>> Added support to load firmware to target RAM from Bluetooth USB transport >> driver. >we have discussed this a long time ago and the better approach would be >to create a setup stage for all HCI drivers. For example for special HCI >commands to set BD_ADDR and other details. Maybe also a firmware loading >stage should be used. Making this USB specific sounds pretty much wrong >to me at this point. At least SDIO might have similar issues. >>The current approach looks more hackish than actually nicely integrated. Thanks for bringing up old topic. We discussed this few years ago and things been somehow stalled. Besides, USB, SDIO there's UART which is used in a lot of embedded platforms and everybody hacks custom code around. Overall Marcel suggests to have intermediate stage between DOWN and UP states for hci device aka - SETUP (call it any name). Here are low level BT setup states that I "think" are common for majority of embedded implementations: 1. low level GPIO, CLC etc setup - can not talk to chip before that. 2. Initial firmware/patch download - at this state one can talk HCI to chip, but chip is barely functional, firmware, patches etc are downloaded at this stage. 3. "Run time config download" (often combined with #2, but I suggest to separate) this is when BDADDR is programmed and chip run time parameters for given platform are set up. For majority of chips this stage also defines Sleep algorithm to be used. There are few ways of doing BT sleep - HCI, UART signaling or usage of extra WAKE GPIO's to determine sleep condition. Most of them require initial HCI setup. 4. Enable Sleep and low power mode. Currently everybody hardcodes this step, some platforms have programmatic ifaces (aka sysfs) 5. WiFI coex setup if needed. Feel free to add more here .... At this stage hci can be brought to UP stage and be functional. All of that is tight with RFKILL of course and also suspend/resume entries in transport driver. I'm also not doing in to details of sleep mode implementation in this thread but welcome to discuss it in separate thread. Oleg. -- 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 -- 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
