Skip to content

SoundWire: add MBQ support in regmap - #2364

Merged
plbossart merged 6 commits into
thesofproject:topic/sof-devfrom
plbossart:sdw/regmap_mbq
Aug 25, 2020
Merged

SoundWire: add MBQ support in regmap#2364
plbossart merged 6 commits into
thesofproject:topic/sof-devfrom
plbossart:sdw/regmap_mbq

Conversation

@plbossart

Copy link
Copy Markdown
Member

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.

Comment threaddrivers/base/regmap/regmap-sdw-mbq.c

@bardliaobardliao left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The concept is good to me. How about to support 16, 24, 32 bits?

Comment threadsound/soc/intel/boards/Kconfig Outdated
Comment threaddrivers/base/regmap/regmap-sdw-mbq.c
Comment threaddrivers/base/regmap/Kconfig
Comment threaddrivers/base/regmap/regmap-sdw-mbq.c
Comment threaddrivers/base/regmap/regmap-sdw-mbq.c
Comment threadinclude/linux/regmap.h

@kv2019ikv2019i left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One generic comment on the approach, no other issues seen.

Comment threaddrivers/base/regmap/Makefile
Comment threaddrivers/base/regmap/regmap-sdw-mbq.c Outdated
@plbossart
plbossartforce-pushed the sdw/regmap_mbq branch 2 times, most recently from 4e6466e to 1adb80aCompareAugust 18, 2020 13:47
@plbossartplbossart changed the title [RFC] SoundWire: add MBQ support in regmapSoundWire: add MBQ support in regmapAug 18, 2020
Comment threadinclude/linux/regmap.h
kv2019i
kv2019i previously approved these changes Aug 19, 2020
RanderWang
RanderWang previously approved these changes Aug 20, 2020

@RanderWangRanderWang left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

lyakh
lyakh previously approved these changes Aug 24, 2020

@lyakhlyakh left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a typo in the last patch commit message "An update will be provided"

This reverts commit b42cc42.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
This reverts commit 78141ac.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
-ENOTSUPP is not a valid error code, use recommended value instead.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Explicitly add header files used by regmap SoundWire support.
Suggested-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
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 <pierre-louis.bossart@linux.intel.com>
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 <pierre-louis.bossart@linux.intel.com>
@plbossart

Copy link
Copy Markdown
MemberAuthor

a typo in the last patch commit message "An update will be provided"

fixed

@plbossart

Copy link
Copy Markdown
MemberAuthor

@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!

@bardliaobardliao left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kv2019ikv2019i left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good now. @plbossart I'll let you merge.

@plbossart
plbossart merged commit 734fc1b into thesofproject:topic/sof-devAug 25, 2020
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants

@plbossart@lyakh@ranj063@bardliao@shumingfan@RanderWang@kv2019i