* Patch "drm/i915/gen9: fix watermarks when using the pipe scaler" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:26 UTC (permalink / raw)
To: paulo.r.zanoni, gregkh, jani.nikula, matthew.d.roper
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/i915/gen9: fix watermarks when using the pipe scaler
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-watermarks-when-using-the-pipe-scaler.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 5e33791e1f27c3207e7b44071e7c94a487d1eb39 Mon Sep 17 00:00:00 2001
From: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri, 7 Oct 2016 17:28:57 -0300
Subject: drm/i915/gen9: fix watermarks when using the pipe scaler
From: Paulo Zanoni <paulo.r.zanoni@intel.com>
commit 5e33791e1f27c3207e7b44071e7c94a487d1eb39 upstream.
Luckily, the necessary adjustments for when we're using the scaler are
exactly the same as the ones needed on ILK+, so just reuse the
function we already have.
v2: Invert the patch order so stable backports get easier.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1475872138-16194-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit cfd7e3a20251b9ac95651d64556f87f86128a966)
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, 3 insertions(+), 9 deletions(-)
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3471,12 +3471,6 @@ skl_allocate_pipe_ddb(struct intel_crtc_
return 0;
}
-static uint32_t skl_pipe_pixel_rate(const struct intel_crtc_state *config)
-{
- /* TODO: Take into account the scalers once we support them */
- return config->base.adjusted_mode.crtc_clock;
-}
-
/*
* The max latency should be 257 (max the punit can code is 255 and we add 2us
* for the read latency) and cpp should always be <= 8, so that
@@ -3527,7 +3521,7 @@ static uint32_t skl_adjusted_plane_pixel
* Adjusted plane pixel rate is just the pipe's adjusted pixel rate
* with additional adjustments for plane-specific scaling.
*/
- adjusted_pixel_rate = skl_pipe_pixel_rate(cstate);
+ adjusted_pixel_rate = ilk_pipe_pixel_rate(cstate);
downscale_amount = skl_plane_downscale_amount(pstate);
pixel_rate = adjusted_pixel_rate * downscale_amount >> 16;
@@ -3739,11 +3733,11 @@ skl_compute_linetime_wm(struct intel_crt
if (!cstate->base.active)
return 0;
- if (WARN_ON(skl_pipe_pixel_rate(cstate) == 0))
+ if (WARN_ON(ilk_pipe_pixel_rate(cstate) == 0))
return 0;
return DIV_ROUND_UP(8 * cstate->base.adjusted_mode.crtc_htotal * 1000,
- skl_pipe_pixel_rate(cstate));
+ ilk_pipe_pixel_rate(cstate));
}
static void skl_compute_transition_wm(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
* Patch "drm/i915/fbc: fix CFB size calculation for gen8+" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:26 UTC (permalink / raw)
To: paulo.r.zanoni, chris, gregkh, jani.nikula, ville.syrjala
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/i915/fbc: fix CFB size calculation for gen8+
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-fbc-fix-cfb-size-calculation-for-gen8.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 e3b9e6e3a989904ae062e7a48a9431edc837ea6b Mon Sep 17 00:00:00 2001
From: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri, 21 Oct 2016 13:55:45 -0200
Subject: drm/i915/fbc: fix CFB size calculation for gen8+
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Paulo Zanoni <paulo.r.zanoni@intel.com>
commit e3b9e6e3a989904ae062e7a48a9431edc837ea6b upstream.
Broadwell and newer actually compress up to 2560 lines instead of 2048
(as documented in the FBC_CTL page). If we don't take this into
consideration we end up reserving too little stolen memory for the
CFB, so we may allocate something else (such as a ring) right after
what we reserved, and the hardware will overwrite it with the contents
of the CFB when FBC is active, causing GPU hangs. Another possibility
is that the CFB may be allocated at the very end of the available
space, so the CFB will overlap the reserved stolen area, leading to
FIFO underruns.
This bug has always been a problem on BDW (the only affected platform
where FBC is enabled by default), but it's much easier to reproduce
since the following commit:
commit c58b735fc762e891481e92af7124b85cb0a51fce
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Aug 18 17:16:57 2016 +0100
drm/i915: Allocate rings from stolen
Of course, you can only reproduce the bug if your screen is taller
than 2048 lines.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98213
Fixes: a98ee79317b4 ("drm/i915/fbc: enable FBC by default on HSW and BDW")
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477065346-13736-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 79f2624b1b9f776b173b41d743fb3dd7374b3827)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_fbc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -104,8 +104,10 @@ static int intel_fbc_calculate_cfb_size(
int lines;
intel_fbc_get_plane_source_size(cache, NULL, &lines);
- if (INTEL_INFO(dev_priv)->gen >= 7)
+ if (INTEL_GEN(dev_priv) == 7)
lines = min(lines, 2048);
+ else if (INTEL_GEN(dev_priv) >= 8)
+ lines = min(lines, 2560);
/* Hardware needs the full buffer stride, not just the active area. */
return lines * cache->fb.stride;
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
* Patch "drm/i915: Clean up DDI DDC/AUX CH sanitation" 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: Clean up DDI DDC/AUX CH sanitation
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-clean-up-ddi-ddc-aux-ch-sanitation.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 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
@@ -1031,6 +1031,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)
{
@@ -1105,54 +1176,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.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/dp/mst: Check peer device type before attempting EDID read" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:26 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.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-dp-mst-check-peer-device-type-before-attempting-edid-read.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 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
@@ -1160,7 +1160,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.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 v2 linux dev-4.7 7/7] mtd: spi-nor: aspeed: rework io routines
From: Cédric Le Goater @ 2016-11-09 8:15 UTC (permalink / raw)
To: openbmc
In-Reply-To: <1478679343-25354-1-git-send-email-clg@kaod.org>
The io accessors from pflash are shorter and simpler.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
---
Changes since v1:
- renamed the routine
drivers/mtd/spi-nor/aspeed-smc.c | 112 +++++++++++++--------------------------
1 file changed, 38 insertions(+), 74 deletions(-)
diff --git a/drivers/mtd/spi-nor/aspeed-smc.c b/drivers/mtd/spi-nor/aspeed-smc.c
index 231d4bda4e97..d3bed34f5aa0 100644
--- a/drivers/mtd/spi-nor/aspeed-smc.c
+++ b/drivers/mtd/spi-nor/aspeed-smc.c
@@ -65,84 +65,48 @@ module_param(dma_timeout, uint, 0644);
* the memory buffer pointer and count via explicit code. The final updates
* to len are optimistically suppressed.
*/
-
-static void aspeed_smc_from_fifo(void *buf, const void __iomem *iop, size_t len)
+static int aspeed_smc_read_from_ahb(void *buf, const void __iomem *src,
+ size_t len)
{
- if (!len)
- return;
-
- /* Expect a 4 byte input port. Otherwise just read bytes. */
- if (unlikely((unsigned long)iop & 3)) {
- while (len--) {
- *(u8 *)buf = readb(iop);
- buf++;
+ if ((((unsigned long) src | (unsigned long) buf | len) & 3) == 0) {
+ while (len > 3) {
+ *(u32 *) buf = readl(src);
+ buf += 4;
+ src += 4;
+ len -= 4;
}
}
- /* Align target to word: first byte then half word */
- if ((unsigned long)buf & 1) {
- *(u8 *)buf = readb(iop);
- buf++;
- len--;
- }
- if (((unsigned long)buf & 2) && (len >= 2)) {
- *(u16 *)buf = readw(iop);
- buf += 2;
- len -= 2;
- }
-
- /* Transfer words, then remaining halfword and remaining byte */
- while (len >= 4) {
- *(u32 *)buf = readl(iop);
- buf += 4;
- len -= 4;
- }
- if (len & 2) {
- *(u16 *)buf = readw(iop);
- buf += 2;
+ while (len--) {
+ *(u8 *) buf = readb(src);
+ buf += 1;
+ src += 1;
}
- if (len & 1)
- *(u8 *)buf = readb(iop);
+ return 0;
}
-static void aspeed_smc_to_fifo(void __iomem *iop, const void *buf, size_t len)
+static int aspeed_smc_write_to_ahb(void __iomem *dst, const void *buf,
+ size_t len)
{
- if (!len)
- return;
-
- /* Expect a 4 byte output port. Otherwise just write bytes. */
- if ((unsigned long)iop & 3) {
- while (len--) {
- writeb(*(u8 *)buf, iop);
- buf++;
+ if ((((unsigned long) dst | (unsigned long) buf | len) & 3) == 0) {
+ while (len > 3) {
+ u32 val = *(u32 *) buf;
+
+ writel(val, dst);
+ buf += 4;
+ dst += 4;
+ len -= 4;
}
- return;
}
- /* Align target to word: first byte then half word */
- if ((unsigned long)buf & 1) {
- writeb(*(u8 *)buf, iop);
- buf++;
- len--;
- }
- if (((unsigned long)buf & 2) && (len >= 2)) {
- writew(*(u16 *)buf, iop);
- buf += 2;
- len -= 2;
- }
+ while (len--) {
+ u8 val = *(u8 *) buf;
- /* Transfer words, then remaining halfword and remaining byte */
- while (len >= 4) {
- writel(*(u32 *)buf, iop);
- buf += 4;
- len -= 4;
+ writeb(val, dst);
+ buf += 1;
+ dst += 1;
}
- if (len & 2) {
- writew(*(u16 *)buf, iop);
- buf += 2;
- }
- if (len & 1)
- writeb(*(u8 *)buf, iop);
+ return 0;
}
enum smc_flash_type {
@@ -518,8 +482,8 @@ static int aspeed_smc_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
mutex_lock(&chip->controller->mutex);
aspeed_smc_start_user(nor);
- aspeed_smc_to_fifo(chip->base, &opcode, 1);
- aspeed_smc_from_fifo(buf, chip->base, len);
+ aspeed_smc_write_to_ahb(chip->base, &opcode, 1);
+ aspeed_smc_read_from_ahb(buf, chip->base, len);
aspeed_smc_stop_user(nor);
mutex_unlock(&chip->controller->mutex);
@@ -535,8 +499,8 @@ static int aspeed_smc_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
mutex_lock(&chip->controller->mutex);
aspeed_smc_start_user(nor);
- aspeed_smc_to_fifo(chip->base, &opcode, 1);
- aspeed_smc_to_fifo(chip->base, buf, len);
+ aspeed_smc_write_to_ahb(chip->base, &opcode, 1);
+ aspeed_smc_write_to_ahb(chip->base, buf, len);
aspeed_smc_stop_user(nor);
mutex_unlock(&chip->controller->mutex);
@@ -561,12 +525,12 @@ static void aspeed_smc_send_cmd_addr(struct spi_nor *nor, u8 cmd, u32 addr)
cmdaddr |= (u32)cmd << 24;
temp = cpu_to_be32(cmdaddr);
- aspeed_smc_to_fifo(chip->base, &temp, 4);
+ aspeed_smc_write_to_ahb(chip->base, &temp, 4);
break;
case 4:
temp = cpu_to_be32(addr);
- aspeed_smc_to_fifo(chip->base, &cmd, 1);
- aspeed_smc_to_fifo(chip->base, &temp, 4);
+ aspeed_smc_write_to_ahb(chip->base, &cmd, 1);
+ aspeed_smc_write_to_ahb(chip->base, &temp, 4);
break;
}
}
@@ -593,7 +557,7 @@ static int aspeed_smc_read_user(struct spi_nor *nor, loff_t from, size_t len,
aspeed_smc_start_user(nor);
aspeed_smc_send_cmd_addr(nor, nor->read_opcode, from);
- aspeed_smc_from_fifo(read_buf, chip->base, len);
+ aspeed_smc_read_from_ahb(read_buf, chip->base, len);
aspeed_smc_stop_user(nor);
out:
@@ -626,7 +590,7 @@ static void aspeed_smc_write_user(struct spi_nor *nor, loff_t to, size_t len,
aspeed_smc_start_user(nor);
aspeed_smc_send_cmd_addr(nor, nor->program_opcode, to);
- aspeed_smc_to_fifo(chip->base, write_buf, len);
+ aspeed_smc_write_to_ahb(chip->base, write_buf, len);
aspeed_smc_stop_user(nor);
out:
--
2.7.4
^ permalink raw reply related
* [PATCH v2 linux dev-4.7 2/7] mtd: spi-nor: aspeed: improve 4 bytes mode
From: Cédric Le Goater @ 2016-11-09 8:15 UTC (permalink / raw)
To: openbmc
In-Reply-To: <1478679343-25354-1-git-send-email-clg@kaod.org>
The AST2400 SPI flash uses the CE0 control register to set 4Byte mode
and the AST2500 FMC and AST2400 FMC flash controllers use the CE
Control register for this purpose or they are strapped by hardware.
Currently, the setting of the CE0 control register is done for all,
which is incorrect, so fix that to keep only the AST2400 SPI. Luckily,
the bogus setting has no impact on operations as bit 13 defines a SPI
clock divisor.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
Changes since v1 :
- added a set_4b() ops
- removed the use of SZ_16M
drivers/mtd/spi-nor/aspeed-smc.c | 62 +++++++++++++++++++++++++++-------------
1 file changed, 42 insertions(+), 20 deletions(-)
diff --git a/drivers/mtd/spi-nor/aspeed-smc.c b/drivers/mtd/spi-nor/aspeed-smc.c
index 75ba73ef0660..ecc38752c2c3 100644
--- a/drivers/mtd/spi-nor/aspeed-smc.c
+++ b/drivers/mtd/spi-nor/aspeed-smc.c
@@ -151,6 +151,8 @@ enum smc_flash_type {
smc_type_spi = 2, /* controller connected to spi flash */
};
+struct aspeed_smc_chip;
+
struct aspeed_smc_info {
u32 maxsize; /* maximum size of 1 chip window */
u8 nce; /* number of chip enables */
@@ -160,8 +162,13 @@ struct aspeed_smc_info {
u8 ctl0; /* offset in regs of ctl for ce 0 */
u8 time; /* offset in regs of timing */
u8 misc; /* offset in regs of misc settings */
+
+ void (*set_4b)(struct aspeed_smc_chip *chip);
};
+static void aspeed_smc_chip_set_4b_smc_2400(struct aspeed_smc_chip *chip);
+static void aspeed_smc_chip_set_4b(struct aspeed_smc_chip *chip);
+
static const struct aspeed_smc_info fmc_2400_info = {
.maxsize = 64 * 1024 * 1024,
.nce = 5,
@@ -171,6 +178,7 @@ static const struct aspeed_smc_info fmc_2400_info = {
.ctl0 = 0x10,
.time = 0x94,
.misc = 0x54,
+ .set_4b = aspeed_smc_chip_set_4b,
};
static const struct aspeed_smc_info smc_2400_info = {
@@ -182,6 +190,7 @@ static const struct aspeed_smc_info smc_2400_info = {
.ctl0 = 0x04,
.time = 0x14,
.misc = 0x10,
+ .set_4b = aspeed_smc_chip_set_4b_smc_2400,
};
static const struct aspeed_smc_info fmc_2500_info = {
@@ -193,6 +202,7 @@ static const struct aspeed_smc_info fmc_2500_info = {
.ctl0 = 0x10,
.time = 0x94,
.misc = 0x54,
+ .set_4b = aspeed_smc_chip_set_4b,
};
static const struct aspeed_smc_info smc_2500_info = {
@@ -204,6 +214,7 @@ static const struct aspeed_smc_info smc_2500_info = {
.ctl0 = 0x10,
.time = 0x94,
.misc = 0x54,
+ .set_4b = aspeed_smc_chip_set_4b,
};
enum smc_ctl_reg_value {
@@ -751,6 +762,34 @@ static void aspeed_smc_chip_set_type(struct aspeed_smc_chip *chip, int type)
writel(reg, controller->regs + CONFIG_REG);
}
+/*
+ * The AST2500 FMC and AST2400 FMC flash controllers should be
+ * strapped by hardware, or autodetected, but the AST2500 SPI flash
+ * needs to be set.
+ */
+static void aspeed_smc_chip_set_4b(struct aspeed_smc_chip *chip)
+{
+ struct aspeed_smc_controller *controller = chip->controller;
+ u32 reg;
+
+ if (chip->controller->info == &smc_2500_info) {
+ reg = readl(controller->regs + CE_CONTROL_REG);
+ reg |= 1 << chip->cs;
+ writel(reg, controller->regs + CE_CONTROL_REG);
+ }
+}
+
+/*
+ * The AST2400 SPI flash controller does not have a CE Control
+ * register. It uses the CE0 control register to set 4Byte mode at the
+ * controller level.
+ */
+static void aspeed_smc_chip_set_4b_smc_2400(struct aspeed_smc_chip *chip)
+{
+ chip->ctl_val[smc_base] |= CONTROL_SPI_IO_ADDRESS_4B;
+ chip->ctl_val[smc_read] |= CONTROL_SPI_IO_ADDRESS_4B;
+}
+
static int aspeed_smc_chip_setup_init(struct aspeed_smc_chip *chip,
struct resource *r)
{
@@ -815,27 +854,10 @@ static int aspeed_smc_chip_setup_init(struct aspeed_smc_chip *chip,
static void aspeed_smc_chip_setup_finish(struct aspeed_smc_chip *chip)
{
struct aspeed_smc_controller *controller = chip->controller;
- u32 reg;
-
- /*
- * Set 4 byte mode in the chip controller register and also in
- * controller config register. The BMC flash controller is
- * strapped by hardware, or autodetected, but the SPI flash
- * controller of the AST2500 still needs to be set.
- */
- if (chip->nor.mtd.size > SZ_16M) {
- chip->ctl_val[smc_base] |= CONTROL_SPI_IO_ADDRESS_4B;
+ const struct aspeed_smc_info *info = controller->info;
- /*
- * The SPI flash controller of the AST2400 does not
- * have such a setting.
- */
- if (chip->controller->info == &smc_2500_info) {
- reg = readl(controller->regs + CE_CONTROL_REG);
- reg |= 1 << chip->cs;
- writel(reg, controller->regs + CE_CONTROL_REG);
- }
- }
+ if (chip->nor.addr_width == 4 && info->set_4b)
+ info->set_4b(chip);
chip->ctl_val[smc_write] = chip->ctl_val[smc_base] |
spi_control_fill_opcode(chip->nor.program_opcode) |
--
2.7.4
^ permalink raw reply related
* Re: Forbid access to /gitweb but authorize the sub projets
From: Dennis Kaarsemaker @ 2016-11-09 8:25 UTC (permalink / raw)
To: Alexandre Duplaix, git
In-Reply-To: <58207CAB.3060105@sagemcom.com>
On Mon, 2016-11-07 at 14:07 +0100, Alexandre Duplaix wrote:
> Hello,
>
> I have several projects under https://myserver/gitweb and I would like
> to forbid the access to the root, so that the users can't list the
> differents projects.
>
> However, I need to let the access to the sub projects (ex:
> https://myserver/gitweb/?p=project1;a=summary
>
> How can I do please ?
My favourite way of doing this is abusing the fact that gitweb.conf is
perl code that's loaded with do $filename.
This makes it easy to override such things. Try this in gitweb.conf for example:
sub no_index {
die_error(403, "No access to the repository list");
}
$actions{project_list} = \&no_index;
$actions{project_index} = \&no_index;
$actions{opml} = \&no_index;
--
Dennis Kaarsemaker
http://www.kaarsemaker.net
^ permalink raw reply
* [PATCH v2 linux dev-4.7 4/7] mtd: spi-nor: aspeed: add some logging
From: Cédric Le Goater @ 2016-11-09 8:15 UTC (permalink / raw)
To: openbmc
In-Reply-To: <1478679343-25354-1-git-send-email-clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
---
drivers/mtd/spi-nor/aspeed-smc.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi-nor/aspeed-smc.c b/drivers/mtd/spi-nor/aspeed-smc.c
index 195166def945..4839a26b387f 100644
--- a/drivers/mtd/spi-nor/aspeed-smc.c
+++ b/drivers/mtd/spi-nor/aspeed-smc.c
@@ -759,8 +759,6 @@ static void aspeed_smc_chip_enable_write(struct aspeed_smc_chip *chip)
u32 reg;
reg = readl(controller->regs + CONFIG_REG);
- dev_dbg(controller->dev, "config reg @%p: 0x%08x\n",
- controller->regs + CONFIG_REG, reg);
reg |= aspeed_smc_chip_write_bit(chip);
writel(reg, controller->regs + CONFIG_REG);
@@ -772,8 +770,6 @@ static void aspeed_smc_chip_set_type(struct aspeed_smc_chip *chip, int type)
u32 reg;
reg = readl(controller->regs + CONFIG_REG);
- dev_dbg(controller->dev, "config reg @%p: 0x%08x\n",
- controller->regs + CONFIG_REG, reg);
chip->type = type;
@@ -868,6 +864,8 @@ static int aspeed_smc_chip_setup_init(struct aspeed_smc_chip *chip,
chip->ctl_val[smc_read] = chip->ctl_val[smc_base] |
CONTROL_SPI_COMMAND_MODE_NORMAL;
+ dev_dbg(controller->dev, "default control register: %08x\n",
+ chip->ctl_val[smc_read]);
return 0;
}
@@ -883,6 +881,9 @@ static void aspeed_smc_chip_setup_finish(struct aspeed_smc_chip *chip)
spi_control_fill_opcode(chip->nor.program_opcode) |
CONTROL_SPI_COMMAND_MODE_WRITE;
+ dev_dbg(controller->dev, "write control register: %08x\n",
+ chip->ctl_val[smc_write]);
+
/*
* XXX TODO
* Enable fast read mode as required here.
--
2.7.4
^ permalink raw reply related
* Re: GPIO IN LINUX KERENL 4.8
From: Linus Walleij @ 2016-11-09 8:25 UTC (permalink / raw)
To: Rahul Mahajan; +Cc: linux-gpio@vger.kernel.org
In-Reply-To: <CAGyKHxL+Hf70c4+_oeO-4nVEH_iqSL5yn7MWdp1LGjZntNHzBg@mail.gmail.com>
On Tue, Nov 8, 2016 at 7:18 PM, Rahul Mahajan
<rahulcmahajan.84@gmail.com> wrote:
> 1) why we remove gpio system not uses /sys/class/gpio. ?
Class devices are generally deprecated in favor of bus devices.
(Source: Greg Kroah-Hartman.)
The new devices appear in /sys/bus/gpio/*
> 2) if i want to use old kernel gpio driver with linux 4.8 driver. So how to
> port because any impact with other system or api change.
You should submit your drivers to the upstream Linux kernel
so you do not face the situation of maintaining out-of-tree code.
The changes made to the kernel for drivers recently are detailed
in that talk. Further consult this document:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/stable_api_nonsense.txt
> 3) Old Approach is very easy just we give export through /sys and how to
> exoort from user space?
The new ABI does not use exporting. It uses anonymous file handles,
and GPIOs are marked for userspace use on-demand.
It could be argued that the sysfs ABI is "easy" but is it really?
If your script or program using a few exported GPIOs crashes,
the exported GPIOs are never unexported and you have a leak
that you need to work around with more scripts. And that is not
"easy".
> Hello Linus,
>
> Can you please reply on my question?
Take it easy, I have lots of stuff to do.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] x86emul: correct direction of FPU insn emulations
From: Jan Beulich @ 2016-11-09 8:25 UTC (permalink / raw)
To: xen-devel; +Cc: Andrew Cooper, Wei Liu
[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]
There are two cases where this was wrong, albeit in a benign way (the
compiler - according to my checking - didn't leverage the wrongness
for any optimizations affecting overall outcome).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3683,7 +3683,7 @@ x86_emulate(
if ( (rc = ops->read(src.mem.seg, src.mem.off,
&src.val, src.bytes, ctxt)) != 0 )
goto done;
- emulate_fpu_insn_memdst("fldt", src.val);
+ emulate_fpu_insn_memsrc("fldt", src.val);
break;
case 7: /* fstp m80fp */
ea.bytes = 10;
@@ -3780,7 +3780,7 @@ x86_emulate(
ea.bytes = 8;
dst = ea;
dst.type = OP_MEM;
- emulate_fpu_insn_memsrc("fstl", dst.val);
+ emulate_fpu_insn_memdst("fstl", dst.val);
break;
case 3: /* fstp m64fp */
ea.bytes = 8;
[-- Attachment #2: x86emul-FPU-mem-direction.patch --]
[-- Type: text/plain, Size: 1162 bytes --]
x86emul: correct direction of FPU insn emulations
There are two cases where this was wrong, albeit in a benign way (the
compiler - according to my checking - didn't leverage the wrongness
for any optimizations affecting overall outcome).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -3683,7 +3683,7 @@ x86_emulate(
if ( (rc = ops->read(src.mem.seg, src.mem.off,
&src.val, src.bytes, ctxt)) != 0 )
goto done;
- emulate_fpu_insn_memdst("fldt", src.val);
+ emulate_fpu_insn_memsrc("fldt", src.val);
break;
case 7: /* fstp m80fp */
ea.bytes = 10;
@@ -3780,7 +3780,7 @@ x86_emulate(
ea.bytes = 8;
dst = ea;
dst.type = OP_MEM;
- emulate_fpu_insn_memsrc("fstl", dst.val);
+ emulate_fpu_insn_memdst("fstl", dst.val);
break;
case 3: /* fstp m64fp */
ea.bytes = 8;
[-- Attachment #3: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
From: Dave Young @ 2016-11-09 8:25 UTC (permalink / raw)
To: Wen Congyang; +Cc: anderson, lersek, qemu-devel, bhe
In-Reply-To: <f197ac51-7727-72a9-cd68-e02d16b6e413@cn.fujitsu.com>
On 11/09/16 at 03:42pm, Wen Congyang wrote:
> On 11/09/2016 01:02 PM, Dave Young wrote:
> > On 11/09/16 at 11:58am, Wen Congyang wrote:
> >> On 11/09/2016 11:17 AM, Dave Young wrote:
> >>> Drop qiaonuohan, seems the mail address is wrong..
> >>>
> >>> On 11/09/16 at 11:01am, Dave Young wrote:
> >>>> Hi,
> >>>>
> >>>> Latest linux kernel enabled kaslr to randomiz phys/virt memory
> >>>> addresses, we had some effort to support kexec/kdump so that crash
> >>>> utility can still works in case crashed kernel has kaslr enabled.
> >>>>
> >>>> But according to Dave Anderson virsh dump does not work, quoted messages
> >>>> from Dave below:
> >>>>
> >>>> """
> >>>> with virsh dump, there's no way of even knowing that KASLR
> >>>> has randomized the kernel __START_KERNEL_map region, because there is no
> >>>> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump
> >>>> vmcoreinfo data to compare against the vmlinux file symbol value.
> >>>> Unless virsh dump can export some basic virtual memory data, which
> >>>> they say it can't, I don't see how KASLR can ever be supported.
> >>>> """
> >>>>
> >>>> I assume virsh dump is using qemu guest memory dump facility so it
> >>>> should be first addressed in qemu. Thus post this query to qemu devel
> >>>> list. If this is not correct please let me know.
> >>
> >> IIRC, 'virsh dump --memory-only' uses dump-guest-memory, and 'virsh dump'
> >> uses migration to dump.
> >
> > Do they need different fixes? Dave, I guess you mean --memory-only, but
> > could you clarify and confirm it?
> >
> >>
> >> I think I should study kaslr first...
> >
> > Thanks for taking care of it.
>
> Can you give me the patch for kexec/kdump. I want to know what I need to do
> for dump-guest-memory.
AFAIK, there are below patches for kexec/kdump userspace:
kexec-tools, git commit:
commit 9f62cbddddfc93d78d9aafbddf3e1208cb242f7b
Author: Thomas Garnier <thgarnie@google.com>
Date: Tue Sep 13 15:10:05 2016 +0800
kexec/arch/i386: Add support for KASLR memory randomization
Originally Baoquan He posted below patches to export vmcoreinfo for some
kernel fields:
http://lists.infradead.org/pipermail/kexec/2016-September/017191.html
But later it was dropped, we finally do it in userspace with several
makedumpfile patches:
http://lists.infradead.org/pipermail/kexec/2016-October/017540.html
http://lists.infradead.org/pipermail/kexec/2016-October/017539.html
http://lists.infradead.org/pipermail/kexec/2016-October/017541.html
For virsh dumped vmcore it should manage to export some infomation so that
crash utility can use. I would leave Dave to provide more information
what he needs because the goal is userspace utility like crash can
correctly analysis the vmcore.
>
> Thanks
> Wen Congyang
>
> >
> >>
> >> Thanks
> >> Wen Congyang
> >>
> >>>>
> >>>> Could you qemu dump people make it work? Or we can not support virt dump
> >>>> as long as KASLR being enabled. Latest Fedora kernel has enabled it in x86_64.
> >>>>
> >>>> Thanks
> >>>> Dave
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> > .
> >
>
>
>
^ permalink raw reply
* Re: [PATCH] HID:i2c-hid: add a simple quirk to fix device defects
From: Benjamin Tissoires @ 2016-11-09 8:25 UTC (permalink / raw)
To: Hn Chen
Cc: jkosina@suse.cz, dmitry.torokhov@gmail.com,
linux-input@vger.kernel.org
In-Reply-To: <22498D53301C4D4A8FFA8F02C7C3C7C06DDE7593@mail02.WHT.local>
On Nov 09 2016 or thereabouts, Hn Chen wrote:
> Hi Benjamin,
>
> Ok, I will add a static quirk table and lookup for the quirks in i2c_hid_probe().
>
> About the return value after send the PWR_ON command, it should be failed in weida's case.
> The oscillator of the controller will be gated in the deep sleep mode and
> the controller will be active after the first command but there is no any feedback.
> So should I check the failed return value here ? Or I should check if it is ok and then just return ?
Maybe just add a comment above saying that this is expected to fail on
some devices, so there is no point in checking the return value here.
Cheers,
Benjamin
>
> Hn.chen
>
> -----Original Message-----
> From: Benjamin Tissoires [mailto:benjamin.tissoires@redhat.com]
> Sent: Tuesday, November 08, 2016 5:38 PM
> To: Hn Chen
> Cc: jkosina@suse.cz; dmitry.torokhov@gmail.com; linux-input@vger.kernel.org
> Subject: Re: [PATCH] HID:i2c-hid: add a simple quirk to fix device defects
>
> On Nov 08 2016 or thereabouts, hn.chen@weidahitech.com wrote:
> > From: HungNien Chen <hn.chen@weidahitech.com>
> >
> > Weida's device can get a quirk value by the quirk function.
> > Base on the quirk value, set_power function will send a command to
> > wake up the device before send the PWR_ON command.
> >
> > Signed-off-by: HungNien Chen <hn.chen@weidahitech.com>
> > ---
> > drivers/hid/hid-ids.h | 5 +++++
> > drivers/hid/i2c-hid/i2c-hid.c | 32 ++++++++++++++++++++++++++++++++
> > 2 files changed, 37 insertions(+)
> >
> > diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index
> > 6cfb5ca..787afdf 100644
> > --- a/drivers/hid/hid-ids.h
> > +++ b/drivers/hid/hid-ids.h
> > @@ -1033,6 +1033,11 @@
> > #define USB_DEVICE_ID_WALTOP_MEDIA_TABLET_14_1_INCH 0x0500
> > #define USB_DEVICE_ID_WALTOP_SIRIUS_BATTERY_FREE_TABLET 0x0502
> >
> > +#define USB_VENDOR_ID_WEIDA 0x2575
> > +#define USB_DEVICE_ID_WEIDA_8756 0x8756
> > +#define USB_DEVICE_ID_WEIDA_8752 0xC300
> > +#define USB_DEVICE_ID_WEIDA_8755 0xC301
> > +
> > #define USB_VENDOR_ID_WISEGROUP 0x0925
> > #define USB_DEVICE_ID_SMARTJOY_PLUS 0x0005
> > #define USB_DEVICE_ID_SUPER_JOY_BOX_3 0x8888
> > diff --git a/drivers/hid/i2c-hid/i2c-hid.c
> > b/drivers/hid/i2c-hid/i2c-hid.c index b3ec4f2..7a9b100 100644
> > --- a/drivers/hid/i2c-hid/i2c-hid.c
> > +++ b/drivers/hid/i2c-hid/i2c-hid.c
> > @@ -41,6 +41,11 @@
> >
> > #include <linux/i2c/i2c-hid.h>
> >
> > +#include "../hid-ids.h"
> > +
> > +/* quirks to control the device */
> > +#define I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV (1 << 0)
> > +
> > /* flags */
> > #define I2C_HID_STARTED 0
> > #define I2C_HID_RESET_PENDING 1
> > @@ -143,6 +148,7 @@ struct i2c_hid {
> > char *argsbuf; /* Command arguments buffer */
> >
> > unsigned long flags; /* device flags */
> > + unsigned long quirks; /* Various quirks */
> >
> > wait_queue_head_t wait; /* For waiting the interrupt */
> > struct gpio_desc *desc;
> > @@ -154,6 +160,25 @@ struct i2c_hid {
> > struct mutex reset_lock;
> > };
> >
> > +/*
> > + * i2c_hid_lookup_quirk: return any quirks associated with a I2C HID
> > +device
> > + * @idVendor: the 16-bit vendor ID
> > + * @idProduct: the 16-bit product ID
> > + *
> > + * Returns: a u32 quirks value.
> > + */
> > +static u32 i2c_hid_lookup_quirk(const u16 idVendor, const u16
> > +idProduct) {
> > + u32 quirks = 0;
> > +
> > + /* Weida devices check here */
> > + if (idVendor == USB_VENDOR_ID_WEIDA &&
> > + idProduct >= USB_DEVICE_ID_WEIDA_8752)
>
> Wouldn't it make more sense to have a static table of the affected products, instead of this test?
>
> > + return I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV;
> > +
> > + return quirks;
> > +}
> > +
> > static int __i2c_hid_command(struct i2c_client *client,
> > const struct i2c_hid_cmd *command, u8 reportID,
> > u8 reportType, u8 *args, int args_len, @@ -346,6 +371,11 @@ static
> > int i2c_hid_set_power(struct i2c_client *client, int power_state)
> >
> > i2c_hid_dbg(ihid, "%s\n", __func__);
> >
> > + /* Some devices require to send a command to wakeup first */
> > + if (power_state == I2C_HID_PWR_ON &&
> > + ihid->quirks & I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV)
> > + i2c_hid_command(client, &hid_set_power_cmd, NULL, 0);
>
> Isn't there a need to check the return value here?
>
> > +
> > ret = __i2c_hid_command(client, &hid_set_power_cmd, power_state,
> > 0, NULL, 0, NULL, 0);
> > if (ret)
> > @@ -661,6 +691,8 @@ static int i2c_hid_parse(struct hid_device *hid)
> >
> > i2c_hid_dbg(ihid, "entering %s\n", __func__);
> >
> > + ihid->quirks = i2c_hid_lookup_quirk(hid->vendor, hid->product);
>
> Please lookup for the quirks in i2c_hid_probe(), right after we set version, vendor and product
>
> > +
> > rsize = le16_to_cpu(hdesc->wReportDescLength);
> > if (!rsize || rsize > HID_MAX_DESCRIPTOR_SIZE) {
> > dbg_hid("weird size of report descriptor (%u)\n", rsize);
> > --
> > 1.9.1
> >
>
> Cheers,
> Benjamin
>
^ permalink raw reply
* [Bug 98627] mesa doesn't build since llvm r286062
From: bugzilla-daemon @ 2016-11-09 8:24 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-98627-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 511 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=98627
Laurent carlier <lordheavym@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bero@lindev.ch
--- Comment #2 from Laurent carlier <lordheavym@gmail.com> ---
*** Bug 98652 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 2004 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [Buildroot] [PATCH] package/e2fsprogs: backport build fix for rhel5 due to missing magic
From: Baruch Siach @ 2016-11-09 8:24 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAMo8BfJnGVYAd_3nUDFZbtWDQNkTOcOr_z6NpV9OK8YKNS4N8g@mail.gmail.com>
Hi Max,
On Wed, Nov 09, 2016 at 12:18:07AM -0800, Max Filippov wrote:
> On Wed, Nov 9, 2016 at 12:03 AM, Baruch Siach <baruch@tkos.co.il> wrote:
> > On Tue, Nov 08, 2016 at 11:39:02PM -0800, Max Filippov wrote:
> >> RHEL 5.x does have magic.h, but it does not define all expected symbols. In
> >> particular, the NO_CHECK symbols were only added in file 4.20 and RHEL 5.x
> >> is using 4.17.
> >
> > Instead of relying on host libmagic that may or may not be installed, why not
> > add host-file to HOST_E2FSPROGS_DEPENDENCIES?
>
> My first reaction was to look if the issue is addressed in the package mainline,
> and that's how e2fsprogs mainline decided to deal with that. So the next
> version bump of e2fsprogs will make host-libmagic not necessary, there's
> probably no reason to introduce that dependency?
>
> "libmagic installed" vs. "not installed" is handled well by e2fsprogs, it's
> "installed, but too old" case that fails.
We would generally like to avoid dependency on host libraries as much as
possible since it reduces the build reproducibility. But as this is just a
host tool I'm not sure we care.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH v2] arm64: dts: marvell: Fix typo in label name on Armada 37xx
From: Gregory CLEMENT @ 2016-11-09 8:24 UTC (permalink / raw)
To: linux-arm-kernel
The label names of the peripheral clocks have a typo. Fix it before it is
more widely used.
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Changelog:
v1 -> v2
Fix missing space
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index c4762538ec01..e9bd58793464 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -105,7 +105,7 @@
status = "disabled";
};
- nb_perih_clk: nb-periph-clk at 13000{
+ nb_periph_clk: nb-periph-clk at 13000 {
compatible = "marvell,armada-3700-periph-clock-nb";
reg = <0x13000 0x100>;
clocks = <&tbg 0>, <&tbg 1>, <&tbg 2>,
@@ -113,7 +113,7 @@
#clock-cells = <1>;
};
- sb_perih_clk: sb-periph-clk at 18000{
+ sb_periph_clk: sb-periph-clk at 18000 {
compatible = "marvell,armada-3700-periph-clock-sb";
reg = <0x18000 0x100>;
clocks = <&tbg 0>, <&tbg 1>, <&tbg 2>,
--
2.10.1
^ permalink raw reply related
* [PATCH] examples/l3fwd: force CRC stripping for i40evf
From: Björn Töpel @ 2016-11-09 8:23 UTC (permalink / raw)
To: dev
Cc: qian.q.xu, lei.a.yao, jingjing.wu, thomas.monjalon,
Björn Töpel
Commit 1bbcc5d21129 ("i40evf: report error for unsupported CRC
stripping config") broke l3fwd, since it was forcing that CRC was
kept. Now, if i40evf is running, CRC stripping will be enabled.
Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
---
examples/l3fwd/main.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 7223e773107e..b60278794135 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -906,6 +906,14 @@ main(int argc, char **argv)
n_tx_queue = MAX_TX_QUEUE_PER_PORT;
printf("Creating queues: nb_rxq=%d nb_txq=%u... ",
nb_rx_queue, (unsigned)n_tx_queue );
+ rte_eth_dev_info_get(portid, &dev_info);
+ if (dev_info.driver_name &&
+ strcmp(dev_info.driver_name, "net_i40e_vf") == 0) {
+ /* i40evf require that CRC stripping is enabled. */
+ port_conf.rxmode.hw_strip_crc = 1;
+ } else {
+ port_conf.rxmode.hw_strip_crc = 0;
+ }
ret = rte_eth_dev_configure(portid, nb_rx_queue,
(uint16_t)n_tx_queue, &port_conf);
if (ret < 0)
@@ -946,7 +954,6 @@ main(int argc, char **argv)
printf("txq=%u,%d,%d ", lcore_id, queueid, socketid);
fflush(stdout);
- rte_eth_dev_info_get(portid, &dev_info);
txconf = &dev_info.default_txconf;
if (port_conf.rxmode.jumbo_frame)
txconf->txq_flags = 0;
--
2.9.3
^ permalink raw reply related
* FAILED: patch "[PATCH] drm: Don't force all planes to be added to the state due to" failed to apply to 4.8-stable tree
From: gregkh @ 2016-11-09 8:22 UTC (permalink / raw)
To: ville.syrjala, benjamin.gaignard, cpaul, daniel.vetter, daniel,
inki.dae, jy0922.shim, kyungmin.park, laurent.pinchart,
m.szyprowski, maarten.lankhorst, seanpaul, sw0312.kim,
vincent.abriou
Cc: stable
The patch below does not apply to the 4.8-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 38d868e41c4b9250d5a115c049dc2d48f4909581 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
Date: Mon, 10 Oct 2016 17:50:56 +0300
Subject: [PATCH] drm: Don't force all planes to be added to the state due to
zpos
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We don't want all planes to be added to the state whenever a
plane with fixed zpos gets enabled/disabled. This is true
especially for eg. cursor planes on i915, as we want cursor
updates to go through w/o throttling. Same holds for drivers
that don't support zpos at all (i915 actually falls into this
category right now since we've not yet added zpos support).
Allow drivers more freedom by letting them deal with zpos
themselves instead of doing it in drm_atomic_helper_check_planes()
unconditionally. Let's just inline the required calls into all
the driver that currently depend on this.
v2: Inline the stuff into the drivers instead of adding another
helper, document things better (Daniel)
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Lyude <cpaul@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: stable@vger.kernel.org
Fixes: 44d1240d006c ("drm: add generic zpos property")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1476111056-12734-1-git-send-email-ville.syrjala@linux.intel.com
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index c3f83476f996..21f992605541 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -594,10 +594,6 @@ drm_atomic_helper_check_planes(struct drm_device *dev,
struct drm_plane_state *plane_state;
int i, ret = 0;
- ret = drm_atomic_normalize_zpos(dev, state);
- if (ret)
- return ret;
-
for_each_plane_in_state(state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index def78c8c1780..f86e7c846678 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -262,6 +262,26 @@ int exynos_atomic_commit(struct drm_device *dev, struct drm_atomic_state *state,
return 0;
}
+int exynos_atomic_check(struct drm_device *dev,
+ struct drm_atomic_state *state)
+{
+ int ret;
+
+ ret = drm_atomic_helper_check_modeset(dev, state);
+ if (ret)
+ return ret;
+
+ ret = drm_atomic_normalize_zpos(dev, state);
+ if (ret)
+ return ret;
+
+ ret = drm_atomic_helper_check_planes(dev, state);
+ if (ret)
+ return ret;
+
+ return ret;
+}
+
static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
{
struct drm_exynos_file_private *file_priv;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index d215149e737b..80c4d5b81689 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -301,6 +301,7 @@ static inline int exynos_dpi_bind(struct drm_device *dev,
int exynos_atomic_commit(struct drm_device *dev, struct drm_atomic_state *state,
bool nonblock);
+int exynos_atomic_check(struct drm_device *dev, struct drm_atomic_state *state);
extern struct platform_driver fimd_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 40ce841eb952..23cce0a3f5fc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -190,7 +190,7 @@ dma_addr_t exynos_drm_fb_dma_addr(struct drm_framebuffer *fb, int index)
static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = exynos_drm_output_poll_changed,
- .atomic_check = drm_atomic_helper_check,
+ .atomic_check = exynos_atomic_check,
.atomic_commit = exynos_atomic_commit,
};
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index bd9c3bb9252c..392c7e6de042 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -231,8 +231,16 @@ static int rcar_du_atomic_check(struct drm_device *dev,
struct rcar_du_device *rcdu = dev->dev_private;
int ret;
- ret = drm_atomic_helper_check(dev, state);
- if (ret < 0)
+ ret = drm_atomic_helper_check_modeset(dev, state);
+ if (ret)
+ return ret;
+
+ ret = drm_atomic_normalize_zpos(dev, state);
+ if (ret)
+ return ret;
+
+ ret = drm_atomic_helper_check_planes(dev, state);
+ if (ret)
return ret;
if (rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 2784919a7366..9df308565f6c 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -195,6 +195,26 @@ static void sti_atomic_work(struct work_struct *work)
sti_atomic_complete(private, private->commit.state);
}
+static int sti_atomic_check(struct drm_device *dev,
+ struct drm_atomic_state *state)
+{
+ int ret;
+
+ ret = drm_atomic_helper_check_modeset(dev, state);
+ if (ret)
+ return ret;
+
+ ret = drm_atomic_normalize_zpos(dev, state);
+ if (ret)
+ return ret;
+
+ ret = drm_atomic_helper_check_planes(dev, state);
+ if (ret)
+ return ret;
+
+ return ret;
+}
+
static int sti_atomic_commit(struct drm_device *drm,
struct drm_atomic_state *state, bool nonblock)
{
@@ -248,7 +268,7 @@ static void sti_output_poll_changed(struct drm_device *ddev)
static const struct drm_mode_config_funcs sti_mode_config_funcs = {
.fb_create = drm_fb_cma_create,
.output_poll_changed = sti_output_poll_changed,
- .atomic_check = drm_atomic_helper_check,
+ .atomic_check = sti_atomic_check,
.atomic_commit = sti_atomic_commit,
};
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 43cf193e54d6..8b4dc62470ff 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -47,8 +47,14 @@ struct drm_crtc;
* @src_h: height of visible portion of plane (in 16.16)
* @rotation: rotation of the plane
* @zpos: priority of the given plane on crtc (optional)
+ * Note that multiple active planes on the same crtc can have an identical
+ * zpos value. The rule to solving the conflict is to compare the plane
+ * object IDs; the plane with a higher ID must be stacked on top of a
+ * plane with a lower ID.
* @normalized_zpos: normalized value of zpos: unique, range from 0 to N-1
- * where N is the number of active planes for given crtc
+ * where N is the number of active planes for given crtc. Note that
+ * the driver must call drm_atomic_normalize_zpos() to update this before
+ * it can be trusted.
* @src: clipped source coordinates of the plane (in 16.16)
* @dst: clipped destination coordinates of the plane
* @visible: visibility of the plane
^ permalink raw reply related
* Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)
From: Martin Steigerwald @ 2016-11-09 8:20 UTC (permalink / raw)
To: intel-gfx
Cc: Jani Nikula, Intel Gfx Mailing List, Linus Torvalds,
Linux Kernel Mailing List
In-Reply-To: <3409292.hOGaBhKxQ4@merkaba>
Am Dienstag, 8. November 2016, 16:17:59 CET schrieb Martin Steigerwald:
> Am Dienstag, 8. November 2016, 16:11:31 CET schrieb Martin Steigerwald:
> > Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> > > On Mon, 07 Nov 2016, Martin Steigerwald <martin@lichtvoll.de> wrote:
> > > > It is also the same kind of corruptions as shown in
> > > >
> > > > [Bug 177701] warning in intel_dp_aux_transfer
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> > > >
> > > > Just compare
> > > >
> > > > https://bugzilla.kernel.org/attachment.cgi?id=241801
> > > >
> > > > with
> > > >
> > > > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.p
> > > > ng
> > > >
> > > >
> > > > However that bug report links to
> > > >
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > > >
> > > > yet the patch mentioned in there does not fix the issue. So I wonder
> > > > whether bug #97344 and bug #177701 are really the same.
> > >
> > > They are the same, it's just that #177701 conflates two issues, a
> > > warning (tracked at fdo #973449) and a graphics corruption. The latter
> > > appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402.
> > >
> > > The fix has now been pushed to drm-intel-fixes branch of
> > > http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen
> > > latest fixes. Please try that and report back.
> >
> > For now commit 54905ab5fe7aa453610e31cec640e528aaedb2e2 of drm-intel-fixes
>
> I ment not exactly this commit, but this is the last commit in the branch as
> I compiled the kernel.
>
> > branch seems to work okay. I can only test with laptop display at the
> > moment. But I will test with external display this evening – in case the
> > issue at hand is DisplayPort related.
Also no graphics glitches with external DisplayPort connected display.
*However*, I got a soft freeze and a hard freeze (well after about a minute I
gave up and rebooted by pressing power button long enough to forcefully switch
off the laptop) when playing PlaneShift using drm-intel-fixes branch.
Unfortunately I have no further time to debug any of this week, but it seems
not all fixes are there are ready for next stable kernel.
Ciao,
Martin
> > I will add this information to fdo bug 98402 as well.
> >
> > Thanks,
> > Martin
> >
> > > > Of course I can report a bug at fdo as well, but I am a bit confused
> > > > whether it may not already have been reported. Well I hope I get a
> > > > chance to report it there as well and you get to decide.
> > >
> > > If drm-intel-fixes doesn't fix the issue for you, please file a *new*
> > > bug over at the freedesktop.org bugzilla.
> > >
> > > BR,
> > > Jani.
--
Martin
^ permalink raw reply
* Re: [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)
From: Martin Steigerwald @ 2016-11-09 8:20 UTC (permalink / raw)
To: intel-gfx
Cc: Intel Gfx Mailing List, Linus Torvalds, Linux Kernel Mailing List
In-Reply-To: <3409292.hOGaBhKxQ4@merkaba>
Am Dienstag, 8. November 2016, 16:17:59 CET schrieb Martin Steigerwald:
> Am Dienstag, 8. November 2016, 16:11:31 CET schrieb Martin Steigerwald:
> > Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> > > On Mon, 07 Nov 2016, Martin Steigerwald <martin@lichtvoll.de> wrote:
> > > > It is also the same kind of corruptions as shown in
> > > >
> > > > [Bug 177701] warning in intel_dp_aux_transfer
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> > > >
> > > > Just compare
> > > >
> > > > https://bugzilla.kernel.org/attachment.cgi?id=241801
> > > >
> > > > with
> > > >
> > > > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.p
> > > > ng
> > > >
> > > >
> > > > However that bug report links to
> > > >
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > > >
> > > > yet the patch mentioned in there does not fix the issue. So I wonder
> > > > whether bug #97344 and bug #177701 are really the same.
> > >
> > > They are the same, it's just that #177701 conflates two issues, a
> > > warning (tracked at fdo #973449) and a graphics corruption. The latter
> > > appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402.
> > >
> > > The fix has now been pushed to drm-intel-fixes branch of
> > > http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen
> > > latest fixes. Please try that and report back.
> >
> > For now commit 54905ab5fe7aa453610e31cec640e528aaedb2e2 of drm-intel-fixes
>
> I ment not exactly this commit, but this is the last commit in the branch as
> I compiled the kernel.
>
> > branch seems to work okay. I can only test with laptop display at the
> > moment. But I will test with external display this evening – in case the
> > issue at hand is DisplayPort related.
Also no graphics glitches with external DisplayPort connected display.
*However*, I got a soft freeze and a hard freeze (well after about a minute I
gave up and rebooted by pressing power button long enough to forcefully switch
off the laptop) when playing PlaneShift using drm-intel-fixes branch.
Unfortunately I have no further time to debug any of this week, but it seems
not all fixes are there are ready for next stable kernel.
Ciao,
Martin
> > I will add this information to fdo bug 98402 as well.
> >
> > Thanks,
> > Martin
> >
> > > > Of course I can report a bug at fdo as well, but I am a bit confused
> > > > whether it may not already have been reported. Well I hope I get a
> > > > chance to report it there as well and you get to decide.
> > >
> > > If drm-intel-fixes doesn't fix the issue for you, please file a *new*
> > > bug over at the freedesktop.org bugzilla.
> > >
> > > BR,
> > > Jani.
--
Martin
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* FAILED: patch "[PATCH] drm/amdgpu/si_dpm: workaround for SI kickers" failed to apply to 4.8-stable tree
From: gregkh @ 2016-11-09 8:19 UTC (permalink / raw)
To: alexander.deucher, ray.huang; +Cc: stable
The patch below does not apply to the 4.8-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 71451bdfc2f7bc67cf0b7a5d51bc1489aaa55701 Mon Sep 17 00:00:00 2001
From: Alex Deucher <alexander.deucher@amd.com>
Date: Wed, 26 Oct 2016 15:27:45 -0400
Subject: [PATCH] drm/amdgpu/si_dpm: workaround for SI kickers
Consolidate existing quirks. Fixes stability issues
on some kickers.
Acked-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
index ee77e9cb55b1..d6f85b1a0b93 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -3477,6 +3477,49 @@ static void si_apply_state_adjust_rules(struct amdgpu_device *adev,
int i;
struct si_dpm_quirk *p = si_dpm_quirk_list;
+ /* limit all SI kickers */
+ if (adev->asic_type == CHIP_PITCAIRN) {
+ if ((adev->pdev->revision == 0x81) ||
+ (adev->pdev->device == 0x6810) ||
+ (adev->pdev->device == 0x6811) ||
+ (adev->pdev->device == 0x6816) ||
+ (adev->pdev->device == 0x6817) ||
+ (adev->pdev->device == 0x6806))
+ max_mclk = 120000;
+ } else if (adev->asic_type == CHIP_VERDE) {
+ if ((adev->pdev->revision == 0x81) ||
+ (adev->pdev->revision == 0x83) ||
+ (adev->pdev->revision == 0x87) ||
+ (adev->pdev->device == 0x6820) ||
+ (adev->pdev->device == 0x6821) ||
+ (adev->pdev->device == 0x6822) ||
+ (adev->pdev->device == 0x6823) ||
+ (adev->pdev->device == 0x682A) ||
+ (adev->pdev->device == 0x682B)) {
+ max_sclk = 75000;
+ max_mclk = 80000;
+ }
+ } else if (adev->asic_type == CHIP_OLAND) {
+ if ((adev->pdev->revision == 0xC7) ||
+ (adev->pdev->revision == 0x80) ||
+ (adev->pdev->revision == 0x81) ||
+ (adev->pdev->revision == 0x83) ||
+ (adev->pdev->device == 0x6604) ||
+ (adev->pdev->device == 0x6605)) {
+ max_sclk = 75000;
+ max_mclk = 80000;
+ }
+ } else if (adev->asic_type == CHIP_HAINAN) {
+ if ((adev->pdev->revision == 0x81) ||
+ (adev->pdev->revision == 0x83) ||
+ (adev->pdev->revision == 0xC3) ||
+ (adev->pdev->device == 0x6664) ||
+ (adev->pdev->device == 0x6665) ||
+ (adev->pdev->device == 0x6667)) {
+ max_sclk = 75000;
+ max_mclk = 80000;
+ }
+ }
/* Apply dpm quirks */
while (p && p->chip_device != 0) {
if (adev->pdev->vendor == p->chip_vendor &&
@@ -3489,22 +3532,6 @@ static void si_apply_state_adjust_rules(struct amdgpu_device *adev,
}
++p;
}
- /* limit mclk on all R7 370 parts for stability */
- if (adev->pdev->device == 0x6811 &&
- adev->pdev->revision == 0x81)
- max_mclk = 120000;
- /* limit sclk/mclk on Jet parts for stability */
- if (adev->pdev->device == 0x6665 &&
- adev->pdev->revision == 0xc3) {
- max_sclk = 75000;
- max_mclk = 80000;
- }
- /* Limit clocks for some HD8600 parts */
- if (adev->pdev->device == 0x6660 &&
- adev->pdev->revision == 0x83) {
- max_sclk = 75000;
- max_mclk = 80000;
- }
if (rps->vce_active) {
rps->evclk = adev->pm.dpm.vce_states[adev->pm.dpm.vce_level].evclk;
^ permalink raw reply related
* Patch "scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 UTC (permalink / raw)
To: emilne, gregkh, loberman, martin.petersen; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded
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:
scsi-scsi_debug-fix-memory-leak-if-lbp-enabled-and-module-is-unloaded.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 4d2b496f19f3c2cfaca1e8fa0710688b5ff3811d Mon Sep 17 00:00:00 2001
From: "Ewan D. Milne" <emilne@redhat.com>
Date: Wed, 26 Oct 2016 11:22:53 -0400
Subject: scsi: scsi_debug: Fix memory leak if LBP enabled and module is unloaded
From: Ewan D. Milne <emilne@redhat.com>
commit 4d2b496f19f3c2cfaca1e8fa0710688b5ff3811d upstream.
map_storep was not being vfree()'d in the module_exit call.
Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/scsi_debug.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -5134,6 +5134,7 @@ static void __exit scsi_debug_exit(void)
bus_unregister(&pseudo_lld_bus);
root_device_unregister(pseudo_primary);
+ vfree(map_storep);
vfree(dif_storep);
vfree(fake_storep);
kfree(sdebug_q_arr);
Patches currently in stable-queue which might be from emilne@redhat.com are
queue-4.8/scsi-megaraid_sas-fix-data-integrity-failure-for-jbod-passthrough-devices.patch
queue-4.8/scsi-scsi_debug-fix-memory-leak-if-lbp-enabled-and-module-is-unloaded.patch
^ permalink raw reply
* Patch "scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 UTC (permalink / raw)
To: kashyap.desai, emilne, gregkh, hare, martin.petersen,
sumit.saxena, thenzl
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices
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:
scsi-megaraid_sas-fix-data-integrity-failure-for-jbod-passthrough-devices.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 1e793f6fc0db920400574211c48f9157a37e3945 Mon Sep 17 00:00:00 2001
From: Kashyap Desai <kashyap.desai@broadcom.com>
Date: Fri, 21 Oct 2016 06:33:32 -0700
Subject: scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) devices
From: Kashyap Desai <kashyap.desai@broadcom.com>
commit 1e793f6fc0db920400574211c48f9157a37e3945 upstream.
Commit 02b01e010afe ("megaraid_sas: return sync cache call with
success") modified the driver to successfully complete SYNCHRONIZE_CACHE
commands without passing them to the controller. Disk drive caches are
only explicitly managed by controller firmware when operating in RAID
mode. So this commit effectively disabled writeback cache flushing for
any drives used in JBOD mode, leading to data integrity failures.
[mkp: clarified patch description]
Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
Signed-off-by: Kashyap Desai <kashyap.desai@broadcom.com>
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/megaraid/megaraid_sas_base.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -1713,16 +1713,13 @@ megasas_queue_command(struct Scsi_Host *
goto out_done;
}
- switch (scmd->cmnd[0]) {
- case SYNCHRONIZE_CACHE:
- /*
- * FW takes care of flush cache on its own
- * No need to send it down
- */
+ /*
+ * FW takes care of flush cache on its own for Virtual Disk.
+ * No need to send it down for VD. For JBOD send SYNCHRONIZE_CACHE to FW.
+ */
+ if ((scmd->cmnd[0] == SYNCHRONIZE_CACHE) && MEGASAS_IS_LOGICAL(scmd)) {
scmd->result = DID_OK << 16;
goto out_done;
- default:
- break;
}
return instance->instancet->build_and_issue_cmd(instance, scmd);
Patches currently in stable-queue which might be from kashyap.desai@broadcom.com are
queue-4.8/scsi-megaraid_sas-fix-data-integrity-failure-for-jbod-passthrough-devices.patch
^ permalink raw reply
* Patch "scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 UTC (permalink / raw)
To: ching2048, gregkh, martin.petersen, thenzl; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware
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:
scsi-arcmsr-send-synchronize_cache-command-to-firmware.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 2bf7dc8443e113844d078fd6541b7f4aa544f92f Mon Sep 17 00:00:00 2001
From: Ching Huang <ching2048@areca.com.tw>
Date: Wed, 19 Oct 2016 17:50:26 +0800
Subject: scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware
From: Ching Huang <ching2048@areca.com.tw>
commit 2bf7dc8443e113844d078fd6541b7f4aa544f92f upstream.
The arcmsr driver failed to pass SYNCHRONIZE CACHE to controller
firmware. Depending on how drive caches are handled internally by
controller firmware this could potentially lead to data integrity
problems.
Ensure that cache flushes are passed to the controller.
[mkp: applied by hand and removed unused vars]
Signed-off-by: Ching Huang <ching2048@areca.com.tw>
Reported-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/scsi/arcmsr/arcmsr_hba.c | 9 ---------
1 file changed, 9 deletions(-)
--- a/drivers/scsi/arcmsr/arcmsr_hba.c
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c
@@ -2636,18 +2636,9 @@ static int arcmsr_queue_command_lck(stru
struct AdapterControlBlock *acb = (struct AdapterControlBlock *) host->hostdata;
struct CommandControlBlock *ccb;
int target = cmd->device->id;
- int lun = cmd->device->lun;
- uint8_t scsicmd = cmd->cmnd[0];
cmd->scsi_done = done;
cmd->host_scribble = NULL;
cmd->result = 0;
- if ((scsicmd == SYNCHRONIZE_CACHE) ||(scsicmd == SEND_DIAGNOSTIC)){
- if(acb->devstate[target][lun] == ARECA_RAID_GONE) {
- cmd->result = (DID_NO_CONNECT << 16);
- }
- cmd->scsi_done(cmd);
- return 0;
- }
if (target == 16) {
/* virtual device for iop message transfer */
arcmsr_handle_virtual_command(acb, cmd);
Patches currently in stable-queue which might be from ching2048@areca.com.tw are
queue-4.8/scsi-arcmsr-send-synchronize_cache-command-to-firmware.patch
^ permalink raw reply
* Patch "Revert "drm/radeon: fix DP link training issue with second 4K monitor"" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 UTC (permalink / raw)
To: michel.daenzer, alexander.deucher, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
Revert "drm/radeon: fix DP link training issue with second 4K monitor"
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:
revert-drm-radeon-fix-dp-link-training-issue-with-second-4k-monitor.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 9dc79965b21967caebde575f5f5d8bf1aa2c23ab Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <michel.daenzer@amd.com>
Date: Mon, 24 Oct 2016 16:52:20 +0900
Subject: Revert "drm/radeon: fix DP link training issue with second 4K monitor"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Michel Dänzer <michel.daenzer@amd.com>
commit 9dc79965b21967caebde575f5f5d8bf1aa2c23ab upstream.
This reverts commit 1a738347df2ee4977459a8776fe2c62196bdcb1b.
It caused at least some Kaveri laptops to incorrectly report DisplayPort
connectors as connected.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97857
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/radeon/radeon_dp_auxch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
@@ -105,7 +105,7 @@ radeon_dp_aux_transfer_native(struct drm
tmp &= AUX_HPD_SEL(0x7);
tmp |= AUX_HPD_SEL(chan->rec.hpd);
- tmp |= AUX_EN | AUX_LS_READ_EN | AUX_HPD_DISCON(0x1);
+ tmp |= AUX_EN | AUX_LS_READ_EN;
WREG32(AUX_CONTROL + aux_offset[instance], tmp);
Patches currently in stable-queue which might be from michel.daenzer@amd.com are
queue-4.8/revert-drm-radeon-fix-dp-link-training-issue-with-second-4k-monitor.patch
^ permalink raw reply
* Patch "Revert "ath9k_hw: implement temperature compensation support for AR9003+"" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 UTC (permalink / raw)
To: nbd, gregkh, kvalo; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
Revert "ath9k_hw: implement temperature compensation support for AR9003+"
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:
revert-ath9k_hw-implement-temperature-compensation-support-for-ar9003.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 304e5ac118cc351eb047b6c433a89e13ea7259cf Mon Sep 17 00:00:00 2001
From: Felix Fietkau <nbd@nbd.name>
Date: Tue, 11 Oct 2016 19:46:49 +0200
Subject: Revert "ath9k_hw: implement temperature compensation support for AR9003+"
From: Felix Fietkau <nbd@nbd.name>
commit 304e5ac118cc351eb047b6c433a89e13ea7259cf upstream.
This reverts commit 171f6402e4aa ("ath9k_hw: implement temperature compensation
support for AR9003+"). Some users report that this commit causes a regression
in performance under some conditions.
Fixes: 171f6402e4aa ("ath9k_hw: implement temperature compensation support for AR9003+")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
[kvalo@qca.qualcomm.com: improve commit log]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 25 +++----------------------
drivers/net/wireless/ath/ath9k/hw.h | 1 -
2 files changed, 3 insertions(+), 23 deletions(-)
--- a/drivers/net/wireless/ath/ath9k/ar9003_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_calib.c
@@ -33,7 +33,6 @@ struct coeff {
enum ar9003_cal_types {
IQ_MISMATCH_CAL = BIT(0),
- TEMP_COMP_CAL = BIT(1),
};
static void ar9003_hw_setup_calibration(struct ath_hw *ah,
@@ -59,12 +58,6 @@ static void ar9003_hw_setup_calibration(
/* Kick-off cal */
REG_SET_BIT(ah, AR_PHY_TIMING4, AR_PHY_TIMING4_DO_CAL);
break;
- case TEMP_COMP_CAL:
- ath_dbg(common, CALIBRATE,
- "starting Temperature Compensation Calibration\n");
- REG_SET_BIT(ah, AR_CH0_THERM, AR_CH0_THERM_LOCAL);
- REG_SET_BIT(ah, AR_CH0_THERM, AR_CH0_THERM_START);
- break;
default:
ath_err(common, "Invalid calibration type\n");
break;
@@ -93,8 +86,7 @@ static bool ar9003_hw_per_calibration(st
/*
* Accumulate cal measures for active chains
*/
- if (cur_caldata->calCollect)
- cur_caldata->calCollect(ah);
+ cur_caldata->calCollect(ah);
ah->cal_samples++;
if (ah->cal_samples >= cur_caldata->calNumSamples) {
@@ -107,8 +99,7 @@ static bool ar9003_hw_per_calibration(st
/*
* Process accumulated data
*/
- if (cur_caldata->calPostProc)
- cur_caldata->calPostProc(ah, numChains);
+ cur_caldata->calPostProc(ah, numChains);
/* Calibration has finished. */
caldata->CalValid |= cur_caldata->calType;
@@ -323,16 +314,9 @@ static const struct ath9k_percal_data iq
ar9003_hw_iqcalibrate
};
-static const struct ath9k_percal_data temp_cal_single_sample = {
- TEMP_COMP_CAL,
- MIN_CAL_SAMPLES,
- PER_MAX_LOG_COUNT,
-};
-
static void ar9003_hw_init_cal_settings(struct ath_hw *ah)
{
ah->iq_caldata.calData = &iq_cal_single_sample;
- ah->temp_caldata.calData = &temp_cal_single_sample;
if (AR_SREV_9300_20_OR_LATER(ah)) {
ah->enabled_cals |= TX_IQ_CAL;
@@ -340,7 +324,7 @@ static void ar9003_hw_init_cal_settings(
ah->enabled_cals |= TX_IQ_ON_AGC_CAL;
}
- ah->supp_cals = IQ_MISMATCH_CAL | TEMP_COMP_CAL;
+ ah->supp_cals = IQ_MISMATCH_CAL;
}
#define OFF_UPPER_LT 24
@@ -1399,9 +1383,6 @@ static void ar9003_hw_init_cal_common(st
INIT_CAL(&ah->iq_caldata);
INSERT_CAL(ah, &ah->iq_caldata);
- INIT_CAL(&ah->temp_caldata);
- INSERT_CAL(ah, &ah->temp_caldata);
-
/* Initialize current pointer to first element in list */
ah->cal_list_curr = ah->cal_list;
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -830,7 +830,6 @@ struct ath_hw {
/* Calibration */
u32 supp_cals;
struct ath9k_cal_list iq_caldata;
- struct ath9k_cal_list temp_caldata;
struct ath9k_cal_list adcgain_caldata;
struct ath9k_cal_list adcdc_caldata;
struct ath9k_cal_list *cal_list;
Patches currently in stable-queue which might be from nbd@nbd.name are
queue-4.8/revert-ath9k_hw-implement-temperature-compensation-support-for-ar9003.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.