-
Notifications
You must be signed in to change notification settings - Fork 349
[REVIEW ONLY] topology 2.0 #3183
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,55 @@ | ||
| # common attributes and attribute types. Attributes, defined here can then be | ||
| # used by any blocks. E.g. the "format" attribute can be used by pipelines, | ||
| # DAIs, etc. | ||
|
|
||
| # we're using an "availability" parameter in attribute declaration instead of | ||
| # adding ".optional" or ".mandatory" to the array name | ||
|
|
||
| DefineType.format { | ||
| enum [ | ||
| "s16le" | ||
| "s24le" | ||
| "s32le" | ||
| "float" | ||
| ] | ||
| } | ||
|
|
||
| DefineType.time_domain { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ditto "pipeline.time_domain" |
||
| enum [ | ||
| "dma" | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should use the |
||
| "timer" | ||
| ] | ||
| } | ||
|
|
||
| DefineAttribute.tokens { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Dont need to define tokens - it's low level implementation detail only.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a "tokens" attribute for cases where higher level configuration files (e.g. machine level) pass their specific token arrays to lower level configuration files (pipelines). This is currently used for example to define pipelines: which then is called as and
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But we are not using SectionWidget or token array directly - we abstract all tokens with Attributes.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @lgirdwood we do that where possible, yes. E.g. for volume, where it's known in advance which tokens must be supplied. But here it can be any tokens that the respective platform decides to apply. So I don't see how we can replace them with fixed attributes? |
||
| type array.tuple | ||
| } | ||
|
|
||
| DefineAttribute.format { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This overlaps with DefineType. I much rather reduce the number of new keywords so
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. but we will have several attributes of type "format." Without defining the type "format" we'll have to repeat the same enum every time. Even worse with much longer enums like widget types.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This will be global and in a global pcm.conf header. PCM format will be used in lots of places so why would we have to repeat. Can you provide an example ?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @lgirdwood Even in minimal examples we have two formats: a pipeline format and a DAI format, so we need at least two attributes of type "format" - see |
||
| type format | ||
| availability mandatory | ||
| } | ||
|
|
||
| DefineAttribute.template { | ||
| type string | ||
| availability mandatory | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Lets not put the availability in the attribute definitions, since each attribute may be optional for some and mandatory for other components.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah, I remember that was your proposal. And I understand the improvement, that it offers, but it would make the code look less readable IMHO. Also, I don't think you can make this work 100%. The same attribute within the same component can be mandatory in some configurations and optional in others, can it not? I don't think you can catch all such errors at compile-time, some can only be really verified at run-time? We could omit availability altogether for now and see later, if you feel strongly about it? |
||
| } | ||
|
|
||
| DefineAttribute.pipeline_id { | ||
| type integer | ||
| availability mandatory | ||
| } | ||
|
|
||
| DefineAttribute.periods_sink { | ||
| type integer | ||
| availability optional | ||
| default 2 | ||
| min 1 | ||
| } | ||
|
|
||
| DefineAttribute.periods_source { | ||
| type integer | ||
| availability optional | ||
| default 2 | ||
| min 1 | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| # Buffer block and related attributes | ||
|
|
||
| DefineAttribute.capabilities { | ||
| type array.integer | ||
| } | ||
|
|
||
| # A buffer block, most attributes inherited from "Widget" | ||
| DefineWidget."buffer" { | ||
| attributes [ | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can we make these attribute mandatory and optional in the widget definition. Some widgets will only have mandatory but some will have both e.g. for buffer "size" is mandatory but "ignore_underrun" is optional and false by default. |
||
| name | ||
| format | ||
| periods | ||
| capabilities | ||
| ] | ||
|
|
||
| type buffer | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,17 @@ | ||
| # BXT specific topology elements | ||
|
|
||
| # BXT host memory capability flags | ||
| platform_host_mem_cap [ | ||
| MEM_CAP_RAM | ||
| MEM_CAP_DMA | ||
| MEM_CAP_CACHE | ||
| MEM_CAP_HP | ||
| ] | ||
|
|
||
| # BXT DAI memory capability flags | ||
| platform_dai_mem_cap [ | ||
| MEM_CAP_RAM | ||
| MEM_CAP_DMA | ||
| MEM_CAP_CACHE | ||
| MEM_CAP_HP | ||
| ] |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,47 @@ | ||
| # Common topology defines | ||
|
|
||
| # All SOF widget types | ||
| DefineType.widget_type { | ||
| enum [ | ||
| "aif_in" | ||
| "aif_out" | ||
| "asrc" | ||
| "buffer" | ||
| "dai_in" | ||
| "dai_out" | ||
| "effect" | ||
| "input" | ||
| "mixer" | ||
| "output" | ||
| "pga" | ||
| "scheduler" | ||
| "siggen" | ||
| "src" | ||
| ] | ||
| } | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Dont need this, it's low level and encoded in the CC.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. don't we add new widget types from time to time? Do we really want to patch the compiler every time we do that? |
||
|
|
||
| # Attributes, common to all widgets | ||
| DefineAttribute.type { | ||
| type widget_type | ||
| availability optional | ||
| } | ||
|
|
||
| DefineAttribute.index { | ||
| type integer | ||
| availability optional | ||
| } | ||
|
|
||
| DefineAttribute.no_pm { | ||
| type bool | ||
| availability optional | ||
| default true | ||
| } | ||
|
|
||
| # All widgets inherit these attributes | ||
| DefineWidget { | ||
| attributes [ | ||
| type | ||
| index | ||
| no_pm | ||
| ] | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,114 @@ | ||
| # DAI attributes and component declarations | ||
|
|
||
| # These have to be globally defined, so they are using a "dai_" prefix | ||
| DefineAttribute.dai_format { | ||
| type format | ||
| # could make it optional with s32le as default? | ||
| availability mandatory | ||
| } | ||
|
|
||
| DefineAttribute.dai_periods { | ||
| type integer | ||
| availability optional | ||
| default 2 | ||
| min 1 | ||
| } | ||
|
|
||
| DefineAttribute.dai_index { | ||
| type integer | ||
| availability mandatory | ||
| } | ||
|
|
||
| DefineType.dai_type { | ||
| enum [ | ||
| "ALH" | ||
| "DMIC" | ||
| "ESAI" | ||
| "HDA" | ||
| "SAI" | ||
| "SSP" | ||
| ] | ||
| } | ||
|
|
||
| DefineAttribute.dai_type { | ||
| type dai_type | ||
| availability mandatory | ||
| } | ||
|
|
||
| # The DAI widget | ||
| DefineWidget."dai" { | ||
| DefineAttribute.backend { | ||
| type string | ||
| availability mandatory | ||
| } | ||
|
|
||
| attributes [ | ||
| template | ||
| backend | ||
| periods_sink | ||
| periods_source | ||
| dai_format | ||
| dai_type | ||
| dai_index | ||
| schedule_time_domain | ||
| ] | ||
| } | ||
|
|
||
| # DAI_CONFIG adds 2 components: SectionBE, SectionHWConfig, but we want a block | ||
| # for each component, so we need two defines | ||
|
|
||
| # A back end / SectionBE | ||
| DefineBE { | ||
| DefineAttribute.index { | ||
| type integer | ||
| availability mandatory | ||
| } | ||
|
|
||
| DefineAttribute.id { | ||
| type integer | ||
| availability mandatory | ||
| } | ||
|
|
||
| DefineAttribute.default_hw_conf_id { | ||
| type integer | ||
| availability mandatory | ||
| } | ||
|
|
||
| DefineAttribute.hw_configs { | ||
| type array.string | ||
| availability mandatory | ||
| } | ||
|
|
||
| # index is always \"0\", default_hw_conf_id is always identical | ||
| attributes [ | ||
| id | ||
| index | ||
| default_hw_conf_id | ||
| hw_configs | ||
| ] | ||
|
|
||
| index 0 | ||
| default_hw_conf_id $id | ||
|
|
||
| # FIXME we need concatenation | ||
| hw_configs [ | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do you need to concat this ?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. those aren't multiple configurations, that's just one configuration, generated by concatenating those two strings: |
||
| @func concat | ||
| strings [ | ||
| $dai_type | ||
| $dai_index | ||
| ] | ||
| ] | ||
| } | ||
|
|
||
| # SectionHWConfig | ||
| DefineHWConfig { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. DefineHWConfig."hw_cfg.ssp" etc would support per DAI type configs.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure I understand correctly what you mean. This is dai.conf, so this is a generic definition of a |
||
| DefineAttribute.id { | ||
| type integer | ||
| availability mandatory | ||
| } | ||
|
|
||
| attributes [ | ||
| id | ||
| # we also need to define attributes for SSP, SAI, ESAI | ||
| ] | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,80 @@ | ||
| # Instantiate a subtree - all the pipelines, connected to one DAI | ||
| subtree { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would expect the machine file to contain It should be representing the same data as contained in the machine M4 today.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "Declare" in your code above means instantiation? I use "new." for it now. But yes, that's also what I do. |
||
| # Subtree-level attributes | ||
|
|
||
| # the DAI will use pipeline_id from the first pipeline in the array | ||
| # We put all the DAI attributes in the global scope, but in principle | ||
| # the compiler can also be taught to take them from the DAI scope. | ||
| dai_format s32le | ||
| dai_periods 2 | ||
| dai_type HDA | ||
| dai_index 4 | ||
| schedule_time_domain timer | ||
|
|
||
| # the below could also be written as "pipelines.0 {...}" especially in | ||
| # cases with only one pipeline in the subtree | ||
|
|
||
| # Each element of this array instantiates a block, as defined per | ||
| # DefineWidget."pipeline" | ||
| # TODO: this has to be made explicit | ||
| pipelines [ | ||
| { | ||
| template "volume-playback" | ||
|
|
||
| pipeline_id 7 | ||
| pipeline_channels 2 | ||
| pipeline_format s24le | ||
| pipeline_rate 48000 | ||
|
|
||
| schedule_period 1000 | ||
| schedule_priority 0 | ||
| # optional: 0 core is the default | ||
| schedule_core 0 | ||
|
|
||
| pcm_id 3 | ||
| pcm_rate { | ||
| min 48000 | ||
| max 48000 | ||
| } | ||
|
|
||
| tokens [ | ||
| { | ||
| # from bxt.m4, cnl.m4 | ||
| sched_mips 5000 | ||
| } | ||
| ] | ||
|
|
||
| # Not every pipeline has a PCM, some pipelines might | ||
| # just form an alternative path in a graph, so a PCM in | ||
| # a pipeline is optional, but common | ||
| # PCM_PLAYBACK_ADD(HDMI1, 3, PIPELINE_PCM_7) | ||
| # adds a "SectionPCM" block | ||
| pcm { | ||
| name "HDMI1" | ||
| } | ||
| } | ||
| ] | ||
|
|
||
| # Instantiate a block, as defined per | ||
| # DefineWidget."dai" | ||
| # TODO: this has to be made explicit | ||
| dai { | ||
| # DAI-specific attributes | ||
| template "playback" | ||
| backend "iDisp1" | ||
| } | ||
|
|
||
| # The fourth parameter is the BE name and it seems to always be equal to | ||
| # the fifth parameter of the DAI_ADD() macro, however, this hasn't been | ||
| # verified in all topologies. | ||
| # DAI_CONFIG(HDA, 4, 1, iDisp1) | ||
| # Possibly this can be merged with the "dai" block above | ||
| dai_config { | ||
| id 1 | ||
| } | ||
|
|
||
| # Need to instantiate SectionHWConfig separately | ||
| hw_config { | ||
| id 1 | ||
| } | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we name space this and use the "" here. e.g.
Since "format" can be used for multiple items.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is a type definition, not an attribute declaration. PCM and DAI formats are the same, aren't they?