Add memory usage scan possibility

[ktrzcinx]

Such an mechanism may be used to monitor memory utilization and memory leaks.

Possible memory leaks tracking was main motivation for this mechanism. To scan them, memory usage should be scanned before topology creation, then some functional test should be done, topology deletion and iterate whole process a few times - when memory usage grows, then some memory leak is present. To efficiently track memory leaks, memory utilization must be scanned at strictly defined moments in FW life-cycle, it's why scan should be done on host request instead regular memory utilization printing (eq. in trace system).

FW part: thesofproject/sof#3389

[plbossart]

Great idea. I think we need to enable this mode by taking a reference to the device so as to prevent pm_runtime suspend, e.g.

echo 1 > /sys/bus/pci/..../mem_info_enable
cat /sys/bus/pci/..../mem_info
cat /sys/bus/pci/..../mem_info
cat /sys/bus/pci/..../mem_info
echo 0 > /sys/bus/pci/..../mem_info_enable

[lyakh]

looks correct to me now

[fredoh9]

LGTM but one thing I'd like to make sure we agree upon this difference.
There is no LAST_ELEM in kernel header, which is different from SOF FW header. Hence the array size is remained variable struct config_elem elems[];

Updated: I read late further discussion in
thesofproject/sof#3527
If we can add comments in firmware header, actually I like this idea.

[kv2019i]

Thanks @ktrzcinx , looks good now!

[kv2019i]

Oops, these checkpatch things would be nice-to-fix as well.

[xiulipan]

Thanks for the update. manually test pass on APL UP2 board.
IPC dmesg logs and debugfs output all look nice.

[ 58.540955] sof-audio-pci 0000:00:0e.0: ipc tx: 0xd0010000: GLB_DEBUG: MEM_USAGE
[ 58.541049] sof-audio-pci 0000:00:0e.0: ipc tx succeeded: 0xd0010000: GLB_DEBUG: MEM_USAGE

/sys/kernel/debug/sof# cat memory_info
zone 0.0 used 0x2340 free 0x5cc0
zone 1.0 used 0xf00 free 0x4100
zone 2.0 used 0x7500 free 0x6300
zone 3.0 used 0x9200 free 0x6e00
zone 3.1 used 0x0 free 0x20000

[lyakh]

I know this has been discussed and I know the reasons and I don't have a good universal solution, but having different (compatible) struct definitions in the kernel and the firmware still feels uncomfortable to me...

[kv2019i]

@lyakh I think that's a fair point. One one hand, we could have a more strict approach of defining the ABI with a separate formal description (we've started to documents some bits with doxygen notation in FW headers), but in practise the current model has been fairly effective. So for now, any exception needs to be agreed separately, but e.g. in this case, after a lot of back and forth, this seems to be best candidate.

[plbossart]

@kv2019i I'll let you merge if you feel this is good enough.

[kv2019i]

Thanks all, looks ready for merge. Checkpatch issues are related to uint32 usage which we do allow. One travis failure unrelated to the PR and one CI device test failure is the known DRM warning (already filtered in latest sof-test):
"[ 1017.783841] [drm:drm_dp_send_link_address [drm_kms_helper]] ERROR Sending link address failed with -5"
So all good. Thanks @ktrzcinx !