lkml.org 
[lkml]   [2017]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [alsa-devel] [Patch v6 2/7] slimbus: Add messaging APIs to slimbus framework
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

--
~Vinod

\
 
 \ /
  Last update: 2017-10-11 12:22    [W:0.063 / U:29.628 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site