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

[Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html