Repository navigation
Conversation
4186ad2 to
dae29de
Compare
|
@dragosht is there a corresponding FW PR for this change? |
plbossart
left a comment
plbossart
left a comment
There was a problem hiding this comment.
Thanks @dragosht. Multiple configurations is really a must-have so I am really supportive of this effort.
That said, I must admit I am a tad lost on the suggested solution. Passing all the configurations to firmware does require that the firmware be able to store all the configs, and information on how many configs are valid, which probably requires an ABI change. Also it's not clear to me how a config would be selected, this may be done probably only at hw_params time so there are clearly additional steps required.
| config->hdr.cmd, | ||
| config, | ||
| config->hdr.size, | ||
| &reply, sizeof(reply)); |
There was a problem hiding this comment.
Right there I don't understand how this patch would work. There is nothing in the config that is passed to the firmware that identifies it uniquely, so how would we select one in hw_params? Don't we need a lot more logic than just passing N configs instead of 1? And don't we need a matching PR for firmware to store these configs?
|
@ranj063 No, I have not yet issued a PR on the firmware side. I have some changes available, but they still need some work. I just figured I would start on the driver side first to also collect some feedback on the topic. But yes, the idea was to have all these configs also stored within the dai. And yes, the firmware would currently just send each config down to the corresponding driver for the dai overwriting the previous one. |
@plbossart Thank you for the feedback. I'm aware the firmware also needs to be reworked for keeping up with these configs. I also have some patches on the firmware side, but I still have some reworks to do on those. I haven't actually thought about selecting a config in hw_params, but instead having an enumerated kcontrol for the dai allowing the user to manually do the switch. I think this would touch the ASoC core though, as those dai widgets don't have kcontrols enabled at this point. As for the ABI change in this approach, I was thinking that I would probably need some field within the ipc_dai_config to mark the currently active configuration to be set by the firmware. |
If multiple hw_configs are currently being provided from the topology, the driver only keeps the default one and ignores the rest. This patch changes that by storing them all and also sending all of those to the firmware. Signed-off-by: Dragos Tarcatu <dragos_tarcatu@mentor.com>
If multiple hw_configs are currently being provided from the topology,
the driver only keeps the default one and ignores the rest. This patch
changes that by storing them all and also sending all of those to the
firmware.
Signed-off-by: Dragos Tarcatu dragos_tarcatu@mentor.com