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 D39E1C19F2D for ; Tue, 9 Aug 2022 18:27:57 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id D8AA783FB3; Tue, 9 Aug 2022 20:27:54 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1660069675; bh=FEj5Zo4k8lqV9I/ZpIRDJtGy1KDQ2FIPoXjZGJLwG54=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=S7qK3RuWnsdgLCd+t1bfsCFmFpi/ihpHo+DdFxR1WLodeuKsi+Jtd4YjhtMgibGzU 1cCmL4APoASg3F/gvJGhXHcIPKMzL0BWgSK/QZ9nM0xVgcn9a4e/LlWCxkPAcMcKtk I63Mqw3rzZK0qx8BqjMOFI/Rbi2hZElW9M/DFb0JDMRPBUL6N63IjYF2Y2W0yjm8Mj 3TZmwmpm5MVJTwDU9f5L/RrRLKLCsTE9wc57IaBpefoHmRWoaHVE27Bl4y6qYfE/fL mIMtN14BYQ1VlAt1ksgdsR2whkuNl6w9kTqjfu3dwBIO755bCDKwNKX9X+J+PL4MLS E5JovIxNPBMBA== Received: from [127.0.0.1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 2FF51849D7; Tue, 9 Aug 2022 20:27:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1660069672; bh=FEj5Zo4k8lqV9I/ZpIRDJtGy1KDQ2FIPoXjZGJLwG54=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=a3LgaE8wa60yccjLXgT+oV8e64AOaayyvHNJeSAbcUUyH2lB/fZj2KLjZj7ami1p5 e8F/Y2edOJHesqH/lje8X7e4GnhK6HM6Qlj5gpxdJcr5130UArWfizl1LbNAg+Y7Ib kUEs5ddKnMkiMr+jsdqL0/jacJugaxaVxuzu4iGGB+4GculBVcdrjXTBeozo1mj3XA YyxJuAWOYIay1d5eMx5Wt+detPnL2sahstNK1b4/wtgWFlb/2awIB9OJznySsc9hR3 XvA5kCSTqrxcOo8rhKS0ptnB5Zq6HzMuf35Wc4fVM2QYYnfhjQeA4c1OWoh0S/XgUr IN08bsW0ywlOg== Message-ID: Date: Tue, 9 Aug 2022 20:27:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH v3 1/3] Convert CONFIG_SYS_L2_PL310 to Kconfig Content-Language: en-US To: Tom Rini Cc: =?UTF-8?Q?Pali_Roh=c3=a1r?= , Philip Oberfichtner , u-boot@lists.denx.de, Christoph Niedermaier , Stefano Babic , Marcel Ziswiler , =?UTF-8?Q?Marek_Beh=c3=ban?= , Peng Fan , u-boot@dh-electronics.com References: <20220809100703.3101047-1-pro@denx.de> <20220809100703.3101047-2-pro@denx.de> <20220809105813.aa4vjcyiqm3mnqx4@pali> <41f76858-38d9-284b-1b54-b511f3b3cd67@denx.de> <20220809112151.jhrytuxraqcahzh5@pali> <4c124a1f-28cb-a805-ac6f-fd50ae2ee00e@denx.de> <20220809113224.4mvygsubvtb5wd7a@pali> <20220809134634.GV1146598@bill-the-cat> <7a2a67b7-78ba-d687-55c9-23b4fd1203f6@denx.de> <20220809163601.GZ1146598@bill-the-cat> From: Marek Vasut In-Reply-To: <20220809163601.GZ1146598@bill-the-cat> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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.6 at phobos.denx.de X-Virus-Status: Clean On 8/9/22 18:36, Tom Rini wrote: [...] >>> It's tricky to say when to "select" or just "default y if .." or "imply" >>> a given option. It's not only a matter of "can you disable X and the >>> system is functional" but "would you normally want to". There are >>> certainly system bring-up cases and similar where you want to disable >>> L2CC because you're tracking down something. But it's really a feature >>> of the chip and expected to work and something we want enabled, and the >>> scope of when it would be disabled is very very narrow. Looking back at >>> the patch itself, the config.h files that enabled this are almost all a >>> SoC-common file (ti_am335x_common.h should have been setting this I bet, >>> something else for the TODO pile for me), so my thought is that it >>> should be a select'd option, but if there's strong opinion that it's >>> useful to make it easy to turn off when needed, imply'd instead by the >>> various ARCH's in question instead. >>> >>> That said, thinking about the missing dependency I listed above, that's >>> how to disable L2 when needed, so perhaps select SYS_L2_PL310 if >>> !SYS_L2CACHE_OFF under the various ARCH's is the right way. >> >> Uh, I didn't realize we also had this SYS_L2CACHE_OFF . > > Yeah, and it's also one of the odd "Enable this to turn oFF ..." > options, but I think in this case, that makes the most sense. Note that > SYS_L2CACHE_OFF defaults to 'n' so do assume we have an L2 cache, and > also the option is ARM-specific. > >> In that case, the SYS_L2_PL310 selects the L2CC driver to be compiled in and >> that should likely be per-arch select indeed. And then SYS_L2CACHE_OFF >> should be 'default' or 'imply', so the user can configure it for the various >> hardware bring up cases ? > > Yeah, I think we're in agreement here. Yes