Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SDCA DisCo Parsing #5302

Open
wants to merge 10 commits into
base: topic/sof-dev
Choose a base branch
from

Conversation

charleskeepax
Copy link

Having just missed the merge window with this series I will push it here first and then start upstream review once the merge window closes. The series adds support for parsing most of the relevant information from ACPI/DisCo. The next steps I am looking at after this are adding helper functions (part of the library concept) for creating regmaps, lists of controls and DAPM graphs.

Copy link
Member

@lgirdwood lgirdwood left a comment

Choose a reason for hiding this comment

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

Nice work @charleskeepax ! LGTM
@bardliao @ujfalusi pls review

Comment on lines -23 to +46
SDCA_FUNCTION_TYPE_SMART_AMP = 0x01, /* Amplifier with protection features */
SDCA_FUNCTION_TYPE_SIMPLE_AMP = 0x02, /* subset of SmartAmp */
SDCA_FUNCTION_TYPE_SMART_MIC = 0x03, /* Smart microphone with acoustic triggers */
SDCA_FUNCTION_TYPE_SIMPLE_MIC = 0x04, /* subset of SmartMic */
SDCA_FUNCTION_TYPE_SPEAKER_MIC = 0x05, /* Combination of SmartMic and SmartAmp */
SDCA_FUNCTION_TYPE_UAJ = 0x06, /* 3.5mm Universal Audio jack */
SDCA_FUNCTION_TYPE_RJ = 0x07, /* Retaskable jack */
SDCA_FUNCTION_TYPE_SIMPLE_JACK = 0x08, /* Subset of UAJ */
SDCA_FUNCTION_TYPE_HID = 0x0A, /* Human Interface Device, for e.g. buttons */
SDCA_FUNCTION_TYPE_IMP_DEF = 0x1F, /* Implementation-defined function */
SDCA_FUNCTION_TYPE_SMART_AMP = 0x01,
SDCA_FUNCTION_TYPE_SIMPLE_AMP = 0x02,
SDCA_FUNCTION_TYPE_SMART_MIC = 0x03,
SDCA_FUNCTION_TYPE_SIMPLE_MIC = 0x04,
SDCA_FUNCTION_TYPE_SPEAKER_MIC = 0x05,
SDCA_FUNCTION_TYPE_UAJ = 0x06,
SDCA_FUNCTION_TYPE_RJ = 0x07,
SDCA_FUNCTION_TYPE_SIMPLE_JACK = 0x08,
SDCA_FUNCTION_TYPE_HID = 0x0A,
SDCA_FUNCTION_TYPE_IMP_DEF = 0x1F,
Copy link
Member

Choose a reason for hiding this comment

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

any reason to remove all the comments ?

Copy link
Author

Choose a reason for hiding this comment

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

Moved them into kerneldoc, just above.

void sdca_lookup_functions(struct sdw_slave *slave)
{
struct device *dev = &slave->dev;
struct acpi_device *adev = to_acpi_device_node(dev->fwnode);

if (!adev) {
dev_info(dev, "No matching ACPI device found, ignoring peripheral\n");
dev_info(dev, "no matching ACPI device found, ignoring peripheral\n");
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't have objection. But may I know the reason of the change?

Copy link
Author

Choose a reason for hiding this comment

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

Was just consistency all the other error messages in the file didn't capitalize so I made this one match them.

const char *label;
int id;
enum sdca_entity_type type;

Copy link
Collaborator

Choose a reason for hiding this comment

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

nitpick: No new line is required.


struct sdca_entity *entities;
int num_entities;

Copy link
Collaborator

Choose a reason for hiding this comment

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

nitpick: No new line is required.

Copy link
Member

@plbossart plbossart left a comment

Choose a reason for hiding this comment

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

nice update @charleskeepax, see comments below.

@@ -17,6 +17,14 @@
#include <sound/sdca.h>
#include <sound/sdca_function.h>

#define SDCA_PROPERTY_LENGTH 48
Copy link
Member

Choose a reason for hiding this comment

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

I can't recall where this comes from, a comment wouldn't hurt.

u32 addr;
u8 val;
};

Copy link
Member

Choose a reason for hiding this comment

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

This comment is not correct

"
Each SDCA Function may contain a table of register writes that should be
written out when the Function is first probed.
"

The register writes can only happens after the device attaches, which could be much later than the SDCA driver probe based on ACPI information.

Copy link
Author

Choose a reason for hiding this comment

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

I will update the comment to be a little more vague, although it does say when the Function probes, rather than device probes, which I would still intend to only happen well after the device has attached.

/*
* Sanity check on number of initialization writes, can be expanded if needed.
*/
#define SDCA_MAX_INIT_COUNT 64
Copy link
Member

Choose a reason for hiding this comment

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

that is much too low IMHO. This could include large set of parameters.

I would make this 64k...

Copy link
Author

Choose a reason for hiding this comment

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

64k seems bonkers to me, like if you need that many writes that is just circumventing the FDL process. I will update this to like 2k, if devices come along that need more its easy to update the number anyway. It would be good that updating this number would solicit some discussion if someone was making a device that needed so many init writes.

Copy link
Author

Choose a reason for hiding this comment

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

Aside from anything else 64k of init writes would take an ages to download, with a 48k frame rate, that is 1.5 seconds if you can do a write in every frame which current systems won't come close to, so that is probably like 10 seconds of doing init writes.


fwnode_property_read_u8_array(function_node,
"mipi-sdca-function-initialization-table",
init_list, num_init_writes);
Copy link
Member

Choose a reason for hiding this comment

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

didn't I write the initial code, would be nice if that was mentioned...

also we need to check for all fwnode_ return values to be consistent.

Copy link
Author

Choose a reason for hiding this comment

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

Apologies I actually did miss that you had a function for this in one of your pull requests and wrote this one from scratch, but I will add a signed off by to the patch.

Copy link
Author

Choose a reason for hiding this comment

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

Sorry also do we need to check the read_u8_array return value, I think any errors would be caught at the count stage?

/**
* define SDCA_CTL_TYPE - create a unique identifier for an SDCA Control
* @ent: Entity Type code.
* @sel: Control Selector code.
Copy link
Member

Choose a reason for hiding this comment

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

don't we need a version with the channel selector as well? If we want to e.g. mute the right channel, we need a means to access the volume.1 control, no?

Edit: this was mentioned in the commit message but worth adding as a comment in the code as well for reference.

Copy link
Author

Choose a reason for hiding this comment

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

Perhaps my wording needs more work here, the purpose does not require differentiating channels (Control Numbers), this is used for looking up the many fixed properties of the controls in SDCA. All of the channels, have the same properties (name, size, etc.).

Copy link
Author

Choose a reason for hiding this comment

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

Sorry and to answer your actually question if constructing an actual register address there is the SDW_SDCA_CTL in the sdw_registers.h header. That does include the Control Number.

* struct sdca_channel - a single Channel with a Cluster
* @id: Identifier used for addressing.
* @purpose: Indicates the purpose of the Channel, usually to give
* symantic meaning to the audio, eg. voice, ultrasound.
Copy link
Member

Choose a reason for hiding this comment

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

semantic

Copy link
Author

Choose a reason for hiding this comment

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

Hmm... yes my spelling always on point :-)

@@ -752,6 +752,29 @@ struct sdca_entity_iot {
int num_transducer;
};

/**
Copy link
Member

Choose a reason for hiding this comment

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

commit message type: add support

/**
* enum sdca_clock_type - SDCA Clock Types
*
* Indicate the synchronisity of an Clock Entity, see section 6.4.1.3
Copy link
Member

Choose a reason for hiding this comment

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

synchronicity?


/**
* struct sdca_entity_cs - information specific to Clock Source Entities
* @type: Synchronisity of the Clock Source.
Copy link
Member

Choose a reason for hiding this comment

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

ditto

struct sdca_pde_delay {
int from_ps;
int to_ps;
int us;
Copy link
Member

Choose a reason for hiding this comment

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

it's possible that the delay is > 64k us, I would use u32

Copy link
Member

Choose a reason for hiding this comment

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

It's not clear if we should care about such delays, except maybe to implement a timeout when the transition to the desired power state is stuck?

Copy link
Author

Choose a reason for hiding this comment

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

Yeah I am imagining the delays would likely be used either as delays or as timeouts in DAPM widgets for the PDEs. But either way even if we didn't no harm in them being parsed anyways. It is worth I did only parse the max delay, as I couldn't see any use for the typical delay. Both delays and timeouts would have to run on the max delay.

Fix up some variable/struct member naming, add some missing kerneldoc
and fix some minor formatting/whitespace issues.

Signed-off-by: Charles Keepax <[email protected]>
@charleskeepax charleskeepax force-pushed the sof/sdca branch 2 times, most recently from 0d34472 to 874699e Compare January 23, 2025 13:01
Add a helper function to parse all the Function and Entity
information from ACPI. In SDCA each device may have several Functions
and each corresponds to a specific audio capability such as say
amplifier playback or microphone capture. Each Function then contains
a number of Entities that represent individual parts of the audio
signal chain and are linked together in a graph similar to DAPM.

Signed-off-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Charles Keepax <[email protected]>
plbossart and others added 8 commits January 23, 2025 14:32
Each SDCA Function may contain a table of register writes that should be
written out before the Function is used. Add code to parse this table
from the DisCo tables in ACPI.

Signed-off-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Charles Keepax <[email protected]>
Within SDCA there is a special Entity called Entity 0 which is used
to hold Function level controls. Whilst Entity 0 isn't a full SDCA
entity, it is helpful to add an sdca_entity structure for it. This
will allow it to be treated identically when the code to add control
handling is added.

Signed-off-by: Charles Keepax <[email protected]>
Each SDCA Entity will contain a number of Controls, these are
basically equivalent to registers. Although a single Control will only
ever contain a single field. Some of these would map directly to ALSA
controls once more of the SDCA class driver is implemented. These
controls are parsed out of the DisCo ACPI tables.

One small todo here is that each Control can have multiple
sub-entries (Control Numbers), these are typically used to represent
channels. Whilst support is present for these, currently the
ACPI properties that would allow differing defaults for each channel
are not parsed. But there is nothing here that should prevent that
being added in the future.

Signed-off-by: Charles Keepax <[email protected]>
DisCo/SDCA contains small buffers of data that hold ranges of valid
values for the various SDCA Controls. Add support for parsing these
from ACPI.

Signed-off-by: Charles Keepax <[email protected]>
Within SDCA collections of Channels are referred to as Clusters, each
Channel within a Cluster can have various properties attached to it.
For example a stereo audio stream, would have a Cluster with 2 Channels
one marked as left and the other as right. Various Clusters are
specified in DisCo/ACPI and controls then allow the class driver to
select between these channel configurations. Add support for parsing
these Cluster definitions.

Signed-off-by: Charles Keepax <[email protected]>
Add support for parsing the Input/Output Terminal Entity properties from
DisCo/ACPI.

Signed-off-by: Charles Keepax <[email protected]>
Add support for parsing the Clock Source Entity properties from
DisCo/ACPI.

Signed-off-by: Charles Keepax <[email protected]>
Add support for parsing the Power Domain Entity properties from
DisCo/ACPI.

Signed-off-by: Charles Keepax <[email protected]>
Sign up for free to 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.

4 participants