Return-path: Received: from mail.atheros.com ([12.36.123.2]:57030 "EHLO mail.atheros.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750740AbZE1TZx (ORCPT ); Thu, 28 May 2009 15:25:53 -0400 Received: from mail.atheros.com ([10.10.20.105]) by sidewinder.atheros.com for ; Thu, 28 May 2009 12:25:56 -0700 Date: Thu, 28 May 2009 12:26:01 -0700 From: "Luis R. Rodriguez" To: Christian Lamparter CC: Luis Rodriguez , "linux-wireless@vger.kernel.org" , "jal2@gmx.de" , Peter Grabienski , Stephen Chen , Michael Fortin , Johnny Cheng , Yuan-Gu Wei , "otus-devel@lists.madwifi-project.org" Subject: Re: [RFT 1/2] ar9170: add initial support for 1-stage firmware Message-ID: <20090528192601.GD20870@tesla> References: <1243475326-28867-1-git-send-email-lrodriguez@atheros.com> <1243475326-28867-2-git-send-email-lrodriguez@atheros.com> <200905281803.44198.chunkeey@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" In-Reply-To: <200905281803.44198.chunkeey@web.de> Sender: linux-wireless-owner@vger.kernel.org List-ID: On Thu, May 28, 2009 at 09:03:43AM -0700, Christian Lamparter wrote: > On Thursday 28 May 2009 03:48:45 Luis R. Rodriguez wrote: > > You can get the stage 1 firmware from here: > > > > http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/ar9170.fw > > > > Its license: > > > > http://www.kernel.org/pub/linux/kernel/people/mcgrof/firmware/ar9170/LICENSE > > > > It seems with some devices this works, with some others > > I see only scan working. We shall not push this firmware > > into the linux-firmware tree until these issues have been > > resolved. > > > > Cc: Peter Grabienski > > Cc: Stephen Chen > > Cc: Michael Fortin > > Cc: Johnny Cheng > > Cc: Yuan-Gu Wei > > Cc: Joerg Albert > > Signed-off-by: Luis R. Rodriguez > > --- > > drivers/net/wireless/ath/ar9170/phy.c | 13 ++++++++++--- > > drivers/net/wireless/ath/ar9170/usb.c | 22 +++++++++++++++++----- > > 2 files changed, 27 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/net/wireless/ath/ar9170/phy.c b/drivers/net/wireless/ath/ar9170/phy.c > > index 6ce2075..0675dc8 100644 > > --- a/drivers/net/wireless/ath/ar9170/phy.c > > +++ b/drivers/net/wireless/ath/ar9170/phy.c > > @@ -39,6 +39,7 @@ > > #include > > #include "ar9170.h" > > #include "cmd.h" > > +#include "usb.h" > > > > static int ar9170_init_power_cal(struct ar9170 *ar) > > { > > @@ -996,6 +997,10 @@ static int ar9170_set_power_cal(struct ar9170 *ar, u32 freq, enum ar9170_bw bw) > > int idx, i, n; > > u8 ackpower, ackchains, f; > > u8 pwr_freqs[AR5416_MAX_NUM_TGT_PWRS]; > > + struct ar9170_usb *aru; > > + > > + /* All ar9170 devices are USB */ > > + aru = container_of(ar, struct ar9170_usb, common); > > > > if (freq < 3000) > > f = freq - 2300; > > @@ -1102,9 +1107,11 @@ static int ar9170_set_power_cal(struct ar9170 *ar, u32 freq, enum ar9170_bw bw) > > else > > ackpower = ar->power_5G_leg[0] & 0x3f; > > > > - ar9170_regwrite(0x1c3694, ackpower << 20 | ackchains << 26); > > - ar9170_regwrite(0x1c3bb4, ackpower << 5 | ackchains << 11 | > > - ackpower << 21 | ackchains << 27); > > + if (aru->init_values) { > > + ar9170_regwrite(0x1c3694, ackpower << 20 | ackchains << 26); > > + ar9170_regwrite(0x1c3bb4, ackpower << 5 | ackchains << 11 | > > + ackpower << 21 | ackchains << 27); > > + } > > > > ar9170_regwrite_finish(); > > return ar9170_regwrite_result(); > I guess you can drop this changes. see hpmain.c line 4039, 4061, 4069 > > --> #if_N_def ZM_OTUS_LINUX_PHASE_2 <-- > zfDelayWriteInternalReg(dev, 0x1c3694, ((hpPriv->tPow2x2g[0]&0x3f) << 20) | (0x5<<26)); > zfDelayWriteInternalReg(dev, 0x1c3bb4, ((hpPriv->tPow2x2g[0]&0x3f) << 5 ) | (0x5<<11) | > ((hpPriv->tPow2x2g[0]&0x3f) << 21) | (0x5<<27) ); > #endif > so, the current ar9170 code is actually _wrong_ (but works!)... > and we should not touch these fields with the 2-stage firmware. Oh, hm, yeah good catch, but to match would actually need to call it when stage-1 firmware is used. > OT: since the firmware will (inevitably end up in the firmware-git-tree) > we should convert it to ihex, so it can be downloaded with the git-web. > (this can be done by: objcopy -I binary -O ihex ar9170.fw ar9170.fw.ihex ) Sure, whatever works best. If you download it from gitweb you then have to do the conversion back though. > And for future: it might be a good idea to add a little header/tail on the > firmware files. e.g.: > - firmware version and variant (e.g. 1-stage or 2-stage firmware) > - supported hardware variants/interfaces > - maybe API revision / feature bitmap > - maybe more: e.g: vendor string / build / build-date / build no. etc. I think some version strings exist, but yeah you're right. Luis