[RFC] Reorganizing HD-audio driver code?

[Takashi Iwai <tiwai@suse.de>]

Hi,

HD-audio driver is known to be quite messy in both file structures and
its design, but until now I haven't touched its files paths so much
because I set a higher priority for the easiness of backport to stable
kernels.  But, you can't leave garbages forever, it's been already
high time for a large clean up.

So I tried a quick code reorganization, and put the result in
test/hda-reorg branch of sound.git tree.
  https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=test/hda-reorg

The basic idea is to move the code from sound/pci/hda/* into different
subdirectories in sound/hda/ per functionality, as most of the stuff
are independent from PCI, but rather HD-audio bus specific.

After the changes, the HD-audio root directory looks like:

  % ls sound/hda 
  codecs/  common/  controllers/  core/  Kconfig  Makefile

The current HD-audio core code is moved to sound/hda/core/*.
The common snd-hda-codec driver code is moved into
sound/hda/common/*.
The controller code (snd-hda-intel, snd-hda-tegra, snd-hda-acpi) are
moved into sound/hda/controllers/*.
And the codecs are moved to sound/hda/codecs/*.

The core code is almost same as now but I dropped the ugly hdac_
prefix from the filenames:

  % ls sound/hda/core
  array.c       device.c        i915.c              Kconfig   stream.c
  bus.c         ext/            intel-dsp-config.c  local.h   sysfs.c
  component.c   hda_bus_type.c  intel-nhlt.c        Makefile  trace.c
  controller.c  hdmi_chmap.c    intel-sdw-acpi.c    regmap.c  trace.h

  % ls sound/hda/core/ext
  bus.c  controller.c  Makefile  stream.c

The code of snd-hda-codec library module is found in common directory:

  % ls sound/hda/common
  auto_parser.c  controller.c        hda_controller.h  jack.c    sysfs.c
  beep.c         controller_trace.h  hda_jack.h        Kconfig
  bind.c         hda_auto_parser.h   hda_local.h       Makefile
  codec.c        hda_beep.h          hwdep.c           proc.c

Again, the hda_ prefix is dropped from most of files.  The headers
still contain hda_ prefix because otherwise it can be confusing at
including from others.

The controller driver code looks like:

  % ls sound/hda/controllers
  acpi.c  intel_trace.h  intel.c  intel.h  Kconfig  Makefile  tegra.c

And the codec driver code looks like:

  % ls sound/hda/codecs
  analog.c       cmedia.c         eld.c      Kconfig       side-codecs/
  ca0110.c       conexant.c       generic.c  Makefile      sigmatel.c
  ca0132.c       cs8409.c         generic.h  realtek/      via.c
  ca0132_regs.h  cs8409.h         hdmi.c     senarytech.c
  cirrus.c       cs8409-tables.c  helpers/   si3054.c

The Realtek codec is split further to smaller pieces (which was really
huge).

  % ls sound/hda/codecs/realtek
  alc260.c  alc268.c  alc662.c  alc861.c    alc880.c  Kconfig   realtek.c
  alc262.c  alc269.c  alc680.c  alc861vd.c  alc882.c  Makefile  realtek.h

Other drivers like Sigmatel/IDT driver might be worth to split, too.

The Cirrus and TI sub-codec drivers are moved to codecs/side-codecs
subdirectory:

  % ls sound/hda/codecs/side-codecs
  cirrus_scodec.c         cs35l41_hda_property.h  hda_component.h
  cirrus_scodec.h         cs35l41_hda_spi.c       Kconfig
  cirrus_scodec_test.c    cs35l56_hda.c           Makefile
  cs35l41_hda.c           cs35l56_hda.h           tas2781_hda.c
  cs35l41_hda.h           cs35l56_hda_i2c.c       tas2781_hda.h
  cs35l41_hda_i2c.c       cs35l56_hda_spi.c       tas2781_hda_i2c.c
  cs35l41_hda_property.c  hda_component.c         tas2781_hda_spi.c

They can be put to each own directory and drop the file name prefix,
if we want, too.  Let me know if Cirrus and TI people would like to
split to more subdirectories.

Finally, the helper code that is included from the codec driver is put
under codecs/helpers subdirectory (with drop of superfluous suffix):

  % ls sound/hda/codecs/helpers
  hp_x360.c  ideapad_hotkey_led.c  ideapad_s740.c  thinkpad.c

So far, so good; all looks better organized.
I planned for further driver code modernization, and this code
reorganization makes it easier, too.

*HOWEVER* the biggest question is: whether it's worth?

Essentially, this makes almost impossible to make a patch for stable
trees from the original commit as is; one has to translate the file
paths and adjust manually in each patch.

Also, of course, if anyone is working on HD-audio stuff right now, the
work had to be adjusted to the new file path.  It'd be one-off action,
though.

Any thoughts / opinions?


thanks,

Takashi