All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Tom Rini <trini@konsulko.com>
Cc: "Pali Rohár" <pali@kernel.org>,
	"Philip Oberfichtner" <pro@denx.de>,
	u-boot@lists.denx.de,
	"Christoph Niedermaier" <cniedermaier@dh-electronics.com>,
	"Stefano Babic" <sbabic@denx.de>,
	"Marcel Ziswiler" <marcel.ziswiler@toradex.com>,
	"Marek Behún" <kabel@kernel.org>, "Peng Fan" <peng.fan@nxp.com>,
	u-boot@dh-electronics.com
Subject: Re: [PATCH v3 1/3] Convert CONFIG_SYS_L2_PL310 to Kconfig
Date: Tue, 9 Aug 2022 20:27:51 +0200	[thread overview]
Message-ID: <fff105ee-eca4-ba35-13a1-817ed1125552@denx.de> (raw)
In-Reply-To: <20220809163601.GZ1146598@bill-the-cat>

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

  reply	other threads:[~2022-08-09 18:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-09 10:06 [PATCH v3 0/3] ARM: imx6: dh-imx6: Enable d-cache early in SPL Philip Oberfichtner
2022-08-09 10:07 ` [PATCH v3 1/3] Convert CONFIG_SYS_L2_PL310 to Kconfig Philip Oberfichtner
2022-08-09 10:58   ` Pali Rohár
2022-08-09 11:16     ` Marek Vasut
2022-08-09 11:21       ` Pali Rohár
2022-08-09 11:27         ` Marek Vasut
2022-08-09 11:32           ` Pali Rohár
2022-08-09 11:38             ` Marek Vasut
2022-08-09 12:59               ` Pali Rohár
2022-08-09 13:16               ` Marek Behún
2022-08-09 13:18                 ` Marek Behún
2022-08-09 13:46             ` Tom Rini
2022-08-09 16:03               ` Marek Vasut
2022-08-09 16:36                 ` Tom Rini
2022-08-09 18:27                   ` Marek Vasut [this message]
2022-08-11 10:17                     ` Philip Oberfichtner
2022-08-16 14:42                       ` Philip Oberfichtner
2022-08-09 14:32         ` Phil Sutter
2022-08-12  8:39   ` Soeren Moch
2022-08-09 10:07 ` [PATCH v3 2/3] ARM: cache: Allow SPL to build cache-pl310.c Philip Oberfichtner
2022-08-09 10:07 ` [PATCH v3 3/3] ARM: imx6: dh-imx6: Enable d-cache early in SPL Philip Oberfichtner
2022-08-09 11:17   ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fff105ee-eca4-ba35-13a1-817ed1125552@denx.de \
    --to=marex@denx.de \
    --cc=cniedermaier@dh-electronics.com \
    --cc=kabel@kernel.org \
    --cc=marcel.ziswiler@toradex.com \
    --cc=pali@kernel.org \
    --cc=peng.fan@nxp.com \
    --cc=pro@denx.de \
    --cc=sbabic@denx.de \
    --cc=trini@konsulko.com \
    --cc=u-boot@dh-electronics.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.