alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Liam Girdwood <lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Subject: Re: [PATCH] ASoC: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_*
Date: Wed, 17 Jul 2013 16:52:42 -0600	[thread overview]
Message-ID: <51E7203A.2020007@wwwdotorg.org> (raw)
In-Reply-To: <20130717223309.GZ22506-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>

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?

  parent reply	other threads:[~2013-07-17 22:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-16 22:27 [PATCH] ASoC: tegra: depend on ARCH_TEGRA, not ARCH_TEGRA_* Stephen Warren
     [not found] ` <1374013667-21435-1-git-send-email-swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-07-17  8:30   ` Mark Brown
     [not found]     ` <20130717083003.GA22506-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-07-17 17:01       ` Stephen Warren
2013-07-17 17:57         ` Mark Brown
2013-07-17 18:23           ` Stephen Warren
     [not found]             ` <51E6E107.8020300-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-07-17 22:33               ` Mark Brown
     [not found]                 ` <20130717223309.GZ22506-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-07-17 22:52                   ` Stephen Warren [this message]
     [not found]                     ` <51E7203A.2020007-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-07-18  9:58                       ` Mark Brown
     [not found]                         ` <20130718095815.GE22506-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-07-18 16:58                           ` Stephen Warren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51E7203A.2020007@wwwdotorg.org \
    --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
    --cc=alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org \
    --cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=lgirdwood-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).