From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0320FC433F5 for ; Wed, 23 Mar 2022 19:19:40 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 946C983FAA; Wed, 23 Mar 2022 20:19:38 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="qfhYZMXG"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7BCAB83FAA; Wed, 23 Mar 2022 20:19:36 +0100 (CET) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 8B0DB83FAA for ; Wed, 23 Mar 2022 20:19:32 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=seanga2@gmail.com Received: by mail-qk1-x733.google.com with SMTP id w141so1621837qkb.6 for ; Wed, 23 Mar 2022 12:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9bXxCvo8wcSySWcJT3BsVH3BC1uRFYZ49Gp9OmrXReE=; b=qfhYZMXG3EqZflA5mEQybdMq0Dr5a23VHOJZvgWglnbJBI4P6EtjYcKwceA2wa97Wd kW9cNRrkK9hTkSERi6Km3029ub4n5hVi4BnzDIon/kYCp1ohElZZfPbw+6+N+wjiiOgk gvNVSpKcuKFGBynJla9eTb38jV3QAiKlpc/H0uR09uwI8uYbEZjZ7bns5/Q0Td+JRT7G D4QUx/btaWi3XQL3FcTjTqMtd39UIDnSme5KLOBPeH0yh4Y68YCBucbCvTJ3G+m90yzQ IFdu3eFivD7ihebt2IN/M2qiU1NqKK3cQIewsbcm84+GzbEe7ZmFOw7BgrSVP/PjzGIa o5Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9bXxCvo8wcSySWcJT3BsVH3BC1uRFYZ49Gp9OmrXReE=; b=ncSbygkEbk7HCJuFhjsE7TUFSvnkBXxehXgM9PjX/whS9UNO59wXEW0NdLbeJPhB3d Eh0Z37B4vtVqRxXZhygTVuGfcNVYVSTWqv61fFPE6juxvxINEI5gKk+vtEO5IjQBGfwv OIcYUfDpAFVwRES1KsDajo5hoX3BOG0ztpVL+JkhiHsXeuoTReVv4eLNhvMoVsdh4vHp trWNtUgoLMJIKZzo/+LkMBC3ih4HP2Fe2QwuHT/TBWjF3QzUc4ab8az9NmF+pVe4wesu pSt9tjmqeEb4pSuIVM9oun55fjOii4eEeB9bXaZrZyO0uMANi8lCWSmsF3vF686c1Z1C dhog== X-Gm-Message-State: AOAM5318+7h0pMMTcX2BBk62zBGUhLUBEadDFLqaoAlCKPx5fHI3Bt0Y c7j/UamsoemA4m6wQ3uEtWxYGwq5x60= X-Google-Smtp-Source: ABdhPJx2F5Qk2bjDvkWFY3XzT3oSk9SsodMJ809LIWFm2qDlMkkPw9qjF9S0UvNlAr5XrTLtT3w2xA== X-Received: by 2002:a05:620a:892:b0:67e:60a9:83c2 with SMTP id b18-20020a05620a089200b0067e60a983c2mr1021434qka.670.1648063170958; Wed, 23 Mar 2022 12:19:30 -0700 (PDT) Received: from [192.168.1.201] (pool-108-18-137-133.washdc.fios.verizon.net. [108.18.137.133]) by smtp.googlemail.com with ESMTPSA id k1-20020ac85fc1000000b002e1c6420790sm725317qta.40.2022.03.23.12.19.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 23 Mar 2022 12:19:30 -0700 (PDT) Subject: Re: [PATCH v2] board: kontron: increase the CONFIG_SYS_MALLOC_F_LEN To: Simon Glass Cc: Heiko Thiery , Heinrich Schuchardt , Tom Rini , Stefano Babic , Fabio Estevam , Peng Fan , U-Boot Mailing List References: <20220321142631.63704-1-heiko.thiery@gmail.com> <19e21ec5-184b-10d9-9bee-8ece6dc58095@gmail.com> From: Sean Anderson Message-ID: <405fcc3e-0f78-a2d2-946b-3a6282f962df@gmail.com> Date: Wed, 23 Mar 2022 15:19:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean On 3/23/22 2:53 PM, Simon Glass wrote: > Hi Sean, >=20 > On Wed, 23 Mar 2022 at 12:33, Sean Anderson wrote: >> >> On 3/23/22 2:26 PM, Heiko Thiery wrote: >>> Hi Simon, >>> >>> Am Mi., 23. M=C3=A4rz 2022 um 19:04 Uhr schrieb Simon Glass : >>>> >>>> Hi Heinrich, >>>> >>>> On Tue, 22 Mar 2022 at 03:25, Heinrich Schuchardt wrote: >>>>> >>>>> On 3/21/22 15:26, Heiko Thiery wrote: >>>>>> It was observed that enabling additional DM modules the configured= >>>>>> malloc value is not sufficient. So lets increase the value. >>>>>> >>>>>> Signed-off-by: Heiko Thiery >>>>>> --- >>>>>> v2: >>>>>> - add a more proper commit message to explan why the value was= increased >>>>>> >>>>>> configs/kontron_pitx_imx8m_defconfig | 1 + >>>>>> 1 file changed, 1 insertion(+) >>>>>> >>>>>> diff --git a/configs/kontron_pitx_imx8m_defconfig b/configs/kontro= n_pitx_imx8m_defconfig >>>>>> index 76430213e3..30c3586937 100644 >>>>>> --- a/configs/kontron_pitx_imx8m_defconfig >>>>>> +++ b/configs/kontron_pitx_imx8m_defconfig >>>>>> @@ -2,6 +2,7 @@ CONFIG_ARM=3Dy >>>>>> CONFIG_ARCH_IMX8M=3Dy >>>>>> CONFIG_SYS_TEXT_BASE=3D0x40200000 >>>>>> CONFIG_SYS_MALLOC_LEN=3D0x600000 >>>>>> +CONFIG_SYS_MALLOC_F_LEN=3D0x10000 >>>>> >>>>> @Heiko >>>>> Should we really adjust this on board level? Won't we have the same= >>>>> problem on all imx8m boards? >>>>> >>>>> Why don't you change the default for all i.mx8 boards in /Kconfig? >>>>> >>>>> @Tom, @Simon >>>>> Shouldn't we replace the default of 0x400 by 0x2000 generally? >>>> >>>> I don't think that is a good idea. That is a lot of memory! Many >>>> platforms don't need that much. >>>> >>>> I wonder what is driving this large amount. Is it pinctrl? >>> >>> The increase comes from the introduction of a clock driver for the >>> imx8mq platform. >> >> Yes, the problem is that CCF creates a udevice+clk+private data for >> every clock. This runs about 150-200 bytes per clock on a 64-bit >> platform. In addition, many physical clocks are modeled as several >> logical clocks plus a composite. This means a platform with maybe >> 20-30 physical clocks can easily allocate 10k-20k to create >> the clock tree. >=20 > With the new DM tag support we could move uncommon fields in struct > udevice to tags, such as parent_plat_, uclass_plat_, driver_data, > uclass_priv_, parent_priv_, dma_offset. It would add a small amount of > code but save data. We could call this DM_TINY_DATA and It might save > 64 bytes per device. >=20 > Also the #ifdef CONFIG_DEVRES should use CONFIG_IS_ENABLED(DEVRES) so > that devres_head is not included in SPL. Personally, I think we could get away with a much smaller amount of data per-clock, and not make every clock a separate device. The primary reason= each CCF clock gets its own device is that we cache things like clock rates. Because of this, we need to keep track of children so we can invalidate their rates correctly. But caching rates is probably not that much faster than just recalculating (especially since most of the time it's just a division). We also don't try and find the best way to achieve= a clock speed like Linux does. If we don't cache clock rates, we don't need to keep track of a clock's children. Further, we could likely also eliminate tracking enable/disable counts. We don't have fine-grained low power states like Linux does, so generally= when someone disables a clock we're getting in the way by trying to keep track of the count. This is all a rather big change, so we're stuck with the status quo for now, but it's the direction I would like to move in going ahead. I know Marek would rather just not create as many clocks in SPL/pre-reloc. --Sean