Skip to content

SOF client support (auxiliary bus)#3007

Closed
ujfalusi wants to merge 32 commits intothesofproject:topic/sof-devfrom
ujfalusi:peter/sof/pr/sof_clients_02
Closed

SOF client support (auxiliary bus)#3007
ujfalusi wants to merge 32 commits intothesofproject:topic/sof-devfrom
ujfalusi:peter/sof/pr/sof_clients_02

Conversation

@ujfalusi
Copy link
Copy Markdown
Collaborator

Hi,

this series is relatively big departure from previous versions (the latest was #2836 from me).
The high level concept is:

  • SOF client are auxiliary devices / drivers (sof_client_drv level is dropped)
  • The API used by clients are going to be sof_client_*
    • we will add new ones as the need emerges
  • platform dependent and dynamic information can be passed to the client driver via standard device platform_data
  • platform dependent static information, parameters which can be local to the client driver can be propagated via match with different device name.
  • In case the platform needs host side software control like HDA does, the platform_data is the place to give the ops to the client driver along with a parameter that the callbacks should be called with (void *host_data) and it is up to the host side code to cast it to what it is using internally.
    • see the sof-client-probes and hda-probes pair.

Dropped most of the reviewed-by, tested-by tags since not much is intact from the original versions, but I have kept @ranj063 as author where she was and @fredoh9 as co-author.
I have tested the IPC flood test with 3 instance and the probes on my TGL-H HDA device, all works correctly.

Reasons for a draft status:

  • the sound card created by the probes takes card0 with a single compr, the normal audio card is enumerated as card1
    • I want to find a way to keep the audio card as card0 and have the probes at card1
    • I'm not sure if this actually matters.
  • I have tried to split up the probes conversion patch (last one), but I just don't see how it can be done in a bisectable way
  • I might have missed some of the comments for the previous approach, but I have tried, some of them no longer applicable
  • I want to see if I can also move the trace support out as a client as next step.

Next steps:

  • split up the snd_sof_dsp_ops into chunks for the really core DSP/Firmware management, communication and audio, trace to prepare for the audio support client conversion.
  • abstract away all platform specific members from snd_sof_pdata, sof_dev_desc, snd_sof_dev and other structures under a void * and make them only visible for the platform they are actually used (whenever it is possible)
  • IO function abstraction break up
  • work towards full client based setup of SOF.

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants