From: Zefir Kurtisi <zefir.kurtisi@neratec.com>
To: "Luis R. Rodriguez" <rodrigue@qca.qualcomm.com>
Cc: linux-wireless <linux-wireless@vger.kernel.org>,
Boris Presman <boris.presman@ti.com>, Assaf Azulay <assaf@ti.com>,
Michael Green <green@qca.qualcomm.com>,
David Quan <dquan@qca.qualcomm.com>,
Kevin Hayes <hayes@qca.qualcomm.com>,
Arun Venkataraman <arunvenk@qca.qualcomm.com>
Subject: Re: Regulatory revamp status
Date: Thu, 29 Sep 2011 10:37:06 +0200 (CEST) [thread overview]
Message-ID: <1125417094.1836.1317285426615.JavaMail.root@idefix> (raw)
In-Reply-To: <CAB=NE6U6qmYbvHPTWGTqOdXtuxbKYbUzZXNiE6POOX9QZNRWAg@mail.gmail.com>
Thanks for the update.
To me it looks not reasonable to mix in between the two approaches: either we assume countrycodes use the same DFS region for all channels, or each channel/band needs to have its own. Otherwise I feel that a DFS region bitmap would give a semi-flexible compromise that might end up being insufficient to represent some fancy countrycodes.
Zefir
----- Original Message -----
> From: "Luis R. Rodriguez" <rodrigue@qca.qualcomm.com>
> To: "Zefir Kurtisi" <zefir.kurtisi@neratec.com>, "Michael Green" <green@qca.qualcomm.com>, "David Quan"
> <dquan@qca.qualcomm.com>, "Kevin Hayes" <hayes@qca.qualcomm.com>, "Arun Venkataraman" <arunvenk@qca.qualcomm.com>
> Cc: "linux-wireless" <linux-wireless@vger.kernel.org>, "Boris Presman" <boris.presman@ti.com>, "Assaf Azulay"
> <assaf@ti.com>
> Sent: Wednesday, 28 September, 2011 9:52:15 PM
> Subject: Re: Regulatory revamp status
> On Wed, Sep 28, 2011 at 8:45 AM, Zefir Kurtisi
> <zefir.kurtisi@neratec.com> wrote:
> > Hello Luis,
> >
> > I am referring to your announcement for a regulatory revamp at the
> > LinuxWireless
> > summit in Vancouver and the patches to add DFS information to CRDA
> > you
> > proposed quite some time ago in [1].
> >
> > For the integration of DFS that is currently being worked out by TI,
> > we will need to have
> > the DFS regulatory domain for the selected countrycode available --
> > that basically was
> > implemented with the named patch set.
>
> Yup, there was one pending item on that and it was to determine
> whether or not a country can have different DFS regions for different
> frequency bands. If this is true this also implies that a country can
> have multiple DFS regions. I have found one country in our internal
> regulatory updates which maps Bulgaria to different DFS regions and
> have asked our regulatory folks about this. This seems odd to me and
> I'd prefer to stick to one DFS region entirely for one country, but if
> in the future we forsee DFS regions to be band specific this may
> complicate things and we should address this now. Can you tell me if
> at TI you have no multiple DFS regions for one country ? Do you guys
> have Bulgaria mapping to one DFS region?
>
> > Could you please give some info on the status of the regulatory
> > revamp and particularly if
> > the proposed DFS information will be part of it?
>
> You should consider DFS integration into wireless-regdb as independent
> of the regulatory revamp given that we have 16 bits we can use to
> extend wireless-regdb for any future capabilities without having to
> restructure the format of the file to require a different version of
> crda. So DFS can be added as-is today. Updates below on the regulatory
> revamp though and DFS.
>
> I'm chugging along the regulatory revamp slowly given the questions
> that come up with it require consulting with several different people.
> The latest piece I reviewed was TPC and for that it seems we already
> take into account the 3 dB difference into account into
> wireless-regdb, however this can be further optimized if TPC is
> implemented -- but implementing TPC is device specific in that the TPC
> reports and how you use them can vary depending on the device. When
> you send TPC report requests will also vary. In short I've latest
> determined to stick to what we have today and assume we'll always be
> reducing the 3 dB in power built-in already into the wireless-regdb
> power for each country where needed. This assumes no proper TPC
> implementation. It would still be nice to know when a band requires
> TPC though to enable vendors to implement TPC and reduce power not by
> 3 dB but by whatever metrics they come up with. Given that 3 dB seems
> to be the only required change we likely could stick to that as the
> assumed max value and just require a TPC flag, and if the band has
> this flag allow the driver / stack / etc to add 3 dB more to power if
> it implements TPC. The only problem with this is we'd assume alway a
> static 3 dB. Another possibility is to use a u8 value here to
> represent the deducted tx power, instead of a bit value for a flag.
>
> Technically speaking we can support both DFS and TPC in the current
> file format for wireless-regdb, we have 16 bits left, we could leave
> u8 for DFS region as a bitmask (left to determine about the multiple
> DFS regions) and u8 for the tx power adaptation for TPC. Thoughts?
>
> > One detail that came up in the discussion to
> > your patches was whether DFS regulatory domains are constant for a
> > countrycode or might
> > differ between bands. Has this been clarified meanwhile?
>
> Not yet! I've asked for input a while ago and today as well. What do
> you guys think?
>
> Luis
next prev parent reply other threads:[~2011-09-29 8:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-24 23:11 Regulatory simulator - regulatory revamp work Luis R. Rodriguez
2011-09-28 15:45 ` Regulatory revamp status Zefir Kurtisi
2011-09-28 19:52 ` Luis R. Rodriguez
2011-09-29 8:37 ` Zefir Kurtisi [this message]
2011-09-29 11:45 ` Adrian Chadd
2011-09-29 12:46 ` Zefir Kurtisi
2011-09-29 17:47 ` Luis R. Rodriguez
2011-09-30 11:11 ` Zefir Kurtisi
2011-09-30 11:21 ` Adrian Chadd
2011-09-30 12:52 ` Zefir Kurtisi
2011-10-03 20:00 ` Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1125417094.1836.1317285426615.JavaMail.root@idefix \
--to=zefir.kurtisi@neratec.com \
--cc=arunvenk@qca.qualcomm.com \
--cc=assaf@ti.com \
--cc=boris.presman@ti.com \
--cc=dquan@qca.qualcomm.com \
--cc=green@qca.qualcomm.com \
--cc=hayes@qca.qualcomm.com \
--cc=linux-wireless@vger.kernel.org \
--cc=rodrigue@qca.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).