Amitkumar Karwar <amitkarwar@xxxxxxxxx> writes:
> On Thu, Feb 1, 2018 at 12:26 PM, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote:
>> Amitkumar Karwar <amitkarwar@xxxxxxxxx> writes:
>>
>>> From: Prameela Rani Garnepudi <prameela.j04cs@xxxxxxxxx>
>>>
>>> With BT support, driver has to handle two streams of data
>>> (i.e. wlan and BT). Actual coex implementation is in firmware.
>>> Coex module just schedule the packets to firmware by taking them
>>> from the corresponding paths.
>>>
>>> Structures for module and protocol operations are introduced for
>>> this purpose. Protocol operations structure is global structure
>>> which can be shared among different modules. Initialization of
>>> coex and operating mode values is moved to rsi_91x_init().
>>>
>>> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@xxxxxxxxx>
>>> Signed-off-by: Siva Rebbagondla <siva.rebbagondla@xxxxxxxxxxxxxxxxxx>
>>> Signed-off-by: Amitkumar Karwar <amit.karwar@xxxxxxxxxxxxxxxxxx>
>>
>> [...]
>>
>>> @@ -270,6 +271,7 @@ struct rsi_common {
>>> u8 obm_ant_sel_val;
>>> int tx_power;
>>> u8 ant_in_use;
>>> + struct semaphore tx_bus_lock;
>>
>> Do you really need to use semaphore? I think nowadays the preference is
>> to use something other than semaphores.
>
> We used semaphore here, as USB/SDIO bus write operations could be
> blocking/waiting. I will check if spinlock suits here in follow up
> patch. It will need some testing.
I was more thinking about using a mutex.
--
Kalle Valo
--
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
