Repository navigation
Copier: preparation work for convert copier to module interface - #7740
Conversation
91196fc to
222ca47
Compare
87556ea to
d5ead7c
Compare
There was a problem hiding this comment.
will it all fit in one line?
There was a problem hiding this comment.
can we move this inside case SOF_COMP_DAI: for the multiendpoint case?
There was a problem hiding this comment.
will move once all CI passed.
There was a problem hiding this comment.
for the module copier, will cd->endpoint_num ever be > 0?
There was a problem hiding this comment.
it should be 0, also the type is NONE, neither host nor dai.
There was a problem hiding this comment.
endpoint_num will always be 0 for module copier
There was a problem hiding this comment.
and instead of checking for bsource_buffer, I'd check the cd->direction
There was a problem hiding this comment.
ok, let's remove this part of code, since only endpoint copy need add this data.
There was a problem hiding this comment.
this will likely run into compilation issues because this function is unused. Either you need to call this from copier_copy() or you need convert to module_interface in this patch
There was a problem hiding this comment.
yes, right way is add all left code into this patch.
dfd81d5 to
abf7ed6
Compare
There was a problem hiding this comment.
I'm wondering why some .set_configuration() methods invalidate cache and others don't? If it's needed, maybe it should be done centrally in module_set_large_config()? @ranj063
0daed68 to
61bdee1
Compare
0d06602 to
6a049b3
Compare
There was a problem hiding this comment.
@btian1 if you're going to do this, I think we can go further and remove do_enpoint_copy() altogether isnt it? Maybe we can do this ina follow up PR
There was a problem hiding this comment.
I use last patch to remove all do_endpoint_copy, please have a check.
6a049b3 to
16d2cfe
Compare
lyakh
left a comment
There was a problem hiding this comment.
mostly looks good to me, just one doubt about a potential change in behaviour and a couple of minor comments
There was a problem hiding this comment.
this is an unusual name for a "configuration" variable?
There was a problem hiding this comment.
followed module_adapter_new, we can change use another patch to unify those usages.
There was a problem hiding this comment.
ack, dst is usually used as a destination pointer. We use source or sink, so I would rename to sink_config if this is configuration data for a destination module. If its our local configuration then call it config.
There was a problem hiding this comment.
ok, line 68 already have config named, for avoid confusing, I removed this variable.
There was a problem hiding this comment.
how about just md->cfg.init_data = spec and remove dst. Or even mod->priv.cfg.init_data = spec and remove both md and dst
There was a problem hiding this comment.
In assembly level, there is no difference at all for both implementation.
There was a problem hiding this comment.
Yes, dst is confusing name for me.
There was a problem hiding this comment.
@lyakh @lgirdwood , use md->cfg.init_data = spec to remove dst usage, mod->priv.cfg.init_data = spec this is a little long, I prefer use md->cfg.init_data = spec.
There was a problem hiding this comment.
In assembly level, there is no difference at all for both implementation.
Sure, but we aren't programming in assembly. There are many ways to write code in C to generate the same assembly output. You can name your variables a1, a2 etc. but that's not how we're programming
There was a problem hiding this comment.
fully agree, please review the changes, and let me know if you still have further comments.
There was a problem hiding this comment.
what was wrong with the original line 637?
There was a problem hiding this comment.
you are right, nothing changed, let me change back, don't remember why have this change.
577de5c to
86019ec
Compare
There was a problem hiding this comment.
ack, dst is usually used as a destination pointer. We use source or sink, so I would rename to sink_config if this is configuration data for a destination module. If its our local configuration then call it config.
There was a problem hiding this comment.
Yes, dst is confusing name for me.
Set dev private as module interface, create new copier_init to meet module interface requirement, and change all copier_data related code. Signed-off-by: Baofeng Tian <baofeng.tian@intel.com>
Add new function to implement free and reset module interface. Signed-off-by: Baofeng Tian <baofeng.tian@intel.com>
Use module parameter instead of device parameters. Signed-off-by: Baofeng Tian <baofeng.tian@intel.com>
Use standard module set and get config interface in copier. Signed-off-by: Baofeng Tian <baofeng.tian@intel.com>
Convert copier unbind to module interface. Signed-off-by: Baofeng Tian <baofeng.tian@intel.com>
86019ec to
e0f6e19
Compare
e0f6e19 to
5a1331a
Compare
This will be used to separate multi-endpoint DAI copy from the module copier copy. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Baofeng Tian <baofeng.tian@intel.com>
In preparation for converting the copier to use the module interface, split up the multi-endpoint DAI copy and the module copier copy cases. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Baofeng Tian <baofeng.tian@intel.com>
It is only used in the multi-endpoint case, so use the multi_endpoint_buffer directly. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Baofeng Tian <baofeng.tian@intel.com>
This is 1ms function calling, remove one more layer to get better performance. Signed-off-by: Baofeng Tian <baofeng.tian@intel.com>
lyakh
left a comment
There was a problem hiding this comment.
we can address the comments in a follow-up, and the problem with the .init_data is larger than just the copier
| */ | ||
| if (memcpy_s(&cd->config, sizeof(cd->config), copier, sizeof(*copier)) < 0) | ||
| goto error_cd; | ||
| if (memcpy_s(&cd->config, sizeof(cd->config), copier, sizeof(*copier)) < 0) { |
There was a problem hiding this comment.
actually it would be better to propagate the error:
ret = memcpy_s(&cd->config, sizeof(cd->config), copier, sizeof(*copier));
if (ret < 0)
goto error;
Can be done in a follow up, unless you anyway submit an update to this PR
| comp_cl_err(&comp_copier, "pipeline %d is not existed", config->pipeline_id); | ||
| goto error_cd; | ||
| comp_err(dev, "pipeline %d is not existed", config->pipeline_id); | ||
| ret = -EPIPE; |
There was a problem hiding this comment.
I think EPIPE means "broken pipeline." Here it's more like ENODEV / ENOENT?
| comp_set_drvdata(dev, mod); | ||
| md = &mod->priv; | ||
| mod->dev = dev; | ||
| md->cfg.init_data = spec; |
There was a problem hiding this comment.
we should remove all these. spec points to the mailbox, data there will change, so storing a pointer to it isn't a good idea. The module adapter does that too and has to be fixed as well.
| break; | ||
| case SOF_COMP_DAI: | ||
| if (cd->endpoint_num == 1) | ||
| return dai_common_copy(cd->dd[0], dev, cd->converter); |
There was a problem hiding this comment.
this case is already handled somewhere, right?
@lgirdwood yes already approved |
No description provided.