Re: [PATCH] dt-bindings: display: Convert Allwinner display pipeline to schemas
On Thu, Dec 19, 2019 at 09:47:55AM +0100, Maxime Ripard wrote: > The Allwinner SoCs have a display engine composed of several controllers > assembled differently depending on the SoC, the number and type of output > they have, and the additional features they provide. A number of those are > supported in Linux, with the matching bindings. > > Now that we have the DT validation in place, let's split into separate file > and convert the device tree bindings for those controllers to schemas. > > Signed-off-by: Maxime Ripard Ping? Maxime ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206021] AMDGPU/DC: freesync disabled on the monitor side after the monitor sleeps and resumes
https://bugzilla.kernel.org/show_bug.cgi?id=206021 --- Comment #3 from Clément Guérin (li...@protonmail.com) --- Created attachment 286535 --> https://bugzilla.kernel.org/attachment.cgi?id=286535=edit manually turning the monitor off and on with drm.debug=6 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206021] AMDGPU/DC: freesync disabled on the monitor side after the monitor sleeps and resumes
https://bugzilla.kernel.org/show_bug.cgi?id=206021 --- Comment #2 from Clément Guérin (li...@protonmail.com) --- Created attachment 286533 --> https://bugzilla.kernel.org/attachment.cgi?id=286533=edit lock/resume with drm.debug=6 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ
[AMD Official Use Only - Internal Distribution Only] > > From: Wentland, Harry > Sent: Monday, December 30, 2019 23:26 > To: Lin, Wayne; dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org > Cc: ly...@redhat.com; Zuo, Jerry; Kazlauskas, Nicholas; Wentland, Harry > Subject: Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ > > On 2019-12-30 2:05 a.m., Wayne Lin wrote: > > [Why] > > According to DP spec, it should shift left 4 digits for NO_STOP_BIT > > in REMOTE_I2C_READ message. Not 5 digits. > > > > [How] > > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in > > drm_dp_encode_sideband_req(). > > > > Signed-off-by: Wayne Lin > > Good catch. Looks like this has been there since the beginning of MST in > the kernel. How did you find this? Did this cause bad EDID reads or some > other problem? If so the commit message should probably mention it. > > Harry Thanks for your time. I found this while I was trying to debug MST issues by using AUX monitor. So far, I don't observe problems that relate to this under my test cases and environment. However, this bit might affect the I2C signal generated by I2C master, I will mention more in the commit message. Thanks. > > > --- > > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c > > b/drivers/gpu/drm/drm_dp_mst_topology.c > > index 1d1bfa49ca2b..0557e225ff67 100644 > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > > @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct > > drm_dp_sideband_msg_req_body *req, > > memcpy([idx], > > req->u.i2c_read.transactions[i].bytes, > > req->u.i2c_read.transactions[i].num_bytes); > > idx += req->u.i2c_read.transactions[i].num_bytes; > > > > - buf[idx] = > > (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 5; > > + buf[idx] = > > (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4; > > buf[idx] |= > > (req->u.i2c_read.transactions[i].i2c_transaction_delay & 0xf); > > idx++; > > } > > -- Wayne Lin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ
[AMD Official Use Only - Internal Distribution Only] > > From: Jani Nikula > Sent: Monday, December 30, 2019 19:15 > To: Lin, Wayne; dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org > Cc: Zuo, Jerry; Kazlauskas, Nicholas; Lin, Wayne > Subject: Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ > > On Mon, 30 Dec 2019, Wayne Lin wrote: > > [Why] > > According to DP spec, it should shift left 4 digits for NO_STOP_BIT > > in REMOTE_I2C_READ message. Not 5 digits. > > > > [How] > > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in > > drm_dp_encode_sideband_req(). > > Which commit introduced the issue? Fixes: tag. Does it need a stable > backport? Does this fix a user visible bug? > > BR, > Jani. > Thanks for your time and reminder. It seems like the issue has been there since very beginning.(commit: ad7f8a1). It doesn't introduce user visible bug under my test cases, but this affects the I2C signal between I2C master and I2C slave. Not pretty sure if there is any eeprom will reset the written offset once received I2C stop. If so, that might cause wrongly reading EDID. I will Cc to stable. Thanks. > > Signed-off-by: Wayne Lin > > --- > > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c > > b/drivers/gpu/drm/drm_dp_mst_topology.c > > index 1d1bfa49ca2b..0557e225ff67 100644 > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > > @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct > > drm_dp_sideband_msg_req_body *req, > > memcpy([idx], > > req->u.i2c_read.transactions[i].bytes, > > req->u.i2c_read.transactions[i].num_bytes); > > idx += req->u.i2c_read.transactions[i].num_bytes; > > > > - buf[idx] = > > (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 5; > > + buf[idx] = > > (req->u.i2c_read.transactions[i].no_stop_bit & 0x1) << 4; > > buf[idx] |= > > (req->u.i2c_read.transactions[i].i2c_transaction_delay & 0xf); > > idx++; > > } > > -- > Jani Nikula, Intel Open Source Graphics Center -- Wayne Lin ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] mediatek drm fixes for 5.5
Hi Dave, Daniel: This include phy timing and plane index fixes. Regards, CK The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a: Linux 5.5-rc1 (2019-12-08 14:57:55 -0800) are available in the Git repository at: https://github.com/ckhu-mediatek/linux.git-tags.git tags/mediatek-drm-fixes-5.5 for you to fetch changes up to e18e0f6b7c8f220774dd68965e8a9b046905acc8: drm/mediatek: reduce the hbp and hfp for phy timing (2019-12-17 10:23:43 +0800) Mediatek DRM fixes for Linux 5.5 Jitao Shi (1): drm/mediatek: reduce the hbp and hfp for phy timing Pi-Hsun Shih (1): drm/mediatek: Check return value of mtk_drm_ddp_comp_for_plane. Yongqiang Niu (1): drm/mediatek: Fix can't get component for external display plane. drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 18 ++--- drivers/gpu/drm/mediatek/mtk_dsi.c | 67 +++-- 2 files changed, 50 insertions(+), 35 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/1] drm/lima: Add optional devfreq support
On Sat, Dec 28, 2019 at 1:37 AM Martin Blumenstingl
wrote:
>
> Most platforms with a Mali-400 or Mali-450 GPU also have support for
> changing the GPU clock frequency. Add devfreq support so the GPU clock
> rate is updated based on the actual GPU usage when the
> "operating-points-v2" property is present in the board.dts.
>
> The actual devfreq code is taken from panfrost_devfreq.c and modified so
> it matches what the lima hardware needs:
> - a call to dev_pm_opp_set_clkname() during initialization because there
> are two clocks on Mali-4x0 IPs. "core" is the one that actually clocks
> the GPU so we need to control it using devfreq.
> - locking when reading or writing the devfreq statistics because (unlike
> than panfrost) we have multiple PP and GP IRQs which may finish jobs
> concurrently.
>
> Signed-off-by: Martin Blumenstingl
> ---
> drivers/gpu/drm/lima/Kconfig| 1 +
> drivers/gpu/drm/lima/Makefile | 3 +-
> drivers/gpu/drm/lima/lima_devfreq.c | 183
> drivers/gpu/drm/lima/lima_devfreq.h | 15 +++
> drivers/gpu/drm/lima/lima_device.c | 4 +
> drivers/gpu/drm/lima/lima_device.h | 17 +++
> drivers/gpu/drm/lima/lima_drv.c | 14 ++-
> drivers/gpu/drm/lima/lima_sched.c | 7 ++
> drivers/gpu/drm/lima/lima_sched.h | 3 +
> 9 files changed, 244 insertions(+), 3 deletions(-)
> create mode 100644 drivers/gpu/drm/lima/lima_devfreq.c
> create mode 100644 drivers/gpu/drm/lima/lima_devfreq.h
>
> diff --git a/drivers/gpu/drm/lima/Kconfig b/drivers/gpu/drm/lima/Kconfig
> index 571dc369a7e9..cdd24b68b5d4 100644
> --- a/drivers/gpu/drm/lima/Kconfig
> +++ b/drivers/gpu/drm/lima/Kconfig
> @@ -10,5 +10,6 @@ config DRM_LIMA
> depends on OF
> select DRM_SCHED
> select DRM_GEM_SHMEM_HELPER
> + select PM_DEVFREQ
> help
> DRM driver for ARM Mali 400/450 GPUs.
> diff --git a/drivers/gpu/drm/lima/Makefile b/drivers/gpu/drm/lima/Makefile
> index a85444b0a1d4..5e5c29875e9c 100644
> --- a/drivers/gpu/drm/lima/Makefile
> +++ b/drivers/gpu/drm/lima/Makefile
> @@ -14,6 +14,7 @@ lima-y := \
> lima_sched.o \
> lima_ctx.o \
> lima_dlbu.o \
> - lima_bcast.o
> + lima_bcast.o \
> + lima_devfreq.o
>
> obj-$(CONFIG_DRM_LIMA) += lima.o
> diff --git a/drivers/gpu/drm/lima/lima_devfreq.c
> b/drivers/gpu/drm/lima/lima_devfreq.c
> new file mode 100644
> index ..a5fd6b8faa77
> --- /dev/null
> +++ b/drivers/gpu/drm/lima/lima_devfreq.c
> @@ -0,0 +1,183 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 Martin Blumenstingl
> + *
> + * Based on panfrost_devfreq.c:
> + * Copyright 2019 Collabora ltd.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "lima_device.h"
> +#include "lima_devfreq.h"
> +
> +static void lima_devfreq_update_utilization(struct lima_device *ldev)
> +{
> + unsigned long irqflags;
> + ktime_t now, last;
> +
> + if (!ldev->devfreq.devfreq)
> + return;
> +
> + spin_lock_irqsave(>devfreq.lock, irqflags);
> +
> + now = ktime_get();
> + last = ldev->devfreq.time_last_update;
> +
> + if (atomic_read(>devfreq.busy_count) > 0)
> + ldev->devfreq.busy_time += ktime_sub(now, last);
> + else
> + ldev->devfreq.idle_time += ktime_sub(now, last);
> +
> + ldev->devfreq.time_last_update = now;
> +
> + spin_unlock_irqrestore(>devfreq.lock, irqflags);
> +}
> +
> +static int lima_devfreq_target(struct device *dev, unsigned long *freq,
> + u32 flags)
> +{
> + struct dev_pm_opp *opp;
> + int err;
> +
> + opp = devfreq_recommended_opp(dev, freq, flags);
> + if (IS_ERR(opp))
> + return PTR_ERR(opp);
> + dev_pm_opp_put(opp);
> +
> + err = dev_pm_opp_set_rate(dev, *freq);
> + if (err)
> + return err;
> +
> + return 0;
> +}
> +
> +static void lima_devfreq_reset(struct lima_device *ldev)
> +{
> + unsigned long irqflags;
> +
> + spin_lock_irqsave(>devfreq.lock, irqflags);
> +
> + ldev->devfreq.busy_time = 0;
> + ldev->devfreq.idle_time = 0;
> + ldev->devfreq.time_last_update = ktime_get();
> +
> + spin_unlock_irqrestore(>devfreq.lock, irqflags);
> +}
> +
> +static int lima_devfreq_get_dev_status(struct device *dev,
> + struct devfreq_dev_status *status)
> +{
> + struct lima_device *ldev = dev_get_drvdata(dev);
> + unsigned long irqflags;
> +
> + lima_devfreq_update_utilization(ldev);
> +
> + status->current_frequency = clk_get_rate(ldev->clk_gpu);
> +
> + spin_lock_irqsave(>devfreq.lock, irqflags);
> +
> + status->total_time = ktime_to_ns(ktime_add(ldev->devfreq.busy_time,
> + ldev->devfreq.idle_time));
> + status->busy_time =
[Bug 206021] New: AMDGPU/DC: freesync disabled on the monitor side after the monitor sleeps and resumes
https://bugzilla.kernel.org/show_bug.cgi?id=206021 Bug ID: 206021 Summary: AMDGPU/DC: freesync disabled on the monitor side after the monitor sleeps and resumes Product: Drivers Version: 2.5 Kernel Version: 5.4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: li...@protonmail.com Regression: No Created attachment 286525 --> https://bugzilla.kernel.org/attachment.cgi?id=286525=edit Freesync ON linux 5.4.6 xorg-server 1.20.6 xf86-video-amdgpu 19.1.0 mesa 19.3.1 gnome-shell 3.34.2 R9 Fury Samsung C27HG70 with 1023.0 firmware Steps to reproduce: - Hit Super+L to lock screen - Wait for the monitor to turn off (blinking status LED) - Wake up screen by hitting any key Before going to sleep, the monitor will show that Freesync is active in the OSD (see freesync_on.jpg attachment). After sleep, Freesync will be disabled in the OSD (see freesync_off.jpg). However the driver still thinks Freesync is active: in games, the screen will turn blank when the framerate goes below 144Hz. It's possible to recover by replugging the displayport cable or by manually powering the monitor off and back on. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206021] AMDGPU/DC: freesync disabled on the monitor side after the monitor sleeps and resumes
https://bugzilla.kernel.org/show_bug.cgi?id=206021 --- Comment #1 from Clément Guérin (li...@protonmail.com) --- Created attachment 286527 --> https://bugzilla.kernel.org/attachment.cgi?id=286527=edit Freesync OFF -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/9] drm/dp: get/set phy compliance pattern
On 30-12-2019 21:41, Harry Wentland wrote:
On 2019-12-30 11:05 a.m., Manna, Animesh wrote:
On 24-12-2019 01:23, Harry Wentland wrote:
On 2019-12-23 12:03 p.m., Animesh Manna wrote:
During phy compliance auto test mode source need to read
requested test pattern from sink through DPCD. After processing
the request source need to set the pattern. So set/get method
added in drm layer as it is DP protocol.
v2: As per review feedback from Manasi on RFC version,
- added dp revision as function argument in set_phy_pattern api.
- used int for link_rate and u8 for lane_count to align with
existing code.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/drm_dp_helper.c | 93
+
include/drm/drm_dp_helper.h | 31 +++
2 files changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c
b/drivers/gpu/drm/drm_dp_helper.c
index 2c7870aef469..91c80973aa83 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1371,3 +1371,96 @@ int
drm_dp_dsc_sink_supported_input_bpcs(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_S
return num_bpc;
}
EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
+
+/**
+ * drm_dp_get_phy_test_pattern() - get the requested pattern from
the sink.
+ * @aux: DisplayPort AUX channel
+ * @data: DP phy compliance test parameters.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
+ struct drm_dp_phy_test_params *data)
+{
+ int err;
+ u8 rate, lanes;
+
+ err = drm_dp_dpcd_readb(aux, DP_TEST_LINK_RATE, );
+ if (err < 0)
+ return err;
+ data->link_rate = drm_dp_bw_code_to_link_rate(rate);
+
+ err = drm_dp_dpcd_readb(aux, DP_TEST_LANE_COUNT, );
+ if (err < 0)
+ return err;
+ data->num_lanes = lanes & DP_MAX_LANE_COUNT_MASK;
+
+ if (lanes & DP_ENHANCED_FRAME_CAP)
+ data->enahanced_frame_cap = true;
+
+ err = drm_dp_dpcd_readb(aux, DP_PHY_TEST_PATTERN,
>phy_pattern);
+ if (err < 0)
+ return err;
+
+ switch (data->phy_pattern) {
+ case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
+ err = drm_dp_dpcd_read(aux, DP_TEST_80BIT_CUSTOM_PATTERN_7_0,
+ >custom80, 10);
Using sizeof(data->custom80) might be safer.
+ if (err < 0)
+ return err;
+
+ break;
+ case DP_PHY_TEST_PATTERN_CP2520:
+ err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
+ >hbr2_reset, 2);
Same here, using sizeof(data->hbr2_reset).
+ if (err < 0)
+ return err;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_phy_test_pattern);
+
+/**
+ * drm_dp_set_phy_test_pattern() - set the pattern to the sink.
+ * @aux: DisplayPort AUX channel
+ * @data: DP phy compliance test parameters.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
+ struct drm_dp_phy_test_params *data, u8 dp_rev)
+{
+ int err, i;
+ u8 link_config[2];
+ u8 test_pattern;
+
+ link_config[0] = drm_dp_link_rate_to_bw_code(data->link_rate);
+ link_config[1] = data->num_lanes;
+ if (data->enahanced_frame_cap)
+ link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
+ err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, link_config, 2);
+ if (err < 0)
+ return err;
+
+ test_pattern = data->phy_pattern;
+ if (dp_rev < 0x12) {
+ test_pattern = (test_pattern << 2) &
+ DP_LINK_QUAL_PATTERN_11_MASK;
+ err = drm_dp_dpcd_writeb(aux, DP_TRAINING_PATTERN_SET,
+ test_pattern);
+ if (err < 0)
+ return err;
+ } else {
+ for (i = 0; i < data->num_lanes; i++) {
+ err = drm_dp_dpcd_writeb(aux,
+ DP_LINK_QUAL_LANE0_SET + i,
+ test_pattern);
+ if (err < 0)
+ return err;
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_set_phy_test_pattern);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index d6e560870fb1..42a364748308 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -700,6 +700,15 @@
# define DP_TEST_COUNT_MASK 0xf
#define DP_PHY_TEST_PATTERN 0x248
+# define DP_PHY_TEST_PATTERN_SEL_MASK 0x7
+# define DP_PHY_TEST_PATTERN_NONE 0x0
+# define DP_PHY_TEST_PATTERN_D10_2 0x1
+# define DP_PHY_TEST_PATTERN_ERROR_COUNT 0x2
+# define DP_PHY_TEST_PATTERN_PRBS7 0x3
+# define DP_PHY_TEST_PATTERN_80BIT_CUSTOM 0x4
+# define DP_PHY_TEST_PATTERN_CP2520 0x5
+
+#define DP_TEST_HBR2_SCRAMBLER_RESET 0x24A
#define DP_TEST_80BIT_CUSTOM_PATTERN_7_0 0x250
#define DP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251
#define DP_TEST_80BIT_CUSTOM_PATTERN_23_16 0x252
@@ -1570,4 +1579,26 @@ static inline void
[PATCH v3 7/9] drm/i915/dp: Register definition for DP compliance register
DP_COMP_CTL and DP_COMP_PAT register used to program DP
compliance pattern.
Reviewed-by: Manasi Navare
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_reg.h | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 030a3f3e69af..a536d920324c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9794,6 +9794,26 @@ enum skl_power_gate {
#define DDI_BUF_BALANCE_LEG_ENABLE(1 << 31)
#define DDI_BUF_TRANS_HI(port, i) _MMIO(_PORT(port, _DDI_BUF_TRANS_A,
_DDI_BUF_TRANS_B) + (i) * 8 + 4)
+/* DDI DP Compliance Control */
+#define DDI_DP_COMP_CTL_A 0x605F0
+#define DDI_DP_COMP_CTL_B 0x615F0
+#define DDI_DP_COMP_CTL(port) _MMIO_PORT(port, DDI_DP_COMP_CTL_A, \
+DDI_DP_COMP_CTL_B)
+#define DDI_DP_COMP_CTL_ENABLE(1 << 31)
+#define DDI_DP_COMP_CTL_D10_2 (0 << 28)
+#define DDI_DP_COMP_CTL_SCRAMBLED_0 (1 << 28)
+#define DDI_DP_COMP_CTL_PRBS7 (2 << 28)
+#define DDI_DP_COMP_CTL_CUSTOM80 (3 << 28)
+#define DDI_DP_COMP_CTL_HBR2 (4 << 28)
+#define DDI_DP_COMP_CTL_SCRAMBLED_1 (5 << 28)
+#define DDI_DP_COMP_CTL_HBR2_RESET(0xFC << 0)
+
+/* DDI DP Compliance Pattern */
+#define DDI_DP_COMP_PAT_A 0x605F4
+#define DDI_DP_COMP_PAT_B 0x615F4
+#define DDI_DP_COMP_PAT(port, i) _MMIO(_PORT(port, DDI_DP_COMP_PAT_A, \
+DDI_DP_COMP_PAT_B) + (i) * 4)
+
/* Sideband Interface (SBI) is programmed indirectly, via
* SBI_ADDR, which contains the register offset; and SBI_DATA,
* which contains the payload */
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/9] drm/i915/dsb: Send uevent to testapp.
Send uevent to testapp and set test_active flag. To align with link
compliance design existing intel_dp_compliance tool will be used to
get the phy request in userspace through uevent.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dp.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index fa67b8f88e65..cbefda9b6204 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5013,6 +5013,9 @@ static u8 intel_dp_autotest_phy_pattern(struct intel_dp
*intel_dp)
if (test_result != DP_TEST_ACK)
DRM_ERROR("Phy test preparation failed\n");
+ /* Set test active flag here so userspace doesn't interrupt things */
+ intel_dp->compliance.test_active = 1;
+
return test_result;
}
@@ -5338,8 +5341,11 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
intel_psr_short_pulse(intel_dp);
- if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
- DRM_DEBUG_KMS("Link Training Compliance Test requested\n");
+ if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING ||
+ intel_dp->compliance.test_type ==
+ DP_TEST_LINK_PHY_TEST_PATTERN) {
+ DRM_DEBUG_KMS("Compliance Test requested, test-type = 0x%lx\n",
+ intel_dp->compliance.test_type);
/* Send a Hotplug Uevent to userspace to start modeset */
drm_kms_helper_hotplug_event(_priv->drm);
}
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/9] drm/amd/display: Align macro name as per DP spec
[Why]: Aligh with DP spec wanted to follow same naming convention. [How]: Changed the macro name of the dpcd address used for getting requested test-pattern. Cc: Harry Wentland Cc: Alex Deucher Reviewed-by: Harry Wentland Signed-off-by: Animesh Manna --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- include/drm/drm_dp_helper.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 42aa889fd0f5..1a6109be2fce 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -2491,7 +2491,7 @@ static void dp_test_send_phy_test_pattern(struct dc_link *link) /* get phy test pattern and pattern parameters from DP receiver */ core_link_read_dpcd( link, - DP_TEST_PHY_PATTERN, + DP_PHY_TEST_PATTERN, _test_pattern.raw, sizeof(dpcd_test_pattern)); core_link_read_dpcd( diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 8f8f3632e697..d6e560870fb1 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -699,7 +699,7 @@ # define DP_TEST_CRC_SUPPORTED (1 << 5) # define DP_TEST_COUNT_MASK0xf -#define DP_TEST_PHY_PATTERN 0x248 +#define DP_PHY_TEST_PATTERN 0x248 #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250 #defineDP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251 #defineDP_TEST_80BIT_CUSTOM_PATTERN_23_16 0x252 -- 2.24.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 8/9] drm/i915/dp: Update the pattern as per request
As per request from DP phy compliance test few special
test pattern need to set by source. Added function
to set pattern in DP_COMP_CTL register. It will be
called along with other test parameters like vswing,
pre-emphasis programming in atomic_commit_tail path.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dp.c | 55 +
1 file changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index cbefda9b6204..7c3f65e5d88b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5005,6 +5005,61 @@ static u8 intel_dp_prepare_phytest(struct intel_dp
*intel_dp)
return DP_TEST_ACK;
}
+static inline void intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *dev_priv =
+ to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_dp_phy_test_params *data =
+ _dp->compliance.test_data.phytest;
+ u32 temp;
+
+ switch (data->phy_pattern) {
+ case DP_PHY_TEST_PATTERN_NONE:
+ DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
+ I915_WRITE(DDI_DP_COMP_CTL(intel_dig_port->base.port), 0x0);
+ break;
+ case DP_PHY_TEST_PATTERN_D10_2:
+ DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
+ I915_WRITE(DDI_DP_COMP_CTL(intel_dig_port->base.port),
+ DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
+ break;
+ case DP_PHY_TEST_PATTERN_ERROR_COUNT:
+ DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
+ I915_WRITE(DDI_DP_COMP_CTL(intel_dig_port->base.port),
+ DDI_DP_COMP_CTL_ENABLE |
+ DDI_DP_COMP_CTL_SCRAMBLED_0);
+ break;
+ case DP_PHY_TEST_PATTERN_PRBS7:
+ DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
+ I915_WRITE(DDI_DP_COMP_CTL(intel_dig_port->base.port),
+ DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
+ break;
+ case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
+ DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern\n");
+ temp = ((data->custom80[0] << 24) | (data->custom80[1] << 16) |
+ (data->custom80[2] << 8) | (data->custom80[3]));
+ I915_WRITE(DDI_DP_COMP_PAT(intel_dig_port->base.port, 0), temp);
+ temp = ((data->custom80[4] << 24) | (data->custom80[5] << 16) |
+ (data->custom80[6] << 8) | (data->custom80[7]));
+ I915_WRITE(DDI_DP_COMP_PAT(intel_dig_port->base.port, 1), temp);
+ temp = ((data->custom80[8] << 8) | data->custom80[9]);
+ I915_WRITE(DDI_DP_COMP_PAT(intel_dig_port->base.port, 2), temp);
+ I915_WRITE(DDI_DP_COMP_CTL(intel_dig_port->base.port),
+ DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_CUSTOM80);
+ break;
+ case DP_PHY_TEST_PATTERN_CP2520:
+ DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
+ temp = ((data->hbr2_reset[1] << 8) | data->hbr2_reset[0]);
+ I915_WRITE(DDI_DP_COMP_CTL(intel_dig_port->base.port),
+ DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
+ temp);
+ break;
+ default:
+ WARN(1, "Invalid Phy Test PAttern\n");
+ }
+}
+
static u8 intel_dp_autotest_phy_pattern(struct intel_dp *intel_dp)
{
u8 test_result = DP_TEST_NAK;
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/9] drm/i915/dp: Move vswing/pre-emphasis adjustment calculation
vswing/pre-emphasis adjustment calculation is needed in processing
of auto phy compliance request other than link training, so moved
the same function in intel_dp.c.
No functional change.
v1: initial patch.
v2:
- used "intel_dp" prefix in function name. (Jani)
- used array notation instead pointer for link_status. (Ville)
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_dp.c | 34 ++
drivers/gpu/drm/i915/display/intel_dp.h | 4 +++
.../drm/i915/display/intel_dp_link_training.c | 36 ++-
3 files changed, 40 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 991f343579ef..2a27ee106089 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4110,6 +4110,40 @@ ivb_cpu_edp_signal_levels(u8 train_set)
}
}
+void
+intel_dp_get_adjust_train(struct intel_dp *intel_dp,
+ const u8 link_status[DP_LINK_STATUS_SIZE])
+{
+ u8 v = 0;
+ u8 p = 0;
+ int lane;
+ u8 voltage_max;
+ u8 preemph_max;
+
+ for (lane = 0; lane < intel_dp->lane_count; lane++) {
+ u8 this_v = drm_dp_get_adjust_request_voltage(link_status,
+ lane);
+ u8 this_p = drm_dp_get_adjust_request_pre_emphasis(link_status,
+ lane);
+
+ if (this_v > v)
+ v = this_v;
+ if (this_p > p)
+ p = this_p;
+ }
+
+ voltage_max = intel_dp_voltage_max(intel_dp);
+ if (v >= voltage_max)
+ v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
+
+ preemph_max = intel_dp_pre_emphasis_max(intel_dp, v);
+ if (p >= preemph_max)
+ p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
+
+ for (lane = 0; lane < 4; lane++)
+ intel_dp->train_set[lane] = v | p;
+}
+
void
intel_dp_set_signal_levels(struct intel_dp *intel_dp)
{
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 3da166054788..83eadc87af26 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -9,6 +9,7 @@
#include
#include
+#include
#include "i915_reg.h"
@@ -91,6 +92,9 @@ void
intel_dp_program_link_training_pattern(struct intel_dp *intel_dp,
u8 dp_train_pat);
void
+intel_dp_get_adjust_train(struct intel_dp *intel_dp,
+ const u8 link_status[DP_LINK_STATUS_SIZE]);
+void
intel_dp_set_signal_levels(struct intel_dp *intel_dp);
void intel_dp_set_idle_link_train(struct intel_dp *intel_dp);
u8
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index 2a1130dd1ad0..e8ff9e279800 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -34,38 +34,6 @@ intel_dp_dump_link_status(const u8
link_status[DP_LINK_STATUS_SIZE])
link_status[3], link_status[4], link_status[5]);
}
-static void
-intel_get_adjust_train(struct intel_dp *intel_dp,
- const u8 link_status[DP_LINK_STATUS_SIZE])
-{
- u8 v = 0;
- u8 p = 0;
- int lane;
- u8 voltage_max;
- u8 preemph_max;
-
- for (lane = 0; lane < intel_dp->lane_count; lane++) {
- u8 this_v = drm_dp_get_adjust_request_voltage(link_status,
lane);
- u8 this_p = drm_dp_get_adjust_request_pre_emphasis(link_status,
lane);
-
- if (this_v > v)
- v = this_v;
- if (this_p > p)
- p = this_p;
- }
-
- voltage_max = intel_dp_voltage_max(intel_dp);
- if (v >= voltage_max)
- v = voltage_max | DP_TRAIN_MAX_SWING_REACHED;
-
- preemph_max = intel_dp_pre_emphasis_max(intel_dp, v);
- if (p >= preemph_max)
- p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
-
- for (lane = 0; lane < 4; lane++)
- intel_dp->train_set[lane] = v | p;
-}
-
static bool
intel_dp_set_link_train(struct intel_dp *intel_dp,
u8 dp_train_pat)
@@ -215,7 +183,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp)
voltage = intel_dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK;
/* Update training set as requested by target */
- intel_get_adjust_train(intel_dp, link_status);
+ intel_dp_get_adjust_train(intel_dp, link_status);
if (!intel_dp_update_link_train(intel_dp)) {
DRM_ERROR("failed to update link training\n");
return false;
@@ -325,7 +293,7 @@
[PATCH v3 4/9] drm/i915/dp: Preparation for DP phy compliance auto test
During DP phy compliance auto test mode, sink will request
combination of different test pattern with differnt level of
vswing, pre-emphasis. Function added to prepare for it.
Reviewed-by: Manasi Navare
Signed-off-by: Animesh Manna
---
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 24 +++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 630a94892b7b..32f0740e4569 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1208,6 +1208,7 @@ struct intel_dp_compliance_data {
u8 video_pattern;
u16 hdisplay, vdisplay;
u8 bpc;
+ struct drm_dp_phy_test_params phytest;
};
struct intel_dp_compliance {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 2a27ee106089..fa67b8f88e65 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4986,9 +4986,33 @@ static u8 intel_dp_autotest_edid(struct intel_dp
*intel_dp)
return test_result;
}
+static u8 intel_dp_prepare_phytest(struct intel_dp *intel_dp)
+{
+ struct drm_dp_phy_test_params *data =
+ _dp->compliance.test_data.phytest;
+
+ if (drm_dp_get_phy_test_pattern(_dp->aux, data)) {
+ DRM_DEBUG_KMS("DP Phy Test pattern AUX read failure\n");
+ return DP_TEST_NAK;
+ }
+
+ /*
+* link_mst is set to false to avoid executing mst related code
+* during compliance testing.
+*/
+ intel_dp->link_mst = false;
+
+ return DP_TEST_ACK;
+}
+
static u8 intel_dp_autotest_phy_pattern(struct intel_dp *intel_dp)
{
u8 test_result = DP_TEST_NAK;
+
+ test_result = intel_dp_prepare_phytest(intel_dp);
+ if (test_result != DP_TEST_ACK)
+ DRM_ERROR("Phy test preparation failed\n");
+
return test_result;
}
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/9] drm/i915/dp: Add debugfs entry for DP phy compliance.
These debugfs entry will help testapp to understand the test request
during dp phy compliance mode.
Acked-by: Manasi Navare
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0ac98e39eb75..a903ed0632cb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3177,6 +3177,16 @@ static int i915_displayport_test_data_show(struct
seq_file *m, void *data)
intel_dp->compliance.test_data.vdisplay);
seq_printf(m, "bpc: %u\n",
intel_dp->compliance.test_data.bpc);
+ } else if (intel_dp->compliance.test_type ==
+ DP_TEST_LINK_PHY_TEST_PATTERN) {
+ seq_printf(m, "pattern: %d\n",
+
intel_dp->compliance.test_data.phytest.phy_pattern);
+ seq_printf(m, "Number of lanes: %d\n",
+
intel_dp->compliance.test_data.phytest.num_lanes);
+ seq_printf(m, "Link Rate: %d\n",
+
intel_dp->compliance.test_data.phytest.link_rate);
+ seq_printf(m, "level: %02x\n",
+ intel_dp->train_set[0]);
}
} else
seq_puts(m, "0");
@@ -3209,7 +3219,7 @@ static int i915_displayport_test_type_show(struct
seq_file *m, void *data)
if (encoder && connector->status == connector_status_connected)
{
intel_dp = enc_to_intel_dp(>base);
- seq_printf(m, "%02lx", intel_dp->compliance.test_type);
+ seq_printf(m, "%02lx\n",
intel_dp->compliance.test_type);
} else
seq_puts(m, "0");
}
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 9/9] drm/i915/dp: [FIXME] Program vswing, pre-emphasis, test-pattern
This patch process phy compliance request by programming requested
vswing, pre-emphasis and test pattern.
Note: FIXME tag added as design discusion is ongoing in previous patch
series. Some temporary fix added and the patch is under-development, not for
review.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/display/intel_display.c | 24 ++-
drivers/gpu/drm/i915/display/intel_dp.c | 74
drivers/gpu/drm/i915/display/intel_dp.h | 2 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
4 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index da5266e76738..c00be1eb67d6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14480,6 +14480,9 @@ static int intel_atomic_check(struct drm_device *dev,
int ret, i;
bool any_ms = false;
+ if (dev_priv->dp_phy_comp)
+ return 0;
+
/* Catch I915_MODE_FLAG_INHERITED */
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
@@ -15207,10 +15210,23 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc_state *new_crtc_state, *old_crtc_state;
struct intel_crtc *crtc;
+ const struct drm_connector_state *conn_state;
+ struct drm_connector *conn;
u64 put_domains[I915_MAX_PIPES] = {};
intel_wakeref_t wakeref = 0;
int i;
+ if(dev_priv->dp_phy_comp) {
+ for_each_new_connector_in_state(>base, conn, conn_state,
i) {
+ struct intel_encoder *encoder =
+ to_intel_encoder(conn_state->best_encoder);
+ struct intel_dp *intel_dp =
enc_to_intel_dp(>base);
+
+ intel_dp_process_phy_request(intel_dp);
+ }
+ goto dp_phy_comp1;
+ }
+
intel_atomic_commit_fence_wait(state);
drm_atomic_helper_wait_for_dependencies(>base);
@@ -15345,6 +15361,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
if (state->modeset && intel_can_enable_sagv(state))
intel_enable_sagv(dev_priv);
+dp_phy_comp1:
drm_atomic_helper_commit_hw_done(>base);
if (state->modeset) {
@@ -15436,6 +15453,7 @@ static int intel_atomic_commit(struct drm_device *dev,
state->wakeref = intel_runtime_pm_get(_priv->runtime_pm);
drm_atomic_state_get(>base);
+ if (!dev_priv->dp_phy_comp) {
i915_sw_fence_init(>commit_ready,
intel_atomic_commit_ready);
@@ -15474,11 +15492,13 @@ static int intel_atomic_commit(struct drm_device *dev,
intel_runtime_pm_put(_priv->runtime_pm, state->wakeref);
return ret;
}
+ }
ret = drm_atomic_helper_setup_commit(>base, nonblock);
if (!ret)
ret = drm_atomic_helper_swap_state(>base, true);
+ if (!dev_priv->dp_phy_comp) {
if (ret) {
i915_sw_fence_commit(>commit_ready);
@@ -15489,6 +15509,7 @@ static int intel_atomic_commit(struct drm_device *dev,
dev_priv->wm.distrust_bios_wm = false;
intel_shared_dpll_swap_state(state);
intel_atomic_track_fbs(state);
+ }
if (state->global_state_changed) {
assert_global_state_locked(dev_priv);
@@ -15505,8 +15526,9 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_state_get(>base);
INIT_WORK(>base.commit_work, intel_atomic_commit_work);
-
+ if (!dev_priv->dp_phy_comp) {
i915_sw_fence_commit(>commit_ready);
+ }
if (nonblock && state->modeset) {
queue_work(dev_priv->modeset_wq, >base.commit_work);
} else if (nonblock) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 7c3f65e5d88b..c3454053a212 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5060,9 +5060,82 @@ static inline void intel_dp_phy_pattern_update(struct
intel_dp *intel_dp)
}
}
+static void
+intel_dp_autotest_phy_ddi_disable(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum port port = intel_dig_port->base.port;
+ u32 ddi_buf_ctl_value, dp_tp_ctl_value, trans_ddi_func_ctl_value;
+
+ ddi_buf_ctl_value = I915_READ(DDI_BUF_CTL(port));
+ dp_tp_ctl_value = I915_READ(TGL_DP_TP_CTL(port));
+ trans_ddi_func_ctl_value = I915_READ(TRANS_DDI_FUNC_CTL(port));
+
+
[PATCH v3 0/9] DP Phy compliance auto test
Driver changes mainly to process the request coming from Test equipment as short pulse hpd interrupt to change link-pattern/v-swing/pre-emphasis Complete auto test suite takes much lesser time than manual run. Overall design: -- Automate test request will come to source device as HDP short pulse interrupt from test scope. Read DPCD 0x201, Check for bit 1 for automated test request. If set continue and read DPCD 0x218. Check for bit 3 for phy test pattern, If set continue. Get the requested test pattern through DPCD 0x248. Compute requested voltage swing level and pre-emphasis level from DPCD 0x206 and 0x207 Set signal level through vswing programming sequence. Write DDI_COMP_CTL and DDI_COMP_PATx as per requested pattern. Configure the link and write the new test pattern through DPCD. High level patch description. - patch 1: drm level api added to get/set test pattern as per vesa DP spec. This maybe useful for other driver so added in drm layer. patch 2: Fix for a compilation issue. patch 3: vswing/preemphasis adjustment calculation is needed during phy compliance request processing along with existing link training process, so moved the same function in intel_dp.c. patch 4: Parse the test scope request regarding rquested test pattern, vswing level, preemphasis level. patch 5: Notify testapp through uevent. patch 6: Added debugfs entry for phy compliance. patch 7: Register difnition of DP compliance register added. patch 8: Function added to update the pattern in source side. patch 9: This patch os mainly processing the request. Currently through prototyping patch able to run DP compliance where vswing, preemphasis and test pattern is changing fine but complete test is under process. As per feedback redesigned the code. Could not test due to unavailability of test scope, so sending as RFC again to get design feedback. v1: Redesigned the code as per review feedback from Manasi on RFC. v2: Addressed review comments from Manasi. v3: Addressed review commnets from Harry, Ville, Jani. Animesh Manna (9): drm/amd/display: Align macro name as per DP spec drm/dp: get/set phy compliance pattern drm/i915/dp: Move vswing/pre-emphasis adjustment calculation drm/i915/dp: Preparation for DP phy compliance auto test drm/i915/dsb: Send uevent to testapp. drm/i915/dp: Add debugfs entry for DP phy compliance. drm/i915/dp: Register definition for DP compliance register drm/i915/dp: Update the pattern as per request drm/i915/dp: [FIXME] Program vswing, pre-emphasis, test-pattern .../gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- drivers/gpu/drm/drm_dp_helper.c | 94 + drivers/gpu/drm/i915/display/intel_display.c | 24 ++- .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_dp.c | 197 +- drivers/gpu/drm/i915/display/intel_dp.h | 6 + .../drm/i915/display/intel_dp_link_training.c | 36 +--- drivers/gpu/drm/i915/i915_debugfs.c | 12 +- drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_reg.h | 20 ++ include/drm/drm_dp_helper.h | 33 ++- 11 files changed, 387 insertions(+), 40 deletions(-) -- 2.24.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/9] drm/dp: get/set phy compliance pattern
During phy compliance auto test mode source need to read
requested test pattern from sink through DPCD. After processing
the request source need to set the pattern. So set/get method
added in drm layer as it is DP protocol.
v2: As per review feedback from Manasi on RFC version,
- added dp revision as function argument in set_phy_pattern api.
- used int for link_rate and u8 for lane_count to align with existing code.
v3: As per review feedback from Harry,
- used sizeof() instead of magic number.
- corrected kernel-doc for drm_dp_phy_test_params structure.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/drm_dp_helper.c | 94 +
include/drm/drm_dp_helper.h | 31 +++
2 files changed, 125 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 2c7870aef469..8a0786dd262d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1371,3 +1371,97 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_S
return num_bpc;
}
EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
+
+/**
+ * drm_dp_get_phy_test_pattern() - get the requested pattern from the sink.
+ * @aux: DisplayPort AUX channel
+ * @data: DP phy compliance test parameters.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
+ struct drm_dp_phy_test_params *data)
+{
+ int err;
+ u8 rate, lanes;
+
+ err = drm_dp_dpcd_readb(aux, DP_TEST_LINK_RATE, );
+ if (err < 0)
+ return err;
+ data->link_rate = drm_dp_bw_code_to_link_rate(rate);
+
+ err = drm_dp_dpcd_readb(aux, DP_TEST_LANE_COUNT, );
+ if (err < 0)
+ return err;
+ data->num_lanes = lanes & DP_MAX_LANE_COUNT_MASK;
+
+ if (lanes & DP_ENHANCED_FRAME_CAP)
+ data->enhanced_frame_cap = true;
+
+ err = drm_dp_dpcd_readb(aux, DP_PHY_TEST_PATTERN, >phy_pattern);
+ if (err < 0)
+ return err;
+
+ switch (data->phy_pattern) {
+ case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
+ err = drm_dp_dpcd_read(aux, DP_TEST_80BIT_CUSTOM_PATTERN_7_0,
+ >custom80, sizeof(data->custom80));
+ if (err < 0)
+ return err;
+
+ break;
+ case DP_PHY_TEST_PATTERN_CP2520:
+ err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
+ >hbr2_reset,
+ sizeof(data->hbr2_reset));
+ if (err < 0)
+ return err;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_phy_test_pattern);
+
+/**
+ * drm_dp_set_phy_test_pattern() - set the pattern to the sink.
+ * @aux: DisplayPort AUX channel
+ * @data: DP phy compliance test parameters.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
+ struct drm_dp_phy_test_params *data, u8 dp_rev)
+{
+ int err, i;
+ u8 link_config[2];
+ u8 test_pattern;
+
+ link_config[0] = drm_dp_link_rate_to_bw_code(data->link_rate);
+ link_config[1] = data->num_lanes;
+ if (data->enhanced_frame_cap)
+ link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
+ err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, link_config, 2);
+ if (err < 0)
+ return err;
+
+ test_pattern = data->phy_pattern;
+ if (dp_rev < 0x12) {
+ test_pattern = (test_pattern << 2) &
+ DP_LINK_QUAL_PATTERN_11_MASK;
+ err = drm_dp_dpcd_writeb(aux, DP_TRAINING_PATTERN_SET,
+test_pattern);
+ if (err < 0)
+ return err;
+ } else {
+ for (i = 0; i < data->num_lanes; i++) {
+ err = drm_dp_dpcd_writeb(aux,
+DP_LINK_QUAL_LANE0_SET + i,
+test_pattern);
+ if (err < 0)
+ return err;
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_set_phy_test_pattern);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index d6e560870fb1..3d0e9e0d55cf 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -700,6 +700,15 @@
# define DP_TEST_COUNT_MASK0xf
#define DP_PHY_TEST_PATTERN 0x248
+# define DP_PHY_TEST_PATTERN_SEL_MASK 0x7
+# define DP_PHY_TEST_PATTERN_NONE 0x0
+# define DP_PHY_TEST_PATTERN_D10_2 0x1
+# define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
+# define DP_PHY_TEST_PATTERN_PRBS7 0x3
+# define DP_PHY_TEST_PATTERN_80BIT_CUSTOM 0x4
Re: [PATCH v3 2/9] drm/dp: get/set phy compliance pattern
On 2019-12-30 11:05 a.m., Manna, Animesh wrote:
> On 24-12-2019 01:23, Harry Wentland wrote:
>>
>> On 2019-12-23 12:03 p.m., Animesh Manna wrote:
>>> During phy compliance auto test mode source need to read
>>> requested test pattern from sink through DPCD. After processing
>>> the request source need to set the pattern. So set/get method
>>> added in drm layer as it is DP protocol.
>>>
>>> v2: As per review feedback from Manasi on RFC version,
>>> - added dp revision as function argument in set_phy_pattern api.
>>> - used int for link_rate and u8 for lane_count to align with
>>> existing code.
>>>
>>> Signed-off-by: Animesh Manna
>>> ---
>>> drivers/gpu/drm/drm_dp_helper.c | 93
>>> +
>>> include/drm/drm_dp_helper.h | 31 +++
>>> 2 files changed, 124 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>>> b/drivers/gpu/drm/drm_dp_helper.c
>>> index 2c7870aef469..91c80973aa83 100644
>>> --- a/drivers/gpu/drm/drm_dp_helper.c
>>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>>> @@ -1371,3 +1371,96 @@ int
>>> drm_dp_dsc_sink_supported_input_bpcs(const u8
>>> dsc_dpcd[DP_DSC_RECEIVER_CAP_S
>>> return num_bpc;
>>> }
>>> EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
>>> +
>>> +/**
>>> + * drm_dp_get_phy_test_pattern() - get the requested pattern from
>>> the sink.
>>> + * @aux: DisplayPort AUX channel
>>> + * @data: DP phy compliance test parameters.
>>> + *
>>> + * Returns 0 on success or a negative error code on failure.
>>> + */
>>> +int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
>>> + struct drm_dp_phy_test_params *data)
>>> +{
>>> + int err;
>>> + u8 rate, lanes;
>>> +
>>> + err = drm_dp_dpcd_readb(aux, DP_TEST_LINK_RATE, );
>>> + if (err < 0)
>>> + return err;
>>> + data->link_rate = drm_dp_bw_code_to_link_rate(rate);
>>> +
>>> + err = drm_dp_dpcd_readb(aux, DP_TEST_LANE_COUNT, );
>>> + if (err < 0)
>>> + return err;
>>> + data->num_lanes = lanes & DP_MAX_LANE_COUNT_MASK;
>>> +
>>> + if (lanes & DP_ENHANCED_FRAME_CAP)
>>> + data->enahanced_frame_cap = true;
>>> +
>>> + err = drm_dp_dpcd_readb(aux, DP_PHY_TEST_PATTERN,
>>> >phy_pattern);
>>> + if (err < 0)
>>> + return err;
>>> +
>>> + switch (data->phy_pattern) {
>>> + case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
>>> + err = drm_dp_dpcd_read(aux, DP_TEST_80BIT_CUSTOM_PATTERN_7_0,
>>> + >custom80, 10);
>> Using sizeof(data->custom80) might be safer.
>>
>>> + if (err < 0)
>>> + return err;
>>> +
>>> + break;
>>> + case DP_PHY_TEST_PATTERN_CP2520:
>>> + err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
>>> + >hbr2_reset, 2);
>> Same here, using sizeof(data->hbr2_reset).
>>
>>> + if (err < 0)
>>> + return err;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL(drm_dp_get_phy_test_pattern);
>>> +
>>> +/**
>>> + * drm_dp_set_phy_test_pattern() - set the pattern to the sink.
>>> + * @aux: DisplayPort AUX channel
>>> + * @data: DP phy compliance test parameters.
>>> + *
>>> + * Returns 0 on success or a negative error code on failure.
>>> + */
>>> +int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
>>> + struct drm_dp_phy_test_params *data, u8 dp_rev)
>>> +{
>>> + int err, i;
>>> + u8 link_config[2];
>>> + u8 test_pattern;
>>> +
>>> + link_config[0] = drm_dp_link_rate_to_bw_code(data->link_rate);
>>> + link_config[1] = data->num_lanes;
>>> + if (data->enahanced_frame_cap)
>>> + link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
>>> + err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, link_config, 2);
>>> + if (err < 0)
>>> + return err;
>>> +
>>> + test_pattern = data->phy_pattern;
>>> + if (dp_rev < 0x12) {
>>> + test_pattern = (test_pattern << 2) &
>>> + DP_LINK_QUAL_PATTERN_11_MASK;
>>> + err = drm_dp_dpcd_writeb(aux, DP_TRAINING_PATTERN_SET,
>>> + test_pattern);
>>> + if (err < 0)
>>> + return err;
>>> + } else {
>>> + for (i = 0; i < data->num_lanes; i++) {
>>> + err = drm_dp_dpcd_writeb(aux,
>>> + DP_LINK_QUAL_LANE0_SET + i,
>>> + test_pattern);
>>> + if (err < 0)
>>> + return err;
>>> + }
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +EXPORT_SYMBOL(drm_dp_set_phy_test_pattern);
>>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>>> index d6e560870fb1..42a364748308 100644
>>> --- a/include/drm/drm_dp_helper.h
>>> +++ b/include/drm/drm_dp_helper.h
>>> @@ -700,6 +700,15 @@
>>> # define DP_TEST_COUNT_MASK 0xf
>>> #define DP_PHY_TEST_PATTERN 0x248
>>> +# define DP_PHY_TEST_PATTERN_SEL_MASK 0x7
>>> +# define DP_PHY_TEST_PATTERN_NONE 0x0
>>> +# define DP_PHY_TEST_PATTERN_D10_2
Re: [PATCH v3 2/9] drm/dp: get/set phy compliance pattern
On 24-12-2019 01:23, Harry Wentland wrote:
On 2019-12-23 12:03 p.m., Animesh Manna wrote:
During phy compliance auto test mode source need to read
requested test pattern from sink through DPCD. After processing
the request source need to set the pattern. So set/get method
added in drm layer as it is DP protocol.
v2: As per review feedback from Manasi on RFC version,
- added dp revision as function argument in set_phy_pattern api.
- used int for link_rate and u8 for lane_count to align with existing code.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/drm_dp_helper.c | 93 +
include/drm/drm_dp_helper.h | 31 +++
2 files changed, 124 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 2c7870aef469..91c80973aa83 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1371,3 +1371,96 @@ int drm_dp_dsc_sink_supported_input_bpcs(const u8
dsc_dpcd[DP_DSC_RECEIVER_CAP_S
return num_bpc;
}
EXPORT_SYMBOL(drm_dp_dsc_sink_supported_input_bpcs);
+
+/**
+ * drm_dp_get_phy_test_pattern() - get the requested pattern from the sink.
+ * @aux: DisplayPort AUX channel
+ * @data: DP phy compliance test parameters.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
+ struct drm_dp_phy_test_params *data)
+{
+ int err;
+ u8 rate, lanes;
+
+ err = drm_dp_dpcd_readb(aux, DP_TEST_LINK_RATE, );
+ if (err < 0)
+ return err;
+ data->link_rate = drm_dp_bw_code_to_link_rate(rate);
+
+ err = drm_dp_dpcd_readb(aux, DP_TEST_LANE_COUNT, );
+ if (err < 0)
+ return err;
+ data->num_lanes = lanes & DP_MAX_LANE_COUNT_MASK;
+
+ if (lanes & DP_ENHANCED_FRAME_CAP)
+ data->enahanced_frame_cap = true;
+
+ err = drm_dp_dpcd_readb(aux, DP_PHY_TEST_PATTERN, >phy_pattern);
+ if (err < 0)
+ return err;
+
+ switch (data->phy_pattern) {
+ case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
+ err = drm_dp_dpcd_read(aux, DP_TEST_80BIT_CUSTOM_PATTERN_7_0,
+ >custom80, 10);
Using sizeof(data->custom80) might be safer.
+ if (err < 0)
+ return err;
+
+ break;
+ case DP_PHY_TEST_PATTERN_CP2520:
+ err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
+ >hbr2_reset, 2);
Same here, using sizeof(data->hbr2_reset).
+ if (err < 0)
+ return err;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_get_phy_test_pattern);
+
+/**
+ * drm_dp_set_phy_test_pattern() - set the pattern to the sink.
+ * @aux: DisplayPort AUX channel
+ * @data: DP phy compliance test parameters.
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_set_phy_test_pattern(struct drm_dp_aux *aux,
+ struct drm_dp_phy_test_params *data, u8 dp_rev)
+{
+ int err, i;
+ u8 link_config[2];
+ u8 test_pattern;
+
+ link_config[0] = drm_dp_link_rate_to_bw_code(data->link_rate);
+ link_config[1] = data->num_lanes;
+ if (data->enahanced_frame_cap)
+ link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
+ err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, link_config, 2);
+ if (err < 0)
+ return err;
+
+ test_pattern = data->phy_pattern;
+ if (dp_rev < 0x12) {
+ test_pattern = (test_pattern << 2) &
+ DP_LINK_QUAL_PATTERN_11_MASK;
+ err = drm_dp_dpcd_writeb(aux, DP_TRAINING_PATTERN_SET,
+test_pattern);
+ if (err < 0)
+ return err;
+ } else {
+ for (i = 0; i < data->num_lanes; i++) {
+ err = drm_dp_dpcd_writeb(aux,
+DP_LINK_QUAL_LANE0_SET + i,
+test_pattern);
+ if (err < 0)
+ return err;
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_set_phy_test_pattern);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index d6e560870fb1..42a364748308 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -700,6 +700,15 @@
# define DP_TEST_COUNT_MASK 0xf
#define DP_PHY_TEST_PATTERN 0x248
+# define DP_PHY_TEST_PATTERN_SEL_MASK 0x7
+# define DP_PHY_TEST_PATTERN_NONE 0x0
+# define DP_PHY_TEST_PATTERN_D10_2 0x1
+# define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
+# define DP_PHY_TEST_PATTERN_PRBS7 0x3
+# define DP_PHY_TEST_PATTERN_80BIT_CUSTOM 0x4
+# define
[Bug 206017] Kernel 5.4.x unusable with GUI due to [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!
https://bugzilla.kernel.org/show_bug.cgi?id=206017 --- Comment #1 from udo (udo...@xs4all.nl) --- See https://gitlab.freedesktop.org/drm/amd/issues/934 for more details. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206017] New: Kernel 5.4.x unusable with GUI due to [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!
https://bugzilla.kernel.org/show_bug.cgi?id=206017 Bug ID: 206017 Summary: Kernel 5.4.x unusable with GUI due to [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! Product: Drivers Version: 2.5 Kernel Version: 5.4.x Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: udo...@xs4all.nl Regression: No AMD Ryzen 5 3400G with Radeon Vega Graphics on Gigabyte X570 AORUS PRO, running Fedora 31, kernel.org kernels, git mesa, etc After booting into 5.4, soon the GUI freezes, e.g. right when I start Firefox. On 5.3.18 it takes days to crash amdgpu. Soft recovery does not help. 5.3.18 is EOLed so 5.4 issues need priority: (..) [ 12.884828] pps pps0: new PPS source serial0 [ 12.884832] pps pps0: source "/dev/ttyS0" added [ 12.898511] it87: it87 driver version [ 12.898635] it87: Found IT8792E/IT8795E chip at 0xa60, revision 3 [ 12.898675] it87: Beeping is supported [ 14.244524] igb :04:00.0: changing MTU from 1500 to 7200 [ 17.328845] igb :04:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [ 17.331973] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 18.564142] io scheduler mq-deadline registered [ 22.352636] igb :04:00.0 eth0: igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [ 31.464130] fuse: init (API version 7.31) [ 75.198868] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out! [ 80.318799] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: Move radeon and amdgpu Kconfig options into their directories
Most Kconfig options to enable a driver are in the Kconfig file inside the relevant directory, move these two to the same. Signed-off-by: Andrew F. Davis --- Changes from v1: - Rebased drivers/gpu/drm/Kconfig| 34 -- drivers/gpu/drm/amd/amdgpu/Kconfig | 18 drivers/gpu/drm/radeon/Kconfig | 18 3 files changed, 36 insertions(+), 34 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index bfdadc3667e0..714ae842b7ce 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -231,42 +231,8 @@ source "drivers/gpu/drm/i2c/Kconfig" source "drivers/gpu/drm/arm/Kconfig" -config DRM_RADEON - tristate "ATI Radeon" - depends on DRM && PCI && MMU - select FW_LOADER -select DRM_KMS_HELPER -select DRM_TTM - select POWER_SUPPLY - select HWMON - select BACKLIGHT_CLASS_DEVICE - select INTERVAL_TREE - help - Choose this option if you have an ATI Radeon graphics card. There - are both PCI and AGP versions. You don't need to choose this to - run the Radeon in plain VGA mode. - - If M is selected, the module will be called radeon. - source "drivers/gpu/drm/radeon/Kconfig" -config DRM_AMDGPU - tristate "AMD GPU" - depends on DRM && PCI && MMU - select FW_LOADER - select DRM_KMS_HELPER - select DRM_SCHED - select DRM_TTM - select POWER_SUPPLY - select HWMON - select BACKLIGHT_CLASS_DEVICE - select INTERVAL_TREE - select CHASH - help - Choose this option if you have a recent AMD Radeon graphics card. - - If M is selected, the module will be called amdgpu. - source "drivers/gpu/drm/amd/amdgpu/Kconfig" source "drivers/gpu/drm/nouveau/Kconfig" diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig b/drivers/gpu/drm/amd/amdgpu/Kconfig index 9375e7f12420..f6100cb193fb 100644 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig @@ -1,4 +1,22 @@ # SPDX-License-Identifier: MIT + +config DRM_AMDGPU + tristate "AMD GPU" + depends on DRM && PCI && MMU + select FW_LOADER + select DRM_KMS_HELPER + select DRM_SCHED + select DRM_TTM + select POWER_SUPPLY + select HWMON + select BACKLIGHT_CLASS_DEVICE + select INTERVAL_TREE + select CHASH + help + Choose this option if you have a recent AMD Radeon graphics card. + + If M is selected, the module will be called amdgpu. + config DRM_AMDGPU_SI bool "Enable amdgpu support for SI parts" depends on DRM_AMDGPU diff --git a/drivers/gpu/drm/radeon/Kconfig b/drivers/gpu/drm/radeon/Kconfig index 6f60f4840cc5..ba67b879d31d 100644 --- a/drivers/gpu/drm/radeon/Kconfig +++ b/drivers/gpu/drm/radeon/Kconfig @@ -1,4 +1,22 @@ # SPDX-License-Identifier: GPL-2.0-only + +config DRM_RADEON + tristate "ATI Radeon" + depends on DRM && PCI && MMU + select FW_LOADER + select DRM_KMS_HELPER + select DRM_TTM + select POWER_SUPPLY + select HWMON + select BACKLIGHT_CLASS_DEVICE + select INTERVAL_TREE + help + Choose this option if you have an ATI Radeon graphics card. There + are both PCI and AGP versions. You don't need to choose this to + run the Radeon in plain VGA mode. + + If M is selected, the module will be called radeon. + config DRM_RADEON_USERPTR bool "Always enable userptr support" depends on DRM_RADEON -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v3 4/7] arm: dts: exynos: Add interconnect bindings for Exynos4412
On Fri, Dec 20, 2019 at 12:56:50PM +0100, Artur Świgoń wrote:
> This patch adds the following properties to the Exynos4412 DT:
> - exynos,interconnect-parent-node: to declare connections between
> nodes in order to guarantee PM QoS requirements between nodes;
> - #interconnect-cells: required by the interconnect framework.
>
> Note that #interconnect-cells is always zero and node IDs are not
> hardcoded anywhere.
>
> Signed-off-by: Artur Świgoń
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 5 +
> 1 file changed, 5 insertions(+)
The order of patches is confusing. Patches 4 and 6 are split - do the
depend on 5? I doubt but...
Adjust the title to match the contents - you are not adding bindings but
properties to bus nodes. Also the prefix is ARM: (look at recent
commits).
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index 4ce3d77a6704..d9d70eacfcaf 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -90,6 +90,7 @@
> _dmc {
> exynos,ppmu-device = <_dmc0_3>, <_dmc1_3>;
> vdd-supply = <_reg>;
> + #interconnect-cells = <0>;
This does not look like property of Odroid but Exynos4412 or Exynos4.
Best regards,
Krzysztof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ
On 2019-12-30 2:05 a.m., Wayne Lin wrote: > [Why] > According to DP spec, it should shift left 4 digits for NO_STOP_BIT > in REMOTE_I2C_READ message. Not 5 digits. > > [How] > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in > drm_dp_encode_sideband_req(). > > Signed-off-by: Wayne Lin Good catch. Looks like this has been there since the beginning of MST in the kernel. How did you find this? Did this cause bad EDID reads or some other problem? If so the commit message should probably mention it. Harry > --- > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c > b/drivers/gpu/drm/drm_dp_mst_topology.c > index 1d1bfa49ca2b..0557e225ff67 100644 > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct > drm_dp_sideband_msg_req_body *req, > memcpy([idx], > req->u.i2c_read.transactions[i].bytes, > req->u.i2c_read.transactions[i].num_bytes); > idx += req->u.i2c_read.transactions[i].num_bytes; > > - buf[idx] = (req->u.i2c_read.transactions[i].no_stop_bit > & 0x1) << 5; > + buf[idx] = (req->u.i2c_read.transactions[i].no_stop_bit > & 0x1) << 4; > buf[idx] |= > (req->u.i2c_read.transactions[i].i2c_transaction_delay & 0xf); > idx++; > } > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fb-helper: Round up bits_per_pixel if possible
When userspace requests a video mode parameter value that is not
supported, frame buffer device drivers should round it up to a supported
value, if possible, instead of just rejecting it. This allows
applications to quickly scan for supported video modes.
Currently this rule is not followed for the number of bits per pixel,
causing e.g. "fbset -depth N" to fail, if N is smaller than the current
number of bits per pixel.
Fix this by returning an error only if bits per pixel is too large, and
setting it to the current value otherwise.
See also Documentation/fb/framebuffer.rst, Section 2 (Programmer's View
of /dev/fb*").
Fixes: 865afb11949e5bf4 ("drm/fb-helper: reject any changes to the fbdev")
Signed-off-by: Geert Uytterhoeven
---
Against drm-misc#for-linux-next.
Applies with some fuzz against v5.5-rc4.
---
drivers/gpu/drm/drm_fb_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f8e9051926083373..cae8fa74781c8db0 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1267,7 +1267,7 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
* Changes struct fb_var_screeninfo are currently not pushed back
* to KMS, hence fail if different settings are requested.
*/
- if (var->bits_per_pixel != fb->format->cpp[0] * 8 ||
+ if (var->bits_per_pixel > fb->format->cpp[0] * 8 ||
var->xres > fb->width || var->yres > fb->height ||
var->xres_virtual > fb->width || var->yres_virtual > fb->height) {
drm_dbg_kms(dev, "fb requested width/height/bpp can't fit in
current fb "
@@ -1292,6 +1292,11 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
drm_fb_helper_fill_pixel_fmt(var, fb->format->depth);
}
+ /*
+* Likewise, bits_per_pixel should be rounded up to a supported value.
+*/
+ var->bits_per_pixel = fb->format->cpp[0] * 8;
+
/*
* drm fbdev emulation doesn't support changing the pixel format at all,
* so reject all pixel format changing requests.
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] pinctrl: Allow modules to use pinctrl_[un]register_mappings
On Mon, Dec 16, 2019 at 9:51 PM Hans de Goede wrote: > Currently only the drivers/pinctrl/devicetree.c code allows registering > pinctrl-mappings which may later be unregistered, all other mappings > are assumed to be permanent. > > Non-dt platforms may also want to register pinctrl mappings from code which > is build as a module, which requires being able to unregister the mapping > when the module is unloaded to avoid dangling pointers. > > To allow unregistering the mappings the devicetree code uses 2 internal > functions: pinctrl_register_map and pinctrl_unregister_map. > > pinctrl_register_map allows the devicetree code to tell the core to > not memdup the mappings as it retains ownership of them and > pinctrl_unregister_map does the unregistering, note this only works > when the mappings where not memdupped. > > The only code relying on the memdup/shallow-copy done by > pinctrl_register_mappings is arch/arm/mach-u300/core.c this commit > replaces the __initdata with const, so that the shallow-copy is no > longer necessary. > > After that we can get rid of the internal pinctrl_unregister_map function > and just use pinctrl_register_mappings directly everywhere. > > This commit also renames pinctrl_unregister_map to > pinctrl_unregister_mappings so that its naming matches its > pinctrl_register_mappings counter-part and exports it. > > Together these 2 changes will allow non-dt platform code to > register pinctrl-mappings from modules without breaking things on > module unload (as they can now unregister the mapping on unload). > > Signed-off-by: Hans de Goede This v2 works fine for me, I applied it to this immutable branch in the pinctrl tree: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=ib-pinctrl-unreg-mappings And pulled that into the pinctrl "devel" branch for v5.6. Please pull this immutable branch into the Intel DRM tree and apply the rest of the stuff on top! Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/mipi_dbi: Fix off-by-one bugs in mipi_dbi_blank()
When configuring the frame memory window, the last column and row
numbers are written to the column resp. page address registers. These
numbers are thus one less than the actual window width resp. height.
While this is handled correctly in mipi_dbi_fb_dirty() since commit
03ceb1c8dfd1e293 ("drm/tinydrm: Fix setting of the column/page end
addresses."), it is not in mipi_dbi_blank(). The latter still forgets
to subtract one when calculating the most significant bytes of the
column and row numbers, thus programming wrong values when the display
width or height is a multiple of 256.
Fixes: 02dd95fe31693626 ("drm/tinydrm: Add MIPI DBI support")
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/drm_mipi_dbi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index e34058c721becd6b..16bff1be4b8ac622 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -367,9 +367,9 @@ static void mipi_dbi_blank(struct mipi_dbi_dev *dbidev)
memset(dbidev->tx_buf, 0, len);
mipi_dbi_command(dbi, MIPI_DCS_SET_COLUMN_ADDRESS, 0, 0,
-(width >> 8) & 0xFF, (width - 1) & 0xFF);
+((width - 1) >> 8) & 0xFF, (width - 1) & 0xFF);
mipi_dbi_command(dbi, MIPI_DCS_SET_PAGE_ADDRESS, 0, 0,
-(height >> 8) & 0xFF, (height - 1) & 0xFF);
+((height - 1) >> 8) & 0xFF, (height - 1) & 0xFF);
mipi_dbi_command_buf(dbi, MIPI_DCS_WRITE_MEMORY_START,
(u8 *)dbidev->tx_buf, len);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dp_mst: correct the shifting in DP_REMOTE_I2C_READ
On Mon, 30 Dec 2019, Wayne Lin wrote: > [Why] > According to DP spec, it should shift left 4 digits for NO_STOP_BIT > in REMOTE_I2C_READ message. Not 5 digits. > > [How] > Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in > drm_dp_encode_sideband_req(). Which commit introduced the issue? Fixes: tag. Does it need a stable backport? Does this fix a user visible bug? BR, Jani. > Signed-off-by: Wayne Lin > --- > drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c > b/drivers/gpu/drm/drm_dp_mst_topology.c > index 1d1bfa49ca2b..0557e225ff67 100644 > --- a/drivers/gpu/drm/drm_dp_mst_topology.c > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c > @@ -393,7 +393,7 @@ drm_dp_encode_sideband_req(const struct > drm_dp_sideband_msg_req_body *req, > memcpy([idx], > req->u.i2c_read.transactions[i].bytes, > req->u.i2c_read.transactions[i].num_bytes); > idx += req->u.i2c_read.transactions[i].num_bytes; > > - buf[idx] = (req->u.i2c_read.transactions[i].no_stop_bit > & 0x1) << 5; > + buf[idx] = (req->u.i2c_read.transactions[i].no_stop_bit > & 0x1) << 4; > buf[idx] |= > (req->u.i2c_read.transactions[i].i2c_transaction_delay & 0xf); > idx++; > } -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/hisilicon: Added three new resolutions and changed the alignment to 128 Bytes
Hi Tian, On Sat, 28 Dec 2019 at 01:14, Tian Tao wrote: > @@ -118,11 +119,9 @@ static void hibmc_plane_atomic_update(struct drm_plane > *plane, > writel(gpu_addr, priv->mmio + HIBMC_CRT_FB_ADDRESS); > > reg = state->fb->width * (state->fb->format->cpp[0]); > - /* now line_pad is 16 */ > - reg = PADDING(16, reg); > > line_l = state->fb->width * state->fb->format->cpp[0]; > - line_l = PADDING(16, line_l); > + line_l = PADDING(128, line_l); The 'line length' here is the 'stride' field of the FB. Stride is set by userspace when allocating the buffer, and the kernel must not attempt to guess what userspace set. You should use state->fb->strides[0] directly here, and in your atomic_check() function, make sure that the framebuffer stride is correctly aligned. Please split this into a separate change. Your commit has three changes in it, which should all be separate commits: * enforce 128-byte stride alignment (is this a hardware limit?) * get the BO from drm_fb rather than hibmc_fb (can hibmc_fb->obj just be removed now?) * add new clock/resolution configurations Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
