----- Original Message ---- From: Marcel Holtmann <marcel@xxxxxxxxxxxx> To: Pavan Savoy <pavan_savoy@xxxxxxxxxxx> Cc: linux-bluetooth@xxxxxxxxxxxxxxx Sent: Friday, 28 August, 2009 12:59:08 AM Subject: Re: shared hci transport Hi Pavan, please don't do top-posting on this mailing list. We want proper inline quoting. > sure. > the bcm4325 has uart transport for BT [so I can make use of hci_h4, say by hciattach - like bcm2035]. > The FM core understands hci-vendor specific command. > > for example, I send HCI_VS opcode=0x20 to set the power of Rx to On.[The power on sequence also involves download of a firmware which is nothing but a file with ~10/20 hci-vendor specific commands with different opcodes]. > opcode 0x0a (say) to set the frequency and similarly in opcode 0x1d [audio enable] I give an data arguement 0x01 or 0x02 to say to FM Rx to put out audio on either it's analog lines or digital [i2s] lines.. > > Currently my fm stack, application is making use of hci_open_dev, send_cmd kind of hci lib calls to send commands. > > Now what should be my approach to send in same sort of commands from the kernel space ? >For the firmware loading part, we have to change this whole driver model >and add an init stage that allows configuration etc. >I am not sold on the whole in-kernel approach for FM yet. We need to >talk more about it. Especially since vendor commands and messing with >the flow control is tricky. >Regards >Marcel Yes -- Sorry for top posting [unfortunately this dumb mail editor doesn't give me much of choice] In any case, I was thinking more in terms of hci_device and hci_driver kind of a model, where in there can be a hci_device for a transport [say HCI-UART] and multiple hci_driver(s) for 1 such hci_device -- these hci_drivers get registered to a main/single hci_device. hci_device { open,send_frame, notify, flush, close } and the new hci_driver { pre/post_open, -- can be used for a f/w download pre/post_send, -- can be used to packetize/depacketize pre/post_notify, -- events can be categorised to HCI [cmd complete] sort of events or processed locally and not be notified to hci-user space layer.. pre/post_flush and pre/post_close } It would be same as using line discipline driver over uart. Every HCI transfer send or recieve can have a pre/post function of an already registered "hci_driver" which needs to called. We would kind of make use for plenty of other purpose also, since the transports are being shared for all sort of devices nowadays [gps+bt on uart/usb, fm+bt on uart]. -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html Love Cricket? Check out live scores, photos, video highlights and more. Click here http://cricket.yahoo.com -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html