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