SoundWire: add MBQ support in regmap#2364
Merged
Merged
Conversation
2831c36 to
a983e16
Compare
RanderWang
reviewed
Aug 14, 2020
bardliao
reviewed
Aug 14, 2020
Collaborator
bardliao
left a comment
There was a problem hiding this comment.
The concept is good to me. How about to support 16, 24, 32 bits?
lyakh
requested changes
Aug 14, 2020
kv2019i
reviewed
Aug 14, 2020
Collaborator
kv2019i
left a comment
There was a problem hiding this comment.
One generic comment on the approach, no other issues seen.
shumingfan
reviewed
Aug 18, 2020
4e6466e to
1adb80a
Compare
RanderWang
reviewed
Aug 19, 2020
kv2019i
previously approved these changes
Aug 19, 2020
lyakh
previously approved these changes
Aug 24, 2020
Collaborator
lyakh
left a comment
There was a problem hiding this comment.
a typo in the last patch commit message "An update will be provided"
This reverts commit b42cc42. Signed-off-by: Pierre-Louis Bossart <[email protected]>
This reverts commit 78141ac. Signed-off-by: Pierre-Louis Bossart <[email protected]>
-ENOTSUPP is not a valid error code, use recommended value instead. Signed-off-by: Pierre-Louis Bossart <[email protected]>
Explicitly add header files used by regmap SoundWire support. Suggested-by: Guennadi Liakhovetski <[email protected]> Signed-off-by: Pierre-Louis Bossart <[email protected]>
The upcoming SDCA (SoundWire Device Class Audio) specification defines a hiearchical encoding to interface with Class-defined capabilities. The specification is not yet accessible to the general public but this information is released with explicit permission from the MIPI Board to avoid delays with SDCA support on Linux platforms. A block of 64 MBytes of register addresses are allocated to SDCA controls, starting at address 0x40000000. The 26 LSBs which identify individual controls are set based on the following variables: - Function Number. An SCDA device can be split in up to 8 independent Functions. Each of these Functions is described in the SDCA specification, e.g. Smart Amplifier, Smart Microphone, Simple Microphone, Jack codec, HID, etc. - Entity Number. Within each Function, an Entity is an identifiable block. Up to 127 Entities are connected in a pre-defined graph (similar to USB), with Entity0 reserved for Function-level configurations. In contrast to USB, the SDCA spec pre-defines Function Types, topologies, and allowed options, i.e. the degree of freedom is not unlimited to limit the possibility of errors in descriptors leading to software quirks. - Control Selector. Within each Entity, the SDCA specification defines 48 controls such as Mute, Gain, AGC, etc, and 16 implementation defined ones. Some Control Selectors might be used for low-level platform setup, and other exposed to applications and users. Note that the same Control Selector capability, e.g. Latency control, might be located at different offsets in different entities, the Control Selector mapping is Entity-specific. - Control Number. Some Control Selectors allow channel-specific values to be set, with up to 64 channels allowed. This is mostly used for volume control. - Current/Next values. Some Control Selectors are 'Dual-Ranked'. Software may either update the Current value directly for immediate effect. Alternatively, software may write into the 'Next' values and update the SoundWire 1.2 'Commit Groups' register to copy 'Next' values into 'Current' ones in a synchronized manner. This is different from bank switching which is typically used to change the bus configuration only. - MBQ. the Multi-Byte Quantity bit is used to provide atomic updates when accessing more that one byte, for example a 16-bit volume control would be updated consistently, the intermediate values mixing old MSB with new LSB are not applied. These 6 parameters are used to build a 32-bit address to access the desired Controls. Because of address range, paging is required, but the most often used parameter values are placed in the lower 16 bits of the address. This helps to keep the paging registers constant while updating Controls for a specific Device/Function. Signed-off-by: Pierre-Louis Bossart <[email protected]>
The SoundWire 1.1 specification only allowed for reads and writes of bytes. The SoundWire 1.2 specification adds a new capability to transfer "Multi-Byte Quantities" (MBQ) across the bus. The transfers still happens one-byte-at-a-time, but the update is atomic. For example when writing a 16-bit volume, the first byte transferred is only taken into account when the second byte is successfully transferred. The mechanism is symmetrical for read and writes: - On a read, the address of the last byte to be read is modified by setting the MBQ bit - On a write, the address of all but the last byte to be written are modified by setting the MBQ bit. The address for the last byte relies on the MBQ bit being cleared. The current definitions for MBQ-based controls in the SDCA draft standard are limited to 16 bits for volumes, so for now this is the only supported format. An update will be provided if and when support for 24-bit and 32-bit values is specified by the SDCA standard. One possible objection is that this code could have been handled with regmap-sdw.c. However this is a new spec addition not handled by every SoundWire 1.1 and non-SDCA device, so there's no reason to load code that will never be used. Also in practice it's extremely unlikely that CONFIG_REGMAP would not be selected with CONFIG_REGMAP_MBQ selected. However there's no functional dependency between the two modules so they can be selected separately. Signed-off-by: Pierre-Louis Bossart <[email protected]>
7e1279e
1adb80a to
7e1279e
Compare
Member
Author
fixed |
Member
Author
|
@lyakh @bardliao @shumingfan @RanderWang @kv2019i I reverted the patches for SDCA macros and re-added a commit with a better description for the hierarchical encoding to address Vinod Koul's objections. Please review and let me know if this makes any sense, thanks! |
ranj063
approved these changes
Aug 25, 2020
RanderWang
approved these changes
Aug 25, 2020
lyakh
approved these changes
Aug 25, 2020
kv2019i
approved these changes
Aug 25, 2020
Collaborator
kv2019i
left a comment
There was a problem hiding this comment.
Looks good now. @plbossart I'll let you merge.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Instead of manually open-coding MBQ access, we can define a new regmap support. This would have the main benefit of having values refreshed on resume in a consistent manner. The drawback is that a separate regmap definition is required, but maybe it's not so bad to avoid mixing regular registers and multi-byte SCDA controls.