Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758281AbbKSLHa (ORCPT ); Thu, 19 Nov 2015 06:07:30 -0500 Received: from mailout1.w1.samsung.com ([210.118.77.11]:39151 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752892AbbKSLH1 (ORCPT ); Thu, 19 Nov 2015 06:07:27 -0500 X-AuditID: cbfec7f4-f79026d00000418a-e5-564dad6cbc89 Message-id: <564DAD0A.3000007@samsung.com> Date: Thu, 19 Nov 2015 12:05:46 +0100 From: Sylwester Nawrocki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-version: 1.0 To: Tomasz Figa , Krzysztof Kozlowski Cc: Michael Turquette , Stephen Boyd , "linux-samsung-soc@vger.kernel.org" , linux-clk@vger.kernel.org, linux-kernel , Catalin Marinas , Will Deacon , Kukjin Kim , Olof Johansson , Arnd Bergmann , linux-arm-kernel , Kevin Hilman , Pankaj Dubey Subject: Re: [PATCH 1/2] clk: samsung: Don't build ARMv8 clock drivers on ARMv7 References: <1447637775-9887-1-git-send-email-k.kozlowski@samsung.com> <1447637775-9887-2-git-send-email-k.kozlowski@samsung.com> <564D5552.4070806@samsung.com> In-reply-to: Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsVy+t/xy7o5a33DDGbsULP4O+kYu8X7ZT2M Fq9fGFr0P37NbPH18ApGi02Pr7FafOy5x2pxedccNosZ5/cxWVw85Wpx6vpnNotFW7+wW/w4 081isWrXH0aLlx9PsDjwe6yZt4bR4/evSYwe72+0sntc7utl8tg56y67x6ZVnWwed67tYfPY vKTe48qJJlaPvi2rGD0+b5IL4I7isklJzcksSy3St0vgyuhbeJ6pYK5AxeW7F1kbGP/ydDFy ckgImEjs2tbJCmGLSVy4t56ti5GLQ0hgKaPE/wuzWCCc54wSE67eBaviFdCSWPv/EDOIzSKg KtE9YQULiM0mYCjRe7SPEcQWFYiQWL76JCNEvaDEj8n3gGo4OESA4o3PfEBmMgssZ5GYsGcb E0iNsIC/xLuPZ6E2b2KSaJpwDizBKRAscfPES0aQZmYBdYkpU3JBwswC8hKb17xlnsAoMAvJ ilkIVbOQVC1gZF7FKJpamlxQnJSea6hXnJhbXJqXrpecn7uJERJrX3YwLj5mdYhRgINRiYd3 wymfMCHWxLLiytxDjBIczEoivE+n+YYJ8aYkVlalFuXHF5XmpBYfYpTmYFES5527632IkEB6 YklqdmpqQWoRTJaJg1OqgXHFrmhRIdEzeSy/dr6u173vpqIl1s6qsn/GrmjXu7WcF6L4PHaY 6GXPmL9kaaBBNctNz/2qRm+FD/zf39p45M632rsXq+w28xn8vLB34asZp4NcV+xkcjnlU8jT vdfp2oVCtoNKBSJpbc7Pv7649/zSE/U0py0HGI4qKmvLtRz+Pdv42j+PY/+UWIozEg21mIuK EwHmKamRsQIAAA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2276 Lines: 51 On 19/11/15 10:16, Tomasz Figa wrote: > 2015-11-19 13:51 GMT+09:00 Krzysztof Kozlowski : >> > On 19.11.2015 13:18, Tomasz Figa wrote: >>> >> However, I don't think we can disable compilation of particular >>> >> 64-bit SoCs, so maybe there isn't much sense in splitting their >>> >> clock drivers into separate symbols? >> > >> > To me it does not really matter. Indeed as you said one cannot >> > disable building of one particular Exynos SoCs. >> > >> > However we could still want not build some parts of such SoCs (like >> > clock, pinctrl etc). I don't see much benefit for such case except >> > when someone would like to drastically reduce the size of kernel >> > image (for whatever reasons he has.). > > Can we really build a kernel that support selected Exynos SoC without > its clock driver? Actually I don't think we even allow deselecting > clock drivers currently, because they are not visible in menuconfig. > Unless there is a clear goal to separate ARCH level Kconfig symbol for > particular ARM64-based Exynos SoCs, I don't think it makes any sense > to keep the clock-related symbols separate. > >> > >> > On the other hand having separate symbols causes duplication and >> > obfuscates a little the Kconfig/Makefile. I like keeping things >> > simple so one symbol for all ARM64 Exynos clocks sounds good. >> > >> > Sylwester preferred current approach. You and Pankaj seem to prefer >> > one symbol-way. > > Hmm, I read Sylwester's post as a reply to your original message and > not Pankaj's. Sylwester, could you clarify? OK, let's just use a common clk Kconfig symbol for Exynos ARM64. What I tried to say is that with addition of support for few more of those SoCs the kernel image size can easily grow by 1MB order, due to just clk drivers inclusion. Perhaps it's not a big issue with current hardware configuration. Maybe in long term we should think about splitting CMU drivers into a built-in critical clocks part and the rest in loadable modules. -- Thanks, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/