On Tue, Feb 13, 2018 at 9:07 PM, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote:
> 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.
Right. mutex would be better option. I will submit updated version
with this change
Regards,
Amitkumar Karwar
