* 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
* Patch "RAID10: ignore discard error" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 UTC (permalink / raw)
To: shli, gregkh, sitsofe; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
RAID10: ignore discard error
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:
raid10-ignore-discard-error.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 579ed34f7b751b8add233cba4cf755258dbdd60a Mon Sep 17 00:00:00 2001
From: Shaohua Li <shli@fb.com>
Date: Thu, 6 Oct 2016 14:13:52 -0700
Subject: RAID10: ignore discard error
From: Shaohua Li <shli@fb.com>
commit 579ed34f7b751b8add233cba4cf755258dbdd60a upstream.
This is the counterpart of raid10 fix. If a write error occurs, raid10
will try to rewrite the bio in small chunk size. If the rewrite fails,
raid10 will record the error in bad block. narrow_write_error will
always use WRITE for the bio, but actually it could be a discard. Since
discard bio hasn't payload, write the bio will cause different issues.
But discard error isn't fatal, we can safely ignore it. This is what
this patch does.
This issue should exist since discard is added, but only exposed with
recent arbitrary bio size feature.
Cc: Sitsofe Wheeler <sitsofe@gmail.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/raid10.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -447,6 +447,9 @@ static void raid10_end_write_request(str
struct r10conf *conf = r10_bio->mddev->private;
int slot, repl;
struct md_rdev *rdev = NULL;
+ bool discard_error;
+
+ discard_error = bio->bi_error && bio_op(bio) == REQ_OP_DISCARD;
dev = find_bio_disk(conf, r10_bio, bio, &slot, &repl);
@@ -460,7 +463,7 @@ static void raid10_end_write_request(str
/*
* this branch is our 'one mirror IO has finished' event handler:
*/
- if (bio->bi_error) {
+ if (bio->bi_error && !discard_error) {
if (repl)
/* Never record new bad blocks to replacement,
* just fail it.
@@ -503,7 +506,7 @@ static void raid10_end_write_request(str
if (is_badblock(rdev,
r10_bio->devs[slot].addr,
r10_bio->sectors,
- &first_bad, &bad_sectors)) {
+ &first_bad, &bad_sectors) && !discard_error) {
bio_put(bio);
if (repl)
r10_bio->devs[slot].repl_bio = IO_MADE_GOOD;
Patches currently in stable-queue which might be from shli@fb.com are
queue-4.8/raid1-ignore-discard-error.patch
queue-4.8/raid10-ignore-discard-error.patch
queue-4.8/md-be-careful-not-lot-leak-internal-curr_resync-value-into-metadata.-all.patch
^ permalink raw reply
* Patch "RAID1: ignore discard error" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 UTC (permalink / raw)
To: shli, gregkh, sitsofe; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
RAID1: ignore discard error
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:
raid1-ignore-discard-error.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 e3f948cd3283e4fbe5907f1f3967c839912f480e Mon Sep 17 00:00:00 2001
From: Shaohua Li <shli@fb.com>
Date: Thu, 6 Oct 2016 14:09:16 -0700
Subject: RAID1: ignore discard error
From: Shaohua Li <shli@fb.com>
commit e3f948cd3283e4fbe5907f1f3967c839912f480e upstream.
If a write error occurs, raid1 will try to rewrite the bio in small
chunk size. If the rewrite fails, raid1 will record the error in bad
block. narrow_write_error will always use WRITE for the bio, but
actually it could be a discard. Since discard bio hasn't payload, write
the bio will cause different issues. But discard error isn't fatal, we
can safely ignore it. This is what this patch does.
This issue should exist since discard is added, but only exposed with
recent arbitrary bio size feature.
Reported-and-tested-by: Sitsofe Wheeler <sitsofe@gmail.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/raid1.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -407,11 +407,14 @@ static void raid1_end_write_request(stru
struct bio *to_put = NULL;
int mirror = find_bio_disk(r1_bio, bio);
struct md_rdev *rdev = conf->mirrors[mirror].rdev;
+ bool discard_error;
+
+ discard_error = bio->bi_error && bio_op(bio) == REQ_OP_DISCARD;
/*
* 'one mirror IO has finished' event handler:
*/
- if (bio->bi_error) {
+ if (bio->bi_error && !discard_error) {
set_bit(WriteErrorSeen, &rdev->flags);
if (!test_and_set_bit(WantReplacement, &rdev->flags))
set_bit(MD_RECOVERY_NEEDED, &
@@ -448,7 +451,7 @@ static void raid1_end_write_request(stru
/* Maybe we can clear some bad blocks. */
if (is_badblock(rdev, r1_bio->sector, r1_bio->sectors,
- &first_bad, &bad_sectors)) {
+ &first_bad, &bad_sectors) && !discard_error) {
r1_bio->bios[mirror] = IO_MADE_GOOD;
set_bit(R1BIO_MadeGood, &r1_bio->state);
}
Patches currently in stable-queue which might be from shli@fb.com are
queue-4.8/raid1-ignore-discard-error.patch
queue-4.8/raid10-ignore-discard-error.patch
queue-4.8/md-be-careful-not-lot-leak-internal-curr_resync-value-into-metadata.-all.patch
^ permalink raw reply
* Patch "mmc: dw_mmc-pltfm: fix the potential NULL pointer dereference" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 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.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:
mmc-dw_mmc-pltfm-fix-the-potential-null-pointer-dereference.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 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
@@ -46,12 +46,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.8/mmc-dw_mmc-pltfm-fix-the-potential-null-pointer-dereference.patch
^ permalink raw reply
* Patch "md: be careful not lot leak internal curr_resync value into metadata. -- (all)" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 UTC (permalink / raw)
To: neilb, gregkh, shli, viswesh.vichu; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
md: be careful not lot leak internal curr_resync value into metadata. -- (all)
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:
md-be-careful-not-lot-leak-internal-curr_resync-value-into-metadata.-all.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 1217e1d1999ed6c9c1e1b1acae0a74ab70464ae2 Mon Sep 17 00:00:00 2001
From: NeilBrown <neilb@suse.com>
Date: Fri, 28 Oct 2016 15:59:41 +1100
Subject: md: be careful not lot leak internal curr_resync value into metadata. -- (all)
From: NeilBrown <neilb@suse.com>
commit 1217e1d1999ed6c9c1e1b1acae0a74ab70464ae2 upstream.
mddev->curr_resync usually records where the current resync is up to,
but during the starting phase it has some "magic" values.
1 - means that the array is trying to start a resync, but has yielded
to another array which shares physical devices, and also needs to
start a resync
2 - means the array is trying to start resync, but has found another
array which shares physical devices and has already started resync.
3 - means that resync has commensed, but it is possible that nothing
has actually been resynced yet.
It is important that this value not be visible to user-space and
particularly that it doesn't get written to the metadata, as the
resync or recovery checkpoint. In part, this is because it may be
slightly higher than the correct value, though this is very rare.
In part, because it is not a multiple of 4K, and some devices only
support 4K aligned accesses.
There are two places where this value is propagates into either
->curr_resync_completed or ->recovery_cp or ->recovery_offset.
These currently avoid the propagation of values 1 and 3, but will
allow 3 to leak through.
Change them to only propagate the value if it is > 3.
As this can cause an array to fail, the patch is suitable for -stable.
Reported-by: Viswesh <viswesh.vichu@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/md.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -8120,14 +8120,14 @@ void md_do_sync(struct md_thread *thread
if (!test_bit(MD_RECOVERY_RESHAPE, &mddev->recovery) &&
!test_bit(MD_RECOVERY_INTR, &mddev->recovery) &&
- mddev->curr_resync > 2) {
+ mddev->curr_resync > 3) {
mddev->curr_resync_completed = mddev->curr_resync;
sysfs_notify(&mddev->kobj, NULL, "sync_completed");
}
mddev->pers->sync_request(mddev, max_sectors, &skipped);
if (!test_bit(MD_RECOVERY_CHECK, &mddev->recovery) &&
- mddev->curr_resync > 2) {
+ mddev->curr_resync > 3) {
if (test_bit(MD_RECOVERY_SYNC, &mddev->recovery)) {
if (test_bit(MD_RECOVERY_INTR, &mddev->recovery)) {
if (mddev->curr_resync >= mddev->recovery_cp) {
Patches currently in stable-queue which might be from neilb@suse.com are
queue-4.8/md-be-careful-not-lot-leak-internal-curr_resync-value-into-metadata.-all.patch
^ permalink raw reply
* Patch "mac80211: discard multicast and 4-addr A-MSDUs" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 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.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:
mac80211-discard-multicast-and-4-addr-a-msdus.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 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
@@ -2253,16 +2253,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.8/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.8-stable tree
From: gregkh @ 2016-11-09 8:18 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.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-radeon-si_dpm-limit-clocks-on-hd86xx-part.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 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.8/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.8-stable tree
From: gregkh @ 2016-11-09 8:18 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.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-radeon-si_dpm-workaround-for-si-kickers.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 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.8/revert-drm-radeon-fix-dp-link-training-issue-with-second-4k-monitor.patch
queue-4.8/drm-radeon-si_dpm-limit-clocks-on-hd86xx-part.patch
queue-4.8/drm-radeon-si_dpm-workaround-for-si-kickers.patch
queue-4.8/drm-radeon-drop-register-readback-in-cayman_cp_int_cntl_setup.patch
^ permalink raw reply
* Patch "drm/radeon: drop register readback in cayman_cp_int_cntl_setup" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 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.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-radeon-drop-register-readback-in-cayman_cp_int_cntl_setup.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 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.8/drm-radeon-drop-register-readback-in-cayman_cp_int_cntl_setup.patch
^ permalink raw reply
* Re: [PATCH v1 1/2] config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11
From: Torsten Bögershausen @ 2016-11-09 8:18 UTC (permalink / raw)
To: Jeff King, Lars Schneider; +Cc: git, gitster
In-Reply-To: <20161107172617.tlcrpwbjy2w7aoyc@sigill.intra.peff.net>
On 07.11.16 18:26, Jeff King wrote:
> On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote:
>
>> Good point. I think I found an even easier way to achieve the same.
>> What do you think about the patch below?
>>
>> [...]
>>
>> diff --git a/Makefile b/Makefile
>> index 9d6c245..f53fcc9 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1047,6 +1047,7 @@ ifeq ($(uname_S),Darwin)
>> endif
>> endif
>> ifndef NO_APPLE_COMMON_CRYPTO
>> + NO_OPENSSL = YesPlease
>> APPLE_COMMON_CRYPTO = YesPlease
>> COMPAT_CFLAGS += -DAPPLE_COMMON_CRYPTO
>> endif
>
> That is much simpler.
[]
I don't know if that is a correct solution.
If I have Mac OS 10.12 and Mac Ports installed, I may want to use
OPENSSL from Mac Ports.
How about this:
diff --git a/Makefile b/Makefile
index ee89c06..e93511f 100644
--- a/Makefile
+++ b/Makefile
@@ -1038,17 +1038,22 @@ ifeq ($(uname_S),Darwin)
ifeq ($(shell test -d /sw/lib && echo y),y)
BASIC_CFLAGS += -I/sw/include
BASIC_LDFLAGS += -L/sw/lib
+ HAS_OPENSSL = Yes
endif
endif
ifndef NO_DARWIN_PORTS
ifeq ($(shell test -d /opt/local/lib && echo y),y)
BASIC_CFLAGS += -I/opt/local/include
BASIC_LDFLAGS += -L/opt/local/lib
+ HAS_OPENSSL = Yes
endif
endif
ifndef NO_APPLE_COMMON_CRYPTO
APPLE_COMMON_CRYPTO = YesPlease
COMPAT_CFLAGS += -DAPPLE_COMMON_CRYPTO
+ ifndef HAS_OPENSSL
+ NO_OPENSSL = YesPlease
+ endif
endif
NO_REGEX = YesPlease
PTHREAD_LIBS =
^ permalink raw reply related
* Patch "drm/nouveau/acpi: fix check for power resources support" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 UTC (permalink / raw)
To: peter, airlied, gregkh, mika.westerberg, rick.2889; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/nouveau/acpi: fix check for power resources support
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-nouveau-acpi-fix-check-for-power-resources-support.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 b0a6af8b34c9ad20894aa46f85f4bf59d444f286 Mon Sep 17 00:00:00 2001
From: Peter Wu <peter@lekensteyn.nl>
Date: Mon, 31 Oct 2016 23:48:22 +0100
Subject: drm/nouveau/acpi: fix check for power resources support
From: Peter Wu <peter@lekensteyn.nl>
commit b0a6af8b34c9ad20894aa46f85f4bf59d444f286 upstream.
Check whether the kernel really supports power resources for a device,
otherwise the power might not be removed when the device is runtime
suspended (DSM should still work in these cases where PR does not).
This is a workaround for a problem where ACPICA and Windows 10 differ in
behavior. ACPICA does not correctly enumerate power resources within a
conditional block (due to delayed execution of such blocks) and as a
result power_resources is set to false even if _PR3 exists.
Fixes: 692a17dcc292 ("drm/nouveau/acpi: fix lockup with PCIe runtime PM")
Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398
Reported-and-tested-by: Rick Kerkhof <rick.2889@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -240,7 +240,8 @@ static bool nouveau_pr3_present(struct p
if (!parent_adev)
return false;
- return acpi_has_method(parent_adev->handle, "_PR3");
+ return parent_adev->power.flags.power_resources &&
+ acpi_has_method(parent_adev->handle, "_PR3");
}
static void nouveau_dsm_pci_probe(struct pci_dev *pdev, acpi_handle *dhandle_out,
Patches currently in stable-queue which might be from peter@lekensteyn.nl are
queue-4.8/drm-nouveau-acpi-fix-check-for-power-resources-support.patch
^ permalink raw reply
* Patch "drm/imx: ipuv3-plane: Switch EBA buffer only when we don't need modeset" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 UTC (permalink / raw)
To: gnuiyl, gregkh, p.zabel; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/imx: ipuv3-plane: Switch EBA buffer only when we don't need modeset
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-imx-ipuv3-plane-switch-eba-buffer-only-when-we-don-t-need-modeset.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 43daa01323da37a3692cabe1579ef5c2c4372e06 Mon Sep 17 00:00:00 2001
From: Liu Ying <gnuiyl@gmail.com>
Date: Mon, 10 Oct 2016 14:50:06 +0800
Subject: drm/imx: ipuv3-plane: Switch EBA buffer only when we don't need modeset
From: Liu Ying <gnuiyl@gmail.com>
commit 43daa01323da37a3692cabe1579ef5c2c4372e06 upstream.
We added active plane reconfiguration support by forcing a full modeset
operation. So, looking at old_plane_state->fb to determine whether we need to
switch EBA buffer(for hardware double buffering) in ipu_plane_atomic_set_base()
or not is no more correct. Instead, we should do that only when we don't need
modeset, otherwise, we initialize the two EBA buffers with the buffer address.
Fixes: c6c1f9bc798b ("drm/imx: Add active plane reconfiguration support")
Signed-off-by: Liu Ying <gnuiyl@gmail.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/imx/ipuv3-plane.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -108,6 +108,7 @@ static void ipu_plane_atomic_set_base(st
{
struct drm_plane *plane = &ipu_plane->base;
struct drm_plane_state *state = plane->state;
+ struct drm_crtc_state *crtc_state = state->crtc->state;
struct drm_framebuffer *fb = state->fb;
unsigned long eba, ubo, vbo;
int active;
@@ -149,7 +150,7 @@ static void ipu_plane_atomic_set_base(st
break;
}
- if (old_state->fb) {
+ if (!drm_atomic_crtc_needs_modeset(crtc_state)) {
active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
ipu_cpmem_set_buffer(ipu_plane->ipu_ch, !active, eba);
ipu_idmac_select_buffer(ipu_plane->ipu_ch, !active);
Patches currently in stable-queue which might be from gnuiyl@gmail.com are
queue-4.8/drm-imx-ipuv3-plane-access-old-u-vbo-properly-in-atomic_check-for-yu12-yv12.patch
queue-4.8/drm-imx-ipuv3-plane-switch-eba-buffer-only-when-we-don-t-need-modeset.patch
^ permalink raw reply
* Patch "drm/fb-helper: Keep references for the current set of used connectors" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 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.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-fb-helper-keep-references-for-the-current-set-of-used-connectors.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 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
@@ -606,6 +606,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;
@@ -615,10 +633,12 @@ static void drm_fb_helper_crtc_free(stru
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);
}
@@ -2034,7 +2054,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;
@@ -2082,45 +2101,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.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-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
^ permalink raw reply
* Patch "drm/imx: ipuv3-plane: Access old u/vbo properly in ->atomic_check for YU12/YV12" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 UTC (permalink / raw)
To: gnuiyl, gregkh, p.zabel; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
drm/imx: ipuv3-plane: Access old u/vbo properly in ->atomic_check for YU12/YV12
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-imx-ipuv3-plane-access-old-u-vbo-properly-in-atomic_check-for-yu12-yv12.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 e73aca5184ad9fc948ba22b4d35dce11db35bb25 Mon Sep 17 00:00:00 2001
From: Liu Ying <gnuiyl@gmail.com>
Date: Tue, 18 Oct 2016 16:44:03 +0800
Subject: drm/imx: ipuv3-plane: Access old u/vbo properly in ->atomic_check for YU12/YV12
From: Liu Ying <gnuiyl@gmail.com>
commit e73aca5184ad9fc948ba22b4d35dce11db35bb25 upstream.
Before accessing the u/v offset(aka, u/vbo for IPUv3) of the old plane state's
relevant fb, we should make sure the fb is in YU12 or YV12 pixel format(which
are the two YUV pixel formats we support only), otherwise, we are likely to
trigger BUG_ON() in drm_plane_state_to_u/vbo() since the fb's pixel format is
probably not YU12 or YV12.
Link: https://bugs.freedesktop.org/show_bug.cgi?id=98150
Fixes: c6c1f9bc798b ("drm/imx: Add active plane reconfiguration support")
Signed-off-by: Liu Ying <gnuiyl@gmail.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/imx/ipuv3-plane.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -360,7 +360,9 @@ static int ipu_plane_atomic_check(struct
if ((ubo > 0xfffff8) || (vbo > 0xfffff8))
return -EINVAL;
- if (old_fb) {
+ if (old_fb &&
+ (old_fb->pixel_format == DRM_FORMAT_YUV420 ||
+ old_fb->pixel_format == DRM_FORMAT_YVU420)) {
old_ubo = drm_plane_state_to_ubo(old_state);
old_vbo = drm_plane_state_to_vbo(old_state);
if (ubo != old_ubo || vbo != old_vbo)
Patches currently in stable-queue which might be from gnuiyl@gmail.com are
queue-4.8/drm-imx-ipuv3-plane-access-old-u-vbo-properly-in-atomic_check-for-yu12-yv12.patch
queue-4.8/drm-imx-ipuv3-plane-switch-eba-buffer-only-when-we-don-t-need-modeset.patch
^ permalink raw reply
* Patch "drm/fb-helper: Fix connector ref leak on error" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 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.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-fb-helper-fix-connector-ref-leak-on-error.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 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
@@ -129,7 +129,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.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-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
^ permalink raw reply
* Patch "drm/fb-helper: Don't call dirty callback for untouched clips" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 UTC (permalink / raw)
To: tiwai, 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/fb-helper: Don't call dirty callback for untouched clips
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-fb-helper-don-t-call-dirty-callback-for-untouched-clips.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 87d3b6588f9bf205902868d3e5baf68e37ad4ae1 Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai@suse.de>
Date: Thu, 20 Oct 2016 17:05:30 +0200
Subject: drm/fb-helper: Don't call dirty callback for untouched clips
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Takashi Iwai <tiwai@suse.de>
commit 87d3b6588f9bf205902868d3e5baf68e37ad4ae1 upstream.
Since 4.7 kernel, we've seen the error messages like
kernel: [TTM] Buffer eviction failed
kernel: qxl 0000:00:02.0: object_init failed for (4026540032, 0x00000001)
kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate VRAM BO
on QXL when switching and accessing on VT. The culprit was the
generic deferred_io code (qxl driver switched to it since 4.7).
There is a race between the dirty clip update and the call of
callback.
In drm_fb_helper_dirty(), the dirty clip is updated in the spinlock,
while it kicks off the update worker outside the spinlock. Meanwhile
the update worker clears the dirty clip in the spinlock, too. Thus,
when drm_fb_helper_dirty() is called concurrently, schedule_work() is
called after the clip is cleared in the first worker call.
This patch addresses it by validating the clip before calling the
dirty fb callback.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98322
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1003298
Fixes: eaa434defaca ('drm/fb-helper: Add fb_deferred_io support')
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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/20161020150530.5787-1-tiwai@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/drm_fb_helper.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -632,7 +632,9 @@ static void drm_fb_helper_dirty_work(str
clip->x2 = clip->y2 = 0;
spin_unlock_irqrestore(&helper->dirty_lock, flags);
- helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
+ /* call dirty callback only when it has been really touched */
+ if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2)
+ helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1);
}
/**
Patches currently in stable-queue which might be from tiwai@suse.de are
queue-4.8/alsa-hda-adding-a-new-group-of-pin-cfg-into-alc295-pin-quirk-table.patch
queue-4.8/drm-fb-helper-don-t-call-dirty-callback-for-untouched-clips.patch
queue-4.8/alsa-seq-fix-time-account-regression.patch
queue-4.8/alsa-hda-fix-headset-mic-detection-problem-for-two-dell-laptops.patch
queue-4.8/alsa-hda-allow-40-bit-dma-mask-for-nvidia-devices.patch
queue-4.8/alsa-hda-fix-surround-output-pins-for-asrock-b150m-mobo.patch
queue-4.8/alsa-usb-audio-add-quirk-for-syntek-stk1160.patch
^ permalink raw reply
* Patch "ath10k: cache calibration data when the core is stopped" has been added to the 4.8-stable tree
From: gregkh @ 2016-11-09 8:18 UTC (permalink / raw)
To: mfaltesek, gregkh, kvalo, mar.kolya; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ath10k: cache calibration data when the core is stopped
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:
ath10k-cache-calibration-data-when-the-core-is-stopped.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 f67b107d4ceddcf7aa65b706aaaf50d68edb52a6 Mon Sep 17 00:00:00 2001
From: Marty Faltesek <mfaltesek@google.com>
Date: Mon, 10 Oct 2016 19:00:04 +0300
Subject: ath10k: cache calibration data when the core is stopped
From: Marty Faltesek <mfaltesek@google.com>
commit f67b107d4ceddcf7aa65b706aaaf50d68edb52a6 upstream.
Commit 0b8e3c4ca29f ("ath10k: move cal data len to hw_params") broke retrieving
the calibration data from cal_data debugfs file. The length of file was always
zero. The reason is:
static ssize_t ath10k_debug_cal_data_read(struct file *file,
char __user *user_buf,
size_t count, loff_t *ppos)
{
struct ath10k *ar = file->private_data;
void *buf = file->private_data;
This is obviously bogus, private_data cannot contain both struct ath10k and the
buffer. Fix it by caching calibration data to ar->debug.cal_data. This also
allows it to be accessed when the device is not active (interface is down).
The cal_data buffer is fixed size because during the first firmware probe we
don't yet know what will be the lenght of the calibration data. It was simplest
just to use a fixed length. There's a WARN_ON() in
ath10k_debug_cal_data_fetch() if the buffer is too small.
Tested with qca988x and firmware 10.2.4.70.56.
Reported-by: Nikolay Martynov <mar.kolya@gmail.com>
Fixes: 0b8e3c4ca29f ("ath10k: move cal data len to hw_params")
Signed-off-by: Marty Faltesek <mfaltesek@google.com>
[kvalo@qca.qualcomm.com: improve commit log and minor other changes]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/ath/ath10k/core.h | 1
drivers/net/wireless/ath/ath10k/debug.c | 75 ++++++++++++++++----------------
2 files changed, 40 insertions(+), 36 deletions(-)
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -445,6 +445,7 @@ struct ath10k_debug {
u32 pktlog_filter;
u32 reg_addr;
u32 nf_cal_period;
+ void *cal_data;
struct ath10k_fw_crash_data *fw_crash_data;
};
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -30,6 +30,8 @@
/* ms */
#define ATH10K_DEBUG_HTT_STATS_INTERVAL 1000
+#define ATH10K_DEBUG_CAL_DATA_LEN 12064
+
#define ATH10K_FW_CRASH_DUMP_VERSION 1
/**
@@ -1450,56 +1452,51 @@ static const struct file_operations fops
.llseek = default_llseek,
};
-static int ath10k_debug_cal_data_open(struct inode *inode, struct file *file)
+static int ath10k_debug_cal_data_fetch(struct ath10k *ar)
{
- struct ath10k *ar = inode->i_private;
- void *buf;
u32 hi_addr;
__le32 addr;
int ret;
- mutex_lock(&ar->conf_mutex);
-
- if (ar->state != ATH10K_STATE_ON &&
- ar->state != ATH10K_STATE_UTF) {
- ret = -ENETDOWN;
- goto err;
- }
+ lockdep_assert_held(&ar->conf_mutex);
- buf = vmalloc(ar->hw_params.cal_data_len);
- if (!buf) {
- ret = -ENOMEM;
- goto err;
- }
+ if (WARN_ON(ar->hw_params.cal_data_len > ATH10K_DEBUG_CAL_DATA_LEN))
+ return -EINVAL;
hi_addr = host_interest_item_address(HI_ITEM(hi_board_data));
ret = ath10k_hif_diag_read(ar, hi_addr, &addr, sizeof(addr));
if (ret) {
- ath10k_warn(ar, "failed to read hi_board_data address: %d\n", ret);
- goto err_vfree;
+ ath10k_warn(ar, "failed to read hi_board_data address: %d\n",
+ ret);
+ return ret;
}
- ret = ath10k_hif_diag_read(ar, le32_to_cpu(addr), buf,
+ ret = ath10k_hif_diag_read(ar, le32_to_cpu(addr), ar->debug.cal_data,
ar->hw_params.cal_data_len);
if (ret) {
ath10k_warn(ar, "failed to read calibration data: %d\n", ret);
- goto err_vfree;
+ return ret;
}
- file->private_data = buf;
+ return 0;
+}
- mutex_unlock(&ar->conf_mutex);
+static int ath10k_debug_cal_data_open(struct inode *inode, struct file *file)
+{
+ struct ath10k *ar = inode->i_private;
- return 0;
+ mutex_lock(&ar->conf_mutex);
-err_vfree:
- vfree(buf);
+ if (ar->state == ATH10K_STATE_ON ||
+ ar->state == ATH10K_STATE_UTF) {
+ ath10k_debug_cal_data_fetch(ar);
+ }
-err:
+ file->private_data = ar;
mutex_unlock(&ar->conf_mutex);
- return ret;
+ return 0;
}
static ssize_t ath10k_debug_cal_data_read(struct file *file,
@@ -1507,18 +1504,16 @@ static ssize_t ath10k_debug_cal_data_rea
size_t count, loff_t *ppos)
{
struct ath10k *ar = file->private_data;
- void *buf = file->private_data;
- return simple_read_from_buffer(user_buf, count, ppos,
- buf, ar->hw_params.cal_data_len);
-}
+ mutex_lock(&ar->conf_mutex);
-static int ath10k_debug_cal_data_release(struct inode *inode,
- struct file *file)
-{
- vfree(file->private_data);
+ count = simple_read_from_buffer(user_buf, count, ppos,
+ ar->debug.cal_data,
+ ar->hw_params.cal_data_len);
- return 0;
+ mutex_unlock(&ar->conf_mutex);
+
+ return count;
}
static ssize_t ath10k_write_ani_enable(struct file *file,
@@ -1579,7 +1574,6 @@ static const struct file_operations fops
static const struct file_operations fops_cal_data = {
.open = ath10k_debug_cal_data_open,
.read = ath10k_debug_cal_data_read,
- .release = ath10k_debug_cal_data_release,
.owner = THIS_MODULE,
.llseek = default_llseek,
};
@@ -1931,6 +1925,8 @@ void ath10k_debug_stop(struct ath10k *ar
{
lockdep_assert_held(&ar->conf_mutex);
+ ath10k_debug_cal_data_fetch(ar);
+
/* Must not use _sync to avoid deadlock, we do that in
* ath10k_debug_destroy(). The check for htt_stats_mask is to avoid
* warning from del_timer(). */
@@ -2343,6 +2339,10 @@ int ath10k_debug_create(struct ath10k *a
if (!ar->debug.fw_crash_data)
return -ENOMEM;
+ ar->debug.cal_data = vzalloc(ATH10K_DEBUG_CAL_DATA_LEN);
+ if (!ar->debug.cal_data)
+ return -ENOMEM;
+
INIT_LIST_HEAD(&ar->debug.fw_stats.pdevs);
INIT_LIST_HEAD(&ar->debug.fw_stats.vdevs);
INIT_LIST_HEAD(&ar->debug.fw_stats.peers);
@@ -2356,6 +2356,9 @@ void ath10k_debug_destroy(struct ath10k
vfree(ar->debug.fw_crash_data);
ar->debug.fw_crash_data = NULL;
+ vfree(ar->debug.cal_data);
+ ar->debug.cal_data = NULL;
+
ath10k_debug_fw_stats_reset(ar);
kfree(ar->debug.tpc_stats);
Patches currently in stable-queue which might be from mfaltesek@google.com are
queue-4.8/ath10k-cache-calibration-data-when-the-core-is-stopped.patch
^ permalink raw reply
* [Buildroot] [PATCH] package/e2fsprogs: backport build fix for rhel5 due to missing magic
From: Max Filippov @ 2016-11-09 8:18 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161109080341.5vmnkhdchbibzofz@tarshish>
Hi Baruch,
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.
--
Thanks.
-- Max
^ permalink raw reply
* Re: Seeking help in getting run-tox-ceph-detect-init to work.
From: kefu chai @ 2016-11-09 8:17 UTC (permalink / raw)
To: Willem Jan Withagen; +Cc: Ceph Development
In-Reply-To: <6a74274e-4134-183c-f8fa-a180b5a93783@digiware.nl>
On Wed, Nov 9, 2016 at 6:57 AM, Willem Jan Withagen <wjw@digiware.nl> wrote:
> Hi,
>
> I'm looking for a developer with more Python experience....
> Especially with getting things thru tox.
>
> I was able to add FreeBSD support to ceph-detect-init in #11829. But
> then that is tested in run-tox-detect-init. Which now fails in a Linux
> Jenkins run:
> https://jenkins.ceph.com/job/ceph-pull-requests/13621/consoleFull#124607955c19247c4-fcb7-4c61-9a5d-7e2b9731c678
>
> But that heavily depends on mock and variations on
> platform.linux_distribution(), which is over my head.
>
> Like:
> def test_get(self):
> g = ceph_detect_init.get
> with mock.patch('platform.linux_distribution',
> lambda **kwargs: (('unknown', '', ''))):
> self.assertRaises(exc.UnsupportedPlatform, g)
>
> Which hits the assert because linux_distribution() returns
> (' ', ' ', ' ')
> and the system info needs to be extracted from other functions.
>
> The brutal way would be to override this test, but the question then is
> with what? Because there is no one function that returns the required
> values. So the code would be a copy from what is in the _init_.py code.
>
> And that feels like a butcher testing his own meat.
yes, you need to mock some methods get called in
platform_information(), please see the updated patch at:
https://github.com/tchaikov/ceph/commit/fced2823c311bee2be0d226759809fc10170a6ff
in which, i also added a test for unsupported system.
>
> So help very much welcomed,
> --WjW
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards
Kefu Chai
^ permalink raw reply
* [PATCH v2 linux dev-4.7 5/7] mtd: spi-nor: aspeed: use smc_read mode when doing DMAs
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>
smc_base is to send commands. smc_read is for flash content accesses.
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 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/spi-nor/aspeed-smc.c b/drivers/mtd/spi-nor/aspeed-smc.c
index 4839a26b387f..bbe505d5d8a3 100644
--- a/drivers/mtd/spi-nor/aspeed-smc.c
+++ b/drivers/mtd/spi-nor/aspeed-smc.c
@@ -405,7 +405,7 @@ static int aspeed_smc_dma_start(struct aspeed_smc_chip *chip,
int ret;
aspeed_smc_chip_configure(chip, is_write ? chip->ctl_val[smc_write] :
- chip->ctl_val[smc_base]);
+ chip->ctl_val[smc_read]);
dev_dbg(chip->nor.dev, "DMA %s to=0x%08x len=0x%08x\n",
is_write ? "write" : "read", offset, length);
@@ -446,7 +446,7 @@ static int aspeed_smc_dma_start(struct aspeed_smc_chip *chip,
controller->dma_addr, controller->dma_length,
(is_write ? DMA_TO_DEVICE : DMA_FROM_DEVICE));
out:
- aspeed_smc_chip_configure(chip, chip->ctl_val[smc_base]);
+ aspeed_smc_chip_configure(chip, chip->ctl_val[smc_read]);
return ret;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v2 linux dev-4.7 3/7] mtd: spi-nor: aspeed: extend the bits definitions
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 | 32 ++++++++++++++++++++++++++------
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/spi-nor/aspeed-smc.c b/drivers/mtd/spi-nor/aspeed-smc.c
index ecc38752c2c3..195166def945 100644
--- a/drivers/mtd/spi-nor/aspeed-smc.c
+++ b/drivers/mtd/spi-nor/aspeed-smc.c
@@ -261,16 +261,36 @@ struct aspeed_smc_controller {
};
/*
- * FMC Type setting Register
- * or
- * SPI Flash Configuration Register
+ * SPI Flash Configuration Register (AST2400 SPI)
*/
#define CONFIG_REG 0x0
+#define CONFIG_ENABLE_CE_INACTIVE BIT(1)
+#define CONFIG_WRITE BIT(0)
/*
- * CE Control Register
+ * SPI Flash Configuration Register (AST2500 SPI)
+ * Type setting Register (AST2500 FMC and AST2400 FMC)
+ */
+#define TYPE_SETTING_REG 0x0
+#define CONFIG_DISABLE_LEGACY BIT(31) /* 1 on AST2500 FMC */
+
+#define CONFIG_CE2_WRITE BIT(18)
+#define CONFIG_CE1_WRITE BIT(17)
+#define CONFIG_CE0_WRITE BIT(16)
+
+#define CONFIG_CE2_TYPE BIT(4) /* FMC only */
+#define CONFIG_CE1_TYPE BIT(2) /* FMC only */
+#define CONFIG_CE0_TYPE BIT(0) /* FMC only */
+
+/*
+ * CE Control Register (AST2500 SPI,FMC and AST2400 FMC)
*/
#define CE_CONTROL_REG 0x4
+#define CE2_ENABLE_CE_INACTIVE BIT(10)
+#define CE1_ENABLE_CE_INACTIVE BIT(9)
+#define CE0_ENABLE_CE_INACTIVE BIT(8)
+#define CE2_CONTROL_EXTENDED BIT(2)
+#define CE1_CONTROL_EXTENDED BIT(1)
#define CE0_CONTROL_EXTENDED BIT(0)
/* CE0 Control Register (depends on the controller type) */
@@ -287,8 +307,8 @@ struct aspeed_smc_controller {
#define CONTROL_SPI_DUMMY_CYCLE_COMMAND_OUTPUT BIT(15)
#define CONTROL_SPI_IO_DUMMY_CYCLES_HI BIT(14)
#define CONTROL_SPI_IO_DUMMY_CYCLES_HI_SHIFT (14 - 2)
-#define CONTROL_SPI_IO_ADDRESS_4B BIT(13) /* 2400-smc */
-#define CONTROL_SPI_CLK_DIV4 BIT(13) /* FMC, 2500 */
+#define CONTROL_SPI_IO_ADDRESS_4B BIT(13) /* AST2400 SPI */
+#define CONTROL_SPI_CLK_DIV4 BIT(13) /* others */
#define CONTROL_SPI_RW_MERGE BIT(12)
#define CONTROL_SPI_IO_DUMMY_CYCLES_LO_SHIFT 6
#define CONTROL_SPI_IO_DUMMY_CYCLES_LO GENMASK(7, \
--
2.7.4
^ permalink raw reply related
* [PATCH v2 linux dev-4.7 1/7] mtd: spi-nor: aspeed: fix setting of the register control value for writes
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 setting of the register control value for writes depends on the
base value which was defined only if the mask applied to it changed
the register control value.
Fix that.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
I kept the info level because nothing wrong is happening. we are just
possibly changing an optimized value for a non optimized value
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 f65379bb2287..75ba73ef0660 100644
--- a/drivers/mtd/spi-nor/aspeed-smc.c
+++ b/drivers/mtd/spi-nor/aspeed-smc.c
@@ -756,7 +756,7 @@ static int aspeed_smc_chip_setup_init(struct aspeed_smc_chip *chip,
{
struct aspeed_smc_controller *controller = chip->controller;
const struct aspeed_smc_info *info = controller->info;
- u32 reg;
+ u32 reg, base_reg;
/*
* Always turn on the write enable bit to allow opcodes to be
@@ -789,12 +789,13 @@ static int aspeed_smc_chip_setup_init(struct aspeed_smc_chip *chip,
reg = readl(chip->ctl);
dev_dbg(controller->dev, "control register: %08x\n", reg);
- if ((reg & CONTROL_SPI_KEEP_MASK) != reg) {
- chip->ctl_val[smc_base] = reg & CONTROL_SPI_KEEP_MASK;
+ base_reg = reg & CONTROL_SPI_KEEP_MASK;
+ if (base_reg != reg) {
dev_info(controller->dev,
"control register changed to: %08x\n",
- chip->ctl_val[smc_base]);
+ base_reg);
}
+ chip->ctl_val[smc_base] = base_reg;
/*
* Retain the prior value of the control register as the
--
2.7.4
^ permalink raw reply related
* [PATCH v2 linux dev-4.7 0/7] Aspeed SMC improvements
From: Cédric Le Goater @ 2016-11-09 8:15 UTC (permalink / raw)
To: openbmc
Hello,
Here is short serie improving the Aspeed SMC driver. There are a
couple of fixes and also changes preparing ground for read
optimization.
Patch 1 and 2 are fixes for the current driver. When merging all the
code before sending a v1 to mainline, a few minor errors slipped
through.
Patch 3 and 4 are cleanups.
Patch 5 and 6 should not have any impacts as we are not using DMAs or
fast reads, yet.
Patch 7 is more important as the IO routines are completely reworked.
I dropped the patch activating command mode for read. It is broken on
the witherspoon because the size of the flash module is larger than
the maximum allowable segment window for a CS. It would nice to
activate it when possible but this requires more checks.
I gave the patches a good test on a palmetto, an ast2500 evb and a
witherspool and the overall result should be a v2 for upstream.
Cheers,
C.
Cédric Le Goater (7):
mtd: spi-nor: aspeed: fix setting of the register control value for
writes
mtd: spi-nor: aspeed: improve 4 bytes mode
mtd: spi-nor: aspeed: extend the bits definitions
mtd: spi-nor: aspeed: add some logging
mtd: spi-nor: aspeed: use smc_read mode when doing DMAs
mtd: spi-nor: aspeed: prepare for fast read
mtd: spi-nor: aspeed: rework io routines
drivers/mtd/spi-nor/aspeed-smc.c | 265 ++++++++++++++++++++++-----------------
1 file changed, 151 insertions(+), 114 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-09 8:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161109081431.10115-1-romain.perier@free-electrons.com>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
^ permalink raw reply related
* [PATCH v2 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-09 8:14 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161109081431.10115-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
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.