Hi Johannes,
Sorry for the late response:(
On 2017-01-09 16:06, Johannes Berg wrote:
Is it fine to have something like this
1) We can have this btcoex_priority value as a optional value in
btcoex enable command like below
iw phyX btcoex_state [prirority(vendor spcific
> Is it fine to have something like this
>
> 1) We can have this btcoex_priority value as a optional value in
> btcoex enable command like below
>
> iw phyX btcoex_state [prirority(vendor spcific
> value)]
>
> 2) Or we can have seperate command for btcoex_priority as below
>
Hi Johannes,
Thank you for the reply.
On 2017-01-05 19:08, Johannes Berg wrote:
> IOW - why have all these bits rather than just one?
Hardware supports data across all the access categories, this is
just meant for prioritising the traffic. f.e, If the fw/target has
both wlan and bt traffic
> > IOW - why have all these bits rather than just one?
>
> Hardware supports data across all the access categories, this is
> just meant for prioritising the traffic. f.e, If the fw/target has
> both wlan and bt traffic queued and if VO is set as priority, then
> wlan VO packets will be
On 2017-01-02 16:18, Johannes Berg wrote:
> 1) does it even make sense to split it out per AC? wouldn't it be
> weird
> if you supported this only for VO and BK, and not the others, or
> something like that?
>
It has support for BE, VI, management and beacon frames also.
Or do you meant to say
> > 1) does it even make sense to split it out per AC? wouldn't it be
> > weird
> > if you supported this only for VO and BK, and not the others, or
> > something like that?
> >
>
> It has support for BE, VI, management and beacon frames also.
> Or do you meant to say like support only for VO
Hi Johannes,
Thanks for your comments.
On 2016-12-16 15:07, Johannes Berg wrote:
> > is it fine to have as WIPHY_BTCOEX_BE_PREFERRED ?
>
> It's not really clear to me what you intend to do this - if it's
> really support flags then you really should name those better.
>
This is support flags
> > > is it fine to have as WIPHY_BTCOEX_BE_PREFERRED ?
> >
> > It's not really clear to me what you intend to do this - if it's
> > really support flags then you really should name those better.
> >
>
> This is support flags and it used by the driver to intimate driver
> supported frame type
> > > /**
> > > + * wiphy_btcoex_support_flags
> > > + * This enum has the driver supported frame types for
> > > BTCOEX.
> > > + * @WIPHY_WLAN_BE_PREFERRED - Supports Best Effort frame for
> > > BTCOEX
> > > + * @WIPHY_WLAN_BK_PREFERRED - supports Background frame for
> > > BTCOEX
> > > +
Hi Johannes,
Thanks for the comments.
On 2016-12-05 20:19, Johannes Berg wrote:
On Tue, 2016-11-08 at 18:45 +0530, c_tr...@qti.qualcomm.com wrote:
+ * struct cfg80211_btcoex_priority - BTCOEX support frame type
+ *
+ * This structure defines the driver supporting frame types for
BTCOEX
+ *
On Tue, 2016-11-08 at 18:45 +0530, c_tr...@qti.qualcomm.com wrote:
>
> + * struct cfg80211_btcoex_priority - BTCOEX support frame type
> + *
> + * This structure defines the driver supporting frame types for
> BTCOEX
> + *
> + * @wlan_be_preferred: best effort frames preferred over bt traffic
> +
From: Tamizh chelvam
This change enables user to set high priority for driver supported wlan
frames when BTCOEX enabled. The drivers that expose such capability make
use of this priority table to decide to whom the radio should be shared
(either bluetooth or WLAN). When
12 matches
Mail list logo