Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755295AbdLTNOK (ORCPT ); Wed, 20 Dec 2017 08:14:10 -0500 Received: from mail-qt0-f193.google.com ([209.85.216.193]:38159 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755184AbdLTNOJ (ORCPT ); Wed, 20 Dec 2017 08:14:09 -0500 X-Google-Smtp-Source: ACJfBospaACNOiHdDsVFWBjkK+qOYGmOFuiWKHdNcZ9obV1Npy+f1LYBCr8YrfeyY/hXKuNwmU0CHbNubf/HBgEdJ5k= MIME-Version: 1.0 In-Reply-To: <1513774853.1538.15.camel@Nokia-N900> References: <20171116232239.16823-1-lukma@denx.de> <20171211233625.5689-1-lukma@denx.de> <1513153607.2439.2.camel@Nokia-N900> <20171213095257.5cf424fb@jawa> <1513774853.1538.15.camel@Nokia-N900> From: Arnd Bergmann Date: Wed, 20 Dec 2017 14:14:07 +0100 X-Google-Sender-Auth: 8wpFD1oABsPiIpQSaZzVmJS5VsE Message-ID: Subject: Re: [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board To: Alexander Sverdlin Cc: Linus Walleij , Lukasz Majewski , Hartley Sweeten , Russell King , Linux ARM , Linux Kernel Mailing List , Olof Johansson Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1508 Lines: 32 On Wed, Dec 20, 2017 at 2:00 PM, Alexander Sverdlin wrote: > Hi! > > On Wed Dec 20 13:50:28 2017 Arnd Bergmann wrote: >> I'm generally more interested in the multiplatform conversion than >> the DT conversion, and I think converting this one to multiplatform >> isn't actually that hard, and doesn't have a significant risk for >> regressions, the main work is to convert the clock handling. > > If it will be still possible to build the binary kernel of the same size after the > conversion, I'm in for testing, otherwise it will not fit into Flash any more... I think there is an increase in code size that comes mainly from the common clock layer itself, plus a few bytes here and there. Obviously the increase is much bigger if you actually enable multiple platforms. Here is the size of the uncompressed vmlinux file with the current clk implementation, compared to a build with a build containing the common clk code but no clock driver, and the separate clock implementation we have today: text data bss dec hex filename 4752655 1036028 128260 5916943 5a490f build/tmp/vmlinux-old-clk 4780174 1040524 128284 5948982 5ac636 build/tmp/vmlinux-common-clk 2491 1700 0 4191 105f build/tmp/arch/arm/mach-ep93xx/clock.o The difference would come to about 0.7% of the current image size, I guess around 1% when the other changes are included. Is that within the margins you have, or is this already critical? Arnd