On Thu, Dec 07, 2023 at 04:29:29PM -0600, 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. > > Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> > --- > +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. Is this definitely a show stopper? Not saying that it wouldn't be desirable to do both from a speed perspective, but current systems that download firmware (I2C/SPI) typically will block the bus for some amount of time. There are also some desirable properties to a single lock such as not needing to worry about accessing the same register in the bulk transfer and a normal command transfer. > +Audio DMA support > +----------------- > + > +Some DMAs, such as HDaudio, require an audio format field to be > +set. This format is in turn used to define acceptable bursts. BPT/BRA > +support is not fully compatible with these definitions in that the > +format may vary between read and write commands. > + > +In addition, on Intel HDaudio Intel platforms the DMAs need to be > +programmed with a PCM format matching the bandwidth of the BPT/BRA > +transfer. The format is based on 48kHz 32-bit samples, and the number > +of channels varies to adjust the bandwidth. The notion of channel is > +completely notional since the data is not typical audio > +PCM. Programming channels helps reserve enough bandwidth and adjust > +FIFO sizes to avoid xruns. Note that the quality of service comes as a > +cost. Since all channels need to be present as a sample block, data > +sizes not aligned to 128-bytes are not supported. Apologies but could you elaborate a litte on this? I am not sure I follow the reasoning, how does the 48k 32bit DMA implementation result in 128-byte limitation? I would have thought 1 channel would be 4-bytes and you are varying the channels so I would have expected 4-byte aligned maybe 8-byte if the DMA expects stereo pairs. And what exactly do we mean by aligned, are we saying the length all transfers needs to be a multiple of 128-bytes? I think we might have some annoying restrictions on the block size on our hardware as well I will go dig into that and report back. Thanks, Charles
