On 2021-10-19 11:16 AM, Kai Vehmanen wrote:
Hey,
On Mon, 18 Oct 2021, Cezary Rojewski wrote:
HDAudio-extended bus initialization parts are scattered throughout Intel ADSP drivers code. Gather them up in snd_hda_ext_bus_init() to provide unified initialization point.
[...]
--- a/sound/hda/ext/hdac_ext_bus.c +++ b/sound/hda/ext/hdac_ext_bus.c
[..]
-int snd_hdac_ext_bus_init(struct hdac_bus *bus, struct device *dev,
const struct hdac_bus_ops *ops,const struct hdac_ext_bus_ops *ext_ops)+int snd_hda_ext_bus_init(struct hda_bus *bus, struct pci_dev *pdev,
const struct hdac_bus_ops *ops,const struct hdac_ext_bus_ops *ext_ops,const char *model)[...]
- bus->idx = 0;
- bus->cmd_dma_state = true;
- base->idx = 0;
- base->cmd_dma_state = true;
- base->use_posbuf = 1;
- base->bdl_pos_adj = 0;
- base->sync_write = 1;
- bus->pci = pdev;
- bus->modelname = model;
- bus->mixer_assigned = -1;
- mutex_init(&bus->prepare_mutex);
hmm. It's not clear whether we should initialize the regular hdac_bus fields in the ext_bus_init(). For plain HDA, these are also initialized in the caller. E.g. in sound/pci/hda/hda_controller.c.
So if we start cleaning up, should we go further put this in snd_hdac_bus_init()?
Then another is what is the right place for settings like "sync_write = 1". While this settings applies to all current users of the extended bus, this is really hw specific setting and not really a property of the extended bus, so this feels a bit out-of-place.
I'm rather in favor of bigger cleanups. We can definitely move further in the future : )
Notice that some 'core' field are being initialized in snd_hda_ext_bus_init() for a very long time. The problem with moving all 'core' bits to snd_hdac_bus_init() is that some of these are not 1:1 between ASoC and ALSA hda-drivers. Also, hda_tegra differs from hda_intel too. I could update said function while not removing any assignments which differ from the default. Maybe let's just go for it..
TLDR: treat snd_hdac_bus_init() as function initializing fields with defaults. Any you don't like? Change after its invocation.
BTW, I don't see any problems with ->sync_write=1 as from software perspective it is a bus property. Otherwise, interface change is required to reflect this 'misleading' information.
Regards, Czarek