refine multi-core support

[keyonjie]

At the moment, the DSP multi-core support is chaos:

1. We send SOF_IPC_PM_CORE_ENABLE with the enabled_cores_mask to FW when a new core should be enabled, and FW will iterate all cores to check which do corresponding switching, this is in low efficiency, our use case is enable/disable one core only each time.
   suggestion: change IPC to use core_index + enable/disable as params.

2. We do power on/off pipeline->core for each pipeline loading/unloading, without checking the power status of the corresponding core, this will lead to bandwidth/efficiency waste only in FW side, but it doing real multiple power on/off on driver side(see dmesg log on the bottom), this need to be fixed.

3. It would be better to add ref_cnt for each DSP core, after booted, core0.ref_cnt = 1, ref_cnt of other cores set to be 0. Increase ref_cnt at each pipeline_load(or task load in the future), power up the DSP core when changing from 0->1; Decrease ref_cnt at each pipeline_unload(or task unload in the future), power down the core when changing from 1->0.

[ 1506.427122] input: sof-skl_hda_card Mic as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input569
[ 1506.427185] input: sof-skl_hda_card Headphone as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input570
[ 1506.427241] input: sof-skl_hda_card HDMI/DP, pcm=11 Jack as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input571
[ 1506.427296] input: sof-skl_hda_card HDMI/DP, pcm=12 Jack as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input572
[ 1506.427349] input: sof-skl_hda_card HDMI/DP, pcm=13 Jack as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input573
[ 1506.427556] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0x1010f0f successful
[ 1506.427565] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0x1000f0f successful
[ 1506.427569] sof-audio-pci 0000:00:1f.3: DSP core(s) enabled? 0 : core_mask 1
[ 1506.427584] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427592] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427596] sof-audio-pci 0000:00:1f.3: DSP core(s) enabled? 0 : core_mask 1
[ 1506.427608] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427615] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427620] sof-audio-pci 0000:00:1f.3: DSP core(s) enabled? 0 : core_mask 1
[ 1506.427634] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427649] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427653] sof-audio-pci 0000:00:1f.3: DSP core(s) enabled? 0 : core_mask 1
[ 1506.427664] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427727] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427733] sof-audio-pci 0000:00:1f.3: DSP core(s) enabled? 0 : core_mask 1
[ 1506.427745] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427753] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427757] sof-audio-pci 0000:00:1f.3: DSP core(s) enabled? 0 : core_mask 1
[ 1506.427767] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427774] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427777] sof-audio-pci 0000:00:1f.3: DSP core(s) enabled? 0 : core_mask 1
[ 1506.427788] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427795] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427799] sof-audio-pci 0000:00:1f.3: DSP core(s) enabled? 0 : core_mask 1
[ 1506.427809] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427816] sof-audio-pci 0000:00:1f.3: FW Poll Status: reg=0xf0f successful
[ 1506.427819] sof-audio-pci 0000:00:1f.3: DSP core(s) enabled? 0 : core_mask 1

[lyakh]

What are the actual reasons for such a tight core enabling control from the driver? Is it just to remove some complexity from the FW and keep it on the host, or are there good practical reasons for that?

[kv2019i]

Summing up a long email discussion. It would seem to debug (and get FW DMA traces for) invalid topologies, especially bullet (3) would be very useful:
"3. It would be better to add ref_cnt for each DSP core, after booted, core0.ref_cnt = 1,"

With current code, some serious hacking is needed to do debug that should be a fairly
common need for anyone developing new topologies.

[plbossart]

@keyonjie isn't this implemented already?

[keyonjie]

@keyonjie isn't this implemented already?

Don't think so, at least the ref_cnt for each DSP core not added. I submitted #2850 and then @ranj063 took over of this.

I think @ranj063 haven't had chance to do this yet?

[plbossart]

@ranj063 can you please comment? what remains to be done here?