On Fri, Nov 24, 2017 at 09:34:49PM +0530, Sanyog Kale wrote: > On Thu, Nov 23, 2017 at 02:38:12PM +0000, Charles Keepax wrote: > > On Fri, Nov 10, 2017 at 05:19:06PM +0530, Vinod Koul wrote: > > > > MIPI Discovery And Configuration (DisCo) Specification for SoundWire > > > specifies properties to be implemented for SoundWire Masters and > > > Slaves. The DisCo spec doesn't mandate these properties. However, > > > SDW bus cannot work without knowing these values. > > > > > > The helper functions read the Master and Slave properties. > > > Implementers of Master or Slave drivers can use any of the below > > > three mechanisms: > > > a) Use these APIs here as .read_prop() callback for Master > > > and Slave > > > b) Implement own methods and set those as .read_prop(), but invoke > > > APIs in this file for generic read and override the values with > > > platform specific data > > > c) Implement ones own methods which do not use anything provided > > > here > > > > > > Signed-off-by: Sanyog Kale <sanyog.r.kale@xxxxxxxxx> > > > Signed-off-by: Vinod Koul <vinod.koul@xxxxxxxxx> > > > --- > > Apologies for the long and slightly vague comment, but I guess my > > question is do you have a thought on how drivers should know when > > it is safe to communicate with a SoundWire device? > > IMO it is safe to communicate with SoundWire device when the Slave > status is ATTACHED. In any case bus will report error if it is not able > to communicate with SoundWire device. > Yeah I guess my point here is that there is currently no way in this SoundWire framework for the slave driver to know if the device is attached or not, unless I am missing something? There are calls by which the master can inform the framework, but nothing to pass that on to the slave driver. I would indeed imagine the comms would fail if the slave isn't attached but that doesn't seem like a particularly robust way of determining that. Thanks, Charles _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
