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@linux.intel.com
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 whenaudio 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 functionallocates a work buffer internally. This buffer is not exposedto the caller.errors:-ENODEV: BPT/BRA is not supported by the Manager.-EBUSY: another agent is already using the audio payload foraudio transfers. There is no way to predict when the audiostreams might stop, this will require the Peripheral driverto fall back to the regular (slow) command channel.-EAGAIN: another agent is already transferring data using theBPT/BRA protocol. Since the transfers will typically last10s or 100s of ms, the Peripheral driver may wait and retrylater.
- 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