Hi,
could somebody enlighten me, when exactly those timestamps are generated?
Regards
Oliver
Hi Oliver,
> > > could somebody enlighten me, when exactly those timestamps are generated?
> >
> > they are normally stamped when they enter our internal queues. So the
> > Bluetooth core stamps them when they come from the driver.
>
> Thanks. That means if they come from btusb on ehci they are
> stamped in interrupt.
> So it is not possible that an event is late because the work queue
> was congested.
not that I can tell. And yes, in case of USB they are stamped in
interrupt.
But with USB keep in mind that HCI events and HCI ACL data is on
different endpoints.
Regards
Marcel
Am Donnerstag, 5. April 2012, 21:34:39 schrieb Marcel Holtmann:
> Hi Oliver,
>
> > could somebody enlighten me, when exactly those timestamps are generated?
>
> they are normally stamped when they enter our internal queues. So the
> Bluetooth core stamps them when they come from the driver.
Thanks. That means if they come from btusb on ehci they are
stamped in interrupt.
So it is not possible that an event is late because the work queue
was congested.
Regards
Oliver
Hi Oliver,
> could somebody enlighten me, when exactly those timestamps are generated?
they are normally stamped when they enter our internal queues. So the
Bluetooth core stamps them when they come from the driver.
/* Receive frame from HCI drivers */
int hci_recv_frame(struct sk_buff *skb)
{
struct hci_dev *hdev = (struct hci_dev *) skb->dev;
if (!hdev || (!test_bit(HCI_UP, &hdev->flags)
&& !test_bit(HCI_INIT, &hdev->flags))) {
kfree_skb(skb);
return -ENXIO;
}
/* Incomming skb */
bt_cb(skb)->incoming = 1;
/* Time stamp */
__net_timestamp(skb);
skb_queue_tail(&hdev->rx_q, skb);
queue_work(hdev->workqueue, &hdev->rx_work);
return 0;
}
Regards
Marcel