Re: [PATCH 13/60] drm/bridge: tfp410: Don't include drmP.h
On 07/07/2019 21:18, Laurent Pinchart wrote: The drmP.h header is deprecated, replace it with the headers specifically needed by the tfp410 driver. While at it, replace the DRM print macros with dev_info() and dev_err() instead of including drm_print.h Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/bridge/ti-tfp410.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c index 8d4690e436c3..a1cad777b057 100644 --- a/drivers/gpu/drm/bridge/ti-tfp410.c +++ b/drivers/gpu/drm/bridge/ti-tfp410.c @@ -18,6 +18,7 @@ #include #include +#include #include #include #include You're not actually removing drmP.h. So is the drm_bridge.h needed? Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/60] drm/bridge: Add driver for the TI TPD12S015 HDMI level shifter
On 07/07/2019 21:18, Laurent Pinchart wrote:
The TI TPD12S015 is an HDMI level shifter and ESD protector controlled
through GPIOs. Add a DRM bridge driver for the device.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/Kconfig| 8 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/ti-tpd12s015.c | 204 ++
3 files changed, 213 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ti-tpd12s015.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 295a62f65ef9..3928651a0819 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -159,6 +159,14 @@ config DRM_TI_SN65DSI86
help
Texas Instruments SN65DSI86 DSI to eDP Bridge driver
+config DRM_TI_TPD12S015
+ tristate "TI TPD12S015 HDMI level shifter and ESD protection"
+ depends on OF
+ select DRM_KMS_HELPER
+ help
+ Texas Instruments TPD12S015 HDMI level shifter and ESD protection
+ driver.
+
source "drivers/gpu/drm/bridge/analogix/Kconfig"
source "drivers/gpu/drm/bridge/adv7511/Kconfig"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index e5987b3aaf62..ce635651e31b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -17,4 +17,5 @@ obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/ti-tpd12s015.c
b/drivers/gpu/drm/bridge/ti-tpd12s015.c
new file mode 100644
index ..d01f0c4133a2
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-tpd12s015.c
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * TPD12S015 HDMI ESD protection & level shifter chip driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated
+ * Author: Tomi Valkeinen
+ */
You may want to mention that the driver is based on an existing omapdrm
driver. Otherwise the above lines don't quite make sense when adding a
new driver =).
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct tpd12s015_device {
+ struct drm_bridge bridge;
+
+ struct gpio_desc *ct_cp_hpd_gpio;
+ struct gpio_desc *ls_oe_gpio;
+ struct gpio_desc *hpd_gpio;
+ int hpd_irq;
+
+ struct drm_bridge *next_bridge;
+};
+
+static inline struct tpd12s015_device *to_tpd12s015(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct tpd12s015_device, bridge);
+}
+
+static int tpd12s015_attach(struct drm_bridge *bridge, bool create_connector)
+{
+ struct tpd12s015_device *tpd = to_tpd12s015(bridge);
+ int ret;
+
+ if (create_connector)
+ return -EINVAL;
+
+ ret = drm_bridge_attach(bridge->encoder, tpd->next_bridge,
+ bridge, false);
+ if (ret < 0)
+ return ret;
+
+ gpiod_set_value_cansleep(tpd->ct_cp_hpd_gpio, 1);
+ gpiod_set_value_cansleep(tpd->ls_oe_gpio, 1);
These are fine (and as they were in the old driver), but just talking
out loud: LS_OE is needed when talking over i2c, and CT_CP_HPD is needed
when interested in HPD.
Not sure what kind of power-savings are possible, but at least in theory
we could turn those off at times. At least when going to system suspend.
+ /* DC-DC converter needs at max 300us to get to 90% of 5V. */
+ usleep_range(300, 1000);
+
+ return 0;
+}
+
+static void tpd12s015_detach(struct drm_bridge *bridge)
+{
+ struct tpd12s015_device *tpd = to_tpd12s015(bridge);
+
+ gpiod_set_value_cansleep(tpd->ct_cp_hpd_gpio, 0);
+ gpiod_set_value_cansleep(tpd->ls_oe_gpio, 0);
+}
+
+static enum drm_connector_status tpd12s015_detect(struct drm_bridge *bridge)
+{
+ struct tpd12s015_device *tpd = to_tpd12s015(bridge);
+
+ if (gpiod_get_value_cansleep(tpd->hpd_gpio))
+ return connector_status_connected;
+ else
+ return connector_status_disconnected;
+}
+
+static void tpd12s015_hpd_enable(struct drm_bridge *bridge)
+{
+}
+
+static void tpd12s015_hpd_disable(struct drm_bridge *bridge)
+{
+}
Shouldn't we manage the CT_HPD_GPIO here, and request the irq here? I'm
fine with leaving that for later, though, as it may be better to keep
this new driver as similar to the old one as possible to prevent
regressions during this big patch series.
I guess it's fine for a bridge to do hpd_notify even if hpd_enable has
not been called?
+static const struct drm_bridge_funcs tpd12s015_bridge_funcs = {
+ .attach = tpd12s015_attach,
+ .detach = tpd12s015_detach,
+ .detect = tpd12s015_detect,
+ .hpd_enable = tpd12s015_hpd_enable,
+ .
Re: [PATCH 07/60] drm/bridge: simple-bridge: Add support for the TI OP362
On 07/07/2019 21:18, Laurent Pinchart wrote:
The TI OP362 is an analog video amplifier controlled through a GPIO. Add
support for it to the simple-bridge driver.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/simple-bridge.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c
b/drivers/gpu/drm/bridge/simple-bridge.c
index a7edf3c39627..7495b9bef865 100644
--- a/drivers/gpu/drm/bridge/simple-bridge.c
+++ b/drivers/gpu/drm/bridge/simple-bridge.c
@@ -296,6 +296,11 @@ static const struct of_device_id simple_bridge_match[] = {
.timings = &default_bridge_timings,
.type = DRM_MODE_CONNECTOR_VGA,
},
+ }, {
+ .compatible = "ti,opa362",
+ .data = &(const struct simple_bridge_info) {
+ .type = DRM_MODE_CONNECTOR_Composite,
+ },
I have to say I'm pretty clueless about the analog TV, but OMAP DSS
supports also s-video outputs. But I don't know if OPA362 can be used
with s-video, or does it dictate composite.
In any case,
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: tc358767: Expose test mode functionality via debugfs
Hi,
On 26/08/2019 21:25, Andrey Smirnov wrote:
Presently, the driver code artificially limits test pattern mode to a
single pattern with fixed color selection. It being a kernel module
parameter makes switching "test patter" <-> "proper output" modes
on-the-fly clunky and outright impossible if the driver is built into
the kernel.
To improve the situation a bit, convert current test pattern code to
use debugfs instead by exposing "TestCtl" register. This way old
"tc_test_pattern=1" functionality can be emulated via:
echo -n 0x78146312 > tstctl
and switch back to regular mode can be done with:
echo -n 0x78146310 > tstctl
It might be worth explaining the format in the commit msg or in a
comment in the driver.
Note that switching to any of the test patterns, will NOT trigger link
re-establishment whereas switching to normal operation WILL. This is
done so:
a) we can isolate and verify (e)DP link functionality by switching to
one of the test patters
b) trigger a link re-establishment by switching back to normal mode
Signed-off-by: Andrey Smirnov
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Cc: Cory Tusar
Cc: Chris Healy
Cc: Lucas Stach
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/bridge/tc358767.c | 137 ++
1 file changed, 101 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 6308d93ad91d..7a795b613ed0 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
#include
@@ -222,11 +223,10 @@
#define COLOR_B GENMASK(15, 8)
#define ENI2CFILTER BIT(4)
#define COLOR_BAR_MODEGENMASK(1, 0)
+#define COLOR_BAR_MODE_NORMAL 0
#define COLOR_BAR_MODE_BARS 2
-#define PLL_DBG0x0a04
-static bool tc_test_pattern;
-module_param_named(test, tc_test_pattern, bool, 0644);
+#define PLL_DBG0x0a04
struct tc_edp_link {
struct drm_dp_link base;
@@ -789,16 +789,6 @@ static int tc_set_video_mode(struct tc_data *tc,
if (ret)
return ret;
- /* Test pattern settings */
- ret = regmap_write(tc->regmap, TSTCTL,
- FIELD_PREP(COLOR_R, 120) |
- FIELD_PREP(COLOR_G, 20) |
- FIELD_PREP(COLOR_B, 99) |
- ENI2CFILTER |
- FIELD_PREP(COLOR_BAR_MODE, COLOR_BAR_MODE_BARS));
- if (ret)
- return ret;
-
/* DP Main Stream Attributes */
vid_sync_dly = hsync_len + left_margin + mode->hdisplay;
ret = regmap_write(tc->regmap, DP0_VIDSYNCDELAY,
@@ -1150,14 +1140,6 @@ static int tc_stream_enable(struct tc_data *tc)
dev_dbg(tc->dev, "enable video stream\n");
- /* PXL PLL setup */
- if (tc_test_pattern) {
- ret = tc_pxl_pll_en(tc, clk_get_rate(tc->refclk),
- 1000 * tc->mode.clock);
- if (ret)
- return ret;
- }
-
ret = tc_set_video_mode(tc, &tc->mode);
if (ret)
return ret;
@@ -1186,12 +1168,8 @@ static int tc_stream_enable(struct tc_data *tc)
if (ret)
return ret;
/* Set input interface */
- value = DP0_AUDSRC_NO_INPUT;
- if (tc_test_pattern)
- value |= DP0_VIDSRC_COLOR_BAR;
- else
- value |= DP0_VIDSRC_DPI_RX;
- ret = regmap_write(tc->regmap, SYSCTRL, value);
+ ret = regmap_write(tc->regmap, SYSCTRL,
+ DP0_AUDSRC_NO_INPUT | DP0_VIDSRC_DPI_RX);
if (ret)
return ret;
@@ -1220,39 +1198,44 @@ static void tc_bridge_pre_enable(struct drm_bridge *bridge)
drm_panel_prepare(tc->panel);
}
-static void tc_bridge_enable(struct drm_bridge *bridge)
+static int __tc_bridge_enable(struct tc_data *tc)
{
- struct tc_data *tc = bridge_to_tc(bridge);
int ret;
ret = tc_get_display_props(tc);
if (ret < 0) {
dev_err(tc->dev, "failed to read display props: %d\n", ret);
- return;
+ return ret;
}
ret = tc_main_link_enable(tc);
if (ret < 0) {
dev_err(tc->dev, "main link enable error: %d\n", ret);
- return;
+ return ret;
}
ret = tc_stream_enable(tc);
if (ret < 0) {
dev_err(tc->dev, "main link stream start error: %d\n", ret);
tc_main_link_disable(tc);
- return;
}
- drm_panel_enable(tc->panel);
+ return ret;
}
Maybe it's just me, but I rather have the last if() block do a "return
ret"; and have "return 0;" at the end of the function to keep all the if
Re: [PATCH] drm/meson: vclk: use the correct G12A frac max value
On Mon, Aug 26, 2019 at 4:47 PM Neil Armstrong wrote: > > When calculating the HDMI PLL settings for a DMT mode PHY frequency, > use the correct max fractional PLL value for G12A VPU. > > With this fix, we can finally setup the 1024x76-60 mode. nit-pick: is this really 1024x76 or 1024x768?
Re: [PATCH v9 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp
Regards
Shashank
On 8/27/2019 10:57 AM, Ramalingam C wrote:
On 2019-08-27 at 10:49:25 +0530, Sharma, Shashank wrote:
Regards
Shashank
On 8/22/2019 8:49 PM, Ramalingam C wrote:
On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.
v2:
s/trans/cpu_transcoder [Jani]
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
.../drm/i915/display/intel_display_types.h| 7 +++
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 49 ++-
drivers/gpu/drm/i915/display/intel_hdcp.h | 3 ++
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 449abaea619f..fc85b3e284d4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -388,6 +388,13 @@ struct intel_hdcp {
wait_queue_head_t cp_irq_queue;
atomic_t cp_irq_count;
int cp_irq_count_cached;
+
+ /*
+* HDCP register access for gen12+ need the transcoder associated.
+* Transcoder attached to the connector could be changed at modeset.
+* Hence caching the transcoder here.
+*/
+ enum transcoder cpu_transcoder;
attached_transcoder to be inline with MEI counterpart of the code ?
This is needed so that we can use this to get the offset of register.
Need not be inline with MEI.
:) I meant in the MEI side we are using name "attached_transcoder" so
using the same in I915 also would be easy to understand. But this is not
important, I will leave it to you.
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 921ad0a2f7ba..ba5317d56da7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2244,6 +2244,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
intel_psr_compute_config(intel_dp, pipe_config);
+ intel_hdcp_transcoder_config(intel_connector,
+pipe_config->cpu_transcoder);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 534832f435dc..1e5548833e8f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1762,13 +1762,60 @@ enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port
port)
}
}
+static inline
+enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder)
+{
+ switch (cpu_transcoder) {
+ case TRANSCODER_A ... TRANSCODER_D:
+ return (enum mei_fw_tc)(cpu_transcoder | 0x10);
Again, as this is in context of HDCP, we should not entertain transcoders
below. Or we should move this function in a more generic file like
intel_display.c or intel_ddi.c
This is specific to hdcp. So let it be here. We will fill invalid
TRANSCODER for all non HDCO capable transcoders. Hope that works for
you.
Sure.
+ case TRANSCODER_EDP:
+ return MEI_TC_EDP;
+ case TRANSCODER_DSI_0:
+ return MEI_TC_DSI0;
+ case TRANSCODER_DSI_1:
+ return MEI_TC_DSI1;
+ default:
+ return MEI_INVALID_TRANSCODER;
+ }
+}
+
+void intel_hdcp_transcoder_config(struct intel_connector *connector,
+ enum transcoder cpu_transcoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ if (!hdcp->shim)
+ return;
+
+ if (INTEL_GEN(dev_priv) >= 12) {
Ah, so this is the gen_check which I was talking about in previous patch :-)
+ mutex_lock(&hdcp->mutex);
+ hdcp->cpu_transcoder = cpu_transcoder;
+ hdcp->port_data.fw_tc = intel_get_mei_fw_tc(cpu_transcoder);
+ mutex_unlock(&hdcp->mutex);
+ }
+}
+
static inline int initialize_hdcp_port_data(struct intel_connector
*connector,
const struct intel_hdcp_shim *shim)
{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = &connector->hdcp;
struct hdcp_port_data *data = &hdcp->port_data;
+ struct intel_crtc *crtc;
+
+ if (INTEL_GEN(dev_priv) < 12) {
+ data->fw_ddi =
+ intel_get_mei_fw_ddi_index(connector->encoder->port);
+ } else {
+ crtc = to_intel_crtc(connector->base.state->crtc);
+ if (crtc) {
+ hdcp->cpu_transcoder = crtc->config->cpu_transcoder;
+ data->fw_tc = intel_get_mei_fw_tc(hdcp->cpu_transcoder);
+
Re: [PATCH v9 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp
On 2019-08-27 at 10:49:25 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
> On 8/22/2019 8:49 PM, Ramalingam C wrote:
> > On gen12+ platforms, HDCP HW is associated to the transcoder.
> > Hence on every modeset update associated transcoder into the
> > intel_hdcp of the port.
> >
> > v2:
> >s/trans/cpu_transcoder [Jani]
> >
> > Signed-off-by: Ramalingam C
> > Acked-by: Jani Nikula
> > ---
> > .../drm/i915/display/intel_display_types.h| 7 +++
> > drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 49 ++-
> > drivers/gpu/drm/i915/display/intel_hdcp.h | 3 ++
> > drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++
> > 5 files changed, 64 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> > b/drivers/gpu/drm/i915/display/intel_display_types.h
> > index 449abaea619f..fc85b3e284d4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> > @@ -388,6 +388,13 @@ struct intel_hdcp {
> > wait_queue_head_t cp_irq_queue;
> > atomic_t cp_irq_count;
> > int cp_irq_count_cached;
> > +
> > + /*
> > +* HDCP register access for gen12+ need the transcoder associated.
> > +* Transcoder attached to the connector could be changed at modeset.
> > +* Hence caching the transcoder here.
> > +*/
> > + enum transcoder cpu_transcoder;
> attached_transcoder to be inline with MEI counterpart of the code ?
This is needed so that we can use this to get the offset of register.
Need not be inline with MEI.
> > };
> > struct intel_connector {
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 921ad0a2f7ba..ba5317d56da7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -2244,6 +2244,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> > intel_psr_compute_config(intel_dp, pipe_config);
> > + intel_hdcp_transcoder_config(intel_connector,
> > +pipe_config->cpu_transcoder);
> > +
> > return 0;
> > }
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index 534832f435dc..1e5548833e8f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -1762,13 +1762,60 @@ enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum
> > port port)
> > }
> > }
> > +static inline
> > +enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder)
> > +{
> > + switch (cpu_transcoder) {
> > + case TRANSCODER_A ... TRANSCODER_D:
> > + return (enum mei_fw_tc)(cpu_transcoder | 0x10);
> Again, as this is in context of HDCP, we should not entertain transcoders
> below. Or we should move this function in a more generic file like
> intel_display.c or intel_ddi.c
This is specific to hdcp. So let it be here. We will fill invalid
TRANSCODER for all non HDCO capable transcoders. Hope that works for
you.
> > + case TRANSCODER_EDP:
> > + return MEI_TC_EDP;
> > + case TRANSCODER_DSI_0:
> > + return MEI_TC_DSI0;
> > + case TRANSCODER_DSI_1:
> > + return MEI_TC_DSI1;
> > + default:
> > + return MEI_INVALID_TRANSCODER;
> > + }
> > +}
> > +
> > +void intel_hdcp_transcoder_config(struct intel_connector *connector,
> > + enum transcoder cpu_transcoder)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > + struct intel_hdcp *hdcp = &connector->hdcp;
> > +
> > + if (!hdcp->shim)
> > + return;
> > +
> > + if (INTEL_GEN(dev_priv) >= 12) {
> Ah, so this is the gen_check which I was talking about in previous patch :-)
> > + mutex_lock(&hdcp->mutex);
> > + hdcp->cpu_transcoder = cpu_transcoder;
> > + hdcp->port_data.fw_tc = intel_get_mei_fw_tc(cpu_transcoder);
> > + mutex_unlock(&hdcp->mutex);
> > + }
> > +}
> > +
> > static inline int initialize_hdcp_port_data(struct intel_connector
> > *connector,
> > const struct intel_hdcp_shim *shim)
> > {
> > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > struct intel_hdcp *hdcp = &connector->hdcp;
> > struct hdcp_port_data *data = &hdcp->port_data;
> > + struct intel_crtc *crtc;
> > +
> > + if (INTEL_GEN(dev_priv) < 12) {
> > + data->fw_ddi =
> > + intel_get_mei_fw_ddi_index(connector->encoder->port);
> > + } else {
> > + crtc = to_intel_crtc(connector->base.state->crtc);
> > + if (crtc) {
> > + hdcp->cpu_transcoder = crtc->config->cpu_transcoder;
> > + data->fw_tc = intel_get_mei_fw_tc(hdcp->cpu_transcoder);
> > + }
> > +
Re: [PATCH v2] drm/virtio: add plane check
On Mon, Aug 26, 2019 at 03:34:56PM -0700, Chia-I Wu wrote:
> On Thu, Aug 22, 2019 at 2:47 AM Gerd Hoffmann wrote:
> >
> > Use drm_atomic_helper_check_plane_state()
> > to sanity check the plane state.
> >
> > Signed-off-by: Gerd Hoffmann
> > ---
> > drivers/gpu/drm/virtio/virtgpu_plane.c | 17 -
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
> > b/drivers/gpu/drm/virtio/virtgpu_plane.c
> > index a492ac3f4a7e..fe5efb2de90d 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
> > @@ -84,7 +84,22 @@ static const struct drm_plane_funcs
> > virtio_gpu_plane_funcs = {
> > static int virtio_gpu_plane_atomic_check(struct drm_plane *plane,
> > struct drm_plane_state *state)
> > {
> > - return 0;
> > + bool is_cursor = plane->type == DRM_PLANE_TYPE_CURSOR;
> > + struct drm_crtc_state *crtc_state;
> > + int ret;
> > +
> > + if (!state->fb || !state->crtc)
> > + return 0;
> > +
> > + crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
> > + if (IS_ERR(crtc_state))
> > +return PTR_ERR(crtc_state);
> Is drm_atomic_get_new_crtc_state better here?
We don't have to worry about old/new state here. The drm_plane_state we
get passed is the state we should check in this callback (and I think
this always is the new state).
cheers,
Gerd
Re: [PATCH v9 3/6] drm: Extend I915 mei interface for transcoder info
On 2019-08-27 at 10:36:11 +0530, Sharma, Shashank wrote:
>
> On 8/22/2019 8:49 PM, Ramalingam C wrote:
> > I915 needs to send the index of the transcoder as per ME FW.
> > To support this, define enum mei_fw_ddi and add as a member into
> > the struct hdcp_port_data.
> >
> > Signed-off-by: Ramalingam C
> > Acked-by: Jani Nikula
> > ---
> > include/drm/i915_mei_hdcp_interface.h | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/include/drm/i915_mei_hdcp_interface.h
> > b/include/drm/i915_mei_hdcp_interface.h
> > index a97acf1c9710..0de629bf2f62 100644
> > --- a/include/drm/i915_mei_hdcp_interface.h
> > +++ b/include/drm/i915_mei_hdcp_interface.h
> > @@ -54,9 +54,21 @@ enum mei_fw_ddi {
> > MEI_DDI_RANGE_END = MEI_DDI_A,
> > };
> > +enum mei_fw_tc {
> > + MEI_INVALID_TRANSCODER = 0x00, /* Invalid transcoder type */
> > + MEI_TC_EDP, /* Transcoder for eDP */
> > + MEI_TC_DSI0,/* Transcoder for DSI0 */
> > + MEI_TC_DSI1,/* Transcoder for DSI1 */
> Also, this is a bit odd, coz ports above can't do HDCP, so it doesn't make
> sense to have them here. But seems like we want to be in sync with MEI FW
> definitions, so we should change the function
>
> intel_get_mei_fw_ddi_index to accept only from ports A to D, not above or
> below.
As we(I915) support HDCP on HDMI and DP only we will have TCA to TCD
only. Sure we can fix the intel_get_mei_fw_ddi_index to fill invalid TC
on other transcoders.
-Ram
>
> - Shashank
>
> > + MEI_TC_A = 0x10,/* Transcoder TCA */
> > + MEI_TC_B, /* Transcoder TCB */
> > + MEI_TC_C, /* Transcoder TCC */
> > + MEI_TC_D/* Transcoder TCD */
> > +};
> > +
> > /**
> >* struct hdcp_port_data - intel specific HDCP port data
> >* @fw_ddi: ddi index as per ME FW
> > + * @fw_tc: transcoder index as per ME FW
> >* @port_type: HDCP port type as per ME FW classification
> >* @protocol: HDCP adaptation as per ME FW
> >* @k: No of streams transmitted on a port. Only on DP MST this is != 1
> > @@ -69,6 +81,7 @@ enum mei_fw_ddi {
> >*/
> > struct hdcp_port_data {
> > enum mei_fw_ddi fw_ddi;
> > + enum mei_fw_tc fw_tc;
> > u8 port_type;
> > u8 protocol;
> > u16 k;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 4/6] misc/mei/hdcp: Fill transcoder index in port info
On 8/27/2019 10:47 AM, Ramalingam C wrote:
On 2019-08-27 at 10:42:33 +0530, Sharma, Shashank wrote:
Regards
Shashank
On 8/22/2019 8:49 PM, Ramalingam C wrote:
For gen12+ platform we need to pass the transcoder info
as part of the port info into ME FW.
This change fills the payload for ME FW from hdcp_port_data.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
drivers/misc/mei/hdcp/mei_hdcp.h | 4 +++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 3638c77eba26..93027fd96c71 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -58,6 +58,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
hdcp_port_data *data,
session_init_in.port.integrated_port_type = data->port_type;
session_init_in.port.physical_port = (u8)data->fw_ddi;
As this entry is only valid till GEN11.5, don't we need GEN_CHECK here, say
(INTEL_GEN() < 12). Is that possible in MEI_FW ?
Shashank,
Not needed, as I915 checks the GEN# while loading the transcoder detail
into hdcp_port_data. So here we can assign whatever passed as part of
hdcp_port_data.
-Ram
Yep, just saw this in the next patch,
Please feel free to use: Reviewed-by: Shashank Sharma
If not, probably we have to add this gen_check while filling the fw_tc part
in I915.
Applies for all the changes below too.
- Shashank
+ session_init_in.port.attached_transcoder = (u8)data->fw_tc;
session_init_in.protocol = data->protocol;
byte = mei_cldev_send(cldev, (u8 *)&session_init_in,
@@ -127,6 +128,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
verify_rxcert_in.port.integrated_port_type = data->port_type;
verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
+ verify_rxcert_in.port.attached_transcoder = (u8)data->fw_tc;
verify_rxcert_in.cert_rx = rx_cert->cert_rx;
memcpy(verify_rxcert_in.r_rx, &rx_cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -197,6 +199,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
send_hprime_in.port.integrated_port_type = data->port_type;
send_hprime_in.port.physical_port = (u8)data->fw_ddi;
+ send_hprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
HDCP_2_2_H_PRIME_LEN);
@@ -254,6 +257,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
pairing_info_in.port.integrated_port_type = data->port_type;
pairing_info_in.port.physical_port = (u8)data->fw_ddi;
+ pairing_info_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
HDCP_2_2_E_KH_KM_LEN);
@@ -312,6 +316,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.port.integrated_port_type = data->port_type;
lc_init_in.port.physical_port = (u8)data->fw_ddi;
+ lc_init_in.port.attached_transcoder = (u8)data->fw_tc;
byte = mei_cldev_send(cldev, (u8 *)&lc_init_in, sizeof(lc_init_in));
if (byte < 0) {
@@ -367,6 +372,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct
hdcp_port_data *data,
verify_lprime_in.port.integrated_port_type = data->port_type;
verify_lprime_in.port.physical_port = (u8)data->fw_ddi;
+ verify_lprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
HDCP_2_2_L_PRIME_LEN);
@@ -424,6 +430,7 @@ static int mei_hdcp_get_session_key(struct device *dev,
get_skey_in.port.integrated_port_type = data->port_type;
get_skey_in.port.physical_port = (u8)data->fw_ddi;
+ get_skey_in.port.attached_transcoder = (u8)data->fw_tc;
byte = mei_cldev_send(cldev, (u8 *)&get_skey_in, sizeof(get_skey_in));
if (byte < 0) {
@@ -488,6 +495,7 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct device *dev,
verify_repeater_in.port.integrated_port_type = data->port_type;
verify_repeater_in.port.physical_port = (u8)data->fw_ddi;
+ verify_repeater_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
HDCP_2_2_RXINFO_LEN);
@@ -558,6 +566,7 @@ static int mei_hdcp_verify_mprime(struct device *dev,
verify_mprime_in.port.integrated_port_type = data->port_type;
verify_mprime_in.port.physical_port = (u8)data->fw_ddi;
+ verify_mprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
HDCP_2_2_MPRIME_LEN);
@@ -619,6 +628,7 @@ static int mei_hdcp_enable_authentication(struct device
*dev,
enable_auth_in.port.integrated_port_type = data->port_type;
enable_auth_in.port.physical_port = (u8)data->fw_ddi;
+ enable_auth_in
Re: [PATCH v9 3/6] drm: Extend I915 mei interface for transcoder info
On 2019-08-27 at 10:18:07 +0530, Sharma, Shashank wrote:
>
> On 8/22/2019 8:49 PM, Ramalingam C wrote:
> > I915 needs to send the index of the transcoder as per ME FW.
> > To support this, define enum mei_fw_ddi and add as a member into
> > the struct hdcp_port_data.
>
> The commit message says you are defining enum mei_fw_ddi, but you are
> actually defining enum mei_fw_tc;
dangerous typo :) I will fix it. Thanks
-Ram
>
> - Shashank
>
> > Signed-off-by: Ramalingam C
> > Acked-by: Jani Nikula
> > ---
> > include/drm/i915_mei_hdcp_interface.h | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/include/drm/i915_mei_hdcp_interface.h
> > b/include/drm/i915_mei_hdcp_interface.h
> > index a97acf1c9710..0de629bf2f62 100644
> > --- a/include/drm/i915_mei_hdcp_interface.h
> > +++ b/include/drm/i915_mei_hdcp_interface.h
> > @@ -54,9 +54,21 @@ enum mei_fw_ddi {
> > MEI_DDI_RANGE_END = MEI_DDI_A,
> > };
> > +enum mei_fw_tc {
> > + MEI_INVALID_TRANSCODER = 0x00, /* Invalid transcoder type */
> > + MEI_TC_EDP, /* Transcoder for eDP */
> > + MEI_TC_DSI0,/* Transcoder for DSI0 */
> > + MEI_TC_DSI1,/* Transcoder for DSI1 */
> > + MEI_TC_A = 0x10,/* Transcoder TCA */
> > + MEI_TC_B, /* Transcoder TCB */
> > + MEI_TC_C, /* Transcoder TCC */
> > + MEI_TC_D/* Transcoder TCD */
> > +};
> > +
> > /**
> >* struct hdcp_port_data - intel specific HDCP port data
> >* @fw_ddi: ddi index as per ME FW
> > + * @fw_tc: transcoder index as per ME FW
> >* @port_type: HDCP port type as per ME FW classification
> >* @protocol: HDCP adaptation as per ME FW
> >* @k: No of streams transmitted on a port. Only on DP MST this is != 1
> > @@ -69,6 +81,7 @@ enum mei_fw_ddi {
> >*/
> > struct hdcp_port_data {
> > enum mei_fw_ddi fw_ddi;
> > + enum mei_fw_tc fw_tc;
> > u8 port_type;
> > u8 protocol;
> > u16 k;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 5/6] drm/i915/hdcp: update current transcoder into intel_hdcp
Regards
Shashank
On 8/22/2019 8:49 PM, Ramalingam C wrote:
On gen12+ platforms, HDCP HW is associated to the transcoder.
Hence on every modeset update associated transcoder into the
intel_hdcp of the port.
v2:
s/trans/cpu_transcoder [Jani]
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
.../drm/i915/display/intel_display_types.h| 7 +++
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 49 ++-
drivers/gpu/drm/i915/display/intel_hdcp.h | 3 ++
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 ++
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 449abaea619f..fc85b3e284d4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -388,6 +388,13 @@ struct intel_hdcp {
wait_queue_head_t cp_irq_queue;
atomic_t cp_irq_count;
int cp_irq_count_cached;
+
+ /*
+* HDCP register access for gen12+ need the transcoder associated.
+* Transcoder attached to the connector could be changed at modeset.
+* Hence caching the transcoder here.
+*/
+ enum transcoder cpu_transcoder;
attached_transcoder to be inline with MEI counterpart of the code ?
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 921ad0a2f7ba..ba5317d56da7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -2244,6 +2244,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
intel_psr_compute_config(intel_dp, pipe_config);
+ intel_hdcp_transcoder_config(intel_connector,
+pipe_config->cpu_transcoder);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 534832f435dc..1e5548833e8f 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1762,13 +1762,60 @@ enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port
port)
}
}
+static inline
+enum mei_fw_tc intel_get_mei_fw_tc(enum transcoder cpu_transcoder)
+{
+ switch (cpu_transcoder) {
+ case TRANSCODER_A ... TRANSCODER_D:
+ return (enum mei_fw_tc)(cpu_transcoder | 0x10);
Again, as this is in context of HDCP, we should not entertain
transcoders below. Or we should move this function in a more generic
file like intel_display.c or intel_ddi.c
+ case TRANSCODER_EDP:
+ return MEI_TC_EDP;
+ case TRANSCODER_DSI_0:
+ return MEI_TC_DSI0;
+ case TRANSCODER_DSI_1:
+ return MEI_TC_DSI1;
+ default:
+ return MEI_INVALID_TRANSCODER;
+ }
+}
+
+void intel_hdcp_transcoder_config(struct intel_connector *connector,
+ enum transcoder cpu_transcoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ if (!hdcp->shim)
+ return;
+
+ if (INTEL_GEN(dev_priv) >= 12) {
Ah, so this is the gen_check which I was talking about in previous patch :-)
+ mutex_lock(&hdcp->mutex);
+ hdcp->cpu_transcoder = cpu_transcoder;
+ hdcp->port_data.fw_tc = intel_get_mei_fw_tc(cpu_transcoder);
+ mutex_unlock(&hdcp->mutex);
+ }
+}
+
static inline int initialize_hdcp_port_data(struct intel_connector *connector,
const struct intel_hdcp_shim *shim)
{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = &connector->hdcp;
struct hdcp_port_data *data = &hdcp->port_data;
+ struct intel_crtc *crtc;
+
+ if (INTEL_GEN(dev_priv) < 12) {
+ data->fw_ddi =
+ intel_get_mei_fw_ddi_index(connector->encoder->port);
+ } else {
+ crtc = to_intel_crtc(connector->base.state->crtc);
+ if (crtc) {
+ hdcp->cpu_transcoder = crtc->config->cpu_transcoder;
+ data->fw_tc = intel_get_mei_fw_tc(hdcp->cpu_transcoder);
+ }
+ data->fw_ddi = intel_get_mei_fw_ddi_index(PORT_NONE);
I dint understand this, why PORT_NONE ?
- Shashank
+ }
- data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder->port);
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
data->protocol = (u8)shim->protocol;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 59a2b40405cc..41c1053d9e38 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel
Re: [PATCH v9 4/6] misc/mei/hdcp: Fill transcoder index in port info
On 2019-08-27 at 10:42:33 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
> On 8/22/2019 8:49 PM, Ramalingam C wrote:
> > For gen12+ platform we need to pass the transcoder info
> > as part of the port info into ME FW.
> >
> > This change fills the payload for ME FW from hdcp_port_data.
> >
> > Signed-off-by: Ramalingam C
> > Acked-by: Jani Nikula
> > ---
> > drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
> > drivers/misc/mei/hdcp/mei_hdcp.h | 4 +++-
> > 2 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> > b/drivers/misc/mei/hdcp/mei_hdcp.c
> > index 3638c77eba26..93027fd96c71 100644
> > --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> > +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> > @@ -58,6 +58,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
> > hdcp_port_data *data,
> > session_init_in.port.integrated_port_type = data->port_type;
> > session_init_in.port.physical_port = (u8)data->fw_ddi;
>
> As this entry is only valid till GEN11.5, don't we need GEN_CHECK here, say
> (INTEL_GEN() < 12). Is that possible in MEI_FW ?
Shashank,
Not needed, as I915 checks the GEN# while loading the transcoder detail
into hdcp_port_data. So here we can assign whatever passed as part of
hdcp_port_data.
-Ram
>
> If not, probably we have to add this gen_check while filling the fw_tc part
> in I915.
>
> Applies for all the changes below too.
>
> - Shashank
>
> > + session_init_in.port.attached_transcoder = (u8)data->fw_tc;
> > session_init_in.protocol = data->protocol;
> > byte = mei_cldev_send(cldev, (u8 *)&session_init_in,
> > @@ -127,6 +128,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device
> > *dev,
> > verify_rxcert_in.port.integrated_port_type = data->port_type;
> > verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
> > + verify_rxcert_in.port.attached_transcoder = (u8)data->fw_tc;
> > verify_rxcert_in.cert_rx = rx_cert->cert_rx;
> > memcpy(verify_rxcert_in.r_rx, &rx_cert->r_rx, HDCP_2_2_RRX_LEN);
> > @@ -197,6 +199,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
> > hdcp_port_data *data,
> > send_hprime_in.port.integrated_port_type = data->port_type;
> > send_hprime_in.port.physical_port = (u8)data->fw_ddi;
> > + send_hprime_in.port.attached_transcoder = (u8)data->fw_tc;
> > memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
> >HDCP_2_2_H_PRIME_LEN);
> > @@ -254,6 +257,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
> > hdcp_port_data *data,
> > pairing_info_in.port.integrated_port_type = data->port_type;
> > pairing_info_in.port.physical_port = (u8)data->fw_ddi;
> > + pairing_info_in.port.attached_transcoder = (u8)data->fw_tc;
> > memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
> >HDCP_2_2_E_KH_KM_LEN);
> > @@ -312,6 +316,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
> > lc_init_in.port.integrated_port_type = data->port_type;
> > lc_init_in.port.physical_port = (u8)data->fw_ddi;
> > + lc_init_in.port.attached_transcoder = (u8)data->fw_tc;
> > byte = mei_cldev_send(cldev, (u8 *)&lc_init_in, sizeof(lc_init_in));
> > if (byte < 0) {
> > @@ -367,6 +372,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct
> > hdcp_port_data *data,
> > verify_lprime_in.port.integrated_port_type = data->port_type;
> > verify_lprime_in.port.physical_port = (u8)data->fw_ddi;
> > + verify_lprime_in.port.attached_transcoder = (u8)data->fw_tc;
> > memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
> >HDCP_2_2_L_PRIME_LEN);
> > @@ -424,6 +430,7 @@ static int mei_hdcp_get_session_key(struct device *dev,
> > get_skey_in.port.integrated_port_type = data->port_type;
> > get_skey_in.port.physical_port = (u8)data->fw_ddi;
> > + get_skey_in.port.attached_transcoder = (u8)data->fw_tc;
> > byte = mei_cldev_send(cldev, (u8 *)&get_skey_in, sizeof(get_skey_in));
> > if (byte < 0) {
> > @@ -488,6 +495,7 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct device
> > *dev,
> > verify_repeater_in.port.integrated_port_type = data->port_type;
> > verify_repeater_in.port.physical_port = (u8)data->fw_ddi;
> > + verify_repeater_in.port.attached_transcoder = (u8)data->fw_tc;
> > memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
> >HDCP_2_2_RXINFO_LEN);
> > @@ -558,6 +566,7 @@ static int mei_hdcp_verify_mprime(struct device *dev,
> > verify_mprime_in.port.integrated_port_type = data->port_type;
> > verify_mprime_in.port.physical_port = (u8)data->fw_ddi;
> > + verify_mprime_in.port.attached_transcoder = (u8)data->fw_tc;
> > memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
> >HDCP_2_2_MPRIME_LEN);
> > @@ -619,6 +628,7 @@ static int mei_hdcp_enable_authentication(struct device
> > *dev,
> > enable_auth_in.port.integrated_port_type = data->port_type;
> > enable_auth_in.port.physical_port = (u8)data->fw_ddi;
> >
Re: [PATCH v4 00/17] drm: add gem ttm helpers, rework mmap workflow.
Hi, > Also this patch series also adjust vram helpers, and I think it has a > slightly different goal: Just aligning mmap paths a bit more between > ttm and not-ttm based drivers. Not just ttm/not-ttm. gem_driver->fops->mmap is the only fops callback where we can't use a generic gem callback today. This series tries to fix that with the new drm_gem_object_funcs->mmap hook, so the mmap() code path isn't the odd one which works different than every other drm_gem_object operation. > Seems like a good goal, details might need adjustment. Which details? cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 4/6] misc/mei/hdcp: Fill transcoder index in port info
Regards
Shashank
On 8/22/2019 8:49 PM, Ramalingam C wrote:
For gen12+ platform we need to pass the transcoder info
as part of the port info into ME FW.
This change fills the payload for ME FW from hdcp_port_data.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
drivers/misc/mei/hdcp/mei_hdcp.c | 11 +++
drivers/misc/mei/hdcp/mei_hdcp.h | 4 +++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index 3638c77eba26..93027fd96c71 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -58,6 +58,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
hdcp_port_data *data,
session_init_in.port.integrated_port_type = data->port_type;
session_init_in.port.physical_port = (u8)data->fw_ddi;
As this entry is only valid till GEN11.5, don't we need GEN_CHECK here,
say (INTEL_GEN() < 12). Is that possible in MEI_FW ?
If not, probably we have to add this gen_check while filling the fw_tc
part in I915.
Applies for all the changes below too.
- Shashank
+ session_init_in.port.attached_transcoder = (u8)data->fw_tc;
session_init_in.protocol = data->protocol;
byte = mei_cldev_send(cldev, (u8 *)&session_init_in,
@@ -127,6 +128,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
verify_rxcert_in.port.integrated_port_type = data->port_type;
verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
+ verify_rxcert_in.port.attached_transcoder = (u8)data->fw_tc;
verify_rxcert_in.cert_rx = rx_cert->cert_rx;
memcpy(verify_rxcert_in.r_rx, &rx_cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -197,6 +199,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
send_hprime_in.port.integrated_port_type = data->port_type;
send_hprime_in.port.physical_port = (u8)data->fw_ddi;
+ send_hprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
HDCP_2_2_H_PRIME_LEN);
@@ -254,6 +257,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
pairing_info_in.port.integrated_port_type = data->port_type;
pairing_info_in.port.physical_port = (u8)data->fw_ddi;
+ pairing_info_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
HDCP_2_2_E_KH_KM_LEN);
@@ -312,6 +316,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.port.integrated_port_type = data->port_type;
lc_init_in.port.physical_port = (u8)data->fw_ddi;
+ lc_init_in.port.attached_transcoder = (u8)data->fw_tc;
byte = mei_cldev_send(cldev, (u8 *)&lc_init_in, sizeof(lc_init_in));
if (byte < 0) {
@@ -367,6 +372,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct
hdcp_port_data *data,
verify_lprime_in.port.integrated_port_type = data->port_type;
verify_lprime_in.port.physical_port = (u8)data->fw_ddi;
+ verify_lprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_lprime_in.l_prime, rx_lprime->l_prime,
HDCP_2_2_L_PRIME_LEN);
@@ -424,6 +430,7 @@ static int mei_hdcp_get_session_key(struct device *dev,
get_skey_in.port.integrated_port_type = data->port_type;
get_skey_in.port.physical_port = (u8)data->fw_ddi;
+ get_skey_in.port.attached_transcoder = (u8)data->fw_tc;
byte = mei_cldev_send(cldev, (u8 *)&get_skey_in, sizeof(get_skey_in));
if (byte < 0) {
@@ -488,6 +495,7 @@ mei_hdcp_repeater_check_flow_prepare_ack(struct device *dev,
verify_repeater_in.port.integrated_port_type = data->port_type;
verify_repeater_in.port.physical_port = (u8)data->fw_ddi;
+ verify_repeater_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_repeater_in.rx_info, rep_topology->rx_info,
HDCP_2_2_RXINFO_LEN);
@@ -558,6 +566,7 @@ static int mei_hdcp_verify_mprime(struct device *dev,
verify_mprime_in.port.integrated_port_type = data->port_type;
verify_mprime_in.port.physical_port = (u8)data->fw_ddi;
+ verify_mprime_in.port.attached_transcoder = (u8)data->fw_tc;
memcpy(verify_mprime_in.m_prime, stream_ready->m_prime,
HDCP_2_2_MPRIME_LEN);
@@ -619,6 +628,7 @@ static int mei_hdcp_enable_authentication(struct device
*dev,
enable_auth_in.port.integrated_port_type = data->port_type;
enable_auth_in.port.physical_port = (u8)data->fw_ddi;
+ enable_auth_in.port.attached_transcoder = (u8)data->fw_tc;
enable_auth_in.stream_type = data->streams[0].stream_type;
byte = mei_cldev_send(cldev, (u8 *)&enable_auth_in,
@@ -673,6 +683,7 @@ mei_hdcp_close_session(struct device *dev, struct
hdcp_port_data *data)
session_close_in.port.integrated_port_type = data->port_type;
session_close_in.port.physical_port = (u8)data->fw_ddi
Re: [PATCH v9 3/6] drm: Extend I915 mei interface for transcoder info
On 8/22/2019 8:49 PM, Ramalingam C wrote:
I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_ddi and add as a member into
the struct hdcp_port_data.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
include/drm/i915_mei_hdcp_interface.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/i915_mei_hdcp_interface.h
b/include/drm/i915_mei_hdcp_interface.h
index a97acf1c9710..0de629bf2f62 100644
--- a/include/drm/i915_mei_hdcp_interface.h
+++ b/include/drm/i915_mei_hdcp_interface.h
@@ -54,9 +54,21 @@ enum mei_fw_ddi {
MEI_DDI_RANGE_END = MEI_DDI_A,
};
+enum mei_fw_tc {
+ MEI_INVALID_TRANSCODER = 0x00, /* Invalid transcoder type */
+ MEI_TC_EDP, /* Transcoder for eDP */
+ MEI_TC_DSI0,/* Transcoder for DSI0 */
+ MEI_TC_DSI1,/* Transcoder for DSI1 */
Also, this is a bit odd, coz ports above can't do HDCP, so it doesn't
make sense to have them here. But seems like we want to be in sync with
MEI FW definitions, so we should change the function
intel_get_mei_fw_ddi_index to accept only from ports A to D, not above
or below.
- Shashank
+ MEI_TC_A = 0x10,/* Transcoder TCA */
+ MEI_TC_B, /* Transcoder TCB */
+ MEI_TC_C, /* Transcoder TCC */
+ MEI_TC_D/* Transcoder TCD */
+};
+
/**
* struct hdcp_port_data - intel specific HDCP port data
* @fw_ddi: ddi index as per ME FW
+ * @fw_tc: transcoder index as per ME FW
* @port_type: HDCP port type as per ME FW classification
* @protocol: HDCP adaptation as per ME FW
* @k: No of streams transmitted on a port. Only on DP MST this is != 1
@@ -69,6 +81,7 @@ enum mei_fw_ddi {
*/
struct hdcp_port_data {
enum mei_fw_ddi fw_ddi;
+ enum mei_fw_tc fw_tc;
u8 port_type;
u8 protocol;
u16 k;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/17] drm: add gem ttm helpers, rework mmap workflow.
On Mon, Aug 26, 2019 at 10:47:07AM +0200, Thomas Zimmermann wrote: > Hi, > > I would have liked to get some context on the purpose of GEM TTM > helpers. Is is just share-able code? Yes. Shareable code for drivers which use both ttm and gem (all except vmgfx). > From my understanding VRAM helpers _are_ GEM TTM helpers. And they where > re-named to VRAM helpers, so that the naming is independent from the > implementation (and vice versa). I think vram helpers are for old/simple devices which basically support dumb gem objects stored in vram (device memory typically exposed as pci bar). Using ttm underneath is largely an implementation detail for the users of the vram helpers, they don't need to know. > Wrt qxl, would it be possible to convert the driver over to VRAM helpers > entirely? I noticed a memory region named PRIV. Could we add this to > VRAM helpers? PRIV is vram too, qxl has two pci bars with memory. Historical reasons. There are rules which pci bar can store which kind of objects. I don't think it makes sense to move such device-specific things into vram helpers. Also qxl is complex enough that you can hardly hide ttm behind vram helpers. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ingenic: Hardcode panel type to DPI
On Fri, Aug 23, 2019 at 11:30:09PM +0200, Paul Cercueil wrote:
> Hi Laurent,
>
>
> Le ven. 23 août 2019 à 23:23, Laurent Pinchart
> a écrit :
> > The ingenic driver supports DPI panels only at the moment, so hardcode
> > their type to DPI instead of Unknown.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> > Paul, as the driver has been merged in v5.3-rc1, this is a candidate for
> > a v5.3 fix. Keeping the connector type as unknown could cause a
> > userspace dependency on it, preventing it from being changed later.
>
> Makes sense.
>
> Reviewed-by: Paul Cercueil
In another mail we discuss CONNECTOR_PANEL. But we should not hold up
due to this.
Reviewed-by: Sam Ravnborg
Paul - will you apply to drm-misc-fixes?
Sam
>
>
> >
> > diff --git a/drivers/gpu/drm/ingenic/ingenic-drm.c
> > b/drivers/gpu/drm/ingenic/ingenic-drm.c
> > index ce1fae3a78a9..2e2ed653e9c6 100644
> > --- a/drivers/gpu/drm/ingenic/ingenic-drm.c
> > +++ b/drivers/gpu/drm/ingenic/ingenic-drm.c
> > @@ -675,10 +675,9 @@ static int ingenic_drm_probe(struct platform_device
> > *pdev)
> > return ret;
> > }
> >
> > - if (panel) {
> > + if (panel)
> > bridge = devm_drm_panel_bridge_add(dev, panel,
> > - DRM_MODE_CONNECTOR_Unknown);
> > - }
> > + DRM_MODE_CONNECTOR_DPI);
> >
> > priv->dma_hwdesc = dma_alloc_coherent(dev, sizeof(*priv->dma_hwdesc),
> > &priv->dma_hwdesc_phys,
> > --
> > Regards,
> >
> > Laurent Pinchart
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111494] Raven Ridge (2400G): Firefox menu items become invisible
https://bugs.freedesktop.org/show_bug.cgi?id=111494 --- Comment #1 from Diego Viola --- My system specs: - Arch Linux (x86_64). - Linux 5.2.9-arch1-1-ARCH - mesa 19.1.5-1 - i3-wm 4.17-1 - Firefox 68.0.2-1 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 3/6] drm: Extend I915 mei interface for transcoder info
On 8/22/2019 8:49 PM, Ramalingam C wrote:
I915 needs to send the index of the transcoder as per ME FW.
To support this, define enum mei_fw_ddi and add as a member into
the struct hdcp_port_data.
The commit message says you are defining enum mei_fw_ddi, but you are
actually defining enum mei_fw_tc;
- Shashank
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
include/drm/i915_mei_hdcp_interface.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/i915_mei_hdcp_interface.h
b/include/drm/i915_mei_hdcp_interface.h
index a97acf1c9710..0de629bf2f62 100644
--- a/include/drm/i915_mei_hdcp_interface.h
+++ b/include/drm/i915_mei_hdcp_interface.h
@@ -54,9 +54,21 @@ enum mei_fw_ddi {
MEI_DDI_RANGE_END = MEI_DDI_A,
};
+enum mei_fw_tc {
+ MEI_INVALID_TRANSCODER = 0x00, /* Invalid transcoder type */
+ MEI_TC_EDP, /* Transcoder for eDP */
+ MEI_TC_DSI0,/* Transcoder for DSI0 */
+ MEI_TC_DSI1,/* Transcoder for DSI1 */
+ MEI_TC_A = 0x10,/* Transcoder TCA */
+ MEI_TC_B, /* Transcoder TCB */
+ MEI_TC_C, /* Transcoder TCC */
+ MEI_TC_D/* Transcoder TCD */
+};
+
/**
* struct hdcp_port_data - intel specific HDCP port data
* @fw_ddi: ddi index as per ME FW
+ * @fw_tc: transcoder index as per ME FW
* @port_type: HDCP port type as per ME FW classification
* @protocol: HDCP adaptation as per ME FW
* @k: No of streams transmitted on a port. Only on DP MST this is != 1
@@ -69,6 +81,7 @@ enum mei_fw_ddi {
*/
struct hdcp_port_data {
enum mei_fw_ddi fw_ddi;
+ enum mei_fw_tc fw_tc;
u8 port_type;
u8 protocol;
u16 k;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111482] Sapphire Pulse RX 5700 XT power consumption
https://bugs.freedesktop.org/show_bug.cgi?id=111482 --- Comment #2 from Andrew Sheldon --- I have the same problem, but with the MSI Evoke 5700 XT. If you read /sys/class/drm/card0/device/pp_dpm_mclk you should find that it's forced to the highest state (3: 875Mhz) and that although it lets you set a lower value, it immediately jumps back to the maximum value. In theory, this problem should have been fixed with b90053edc9d6d639ddb600f8799d990d92aca328 in amd-staging-drm-next: drm/amd/display: Support uclk switching for DCN2 but it doesn't seem to fix the problem for me. Before this, you could revert the old workaround: 02316e963a5a drm/amd/display: Force uclk to max for every state" and you could manually set mclk. I should note that from some brief tests on Windows, the card also seem to be stuck at maximum mclk (it's actually even worse since temperature readings don't even work there). So it could be that aftermarket cards need some extra work, in order to work properly. System: Mesa git amd-staging-drm-next (also tested 5.3-rcX and drm-next-5.4) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/6] drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
Regards
Shashank
On 8/27/2019 10:03 AM, Ramalingam C wrote:
On 2019-08-27 at 09:54:18 +0530, Sharma, Shashank wrote:
Hello Ram,
On 8/22/2019 8:48 PM, Ramalingam C wrote:
I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.
Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +-
drivers/misc/mei/hdcp/mei_hdcp.c | 34 ---
drivers/misc/mei/hdcp/mei_hdcp.h | 12
include/drm/i915_mei_hdcp_interface.h | 16 +--
4 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6ec5ceeab601..534832f435dc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1749,13 +1749,26 @@ static const struct component_ops
i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
};
+static inline
+enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return MEI_DDI_A;
+ case PORT_B ... PORT_F:
+ return (enum mei_fw_ddi)port;
+ default:
+ return MEI_DDI_INVALID_PORT;
+ }
+}
+
static inline int initialize_hdcp_port_data(struct intel_connector
*connector,
const struct intel_hdcp_shim *shim)
{
struct intel_hdcp *hdcp = &connector->hdcp;
struct hdcp_port_data *data = &hdcp->port_data;
- data->port = connector->encoder->port;
+ data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder->port);
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
data->protocol = (u8)shim->protocol;
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index c681f6fab342..3638c77eba26 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -27,18 +27,6 @@
#include "mei_hdcp.h"
-static inline u8 mei_get_ddi_index(enum port port)
-{
- switch (port) {
- case PORT_A:
- return MEI_DDI_A;
- case PORT_B ... PORT_F:
- return (u8)port;
- default:
- return MEI_DDI_INVALID_PORT;
- }
-}
-
/**
* mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
* @dev: device corresponding to the mei_cl_device
@@ -69,7 +57,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
session_init_in.port.integrated_port_type = data->port_type;
- session_init_in.port.physical_port = mei_get_ddi_index(data->port);
+ session_init_in.port.physical_port = (u8)data->fw_ddi;
session_init_in.protocol = data->protocol;
byte = mei_cldev_send(cldev, (u8 *)&session_init_in,
@@ -138,7 +126,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
verify_rxcert_in.port.integrated_port_type = data->port_type;
- verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
+ verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
verify_rxcert_in.cert_rx = rx_cert->cert_rx;
memcpy(verify_rxcert_in.r_rx, &rx_cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -208,7 +196,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
send_hprime_in.port.integrated_port_type = data->port_type;
- send_hprime_in.port.physical_port = mei_get_ddi_index(data->port);
+ send_hprime_in.port.physical_port = (u8)data->fw_ddi;
memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
HDCP_2_2_H_PRIME_LEN);
@@ -265,7 +253,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
pairing_info_in.port.integrated_port_type = data->port_type;
- pairing_info_in.port.physical_port = mei_get_ddi_index(data->port);
+ pairing_info_in.port.physical_port = (u8)data->fw_ddi;
memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
HDCP_2_2_E_KH_KM_LEN);
@@ -323,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
lc_init_in.port.integrated_port_type = data->port_type;
- lc_init_in.port.physical_port = mei_get_ddi_index(data->port);
+ lc_init_in.port.physical_port = (u8)data->fw_ddi;
byte = mei_cldev_send(cldev, (u8 *)&lc_init_in, sizeof(lc_init_in));
if (byte < 0) {
@@ -378,7 +366,7 @@ me
Re: [PATCH v9 2/6] drm: Move port definition back to i915 header
On 8/22/2019 8:49 PM, Ramalingam C wrote:
Handled the need for exposing enum port to mei_hdcp driver, by
converting the port into ddi index as per ME FW and sending to mei_hdcp.
Hence move enum port definition into I915 driver itself.
This is a nitpick, but if we can re-arrange this commit message a bit,
it would be easy to understand the changes and the reason behind that.
How about something like:
We need to expose enum port to mei_hdcp driver, so that it can convert
the port into MEI's respective DDI index.
So this patch moves definition of enum port from include/i915_drv.h, to
intel_display.h, inside display driver.
v2:
intel_display.h is included in intel_hdcp.h
v3:
enum port is declared in headers.
Signed-off-by: Ramalingam C
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.h| 1 +
drivers/gpu/drm/i915/display/intel_display.h | 18 ++
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
drivers/gpu/drm/i915/display/intel_hdcp.h| 1 +
drivers/gpu/drm/i915/display/intel_hdmi.h| 1 +
drivers/gpu/drm/i915/display/intel_hotplug.h | 1 +
drivers/gpu/drm/i915/display/intel_sdvo.h| 1 +
include/drm/i915_drm.h | 18 --
8 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
b/drivers/gpu/drm/i915/display/intel_bios.h
index 4969189e620f..4c6e56a3940a 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -35,6 +35,7 @@
#include
struct drm_i915_private;
+enum port;
enum intel_backlight_type {
INTEL_BACKLIGHT_PMIC,
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index e57e6969051d..40610d51327e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -182,6 +182,24 @@ enum plane_id {
for ((__p) = PLANE_PRIMARY; (__p) < I915_MAX_PLANES; (__p)++) \
for_each_if((__crtc)->plane_ids_mask & BIT(__p))
+enum port {
+ PORT_NONE = -1,
+
+ PORT_A = 0,
+ PORT_B,
+ PORT_C,
+ PORT_D,
+ PORT_E,
+ PORT_F,
+ PORT_G,
+ PORT_H,
+ PORT_I,
+
+ I915_MAX_PORTS
+};
+
+#define port_name(p) ((p) + 'A')
+
/*
* Ports identifier referenced from other drivers.
* Expected to remain stable over time
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 657bbb1f5ed0..e01d1f89409d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -13,6 +13,7 @@
#include "i915_reg.h"
enum pipe;
+enum port;
struct drm_connector_state;
struct drm_encoder;
struct drm_i915_private;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
b/drivers/gpu/drm/i915/display/intel_hdcp.h
index 13555b054930..59a2b40405cc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.h
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
@@ -15,6 +15,7 @@ struct drm_connector_state;
struct drm_i915_private;
struct intel_connector;
struct intel_hdcp_shim;
+enum port;
void intel_hdcp_atomic_check(struct drm_connector *connector,
struct drm_connector_state *old_state,
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.h
b/drivers/gpu/drm/i915/display/intel_hdmi.h
index 106c2e0bc3c9..cf1ea5427639 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.h
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.h
@@ -23,6 +23,7 @@ struct intel_crtc_state;
struct intel_hdmi;
struct drm_connector_state;
union hdmi_infoframe;
+enum port;
void intel_hdmi_init(struct drm_i915_private *dev_priv, i915_reg_t hdmi_reg,
enum port port);
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.h
b/drivers/gpu/drm/i915/display/intel_hotplug.h
index b0cd447b7fbc..087b5f57b321 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.h
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.h
@@ -13,6 +13,7 @@
struct drm_i915_private;
struct intel_connector;
struct intel_encoder;
+enum port;
void intel_hpd_poll_init(struct drm_i915_private *dev_priv);
enum intel_hotplug_state intel_encoder_hotplug(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.h
b/drivers/gpu/drm/i915/display/intel_sdvo.h
index c9e05bcdd141..a66f224aa17d 100644
--- a/drivers/gpu/drm/i915/display/intel_sdvo.h
+++ b/drivers/gpu/drm/i915/display/intel_sdvo.h
@@ -14,6 +14,7 @@
struct drm_i915_private;
enum pipe;
+enum port;
bool intel_sdvo_port_enabled(struct drm_i915_private *dev_priv,
i915_reg_t sdvo_reg, enum pipe *pipe);
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 23274cf92712..6722005884db 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -100,22 +100,4 @@ extern struct resource int
Re: [PATCH v9 1/6] drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
On 2019-08-27 at 09:54:18 +0530, Sharma, Shashank wrote:
> Hello Ram,
>
> On 8/22/2019 8:48 PM, Ramalingam C wrote:
> > I915 converts it's port value into ddi index defiend by ME FW
> > and pass it as a member of hdcp_port_data structure.
> >
> > Hence expose the enum mei_fw_ddi to I915 through
> > i915_mei_interface.h.
> >
> > Signed-off-by: Ramalingam C
> > Acked-by: Jani Nikula
> > ---
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +-
> > drivers/misc/mei/hdcp/mei_hdcp.c | 34 ---
> > drivers/misc/mei/hdcp/mei_hdcp.h | 12
> > include/drm/i915_mei_hdcp_interface.h | 16 +--
> > 4 files changed, 39 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index 6ec5ceeab601..534832f435dc 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -1749,13 +1749,26 @@ static const struct component_ops
> > i915_hdcp_component_ops = {
> > .unbind = i915_hdcp_component_unbind,
> > };
> > +static inline
> > +enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port port)
> > +{
> > + switch (port) {
> > + case PORT_A:
> > + return MEI_DDI_A;
> > + case PORT_B ... PORT_F:
> > + return (enum mei_fw_ddi)port;
> > + default:
> > + return MEI_DDI_INVALID_PORT;
> > + }
> > +}
> > +
> > static inline int initialize_hdcp_port_data(struct intel_connector
> > *connector,
> > const struct intel_hdcp_shim *shim)
> > {
> > struct intel_hdcp *hdcp = &connector->hdcp;
> > struct hdcp_port_data *data = &hdcp->port_data;
> > - data->port = connector->encoder->port;
> > + data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder->port);
> > data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
> > data->protocol = (u8)shim->protocol;
> > diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> > b/drivers/misc/mei/hdcp/mei_hdcp.c
> > index c681f6fab342..3638c77eba26 100644
> > --- a/drivers/misc/mei/hdcp/mei_hdcp.c
> > +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> > @@ -27,18 +27,6 @@
> > #include "mei_hdcp.h"
> > -static inline u8 mei_get_ddi_index(enum port port)
> > -{
> > - switch (port) {
> > - case PORT_A:
> > - return MEI_DDI_A;
> > - case PORT_B ... PORT_F:
> > - return (u8)port;
> > - default:
> > - return MEI_DDI_INVALID_PORT;
> > - }
> > -}
> > -
> > /**
> >* mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in
> > ME FW
> >* @dev: device corresponding to the mei_cl_device
> > @@ -69,7 +57,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
> > hdcp_port_data *data,
> > WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
> > session_init_in.port.integrated_port_type = data->port_type;
> > - session_init_in.port.physical_port = mei_get_ddi_index(data->port);
> > + session_init_in.port.physical_port = (u8)data->fw_ddi;
> > session_init_in.protocol = data->protocol;
> > byte = mei_cldev_send(cldev, (u8 *)&session_init_in,
> > @@ -138,7 +126,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device
> > *dev,
> > WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
> > verify_rxcert_in.port.integrated_port_type = data->port_type;
> > - verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
> > + verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
> > verify_rxcert_in.cert_rx = rx_cert->cert_rx;
> > memcpy(verify_rxcert_in.r_rx, &rx_cert->r_rx, HDCP_2_2_RRX_LEN);
> > @@ -208,7 +196,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
> > hdcp_port_data *data,
> > send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
> > send_hprime_in.port.integrated_port_type = data->port_type;
> > - send_hprime_in.port.physical_port = mei_get_ddi_index(data->port);
> > + send_hprime_in.port.physical_port = (u8)data->fw_ddi;
> > memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
> >HDCP_2_2_H_PRIME_LEN);
> > @@ -265,7 +253,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
> > hdcp_port_data *data,
> > WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
> > pairing_info_in.port.integrated_port_type = data->port_type;
> > - pairing_info_in.port.physical_port = mei_get_ddi_index(data->port);
> > + pairing_info_in.port.physical_port = (u8)data->fw_ddi;
> > memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
> >HDCP_2_2_E_KH_KM_LEN);
> > @@ -323,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
> > lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
> > lc_init_in.port.integrated_port_type = data->port_type;
> > - lc_init_in.port.physical_port = mei_get_ddi_index(data->port);
> > + lc_init_in.port.physic
Re: [PATCH] drm/bridge: tc358767: Expose test mode functionality via debugfs
On Mon, Aug 26, 2019 at 3:08 PM Laurent Pinchart
wrote:
>
> Hi Andrey,
>
> Thank you for the patch.
>
> On Mon, Aug 26, 2019 at 11:25:24AM -0700, Andrey Smirnov wrote:
> > Presently, the driver code artificially limits test pattern mode to a
> > single pattern with fixed color selection. It being a kernel module
> > parameter makes switching "test patter" <-> "proper output" modes
> > on-the-fly clunky and outright impossible if the driver is built into
> > the kernel.
> >
> > To improve the situation a bit, convert current test pattern code to
> > use debugfs instead by exposing "TestCtl" register. This way old
> > "tc_test_pattern=1" functionality can be emulated via:
> >
> > echo -n 0x78146312 > tstctl
> >
> > and switch back to regular mode can be done with:
> >
> > echo -n 0x78146310 > tstctl
>
> Can't we make this more userfriendly by exposing either a test pattern
> index, or a string ?
We could, but then a) it would require more code in the driver b) the
files wouldn't correspond directly to something described in the
part's datasheet. Just didn't seem worth it to me.
> Do all bits in the register need to be controlled
> from userspace ?
Pretty much, yes. It's formatted as RR_GG_BB_X_M, where R, G, B
specifies color used for various patterns, X is irrelevant and M
specifies test pattern to use.
>
> > Note that switching to any of the test patterns, will NOT trigger link
> > re-establishment whereas switching to normal operation WILL. This is
> > done so:
> >
> > a) we can isolate and verify (e)DP link functionality by switching to
> >one of the test patters
> >
> > b) trigger a link re-establishment by switching back to normal mode
> >
> > Signed-off-by: Andrey Smirnov
> > Cc: Andrzej Hajda
> > Cc: Laurent Pinchart
> > Cc: Tomi Valkeinen
> > Cc: Cory Tusar
> > Cc: Chris Healy
> > Cc: Lucas Stach
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-ker...@vger.kernel.org
> > ---
> > drivers/gpu/drm/bridge/tc358767.c | 137 ++
> > 1 file changed, 101 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/tc358767.c
> > b/drivers/gpu/drm/bridge/tc358767.c
> > index 6308d93ad91d..7a795b613ed0 100644
> > --- a/drivers/gpu/drm/bridge/tc358767.c
> > +++ b/drivers/gpu/drm/bridge/tc358767.c
> > @@ -17,6 +17,7 @@
> >
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -222,11 +223,10 @@
> > #define COLOR_B GENMASK(15, 8)
> > #define ENI2CFILTER BIT(4)
> > #define COLOR_BAR_MODE GENMASK(1, 0)
> > +#define COLOR_BAR_MODE_NORMAL0
> > #define COLOR_BAR_MODE_BARS 2
> > -#define PLL_DBG 0x0a04
> >
> > -static bool tc_test_pattern;
> > -module_param_named(test, tc_test_pattern, bool, 0644);
>
> I assume that his being a debug feature there's no system relying on the
> module parameter that would break if you remove it ?
>
Yeah, I don't know of any system that needs that parameter. It seems
pretty useless for anything but basic debugging.
> > +#define PLL_DBG 0x0a04
> >
> > struct tc_edp_link {
> > struct drm_dp_link base;
> > @@ -789,16 +789,6 @@ static int tc_set_video_mode(struct tc_data *tc,
> > if (ret)
> > return ret;
> >
> > - /* Test pattern settings */
> > - ret = regmap_write(tc->regmap, TSTCTL,
> > -FIELD_PREP(COLOR_R, 120) |
> > -FIELD_PREP(COLOR_G, 20) |
> > -FIELD_PREP(COLOR_B, 99) |
> > -ENI2CFILTER |
> > -FIELD_PREP(COLOR_BAR_MODE, COLOR_BAR_MODE_BARS));
> > - if (ret)
> > - return ret;
> > -
> > /* DP Main Stream Attributes */
> > vid_sync_dly = hsync_len + left_margin + mode->hdisplay;
> > ret = regmap_write(tc->regmap, DP0_VIDSYNCDELAY,
> > @@ -1150,14 +1140,6 @@ static int tc_stream_enable(struct tc_data *tc)
> >
> > dev_dbg(tc->dev, "enable video stream\n");
> >
> > - /* PXL PLL setup */
> > - if (tc_test_pattern) {
> > - ret = tc_pxl_pll_en(tc, clk_get_rate(tc->refclk),
> > - 1000 * tc->mode.clock);
> > - if (ret)
> > - return ret;
> > - }
> > -
> > ret = tc_set_video_mode(tc, &tc->mode);
> > if (ret)
> > return ret;
> > @@ -1186,12 +1168,8 @@ static int tc_stream_enable(struct tc_data *tc)
> > if (ret)
> > return ret;
> > /* Set input interface */
> > - value = DP0_AUDSRC_NO_INPUT;
> > - if (tc_test_pattern)
> > - value |= DP0_VIDSRC_COLOR_BAR;
> > - else
> > - value |= DP0_VIDSRC_DPI_RX;
> > - ret = regmap_write(tc->regmap, SYSCTRL, value);
> > + ret = regmap_write(tc->regmap, SYSCTRL,
> > +DP0_AUDSRC_NO_INPUT | DP0_VIDSRC_DPI_RX);
> > if (ret)
> > return
Re: [PATCH v9 1/6] drm/i915: mei_hdcp: I915 sends ddi index as per ME FW
Hello Ram,
On 8/22/2019 8:48 PM, Ramalingam C wrote:
I915 converts it's port value into ddi index defiend by ME FW
and pass it as a member of hdcp_port_data structure.
Hence expose the enum mei_fw_ddi to I915 through
i915_mei_interface.h.
Signed-off-by: Ramalingam C
Acked-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 15 +-
drivers/misc/mei/hdcp/mei_hdcp.c | 34 ---
drivers/misc/mei/hdcp/mei_hdcp.h | 12
include/drm/i915_mei_hdcp_interface.h | 16 +--
4 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 6ec5ceeab601..534832f435dc 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1749,13 +1749,26 @@ static const struct component_ops
i915_hdcp_component_ops = {
.unbind = i915_hdcp_component_unbind,
};
+static inline
+enum mei_fw_ddi intel_get_mei_fw_ddi_index(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return MEI_DDI_A;
+ case PORT_B ... PORT_F:
+ return (enum mei_fw_ddi)port;
+ default:
+ return MEI_DDI_INVALID_PORT;
+ }
+}
+
static inline int initialize_hdcp_port_data(struct intel_connector *connector,
const struct intel_hdcp_shim *shim)
{
struct intel_hdcp *hdcp = &connector->hdcp;
struct hdcp_port_data *data = &hdcp->port_data;
- data->port = connector->encoder->port;
+ data->fw_ddi = intel_get_mei_fw_ddi_index(connector->encoder->port);
data->port_type = (u8)HDCP_PORT_TYPE_INTEGRATED;
data->protocol = (u8)shim->protocol;
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index c681f6fab342..3638c77eba26 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -27,18 +27,6 @@
#include "mei_hdcp.h"
-static inline u8 mei_get_ddi_index(enum port port)
-{
- switch (port) {
- case PORT_A:
- return MEI_DDI_A;
- case PORT_B ... PORT_F:
- return (u8)port;
- default:
- return MEI_DDI_INVALID_PORT;
- }
-}
-
/**
* mei_hdcp_initiate_session() - Initiate a Wired HDCP2.2 Tx Session in ME FW
* @dev: device corresponding to the mei_cl_device
@@ -69,7 +57,7 @@ mei_hdcp_initiate_session(struct device *dev, struct
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
session_init_in.port.integrated_port_type = data->port_type;
- session_init_in.port.physical_port = mei_get_ddi_index(data->port);
+ session_init_in.port.physical_port = (u8)data->fw_ddi;
session_init_in.protocol = data->protocol;
byte = mei_cldev_send(cldev, (u8 *)&session_init_in,
@@ -138,7 +126,7 @@ mei_hdcp_verify_receiver_cert_prepare_km(struct device *dev,
WIRED_CMD_BUF_LEN_VERIFY_RECEIVER_CERT_IN;
verify_rxcert_in.port.integrated_port_type = data->port_type;
- verify_rxcert_in.port.physical_port = mei_get_ddi_index(data->port);
+ verify_rxcert_in.port.physical_port = (u8)data->fw_ddi;
verify_rxcert_in.cert_rx = rx_cert->cert_rx;
memcpy(verify_rxcert_in.r_rx, &rx_cert->r_rx, HDCP_2_2_RRX_LEN);
@@ -208,7 +196,7 @@ mei_hdcp_verify_hprime(struct device *dev, struct
hdcp_port_data *data,
send_hprime_in.header.buffer_len = WIRED_CMD_BUF_LEN_AKE_SEND_HPRIME_IN;
send_hprime_in.port.integrated_port_type = data->port_type;
- send_hprime_in.port.physical_port = mei_get_ddi_index(data->port);
+ send_hprime_in.port.physical_port = (u8)data->fw_ddi;
memcpy(send_hprime_in.h_prime, rx_hprime->h_prime,
HDCP_2_2_H_PRIME_LEN);
@@ -265,7 +253,7 @@ mei_hdcp_store_pairing_info(struct device *dev, struct
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_SEND_PAIRING_INFO_IN;
pairing_info_in.port.integrated_port_type = data->port_type;
- pairing_info_in.port.physical_port = mei_get_ddi_index(data->port);
+ pairing_info_in.port.physical_port = (u8)data->fw_ddi;
memcpy(pairing_info_in.e_kh_km, pairing_info->e_kh_km,
HDCP_2_2_E_KH_KM_LEN);
@@ -323,7 +311,7 @@ mei_hdcp_initiate_locality_check(struct device *dev,
lc_init_in.header.buffer_len = WIRED_CMD_BUF_LEN_INIT_LOCALITY_CHECK_IN;
lc_init_in.port.integrated_port_type = data->port_type;
- lc_init_in.port.physical_port = mei_get_ddi_index(data->port);
+ lc_init_in.port.physical_port = (u8)data->fw_ddi;
byte = mei_cldev_send(cldev, (u8 *)&lc_init_in, sizeof(lc_init_in));
if (byte < 0) {
@@ -378,7 +366,7 @@ mei_hdcp_verify_lprime(struct device *dev, struct
hdcp_port_data *data,
WIRED_CMD_BUF_LEN_VA
[Bug 111494] Raven Ridge (2400G): Firefox menu items become invisible
https://bugs.freedesktop.org/show_bug.cgi?id=111494 Bug ID: 111494 Summary: Raven Ridge (2400G): Firefox menu items become invisible Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: diego.vi...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 145173 --> https://bugs.freedesktop.org/attachment.cgi?id=145173&action=edit Firefox with the bug I believe this started happening with Mesa 19.1.5 (I'm not completely sure), I know I can reproduce it with the current mesa git master however. Is this another scissor bug? Please see the screenshot attached and note how the ">" disappears in "Bookmarks Toolbar". Thanks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 08/14] drm: rcar-du: Add support for CMM
Hi Jacopo,
Thank you for the patch.
On Sun, Aug 25, 2019 at 03:51:48PM +0200, Jacopo Mondi wrote:
> Add a driver for the R-Car Display Unit Color Correction Module.
>
> In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> to perform image enhancement and color correction.
>
> Add support for CMM through a driver that supports configuration of
> the 1-dimensional LUT table. More advanced CMM feature will be
> implemented on top of this basic one.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpu/drm/rcar-du/Kconfig| 7 +
> drivers/gpu/drm/rcar-du/Makefile | 1 +
> drivers/gpu/drm/rcar-du/rcar_cmm.c | 262 +
> drivers/gpu/drm/rcar-du/rcar_cmm.h | 38 +
> 4 files changed, 308 insertions(+)
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c
> create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h
>
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 1529849e217e..539d232790d1 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -13,6 +13,13 @@ config DRM_RCAR_DU
> Choose this option if you have an R-Car chipset.
> If M is selected the module will be called rcar-du-drm.
>
> +config DRM_RCAR_CMM
> + bool "R-Car DU Color Management Module (CMM) Support"
> + depends on DRM && OF
> + depends on DRM_RCAR_DU
> + help
> + Enable support for R-Car Color Management Module (CMM).
> +
> config DRM_RCAR_DW_HDMI
> tristate "R-Car DU Gen3 HDMI Encoder Support"
> depends on DRM && OF
> diff --git a/drivers/gpu/drm/rcar-du/Makefile
> b/drivers/gpu/drm/rcar-du/Makefile
> index 6c2ed9c46467..4d1187ccc3e5 100644
> --- a/drivers/gpu/drm/rcar-du/Makefile
> +++ b/drivers/gpu/drm/rcar-du/Makefile
> @@ -15,6 +15,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o \
> rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
> rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
>
> +obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
> obj-$(CONFIG_DRM_RCAR_DU)+= rcar-du-drm.o
> obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
> obj-$(CONFIG_DRM_RCAR_LVDS) += rcar_lvds.o
> diff --git a/drivers/gpu/drm/rcar-du/rcar_cmm.c
> b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> new file mode 100644
> index ..55361f5701e8
> --- /dev/null
> +++ b/drivers/gpu/drm/rcar-du/rcar_cmm.c
> @@ -0,0 +1,262 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * rcar_cmm.c -- R-Car Display Unit Color Management Module
> + *
> + * Copyright (C) 2019 Jacopo Mondi
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "rcar_cmm.h"
> +
> +#define CM2_LUT_CTRL 0x
> +#define CM2_LUT_CTRL_LUT_EN BIT(0)
> +#define CM2_LUT_TBL_BASE 0x0600
> +#define CM2_LUT_TBL(__i) (CM2_LUT_TBL_BASE + (__i) * 4)
> +
> +struct rcar_cmm {
> + void __iomem *base;
> + bool enabled;
> +
> + /*
> + * @lut:1D-LUT status
> + * @lut.enabled:1D-LUT enabled flag
> + * @lut.size: Number of entries in the LUT table
Please see my review of patch 13/14, I wonder if we could drop this
field.
> + * @lut.table: Table of 1D-LUT entries scaled to HW support
> + * precision (8-bits per color component)
> + */
> + struct {
> + bool enabled;
> + unsigned int size;
> + u32 table[CMM_GAMMA_LUT_SIZE];
> + } lut;
> +};
> +
> +static inline int rcar_cmm_read(struct rcar_cmm *rcmm, u32 reg)
> +{
> + return ioread32(rcmm->base + reg);
> +}
> +
> +static inline void rcar_cmm_write(struct rcar_cmm *rcmm, u32 reg, u32 data)
> +{
> + iowrite32(data, rcmm->base + reg);
> +}
> +
> +/*
> + * rcar_cmm_lut_extract() - Scale down to hw precision the DRM LUT table
s/hw/hardware/ (and below too)
> + * entries and store them.
> + * @rcmm: Pointer to the CMM device
> + * @size: Number of entries in the table
> + * @drm_lut: DRM LUT table
> + */
> +static void rcar_cmm_lut_extract(struct rcar_cmm *rcmm, size_t size,
> + const struct drm_color_lut *drm_lut)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < size; ++i) {
> + const struct drm_color_lut *lut = &drm_lut[i];
> +
> + rcmm->lut.table[i] = drm_color_lut_extract(lut->red, 8) << 16
> +| drm_color_lut_extract(lut->green, 8) << 8
> +| drm_color_lut_extract(lut->blue, 8);
> + }
> +
> + rcmm->lut.size = size;
> +}
> +
> +/*
> + * rcar_cmm_lut_load() - Write to hw the LUT table entries from the local
> table.
> + *
No need for a blank line
> + * @rcmm: Pointer to the CMM device
> + */
> +static void rcar_cmm_lut_load(struct rcar_cmm *rcmm)
I would name this rcar_cmm_lut_write().
> +{
> + unsigned int i;
> +
> + for (
Re: [PATCH v3 13/14] drm: rcar-du: kms: Update CMM in atomic commit tail
On Tue, Aug 27, 2019 at 03:00:17AM +0300, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> On Sun, Aug 25, 2019 at 03:51:53PM +0200, Jacopo Mondi wrote:
> > Update CMM settings at in the atomic commit tail helper method.
> >
> > The CMM is updated with new gamma values provided to the driver
> > in the GAMMA_LUT blob property.
> >
> > Reviewed-by: Ulrich Hecht
> > Reviewed-by: Laurent Pinchart
> > Signed-off-by: Jacopo Mondi
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 35 +++
> > 1 file changed, 35 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > index 61ca1d3c379a..047fdb982a11 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -22,6 +22,7 @@
> > #include
> > #include
> >
> > +#include "rcar_cmm.h"
> > #include "rcar_du_crtc.h"
> > #include "rcar_du_drv.h"
> > #include "rcar_du_encoder.h"
> > @@ -368,6 +369,37 @@ rcar_du_fb_create(struct drm_device *dev, struct
> > drm_file *file_priv,
> > * Atomic Check and Update
> > */
> >
> > +static void rcar_du_atomic_commit_update_cmm(struct drm_crtc *crtc,
> > +struct drm_crtc_state *old_state)
> > +{
> > + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> > + struct rcar_cmm_config cmm_config = {};
> > +
> > + if (!rcrtc->cmm || !crtc->state->color_mgmt_changed)
> > + return;
> > +
> > + if (!crtc->state->gamma_lut) {
> > + cmm_config.lut.enable = false;
> > + rcar_cmm_setup(rcrtc->cmm, &cmm_config);
> > +
> > + return;
> > + }
> > +
> > + cmm_config.lut.enable = true;
> > + cmm_config.lut.table = (struct drm_color_lut *)
> > + crtc->state->gamma_lut->data;
> > +
> > + /* Set LUT table size to 0 if entries should not be updated. */
> > + if (!old_state->gamma_lut ||
> > + old_state->gamma_lut->base.id != crtc->state->gamma_lut->base.id)
> > + cmm_config.lut.size = crtc->state->gamma_lut->length
> > + / sizeof(cmm_config.lut.table[0]);
>
> It has just occurred to me that the hardware only support LUTs of
> exactly 256 entries. Should we remove cmm_config.lut.size (simplifying
> the code in the CMM driver), and add a check to the CRTC .atomic_check()
> handler to reject invalid LUTs ? Sorry for not having caught this
> earlier.
Just an additional comment, if we drop the size field, then the
cmm_config.lut.table pointer should be set to NULL when the LUT contents
don't need to be updated.
> > + else
> > + cmm_config.lut.size = 0;
> > +
> > + rcar_cmm_setup(rcrtc->cmm, &cmm_config);
> > +}
> > +
> > static int rcar_du_atomic_check(struct drm_device *dev,
> > struct drm_atomic_state *state)
> > {
> > @@ -410,6 +442,9 @@ static void rcar_du_atomic_commit_tail(struct
> > drm_atomic_state *old_state)
> > rcdu->dpad1_source = rcrtc->index;
> > }
> >
> > + for_each_old_crtc_in_state(old_state, crtc, crtc_state, i)
> > + rcar_du_atomic_commit_update_cmm(crtc, crtc_state);
> > +
> > /* Apply the atomic update. */
> > drm_atomic_helper_commit_modeset_disables(dev, old_state);
> > drm_atomic_helper_commit_planes(dev, old_state,
>
> --
> Regards,
>
> Laurent Pinchart
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 14/14] drm: rcar-du: Force CMM enablement when resuming
Hi Jacopo,
(Question for Daniel below)
Thank you for the patch.
On Sun, Aug 25, 2019 at 03:51:54PM +0200, Jacopo Mondi wrote:
> When resuming from system suspend, the DU driver is responsible for
> reprogramming and enabling the CMM unit if it was in use at the time
> the system entered the suspend state.
>
> Force the color_mgmt_changed flag to true if any of the DRM color
> transformation properties was set in the CRTC state duplicated at
> suspend time, as the CMM gets reprogrammed only if said flag is active in
> the rcar_du_atomic_commit_update_cmm() method.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpu/drm/rcar-du/rcar_du_drv.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index 018480a8f35c..6e38495fb78f 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -17,6 +17,7 @@
> #include
> #include
>
> +#include
> #include
> #include
> #include
> @@ -482,6 +483,26 @@ static int rcar_du_pm_suspend(struct device *dev)
> static int rcar_du_pm_resume(struct device *dev)
> {
> struct rcar_du_device *rcdu = dev_get_drvdata(dev);
> + struct drm_atomic_state *state = rcdu->ddev->mode_config.suspend_state;
> + unsigned int i;
> +
> + for (i = 0; i < rcdu->num_crtcs; ++i) {
> + struct drm_crtc *crtc = &rcdu->crtcs[i].crtc;
> + struct drm_crtc_state *crtc_state;
> +
> + crtc_state = drm_atomic_get_existing_crtc_state(state, crtc);
> + if (!crtc_state)
> + continue;
Shouldn't you get the new state here ?
> +
> + /*
> + * Force re-enablement of CMM after system resume if any
> + * of the DRM color transformation properties was set in
> + * the state saved at system suspend time.
> + */
> + if (crtc_state->gamma_lut || crtc_state->degamma_lut ||
> + crtc_state->ctm)
We don't support degamma_lut or crm, so I would drop those.
With these small issues addressed,
Reviewed-by: Laurent Pinchart
Shouldn't we however squash this with the previous patch to avoid
bisection issues ?
> + crtc_state->color_mgmt_changed = true;
Daniel, is this something that would make sense in the KMS core (or
helpers) ?
> + }
>
> return drm_mode_config_helper_resume(rcdu->ddev);
> }
--
Regards,
Laurent Pinchart
Re: [PATCH v3 13/14] drm: rcar-du: kms: Update CMM in atomic commit tail
Hi Jacopo,
Thank you for the patch.
On Sun, Aug 25, 2019 at 03:51:53PM +0200, Jacopo Mondi wrote:
> Update CMM settings at in the atomic commit tail helper method.
>
> The CMM is updated with new gamma values provided to the driver
> in the GAMMA_LUT blob property.
>
> Reviewed-by: Ulrich Hecht
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 61ca1d3c379a..047fdb982a11 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -22,6 +22,7 @@
> #include
> #include
>
> +#include "rcar_cmm.h"
> #include "rcar_du_crtc.h"
> #include "rcar_du_drv.h"
> #include "rcar_du_encoder.h"
> @@ -368,6 +369,37 @@ rcar_du_fb_create(struct drm_device *dev, struct
> drm_file *file_priv,
> * Atomic Check and Update
> */
>
> +static void rcar_du_atomic_commit_update_cmm(struct drm_crtc *crtc,
> + struct drm_crtc_state *old_state)
> +{
> + struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
> + struct rcar_cmm_config cmm_config = {};
> +
> + if (!rcrtc->cmm || !crtc->state->color_mgmt_changed)
> + return;
> +
> + if (!crtc->state->gamma_lut) {
> + cmm_config.lut.enable = false;
> + rcar_cmm_setup(rcrtc->cmm, &cmm_config);
> +
> + return;
> + }
> +
> + cmm_config.lut.enable = true;
> + cmm_config.lut.table = (struct drm_color_lut *)
> +crtc->state->gamma_lut->data;
> +
> + /* Set LUT table size to 0 if entries should not be updated. */
> + if (!old_state->gamma_lut ||
> + old_state->gamma_lut->base.id != crtc->state->gamma_lut->base.id)
> + cmm_config.lut.size = crtc->state->gamma_lut->length
> + / sizeof(cmm_config.lut.table[0]);
It has just occurred to me that the hardware only support LUTs of
exactly 256 entries. Should we remove cmm_config.lut.size (simplifying
the code in the CMM driver), and add a check to the CRTC .atomic_check()
handler to reject invalid LUTs ? Sorry for not having caught this
earlier.
> + else
> + cmm_config.lut.size = 0;
> +
> + rcar_cmm_setup(rcrtc->cmm, &cmm_config);
> +}
> +
> static int rcar_du_atomic_check(struct drm_device *dev,
> struct drm_atomic_state *state)
> {
> @@ -410,6 +442,9 @@ static void rcar_du_atomic_commit_tail(struct
> drm_atomic_state *old_state)
> rcdu->dpad1_source = rcrtc->index;
> }
>
> + for_each_old_crtc_in_state(old_state, crtc, crtc_state, i)
> + rcar_du_atomic_commit_update_cmm(crtc, crtc_state);
> +
> /* Apply the atomic update. */
> drm_atomic_helper_commit_modeset_disables(dev, old_state);
> drm_atomic_helper_commit_planes(dev, old_state,
--
Regards,
Laurent Pinchart
Re: [PATCH v3 10/14] drm: rcar-du: kms: Collect CMM instances
Hi Jacopo,
Thank you for the patch.
On Sun, Aug 25, 2019 at 03:51:50PM +0200, Jacopo Mondi wrote:
> Implement device tree parsing to collect the available CMM instances
> described by the 'cmms' property. Associate CMMs with CRTCs and store a
> mask of active CMMs in the DU group for later enablement.
>
> Enforce the suspend/resume ordering of DU and CMM by creating a
> stateless device link between the two to make sure the CMM supplier
> device suspends after and resumes before the DU consumer.
>
> Signed-off-by: Jacopo Mondi
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 6 +++
> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +
> drivers/gpu/drm/rcar-du/rcar_du_drv.h | 3 ++
> drivers/gpu/drm/rcar-du/rcar_du_group.h | 2 +
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 63 +
> 5 files changed, 76 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index 2da46e3dc4ae..23f1d6cc1719 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -1194,6 +1194,12 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp,
> unsigned int swindex,
> if (ret < 0)
> return ret;
>
> + /* CMM might be disabled for this CRTC. */
> + if (rcdu->cmms[swindex]) {
> + rcrtc->cmm = rcdu->cmms[swindex];
> + rgrp->cmms_mask |= BIT(hwindex % 2);
> + }
> +
> drm_crtc_helper_add(crtc, &crtc_helper_funcs);
>
> /* Start with vertical blanking interrupt reporting disabled. */
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> index 3b7fc668996f..5f2940c42225 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> @@ -39,6 +39,7 @@ struct rcar_du_vsp;
> * @vblank_wait: wait queue used to signal vertical blanking
> * @vblank_count: number of vertical blanking interrupts to wait for
> * @group: CRTC group this CRTC belongs to
> + * @cmm: CMM associated with this CRTC
> * @vsp: VSP feeding video to this CRTC
> * @vsp_pipe: index of the VSP pipeline feeding video to this CRTC
> * @writeback: the writeback connector
> @@ -64,6 +65,7 @@ struct rcar_du_crtc {
> unsigned int vblank_count;
>
> struct rcar_du_group *group;
> + struct platform_device *cmm;
> struct rcar_du_vsp *vsp;
> unsigned int vsp_pipe;
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> index a00dccc447aa..300ec60ba31b 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -13,6 +13,7 @@
> #include
> #include
>
> +#include "rcar_cmm.h"
> #include "rcar_du_crtc.h"
> #include "rcar_du_group.h"
> #include "rcar_du_vsp.h"
> @@ -70,6 +71,7 @@ struct rcar_du_device_info {
>
> #define RCAR_DU_MAX_CRTCS4
> #define RCAR_DU_MAX_GROUPS DIV_ROUND_UP(RCAR_DU_MAX_CRTCS, 2)
> +#define RCAR_DU_MAX_CMMS 4
Maybe alphabetically sorted ?
> #define RCAR_DU_MAX_VSPS 4
>
> struct rcar_du_device {
> @@ -86,6 +88,7 @@ struct rcar_du_device {
> struct rcar_du_encoder *encoders[RCAR_DU_OUTPUT_MAX];
>
> struct rcar_du_group groups[RCAR_DU_MAX_GROUPS];
> + struct platform_device *cmms[RCAR_DU_MAX_CMMS];
As there's one CMM per CRTC, should we use RCAR_DU_MAX_CRTCS here ? It's
not very useful to have two different macros that are required to have
the same value :-)
> struct rcar_du_vsp vsps[RCAR_DU_MAX_VSPS];
>
> struct {
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.h
> b/drivers/gpu/drm/rcar-du/rcar_du_group.h
> index 87950c1f6a52..e9906609c635 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_group.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.h
> @@ -22,6 +22,7 @@ struct rcar_du_device;
> * @mmio_offset: registers offset in the device memory map
> * @index: group index
> * @channels_mask: bitmask of populated DU channels in this group
> + * @cmms_mask: bitmask of available CMMs in this group
> * @num_crtcs: number of CRTCs in this group (1 or 2)
> * @use_count: number of users of the group (rcar_du_group_(get|put))
> * @used_crtcs: number of CRTCs currently in use
> @@ -37,6 +38,7 @@ struct rcar_du_group {
> unsigned int index;
>
> unsigned int channels_mask;
> + unsigned int cmms_mask;
> unsigned int num_crtcs;
> unsigned int use_count;
> unsigned int used_crtcs;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 2dc9caee8767..61ca1d3c379a 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -17,7 +17,9 @@
> #include
> #include
>
> +#include
> #include
> +#include
> #include
>
> #include "rcar_du_crtc.h"
> @@ -614,6 +616,62 @@ static int rcar_du_vsps_init(struct rcar_du_device *rcdu)
>
[Bug 204611] amdgpu error scheduling IBs when waking from sleep
https://bugzilla.kernel.org/show_bug.cgi?id=204611 --- Comment #2 from tones...@hotmail.com --- The problem is after v5.1, and before v5.2. It's very reproducible on v5.2 but might be less frequent as the bisect progresses. Attempts have driven me into the weeds, but I'm still trying. It looks like another user reported the same issue here: https://bugzilla.kernel.org/show_bug.cgi?id=204227 During my bisect I was seeing visual artifacts without the lockup so I believe they're separate issues. -- 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 204227] Visual artefacts and crash from suspend on amdgpu
https://bugzilla.kernel.org/show_bug.cgi?id=204227 tones...@hotmail.com changed: What|Removed |Added CC||tones...@hotmail.com --- Comment #4 from tones...@hotmail.com --- I'm seeing the same problems when running 5.2.x that were not present in 5.1. The commit above is the source of the visual artifacts, but I believe the lockup issue was introduced later. Is there any help I can provide in testing a fix? It looks like there might have been some previous effort here: https://www.spinics.net/lists/amd-gfx/msg32192.html I created https://bugzilla.kernel.org/show_bug.cgi?id=204611 that can be used to track the lockup issue. -- 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 111482] Sapphire Pulse RX 5700 XT power consumption
https://bugs.freedesktop.org/show_bug.cgi?id=111482 --- Comment #1 from Robert --- Not sure if it's of any use but I figured out today that after starting KDE Plasma, launching "Konsole" and typing "sensors" the output is basically garbage: """ amdgpu-pci-0c00 Adapter: PCI adapter vddgfx: +0.72 V fan1: N/A (min =0 RPM, max = 3200 RPM) edge: N/A (crit = +118.0°C, hyst = -273.1°C) (emerg = +99.0°C) junction: N/A (crit = +99.0°C, hyst = -273.1°C) (emerg = +99.0°C) mem: N/A (crit = +99.0°C, hyst = -273.1°C) (emerg = +99.0°C) power1: N/A (cap = 180.00 W) asus-isa- Adapter: ISA adapter cpu_fan:0 RPM """ I can repeat this a few times and it stays the same. And I always see this errors in "dmesg" or "journalctl": """ [ 137.931148] amdgpu: [powerplay] failed send message: TransferTableSmu2Dram (18) param: 0x0006 response 0xffc2 [ 137.931150] amdgpu: [powerplay] Failed to export SMU metrics table! [ 140.144885] amdgpu: [powerplay] failed send message: SetDriverDramAddrHigh (14) param: 0x0080 response 0xffc2 [ 142.358346] amdgpu: [powerplay] failed send message: SetDriverDramAddrHigh (14) param: 0x0080 response 0xffc2 [ 142.358348] amdgpu: [powerplay] Failed to export SMU metrics table! [ 144.571878] amdgpu: [powerplay] failed send message: SetDriverDramAddrHigh (14) param: 0x0080 response 0xffc2 [ 146.785069] amdgpu: [powerplay] failed send message: SetDriverDramAddrHigh (14) param: 0x0080 response 0xffc2 [ 146.785071] amdgpu: [powerplay] Failed to export SMU metrics table! [ 148.998450] amdgpu: [powerplay] failed send message: SetDriverDramAddrHigh (14) param: 0x0080 response 0xffc2 [ 151.211737] amdgpu: [powerplay] failed send message: SetDriverDramAddrHigh (14) param: 0x0080 response 0xffc2 [ 151.211738] amdgpu: [powerplay] Failed to export SMU metrics table! [ 153.425132] amdgpu: [powerplay] failed send message: SetDriverDramAddrHigh (14) param: 0x0080 response 0xffc2 [ 155.638843] amdgpu: [powerplay] failed send message: SetDriverDramAddrHigh (14) param: 0x0080 response 0xffc2 [ 155.638845] amdgpu: [powerplay] Failed to export SMU metrics table! """ It looks like that for every value "sensors" try to get it prints one such "failed send message..." errors. Now the funny thing is if I start "Firefox" the screen "flickers" very shortly and afterwards "sensors" prints useful values e.g.: """ amdgpu-pci-0c00 Adapter: PCI adapter vddgfx: +0.72 V fan1: 531 RPM (min =0 RPM, max = 3200 RPM) edge: +54.0°C (crit = +118.0°C, hyst = -273.1°C) (emerg = +99.0°C) junction: +56.0°C (crit = +99.0°C, hyst = -273.1°C) (emerg = +99.0°C) mem: +66.0°C (crit = +99.0°C, hyst = -273.1°C) (emerg = +99.0°C) power1: 34.00 W (cap = 180.00 W) asus-isa- Adapter: ISA adapter cpu_fan:0 RPM """ But the problem with high idle power consumption of course doesn't change. Today I updated to the latest firmware from 2019-08-26 and also updated Mesa to 19.2-rc1. In the last post I forgot to mention that I'm currently using "libdrm-git 2.4.99.r16.g14922551-1" which is basically libdrm master branch AFAIK. I'm really a little bit out of ideas ATM. Besides the idle power consumption thingy everything is working perfectly. Even Minecraft ;-) Before I installed Archlinux from scratch I used a Nvidia GTX 1060 with the Nvidia binary drivers in the same host as the Sapphire card I now use wasn't released at that time. With that card I hadn't any issues with idle power consumption. It was around 8-10W while running KDE Plasma. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 07/14] arm64: dts: renesas: r8a77995: Add CMM units
Hi Jacopo,
Thank you for the patch.
On Sun, Aug 25, 2019 at 03:51:47PM +0200, Jacopo Mondi wrote:
> Add CMM units to Renesas R-Car D3 device tree and reference them from
> the Display Unit they are connected to.
>
> While at it, re-sort the du device node properties to match the ordering
> found in other SoCs.
>
> Signed-off-by: Jacopo Mondi
Apart from the issue with compatible string as pointed out for patch
03/14,
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77995.dtsi | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> index 183fef86cf7c..b91a20fbbbc6 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -993,6 +993,22 @@
> iommus = <&ipmmu_vi0 9>;
> };
>
> + cmm0: cmm@fea4 {
> + compatible = "renesas,cmm-r8a77995";
> + reg = <0 0xfea4 0 0x1000>;
> + clocks = <&cpg CPG_MOD 711>;
> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> + resets = <&cpg 711>;
> + };
> +
> + cmm1: cmm@fea5 {
> + compatible = "renesas,cmm-r8a77995";
> + reg = <0 0xfea5 0 0x1000>;
> + clocks = <&cpg CPG_MOD 710>;
> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> + resets = <&cpg 710>;
> + };
> +
> du: display@feb0 {
> compatible = "renesas,du-r8a77995";
> reg = <0 0xfeb0 0 0x4>;
> @@ -1003,9 +1019,11 @@
> clock-names = "du.0", "du.1";
> resets = <&cpg 724>;
> reset-names = "du.0";
> - vsps = <&vspd0 0>, <&vspd1 0>;
> status = "disabled";
>
> + vsps = <&vspd0 0>, <&vspd1 0>;
> + cmms = <&cmm0 &cmm1>;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
--
Regards,
Laurent Pinchart
Re: [PATCH v3 06/14] arm64: dts: renesas: r8a77990: Add CMM units
Hi Jacopo,
Thank you for the patch.
On Sun, Aug 25, 2019 at 03:51:46PM +0200, Jacopo Mondi wrote:
> Add CMM units to Renesas R-Car E3 device tree and reference them from
> the Display Unit they are connected to.
>
> While at it, re-sort the du device node properties to match the ordering
> found in other SoCs.
>
> Signed-off-by: Jacopo Mondi
Apart from the issue with compatible string as pointed out for patch
03/14,
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 20 +++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> index 455954c3d98e..89ebe6f565af 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> @@ -1727,6 +1727,22 @@
> iommus = <&ipmmu_vi0 9>;
> };
>
> + cmm0: cmm@fea4 {
> + compatible = "renesas,cmm-r8a77990";
> + reg = <0 0xfea4 0 0x1000>;
> + clocks = <&cpg CPG_MOD 711>;
> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> + resets = <&cpg 711>;
> + };
> +
> + cmm1: cmm@fea5 {
> + compatible = "renesas,cmm-r8a77990";
> + reg = <0 0xfea5 0 0x1000>;
> + clocks = <&cpg CPG_MOD 710>;
> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> + resets = <&cpg 710>;
> + };
> +
> csi40: csi2@feaa {
> compatible = "renesas,r8a77990-csi2";
> reg = <0 0xfeaa 0 0x1>;
> @@ -1768,9 +1784,11 @@
> clock-names = "du.0", "du.1";
> resets = <&cpg 724>;
> reset-names = "du.0";
> - vsps = <&vspd0 0>, <&vspd1 0>;
> status = "disabled";
>
> + vsps = <&vspd0 0>, <&vspd1 0>;
> + cmms = <&cmm0 &cmm1>;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
--
Regards,
Laurent Pinchart
Re: [PATCH v3 05/14] arm64: dts: renesas: r8a77965: Add CMM units
Hi Jacopo,
Thank you for the patch.
On Sun, Aug 25, 2019 at 03:51:45PM +0200, Jacopo Mondi wrote:
> Add CMM units to Renesas R-Car M3-N device tree and reference them from
> the Display Unit they are connected to.
>
> Signed-off-by: Jacopo Mondi
Apart from the issue with compatible string as pointed out for patch
03/14,
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a77965.dtsi | 25 +++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> index 4ae163220f60..8cf0d049203d 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
> @@ -2320,6 +2320,30 @@
> resets = <&cpg 611>;
> };
>
> + cmm0: cmm@fea4 {
> + compatible = "renesas,cmm-r8a77965";
> + reg = <0 0xfea4 0 0x1000>;
> + clocks = <&cpg CPG_MOD 711>;
> + power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
> + resets = <&cpg 711>;
> + };
> +
> + cmm1: cmm@fea5 {
> + compatible = "renesas,cmm-r8a77965";
> + reg = <0 0xfea5 0 0x1000>;
> + clocks = <&cpg CPG_MOD 710>;
> + power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
> + resets = <&cpg 710>;
> + };
> +
> + cmm3: cmm@fea7 {
> + compatible = "renesas,cmm-r8a77965";
> + reg = <0 0xfea7 0 0x1000>;
> + clocks = <&cpg CPG_MOD 708>;
> + power-domains = <&sysc R8A77965_PD_ALWAYS_ON>;
> + resets = <&cpg 708>;
> + };
> +
> csi20: csi2@fea8 {
> compatible = "renesas,r8a77965-csi2";
> reg = <0 0xfea8 0 0x1>;
> @@ -2470,6 +2494,7 @@
> status = "disabled";
>
> vsps = <&vspd0 0>, <&vspd1 0>, <&vspd0 1>;
> + cmms = <&cmm0 &cmm1 &cmm3>;
>
> ports {
> #address-cells = <1>;
--
Regards,
Laurent Pinchart
[Bug 110865] Rx480 consumes 20w more power in idle than under Windows
https://bugs.freedesktop.org/show_bug.cgi?id=110865 --- Comment #24 from Martin --- I am so sorry to hear that Dieter, this is really terrible. But I can assure you your English is fine. I also think your problem is somewhere else. You mentioned it yourself. and I think Alex Deucher did as well, that your P-States are not changing. I have two different screens. One HP ZR2440W connected via DVI and a Dell U2412M connected via Displayport. Both run at 59.95Hz@1920x1200 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 04/14] arm64: dts: renesas: r8a7795: Add CMM units
Hi Jacopo,
Thank you for the patch.
On Sun, Aug 25, 2019 at 03:51:44PM +0200, Jacopo Mondi wrote:
> Add CMM units to Renesas R-Car H3 device tree and reference them from
> the Display Unit they are connected to.
>
> While at it, re-sort the du device node properties to match the ordering
> found in other SoCs.
>
> Signed-off-by: Jacopo Mondi
Apart from the issue with compatible string as pointed out for patch
03/14,
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a7795.dtsi | 36 +++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> index 95deff66eeb6..21b4069f07e7 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> @@ -2909,6 +2909,38 @@
> iommus = <&ipmmu_vi1 10>;
> };
>
> + cmm0: cmm@fea4 {
> + compatible = "renesas,cmm-r8a7795";
> + reg = <0 0xfea4 0 0x1000>;
> + clocks = <&cpg CPG_MOD 711>;
> + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> + resets = <&cpg 711>;
> + };
> +
> + cmm1: cmm@fea5 {
> + compatible = "renesas,cmm-r8a7795";
> + reg = <0 0xfea5 0 0x1000>;
> + clocks = <&cpg CPG_MOD 710>;
> + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> + resets = <&cpg 710>;
> + };
> +
> + cmm2: cmm@fea6 {
> + compatible = "renesas,cmm-r8a7795";
> + reg = <0 0xfea6 0 0x1000>;
> + clocks = <&cpg CPG_MOD 709>;
> + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> + resets = <&cpg 709>;
> + };
> +
> + cmm3: cmm@fea7 {
> + compatible = "renesas,cmm-r8a7795";
> + reg = <0 0xfea7 0 0x1000>;
> + clocks = <&cpg CPG_MOD 708>;
> + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;
> + resets = <&cpg 708>;
> + };
> +
> csi20: csi2@fea8 {
> compatible = "renesas,r8a7795-csi2";
> reg = <0 0xfea8 0 0x1>;
> @@ -3112,9 +3144,11 @@
><&cpg CPG_MOD 722>,
><&cpg CPG_MOD 721>;
> clock-names = "du.0", "du.1", "du.2", "du.3";
> - vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
> status = "disabled";
>
> + vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
> + cmms = <&cmm0 &cmm1 &cmm2 &cmm3>;
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
--
Regards,
Laurent Pinchart
Re: [PATCH v3 03/14] arm64: dts: renesas: r8a7796: Add CMM units
Hi Jacopo,
Thank you for the patch.
Should you squash this with the patches that add CMM units to the other
SoCs ?
On Sun, Aug 25, 2019 at 03:51:43PM +0200, Jacopo Mondi wrote:
> Add CMM units to Renesas R-Car M3-W device tree and reference them from
> the Display Unit they are connected to.
>
> Signed-off-by: Jacopo Mondi
Apart from the issue pointed out by Geert,
Reviewed-by: Laurent Pinchart
> ---
> arch/arm64/boot/dts/renesas/r8a7796.dtsi | 25
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> index 3dc9d73f589a..8d78e1f98a23 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -2613,6 +2613,30 @@
> renesas,fcp = <&fcpvi0>;
> };
>
> + cmm0: cmm@fea4 {
> + compatible = "renesas,cmm-r8a7796";
> + reg = <0 0xfea4 0 0x1000>;
> + clocks = <&cpg CPG_MOD 711>;
> + power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
> + resets = <&cpg 711>;
> + };
> +
> + cmm1: cmm@fea5 {
> + compatible = "renesas,cmm-r8a7796";
> + reg = <0 0xfea5 0 0x1000>;
> + clocks = <&cpg CPG_MOD 710>;
> + power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
> + resets = <&cpg 710>;
> + };
> +
> + cmm2: cmm@fea6 {
> + compatible = "renesas,cmm-r8a7796";
> + reg = <0 0xfea6 0 0x1000>;
> + clocks = <&cpg CPG_MOD 709>;
> + power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
> + resets = <&cpg 709>;
> + };
> +
> csi20: csi2@fea8 {
> compatible = "renesas,r8a7796-csi2";
> reg = <0 0xfea8 0 0x1>;
> @@ -2766,6 +2790,7 @@
> status = "disabled";
>
> vsps = <&vspd0 &vspd1 &vspd2>;
> + cmms = <&cmm0 &cmm1 &cmm2>;
>
> ports {
> #address-cells = <1>;
--
Regards,
Laurent Pinchart
Re: [PATCH v2] drm/virtio: add plane check
On Thu, Aug 22, 2019 at 2:47 AM Gerd Hoffmann wrote:
>
> Use drm_atomic_helper_check_plane_state()
> to sanity check the plane state.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_plane.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
> b/drivers/gpu/drm/virtio/virtgpu_plane.c
> index a492ac3f4a7e..fe5efb2de90d 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
> @@ -84,7 +84,22 @@ static const struct drm_plane_funcs virtio_gpu_plane_funcs
> = {
> static int virtio_gpu_plane_atomic_check(struct drm_plane *plane,
> struct drm_plane_state *state)
> {
> - return 0;
> + bool is_cursor = plane->type == DRM_PLANE_TYPE_CURSOR;
> + struct drm_crtc_state *crtc_state;
> + int ret;
> +
> + if (!state->fb || !state->crtc)
> + return 0;
> +
> + crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
> + if (IS_ERR(crtc_state))
> +return PTR_ERR(crtc_state);
Is drm_atomic_get_new_crtc_state better here?
> +
> + ret = drm_atomic_helper_check_plane_state(state, crtc_state,
> + DRM_PLANE_HELPER_NO_SCALING,
> + DRM_PLANE_HELPER_NO_SCALING,
> + is_cursor, true);
> + return ret;
> }
>
> static void virtio_gpu_primary_plane_update(struct drm_plane *plane,
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 5/8] drm/panfrost: Split mmu_hw_do_operation into locked and unlocked version
In preparation to call mmu_hw_do_operation with the as_lock already held,
Add a mmu_hw_do_operation_locked function.
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
v3:
- new patch
drivers/gpu/drm/panfrost/panfrost_mmu.c | 26 -
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 2204e60f7808..3407b00d0a3a 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -80,19 +80,11 @@ static void lock_region(struct panfrost_device *pfdev, u32
as_nr,
}
-static int mmu_hw_do_operation(struct panfrost_device *pfdev,
- struct panfrost_mmu *mmu,
- u64 iova, size_t size, u32 op)
+static int mmu_hw_do_operation_locked(struct panfrost_device *pfdev, int as_nr,
+ u64 iova, size_t size, u32 op)
{
- int ret, as_nr;
-
- spin_lock(&pfdev->as_lock);
- as_nr = mmu->as;
-
- if (as_nr < 0) {
- spin_unlock(&pfdev->as_lock);
+ if (as_nr < 0)
return 0;
- }
if (op != AS_COMMAND_UNLOCK)
lock_region(pfdev, as_nr, iova, size);
@@ -101,10 +93,18 @@ static int mmu_hw_do_operation(struct panfrost_device
*pfdev,
write_cmd(pfdev, as_nr, op);
/* Wait for the flush to complete */
- ret = wait_ready(pfdev, as_nr);
+ return wait_ready(pfdev, as_nr);
+}
- spin_unlock(&pfdev->as_lock);
+static int mmu_hw_do_operation(struct panfrost_device *pfdev,
+ struct panfrost_mmu *mmu,
+ u64 iova, size_t size, u32 op)
+{
+ int ret;
+ spin_lock(&pfdev->as_lock);
+ ret = mmu_hw_do_operation_locked(pfdev, mmu->as, iova, size, op);
+ spin_unlock(&pfdev->as_lock);
return ret;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/8] drm/panfrost: Rework runtime PM initialization
There's a few issues with the runtime PM initialization.
The documentation states pm_runtime_set_active() should be called before
pm_runtime_enable(). The pm_runtime_put_autosuspend() could suspend the GPU
before panfrost_perfcnt_init() is called which touches the h/w. The
autosuspend delay keeps things from breaking. There's no need explicitly
power off the GPU only to wake back up with pm_runtime_get_sync(). Just
delaying pm_runtime_enable to the end of probe is sufficient.
Lets move all the runtime PM calls into the probe() function so they are
all in one place and are done after all initialization.
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: David Airlie
Cc: Daniel Vetter
Acked-by: Alyssa Rosenzweig
Signed-off-by: Rob Herring
---
v3:
- Move autosuspend setup after pm_runtime_enable as only autosuspend changes
trigger suspend.
- Fix autosuspend delay to 50ms instead of 0.
drivers/gpu/drm/panfrost/panfrost_device.c | 9 -
drivers/gpu/drm/panfrost/panfrost_drv.c| 10 ++
2 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 4da71bb56c20..73805210834e 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -5,7 +5,6 @@
#include
#include
#include
-#include
#include
#include "panfrost_device.h"
@@ -166,14 +165,6 @@ int panfrost_device_init(struct panfrost_device *pfdev)
if (err)
goto err_out4;
- /* runtime PM will wake us up later */
- panfrost_gpu_power_off(pfdev);
-
- pm_runtime_set_active(pfdev->dev);
- pm_runtime_get_sync(pfdev->dev);
- pm_runtime_mark_last_busy(pfdev->dev);
- pm_runtime_put_autosuspend(pfdev->dev);
-
err = panfrost_perfcnt_init(pfdev);
if (err)
goto err_out5;
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index d74442d71048..bc2ddeb55f5d 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -523,10 +523,6 @@ static int panfrost_probe(struct platform_device *pdev)
mutex_init(&pfdev->shrinker_lock);
INIT_LIST_HEAD(&pfdev->shrinker_list);
- pm_runtime_use_autosuspend(pfdev->dev);
- pm_runtime_set_autosuspend_delay(pfdev->dev, 50); /* ~3 frames */
- pm_runtime_enable(pfdev->dev);
-
err = panfrost_device_init(pfdev);
if (err) {
if (err != -EPROBE_DEFER)
@@ -541,6 +537,12 @@ static int panfrost_probe(struct platform_device *pdev)
goto err_out1;
}
+ pm_runtime_set_active(pfdev->dev);
+ pm_runtime_mark_last_busy(pfdev->dev);
+ pm_runtime_enable(pfdev->dev);
+ pm_runtime_set_autosuspend_delay(pfdev->dev, 50); /* ~3 frames */
+ pm_runtime_use_autosuspend(pfdev->dev);
+
/*
* Register the DRM device with the core and the connectors with
* sysfs
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 6/8] drm/panfrost: Add cache/TLB flush before switching address space
It's not entirely clear if this is required, but add a flush of GPU caches
and TLBs before we change an address space to new page tables.
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 ++
1 file changed, 2 insertions(+)
v3:
- New patch
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 3407b00d0a3a..d1ebde3327fe 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -115,6 +115,8 @@ static void panfrost_mmu_enable(struct panfrost_device
*pfdev, struct panfrost_m
u64 transtab = cfg->arm_mali_lpae_cfg.transtab;
u64 memattr = cfg->arm_mali_lpae_cfg.memattr;
+ mmu_hw_do_operation_locked(pfdev, as_nr, 0, ~0UL, AS_COMMAND_FLUSH_MEM);
+
mmu_write(pfdev, AS_TRANSTAB_LO(as_nr), transtab & 0xUL);
mmu_write(pfdev, AS_TRANSTAB_HI(as_nr), transtab >> 32);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 7/8] drm/panfrost: Flush and disable address space when freeing page tables
Currently, page tables are freed without disabling the address space first.
This probably is fine as we'll switch to new page tables when the address
space is allocated again and runtime PM suspend will reset the GPU
clearing the registers. However, it's better to clean up after ourselves.
There is also a problem that we could be accessing the h/w in
tlb_inv_context() when suspended.
Rework the disable code to make sure we flush caches/TLBs and disable the
address space before freeing the page tables if we are not suspended. As
the tlb_inv_context() hook is only called when freeing the page tables and
we do a flush before disabling the AS, lets remove the flush from
tlb_inv_context and avoid any runtime PM issues.
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
v3:
- New patch replacing "drm/panfrost: Remove unnecessary flushing from
tlb_inv_context"
drivers/gpu/drm/panfrost/panfrost_mmu.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index d1ebde3327fe..387d830cb7cf 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -129,8 +129,10 @@ static void panfrost_mmu_enable(struct panfrost_device
*pfdev, struct panfrost_m
write_cmd(pfdev, as_nr, AS_COMMAND_UPDATE);
}
-static void mmu_disable(struct panfrost_device *pfdev, u32 as_nr)
+static void panfrost_mmu_disable(struct panfrost_device *pfdev, u32 as_nr)
{
+ mmu_hw_do_operation_locked(pfdev, as_nr, 0, ~0UL, AS_COMMAND_FLUSH_MEM);
+
mmu_write(pfdev, AS_TRANSTAB_LO(as_nr), 0);
mmu_write(pfdev, AS_TRANSTAB_HI(as_nr), 0);
@@ -321,11 +323,7 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
}
static void mmu_tlb_inv_context_s1(void *cookie)
-{
- struct panfrost_file_priv *priv = cookie;
-
- mmu_hw_do_operation(priv->pfdev, &priv->mmu, 0, ~0UL,
AS_COMMAND_FLUSH_MEM);
-}
+{}
static void mmu_tlb_inv_range_nosync(unsigned long iova, size_t size,
size_t granule, bool leaf, void *cookie)
@@ -374,6 +372,11 @@ void panfrost_mmu_pgtable_free(struct panfrost_file_priv
*priv)
spin_lock(&pfdev->as_lock);
if (mmu->as >= 0) {
+ pm_runtime_get_noresume(pfdev->dev);
+ if (pm_runtime_active(pfdev->dev))
+ panfrost_mmu_disable(pfdev, mmu->as);
+ pm_runtime_put_autosuspend(pfdev->dev);
+
clear_bit(mmu->as, &pfdev->as_alloc_mask);
clear_bit(mmu->as, &pfdev->as_in_use_mask);
list_del(&mmu->list);
@@ -618,5 +621,4 @@ int panfrost_mmu_init(struct panfrost_device *pfdev)
void panfrost_mmu_fini(struct panfrost_device *pfdev)
{
mmu_write(pfdev, MMU_INT_MASK, 0);
- mmu_disable(pfdev, 0);
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/8] drm/panfrost: Hold runtime PM reference until jobs complete
Doing a pm_runtime_put as soon as a job is submitted is wrong as it should
not happen until the job completes. It works currently because we are
relying on the autosuspend timeout to keep the h/w enabled.
Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
v3:
- Fix race between clearing pfdev->jobs[] in timeout and the ISR using the
job_lock
- Maintain pm_runtime_put in the panfrost_job_hw_submit error path
drivers/gpu/drm/panfrost/panfrost_job.c | 39 ++---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 05c85f45a0de..18bcc9bac6d2 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -150,8 +150,10 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
if (ret < 0)
return;
- if (WARN_ON(job_read(pfdev, JS_COMMAND_NEXT(js
- goto end;
+ if (WARN_ON(job_read(pfdev, JS_COMMAND_NEXT(js {
+ pm_runtime_put_sync_autosuspend(pfdev->dev);
+ return;
+ }
cfg = panfrost_mmu_as_get(pfdev, &job->file_priv->mmu);
@@ -187,10 +189,6 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START);
spin_unlock_irqrestore(&pfdev->hwaccess_lock, flags);
-
-end:
- pm_runtime_mark_last_busy(pfdev->dev);
- pm_runtime_put_autosuspend(pfdev->dev);
}
static void panfrost_acquire_object_fences(struct drm_gem_object **bos,
@@ -369,6 +367,7 @@ static void panfrost_job_timedout(struct drm_sched_job
*sched_job)
struct panfrost_job *job = to_panfrost_job(sched_job);
struct panfrost_device *pfdev = job->pfdev;
int js = panfrost_job_get_slot(job);
+ unsigned long flags;
int i;
/*
@@ -394,6 +393,15 @@ static void panfrost_job_timedout(struct drm_sched_job
*sched_job)
if (sched_job)
drm_sched_increase_karma(sched_job);
+ spin_lock_irqsave(&pfdev->js->job_lock, flags);
+ for (i = 0; i < NUM_JOB_SLOTS; i++) {
+ if (pfdev->jobs[i]) {
+ pm_runtime_put_noidle(pfdev->dev);
+ pfdev->jobs[i] = NULL;
+ }
+ }
+ spin_unlock_irqrestore(&pfdev->js->job_lock, flags);
+
/* panfrost_core_dump(pfdev); */
panfrost_devfreq_record_transition(pfdev, js);
@@ -450,12 +458,21 @@ static irqreturn_t panfrost_job_irq_handler(int irq, void
*data)
}
if (status & JOB_INT_MASK_DONE(j)) {
- struct panfrost_job *job = pfdev->jobs[j];
+ struct panfrost_job *job;
+
+ spin_lock(&pfdev->js->job_lock);
+ job = pfdev->jobs[j];
+ /* Only NULL if job timeout occurred */
+ if (job) {
+ pfdev->jobs[j] = NULL;
+
+ panfrost_mmu_as_put(pfdev,
&job->file_priv->mmu);
+ panfrost_devfreq_record_transition(pfdev, j);
- pfdev->jobs[j] = NULL;
- panfrost_mmu_as_put(pfdev, &job->file_priv->mmu);
- panfrost_devfreq_record_transition(pfdev, j);
- dma_fence_signal(job->done_fence);
+ dma_fence_signal_locked(job->done_fence);
+ pm_runtime_put_autosuspend(pfdev->dev);
+ }
+ spin_unlock(&pfdev->js->job_lock);
}
status &= ~mask;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 8/8] drm/panfrost: Remove unnecessary hwaccess_lock spin_lock
With the introduction of the as_lock to serialize address space registers,
the hwaccess_lock is only used within the job code and is not protecting
anything. panfrost_job_hw_submit() only accesses registers for 1 job slot
and it's already serialized by drm_sched.
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
v3:
- New patch
drivers/gpu/drm/panfrost/panfrost_device.c | 1 -
drivers/gpu/drm/panfrost/panfrost_device.h | 2 --
drivers/gpu/drm/panfrost/panfrost_job.c| 4
3 files changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 73805210834e..46b0b02e4289 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -124,7 +124,6 @@ int panfrost_device_init(struct panfrost_device *pfdev)
INIT_LIST_HEAD(&pfdev->scheduled_jobs);
INIT_LIST_HEAD(&pfdev->as_lru_list);
- spin_lock_init(&pfdev->hwaccess_lock);
spin_lock_init(&pfdev->as_lock);
err = panfrost_clk_init(pfdev);
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index b7fa08ed3a23..9c39b9794811 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -63,8 +63,6 @@ struct panfrost_device {
struct drm_device *ddev;
struct platform_device *pdev;
- spinlock_t hwaccess_lock;
-
void __iomem *iomem;
struct clk *clock;
struct clk *bus_clock;
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 18bcc9bac6d2..a58551668d9a 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -141,7 +141,6 @@ static void panfrost_job_write_affinity(struct
panfrost_device *pfdev,
static void panfrost_job_hw_submit(struct panfrost_job *job, int js)
{
struct panfrost_device *pfdev = job->pfdev;
- unsigned long flags;
u32 cfg;
u64 jc_head = job->jc;
int ret;
@@ -158,7 +157,6 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
cfg = panfrost_mmu_as_get(pfdev, &job->file_priv->mmu);
panfrost_devfreq_record_transition(pfdev, js);
- spin_lock_irqsave(&pfdev->hwaccess_lock, flags);
job_write(pfdev, JS_HEAD_NEXT_LO(js), jc_head & 0x);
job_write(pfdev, JS_HEAD_NEXT_HI(js), jc_head >> 32);
@@ -187,8 +185,6 @@ static void panfrost_job_hw_submit(struct panfrost_job
*job, int js)
job, js, jc_head);
job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START);
-
- spin_unlock_irqrestore(&pfdev->hwaccess_lock, flags);
}
static void panfrost_acquire_object_fences(struct drm_gem_object **bos,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/8] drm/panfrost: Remove unnecessary mmu->lock mutex
There's no need to serialize io-pgtable calls and the as_lock is
sufficient to serialize flush operations, so we can remove the per
page table lock.
Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces")
Suggested-by: Robin Murphy
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
v3:
- new patch
drivers/gpu/drm/panfrost/panfrost_device.h | 1 -
drivers/gpu/drm/panfrost/panfrost_mmu.c| 9 -
2 files changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index f503c566e99f..b7fa08ed3a23 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -104,7 +104,6 @@ struct panfrost_device {
struct panfrost_mmu {
struct io_pgtable_cfg pgtbl_cfg;
struct io_pgtable_ops *pgtbl_ops;
- struct mutex lock;
int as;
atomic_t as_count;
struct list_head list;
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 842bdd7cf6be..3a8bcfa7e7b6 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -228,8 +228,6 @@ static int mmu_map_sg(struct panfrost_device *pfdev, struct
panfrost_mmu *mmu,
struct io_pgtable_ops *ops = mmu->pgtbl_ops;
u64 start_iova = iova;
- mutex_lock(&mmu->lock);
-
for_each_sg(sgt->sgl, sgl, sgt->nents, count) {
unsigned long paddr = sg_dma_address(sgl);
size_t len = sg_dma_len(sgl);
@@ -249,8 +247,6 @@ static int mmu_map_sg(struct panfrost_device *pfdev, struct
panfrost_mmu *mmu,
mmu_hw_do_operation(pfdev, mmu, start_iova, iova - start_iova,
AS_COMMAND_FLUSH_PT);
- mutex_unlock(&mmu->lock);
-
return 0;
}
@@ -304,8 +300,6 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
if (ret < 0)
return;
- mutex_lock(&bo->mmu->lock);
-
while (unmapped_len < len) {
size_t unmapped_page;
size_t pgsize = get_pgsize(iova, len - unmapped_len);
@@ -321,8 +315,6 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
mmu_hw_do_operation(pfdev, bo->mmu, bo->node.start << PAGE_SHIFT,
bo->node.size << PAGE_SHIFT, AS_COMMAND_FLUSH_PT);
- mutex_unlock(&bo->mmu->lock);
-
pm_runtime_mark_last_busy(pfdev->dev);
pm_runtime_put_autosuspend(pfdev->dev);
bo->is_mapped = false;
@@ -356,7 +348,6 @@ int panfrost_mmu_pgtable_alloc(struct panfrost_file_priv
*priv)
struct panfrost_mmu *mmu = &priv->mmu;
struct panfrost_device *pfdev = priv->pfdev;
- mutex_init(&mmu->lock);
INIT_LIST_HEAD(&mmu->list);
mmu->as = -1;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 4/8] drm/panfrost: Rework page table flushing and runtime PM interaction
There is no point in resuming the h/w just to do flush operations and
doing so takes several locks which cause lockdep issues with the shrinker.
Rework the flush operations to only happen when the h/w is already awake.
This avoids taking any locks associated with resuming which trigger
lockdep warnings.
Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support")
Cc: Tomeu Vizoso
Cc: Steven Price
Cc: Alyssa Rosenzweig
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Rob Herring
---
v3:
- Use pm_runtime_get_noresume() and pm_runtime_active() instead of
pm_runtime_get_if_not_used(). The problem is pm_runtime_get_if_not_used()
returns 0 (no get) if in the period between the last put()
and before the autosuspend timeout when the h/w is still active.
drivers/gpu/drm/panfrost/panfrost_mmu.c | 38 -
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index 3a8bcfa7e7b6..2204e60f7808 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -220,6 +220,22 @@ static size_t get_pgsize(u64 addr, size_t size)
return SZ_2M;
}
+void panfrost_mmu_flush_range(struct panfrost_device *pfdev,
+ struct panfrost_mmu *mmu,
+ u64 iova, size_t size)
+{
+ if (mmu->as < 0)
+ return;
+
+ pm_runtime_get_noresume(pfdev->dev);
+
+ /* Flush the PTs only if we're already awake */
+ if (pm_runtime_active(pfdev->dev))
+ mmu_hw_do_operation(pfdev, mmu, iova, size,
AS_COMMAND_FLUSH_PT);
+
+ pm_runtime_put_sync_autosuspend(pfdev->dev);
+}
+
static int mmu_map_sg(struct panfrost_device *pfdev, struct panfrost_mmu *mmu,
u64 iova, int prot, struct sg_table *sgt)
{
@@ -244,8 +260,7 @@ static int mmu_map_sg(struct panfrost_device *pfdev, struct
panfrost_mmu *mmu,
}
}
- mmu_hw_do_operation(pfdev, mmu, start_iova, iova - start_iova,
- AS_COMMAND_FLUSH_PT);
+ panfrost_mmu_flush_range(pfdev, mmu, start_iova, iova - start_iova);
return 0;
}
@@ -255,7 +270,6 @@ int panfrost_mmu_map(struct panfrost_gem_object *bo)
struct drm_gem_object *obj = &bo->base.base;
struct panfrost_device *pfdev = to_panfrost_device(obj->dev);
struct sg_table *sgt;
- int ret;
int prot = IOMMU_READ | IOMMU_WRITE;
if (WARN_ON(bo->is_mapped))
@@ -268,14 +282,7 @@ int panfrost_mmu_map(struct panfrost_gem_object *bo)
if (WARN_ON(IS_ERR(sgt)))
return PTR_ERR(sgt);
- ret = pm_runtime_get_sync(pfdev->dev);
- if (ret < 0)
- return ret;
-
mmu_map_sg(pfdev, bo->mmu, bo->node.start << PAGE_SHIFT, prot, sgt);
-
- pm_runtime_mark_last_busy(pfdev->dev);
- pm_runtime_put_autosuspend(pfdev->dev);
bo->is_mapped = true;
return 0;
@@ -289,17 +296,12 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
u64 iova = bo->node.start << PAGE_SHIFT;
size_t len = bo->node.size << PAGE_SHIFT;
size_t unmapped_len = 0;
- int ret;
if (WARN_ON(!bo->is_mapped))
return;
dev_dbg(pfdev->dev, "unmap: as=%d, iova=%llx, len=%zx", bo->mmu->as,
iova, len);
- ret = pm_runtime_get_sync(pfdev->dev);
- if (ret < 0)
- return;
-
while (unmapped_len < len) {
size_t unmapped_page;
size_t pgsize = get_pgsize(iova, len - unmapped_len);
@@ -312,11 +314,7 @@ void panfrost_mmu_unmap(struct panfrost_gem_object *bo)
unmapped_len += pgsize;
}
- mmu_hw_do_operation(pfdev, bo->mmu, bo->node.start << PAGE_SHIFT,
- bo->node.size << PAGE_SHIFT, AS_COMMAND_FLUSH_PT);
-
- pm_runtime_mark_last_busy(pfdev->dev);
- pm_runtime_put_autosuspend(pfdev->dev);
+ panfrost_mmu_flush_range(pfdev, bo->mmu, bo->node.start << PAGE_SHIFT,
len);
bo->is_mapped = false;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/8] panfrost: Locking and runtime PM fixes
With further testing of recent changes with lockdep identified some locking issues. Avoiding lockdep issues means we need to avoid some locks in panfrost_mmu_unmap which in turn means avoiding runtime PM resume. In the process of re-working runtime PM several runtime PM and locking clean-ups have been identified. v3: - Applied patches 1, 4, 5, and 6 - Fix race in job timeout handling with ISR - Remove some no longer needed locks - Fix panfrost_mmu_unmap when autosuspend delay is > 0 - Disable AS MMU when freeing page tables v2: - Drop already applied 'drm/panfrost: Fix sleeping while atomic in panfrost_gem_open' - Runtime PM clean-ups - Keep panfrost_gem_purge and use mutex_trylock there - Rework panfrost_mmu_unmap runtime PM Rob Rob Herring (8): drm/panfrost: Rework runtime PM initialization drm/panfrost: Hold runtime PM reference until jobs complete drm/panfrost: Remove unnecessary mmu->lock mutex drm/panfrost: Rework page table flushing and runtime PM interaction drm/panfrost: Split mmu_hw_do_operation into locked and unlocked version drm/panfrost: Add cache/TLB flush before switching address space drm/panfrost: Flush and disable address space when freeing page tables drm/panfrost: Remove unnecessary hwaccess_lock spin_lock drivers/gpu/drm/panfrost/panfrost_device.c | 10 --- drivers/gpu/drm/panfrost/panfrost_device.h | 3 - drivers/gpu/drm/panfrost/panfrost_drv.c| 10 ++- drivers/gpu/drm/panfrost/panfrost_job.c| 43 ++ drivers/gpu/drm/panfrost/panfrost_mmu.c| 91 ++ 5 files changed, 76 insertions(+), 81 deletions(-) -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND 05/14] drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory
Am Montag, 26. August 2019, 21:25:47 CEST schrieb Andrzej Pietrasiewicz: > Use the ddc pointer provided by the generic connector. > > Signed-off-by: Andrzej Pietrasiewicz > Acked-by: Sam Ravnborg > Reviewed-by: Emil Velikov Acked-by: Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND 06/14] drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory
Am Montag, 26. August 2019, 21:25:48 CEST schrieb Andrzej Pietrasiewicz: > Use the ddc pointer provided by the generic connector. > > Signed-off-by: Andrzej Pietrasiewicz > Acked-by: Sam Ravnborg > Reviewed-by: Emil Velikov Acked-by: Heiko Stuebner
Re: [PATCH] drm/bridge: tc358767: Expose test mode functionality via debugfs
Hi Andrey,
Thank you for the patch.
On Mon, Aug 26, 2019 at 11:25:24AM -0700, Andrey Smirnov wrote:
> Presently, the driver code artificially limits test pattern mode to a
> single pattern with fixed color selection. It being a kernel module
> parameter makes switching "test patter" <-> "proper output" modes
> on-the-fly clunky and outright impossible if the driver is built into
> the kernel.
>
> To improve the situation a bit, convert current test pattern code to
> use debugfs instead by exposing "TestCtl" register. This way old
> "tc_test_pattern=1" functionality can be emulated via:
>
> echo -n 0x78146312 > tstctl
>
> and switch back to regular mode can be done with:
>
> echo -n 0x78146310 > tstctl
Can't we make this more userfriendly by exposing either a test pattern
index, or a string ? Do all bits in the register need to be controlled
from userspace ?
> Note that switching to any of the test patterns, will NOT trigger link
> re-establishment whereas switching to normal operation WILL. This is
> done so:
>
> a) we can isolate and verify (e)DP link functionality by switching to
>one of the test patters
>
> b) trigger a link re-establishment by switching back to normal mode
>
> Signed-off-by: Andrey Smirnov
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc: Tomi Valkeinen
> Cc: Cory Tusar
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> ---
> drivers/gpu/drm/bridge/tc358767.c | 137 ++
> 1 file changed, 101 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index 6308d93ad91d..7a795b613ed0 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -17,6 +17,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -222,11 +223,10 @@
> #define COLOR_B GENMASK(15, 8)
> #define ENI2CFILTER BIT(4)
> #define COLOR_BAR_MODE GENMASK(1, 0)
> +#define COLOR_BAR_MODE_NORMAL0
> #define COLOR_BAR_MODE_BARS 2
> -#define PLL_DBG 0x0a04
>
> -static bool tc_test_pattern;
> -module_param_named(test, tc_test_pattern, bool, 0644);
I assume that his being a debug feature there's no system relying on the
module parameter that would break if you remove it ?
> +#define PLL_DBG 0x0a04
>
> struct tc_edp_link {
> struct drm_dp_link base;
> @@ -789,16 +789,6 @@ static int tc_set_video_mode(struct tc_data *tc,
> if (ret)
> return ret;
>
> - /* Test pattern settings */
> - ret = regmap_write(tc->regmap, TSTCTL,
> -FIELD_PREP(COLOR_R, 120) |
> -FIELD_PREP(COLOR_G, 20) |
> -FIELD_PREP(COLOR_B, 99) |
> -ENI2CFILTER |
> -FIELD_PREP(COLOR_BAR_MODE, COLOR_BAR_MODE_BARS));
> - if (ret)
> - return ret;
> -
> /* DP Main Stream Attributes */
> vid_sync_dly = hsync_len + left_margin + mode->hdisplay;
> ret = regmap_write(tc->regmap, DP0_VIDSYNCDELAY,
> @@ -1150,14 +1140,6 @@ static int tc_stream_enable(struct tc_data *tc)
>
> dev_dbg(tc->dev, "enable video stream\n");
>
> - /* PXL PLL setup */
> - if (tc_test_pattern) {
> - ret = tc_pxl_pll_en(tc, clk_get_rate(tc->refclk),
> - 1000 * tc->mode.clock);
> - if (ret)
> - return ret;
> - }
> -
> ret = tc_set_video_mode(tc, &tc->mode);
> if (ret)
> return ret;
> @@ -1186,12 +1168,8 @@ static int tc_stream_enable(struct tc_data *tc)
> if (ret)
> return ret;
> /* Set input interface */
> - value = DP0_AUDSRC_NO_INPUT;
> - if (tc_test_pattern)
> - value |= DP0_VIDSRC_COLOR_BAR;
> - else
> - value |= DP0_VIDSRC_DPI_RX;
> - ret = regmap_write(tc->regmap, SYSCTRL, value);
> + ret = regmap_write(tc->regmap, SYSCTRL,
> +DP0_AUDSRC_NO_INPUT | DP0_VIDSRC_DPI_RX);
> if (ret)
> return ret;
>
> @@ -1220,39 +1198,44 @@ static void tc_bridge_pre_enable(struct drm_bridge
> *bridge)
> drm_panel_prepare(tc->panel);
> }
>
> -static void tc_bridge_enable(struct drm_bridge *bridge)
> +static int __tc_bridge_enable(struct tc_data *tc)
> {
> - struct tc_data *tc = bridge_to_tc(bridge);
> int ret;
>
> ret = tc_get_display_props(tc);
> if (ret < 0) {
> dev_err(tc->dev, "failed to read display props: %d\n", ret);
> - return;
> + return ret;
> }
>
> ret = tc_main_link_enable(tc);
> if (ret < 0) {
> dev_err(tc->dev, "main link enable error: %d\n", ret);
> - return;
> + return ret;
> }
>
> ret =
[Bug 110865] Rx480 consumes 20w more power in idle than under Windows
https://bugs.freedesktop.org/show_bug.cgi?id=110865 --- Comment #23 from Dieter Nützel --- Oh, BTW Martin which type are your 2 identical displays? HDMI (like mine) or DisplayPort? I use sound over HDMI, too. And only one display present it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/26] drm/dp_mst: Destroy mstbs from destroy_connector_work
On Tue, 2019-08-13 at 15:00 +0200, Daniel Vetter wrote:
> On Wed, Jul 17, 2019 at 09:42:25PM -0400, Lyude Paul wrote:
> > Currently we remove MST branch devices from the in-memory topology
> > immediately when their topology refcount reaches 0. This works just fine
> > at the moment, but since we're about to add suspend/resume reprobing for
> > MST topologies we're going to need to be able to travel through the
> > topology and drop topology refs on branch devices while holding
> > mgr->mutex. Since we currently can't do this due to the circular locking
> > dependencies that would incur, move all of the actual work for
> > drm_dp_destroy_mst_branch_device() into drm_dp_destroy_connector_work()
> > so we can drop topology refs on MSTBs in any locking context.
>
> Would be good to point at where exactly the problem is here, maybe also
> mentioned the exact future patch that causes the problem. I did go look
> around a bit, but didn't spot it.
Ah, I didn't do a great job of explaining whoops! Basically, the issue is that
when reprobing the state during suspend/resume, there's of course going to be
a chance that any MST ports in the topology could have had their PDT changed
while we were suspended. This in turn means that while we're iterating through
each mstb's ports in drm_dp_send_link_address() we want to be able to remove
MSTBs from while under &mgr->lock, something we can't do without handling MSTB
destruction in another thread. I'll mention this in the next version of this
patch
>
> > Cc: Juston Li
> > Cc: Imre Deak
> > Cc: Ville Syrjälä
> > Cc: Harry Wentland
> > Signed-off-by: Lyude Paul
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 121 +-
> > include/drm/drm_dp_mst_helper.h | 10 +++
> > 2 files changed, 90 insertions(+), 41 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 998081b9b205..d7c3d9233834 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -1108,34 +1108,17 @@ static void
> > drm_dp_destroy_mst_branch_device(struct kref *kref)
> > struct drm_dp_mst_branch *mstb =
> > container_of(kref, struct drm_dp_mst_branch, topology_kref);
> > struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
> > - struct drm_dp_mst_port *port, *tmp;
> > - bool wake_tx = false;
> > -
> > - mutex_lock(&mgr->lock);
> > - list_for_each_entry_safe(port, tmp, &mstb->ports, next) {
> > - list_del(&port->next);
> > - drm_dp_mst_topology_put_port(port);
> > - }
> > - mutex_unlock(&mgr->lock);
> > -
> > - /* drop any tx slots msg */
> > - mutex_lock(&mstb->mgr->qlock);
> > - if (mstb->tx_slots[0]) {
> > - mstb->tx_slots[0]->state = DRM_DP_SIDEBAND_TX_TIMEOUT;
> > - mstb->tx_slots[0] = NULL;
> > - wake_tx = true;
> > - }
> > - if (mstb->tx_slots[1]) {
> > - mstb->tx_slots[1]->state = DRM_DP_SIDEBAND_TX_TIMEOUT;
> > - mstb->tx_slots[1] = NULL;
> > - wake_tx = true;
> > - }
> > - mutex_unlock(&mstb->mgr->qlock);
> >
> > - if (wake_tx)
> > - wake_up_all(&mstb->mgr->tx_waitq);
> > + INIT_LIST_HEAD(&mstb->destroy_next);
> >
> > - drm_dp_mst_put_mstb_malloc(mstb);
> > + /*
> > +* This can get called under mgr->mutex, so we need to perform the
> > +* actual destruction of the mstb in another worker
> > +*/
> > + mutex_lock(&mgr->destroy_connector_lock);
> > + list_add(&mstb->destroy_next, &mgr->destroy_branch_device_list);
> > + mutex_unlock(&mgr->destroy_connector_lock);
> > + schedule_work(&mgr->destroy_connector_work);
> > }
> >
> > /**
> > @@ -3618,10 +3601,56 @@ static void drm_dp_tx_work(struct work_struct
> > *work)
> > mutex_unlock(&mgr->qlock);
> > }
> >
> > +static inline void
> > +drm_dp_finish_destroy_port(struct drm_dp_mst_port *port)
>
> Bikeshed: I'd call this _delayed_destroy, I think that makes a bit clearer
> why there's 2 stages to destroying stuff.
>
> > +{
> > + INIT_LIST_HEAD(&port->next);
> > +
> > + port->mgr->cbs->destroy_connector(port->mgr, port->connector);
> > +
> > + drm_dp_port_teardown_pdt(port, port->pdt);
> > + port->pdt = DP_PEER_DEVICE_NONE;
> > +
> > + drm_dp_mst_put_port_malloc(port);
> > +}
> > +
> > +static inline void
> > +drm_dp_finish_destroy_mst_branch_device(struct drm_dp_mst_branch *mstb)
> > +{
> > + struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
> > + struct drm_dp_mst_port *port, *tmp;
> > + bool wake_tx = false;
> > +
> > + mutex_lock(&mgr->lock);
> > + list_for_each_entry_safe(port, tmp, &mstb->ports, next) {
> > + list_del(&port->next);
> > + drm_dp_mst_topology_put_port(port);
> > + }
> > + mutex_unlock(&mgr->lock);
> > +
> > + /* drop any tx slots msg */
> > + mutex_lock(&mstb->mgr->qlock);
> > + if (mstb->tx_slots[0]) {
> > + mstb->tx_slots[0]->state = DRM_DP_SIDE
Re: [PATCH v2] drm/virtio: make resource id workaround runtime switchable.
On Thu, Aug 22, 2019 at 3:26 AM Gerd Hoffmann wrote:
>
> Also update the comment with a reference to the virglrenderer fix.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Chia-I Wu
> ---
> drivers/gpu/drm/virtio/virtgpu_object.c | 44 ++---
> 1 file changed, 24 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
> b/drivers/gpu/drm/virtio/virtgpu_object.c
> index b2da31310d24..e98aaa00578d 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_object.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_object.c
> @@ -27,34 +27,38 @@
>
> #include "virtgpu_drv.h"
>
> +static int virtio_gpu_virglrenderer_workaround = 1;
> +module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int,
> 0400);
> +
> static int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev,
>uint32_t *resid)
> {
> -#if 0
> - int handle = ida_alloc(&vgdev->resource_ida, GFP_KERNEL);
> -
> - if (handle < 0)
> - return handle;
> -#else
> - static int handle;
> -
> - /*
> -* FIXME: dirty hack to avoid re-using IDs, virglrenderer
> -* can't deal with that. Needs fixing in virglrenderer, also
> -* should figure a better way to handle that in the guest.
> -*/
> - handle++;
> -#endif
> -
> - *resid = handle + 1;
> + if (virtio_gpu_virglrenderer_workaround) {
> + /*
> +* Hack to avoid re-using resource IDs.
> +*
> +* virglrenderer versions up to (and including) 0.7.0
> +* can't deal with that. virglrenderer commit
> +* "f91a9dd35715 Fix unlinking resources from hash
> +* table." (Feb 2019) fixes the bug.
> +*/
> + static int handle;
> + handle++;
> + *resid = handle + 1;
> + } else {
> + int handle = ida_alloc(&vgdev->resource_ida, GFP_KERNEL);
> + if (handle < 0)
> + return handle;
> + *resid = handle + 1;
> + }
> return 0;
> }
>
> static void virtio_gpu_resource_id_put(struct virtio_gpu_device *vgdev,
> uint32_t id)
> {
> -#if 0
> - ida_free(&vgdev->resource_ida, id - 1);
> -#endif
> + if (!virtio_gpu_virglrenderer_workaround) {
> + ida_free(&vgdev->resource_ida, id - 1);
> + }
> }
>
> static void virtio_gpu_ttm_bo_destroy(struct ttm_buffer_object *tbo)
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/26] drm/dp_mst: Move link address dumping into a function
*sigh* finally have some time to go through these reviews
jfyi: I realized after looking over this patch that it's not actually needed -
I had been planning on using drm_dp_dump_link_address() for other things, but
ended up deciding to make the final plan to use something that dumps into a
format that's identical to the one we're using for dumping DOWN requests. IMHO
though, this patch does make things look nicer so I'll probably keep it.
Assuming I can still count your r-b as valid with a change to the commit
description?
On Thu, 2019-08-08 at 21:53 +0200, Daniel Vetter wrote:
> On Wed, Jul 17, 2019 at 09:42:24PM -0400, Lyude Paul wrote:
> > Since we're about to be calling this from multiple places. Also it makes
> > things easier to read!
> >
> > Cc: Juston Li
> > Cc: Imre Deak
> > Cc: Ville Syrjälä
> > Cc: Harry Wentland
> > Signed-off-by: Lyude Paul
>
> Reviewed-by: Daniel Vetter
>
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 35 ++-
> > 1 file changed, 23 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 0984b9a34d55..998081b9b205 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -2013,6 +2013,28 @@ static void drm_dp_queue_down_tx(struct
> > drm_dp_mst_topology_mgr *mgr,
> > mutex_unlock(&mgr->qlock);
> > }
> >
> > +static void
> > +drm_dp_dump_link_address(struct drm_dp_link_address_ack_reply *reply)
> > +{
> > + struct drm_dp_link_addr_reply_port *port_reply;
> > + int i;
> > +
> > + for (i = 0; i < reply->nports; i++) {
> > + port_reply = &reply->ports[i];
> > + DRM_DEBUG_KMS("port %d: input %d, pdt: %d, pn: %d, dpcd_rev:
> > %02x, mcs: %d, ddps: %d, ldps %d, sdp %d/%d\n",
> > + i,
> > + port_reply->input_port,
> > + port_reply->peer_device_type,
> > + port_reply->port_number,
> > + port_reply->dpcd_revision,
> > + port_reply->mcs,
> > + port_reply->ddps,
> > + port_reply->legacy_device_plug_status,
> > + port_reply->num_sdp_streams,
> > + port_reply->num_sdp_stream_sinks);
> > + }
> > +}
> > +
> > static void drm_dp_send_link_address(struct drm_dp_mst_topology_mgr *mgr,
> > struct drm_dp_mst_branch *mstb)
> > {
> > @@ -2038,18 +2060,7 @@ static void drm_dp_send_link_address(struct
> > drm_dp_mst_topology_mgr *mgr,
> > DRM_DEBUG_KMS("link address nak received\n");
> > } else {
> > DRM_DEBUG_KMS("link address reply: %d\n", txmsg-
> > >reply.u.link_addr.nports);
> > - for (i = 0; i < txmsg->reply.u.link_addr.nports; i++)
> > {
> > - DRM_DEBUG_KMS("port %d: input %d, pdt: %d, pn:
> > %d, dpcd_rev: %02x, mcs: %d, ddps: %d, ldps %d, sdp %d/%d\n", i,
> > - txmsg-
> > >reply.u.link_addr.ports[i].input_port,
> > - txmsg-
> > >reply.u.link_addr.ports[i].peer_device_type,
> > - txmsg-
> > >reply.u.link_addr.ports[i].port_number,
> > - txmsg-
> > >reply.u.link_addr.ports[i].dpcd_revision,
> > - txmsg->reply.u.link_addr.ports[i].mcs,
> > - txmsg->reply.u.link_addr.ports[i].ddps,
> > - txmsg-
> > >reply.u.link_addr.ports[i].legacy_device_plug_status,
> > - txmsg-
> > >reply.u.link_addr.ports[i].num_sdp_streams,
> > - txmsg-
> > >reply.u.link_addr.ports[i].num_sdp_stream_sinks);
> > - }
> > + drm_dp_dump_link_address(&txmsg->reply.u.link_addr);
> >
> > drm_dp_check_mstb_guid(mstb, txmsg-
> > >reply.u.link_addr.guid);
> >
> > --
> > 2.21.0
> >
--
Cheers,
Lyude Paul
[Bug 110865] Rx480 consumes 20w more power in idle than under Windows
https://bugs.freedesktop.org/show_bug.cgi?id=110865 --- Comment #22 from Dieter Nützel --- Hello Alex and Martin, I've tried both on my Polaris 20, RX580 8 GB Sapphire Technology Limited Nitro+ Radeon RX 580 - v2 patched into amd-staging-drm-next (before inclusion of v3) - v3 with amd-staging-drm-next https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=ca82748783d8189a54a85f2ea1c2710182ba6138 Both flicker with green/black (?) horizontally lines over both screens. Mostly during power level switch. For example during mouse movement/interaction (wheel) and mouse pointer traverse from konsole/etc. to desktop (KDE5 Plasma 5.xx, here). UVD load (mplayer etc.) is not enough to fix it. E.g. radv (vkcube) not. But other gfx load (vkmark/glmark2, etc.). When there is lower gfx demand during the above tests (glmark2 -b buffer) the flicker came up, again. Martin's observation [-] If i do "echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level" the flickering stops. So the flickering is caused by the automatic powermanagement / reclocking. [-] Works here, too (tested with v3). But I never could go below ~32 W !!! Tested with both Nitro+ BIOS modes. The PSTATE_ wouldn't change on my card. They stay @ 600/1000 all the time!? GFX Clocks and Power: 300 MHz (MCLK) 300 MHz (SCLK) 600 MHz (PSTATE_SCLK) 1000 MHz (PSTATE_MCLK) 750 mV (VDDGFX) 32.76 W (average GPU) GPU Temperature: 31 C GPU Load: 0 % MEM Load: 3 % Any hints? And sorry for my bad English this time - my best friend from beginning of German Gymnasium died after 6 years of fight against cancer. He aged only 52. Leaving a wife and two little girls... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/5] MST DSC support in drm-mst
On 2019-08-26 3:50 p.m., Dave Airlie wrote: > On Sat, 24 Aug 2019 at 06:24, Francis, David wrote: >> >> Adding DSC functionality to drm_dp_mst_atomic_check() is a good idea. >> However, until amdgpu switches over to that system, I wouldn't be able >> to test those changes. Making that switch is on our TODO list, and it would >> fix a number of problems with our current MST implementation, but >> it's going to be a major rewrite. >> >> MST DSC hardware is already on the market. It would be expedient to >> merge the patches we need for Navi support sooner and update >> drm_dp_mst_atomic_check when we're able to test it. > > Is there any commitment to rewriting it, a timeline or anything? > > The problem with this situation is there is always new hardware coming > onto the market, and there is always pressure to support all the > features of that new hardware, and the pressure always comes like this > and being expedient. However I've found that a lot of the time the > required refactor or work is never done, because the time is being > allocated now to the next GPU that is coming on the market, and nobody > ever cares enough to clean up their technical debt. > > How come the needs for MST DSC support wasn't identified earlier, > blocked on refactoring of the code to use common code, and then that > task made a higher priority? > drm_dp_mst_atomic_check was introduced by Lyude back in January with https://patchwork.freedesktop.org/patch/276405/ as part of https://patchwork.freedesktop.org/series/54031/ At the time Lyude updated i915 and nouveau to use these helpers. amdgpu wasn't updated. > I'm sorta inclined to say no we shouldn't be merging any driver > specific code here, because this is the only point we can push > pressure on to refactor the MST implementation, which I guess > otherwise we'll just keep avoiding until Lyude ends up doing it for > you. > That's fair. I agree that the refactor should be done and I understand where you're coming from. Since David is heading back to school in less than a week I was inclined to see if we can push back a little so he can get his change in. Other than that I don't mind holding off on the merge unless the refactor is done. Adding Mikita who'll pick up DSC stuff from David and will iterate on these patches if necessary and look at the MST refactor. Thanks for keeping us honest. Harry > Dave. > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 5/6] drm/dp_mst: Add new quirk for Synaptics MST hubs
On 2019-08-26 3:14 p.m., Francis, David wrote:
> On 2019-08-26 2:05 p.m., David Francis wrote:
>>> Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
>>> support virtual DPCD registers, but do support DSC.
>>> The DSC caps can be read from the physical aux,
>>> like in SST DSC. These hubs have many different
>>> DEVICE_IDs. Add a new quirk to detect this case.
>>>
>>> Cc: Lyude Paul
>>> Cc: Jani Nikula
>>> Signed-off-by: David Francis
>>> ---
>>> drivers/gpu/drm/drm_dp_helper.c | 2 ++
>>> include/drm/drm_dp_helper.h | 7 +++
>>> 2 files changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>>> b/drivers/gpu/drm/drm_dp_helper.c
>>> index 2cc21eff4cf3..fc39323e7d52 100644
>>> --- a/drivers/gpu/drm/drm_dp_helper.c
>>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>>> @@ -1270,6 +1270,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
>>>{ OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false,
>>> BIT(DP_DPCD_QUIRK_NO_PSR) },
>>>/* CH7511 seems to leave SINK_COUNT zeroed */
>>>{ OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'),
>>> false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
>>> + /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
>>> + { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
>>> BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
>>
>> This seems to be generic OUI for Synaptics [1]. Could this cause us to
>> cast the net too wide?
>>
>> Even if we check that it's DP_DPCD_REV >= 1.4 there's a good chance
>> Synaptics is fixing this in the future and won't require the quirk.
>>
>> [1] https://aruljohn.com/mac/vendor/Synaptics
>>
>>
>> Harry
>
> It's not pretty, but
> - Currently the net of "all Synaptics devices with rev>DP1.4" catches every
> device we care about and none we don't
> - If a future Synaptics device supports virtual DPCD properly, we will check
> for that first and never resort to the workaround (see patch 6/6)
> - We don't know any of the properties of any hypothetical future Synaptics
> hardware, so we can't create cases for them now
>
That's fair enough. Thanks for the explanation.
Reviewed-by: Harry Wentland
Harry
> Also, received offline review from AMD MST DSC (Non-Linux) expert Wenjing
> Liu, giving me permission o mark this patch
> Reviewed-by: Wenjing Liu
>
>>
>>> };
>>>
>>> #undef OUI
>>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>>> index 8364502f92cf..a1331b08705f 100644
>>> --- a/include/drm/drm_dp_helper.h
>>> +++ b/include/drm/drm_dp_helper.h
>>> @@ -1434,6 +1434,13 @@ enum drm_dp_quirk {
>>> * The driver should ignore SINK_COUNT during detection.
>>> */
>>>DP_DPCD_QUIRK_NO_SINK_COUNT,
>>> + /**
>>> + * @DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD:
>>> + *
>>> + * The device supports MST DSC despite not supporting Virtual DPCD.
>>> + * The DSC caps can be read from the physical aux instead.
>>> + */
>>> + DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD,
>>> };
>>>
>>> /**
>
>
> From: Wentland, Harry
> Sent: August 26, 2019 3:05 PM
> To: Francis, David; dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH v8 5/6] drm/dp_mst: Add new quirk for Synaptics MST hubs
>
> On 2019-08-26 2:05 p.m., David Francis wrote:
>> Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
>> support virtual DPCD registers, but do support DSC.
>> The DSC caps can be read from the physical aux,
>> like in SST DSC. These hubs have many different
>> DEVICE_IDs. Add a new quirk to detect this case.
>>
>> Cc: Lyude Paul
>> Cc: Jani Nikula
>> Signed-off-by: David Francis
>> ---
>> drivers/gpu/drm/drm_dp_helper.c | 2 ++
>> include/drm/drm_dp_helper.h | 7 +++
>> 2 files changed, 9 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 2cc21eff4cf3..fc39323e7d52 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -1270,6 +1270,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
>> { OUI(0x00, 0x10, 0xfa), DEVICE_ID_ANY, false,
>> BIT(DP_DPCD_QUIRK_NO_PSR) },
>> /* CH7511 seems to leave SINK_COUNT zeroed */
>> { OUI(0x00, 0x00, 0x00), DEVICE_ID('C', 'H', '7', '5', '1', '1'),
>> false, BIT(DP_DPCD_QUIRK_NO_SINK_COUNT) },
>> + /* Synaptics DP1.4 MST hubs can support DSC without virtual DPCD */
>> + { OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
>> BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
>
> This seems to be generic OUI for Synaptics [1]. Could this cause us to
> cast the net too wide?
>
> Even if we check that it's DP_DPCD_REV >= 1.4 there's a good chance
> Synaptics is fixing this in the future and won't require the quirk.
>
> [1] https://aruljohn.com/mac/vendor/Synaptics
>
> Harry
>
>> };
>>
>> #undef OUI
>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>> index 8364502f92cf..a1331b08705f 100644
>> --- a/include/d
Re: [PATCH v8 6/6] drm/dp_mst: Add helpers for MST DSC and virtual DPCD aux
On 2019-08-26 2:05 p.m., David Francis wrote:
> Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
> register might have to be written on the leaf port's DPCD,
> its parent's DPCD, or the MST manager's DPCD. This function
> finds the correct aux for the job.
>
> As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual DPCD
> is a DP feature new in DP v1.4, which exposes certain DPCD
> registers on virtual ports.
>
> v2: Remember to unlock mutex on all paths
>
> Cc: Lyude Paul
> Cc: Jani Nikula
> Signed-off-by: David Francis
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 152 ++
> include/drm/drm_dp_mst_helper.h | 2 +
> 2 files changed, 154 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 502923c24450..1fee92bd51f7 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4150,3 +4150,155 @@ static void drm_dp_mst_unregister_i2c_bus(struct
> drm_dp_aux *aux)
> {
> i2c_del_adapter(&aux->ddc);
> }
> +
> +/**
> + * drm_dp_mst_is_virtual_dpcd() - Is the given port a virtual DP Peer Device
> + * @port: The port to check
> + *
> + * A single physical MST hub object can be represented in the topology
> + * by multiple branches, with virtual ports between those branches.
> + *
> + * As of DP1.4, An MST hub with internal (virtual) ports must expose
> + * certain DPCD registers over those ports. See sections 2.6.1.1.1
> + * and 2.6.1.1.2 of Display Port specification v1.4 for details.
> + *
I've briefly perused these sections and they seem quite vague. What we
have here is probably a reasonable implementation, though.
Might be worthwhile to mention that the spec is not very clear on this
and that this is the best interpretation we have.
> + * May acquire mgr->lock
> + *
> + * Returns:
> + * true if the port is a virtual DP peer device, false otherwise
> + */
> +static bool drm_dp_mst_is_virtual_dpcd(struct drm_dp_mst_port *port)
> +{
> + struct drm_dp_mst_port *downstream_port;
> +
> + if (!port)
> + return false;
> +
Can we early return with false if dpcd_rev < DP_DPCD_REV_14 rather than
check this in each if statement below?
> + /* Virtual DP Sink (Internal Display Panel) */
> + if (port->port_num >= 8 && port->dpcd_rev >= DP_DPCD_REV_14)
> + return true;
> +
> + /* DP-to-HDMI Protocol Converter */
> + if (port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV &&
> + !port->mcs &&
> + port->ldps &&
> + port->dpcd_rev >= DP_DPCD_REV_14)
> + return true;
> +
> + /* DP-to-DP */
> + mutex_lock(&port->mgr->lock);
> + if (port->pdt == DP_PEER_DEVICE_MST_BRANCHING &&
> + port->mstb &&
> + port->dpcd_rev >= DP_DPCD_REV_14 &&
> + port->mstb->num_ports == 2) {
Is 'num_ports == 2' required? Maybe I don't follow this bit...
> + list_for_each_entry(downstream_port, &port->mstb->ports, next) {
> + if (downstream_port->pdt == DP_PEER_DEVICE_SST_SINK &&
> + !downstream_port->input) {
> + mutex_unlock(&port->mgr->lock);
> + return true;
> + }
> + }
> + }
> + mutex_unlock(&port->mgr->lock);
> +
> + return false;
> +}
> +
> +/**
> + * drm_dp_mst_dsc_aux_for_port() - Find the correct aux for DSC
> + * @port: The port to check. A leaf of the MST tree with an attached display.
> + *
> + * Depending on the situation, DSC may be enabled via the endpoint aux,
> + * the immediately upstream aux, or the connector's physical aux.
> + *
> + * This is both the correct aux to read DSC_CAPABILITY and the
> + * correct aux to write DSC_ENABLED.
> + *
> + * This operation can be expensive (up to four aux reads), so
> + * the caller should cache the return.
> + *
> + * Returns:
> + * NULL if DSC cannot be enabled on this port, otherwise the aux device
> + */
> +struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port *port)
> +{
> + struct drm_dp_mst_port *immediate_upstream_port;
> + struct drm_dp_mst_port *fec_port;
> + struct drm_dp_desc *desc = NULL;
> +
Might be good to early return if !port to avoid proceeding through the
entire function if this is called without a port.
> + if (port && port->parent)
> + immediate_upstream_port = port->parent->port_parent;
> + else
> + immediate_upstream_port = NULL;
> +
> + fec_port = immediate_upstream_port;
> + while (fec_port) {
> + /*
> + * Each physical link (i.e. not a virtual port) between the
> + * output and the primary device must support FEC
> + */
> + if (!drm_dp_mst_is_virtual_dpcd(fec_port) &&
> + !fec_port->fec_c
[Bug 111492] HDMI audio is unavailable with amdgpu on R9 270
https://bugs.freedesktop.org/show_bug.cgi?id=111492 --- Comment #1 from Marti Raudsepp --- Oh and I'm using HDMI output for video, which works fine. Unplugging and re-plugging the HDMI cable does not help. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 6/6] drm/dp_mst: Add helpers for MST DSC and virtual DPCD aux
Please fix the indenting on this. I've mentioned this already in my previous
reviews.
On Mon, 2019-08-26 at 19:16 +, Francis, David wrote:
> Received offline review from AMD MST DSC (Non-Linux) expert Wenjing Liu,
> giving me permission to mark this patch
> Reviewed-by: Wenjing Liu
>
>
> From: David Francis
> Sent: August 26, 2019 2:05 PM
> To: dri-devel@lists.freedesktop.org
> Cc: Francis, David; Lyude Paul; Jani Nikula
> Subject: [PATCH v8 6/6] drm/dp_mst: Add helpers for MST DSC and virtual DPCD
> aux
>
> Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
> register might have to be written on the leaf port's DPCD,
> its parent's DPCD, or the MST manager's DPCD. This function
> finds the correct aux for the job.
>
> As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual DPCD
> is a DP feature new in DP v1.4, which exposes certain DPCD
> registers on virtual ports.
>
> v2: Remember to unlock mutex on all paths
>
> Cc: Lyude Paul
> Cc: Jani Nikula
> Signed-off-by: David Francis
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 152 ++
> include/drm/drm_dp_mst_helper.h | 2 +
> 2 files changed, 154 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 502923c24450..1fee92bd51f7 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4150,3 +4150,155 @@ static void drm_dp_mst_unregister_i2c_bus(struct
> drm_dp_aux *aux)
> {
> i2c_del_adapter(&aux->ddc);
> }
> +
> +/**
> + * drm_dp_mst_is_virtual_dpcd() - Is the given port a virtual DP Peer
> Device
> + * @port: The port to check
> + *
> + * A single physical MST hub object can be represented in the topology
> + * by multiple branches, with virtual ports between those branches.
> + *
> + * As of DP1.4, An MST hub with internal (virtual) ports must expose
> + * certain DPCD registers over those ports. See sections 2.6.1.1.1
> + * and 2.6.1.1.2 of Display Port specification v1.4 for details.
> + *
> + * May acquire mgr->lock
> + *
> + * Returns:
> + * true if the port is a virtual DP peer device, false otherwise
> + */
> +static bool drm_dp_mst_is_virtual_dpcd(struct drm_dp_mst_port *port)
> +{
> + struct drm_dp_mst_port *downstream_port;
> +
> + if (!port)
> + return false;
> +
> + /* Virtual DP Sink (Internal Display Panel) */
> + if (port->port_num >= 8 && port->dpcd_rev >= DP_DPCD_REV_14)
> + return true;
> +
> + /* DP-to-HDMI Protocol Converter */
> + if (port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV &&
> + !port->mcs &&
> + port->ldps &&
> + port->dpcd_rev >= DP_DPCD_REV_14)
> + return true;
> +
> + /* DP-to-DP */
> + mutex_lock(&port->mgr->lock);
> + if (port->pdt == DP_PEER_DEVICE_MST_BRANCHING &&
> + port->mstb &&
> + port->dpcd_rev >= DP_DPCD_REV_14 &&
> + port->mstb->num_ports == 2) {
> + list_for_each_entry(downstream_port, &port->mstb->ports,
> next) {
> + if (downstream_port->pdt == DP_PEER_DEVICE_SST_SINK
> &&
> + !downstream_port->input) {
> + mutex_unlock(&port->mgr->lock);
> + return true;
> + }
> + }
> + }
> + mutex_unlock(&port->mgr->lock);
> +
> + return false;
> +}
> +
> +/**
> + * drm_dp_mst_dsc_aux_for_port() - Find the correct aux for DSC
> + * @port: The port to check. A leaf of the MST tree with an attached
> display.
> + *
> + * Depending on the situation, DSC may be enabled via the endpoint aux,
> + * the immediately upstream aux, or the connector's physical aux.
> + *
> + * This is both the correct aux to read DSC_CAPABILITY and the
> + * correct aux to write DSC_ENABLED.
> + *
> + * This operation can be expensive (up to four aux reads), so
> + * the caller should cache the return.
> + *
> + * Returns:
> + * NULL if DSC cannot be enabled on this port, otherwise the aux device
> + */
> +struct drm_dp_aux *drm_dp_mst_dsc_aux_for_port(struct drm_dp_mst_port
> *port)
> +{
> + struct drm_dp_mst_port *immediate_upstream_port;
> + struct drm_dp_mst_port *fec_port;
> + struct drm_dp_desc *desc = NULL;
> +
> + if (port && port->parent)
> + immediate_upstream_port = port->parent->port_parent;
> + else
> + immediate_upstream_port = NULL;
> +
> + fec_port = immediate_upstream_port;
> + while (fec_port) {
> + /*
> +* Each physical link (i.e. not a virtual port) between the
> +* output and the primary device must support FEC
> +*/
> + if (!drm_dp_mst_is_virtual_dpcd(fec_p
[PATCH 0/5] mmu notifer debug annotations
Hi all, Next round. Changes: - I kept the two lockdep annotations patches since when I rebased this before retesting linux-next didn't yet have them. Otherwise unchanged except for a trivial conflict. - Ack from Peter Z. on the kernel.h patch. - Added annotations for non_block to invalidate_range_end. I can't test that readily since i915 doesn't use it. - Added might_sleep annotations to also make sure the mm side keeps up it's side of the contract here around what's allowed and what's not. Comments, feedback, review as usual very much appreciated. Cheers, Daniel Daniel Vetter (5): mm, notifier: Add a lockdep map for invalidate_range_start/end mm, notifier: Prime lockdep kernel.h: Add non_block_start/end() mm, notifier: Catch sleeping/blocking for !blockable mm, notifier: annotate with might_sleep() include/linux/kernel.h | 25 - include/linux/mmu_notifier.h | 13 + include/linux/sched.h| 4 kernel/sched/core.c | 19 ++- mm/mmu_notifier.c| 31 +-- 5 files changed, 84 insertions(+), 8 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] mm, notifier: annotate with might_sleep()
Since mmu notifiers don't exist for more processes, but could block in
interesting places, add some annotations. This should help make sure
core mm keeps up its end of the mmu notifier contract.
The checks here are outside of all notifier checks because of that.
They compile away without CONFIG_DEBUG_ATOMIC_SLEEP.
Suggested by Jason.
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: Michal Hocko
Cc: David Rientjes
Cc: "Christian König"
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Signed-off-by: Daniel Vetter
---
include/linux/mmu_notifier.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 3f9829a1f32e..8b71813417e7 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -345,6 +345,8 @@ static inline void mmu_notifier_change_pte(struct mm_struct
*mm,
static inline void
mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range)
{
+ might_sleep();
+
lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
if (mm_has_notifiers(range->mm)) {
range->flags |= MMU_NOTIFIER_RANGE_BLOCKABLE;
@@ -368,6 +370,9 @@ mmu_notifier_invalidate_range_start_nonblock(struct
mmu_notifier_range *range)
static inline void
mmu_notifier_invalidate_range_end(struct mmu_notifier_range *range)
{
+ if (mmu_notifier_range_blockable(range))
+ might_sleep();
+
if (mm_has_notifiers(range->mm))
__mmu_notifier_invalidate_range_end(range, false);
}
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] mm, notifier: Prime lockdep
We want to teach lockdep that mmu notifiers can be called from direct
reclaim paths, since on many CI systems load might never reach that
level (e.g. when just running fuzzer or small functional tests).
Motivated by a discussion with Jason.
I've put the annotation into mmu_notifier_register since only when we
have mmu notifiers registered is there any point in teaching lockdep
about them. Also, we already have a kmalloc(, GFP_KERNEL), so this is
safe.
Cc: Jason Gunthorpe
Cc: Chris Wilson
Cc: Andrew Morton
Cc: David Rientjes
Cc: "Jérôme Glisse"
Cc: Michal Hocko
Cc: "Christian König"
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: Mike Rapoport
Cc: linux...@kvack.org
Reviewed-by: Jason Gunthorpe
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index d48d3b2abd68..0523555933c9 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -259,6 +259,13 @@ int __mmu_notifier_register(struct mmu_notifier *mn,
struct mm_struct *mm)
lockdep_assert_held_write(&mm->mmap_sem);
BUG_ON(atomic_read(&mm->mm_users) <= 0);
+ if (IS_ENABLED(CONFIG_LOCKDEP)) {
+ fs_reclaim_acquire(GFP_KERNEL);
+ lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
+ lock_map_release(&__mmu_notifier_invalidate_range_start_map);
+ fs_reclaim_release(GFP_KERNEL);
+ }
+
mn->mm = mm;
mn->users = 1;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] mm, notifier: Catch sleeping/blocking for !blockable
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch it.
I'm not sure whether this is the best way to make sure all the
might_sleep() callsites trigger, and it's a bit ugly in the code flow.
But it gets the job done.
Inspired by an i915 patch series which did exactly that, because the
rules haven't been entirely clear to us.
v2: Use the shiny new non_block_start/end annotations instead of
abusing preempt_disable/enable.
v3: Rebase on top of Glisse's arg rework.
v4: Rebase on top of more Glisse rework.
v5: Also annotate invalidate_range_end in the same style. I hope I got
Jason's request for this right.
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: Michal Hocko
Cc: David Rientjes
Cc: "Christian König"
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Reviewed-by: Christian König (v1)
Reviewed-by: Jérôme Glisse (v4)
Signed-off-by: Daniel Vetter
---
mm/mmu_notifier.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index 0523555933c9..b17f3fd3779b 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -181,7 +181,13 @@ int __mmu_notifier_invalidate_range_start(struct
mmu_notifier_range *range)
id = srcu_read_lock(&srcu);
hlist_for_each_entry_rcu(mn, &range->mm->mmu_notifier_mm->list, hlist) {
if (mn->ops->invalidate_range_start) {
- int _ret = mn->ops->invalidate_range_start(mn, range);
+ int _ret;
+
+ if (!mmu_notifier_range_blockable(range))
+ non_block_start();
+ _ret = mn->ops->invalidate_range_start(mn, range);
+ if (!mmu_notifier_range_blockable(range))
+ non_block_end();
if (_ret) {
pr_info("%pS callback failed with %d in
%sblockable context.\n",
mn->ops->invalidate_range_start, _ret,
@@ -224,8 +230,13 @@ void __mmu_notifier_invalidate_range_end(struct
mmu_notifier_range *range,
mn->ops->invalidate_range(mn, range->mm,
range->start,
range->end);
- if (mn->ops->invalidate_range_end)
+ if (mn->ops->invalidate_range_end) {
+ if (!mmu_notifier_range_blockable(range))
+ non_block_start();
mn->ops->invalidate_range_end(mn, range);
+ if (!mmu_notifier_range_blockable(range))
+ non_block_end();
+ }
}
srcu_read_unlock(&srcu, id);
lock_map_release(&__mmu_notifier_invalidate_range_start_map);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] kernel.h: Add non_block_start/end()
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not allowed to make sure there's forward progress. Quoting Michal:
"The notifier is called from quite a restricted context - oom_reaper -
which shouldn't depend on any locks or sleepable conditionals. The code
should be swift as well but we mostly do care about it to make a forward
progress. Checking for sleepable context is the best thing we could come
up with that would describe these demands at least partially."
Peter also asked whether we want to catch spinlocks on top, but Michal
said those are less of a problem because spinlocks can't have an
indirect dependency upon the page allocator and hence close the loop
with the oom reaper.
Suggested by Michal Hocko.
v2:
- Improve commit message (Michal)
- Also check in schedule, not just might_sleep (Peter)
v3: It works better when I actually squash in the fixup I had lying
around :-/
v4: Pick the suggestion from Andrew Morton to give non_block_start/end
some good kerneldoc comments. I added that other blocking calls like
wait_event pose similar issues, since that's the other example we
discussed.
Cc: Jason Gunthorpe
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Andrew Morton
Cc: Michal Hocko
Cc: David Rientjes
Cc: "Christian König"
Cc: Daniel Vetter
Cc: "Jérôme Glisse"
Cc: linux...@kvack.org
Cc: Masahiro Yamada
Cc: Wei Wang
Cc: Andy Shevchenko
Cc: Thomas Gleixner
Cc: Jann Horn
Cc: Feng Tang
Cc: Kees Cook
Cc: Randy Dunlap
Cc: linux-ker...@vger.kernel.org
Acked-by: Christian König (v1)
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Daniel Vetter
---
include/linux/kernel.h | 25 -
include/linux/sched.h | 4
kernel/sched/core.c| 19 ++-
3 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4fa360a13c1e..82f84cfe372f 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -217,7 +217,9 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
* might_sleep - annotation for functions that can sleep
*
* this macro will print a stack trace if it is executed in an atomic
- * context (spinlock, irq-handler, ...).
+ * context (spinlock, irq-handler, ...). Additional sections where blocking is
+ * not allowed can be annotated with non_block_start() and non_block_end()
+ * pairs.
*
* This is a useful debugging help to be able to catch problems early and not
* be bitten later when the calling function happens to sleep when it is not
@@ -233,6 +235,25 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
# define cant_sleep() \
do { __cant_sleep(__FILE__, __LINE__, 0); } while (0)
# define sched_annotate_sleep()(current->task_state_change = 0)
+/**
+ * non_block_start - annotate the start of section where sleeping is prohibited
+ *
+ * This is on behalf of the oom reaper, specifically when it is calling the mmu
+ * notifiers. The problem is that if the notifier were to block on, for
example,
+ * mutex_lock() and if the process which holds that mutex were to perform a
+ * sleeping memory allocation, the oom reaper is now blocked on completion of
+ * that memory allocation. Other blocking calls like wait_event() pose similar
+ * issues.
+ */
+# define non_block_start() \
+ do { current->non_block_count++; } while (0)
+/**
+ * non_block_end - annotate the end of section where sleeping is prohibited
+ *
+ * Closes a section opened by non_block_start().
+ */
+# define non_block_end() \
+ do { WARN_ON(current->non_block_count-- == 0); } while (0)
#else
static inline void ___might_sleep(const char *file, int line,
int preempt_offset) { }
@@ -241,6 +262,8 @@ extern void __cant_sleep(const char *file, int line, int
preempt_offset);
# define might_sleep() do { might_resched(); } while (0)
# define cant_sleep() do { } while (0)
# define sched_annotate_sleep() do { } while (0)
+# define non_block_start() do { } while (0)
+# define non_block_end() do { } while (0)
#endif
#define might_sleep_if(cond) do { if (cond) might_sleep(); } while (0)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index b6ec130dff9b..e8bb965f5019 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -980,6 +980,10 @@ struct task_struct {
struct mutex_waiter *blocked_on;
#endif
+#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
+ int non_block_count;
+#endif
+
#ifdef CONFIG_TRACE_IRQFLAGS
unsigned intirq_events;
unsigned long hardirq_enable_ip;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 45dceec209f4..0d01c7994a9a 1
[PATCH 1/5] mm, notifier: Add a lockdep map for invalidate_range_start/end
This is a similar idea to the fs_reclaim fake lockdep lock. It's
fairly easy to provoke a specific notifier to be run on a specific
range: Just prep it, and then munmap() it.
A bit harder, but still doable, is to provoke the mmu notifiers for
all the various callchains that might lead to them. But both at the
same time is really hard to reliable hit, especially when you want to
exercise paths like direct reclaim or compaction, where it's not
easy to control what exactly will be unmapped.
By introducing a lockdep map to tie them all together we allow lockdep
to see a lot more dependencies, without having to actually hit them
in a single challchain while testing.
On Jason's suggestion this is is rolled out for both
invalidate_range_start and invalidate_range_end. They both have the
same calling context, hence we can share the same lockdep map. Note
that the annotation for invalidate_ranage_start is outside of the
mm_has_notifiers(), to make sure lockdep is informed about all paths
leading to this context irrespective of whether mmu notifiers are
present for a given context. We don't do that on the
invalidate_range_end side to avoid paying the overhead twice, there
the lockdep annotation is pushed down behind the mm_has_notifiers()
check.
v2: Use lock_map_acquire/release() like fs_reclaim, to avoid confusion
with this being a real mutex (Chris Wilson).
v3: Rebase on top of Glisse's arg rework.
v4: Also annotate invalidate_range_end (Jason Gunthorpe)
Also annotate invalidate_range_start_nonblock, I somehow missed that
one in the first version.
Cc: Jason Gunthorpe
Cc: Chris Wilson
Cc: Andrew Morton
Cc: David Rientjes
Cc: "Jérôme Glisse"
Cc: Michal Hocko
Cc: "Christian König"
Cc: Greg Kroah-Hartman
Cc: Daniel Vetter
Cc: Mike Rapoport
Cc: linux...@kvack.org
Reviewed-by: Jason Gunthorpe
Signed-off-by: Daniel Vetter
---
include/linux/mmu_notifier.h | 8
mm/mmu_notifier.c| 9 +
2 files changed, 17 insertions(+)
diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
index 31aa971315a1..3f9829a1f32e 100644
--- a/include/linux/mmu_notifier.h
+++ b/include/linux/mmu_notifier.h
@@ -42,6 +42,10 @@ enum mmu_notifier_event {
#ifdef CONFIG_MMU_NOTIFIER
+#ifdef CONFIG_LOCKDEP
+extern struct lockdep_map __mmu_notifier_invalidate_range_start_map;
+#endif
+
/*
* The mmu notifier_mm structure is allocated and installed in
* mm->mmu_notifier_mm inside the mm_take_all_locks() protected
@@ -341,19 +345,23 @@ static inline void mmu_notifier_change_pte(struct
mm_struct *mm,
static inline void
mmu_notifier_invalidate_range_start(struct mmu_notifier_range *range)
{
+ lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
if (mm_has_notifiers(range->mm)) {
range->flags |= MMU_NOTIFIER_RANGE_BLOCKABLE;
__mmu_notifier_invalidate_range_start(range);
}
+ lock_map_release(&__mmu_notifier_invalidate_range_start_map);
}
static inline int
mmu_notifier_invalidate_range_start_nonblock(struct mmu_notifier_range *range)
{
+ lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
if (mm_has_notifiers(range->mm)) {
range->flags &= ~MMU_NOTIFIER_RANGE_BLOCKABLE;
return __mmu_notifier_invalidate_range_start(range);
}
+ lock_map_release(&__mmu_notifier_invalidate_range_start_map);
return 0;
}
diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
index d76ea27e2bbb..d48d3b2abd68 100644
--- a/mm/mmu_notifier.c
+++ b/mm/mmu_notifier.c
@@ -21,6 +21,13 @@
/* global SRCU for all MMs */
DEFINE_STATIC_SRCU(srcu);
+#ifdef CONFIG_LOCKDEP
+struct lockdep_map __mmu_notifier_invalidate_range_start_map = {
+ .name = "mmu_notifier_invalidate_range_start"
+};
+EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_start_map);
+#endif
+
/*
* This function allows mmu_notifier::release callback to delay a call to
* a function that will free appropriate resources. The function must be
@@ -197,6 +204,7 @@ void __mmu_notifier_invalidate_range_end(struct
mmu_notifier_range *range,
struct mmu_notifier *mn;
int id;
+ lock_map_acquire(&__mmu_notifier_invalidate_range_start_map);
id = srcu_read_lock(&srcu);
hlist_for_each_entry_rcu(mn, &range->mm->mmu_notifier_mm->list, hlist) {
/*
@@ -220,6 +228,7 @@ void __mmu_notifier_invalidate_range_end(struct
mmu_notifier_range *range,
mn->ops->invalidate_range_end(mn, range);
}
srcu_read_unlock(&srcu, id);
+ lock_map_release(&__mmu_notifier_invalidate_range_start_map);
}
EXPORT_SYMBOL_GPL(__mmu_notifier_invalidate_range_end);
--
2.23.0
Re: [PATCH v2 3/4] drm/vmwgfx: Update the backdoor call with support for new instructions
Acked-by: Dave Airlie (for merging via x86 trees). Dave. On Fri, 23 Aug 2019 at 18:13, Thomas Hellström (VMware) wrote: > > From: Thomas Hellstrom > > Use the definition provided by include/asm/vmware.h > > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: "H. Peter Anvin" > Cc: > Cc: > Signed-off-by: Thomas Hellstrom > Reviewed-by: Doug Covelli > --- > drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 21 + > drivers/gpu/drm/vmwgfx/vmwgfx_msg.h | 35 +++-- > 2 files changed, 28 insertions(+), 28 deletions(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c > index 81a86c3b77bc..1281e52898ee 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c > @@ -45,8 +45,6 @@ > #define RETRIES 3 > > #define VMW_HYPERVISOR_MAGIC0x564D5868 > -#define VMW_HYPERVISOR_PORT 0x5658 > -#define VMW_HYPERVISOR_HB_PORT 0x5659 > > #define VMW_PORT_CMD_MSG30 > #define VMW_PORT_CMD_HB_MSG 0 > @@ -92,7 +90,7 @@ static int vmw_open_channel(struct rpc_channel *channel, > unsigned int protocol) > > VMW_PORT(VMW_PORT_CMD_OPEN_CHANNEL, > (protocol | GUESTMSG_FLAG_COOKIE), si, di, > - VMW_HYPERVISOR_PORT, > + 0, > VMW_HYPERVISOR_MAGIC, > eax, ebx, ecx, edx, si, di); > > @@ -125,7 +123,7 @@ static int vmw_close_channel(struct rpc_channel *channel) > > VMW_PORT(VMW_PORT_CMD_CLOSE_CHANNEL, > 0, si, di, > - (VMW_HYPERVISOR_PORT | (channel->channel_id << 16)), > + channel->channel_id << 16, > VMW_HYPERVISOR_MAGIC, > eax, ebx, ecx, edx, si, di); > > @@ -159,7 +157,8 @@ static unsigned long vmw_port_hb_out(struct rpc_channel > *channel, > VMW_PORT_HB_OUT( > (MESSAGE_STATUS_SUCCESS << 16) | VMW_PORT_CMD_HB_MSG, > msg_len, si, di, > - VMW_HYPERVISOR_HB_PORT | (channel->channel_id << 16), > + VMWARE_HYPERVISOR_HB | (channel->channel_id << 16) | > + VMWARE_HYPERVISOR_OUT, > VMW_HYPERVISOR_MAGIC, bp, > eax, ebx, ecx, edx, si, di); > > @@ -180,7 +179,7 @@ static unsigned long vmw_port_hb_out(struct rpc_channel > *channel, > > VMW_PORT(VMW_PORT_CMD_MSG | (MSG_TYPE_SENDPAYLOAD << 16), > word, si, di, > -VMW_HYPERVISOR_PORT | (channel->channel_id << 16), > +channel->channel_id << 16, > VMW_HYPERVISOR_MAGIC, > eax, ebx, ecx, edx, si, di); > } > @@ -212,7 +211,7 @@ static unsigned long vmw_port_hb_in(struct rpc_channel > *channel, char *reply, > VMW_PORT_HB_IN( > (MESSAGE_STATUS_SUCCESS << 16) | VMW_PORT_CMD_HB_MSG, > reply_len, si, di, > - VMW_HYPERVISOR_HB_PORT | (channel->channel_id << 16), > + VMWARE_HYPERVISOR_HB | (channel->channel_id << 16), > VMW_HYPERVISOR_MAGIC, bp, > eax, ebx, ecx, edx, si, di); > > @@ -229,7 +228,7 @@ static unsigned long vmw_port_hb_in(struct rpc_channel > *channel, char *reply, > > VMW_PORT(VMW_PORT_CMD_MSG | (MSG_TYPE_RECVPAYLOAD << 16), > MESSAGE_STATUS_SUCCESS, si, di, > -VMW_HYPERVISOR_PORT | (channel->channel_id << 16), > +channel->channel_id << 16, > VMW_HYPERVISOR_MAGIC, > eax, ebx, ecx, edx, si, di); > > @@ -268,7 +267,7 @@ static int vmw_send_msg(struct rpc_channel *channel, > const char *msg) > > VMW_PORT(VMW_PORT_CMD_SENDSIZE, > msg_len, si, di, > - VMW_HYPERVISOR_PORT | (channel->channel_id << 16), > + channel->channel_id << 16, > VMW_HYPERVISOR_MAGIC, > eax, ebx, ecx, edx, si, di); > > @@ -326,7 +325,7 @@ static int vmw_recv_msg(struct rpc_channel *channel, void > **msg, > > VMW_PORT(VMW_PORT_CMD_RECVSIZE, > 0, si, di, > - (VMW_HYPERVISOR_PORT | (channel->channel_id << 16)), > + channel->channel_id << 16, > VMW_HYPERVISOR_MAGIC, > eax, ebx, ecx, edx, si, di); > > @@ -370,7 +369,7 @@ static int vmw_recv_msg(struct rpc_channel *channel, void > **msg, > > VMW_PORT(VMW_PORT_CMD_RECVSTATUS, > MESSAGE_STATUS_SUCCESS, si, di, > - (VMW_HYPERVISOR_PORT | (channel->channel_id << 16)), > + channel->channel_id << 16, >
[Bug 107835] DisplayPort audio stopped working in a kernel upgrade
https://bugs.freedesktop.org/show_bug.cgi?id=107835 --- Comment #3 from Marti Raudsepp --- Thanks Alex, reported new bug 111492. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mcde: Fix an error handling path in 'mcde_probe()'
On Thu, Aug 22, 2019 at 11:15 PM Christophe JAILLET
wrote:
> If we don't find any matching components, we should go through the error
> handling path, in order to free some resources.
>
> Fixes: ca5be902a87d ("drm/mcde: Fix uninitialized variable")
> Signed-off-by: Christophe JAILLET
Patch applied!
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111492] HDMI audio is unavailable with amdgpu on R9 270
https://bugs.freedesktop.org/show_bug.cgi?id=111492 Bug ID: 111492 Summary: HDMI audio is unavailable with amdgpu on R9 270 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: not set Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: ma...@juffo.org Video card: ASUS Radeon R9 270 Kernel: 5.2.9-arch1-1-ARCH I recently had some issues with the "radeon" driver and discovered that the "amdgpu" driver now has support for Southern Islands (SI) GPUs using the amdgpu.si_support=1 boot flag. Graphics stuff works great with amdgpu so far, however, all HDMI audio outputs are marked as "(unplugged) (unavailable)" in the pavuctl utility. Someone else's screenshot with similar issue: https://i.imgur.com/67HYPG3.png Initially this issue seemed related to bug 107835, but Alex Deucher said that's not the case. alsa-info.sh debug dump uploaded to: http://alsa-project.org/db/?f=bd09f9bd5cdadc129852d2f4487aec9f22d9b915 There is nothing in kernel logs to indicate issues. Grepping for relevant keywords in dmesg gives this: [0.145413] Kernel command line: initrd=\initramfs-linux.img root=UUID=93067a3f-2c68-4e1a-9f3a-96cdc0221771 rw acpi_enforce_resources=lax iommu=pt radeon.si_support=0 amdgpu.si_support=1 amdgpu.dc=1 radeon.audio=1 ... [3.910423] input: HDA ATI HDMI HDMI/DP,pcm=3 as /devices/pci:00/:00:03.1/:09:00.1/sound/card0/input4 [3.910454] input: HDA ATI HDMI HDMI/DP,pcm=7 as /devices/pci:00/:00:03.1/:09:00.1/sound/card0/input5 [3.910480] input: HDA ATI HDMI HDMI/DP,pcm=8 as /devices/pci:00/:00:03.1/:09:00.1/sound/card0/input6 [3.910513] input: HDA ATI HDMI HDMI/DP,pcm=9 as /devices/pci:00/:00:03.1/:09:00.1/sound/card0/input7 [3.910547] input: HDA ATI HDMI HDMI/DP,pcm=10 as /devices/pci:00/:00:03.1/:09:00.1/sound/card0/input8 [3.910579] input: HDA ATI HDMI HDMI/DP,pcm=11 as /devices/pci:00/:00:03.1/:09:00.1/sound/card0/input9 ... [4.110170] [drm] amdgpu kernel modesetting enabled. [4.110310] amdgpu :09:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xe000 -> 0xefff [4.110312] amdgpu :09:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xfcf0 -> 0xfcf3 [4.110313] amdgpu :09:00.0: vgaarb: deactivate vga console [4.110485] amdgpu :09:00.0: kfd not supported on this ASIC [4.120150] amdgpu :09:00.0: No more image in the PCI ROM [4.121491] amdgpu :09:00.0: VRAM: 2048M 0x00F4 - 0x00F47FFF (2048M used) [4.121492] amdgpu :09:00.0: GART: 1024M 0x00FF - 0x00FF3FFF [4.121557] [drm] amdgpu: 2048M of VRAM memory ready [4.121560] [drm] amdgpu: 3072M of GTT memory ready. [4.123745] amdgpu :09:00.0: PCIE GART of 1024M enabled (table at 0x00F40030). [4.124929] [drm] amdgpu: dpm initialized [4.125034] [drm] AMDGPU Display Connectors [4.502455] fbcon: amdgpudrmfb (fb0) is primary device [4.779046] amdgpu :09:00.0: fb0: amdgpudrmfb frame buffer device [5.237526] [drm] Initialized amdgpu 3.32.0 20150101 for :09:00.0 on minor 0 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] Add possibility to specify the number of displayed logos
Hi! The first patch fixes the fact that there are two items numbered "4" in the list of fbcon options. This bug is a teenager... The second patch extends that list with a new option that allows the user to display any number of logos (that fits on the screen). I need it to limit the display to only one logo instead of one for each CPU core. Changes since v1 - do not needlessly export fb_logo_count [Matthew Wilcox] - added patch 3/3, which removes the export of fb_center_logo Cheers, Peter Peter Rosin (3): fbdev: fix numbering of fbcon options fbdev: fbmem: allow overriding the number of bootup logos fbdev: fbmem: avoid exporting fb_center_logo Documentation/fb/fbcon.rst | 13 + drivers/video/fbdev/core/fbcon.c | 7 +++ drivers/video/fbdev/core/fbmem.c | 5 +++-- include/linux/fb.h | 1 + 4 files changed, 20 insertions(+), 6 deletions(-) -- 2.11.0
[PATCH v2 3/3] fbdev: fbmem: avoid exporting fb_center_logo
The variable is only ever used from fbcon.c which is linked into the same module. Therefore, the export is not needed. Signed-off-by: Peter Rosin --- drivers/video/fbdev/core/fbmem.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c index a7d8022db516..17e250a515b0 100644 --- a/drivers/video/fbdev/core/fbmem.c +++ b/drivers/video/fbdev/core/fbmem.c @@ -54,7 +54,6 @@ int num_registered_fb __read_mostly; EXPORT_SYMBOL(num_registered_fb); bool fb_center_logo __read_mostly; -EXPORT_SYMBOL(fb_center_logo); unsigned int fb_logo_count __read_mostly; -- 2.11.0
[PATCH v2 2/3] fbdev: fbmem: allow overriding the number of bootup logos
Probably most useful if you only want one logo regardless of how many
CPU cores you have.
Signed-off-by: Peter Rosin
---
Documentation/fb/fbcon.rst | 5 +
drivers/video/fbdev/core/fbcon.c | 7 +++
drivers/video/fbdev/core/fbmem.c | 4 +++-
include/linux/fb.h | 1 +
4 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/Documentation/fb/fbcon.rst b/Documentation/fb/fbcon.rst
index 65ba40255137..9f0b399d8d4e 100644
--- a/Documentation/fb/fbcon.rst
+++ b/Documentation/fb/fbcon.rst
@@ -174,6 +174,11 @@ C. Boot options
displayed due to multiple CPUs, the collected line of logos is moved
as a whole.
+9. fbcon=logo-count:
+
+ The value 'n' overrides the number of bootup logos. Zero gives the
+ default, which is the number of online cpus.
+
C. Attaching, Detaching and Unloading
Before going on to how to attach, detach and unload the framebuffer console, an
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index c9235a2f42f8..be4bc5540aad 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -536,6 +536,13 @@ static int __init fb_console_setup(char *this_opt)
fb_center_logo = true;
continue;
}
+
+ if (!strncmp(options, "logo-count:", 11)) {
+ options += 11;
+ if (*options)
+ fb_logo_count = simple_strtoul(options,
&options, 0);
+ continue;
+ }
}
return 1;
}
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 64dd732021d8..a7d8022db516 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -56,6 +56,8 @@ EXPORT_SYMBOL(num_registered_fb);
bool fb_center_logo __read_mostly;
EXPORT_SYMBOL(fb_center_logo);
+unsigned int fb_logo_count __read_mostly;
+
static struct fb_info *get_fb_info(unsigned int idx)
{
struct fb_info *fb_info;
@@ -689,7 +691,7 @@ int fb_show_logo(struct fb_info *info, int rotate)
int y;
y = fb_show_logo_line(info, rotate, fb_logo.logo, 0,
- num_online_cpus());
+ fb_logo_count ?: num_online_cpus());
y = fb_show_extra_logos(info, y, rotate);
return y;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 303771264644..5f2b05406262 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -630,6 +630,7 @@ extern int fb_new_modelist(struct fb_info *info);
extern struct fb_info *registered_fb[FB_MAX];
extern int num_registered_fb;
extern bool fb_center_logo;
+extern unsigned int fb_logo_count;
extern struct class *fb_class;
#define for_each_registered_fb(i) \
--
2.11.0
[PATCH v2 1/3] fbdev: fix numbering of fbcon options
Three shall be the number thou shalt count, and the number of the
counting shall be three. Four shalt thou not count...
One! Two! Five!
Fixes: efb985f6b265 ("[PATCH] fbcon: Console Rotation - Add framebuffer console
documentation")
Signed-off-by: Peter Rosin
---
Documentation/fb/fbcon.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/fb/fbcon.rst b/Documentation/fb/fbcon.rst
index ebca41785abe..65ba40255137 100644
--- a/Documentation/fb/fbcon.rst
+++ b/Documentation/fb/fbcon.rst
@@ -127,7 +127,7 @@ C. Boot options
is typically located on the same video card. Thus, the consoles that
are controlled by the VGA console will be garbled.
-4. fbcon=rotate:
+5. fbcon=rotate:
This option changes the orientation angle of the console display. The
value 'n' accepts the following:
@@ -152,21 +152,21 @@ C. Boot options
Actually, the underlying fb driver is totally ignorant of console
rotation.
-5. fbcon=margin:
+6. fbcon=margin:
This option specifies the color of the margins. The margins are the
leftover area at the right and the bottom of the screen that are not
used by text. By default, this area will be black. The 'color' value
is an integer number that depends on the framebuffer driver being used.
-6. fbcon=nodefer
+7. fbcon=nodefer
If the kernel is compiled with deferred fbcon takeover support, normally
the framebuffer contents, left in place by the firmware/bootloader, will
be preserved until there actually is some text is output to the console.
This option causes fbcon to bind immediately to the fbdev device.
-7. fbcon=logo-pos:
+8. fbcon=logo-pos:
The only possible 'location' is 'center' (without quotes), and when
given, the bootup logo is moved from the default top-left corner
--
2.11.0
[Bug 111491] missing 32 bits multiarch in the openSUSE Leap 15.1 AMDGpu-pro 19.30
https://bugs.freedesktop.org/show_bug.cgi?id=111491 alexandr changed: What|Removed |Added Summary|missing 32 bits multiarch |missing 32 bits multiarch |in the openSUSE Leap 15.1 |in the openSUSE Leap 15.1 |AMDGpu 19.30|AMDGpu-pro 19.30 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111491] missing 32 bits multiarch in the openSUSE Leap 15.1 AMDGpu 19.30
https://bugs.freedesktop.org/show_bug.cgi?id=111491 Bug ID: 111491 Summary: missing 32 bits multiarch in the openSUSE Leap 15.1 AMDGpu 19.30 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: not set Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: sashbo...@gmail.com Hi guys! You forgot to put multiarch support in the installer -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/5] MST DSC support in drm-mst
On Sat, 24 Aug 2019 at 06:24, Francis, David wrote: > > Adding DSC functionality to drm_dp_mst_atomic_check() is a good idea. > However, until amdgpu switches over to that system, I wouldn't be able > to test those changes. Making that switch is on our TODO list, and it would > fix a number of problems with our current MST implementation, but > it's going to be a major rewrite. > > MST DSC hardware is already on the market. It would be expedient to > merge the patches we need for Navi support sooner and update > drm_dp_mst_atomic_check when we're able to test it. Is there any commitment to rewriting it, a timeline or anything? The problem with this situation is there is always new hardware coming onto the market, and there is always pressure to support all the features of that new hardware, and the pressure always comes like this and being expedient. However I've found that a lot of the time the required refactor or work is never done, because the time is being allocated now to the next GPU that is coming on the market, and nobody ever cares enough to clean up their technical debt. How come the needs for MST DSC support wasn't identified earlier, blocked on refactoring of the code to use common code, and then that task made a higher priority? I'm sorta inclined to say no we shouldn't be merging any driver specific code here, because this is the only point we can push pressure on to refactor the MST implementation, which I guess otherwise we'll just keep avoiding until Lyude ends up doing it for you. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 6/6] drm/i915/dp: Attach HDR metadata property to DP connector
>-Original Message-
>From: Mun, Gwan-gyeong
>Sent: Friday, August 23, 2019 3:23 PM
>To: intel-...@lists.freedesktop.org
>Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
>Sharma, Shashank
>Subject: [PATCH v2 6/6] drm/i915/dp: Attach HDR metadata property to DP
>connector
>
>It attaches HDR metadata property to DP connector on GLK+.
>It enables HDR metadata infoframe sdp on GLK+ to be used to send HDR metadata
>to
>DP sink.
>
>v2: Minor style fix
The changes look good to me.
Reviewed-by: Uma Shankar
>Signed-off-by: Gwan-gyeong Mun
>---
> drivers/gpu/drm/i915/display/intel_dp.c | 5 +
> 1 file changed, 5 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>b/drivers/gpu/drm/i915/display/intel_dp.c
>index 00da8221eaba..899923ecd1c9 100644
>--- a/drivers/gpu/drm/i915/display/intel_dp.c
>+++ b/drivers/gpu/drm/i915/display/intel_dp.c
>@@ -6495,6 +6495,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
>struct
>drm_connector *connect
>
> intel_attach_colorspace_property(connector);
>
>+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
>+ drm_object_attach_property(&connector->base,
>+ connector->dev-
>>mode_config.hdr_output_metadata_property,
>+ 0);
>+
> if (intel_dp_is_edp(intel_dp)) {
> u32 allowed_scalers;
>
>--
>2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v2 5/6] drm/i915/dp: Program an Infoframe SDP Header and DB for HDR Static Metadata
>-Original Message-
>From: Mun, Gwan-gyeong
>Sent: Friday, August 23, 2019 3:23 PM
>To: intel-...@lists.freedesktop.org
>Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
>Sharma, Shashank
>Subject: [PATCH v2 5/6] drm/i915/dp: Program an Infoframe SDP Header and DB for
>HDR Static Metadata
>
>Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
>header and data block setup for HDR Static Metadata. It enables writing of HDR
>metadata infoframe SDP to panel. Support for HDR video was introduced in
>DisplayPort 1.4. It implements the CTA-861-G standard for transport of static
>HDR
>metadata. The HDR Metadata will be provided by userspace compositors, based on
>blending policies and passed to the driver through a blob property.
>
>Because each of GEN11 and prior GEN11 have different register size for HDR
>Metadata Infoframe SDP packet, it adds and uses different register size.
>
>Setup Infoframe SDP header and data block in function
>intel_dp_setup_hdr_metadata_infoframe_sdp for HDR Static Metadata as per dp 1.4
>spec and CTA-861-F spec.
>As per DP 1.4 spec, 2.2.2.5 SDP Formats. It enables Dynamic Range and Mastering
>Infoframe for HDR content, which is defined in CTA-861-F spec.
>According to DP 1.4 spec and CEA-861-F spec Table 5, in order to transmit
>static HDR
>metadata, we have to use Non-audio INFOFRAME SDP v1.3.
>
>++---+
>| [ Packet Type Value ] | [ Packet Type ] |
>++---+
>| 80h + Non-audio INFOFRAME Type | CEA-861-F Non-audio INFOFRAME |
>++---+
>| [Transmission Timing] |
>++
>| As per CEA-861-F for INFOFRAME, including CEA-861.3 within |
>| which Dynamic Range and Mastering INFOFRAME are defined|
>++
>
>v2: Add a missed blank line after function declaration.
>
>Signed-off-by: Gwan-gyeong Mun
>---
> drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
>drivers/gpu/drm/i915/display/intel_dp.c | 91
>drivers/gpu/drm/i915/display/intel_dp.h | 3 +
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 4 files changed, 96 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
>b/drivers/gpu/drm/i915/display/intel_ddi.c
>index 5c42b58c1c2f..9f5bea941bcd 100644
>--- a/drivers/gpu/drm/i915/display/intel_ddi.c
>+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
>@@ -3478,6 +3478,7 @@ static void intel_enable_ddi_dp(struct intel_encoder
>*encoder,
> intel_edp_backlight_on(crtc_state, conn_state);
> intel_psr_enable(intel_dp, crtc_state);
> intel_dp_vsc_enable(intel_dp, crtc_state, conn_state);
>+ intel_dp_hdr_metadata_enable(intel_dp, crtc_state, conn_state);
> intel_edp_drrs_enable(intel_dp, crtc_state);
>
> if (crtc_state->has_audio)
>diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>b/drivers/gpu/drm/i915/display/intel_dp.c
>index 7218e159f55d..00da8221eaba 100644
>--- a/drivers/gpu/drm/i915/display/intel_dp.c
>+++ b/drivers/gpu/drm/i915/display/intel_dp.c
>@@ -4554,6 +4554,85 @@ intel_dp_setup_vsc_sdp(struct intel_dp *intel_dp,
> crtc_state, DP_SDP_VSC, &vsc_sdp, sizeof(vsc_sdp)); }
>
>+static int
>+intel_dp_setup_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
>+const struct intel_crtc_state
>*crtc_state,
>+const struct drm_connector_state
The return value is not handled, you may convert it as void.
>*conn_state) {
>+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>+ struct drm_i915_private *dev_priv =
>to_i915(intel_dig_port->base.base.dev);
>+ struct dp_sdp infoframe_sdp = {};
>+ struct hdmi_drm_infoframe drm_infoframe = {};
>+ const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE +
>HDMI_DRM_INFOFRAME_SIZE;
>+ unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE +
>HDMI_DRM_INFOFRAME_SIZE];
>+ ssize_t len;
>+ int ret;
>+
>+ ret = drm_hdmi_infoframe_set_hdr_metadata(&drm_infoframe, conn_state);
>+ if (ret) {
>+ DRM_DEBUG_KMS("couldn't set HDR metadata in infoframe\n");
>+ return ret;
>+ }
>+
>+ len = hdmi_drm_infoframe_pack_only(&drm_infoframe, buf, sizeof(buf));
>+ if (len < 0) {
>+ DRM_DEBUG_KMS("buffer size is smaller than hdr metadata
>infoframe\n");
>+ return (int)len;
If made void, this will not be required.
>+ }
>+
>+ if (len != infoframe_size) {
>+ DRM_DEBUG_KMS("wrong static hdr metadata size\n");
>+ return -EINVAL;
>+ }
>+
>+ /*
>+ * Set up the infoframe sdp packet for HDR static metadata.
>+ * Prepare VSC Header
[PATCH RESEND 13/14] drm/tilcdc: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz Acked-by: Sam Ravnborg Reviewed-by: Emil Velikov --- drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c index 525dc1c0f1c1..46d1b30cc164 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c @@ -213,8 +213,10 @@ static struct drm_connector *tfp410_connector_create(struct drm_device *dev, connector = &tfp410_connector->base; - drm_connector_init(dev, connector, &tfp410_connector_funcs, - DRM_MODE_CONNECTOR_DVID); + drm_connector_init_with_ddc(dev, connector, + &tfp410_connector_funcs, + DRM_MODE_CONNECTOR_DVID, + mod->i2c); drm_connector_helper_add(connector, &tfp410_connector_helper_funcs); connector->polled = DRM_CONNECTOR_POLL_CONNECT | -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 12/14] drm: zte: Provide ddc symlink in vga connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/zte/zx_vga.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_vga.c b/drivers/gpu/drm/zte/zx_vga.c
index 9b67e419280c..c4fa3bbaba78 100644
--- a/drivers/gpu/drm/zte/zx_vga.c
+++ b/drivers/gpu/drm/zte/zx_vga.c
@@ -165,8 +165,10 @@ static int zx_vga_register(struct drm_device *drm, struct
zx_vga *vga)
vga->connector.polled = DRM_CONNECTOR_POLL_HPD;
- ret = drm_connector_init(drm, connector, &zx_vga_connector_funcs,
-DRM_MODE_CONNECTOR_VGA);
+ ret = drm_connector_init_with_ddc(drm, connector,
+ &zx_vga_connector_funcs,
+ DRM_MODE_CONNECTOR_VGA,
+ &vga->ddc->adap);
if (ret) {
DRM_DEV_ERROR(dev, "failed to init connector: %d\n", ret);
goto clean_encoder;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 14/14] drm/i915: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 0ebec69bbbfc..7e69e5782f6e 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -3084,6 +3084,7 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
struct intel_encoder *intel_encoder = &intel_dig_port->base;
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
+ struct i2c_adapter *ddc;
enum port port = intel_encoder->port;
DRM_DEBUG_KMS("Adding HDMI connector on port %c\n",
@@ -3094,8 +3095,13 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
intel_dig_port->max_lanes, port_name(port)))
return;
- drm_connector_init(dev, connector, &intel_hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+ intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
+ ddc = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+
+ drm_connector_init_with_ddc(dev, connector,
+ &intel_hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ ddc);
drm_connector_helper_add(connector, &intel_hdmi_connector_helper_funcs);
connector->interlace_allowed = 1;
@@ -3105,8 +3111,6 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
connector->ycbcr_420_allowed = true;
- intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
-
if (WARN_ON(port == PORT_A))
return;
intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 09/14] drm/tegra: Provide ddc symlink in output connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz Acked-by: Sam Ravnborg Reviewed-by: Emil Velikov --- drivers/gpu/drm/tegra/hdmi.c | 7 --- drivers/gpu/drm/tegra/sor.c | 7 --- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c index 50269ffbcb6b..21a629adcb51 100644 --- a/drivers/gpu/drm/tegra/hdmi.c +++ b/drivers/gpu/drm/tegra/hdmi.c @@ -1430,9 +1430,10 @@ static int tegra_hdmi_init(struct host1x_client *client) hdmi->output.dev = client->dev; - drm_connector_init(drm, &hdmi->output.connector, - &tegra_hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(drm, &hdmi->output.connector, + &tegra_hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + hdmi->output.ddc); drm_connector_helper_add(&hdmi->output.connector, &tegra_hdmi_connector_helper_funcs); hdmi->output.connector.dpms = DRM_MODE_DPMS_OFF; diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c index e1669ada0a40..0ad99dc0b4a1 100644 --- a/drivers/gpu/drm/tegra/sor.c +++ b/drivers/gpu/drm/tegra/sor.c @@ -2835,9 +2835,10 @@ static int tegra_sor_init(struct host1x_client *client) sor->output.dev = sor->dev; - drm_connector_init(drm, &sor->output.connector, - &tegra_sor_connector_funcs, - connector); + drm_connector_init_with_ddc(drm, &sor->output.connector, + &tegra_sor_connector_funcs, + connector, + sor->output.ddc); drm_connector_helper_add(&sor->output.connector, &tegra_sor_connector_helper_funcs); sor->output.connector.dpms = DRM_MODE_DPMS_OFF; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 11/14] drm: zte: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz Acked-by: Sam Ravnborg Reviewed-by: Emil Velikov --- drivers/gpu/drm/zte/zx_hdmi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c index a50f5a1f09b8..b98a1420dcd3 100644 --- a/drivers/gpu/drm/zte/zx_hdmi.c +++ b/drivers/gpu/drm/zte/zx_hdmi.c @@ -319,8 +319,10 @@ static int zx_hdmi_register(struct drm_device *drm, struct zx_hdmi *hdmi) hdmi->connector.polled = DRM_CONNECTOR_POLL_HPD; - drm_connector_init(drm, &hdmi->connector, &zx_hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(drm, &hdmi->connector, + &zx_hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + &hdmi->ddc->adap); drm_connector_helper_add(&hdmi->connector, &zx_hdmi_connector_helper_funcs); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 10/14] drm/vc4: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index ee7d4e7b0ee3..eb57c907a256 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -267,7 +267,8 @@ static const struct drm_connector_helper_funcs
vc4_hdmi_connector_helper_funcs =
};
static struct drm_connector *vc4_hdmi_connector_init(struct drm_device *dev,
-struct drm_encoder
*encoder)
+struct drm_encoder
*encoder,
+struct i2c_adapter *ddc)
{
struct drm_connector *connector;
struct vc4_hdmi_connector *hdmi_connector;
@@ -281,8 +282,10 @@ static struct drm_connector
*vc4_hdmi_connector_init(struct drm_device *dev,
hdmi_connector->encoder = encoder;
- drm_connector_init(dev, connector, &vc4_hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+ drm_connector_init_with_ddc(dev, connector,
+ &vc4_hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ ddc);
drm_connector_helper_add(connector, &vc4_hdmi_connector_helper_funcs);
/* Create and attach TV margin props to this connector. */
@@ -1395,7 +1398,8 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
DRM_MODE_ENCODER_TMDS, NULL);
drm_encoder_helper_add(hdmi->encoder, &vc4_hdmi_encoder_helper_funcs);
- hdmi->connector = vc4_hdmi_connector_init(drm, hdmi->encoder);
+ hdmi->connector =
+ vc4_hdmi_connector_init(drm, hdmi->encoder, hdmi->ddc);
if (IS_ERR(hdmi->connector)) {
ret = PTR_ERR(hdmi->connector);
goto err_destroy_encoder;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 07/14] drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz Acked-by: Sam Ravnborg Reviewed-by: Emil Velikov --- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c index 07b4cb877d82..1f03262b8a52 100644 --- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c +++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c @@ -450,8 +450,10 @@ struct drm_connector *msm_hdmi_connector_init(struct hdmi *hdmi) connector = &hdmi_connector->base; - drm_connector_init(hdmi->dev, connector, &hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(hdmi->dev, connector, + &hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + hdmi->i2c); drm_connector_helper_add(connector, &msm_hdmi_connector_helper_funcs); connector->polled = DRM_CONNECTOR_POLL_CONNECT | -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 08/14] drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index ce91b61364eb..f419765b7cc0 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1299,9 +1299,10 @@ static int mtk_hdmi_bridge_attach(struct drm_bridge
*bridge)
struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
int ret;
- ret = drm_connector_init(bridge->encoder->dev, &hdmi->conn,
-&mtk_hdmi_connector_funcs,
-DRM_MODE_CONNECTOR_HDMIA);
+ ret = drm_connector_init_with_ddc(bridge->encoder->dev, &hdmi->conn,
+ &mtk_hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ hdmi->ddc_adpt);
if (ret) {
dev_err(hdmi->dev, "Failed to initialize connector: %d\n", ret);
return ret;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 05/14] drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz Acked-by: Sam Ravnborg Reviewed-by: Emil Velikov --- drivers/gpu/drm/rockchip/rk3066_hdmi.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c b/drivers/gpu/drm/rockchip/rk3066_hdmi.c index 85fc5f01f761..e874f5fdeec4 100644 --- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c +++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c @@ -564,9 +564,10 @@ rk3066_hdmi_register(struct drm_device *drm, struct rk3066_hdmi *hdmi) drm_connector_helper_add(&hdmi->connector, &rk3066_hdmi_connector_helper_funcs); - drm_connector_init(drm, &hdmi->connector, - &rk3066_hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(drm, &hdmi->connector, + &rk3066_hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + hdmi->ddc); drm_connector_attach_encoder(&hdmi->connector, encoder); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 06/14] drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz Acked-by: Sam Ravnborg Reviewed-by: Emil Velikov --- drivers/gpu/drm/rockchip/inno_hdmi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c index ed344a795b4d..e5864e823020 100644 --- a/drivers/gpu/drm/rockchip/inno_hdmi.c +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c @@ -624,8 +624,10 @@ static int inno_hdmi_register(struct drm_device *drm, struct inno_hdmi *hdmi) drm_connector_helper_add(&hdmi->connector, &inno_hdmi_connector_helper_funcs); - drm_connector_init(drm, &hdmi->connector, &inno_hdmi_connector_funcs, - DRM_MODE_CONNECTOR_HDMIA); + drm_connector_init_with_ddc(drm, &hdmi->connector, + &inno_hdmi_connector_funcs, + DRM_MODE_CONNECTOR_HDMIA, + hdmi->ddc); drm_connector_attach_encoder(&hdmi->connector, encoder); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 03/14] drm/amdgpu: Provide ddc symlink in dm connector's sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
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 cb7cfa9b34f2..e872a415b409 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5144,11 +5144,12 @@ static int amdgpu_dm_connector_init(struct
amdgpu_display_manager *dm,
connector_type = to_drm_connector_type(link->connector_signal);
- res = drm_connector_init(
+ res = drm_connector_init_with_ddc(
dm->ddev,
&aconnector->base,
&amdgpu_dm_connector_funcs,
- connector_type);
+ connector_type,
+ &i2c->base);
if (res) {
DRM_ERROR("connector_init failed\n");
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 04/14] drm/exynos: Provide ddc symlink in connector's sysfs
Switch to using the ddc provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Sam Ravnborg
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index bc1565f1822a..d4a9c9e17436 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -940,8 +940,10 @@ static int hdmi_create_connector(struct drm_encoder
*encoder)
connector->interlace_allowed = true;
connector->polled = DRM_CONNECTOR_POLL_HPD;
- ret = drm_connector_init(hdata->drm_dev, connector,
- &hdmi_connector_funcs, DRM_MODE_CONNECTOR_HDMIA);
+ ret = drm_connector_init_with_ddc(hdata->drm_dev, connector,
+ &hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA,
+ hdata->ddc_adpt);
if (ret) {
DRM_DEV_ERROR(hdata->dev,
"Failed to initialize connector with drm\n");
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 02/14] drm/radeon: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/radeon/radeon_connectors.c | 143 +++--
1 file changed, 107 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index c60d1a44d22a..62d37eddf99c 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1870,6 +1870,7 @@ radeon_add_atom_connector(struct drm_device *dev,
struct radeon_connector_atom_dig *radeon_dig_connector;
struct drm_encoder *encoder;
struct radeon_encoder *radeon_encoder;
+ struct i2c_adapter *ddc = NULL;
uint32_t subpixel_order = SubPixelNone;
bool shared_ddc = false;
bool is_dp_bridge = false;
@@ -1947,17 +1948,21 @@ radeon_add_atom_connector(struct drm_device *dev,
radeon_connector->con_priv = radeon_dig_connector;
if (i2c_bus->valid) {
radeon_connector->ddc_bus = radeon_i2c_lookup(rdev,
i2c_bus);
- if (radeon_connector->ddc_bus)
+ if (radeon_connector->ddc_bus) {
has_aux = true;
- else
+ ddc = &radeon_connector->ddc_bus->adapter;
+ } else {
DRM_ERROR("DP: Failed to assign ddc bus! Check
dmesg for i2c errors.\n");
+ }
}
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
case DRM_MODE_CONNECTOR_DVIA:
default:
- drm_connector_init(dev, &radeon_connector->base,
- &radeon_dp_connector_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
&radeon_connector->base,
+ &radeon_dp_connector_funcs,
+ connector_type,
+ ddc);
drm_connector_helper_add(&radeon_connector->base,
&radeon_dp_connector_helper_funcs);
connector->interlace_allowed = true;
@@ -1979,8 +1984,10 @@ radeon_add_atom_connector(struct drm_device *dev,
case DRM_MODE_CONNECTOR_HDMIA:
case DRM_MODE_CONNECTOR_HDMIB:
case DRM_MODE_CONNECTOR_DisplayPort:
- drm_connector_init(dev, &radeon_connector->base,
- &radeon_dp_connector_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
&radeon_connector->base,
+ &radeon_dp_connector_funcs,
+ connector_type,
+ ddc);
drm_connector_helper_add(&radeon_connector->base,
&radeon_dp_connector_helper_funcs);
drm_object_attach_property(&radeon_connector->base.base,
@@ -2027,8 +2034,10 @@ radeon_add_atom_connector(struct drm_device *dev,
break;
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_eDP:
- drm_connector_init(dev, &radeon_connector->base,
- &radeon_lvds_bridge_connector_funcs,
connector_type);
+ drm_connector_init_with_ddc(dev,
&radeon_connector->base,
+
&radeon_lvds_bridge_connector_funcs,
+ connector_type,
+ ddc);
drm_connector_helper_add(&radeon_connector->base,
&radeon_dp_connector_helper_funcs);
drm_object_attach_property(&radeon_connector->base.base,
@@ -2042,13 +2051,18 @@ radeon_add_atom_connector(struct drm_device *dev,
} else {
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
- drm_connector_init(dev, &radeon_connector->base,
&radeon_vga_connector_funcs, connector_type);
- drm_connector_helper_add(&radeon_connector->base,
&radeon_vga_connector_helper_funcs);
if (i2c_bus->valid) {
radeon_connector->ddc_bus =
radeon_i2c_lookup(rdev, i2c_bus);
if (!radeon_connector->ddc_bus)
DRM_ERROR("VGA: Failed to assign ddc
bus! Check dmesg for i2c errors.\n");
+ else
+
[PATCH RESEND 01/14] drm/bridge: ti-tfp410: Update drm_connector_init_with_ddc() error message
From: Geert Uytterhoeven
The code was changed to call drm_connector_init_with_ddc() instead of
drm_connector_init(), but the corresponding error message was not
updated.
Fixes: cfb444552926989f ("drm/bridge: ti-tfp410: Provide ddc symlink in
connector sysfs directory")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Neil Armstrong
---
drivers/gpu/drm/bridge/ti-tfp410.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index 61cc2354ef1b..be6c99cac419 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -139,7 +139,8 @@ static int tfp410_attach(struct drm_bridge *bridge)
dvi->connector_type,
dvi->ddc);
if (ret) {
- dev_err(dvi->dev, "drm_connector_init() failed: %d\n", ret);
+ dev_err(dvi->dev, "drm_connector_init_with_ddc() failed: %d\n",
+ ret);
return ret;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND 00/14] Next round of associating ddc adapters with connectors
I'm resending the patches which have somehow got lost: one patch from Geert and 13 patches from me. Geert's patch updates the error message to reflect the actually called function's name. Most of patches from me have their Acked-by and Reviewed-by tags and deal with providing a ddc symlink in connector's sysfs directory. Rebased onto drm-misc-next as of 26th August. Andrzej Pietrasiewicz (13): drm/radeon: Provide ddc symlink in connector sysfs directory drm/amdgpu: Provide ddc symlink in dm connector's sysfs directory drm/exynos: Provide ddc symlink in connector's sysfs drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory drm/tegra: Provide ddc symlink in output connector sysfs directory drm/vc4: Provide ddc symlink in connector sysfs directory drm: zte: Provide ddc symlink in hdmi connector sysfs directory drm: zte: Provide ddc symlink in vga connector sysfs directory drm/tilcdc: Provide ddc symlink in connector sysfs directory drm/i915: Provide ddc symlink in hdmi connector sysfs directory Geert Uytterhoeven (1): drm/bridge: ti-tfp410: Update drm_connector_init_with_ddc() error message .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +- drivers/gpu/drm/bridge/ti-tfp410.c| 3 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 6 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 12 +- drivers/gpu/drm/mediatek/mtk_hdmi.c | 7 +- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 6 +- drivers/gpu/drm/radeon/radeon_connectors.c| 143 +- drivers/gpu/drm/rockchip/inno_hdmi.c | 6 +- drivers/gpu/drm/rockchip/rk3066_hdmi.c| 7 +- drivers/gpu/drm/tegra/hdmi.c | 7 +- drivers/gpu/drm/tegra/sor.c | 7 +- drivers/gpu/drm/tilcdc/tilcdc_tfp410.c| 6 +- drivers/gpu/drm/vc4/vc4_hdmi.c| 12 +- drivers/gpu/drm/zte/zx_hdmi.c | 6 +- drivers/gpu/drm/zte/zx_vga.c | 6 +- 15 files changed, 168 insertions(+), 71 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/15] Improvements and fixes for mxsfb DRM driver
On 26.08.2019 17:35, Stefan Agner wrote: > On 2019-08-26 14:05, Guido Günther wrote: >> Hi, >> On Wed, Aug 21, 2019 at 01:15:40PM +0300, Robert Chiras wrote: >>> This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM >>> and 8QXP). Following, are the new features added and fixes from this >>> patch-set: >> >> I've applied this whole series on top of my NWL work and it looks good >> with a DSI panel. Applying the whole series also fixes an issue where >> after unblank the output was sometimes shifted about half a screen width >> to the right (which didn't happen with DCSS). So at least from the parts >> I could test: >> >>Tested-by: Guido Günther >> >> for the whole thing. > > Thanks for testing! What SoC did you use? I think it would be good to > also give this a try on i.MX 7 or i.MX 6ULL before merging. I did a quick test on imx6sx-sdb and it seems that [PATCH 07/15] "drm/mxsfb: Fix the vblank events" causes a hang on boot, even without a panel. If I revert that particular patch it seems to be fine: the new pixel formats seem to work in modetest (checked with sii,43wvf1g panel). -- Regards, Leonard
RE: [PATCH v2 4/6] drm/i915/dp: Attach colorspace property
>-Original Message-
>From: Mun, Gwan-gyeong
>Sent: Friday, August 23, 2019 3:23 PM
>To: intel-...@lists.freedesktop.org
>Cc: dri-devel@lists.freedesktop.org; Shankar, Uma ;
>Sharma, Shashank
>Subject: [PATCH v2 4/6] drm/i915/dp: Attach colorspace property
>
>It attaches the colorspace connector property to a DisplayPort connector.
>Based on colorspace change, modeset will be triggered to switch to a new
>colorspace.
>
>Based on colorspace property value create a VSC SDP packet with appropriate
>colorspace. This would help to enable wider color gamut like BT2020 on a sink
>device.
The changes look good to me.
Reviewed-by: Uma Shankar
>Signed-off-by: Gwan-gyeong Mun
>---
> drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>b/drivers/gpu/drm/i915/display/intel_dp.c
>index 295d5ed2be96..7218e159f55d 100644
>--- a/drivers/gpu/drm/i915/display/intel_dp.c
>+++ b/drivers/gpu/drm/i915/display/intel_dp.c
>@@ -6402,6 +6402,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
>drm_connector *connect
> else if (INTEL_GEN(dev_priv) >= 5)
> drm_connector_attach_max_bpc_property(connector, 6, 12);
>
>+ intel_attach_colorspace_property(connector);
>+
> if (intel_dp_is_edp(intel_dp)) {
> u32 allowed_scalers;
>
>--
>2.22.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
