thesofproject
SoundWire: start adding BPT/BRA support
replacement and extension of PR #https://github.com/thesofproject/linux/pull/4676
@bardliao @ujfalusi @shumingfan @jack-cy-yu @oder-chiou @charleskeepax @rfvirgil comments welcome.
Still going through things but overall looks pretty sensible to me. Some initial thoughts/questions would be:
- Do we really want to bypass all the frame allocation stuff? Feels like it might be nice in the future to be able to support BRA whilst audio streams are running, for example downloading a large block of filter coefficients, or algorithm module to a device. There are questions about how one would decide how much frame to allocate, although I guess a good start might just be whatever is not used by audio.
- Regarding the debugfs interface, I don't actually mind skipping regmap for this, the current regmap is very hard to implement bulk transfers into. However, would it make sense just to have a binary file that you read and write for transferring the actual data rather than the weird hoops with a separate command file and using request firmware to load data for writes?
Still going through things but overall looks pretty sensible to me. Some initial thoughts/questions would be:
- Do we really want to bypass all the frame allocation stuff? Feels like it might be nice in the future to be able to support BRA whilst audio streams are running, for example downloading a large block of filter coefficients, or algorithm module to a device. There are questions about how one would decide how much frame to allocate, although I guess a good start might just be whatever is not used by audio.
Yes we could enable a BPT/BRA stream on top of an existing audio transfer. We can use the remaining bandwidth.
The problem is the other way around. When you have an existing BPT/BRA transfer and you want to start *another * audio stream, then the audio stream would be stuck until the BPT/BRA transfer finishes. This is a less-than-desirable solution, in that we cannot adjust the bandwidth of BRA on the fly. Once BPT/BRA has allocated all the frame for control/tables, then there's no way to walk back and leave enough space for other audio streams.
This is even more important now with devices that have multiple functions on the same link. All the firmware download stuff for SDCA is function specific, so it's really not that crazy to see concurrency of audio and BRA happening at some point for different functions.
- Regarding the debugfs interface, I don't actually mind skipping regmap for this, the current regmap is very hard to implement bulk transfers into. However, would it make sense just to have a binary file that you read and write for transferring the actual data rather than the weird hoops with a separate command file and using request firmware to load data for writes?
Oh the debugfs stuff is just to test without waiting for codec drivers to change.
The goal is that the codec driver can use its own binary file or ACPI table and directly do the open/send/wait/close sequence. With SDCA it's even going to be a handshake where the hardware reports it needs firmware download or not, that part has to be entirely handled in the codec driver.
Yes we could enable a BPT/BRA stream on top of an existing audio transfer. We can use the remaining bandwidth.
The problem is the other way around. When you have an existing BPT/BRA transfer and you want to start *another * audio stream, then the audio stream would be stuck until the BPT/BRA transfer finishes. This is a less-than-desirable solution, in that we cannot adjust the bandwidth of BRA on the fly. Once BPT/BRA has allocated all the frame for control/tables, then there's no way to walk back and leave enough space for other audio streams.
Although you have the same problem anyway right? If you block out the whole bus for the BRA, the audio cant start till it is done either, but I guess this way it does at least force people to only BRA when audio isn't going to be happening. I guess yeah the ideal behaviour would be when a new audio stream starts you would shrink the bandwidth allocated to BRA, but as you say its not obvious how one would implement that. Will have a little meditation on this.
This is even more important now with devices that have multiple functions on the same link. All the firmware download stuff for SDCA is function specific, so it's really not that crazy to see concurrency of audio and BRA happening at some point for different functions.
Perhaps there might be some options to reserve a portion of the bus for BRA, but it would undoubtedly end up being system specific and certainly you could imagine there being times it would be more ideal to use the whole bus.
Oh the debugfs stuff is just to test without waiting for codec drivers to change.
cool cool, will ignore that bit for now.
updates based on upstream comments
Split Cadence documentation to different file Simplified API to use send_async/wait Moved alignment requirements to platform-specific drivers Reduced alignment on Intel platforms to 32-bytes (was 128) Moved crc8 table to Cadence driver Various error handling improvements