Consolidate sc5xx-sport drivers

[pamolloy]

There are two ADSP SPORT drivers in the ADSP series; sound/soc/adi/sc5xx-sport-sharc.c and sound/soc/adi/sc5xx-sport.c. Kconfig is used to make sure only one is selected at once. One where Linux controls the SPORT and one for the SHARC. This functionality should likely be in a single driver and configured using devicetree. Besides not adhering to mainline best practices, it breaks the build because we cannot build both drivers in one build, we would need two full builds just to make sure both drivers are built.

Found by @gastmaier and initially reported in #3332.

[sipraga]

I don't think it should be a single driver, since it then forces the user to compile dead code into his kernel (including remoteproc if SHARC ICC is unused). But yes, it should still be possible to compile both. Any common code can be put in a separate module (e.g. sc5xx-sport-common) used by the two driver modules.

I think the SPORT driver needs quite a bit of love anyway. @pamolloy here are some notes I made already but I can split it into a separate issue if you want:

1 SPORT ASoC driver
═══════════════════

  Some thoughts


1.1 #sound-dai-cells = <0> or <1>?
──────────────────────────────────

  Well, from experience it's often desirable to be able to set a
  different DAI format on RX and TX, so I'd go for <1>. That means one
  is Playback only and the other Capture only.

  If you want 4 pins in the same direction, just use another half-SPORT
  from a different top-SPORT and do PCM group/linking.

  Splitting it means you can also have different clock consumer/provider
  roles. Let's not make the same mistake NXP did!


1.2 pinctrl
───────────

  • DAPM has a pinctrl widget which can be used to set up the SRU as
    required

  • For non-DPCM use-cases this can specified in DT as "active" and
    "sleep" pinctrl-names. But without changes to simple-card-utils, the
    onus is on the SPORT driver to set this in its PM routines. See
    stm32_sai.c for an example. fsl,sai also does this I think.

  • This means the SRU can be reconfigured depending on which peripheral
    is being used. Quite a lot of potential here!


1.3 clocks
──────────

  • Top-SPORT seems to always need SCLK1 enabled.

  • PCG clock enablement on PCM start: simple-card-utils picks up the
    first "clocks" property if specified in the cpu node of
    simple-audio-card, or in the port node for audio-graph-card2. Note
    that in simple-audio-card it's probably not granular enough to have
    separate PCG per half-SPORT. For graph card I think it can be put in
    the port endpoint, where the utils will pick it up.

  • Alternatively DAPM also has a clock supply.


2 SC5xx ASoC machine driver
═══════════════════════════

  Machine driver *might* be necessary for SHARC offload, but for the
  Linux-only case it should be totally possible to use simple-audio-card
  or audio-graph-card2 with the SPORT driver. I think everything in
  sc5xx-asoc-card.c can be removed and replaced with DT. Makes for
  better customer experience when prototyping their own board or playing
  with the eval kits too.

[nunojsa]

I don't think it should be a single driver, since it then forces the user to compile dead code into his kernel (including remoteproc if SHARC ICC is unused).

It depends. I don't really know the HW to opinate much but here it goes some generic thoughts.

If they are really different enough or for example with two different interfaces, then yes, what you're saying above is the common practice. Think chips that have both spi and i2c interfaces. What we then have are two drivers and a core/common one that's used by the other two.

Having said the above, you can also have both in the same driver and have one of the pieces as a different source file protected by a kconfig option. Think complex drivers like gpus with multiple files (where some of them are controlled by kconfig). So same driver with a compiled in (or out) additional feature.

I think the SPORT driver needs quite a bit of love anyway

Unfortunately, most of them need :).

[sipraga]

Having said the above, you can also have both in the same driver and have one of the pieces as a different source file protected by a kconfig option. Think complex drivers like gpus with multiple files (where some of them are controlled by kconfig). So same driver with a compiled in (or out) additional feature.

Yes good point, you can flip it around that way too. OK, it's marginally less flexible in that I can't, for example, make the Linux-only support a kernel built-in while having SHARC-mode as a module. But I guess the best approach will become apparent when actually making the changes.

It would be neat if both modes could be compiled in, and both described in DT, and both accessible at runtime, perhaps with an -EBUSY of some kind if the SPORT is already in use by the latter implementation. Something to think about...

I think the SPORT driver needs quite a bit of love anyway

Unfortunately, most of them need :).

Fun :D

[nunojsa]

It would be neat if both modes could be compiled in, and both described in DT, and both accessible at runtime, perhaps with an -EBUSY of some kind if the SPORT is already in use by the latter implementation. Something to think about...

Yeah, DT can always be used to add that kind of control