[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] USB/Stack changes



Hi Mark,

thanks for your help, we look forward to the finished USB-BT stack :)

> -----Original Message-----
> From: Mark Douglas Corner [mailto:mcorner@xxxxxxx.edu]
> Sent: Tuesday, August 01, 2000 11:04 PM
> To: bluetooth-dev@xxxxxxx.com
> Subject: [bluetooth-dev] USB/Stack changes
> 
> 
> 
> Greg KH and I are almost done with the USB driver.  It should 
> almost work
> with the axis stack when done.  

great !

There are a few things I would like to
> request to get this working with my HW.
> 
> 1) Add a reset to hci_init.  Pretty simple, here is the code:
> 
> s32
> hci_reset()
> {
>   D_CTRL("reset()\n");
>   c_pkt.type = CMD_PKT;
>   c_pkt.ocf = RESET;
>   c_pkt.ogf = HCI_HC;
>   c_pkt.len = 0;
> 
>   return send_cmd((unsigned char*) &c_pkt ,c_pkt.len + 
> CMD_HDR_LEN + HCI_HDR_LEN);
> }

done.

> 
> 2) Add code to do the bt_flush_buffer.  If you don't do this,
> then chars in buffer returns nonzero and pppd has a hard time
> exiting.  Something simple:
> 
> static void
> bt_flush_buffer(struct tty_struct *tty)
> {
>   bt_tx_buf* tx_buf;
>   /* Must flush the buffer, otherwise chars_in_buffer returns nonzero
>      and pppd hangs on the exit while doing the set line disc ioctl */
>   BT_DRIVER("bt_flush_buffer\n");
>   
>   while((tx_buf = get_bt_buf())){
>     unsubscribe_bt_buf(tx_buf);
>   }
> }

done.

> 
> 3) In bt_create_connection if the rfcomm_connection_req is interrupted
> (say by ctrl-c) then r_value returns 0 and the sdp_disconnect_req goes
> forward and eventually an oops occurs.  This seemed to work, 
> may be you
> have something better:
> 
> if (r_value != 0)
> 		  sdp_disconnect_req(tmp);
> 

done, this will be changed eventually but will do for now.


> 4) I get timeouts on pretty much all hci ctrl transfers. This 
> is because
> the return result and the wake up occur before the sleep 
> occurs.  I don't
> have a great fix for this yet other than to ignore the 
> timeouts since they
> are harmless.
> 

I don't think we have experienced this problem, however I'll have a look on it.


> 5) I have a few other small problems that seem to occur with 
> my P7C based
> HW, but those may be just me.  One major one is that control 
> messages are
> totally unreliable unless the bulk transfers are off.  There are
> references to this in the USB driver.
> 
> ----                                                          
>          
> Mark Douglas Corner                                      
> mcorner@xxxxxxx.edu
> 

The changes will be in next release hopefully before friday.

brgds
/Mattias