dai: host: copier: component: New pipeline latency calculation algorithm

[softwarecki]

The main goal of this PR is to update the algorithm of pipeline latency calculation. It is based on the number of buffered data blocks between the first and last component.

For this purpose, I have added a new function to the component's api that allows to read the total number of processed data by it. Then, I introduced total_data_processed counter in dai_data and host_data structure. The counters of processed data has been moved from a component device structure to the components private data. Finally I removed the position field from comp_dev structure which become unused. This field was ambiguous - it was not known whether it mean consumed or produced data. I added a similar processed data counters to the Copier module.

In the future, the stamping of start and stop of the pipe will be moved to MixIn component. I have some made preparations for this process in the Copier module. I added reading the dma index using the get_attribute function and reading the gateway position using the position method.

By the way, I cleaned the dai structure from unused fields: dai_pos, dai_pos_blks and start_position.

Changed a declaration of node_id in ipc4_copier_gateway_cfg to use a aproprietary type. This change makes easier to reference the node_id field. Thanks to it, you don't have to wonder what type the value should be casted. It make our work easier and minimize the risk of a mistake.

The ipc_get_ppl_comp function has been simplified by removing the duplicate loop. Now the component list is only reviewed once and both conditions are checked simultaneously.

Created new function comp_get_base_module_cfg for ipc4 which allows to get component's base configuration. This function is still access a component's private data in ugly way but it allows solve this issue easier in the future.

[lgirdwood]

Looks ready, juts need some more inline comments in some places. It wpould be good if we could check the need for 64bit values if we can use 32bit (given 32bit is much cheaper on xtensa).

[lgirdwood]

Btw, since this is allowed to overflow why not use a cheaper 32bit value ? This would overflow at 6.5 hrs with 16bit 48kHz stereo. Could be a optimization if we dont require 64bit values on the host.

Fwiw, ALSA really just cares about the buffer position (and this is allowed to overflow back to 0), so it does not need 64bit values.

Please check for Windows though, no idea if Windows requires a 64bit value here.

[marc-hb]

For the record the following regression was bisected to one commit in this PR:

• [BUG] ipc tx error for 0x60010000 when testing playback on APL_UP2_PCM512X #6003