config: tgl-cavs: add kpb, selector and kd support

[libinyang]

Add KPB, Selector and KD module config

Signed-off-by: Libin Yang libin.yang@intel.com

[aiChaoSONG]

@libinyang the smart amp rimage PR is merged, you can do the rebase now.

[libinyang]

patch update based on the latest code. This PR conflicts with https://github.com/thesofproject/rimage/pull/124. Whichever PR is merged, the other PR should be rebased.

[lgirdwood]

@libinyang #124 now merged, so will need a rebase.

[libinyang]

patch updated based on the latest code.

[libinyang]

One question unrelated to this PR: I found that the module_type IDs for each module in tgl are not exactly same as the IDs in mtl. Do we have plan to make them be the same, which is suggested in https://github.com/thesofproject/rimage/pull/117/commits/9802166b7c0f8430298c02736658472ca528d5c3?

[lgirdwood]

@RanderWang @libinyang can we align to modules types in MTL. i.e. fix the TGL types. @ujfalusi @ranj063 any kernel impact ?

[lgirdwood]

@plbossart any comments of IDs or new updates ?

[RanderWang]

we need to align it to the following definition which are defined by latest windows driver. This type is only used by windows driver. Linux driver uses uuid to identify module

enum mod_type {
        ebasefw = 0,
        emixin,
        emixout,
        ecopier,
        epeakvol,
        eupdwmix,
        emux,
        esrc,
        ewov,
        efx,
        eaec,
        ekpb,
        emicselect,
        efxf,   /*i.e.SmartAmp */
        eaudclass,
        efakecopier,
        eiodriver,
        ewhm,
        egdbstub,
        esensing,
        emax,
        einvalid = emax
} ;

[libinyang]

PR updated Chao has submitted a patch to align the module_types. update the patch based on the latest code

[lgirdwood]

we need to align it to the following definition which are defined by latest windows driver. This type is only used by windows driver. Linux driver uses uuid to identify module

enum mod_type {
        ebasefw = 0,
        emixin,
        emixout,
        ecopier,
        epeakvol,
        eupdwmix,
        emux,
        esrc,
        ewov,
        efx,
        eaec,
        ekpb,
        emicselect,
        efxf,   /*i.e.SmartAmp */
        eaudclass,
        efakecopier,
        eiodriver,
        ewhm,
        egdbstub,
        esensing,
        emax,
        einvalid = emax
} ;

@plbossart does kernel care about any of these ? or can the value be passed directly to FW without any kernel logic ?

[kv2019i]

@RanderWang @lgirdwood I don't think the module_type now has impact, but we definitely need to write down the semantics , e.g. in https://github.com/thesofproject/sof-docs/pull/451/commits/3209a52636e8a20082f4354e7dc45bf6305f4d38

[lgirdwood]

@plbossart ping ?

[libinyang]

@plbossart ping ?

@lgirdwood As @kai mentioned, it seems module_type doesn't have impact currently and my test supports Kai's conclusion. Anyway, I think we should set the module_type correctly in rImage in case we enable the module_type later to align with Windows behavior.