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@xxxxxxxxxx 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
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
