On Sun, 20 Jul 2014 13:50:39 +0200
Rafał Miłecki <zajec5@xxxxxxxxx> wrote:
> On 20 July 2014 13:26, Michael Büsch <m@xxxxxxx> wrote:
> > On Sun, 20 Jul 2014 13:00:22 +0200
> > Rafał Miłecki <zajec5@xxxxxxxxx> wrote:
> >> @@ -6656,5 +6721,4 @@ const struct b43_phy_operations b43_phyops_n = {
> >> .switch_channel = b43_nphy_op_switch_channel,
> >> .get_default_chan = b43_nphy_op_get_default_chan,
> >> .recalc_txpower = b43_nphy_op_recalc_txpower,
> >> - .adjust_txpower = b43_nphy_op_adjust_txpower,
> >
> > recalc_txpower once was designed to just recalculate the txpower and not write it
> > to hardware. adjust_txpower was supposed to write it to hardware afterwards.
> > That had to do with some locking foo and stuff I forgot (AFAIR these callbacks are called
> > in different contexts, but I may be wrong).
> > But I don't think it really matters. Just as a general hint here.
>
> Yeah, I noticed that and was starring at it for a long time.
>
> First of all I verified if @config is allowed to sleep. It is, so our
> "recalc_txpower" can sleep as well if it needs to.
>
> I think that using adjust_txpower on G-PHY could have something to do
> with the way TX power is controlled on these devices. They don't have
adjustment of txpower may be very expensive there. So I think this was
the reason I split it in half and let the heavier part run in workqueue context or
something. Also recalc used to be called from interrupt tasklet. Not sure if
that's still the case anymore, though.
> In N-PHY world there are two registers for setting TX power: 0x1E7 and
> 0x222 (one per core) and two for reading current state: 0x1ED and
> 0x1EE. However you don't really touch them unless you're doing some
> initialization/calibration. For most of the time hardware is supposed
> to adjust TX power, you simply tell the firmware what should it be
> (this is what 0x1EA register is for).
Yeah looks fine.
--
Michael
Attachment:
signature.asc
Description: PGP signature
