* Patch "perf build: Fix traceevent plugins build race" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 8:35 UTC (permalink / raw)
To: jolsa, a.p.zijlstra, acme, dsahern, gregkh, mingo, namhyung, tmb
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
perf build: Fix traceevent plugins build race
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
perf-build-fix-traceevent-plugins-build-race.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 67befc652845c8ffbefc8d173a6e6ced14d472f1 Mon Sep 17 00:00:00 2001
From: Jiri Olsa <jolsa@kernel.org>
Date: Thu, 26 Nov 2015 14:54:04 +0100
Subject: perf build: Fix traceevent plugins build race
From: Jiri Olsa <jolsa@kernel.org>
commit 67befc652845c8ffbefc8d173a6e6ced14d472f1 upstream.
Ingo reported following build failure:
$ make clean install
...
CC plugin_kmem.o
fixdep: error opening depfile: ./.plugin_hrtimer.o.d: No such file or directory
/home/mingo/tip/tools/build/Makefile.build:77: recipe for target
'plugin_hrtimer.o' failed
make[3]: *** [plugin_hrtimer.o] Error 2
Makefile:189: recipe for target 'plugin_hrtimer-in.o' failed
make[2]: *** [plugin_hrtimer-in.o] Error 2
Makefile.perf:414: recipe for target 'libtraceevent_plugins' failed
make[1]: *** [libtraceevent_plugins] Error 2
make[1]: *** Waiting for unfinished jobs....
Currently we have the install-traceevent-plugins target being dependent
on $(LIBTRACEEVENT), which will actualy not build any plugin. So the
install-traceevent-plugins target itself will try to build plugins,
but..
Plugins built is also triggered by perf build itself via
libtraceevent_plugins target.
This might cause a race having one make thread removing temp files from
another and result in above error. Fixing this by having proper plugins
build dependency before installing plugins.
Reported-and-Tested-by:: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1448546044-28973-3-git-send-email-jolsa@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Thomas Backlund <tmb@mageia.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/Makefile.perf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -420,7 +420,7 @@ $(LIBTRACEEVENT)-clean:
$(call QUIET_CLEAN, libtraceevent)
$(Q)$(MAKE) -C $(TRACE_EVENT_DIR) O=$(OUTPUT) clean >/dev/null
-install-traceevent-plugins: $(LIBTRACEEVENT)
+install-traceevent-plugins: libtraceevent_plugins
$(Q)$(MAKE) -C $(TRACE_EVENT_DIR) $(LIBTRACEEVENT_FLAGS) O=$(OUTPUT) install_plugins
$(LIBAPI): fixdep FORCE
Patches currently in stable-queue which might be from jolsa@kernel.org are
queue-4.4/perf-build-fix-traceevent-plugins-build-race.patch
^ permalink raw reply
* Patch "mmc: dw_mmc-pltfm: fix the potential NULL pointer dereference" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 8:35 UTC (permalink / raw)
To: jh80.chung, gregkh, shawn.lin, ulf.hansson; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
mmc: dw_mmc-pltfm: fix the potential NULL pointer dereference
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mmc-dw_mmc-pltfm-fix-the-potential-null-pointer-dereference.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 45c7a4908a307a023e237a64a3eadcafc4836493 Mon Sep 17 00:00:00 2001
From: Jaehoon Chung <jh80.chung@samsung.com>
Date: Fri, 21 Oct 2016 19:57:57 +0900
Subject: mmc: dw_mmc-pltfm: fix the potential NULL pointer dereference
From: Jaehoon Chung <jh80.chung@samsung.com>
commit 45c7a4908a307a023e237a64a3eadcafc4836493 upstream.
platform_get_resource can be returned the NULL pointer.
Then regs->start should be referred to NULL Pointer.
devm_ioremap_resource() checks whether res is NULL or not.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/mmc/host/dw_mmc-pltfm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -59,12 +59,13 @@ int dw_mci_pltfm_register(struct platfor
host->pdata = pdev->dev.platform_data;
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- /* Get registers' physical base address */
- host->phy_regs = regs->start;
host->regs = devm_ioremap_resource(&pdev->dev, regs);
if (IS_ERR(host->regs))
return PTR_ERR(host->regs);
+ /* Get registers' physical base address */
+ host->phy_regs = regs->start;
+
platform_set_drvdata(pdev, host);
return dw_mci_probe(host);
}
Patches currently in stable-queue which might be from jh80.chung@samsung.com are
queue-4.4/mmc-dw_mmc-pltfm-fix-the-potential-null-pointer-dereference.patch
^ permalink raw reply
* Patch "mac80211: discard multicast and 4-addr A-MSDUs" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 8:35 UTC (permalink / raw)
To: johannes.berg, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
mac80211: discard multicast and 4-addr A-MSDUs
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mac80211-discard-multicast-and-4-addr-a-msdus.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From ea720935cf6686f72def9d322298bf7e9bd53377 Mon Sep 17 00:00:00 2001
From: Johannes Berg <johannes.berg@intel.com>
Date: Wed, 5 Oct 2016 10:14:42 +0200
Subject: mac80211: discard multicast and 4-addr A-MSDUs
From: Johannes Berg <johannes.berg@intel.com>
commit ea720935cf6686f72def9d322298bf7e9bd53377 upstream.
In mac80211, multicast A-MSDUs are accepted in many cases that
they shouldn't be accepted in:
* drop A-MSDUs with a multicast A1 (RA), as required by the
spec in 9.11 (802.11-2012 version)
* drop A-MSDUs with a 4-addr header, since the fourth address
can't actually be useful for them; unless 4-address frame
format is actually requested, even though the fourth address
is still not useful in this case, but ignored
Accepting the first case, in particular, is very problematic
since it allows anyone else with possession of a GTK to send
unicast frames encapsulated in a multicast A-MSDU, even when
the AP has client isolation enabled.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/mac80211/rx.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2203,16 +2203,22 @@ ieee80211_rx_h_amsdu(struct ieee80211_rx
if (!(status->rx_flags & IEEE80211_RX_AMSDU))
return RX_CONTINUE;
- if (ieee80211_has_a4(hdr->frame_control) &&
- rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
- !rx->sdata->u.vlan.sta)
- return RX_DROP_UNUSABLE;
+ if (unlikely(ieee80211_has_a4(hdr->frame_control))) {
+ switch (rx->sdata->vif.type) {
+ case NL80211_IFTYPE_AP_VLAN:
+ if (!rx->sdata->u.vlan.sta)
+ return RX_DROP_UNUSABLE;
+ break;
+ case NL80211_IFTYPE_STATION:
+ if (!rx->sdata->u.mgd.use_4addr)
+ return RX_DROP_UNUSABLE;
+ break;
+ default:
+ return RX_DROP_UNUSABLE;
+ }
+ }
- if (is_multicast_ether_addr(hdr->addr1) &&
- ((rx->sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
- rx->sdata->u.vlan.sta) ||
- (rx->sdata->vif.type == NL80211_IFTYPE_STATION &&
- rx->sdata->u.mgd.use_4addr)))
+ if (is_multicast_ether_addr(hdr->addr1))
return RX_DROP_UNUSABLE;
skb->dev = dev;
Patches currently in stable-queue which might be from johannes.berg@intel.com are
queue-4.4/mac80211-discard-multicast-and-4-addr-a-msdus.patch
^ permalink raw reply
* Patch "drm/radeon/si_dpm: Limit clocks on HD86xx part" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 8:35 UTC (permalink / raw)
To: tom.stdenis, alexander.deucher, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/radeon/si_dpm: Limit clocks on HD86xx part
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-radeon-si_dpm-limit-clocks-on-hd86xx-part.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From fb9a5b0c1c9893db2e0d18544fd49e19d784a87d Mon Sep 17 00:00:00 2001
From: Tom St Denis <tom.stdenis@amd.com>
Date: Thu, 13 Oct 2016 12:38:07 -0400
Subject: drm/radeon/si_dpm: Limit clocks on HD86xx part
From: Tom St Denis <tom.stdenis@amd.com>
commit fb9a5b0c1c9893db2e0d18544fd49e19d784a87d upstream.
Limit clocks on a specific HD86xx part to avoid
crashes (while awaiting an appropriate PP fix).
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/si_dpm.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3021,6 +3021,12 @@ static void si_apply_state_adjust_rules(
max_sclk = 75000;
max_mclk = 80000;
}
+ /* limit clocks on HD8600 series */
+ if (rdev->pdev->device == 0x6660 &&
+ rdev->pdev->revision == 0x83) {
+ max_sclk = 75000;
+ max_mclk = 80000;
+ }
if (rps->vce_active) {
rps->evclk = rdev->pm.dpm.vce_states[rdev->pm.dpm.vce_level].evclk;
Patches currently in stable-queue which might be from tom.stdenis@amd.com are
queue-4.4/drm-radeon-si_dpm-limit-clocks-on-hd86xx-part.patch
^ permalink raw reply
* Patch "drm/radeon/si_dpm: workaround for SI kickers" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 8:35 UTC (permalink / raw)
To: alexander.deucher, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/radeon/si_dpm: workaround for SI kickers
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-radeon-si_dpm-workaround-for-si-kickers.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 7dc86ef5ac91642dfc3eb93ee0f0458e702a343e Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher@amd.com>
Date: Fri, 14 Oct 2016 16:38:02 -0400
Subject: drm/radeon/si_dpm: workaround for SI kickers
From: Alex Deucher <alexander.deucher@amd.com>
commit 7dc86ef5ac91642dfc3eb93ee0f0458e702a343e upstream.
Consolidate existing quirks. Fixes stability issues
on some kickers.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/si_dpm.c | 59 +++++++++++++++++++++++++++++-----------
1 file changed, 43 insertions(+), 16 deletions(-)
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2999,6 +2999,49 @@ static void si_apply_state_adjust_rules(
int i;
struct si_dpm_quirk *p = si_dpm_quirk_list;
+ /* limit all SI kickers */
+ if (rdev->family == CHIP_PITCAIRN) {
+ if ((rdev->pdev->revision == 0x81) ||
+ (rdev->pdev->device == 0x6810) ||
+ (rdev->pdev->device == 0x6811) ||
+ (rdev->pdev->device == 0x6816) ||
+ (rdev->pdev->device == 0x6817) ||
+ (rdev->pdev->device == 0x6806))
+ max_mclk = 120000;
+ } else if (rdev->family == CHIP_VERDE) {
+ if ((rdev->pdev->revision == 0x81) ||
+ (rdev->pdev->revision == 0x83) ||
+ (rdev->pdev->revision == 0x87) ||
+ (rdev->pdev->device == 0x6820) ||
+ (rdev->pdev->device == 0x6821) ||
+ (rdev->pdev->device == 0x6822) ||
+ (rdev->pdev->device == 0x6823) ||
+ (rdev->pdev->device == 0x682A) ||
+ (rdev->pdev->device == 0x682B)) {
+ max_sclk = 75000;
+ max_mclk = 80000;
+ }
+ } else if (rdev->family == CHIP_OLAND) {
+ if ((rdev->pdev->revision == 0xC7) ||
+ (rdev->pdev->revision == 0x80) ||
+ (rdev->pdev->revision == 0x81) ||
+ (rdev->pdev->revision == 0x83) ||
+ (rdev->pdev->device == 0x6604) ||
+ (rdev->pdev->device == 0x6605)) {
+ max_sclk = 75000;
+ max_mclk = 80000;
+ }
+ } else if (rdev->family == CHIP_HAINAN) {
+ if ((rdev->pdev->revision == 0x81) ||
+ (rdev->pdev->revision == 0x83) ||
+ (rdev->pdev->revision == 0xC3) ||
+ (rdev->pdev->device == 0x6664) ||
+ (rdev->pdev->device == 0x6665) ||
+ (rdev->pdev->device == 0x6667)) {
+ max_sclk = 75000;
+ max_mclk = 80000;
+ }
+ }
/* Apply dpm quirks */
while (p && p->chip_device != 0) {
if (rdev->pdev->vendor == p->chip_vendor &&
@@ -3011,22 +3054,6 @@ static void si_apply_state_adjust_rules(
}
++p;
}
- /* limit mclk on all R7 370 parts for stability */
- if (rdev->pdev->device == 0x6811 &&
- rdev->pdev->revision == 0x81)
- max_mclk = 120000;
- /* limit sclk/mclk on Jet parts for stability */
- if (rdev->pdev->device == 0x6665 &&
- rdev->pdev->revision == 0xc3) {
- max_sclk = 75000;
- max_mclk = 80000;
- }
- /* limit clocks on HD8600 series */
- if (rdev->pdev->device == 0x6660 &&
- rdev->pdev->revision == 0x83) {
- max_sclk = 75000;
- max_mclk = 80000;
- }
if (rps->vce_active) {
rps->evclk = rdev->pm.dpm.vce_states[rdev->pm.dpm.vce_level].evclk;
Patches currently in stable-queue which might be from alexander.deucher@amd.com are
queue-4.4/revert-drm-radeon-fix-dp-link-training-issue-with-second-4k-monitor.patch
queue-4.4/drm-radeon-si_dpm-limit-clocks-on-hd86xx-part.patch
queue-4.4/drm-radeon-si_dpm-workaround-for-si-kickers.patch
queue-4.4/drm-radeon-drop-register-readback-in-cayman_cp_int_cntl_setup.patch
^ permalink raw reply
* Patch "drm/i915: Clean up DDI DDC/AUX CH sanitation" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 8:35 UTC (permalink / raw)
To: ville.syrjala, gregkh, jani.nikula, jim.bride, madman2003
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/i915: Clean up DDI DDC/AUX CH sanitation
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-clean-up-ddi-ddc-aux-ch-sanitation.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 0ce140d45a8398b501934ac289aef0eb7f47c596 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
Date: Tue, 11 Oct 2016 20:52:47 +0300
Subject: drm/i915: Clean up DDI DDC/AUX CH sanitation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
commit 0ce140d45a8398b501934ac289aef0eb7f47c596 upstream.
Now that we use the AUX and GMBUS assignment from VBT for all ports,
let's clean up the sanitization of the port information a bit.
Previosuly we only did this for port E, and only complained about a
non-standard assignment for the other ports. But as we know that
non-standard assignments are a fact of life, let's expand the
sanitization to all the ports.
v2: Include a commit message, fix up the comments a bit
v3: Don't clobber other ports if the current port has no alternate aux ch/ddc pin
Cc: Maarten Maathuis <madman2003@gmail.com>
Tested-by: Maarten Maathuis <madman2003@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jim Bride <jim.bride@linux.intel.com> (v2)
(cherry picked from commit 9454fa871edf15c20a0371548b3ec0d6d944a498)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_bios.c | 122 +++++++++++++++++++++++---------------
1 file changed, 77 insertions(+), 45 deletions(-)
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -907,6 +907,77 @@ static u8 translate_iboost(u8 val)
return mapping[val];
}
+static void sanitize_ddc_pin(struct drm_i915_private *dev_priv,
+ enum port port)
+{
+ const struct ddi_vbt_port_info *info =
+ &dev_priv->vbt.ddi_port_info[port];
+ enum port p;
+
+ if (!info->alternate_ddc_pin)
+ return;
+
+ for_each_port_masked(p, (1 << port) - 1) {
+ struct ddi_vbt_port_info *i = &dev_priv->vbt.ddi_port_info[p];
+
+ if (info->alternate_ddc_pin != i->alternate_ddc_pin)
+ continue;
+
+ DRM_DEBUG_KMS("port %c trying to use the same DDC pin (0x%x) as port %c, "
+ "disabling port %c DVI/HDMI support\n",
+ port_name(p), i->alternate_ddc_pin,
+ port_name(port), port_name(p));
+
+ /*
+ * If we have multiple ports supposedly sharing the
+ * pin, then dvi/hdmi couldn't exist on the shared
+ * port. Otherwise they share the same ddc bin and
+ * system couldn't communicate with them separately.
+ *
+ * Due to parsing the ports in alphabetical order,
+ * a higher port will always clobber a lower one.
+ */
+ i->supports_dvi = false;
+ i->supports_hdmi = false;
+ i->alternate_ddc_pin = 0;
+ }
+}
+
+static void sanitize_aux_ch(struct drm_i915_private *dev_priv,
+ enum port port)
+{
+ const struct ddi_vbt_port_info *info =
+ &dev_priv->vbt.ddi_port_info[port];
+ enum port p;
+
+ if (!info->alternate_aux_channel)
+ return;
+
+ for_each_port_masked(p, (1 << port) - 1) {
+ struct ddi_vbt_port_info *i = &dev_priv->vbt.ddi_port_info[p];
+
+ if (info->alternate_aux_channel != i->alternate_aux_channel)
+ continue;
+
+ DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) as port %c, "
+ "disabling port %c DP support\n",
+ port_name(p), i->alternate_aux_channel,
+ port_name(port), port_name(p));
+
+ /*
+ * If we have multiple ports supposedlt sharing the
+ * aux channel, then DP couldn't exist on the shared
+ * port. Otherwise they share the same aux channel
+ * and system couldn't communicate with them separately.
+ *
+ * Due to parsing the ports in alphabetical order,
+ * a higher port will always clobber a lower one.
+ */
+ i->supports_dp = false;
+ i->alternate_aux_channel = 0;
+ }
+}
+
static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
const struct bdb_header *bdb)
{
@@ -981,54 +1052,15 @@ static void parse_ddi_port(struct drm_i9
DRM_DEBUG_KMS("Port %c is internal DP\n", port_name(port));
if (is_dvi) {
- if (port == PORT_E) {
- info->alternate_ddc_pin = ddc_pin;
- /* if DDIE share ddc pin with other port, then
- * dvi/hdmi couldn't exist on the shared port.
- * Otherwise they share the same ddc bin and system
- * couldn't communicate with them seperately. */
- if (ddc_pin == DDC_PIN_B) {
- dev_priv->vbt.ddi_port_info[PORT_B].supports_dvi = 0;
- dev_priv->vbt.ddi_port_info[PORT_B].supports_hdmi = 0;
- } else if (ddc_pin == DDC_PIN_C) {
- dev_priv->vbt.ddi_port_info[PORT_C].supports_dvi = 0;
- dev_priv->vbt.ddi_port_info[PORT_C].supports_hdmi = 0;
- } else if (ddc_pin == DDC_PIN_D) {
- dev_priv->vbt.ddi_port_info[PORT_D].supports_dvi = 0;
- dev_priv->vbt.ddi_port_info[PORT_D].supports_hdmi = 0;
- }
- } else if (ddc_pin == DDC_PIN_B && port != PORT_B)
- DRM_DEBUG_KMS("Unexpected DDC pin for port B\n");
- else if (ddc_pin == DDC_PIN_C && port != PORT_C)
- DRM_DEBUG_KMS("Unexpected DDC pin for port C\n");
- else if (ddc_pin == DDC_PIN_D && port != PORT_D)
- DRM_DEBUG_KMS("Unexpected DDC pin for port D\n");
+ info->alternate_ddc_pin = ddc_pin;
+
+ sanitize_ddc_pin(dev_priv, port);
}
if (is_dp) {
- if (port == PORT_E) {
- info->alternate_aux_channel = aux_channel;
- /* if DDIE share aux channel with other port, then
- * DP couldn't exist on the shared port. Otherwise
- * they share the same aux channel and system
- * couldn't communicate with them seperately. */
- if (aux_channel == DP_AUX_A)
- dev_priv->vbt.ddi_port_info[PORT_A].supports_dp = 0;
- else if (aux_channel == DP_AUX_B)
- dev_priv->vbt.ddi_port_info[PORT_B].supports_dp = 0;
- else if (aux_channel == DP_AUX_C)
- dev_priv->vbt.ddi_port_info[PORT_C].supports_dp = 0;
- else if (aux_channel == DP_AUX_D)
- dev_priv->vbt.ddi_port_info[PORT_D].supports_dp = 0;
- }
- else if (aux_channel == DP_AUX_A && port != PORT_A)
- DRM_DEBUG_KMS("Unexpected AUX channel for port A\n");
- else if (aux_channel == DP_AUX_B && port != PORT_B)
- DRM_DEBUG_KMS("Unexpected AUX channel for port B\n");
- else if (aux_channel == DP_AUX_C && port != PORT_C)
- DRM_DEBUG_KMS("Unexpected AUX channel for port C\n");
- else if (aux_channel == DP_AUX_D && port != PORT_D)
- DRM_DEBUG_KMS("Unexpected AUX channel for port D\n");
+ info->alternate_aux_channel = aux_channel;
+
+ sanitize_aux_ch(dev_priv, port);
}
if (bdb->version >= 158) {
Patches currently in stable-queue which might be from ville.syrjala@linux.intel.com are
queue-4.4/usb-gadget-function-u_ether-don-t-starve-tx-request-queue.patch
queue-4.4/drm-i915-clean-up-ddi-ddc-aux-ch-sanitation.patch
queue-4.4/drm-dp-mst-check-peer-device-type-before-attempting-edid-read.patch
queue-4.4/drm-fb-helper-keep-references-for-the-current-set-of-used-connectors.patch
queue-4.4/drm-dp-mst-clear-port-pdt-when-tearing-down-the-i2c-adapter.patch
queue-4.4/drm-fb-helper-fix-connector-ref-leak-on-error.patch
^ permalink raw reply
* Patch "drm/radeon: drop register readback in cayman_cp_int_cntl_setup" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 8:35 UTC (permalink / raw)
To: dev, alexander.deucher, christian.koenig, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/radeon: drop register readback in cayman_cp_int_cntl_setup
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-radeon-drop-register-readback-in-cayman_cp_int_cntl_setup.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 537b4b462caa8bfb9726d9695b8e56e2d5e6b41e Mon Sep 17 00:00:00 2001
From: Lucas Stach <dev@lynxeye.de>
Date: Mon, 24 Oct 2016 23:32:04 +0200
Subject: drm/radeon: drop register readback in cayman_cp_int_cntl_setup
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Lucas Stach <dev@lynxeye.de>
commit 537b4b462caa8bfb9726d9695b8e56e2d5e6b41e upstream.
The read is taking a considerable amount of time (about 50us on this
machine). The register does not ever hold anything other than the ring
ID that is updated in this exact function, so there is no need for
the read modify write cycle.
This chops off a big chunk of the time spent in hardirq disabled
context, as this function is called multiple times in the interrupt
handler. With this change applied radeon won't show up in the list
of the worst IRQ latency offenders anymore, where it was a regular
before.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/ni.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -1396,9 +1396,7 @@ static void cayman_pcie_gart_fini(struct
void cayman_cp_int_cntl_setup(struct radeon_device *rdev,
int ring, u32 cp_int_cntl)
{
- u32 srbm_gfx_cntl = RREG32(SRBM_GFX_CNTL) & ~3;
-
- WREG32(SRBM_GFX_CNTL, srbm_gfx_cntl | (ring & 3));
+ WREG32(SRBM_GFX_CNTL, RINGID(ring));
WREG32(CP_INT_CNTL, cp_int_cntl);
}
Patches currently in stable-queue which might be from dev@lynxeye.de are
queue-4.4/drm-radeon-drop-register-readback-in-cayman_cp_int_cntl_setup.patch
^ permalink raw reply
* Patch "drm/fb-helper: Keep references for the current set of used connectors" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 8:35 UTC (permalink / raw)
To: ville.syrjala, carlos.santa, chris, daniel.vetter, gregkh, kirill
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/fb-helper: Keep references for the current set of used connectors
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-fb-helper-keep-references-for-the-current-set-of-used-connectors.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From a2889606636d135148de101fe3311dfea67baf1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
Date: Wed, 26 Oct 2016 17:41:18 +0300
Subject: drm/fb-helper: Keep references for the current set of used connectors
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
commit a2889606636d135148de101fe3311dfea67baf1c upstream.
The fbdev helper code keeps around two lists of connectors. One is the
list of all connectors it could use, and that list already holds
references for all the connectors. However the other list, or rather
lists, is the one actively being used. That list is tracked per-crtc
and currently doesn't hold any extra references. Let's grab those
extra references to avoid oopsing when the connector vanishes. The
list of all possible connectors should get updated when the hpd happens,
but the list of actively used connectors would not get updated until
the next time the fb-helper picks through the set of possible connectors.
And so we need to hang on to the connectors until that time.
Since we need to clean up in drm_fb_helper_crtc_free() as well,
let's pull the code to a common place. And while at it let's
pull in up the modeset->mode cleanup in there as well. The case
of modeset->fb is a bit less clear. I'm thinking we should probably
hold a reference to it, but for now I just slapped on a FIXME.
v2: Cleanup things drm_fb_helper_crtc_free() too (Chris)
v3: Don't leak modeset->connectors (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Carlos Santa <carlos.santa@intel.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Tested-by: Carlos Santa <carlos.santa@intel.com> (v1)
Tested-by: Kirill A. Shutemov <kirill@shutemov.name> (v1)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477492878-4990-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_fb_helper.c | 57 +++++++++++++++++++++++-----------------
1 file changed, 33 insertions(+), 24 deletions(-)
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -631,6 +631,24 @@ int drm_fb_helper_blank(int blank, struc
}
EXPORT_SYMBOL(drm_fb_helper_blank);
+static void drm_fb_helper_modeset_release(struct drm_fb_helper *helper,
+ struct drm_mode_set *modeset)
+{
+ int i;
+
+ for (i = 0; i < modeset->num_connectors; i++) {
+ drm_connector_unreference(modeset->connectors[i]);
+ modeset->connectors[i] = NULL;
+ }
+ modeset->num_connectors = 0;
+
+ drm_mode_destroy(helper->dev, modeset->mode);
+ modeset->mode = NULL;
+
+ /* FIXME should hold a ref? */
+ modeset->fb = NULL;
+}
+
static void drm_fb_helper_crtc_free(struct drm_fb_helper *helper)
{
int i;
@@ -638,10 +656,12 @@ static void drm_fb_helper_crtc_free(stru
for (i = 0; i < helper->connector_count; i++)
kfree(helper->connector_info[i]);
kfree(helper->connector_info);
+
for (i = 0; i < helper->crtc_count; i++) {
- kfree(helper->crtc_info[i].mode_set.connectors);
- if (helper->crtc_info[i].mode_set.mode)
- drm_mode_destroy(helper->dev, helper->crtc_info[i].mode_set.mode);
+ struct drm_mode_set *modeset = &helper->crtc_info[i].mode_set;
+
+ drm_fb_helper_modeset_release(helper, modeset);
+ kfree(modeset->connectors);
}
kfree(helper->crtc_info);
}
@@ -1983,7 +2003,6 @@ static void drm_setup_crtcs(struct drm_f
struct drm_fb_helper_crtc **crtcs;
struct drm_display_mode **modes;
struct drm_fb_offset *offsets;
- struct drm_mode_set *modeset;
bool *enabled;
int width, height;
int i;
@@ -2031,45 +2050,35 @@ static void drm_setup_crtcs(struct drm_f
/* need to set the modesets up here for use later */
/* fill out the connector<->crtc mappings into the modesets */
- for (i = 0; i < fb_helper->crtc_count; i++) {
- modeset = &fb_helper->crtc_info[i].mode_set;
- modeset->num_connectors = 0;
- modeset->fb = NULL;
- }
+ for (i = 0; i < fb_helper->crtc_count; i++)
+ drm_fb_helper_modeset_release(fb_helper,
+ &fb_helper->crtc_info[i].mode_set);
for (i = 0; i < fb_helper->connector_count; i++) {
struct drm_display_mode *mode = modes[i];
struct drm_fb_helper_crtc *fb_crtc = crtcs[i];
struct drm_fb_offset *offset = &offsets[i];
- modeset = &fb_crtc->mode_set;
+ struct drm_mode_set *modeset = &fb_crtc->mode_set;
if (mode && fb_crtc) {
+ struct drm_connector *connector =
+ fb_helper->connector_info[i]->connector;
+
DRM_DEBUG_KMS("desired mode %s set on crtc %d (%d,%d)\n",
mode->name, fb_crtc->mode_set.crtc->base.id, offset->x, offset->y);
+
fb_crtc->desired_mode = mode;
fb_crtc->x = offset->x;
fb_crtc->y = offset->y;
- if (modeset->mode)
- drm_mode_destroy(dev, modeset->mode);
modeset->mode = drm_mode_duplicate(dev,
fb_crtc->desired_mode);
- modeset->connectors[modeset->num_connectors++] = fb_helper->connector_info[i]->connector;
+ drm_connector_reference(connector);
+ modeset->connectors[modeset->num_connectors++] = connector;
modeset->fb = fb_helper->fb;
modeset->x = offset->x;
modeset->y = offset->y;
}
}
-
- /* Clear out any old modes if there are no more connected outputs. */
- for (i = 0; i < fb_helper->crtc_count; i++) {
- modeset = &fb_helper->crtc_info[i].mode_set;
- if (modeset->num_connectors == 0) {
- BUG_ON(modeset->fb);
- if (modeset->mode)
- drm_mode_destroy(dev, modeset->mode);
- modeset->mode = NULL;
- }
- }
out:
kfree(crtcs);
kfree(modes);
Patches currently in stable-queue which might be from ville.syrjala@linux.intel.com are
queue-4.4/usb-gadget-function-u_ether-don-t-starve-tx-request-queue.patch
queue-4.4/drm-i915-clean-up-ddi-ddc-aux-ch-sanitation.patch
queue-4.4/drm-dp-mst-check-peer-device-type-before-attempting-edid-read.patch
queue-4.4/drm-fb-helper-keep-references-for-the-current-set-of-used-connectors.patch
queue-4.4/drm-dp-mst-clear-port-pdt-when-tearing-down-the-i2c-adapter.patch
queue-4.4/drm-fb-helper-fix-connector-ref-leak-on-error.patch
^ permalink raw reply
* Patch "drm/fb-helper: Fix connector ref leak on error" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 8:35 UTC (permalink / raw)
To: ville.syrjala, carlos.santa, chris, daniel.vetter, gregkh, kirill
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/fb-helper: Fix connector ref leak on error
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-fb-helper-fix-connector-ref-leak-on-error.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 7dfcb36a1f17e4c7c7c12b9d8a6902037c7d98dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
Date: Wed, 26 Oct 2016 12:05:52 +0300
Subject: drm/fb-helper: Fix connector ref leak on error
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
commit 7dfcb36a1f17e4c7c7c12b9d8a6902037c7d98dc upstream.
We need to drop the connector references already taken when we
abort in the middle of drm_fb_helper_single_add_all_connectors()
Cc: Carlos Santa <carlos.santa@intel.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Tested-by: Carlos Santa <carlos.santa@intel.com>
Tested-by: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477472755-15288-2-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_fb_helper.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -124,7 +124,12 @@ int drm_fb_helper_single_add_all_connect
return 0;
fail:
for (i = 0; i < fb_helper->connector_count; i++) {
- kfree(fb_helper->connector_info[i]);
+ struct drm_fb_helper_connector *fb_helper_connector =
+ fb_helper->connector_info[i];
+
+ drm_connector_unreference(fb_helper_connector->connector);
+
+ kfree(fb_helper_connector);
fb_helper->connector_info[i] = NULL;
}
fb_helper->connector_count = 0;
Patches currently in stable-queue which might be from ville.syrjala@linux.intel.com are
queue-4.4/usb-gadget-function-u_ether-don-t-starve-tx-request-queue.patch
queue-4.4/drm-i915-clean-up-ddi-ddc-aux-ch-sanitation.patch
queue-4.4/drm-dp-mst-check-peer-device-type-before-attempting-edid-read.patch
queue-4.4/drm-fb-helper-keep-references-for-the-current-set-of-used-connectors.patch
queue-4.4/drm-dp-mst-clear-port-pdt-when-tearing-down-the-i2c-adapter.patch
queue-4.4/drm-fb-helper-fix-connector-ref-leak-on-error.patch
^ permalink raw reply
* Patch "drm/dp/mst: Check peer device type before attempting EDID read" has been added to the 4.4-stable tree
From: gregkh @ 2016-11-09 8:35 UTC (permalink / raw)
To: ville.syrjala, carlos.santa, daniel.vetter, gregkh, kirill
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/dp/mst: Check peer device type before attempting EDID read
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-dp-mst-check-peer-device-type-before-attempting-edid-read.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 4da5caa6a6f82cda3193bca855235b87debf78bd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
Date: Wed, 26 Oct 2016 12:05:55 +0300
Subject: drm/dp/mst: Check peer device type before attempting EDID read
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
commit 4da5caa6a6f82cda3193bca855235b87debf78bd upstream.
Only certain types of pdts have the DDC bus registered, so check for
that before we attempt the EDID read. Othwewise we risk playing around
with an i2c adapter that doesn't actually exist.
Cc: Carlos Santa <carlos.santa@intel.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Tested-by: Carlos Santa <carlos.santa@intel.com>
Tested-by: Kirill A. Shutemov <kirill@shutemov.name>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477472755-15288-5-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_dp_mst_topology.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1155,7 +1155,9 @@ static void drm_dp_add_port(struct drm_d
drm_dp_put_port(port);
goto out;
}
- if (port->port_num >= DP_MST_LOGICAL_PORT_0) {
+ if ((port->pdt == DP_PEER_DEVICE_DP_LEGACY_CONV ||
+ port->pdt == DP_PEER_DEVICE_SST_SINK) &&
+ port->port_num >= DP_MST_LOGICAL_PORT_0) {
port->cached_edid = drm_get_edid(port->connector, &port->aux.ddc);
drm_mode_connector_set_tile_property(port->connector);
}
Patches currently in stable-queue which might be from ville.syrjala@linux.intel.com are
queue-4.4/usb-gadget-function-u_ether-don-t-starve-tx-request-queue.patch
queue-4.4/drm-i915-clean-up-ddi-ddc-aux-ch-sanitation.patch
queue-4.4/drm-dp-mst-check-peer-device-type-before-attempting-edid-read.patch
queue-4.4/drm-fb-helper-keep-references-for-the-current-set-of-used-connectors.patch
queue-4.4/drm-dp-mst-clear-port-pdt-when-tearing-down-the-i2c-adapter.patch
queue-4.4/drm-fb-helper-fix-connector-ref-leak-on-error.patch
^ permalink raw reply
* Re: perf buildfix for 4.4 -longterm...
From: Greg KH @ 2016-11-09 8:34 UTC (permalink / raw)
To: Thomas Backlund; +Cc: stable
In-Reply-To: <e90969c3-ed81-1c7a-0ff4-8a2140899322@mageia.org>
On Sat, Nov 05, 2016 at 10:13:54AM +0200, Thomas Backlund wrote:
>
> We kept triggering random build failures in perf build in Mageia and I fixed
> it by pulling in this upstream fix:
>
> From 67befc652845c8ffbefc8d173a6e6ced14d472f1 Mon Sep 17 00:00:00 2001
> From: Jiri Olsa <jolsa@kernel.org>
> Date: Thu, 26 Nov 2015 14:54:04 +0100
> Subject: [PATCH] perf build: Fix traceevent plugins build race
>
>
>
> but I forgot to notify stable@ about it, so doing it now :)
>
>
> --
>
> Thomas
Now applied, thanks.
greg k-h
^ permalink raw reply
* Re: [Qemu-devel] [kvm-unit-tests PATCH v4 10/11] arm/arm64: gicv3: add an IPI test
From: Andrew Jones @ 2016-11-09 8:33 UTC (permalink / raw)
To: kvm, kvmarm, qemu-devel, qemu-arm
Cc: pbonzini, andre.przywara, peter.maydell, alex.bennee,
marc.zyngier, eric.auger, christoffer.dall
In-Reply-To: <1478636499-14339-11-git-send-email-drjones@redhat.com>
Argh. I forgot to compile/test arm32/gicv3... Just did now and found
a copy+paste error.
On Tue, Nov 08, 2016 at 09:21:38PM +0100, Andrew Jones wrote:
[...]
> diff --git a/lib/arm/asm/arch_gicv3.h b/lib/arm/asm/arch_gicv3.h
> index 81a1e5f6c29c..cbcec024a2a6 100644
> --- a/lib/arm/asm/arch_gicv3.h
> +++ b/lib/arm/asm/arch_gicv3.h
> @@ -16,10 +16,28 @@
> #define __stringify xstr
>
> #define __ACCESS_CP15(CRn, Op1, CRm, Op2) p15, Op1, %0, CRn, CRm, Op2
> +#define __ACCESS_CP15_64(Op1, CRm) p15, Op1, %Q0, %R0, CRm
>
> +#define ICC_EOIR1 __ACCESS_CP15(c12, 0, c12, 1)
> +#define ICC_IAR1 __ACCESS_CP15(c12, 0, c12, 0)
> +#define ICC_SGI1R __ACCESS_CP15_64(0, c12)
> #define ICC_PMR __ACCESS_CP15(c4, 0, c6, 0)
> #define ICC_IGRPEN1 __ACCESS_CP15(c12, 0, c12, 7)
>
> +static inline void gicv3_write_eoir(u32 irq)
> +{
> + asm volatile("mcr " __stringify(ICC_EOIR1) : : "r" (val));
should be irq ^^
> + isb();
> +}
> +
[...]
I've pushed an arm/gic-v5 branch[*] to github, and removed the broken
arm/gic-v4 branch.
[*] https://github.com/rhdrjones/kvm-unit-tests/commits/arm/gic-v5
drew
^ permalink raw reply
* Re: [PATCH v2 2/3] 99base: apply kernel module memory debug support
From: Dave Young @ 2016-11-09 8:33 UTC (permalink / raw)
To: Xunlei Pang
Cc: Harald Hoyer, initramfs-u79uwXL29TY76Z2rM5mHXA, Pratush Panand
In-Reply-To: <1478496876-17580-2-git-send-email-xlpang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Hi, Xunlei
On 11/07/16 at 01:34pm, Xunlei Pang wrote:
> Extend "rd.memdebug" to "4", and "make_trace_mem" to "4+:komem".
> Add new "cleanup_trace_mem" to cleanup the trace if active.
>
> Signed-off-by: Xunlei Pang <xlpang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> modules.d/98dracut-systemd/dracut-cmdline.sh | 2 +-
> modules.d/98dracut-systemd/dracut-pre-mount.sh | 2 +-
> modules.d/98dracut-systemd/dracut-pre-pivot.sh | 3 ++-
> modules.d/98dracut-systemd/dracut-pre-trigger.sh | 2 +-
> modules.d/99base/dracut-lib.sh | 13 ++++++++++++-
> modules.d/99base/init.sh | 9 +++++----
> modules.d/99base/module-setup.sh | 1 +
> 7 files changed, 23 insertions(+), 9 deletions(-)
>
> diff --git a/modules.d/98dracut-systemd/dracut-cmdline.sh b/modules.d/98dracut-systemd/dracut-cmdline.sh
> index 6c6ee02..bff9435 100755
> --- a/modules.d/98dracut-systemd/dracut-cmdline.sh
> +++ b/modules.d/98dracut-systemd/dracut-cmdline.sh
> @@ -42,7 +42,7 @@ export root
> export rflags
> export fstype
>
> -make_trace_mem "hook cmdline" '1+:mem' '1+:iomem' '3+:slab'
> +make_trace_mem "hook cmdline" '1+:mem' '1+:iomem' '3+:slab' '4+:komem'
> # run scriptlets to parse the command line
> getarg 'rd.break=cmdline' -d 'rdbreak=cmdline' && emergency_shell -n cmdline "Break before cmdline"
> source_hook cmdline
> diff --git a/modules.d/98dracut-systemd/dracut-pre-mount.sh b/modules.d/98dracut-systemd/dracut-pre-mount.sh
> index ae51128..a3b9d29 100755
> --- a/modules.d/98dracut-systemd/dracut-pre-mount.sh
> +++ b/modules.d/98dracut-systemd/dracut-pre-mount.sh
> @@ -8,7 +8,7 @@ type getarg >/dev/null 2>&1 || . /lib/dracut-lib.sh
>
> source_conf /etc/conf.d
>
> -make_trace_mem "hook pre-mount" '1:shortmem' '2+:mem' '3+:slab'
> +make_trace_mem "hook pre-mount" '1:shortmem' '2+:mem' '3+:slab' '4+:komem'
> # pre pivot scripts are sourced just before we doing cleanup and switch over
> # to the new root.
> getarg 'rd.break=pre-mount' 'rdbreak=pre-mount' && emergency_shell -n pre-mount "Break pre-mount"
> diff --git a/modules.d/98dracut-systemd/dracut-pre-pivot.sh b/modules.d/98dracut-systemd/dracut-pre-pivot.sh
> index cc70e3c..dc9a250 100755
> --- a/modules.d/98dracut-systemd/dracut-pre-pivot.sh
> +++ b/modules.d/98dracut-systemd/dracut-pre-pivot.sh
> @@ -8,12 +8,13 @@ type getarg >/dev/null 2>&1 || . /lib/dracut-lib.sh
>
> source_conf /etc/conf.d
>
> -make_trace_mem "hook pre-pivot" '1:shortmem' '2+:mem' '3+:slab'
> +make_trace_mem "hook pre-pivot" '1:shortmem' '2+:mem' '3+:slab' '4+:komem'
> # pre pivot scripts are sourced just before we doing cleanup and switch over
> # to the new root.
> getarg 'rd.break=pre-pivot' 'rdbreak=pre-pivot' && emergency_shell -n pre-pivot "Break pre-pivot"
> source_hook pre-pivot
>
> +cleanup_trace_mem
> # pre pivot cleanup scripts are sourced just before we switch over to the new root.
> getarg 'rd.break=cleanup' 'rdbreak=cleanup' && emergency_shell -n cleanup "Break cleanup"
> source_hook cleanup
> diff --git a/modules.d/98dracut-systemd/dracut-pre-trigger.sh b/modules.d/98dracut-systemd/dracut-pre-trigger.sh
> index ac1ec36..7cd821e 100755
> --- a/modules.d/98dracut-systemd/dracut-pre-trigger.sh
> +++ b/modules.d/98dracut-systemd/dracut-pre-trigger.sh
> @@ -8,7 +8,7 @@ type getarg >/dev/null 2>&1 || . /lib/dracut-lib.sh
>
> source_conf /etc/conf.d
>
> -make_trace_mem "hook pre-trigger" "1:shortmem" "2+:mem" "3+:slab"
> +make_trace_mem "hook pre-trigger" '1:shortmem' '2+:mem' '3+:slab' '4+:komem'
>
> source_hook pre-trigger
>
> diff --git a/modules.d/99base/dracut-lib.sh b/modules.d/99base/dracut-lib.sh
> index 060b3fe..2a29bbc 100755
> --- a/modules.d/99base/dracut-lib.sh
> +++ b/modules.d/99base/dracut-lib.sh
> @@ -1206,12 +1206,20 @@ are_lists_eq() {
>
> setmemdebug() {
> if [ -z "$DEBUG_MEM_LEVEL" ]; then
> - export DEBUG_MEM_LEVEL=$(getargnum 0 0 3 rd.memdebug)
> + export DEBUG_MEM_LEVEL=$(getargnum 0 0 4 rd.memdebug)
> fi
> }
>
> setmemdebug
>
> +cleanup_trace_mem()
> +{
> + # tracekomem based on kernel trace needs cleanup after use.
> + if [[ $DEBUG_MEM_LEVEL -eq 4 ]]; then
It does not work if out of tree modules add it to DEBUG_MEM_LEVEL <
4, sounds bad to hard code it. It seems good to do the cleanup without
the check.
There is another concern, if someone manually enables tracing in kernel
cmdline then we should not cleanup, maybe we can print a warning msg
and do not do our tracing at all.
For cleanup and prepare ideally we can do something like make_trace_mem,
like prepare_trace_mem and cleanup_trace_mem, for each facility if there
is a prepare/cleanup function then call it. But for the time being it
may not worth to add the complexity. What do you think?
> + tracekomem --cleanup
> + fi
> +}
> +
> # parameters: msg [trace_level:trace]...
> make_trace_mem()
> {
> @@ -1296,6 +1304,9 @@ show_memstats()
> iomem)
> cat /proc/iomem
> ;;
> + komem)
> + tracekomem
> + ;;
> esac
> }
>
> diff --git a/modules.d/99base/init.sh b/modules.d/99base/init.sh
> index a563393..e4f7cff 100755
> --- a/modules.d/99base/init.sh
> +++ b/modules.d/99base/init.sh
> @@ -131,7 +131,7 @@ if ! getargbool 1 'rd.hostonly'; then
> fi
>
> # run scriptlets to parse the command line
> -make_trace_mem "hook cmdline" '1+:mem' '1+:iomem' '3+:slab'
> +make_trace_mem "hook cmdline" '1+:mem' '1+:iomem' '3+:slab' '4+:komem'
> getarg 'rd.break=cmdline' -d 'rdbreak=cmdline' && emergency_shell -n cmdline "Break before cmdline"
> source_hook cmdline
>
> @@ -160,7 +160,7 @@ fi
>
> udevproperty "hookdir=$hookdir"
>
> -make_trace_mem "hook pre-trigger" '1:shortmem' '2+:mem' '3+:slab'
> +make_trace_mem "hook pre-trigger" '1:shortmem' '2+:mem' '3+:slab' '4+:komem'
> getarg 'rd.break=pre-trigger' -d 'rdbreak=pre-trigger' && emergency_shell -n pre-trigger "Break before pre-trigger"
> source_hook pre-trigger
>
> @@ -230,7 +230,7 @@ unset RDRETRY
>
> # pre-mount happens before we try to mount the root filesystem,
> # and happens once.
> -make_trace_mem "hook pre-mount" '1:shortmem' '2+:mem' '3+:slab'
> +make_trace_mem "hook pre-mount" '1:shortmem' '2+:mem' '3+:slab' '4+:komem'
> getarg 'rd.break=pre-mount' -d 'rdbreak=pre-mount' && emergency_shell -n pre-mount "Break pre-mount"
> source_hook pre-mount
>
> @@ -266,11 +266,12 @@ done
>
> # pre pivot scripts are sourced just before we doing cleanup and switch over
> # to the new root.
> -make_trace_mem "hook pre-pivot" '1:shortmem' '2+:mem' '3+:slab'
> +make_trace_mem "hook pre-pivot" '1:shortmem' '2+:mem' '3+:slab' '4+:komem'
> getarg 'rd.break=pre-pivot' -d 'rdbreak=pre-pivot' && emergency_shell -n pre-pivot "Break pre-pivot"
> source_hook pre-pivot
>
> make_trace_mem "hook cleanup" '1:shortmem' '2+:mem' '3+:slab'
> +cleanup_trace_mem
> # pre pivot cleanup scripts are sourced just before we switch over to the new root.
> getarg 'rd.break=cleanup' -d 'rdbreak=cleanup' && emergency_shell -n cleanup "Break cleanup"
> source_hook cleanup
> diff --git a/modules.d/99base/module-setup.sh b/modules.d/99base/module-setup.sh
> index b03772e..a1569b1 100755
> --- a/modules.d/99base/module-setup.sh
> +++ b/modules.d/99base/module-setup.sh
> @@ -35,6 +35,7 @@ install() {
> inst_script "$moddir/initqueue.sh" "/sbin/initqueue"
> inst_script "$moddir/loginit.sh" "/sbin/loginit"
> inst_script "$moddir/rdsosreport.sh" "/sbin/rdsosreport"
> + inst_script "$moddir/memtrace-ko.sh" "/sbin/tracekomem"
>
> [ -e "${initdir}/lib" ] || mkdir -m 0755 -p ${initdir}/lib
> mkdir -m 0755 -p ${initdir}/lib/dracut
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks
Dave
^ permalink raw reply
* Re: [kvm-unit-tests PATCH v4 10/11] arm/arm64: gicv3: add an IPI test
From: Andrew Jones @ 2016-11-09 8:33 UTC (permalink / raw)
To: kvm, kvmarm, qemu-devel, qemu-arm
Cc: pbonzini, andre.przywara, peter.maydell, alex.bennee,
marc.zyngier, eric.auger, christoffer.dall
In-Reply-To: <1478636499-14339-11-git-send-email-drjones@redhat.com>
Argh. I forgot to compile/test arm32/gicv3... Just did now and found
a copy+paste error.
On Tue, Nov 08, 2016 at 09:21:38PM +0100, Andrew Jones wrote:
[...]
> diff --git a/lib/arm/asm/arch_gicv3.h b/lib/arm/asm/arch_gicv3.h
> index 81a1e5f6c29c..cbcec024a2a6 100644
> --- a/lib/arm/asm/arch_gicv3.h
> +++ b/lib/arm/asm/arch_gicv3.h
> @@ -16,10 +16,28 @@
> #define __stringify xstr
>
> #define __ACCESS_CP15(CRn, Op1, CRm, Op2) p15, Op1, %0, CRn, CRm, Op2
> +#define __ACCESS_CP15_64(Op1, CRm) p15, Op1, %Q0, %R0, CRm
>
> +#define ICC_EOIR1 __ACCESS_CP15(c12, 0, c12, 1)
> +#define ICC_IAR1 __ACCESS_CP15(c12, 0, c12, 0)
> +#define ICC_SGI1R __ACCESS_CP15_64(0, c12)
> #define ICC_PMR __ACCESS_CP15(c4, 0, c6, 0)
> #define ICC_IGRPEN1 __ACCESS_CP15(c12, 0, c12, 7)
>
> +static inline void gicv3_write_eoir(u32 irq)
> +{
> + asm volatile("mcr " __stringify(ICC_EOIR1) : : "r" (val));
should be irq ^^
> + isb();
> +}
> +
[...]
I've pushed an arm/gic-v5 branch[*] to github, and removed the broken
arm/gic-v4 branch.
[*] https://github.com/rhdrjones/kvm-unit-tests/commits/arm/gic-v5
drew
^ permalink raw reply
* [PATCH] drm/i915/audio: fix hdmi audio noise issue
From: libin.yang @ 2016-11-09 8:27 UTC (permalink / raw)
To: intel-gfx, jani.nikula, ville.syrjala, daniel.vetter, tiwai
From: Libin Yang <libin.yang@intel.com>
This issue is caused by:
6014ac12: drm/i915/audio: set proper N/M in modeset
Some special monitors will have noise or even no sound after
applying the patch 6014ac12.
In patch 6014ac12, it will reset the cts value to 0 for HDMI.
However, we need disable Enable CTS or M Prog bit. This is
the initial setting after HW reset.
Signed-off-by: Libin Yang <libin.yang@intel.com>
---
drivers/gpu/drm/i915/intel_audio.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c
index 813fd74..a472d35 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -332,6 +332,13 @@ hsw_hdmi_audio_config_update(struct intel_crtc *intel_crtc, enum port port,
int n;
u32 tmp;
+ /* reset CTS value to 0 */
+ tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe));
+ tmp &= ~AUD_CONFIG_M_MASK;
+ tmp &= ~AUD_M_CTS_M_VALUE_INDEX;
+ tmp |= AUD_M_CTS_M_PROG_ENABLE;
+ I915_WRITE(HSW_AUD_M_CTS_ENABLE(pipe), tmp);
+
tmp = I915_READ(HSW_AUD_CFG(pipe));
tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
@@ -351,10 +358,12 @@ hsw_hdmi_audio_config_update(struct intel_crtc *intel_crtc, enum port port,
I915_WRITE(HSW_AUD_CFG(pipe), tmp);
+ /*
+ * Let's disable "Enable CTS or M Prog bit"
+ * and let HW calculate the value
+ */
tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe));
- tmp &= ~AUD_CONFIG_M_MASK;
- tmp &= ~AUD_M_CTS_M_VALUE_INDEX;
- tmp |= AUD_M_CTS_M_PROG_ENABLE;
+ tmp &= ~AUD_M_CTS_M_PROG_ENABLE;
I915_WRITE(HSW_AUD_M_CTS_ENABLE(pipe), tmp);
}
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [PATCH nf] netfilter: xt_NFLOG: fix unexpected truncated packet
From: Greg Kroah-Hartman @ 2016-11-09 8:32 UTC (permalink / raw)
To: Chris Caputo
Cc: Liping Zhang, Pablo Neira Ayuso, Liping Zhang,
Netfilter Developer Mailing List, Justin Piszcz, Vishwanath Pai,
Liping Zhang
In-Reply-To: <Pine.LNX.4.64.1610300318300.21786@nacho.alt.net>
On Sun, Oct 30, 2016 at 03:20:25AM +0000, Chris Caputo wrote:
> On Sun, 30 Oct 2016, Liping Zhang wrote:
> > 2016-10-30 3:04 GMT+08:00 Chris Caputo <ccaputo@alt.net>:
> > > Can we get this patch approved? It is definitely needed for the 4.8.x
> > > tree and 4.9-rcX and mainline.
> >
> > This patch was already applied, and was upstream to net.git:
> > https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=6d19375b58763fefc2f215fb45117d3353ced888
> >
> > I think you will see this patch in mainline soon.
>
> Greg, any chance this could be picked up for 4.8.6? (apologies if I am
> out of line)
Looks good, now queued up.
thanks,
greg k-h
^ permalink raw reply
* Re: [Qemu-devel] [virtio-comment] Re: [PATCH v1] docs/vhost-user: extend the vhost-user protocol to support the vhost-pci based inter-vm communication
From: Wei Wang @ 2016-11-09 8:32 UTC (permalink / raw)
To: Marc-André Lureau
Cc: virtio-comment, qemu-devel, mst, stefanha, pbonzini
In-Reply-To: <CAJ+F1CJPLtV3WB5JT61H0zfuun1tn=ALt6QzEPjcUU4G=CxXmA@mail.gmail.com>
On 11/08/2016 08:17 PM, Marc-André Lureau wrote:
> >
>
> > Message Specification
> > ---------------------
> >
> > Note that all numbers are in the machine native byte order. A
> > vhost-user message
> > -consists of 3 header fields and a payload:
> > +consists of 4 header fields and a payload:
> >
> > -------------------------------------
> > -| request | flags | size | payload |
> > -------------------------------------
> > +----------------------------------------------
> > +| request | flags | conn_id | size | payload |
> > +----------------------------------------------
> >
> > * Request: 32-bit type of the request
> > * Flags: 32-bit bit field:
> > - Lower 2 bits are the version (currently 0x01)
> > - - Bit 2 is the reply flag - needs to be sent on each reply
> > from the slave
> > + - Bit 2 is the reply flag - needs to be sent on each reply
> > - Bit 3 is the need_reply flag - see
> > VHOST_USER_PROTOCOL_F_REPLY_ACK for
> > details.
> > + * Conn_id: 64-bit connection id to indentify a client socket
> > connection. It is
> > + introduced in version 0x02 to support the
> > "1-server-N-client" model
> > + and an asynchronous client read implementation. The
> > connection id,
> > + 0xFFFFFFFFFFFFFFFF, is used by an anonymous client
> > (e.g. a client who
> > + has not got its connection id from the server
> in the
> > initial talk)
> >
> >
> > I don't understand why you need a connection id, on each message.
> > What's the purpose? Since the communication is unicast, a single
> > message should be enough.
>
> Sure, please let me explain more:
> The QEMU socket is going to be upgraded to support 1 server socket
> being
> connected by multiple client sockets (I've made patches to achieve
> this). In other words, here, multiple masters will connect to one
> slave,
> and the slave creates a vhost-pci device for each master after
> receiving
> the necessary message info. The slave needs to know which master it is
> talking to when receiving a message, as it maintains multiple
> connections at the same time.
>
>
> You should be able to identify each connection in the slave (as a
> socket server), without a need for connection id: connected sockets
> are independent from each others.
Yes, that's doable. But why couldn't we do it from the protocol layer? I
think it will be easier.
Please check below my thoughts about the implementation if we do it in
the slave:
The interface for receiving a msg is - tcp_chr_read(QIOChannel *chan,
GIOCondition cond, void *opaque)
QIOChannel is the one that we can use to identify the master connection
who sends this msg (the socket server now has an array of QIOChannel,
ioc[MAX_CLIENTS]). Everytime a msg is received, the tcp_chr_read() needs
to compare *chan and the ioc[] array, to find out the id (indexed into
the ioc[]), and passes the id to qemu_chr_be_write(), and all the way
down to the final slave handler where the msg is parsed and handled.
This needs modifications to the existing APIs, for example, the
mentioned qemu_chr_be_write() will need one more parameter, "id". This
will not be compatible with the existing implementation, because all
other implementations which invoke qemu_chr_be_write() will need to be
patched to use the new qemu_chr_be_write(,"id",).
> > * Size - 32-bit size of the payload
> >
> >
> > @@ -97,6 +106,13 @@ Depending on the request type, payload
> can be:
> > log offset: offset from start of supplied file descriptor
> > where logging starts (i.e. where guest address 0
> would be
> > logged)
> >
> > +* Device info
> > + --------------------
> > + | virito id | uuid |
> > + --------------------
> > + Virtio id: 16-bit virtio id of the device
> > + UUID: 128-bit UUID to identify the QEMU instance that
> creates
> > the device
> > +
> >
> >
> > I wonder if UUID should be a different message.
> >
> We can make uuid another message if it has other usages.
> Do you see any other usages of uuid?
>
>
> Allows to associate data/configuration with a particular VM, in a
> multi-master/single-slave scenario. But tbh, I don't see how this is
> necessary, I can imagine solving this differently (having different
> connection address per vm for ex).
Using connection addresses, how could you know if the two connections
are from the same VM?
> I would like to understand your use case.
Here is an example of the use case:
VM1 has two master connections (connection X and Y) and VM2 has 1 master
connection (Z).
X,Y,Z - each has a connection id. But X and Y send the same uuid, uuid1,
to the slave, and Z sends uuid2 to the slave. In this way, the slave
know X and Y are the two connections from the same VM, and Z is a
connection from a different VM.
For connection Y, the vhost-pci device will be created in a way which
does not need the driver to map the memory, since it has already been
mapped by device X from the same VM.
>
>
> > [ Also see the section on REPLY_ACK protocol extension. ]
> >
> > +Currently, the communication also supports the Slave (server)
> > sending messages
> > +to the Master (client). Here is a list of them:
> > + * VHOST_USER_SET_FEATURES
> >
> > + * VHOST_USER_SET_PEER_CONNECTION (the serve may actively
> request
> > to disconnect
> > + with the client)
> >
> >
> > Oh, you are making the communication bidirectional? This is a
> > fundamental change in the protocol. This may be difficult to
> implement
> > in qemu, since the communication in synchronous, a request
> expects an
> > immediate reply, if it gets back a request (from the slave) in the
> > middle, it will fail.
> >
>
> Not really.
> Adding the above two doesn't affect the existing synchronous read()
> messages (basically, those VHOST_USER_GET_xx messages). Like
> VHOST_USER_SET_FEATURES, the _SET_ messages don't need a reply.
> Here, we
> just make the slave capable of actively sending messages to the
> master.
>
>
> Yes, that's the trouble. At any time the Master may send a request and
> expects an immediate reply. There is a race of getting a request from
> the Slave in the middle with your proposed change. I'd rather avoid
> making the request bidirectionnal if possible. (I proposed a second
> channel for Slave->Master request in the past:
> https://lists.gnu.org/archive/html/qemu-devel/2016-04/msg00095.html)
If the message that the slave got has a different "request" field
value, it simply drops it and re-read again. The implementation is not
complex also, please see the change example to vhost_user_get_u64() below:
if (vhost_user_write(dev, &msg_w, NULL, 0) < 0) {
return -1;
}
retry:
if (vhost_user_read(dev, &msg_r) < 0) {
return -1;
}
if (msg_r.request != msg_w.request)
goto retry;
On the other side, the slave's request to the master is dropped due to
the race. This race can be solved in the protocol layer - let the _SET_
request ask for an ACK, if no ACK is received, re-sent it. Also, this
kind of race should be very rare in real usage.
>
> >
> > +This request should be sent only when
> VHOST_USER_PROTOCOL_F_VHOST_PCI
> > has...
> >
> > +* VHOST_USER_SET_DEV_INFO
> > +
> > + Id: 21
> > + Equivalent ioctl: N/A
> > + Master payload: dev info
> > +
> > + The client sends the producer device info to the server.
> >
> >
> > "Master sends producer device info to the Slave" works, no?
>
> Yes, it works. The current dev info only contains a "virtio id" field
> (assume we'll take uuid out as a separate message), which tells the
> slave if it is a net, scsi, console or else. do you see any issue?
> >
> > Could we guarantee this message is sent before SET_VRING*?
>
> Why do we need to guarantee this?
>
>
> It would simplify the protocol to have expectations on when messages
> come. In particular, an early message with devinfo would allow to
> check/pre-configure the Slave for a particular device. Also
> VHOST_USER_SET_DEV_INFO should probably be unique (don't allow a
> device to be reconfigured)
Yes, it is sent in an early age of the vhost-user protocol interaction.
It's implemented to be sent right after sending the
VHOST_USER_SET_PROTOCOL_FEATURES msg. On the slave side, when it
receives SET_DEV_INFO, it pre-configures the device in a table entry (as
mentioned before, a device will be created from the table entry at a
later stage of the protocol interaction).
I think it should be the implementation logic, like
VHOST_USER_SET_PROTOCOL_FEATURES. why do we need to add a guarantee in
the protocol to specify the order?
>
>
> >
> > + This request should be sent only when
> > VHOST_USER_PROTOCOL_F_VHOST_PCI has
> > + been negotiated.
> > +
> >
> >
> > I think this message could be useful for other purposes than
> > vhost-pci, thus I would give it its own flag.
>
> Could you please give an example of other usage? Thanks.
>
>
> You could have a Slave that implements various devices, and pick the
> corresponding one dynamically (we already have implementations for
> net/input/gpu/scsi...)
If I understand the example correctly, the various devices still belongs
to the vhost-pci series - in the future we would have vhost-pci-net,
vhost-pci-scsi, vhost-pci-gpu etc. If that's the case, we may still use
the VHOST_PCI flag.
>
> >
> > +* VHOST_USER_SET_PEER_CONNECTION
> > +
> > + Id: 22
> > + Equivalent ioctl: N/A
> > + Master payload: u64
> > +
> > + The producer device requests to connect or disconnect to
> > the consumer device.
> >
> >
> > producer->Master, consummer->Slave
> >
> > How does it interact with SET_VRING_ENABLE?
>
> It's independent of SET_VRING_ENABLE:
> SET_VRING_ENABLE enables a virtq to be in "active".
> SET_PEER_CONNECTION enables the peer (slave or master) device to be in
> "active". The driver shouldn't send packets if the device is inactive.
>
>
> I fail to see the difference with SET_VRING_ENABLE, perhaps someone
> more familiar with the protocol could help here.
I'm not sure if another email explaning this was sent out successfully,
repost the explanation here:
The SET_PEER_CONNECTION msg is ued to turn "ON/OFF" the (slave or
master) device connection status. For example, when the master side VM
wants to turn down, the virtio-net driver sets the virtio-net device's
PEER_CONNECTION status to "OFF" - before this happens, the virtio-net
device needs to sync-up with the vhost-pci-net device first, that is,
sending a VHOST_USER_SET_PEER_CONNECTION(cmd=OFF) msg to the master. In
return (not as a synchronous reply, because it has to sync with the
driver to stop using the slave side resource first), the vhost-pci-net
device sends VHOST_USER_SET_PEER_CONNECTION(cmd=OFF) msg to the slave -
this sets the virtio-net device's PEER_CONNECTION status to "OFF" and
then the virtio driver is ready to unload. (same for the vhost-pci-net
driver to unload)
SET_VRING_ENABLE controls the virtq status - the slave should not use
the virtq if it's not enabled by the master. For example, a device may
have 4 vitrqs, if vq[0].enabled==0, then the slave should not use vitrq 0.
> >
> > + The consumer device may request to disconnect to the producer
> > device. This
> > + request should be sent only when
> > VHOST_USER_PROTOCOL_F_VHOST_PCI has been
> > + negotiated.
> > + Connection request: If the reply message indicates
> > "success", the vhost-pci based
> > + inter-VM communication channel has been established.
> > + Disconnection request: If the reply message indicates
> > "success", the vhost-pci based
> > + inter-VM communication channel has been destroyed.
> > + #define VHOST_USER_SET_PEER_CONNECTION_F_OFF 0
> > + #define VHOST_USER_SET_PEER_CONNECTION_F_ON 1
> > +
> >
> I think it would be better to add one more command here:
> #define VHOST_USER_SET_PEER_CONNECTION_F_INIT 2
>
> The master uses this command to tell the slave it's ready to
> create the
> vhost-pci device. Regarding the implementation, it is put at the
> bottom
> of vhost_net_start() function (when all the vring info have been sent
> and enabled).
>
>
> Do you have WIP branch for qemu vhost-pci? That could help to
> understand the context.
Yes, I can share them.
Best,
Wei
^ permalink raw reply
* Re: CPUID improvements (phase 2) Design Doc
From: Jan Beulich @ 2016-11-09 8:31 UTC (permalink / raw)
To: Andrew Cooper
Cc: Lan Tianyu, Wei Liu, IanJackson, Xen-devel, Joao Martins,
Roger Pau Monne
In-Reply-To: <12b1935f-57b7-3120-63cd-3c188d4caba6@citrix.com>
>>> On 08.11.16 at 19:36, <andrew.cooper3@citrix.com> wrote:
> On 08/11/16 16:32, Jan Beulich wrote:
>>>>> On 08.11.16 at 16:35, <andrew.cooper3@citrix.com> wrote:
>>> Please find inline the design doc for further CPUID improvements, planned for
>>> development during the 4.9 timeframe.
>> Looks good, just a couple of minor remarks.
>>
>>> ## Changes in hypercall behaviour
>>>
>>> During domain construction, some pieces of information critical to the
>>> determination of the domains maximum acceptable CPUID policy are available
>>> right from the very start (Most notably, the HVM and HAP flags from the
>>> `XEN_DOMCTL_createdomain`).
>>>
>>> However, some other parameters are not available at convenient points.
>>>
>>> 1. The disable flag from `XEN_DOMCTL_disable_migrate` is used to set
>>> `d->disable_migrate`, whose only purpose is to avoid the unconditional
>>> clobbering of the Invariant TSC flag. This flag cannot even be queried by
>>> the toolstack once set.
>>>
>>> There are other facilities which should be restricted based on whether a
>>> VM might migrate or not. (e.g. The use of LBR, whose record format is
>>> hardware specific.)
>> Not really - the LBR format only limits the set of hosts the VM can
>> migrate to. I.e. this is just like a CPUID flag which needs to be set
>> on the target host in order for the VM to be permitted to migrate
>> there.
>
> It is more complicated than that. The LBR format also depends on
> whether TSX is enabled or not, which on Haswell-WS CPUs depends on
> whether hyperthreading is enabled.
Yes, but is this relevant? It's still only a value (identifying the format)
which needs to match between source and destination hosts. I.e. not
different from individual feature bits, just that here we're dealing with
a multi-bit entity.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH] control.rst: improve the queryctrl code examples
From: Hans Verkuil @ 2016-11-09 8:31 UTC (permalink / raw)
To: Linux Media Mailing List
The code examples on how to enumerate controls were really long in the
tooth. Update them.
Using FLAG_NEXT_CTRL is preferred these days, so give that example first.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
diff --git a/Documentation/media/uapi/v4l/control.rst b/Documentation/media/uapi/v4l/control.rst
index d3f1450..51112ba 100644
--- a/Documentation/media/uapi/v4l/control.rst
+++ b/Documentation/media/uapi/v4l/control.rst
@@ -312,21 +312,20 @@ more menu type controls.
.. _enum_all_controls:
-Example: Enumerating all user controls
-======================================
+Example: Enumerating all controls
+=================================
.. code-block:: c
-
struct v4l2_queryctrl queryctrl;
struct v4l2_querymenu querymenu;
- static void enumerate_menu(void)
+ static void enumerate_menu(__u32 id)
{
printf(" Menu items:\\n");
memset(&querymenu, 0, sizeof(querymenu));
- querymenu.id = queryctrl.id;
+ querymenu.id = id;
for (querymenu.index = queryctrl.minimum;
querymenu.index <= queryctrl.maximum;
@@ -339,6 +338,55 @@ Example: Enumerating all user controls
memset(&queryctrl, 0, sizeof(queryctrl));
+ queryctrl.id = V4L2_CTRL_FLAG_NEXT_CTRL;
+ while (0 == ioctl(fd, VIDIOC_QUERYCTRL, &queryctrl)) {
+ if (!(queryctrl.flags & V4L2_CTRL_FLAG_DISABLED)) {
+ printf("Control %s\\n", queryctrl.name);
+
+ if (queryctrl.type == V4L2_CTRL_TYPE_MENU)
+ enumerate_menu(queryctrl.id);
+ }
+
+ queryctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL;
+ }
+ if (errno != EINVAL) {
+ perror("VIDIOC_QUERYCTRL");
+ exit(EXIT_FAILURE);
+ }
+
+Example: Enumerating all controls including compound controls
+=============================================================
+
+.. code-block:: c
+
+ struct v4l2_query_ext_ctrl query_ext_ctrl;
+
+ memset(&query_ext_ctrl, 0, sizeof(query_ext_ctrl));
+
+ query_ext_ctrl.id = V4L2_CTRL_FLAG_NEXT_CTRL | V4L2_CTRL_FLAG_NEXT_COMPOUND;
+ while (0 == ioctl(fd, VIDIOC_QUERY_EXT_CTRL, &query_ext_ctrl)) {
+ if (!(query_ext_ctrl.flags & V4L2_CTRL_FLAG_DISABLED)) {
+ printf("Control %s\\n", query_ext_ctrl.name);
+
+ if (query_ext_ctrl.type == V4L2_CTRL_TYPE_MENU)
+ enumerate_menu(query_ext_ctrl.id);
+ }
+
+ query_ext_ctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL | V4L2_CTRL_FLAG_NEXT_COMPOUND;
+ }
+ if (errno != EINVAL) {
+ perror("VIDIOC_QUERY_EXT_CTRL");
+ exit(EXIT_FAILURE);
+ }
+
+Example: Enumerating all user controls (old style)
+==================================================
+
+.. code-block:: c
+
+
+ memset(&queryctrl, 0, sizeof(queryctrl));
+
for (queryctrl.id = V4L2_CID_BASE;
queryctrl.id < V4L2_CID_LASTP1;
queryctrl.id++) {
@@ -349,7 +397,7 @@ Example: Enumerating all user controls
printf("Control %s\\n", queryctrl.name);
if (queryctrl.type == V4L2_CTRL_TYPE_MENU)
- enumerate_menu();
+ enumerate_menu(queryctrl.id);
} else {
if (errno == EINVAL)
continue;
@@ -368,7 +416,7 @@ Example: Enumerating all user controls
printf("Control %s\\n", queryctrl.name);
if (queryctrl.type == V4L2_CTRL_TYPE_MENU)
- enumerate_menu();
+ enumerate_menu(queryctrl.id);
} else {
if (errno == EINVAL)
break;
@@ -379,32 +427,6 @@ Example: Enumerating all user controls
}
-Example: Enumerating all user controls (alternative)
-====================================================
-
-.. code-block:: c
-
- memset(&queryctrl, 0, sizeof(queryctrl));
-
- queryctrl.id = V4L2_CTRL_CLASS_USER | V4L2_CTRL_FLAG_NEXT_CTRL;
- while (0 == ioctl(fd, VIDIOC_QUERYCTRL, &queryctrl)) {
- if (V4L2_CTRL_ID2CLASS(queryctrl.id) != V4L2_CTRL_CLASS_USER)
- break;
- if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED)
- continue;
-
- printf("Control %s\\n", queryctrl.name);
-
- if (queryctrl.type == V4L2_CTRL_TYPE_MENU)
- enumerate_menu();
-
- queryctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL;
- }
- if (errno != EINVAL) {
- perror("VIDIOC_QUERYCTRL");
- exit(EXIT_FAILURE);
- }
-
Example: Changing controls
==========================
^ permalink raw reply related
* Re: [PATCH] i2c: mark device nodes only in case of successful instantiation
From: Greg KH @ 2016-11-09 8:30 UTC (permalink / raw)
To: Ralf Ramsauer; +Cc: geert+renesas, pantelis.antoniou, wsa, stable, stable
In-Reply-To: <20161106131507.12605-1-ralf@ramses-pyramidenbau.de>
On Sun, Nov 06, 2016 at 02:15:07PM +0100, Ralf Ramsauer wrote:
> commit 6a676fb69dcbf3310b9e462c1db66c8e7f6ead38 upstream.
>
> Instantiated I2C device nodes are marked with OF_POPULATE. This was
> introduced in 4f001fd30145a6. On unloading, loaded device nodes will of
> course be unmarked. The problem are nodes that fail during
> initialisation: If a node fails, it won't be unloaded and hence not be
> unmarked.
>
> If a I2C driver module is unloaded and reloaded, it will skip nodes that
> failed before.
>
> Skip device nodes that are already populated and mark them only in case
> of success.
>
> Fixes: 4f001fd30145a6 ("i2c: Mark instantiated device nodes with OF_POPULATE")
> Signed-off-by: Ralf Ramsauer <ralf@ramses-pyramidenbau.de>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
> [wsa: use 14-digit commit sha]
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> Cc: stable@kernel.org
> ---
> Hi Greg,
>
> this one is the backport for 4.8.y. Only hunks and surrounding context lines
> shifted slightly, no functional changes compared to its upstream commit
> 6a676fb69dcbf.
Thanks for the backport, now applied.
greg k-h
^ permalink raw reply
* Re: [PATCH for-4.8] libxc: fix unmap of ACPI guest memory region
From: Roger Pau Monne @ 2016-11-09 8:28 UTC (permalink / raw)
To: Boris Ostrovsky; +Cc: xen-devel, Wei Liu, Ian Jackson, Andrew Cooper
In-Reply-To: <4810a61f-4f44-6636-ff9e-2fc7ba494d6d@oracle.com>
On Tue, Nov 08, 2016 at 12:19:06PM -0500, Boris Ostrovsky wrote:
>
>
> On 11/08/2016 11:22 AM, Roger Pau Monne wrote:
> > Commit fac7f7 changed the value of ptr so that it points to the right memory
> > area, taking the page offset into account, but failed to remove this when
> > doing the unmap, which caused the region to not be unmapped. Fix this by not
> > modifying ptr and instead adding the page offset directly in the memcpy
> > call.
> >
> > Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> > ---
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> > Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> > Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
> > ---
> > tools/libxc/xc_dom_core.c | 7 +++----
> > 1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> > index ad819dd..36cd3c8 100644
> > --- a/tools/libxc/xc_dom_core.c
> > +++ b/tools/libxc/xc_dom_core.c
> > @@ -1119,10 +1119,9 @@ static int xc_dom_load_acpi(struct xc_dom_image *dom)
> > goto err;
> > }
> >
> > - ptr = (uint8_t *)ptr +
> > - (dom->acpi_modules[i].guest_addr_out & ~XC_PAGE_MASK);
> > -
> > - memcpy(ptr, dom->acpi_modules[i].data, dom->acpi_modules[i].length);
> > + memcpy((uint8_t *)ptr +
> > + (dom->acpi_modules[i].guest_addr_out & ~XC_PAGE_MASK),
> > + dom->acpi_modules[i].data, dom->acpi_modules[i].length);
> > munmap(ptr, XC_PAGE_SIZE * num_pages);
> >
> > free(extents);
> >
>
>
> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>
> (Although I don't think this would cause memory not to be unmapped: per
> Linux man page "All pages containing a part of the indicated range are
> unmapped ..." and ptr is offset from its original value by a fraction of a
> page.)
Linux man page states:
"The implementation shall require that addr be a multiple of the page size
{PAGESIZE}."
And on FreeBSD:
"The munmap() system call will fail if: The addr argument was not page
aligned, [...]"
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Patch "drm: i915: Wait for fences on new fb, not old" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:26 UTC (permalink / raw)
To: daniels, daniel.vetter, daniel.vetter, gregkh, jani.nikula,
maarten.lankhorst
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm: i915: Wait for fences on new fb, not old
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-wait-for-fences-on-new-fb-not-old.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 1fb3672eaf6ec95fb34c22734feffd6041531c5b Mon Sep 17 00:00:00 2001
From: Daniel Stone <daniels@collabora.com>
Date: Fri, 21 Oct 2016 15:44:54 +0100
Subject: drm: i915: Wait for fences on new fb, not old
From: Daniel Stone <daniels@collabora.com>
commit 1fb3672eaf6ec95fb34c22734feffd6041531c5b upstream.
The previous code would wait for fences on the framebuffer from the old
plane state to complete, rather than the new, so you would see tearing
everywhere. Fix this to wait on the new state before we make it active.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 94f050246b42 ("drm/i915: nonblocking commit")
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161021144454.6288-1-daniels@collabora.com
(cherry picked from commit 2d2c5ad83f772d7d7b0bb8348ecea42e88f89ab0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13834,7 +13834,7 @@ static void intel_atomic_commit_tail(str
for_each_plane_in_state(state, plane, plane_state, i) {
struct intel_plane_state *intel_plane_state =
- to_intel_plane_state(plane_state);
+ to_intel_plane_state(plane->state);
if (!intel_plane_state->wait_req)
continue;
Patches currently in stable-queue which might be from daniels@collabora.com are
queue-4.8/drm-i915-wait-for-fences-on-new-fb-not-old.patch
^ permalink raw reply
* Patch "drm: Release reference from blob lookup after replacing property" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:26 UTC (permalink / raw)
To: felix.monninger, chris, daniel.vetter, gregkh, ville.syrjala
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm: Release reference from blob lookup after replacing property
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-release-reference-from-blob-lookup-after-replacing-property.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From cac5fcedaabdadf150c8a9be9fee76defc8ba444 Mon Sep 17 00:00:00 2001
From: Felix Monninger <felix.monninger@gmail.com>
Date: Tue, 25 Oct 2016 22:28:08 +0100
Subject: drm: Release reference from blob lookup after replacing property
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Felix Monninger <felix.monninger@gmail.com>
commit cac5fcedaabdadf150c8a9be9fee76defc8ba444 upstream.
drm_property_lookup_blob() returns a reference to the returned blob, and
drm_atomic_replace_property_blob() takes a references to the blob it
stores, so afterwards we are left owning a reference to the new_blob that
we never release, and thus leak memory every time we update a property
such as during drm_atomic_helper_legacy_gamma_set().
v2: update credentials, drm_property_unreference_blob() is NULL safe and
NULL is passed consistently to it throughout drm_atomic.c so do so here.
Reported-by: Felix Monninger <felix.monninger@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98420
Signed-off-by: Felix Monninger <felix.monninger@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 5488dc16fde7 ("drm: introduce pipe color correction properties")
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161025212808.3908-1-chris@chris-wilson.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_atomic.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -420,18 +420,21 @@ drm_atomic_replace_property_blob_from_id
ssize_t expected_size,
bool *replaced)
{
- struct drm_device *dev = crtc->dev;
struct drm_property_blob *new_blob = NULL;
if (blob_id != 0) {
- new_blob = drm_property_lookup_blob(dev, blob_id);
+ new_blob = drm_property_lookup_blob(crtc->dev, blob_id);
if (new_blob == NULL)
return -EINVAL;
- if (expected_size > 0 && expected_size != new_blob->length)
+
+ if (expected_size > 0 && expected_size != new_blob->length) {
+ drm_property_unreference_blob(new_blob);
return -EINVAL;
+ }
}
drm_atomic_replace_property_blob(blob, new_blob, replaced);
+ drm_property_unreference_blob(new_blob);
return 0;
}
Patches currently in stable-queue which might be from felix.monninger@gmail.com are
queue-4.8/drm-release-reference-from-blob-lookup-after-replacing-property.patch
^ permalink raw reply
* Patch "drm/i915: Respect alternate_aux_channel for all DDI ports" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:26 UTC (permalink / raw)
To: ville.syrjala, gregkh, jani.nikula, jim.bride, madman2003
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/i915: Respect alternate_aux_channel for all DDI ports
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-respect-alternate_aux_channel-for-all-ddi-ports.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 198c5ee3c60169f8b64bcd330a34593be80699aa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
Date: Tue, 11 Oct 2016 20:52:45 +0300
Subject: drm/i915: Respect alternate_aux_channel for all DDI ports
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
commit 198c5ee3c60169f8b64bcd330a34593be80699aa upstream.
The VBT provides the platform a way to mix and match the DDI ports vs.
AUX channels. Currently we only trust the VBT for DDI E, which has no
corresponding AUX channel of its own. However it is possible that some
board might use some non-standard DDI vs. AUX port routing even for
the other ports. Perhaps for signal routing reasons or something,
So let's generalize this and trust the VBT for all ports.
For now we'll limit this to DDI platforms, as we trust the VBT a bit
more there anyway when it comes to the DDI ports. I've structured
the code in a way that would allow us to easily expand this to
other platforms as well, by simply filling in the ddi_port_info.
v2: Drop whitespace changes, keep MISSING_CASE() for unknown
aux ch assignment, include a commit message, include debug
message during init
Cc: Maarten Maathuis <madman2003@gmail.com>
Tested-by: Maarten Maathuis <madman2003@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
(cherry picked from commit 8f7ce038f1178057733b7e765bf9160a2f9be14b)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_dp.c | 71 ++++++++++++++++++++++------------------
1 file changed, 40 insertions(+), 31 deletions(-)
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1090,6 +1090,44 @@ intel_dp_aux_transfer(struct drm_dp_aux
return ret;
}
+static enum port intel_aux_port(struct drm_i915_private *dev_priv,
+ enum port port)
+{
+ const struct ddi_vbt_port_info *info =
+ &dev_priv->vbt.ddi_port_info[port];
+ enum port aux_port;
+
+ if (!info->alternate_aux_channel) {
+ DRM_DEBUG_KMS("using AUX %c for port %c (platform default)\n",
+ port_name(port), port_name(port));
+ return port;
+ }
+
+ switch (info->alternate_aux_channel) {
+ case DP_AUX_A:
+ aux_port = PORT_A;
+ break;
+ case DP_AUX_B:
+ aux_port = PORT_B;
+ break;
+ case DP_AUX_C:
+ aux_port = PORT_C;
+ break;
+ case DP_AUX_D:
+ aux_port = PORT_D;
+ break;
+ default:
+ MISSING_CASE(info->alternate_aux_channel);
+ aux_port = PORT_A;
+ break;
+ }
+
+ DRM_DEBUG_KMS("using AUX %c for port %c (VBT)\n",
+ port_name(aux_port), port_name(port));
+
+ return aux_port;
+}
+
static i915_reg_t g4x_aux_ctl_reg(struct drm_i915_private *dev_priv,
enum port port)
{
@@ -1150,36 +1188,9 @@ static i915_reg_t ilk_aux_data_reg(struc
}
}
-/*
- * On SKL we don't have Aux for port E so we rely
- * on VBT to set a proper alternate aux channel.
- */
-static enum port skl_porte_aux_port(struct drm_i915_private *dev_priv)
-{
- const struct ddi_vbt_port_info *info =
- &dev_priv->vbt.ddi_port_info[PORT_E];
-
- switch (info->alternate_aux_channel) {
- case DP_AUX_A:
- return PORT_A;
- case DP_AUX_B:
- return PORT_B;
- case DP_AUX_C:
- return PORT_C;
- case DP_AUX_D:
- return PORT_D;
- default:
- MISSING_CASE(info->alternate_aux_channel);
- return PORT_A;
- }
-}
-
static i915_reg_t skl_aux_ctl_reg(struct drm_i915_private *dev_priv,
enum port port)
{
- if (port == PORT_E)
- port = skl_porte_aux_port(dev_priv);
-
switch (port) {
case PORT_A:
case PORT_B:
@@ -1195,9 +1206,6 @@ static i915_reg_t skl_aux_ctl_reg(struct
static i915_reg_t skl_aux_data_reg(struct drm_i915_private *dev_priv,
enum port port, int index)
{
- if (port == PORT_E)
- port = skl_porte_aux_port(dev_priv);
-
switch (port) {
case PORT_A:
case PORT_B:
@@ -1235,7 +1243,8 @@ static i915_reg_t intel_aux_data_reg(str
static void intel_aux_reg_init(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = to_i915(intel_dp_to_dev(intel_dp));
- enum port port = dp_to_dig_port(intel_dp)->port;
+ enum port port = intel_aux_port(dev_priv,
+ dp_to_dig_port(intel_dp)->port);
int i;
intel_dp->aux_ch_ctl_reg = intel_aux_ctl_reg(dev_priv, port);
Patches currently in stable-queue which might be from ville.syrjala@linux.intel.com are
queue-4.8/drm-release-reference-from-blob-lookup-after-replacing-property.patch
queue-4.8/x86-smpboot-init-apic-mapping-before-usage.patch
queue-4.8/drm-fb-helper-don-t-call-dirty-callback-for-untouched-clips.patch
queue-4.8/usb-gadget-function-u_ether-don-t-starve-tx-request-queue.patch
queue-4.8/drm-i915-clean-up-ddi-ddc-aux-ch-sanitation.patch
queue-4.8/drm-i915-respect-alternate_aux_channel-for-all-ddi-ports.patch
queue-4.8/drm-dp-mst-check-peer-device-type-before-attempting-edid-read.patch
queue-4.8/drm-fb-helper-keep-references-for-the-current-set-of-used-connectors.patch
queue-4.8/drm-dp-mst-clear-port-pdt-when-tearing-down-the-i2c-adapter.patch
queue-4.8/drm-fb-helper-fix-connector-ref-leak-on-error.patch
queue-4.8/drm-i915-fbc-fix-cfb-size-calculation-for-gen8.patch
^ permalink raw reply
* Patch "drm/i915/gen9: fix DDB partitioning for multi-screen cases" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:26 UTC (permalink / raw)
To: paulo.r.zanoni, cpaul, gregkh, jani.nikula; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/i915/gen9: fix DDB partitioning for multi-screen cases
to the 4.8-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-gen9-fix-ddb-partitioning-for-multi-screen-cases.patch
and it can be found in the queue-4.8 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 01c72d6c17dc524f04d4dbe361d214e423b35457 Mon Sep 17 00:00:00 2001
From: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Tue, 4 Oct 2016 14:37:32 -0300
Subject: drm/i915/gen9: fix DDB partitioning for multi-screen cases
From: Paulo Zanoni <paulo.r.zanoni@intel.com>
commit 01c72d6c17dc524f04d4dbe361d214e423b35457 upstream.
With the previous code we were only recomputing the DDB partitioning
for the CRTCs included in the atomic commit, so any other active CRTCs
would end up having their DDB registers zeroed. In this patch we make
sure that the computed state starts as a copy of the current
partitioning, and then we only zero the DDBs that we're actually
going to recompute.
How to reproduce the bug:
1 - Enable the primary plane on pipe A
2 - Enable the primary plane on pipe B
3 - Enable the cursor or sprite plane on pipe A
Step 3 will zero the DDB partitioning for pipe B since it's not
included in the commit that enabled the cursor or sprite for pipe A.
I expect this to fix many FIFO underrun problems on gen9+.
v2:
- Mention the cursor on the steps to reproduce the problem (Paulo).
- Add Testcase tag provided by Maarten (Maarten).
Testcase: kms_cursor_legacy.cursorA-vs-flipB-atomic-transitions
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96226
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96828
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97450
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97596
Bugzilla: https://www.phoronix.com/scan.php?page=news_item&px=Intel-Skylake-Multi-Screen-Woes
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1475602652-17326-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 5a920b85f2c6e3fd7d9dd9bb3f3345e9085e2360)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_pm.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3363,13 +3363,15 @@ skl_allocate_pipe_ddb(struct intel_crtc_
int num_active;
int id, i;
+ /* Clear the partitioning for disabled planes. */
+ memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
+ memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
+
if (WARN_ON(!state))
return 0;
if (!cstate->base.active) {
ddb->pipe[pipe].start = ddb->pipe[pipe].end = 0;
- memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
- memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
return 0;
}
@@ -4051,6 +4053,12 @@ skl_compute_ddb(struct drm_atomic_state
intel_state->wm_results.dirty_pipes = ~0;
}
+ /*
+ * We're not recomputing for the pipes not included in the commit, so
+ * make sure we start with the current state.
+ */
+ memcpy(ddb, &dev_priv->wm.skl_hw.ddb, sizeof(*ddb));
+
for_each_intel_crtc_mask(dev, intel_crtc, realloc_pipes) {
struct intel_crtc_state *cstate;
Patches currently in stable-queue which might be from paulo.r.zanoni@intel.com are
queue-4.8/drm-i915-gen9-fix-ddb-partitioning-for-multi-screen-cases.patch
queue-4.8/drm-i915-fbc-fix-cfb-size-calculation-for-gen8.patch
queue-4.8/drm-i915-gen9-fix-watermarks-when-using-the-pipe-scaler.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.