b43: N-PHY: b43_nphy_get_tx_gains
From 5c96b3de80f7d044c42808e8123ae3f50916d6fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <[email protected]>
Date: Wed, 6 Jan 2010 15:25:14 +0100
Subject: [PATCH 2/5] b43: N-PHY: b43_nphy_get_tx_gains
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Rafał Miłecki <[email protected]>
---
drivers/net/wireless/b43/phy_n.c | 75 ++++++++++++++++++++++++++++++++++++++
drivers/net/wireless/b43/phy_n.h | 1 +
2 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index 40d7b73..249caf0 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -30,6 +30,8 @@
#include "tables_nphy.h"
+struct nphy_txgains { u16 txgm[2]; u16 pga[2]; u16 pad[2]; u16 ipa[2]; };
+
void b43_nphy_set_rxantenna(struct b43_wldev *dev, int antenna)
{//TODO
}
@@ -405,6 +407,79 @@ static void b43_nphy_stay_carrier_search(struct b43_wldev *dev, bool enable)
}
}
+static struct nphy_txgains b43_nphy_get_tx_gains(struct b43_wldev *dev)
+{
+ struct b43_phy_n *nphy = dev->phy.n;
+
+ u16 curr_gain[2];
+ struct nphy_txgains target;
+ u32 *table = NULL;
+
+ if (nphy->txpwrctrl == 0) {
+ int i;
+
+ if (nphy->hang_avoid)
+ b43_nphy_stay_carrier_search(dev, true);
+ //TODO: Read an N PHY Table with ID 7, length 2, offset 0x110, width 16, and curr_gain
+ if (nphy->hang_avoid)
+ b43_nphy_stay_carrier_search(dev, false);
+
+ for (i = 0; i < 2; ++i) {
+ if (dev->phy.rev >= 3) {
+ target.ipa[i] = curr_gain[i] & 0x000F;
+ target.pad[i] = (curr_gain[i] & 0x00F0) >> 4;
+ target.pga[i] = (curr_gain[i] & 0x0F00) >> 8;
+ target.txgm[i] = (curr_gain[i] & 0x7000) >> 12;
+ } else {
+ target.ipa[i] = curr_gain[i] & 0x0003;
+ target.pad[i] = (curr_gain[i] & 0x000C) >> 2;
+ target.pga[i] = (curr_gain[i] & 0x0070) >> 4;
+ target.txgm[i] = (curr_gain[i] & 0x0380) >> 7;
+ }
+ }
+ } else {
+ int i;
+ u16 index[2];
+
+ for (i = 0; i < 2; ++i) {
+ if (dev->phy.rev >= 3) {
+ enum ieee80211_band band =
+ b43_current_band(dev->wl);
+
+ if ((nphy->ipa2g_on && band == IEEE80211_BAND_2GHZ) ||
+ (nphy->ipa5g_on && band == IEEE80211_BAND_5GHZ)) {
+ table = NULL; //FIXME: = output of N PHY Get IPA GainTbl
+ } else {
+ if (band == IEEE80211_BAND_5GHZ) {
+ if (dev->phy.rev == 3)
+ table = NULL; //FIXME: N PHY TX Power Control - TX Gain Table Rev >= 3 (5 GHz)
+ else if (dev->phy.rev == 4)
+ table = NULL; //FIXME: N PHY TX Power Control - TX Gain Table Rev 4 (5 GHz)
+ else
+ table = NULL; //FIXME: N PHY TX Power Control - TX Gain Table Rev 5 (5 GHz)
+ } else {
+ table = NULL; //FIXME: N PHY TX Power Control - TX Gain Table Rev >= 3 (2.4 GHz)
+ }
+ }
+
+ target.ipa[i] = (table[index[i]] >> 16) & 0xF;
+ target.pad[i] = (table[index[i]] >> 20) & 0xF;
+ target.pga[i] = (table[index[i]] >> 24) & 0xF;
+ target.txgm[i] = (table[index[i]] >> 28) & 0xF;
+ } else {
+ table = NULL; //FIXME: N PHY TX Power Control - TX Gain Table Rev <= 2
+
+ target.ipa[i] = (table[index[i]] >> 16) & 0x3;
+ target.pad[i] = (table[index[i]] >> 18) & 0x3;
+ target.pga[i] = (table[index[i]] >> 20) & 0x7;
+ target.txgm[i] = (table[index[i]] >> 23) & 0x7;
+ }
+ }
+ }
+
+ return target;
+}
+
enum b43_nphy_rf_sequence {
B43_RFSEQ_RX2TX,
B43_RFSEQ_TX2RX,
diff --git a/drivers/net/wireless/b43/phy_n.h b/drivers/net/wireless/b43/phy_n.h
index 6ab07fc..e63c371 100644
--- a/drivers/net/wireless/b43/phy_n.h
+++ b/drivers/net/wireless/b43/phy_n.h
@@ -930,6 +930,7 @@ struct b43_phy_n {
u8 phyrxchain;
u8 mphase_cal_phase_id;
u32 deaf_count;
+ bool hang_avoid;
bool mute;
u16 classifier_state;
--
1.6.4.2
On Wednesday 06 January 2010 20:29:36 Rafał Miłecki wrote:
> > You may read Documentation/SubmittingPatches and format your future
> > patches according to that.
>
> Well, that's really poor joke :| Manually creating .orig files, using
> "diff -up" and so dropping local commits "strategy"...? Er, I don't
> think I'll use this one.
Nobody said you need to fix your internal workflow. Why would anybody care
_how_ you generate your patches?
You could manually type them into your cellphone with T9. If that it results
in a properly formated patch in the end, nobody would complain.
So yes, reading other people's patches probably is a good idea to start with.
In general only put stuff into the mail that you want to show up in the commit
message. (If you want to have additional stuff that doesn't show up in the commit
message, you can use the "---" delimiter. But that's documented elsewhere so
I don't have to explain that here...)
--
Greetings, Michael
On Wednesday 06 January 2010 20:41:52 Rafał Miłecki wrote:
> I started composing that mail before got real idea of patches. I was
> still thinking I need some magic headers "diff" tool generates. Hope I
> totally understand this now and won't cause more problems to you guys
> :)
There are no problems. It's just a little bit easier for maintainers to merge
properly formatted patches. Importing a properly formatted patch into git is just
a matter of a command or two.
So that said, I think it's awesome that you started to work on the N code.
I hope we get something usable, soon. Lots of people will love you and women
will want to marry you. ;)
Your patches _are_ actually in a pretty good shape. The remaining submission issues
are minor and easy to fix.
--
Greetings, Michael.
On 01/06/2010 02:57 PM, Rafał Miłecki wrote:
> V2: adjust to renamed function, fill index array
>
> Signed-off-by: Rafał Miłecki <[email protected]>
> ---
> drivers/net/wireless/b43/phy_n.c | 81
Just a little nitpick to save John some work, and to keep the patches straight.
When you submit a second (or later) version of a patch, indicate the version in
the mail header as in [PATCH 2/5 V2] b43:.... The upstream software strips all
of that out and the commit header will be clean.
In addition, it is useful to state what is different below the --- marker. The
software also strips that part of the patch - the permanent commit message
should be devoid of the details of the review message. It is like making
sausage! Better that the details are hidden.
Larry
2010/1/6 Rafał Miłecki <[email protected]>:
> b43: N-PHY: b43_nphy_get_tx_gains
>
>
> From 5c96b3de80f7d044c42808e8123ae3f50916d6fc Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <[email protected]>
> Date: Wed, 6 Jan 2010 15:25:14 +0100
> Subject: [PATCH 2/5] b43: N-PHY: b43_nphy_get_tx_gains
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
Dude what is up with this e-mail data on your patches in the commit log?
Luis
W dniu 6 stycznia 2010 19:22 użytkownik Michael Buesch <[email protected]> napisał:
> On Wednesday 06 January 2010 19:18:39 Rafał Miłecki wrote:
>> > Dude what is up with this e-mail data on your patches in the commit log?
>>
>> That is way of encoding non-ASCII chars in mail header. You can find
>> info about this in RFC. That is "=?UTF-8?B?" prefix and base 64
>> encoded text.
>>
>> That was generated with git (git format-patch -5) and it understood by
>> git (git am ...).
>
> Well, however, there is no reason to include this in the mail body (and thus
> the GIT commit message).
> As you said, these are mail _headers_.
> Additionally, attaching the patch as mail attachment is _not_ required. We just
> put the patch into the body.
OK, will try to follow that. I checked few patches submitted by other
ppl so probably get the correct way this time.
> You may read Documentation/SubmittingPatches and format your future
> patches according to that.
Well, that's really poor joke :| Manually creating .orig files, using
"diff -up" and so dropping local commits "strategy"...? Er, I don't
think I'll use this one.
--
Rafał
W dniu 6 stycznia 2010 18:26 użytkownik Luis R. Rodriguez
<[email protected]> napisał:
> 2010/1/6 Rafał Miłecki <[email protected]>:
>> b43: N-PHY: b43_nphy_get_tx_gains
>>
>>
>> From 5c96b3de80f7d044c42808e8123ae3f50916d6fc Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <[email protected]>
>> Date: Wed, 6 Jan 2010 15:25:14 +0100
>> Subject: [PATCH 2/5] b43: N-PHY: b43_nphy_get_tx_gains
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>
> Dude what is up with this e-mail data on your patches in the commit log?
That is way of encoding non-ASCII chars in mail header. You can find
info about this in RFC. That is "=?UTF-8?B?" prefix and base 64
encoded text.
That was generated with git (git format-patch -5) and it understood by
git (git am ...).
--
Rafał
W dniu 6 stycznia 2010 22:23 użytkownik Larry Finger
<[email protected]> napisał:
> On 01/06/2010 02:57 PM, Rafał Miłecki wrote:
>> V2: adjust to renamed function, fill index array
>>
>> Signed-off-by: Rafał Miłecki <[email protected]>
>> ---
>> drivers/net/wireless/b43/phy_n.c | 81
>
> Just a little nitpick to save John some work, and to keep the patches straight.
>
> When you submit a second (or later) version of a patch, indicate the version in
> the mail header as in [PATCH 2/5 V2] b43:.... The upstream software strips all
> of that out and the commit header will be clean.
>
> In addition, it is useful to state what is different below the --- marker. The
> software also strips that part of the patch - the permanent commit message
> should be devoid of the details of the review message. It is like making
> sausage! Better that the details are hidden.
Uh, so once again I've made some mistake in my submitting. Sorry John,
thanks Larry.
I can excuse myself only with fact that it's something I've learn from
drm guys. Of course I'll change my ways. Ex.:
commit 3dfc63922f8edfa8774bf1ba882225c5f91b2220
Author: Alex Deucher <[email protected]>
Date: Tue Dec 22 10:06:49 2009 -0500
drm/radeon/kms: add cvt mode if we only have lvds w/h and no edid (v4)
This fixes LVDS on some mac laptops without a panel edid.
v2 - Set proper mode type flags
v3 - Note that this is not neceesarily the exact panel mode,
but an approximation based on the cvt formula. For these
systems we should ideally read the mode info out of the
registers or add a mode table, but this works and is much
simpler.
v4 - Update comments and debug message.
Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
--
Rafał
W dniu 6 stycznia 2010 20:51 użytkownik Michael Buesch <[email protected]> napisał:
> On Wednesday 06 January 2010 20:41:52 Rafał Miłecki wrote:
>> I started composing that mail before got real idea of patches. I was
>> still thinking I need some magic headers "diff" tool generates. Hope I
>> totally understand this now and won't cause more problems to you guys
>> :)
>
> There are no problems. It's just a little bit easier for maintainers to merge
> properly formatted patches. Importing a properly formatted patch into git is just
> a matter of a command or two.
>
> So that said, I think it's awesome that you started to work on the N code.
> I hope we get something usable, soon. Lots of people will love you and women
> will want to marry you. ;)
> Your patches _are_ actually in a pretty good shape. The remaining submission issues
> are minor and easy to fix.
Hey, thanks a lot, glad to hear that :)
It's great opportunity to involve myself in kernel development. I
could never write full working driver myself and in this case I have
most part of driver written and great specs available :)
--
Rafał
On Wednesday 06 January 2010 19:18:39 Rafał Miłecki wrote:
> > Dude what is up with this e-mail data on your patches in the commit log?
>
> That is way of encoding non-ASCII chars in mail header. You can find
> info about this in RFC. That is "=?UTF-8?B?" prefix and base 64
> encoded text.
>
> That was generated with git (git format-patch -5) and it understood by
> git (git am ...).
Well, however, there is no reason to include this in the mail body (and thus
the GIT commit message).
As you said, these are mail _headers_.
Additionally, attaching the patch as mail attachment is _not_ required. We just
put the patch into the body.
You may read Documentation/SubmittingPatches and format your future
patches according to that.
--
Greetings, Michael.
V2: adjust to renamed function, fill index array
Signed-off-by: Rafał Miłecki <[email protected]>
---
drivers/net/wireless/b43/phy_n.c | 81 ++++++++++++++++++++++++++++++++++++++
drivers/net/wireless/b43/phy_n.h | 1 +
2 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/b43/phy_n.c b/drivers/net/wireless/b43/phy_n.c
index 5252c0f..3663386 100644
--- a/drivers/net/wireless/b43/phy_n.c
+++ b/drivers/net/wireless/b43/phy_n.c
@@ -30,6 +30,8 @@
#include "tables_nphy.h"
+struct nphy_txgains { u16 txgm[2]; u16 pga[2]; u16 pad[2]; u16 ipa[2]; };
+
void b43_nphy_set_rxantenna(struct b43_wldev *dev, int antenna)
{//TODO
}
@@ -406,6 +408,85 @@ static void b43_nphy_stay_in_carrier_search(struct b43_wldev *dev, bool enable)
}
}
+static struct nphy_txgains b43_nphy_get_tx_gains(struct b43_wldev *dev)
+{
+ struct b43_phy_n *nphy = dev->phy.n;
+
+ u16 curr_gain[2];
+ struct nphy_txgains target;
+ u32 *table = NULL;
+
+ if (nphy->txpwrctrl == 0) {
+ int i;
+
+ if (nphy->hang_avoid)
+ b43_nphy_stay_in_carrier_search(dev, true);
+ //TODO: Read an N PHY Table with ID 7, length 2, offset 0x110, width 16, and curr_gain
+ if (nphy->hang_avoid)
+ b43_nphy_stay_in_carrier_search(dev, false);
+
+ for (i = 0; i < 2; ++i) {
+ if (dev->phy.rev >= 3) {
+ target.ipa[i] = curr_gain[i] & 0x000F;
+ target.pad[i] = (curr_gain[i] & 0x00F0) >> 4;
+ target.pga[i] = (curr_gain[i] & 0x0F00) >> 8;
+ target.txgm[i] = (curr_gain[i] & 0x7000) >> 12;
+ } else {
+ target.ipa[i] = curr_gain[i] & 0x0003;
+ target.pad[i] = (curr_gain[i] & 0x000C) >> 2;
+ target.pga[i] = (curr_gain[i] & 0x0070) >> 4;
+ target.txgm[i] = (curr_gain[i] & 0x0380) >> 7;
+ }
+ }
+ } else {
+ int i;
+ u16 index[2];
+ index[0] = (b43_phy_read(dev, B43_NPHY_C1_TXPCTL_STAT) &
+ B43_NPHY_TXPCTL_STAT_BIDX) >>
+ B43_NPHY_TXPCTL_STAT_BIDX_SHIFT;
+ index[1] = (b43_phy_read(dev, B43_NPHY_C2_TXPCTL_STAT) &
+ B43_NPHY_TXPCTL_STAT_BIDX) >>
+ B43_NPHY_TXPCTL_STAT_BIDX_SHIFT;
+
+ for (i = 0; i < 2; ++i) {
+ if (dev->phy.rev >= 3) {
+ enum ieee80211_band band =
+ b43_current_band(dev->wl);
+
+ if ((nphy->ipa2g_on && band == IEEE80211_BAND_2GHZ) ||
+ (nphy->ipa5g_on && band == IEEE80211_BAND_5GHZ)) {
+ table = NULL; //FIXME: = output of N PHY Get IPA GainTbl
+ } else {
+ if (band == IEEE80211_BAND_5GHZ) {
+ if (dev->phy.rev == 3)
+ table = NULL; //FIXME: N PHY TX Power Control - TX Gain Table Rev >= 3 (5 GHz)
+ else if (dev->phy.rev == 4)
+ table = NULL; //FIXME: N PHY TX Power Control - TX Gain Table Rev 4 (5 GHz)
+ else
+ table = NULL; //FIXME: N PHY TX Power Control - TX Gain Table Rev 5 (5 GHz)
+ } else {
+ table = NULL; //FIXME: N PHY TX Power Control - TX Gain Table Rev >= 3 (2.4 GHz)
+ }
+ }
+
+ target.ipa[i] = (table[index[i]] >> 16) & 0xF;
+ target.pad[i] = (table[index[i]] >> 20) & 0xF;
+ target.pga[i] = (table[index[i]] >> 24) & 0xF;
+ target.txgm[i] = (table[index[i]] >> 28) & 0xF;
+ } else {
+ table = NULL; //FIXME: N PHY TX Power Control - TX Gain Table Rev <= 2
+
+ target.ipa[i] = (table[index[i]] >> 16) & 0x3;
+ target.pad[i] = (table[index[i]] >> 18) & 0x3;
+ target.pga[i] = (table[index[i]] >> 20) & 0x7;
+ target.txgm[i] = (table[index[i]] >> 23) & 0x7;
+ }
+ }
+ }
+
+ return target;
+}
+
enum b43_nphy_rf_sequence {
B43_RFSEQ_RX2TX,
B43_RFSEQ_TX2RX,
diff --git a/drivers/net/wireless/b43/phy_n.h b/drivers/net/wireless/b43/phy_n.h
index 6ab07fc..e63c371 100644
--- a/drivers/net/wireless/b43/phy_n.h
+++ b/drivers/net/wireless/b43/phy_n.h
@@ -930,6 +930,7 @@ struct b43_phy_n {
u8 phyrxchain;
u8 mphase_cal_phase_id;
u32 deaf_count;
+ bool hang_avoid;
bool mute;
u16 classifier_state;
--
1.6.4.2
W dniu 6 stycznia 2010 20:36 użytkownik Michael Buesch <[email protected]> napisał:
> On Wednesday 06 January 2010 20:29:36 Rafał Miłecki wrote:
>> > You may read Documentation/SubmittingPatches and format your future
>> > patches according to that.
>>
>> Well, that's really poor joke :| Manually creating .orig files, using
>> "diff -up" and so dropping local commits "strategy"...? Er, I don't
>> think I'll use this one.
>
> Nobody said you need to fix your internal workflow. Why would anybody care
> _how_ you generate your patches?
> You could manually type them into your cellphone with T9. If that it results
> in a properly formated patch in the end, nobody would complain.
Good one! ;)
> So yes, reading other people's patches probably is a good idea to start with.
>
> In general only put stuff into the mail that you want to show up in the commit
> message. (If you want to have additional stuff that doesn't show up in the commit
> message, you can use the "---" delimiter. But that's documented elsewhere so
> I don't have to explain that here...)
I started composing that mail before got real idea of patches. I was
still thinking I need some magic headers "diff" tool generates. Hope I
totally understand this now and won't cause more problems to you guys
:)
--
Rafał