Hi Loic, >> since building a kernel with its parent commit [4] works perfectly fine: >> commit: 7649faff1cfe4f76dabf78cd53d659d39f65b3c1 >> Bluetooth: Remove useless rx_lock spinlock >> >> The code change adding the runtime PM functions introduces an autosleep >> delay but it's unclear from the commit description how the BT chipset is >> supposed to get out of sleep afterwards. > > Using out-of-band gpio/irq which are retrieved from the ACPI device. > wakeup can be initiated by host or controller depending which one wants > to transfer hci data. I am actually curious if HCI remote wakeup might not work. So the HID mouse (I assume Classic here) will initiate a HCI Create Connection which will result in a HCI Connection Request. So that wakeup event needs to be allowed. I am curious if we might not set that correctly. I would need to see the btmon trace from the controller initialization (start btmon before calling btattach). I am no longer sure that this has been tested with UART based controllers. On USB the remote wakeup works. If the events for connection creation and remote wakeup set correctly, then it is some GPIO or Broadcom vendor specific thing. Regards Marcel -- 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
