From: Mohammed Shafi Shajakhan <[email protected]>
This feature is to mitigate the problem of certain 3
stream chips that exceed the PCIe power requirements.An EEPROM flag
controls which chips have APM enabled which is basically read from
miscellaneous configuration element of the EEPROM header.
This workaround will reduce power consumption by using 2 Tx chains for
Single and Double stream rates (5 GHz only).All self generated frames
(regardless of rate) are sent on 2 chains when this feature is
enabled(Chip Limitation).
Cc: Paul Shaw <[email protected]>
Signed-off-by: Mohammed Shafi Shajakhan <[email protected]>
Tested-by: Mohammed Shafi Shajakhan <[email protected]>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 ++
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 6 +++++-
drivers/net/wireless/ath/ath9k/ath9k.h | 3 +++
drivers/net/wireless/ath/ath9k/beacon.c | 3 ++-
drivers/net/wireless/ath/ath9k/eeprom.h | 1 +
drivers/net/wireless/ath/ath9k/hw.c | 6 ++++++
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 5 ++++-
drivers/net/wireless/ath/ath9k/xmit.c | 23 +++++++++++++++++++++--
9 files changed, 45 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
index 9a7e151..882384c 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.c
@@ -3029,6 +3029,8 @@ static u32 ath9k_hw_ar9300_get_eeprom(struct ath_hw *ah,
return le32_to_cpu(pBase->swreg);
case EEP_PAPRD:
return !!(pBase->featureEnable & BIT(5));
+ case EEP_CHAIN_MASK_REDUCE:
+ return (pBase->miscConfiguration >> 0x3) & 0x1;
default:
return 0;
}
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index e8d6455..9b187fe 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -487,7 +487,11 @@ void ar9003_hw_set_chain_masks(struct ath_hw *ah, u8 rx, u8 tx)
break;
}
- REG_WRITE(ah, AR_SELFGEN_MASK, tx);
+ if ((ah->caps.hw_caps & ATH9K_HW_CAP_APM) && (tx == 0x7))
+ REG_WRITE(ah, AR_SELFGEN_MASK, 0x3);
+ else
+ REG_WRITE(ah, AR_SELFGEN_MASK, tx);
+
if (tx == 0x5) {
REG_SET_BIT(ah, AR_PHY_ANALOG_SWAP,
AR_PHY_SWAP_ALT_CHAIN);
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 6f90acc..efba413 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -544,6 +544,7 @@ struct ath_ant_comb {
#define SC_OP_BT_PRIORITY_DETECTED BIT(12)
#define SC_OP_BT_SCAN BIT(13)
#define SC_OP_ANI_RUN BIT(14)
+#define SC_OP_ENABLE_APM BIT(15)
/* Powersave flags */
#define PS_WAIT_FOR_BEACON BIT(0)
@@ -695,6 +696,8 @@ static inline void ath_ahb_exit(void) {};
void ath9k_ps_wakeup(struct ath_softc *sc);
void ath9k_ps_restore(struct ath_softc *sc);
+u8 ath_txchainmask_reduction(struct ath_softc *sc, u8 chainmask, u32 rate);
+
void ath9k_set_bssid_mask(struct ieee80211_hw *hw, struct ieee80211_vif *vif);
int ath9k_wiphy_add(struct ath_softc *sc);
int ath9k_wiphy_del(struct ath_wiphy *aphy);
diff --git a/drivers/net/wireless/ath/ath9k/beacon.c b/drivers/net/wireless/ath/ath9k/beacon.c
index 30724a4..47bedd8 100644
--- a/drivers/net/wireless/ath/ath9k/beacon.c
+++ b/drivers/net/wireless/ath/ath9k/beacon.c
@@ -103,7 +103,8 @@ static void ath_beacon_setup(struct ath_softc *sc, struct ath_vif *avp,
memset(series, 0, sizeof(struct ath9k_11n_rate_series) * 4);
series[0].Tries = 1;
series[0].Rate = rate;
- series[0].ChSel = common->tx_chainmask;
+ series[0].ChSel = ath_txchainmask_reduction(sc,
+ common->tx_chainmask, series[0].Rate);
series[0].RateFlags = (ctsrate) ? ATH9K_RATESERIES_RTS_CTS : 0;
ath9k_hw_set11n_ratescenario(ah, ds, ds, 0, ctsrate, ctsduration,
series, 4, 0);
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h b/drivers/net/wireless/ath/ath9k/eeprom.h
index 3c99830..7755fb9 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/eeprom.h
@@ -268,6 +268,7 @@ enum eeprom_param {
EEP_PAPRD,
EEP_MODAL_VER,
EEP_ANT_DIV_CTL1,
+ EEP_CHAIN_MASK_REDUCE
};
enum ar5416_rates {
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 1dbe53b..3b9bd0c 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1972,6 +1972,12 @@ int ath9k_hw_fill_cap_info(struct ath_hw *ah)
if ((ant_div_ctl1 & 0x1) && ((ant_div_ctl1 >> 3) & 0x1))
pCap->hw_caps |= ATH9K_HW_CAP_ANT_DIV_COMB;
}
+ if (AR_SREV_9300_20_OR_LATER(ah)) {
+ if (ah->eep_ops->get_eeprom(ah, EEP_CHAIN_MASK_REDUCE))
+ pCap->hw_caps |= ATH9K_HW_CAP_APM;
+ }
+
+
return 0;
}
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index cc8f3b9..5fcfa48 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -187,6 +187,7 @@ enum ath9k_hw_caps {
ATH9K_HW_CAP_ANT_DIV_COMB = BIT(12),
ATH9K_HW_CAP_2GHZ = BIT(13),
ATH9K_HW_CAP_5GHZ = BIT(14),
+ ATH9K_HW_CAP_APM = BIT(15),
};
struct ath9k_hw_capabilities {
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 50bdb5d..df1bfcf 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -554,9 +554,12 @@ void ath_update_chainmask(struct ath_softc *sc, int is_ht)
static void ath_node_attach(struct ath_softc *sc, struct ieee80211_sta *sta)
{
struct ath_node *an;
-
+ struct ath_hw *ah = sc->sc_ah;
an = (struct ath_node *)sta->drv_priv;
+ if ((ah->caps.hw_caps) & ATH9K_HW_CAP_APM)
+ sc->sc_flags |= SC_OP_ENABLE_APM;
+
if (sc->sc_flags & SC_OP_TXAGGR) {
ath_tx_node_init(sc, an);
an->maxampdu = 1 << (IEEE80211_HT_MAX_AMPDU_FACTOR +
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index c63e283..a01b86e 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1504,6 +1504,18 @@ static u32 ath_pkt_duration(struct ath_softc *sc, u8 rix, int pktlen,
return duration;
}
+u8 ath_txchainmask_reduction(struct ath_softc *sc, u8 chainmask, u32 rate)
+{
+ struct ath_hw *ah = sc->sc_ah;
+ struct ath9k_channel *curchan = ah->curchan;
+ if ((sc->sc_flags & SC_OP_ENABLE_APM) &&
+ (curchan->channelFlags & CHANNEL_5GHZ) &&
+ (chainmask == 0x7) && (rate < 0x90))
+ return 0x3;
+ else
+ return chainmask;
+}
+
static void ath_buf_set_rate(struct ath_softc *sc, struct ath_buf *bf, int len)
{
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
@@ -1544,7 +1556,6 @@ static void ath_buf_set_rate(struct ath_softc *sc, struct ath_buf *bf, int len)
rix = rates[i].idx;
series[i].Tries = rates[i].count;
- series[i].ChSel = common->tx_chainmask;
if ((sc->config.ath_aggr_prot && bf_isaggr(bf)) ||
(rates[i].flags & IEEE80211_TX_RC_USE_RTS_CTS)) {
@@ -1567,6 +1578,8 @@ static void ath_buf_set_rate(struct ath_softc *sc, struct ath_buf *bf, int len)
if (rates[i].flags & IEEE80211_TX_RC_MCS) {
/* MCS rates */
series[i].Rate = rix | 0x80;
+ series[i].ChSel = ath_txchainmask_reduction(sc,
+ common->tx_chainmask, series[i].Rate);
series[i].PktDuration = ath_pkt_duration(sc, rix, len,
is_40, is_sgi, is_sp);
if (rix < 8 && (tx_info->flags & IEEE80211_TX_CTL_STBC))
@@ -1574,7 +1587,7 @@ static void ath_buf_set_rate(struct ath_softc *sc, struct ath_buf *bf, int len)
continue;
}
- /* legcay rates */
+ /* legacy rates */
if ((tx_info->band == IEEE80211_BAND_2GHZ) &&
!(rate->flags & IEEE80211_RATE_ERP_G))
phy = WLAN_RC_PHY_CCK;
@@ -1590,6 +1603,12 @@ static void ath_buf_set_rate(struct ath_softc *sc, struct ath_buf *bf, int len)
is_sp = false;
}
+ if (bf->bf_state.bfs_paprd)
+ series[i].ChSel = common->tx_chainmask;
+ else
+ series[i].ChSel = ath_txchainmask_reduction(sc,
+ common->tx_chainmask, series[i].Rate);
+
series[i].PktDuration = ath9k_hw_computetxtime(sc->sc_ah,
phy, rate->bitrate * 100, len, rix, is_sp);
}
--
1.7.0.4
On 2010-11-24 6:06 AM, Mohammed Shafi wrote:
> On Tuesday 23 November 2010 09:23 PM, Felix Fietkau wrote:
>> On 2010-11-23 4:12 PM, Mohammed Shafi Shajakhan wrote:
>>
>>> From: Mohammed Shafi Shajakhan<[email protected]>
>>>
>>> This feature is to mitigate the problem of certain 3
>>> stream chips that exceed the PCIe power requirements.An EEPROM flag
>>> controls which chips have APM enabled which is basically read from
>>> miscellaneous configuration element of the EEPROM header.
>>>
>>> This workaround will reduce power consumption by using 2 Tx chains for
>>> Single and Double stream rates (5 GHz only).All self generated frames
>>> (regardless of rate) are sent on 2 chains when this feature is
>>> enabled(Chip Limitation).
>>>
>>> Cc: Paul Shaw<[email protected]>
>>> Signed-off-by: Mohammed Shafi Shajakhan<[email protected]>
>>> Tested-by: Mohammed Shafi Shajakhan<[email protected]>I
>>>
>> I think this code would get a lot more concise if you'd move it to
>> ar9003_mac.c, since this issue is AR9003 specific anyway.
>> It would also allow you to avoid adding yet another redundant ath_softc
>> capability flag, as the driver part really doesn't need to be concerned
>> with this.
>>
> Thanks for reviewing the code and for your valuable comments.
> 1.I get a feeling when we add this to ar9003_mac.c this feature won't be
> much explicit and might be hard to debug if any issue comes.You might
> have noticed we might be using APM only for non-PAPRD frames.
> 2.This feature may be applicable for future 3 stream chips (or) in case
> of Power Management we can even disable the third chain (1S and 2S
> rates) while trading of throughput slightly for all 3 stream chips.
> 3.Yes ath_softc flag might be reduntant I will look into it.
> 4.There were so many things directly available in xmit.c such as rate
> descriptor,band(5Ghz or 2 Ghz) we are using,whether its a PAPRD frame,
> to looking for single stream and double stream etc.I really dont know
> whether all these things will be available directly available in
> ar9003_mac.c but it would be very difficult to track them and do all the
> right things.
> I will surely look to concise the code in near future , but now
> I think we can have it in upstream.I had tested it and there were no
> issues in fucntionality.
Makes sense, let's get your change in then.
After I'm done cleaning up the tx aggregation path, I intend to
consolidate all the functions that deal with preparing the tx
descriptor, as the API for that in ath9k_hw has become quite messy.
That will lead to fewer reads/writes to uncached memory and will also
make it much easier to implement the cleanups that I suggested.
- Felix
On 2010-11-23 4:12 PM, Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan <[email protected]>
>
> This feature is to mitigate the problem of certain 3
> stream chips that exceed the PCIe power requirements.An EEPROM flag
> controls which chips have APM enabled which is basically read from
> miscellaneous configuration element of the EEPROM header.
>
> This workaround will reduce power consumption by using 2 Tx chains for
> Single and Double stream rates (5 GHz only).All self generated frames
> (regardless of rate) are sent on 2 chains when this feature is
> enabled(Chip Limitation).
>
> Cc: Paul Shaw <[email protected]>
> Signed-off-by: Mohammed Shafi Shajakhan <[email protected]>
> Tested-by: Mohammed Shafi Shajakhan <[email protected]>
I think this code would get a lot more concise if you'd move it to
ar9003_mac.c, since this issue is AR9003 specific anyway.
It would also allow you to avoid adding yet another redundant ath_softc
capability flag, as the driver part really doesn't need to be concerned
with this.
- Felix
I think Mohammed explained the key points of why this feature is in the upper layer (above the HAL).
I went back and forth on this myself before implementing it above the HAL in our internal code base (newma).
It would have been much simpler to implement in the HAL, but I chose to place it above the HAL because
1. The HAL is supposed to be dumb and stateless. How to set the individual fields of the tx descriptor is decided above the HAL. The HAL just fills in the hw specific descriptor.
2. This feature will span multiple HALs (ar9300 and future HALs)
3. The upper layer already contains code to manipulate the tx chain mask. This is just another feature that manipulates the tx chain mask.
4. The APM feature will not be applied to all tx frames (e.g. PAPRD transmits should be unmodified). This was probably the deciding factor in placing APM above the HAL.
Hope this gives some insight into the decision.
Thanks,
Paul
-----Original Message-----
From: Mohammed Shajakhan
Sent: Wednesday, November 24, 2010 8:25 PM
To: Felix Fietkau
Cc: [email protected]; Luis Rodriguez; Paul Shaw; [email protected]
Subject: Re: [PATCH] ath9k: Add support for Adaptive Power Management
On Wednesday 24 November 2010 11:11 PM, Felix Fietkau wrote:
> On 2010-11-24 6:06 AM, Mohammed Shafi wrote:
>
>> On Tuesday 23 November 2010 09:23 PM, Felix Fietkau wrote:
>>
>>> On 2010-11-23 4:12 PM, Mohammed Shafi Shajakhan wrote:
>>>
>>>
>>>> From: Mohammed Shafi Shajakhan<[email protected]>
>>>>
>>>> This feature is to mitigate the problem of certain 3
>>>> stream chips that exceed the PCIe power requirements.An EEPROM flag
>>>> controls which chips have APM enabled which is basically read from
>>>> miscellaneous configuration element of the EEPROM header.
>>>>
>>>> This workaround will reduce power consumption by using 2 Tx chains for
>>>> Single and Double stream rates (5 GHz only).All self generated frames
>>>> (regardless of rate) are sent on 2 chains when this feature is
>>>> enabled(Chip Limitation).
>>>>
>>>> Cc: Paul Shaw<[email protected]>
>>>> Signed-off-by: Mohammed Shafi Shajakhan<[email protected]>
>>>> Tested-by: Mohammed Shafi Shajakhan<[email protected]>I
>>>>
>>>>
>>> I think this code would get a lot more concise if you'd move it to
>>> ar9003_mac.c, since this issue is AR9003 specific anyway.
>>> It would also allow you to avoid adding yet another redundant ath_softc
>>> capability flag, as the driver part really doesn't need to be concerned
>>> with this.
>>>
>>>
>> Thanks for reviewing the code and for your valuable comments.
>> 1.I get a feeling when we add this to ar9003_mac.c this feature won't be
>> much explicit and might be hard to debug if any issue comes.You might
>> have noticed we might be using APM only for non-PAPRD frames.
>> 2.This feature may be applicable for future 3 stream chips (or) in case
>> of Power Management we can even disable the third chain (1S and 2S
>> rates) while trading of throughput slightly for all 3 stream chips.
>> 3.Yes ath_softc flag might be reduntant I will look into it.
>> 4.There were so many things directly available in xmit.c such as rate
>> descriptor,band(5Ghz or 2 Ghz) we are using,whether its a PAPRD frame,
>> to looking for single stream and double stream etc.I really dont know
>> whether all these things will be available directly available in
>> ar9003_mac.c but it would be very difficult to track them and do all the
>> right things.
>> I will surely look to concise the code in near future , but now
>> I think we can have it in upstream.I had tested it and there were no
>> issues in fucntionality.
>>
> Makes sense, let's get your change in then.
>
Thanks for your understanding. Currently I don't have clear idea to
implement the same in the ar9003_mac.c and if I do it now, the testing
again will be taking a lot of time to make sure that this does not
affects stability,throughput etc.For instance initially there was a drop
in throughput only because when the legacy rates are enabled with APM
and I had no clue it was due to PAPRD frames (a more experienced person
figured that out).
> After I'm done cleaning up the tx aggregation path, I intend to
> consolidate all the functions that deal with preparing the tx
> descriptor, as the API for that in ath9k_hw has become quite messy.
>
Ok sure and Paul who conceived this idea might have thought of this and
thats why he would have implemented in the driver part.
> That will lead to fewer reads/writes to uncached memory and will also
> make it much easier to implement the cleanups that I suggested.
>
Thanks.
> - Felix
> .
>
>
On Tuesday 23 November 2010 09:23 PM, Felix Fietkau wrote:
> On 2010-11-23 4:12 PM, Mohammed Shafi Shajakhan wrote:
>
>> From: Mohammed Shafi Shajakhan<[email protected]>
>>
>> This feature is to mitigate the problem of certain 3
>> stream chips that exceed the PCIe power requirements.An EEPROM flag
>> controls which chips have APM enabled which is basically read from
>> miscellaneous configuration element of the EEPROM header.
>>
>> This workaround will reduce power consumption by using 2 Tx chains for
>> Single and Double stream rates (5 GHz only).All self generated frames
>> (regardless of rate) are sent on 2 chains when this feature is
>> enabled(Chip Limitation).
>>
>> Cc: Paul Shaw<[email protected]>
>> Signed-off-by: Mohammed Shafi Shajakhan<[email protected]>
>> Tested-by: Mohammed Shafi Shajakhan<[email protected]>I
>>
> I think this code would get a lot more concise if you'd move it to
> ar9003_mac.c, since this issue is AR9003 specific anyway.
> It would also allow you to avoid adding yet another redundant ath_softc
> capability flag, as the driver part really doesn't need to be concerned
> with this.
>
Thanks for reviewing the code and for your valuable comments.
1.I get a feeling when we add this to ar9003_mac.c this feature won't be
much explicit and might be hard to debug if any issue comes.You might
have noticed we might be using APM only for non-PAPRD frames.
2.This feature may be applicable for future 3 stream chips (or) in case
of Power Management we can even disable the third chain (1S and 2S
rates) while trading of throughput slightly for all 3 stream chips.
3.Yes ath_softc flag might be reduntant I will look into it.
4.There were so many things directly available in xmit.c such as rate
descriptor,band(5Ghz or 2 Ghz) we are using,whether its a PAPRD frame,
to looking for single stream and double stream etc.I really dont know
whether all these things will be available directly available in
ar9003_mac.c but it would be very difficult to track them and do all the
right things.
I will surely look to concise the code in near future , but now
I think we can have it in upstream.I had tested it and there were no
issues in fucntionality.
thanks,
shafi
> - Felix
> .
>
>
On Wednesday 24 November 2010 11:11 PM, Felix Fietkau wrote:
> On 2010-11-24 6:06 AM, Mohammed Shafi wrote:
>
>> On Tuesday 23 November 2010 09:23 PM, Felix Fietkau wrote:
>>
>>> On 2010-11-23 4:12 PM, Mohammed Shafi Shajakhan wrote:
>>>
>>>
>>>> From: Mohammed Shafi Shajakhan<[email protected]>
>>>>
>>>> This feature is to mitigate the problem of certain 3
>>>> stream chips that exceed the PCIe power requirements.An EEPROM flag
>>>> controls which chips have APM enabled which is basically read from
>>>> miscellaneous configuration element of the EEPROM header.
>>>>
>>>> This workaround will reduce power consumption by using 2 Tx chains for
>>>> Single and Double stream rates (5 GHz only).All self generated frames
>>>> (regardless of rate) are sent on 2 chains when this feature is
>>>> enabled(Chip Limitation).
>>>>
>>>> Cc: Paul Shaw<[email protected]>
>>>> Signed-off-by: Mohammed Shafi Shajakhan<[email protected]>
>>>> Tested-by: Mohammed Shafi Shajakhan<[email protected]>I
>>>>
>>>>
>>> I think this code would get a lot more concise if you'd move it to
>>> ar9003_mac.c, since this issue is AR9003 specific anyway.
>>> It would also allow you to avoid adding yet another redundant ath_softc
>>> capability flag, as the driver part really doesn't need to be concerned
>>> with this.
>>>
>>>
>> Thanks for reviewing the code and for your valuable comments.
>> 1.I get a feeling when we add this to ar9003_mac.c this feature won't be
>> much explicit and might be hard to debug if any issue comes.You might
>> have noticed we might be using APM only for non-PAPRD frames.
>> 2.This feature may be applicable for future 3 stream chips (or) in case
>> of Power Management we can even disable the third chain (1S and 2S
>> rates) while trading of throughput slightly for all 3 stream chips.
>> 3.Yes ath_softc flag might be reduntant I will look into it.
>> 4.There were so many things directly available in xmit.c such as rate
>> descriptor,band(5Ghz or 2 Ghz) we are using,whether its a PAPRD frame,
>> to looking for single stream and double stream etc.I really dont know
>> whether all these things will be available directly available in
>> ar9003_mac.c but it would be very difficult to track them and do all the
>> right things.
>> I will surely look to concise the code in near future , but now
>> I think we can have it in upstream.I had tested it and there were no
>> issues in fucntionality.
>>
> Makes sense, let's get your change in then.
>
Thanks for your understanding. Currently I don't have clear idea to
implement the same in the ar9003_mac.c and if I do it now, the testing
again will be taking a lot of time to make sure that this does not
affects stability,throughput etc.For instance initially there was a drop
in throughput only because when the legacy rates are enabled with APM
and I had no clue it was due to PAPRD frames (a more experienced person
figured that out).
> After I'm done cleaning up the tx aggregation path, I intend to
> consolidate all the functions that deal with preparing the tx
> descriptor, as the API for that in ath9k_hw has become quite messy.
>
Ok sure and Paul who conceived this idea might have thought of this and
thats why he would have implemented in the driver part.
> That will lead to fewer reads/writes to uncached memory and will also
> make it much easier to implement the cleanups that I suggested.
>
Thanks.
> - Felix
> .
>
>