* [Bluez-users] 2.6.0-test9 SiW works sometimes @ 2003-11-05 11:06 Andreas Sundstrom 2003-11-05 11:22 ` Marcel Holtmann 0 siblings, 1 reply; 21+ messages in thread From: Andreas Sundstrom @ 2003-11-05 11:06 UTC (permalink / raw) To: bluez-users Hi, I have a Toshiba Laptop with a Bluetooth USB device integrated in it. I can use the BT device without problems in 2.4.22, but with 2.6.0-test9=20 it doesn't work for most of the time. USB seems to be working just fine so that shouldn't be it. The problem is that most of the time a "hcitool inq/scan" just returns "Inquiring ..." immediatly, without any delay like it didn't do anything. If I remove the modules and reload them over and over again it usually=20 works after a while and when it works it stays working until I decide to=20 reboot. I've tried to enable some debugging in hci_usb.c but I don't understand what to make out of it.. not much that seems wrong to me.. I get one error when loading the hci_usb module though: hub 4-0:1.0: new USB device on port 1, assigned address 2 hci_usb: probe of 4-1:1.1 failed with error -5 Don't know if it's related, the device seems fine and this showes up even when the device happen to work. Just let me know if there is something I can provide/test debug or=20 whatever.. This is my BT device: T: Bus=3D04 Lev=3D01 Prnt=3D01 Port=3D00 Cnt=3D01 Dev#=3D 2 Spd=3D12 M= xCh=3D 0 D: Ver=3D 1.10 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 MxPS=3D64 #Cfgs=3D 1 P: Vendor=3D0930 ProdID=3D0502 Rev=3D 0.00 S: Manufacturer=3DSiW S: Product=3DSiW S: SerialNumber=3D9113087A0300 C:* #Ifs=3D 2 Cfg#=3D 1 Atr=3Da0 MxPwr=3D200mA I: If#=3D 0 Alt=3D 0 #EPs=3D 3 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver= =3Dhci_usb E: Ad=3D81(I) Atr=3D03(Int.) MxPS=3D 16 Ivl=3D1ms E: Ad=3D82(I) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms E: Ad=3D02(O) Atr=3D02(Bulk) MxPS=3D 64 Ivl=3D0ms I: If#=3D 1 Alt=3D 0 #EPs=3D 2 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver= =3D(none) E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 0 Ivl=3D1ms I: If#=3D 1 Alt=3D 1 #EPs=3D 2 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver= =3D(none) E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 9 Ivl=3D1ms I: If#=3D 1 Alt=3D 2 #EPs=3D 2 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver= =3D(none) E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 17 Ivl=3D1ms I: If#=3D 1 Alt=3D 3 #EPs=3D 2 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver= =3D(none) E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 25 Ivl=3D1ms I: If#=3D 1 Alt=3D 4 #EPs=3D 2 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver= =3D(none) E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 33 Ivl=3D1ms I: If#=3D 1 Alt=3D 5 #EPs=3D 2 Cls=3De0(unk. ) Sub=3D01 Prot=3D01 Driver= =3D(none) E: Ad=3D83(I) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms E: Ad=3D03(O) Atr=3D01(Isoc) MxPS=3D 49 Ivl=3D1ms Thanks /Andreas Sundstr=F6m ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-05 11:06 [Bluez-users] 2.6.0-test9 SiW works sometimes Andreas Sundstrom @ 2003-11-05 11:22 ` Marcel Holtmann 2003-11-05 12:07 ` Andreas Sundstrom 0 siblings, 1 reply; 21+ messages in thread From: Marcel Holtmann @ 2003-11-05 11:22 UTC (permalink / raw) To: Andreas Sundstrom; +Cc: BlueZ Mailing List Hi Andreas, > I have a Toshiba Laptop with a Bluetooth USB device integrated in it. > I can use the BT device without problems in 2.4.22, but with 2.6.0-test9 > it doesn't work for most of the time. from the devices output I see that this device is based on a Silicon Wave chip and it seems that I don't have this device in my list. So what kind of model do you have and what is the output of "hciconfig -a". > USB seems to be working just fine so that shouldn't be it. > > The problem is that most of the time a "hcitool inq/scan" just returns > "Inquiring ..." immediatly, without any delay like it didn't do anything. > > If I remove the modules and reload them over and over again it usually > works after a while and when it works it stays working until I decide to > reboot. What are your kernel config settings for the HCI USB driver. I prefer you try it with these. CONFIG_BT_HCIUSB=m # CONFIG_BT_USB_SCO is not set # CONFIG_BT_USB_ZERO_PACKET is not set > I've tried to enable some debugging in hci_usb.c but I don't understand > what to make out of it.. not much that seems wrong to me.. Include a "#define HCI_USB_DEBUG" after the last include directive. > I get one error when loading the hci_usb module though: > hub 4-0:1.0: new USB device on port 1, assigned address 2 > hci_usb: probe of 4-1:1.1 failed with error -5 > > Don't know if it's related, the device seems fine and this showes up > even when the device happen to work. This is a question for the USB guys. Do you have another USB Bluetooth dongle to test with your notebook? Regards Marcel ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-05 11:22 ` Marcel Holtmann @ 2003-11-05 12:07 ` Andreas Sundstrom 2003-11-05 12:18 ` Marcel Holtmann 0 siblings, 1 reply; 21+ messages in thread From: Andreas Sundstrom @ 2003-11-05 12:07 UTC (permalink / raw) To: BlueZ Mailing List First, thanks for taking your time to look at my problem, I appreciate it! Here goes... Marcel Holtmann wrote: > Hi Andreas, ... > from the devices output I see that this device is based on a Silicon > Wave chip and it seems that I don't have this device in my list. So what > kind of model do you have and what is the output of "hciconfig -a". hci0: Type: USB BD Address: 00:03:7A:08:13:91 ACL MTU: 60:20 SCO MTU: 64:0 UP RUNNING PSCAN ISCAN RX bytes:63 acl:0 sco:0 events:7 errors:0 TX bytes:28 acl:0 sco:0 commands:7 errors:0 Features: 0xff 0x02 0x04 0x00 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 Link policy: Link mode: SLAVE ACCEPT Name: '' Class: 0x000000 Service Classes: Unspecified Device Class: Miscellaneous, HCI Ver: 1.1 (0x1) HCI Rev: 0x0 LMP Ver: 1.1 (0x1) LMP Subver: 0x514 Manufacturer: Silicon Wave (11) > What are your kernel config settings for the HCI USB driver. I prefer > you try it with these. > > CONFIG_BT_HCIUSB=m > # CONFIG_BT_USB_SCO is not set > # CONFIG_BT_USB_ZERO_PACKET is not set Right now I have CONFIG_BT_HCIUSB=y beacause I checked if that would make things better, it did not. SCO,Zeropacket is off >>I've tried to enable some debugging in hci_usb.c but I don't understand >>what to make out of it.. not much that seems wrong to me.. > > > Include a "#define HCI_USB_DEBUG" after the last include directive. That's what I did.. I meant that the output I got from it didn't say much to mee.. I'll attach it in the end of the mail so you can check it. >>I get one error when loading the hci_usb module though: >>hub 4-0:1.0: new USB device on port 1, assigned address 2 >>hci_usb: probe of 4-1:1.1 failed with error -5 >> >>Don't know if it's related, the device seems fine and this showes up >>even when the device happen to work. > > > This is a question for the USB guys. Do you have another USB Bluetooth > dongle to test with your notebook? I inserted a MS Wireless Transceiver for Bluetooth and it gave the same error.. but seems to work alright. Havn't done much testing yet though. > > Regards > > Marcel > Here's the output from a "bad" session: This is what I'v run: //inserts the device into the USB hub # echo blue_on:1 > /proc/acpi/toshiba/bluetooth # hciconfig hci0: Type: USB BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0 DOWN RX bytes:0 acl:0 sco:0 events:0 errors:0 TX bytes:0 acl:0 sco:0 commands:0 errors:0 # hciconfig hic0 up //No delay and no detected devices # hcitool inq Inquiring ... Here's the dmesg output: hub 4-0:1.0: new USB device on port 1, assigned address 2 hci_usb_probe: udev d8436c00 ifnum -1069408960 hci_usb_probe: udev d8436c00 ifnum -1069408960 hci_usb: probe of 4-1:1.1 failed with error -5 hci_usb_open: hci0 hci_usb_intr_rx_submit: hci0 hci_usb_bulk_rx_submit: hci0 urb d947f694 hci_usb_send_frame: hci0 type 1 len 3 hci_usb_tx_process: hci0 hci_usb_send_ctrl: hci0 skb da07f880 len 3 __tx_submit: hci0 urb d8fd3c14 type 1 hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0 hci_usb_tx_process: hci0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 14 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 14 __recv_frame: new packet len 14 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_send_frame: hci0 type 1 len 3 hci_usb_tx_process: hci0 hci_usb_send_ctrl: hci0 skb d843bb80 len 3 __tx_submit: hci0 urb d8fd3c14 type 1 hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0 hci_usb_tx_process: hci0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 13 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 13 __recv_frame: new packet len 13 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_send_frame: hci0 type 1 len 3 hci_usb_tx_process: hci0 hci_usb_send_ctrl: hci0 skb da07f980 len 3 __tx_submit: hci0 urb d8fd3c14 type 1 hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0 hci_usb_tx_process: hci0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 12 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 12 __recv_frame: new packet len 12 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_send_frame: hci0 type 1 len 5 hci_usb_tx_process: hci0 hci_usb_send_ctrl: hci0 skb dd748980 len 5 __tx_submit: hci0 urb d8fd3c14 type 1 hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0 hci_usb_tx_process: hci0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 6 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 6 __recv_frame: new packet len 6 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_send_frame: hci0 type 1 len 5 hci_usb_tx_process: hci0 hci_usb_send_ctrl: hci0 skb d843bc80 len 5 __tx_submit: hci0 urb d8fd3c14 type 1 hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0 hci_usb_tx_process: hci0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 6 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 6 __recv_frame: new packet len 6 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_send_frame: hci0 type 1 len 5 hci_usb_tx_process: hci0 hci_usb_send_ctrl: hci0 skb d843ba80 len 5 __tx_submit: hci0 urb d8fd3c14 type 1 hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0 hci_usb_tx_process: hci0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 6 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 6 __recv_frame: new packet len 6 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_send_frame: hci0 type 1 len 4 hci_usb_tx_process: hci0 hci_usb_send_ctrl: hci0 skb da07f680 len 4 __tx_submit: hci0 urb d8fd3c14 type 1 hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0 hci_usb_tx_process: hci0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 6 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 6 __recv_frame: new packet len 6 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_send_frame: hci0 type 1 len 3 hci_usb_tx_process: hci0 hci_usb_send_ctrl: hci0 skb de339380 len 3 __tx_submit: hci0 urb d8fd3c14 type 1 hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0 hci_usb_tx_process: hci0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 __recv_frame: new packet len 254 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 16 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 16 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 14 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 14 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_send_frame: hci0 type 1 len 3 hci_usb_tx_process: hci0 hci_usb_send_ctrl: hci0 skb d51d8080 len 3 __tx_submit: hci0 urb d8fd3c14 type 1 hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0 hci_usb_tx_process: hci0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 9 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 9 __recv_frame: new packet len 9 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 hci_usb_send_frame: hci0 type 1 len 3 hci_usb_tx_process: hci0 hci_usb_send_ctrl: hci0 skb de339a80 len 3 __tx_submit: hci0 urb d8fd3c14 type 1 hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0 hci_usb_tx_process: hci0 hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 14 flags 0 __recv_frame: hci0 type 4 data da088dc0 count 14 __recv_frame: new packet len 14 hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 Hope you can make something out of it. /Andreas ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-05 12:07 ` Andreas Sundstrom @ 2003-11-05 12:18 ` Marcel Holtmann 2003-11-05 12:54 ` Andreas Sundstrom 2003-11-05 13:49 ` Andreas Sundstrom 0 siblings, 2 replies; 21+ messages in thread From: Marcel Holtmann @ 2003-11-05 12:18 UTC (permalink / raw) To: Andreas Sundstrom; +Cc: BlueZ Mailing List Hi Andreas, > > from the devices output I see that this device is based on a Silicon > > Wave chip and it seems that I don't have this device in my list. So what > > kind of model do you have and what is the output of "hciconfig -a". > hci0: Type: USB > BD Address: 00:03:7A:08:13:91 ACL MTU: 60:20 SCO MTU: 64:0 > UP RUNNING PSCAN ISCAN > RX bytes:63 acl:0 sco:0 events:7 errors:0 > TX bytes:28 acl:0 sco:0 commands:7 errors:0 > Features: 0xff 0x02 0x04 0x00 > Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 > Link policy: > Link mode: SLAVE ACCEPT > Name: '' > Class: 0x000000 > Service Classes: Unspecified > Device Class: Miscellaneous, > HCI Ver: 1.1 (0x1) HCI Rev: 0x0 LMP Ver: 1.1 (0x1) LMP Subver: > 0x514 > Manufacturer: Silicon Wave (11) and what is the model of your notebook? > > This is a question for the USB guys. Do you have another USB Bluetooth > > dongle to test with your notebook? > I inserted a MS Wireless Transceiver for Bluetooth and it gave the same > error.. but seems to work alright. Havn't done much testing yet though. Please test this. If the Microsoft is working all the time then your problem is part of the Silicon Wave chip or some else in the internal USB stuff of your notebook. However it works in 2.4 this must be some kind of problem in the Linux USB subsystem which only effects this kind of device. > Here's the output from a "bad" session: > > This is what I'v run: > > //inserts the device into the USB hub > # echo blue_on:1 > /proc/acpi/toshiba/bluetooth Where is this documented? > Here's the dmesg output: > hub 4-0:1.0: new USB device on port 1, assigned address 2 > hci_usb_probe: udev d8436c00 ifnum -1069408960 > hci_usb_probe: udev d8436c00 ifnum -1069408960 > hci_usb: probe of 4-1:1.1 failed with error -5 > hci_usb_open: hci0 > hci_usb_intr_rx_submit: hci0 > hci_usb_bulk_rx_submit: hci0 urb d947f694 > hci_usb_send_frame: hci0 type 1 len 3 > hci_usb_tx_process: hci0 > hci_usb_send_ctrl: hci0 skb da07f880 len 3 > __tx_submit: hci0 urb d8fd3c14 type 1 > hci_usb_tx_complete: hci0 urb d8fd3c14 status 0 flags 0 > hci_usb_tx_process: hci0 > hci_usb_rx_complete: hci0 urb d947f614 type 4 status 0 count 14 flags 0 > __recv_frame: hci0 type 4 data da088dc0 count 14 > __recv_frame: new packet len 14 > hci_usb_rx_complete: hci0 urb d947f614 type 4 resubmit status 0 The resubmit means that the previous URB fails and this is causing the problems. But at the moment I have no idea how to track this in detail. Regards Marcel ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-05 12:18 ` Marcel Holtmann @ 2003-11-05 12:54 ` Andreas Sundstrom 2003-11-05 14:15 ` Marcel Holtmann 2003-11-05 13:49 ` Andreas Sundstrom 1 sibling, 1 reply; 21+ messages in thread From: Andreas Sundstrom @ 2003-11-05 12:54 UTC (permalink / raw) To: BlueZ Mailing List Marcel Holtmann wrote: > and what is the model of your notebook? Toshiba Satellite S5200-801 >>I inserted a MS Wireless Transceiver for Bluetooth and it gave the same >>error.. but seems to work alright. Havn't done much testing yet though. > > > Please test this. If the Microsoft is working all the time then your > problem is part of the Silicon Wave chip or some else in the internal > USB stuff of your notebook. However it works in 2.4 this must be some > kind of problem in the Linux USB subsystem which only effects this kind > of device. I will do some testing of this and report back if it works all the time or if it has the same intermittend problems as my internal USB device. >>This is what I'v run: >> >>//inserts the device into the USB hub >># echo blue_on:1 > /proc/acpi/toshiba/bluetooth > > > Where is this documented? Apparently many notebooks (atleast many toshiba's) have devices that can be plugged in and out via software. The USB BT dongle in my notebook is one of these.. There's a button on the side of the notebook that can be used to be sure that the device is off (like in an airplane). I found a patch for linux/driver/acpi/toshiba_acpi.c on this site: http://nicolas.bettenburg.free.fr/linux/#c4 I hade to fiddle alot with it to make it work with 2.4.22 (I guess he has not written it against a recent kernel). I came up with a patch that worked ok with 2.4.22, and to my surprice it worked fine with 2.6.0 too. My guess is that the ACPI stuff has been backported into 2.4.22 and that's why it's almost the same.. I put the patch I use here so you can look if you want: ftp://zappa.cx/pub/echinacea/toshiba_bluetooth.patch It currently doesn't apply cleanly on 2.6.0-test9 but not important stuff just comments doesn't apply. I would be glad if this is the problem (though I think it's not since I guess it's only job is to logically insert the USB dongle). I'm no programmer so I might have done a poor conversion so it won't hurt to check. > The resubmit means that the previous URB fails and this is causing the > problems. But at the moment I have no idea how to track this in detail. Will it help if I attach a session when it works to see if it's any different? ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-05 12:54 ` Andreas Sundstrom @ 2003-11-05 14:15 ` Marcel Holtmann 2003-11-05 14:33 ` Andreas Sundstrom 0 siblings, 1 reply; 21+ messages in thread From: Marcel Holtmann @ 2003-11-05 14:15 UTC (permalink / raw) To: Andreas Sundstrom; +Cc: BlueZ Mailing List Hi Andreas, > >>This is what I'v run: > >> > >>//inserts the device into the USB hub > >># echo blue_on:1 > /proc/acpi/toshiba/bluetooth > > > > > > Where is this documented? > Apparently many notebooks (atleast many toshiba's) have devices that can > be plugged in and out via software. The USB BT dongle in my notebook is > one of these.. There's a button on the side of the notebook that can be > used to be sure that the device is off (like in an airplane). > I found a patch for linux/driver/acpi/toshiba_acpi.c on this site: > > http://nicolas.bettenburg.free.fr/linux/#c4 > > I hade to fiddle alot with it to make it work with 2.4.22 (I guess he > has not written it against a recent kernel). I came up with a patch that > worked ok with 2.4.22, and to my surprice it worked fine with 2.6.0 too. > > My guess is that the ACPI stuff has been backported into 2.4.22 and > that's why it's almost the same.. I put the patch I use here so you can > look if you want: ftp://zappa.cx/pub/echinacea/toshiba_bluetooth.patch > It currently doesn't apply cleanly on 2.6.0-test9 but not important > stuff just comments doesn't apply. this should be included in the mainstream kernel source, but the code must be a little bit cleaned up. I will check this later and send you a patch for testing. After that I'll forward it to the maintainer. Regards Marcel ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-05 14:15 ` Marcel Holtmann @ 2003-11-05 14:33 ` Andreas Sundstrom 2003-11-06 23:48 ` Marcel Holtmann 0 siblings, 1 reply; 21+ messages in thread From: Andreas Sundstrom @ 2003-11-05 14:33 UTC (permalink / raw) To: BlueZ Mailing List Marcel Holtmann wrote: > Hi Andreas, > > >>>>This is what I'v run: >>>> >>>>//inserts the device into the USB hub >>>># echo blue_on:1 > /proc/acpi/toshiba/bluetooth >>> >>> >>>Where is this documented? >> >>Apparently many notebooks (atleast many toshiba's) have devices that can >>be plugged in and out via software. The USB BT dongle in my notebook is >>one of these.. There's a button on the side of the notebook that can be >>used to be sure that the device is off (like in an airplane). >>I found a patch for linux/driver/acpi/toshiba_acpi.c on this site: >> >>http://nicolas.bettenburg.free.fr/linux/#c4 >> >>I hade to fiddle alot with it to make it work with 2.4.22 (I guess he >>has not written it against a recent kernel). I came up with a patch that >>worked ok with 2.4.22, and to my surprice it worked fine with 2.6.0 too. >> >>My guess is that the ACPI stuff has been backported into 2.4.22 and >>that's why it's almost the same.. I put the patch I use here so you can >>look if you want: ftp://zappa.cx/pub/echinacea/toshiba_bluetooth.patch >>It currently doesn't apply cleanly on 2.6.0-test9 but not important >>stuff just comments doesn't apply. > > > this should be included in the mainstream kernel source, but the code > must be a little bit cleaned up. I will check this later and send you a > patch for testing. After that I'll forward it to the maintainer. > I'll appreciate that, just let me know when you have gone over it and I'll check that it works as expected. > Regards > > Marcel > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-05 14:33 ` Andreas Sundstrom @ 2003-11-06 23:48 ` Marcel Holtmann 2003-11-07 10:04 ` Andreas Sundstrom 0 siblings, 1 reply; 21+ messages in thread From: Marcel Holtmann @ 2003-11-06 23:48 UTC (permalink / raw) To: Andreas Sundstrom; +Cc: BlueZ Mailing List [-- Attachment #1: Type: text/plain, Size: 590 bytes --] Hi Andreas, > > this should be included in the mainstream kernel source, but the code > > must be a little bit cleaned up. I will check this later and send you a > > patch for testing. After that I'll forward it to the maintainer. > > > I'll appreciate that, just let me know when you have gone over it and > I'll check that it works as expected. here is my patch for it. I changed some stuff and left some stupid things out. It is now switched on/off with "bluetooth:1"/"bluetooth:0" and please check that I don't break the other stuff like fan or screen brightness. Regards Marcel [-- Attachment #2: patch-toshiba-acpi-bluetooth --] [-- Type: text/plain, Size: 6027 bytes --] ===== drivers/acpi/toshiba_acpi.c 1.6 vs edited ===== --- 1.6/drivers/acpi/toshiba_acpi.c Thu Aug 21 16:39:06 2003 +++ edited/drivers/acpi/toshiba_acpi.c Thu Nov 6 16:05:26 2003 @@ -82,6 +82,7 @@ #define HCI_VIDEO_OUT 0x001c #define HCI_HOTKEY_EVENT 0x001e #define HCI_LCD_BRIGHTNESS 0x002a +#define HCI_BLUETOOTH 0x0056 /* field definitions */ #define HCI_LCD_BRIGHTNESS_BITS 3 @@ -90,6 +91,9 @@ #define HCI_VIDEO_OUT_LCD 0x1 #define HCI_VIDEO_OUT_CRT 0x2 #define HCI_VIDEO_OUT_TV 0x4 +#define HCI_BLUETOOTH_ACTIVATE 0x0080 +#define HCI_BLUETOOTH_ATTACH 0x0040 +#define HCI_BLUETOOTH_DX 0x0001 /* utility */ @@ -196,9 +200,9 @@ */ static acpi_status -hci_write1(u32 reg, u32 in1, u32* result) +hci_write1(u32 reg, u32 in1, u32 in2, u32* result) { - u32 in[HCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 }; + u32 in[HCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 }; u32 out[HCI_WORDS]; acpi_status status = hci_raw(in, out); *result = (status == AE_OK) ? out[0] : HCI_FAILURE; @@ -206,9 +210,9 @@ } static acpi_status -hci_read1(u32 reg, u32* out1, u32* result) +hci_read1(u32 reg, u32* out1, u32 in2, u32* result) { - u32 in[HCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 }; + u32 in[HCI_WORDS] = { HCI_GET, reg, 0, in2, 0, 0 }; u32 out[HCI_WORDS]; acpi_status status = hci_raw(in, out); *out1 = out[2]; @@ -264,7 +268,7 @@ u32 hci_result; u32 value; - hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result); + hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { value = value >> HCI_LCD_BRIGHTNESS_SHIFT; p += sprintf(p, "brightness: %d\n", value); @@ -286,7 +290,7 @@ if (snscanf(buffer, count, " brightness : %i", &value) == 1 && value >= 0 && value < HCI_LCD_BRIGHTNESS_LEVELS) { value = value << HCI_LCD_BRIGHTNESS_SHIFT; - hci_write1(HCI_LCD_BRIGHTNESS, value, &hci_result); + hci_write1(HCI_LCD_BRIGHTNESS, value, 0, &hci_result); if (hci_result != HCI_SUCCESS) return -EFAULT; } else { @@ -302,7 +306,7 @@ u32 hci_result; u32 value; - hci_read1(HCI_VIDEO_OUT, &value, &hci_result); + hci_read1(HCI_VIDEO_OUT, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { int is_lcd = (value & HCI_VIDEO_OUT_LCD) ? 1 : 0; int is_crt = (value & HCI_VIDEO_OUT_CRT) ? 1 : 0; @@ -341,7 +345,7 @@ while ((buffer < buffer_end) && (*(buffer-1) != ';')); } while (buffer < buffer_end); - hci_read1(HCI_VIDEO_OUT, &video_out, &hci_result); + hci_read1(HCI_VIDEO_OUT, &video_out, 0, &hci_result); if (hci_result == HCI_SUCCESS) { int new_video_out = video_out; if (lcd_out != -1) @@ -365,7 +369,7 @@ u32 hci_result; u32 value; - hci_read1(HCI_FAN, &value, &hci_result); + hci_read1(HCI_FAN, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { p += sprintf(p, "running: %d\n", (value > 0)); p += sprintf(p, "force_on: %d\n", force_fan); @@ -384,7 +388,7 @@ if (snscanf(buffer, count, " force_on : %i", &value) == 1 && value >= 0 && value <= 1) { - hci_write1(HCI_FAN, value, &hci_result); + hci_write1(HCI_FAN, value, 0, &hci_result); if (hci_result != HCI_SUCCESS) return -EFAULT; else @@ -403,7 +407,7 @@ u32 value; if (!key_event_valid) { - hci_read1(HCI_SYSTEM_EVENT, &value, &hci_result); + hci_read1(HCI_SYSTEM_EVENT, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { key_event_valid = 1; last_key_event = value; @@ -413,7 +417,7 @@ /* This is a workaround for an unresolved issue on * some machines where system events sporadically * become disabled. */ - hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result); + hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result); } else { p += sprintf(p, "ERROR\n"); goto end; @@ -451,6 +455,57 @@ return p; } +static char* +read_bluetooth(char *p) +{ + u32 hci_result; + u32 value; + + hci_read1(HCI_BLUETOOTH, &value, 0, &hci_result); + if (hci_result == HCI_SUCCESS) { + p += sprintf(p, "bluetooth_available: %d\n", value); + } else { + p += sprintf(p, "ERROR\n"); + goto end; + } + + hci_read1(HCI_BLUETOOTH, &value, HCI_BLUETOOTH_DX, &hci_result); + if (hci_result == HCI_SUCCESS) { + p += sprintf(p, "wireless_switch: %d\n", value); + } else { + p += sprintf(p, "ERROR\n"); + } + +end: + return p; +} + +static unsigned long +write_bluetooth(const char* buffer, unsigned long count) +{ + int value; + u32 hci_result; + + if (snscanf(buffer, count, " bluetooth : %i", &value) == 1 && + value >= 0 && value <= 1) { + hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ACTIVATE, &hci_result); + if (hci_result != HCI_SUCCESS) + return -EFAULT; + + hci_write1(0, 0, 0, &hci_result); + + hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ATTACH, &hci_result); + if (hci_result != HCI_SUCCESS); + return -EFAULT; + + hci_write1(0, 0, 0, &hci_result); + } else { + return -EINVAL; + } + + return count; +} + /* proc and module init */ @@ -458,12 +513,13 @@ ProcItem proc_items[] = { - { "lcd" , read_lcd , write_lcd }, - { "video" , read_video , write_video }, - { "fan" , read_fan , write_fan }, - { "keys" , read_keys , write_keys }, - { "version" , read_version , 0 }, - { 0 , 0 , 0 }, + { "lcd", read_lcd, write_lcd }, + { "video", read_video, write_video }, + { "fan", read_fan, write_fan }, + { "keys", read_keys, write_keys }, + { "version", read_version, 0 }, + { "bluetooth", read_bluetooth, write_bluetooth }, + { 0, 0, 0 }, }; static acpi_status @@ -502,7 +558,7 @@ u32 hci_result; /* simple device detection: try reading an HCI register */ - hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result); + hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result); if (hci_result != HCI_SUCCESS) return -ENODEV; @@ -512,7 +568,7 @@ key_event_valid = 0; /* enable event fifo */ - hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result); + hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result); toshiba_proc_dir = proc_mkdir(PROC_TOSHIBA, acpi_root_dir); if (!toshiba_proc_dir) { ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-06 23:48 ` Marcel Holtmann @ 2003-11-07 10:04 ` Andreas Sundstrom 2003-11-07 11:25 ` Marcel Holtmann 0 siblings, 1 reply; 21+ messages in thread From: Andreas Sundstrom @ 2003-11-07 10:04 UTC (permalink / raw) To: BlueZ Mailing List [-- Attachment #1: Type: text/plain, Size: 2471 bytes --] Marcel Holtmann wrote: > Hi Andreas, > > >>>this should be included in the mainstream kernel source, but the code >>>must be a little bit cleaned up. I will check this later and send you a >>>patch for testing. After that I'll forward it to the maintainer. >>> >> >>I'll appreciate that, just let me know when you have gone over it and >>I'll check that it works as expected. > > > here is my patch for it. I changed some stuff and left some stupid > things out. It is now switched on/off with "bluetooth:1"/"bluetooth:0" > and please check that I don't break the other stuff like fan or screen > brightness. Ok, first of all I want to say that it works ok for me. I have tried everything except the "keys" proc entry. However, I would like to change the behaviour a bit, to behave more like the other proc entries and more like it was before your rework. First I'd like a user friendly way of finding out if BT is really enabled, and second I think you should be able to guess what to "echo" into the proc entry. To enable fan running all the time you use, "echo force_on:1 > fan" lcd brightness is set through "echo brightness:1 > lcd" The output from "cat fan lcd" is: brightness: 6 brightness_levels: 8 running: 0 force_on: 0 Which means that when you have learnd how they function you should be able to guess what to do with the bluetooth entry if it for example looked like this: #cat bluetooth bluetooth_available: 15 wireless_switch: 512 bluetooth_on: 0 I have here changed the parameter to echo into "bluetooth" from bluetooth to bluetooth_on, and added an entry that shows the status of it. This makes it easy to guess that "echo bluetooth_on:1 > bluetooth" should enable the device if you know how the other entris work. Without this you want be able to guess that "bluetooth:1/0" is used for enabling/disabling the device. I have attached two patches, one is against "stock" 2.6.0-test9 and the other is against your previous version on a patched 2.6.0-test9 I had to do some trial and error guessing the value 576, I don't understand why it changed from 512 as it was in the patch I used earlier. Maybe you understand and maybe it all should be done totally different, but you should be able to understand what I want to do and implement it in a prettier way if thats needed. Please look at this and give me some feedback on your thoughts about it. /Andreas [-- Attachment #2: patch-2.6.0-test9-toshiba-acpi-bt-mh.patch --] [-- Type: text/plain, Size: 994 bytes --] --- tmp/linux-2.6.0-test9-mh/drivers/acpi/toshiba_acpi.c 2003-11-07 10:38:39.971763024 +0100 +++ linux-2.6.0-test9/drivers/acpi/toshiba_acpi.c 2003-11-07 10:07:39.629578024 +0100 @@ -469,8 +469,12 @@ } hci_read1(HCI_BLUETOOTH, &value, HCI_BLUETOOTH_DX, &hci_result); - if (hci_result == HCI_SUCCESS) { + if (hci_result == HCI_SUCCESS && value > 576) { p += sprintf(p, "wireless_switch: %d\n", value); + p += sprintf(p, "bluetooth_on: 1\n"); + } else if (hci_result == HCI_SUCCESS) { + p += sprintf(p, "wireless_switch: %d\n", value); + p += sprintf(p, "bluetooth_on: 0\n"); } else { p += sprintf(p, "ERROR\n"); } @@ -485,7 +489,7 @@ int value; u32 hci_result; - if (snscanf(buffer, count, " bluetooth : %i", &value) == 1 && + if (snscanf(buffer, count, " bluetooth_on : %i", &value) == 1 && value >= 0 && value <= 1) { hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ACTIVATE, &hci_result); if (hci_result != HCI_SUCCESS) [-- Attachment #3: patch-2.6.0-test9-toshiba-acpi-bt-stock.patch --] [-- Type: text/plain, Size: 6254 bytes --] --- tmp/linux-2.6.0-test9-stock/drivers/acpi/toshiba_acpi.c 2003-10-25 20:42:52.000000000 +0200 +++ linux-2.6.0-test9/drivers/acpi/toshiba_acpi.c 2003-11-07 10:07:39.629578024 +0100 @@ -81,6 +81,7 @@ #define HCI_VIDEO_OUT 0x001c #define HCI_HOTKEY_EVENT 0x001e #define HCI_LCD_BRIGHTNESS 0x002a +#define HCI_BLUETOOTH 0x0056 /* field definitions */ #define HCI_LCD_BRIGHTNESS_BITS 3 @@ -89,6 +90,9 @@ #define HCI_VIDEO_OUT_LCD 0x1 #define HCI_VIDEO_OUT_CRT 0x2 #define HCI_VIDEO_OUT_TV 0x4 +#define HCI_BLUETOOTH_ACTIVATE 0x0080 +#define HCI_BLUETOOTH_ATTACH 0x0040 +#define HCI_BLUETOOTH_DX 0x0001 /* utility */ @@ -195,9 +199,9 @@ */ static acpi_status -hci_write1(u32 reg, u32 in1, u32* result) +hci_write1(u32 reg, u32 in1, u32 in2, u32* result) { - u32 in[HCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 }; + u32 in[HCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 }; u32 out[HCI_WORDS]; acpi_status status = hci_raw(in, out); *result = (status == AE_OK) ? out[0] : HCI_FAILURE; @@ -205,9 +209,9 @@ } static acpi_status -hci_read1(u32 reg, u32* out1, u32* result) +hci_read1(u32 reg, u32* out1, u32 in2, u32* result) { - u32 in[HCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 }; + u32 in[HCI_WORDS] = { HCI_GET, reg, 0, in2, 0, 0 }; u32 out[HCI_WORDS]; acpi_status status = hci_raw(in, out); *out1 = out[2]; @@ -263,7 +267,7 @@ u32 hci_result; u32 value; - hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result); + hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { value = value >> HCI_LCD_BRIGHTNESS_SHIFT; p += sprintf(p, "brightness: %d\n", value); @@ -285,7 +289,7 @@ if (snscanf(buffer, count, " brightness : %i", &value) == 1 && value >= 0 && value < HCI_LCD_BRIGHTNESS_LEVELS) { value = value << HCI_LCD_BRIGHTNESS_SHIFT; - hci_write1(HCI_LCD_BRIGHTNESS, value, &hci_result); + hci_write1(HCI_LCD_BRIGHTNESS, value, 0, &hci_result); if (hci_result != HCI_SUCCESS) return -EFAULT; } else { @@ -301,7 +305,7 @@ u32 hci_result; u32 value; - hci_read1(HCI_VIDEO_OUT, &value, &hci_result); + hci_read1(HCI_VIDEO_OUT, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { int is_lcd = (value & HCI_VIDEO_OUT_LCD) ? 1 : 0; int is_crt = (value & HCI_VIDEO_OUT_CRT) ? 1 : 0; @@ -340,7 +344,7 @@ while ((buffer < buffer_end) && (*(buffer-1) != ';')); } while (buffer < buffer_end); - hci_read1(HCI_VIDEO_OUT, &video_out, &hci_result); + hci_read1(HCI_VIDEO_OUT, &video_out, 0, &hci_result); if (hci_result == HCI_SUCCESS) { int new_video_out = video_out; if (lcd_out != -1) @@ -364,7 +368,7 @@ u32 hci_result; u32 value; - hci_read1(HCI_FAN, &value, &hci_result); + hci_read1(HCI_FAN, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { p += sprintf(p, "running: %d\n", (value > 0)); p += sprintf(p, "force_on: %d\n", force_fan); @@ -383,7 +387,7 @@ if (snscanf(buffer, count, " force_on : %i", &value) == 1 && value >= 0 && value <= 1) { - hci_write1(HCI_FAN, value, &hci_result); + hci_write1(HCI_FAN, value, 0, &hci_result); if (hci_result != HCI_SUCCESS) return -EFAULT; else @@ -402,7 +406,7 @@ u32 value; if (!key_event_valid) { - hci_read1(HCI_SYSTEM_EVENT, &value, &hci_result); + hci_read1(HCI_SYSTEM_EVENT, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { key_event_valid = 1; last_key_event = value; @@ -412,7 +416,7 @@ /* This is a workaround for an unresolved issue on * some machines where system events sporadically * become disabled. */ - hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result); + hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result); } else { p += sprintf(p, "ERROR\n"); goto end; @@ -450,6 +454,61 @@ return p; } +static char* +read_bluetooth(char *p) +{ + u32 hci_result; + u32 value; + + hci_read1(HCI_BLUETOOTH, &value, 0, &hci_result); + if (hci_result == HCI_SUCCESS) { + p += sprintf(p, "bluetooth_available: %d\n", value); + } else { + p += sprintf(p, "ERROR\n"); + goto end; + } + + hci_read1(HCI_BLUETOOTH, &value, HCI_BLUETOOTH_DX, &hci_result); + if (hci_result == HCI_SUCCESS && value > 576) { + p += sprintf(p, "wireless_switch: %d\n", value); + p += sprintf(p, "bluetooth_on: 1\n"); + } else if (hci_result == HCI_SUCCESS) { + p += sprintf(p, "wireless_switch: %d\n", value); + p += sprintf(p, "bluetooth_on: 0\n"); + } else { + p += sprintf(p, "ERROR\n"); + } + +end: + return p; +} + +static unsigned long +write_bluetooth(const char* buffer, unsigned long count) +{ + int value; + u32 hci_result; + + if (snscanf(buffer, count, " bluetooth_on : %i", &value) == 1 && + value >= 0 && value <= 1) { + hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ACTIVATE, &hci_result); + if (hci_result != HCI_SUCCESS) + return -EFAULT; + + hci_write1(0, 0, 0, &hci_result); + + hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ATTACH, &hci_result); + if (hci_result != HCI_SUCCESS); + return -EFAULT; + + hci_write1(0, 0, 0, &hci_result); + } else { + return -EINVAL; + } + + return count; +} + /* proc and module init */ @@ -457,12 +516,13 @@ ProcItem proc_items[] = { - { "lcd" , read_lcd , write_lcd }, - { "video" , read_video , write_video }, - { "fan" , read_fan , write_fan }, - { "keys" , read_keys , write_keys }, - { "version" , read_version , 0 }, - { 0 , 0 , 0 }, + { "lcd", read_lcd, write_lcd }, + { "video", read_video, write_video }, + { "fan", read_fan, write_fan }, + { "keys", read_keys, write_keys }, + { "version", read_version, 0 }, + { "bluetooth", read_bluetooth, write_bluetooth }, + { 0, 0, 0 }, }; static acpi_status @@ -501,7 +561,7 @@ u32 hci_result; /* simple device detection: try reading an HCI register */ - hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result); + hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result); if (hci_result != HCI_SUCCESS) return -ENODEV; @@ -511,7 +571,7 @@ key_event_valid = 0; /* enable event fifo */ - hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result); + hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result); toshiba_proc_dir = proc_mkdir(PROC_TOSHIBA, acpi_root_dir); if (!toshiba_proc_dir) { ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-07 10:04 ` Andreas Sundstrom @ 2003-11-07 11:25 ` Marcel Holtmann 2003-11-07 11:34 ` Andreas Sundstrom 0 siblings, 1 reply; 21+ messages in thread From: Marcel Holtmann @ 2003-11-07 11:25 UTC (permalink / raw) To: Andreas Sundstrom; +Cc: BlueZ Mailing List Hi Andreas, > Ok, first of all I want to say that it works ok for me. I have tried > everything except the "keys" proc entry. this is good to hear, so I don't break anything else ;) > Which means that when you have learnd how they function you should be > able to guess what to do with the bluetooth entry if it for example > looked like this: > #cat bluetooth > bluetooth_available: 15 > wireless_switch: 512 > bluetooth_on: 0 > > I have here changed the parameter to echo into "bluetooth" from > bluetooth to bluetooth_on, and added an entry that shows the status of > it. This makes it easy to guess that "echo bluetooth_on:1 > bluetooth" > should enable the device if you know how the other entris work. > Without this you want be able to guess that "bluetooth:1/0" is used > for enabling/disabling the device. The problem here are the information about these values. Try to play a little bit with the switch on your notebook and get the values of the wireless_switch and bluetooth_available registers for Bluetooth on/off and Wirless LAN on/off. Maybe this register could also be used to switch the Wireless LAN card on/off and so I tend to rename the complete proc entry to wireless and redo some parts of the patch. Regards Marcel ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-07 11:25 ` Marcel Holtmann @ 2003-11-07 11:34 ` Andreas Sundstrom 2003-11-07 11:41 ` Marcel Holtmann 0 siblings, 1 reply; 21+ messages in thread From: Andreas Sundstrom @ 2003-11-07 11:34 UTC (permalink / raw) To: BlueZ Mailing List Marcel Holtmann wrote: > The problem here are the information about these values. Try to play a > little bit with the switch on your notebook and get the values of the > wireless_switch and bluetooth_available registers for Bluetooth on/off > and Wirless LAN on/off. > > Maybe this register could also be used to switch the Wireless LAN card > on/off and so I tend to rename the complete proc entry to wireless and > redo some parts of the patch. I played with it in all possible ways on my notebook and the highest value I saw without bluetooth getting enabled was 576, and that was when I tried to enable bluetooth without first flipping the switch on the side of the notebook. It looks like this with my changes from my last mail apllied. This is done with the switch on the notebook in the "Off" position. root@swe248:/proc/acpi/toshiba# cat bluetooth ; echo "bluetooth_on:1" > bluetooth ; cat bluetooth bluetooth_available: 15 wireless_switch: 512 bluetooth_on: 0 bluetooth_available: 15 wireless_switch: 576 bluetooth_on: 0 I'm afraid I don't have a 802.b module in my computer, it's an option and currently I'm using BT as a cheap alternative :) Maybe someonelse on the list have access to a Toshiba with wlan card in it? /Andreas ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-07 11:34 ` Andreas Sundstrom @ 2003-11-07 11:41 ` Marcel Holtmann 2003-11-07 12:00 ` Andreas Sundstrom 0 siblings, 1 reply; 21+ messages in thread From: Marcel Holtmann @ 2003-11-07 11:41 UTC (permalink / raw) To: Andreas Sundstrom; +Cc: BlueZ Mailing List Hi Andreas, > It looks like this with my changes from my last mail apllied. > This is done with the switch on the notebook in the "Off" position. and how do it look with the switch in "On" position? > I'm afraid I don't have a 802.b module in my computer, it's an option > and currently I'm using BT as a cheap alternative :) > > Maybe someonelse on the list have access to a Toshiba with wlan card in it? I really need this information :( Regards Marcel ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-07 11:41 ` Marcel Holtmann @ 2003-11-07 12:00 ` Andreas Sundstrom 2003-11-07 12:12 ` Marcel Holtmann 0 siblings, 1 reply; 21+ messages in thread From: Andreas Sundstrom @ 2003-11-07 12:00 UTC (permalink / raw) To: BlueZ Mailing List Marcel Holtmann wrote: > Hi Andreas, > > >>It looks like this with my changes from my last mail apllied. >>This is done with the switch on the notebook in the "Off" position. > > > and how do it look with the switch in "On" position? This is when I have successfully enabled bluetooth and USB has noticed that the dongle has been plugged in. root@swe248:/proc/acpi/toshiba# cat bluetooth bluetooth_available: 15 wireless_switch: 705 bluetooth_on: 1 By accident I noticed that when I changed the switched from Off to On it went up to 577 so I that is now the highest number I've seen without the bluetooth dongle actually working. Since I'm not used to "research" these kind of things I might not be doing it the most efficient way, if you suggest that I shall try things in a specific order and document it I can do it for you.. > >>I'm afraid I don't have a 802.b module in my computer, it's an option >>and currently I'm using BT as a cheap alternative :) >> >>Maybe someonelse on the list have access to a Toshiba with wlan card in it? > > > I really need this information :( I hope that someone will notice this thread and fill in the blanks for this.. The topic/subject is not the best though.. /Andreas ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-07 12:00 ` Andreas Sundstrom @ 2003-11-07 12:12 ` Marcel Holtmann 2003-11-07 13:22 ` Andreas Sundstrom ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Marcel Holtmann @ 2003-11-07 12:12 UTC (permalink / raw) To: Andreas Sundstrom; +Cc: BlueZ Mailing List Hi Andreas, > This is when I have successfully enabled bluetooth and USB has noticed > that the dongle has been plugged in. > > root@swe248:/proc/acpi/toshiba# cat bluetooth > bluetooth_available: 15 > wireless_switch: 705 > bluetooth_on: 1 > > By accident I noticed that when I changed the switched from Off to On it > went up to 577 so I that is now the highest number I've seen without the > bluetooth dongle actually working. don't think of highest number. You should start thinking in which bit is set and which is not. It seems that the bluetooth_available register will always be 15 and can be ignored at this point. The important part is the value of wireless_switch. It seems that we have some variables to fill in. The hardware switch on/off Bluetooth activated/deactivated through software Bluetooth dongle found/disabled by USB subsystem So you should make a table with all possible combinations and fill in the values (in hex) for it. This is what I need to see which bit gets toggled and which not. Regards Marcel ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-07 12:12 ` Marcel Holtmann @ 2003-11-07 13:22 ` Andreas Sundstrom 2003-11-07 15:27 ` Andreas Sundstrom 2003-11-07 18:50 ` Andreas Sundstrom 2 siblings, 0 replies; 21+ messages in thread From: Andreas Sundstrom @ 2003-11-07 13:22 UTC (permalink / raw) To: BlueZ Mailing List Marcel Holtmann wrote: > Hi Andreas, > > >>This is when I have successfully enabled bluetooth and USB has noticed >>that the dongle has been plugged in. >> >>root@swe248:/proc/acpi/toshiba# cat bluetooth >>bluetooth_available: 15 >>wireless_switch: 705 >>bluetooth_on: 1 >> >>By accident I noticed that when I changed the switched from Off to On it >>went up to 577 so I that is now the highest number I've seen without the >>bluetooth dongle actually working. > > > don't think of highest number. You should start thinking in which bit is > set and which is not. It seems that the bluetooth_available register > will always be 15 and can be ignored at this point. The important part > is the value of wireless_switch. > > It seems that we have some variables to fill in. > > The hardware switch on/off > Bluetooth activated/deactivated through software > Bluetooth dongle found/disabled by USB subsystem > > So you should make a table with all possible combinations and fill in > the values (in hex) for it. This is what I need to see which bit gets > toggled and which not. Now I've done some testing, and with hex numbers it seems to clarify a bit. When the notebook is freshly booted I get the following values: sw-off: 0x200 sw-on: 0x201 After I have sent a bluetooth_on:1 the values changes to: sw-off: 0x240 sw-on: 0x241 When the switch is on and bluetooth is enabled (plugged in): sw-on bt-on: 0x2c1 If I then move the switch back to off it goes back to 0x240 This is essentially the same numbers as earlier but in hex form, but it seems to me that the first bit is responsible for reporting if the switch is on or off. If I convert it to binary I get the following: sw-off bt-off 1000000000 1001000000 sw-on bt-off 1000000001 1001000001 sw-on bt-on 1011000001 I'm not sure if I answered all your (three) questions, if not.. please explain a bit further beacause then I didn't understand it. /Andreas ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-07 12:12 ` Marcel Holtmann 2003-11-07 13:22 ` Andreas Sundstrom @ 2003-11-07 15:27 ` Andreas Sundstrom 2003-11-07 18:50 ` Andreas Sundstrom 2 siblings, 0 replies; 21+ messages in thread From: Andreas Sundstrom @ 2003-11-07 15:27 UTC (permalink / raw) To: BlueZ Mailing List [-- Attachment #1: Type: text/plain, Size: 399 bytes --] Marcel Holtmann wrote: > So you should make a table with all possible combinations and fill in > the values (in hex) for it. This is what I need to see which bit gets > toggled and which not. I think you will like this patch. I hope the registers is the same for all Toshiba notebooks, but that can probably not be assured before it is implemented in stock kernel so users will test it. /Andreas [-- Attachment #2: patch-2.6.0-test9-toshiba-acpi-bt-stock.patch --] [-- Type: text/plain, Size: 6112 bytes --] --- tmp/linux-2.6.0-test9-stock/drivers/acpi/toshiba_acpi.c 2003-10-25 20:42:52.000000000 +0200 +++ linux-2.6.0-test9/drivers/acpi/toshiba_acpi.c 2003-11-07 16:21:39.174442800 +0100 @@ -81,6 +81,7 @@ #define HCI_VIDEO_OUT 0x001c #define HCI_HOTKEY_EVENT 0x001e #define HCI_LCD_BRIGHTNESS 0x002a +#define HCI_BLUETOOTH 0x0056 /* field definitions */ #define HCI_LCD_BRIGHTNESS_BITS 3 @@ -89,6 +90,9 @@ #define HCI_VIDEO_OUT_LCD 0x1 #define HCI_VIDEO_OUT_CRT 0x2 #define HCI_VIDEO_OUT_TV 0x4 +#define HCI_BLUETOOTH_ACTIVATE 0x0080 +#define HCI_BLUETOOTH_ATTACH 0x0040 +#define HCI_BLUETOOTH_DX 0x0001 /* utility */ @@ -195,9 +199,9 @@ */ static acpi_status -hci_write1(u32 reg, u32 in1, u32* result) +hci_write1(u32 reg, u32 in1, u32 in2, u32* result) { - u32 in[HCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 }; + u32 in[HCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 }; u32 out[HCI_WORDS]; acpi_status status = hci_raw(in, out); *result = (status == AE_OK) ? out[0] : HCI_FAILURE; @@ -205,9 +209,9 @@ } static acpi_status -hci_read1(u32 reg, u32* out1, u32* result) +hci_read1(u32 reg, u32* out1, u32 in2, u32* result) { - u32 in[HCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 }; + u32 in[HCI_WORDS] = { HCI_GET, reg, 0, in2, 0, 0 }; u32 out[HCI_WORDS]; acpi_status status = hci_raw(in, out); *out1 = out[2]; @@ -263,7 +267,7 @@ u32 hci_result; u32 value; - hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result); + hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { value = value >> HCI_LCD_BRIGHTNESS_SHIFT; p += sprintf(p, "brightness: %d\n", value); @@ -285,7 +289,7 @@ if (snscanf(buffer, count, " brightness : %i", &value) == 1 && value >= 0 && value < HCI_LCD_BRIGHTNESS_LEVELS) { value = value << HCI_LCD_BRIGHTNESS_SHIFT; - hci_write1(HCI_LCD_BRIGHTNESS, value, &hci_result); + hci_write1(HCI_LCD_BRIGHTNESS, value, 0, &hci_result); if (hci_result != HCI_SUCCESS) return -EFAULT; } else { @@ -301,7 +305,7 @@ u32 hci_result; u32 value; - hci_read1(HCI_VIDEO_OUT, &value, &hci_result); + hci_read1(HCI_VIDEO_OUT, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { int is_lcd = (value & HCI_VIDEO_OUT_LCD) ? 1 : 0; int is_crt = (value & HCI_VIDEO_OUT_CRT) ? 1 : 0; @@ -340,7 +344,7 @@ while ((buffer < buffer_end) && (*(buffer-1) != ';')); } while (buffer < buffer_end); - hci_read1(HCI_VIDEO_OUT, &video_out, &hci_result); + hci_read1(HCI_VIDEO_OUT, &video_out, 0, &hci_result); if (hci_result == HCI_SUCCESS) { int new_video_out = video_out; if (lcd_out != -1) @@ -364,7 +368,7 @@ u32 hci_result; u32 value; - hci_read1(HCI_FAN, &value, &hci_result); + hci_read1(HCI_FAN, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { p += sprintf(p, "running: %d\n", (value > 0)); p += sprintf(p, "force_on: %d\n", force_fan); @@ -383,7 +387,7 @@ if (snscanf(buffer, count, " force_on : %i", &value) == 1 && value >= 0 && value <= 1) { - hci_write1(HCI_FAN, value, &hci_result); + hci_write1(HCI_FAN, value, 0, &hci_result); if (hci_result != HCI_SUCCESS) return -EFAULT; else @@ -402,7 +406,7 @@ u32 value; if (!key_event_valid) { - hci_read1(HCI_SYSTEM_EVENT, &value, &hci_result); + hci_read1(HCI_SYSTEM_EVENT, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { key_event_valid = 1; last_key_event = value; @@ -412,7 +416,7 @@ /* This is a workaround for an unresolved issue on * some machines where system events sporadically * become disabled. */ - hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result); + hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result); } else { p += sprintf(p, "ERROR\n"); goto end; @@ -450,6 +454,58 @@ return p; } +static char* +read_bluetooth(char *p) +{ + u32 hci_result; + u32 value; + + hci_read1(HCI_BLUETOOTH, &value, 0, &hci_result); + if (hci_result == HCI_SUCCESS) { + p += sprintf(p, "bluetooth_available: %d\n", value); + } else { + p += sprintf(p, "ERROR\n"); + goto end; + } + + hci_read1(HCI_BLUETOOTH, &value, HCI_BLUETOOTH_DX, &hci_result); + if (hci_result == HCI_SUCCESS) { + p += sprintf(p, "wireless_switch: %d\n", value & 1); + p += sprintf(p, "bluetooth_on: %d\n", (value & 128) == 128); + } else { + p += sprintf(p, "ERROR\n"); + } + +end: + return p; +} + +static unsigned long +write_bluetooth(const char* buffer, unsigned long count) +{ + int value; + u32 hci_result; + + if (snscanf(buffer, count, " bluetooth_on : %i", &value) == 1 && + value >= 0 && value <= 1) { + hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ACTIVATE, &hci_result); + if (hci_result != HCI_SUCCESS) + return -EFAULT; + + hci_write1(0, 0, 0, &hci_result); + + hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ATTACH, &hci_result); + if (hci_result != HCI_SUCCESS); + return -EFAULT; + + hci_write1(0, 0, 0, &hci_result); + } else { + return -EINVAL; + } + + return count; +} + /* proc and module init */ @@ -457,12 +513,13 @@ ProcItem proc_items[] = { - { "lcd" , read_lcd , write_lcd }, - { "video" , read_video , write_video }, - { "fan" , read_fan , write_fan }, - { "keys" , read_keys , write_keys }, - { "version" , read_version , 0 }, - { 0 , 0 , 0 }, + { "lcd", read_lcd, write_lcd }, + { "video", read_video, write_video }, + { "fan", read_fan, write_fan }, + { "keys", read_keys, write_keys }, + { "version", read_version, 0 }, + { "bluetooth", read_bluetooth, write_bluetooth }, + { 0, 0, 0 }, }; static acpi_status @@ -501,7 +558,7 @@ u32 hci_result; /* simple device detection: try reading an HCI register */ - hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result); + hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result); if (hci_result != HCI_SUCCESS) return -ENODEV; @@ -511,7 +568,7 @@ key_event_valid = 0; /* enable event fifo */ - hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result); + hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result); toshiba_proc_dir = proc_mkdir(PROC_TOSHIBA, acpi_root_dir); if (!toshiba_proc_dir) { ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-07 12:12 ` Marcel Holtmann 2003-11-07 13:22 ` Andreas Sundstrom 2003-11-07 15:27 ` Andreas Sundstrom @ 2003-11-07 18:50 ` Andreas Sundstrom 2 siblings, 0 replies; 21+ messages in thread From: Andreas Sundstrom @ 2003-11-07 18:50 UTC (permalink / raw) To: BlueZ Mailing List [-- Attachment #1: Type: text/plain, Size: 255 bytes --] LOL, The field values are already present in the file.. I'm not sure that the DX value is supposed to map to the switch on the notbook or if it's a coincidence that both are 0x1. The following patch is the best I have come up with until now. /Andreas [-- Attachment #2: patch-2.6.0-test9-toshiba-acpi-bt-2-stock.patch --] [-- Type: text/plain, Size: 6217 bytes --] --- tmp/linux-2.6.0-test9-stock/drivers/acpi/toshiba_acpi.c 2003-10-25 20:42:52.000000000 +0200 +++ linux-2.6.0-test9/drivers/acpi/toshiba_acpi.c 2003-11-07 19:37:38.000000000 +0100 @@ -81,6 +81,7 @@ #define HCI_VIDEO_OUT 0x001c #define HCI_HOTKEY_EVENT 0x001e #define HCI_LCD_BRIGHTNESS 0x002a +#define HCI_BLUETOOTH 0x0056 /* field definitions */ #define HCI_LCD_BRIGHTNESS_BITS 3 @@ -89,6 +90,9 @@ #define HCI_VIDEO_OUT_LCD 0x1 #define HCI_VIDEO_OUT_CRT 0x2 #define HCI_VIDEO_OUT_TV 0x4 +#define HCI_BLUETOOTH_ACTIVATE 0x0080 +#define HCI_BLUETOOTH_ATTACH 0x0040 +#define HCI_BLUETOOTH_DX 0x0001 /* utility */ @@ -195,9 +199,9 @@ */ static acpi_status -hci_write1(u32 reg, u32 in1, u32* result) +hci_write1(u32 reg, u32 in1, u32 in2, u32* result) { - u32 in[HCI_WORDS] = { HCI_SET, reg, in1, 0, 0, 0 }; + u32 in[HCI_WORDS] = { HCI_SET, reg, in1, in2, 0, 0 }; u32 out[HCI_WORDS]; acpi_status status = hci_raw(in, out); *result = (status == AE_OK) ? out[0] : HCI_FAILURE; @@ -205,9 +209,9 @@ } static acpi_status -hci_read1(u32 reg, u32* out1, u32* result) +hci_read1(u32 reg, u32* out1, u32 in2, u32* result) { - u32 in[HCI_WORDS] = { HCI_GET, reg, 0, 0, 0, 0 }; + u32 in[HCI_WORDS] = { HCI_GET, reg, 0, in2, 0, 0 }; u32 out[HCI_WORDS]; acpi_status status = hci_raw(in, out); *out1 = out[2]; @@ -263,7 +267,7 @@ u32 hci_result; u32 value; - hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result); + hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { value = value >> HCI_LCD_BRIGHTNESS_SHIFT; p += sprintf(p, "brightness: %d\n", value); @@ -285,7 +289,7 @@ if (snscanf(buffer, count, " brightness : %i", &value) == 1 && value >= 0 && value < HCI_LCD_BRIGHTNESS_LEVELS) { value = value << HCI_LCD_BRIGHTNESS_SHIFT; - hci_write1(HCI_LCD_BRIGHTNESS, value, &hci_result); + hci_write1(HCI_LCD_BRIGHTNESS, value, 0, &hci_result); if (hci_result != HCI_SUCCESS) return -EFAULT; } else { @@ -301,7 +305,7 @@ u32 hci_result; u32 value; - hci_read1(HCI_VIDEO_OUT, &value, &hci_result); + hci_read1(HCI_VIDEO_OUT, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { int is_lcd = (value & HCI_VIDEO_OUT_LCD) ? 1 : 0; int is_crt = (value & HCI_VIDEO_OUT_CRT) ? 1 : 0; @@ -340,7 +344,7 @@ while ((buffer < buffer_end) && (*(buffer-1) != ';')); } while (buffer < buffer_end); - hci_read1(HCI_VIDEO_OUT, &video_out, &hci_result); + hci_read1(HCI_VIDEO_OUT, &video_out, 0, &hci_result); if (hci_result == HCI_SUCCESS) { int new_video_out = video_out; if (lcd_out != -1) @@ -364,7 +368,7 @@ u32 hci_result; u32 value; - hci_read1(HCI_FAN, &value, &hci_result); + hci_read1(HCI_FAN, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { p += sprintf(p, "running: %d\n", (value > 0)); p += sprintf(p, "force_on: %d\n", force_fan); @@ -383,7 +387,7 @@ if (snscanf(buffer, count, " force_on : %i", &value) == 1 && value >= 0 && value <= 1) { - hci_write1(HCI_FAN, value, &hci_result); + hci_write1(HCI_FAN, value, 0, &hci_result); if (hci_result != HCI_SUCCESS) return -EFAULT; else @@ -402,7 +406,7 @@ u32 value; if (!key_event_valid) { - hci_read1(HCI_SYSTEM_EVENT, &value, &hci_result); + hci_read1(HCI_SYSTEM_EVENT, &value, 0, &hci_result); if (hci_result == HCI_SUCCESS) { key_event_valid = 1; last_key_event = value; @@ -412,7 +416,7 @@ /* This is a workaround for an unresolved issue on * some machines where system events sporadically * become disabled. */ - hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result); + hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result); } else { p += sprintf(p, "ERROR\n"); goto end; @@ -450,6 +454,60 @@ return p; } +static char* +read_bluetooth(char *p) +{ + u32 hci_result; + u32 value; + + hci_read1(HCI_BLUETOOTH, &value, 0, &hci_result); + if (hci_result == HCI_SUCCESS) { + p += sprintf(p, "bluetooth_available: %d\n", value); + } else { + p += sprintf(p, "ERROR\n"); + goto end; + } + + hci_read1(HCI_BLUETOOTH, &value, HCI_BLUETOOTH_DX, &hci_result); + if (hci_result == HCI_SUCCESS) { + int is_switch = (value & HCI_BLUETOOTH_DX) ? 1 : 0; + int is_btooth = (value & HCI_BLUETOOTH_ACTIVATE) ? 1 : 0; + p += sprintf(p, "wireless_switch: %d\n", is_switch); + p += sprintf(p, "bluetooth_on: %d\n", is_btooth); + } else { + p += sprintf(p, "ERROR\n"); + } + +end: + return p; +} + +static unsigned long +write_bluetooth(const char* buffer, unsigned long count) +{ + int value; + u32 hci_result; + + if (snscanf(buffer, count, " bluetooth_on : %i", &value) == 1 && + value >= 0 && value <= 1) { + hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ACTIVATE, &hci_result); + if (hci_result != HCI_SUCCESS) + return -EFAULT; + + hci_write1(0, 0, 0, &hci_result); + + hci_write1(HCI_BLUETOOTH, value, HCI_BLUETOOTH_ATTACH, &hci_result); + if (hci_result != HCI_SUCCESS); + return -EFAULT; + + hci_write1(0, 0, 0, &hci_result); + } else { + return -EINVAL; + } + + return count; +} + /* proc and module init */ @@ -457,12 +515,13 @@ ProcItem proc_items[] = { - { "lcd" , read_lcd , write_lcd }, - { "video" , read_video , write_video }, - { "fan" , read_fan , write_fan }, - { "keys" , read_keys , write_keys }, - { "version" , read_version , 0 }, - { 0 , 0 , 0 }, + { "lcd", read_lcd, write_lcd }, + { "video", read_video, write_video }, + { "fan", read_fan, write_fan }, + { "keys", read_keys, write_keys }, + { "version", read_version, 0 }, + { "bluetooth", read_bluetooth, write_bluetooth }, + { 0, 0, 0 }, }; static acpi_status @@ -501,7 +560,7 @@ u32 hci_result; /* simple device detection: try reading an HCI register */ - hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result); + hci_read1(HCI_LCD_BRIGHTNESS, &value, 0, &hci_result); if (hci_result != HCI_SUCCESS) return -ENODEV; @@ -511,7 +570,7 @@ key_event_valid = 0; /* enable event fifo */ - hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result); + hci_write1(HCI_SYSTEM_EVENT, 1, 0, &hci_result); toshiba_proc_dir = proc_mkdir(PROC_TOSHIBA, acpi_root_dir); if (!toshiba_proc_dir) { ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-05 12:18 ` Marcel Holtmann 2003-11-05 12:54 ` Andreas Sundstrom @ 2003-11-05 13:49 ` Andreas Sundstrom 2003-11-05 14:03 ` Marcel Holtmann 1 sibling, 1 reply; 21+ messages in thread From: Andreas Sundstrom @ 2003-11-05 13:49 UTC (permalink / raw) To: Marcel Holtmann; +Cc: BlueZ Mailing List Marcel Holtmann wrote: >>>This is a question for the USB guys. Do you have another USB Bluetooth >>>dongle to test with your notebook? >> >>I inserted a MS Wireless Transceiver for Bluetooth and it gave the same >>error.. but seems to work alright. Havn't done much testing yet though. > > > Please test this. If the Microsoft is working all the time then your > problem is part of the Silicon Wave chip or some else in the internal > USB stuff of your notebook. However it works in 2.4 this must be some > kind of problem in the Linux USB subsystem which only effects this kind > of device. I just rebooted to check and it actually had the same problem as the internal device. Now I'm starting to guess it maybe is USB that is the problem, what is your opinion(s) ? /Andreas ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-05 13:49 ` Andreas Sundstrom @ 2003-11-05 14:03 ` Marcel Holtmann 2003-11-05 14:31 ` Andreas Sundstrom 2003-11-08 9:53 ` Andreas Sundstrom 0 siblings, 2 replies; 21+ messages in thread From: Marcel Holtmann @ 2003-11-05 14:03 UTC (permalink / raw) To: Andreas Sundstrom; +Cc: BlueZ Mailing List Hi Andreas, > > Please test this. If the Microsoft is working all the time then your > > problem is part of the Silicon Wave chip or some else in the internal > > USB stuff of your notebook. However it works in 2.4 this must be some > > kind of problem in the Linux USB subsystem which only effects this kind > > of device. > I just rebooted to check and it actually had the same problem as the > internal device. Now I'm starting to guess it maybe is USB that is the > problem, what is your opinion(s) ? please check this some more times and then report it to the USB mailing list. Some of them should know what is changed in 2.6. Do you have a desktop PC running 2.6 to verify that it is your notebook that is some kind of buggy? Regards Marcel ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-05 14:03 ` Marcel Holtmann @ 2003-11-05 14:31 ` Andreas Sundstrom 2003-11-08 9:53 ` Andreas Sundstrom 1 sibling, 0 replies; 21+ messages in thread From: Andreas Sundstrom @ 2003-11-05 14:31 UTC (permalink / raw) To: BlueZ Mailing List Marcel Holtmann wrote: > Hi Andreas, > > >>>Please test this. If the Microsoft is working all the time then your >>>problem is part of the Silicon Wave chip or some else in the internal >>>USB stuff of your notebook. However it works in 2.4 this must be some >>>kind of problem in the Linux USB subsystem which only effects this kind >>>of device. >> >>I just rebooted to check and it actually had the same problem as the >>internal device. Now I'm starting to guess it maybe is USB that is the >>problem, what is your opinion(s) ? > > > please check this some more times and then report it to the USB mailing > list. Some of them should know what is changed in 2.6. Do you have a > desktop PC running 2.6 to verify that it is your notebook that is some > kind of buggy? Will do.. > > Regards > > Marcel > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bluez-users] 2.6.0-test9 SiW works sometimes 2003-11-05 14:03 ` Marcel Holtmann 2003-11-05 14:31 ` Andreas Sundstrom @ 2003-11-08 9:53 ` Andreas Sundstrom 1 sibling, 0 replies; 21+ messages in thread From: Andreas Sundstrom @ 2003-11-08 9:53 UTC (permalink / raw) To: BlueZ Mailing List Marcel Holtmann wrote: > Hi Andreas, > > >>>Please test this. If the Microsoft is working all the time then your >>>problem is part of the Silicon Wave chip or some else in the internal >>>USB stuff of your notebook. However it works in 2.4 this must be some >>>kind of problem in the Linux USB subsystem which only effects this kind >>>of device. >> >>I just rebooted to check and it actually had the same problem as the >>internal device. Now I'm starting to guess it maybe is USB that is the >>problem, what is your opinion(s) ? > > > please check this some more times and then report it to the USB mailing > list. Some of them should know what is changed in 2.6. Do you have a > desktop PC running 2.6 to verify that it is your notebook that is some > kind of buggy? Well I have now verified the same problem with the MS dongle on one of my desktop computers (ASUS A7V333 mb), I tested with 2.6.0-test9-bk12. Do you think it's time to try and report this to the USB people or what? I get this type of error on both the notebook and desktop computer: Nov 8 10:46:56 sunkan kernel: hci_usb: probe of 4-1.1:1.1 failed with error -5 /Andreas ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2003-11-08 9:53 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-11-05 11:06 [Bluez-users] 2.6.0-test9 SiW works sometimes Andreas Sundstrom 2003-11-05 11:22 ` Marcel Holtmann 2003-11-05 12:07 ` Andreas Sundstrom 2003-11-05 12:18 ` Marcel Holtmann 2003-11-05 12:54 ` Andreas Sundstrom 2003-11-05 14:15 ` Marcel Holtmann 2003-11-05 14:33 ` Andreas Sundstrom 2003-11-06 23:48 ` Marcel Holtmann 2003-11-07 10:04 ` Andreas Sundstrom 2003-11-07 11:25 ` Marcel Holtmann 2003-11-07 11:34 ` Andreas Sundstrom 2003-11-07 11:41 ` Marcel Holtmann 2003-11-07 12:00 ` Andreas Sundstrom 2003-11-07 12:12 ` Marcel Holtmann 2003-11-07 13:22 ` Andreas Sundstrom 2003-11-07 15:27 ` Andreas Sundstrom 2003-11-07 18:50 ` Andreas Sundstrom 2003-11-05 13:49 ` Andreas Sundstrom 2003-11-05 14:03 ` Marcel Holtmann 2003-11-05 14:31 ` Andreas Sundstrom 2003-11-08 9:53 ` Andreas Sundstrom
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.