From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D1F5F35894 for ; Mon, 9 Oct 2023 16:10:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="mPGo3aaS" Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 319FA91 for ; Mon, 9 Oct 2023 09:10:07 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id d9443c01a7336-1c6193d6bb4so307165ad.0 for ; Mon, 09 Oct 2023 09:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696867806; x=1697472606; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=dGIYsu1MNfGtvrI3i3A4TgarZixnrBWwMgUCqpQdV34=; b=mPGo3aaSt2Zs/4XhDbpboFd1/W5DgA+MxWc8D6CG825AnGVgybo9Hb73eX/zHIxQ9y HAtgUnv3rlngt05B+RQl6NouHS0DUWWGHW3tN9qwOc9yEDPylMZ5wJD/TlHzy/2+lbeD 5MTW2odzn3ddG9+kqTHFz/dCR+5x32eFODjv0EEVWX6cjwxk7KB7smscVTeQcqFZRBIs kS+8FayOi27YymTXZSyM8FqAGvPlr/3E/C79eEH6XQWm4iWY71fEpZWt4UM7vGfZQ+Cu xC4xkYpN2AQKC7VXDFZm/23mOyNRTF4MhDol8ptOG3jdnTZ5l1W4he59GbMPqnz5kCb3 +0Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696867806; x=1697472606; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dGIYsu1MNfGtvrI3i3A4TgarZixnrBWwMgUCqpQdV34=; b=LcDqdPvlwnnWV7Ylyir3U3kvBgcamjV9V3yIVxeYm8apESHbPpV3PNI0IXW+qfS5UL L2Q5fWZl1DOcn2gGW6+Ph2YSjpw8+kk7gYi+Cw979Or6nBSTAzZ49zIREC3CUKAYL5zE EO3K69S2ycsnNtURYcPRGG9AA2XzZgLxaLk5ZSlrzZWwgaVwotza+eoBeKjW2sI1a8p7 3EATLAniITn9P2YJh3VhsWSrG/Oxjeoor3AP8PR4wll9zHjOwzrb8dkd1Lx4mJvIuSc3 xmSi+59ncyN31CS7c9FhvubDhYBUF5yhXrsRJSA4YnTjUHLb3G3G4odOU/9+yQbboNKa 8dyw== X-Gm-Message-State: AOJu0YwVVRr1RH5yYxJDSp2epwbK/kBbLU8pZPyus7D2DB7AoH3XoeeT V4jLYTpdtdiOYw4fQxSXRh3Ajg== X-Google-Smtp-Source: AGHT+IHy1UHB7+iKwEt/4HFm84LkAhlK5DfErxNNnYkX3w3H99+guWbxzofQ+qkXAw5azJ9m9sSRpw== X-Received: by 2002:a17:903:18c:b0:1c7:5627:2053 with SMTP id z12-20020a170903018c00b001c756272053mr721817plg.18.1696867806422; Mon, 09 Oct 2023 09:10:06 -0700 (PDT) Received: from google.com (13.65.82.34.bc.googleusercontent.com. [34.82.65.13]) by smtp.gmail.com with ESMTPSA id 17-20020a17090a001100b00274262bcf8dsm11287754pja.41.2023.10.09.09.10.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Oct 2023 09:10:05 -0700 (PDT) Date: Mon, 9 Oct 2023 09:10:02 -0700 From: William McVicker To: Krzysztof Kozlowski Cc: Arnd Bergmann , Greg Kroah-Hartman , Peter Griffin , Rob Herring , krzysztof.kozlowski+dt@linaro.org, Michael Turquette , Conor Dooley , Stephen Boyd , Tomasz Figa , Sylwester Nawrocki , Linus Walleij , Wim Van Sebroeck , Guenter Roeck , Catalin Marinas , Will Deacon , Olof Johansson , Chanwoo Choi , Tudor Ambarus , andre.draszik@linaro.org, semen.protsenko@linaro.org, soc@kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-clk@vger.kernel.org, "open list:GPIO SUBSYSTEM" , linux-watchdog@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH 18/21] arm64: dts: google: Add initial Google gs101 SoC support Message-ID: References: <2023100520-cleaver-sinless-fbae@gregkh> <99419159-cab0-4c79-a4a0-12229bfad3c0@linaro.org> <2023100513-mashing-scrubber-ea59@gregkh> <44816879-a3a7-4bd0-bb20-19a645107b4b@linaro.org> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-15.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,HK_RANDOM_ENVFROM,HK_RANDOM_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net On 10/07/2023, Krzysztof Kozlowski wrote: > On 06/10/2023 18:33, William McVicker wrote: > > On 10/06/2023, Arnd Bergmann wrote: > >> On Fri, Oct 6, 2023, at 08:06, Krzysztof Kozlowski wrote: > >>> On 06/10/2023 01:19, William McVicker wrote: > >>>> On 10/05/2023, Krzysztof Kozlowski wrote: > >>>>> On 05/10/2023 21:23, Greg KH wrote: > >>>> > >>>> Being able to include SERIAL_SAMSUNG and SERIAL_MSM without all the vendor> specific drivers that ARCH_EXYNOS and ARCH_QCOM select is very > >>> valuable for > >>>> debugging early boot issues. > >>> > >>> Really? How related? The drivers are independent. You describe some > >>> out-of-tree development process which we never needed for upstream work. > >>> And we did here quite a lot of upstream, specially if you look at ARCH_QCOM. > >> > >> Right: in general, all drivers are independent of the platform > >> besides the typical 'depends on ARCH_FOO || COMPILE_TEST' dependency, > >> but I think it's worth mentioning the known exceptions, so Greg and > >> Will can take that fight to the respective places rather than > >> discussing it in the platform submission: > >> > >> - Some subsystems are considered 'special' and the maintainers > >> prefer the drivers to be automatically selected based on the > >> ARCH_* settings instead of having user-visible options. This is > >> traditionally true for large chunks of drivers/irqchip, > >> drivers/clocksource and drivers/pinctrl, though it has gotten > >> better over time on all of them. > >> > >> - Some older 32-bit platforms are still not as modular as we'd > >> like them to be, especially the StrongARM (ARMv4) platforms that > >> require a custom kernel build, and some of ARMv4T and ARMv5 > >> boards that are still missing DT support. These tend to require > >> drivers they directly link to from board code, so disabling > >> the drivers would cause a link failure until this gets > >> cleaned up. > >> > >> - A couple of drivers are force-enabled based on the ARCH_* > >> options because booting without these drivers would risk > >> permanent damage to hardware, e.g. in overtemp or overcurrent > >> scenarios. > >> > >> - ACPI based platforms require the PCI host bridge driver to > >> be built-in rather than a loadable module because ACPI > >> needs to probe PCI devices during early boot. > >> > >> - Some subsystems (notably drivers/gpu/, but others as well) > >> have an excessive number of 'select' statements, so you > >> end up surprise-enabling a number of additional drivers > >> and subsystems by enabling certain less important platform > >> specific drivers. > >> > >> Arnd > > > > So if the argument is that the existing upstream Exynos platforms are required > > to have these drivers built-in to the kernel to boot: > > COMMON_CLK_SAMSUNG > > CLKSRC_EXYNOS_MCT > > EXYNOS_PM_DOMAINS if PM_GENERIC_DOMAINS > > EXYNOS_PMU > > PINCTRL > > PINCTRL_EXYNOS > > PM_GENERIC_DOMAINS if PM > > SOC_SAMSUNG > > > > ...then that is understandable and we can work to fix that. > > > > My last question then is -- why do we need a new ARCH_GOOGLE_TENSOR config in > > the platform Kconfig? For example, I don't really like this: > > > > diff --git a/drivers/clk/samsung/Kconfig b/drivers/clk/samsung/Kconfig > > index 76a494e95027..4c8f173c4dec 100644 > > --- a/drivers/clk/samsung/Kconfig > > +++ b/drivers/clk/samsung/Kconfig > > @@ -13,6 +13,7 @@ config COMMON_CLK_SAMSUNG > > select EXYNOS_5420_COMMON_CLK if ARM && SOC_EXYNOS5420 > > select EXYNOS_ARM64_COMMON_CLK if ARM64 && ARCH_EXYNOS > > select TESLA_FSD_COMMON_CLK if ARM64 && ARCH_TESLA_FSD > > + select GOOGLE_GS101_COMMON_CLK if ARM64 && ARCH_GOOGLE_TENSOR > > > > What happens when we have GOOGLE_GS101_COMMON_CLK, GOOGLE_GS201_COMMON_CLK, and > > so on? > > Nothing happens... or happens anything you wish. Did you read the > motivation why this was created like this? > > > > How are we going to pick the right driver when e have a generic > > ARCH_GOOGLE_TENSOR config? > Okay, we can figure that out the gs201 specifics when the time comes. > You do not have to pick. You select ARCH_GOOGLE_TENSOR and proper pick > is done by you. Nothing to do more. > > > Ideally, we should have one Exynos clock driver that > > can detect what hardware is running (using the DT) to determine what it needs > > It's already like this. We're done. > > > to do. If you really want to compile out the other vendor's clock drivers using > > some configs, then we should do that with SOC_GS101, SOC_GS201, SOC_TESLA_FSD > > Whether you call it SOC or ARCH it is the same. We organized it as ARCH. > > > configs (not ideal though). With that approach, we could drop the platform > > ARCH_GOOGLE_TENSOR config and create an SOC_GS101 config that can be used for > > things like the COMMON_CLK_SAMSUNG driver (for now) and building the GS101 dtb. > > There is no need for this. ARCH does exactly the same. Okay, sounds good. Thanks for the responses. Regards, Will > > Best regards, > Krzysztof >