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 97131C4167D for ; Tue, 7 Nov 2023 03:53:05 +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:References:MIME-Version:Message-ID:Date :Subject:In-Reply-To:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FRrvadLIHeqBp9R+/DinqDqYhlDLkw1UGZlXXO1MRkA=; b=MmiPN5Ukwzdeof rm376G0xTGUR/5VT0+AMHTvZ/H2J5xgHVpbVZYWse6YK+Xo/PEtS0F9Wgb4za7TjU+tcCWyMVw0P2 p6FGHkZfj0nmTNWJkCbr5tzrpHVohpxu2K195ivrDwU0ULXWPqsF1AagF6qtZkFpS2JKWGC0ggD32 981+jISeJYiXgD7aJoP0nRjOt2WpArrdo9cpUFAPVbi6KvIWVsFLLk74tzWij+97Di7yjfr3Zzhg3 Jf6mHzxMAlgz02ML3KxG6Fyonul83AAxnSlm+bPoIKE9/VBRRxd7Z3PfNrBPrGhTJtY6uiPsqalvG 8oDLszd7H5p1jVUZmEPw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r0D8i-000Sfq-01; Tue, 07 Nov 2023 03:52:32 +0000 Received: from mailout1.samsung.com ([203.254.224.24]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r0D8b-000Se3-0w for linux-arm-kernel@lists.infradead.org; Tue, 07 Nov 2023 03:52:30 +0000 Received: from epcas5p2.samsung.com (unknown [182.195.41.40]) by mailout1.samsung.com (KnoxPortal) with ESMTP id 20231107035217epoutp0186d662c8ab6df70467b4f4386951dba6~VOtj2b0bk3049630496epoutp01h for ; Tue, 7 Nov 2023 03:52:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.samsung.com 20231107035217epoutp0186d662c8ab6df70467b4f4386951dba6~VOtj2b0bk3049630496epoutp01h DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1699329137; bh=UTH8SuUbQPHKLc2e7maM9wNCoInY5htpj08w74pBt8A=; h=From:To:Cc:In-Reply-To:Subject:Date:References:From; b=etq6PgIfqtofVU44MPEFtOqpaKla98QdAcfCDPSFWuJ/hqDuCRv7+c3Y1rMX0tM+7 K+SHraZkQ4TaOxNA60LgXCQ8Vxjhw2zZdxDwAIFyhh1rnC1fyhyGw6W0tcILBEGd2b b6iLxV/czlgA8gjhBX/Sr8LWApF/LRfD6YZSrxR4= Received: from epsnrtp1.localdomain (unknown [182.195.42.162]) by epcas5p2.samsung.com (KnoxPortal) with ESMTP id 20231107035216epcas5p25c0b3f5c127f275f16161f71b79ed596~VOti_xYpV1433214332epcas5p22; Tue, 7 Nov 2023 03:52:16 +0000 (GMT) Received: from epsmgec5p1new.samsung.com (unknown [182.195.38.178]) by epsnrtp1.localdomain (Postfix) with ESMTP id 4SPZ6R33MHz4x9Q0; Tue, 7 Nov 2023 03:52:15 +0000 (GMT) Received: from epcas5p1.samsung.com ( [182.195.41.39]) by epsmgec5p1new.samsung.com (Symantec Messaging Gateway) with SMTP id 7C.85.08567.F64B9456; Tue, 7 Nov 2023 12:52:15 +0900 (KST) Received: from epsmtrp2.samsung.com (unknown [182.195.40.14]) by epcas5p1.samsung.com (KnoxPortal) with ESMTPA id 20231107035214epcas5p1e7979487e7406460d43ae4ef44790472~VOtg2Yo-N0876708767epcas5p1r; Tue, 7 Nov 2023 03:52:14 +0000 (GMT) Received: from epsmgms1p2new.samsung.com (unknown [182.195.42.42]) by epsmtrp2.samsung.com (KnoxPortal) with ESMTP id 20231107035214epsmtrp2c910fad55ec81e7c26345a1e604e6d00~VOtg08-6h1894518945epsmtrp2J; Tue, 7 Nov 2023 03:52:14 +0000 (GMT) X-AuditID: b6c32a44-3abff70000002177-59-6549b46f2a19 Received: from epsmtip1.samsung.com ( [182.195.34.30]) by epsmgms1p2new.samsung.com (Symantec Messaging Gateway) with SMTP id 75.4A.08817.E64B9456; Tue, 7 Nov 2023 12:52:14 +0900 (KST) Received: from INBRO000447 (unknown [107.122.12.5]) by epsmtip1.samsung.com (KnoxPortal) with ESMTPA id 20231107035210epsmtip1e85a1b9b4be95fe1118b9995f2f8e9ff~VOtcyc2tN0178001780epsmtip1D; Tue, 7 Nov 2023 03:52:10 +0000 (GMT) From: "Alim Akhtar" To: "'Peter Griffin'" , "'Maksym Holovach'" Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , In-Reply-To: Subject: RE: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board Date: Tue, 7 Nov 2023 09:22:08 +0530 Message-ID: <02fa01da112d$cb404bc0$61c0e340$@samsung.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGPgbmEF6+ub3qtRjh359af8ajCkQMZWII3AhbeOfwCeEklngG7UdjkAXxQE1KwrFSicA== Content-Language: en-us X-Brightmail-Tracker: H4sIAAAAAAAAA02TfVDTdRzH77ffnuACfg3ML6sQp+VhgVuw+cVzwiXgr9MKj6y7SmGx322T sc09KJjdBgnxoKgcdbTDAOGGjCGPAYKA8pBJC3ziQZC4gFIgJgLSpWO28cPiv9f3832/P0/f +zJRVguDzZQptIRaIZJz6O7Uhs6ALYHK+vcI7q0+L1g/XUeFy7k/MeAj0ykEWlp7KXBw8QEN Fnb10mBTow/Mefg7CvPsZRRYOzFAg49P/UaDdYV2BOb3tVGgteQ0Aw5damPAyWIrBd75tosC b/VEwp7BBTqszndQYVprFwN2/vUNDWZ1LNOhY6CGCh/kOK0Tg3Y6NDc7M80PH4In7/Ohef45 AiemHGj4BryhpYGGW36wIPizp7kI/mgojYFfNo4y8KJaHV5rzqTj9weu0PFyi4WG15Xq8bs/ p9Lwmku9TtXfBgaeU29G8IVav2ivTxN2SgmRmFD7E4p4pVimkAg5e2Nid8fyBVxeIC8Ubuf4 K0SJhJATsS86MEomd66K439UJNc5Q9EijYazbddOtVKnJfylSo1WyCFUYrkqRBWkESVqdApJ kILQ7uBxue/wncK4BGlbZjVD5fgw6fbAEmpAqsOzEDcmwEJASVYK6mIW1oKA8ZEokucR0J0p yELcnbyEgAuWTOoLg/2MgUFetCKgbyaFQh4eOh1lNxkuFR0LBE0l6XQX+2AyUNhuRlyMYkV0 UDJJc7Ebth8sT1pWsnpjnwN7Vv5KnIptBrOmeysteWCh4PHcyCq/DG58P0kl87wFTMUzKNmR P/jnD5PTy3TW+hikl7uTkvVgqrtrpVGAOdxATWnGqj4CpOYbKSR7g+nr9QyS2WDB1kp35QEY Di7Y2WRYCmbLqhCSw8DVuwVUlwTFAkBV8zaylCc4/WySQjo9QEY6i1S/Ab629a+u7VVwLjub RjIO/ux7jp5FNhrXzGVcM5dxzQDG/4sVIVQz4kuoNIkSIp6v4imIY/89drwysRZZ+UVbI5qQ oUJHUAdCYSIdCGCiHB+P5TCcYHmIRcnHCbUyVq2TE5oOhO9c9jmUvS5e6fyGCm0sLySUGyIQ CEJCgwU8znqPmbTzYhYmEWmJBIJQEeoXPgrTjW2gtO3Ty+OKv+pM+ihYL33iUKYtVm0fu7nO Nvw6GP8iION4GGdLywHfigp+/+4TzGNcpm95YPhnnqn694VVZwWjbnptNrd4rD041+EtP+jn 6ItE36buztw1zP0lvZKpbmbdszVKl5PjqiOv73+3Iu+aRFeQcOOyISpcHPfJKzMNRwqmbqc8 MV2sAtf2vPRlUV7/6OCPKRueshbGXjt4wPPO4aDzZ2I8T0SFfzdt67ES3rrIIzkx0iYZ0a6X 8Lo5QovMbzZhrvToB3Np/Y2NldYdJ+mjSQtSgzVJX2ALMFUulS1u/tWycRyNO3wouZsdmXFV Wegl3LR3vNHqfiXM5yLrzZFNHKpGKuJtRdUa0b+dLcEazgQAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsWy7bCSnG7eFs9Ug/l7ZC22vNrMYvF30jF2 i/fLehgt1uw9x2Rx/ctzVov5R86xWuzYLmLR9+Ihs8WUP8uZLDY9vsZq8bHnHqvF5vl/GC1m nN/HZHFmcS+7xY11+9gtniw8w2RxeeoRJouLp1wtTl3/zGaxYcY/FovWvUfYLQ6/aWe16Dr0 l83i37WNLBbP+4BaH1//w2axahfQpE+34ixa7pharPr0n9Hi8ct/zA7yHtt2b2P1WDNvDaPH 71+TGD3e32hl99g56y67x4JNpR6bVnWyedy5tofNY+WaNawem5fUe1w50cTqsXHdOaCq7w3s Hn1bVjF6fN4kF8AfxWWTkpqTWZZapG+XwJVxfec9loI9/hXXFy5jbWA8Zt/FyMkhIWAi8ae/ gb2LkYtDSGA3o8Tc+UdYIBLSEtc3TmCHsIUlVv57DlX0jFHi4++LzCAJNgFdiR2L29hAbBGB TIlDDbfZQIqYBQ6xSTxeuY0VouMnk8StTX/AOjgFAiX+PlkDtkJYIEri3YWfYDaLgIrE22U3 wWp4BSwlPn64DWULSpyc+QSshllAW+Lpzadw9rKFr5khzlOQ+Pl0GdAyDqArwiTaVnJBlIhL vDx6hH0Co/AsJJNmIZk0C8mkWUhaFjCyrGKUTC0ozk3PLTYsMMpLLdcrTswtLs1L10vOz93E CE5MWlo7GPes+qB3iJGJg/EQowQHs5II7197j1Qh3pTEyqrUovz4otKc1OJDjNIcLErivN9e 96YICaQnlqRmp6YWpBbBZJk4OKUamC4F8YiZaf19MeOMQti+ngXiixKDv4TO29tbLig1tZHL SDNU15p3P/du3yMNImJ1qadnTarJy2HcrC7ioZVzk+fhKSeOvvzKOW1Tep+kzFnyrdrrQX3R o72i+enXGhhv3zvvv1/yzqSTk/s7WzY2nXd0crvBtv7l6qN11xmY+E9LHE8WyjD2WHdJuEd+ 8eVZ3zl95fYvbxFyS39ydBZbhoXLxcrHTs4l83VW3PgwTVbl3Cfj6r5ZC8U391a7+2q6y2Ss W8J25UktN7v7RfHF3v2VSalyAlE/00WEErusZv4v4ys0Yg7pTNn0Pu1qefPBzPrDClfLpG7K TT+8LTu5rclQ0Ed2Mpvb5r3sx4yUWIozEg21mIuKEwFXhNtmuwMAAA== X-CMS-MailID: 20231107035214epcas5p1e7979487e7406460d43ae4ef44790472 X-Msg-Generator: CA CMS-TYPE: 105P DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20231106124623epcas5p20f05ced9527800166c35e9c5a19f4479 References: <20231010224928.2296997-1-peter.griffin@linaro.org> <3d489d6c-2098-4f0c-9ec4-f6040665753e@lpnu.ua> <48e1c0bd-9518-4927-b490-f3206256bbd4@lpnu.ua> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231106_195227_378124_DA38083C X-CRM114-Status: GOOD ( 63.91 ) 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 Peter > -----Original Message----- > From: Peter Griffin > Sent: Monday, November 6, 2023 6:16 PM > To: Maksym Holovach > Cc: 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; > willmcvicker@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 > > Hi Maksym, > > On Fri, 3 Nov 2023 at 13: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. > > Also Exynos850 as I pointed out previously. I think that is the wrong approach > and very confusing. This SoC is not commonly known by anyone as > Exynos9845. > > The same as the Exynos850 isn't known by anyone apart from Samsung folks > as Exynos 3830, and the tesla fsd SoC isn't known by whatever internal > Samsung name that presumably had. > > Maybe Alim can comment what tesla fsd SoC has in the product id register. > FSD does not contain chip_id IP found in Exynos series of SoCs. And it does not follow chip ID naming convention like S5Exxxx etc. Chip ID is vendor specific and its depends on SoC owner/vendor how and what they want to embed for the chip identification. > > >> > > >> 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. > > Where does this 'almost 100%' number come from? Are you measuring the > die area here or something else? > > > > 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. > > You are correct. William clarified that point for us. Thanks William! > > > > > Also, what kind of Google IP are you talking about? I believe only the > > neural accelerator should be custom-ish. > > This should not be considered an exhaustive list, but whilst looking in the > downstream public drivers at least the following Google IPs in the SoC > > TPU/ML accelerator > Bigocean av1 video accelerator > Emerald hill compression engine > Camera ISP blocks > (AoC) Always on Compute > > Plus of course Arm IPs (CPU+GPU), Synopsis IPs (USB, PCI. phys) etc. > > The Exynos based IPs tend to be for things like pinmux, clocks, i2c, spi, uart, > mfc, display controller, timer etc. > > > > > 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. > > I think RPi / Broadcom is a very different situation to this. The original SoC in > RPi 1 was wholly designed by Broadcom, and marketed as a Broadcom SoC > [1]. > > Further iterations of the SoC until now have also not had RPi IP integrated. > RPi themselves refer to them as "Broadcom SoCs" on their webpage [2], so it > is completely expected that they live in a broadcom directory. > > BCM2717 has integrated the RPi ISP, but to all intents and purposes this is a > Broadcom owned and designed SoC, albeit only now sold to one customer. > > [1] https://protect2.fireeye.com/v1/url?k=da5b6ba0-bb20c137-da5ae0ef- > 74fe4860001d-7fce4d4e8d7e8af0&q=1&e=b917214e-9ab0-44fd-9dce- > aa4e41be3905&u=https%3A%2F%2Fweb.archive.org%2Fweb%2F2012021508 > 0023%2Fhttps%3A%2F%2Fwww.broadcom.com%2Fproducts%2FBCM2835 > [2] > https://www.raspberrypi.com/documentation/computers/processors.html > > > > > > > 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. > > It is going by its real name :) just not by its internal name that nobody has > heard of. > > > Ultimately, I believe all of those SoCs should go under their > > technical name in the exynos/ directory. > > > > 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 expect Google, or Google sponsored devs (as is the case for Linaro) to be > helping maintain the Google SoCs upstream. See the MAINTAINERS entry for > this series of who I expect to maintain this google directory. > > > > > 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. > > That is correct, it is named Zuma downstream and they did away with the > gs101, gs201 type naming scheme. > > > > > 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. > > As you can see from this series we are not proposing that. Any IPs that use > Exynos IP we are using the existing upstream driver and enhance it where > we have features that aren't present upstream. > > > > > 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. > > Who manufactures it seems irrelevant. Qcom and Broadcom don't > manufacture their SoCs either, but they still live in qcom and broadcom > directories upstream. Whether they designed the SoC from scratch or not is > also IMO largely irrelevant. In many cases the upstream community has no > way to determine whether things were outsourced or not anyway. > Did Apple outsource things in their silicon design? Who knows, and why do > we care? It's an apple branded chip in an apple branded product let's call the > directory apple. > > Interestingly apple uses the same uart driver as Tensor, when I check back > through the commits in the driver. > > fcbba344907afe26da487f1ed0b0e285c06a547b > > tty: serial: samsung_tty: Add support for Apple UARTs > > Apple SoCs are a distant descendant of Samsung designs and use yet > another variant of their UART style, with different interrupt handling. > > > > 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. > > Also the fact that they contain IPs not found in Samsung designed devices, > aren't known to most people as Exynos, and the maintenance issues of > having all the Google, Tesla, Axis, Exynos based SoCs in the same directory > (and who knows how many other ASIC customers in the future). > > Ultimately it is Krzysztof's decision I think. I followed what he had previously > accepted for other SoCs for consistency and also because it seemed like the > correct approach to help scale up and ease the maintenance burden. If I look > at the number of tensor based SoCs, phones per SoC and board variants per > phone model, then you end up having a lot of files in the exynos directory > over time. > > regards, > > Peter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel