[alsa-devel] [Patch v6 2/7] slimbus: Add messaging APIs to slimbus framework

[Srinivas Kandagatla]

On 11/10/17 11:24, Vinod Koul wrote:
> On Wed, Oct 11, 2017 at 10:42:28AM +0100, Srinivas Kandagatla wrote:
>> On 11/10/17 05:38, Vinod Koul wrote:
>>> On Fri, Oct 06, 2017 at 05:51:31PM +0200, srinivas.kandagatla at linaro.org wrote:
>>>
>>>>   	mutex_init(&ctrl->m_ctrl);
>>>> +	spin_lock_init(&ctrl->tx.lock);
>>>> +	spin_lock_init(&ctrl->rx.lock);
>>>
>>> locks galore :) My assumption is that you want to optimize these? But given
>>> that audio user is going to be serialized do we practically need two locks?
>>>
>> If we remove the locking, It will be issue if we have multiple devices in a
>> component, which is common atleast with the codec which am looking at.
> 
> can you explian what you mean by a "device" here?

SLIMbus component contain two or more SLIMbus devices,
like function(Generic) device, interface device.
Interface device provides bus management services, where as generic 
device provides more of application specific functionality like ADC/DAC..


> 
>>>> +	switch (mc) {
>>>> +	case SLIM_MSG_MC_REQUEST_VALUE:
>>>> +	case SLIM_MSG_MC_REQUEST_INFORMATION:
>>>
>>> what does MC refer to?
>>
>> Message Code.
> 
> isnt SLIM_MSG enough :D I think we cna get rid of MC here..
> 
>>>> +struct slim_val_inf {
>>>> +	u16			start_offset;
>>>> +	u8			num_bytes;
>>>> +	u8			*rbuf;
>>>> +	const u8		*wbuf;
>>>
>>> can we do read and write, if not it can be a buf which maybe rbuf or wbug
>>> based on type
>> With REQUEST_CHANGE_VALUE single command we can read old value at the same
>> time we can write new value.
> 
> so that is a read modify write, correct? Is that implemented in HW, if so we
> need to provide only write value

Its not really a read-modify-write,
REQUEST_CHANGE_VALUE/REQUEST_CLEAR_INFORMATION commands are part of 
SLIMbus Spec.
We need provide write value + buffer for read value to store.

all REQUEST_CHANGE_VALUE cmd do is this in single operation:

1> save the old value
2> update new value from wbuf
3> return the saved value from step 1, into rbuf

Not sure what is the real usecase for this, I have not seen its usage in 
any Qualcomm downstream code.

May be it can be used to implement some class of atomic ops.