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@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?
- 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