* [RFC PATCH 0/3] Add ASoC platforms directory
@ 2017-12-05 18:14 ` Andrew F. Davis
0 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-05 18:14 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown; +Cc: alsa-devel, linux-kernel, Andrew F . Davis
Hello all,
The first patch, I think, sums up well what I'm trying to do
here with this series. The last two are a couple examples
of what the moving would look like.
The very end result would look something like:
soc/
|_codecs/
|_codecs*.c
|_platforms/
|_adi/
|_adi_i2s.c
|_...
|_amd/
|_.../
|_machines/
|_amd/
|_acp-rt5645.c
|_...
|_atmel/
|_.../
|_core_files*.c
I would like to think the churn is minimal for this as git
seems to handles renaming like this rather well, but I guess that
is up to the maintainers. :)
Thanks for your comments,
Andrew
Andrew F. Davis (3):
ASoC: Add platforms directory
ASoC: Platforms: Move Davinci platform drivers into platforms
directory
ASoC: Platforms: Move OMAP platform drivers into platforms directory
MAINTAINERS | 1 +
sound/soc/Kconfig | 3 ++
sound/soc/Makefile | 1 +
sound/soc/davinci/Kconfig | 37 -----------------------
sound/soc/davinci/Makefile | 21 +++----------
sound/soc/omap/Kconfig | 29 ------------------
sound/soc/omap/Makefile | 13 --------
sound/soc/omap/am3517evm.c | 2 +-
sound/soc/omap/ams-delta.c | 2 +-
sound/soc/omap/n810.c | 2 +-
sound/soc/omap/omap-abe-twl6040.c | 4 +--
sound/soc/omap/omap-twl4030.c | 2 +-
sound/soc/omap/omap3pandora.c | 2 +-
sound/soc/omap/osk5912.c | 2 +-
sound/soc/omap/rx51.c | 2 +-
sound/soc/platforms/Kconfig | 10 ++++++
sound/soc/platforms/Makefile | 4 +++
sound/soc/platforms/davinci/Kconfig | 36 ++++++++++++++++++++++
sound/soc/{ => platforms}/davinci/Makefile | 5 ---
sound/soc/{ => platforms}/davinci/davinci-i2s.c | 0
sound/soc/{ => platforms}/davinci/davinci-i2s.h | 0
sound/soc/{ => platforms}/davinci/davinci-mcasp.c | 0
sound/soc/{ => platforms}/davinci/davinci-mcasp.h | 0
sound/soc/{ => platforms}/davinci/davinci-vcif.c | 0
sound/soc/{ => platforms}/davinci/edma-pcm.c | 0
sound/soc/{ => platforms}/davinci/edma-pcm.h | 0
sound/soc/platforms/omap/Kconfig | 28 +++++++++++++++++
sound/soc/platforms/omap/Makefile | 13 ++++++++
sound/soc/{ => platforms}/omap/mcbsp.c | 0
sound/soc/{ => platforms}/omap/mcbsp.h | 0
sound/soc/{ => platforms}/omap/omap-dmic.c | 0
sound/soc/{ => platforms}/omap/omap-dmic.h | 0
sound/soc/{ => platforms}/omap/omap-hdmi-audio.c | 0
sound/soc/{ => platforms}/omap/omap-mcbsp.c | 0
sound/soc/{ => platforms}/omap/omap-mcbsp.h | 0
sound/soc/{ => platforms}/omap/omap-mcpdm.c | 0
sound/soc/{ => platforms}/omap/omap-mcpdm.h | 0
sound/soc/{ => platforms}/omap/omap-pcm.c | 0
38 files changed, 110 insertions(+), 109 deletions(-)
rewrite sound/soc/davinci/Makefile (71%)
create mode 100644 sound/soc/platforms/Kconfig
create mode 100644 sound/soc/platforms/Makefile
create mode 100644 sound/soc/platforms/davinci/Kconfig
copy sound/soc/{ => platforms}/davinci/Makefile (76%)
rename sound/soc/{ => platforms}/davinci/davinci-i2s.c (100%)
rename sound/soc/{ => platforms}/davinci/davinci-i2s.h (100%)
rename sound/soc/{ => platforms}/davinci/davinci-mcasp.c (100%)
rename sound/soc/{ => platforms}/davinci/davinci-mcasp.h (100%)
rename sound/soc/{ => platforms}/davinci/davinci-vcif.c (100%)
rename sound/soc/{ => platforms}/davinci/edma-pcm.c (100%)
rename sound/soc/{ => platforms}/davinci/edma-pcm.h (100%)
create mode 100644 sound/soc/platforms/omap/Kconfig
create mode 100644 sound/soc/platforms/omap/Makefile
rename sound/soc/{ => platforms}/omap/mcbsp.c (100%)
rename sound/soc/{ => platforms}/omap/mcbsp.h (100%)
rename sound/soc/{ => platforms}/omap/omap-dmic.c (100%)
rename sound/soc/{ => platforms}/omap/omap-dmic.h (100%)
rename sound/soc/{ => platforms}/omap/omap-hdmi-audio.c (100%)
rename sound/soc/{ => platforms}/omap/omap-mcbsp.c (100%)
rename sound/soc/{ => platforms}/omap/omap-mcbsp.h (100%)
rename sound/soc/{ => platforms}/omap/omap-mcpdm.c (100%)
rename sound/soc/{ => platforms}/omap/omap-mcpdm.h (100%)
rename sound/soc/{ => platforms}/omap/omap-pcm.c (100%)
--
2.15.0
^ permalink raw reply [flat|nested] 24+ messages in thread
* [RFC PATCH 0/3] Add ASoC platforms directory
@ 2017-12-05 18:14 ` Andrew F. Davis
0 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-05 18:14 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown; +Cc: alsa-devel, linux-kernel, Andrew F . Davis
Hello all,
The first patch, I think, sums up well what I'm trying to do
here with this series. The last two are a couple examples
of what the moving would look like.
The very end result would look something like:
soc/
|_codecs/
|_codecs*.c
|_platforms/
|_adi/
|_adi_i2s.c
|_...
|_amd/
|_.../
|_machines/
|_amd/
|_acp-rt5645.c
|_...
|_atmel/
|_.../
|_core_files*.c
I would like to think the churn is minimal for this as git
seems to handles renaming like this rather well, but I guess that
is up to the maintainers. :)
Thanks for your comments,
Andrew
Andrew F. Davis (3):
ASoC: Add platforms directory
ASoC: Platforms: Move Davinci platform drivers into platforms
directory
ASoC: Platforms: Move OMAP platform drivers into platforms directory
MAINTAINERS | 1 +
sound/soc/Kconfig | 3 ++
sound/soc/Makefile | 1 +
sound/soc/davinci/Kconfig | 37 -----------------------
sound/soc/davinci/Makefile | 21 +++----------
sound/soc/omap/Kconfig | 29 ------------------
sound/soc/omap/Makefile | 13 --------
sound/soc/omap/am3517evm.c | 2 +-
sound/soc/omap/ams-delta.c | 2 +-
sound/soc/omap/n810.c | 2 +-
sound/soc/omap/omap-abe-twl6040.c | 4 +--
sound/soc/omap/omap-twl4030.c | 2 +-
sound/soc/omap/omap3pandora.c | 2 +-
sound/soc/omap/osk5912.c | 2 +-
sound/soc/omap/rx51.c | 2 +-
sound/soc/platforms/Kconfig | 10 ++++++
sound/soc/platforms/Makefile | 4 +++
sound/soc/platforms/davinci/Kconfig | 36 ++++++++++++++++++++++
sound/soc/{ => platforms}/davinci/Makefile | 5 ---
sound/soc/{ => platforms}/davinci/davinci-i2s.c | 0
sound/soc/{ => platforms}/davinci/davinci-i2s.h | 0
sound/soc/{ => platforms}/davinci/davinci-mcasp.c | 0
sound/soc/{ => platforms}/davinci/davinci-mcasp.h | 0
sound/soc/{ => platforms}/davinci/davinci-vcif.c | 0
sound/soc/{ => platforms}/davinci/edma-pcm.c | 0
sound/soc/{ => platforms}/davinci/edma-pcm.h | 0
sound/soc/platforms/omap/Kconfig | 28 +++++++++++++++++
sound/soc/platforms/omap/Makefile | 13 ++++++++
sound/soc/{ => platforms}/omap/mcbsp.c | 0
sound/soc/{ => platforms}/omap/mcbsp.h | 0
sound/soc/{ => platforms}/omap/omap-dmic.c | 0
sound/soc/{ => platforms}/omap/omap-dmic.h | 0
sound/soc/{ => platforms}/omap/omap-hdmi-audio.c | 0
sound/soc/{ => platforms}/omap/omap-mcbsp.c | 0
sound/soc/{ => platforms}/omap/omap-mcbsp.h | 0
sound/soc/{ => platforms}/omap/omap-mcpdm.c | 0
sound/soc/{ => platforms}/omap/omap-mcpdm.h | 0
sound/soc/{ => platforms}/omap/omap-pcm.c | 0
38 files changed, 110 insertions(+), 109 deletions(-)
rewrite sound/soc/davinci/Makefile (71%)
create mode 100644 sound/soc/platforms/Kconfig
create mode 100644 sound/soc/platforms/Makefile
create mode 100644 sound/soc/platforms/davinci/Kconfig
copy sound/soc/{ => platforms}/davinci/Makefile (76%)
rename sound/soc/{ => platforms}/davinci/davinci-i2s.c (100%)
rename sound/soc/{ => platforms}/davinci/davinci-i2s.h (100%)
rename sound/soc/{ => platforms}/davinci/davinci-mcasp.c (100%)
rename sound/soc/{ => platforms}/davinci/davinci-mcasp.h (100%)
rename sound/soc/{ => platforms}/davinci/davinci-vcif.c (100%)
rename sound/soc/{ => platforms}/davinci/edma-pcm.c (100%)
rename sound/soc/{ => platforms}/davinci/edma-pcm.h (100%)
create mode 100644 sound/soc/platforms/omap/Kconfig
create mode 100644 sound/soc/platforms/omap/Makefile
rename sound/soc/{ => platforms}/omap/mcbsp.c (100%)
rename sound/soc/{ => platforms}/omap/mcbsp.h (100%)
rename sound/soc/{ => platforms}/omap/omap-dmic.c (100%)
rename sound/soc/{ => platforms}/omap/omap-dmic.h (100%)
rename sound/soc/{ => platforms}/omap/omap-hdmi-audio.c (100%)
rename sound/soc/{ => platforms}/omap/omap-mcbsp.c (100%)
rename sound/soc/{ => platforms}/omap/omap-mcbsp.h (100%)
rename sound/soc/{ => platforms}/omap/omap-mcpdm.c (100%)
rename sound/soc/{ => platforms}/omap/omap-mcpdm.h (100%)
rename sound/soc/{ => platforms}/omap/omap-pcm.c (100%)
--
2.15.0
^ permalink raw reply [flat|nested] 24+ messages in thread
* [RFC PATCH 1/3] ASoC: Add platforms directory
2017-12-05 18:14 ` Andrew F. Davis
@ 2017-12-05 18:14 ` Andrew F. Davis
-1 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-05 18:14 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown; +Cc: alsa-devel, linux-kernel, Andrew F . Davis
Platform ASoC drivers are a lot like ASoC CODEC drivers in that they
both are independent pieces of a sound device, or "machine". Platform
drivers should be free of CODEC specifics and visa-versa. Both are then
used by the the "machine" driver to form the complete sound device.
This forms a hierarchy that makes it natural to group platform drivers
into their own directory, much like we group CODEC drivers already.
With this change, we will leave machine drivers in the top-level ASoC
directory and have CODECs and Platforms below. The machine drivers may
also be moved at some point into a grouping directory to further
enforce the logical separation intended by the ASoC framework.
Create the initial directory, Kconfig, and Makefile here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
sound/soc/Kconfig | 3 +++
sound/soc/Makefile | 1 +
sound/soc/platforms/Kconfig | 7 +++++++
sound/soc/platforms/Makefile | 1 +
4 files changed, 12 insertions(+)
create mode 100644 sound/soc/platforms/Kconfig
create mode 100644 sound/soc/platforms/Makefile
diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index d22758165496..b8064e8b2bdf 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -75,6 +75,9 @@ source "sound/soc/ux500/Kconfig"
source "sound/soc/xtensa/Kconfig"
source "sound/soc/zte/Kconfig"
+# Supported platforms
+source "sound/soc/platforms/Kconfig"
+
# Supported codecs
source "sound/soc/codecs/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index 5327f4d6c668..af578273548c 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_SND_SOC_ACPI) += snd-soc-acpi.o
obj-$(CONFIG_SND_SOC) += snd-soc-core.o
obj-$(CONFIG_SND_SOC) += codecs/
obj-$(CONFIG_SND_SOC) += generic/
+obj-$(CONFIG_SND_SOC) += platforms/
obj-$(CONFIG_SND_SOC) += adi/
obj-$(CONFIG_SND_SOC) += amd/
obj-$(CONFIG_SND_SOC) += atmel/
diff --git a/sound/soc/platforms/Kconfig b/sound/soc/platforms/Kconfig
new file mode 100644
index 000000000000..620d1f292246
--- /dev/null
+++ b/sound/soc/platforms/Kconfig
@@ -0,0 +1,7 @@
+#
+# SoC Platform Support Configuration
+#
+
+menu "Platform drivers"
+
+endmenu
diff --git a/sound/soc/platforms/Makefile b/sound/soc/platforms/Makefile
new file mode 100644
index 000000000000..f66554cd5c45
--- /dev/null
+++ b/sound/soc/platforms/Makefile
@@ -0,0 +1 @@
+# SPDX-License-Identifier: GPL-2.0
--
2.15.0
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [RFC PATCH 1/3] ASoC: Add platforms directory
@ 2017-12-05 18:14 ` Andrew F. Davis
0 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-05 18:14 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown; +Cc: alsa-devel, linux-kernel, Andrew F . Davis
Platform ASoC drivers are a lot like ASoC CODEC drivers in that they
both are independent pieces of a sound device, or "machine". Platform
drivers should be free of CODEC specifics and visa-versa. Both are then
used by the the "machine" driver to form the complete sound device.
This forms a hierarchy that makes it natural to group platform drivers
into their own directory, much like we group CODEC drivers already.
With this change, we will leave machine drivers in the top-level ASoC
directory and have CODECs and Platforms below. The machine drivers may
also be moved at some point into a grouping directory to further
enforce the logical separation intended by the ASoC framework.
Create the initial directory, Kconfig, and Makefile here.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
sound/soc/Kconfig | 3 +++
sound/soc/Makefile | 1 +
sound/soc/platforms/Kconfig | 7 +++++++
sound/soc/platforms/Makefile | 1 +
4 files changed, 12 insertions(+)
create mode 100644 sound/soc/platforms/Kconfig
create mode 100644 sound/soc/platforms/Makefile
diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index d22758165496..b8064e8b2bdf 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -75,6 +75,9 @@ source "sound/soc/ux500/Kconfig"
source "sound/soc/xtensa/Kconfig"
source "sound/soc/zte/Kconfig"
+# Supported platforms
+source "sound/soc/platforms/Kconfig"
+
# Supported codecs
source "sound/soc/codecs/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index 5327f4d6c668..af578273548c 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_SND_SOC_ACPI) += snd-soc-acpi.o
obj-$(CONFIG_SND_SOC) += snd-soc-core.o
obj-$(CONFIG_SND_SOC) += codecs/
obj-$(CONFIG_SND_SOC) += generic/
+obj-$(CONFIG_SND_SOC) += platforms/
obj-$(CONFIG_SND_SOC) += adi/
obj-$(CONFIG_SND_SOC) += amd/
obj-$(CONFIG_SND_SOC) += atmel/
diff --git a/sound/soc/platforms/Kconfig b/sound/soc/platforms/Kconfig
new file mode 100644
index 000000000000..620d1f292246
--- /dev/null
+++ b/sound/soc/platforms/Kconfig
@@ -0,0 +1,7 @@
+#
+# SoC Platform Support Configuration
+#
+
+menu "Platform drivers"
+
+endmenu
diff --git a/sound/soc/platforms/Makefile b/sound/soc/platforms/Makefile
new file mode 100644
index 000000000000..f66554cd5c45
--- /dev/null
+++ b/sound/soc/platforms/Makefile
@@ -0,0 +1 @@
+# SPDX-License-Identifier: GPL-2.0
--
2.15.0
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [RFC PATCH 2/3] ASoC: Platforms: Move Davinci platform drivers into platforms directory
2017-12-05 18:14 ` Andrew F. Davis
@ 2017-12-05 18:14 ` Andrew F. Davis
-1 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-05 18:14 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown; +Cc: alsa-devel, linux-kernel, Andrew F . Davis
Split the Davinci platform drivers from the machine drivers that use
these platform drivers by moving them into the new platforms directory.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
sound/soc/davinci/Kconfig | 37 -----------------------
sound/soc/davinci/Makefile | 21 +++----------
sound/soc/platforms/Kconfig | 2 ++
sound/soc/platforms/Makefile | 2 ++
sound/soc/platforms/davinci/Kconfig | 36 ++++++++++++++++++++++
sound/soc/{ => platforms}/davinci/Makefile | 5 ---
sound/soc/{ => platforms}/davinci/davinci-i2s.c | 0
sound/soc/{ => platforms}/davinci/davinci-i2s.h | 0
sound/soc/{ => platforms}/davinci/davinci-mcasp.c | 0
sound/soc/{ => platforms}/davinci/davinci-mcasp.h | 0
sound/soc/{ => platforms}/davinci/davinci-vcif.c | 0
sound/soc/{ => platforms}/davinci/edma-pcm.c | 0
sound/soc/{ => platforms}/davinci/edma-pcm.h | 0
13 files changed, 45 insertions(+), 58 deletions(-)
rewrite sound/soc/davinci/Makefile (71%)
create mode 100644 sound/soc/platforms/davinci/Kconfig
copy sound/soc/{ => platforms}/davinci/Makefile (76%)
rename sound/soc/{ => platforms}/davinci/davinci-i2s.c (100%)
rename sound/soc/{ => platforms}/davinci/davinci-i2s.h (100%)
rename sound/soc/{ => platforms}/davinci/davinci-mcasp.c (100%)
rename sound/soc/{ => platforms}/davinci/davinci-mcasp.h (100%)
rename sound/soc/{ => platforms}/davinci/davinci-vcif.c (100%)
rename sound/soc/{ => platforms}/davinci/edma-pcm.c (100%)
rename sound/soc/{ => platforms}/davinci/edma-pcm.h (100%)
diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
index 6b732d8e5896..f1f0686acce4 100644
--- a/sound/soc/davinci/Kconfig
+++ b/sound/soc/davinci/Kconfig
@@ -1,40 +1,3 @@
-config SND_DAVINCI_SOC
- tristate
- depends on ARCH_DAVINCI
- select SND_EDMA_SOC
-
-config SND_EDMA_SOC
- tristate "SoC Audio for Texas Instruments chips using eDMA"
- depends on TI_EDMA
- select SND_SOC_GENERIC_DMAENGINE_PCM
- help
- Say Y or M here if you want audio support for TI SoC which uses eDMA.
- The following line of SoCs are supported by this platform driver:
- - daVinci devices
- - AM335x
- - AM437x/AM438x
- - DRA7xx family
-
-config SND_DAVINCI_SOC_I2S
- tristate "DaVinci Multichannel Buffered Serial Port (McBSP) support"
- depends on SND_EDMA_SOC
- help
- Say Y or M here if you want to have support for McBSP IP found in
- Texas Instruments DaVinci DA850 SoCs.
-
-config SND_DAVINCI_SOC_MCASP
- tristate "Multichannel Audio Serial Port (McASP) support"
- depends on SND_OMAP_SOC || SND_EDMA_SOC
- help
- Say Y or M here if you want to have support for McASP IP found in
- various Texas Instruments SoCs like:
- - daVinci devices
- - Sitara line of SoCs (AM335x, AM438x, etc)
- - DRA7x devices
-
-config SND_DAVINCI_SOC_VCIF
- tristate
-
config SND_DAVINCI_SOC_GENERIC_EVM
tristate
select SND_SOC_TLV320AIC3X
diff --git a/sound/soc/davinci/Makefile b/sound/soc/davinci/Makefile
dissimilarity index 71%
index 23c6592eb31a..51b0d06e267b 100644
--- a/sound/soc/davinci/Makefile
+++ b/sound/soc/davinci/Makefile
@@ -1,16 +1,5 @@
-# SPDX-License-Identifier: GPL-2.0
-# DAVINCI Platform Support
-snd-soc-edma-objs := edma-pcm.o
-snd-soc-davinci-i2s-objs := davinci-i2s.o
-snd-soc-davinci-mcasp-objs:= davinci-mcasp.o
-snd-soc-davinci-vcif-objs:= davinci-vcif.o
-
-obj-$(CONFIG_SND_EDMA_SOC) += snd-soc-edma.o
-obj-$(CONFIG_SND_DAVINCI_SOC_I2S) += snd-soc-davinci-i2s.o
-obj-$(CONFIG_SND_DAVINCI_SOC_MCASP) += snd-soc-davinci-mcasp.o
-obj-$(CONFIG_SND_DAVINCI_SOC_VCIF) += snd-soc-davinci-vcif.o
-
-# Generic DAVINCI/AM33xx Machine Support
-snd-soc-evm-objs := davinci-evm.o
-
-obj-$(CONFIG_SND_DAVINCI_SOC_GENERIC_EVM) += snd-soc-evm.o
+# SPDX-License-Identifier: GPL-2.0
+# Generic DAVINCI/AM33xx Machine Support
+snd-soc-evm-objs := davinci-evm.o
+
+obj-$(CONFIG_SND_DAVINCI_SOC_GENERIC_EVM) += snd-soc-evm.o
diff --git a/sound/soc/platforms/Kconfig b/sound/soc/platforms/Kconfig
index 620d1f292246..c4ba367e41c4 100644
--- a/sound/soc/platforms/Kconfig
+++ b/sound/soc/platforms/Kconfig
@@ -4,4 +4,6 @@
menu "Platform drivers"
+source "sound/soc/platforms/davinci/Kconfig"
+
endmenu
diff --git a/sound/soc/platforms/Makefile b/sound/soc/platforms/Makefile
index f66554cd5c45..49629e238da9 100644
--- a/sound/soc/platforms/Makefile
+++ b/sound/soc/platforms/Makefile
@@ -1 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
+
+obj-y += davinci/
diff --git a/sound/soc/platforms/davinci/Kconfig b/sound/soc/platforms/davinci/Kconfig
new file mode 100644
index 000000000000..0a11b8f018ae
--- /dev/null
+++ b/sound/soc/platforms/davinci/Kconfig
@@ -0,0 +1,36 @@
+config SND_DAVINCI_SOC
+ tristate
+ depends on ARCH_DAVINCI
+ select SND_EDMA_SOC
+
+config SND_EDMA_SOC
+ tristate "SoC Audio for Texas Instruments chips using eDMA"
+ depends on TI_EDMA
+ select SND_SOC_GENERIC_DMAENGINE_PCM
+ help
+ Say Y or M here if you want audio support for TI SoC which uses eDMA.
+ The following line of SoCs are supported by this platform driver:
+ - daVinci devices
+ - AM335x
+ - AM437x/AM438x
+ - DRA7xx family
+
+config SND_DAVINCI_SOC_I2S
+ tristate "DaVinci Multichannel Buffered Serial Port (McBSP) support"
+ depends on SND_EDMA_SOC
+ help
+ Say Y or M here if you want to have support for McBSP IP found in
+ Texas Instruments DaVinci DA850 SoCs.
+
+config SND_DAVINCI_SOC_MCASP
+ tristate "Multichannel Audio Serial Port (McASP) support"
+ depends on SND_OMAP_SOC || SND_EDMA_SOC
+ help
+ Say Y or M here if you want to have support for McASP IP found in
+ various Texas Instruments SoCs like:
+ - daVinci devices
+ - Sitara line of SoCs (AM335x, AM438x, etc)
+ - DRA7x devices
+
+config SND_DAVINCI_SOC_VCIF
+ tristate
diff --git a/sound/soc/davinci/Makefile b/sound/soc/platforms/davinci/Makefile
similarity index 76%
copy from sound/soc/davinci/Makefile
copy to sound/soc/platforms/davinci/Makefile
index 23c6592eb31a..8d7d8017d82b 100644
--- a/sound/soc/davinci/Makefile
+++ b/sound/soc/platforms/davinci/Makefile
@@ -9,8 +9,3 @@ obj-$(CONFIG_SND_EDMA_SOC) += snd-soc-edma.o
obj-$(CONFIG_SND_DAVINCI_SOC_I2S) += snd-soc-davinci-i2s.o
obj-$(CONFIG_SND_DAVINCI_SOC_MCASP) += snd-soc-davinci-mcasp.o
obj-$(CONFIG_SND_DAVINCI_SOC_VCIF) += snd-soc-davinci-vcif.o
-
-# Generic DAVINCI/AM33xx Machine Support
-snd-soc-evm-objs := davinci-evm.o
-
-obj-$(CONFIG_SND_DAVINCI_SOC_GENERIC_EVM) += snd-soc-evm.o
diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/platforms/davinci/davinci-i2s.c
similarity index 100%
rename from sound/soc/davinci/davinci-i2s.c
rename to sound/soc/platforms/davinci/davinci-i2s.c
diff --git a/sound/soc/davinci/davinci-i2s.h b/sound/soc/platforms/davinci/davinci-i2s.h
similarity index 100%
rename from sound/soc/davinci/davinci-i2s.h
rename to sound/soc/platforms/davinci/davinci-i2s.h
diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/platforms/davinci/davinci-mcasp.c
similarity index 100%
rename from sound/soc/davinci/davinci-mcasp.c
rename to sound/soc/platforms/davinci/davinci-mcasp.c
diff --git a/sound/soc/davinci/davinci-mcasp.h b/sound/soc/platforms/davinci/davinci-mcasp.h
similarity index 100%
rename from sound/soc/davinci/davinci-mcasp.h
rename to sound/soc/platforms/davinci/davinci-mcasp.h
diff --git a/sound/soc/davinci/davinci-vcif.c b/sound/soc/platforms/davinci/davinci-vcif.c
similarity index 100%
rename from sound/soc/davinci/davinci-vcif.c
rename to sound/soc/platforms/davinci/davinci-vcif.c
diff --git a/sound/soc/davinci/edma-pcm.c b/sound/soc/platforms/davinci/edma-pcm.c
similarity index 100%
rename from sound/soc/davinci/edma-pcm.c
rename to sound/soc/platforms/davinci/edma-pcm.c
diff --git a/sound/soc/davinci/edma-pcm.h b/sound/soc/platforms/davinci/edma-pcm.h
similarity index 100%
rename from sound/soc/davinci/edma-pcm.h
rename to sound/soc/platforms/davinci/edma-pcm.h
--
2.15.0
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [RFC PATCH 2/3] ASoC: Platforms: Move Davinci platform drivers into platforms directory
@ 2017-12-05 18:14 ` Andrew F. Davis
0 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-05 18:14 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown; +Cc: alsa-devel, linux-kernel, Andrew F . Davis
Split the Davinci platform drivers from the machine drivers that use
these platform drivers by moving them into the new platforms directory.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
sound/soc/davinci/Kconfig | 37 -----------------------
sound/soc/davinci/Makefile | 21 +++----------
sound/soc/platforms/Kconfig | 2 ++
sound/soc/platforms/Makefile | 2 ++
sound/soc/platforms/davinci/Kconfig | 36 ++++++++++++++++++++++
sound/soc/{ => platforms}/davinci/Makefile | 5 ---
sound/soc/{ => platforms}/davinci/davinci-i2s.c | 0
sound/soc/{ => platforms}/davinci/davinci-i2s.h | 0
sound/soc/{ => platforms}/davinci/davinci-mcasp.c | 0
sound/soc/{ => platforms}/davinci/davinci-mcasp.h | 0
sound/soc/{ => platforms}/davinci/davinci-vcif.c | 0
sound/soc/{ => platforms}/davinci/edma-pcm.c | 0
sound/soc/{ => platforms}/davinci/edma-pcm.h | 0
13 files changed, 45 insertions(+), 58 deletions(-)
rewrite sound/soc/davinci/Makefile (71%)
create mode 100644 sound/soc/platforms/davinci/Kconfig
copy sound/soc/{ => platforms}/davinci/Makefile (76%)
rename sound/soc/{ => platforms}/davinci/davinci-i2s.c (100%)
rename sound/soc/{ => platforms}/davinci/davinci-i2s.h (100%)
rename sound/soc/{ => platforms}/davinci/davinci-mcasp.c (100%)
rename sound/soc/{ => platforms}/davinci/davinci-mcasp.h (100%)
rename sound/soc/{ => platforms}/davinci/davinci-vcif.c (100%)
rename sound/soc/{ => platforms}/davinci/edma-pcm.c (100%)
rename sound/soc/{ => platforms}/davinci/edma-pcm.h (100%)
diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig
index 6b732d8e5896..f1f0686acce4 100644
--- a/sound/soc/davinci/Kconfig
+++ b/sound/soc/davinci/Kconfig
@@ -1,40 +1,3 @@
-config SND_DAVINCI_SOC
- tristate
- depends on ARCH_DAVINCI
- select SND_EDMA_SOC
-
-config SND_EDMA_SOC
- tristate "SoC Audio for Texas Instruments chips using eDMA"
- depends on TI_EDMA
- select SND_SOC_GENERIC_DMAENGINE_PCM
- help
- Say Y or M here if you want audio support for TI SoC which uses eDMA.
- The following line of SoCs are supported by this platform driver:
- - daVinci devices
- - AM335x
- - AM437x/AM438x
- - DRA7xx family
-
-config SND_DAVINCI_SOC_I2S
- tristate "DaVinci Multichannel Buffered Serial Port (McBSP) support"
- depends on SND_EDMA_SOC
- help
- Say Y or M here if you want to have support for McBSP IP found in
- Texas Instruments DaVinci DA850 SoCs.
-
-config SND_DAVINCI_SOC_MCASP
- tristate "Multichannel Audio Serial Port (McASP) support"
- depends on SND_OMAP_SOC || SND_EDMA_SOC
- help
- Say Y or M here if you want to have support for McASP IP found in
- various Texas Instruments SoCs like:
- - daVinci devices
- - Sitara line of SoCs (AM335x, AM438x, etc)
- - DRA7x devices
-
-config SND_DAVINCI_SOC_VCIF
- tristate
-
config SND_DAVINCI_SOC_GENERIC_EVM
tristate
select SND_SOC_TLV320AIC3X
diff --git a/sound/soc/davinci/Makefile b/sound/soc/davinci/Makefile
dissimilarity index 71%
index 23c6592eb31a..51b0d06e267b 100644
--- a/sound/soc/davinci/Makefile
+++ b/sound/soc/davinci/Makefile
@@ -1,16 +1,5 @@
-# SPDX-License-Identifier: GPL-2.0
-# DAVINCI Platform Support
-snd-soc-edma-objs := edma-pcm.o
-snd-soc-davinci-i2s-objs := davinci-i2s.o
-snd-soc-davinci-mcasp-objs:= davinci-mcasp.o
-snd-soc-davinci-vcif-objs:= davinci-vcif.o
-
-obj-$(CONFIG_SND_EDMA_SOC) += snd-soc-edma.o
-obj-$(CONFIG_SND_DAVINCI_SOC_I2S) += snd-soc-davinci-i2s.o
-obj-$(CONFIG_SND_DAVINCI_SOC_MCASP) += snd-soc-davinci-mcasp.o
-obj-$(CONFIG_SND_DAVINCI_SOC_VCIF) += snd-soc-davinci-vcif.o
-
-# Generic DAVINCI/AM33xx Machine Support
-snd-soc-evm-objs := davinci-evm.o
-
-obj-$(CONFIG_SND_DAVINCI_SOC_GENERIC_EVM) += snd-soc-evm.o
+# SPDX-License-Identifier: GPL-2.0
+# Generic DAVINCI/AM33xx Machine Support
+snd-soc-evm-objs := davinci-evm.o
+
+obj-$(CONFIG_SND_DAVINCI_SOC_GENERIC_EVM) += snd-soc-evm.o
diff --git a/sound/soc/platforms/Kconfig b/sound/soc/platforms/Kconfig
index 620d1f292246..c4ba367e41c4 100644
--- a/sound/soc/platforms/Kconfig
+++ b/sound/soc/platforms/Kconfig
@@ -4,4 +4,6 @@
menu "Platform drivers"
+source "sound/soc/platforms/davinci/Kconfig"
+
endmenu
diff --git a/sound/soc/platforms/Makefile b/sound/soc/platforms/Makefile
index f66554cd5c45..49629e238da9 100644
--- a/sound/soc/platforms/Makefile
+++ b/sound/soc/platforms/Makefile
@@ -1 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
+
+obj-y += davinci/
diff --git a/sound/soc/platforms/davinci/Kconfig b/sound/soc/platforms/davinci/Kconfig
new file mode 100644
index 000000000000..0a11b8f018ae
--- /dev/null
+++ b/sound/soc/platforms/davinci/Kconfig
@@ -0,0 +1,36 @@
+config SND_DAVINCI_SOC
+ tristate
+ depends on ARCH_DAVINCI
+ select SND_EDMA_SOC
+
+config SND_EDMA_SOC
+ tristate "SoC Audio for Texas Instruments chips using eDMA"
+ depends on TI_EDMA
+ select SND_SOC_GENERIC_DMAENGINE_PCM
+ help
+ Say Y or M here if you want audio support for TI SoC which uses eDMA.
+ The following line of SoCs are supported by this platform driver:
+ - daVinci devices
+ - AM335x
+ - AM437x/AM438x
+ - DRA7xx family
+
+config SND_DAVINCI_SOC_I2S
+ tristate "DaVinci Multichannel Buffered Serial Port (McBSP) support"
+ depends on SND_EDMA_SOC
+ help
+ Say Y or M here if you want to have support for McBSP IP found in
+ Texas Instruments DaVinci DA850 SoCs.
+
+config SND_DAVINCI_SOC_MCASP
+ tristate "Multichannel Audio Serial Port (McASP) support"
+ depends on SND_OMAP_SOC || SND_EDMA_SOC
+ help
+ Say Y or M here if you want to have support for McASP IP found in
+ various Texas Instruments SoCs like:
+ - daVinci devices
+ - Sitara line of SoCs (AM335x, AM438x, etc)
+ - DRA7x devices
+
+config SND_DAVINCI_SOC_VCIF
+ tristate
diff --git a/sound/soc/davinci/Makefile b/sound/soc/platforms/davinci/Makefile
similarity index 76%
copy from sound/soc/davinci/Makefile
copy to sound/soc/platforms/davinci/Makefile
index 23c6592eb31a..8d7d8017d82b 100644
--- a/sound/soc/davinci/Makefile
+++ b/sound/soc/platforms/davinci/Makefile
@@ -9,8 +9,3 @@ obj-$(CONFIG_SND_EDMA_SOC) += snd-soc-edma.o
obj-$(CONFIG_SND_DAVINCI_SOC_I2S) += snd-soc-davinci-i2s.o
obj-$(CONFIG_SND_DAVINCI_SOC_MCASP) += snd-soc-davinci-mcasp.o
obj-$(CONFIG_SND_DAVINCI_SOC_VCIF) += snd-soc-davinci-vcif.o
-
-# Generic DAVINCI/AM33xx Machine Support
-snd-soc-evm-objs := davinci-evm.o
-
-obj-$(CONFIG_SND_DAVINCI_SOC_GENERIC_EVM) += snd-soc-evm.o
diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/platforms/davinci/davinci-i2s.c
similarity index 100%
rename from sound/soc/davinci/davinci-i2s.c
rename to sound/soc/platforms/davinci/davinci-i2s.c
diff --git a/sound/soc/davinci/davinci-i2s.h b/sound/soc/platforms/davinci/davinci-i2s.h
similarity index 100%
rename from sound/soc/davinci/davinci-i2s.h
rename to sound/soc/platforms/davinci/davinci-i2s.h
diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/platforms/davinci/davinci-mcasp.c
similarity index 100%
rename from sound/soc/davinci/davinci-mcasp.c
rename to sound/soc/platforms/davinci/davinci-mcasp.c
diff --git a/sound/soc/davinci/davinci-mcasp.h b/sound/soc/platforms/davinci/davinci-mcasp.h
similarity index 100%
rename from sound/soc/davinci/davinci-mcasp.h
rename to sound/soc/platforms/davinci/davinci-mcasp.h
diff --git a/sound/soc/davinci/davinci-vcif.c b/sound/soc/platforms/davinci/davinci-vcif.c
similarity index 100%
rename from sound/soc/davinci/davinci-vcif.c
rename to sound/soc/platforms/davinci/davinci-vcif.c
diff --git a/sound/soc/davinci/edma-pcm.c b/sound/soc/platforms/davinci/edma-pcm.c
similarity index 100%
rename from sound/soc/davinci/edma-pcm.c
rename to sound/soc/platforms/davinci/edma-pcm.c
diff --git a/sound/soc/davinci/edma-pcm.h b/sound/soc/platforms/davinci/edma-pcm.h
similarity index 100%
rename from sound/soc/davinci/edma-pcm.h
rename to sound/soc/platforms/davinci/edma-pcm.h
--
2.15.0
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [RFC PATCH 3/3] ASoC: Platforms: Move OMAP platform drivers into platforms directory
2017-12-05 18:14 ` Andrew F. Davis
@ 2017-12-05 18:14 ` Andrew F. Davis
-1 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-05 18:14 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown; +Cc: alsa-devel, linux-kernel, Andrew F . Davis
Split the OMAP platform drivers from the machine drivers that use
these platform drivers by moving them into the new platforms directory.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
MAINTAINERS | 1 +
sound/soc/omap/Kconfig | 29 ------------------------
sound/soc/omap/Makefile | 13 -----------
sound/soc/omap/am3517evm.c | 2 +-
sound/soc/omap/ams-delta.c | 2 +-
sound/soc/omap/n810.c | 2 +-
sound/soc/omap/omap-abe-twl6040.c | 4 ++--
sound/soc/omap/omap-twl4030.c | 2 +-
sound/soc/omap/omap3pandora.c | 2 +-
sound/soc/omap/osk5912.c | 2 +-
sound/soc/omap/rx51.c | 2 +-
sound/soc/platforms/Kconfig | 1 +
sound/soc/platforms/Makefile | 1 +
sound/soc/platforms/omap/Kconfig | 28 +++++++++++++++++++++++
sound/soc/platforms/omap/Makefile | 13 +++++++++++
sound/soc/{ => platforms}/omap/mcbsp.c | 0
sound/soc/{ => platforms}/omap/mcbsp.h | 0
sound/soc/{ => platforms}/omap/omap-dmic.c | 0
sound/soc/{ => platforms}/omap/omap-dmic.h | 0
sound/soc/{ => platforms}/omap/omap-hdmi-audio.c | 0
sound/soc/{ => platforms}/omap/omap-mcbsp.c | 0
sound/soc/{ => platforms}/omap/omap-mcbsp.h | 0
sound/soc/{ => platforms}/omap/omap-mcpdm.c | 0
sound/soc/{ => platforms}/omap/omap-mcpdm.h | 0
sound/soc/{ => platforms}/omap/omap-pcm.c | 0
25 files changed, 53 insertions(+), 51 deletions(-)
create mode 100644 sound/soc/platforms/omap/Kconfig
create mode 100644 sound/soc/platforms/omap/Makefile
rename sound/soc/{ => platforms}/omap/mcbsp.c (100%)
rename sound/soc/{ => platforms}/omap/mcbsp.h (100%)
rename sound/soc/{ => platforms}/omap/omap-dmic.c (100%)
rename sound/soc/{ => platforms}/omap/omap-dmic.h (100%)
rename sound/soc/{ => platforms}/omap/omap-hdmi-audio.c (100%)
rename sound/soc/{ => platforms}/omap/omap-mcbsp.c (100%)
rename sound/soc/{ => platforms}/omap/omap-mcbsp.h (100%)
rename sound/soc/{ => platforms}/omap/omap-mcpdm.c (100%)
rename sound/soc/{ => platforms}/omap/omap-mcpdm.h (100%)
rename sound/soc/{ => platforms}/omap/omap-pcm.c (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..5dbd55449564 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9826,6 +9826,7 @@ L: alsa-devel@alsa-project.org (moderated for non-subscribers)
L: linux-omap@vger.kernel.org
S: Maintained
F: sound/soc/omap/
+F: sound/soc/platforms/omap/
OMAP CLOCK FRAMEWORK SUPPORT
M: Paul Walmsley <paul@pwsan.com>
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index f5451c78ede5..aed03c4894a9 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -1,32 +1,3 @@
-config SND_OMAP_SOC
- tristate "SoC Audio for the Texas Instruments OMAP chips"
- depends on (ARCH_OMAP && DMA_OMAP) || (ARM && COMPILE_TEST)
- select SND_DMAENGINE_PCM
-
-config SND_OMAP_SOC_DMIC
- tristate
-
-config SND_OMAP_SOC_MCBSP
- tristate
-
-config SND_OMAP_SOC_MCPDM
- tristate
-
-config SND_OMAP_SOC_HDMI_AUDIO
- tristate "HDMI audio support for OMAP4+ based SoCs"
- depends on SND_OMAP_SOC
- help
- For HDMI audio to work OMAPDSS HDMI support should be
- enabled.
- The hdmi audio driver implements cpu-dai component using the
- callbacks provided by OMAPDSS and registers the component
- under DSS HDMI device. Omap-pcm is registered for platform
- component also under DSS HDMI device. Dummy codec is used as
- as codec component. The hdmi audio driver implements also
- the card and registers it under its own platform device.
- The device for the driver is registered by OMAPDSS hdmi
- driver.
-
config SND_OMAP_SOC_N810
tristate "SoC Audio support for Nokia N810"
depends on SND_OMAP_SOC && MACH_NOKIA_N810 && I2C
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index a6785dc4fc90..827f8a211e03 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -1,17 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-# OMAP Platform Support
-snd-soc-omap-objs := omap-pcm.o
-snd-soc-omap-dmic-objs := omap-dmic.o
-snd-soc-omap-mcbsp-objs := omap-mcbsp.o mcbsp.o
-snd-soc-omap-mcpdm-objs := omap-mcpdm.o
-snd-soc-omap-hdmi-audio-objs := omap-hdmi-audio.o
-
-obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o
-obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o
-obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
-obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o
-obj-$(CONFIG_SND_OMAP_SOC_HDMI_AUDIO) += snd-soc-omap-hdmi-audio.o
-
# OMAP Machine Support
snd-soc-n810-objs := n810.o
snd-soc-rx51-objs := rx51.o
diff --git a/sound/soc/omap/am3517evm.c b/sound/soc/omap/am3517evm.c
index d5651026ec10..7de6a4d08df8 100644
--- a/sound/soc/omap/am3517evm.c
+++ b/sound/soc/omap/am3517evm.c
@@ -27,7 +27,7 @@
#include <asm/mach-types.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
#include "../codecs/tlv320aic23.h"
diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c
index d40219678700..2d4020594935 100644
--- a/sound/soc/omap/ams-delta.c
+++ b/sound/soc/omap/ams-delta.c
@@ -35,7 +35,7 @@
#include <mach/board-ams-delta.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
#include "../codecs/cx20442.h"
/* Board specific DAPM widgets */
diff --git a/sound/soc/omap/n810.c b/sound/soc/omap/n810.c
index 71e5f31fa306..fa00121da632 100644
--- a/sound/soc/omap/n810.c
+++ b/sound/soc/omap/n810.c
@@ -33,7 +33,7 @@
#include <linux/module.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
#define N810_HEADSET_AMP_GPIO 10
#define N810_SPEAKER_AMP_GPIO 101
diff --git a/sound/soc/omap/omap-abe-twl6040.c b/sound/soc/omap/omap-abe-twl6040.c
index 614b18d2f631..b98c017d2da9 100644
--- a/sound/soc/omap/omap-abe-twl6040.c
+++ b/sound/soc/omap/omap-abe-twl6040.c
@@ -31,8 +31,8 @@
#include <sound/soc.h>
#include <sound/jack.h>
-#include "omap-dmic.h"
-#include "omap-mcpdm.h"
+#include "../platforms/omap/omap-dmic.h"
+#include "../platforms/omap/omap-mcpdm.h"
#include "../codecs/twl6040.h"
struct abe_twl6040 {
diff --git a/sound/soc/omap/omap-twl4030.c b/sound/soc/omap/omap-twl4030.c
index cccc316743fa..997e1bb9c979 100644
--- a/sound/soc/omap/omap-twl4030.c
+++ b/sound/soc/omap/omap-twl4030.c
@@ -42,7 +42,7 @@
#include <sound/soc.h>
#include <sound/jack.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
struct omap_twl4030 {
int jack_detect; /* board can detect jack events */
diff --git a/sound/soc/omap/omap3pandora.c b/sound/soc/omap/omap3pandora.c
index 4e3de712159c..5912b4b9661f 100644
--- a/sound/soc/omap/omap3pandora.c
+++ b/sound/soc/omap/omap3pandora.c
@@ -33,7 +33,7 @@
#include <asm/mach-types.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
#define OMAP3_PANDORA_DAC_POWER_GPIO 118
#define OMAP3_PANDORA_AMP_POWER_GPIO 14
diff --git a/sound/soc/omap/osk5912.c b/sound/soc/omap/osk5912.c
index e4096779ca05..9a58403f29ff 100644
--- a/sound/soc/omap/osk5912.c
+++ b/sound/soc/omap/osk5912.c
@@ -32,7 +32,7 @@
#include <linux/module.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
#include "../codecs/tlv320aic23.h"
#define CODEC_CLOCK 12000000
diff --git a/sound/soc/omap/rx51.c b/sound/soc/omap/rx51.c
index 57448bd5ad77..adf078e76fab 100644
--- a/sound/soc/omap/rx51.c
+++ b/sound/soc/omap/rx51.c
@@ -36,7 +36,7 @@
#include <asm/mach-types.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
enum {
RX51_JACK_DISABLED,
diff --git a/sound/soc/platforms/Kconfig b/sound/soc/platforms/Kconfig
index c4ba367e41c4..472988d07f9d 100644
--- a/sound/soc/platforms/Kconfig
+++ b/sound/soc/platforms/Kconfig
@@ -5,5 +5,6 @@
menu "Platform drivers"
source "sound/soc/platforms/davinci/Kconfig"
+source "sound/soc/platforms/omap/Kconfig"
endmenu
diff --git a/sound/soc/platforms/Makefile b/sound/soc/platforms/Makefile
index 49629e238da9..c9ebc3606069 100644
--- a/sound/soc/platforms/Makefile
+++ b/sound/soc/platforms/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += davinci/
+obj-y += omap/
diff --git a/sound/soc/platforms/omap/Kconfig b/sound/soc/platforms/omap/Kconfig
new file mode 100644
index 000000000000..90cf9a78c24b
--- /dev/null
+++ b/sound/soc/platforms/omap/Kconfig
@@ -0,0 +1,28 @@
+config SND_OMAP_SOC
+ tristate "SoC Audio for the Texas Instruments OMAP chips"
+ depends on (ARCH_OMAP && DMA_OMAP) || (ARM && COMPILE_TEST)
+ select SND_DMAENGINE_PCM
+
+config SND_OMAP_SOC_DMIC
+ tristate
+
+config SND_OMAP_SOC_MCBSP
+ tristate
+
+config SND_OMAP_SOC_MCPDM
+ tristate
+
+config SND_OMAP_SOC_HDMI_AUDIO
+ tristate "HDMI audio support for OMAP4+ based SoCs"
+ depends on SND_OMAP_SOC
+ help
+ For HDMI audio to work OMAPDSS HDMI support should be
+ enabled.
+ The hdmi audio driver implements cpu-dai component using the
+ callbacks provided by OMAPDSS and registers the component
+ under DSS HDMI device. Omap-pcm is registered for platform
+ component also under DSS HDMI device. Dummy codec is used as
+ as codec component. The hdmi audio driver implements also
+ the card and registers it under its own platform device.
+ The device for the driver is registered by OMAPDSS hdmi
+ driver.
diff --git a/sound/soc/platforms/omap/Makefile b/sound/soc/platforms/omap/Makefile
new file mode 100644
index 000000000000..1e83ac1f664b
--- /dev/null
+++ b/sound/soc/platforms/omap/Makefile
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0
+# OMAP Platform Support
+snd-soc-omap-objs := omap-pcm.o
+snd-soc-omap-dmic-objs := omap-dmic.o
+snd-soc-omap-mcbsp-objs := omap-mcbsp.o mcbsp.o
+snd-soc-omap-mcpdm-objs := omap-mcpdm.o
+snd-soc-omap-hdmi-audio-objs := omap-hdmi-audio.o
+
+obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o
+obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o
+obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
+obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o
+obj-$(CONFIG_SND_OMAP_SOC_HDMI_AUDIO) += snd-soc-omap-hdmi-audio.o
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/platforms/omap/mcbsp.c
similarity index 100%
rename from sound/soc/omap/mcbsp.c
rename to sound/soc/platforms/omap/mcbsp.c
diff --git a/sound/soc/omap/mcbsp.h b/sound/soc/platforms/omap/mcbsp.h
similarity index 100%
rename from sound/soc/omap/mcbsp.h
rename to sound/soc/platforms/omap/mcbsp.h
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/platforms/omap/omap-dmic.c
similarity index 100%
rename from sound/soc/omap/omap-dmic.c
rename to sound/soc/platforms/omap/omap-dmic.c
diff --git a/sound/soc/omap/omap-dmic.h b/sound/soc/platforms/omap/omap-dmic.h
similarity index 100%
rename from sound/soc/omap/omap-dmic.h
rename to sound/soc/platforms/omap/omap-dmic.h
diff --git a/sound/soc/omap/omap-hdmi-audio.c b/sound/soc/platforms/omap/omap-hdmi-audio.c
similarity index 100%
rename from sound/soc/omap/omap-hdmi-audio.c
rename to sound/soc/platforms/omap/omap-hdmi-audio.c
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/platforms/omap/omap-mcbsp.c
similarity index 100%
rename from sound/soc/omap/omap-mcbsp.c
rename to sound/soc/platforms/omap/omap-mcbsp.c
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/platforms/omap/omap-mcbsp.h
similarity index 100%
rename from sound/soc/omap/omap-mcbsp.h
rename to sound/soc/platforms/omap/omap-mcbsp.h
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/platforms/omap/omap-mcpdm.c
similarity index 100%
rename from sound/soc/omap/omap-mcpdm.c
rename to sound/soc/platforms/omap/omap-mcpdm.c
diff --git a/sound/soc/omap/omap-mcpdm.h b/sound/soc/platforms/omap/omap-mcpdm.h
similarity index 100%
rename from sound/soc/omap/omap-mcpdm.h
rename to sound/soc/platforms/omap/omap-mcpdm.h
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/platforms/omap/omap-pcm.c
similarity index 100%
rename from sound/soc/omap/omap-pcm.c
rename to sound/soc/platforms/omap/omap-pcm.c
--
2.15.0
^ permalink raw reply related [flat|nested] 24+ messages in thread
* [RFC PATCH 3/3] ASoC: Platforms: Move OMAP platform drivers into platforms directory
@ 2017-12-05 18:14 ` Andrew F. Davis
0 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-05 18:14 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown; +Cc: alsa-devel, linux-kernel, Andrew F . Davis
Split the OMAP platform drivers from the machine drivers that use
these platform drivers by moving them into the new platforms directory.
Signed-off-by: Andrew F. Davis <afd@ti.com>
---
MAINTAINERS | 1 +
sound/soc/omap/Kconfig | 29 ------------------------
sound/soc/omap/Makefile | 13 -----------
sound/soc/omap/am3517evm.c | 2 +-
sound/soc/omap/ams-delta.c | 2 +-
sound/soc/omap/n810.c | 2 +-
sound/soc/omap/omap-abe-twl6040.c | 4 ++--
sound/soc/omap/omap-twl4030.c | 2 +-
sound/soc/omap/omap3pandora.c | 2 +-
sound/soc/omap/osk5912.c | 2 +-
sound/soc/omap/rx51.c | 2 +-
sound/soc/platforms/Kconfig | 1 +
sound/soc/platforms/Makefile | 1 +
sound/soc/platforms/omap/Kconfig | 28 +++++++++++++++++++++++
sound/soc/platforms/omap/Makefile | 13 +++++++++++
sound/soc/{ => platforms}/omap/mcbsp.c | 0
sound/soc/{ => platforms}/omap/mcbsp.h | 0
sound/soc/{ => platforms}/omap/omap-dmic.c | 0
sound/soc/{ => platforms}/omap/omap-dmic.h | 0
sound/soc/{ => platforms}/omap/omap-hdmi-audio.c | 0
sound/soc/{ => platforms}/omap/omap-mcbsp.c | 0
sound/soc/{ => platforms}/omap/omap-mcbsp.h | 0
sound/soc/{ => platforms}/omap/omap-mcpdm.c | 0
sound/soc/{ => platforms}/omap/omap-mcpdm.h | 0
sound/soc/{ => platforms}/omap/omap-pcm.c | 0
25 files changed, 53 insertions(+), 51 deletions(-)
create mode 100644 sound/soc/platforms/omap/Kconfig
create mode 100644 sound/soc/platforms/omap/Makefile
rename sound/soc/{ => platforms}/omap/mcbsp.c (100%)
rename sound/soc/{ => platforms}/omap/mcbsp.h (100%)
rename sound/soc/{ => platforms}/omap/omap-dmic.c (100%)
rename sound/soc/{ => platforms}/omap/omap-dmic.h (100%)
rename sound/soc/{ => platforms}/omap/omap-hdmi-audio.c (100%)
rename sound/soc/{ => platforms}/omap/omap-mcbsp.c (100%)
rename sound/soc/{ => platforms}/omap/omap-mcbsp.h (100%)
rename sound/soc/{ => platforms}/omap/omap-mcpdm.c (100%)
rename sound/soc/{ => platforms}/omap/omap-mcpdm.h (100%)
rename sound/soc/{ => platforms}/omap/omap-pcm.c (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..5dbd55449564 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9826,6 +9826,7 @@ L: alsa-devel@alsa-project.org (moderated for non-subscribers)
L: linux-omap@vger.kernel.org
S: Maintained
F: sound/soc/omap/
+F: sound/soc/platforms/omap/
OMAP CLOCK FRAMEWORK SUPPORT
M: Paul Walmsley <paul@pwsan.com>
diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig
index f5451c78ede5..aed03c4894a9 100644
--- a/sound/soc/omap/Kconfig
+++ b/sound/soc/omap/Kconfig
@@ -1,32 +1,3 @@
-config SND_OMAP_SOC
- tristate "SoC Audio for the Texas Instruments OMAP chips"
- depends on (ARCH_OMAP && DMA_OMAP) || (ARM && COMPILE_TEST)
- select SND_DMAENGINE_PCM
-
-config SND_OMAP_SOC_DMIC
- tristate
-
-config SND_OMAP_SOC_MCBSP
- tristate
-
-config SND_OMAP_SOC_MCPDM
- tristate
-
-config SND_OMAP_SOC_HDMI_AUDIO
- tristate "HDMI audio support for OMAP4+ based SoCs"
- depends on SND_OMAP_SOC
- help
- For HDMI audio to work OMAPDSS HDMI support should be
- enabled.
- The hdmi audio driver implements cpu-dai component using the
- callbacks provided by OMAPDSS and registers the component
- under DSS HDMI device. Omap-pcm is registered for platform
- component also under DSS HDMI device. Dummy codec is used as
- as codec component. The hdmi audio driver implements also
- the card and registers it under its own platform device.
- The device for the driver is registered by OMAPDSS hdmi
- driver.
-
config SND_OMAP_SOC_N810
tristate "SoC Audio support for Nokia N810"
depends on SND_OMAP_SOC && MACH_NOKIA_N810 && I2C
diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile
index a6785dc4fc90..827f8a211e03 100644
--- a/sound/soc/omap/Makefile
+++ b/sound/soc/omap/Makefile
@@ -1,17 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-# OMAP Platform Support
-snd-soc-omap-objs := omap-pcm.o
-snd-soc-omap-dmic-objs := omap-dmic.o
-snd-soc-omap-mcbsp-objs := omap-mcbsp.o mcbsp.o
-snd-soc-omap-mcpdm-objs := omap-mcpdm.o
-snd-soc-omap-hdmi-audio-objs := omap-hdmi-audio.o
-
-obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o
-obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o
-obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
-obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o
-obj-$(CONFIG_SND_OMAP_SOC_HDMI_AUDIO) += snd-soc-omap-hdmi-audio.o
-
# OMAP Machine Support
snd-soc-n810-objs := n810.o
snd-soc-rx51-objs := rx51.o
diff --git a/sound/soc/omap/am3517evm.c b/sound/soc/omap/am3517evm.c
index d5651026ec10..7de6a4d08df8 100644
--- a/sound/soc/omap/am3517evm.c
+++ b/sound/soc/omap/am3517evm.c
@@ -27,7 +27,7 @@
#include <asm/mach-types.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
#include "../codecs/tlv320aic23.h"
diff --git a/sound/soc/omap/ams-delta.c b/sound/soc/omap/ams-delta.c
index d40219678700..2d4020594935 100644
--- a/sound/soc/omap/ams-delta.c
+++ b/sound/soc/omap/ams-delta.c
@@ -35,7 +35,7 @@
#include <mach/board-ams-delta.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
#include "../codecs/cx20442.h"
/* Board specific DAPM widgets */
diff --git a/sound/soc/omap/n810.c b/sound/soc/omap/n810.c
index 71e5f31fa306..fa00121da632 100644
--- a/sound/soc/omap/n810.c
+++ b/sound/soc/omap/n810.c
@@ -33,7 +33,7 @@
#include <linux/module.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
#define N810_HEADSET_AMP_GPIO 10
#define N810_SPEAKER_AMP_GPIO 101
diff --git a/sound/soc/omap/omap-abe-twl6040.c b/sound/soc/omap/omap-abe-twl6040.c
index 614b18d2f631..b98c017d2da9 100644
--- a/sound/soc/omap/omap-abe-twl6040.c
+++ b/sound/soc/omap/omap-abe-twl6040.c
@@ -31,8 +31,8 @@
#include <sound/soc.h>
#include <sound/jack.h>
-#include "omap-dmic.h"
-#include "omap-mcpdm.h"
+#include "../platforms/omap/omap-dmic.h"
+#include "../platforms/omap/omap-mcpdm.h"
#include "../codecs/twl6040.h"
struct abe_twl6040 {
diff --git a/sound/soc/omap/omap-twl4030.c b/sound/soc/omap/omap-twl4030.c
index cccc316743fa..997e1bb9c979 100644
--- a/sound/soc/omap/omap-twl4030.c
+++ b/sound/soc/omap/omap-twl4030.c
@@ -42,7 +42,7 @@
#include <sound/soc.h>
#include <sound/jack.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
struct omap_twl4030 {
int jack_detect; /* board can detect jack events */
diff --git a/sound/soc/omap/omap3pandora.c b/sound/soc/omap/omap3pandora.c
index 4e3de712159c..5912b4b9661f 100644
--- a/sound/soc/omap/omap3pandora.c
+++ b/sound/soc/omap/omap3pandora.c
@@ -33,7 +33,7 @@
#include <asm/mach-types.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
#define OMAP3_PANDORA_DAC_POWER_GPIO 118
#define OMAP3_PANDORA_AMP_POWER_GPIO 14
diff --git a/sound/soc/omap/osk5912.c b/sound/soc/omap/osk5912.c
index e4096779ca05..9a58403f29ff 100644
--- a/sound/soc/omap/osk5912.c
+++ b/sound/soc/omap/osk5912.c
@@ -32,7 +32,7 @@
#include <linux/module.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
#include "../codecs/tlv320aic23.h"
#define CODEC_CLOCK 12000000
diff --git a/sound/soc/omap/rx51.c b/sound/soc/omap/rx51.c
index 57448bd5ad77..adf078e76fab 100644
--- a/sound/soc/omap/rx51.c
+++ b/sound/soc/omap/rx51.c
@@ -36,7 +36,7 @@
#include <asm/mach-types.h>
-#include "omap-mcbsp.h"
+#include "../platforms/omap/omap-mcbsp.h"
enum {
RX51_JACK_DISABLED,
diff --git a/sound/soc/platforms/Kconfig b/sound/soc/platforms/Kconfig
index c4ba367e41c4..472988d07f9d 100644
--- a/sound/soc/platforms/Kconfig
+++ b/sound/soc/platforms/Kconfig
@@ -5,5 +5,6 @@
menu "Platform drivers"
source "sound/soc/platforms/davinci/Kconfig"
+source "sound/soc/platforms/omap/Kconfig"
endmenu
diff --git a/sound/soc/platforms/Makefile b/sound/soc/platforms/Makefile
index 49629e238da9..c9ebc3606069 100644
--- a/sound/soc/platforms/Makefile
+++ b/sound/soc/platforms/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
obj-y += davinci/
+obj-y += omap/
diff --git a/sound/soc/platforms/omap/Kconfig b/sound/soc/platforms/omap/Kconfig
new file mode 100644
index 000000000000..90cf9a78c24b
--- /dev/null
+++ b/sound/soc/platforms/omap/Kconfig
@@ -0,0 +1,28 @@
+config SND_OMAP_SOC
+ tristate "SoC Audio for the Texas Instruments OMAP chips"
+ depends on (ARCH_OMAP && DMA_OMAP) || (ARM && COMPILE_TEST)
+ select SND_DMAENGINE_PCM
+
+config SND_OMAP_SOC_DMIC
+ tristate
+
+config SND_OMAP_SOC_MCBSP
+ tristate
+
+config SND_OMAP_SOC_MCPDM
+ tristate
+
+config SND_OMAP_SOC_HDMI_AUDIO
+ tristate "HDMI audio support for OMAP4+ based SoCs"
+ depends on SND_OMAP_SOC
+ help
+ For HDMI audio to work OMAPDSS HDMI support should be
+ enabled.
+ The hdmi audio driver implements cpu-dai component using the
+ callbacks provided by OMAPDSS and registers the component
+ under DSS HDMI device. Omap-pcm is registered for platform
+ component also under DSS HDMI device. Dummy codec is used as
+ as codec component. The hdmi audio driver implements also
+ the card and registers it under its own platform device.
+ The device for the driver is registered by OMAPDSS hdmi
+ driver.
diff --git a/sound/soc/platforms/omap/Makefile b/sound/soc/platforms/omap/Makefile
new file mode 100644
index 000000000000..1e83ac1f664b
--- /dev/null
+++ b/sound/soc/platforms/omap/Makefile
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0
+# OMAP Platform Support
+snd-soc-omap-objs := omap-pcm.o
+snd-soc-omap-dmic-objs := omap-dmic.o
+snd-soc-omap-mcbsp-objs := omap-mcbsp.o mcbsp.o
+snd-soc-omap-mcpdm-objs := omap-mcpdm.o
+snd-soc-omap-hdmi-audio-objs := omap-hdmi-audio.o
+
+obj-$(CONFIG_SND_OMAP_SOC) += snd-soc-omap.o
+obj-$(CONFIG_SND_OMAP_SOC_DMIC) += snd-soc-omap-dmic.o
+obj-$(CONFIG_SND_OMAP_SOC_MCBSP) += snd-soc-omap-mcbsp.o
+obj-$(CONFIG_SND_OMAP_SOC_MCPDM) += snd-soc-omap-mcpdm.o
+obj-$(CONFIG_SND_OMAP_SOC_HDMI_AUDIO) += snd-soc-omap-hdmi-audio.o
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/platforms/omap/mcbsp.c
similarity index 100%
rename from sound/soc/omap/mcbsp.c
rename to sound/soc/platforms/omap/mcbsp.c
diff --git a/sound/soc/omap/mcbsp.h b/sound/soc/platforms/omap/mcbsp.h
similarity index 100%
rename from sound/soc/omap/mcbsp.h
rename to sound/soc/platforms/omap/mcbsp.h
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/platforms/omap/omap-dmic.c
similarity index 100%
rename from sound/soc/omap/omap-dmic.c
rename to sound/soc/platforms/omap/omap-dmic.c
diff --git a/sound/soc/omap/omap-dmic.h b/sound/soc/platforms/omap/omap-dmic.h
similarity index 100%
rename from sound/soc/omap/omap-dmic.h
rename to sound/soc/platforms/omap/omap-dmic.h
diff --git a/sound/soc/omap/omap-hdmi-audio.c b/sound/soc/platforms/omap/omap-hdmi-audio.c
similarity index 100%
rename from sound/soc/omap/omap-hdmi-audio.c
rename to sound/soc/platforms/omap/omap-hdmi-audio.c
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/platforms/omap/omap-mcbsp.c
similarity index 100%
rename from sound/soc/omap/omap-mcbsp.c
rename to sound/soc/platforms/omap/omap-mcbsp.c
diff --git a/sound/soc/omap/omap-mcbsp.h b/sound/soc/platforms/omap/omap-mcbsp.h
similarity index 100%
rename from sound/soc/omap/omap-mcbsp.h
rename to sound/soc/platforms/omap/omap-mcbsp.h
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/platforms/omap/omap-mcpdm.c
similarity index 100%
rename from sound/soc/omap/omap-mcpdm.c
rename to sound/soc/platforms/omap/omap-mcpdm.c
diff --git a/sound/soc/omap/omap-mcpdm.h b/sound/soc/platforms/omap/omap-mcpdm.h
similarity index 100%
rename from sound/soc/omap/omap-mcpdm.h
rename to sound/soc/platforms/omap/omap-mcpdm.h
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/platforms/omap/omap-pcm.c
similarity index 100%
rename from sound/soc/omap/omap-pcm.c
rename to sound/soc/platforms/omap/omap-pcm.c
--
2.15.0
^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
2017-12-05 18:14 ` Andrew F. Davis
@ 2017-12-06 12:39 ` Mark Brown
-1 siblings, 0 replies; 24+ messages in thread
From: Mark Brown @ 2017-12-06 12:39 UTC (permalink / raw)
To: Andrew F. Davis; +Cc: Liam Girdwood, alsa-devel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
On Tue, Dec 05, 2017 at 12:14:46PM -0600, Andrew F. Davis wrote:
> Platform ASoC drivers are a lot like ASoC CODEC drivers in that they
> both are independent pieces of a sound device, or "machine". Platform
> drivers should be free of CODEC specifics and visa-versa. Both are then
> used by the the "machine" driver to form the complete sound device.
> This forms a hierarchy that makes it natural to group platform drivers
> into their own directory, much like we group CODEC drivers already.
This seems like a step backwards, and your current patch set only does
this for the TI drivers anyway. Currently we have things split up by IP
holder, with machine drivers that have some platform specifics grouped
together with the matching IP drivers that may also share some platform
specific considerations. This would group all the IP drivers together
and separate them from the machine drivers they work in concert with for
no obvious benefit.
If you want to make a common directory for TI stuff do that, there's no
need to mess up all the other platforms to do that though.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
@ 2017-12-06 12:39 ` Mark Brown
0 siblings, 0 replies; 24+ messages in thread
From: Mark Brown @ 2017-12-06 12:39 UTC (permalink / raw)
To: Andrew F. Davis; +Cc: alsa-devel, Liam Girdwood, linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1079 bytes --]
On Tue, Dec 05, 2017 at 12:14:46PM -0600, Andrew F. Davis wrote:
> Platform ASoC drivers are a lot like ASoC CODEC drivers in that they
> both are independent pieces of a sound device, or "machine". Platform
> drivers should be free of CODEC specifics and visa-versa. Both are then
> used by the the "machine" driver to form the complete sound device.
> This forms a hierarchy that makes it natural to group platform drivers
> into their own directory, much like we group CODEC drivers already.
This seems like a step backwards, and your current patch set only does
this for the TI drivers anyway. Currently we have things split up by IP
holder, with machine drivers that have some platform specifics grouped
together with the matching IP drivers that may also share some platform
specific considerations. This would group all the IP drivers together
and separate them from the machine drivers they work in concert with for
no obvious benefit.
If you want to make a common directory for TI stuff do that, there's no
need to mess up all the other platforms to do that though.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
2017-12-06 12:39 ` Mark Brown
@ 2017-12-06 16:06 ` Andrew F. Davis
-1 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-06 16:06 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, alsa-devel, linux-kernel
On 12/06/2017 06:39 AM, Mark Brown wrote:
> On Tue, Dec 05, 2017 at 12:14:46PM -0600, Andrew F. Davis wrote:
>> Platform ASoC drivers are a lot like ASoC CODEC drivers in that they
>> both are independent pieces of a sound device, or "machine". Platform
>> drivers should be free of CODEC specifics and visa-versa. Both are then
>> used by the the "machine" driver to form the complete sound device.
>> This forms a hierarchy that makes it natural to group platform drivers
>> into their own directory, much like we group CODEC drivers already.
>
> This seems like a step backwards, and your current patch set only does
> this for the TI drivers anyway. Currently we have things split up by IP
> holder, with machine drivers that have some platform specifics grouped
> together with the matching IP drivers that may also share some platform
> specific considerations. This would group all the IP drivers together
> and separate them from the machine drivers they work in concert with for
> no obvious benefit.
>
My current patches are an RFC with a couple examples, so I only moved
two TI platforms that I was familiar with, others would follow.
Your wording seems a bit inconsistent to me, what do you mean by "IP
drivers", CODEC or SoC internal IP? For clarity I'll try to use only the
three driver type labels: codec, platform, and machine. This is all in
Documentation/sound/soc/overview.rst which I'm sure you are familiar
with as you seem to have had a hand in writing it.
Anyway, I'm working under the assumption that we should try to enforce a
logical separation between component drivers: codec drivers should be
agnostic to what machine they are placed, platform drivers should do the
same and not make special arrangements to work with one machine in
particular. Machine drivers on the other hand will need to dig into
specifics of the codec and platform drivers that they use and connect.
With this in mind I do not see any reason not to have platform drivers
in a platforms/ directory just like we do with codecs/. In case there
was any confusion, I still want to keep the platform drivers' files all
grouped in directories by IP holder, just moved under this platforms/.
This has the benefit of reducing exactly what you are talking about,
platform drivers working in concert with machine drivers, instead of the
other way around.
This isn't only confusing to me, but other first time ASoC devs:
https://stackoverflow.com/questions/20110801/asoc-drivers-which-files-are-platform-machine-and-codec-drivers
even the answerer seems to assume there is a
sound/soc/platforms/, for the same reason we have sound/soc/codecs/.
> If you want to make a common directory for TI stuff do that, there's no
> need to mess up all the other platforms to do that though.
>
Do you mean sounds/soc/ti/{platforms,machines}/ ? I could do this, but I
don't see how what I've done in my example patches has any effect on
other IP holders, they are free to migrate as the please.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
@ 2017-12-06 16:06 ` Andrew F. Davis
0 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-06 16:06 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, alsa-devel, linux-kernel
On 12/06/2017 06:39 AM, Mark Brown wrote:
> On Tue, Dec 05, 2017 at 12:14:46PM -0600, Andrew F. Davis wrote:
>> Platform ASoC drivers are a lot like ASoC CODEC drivers in that they
>> both are independent pieces of a sound device, or "machine". Platform
>> drivers should be free of CODEC specifics and visa-versa. Both are then
>> used by the the "machine" driver to form the complete sound device.
>> This forms a hierarchy that makes it natural to group platform drivers
>> into their own directory, much like we group CODEC drivers already.
>
> This seems like a step backwards, and your current patch set only does
> this for the TI drivers anyway. Currently we have things split up by IP
> holder, with machine drivers that have some platform specifics grouped
> together with the matching IP drivers that may also share some platform
> specific considerations. This would group all the IP drivers together
> and separate them from the machine drivers they work in concert with for
> no obvious benefit.
>
My current patches are an RFC with a couple examples, so I only moved
two TI platforms that I was familiar with, others would follow.
Your wording seems a bit inconsistent to me, what do you mean by "IP
drivers", CODEC or SoC internal IP? For clarity I'll try to use only the
three driver type labels: codec, platform, and machine. This is all in
Documentation/sound/soc/overview.rst which I'm sure you are familiar
with as you seem to have had a hand in writing it.
Anyway, I'm working under the assumption that we should try to enforce a
logical separation between component drivers: codec drivers should be
agnostic to what machine they are placed, platform drivers should do the
same and not make special arrangements to work with one machine in
particular. Machine drivers on the other hand will need to dig into
specifics of the codec and platform drivers that they use and connect.
With this in mind I do not see any reason not to have platform drivers
in a platforms/ directory just like we do with codecs/. In case there
was any confusion, I still want to keep the platform drivers' files all
grouped in directories by IP holder, just moved under this platforms/.
This has the benefit of reducing exactly what you are talking about,
platform drivers working in concert with machine drivers, instead of the
other way around.
This isn't only confusing to me, but other first time ASoC devs:
https://stackoverflow.com/questions/20110801/asoc-drivers-which-files-are-platform-machine-and-codec-drivers
even the answerer seems to assume there is a
sound/soc/platforms/, for the same reason we have sound/soc/codecs/.
> If you want to make a common directory for TI stuff do that, there's no
> need to mess up all the other platforms to do that though.
>
Do you mean sounds/soc/ti/{platforms,machines}/ ? I could do this, but I
don't see how what I've done in my example patches has any effect on
other IP holders, they are free to migrate as the please.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
2017-12-06 16:06 ` Andrew F. Davis
@ 2017-12-06 17:29 ` Mark Brown
-1 siblings, 0 replies; 24+ messages in thread
From: Mark Brown @ 2017-12-06 17:29 UTC (permalink / raw)
To: Andrew F. Davis; +Cc: Liam Girdwood, alsa-devel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 3501 bytes --]
On Wed, Dec 06, 2017 at 10:06:34AM -0600, Andrew F. Davis wrote:
> Your wording seems a bit inconsistent to me, what do you mean by "IP
> drivers", CODEC or SoC internal IP? For clarity I'll try to use only the
> three driver type labels: codec, platform, and machine. This is all in
> Documentation/sound/soc/overview.rst which I'm sure you are familiar
> with as you seem to have had a hand in writing it.
IPs in SoCs.
> Anyway, I'm working under the assumption that we should try to enforce a
> logical separation between component drivers: codec drivers should be
> agnostic to what machine they are placed, platform drivers should do the
> same and not make special arrangements to work with one machine in
> particular. Machine drivers on the other hand will need to dig into
> specifics of the codec and platform drivers that they use and connect.
Machine and drivers for SoC internal stuff tend to be bound fairly
closely together, simiarly the various drivers for an IP on a SoC often
know things about each other for various reasons.
> With this in mind I do not see any reason not to have platform drivers
> in a platforms/ directory just like we do with codecs/. In case there
> was any confusion, I still want to keep the platform drivers' files all
> grouped in directories by IP holder, just moved under this platforms/.
Moving everything around is at the very least going to be a pain for
anyone doing backports and anyone actively working on patches, splitting
the machine drivers from the rest of the drivers for systems based on
that SoC means it's going to be a little harder for people to find
relevant system specific machine drivers. Generic machine drivers are
already split out.
Any benefits seem very weak here and it's an awfully disruptive change.
> This has the benefit of reducing exactly what you are talking about,
> platform drivers working in concert with machine drivers, instead of the
> other way around.
What I am saying is that they go together very closely. Moving the code
around isn't going to change that.
> This isn't only confusing to me, but other first time ASoC devs:
> https://stackoverflow.com/questions/20110801/asoc-drivers-which-files-are-platform-machine-and-codec-drivers
I rather suspect the confusion they're having is more to do with the
fact that the documentation isn't very good than it is to do with where
the files are.
> even the answerer seems to assume there is a
> sound/soc/platforms/, for the same reason we have sound/soc/codecs/.
Or possibly just because they're not very familiar with what they're
talking about here.
> > If you want to make a common directory for TI stuff do that, there's no
> > need to mess up all the other platforms to do that though.
> Do you mean sounds/soc/ti/{platforms,machines}/ ? I could do this, but I
> don't see how what I've done in my example patches has any effect on
> other IP holders, they are free to migrate as the please.
Oh, right. Your commit message sounded like you wanted to dump
everything into a single directory for all SoC side drivers which
doesn't seem like an obviously useful thing, my best guess had been that
you were trying to get all the TI drivers into one directory. I don't
see a pressing need to do that, but I can see it might potentially be
causing issues for people.
If we were going to do this reshuffling then we *really* shouldn't be
doing it randomly for only a few vendors. Doing it inconsistently is
not going to make anything clearer.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
@ 2017-12-06 17:29 ` Mark Brown
0 siblings, 0 replies; 24+ messages in thread
From: Mark Brown @ 2017-12-06 17:29 UTC (permalink / raw)
To: Andrew F. Davis; +Cc: alsa-devel, Liam Girdwood, linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 3501 bytes --]
On Wed, Dec 06, 2017 at 10:06:34AM -0600, Andrew F. Davis wrote:
> Your wording seems a bit inconsistent to me, what do you mean by "IP
> drivers", CODEC or SoC internal IP? For clarity I'll try to use only the
> three driver type labels: codec, platform, and machine. This is all in
> Documentation/sound/soc/overview.rst which I'm sure you are familiar
> with as you seem to have had a hand in writing it.
IPs in SoCs.
> Anyway, I'm working under the assumption that we should try to enforce a
> logical separation between component drivers: codec drivers should be
> agnostic to what machine they are placed, platform drivers should do the
> same and not make special arrangements to work with one machine in
> particular. Machine drivers on the other hand will need to dig into
> specifics of the codec and platform drivers that they use and connect.
Machine and drivers for SoC internal stuff tend to be bound fairly
closely together, simiarly the various drivers for an IP on a SoC often
know things about each other for various reasons.
> With this in mind I do not see any reason not to have platform drivers
> in a platforms/ directory just like we do with codecs/. In case there
> was any confusion, I still want to keep the platform drivers' files all
> grouped in directories by IP holder, just moved under this platforms/.
Moving everything around is at the very least going to be a pain for
anyone doing backports and anyone actively working on patches, splitting
the machine drivers from the rest of the drivers for systems based on
that SoC means it's going to be a little harder for people to find
relevant system specific machine drivers. Generic machine drivers are
already split out.
Any benefits seem very weak here and it's an awfully disruptive change.
> This has the benefit of reducing exactly what you are talking about,
> platform drivers working in concert with machine drivers, instead of the
> other way around.
What I am saying is that they go together very closely. Moving the code
around isn't going to change that.
> This isn't only confusing to me, but other first time ASoC devs:
> https://stackoverflow.com/questions/20110801/asoc-drivers-which-files-are-platform-machine-and-codec-drivers
I rather suspect the confusion they're having is more to do with the
fact that the documentation isn't very good than it is to do with where
the files are.
> even the answerer seems to assume there is a
> sound/soc/platforms/, for the same reason we have sound/soc/codecs/.
Or possibly just because they're not very familiar with what they're
talking about here.
> > If you want to make a common directory for TI stuff do that, there's no
> > need to mess up all the other platforms to do that though.
> Do you mean sounds/soc/ti/{platforms,machines}/ ? I could do this, but I
> don't see how what I've done in my example patches has any effect on
> other IP holders, they are free to migrate as the please.
Oh, right. Your commit message sounded like you wanted to dump
everything into a single directory for all SoC side drivers which
doesn't seem like an obviously useful thing, my best guess had been that
you were trying to get all the TI drivers into one directory. I don't
see a pressing need to do that, but I can see it might potentially be
causing issues for people.
If we were going to do this reshuffling then we *really* shouldn't be
doing it randomly for only a few vendors. Doing it inconsistently is
not going to make anything clearer.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
2017-12-06 17:29 ` Mark Brown
@ 2017-12-06 18:13 ` Andrew F. Davis
-1 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-06 18:13 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, alsa-devel, linux-kernel
On 12/06/2017 11:29 AM, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 10:06:34AM -0600, Andrew F. Davis wrote:
>
>> Your wording seems a bit inconsistent to me, what do you mean by "IP
>> drivers", CODEC or SoC internal IP? For clarity I'll try to use only the
>> three driver type labels: codec, platform, and machine. This is all in
>> Documentation/sound/soc/overview.rst which I'm sure you are familiar
>> with as you seem to have had a hand in writing it.
>
> IPs in SoCs.
>
>> Anyway, I'm working under the assumption that we should try to enforce a
>> logical separation between component drivers: codec drivers should be
>> agnostic to what machine they are placed, platform drivers should do the
>> same and not make special arrangements to work with one machine in
>> particular. Machine drivers on the other hand will need to dig into
>> specifics of the codec and platform drivers that they use and connect.
>
> Machine and drivers for SoC internal stuff tend to be bound fairly
> closely together, simiarly the various drivers for an IP on a SoC often
> know things about each other for various reasons.
>
This is the problem, we don't want them to be so tightly bound, and
luckily, for the most part they are not. Even a complex and history rich
platform like OMAP was rather trivial to split from its various machine
drivers.
>> With this in mind I do not see any reason not to have platform drivers
>> in a platforms/ directory just like we do with codecs/. In case there
>> was any confusion, I still want to keep the platform drivers' files all
>> grouped in directories by IP holder, just moved under this platforms/.
>
> Moving everything around is at the very least going to be a pain for
> anyone doing backports and anyone actively working on patches, splitting
> the machine drivers from the rest of the drivers for systems based on
> that SoC means it's going to be a little harder for people to find
> relevant system specific machine drivers. Generic machine drivers are
> already split out.
>
> Any benefits seem very weak here and it's an awfully disruptive change.
>
While it may still be a small pain for people currently building patches
against the old structure, for back-ports, git seems to handle these
renames well and follows the file patches back to the old location.
>> This has the benefit of reducing exactly what you are talking about,
>> platform drivers working in concert with machine drivers, instead of the
>> other way around.
>
> What I am saying is that they go together very closely. Moving the code
> around isn't going to change that.
>
Not at first, but this partition will discourage future machine-platform
mash-ups (like omap-hdmi-audio.c, yuck).
My end-goal here is to start trimming the needed machine drivers and
replacing them with generics, a couple OMAP machine drivers do nothing
that couldn't be done with the "asoc-simple-card" driver. With the
machine drivers split out form the platform drivers it becomes easier to
target them.
>> This isn't only confusing to me, but other first time ASoC devs:
>> https://stackoverflow.com/questions/20110801/asoc-drivers-which-files-are-platform-machine-and-codec-drivers
>
> I rather suspect the confusion they're having is more to do with the
> fact that the documentation isn't very good than it is to do with where
> the files are.
>
The documentation wont have to explain why platform and machine drivers
are mashed together in top-level directories if we fix this here :)
>> even the answerer seems to assume there is a
>> sound/soc/platforms/, for the same reason we have sound/soc/codecs/.
>
> Or possibly just because they're not very familiar with what they're
> talking about here.
>
That does seems to be the case, but the assumption was still that a
partitioning should exist.
>>> If you want to make a common directory for TI stuff do that, there's no
>>> need to mess up all the other platforms to do that though.
>
>> Do you mean sounds/soc/ti/{platforms,machines}/ ? I could do this, but I
>> don't see how what I've done in my example patches has any effect on
>> other IP holders, they are free to migrate as the please.
>
> Oh, right. Your commit message sounded like you wanted to dump
> everything into a single directory for all SoC side drivers which
> doesn't seem like an obviously useful thing, my best guess had been that
> you were trying to get all the TI drivers into one directory. I don't
> see a pressing need to do that, but I can see it might potentially be
> causing issues for people.
>
I don't have any need to group the TI platforms (Davinci / OMAP) right
now, but I *have* been thinking about grouping the TI CODECs, they share
a lot of code that could be factored out if they were stored in their
own space sound/soc/codecs/ti/. Plus it would make it easy to add myself
as a reviewer for them (I seem to be getting a lot of internal support
requests for these drivers these days). That can be a re-org for another
day, unless you would like me to post an RFC with what I had in mind?
> If we were going to do this reshuffling then we *really* shouldn't be
> doing it randomly for only a few vendors. Doing it inconsistently is
> not going to make anything clearer.
>
I can send patches for rest of the vendors if you would like to see that
and what the end result would look like.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
@ 2017-12-06 18:13 ` Andrew F. Davis
0 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-06 18:13 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, Liam Girdwood, linux-kernel
On 12/06/2017 11:29 AM, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 10:06:34AM -0600, Andrew F. Davis wrote:
>
>> Your wording seems a bit inconsistent to me, what do you mean by "IP
>> drivers", CODEC or SoC internal IP? For clarity I'll try to use only the
>> three driver type labels: codec, platform, and machine. This is all in
>> Documentation/sound/soc/overview.rst which I'm sure you are familiar
>> with as you seem to have had a hand in writing it.
>
> IPs in SoCs.
>
>> Anyway, I'm working under the assumption that we should try to enforce a
>> logical separation between component drivers: codec drivers should be
>> agnostic to what machine they are placed, platform drivers should do the
>> same and not make special arrangements to work with one machine in
>> particular. Machine drivers on the other hand will need to dig into
>> specifics of the codec and platform drivers that they use and connect.
>
> Machine and drivers for SoC internal stuff tend to be bound fairly
> closely together, simiarly the various drivers for an IP on a SoC often
> know things about each other for various reasons.
>
This is the problem, we don't want them to be so tightly bound, and
luckily, for the most part they are not. Even a complex and history rich
platform like OMAP was rather trivial to split from its various machine
drivers.
>> With this in mind I do not see any reason not to have platform drivers
>> in a platforms/ directory just like we do with codecs/. In case there
>> was any confusion, I still want to keep the platform drivers' files all
>> grouped in directories by IP holder, just moved under this platforms/.
>
> Moving everything around is at the very least going to be a pain for
> anyone doing backports and anyone actively working on patches, splitting
> the machine drivers from the rest of the drivers for systems based on
> that SoC means it's going to be a little harder for people to find
> relevant system specific machine drivers. Generic machine drivers are
> already split out.
>
> Any benefits seem very weak here and it's an awfully disruptive change.
>
While it may still be a small pain for people currently building patches
against the old structure, for back-ports, git seems to handle these
renames well and follows the file patches back to the old location.
>> This has the benefit of reducing exactly what you are talking about,
>> platform drivers working in concert with machine drivers, instead of the
>> other way around.
>
> What I am saying is that they go together very closely. Moving the code
> around isn't going to change that.
>
Not at first, but this partition will discourage future machine-platform
mash-ups (like omap-hdmi-audio.c, yuck).
My end-goal here is to start trimming the needed machine drivers and
replacing them with generics, a couple OMAP machine drivers do nothing
that couldn't be done with the "asoc-simple-card" driver. With the
machine drivers split out form the platform drivers it becomes easier to
target them.
>> This isn't only confusing to me, but other first time ASoC devs:
>> https://stackoverflow.com/questions/20110801/asoc-drivers-which-files-are-platform-machine-and-codec-drivers
>
> I rather suspect the confusion they're having is more to do with the
> fact that the documentation isn't very good than it is to do with where
> the files are.
>
The documentation wont have to explain why platform and machine drivers
are mashed together in top-level directories if we fix this here :)
>> even the answerer seems to assume there is a
>> sound/soc/platforms/, for the same reason we have sound/soc/codecs/.
>
> Or possibly just because they're not very familiar with what they're
> talking about here.
>
That does seems to be the case, but the assumption was still that a
partitioning should exist.
>>> If you want to make a common directory for TI stuff do that, there's no
>>> need to mess up all the other platforms to do that though.
>
>> Do you mean sounds/soc/ti/{platforms,machines}/ ? I could do this, but I
>> don't see how what I've done in my example patches has any effect on
>> other IP holders, they are free to migrate as the please.
>
> Oh, right. Your commit message sounded like you wanted to dump
> everything into a single directory for all SoC side drivers which
> doesn't seem like an obviously useful thing, my best guess had been that
> you were trying to get all the TI drivers into one directory. I don't
> see a pressing need to do that, but I can see it might potentially be
> causing issues for people.
>
I don't have any need to group the TI platforms (Davinci / OMAP) right
now, but I *have* been thinking about grouping the TI CODECs, they share
a lot of code that could be factored out if they were stored in their
own space sound/soc/codecs/ti/. Plus it would make it easy to add myself
as a reviewer for them (I seem to be getting a lot of internal support
requests for these drivers these days). That can be a re-org for another
day, unless you would like me to post an RFC with what I had in mind?
> If we were going to do this reshuffling then we *really* shouldn't be
> doing it randomly for only a few vendors. Doing it inconsistently is
> not going to make anything clearer.
>
I can send patches for rest of the vendors if you would like to see that
and what the end result would look like.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
2017-12-06 18:13 ` Andrew F. Davis
@ 2017-12-06 18:42 ` Mark Brown
-1 siblings, 0 replies; 24+ messages in thread
From: Mark Brown @ 2017-12-06 18:42 UTC (permalink / raw)
To: Andrew F. Davis; +Cc: Liam Girdwood, alsa-devel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2786 bytes --]
On Wed, Dec 06, 2017 at 12:13:22PM -0600, Andrew F. Davis wrote:
> On 12/06/2017 11:29 AM, Mark Brown wrote:
> > Machine and drivers for SoC internal stuff tend to be bound fairly
> > closely together, simiarly the various drivers for an IP on a SoC often
> > know things about each other for various reasons.
> This is the problem, we don't want them to be so tightly bound, and
> luckily, for the most part they are not. Even a complex and history rich
> platform like OMAP was rather trivial to split from its various machine
> drivers.
Anything new that can is already getting pushed into using the existing
generic cards. New machine drivers are only for things where that's not
possible.
> > What I am saying is that they go together very closely. Moving the code
> > around isn't going to change that.
> Not at first, but this partition will discourage future machine-platform
> mash-ups (like omap-hdmi-audio.c, yuck).
It's not a pressing problem.
> My end-goal here is to start trimming the needed machine drivers and
> replacing them with generics, a couple OMAP machine drivers do nothing
> that couldn't be done with the "asoc-simple-card" driver. With the
> machine drivers split out form the platform drivers it becomes easier to
> target them.
We need to preserve old bindings to ensure DT compatiblity, the easiest
way to do that is to keep old machine drivers around. There are plenty
of older drivers that wouldn't be accepted now but would at least need
replacing with a compatibility layer that adapts the bindings onto one
of the generic drivers. That adaption layer would definitely be useful
(basically a big table of platform data) but it'd take time to implement
it.
> I don't have any need to group the TI platforms (Davinci / OMAP) right
> now, but I *have* been thinking about grouping the TI CODECs, they share
> a lot of code that could be factored out if they were stored in their
> own space sound/soc/codecs/ti/. Plus it would make it easy to add myself
You can share code easily enough without moving anything, just make a
library like the arizona drivers did.
> as a reviewer for them (I seem to be getting a lot of internal support
> requests for these drivers these days). That can be a re-org for another
> day, unless you would like me to post an RFC with what I had in mind?
Wouldn't a few regexps in the MAINTAINERS file cover it? We've already
got a bunch of vendors doing this.
> > If we were going to do this reshuffling then we *really* shouldn't be
> > doing it randomly for only a few vendors. Doing it inconsistently is
> > not going to make anything clearer.
> I can send patches for rest of the vendors if you would like to see that
> and what the end result would look like.
I'm not convinced this is a good idea.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
@ 2017-12-06 18:42 ` Mark Brown
0 siblings, 0 replies; 24+ messages in thread
From: Mark Brown @ 2017-12-06 18:42 UTC (permalink / raw)
To: Andrew F. Davis; +Cc: alsa-devel, Liam Girdwood, linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 2786 bytes --]
On Wed, Dec 06, 2017 at 12:13:22PM -0600, Andrew F. Davis wrote:
> On 12/06/2017 11:29 AM, Mark Brown wrote:
> > Machine and drivers for SoC internal stuff tend to be bound fairly
> > closely together, simiarly the various drivers for an IP on a SoC often
> > know things about each other for various reasons.
> This is the problem, we don't want them to be so tightly bound, and
> luckily, for the most part they are not. Even a complex and history rich
> platform like OMAP was rather trivial to split from its various machine
> drivers.
Anything new that can is already getting pushed into using the existing
generic cards. New machine drivers are only for things where that's not
possible.
> > What I am saying is that they go together very closely. Moving the code
> > around isn't going to change that.
> Not at first, but this partition will discourage future machine-platform
> mash-ups (like omap-hdmi-audio.c, yuck).
It's not a pressing problem.
> My end-goal here is to start trimming the needed machine drivers and
> replacing them with generics, a couple OMAP machine drivers do nothing
> that couldn't be done with the "asoc-simple-card" driver. With the
> machine drivers split out form the platform drivers it becomes easier to
> target them.
We need to preserve old bindings to ensure DT compatiblity, the easiest
way to do that is to keep old machine drivers around. There are plenty
of older drivers that wouldn't be accepted now but would at least need
replacing with a compatibility layer that adapts the bindings onto one
of the generic drivers. That adaption layer would definitely be useful
(basically a big table of platform data) but it'd take time to implement
it.
> I don't have any need to group the TI platforms (Davinci / OMAP) right
> now, but I *have* been thinking about grouping the TI CODECs, they share
> a lot of code that could be factored out if they were stored in their
> own space sound/soc/codecs/ti/. Plus it would make it easy to add myself
You can share code easily enough without moving anything, just make a
library like the arizona drivers did.
> as a reviewer for them (I seem to be getting a lot of internal support
> requests for these drivers these days). That can be a re-org for another
> day, unless you would like me to post an RFC with what I had in mind?
Wouldn't a few regexps in the MAINTAINERS file cover it? We've already
got a bunch of vendors doing this.
> > If we were going to do this reshuffling then we *really* shouldn't be
> > doing it randomly for only a few vendors. Doing it inconsistently is
> > not going to make anything clearer.
> I can send patches for rest of the vendors if you would like to see that
> and what the end result would look like.
I'm not convinced this is a good idea.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
2017-12-06 18:42 ` Mark Brown
@ 2017-12-06 18:49 ` Andrew F. Davis
-1 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-06 18:49 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, alsa-devel, linux-kernel
On 12/06/2017 12:42 PM, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 12:13:22PM -0600, Andrew F. Davis wrote:
>> On 12/06/2017 11:29 AM, Mark Brown wrote:
>
>>> Machine and drivers for SoC internal stuff tend to be bound fairly
>>> closely together, simiarly the various drivers for an IP on a SoC often
>>> know things about each other for various reasons.
>
>> This is the problem, we don't want them to be so tightly bound, and
>> luckily, for the most part they are not. Even a complex and history rich
>> platform like OMAP was rather trivial to split from its various machine
>> drivers.
>
> Anything new that can is already getting pushed into using the existing
> generic cards. New machine drivers are only for things where that's not
> possible.
>
>>> What I am saying is that they go together very closely. Moving the code
>>> around isn't going to change that.
>
>> Not at first, but this partition will discourage future machine-platform
>> mash-ups (like omap-hdmi-audio.c, yuck).
>
> It's not a pressing problem.
>
>> My end-goal here is to start trimming the needed machine drivers and
>> replacing them with generics, a couple OMAP machine drivers do nothing
>> that couldn't be done with the "asoc-simple-card" driver. With the
>> machine drivers split out form the platform drivers it becomes easier to
>> target them.
>
> We need to preserve old bindings to ensure DT compatiblity, the easiest
> way to do that is to keep old machine drivers around. There are plenty
> of older drivers that wouldn't be accepted now but would at least need
> replacing with a compatibility layer that adapts the bindings onto one
> of the generic drivers. That adaption layer would definitely be useful
> (basically a big table of platform data) but it'd take time to implement
> it.
>
We then should at least start depreciating them now so that someday we
can drop that stuff. Isolating them would be the first step.
>> I don't have any need to group the TI platforms (Davinci / OMAP) right
>> now, but I *have* been thinking about grouping the TI CODECs, they share
>> a lot of code that could be factored out if they were stored in their
>> own space sound/soc/codecs/ti/. Plus it would make it easy to add myself
>
> You can share code easily enough without moving anything, just make a
> library like the arizona drivers did.
>
The lack of organization bugs me, this is why directories exist.
>> as a reviewer for them (I seem to be getting a lot of internal support
>> requests for these drivers these days). That can be a re-org for another
>> day, unless you would like me to post an RFC with what I had in mind?
>
> Wouldn't a few regexps in the MAINTAINERS file cover it? We've already
> got a bunch of vendors doing this.
>
pcm*
tas*
tlv*
twl*
It's messy how many prefixes we have :/
>>> If we were going to do this reshuffling then we *really* shouldn't be
>>> doing it randomly for only a few vendors. Doing it inconsistently is
>>> not going to make anything clearer.
>
>> I can send patches for rest of the vendors if you would like to see that
>> and what the end result would look like.
>
> I'm not convinced this is a good idea.
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
@ 2017-12-06 18:49 ` Andrew F. Davis
0 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-06 18:49 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, Liam Girdwood, linux-kernel
On 12/06/2017 12:42 PM, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 12:13:22PM -0600, Andrew F. Davis wrote:
>> On 12/06/2017 11:29 AM, Mark Brown wrote:
>
>>> Machine and drivers for SoC internal stuff tend to be bound fairly
>>> closely together, simiarly the various drivers for an IP on a SoC often
>>> know things about each other for various reasons.
>
>> This is the problem, we don't want them to be so tightly bound, and
>> luckily, for the most part they are not. Even a complex and history rich
>> platform like OMAP was rather trivial to split from its various machine
>> drivers.
>
> Anything new that can is already getting pushed into using the existing
> generic cards. New machine drivers are only for things where that's not
> possible.
>
>>> What I am saying is that they go together very closely. Moving the code
>>> around isn't going to change that.
>
>> Not at first, but this partition will discourage future machine-platform
>> mash-ups (like omap-hdmi-audio.c, yuck).
>
> It's not a pressing problem.
>
>> My end-goal here is to start trimming the needed machine drivers and
>> replacing them with generics, a couple OMAP machine drivers do nothing
>> that couldn't be done with the "asoc-simple-card" driver. With the
>> machine drivers split out form the platform drivers it becomes easier to
>> target them.
>
> We need to preserve old bindings to ensure DT compatiblity, the easiest
> way to do that is to keep old machine drivers around. There are plenty
> of older drivers that wouldn't be accepted now but would at least need
> replacing with a compatibility layer that adapts the bindings onto one
> of the generic drivers. That adaption layer would definitely be useful
> (basically a big table of platform data) but it'd take time to implement
> it.
>
We then should at least start depreciating them now so that someday we
can drop that stuff. Isolating them would be the first step.
>> I don't have any need to group the TI platforms (Davinci / OMAP) right
>> now, but I *have* been thinking about grouping the TI CODECs, they share
>> a lot of code that could be factored out if they were stored in their
>> own space sound/soc/codecs/ti/. Plus it would make it easy to add myself
>
> You can share code easily enough without moving anything, just make a
> library like the arizona drivers did.
>
The lack of organization bugs me, this is why directories exist.
>> as a reviewer for them (I seem to be getting a lot of internal support
>> requests for these drivers these days). That can be a re-org for another
>> day, unless you would like me to post an RFC with what I had in mind?
>
> Wouldn't a few regexps in the MAINTAINERS file cover it? We've already
> got a bunch of vendors doing this.
>
pcm*
tas*
tlv*
twl*
It's messy how many prefixes we have :/
>>> If we were going to do this reshuffling then we *really* shouldn't be
>>> doing it randomly for only a few vendors. Doing it inconsistently is
>>> not going to make anything clearer.
>
>> I can send patches for rest of the vendors if you would like to see that
>> and what the end result would look like.
>
> I'm not convinced this is a good idea.
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
2017-12-06 18:49 ` Andrew F. Davis
@ 2017-12-06 19:27 ` Mark Brown
-1 siblings, 0 replies; 24+ messages in thread
From: Mark Brown @ 2017-12-06 19:27 UTC (permalink / raw)
To: Andrew F. Davis; +Cc: Liam Girdwood, alsa-devel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]
On Wed, Dec 06, 2017 at 12:49:39PM -0600, Andrew F. Davis wrote:
> On 12/06/2017 12:42 PM, Mark Brown wrote:
> > We need to preserve old bindings to ensure DT compatiblity, the easiest
> > way to do that is to keep old machine drivers around. There are plenty
> > of older drivers that wouldn't be accepted now but would at least need
> > replacing with a compatibility layer that adapts the bindings onto one
> > of the generic drivers. That adaption layer would definitely be useful
> > (basically a big table of platform data) but it'd take time to implement
> > it.
> We then should at least start depreciating them now so that someday we
> can drop that stuff. Isolating them would be the first step.
Moving the drivers around is not going to help with that. For users the
drivers are not deprecated until someone actually steps up and makes
something that allows the generic drivers to handle the old bindings and
moves them over, at which point we'd just remove things that have been
converted. We can't just tell them not to use something without
providing an alternative. For developers they're just going to end up
with the simpler machine drivers sitting next to a bunch of machine
drivers that reasonably exist which I'm not sure clarifies anything.
It's an orthogonal problem.
> > Wouldn't a few regexps in the MAINTAINERS file cover it? We've already
> > got a bunch of vendors doing this.
> pcm*
> tas*
> tlv*
> twl*
> It's messy how many prefixes we have :/
Eh, not that bad. And easy enough to do anyway.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
@ 2017-12-06 19:27 ` Mark Brown
0 siblings, 0 replies; 24+ messages in thread
From: Mark Brown @ 2017-12-06 19:27 UTC (permalink / raw)
To: Andrew F. Davis; +Cc: alsa-devel, Liam Girdwood, linux-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1536 bytes --]
On Wed, Dec 06, 2017 at 12:49:39PM -0600, Andrew F. Davis wrote:
> On 12/06/2017 12:42 PM, Mark Brown wrote:
> > We need to preserve old bindings to ensure DT compatiblity, the easiest
> > way to do that is to keep old machine drivers around. There are plenty
> > of older drivers that wouldn't be accepted now but would at least need
> > replacing with a compatibility layer that adapts the bindings onto one
> > of the generic drivers. That adaption layer would definitely be useful
> > (basically a big table of platform data) but it'd take time to implement
> > it.
> We then should at least start depreciating them now so that someday we
> can drop that stuff. Isolating them would be the first step.
Moving the drivers around is not going to help with that. For users the
drivers are not deprecated until someone actually steps up and makes
something that allows the generic drivers to handle the old bindings and
moves them over, at which point we'd just remove things that have been
converted. We can't just tell them not to use something without
providing an alternative. For developers they're just going to end up
with the simpler machine drivers sitting next to a bunch of machine
drivers that reasonably exist which I'm not sure clarifies anything.
It's an orthogonal problem.
> > Wouldn't a few regexps in the MAINTAINERS file cover it? We've already
> > got a bunch of vendors doing this.
> pcm*
> tas*
> tlv*
> twl*
> It's messy how many prefixes we have :/
Eh, not that bad. And easy enough to do anyway.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
2017-12-06 19:27 ` Mark Brown
@ 2017-12-06 20:59 ` Andrew F. Davis
-1 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-06 20:59 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, alsa-devel, linux-kernel
On 12/06/2017 01:27 PM, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 12:49:39PM -0600, Andrew F. Davis wrote:
>> On 12/06/2017 12:42 PM, Mark Brown wrote:
>
>>> We need to preserve old bindings to ensure DT compatiblity, the easiest
>>> way to do that is to keep old machine drivers around. There are plenty
>>> of older drivers that wouldn't be accepted now but would at least need
>>> replacing with a compatibility layer that adapts the bindings onto one
>>> of the generic drivers. That adaption layer would definitely be useful
>>> (basically a big table of platform data) but it'd take time to implement
>>> it.
>
>> We then should at least start depreciating them now so that someday we
>> can drop that stuff. Isolating them would be the first step.
>
> Moving the drivers around is not going to help with that. For users the
> drivers are not deprecated until someone actually steps up and makes
> something that allows the generic drivers to handle the old bindings and
> moves them over, at which point we'd just remove things that have been
> converted. We can't just tell them not to use something without
> providing an alternative. For developers they're just going to end up
> with the simpler machine drivers sitting next to a bunch of machine
> drivers that reasonably exist which I'm not sure clarifies anything.
> It's an orthogonal problem.
>
It helps in that people would see an organized set of drivers to target,
"this folder here (sound/soc/machines/) should be reduced as much as
possible". Otherwise it is just, "go dig around for the machine drivers
burred together with platform drivers, which file is which type? Who
knows!?"
I will help too, but there needs to be just a bit of organization first.
>>> Wouldn't a few regexps in the MAINTAINERS file cover it? We've already
>>> got a bunch of vendors doing this.
>
>> pcm*
>> tas*
>> tlv*
>> twl*
>
>> It's messy how many prefixes we have :/
>
> Eh, not that bad. And easy enough to do anyway.
>
And it is easy enough to group them into a directory by something like
vendor, same as everyone else, including your very own sound/soc/. Yet
codecs/ is a giant 400+ file blob, by C file count it is the largest
directory in the whole kernel...
Top 10:
C files count: folder
130: drivers/staging/comedi/drivers
145: drivers/gpio
159: drivers/watchdog
164: drivers/rtc
165: drivers/hwmon
172: net/netfilter
175: drivers/acpi/acpica
194: lib
201: drivers/mfd
239: sound/soc/codecs
Maybe a bit of grouping wouldn't be so bad
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFC PATCH 1/3] ASoC: Add platforms directory
@ 2017-12-06 20:59 ` Andrew F. Davis
0 siblings, 0 replies; 24+ messages in thread
From: Andrew F. Davis @ 2017-12-06 20:59 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, Liam Girdwood, linux-kernel
On 12/06/2017 01:27 PM, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 12:49:39PM -0600, Andrew F. Davis wrote:
>> On 12/06/2017 12:42 PM, Mark Brown wrote:
>
>>> We need to preserve old bindings to ensure DT compatiblity, the easiest
>>> way to do that is to keep old machine drivers around. There are plenty
>>> of older drivers that wouldn't be accepted now but would at least need
>>> replacing with a compatibility layer that adapts the bindings onto one
>>> of the generic drivers. That adaption layer would definitely be useful
>>> (basically a big table of platform data) but it'd take time to implement
>>> it.
>
>> We then should at least start depreciating them now so that someday we
>> can drop that stuff. Isolating them would be the first step.
>
> Moving the drivers around is not going to help with that. For users the
> drivers are not deprecated until someone actually steps up and makes
> something that allows the generic drivers to handle the old bindings and
> moves them over, at which point we'd just remove things that have been
> converted. We can't just tell them not to use something without
> providing an alternative. For developers they're just going to end up
> with the simpler machine drivers sitting next to a bunch of machine
> drivers that reasonably exist which I'm not sure clarifies anything.
> It's an orthogonal problem.
>
It helps in that people would see an organized set of drivers to target,
"this folder here (sound/soc/machines/) should be reduced as much as
possible". Otherwise it is just, "go dig around for the machine drivers
burred together with platform drivers, which file is which type? Who
knows!?"
I will help too, but there needs to be just a bit of organization first.
>>> Wouldn't a few regexps in the MAINTAINERS file cover it? We've already
>>> got a bunch of vendors doing this.
>
>> pcm*
>> tas*
>> tlv*
>> twl*
>
>> It's messy how many prefixes we have :/
>
> Eh, not that bad. And easy enough to do anyway.
>
And it is easy enough to group them into a directory by something like
vendor, same as everyone else, including your very own sound/soc/. Yet
codecs/ is a giant 400+ file blob, by C file count it is the largest
directory in the whole kernel...
Top 10:
C files count: folder
130: drivers/staging/comedi/drivers
145: drivers/gpio
159: drivers/watchdog
164: drivers/rtc
165: drivers/hwmon
172: net/netfilter
175: drivers/acpi/acpica
194: lib
201: drivers/mfd
239: sound/soc/codecs
Maybe a bit of grouping wouldn't be so bad
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2017-12-06 20:59 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-05 18:14 [RFC PATCH 0/3] Add ASoC platforms directory Andrew F. Davis
2017-12-05 18:14 ` Andrew F. Davis
2017-12-05 18:14 ` [RFC PATCH 1/3] ASoC: Add " Andrew F. Davis
2017-12-05 18:14 ` Andrew F. Davis
2017-12-06 12:39 ` Mark Brown
2017-12-06 12:39 ` Mark Brown
2017-12-06 16:06 ` Andrew F. Davis
2017-12-06 16:06 ` Andrew F. Davis
2017-12-06 17:29 ` Mark Brown
2017-12-06 17:29 ` Mark Brown
2017-12-06 18:13 ` Andrew F. Davis
2017-12-06 18:13 ` Andrew F. Davis
2017-12-06 18:42 ` Mark Brown
2017-12-06 18:42 ` Mark Brown
2017-12-06 18:49 ` Andrew F. Davis
2017-12-06 18:49 ` Andrew F. Davis
2017-12-06 19:27 ` Mark Brown
2017-12-06 19:27 ` Mark Brown
2017-12-06 20:59 ` Andrew F. Davis
2017-12-06 20:59 ` Andrew F. Davis
2017-12-05 18:14 ` [RFC PATCH 2/3] ASoC: Platforms: Move Davinci platform drivers into " Andrew F. Davis
2017-12-05 18:14 ` Andrew F. Davis
2017-12-05 18:14 ` [RFC PATCH 3/3] ASoC: Platforms: Move OMAP " Andrew F. Davis
2017-12-05 18:14 ` Andrew F. Davis
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.