Hi Pierre, On 07-12-23, 16:29, Pierre-Louis Bossart wrote: > The Bulk Register Access protocol was left as a TODO topic since > 2018. It's time to document this protocol and the design of its Linux > support. Thanks for letting me know about this thread. At least now with B4 we can grab threads we are not copied. > > Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> > --- > Documentation/driver-api/soundwire/bra.rst | 478 ++++++++++++++++++ Can we split the cadence parts of this to bra-cadence.rst that way this file documents the core parts only > +Concurrency between BRA and regular read/write > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > + > +The existing 'nread/nwrite' API already relies on a notion of start > +address and number of bytes, so it would be possible to extend this > +API with a 'hint' requesting BPT/BRA be used. > + > +However BRA transfers could be quite long, and the use of a single > +mutex for regular read/write and BRA is a show-stopper. Independent > +operation of the control/command and BRA transfers is a fundamental > +requirement, e.g. to change the volume level with the existing regmap > +interface while downloading firmware. > + > +This places the burden on the codec driver to verify that there is no > +concurrent access to the same address with the command/control > +protocol and the BRA protocol. > + > +In addition, the 'sdw_msg' structure hard-codes support for 16-bit > +addresses and paging registers which are irrelevant for BPT/BRA > +support based on native 32-bit addresses. A separate API with > +'sdw_bpt_msg' makes more sense. > + > +One possible strategy to speed-up all initialization tasks would be to > +start a BRA transfer for firmware download, then deal with all the > +"regular" read/writes in parallel with the command channel, and last > +to wait for the BRA transfers to complete. This would allow for a > +degree of overlap instead of a purely sequential solution. As a > +results, the BRA API must support async transfers and expose a > +separate wait function. That sounds logical to me > + > +Error handling > +~~~~~~~~~~~~~~ > + > +The expected response to a 'bra_message' and follow-up behavior may > +vary: > + > + (1) A Peripheral driver may want to receive an immediate -EBUSY > + response if the BRA protocol is not available at a given time. > + > + (2) A Peripheral driver may want to wait until a timeout for the > + on-going transfer to be handled > + > + (3) A Peripheral driver may want to wait until existing BRA > + transfers complete or deal with BRA as a background task when > + audio transfers stop. In this case, there would be no timeout, > + and the operation may not happen if the platform is suspended. Is this runtime suspend or S3/S4 case? > +BTP/BRA API available to peripheral drivers > +------------------------------------------- > + > +ASoC Peripheral drivers may use > + > + - sdw_bpt_stream_open(mode) > + > + This function verifies that the BPT protocol with the > + 'mode'. For now only BRA is accepted as a mode. This function > + allocates a work buffer internally. This buffer is not exposed > + to the caller. > + > + errors: > + -ENODEV: BPT/BRA is not supported by the Manager. > + > + -EBUSY: another agent is already using the audio payload for > + audio transfers. There is no way to predict when the audio > + streams might stop, this will require the Peripheral driver > + to fall back to the regular (slow) command channel. > + > + -EAGAIN: another agent is already transferring data using the > + BPT/BRA protocol. Since the transfers will typically last > + 10s or 100s of ms, the Peripheral driver may wait and retry > + later. > + > + - sdw_bpt_message_send_async(bpt_message) why not have a single API that does both? First check if it is supported and then allocate buffers and do the transfer.. What are the advantages of using this two step process -- ~Vinod
