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 88AF0C433EF for ; Wed, 23 Mar 2022 19:39:32 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 2E7EF83504; Wed, 23 Mar 2022 20:39:24 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="n8kWtsQu"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 079C4817D8; Wed, 23 Mar 2022 20:39:18 +0100 (CET) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 8CE7C83FAD for ; Wed, 23 Mar 2022 20:39:05 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-vs1-xe36.google.com with SMTP id i186so2608960vsc.9 for ; Wed, 23 Mar 2022 12:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=coEIaO1N+cWhpbk9B3B2EdU5eWnhUt9Cxm7+V5QeveY=; b=n8kWtsQutEvVOVVSBgFS9qFnRnZ56UzpV3flf+dw8Omz9LM+YuZwyrw3sj9IW5OQOR Lsw7JDuFzECOkpgx4cqU6O5O0fUmHAxx3mtRlFmTzeSFCIpfMkKbHU7pwdwd2DW/dNM/ OzN3q0tyYOAbs+I4aoICBwIFlFhxmXXJlZO9Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=coEIaO1N+cWhpbk9B3B2EdU5eWnhUt9Cxm7+V5QeveY=; b=8O3iqtk+/GTob8+fKykbtF8Ur37hVeizT27IBLJie50RFSKGLQkXg4XYGIjOCMe9c2 0FGU2/48yLCBCAIjWRXUsAyOeLuJrpniy2Uv4mlrIZfUH//HpWIayk2Ri3zo/5WnMBuu LLWY5UMf6S+U3WY5rw+Hl+1o1wIVhl5AD6lRE6CK6NF+/qNi4FT3DMGReEAFw1jAgcFx rwy0lNyxUJAVs3PHM55wC0bOP/DVD6T6afpZY9oaiICFXMVRgQAznnPEYnMZzL2z6jin uop2nOIDptiw8tK1GQQu57Ij5GDmyTv/zGwlkHInjErivNutuSm4Jl12HtSQq/4cc1s9 unUA== X-Gm-Message-State: AOAM533DPJn1GtNzlIbetgiCG0neZ6LXyLzdeFCXVPcLjFVeYUBKBNEN GH15pN5n/0AZMpZmcXwfhh+EM+Df/VWlsNyZqe0dAw== X-Google-Smtp-Source: ABdhPJwhicxfihUGNx+Ii2YzX+THIufyaM94pd1lSbSG7ClZvw1vTg7cdjm25i7BjPhSyADpxdB5P4Fvva0xc+e2kgg= X-Received: by 2002:a05:6102:21af:b0:325:d6:4a8a with SMTP id i15-20020a05610221af00b0032500d64a8amr1031380vsb.71.1648064344182; Wed, 23 Mar 2022 12:39:04 -0700 (PDT) MIME-Version: 1.0 References: <20220321142631.63704-1-heiko.thiery@gmail.com> <19e21ec5-184b-10d9-9bee-8ece6dc58095@gmail.com> <405fcc3e-0f78-a2d2-946b-3a6282f962df@gmail.com> In-Reply-To: <405fcc3e-0f78-a2d2-946b-3a6282f962df@gmail.com> From: Simon Glass Date: Wed, 23 Mar 2022 13:38:53 -0600 Message-ID: Subject: Re: [PATCH v2] board: kontron: increase the CONFIG_SYS_MALLOC_F_LEN To: Sean Anderson Cc: Heiko Thiery , Heinrich Schuchardt , Tom Rini , Stefano Babic , Fabio Estevam , Peng Fan , U-Boot Mailing List Content-Type: text/plain; charset="UTF-8" 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 Hi Sean, On Wed, 23 Mar 2022 at 13:19, Sean Anderson wrote: > > On 3/23/22 2:53 PM, Simon Glass wrote: > > Hi Sean, > > > > 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. > > > > 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. > > > > 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. This all makes sense. But updating 'struct udevice' would benefit every subsystem, particular arm64. The struct is just too damn big. Regards, Simon