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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EFECAC4332F for ; Fri, 3 Nov 2023 17:37:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=jDTbAJgJTOApKJGTebQzn010YdINhlTbzEaVP42+tuQ=; b=L0Ze1k5FtWm++n OVdBIVnTYsKrK9OZLDsE3GcwnII8EzXRXhBgtFFoZluuijExy9b4olYy1mkxSBm42AltHUFLAVafz v69s/WI2m9J1xgkp3Ts0EwIv21/Jk3rJNCvwtyDWDScskN7heoOfzpoZ85pe1+YVMz3K9v1ZURr0a js4/6H0xjikogfjSGMKflyYXLhZW8k+Bn1B8QTkLAdDzfz+2pkzJeK7ILFE99D15v5wsaQU3easPf 38xnV5yxNILvTs5hsdilrXcJ1ujIKQnvv66napEUCnMgUgfBhjHISTibJX0hJVN2/iVQnSn82bsHF nbBfQXmQ5HrDbTY2qAWQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qyy6E-00BtI2-2U; Fri, 03 Nov 2023 17:36:50 +0000 Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qyy69-00BtHe-1H for linux-arm-kernel@lists.infradead.org; Fri, 03 Nov 2023 17:36:49 +0000 Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-1cc209561c3so13185ad.0 for ; Fri, 03 Nov 2023 10:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699033003; x=1699637803; darn=lists.infradead.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=ljFKvtFUqqFsbXgmTSkchkcxGOyzN4hSb2DoRM1Sf0Y=; b=FD0vHBWybQvWZdrw6C5+/RTQpnppeh4fd9NeXOzk14ypliduX5BNVW3bC0fcWfhLod XctichTmjR6D+vYutCjH3Si3n8KiZ9kc0PxuoFhZOPWCE7Wa4EZwOS55YhMcGTkJS22L TVgChvYG2lG9Kj9NI43RAhkF8m4K8cv/CS8jpOI0SroM0G7wxqWOTYFI17cXG8WRO/3x hBuoVc4A2WJuKty4SKCwicLoAroC48IiGypz/rNggjdtUhz1ZUFIJuZXt4BSGuJfVnG0 AQkKgRbGign44F3I9/WbocwGer4Yztolqn+xkMcI+ThDn8+rZmyqFh0z+CY4Lws1jB+j niLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699033003; x=1699637803; 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=ljFKvtFUqqFsbXgmTSkchkcxGOyzN4hSb2DoRM1Sf0Y=; b=em58Q8IclevGJIfjKGBJfLVmdX1aQayC/x8XcdS8ui1AXwB8qafsna7rbtXQo/rtri aGNPuDzQ3KdEKuG5ikjlGLtGG9sMPPl6pmreeb9ZGdamA/prFRJ0fw2Y/+9/MZ3OCkAK WFopwonFD6KfKAjioRXp8dtWjqTArZe5meCO92rjJxknH1XD62VmG1QlqH+5ZGgZR705 e1PtodIZNOOl6Njg4/949pfl/7OHr8WTTl9Cvx+iyupzVxB1chr9GS9puvqAuSAgQHzt xLb0kOuk4qVfInm3Yn13nMZ39UwsWOAPb5zcfglJIS2P2ARnP4eIBLYj24UBX8RMXTfi K2Gg== X-Gm-Message-State: AOJu0Yy1G+S9unuCVBIiyYL8QUhplvkfS3NCUv/ScFaNaMXZxspA/C5+ PfFnYZFThR88ty/G04u09f2GVA== X-Google-Smtp-Source: AGHT+IHNZ7RrKpl3RUjqk7Qy3sQdAOqNm0LQBFDyIHRujlLtgghzH2cAyzRycaalNK3KDTTCVhOc8w== X-Received: by 2002:a17:902:7d89:b0:1b8:b564:b528 with SMTP id a9-20020a1709027d8900b001b8b564b528mr13284plm.7.1699033003056; Fri, 03 Nov 2023 10:36:43 -0700 (PDT) Received: from google.com (137.22.168.34.bc.googleusercontent.com. [34.168.22.137]) by smtp.gmail.com with ESMTPSA id q16-20020a17090311d000b001ca2484e87asm1622600plh.262.2023.11.03.10.36.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Nov 2023 10:36:42 -0700 (PDT) Date: Fri, 3 Nov 2023 10:36:39 -0700 From: William McVicker To: Krzysztof Kozlowski Cc: Maksym Holovach , Peter Griffin , robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, mturquette@baylibre.com, conor+dt@kernel.org, sboyd@kernel.org, tomasz.figa@gmail.com, s.nawrocki@samsung.com, linus.walleij@linaro.org, wim@linux-watchdog.org, linux@roeck-us.net, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, olof@lixom.net, cw00.choi@samsung.com, tudor.ambarus@linaro.org, andre.draszik@linaro.org, semen.protsenko@linaro.org, saravanak@google.com, soc@kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, linux-clk@vger.kernel.org, linux-gpio@vger.kernel.org, linux-watchdog@vger.kernel.org, kernel-team@android.com, linux-serial@vger.kernel.org, Alim Akhtar Subject: Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board Message-ID: References: <20231010224928.2296997-1-peter.griffin@linaro.org> <3d489d6c-2098-4f0c-9ec4-f6040665753e@lpnu.ua> <48e1c0bd-9518-4927-b490-f3206256bbd4@lpnu.ua> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231103_103645_472148_68B37459 X-CRM114-Status: GOOD ( 61.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Maksym, Krzysztof, Peter, On 11/03/2023, Krzysztof Kozlowski wrote: > On 03/11/2023 14:56, Maksym Holovach wrote: > > Hi Peter, > > > > On 11/3/23 15:11, Peter Griffin wrote: > >> Hi Maksym, > >> > >> Thanks for your feedback. > >> > >> On Thu, 2 Nov 2023 at 22:32, Maksym Holovach > >> wrote: > >>> Hi, all > >>> > >>> I wanted to inquire about how do you all feel about calling this SoC by > >>> the Google "gs101" name. > >> Interesting question, I think calling it gs101 is the correct approach see > >> below for my rationale. > >> > >>> I believe the proper name for it should be the actual Samsung name, > >>> written in the silicon and reported in the Chip ID hardware: Exynos9845. > >>> This also touches the Tensor G2 (Exynos9855), Tensor G3 (Exynos9865), > >>> and possibly the "Tesla" SoCs. > >>> > >>> I do not think the Linux kernel should be a marketing material: it > >>> should reflect reality. The chip is almost 100% composed of Samsung > >>> Exynos IP blocks and should be called that way. > >> As you alluded to Tesla fsd and Axis artpec8 SoCs are also based on > >> Exynos designs and support upstream uses the axis,artpec8* or tesla,fsd* > >> compatibles. > >> > >> So using google,gs101 is consistent with the existing upstream naming > >> scheme, for customized ASICs that were based off a Exynos design. But > >> it also reflects the reality that this SoC is not a Exynos9845 as there is > >> also a lot of Google owned and other third party IP integrated that is not > >> found in Exynos9845. > > > > A quick question: Do you imply Exynos9845 exists outside of the context > > of Tensor G1? I used to believe Exynos9845 **is** Tensor G1. Yes, the gs101 SoC is *not* equivalent to the Exynos9845. Similar to how Tesla FSD licenses Exynos IP blocks, gs101 does not only comprise of Exynos IP blocks. The final design is unique to Google and comprises of several different vendor IP blocks (not only Exynos). > > > > Also, what kind of Google IP are you talking about? I believe only the > > neural accelerator should be custom-ish. > > > > Additionally, I believe it having or not having Google IP is irrelevant: > > for example, the new Raspberry Pi 5 Broadcom SoC has a lot of > > Raspberry's own IP, but it's still called Broadcom as it's the real > > manufacturer and designer of the chip. > > That's a good argument. Indeed BCM2712 contains "New Raspberry > Pi-developed ISP". > https://www.raspberrypi.com/documentation/computers/processors.html > > There aren't many patches but GPU is still called brcm,2712. > > For Tesla FSD, there was discussion and output was not very consisting. > First, the name itself was used for everything - SoC architecture, one > given SoC and eventually the board. > https://lore.kernel.org/all/5ab62673-8d46-ec1d-1c80-696421ab69ca@canonical.com/ > > Eventually the last part - board - was renamed to "Evaluation board", > but I don't know how true or real it is. > > See also: > "I would argue that if this SoC shares the pinctrl, clock, spi, adc, > and timer implementation > with Exynos, we should consider it part of the Exynos family," > https://lore.kernel.org/all/CAK8P3a31bCHNcNWrLX+QW+4RuK=DBpxLA_j5BFKxXxXKCT8PFQ@mail.gmail.com/ > > However it was also claimed: > > "AFA architecture is concerns both Exynos and FSD has completely > different architecture (at least at HW level)." > https://lore.kernel.org/all/07ce01d8091e$9a6fd9c0$cf4f8d40$@samsung.com/ > > >> I guess the same is also true for `axis,artpec8` and `tesla,fsd` SoCs. > >> IMO the SoC compatible string should be uniquely identifying the actual > >> SoC, not a close relative. > >> > >> Regarding product_id you are correct this reads 0x09845000 but even > >> within Samsung Exynos family there are examples where the register > >> value does not match the SoC compatible. For example Exynos850 SoC > >> has a product ID value of "E3830". Where the Linux compatible is > >> matching the Samsung marketing name, not the internal/outdated name. > > > > I did not know Exynos 850 is also not going under it's real name. > > Ultimately, I believe all of those SoCs should go under their technical > > name in the exynos/ directory. > > The initial technical name does not exist outside of vendor sources and > part name. E.g. Winlink E850 board hardware manual calls it: > "Samsung Exynos 850, S5E3830" > and everywhere else Exynos 850 SoC is used. > > If you start calling it Exynos 3830, only me and Sam (who mainlined it) > would know what is it. Everyone else, all users of kernel, would be > confused. > > Therefore using well known final product name is for Exynos850 reasonable. I agree with this. By using the final (well known) product SoC name -- gs101 -- other developers will be able to easily identify the particular SoC. > > > > > Another concern is that Google could in the future license other SoC: be > > it Qualcomm, Nvidia or anything. If we put completely different hw under > > google/ directory, does it really make sense? In that case, who'll > > maintain the google/ directory? Exynos people? Qualcomm people if they > > license it? Some other people? I don't understand why the architecture of the SoC would dictate which folder to put the device tree files under. It makes more sense to group board DT files together based on who distributes them. Having all the Pixel DT board files together allows Google to create a single device tree binary per SoC coupled with the set of device tree overlays per board variant (this is the dtbo.img) to ship to all their devices. If you look at all the in-market Pixel devices with Tensor SoCs, you will find that you could create one dtb (concatenate gs101.dtb, gs201.dtb, and zuma.dtb) and one dtbo image for 10 devices which significantly simplifies the maintenance, testing, and software distribution for all 10 of those products. > > That's indeed a problem. Future Tesla SoC might have just few pieces > similar to FSD. There would be no common SoC part, except the actual > Tesla IP. > > Same for Google. Future GSXXX, if done by Qualcomm, will be absolutely > different than GS101 and the only common part would be the TPU (Tensor). > > So now let's decide what is the common denominator: > 1. Core SoC architecture, like buses, pinctrl, clocks, timers, serial, > and many IP blocks, which constitute 95% of Devicetree bindings and drivers, > 2. The one, big piece made by Samsung's customer: TPU, NPU or whatever. As mentioned above, I think this should be based on how the DTBs and DTBOs are used and distributed. What is the benefit of adding the gs101 board files under the exynos folder? Thanks, Will > > > > > Then, I don't think Tensor G3 has a proper "GS" name, it goes by "Zuma" > > in decompiled kernel modules as far as I see. > > > > Finally, Tesla people already tried to submit drivers called by Tesla > > name, but which basically copied the functionality of the Exynos > > drivers. We would want to avoid that, ideally. > > > > My opinion is that all the Tesla and Google SoCs should be in the > > exynos/ directory, not only because they are basically Samsung Exynos, > > but also because they don't really need a separate directory: neither > > Google nor Tesla didn't neither manufacture or design those SoCs from > > scratch. The only reason I can think of for them to have it in a > > separate directory is maybe because Google and Tesla actually paid > > Samsung money for the right to call Exynos "Google designed" SoCs, but I > > believe the kernel should be left out of that. > > For some reason, although I know which, Cc-list is here trimmed and > misses Alim... > > So standard reply follow (it makes me really, really grumpy, because it > means you develop on some crazy old kernel or do not use tools which > automate the process): > > Please use scripts/get_maintainers.pl to get a list of necessary people > and lists to CC (and consider --no-git-fallback argument). It might > happen, that command when run on an older kernel, gives you outdated > entries. Therefore please be sure you base your patches on recent Linux > kernel. > > Best regards, > Krzysztof > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel