public inbox for linux-samsung-soc@vger.kernel.org
 help / color / mirror / Atom feed
From: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
To: Olof Johansson <olof@lixom.net>
Cc: Tomasz Figa <t.figa@samsung.com>,
	Sachin Kamat <sachin.kamat@linaro.org>,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	Kukjin Kim <kgene.kim@samsung.com>
Subject: Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
Date: Thu, 06 Feb 2014 19:43:44 +0100	[thread overview]
Message-ID: <7214831.iPsDTEq8CU@amdc1032> (raw)
In-Reply-To: <CAOesGMi8SUXzxJSW4yoywLQn0C7HmPL81iCQqxg9uZp_jN7yPQ@mail.gmail.com>

On Thursday, February 06, 2014 10:25:09 AM Olof Johansson wrote:
> On Thu, Feb 6, 2014 at 7:02 AM, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@samsung.com> wrote:
> >
> > Hi,
> >
> > On Thursday, February 06, 2014 03:10:39 PM Tomasz Figa wrote:
> >> Hi Sachin,
> >>
> >> On 06.02.2014 12:59, Sachin Kamat wrote:
> >> > Instead of repeating the Kconfig entries for every SoC, move them under
> >> > ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under
> >> > ARCH_EXYNOS. Also, since the individual SoCs do not have any specific
> >> > machine/platform code, keep them as boolean symbols instead of user
> >
> > All soc_is_exynosxxxx() dependent code gets thrown away is specific SoC
> > support is not selected.  With this change this is not longer true.
> > Moreover some drivers are doing explicit ifdef checks for specific SoC
> > support, i.e. thermal driver.
> 
> I'm guessing you're referring to exynos_tmu_data.c? That's not all

Yes.

> that much data, and not all that substantial compared to things like
> pinctrl and clocks. Removing those ifdefs per SoC is reasonable.

I agree.  I just wanted to point out that the current patch description
is not entirely accurate.

> I'm ok with one Kconfig per family (EXYNOS 4 and 5), but we should
> avoid higher granularity than that. That's similar to how OMAP is
> handled. i.MX is more granular but they aren't introducing as many
> SoCs as Samsung so it's not as big a deal.

OK.

> >> > selectable and select them from Exynos4 and 5 config symbols. Individual
> >> > SoC symbols can be removed eventually once the driver Kconfig dependencies
> >> > on these symbols are removed.
> >> >
> >> > Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> >> > ---
> >> >   arch/arm/Kconfig             |   12 ++++++
> >> >   arch/arm/mach-exynos/Kconfig |   97 ++++++++++--------------------------------
> >> >   2 files changed, 35 insertions(+), 74 deletions(-)
> >>
> >> I fully agree that there is no real need of having per-SoC Kconfig
> >> entries, since the differences caused by them are quite insignificant.
> >
> > I think so but some numbers to back it up would be good..
> >
> >> Moreover, this makes me wonder if there is even need to distinguish
> >> between ARCH_EXYNOS4 and ARCH_EXYNOS5...
> >
> > Well, once again, seeing some numbers would be good. :)
> 
> What numbers do you want? Size comparisons with all SoC options on vs only one?

Yes, size comparisions with all SoCs (for given family) turned on vs
only one turned on (done on kernel without this patch applied).

Also size comparisons for ARCH_EXYNOS4 and ARCH_EXYNOS5 both turned
on vs only ARCH_EXYNOS4 or ARCH_EXYNOS5 turned on (with this patch
applied).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

  reply	other threads:[~2014-02-06 18:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-06 11:59 [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries Sachin Kamat
2014-02-06 14:10 ` Tomasz Figa
2014-02-06 15:02   ` Bartlomiej Zolnierkiewicz
2014-02-06 18:25     ` Olof Johansson
2014-02-06 18:43       ` Bartlomiej Zolnierkiewicz [this message]
2014-02-06 18:59         ` Olof Johansson
2014-02-07 16:33           ` Tomasz Figa
2014-02-10  4:50             ` Sachin Kamat
2014-02-11  6:10               ` Kukjin Kim
2014-02-11  6:30                 ` Olof Johansson
2014-02-11 11:15                   ` Tomasz Figa
2014-02-11 11:08                 ` Tomasz Figa
  -- strict thread matches above, loose matches on Subject: below --
2014-04-02  8:55 Sachin Kamat

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=7214831.iPsDTEq8CU@amdc1032 \
    --to=b.zolnierkie@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=sachin.kamat@linaro.org \
    --cc=t.figa@samsung.com \
    /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