ASoC: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*

From: Stephen Warren <swarren@nvidia.com>

I'm planning to remove CONFIG_ARCH_TEGRA_*_SOC, leaving just ARCH_TEGRA.
This will reduce the number of configurations that need to be supported
by core Tegra code, e.g. CPU idle, hotplug. As a precursor, we need to
update Kconfig for all Tegra drivers not to reference ARCH_TEGRA_*_SOC.

Stop selecting I2S/AC97/SPDIF controller drivers from the machine driver
config options; this doesn't really work if we don't know which specific
SoC(s) we're building for. However, set their default values based on
SND_SOC_TEGRA, since most people will probably want to enable support for
all SoCs. This also avoids the need to change any defconfig files.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 sound/soc/tegra/Kconfig | 36 +++++++++++++++---------------------
 1 file changed, 15 insertions(+), 21 deletions(-)

On Tue, Jul 16, 2013 at 04:27:47PM -0600, Stephen Warren wrote:

> Stop selecting I2S/AC97/SPDIF controller drivers from the machine driver
> config options; this doesn't really work if we don't know which specific
> SoC(s) we're building for. However, set their default values based on
> SND_SOC_TEGRA, since most people will probably want to enable support for
> all SoCs. This also avoids the need to change any defconfig files.

This doesn't seem terribly clever and is definitely not idiomatic for
ASoC.  If you want to just select all CPUs that'd be fine but forcing
the user to select the individual components isn't the style anything
else uses.

On 07/17/2013 02:30 AM, Mark Brown wrote:
> On Tue, Jul 16, 2013 at 04:27:47PM -0600, Stephen Warren wrote:
> 
>> Stop selecting I2S/AC97/SPDIF controller drivers from the machine
>> driver config options; this doesn't really work if we don't know
>> which specific SoC(s) we're building for. However, set their
>> default values based on SND_SOC_TEGRA, since most people will
>> probably want to enable support for all SoCs. This also avoids
>> the need to change any defconfig files.
> 
> This doesn't seem terribly clever and is definitely not idiomatic
> for ASoC.  If you want to just select all CPUs that'd be fine but
> forcing the user to select the individual components isn't the
> style anything else uses.

So I think what you're saying is that machine drivers should be
changed like:

-       select SND_SOC_TEGRA20_I2S if ARCH_TEGRA_2x_SOC
-       select SND_SOC_TEGRA30_I2S if ARCH_TEGRA_3x_SOC
+       select SND_SOC_TEGRA20_I2S
+       select SND_SOC_TEGRA30_I2S

But then, it won't be possible to disable support for older SoCs,
since simply enabling a machine driver that might support Tegra20
would force ASoC support for Tegra20 to be enabled, even if the user
only cares about Tegra30.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, Jul 17, 2013 at 11:01:30AM -0600, Stephen Warren wrote:
> On 07/17/2013 02:30 AM, Mark Brown wrote:

> -       select SND_SOC_TEGRA20_I2S if ARCH_TEGRA_2x_SOC
> -       select SND_SOC_TEGRA30_I2S if ARCH_TEGRA_3x_SOC
> +       select SND_SOC_TEGRA20_I2S
> +       select SND_SOC_TEGRA30_I2S

> But then, it won't be possible to disable support for older SoCs,
> since simply enabling a machine driver that might support Tegra20
> would force ASoC support for Tegra20 to be enabled, even if the user
> only cares about Tegra30.

So how do they disable the core support for the older SoCs with the new
model?

On 07/17/2013 11:57 AM, Mark Brown wrote:
> On Wed, Jul 17, 2013 at 11:01:30AM -0600, Stephen Warren wrote:
>> On 07/17/2013 02:30 AM, Mark Brown wrote:
> 
>> -       select SND_SOC_TEGRA20_I2S if ARCH_TEGRA_2x_SOC -
>> select SND_SOC_TEGRA30_I2S if ARCH_TEGRA_3x_SOC +       select
>> SND_SOC_TEGRA20_I2S +       select SND_SOC_TEGRA30_I2S
> 
>> But then, it won't be possible to disable support for older
>> SoCs, since simply enabling a machine driver that might support
>> Tegra20 would force ASoC support for Tegra20 to be enabled, even
>> if the user only cares about Tegra30.
> 
> So how do they disable the core support for the older SoCs with the
> new model?

They don't; the core support is so small it's not worth having the
ifdefs in it; just a few K. As such, it seems simpler to just always
compile in the core support, and remove the need for all the ifdef
nests in mach-tegra/. The bulk of the differences are different
drivers for different chips.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, Jul 17, 2013 at 12:23:03PM -0600, Stephen Warren wrote:
> On 07/17/2013 11:57 AM, Mark Brown wrote:

> > So how do they disable the core support for the older SoCs with the
> > new model?

> They don't; the core support is so small it's not worth having the
> ifdefs in it; just a few K. As such, it seems simpler to just always
> compile in the core support, and remove the need for all the ifdef
> nests in mach-tegra/. The bulk of the differences are different
> drivers for different chips.

So my take on that is that it seems like it's simpler to just have the
core selection since that's just one option for the user to choose and
save all the space for whatever device they're not interested in rather
than having to go through individual drivers disabling the boring SoCs.
It seems more straightfoward from a UI point of view but perhaps I'm not
thinking about it from the right angle?

On 07/17/2013 04:33 PM, Mark Brown wrote:
> On Wed, Jul 17, 2013 at 12:23:03PM -0600, Stephen Warren wrote:
>> On 07/17/2013 11:57 AM, Mark Brown wrote:
> 
>>> So how do they disable the core support for the older SoCs with
>>> the new model?
> 
>> They don't; the core support is so small it's not worth having
>> the ifdefs in it; just a few K. As such, it seems simpler to just
>> always compile in the core support, and remove the need for all
>> the ifdef nests in mach-tegra/. The bulk of the differences are
>> different drivers for different chips.
> 
> So my take on that is that it seems like it's simpler to just have
> the core selection since that's just one option for the user to
> choose and save all the space for whatever device they're not
> interested in rather than having to go through individual drivers
> disabling the boring SoCs. It seems more straightfoward from a UI
> point of view but perhaps I'm not thinking about it from the right
> angle?

Ah, so you mean keep the options in mach-tegra/Kconfig so that there's
a single place to configure per-SoC support, but just ignore those
options in code (like the Tegra CPU reset vector) where it's not worth
it. That sounds reasonable.

The one remaining issue is that we have plenty of HW module whose
driver works across multiple HW generations. For example,
tegra20_i2s.c supports only Tegra20, yet tegra30_i2s.c supports both
Tegra30 and Tegra114, and likely will support other generations too.
The key to enable tegra30_i2s.c should really be ARCH_TEGRA_3x_SOC ||
ARCH_TEGRA_114_SOC, which gets a bit unwieldy once you have, say, 4
different SoCs in that list and a similar list starts to apply to a
lot of different HW-modules/drivers. Even creating an
ARCH_TEGRA_30_OR_LATER_SOC will get problematic, since defining "or
later" will likely become progressively more complex over time, as we
start putting our more SoCs. What are your thoughts on the best way to
solve that?
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, Jul 17, 2013 at 04:52:42PM -0600, Stephen Warren wrote:

> The key to enable tegra30_i2s.c should really be ARCH_TEGRA_3x_SOC ||
> ARCH_TEGRA_114_SOC, which gets a bit unwieldy once you have, say, 4
> different SoCs in that list and a similar list starts to apply to a
> lot of different HW-modules/drivers. Even creating an
> ARCH_TEGRA_30_OR_LATER_SOC will get problematic, since defining "or
> later" will likely become progressively more complex over time, as we
> start putting our more SoCs. What are your thoughts on the best way to
> solve that?

Can't you just say Tegra 20 or later is Tegra 20 plus Tegra 30 or later
and so on?

On 07/18/2013 03:58 AM, Mark Brown wrote:
> On Wed, Jul 17, 2013 at 04:52:42PM -0600, Stephen Warren wrote:
> 
>> The key to enable tegra30_i2s.c should really be
>> ARCH_TEGRA_3x_SOC || ARCH_TEGRA_114_SOC, which gets a bit
>> unwieldy once you have, say, 4 different SoCs in that list and a
>> similar list starts to apply to a lot of different
>> HW-modules/drivers. Even creating an ARCH_TEGRA_30_OR_LATER_SOC
>> will get problematic, since defining "or later" will likely
>> become progressively more complex over time, as we start putting
>> our more SoCs. What are your thoughts on the best way to solve
>> that?
> 
> Can't you just say Tegra 20 or later is Tegra 20 plus Tegra 30 or
> later and so on?

For the chips that are supported upstream right now, that would work.
However, I'm not sure that life will be quite so linear in the future.
In other words, what is "or later" for, say, the SDHCI controller may
not be the same as what is "or later" for, say, the I2C controller.
(feel free to substitute arbitrary HW modules into that statement).
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html