* pull request: bluetooth-2.6 2010-11-01
@ 2010-12-01 21:11 Gustavo F. Padovan
2011-01-10 21:24 ` carl9170: RX and TX interrupt callback ? Chris Pechard
0 siblings, 1 reply; 5+ messages in thread
From: Gustavo F. Padovan @ 2010-12-01 21:11 UTC (permalink / raw)
To: linville; +Cc: marcel, linux-wireless, linux-bluetooth
Hi John,
Here goes 3 simple patches intended to 2.6.37. First one is from myself
and fix some trivial return values. Then we also have a fix from Stefan
Seyfried on btusb to avoid emitting an err when we USB is autosupended.
Last, a patch from Bala Shanmugam that fix the firmware loading process
for the ath3k driver.
Please pull, or let me know if you disagree with the patches. Thanks a
lot. ;)
The following changes since commit 916448e77f6bcaaa7f13c3de0c3851783ae2bfd0:
ath9k: Fix STA disconnect issue due to received MIC failed bcast frames (2010-11-30 13:45:02 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git master
Bala Shanmugam (1):
Bluetooth: Add new PID for Atheros 3011
Gustavo F. Padovan (1):
Bluetooth: Fix not returning proper error in SCO
Stefan Seyfried (1):
Bluetooth: Fix log spamming in btusb due to autosuspend
drivers/bluetooth/ath3k.c | 4 ++++
drivers/bluetooth/btusb.c | 12 +++++++++---
net/bluetooth/sco.c | 6 +++---
3 files changed, 16 insertions(+), 6 deletions(-)
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply [flat|nested] 5+ messages in thread
* carl9170: RX and TX interrupt callback ?
2010-12-01 21:11 pull request: bluetooth-2.6 2010-11-01 Gustavo F. Padovan
@ 2011-01-10 21:24 ` Chris Pechard
2011-01-10 22:39 ` Christian Lamparter
2011-01-31 21:17 ` carl9170: RX interrupt handler Chris Pechard
0 siblings, 2 replies; 5+ messages in thread
From: Chris Pechard @ 2011-01-10 21:24 UTC (permalink / raw)
To: linux-wireless
I am trying to do time measurement using carl9170 firmware side. There was some
interesting previous thread about clock to be used and location of the probe in
the code. My goal is to get a precise time from the moment a packet has been
transmitted (timestamp when the packet has been transmitted) and the arrival of
the next received packet (time when a packet has been fully received). Looking
though the code, there is a loop in src/main.c handling the TX/RX interrupt by
reading the AR9170_MAC_REG_INT_CTRL register and checking the
AR9170_MAC_INT_TXC/RXC bits. Pending on task to be performed in the loop, it
could take tens of microseconds to go through one iteration which affects the
measurement and resulting in having RXC timestamp smaller than TXC timestamp
which is clearly an issue !
My current workaround is to add many check to AR9170_MAC_REG_INT_CTRL in the
main loop to reduce the detection latency which at least gave me better results
(TXC time < RXC time ) but somehow it does not seem AR9170_MAC_REG_INT_CTRL
register is refreshed right away when a packet is received or transmitted. I
would like to know if there is any way to attach a callback function to the RXC
or TXC interrupt so that we get immediate notification instead of depending on
a polling method. If not, is there any way to minimize delays between the time
a packet is sent/received and the TXC/RXC bit flag raised in the register ?
Thanks,
Chris.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: carl9170: RX and TX interrupt callback ?
2011-01-10 21:24 ` carl9170: RX and TX interrupt callback ? Chris Pechard
@ 2011-01-10 22:39 ` Christian Lamparter
2011-01-10 23:36 ` Chris Pechard
2011-01-31 21:17 ` carl9170: RX interrupt handler Chris Pechard
1 sibling, 1 reply; 5+ messages in thread
From: Christian Lamparter @ 2011-01-10 22:39 UTC (permalink / raw)
To: Chris Pechard; +Cc: linux-wireless
On Monday 10 January 2011 22:24:18 Chris Pechard wrote:
> I am trying to do time measurement using carl9170 firmware side. There was some
> interesting previous thread about clock to be used and location of the probe in
> the code. My goal is to get a precise time from the moment a packet has been
> transmitted (timestamp when the packet has been transmitted) and the arrival of
> the next received packet (time when a packet has been fully received). Looking
> though the code, there is a loop in src/main.c handling the TX/RX interrupt by
> reading the AR9170_MAC_REG_INT_CTRL register and checking the
> AR9170_MAC_INT_TXC/RXC bits. Pending on task to be performed in the loop, it
> could take tens of microseconds to go through one iteration which affects the
> measurement and resulting in having RXC timestamp smaller than TXC timestamp
> which is clearly an issue!
are you sure, you put the right code in the right place :-D .
I've posted code for the same idea a while ago [on this mailing-list] and I
can't remember anything that weird.
> My current workaround is to add many check to AR9170_MAC_REG_INT_CTRL in the
> main loop to reduce the detection latency which at least gave me better results
> (TXC time < RXC time ) but somehow it does not seem AR9170_MAC_REG_INT_CTRL
> register is refreshed right away when a packet is received or transmitted. I
> would like to know if there is any way to attach a callback function to the RXC
> or TXC interrupt so that we get immediate notification instead of depending on
> a polling method.
Oh it is, or it should be easy to get an interrupt event from the MAC processor.
You just have to look through the SH2 platform docs [which are freely available
from Reneas] and setup the interrupt controller accordingly.
If you're stuck and need advice on the f/irq topic, you should definitely ask
Stephen Chen <Stephen.Chen@atheros.com> for assistance. As he's one of the
few persons who know how it works. I certainly can't...
Good Luck!
> If not, is there any way to minimize delays between the time
> a packet is sent/received and the TXC/RXC bit flag raised in the register?
Don't forget the 802.11 is working against you.
CSMA/CA with R/S/D/P/E/IFS, [random] backoff, dynamic ACK delays and
so much more can really spoil the day, if you are not aware that it's
there.
Furthermore, have you tried to contact the people behind similar projects?
Ignacy Gawedzki <i@lri.fr>
David H. Lynch Jr. <dhlii@dlasys.net>
Especially David, since it seems that he's done with it.
Best Regards,
Chr
PS.: you could also go a different route with OpenFWWF.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: carl9170: RX and TX interrupt callback ?
2011-01-10 22:39 ` Christian Lamparter
@ 2011-01-10 23:36 ` Chris Pechard
0 siblings, 0 replies; 5+ messages in thread
From: Chris Pechard @ 2011-01-10 23:36 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless
Thanks for the pointers, I will definitively contact the people you listed.
Chris.
----- Original Message ----
From: Christian Lamparter <chunkeey@googlemail.com>
To: Chris Pechard <chrispechard@yahoo.com>
Cc: linux-wireless@vger.kernel.org
Sent: Mon, January 10, 2011 2:39:39 PM
Subject: Re: carl9170: RX and TX interrupt callback ?
On Monday 10 January 2011 22:24:18 Chris Pechard wrote:
> I am trying to do time measurement using carl9170 firmware side. There was some
>
> interesting previous thread about clock to be used and location of the probe in
>
> the code. My goal is to get a precise time from the moment a packet has been
> transmitted (timestamp when the packet has been transmitted) and the arrival of
>
> the next received packet (time when a packet has been fully received). Looking
> though the code, there is a loop in src/main.c handling the TX/RX interrupt by
> reading the AR9170_MAC_REG_INT_CTRL register and checking the
> AR9170_MAC_INT_TXC/RXC bits. Pending on task to be performed in the loop, it
> could take tens of microseconds to go through one iteration which affects the
> measurement and resulting in having RXC timestamp smaller than TXC timestamp
> which is clearly an issue!
are you sure, you put the right code in the right place :-D .
I've posted code for the same idea a while ago [on this mailing-list] and I
can't remember anything that weird.
[CP]: :-) I am measuring the delta between when a packet has left the wireless
interface and the time the next packet is received on the interface. This timing
is much less forgiving than measuring the time when a packet is sent to the TX
queue and TXC or RXC has occurred ( the time difference could be more than
double due to firmware latency, 802.11 medium access and packet transmit time).
That's the reason I am interested in fast TXC notification which would
eliminates some of the random delays.
> My current workaround is to add many check to AR9170_MAC_REG_INT_CTRL in the
> main loop to reduce the detection latency which at least gave me better results
>
> (TXC time < RXC time ) but somehow it does not seem AR9170_MAC_REG_INT_CTRL
> register is refreshed right away when a packet is received or transmitted. I
> would like to know if there is any way to attach a callback function to the
>RXC
>
> or TXC interrupt so that we get immediate notification instead of depending on
>
> a polling method.
Oh it is, or it should be easy to get an interrupt event from the MAC processor.
You just have to look through the SH2 platform docs [which are freely available
from Reneas] and setup the interrupt controller accordingly.
If you're stuck and need advice on the f/irq topic, you should definitely ask
Stephen Chen <Stephen.Chen@atheros.com> for assistance. As he's one of the
few persons who know how it works. I certainly can't...
Good Luck!
> If not, is there any way to minimize delays between the time
> a packet is sent/received and the TXC/RXC bit flag raised in the register?
Don't forget the 802.11 is working against you.
CSMA/CA with R/S/D/P/E/IFS, [random] backoff, dynamic ACK delays and
so much more can really spoil the day, if you are not aware that it's
there.
Furthermore, have you tried to contact the people behind similar projects?
Ignacy Gawedzki <i@lri.fr>
David H. Lynch Jr. <dhlii@dlasys.net>
Especially David, since it seems that he's done with it.
Best Regards,
Chr
PS.: you could also go a different route with OpenFWWF.
^ permalink raw reply [flat|nested] 5+ messages in thread
* carl9170: RX interrupt handler
2011-01-10 21:24 ` carl9170: RX and TX interrupt callback ? Chris Pechard
2011-01-10 22:39 ` Christian Lamparter
@ 2011-01-31 21:17 ` Chris Pechard
1 sibling, 0 replies; 5+ messages in thread
From: Chris Pechard @ 2011-01-31 21:17 UTC (permalink / raw)
To: linux-wireless
The carl9170 firmware is notified of incoming packets from the the mac processor
via AR9170_MAC_INT_RXC bit set in AR9170_MAC_REG_INT_CTRL control register.
Currently the register is polled through an infinite loop. In order to get
faster detection of incoming packets, I would like to program a hardware
interrupt handler which would be called right away instead of depending on a
polling cycle state. From Steven Chen at Atheros, the chip supports hw
interrupts even though it is not in used by the open source firmware. Has anyone
tried to enable this feature ? If you have any pointers on how to enable hw
interrupt on the arl9170, feel free to flood my mailbox :-) !
Thanks,
Chris.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-01-31 21:24 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-01 21:11 pull request: bluetooth-2.6 2010-11-01 Gustavo F. Padovan
2011-01-10 21:24 ` carl9170: RX and TX interrupt callback ? Chris Pechard
2011-01-10 22:39 ` Christian Lamparter
2011-01-10 23:36 ` Chris Pechard
2011-01-31 21:17 ` carl9170: RX interrupt handler Chris Pechard
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.