Re: [PATCH v3 3/3] Bluetooth: hci_bcm: Add suspend/resume runtime PM functions

[Loic Poulain <loic.poulain@intel.com>]

Hi Fred

>> For hci_intel we are doing this in the enqueue function when the
>> Bluetooth subsystem has to send us data. Why would we do this on the
>> TTY receiving side here? If the device is not active, we would not be
>> receiving anything in the first place. I am failing to see the logic
>> here.
> hci_intel also performs this when receiving LPM_OP_TX_NOTIFY packets.
> Afaik, Broadcom device does not have this feature and we need to delay
> the suspend when we receive a packet.
>
> I will move bcm_schedule_work() after h4_recv_buf() to perform it only
> on completed packet.

What about using a delayed work with work_delay << autosuspend_delay so 
that the work is not queued each time but every work_delay in worst case.

hci_uart proto callback is called with rx spinlock in
hci_uart_tty_receive which is the receive_buf ldisc callback.
In drivers/tty/tty_buffer.c we can see that flush_to_ldisc (work) locks
a mutex (&buf->lock) and push the data to ldisc via receive_buf.

So, I don't see any problem to remove the hci_ldisc rx_spinlock and 
replace it by a mutex, or even don't use locking at all.

Regards,
Loic
-- 
Intel Open Source Technology Center
http://oss.intel.com/