From: Peter Griffin <peter.griffin@linaro.org>
To: Maksym Holovach <maksym.holovach.an.2022@lpnu.ua>
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 <alim.akhtar@samsung.com>
Subject: Re: [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board
Date: Mon, 6 Nov 2023 12:46:08 +0000 [thread overview]
Message-ID: <CADrjBPqB5MOQeMV6uSJHLVyMJYWm7Nm_1XGSq331gPRfO1jkzg@mail.gmail.com> (raw)
In-Reply-To: <48e1c0bd-9518-4927-b490-f3206256bbd4@lpnu.ua>
Hi Maksym,
On Fri, 3 Nov 2023 at 13:56, Maksym Holovach
<maksym.holovach.an.2022@lpnu.ua> 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
> > <maksym.holovach.an.2022@lpnu.ua> 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.
> >>
> >> 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://web.archive.org/web/20120215080023/https://www.broadcom.com/products/BCM2835
[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
next prev parent reply other threads:[~2023-11-06 12:46 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 22:49 [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board Peter Griffin
2023-10-10 22:49 ` [PATCH v2 01/20] dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible Peter Griffin
2023-10-10 22:49 ` [PATCH v2 02/20] dt-bindings: clock: Add Google gs101 clock management unit bindings Peter Griffin
2023-10-10 22:49 ` [PATCH v2 03/20] dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG compatibles to GS101 Peter Griffin
2023-10-10 22:49 ` [PATCH v2 04/20] dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings Peter Griffin
2023-10-10 22:49 ` [PATCH v2 05/20] dt-bindings: arm: google: Add bindings for Google ARM platforms Peter Griffin
2023-10-10 22:49 ` [PATCH v2 06/20] dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible Peter Griffin
2023-10-10 22:49 ` [PATCH v2 07/20] dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible Peter Griffin
2023-10-11 23:12 ` Sam Protsenko
2023-10-12 11:24 ` Peter Griffin
2023-10-10 22:49 ` [PATCH v2 08/20] dt-bindings: serial: samsung: Add google-gs101-uart compatible Peter Griffin
[not found] ` <2023101111-banknote-satin-1f77@gregkh>
2023-10-11 8:49 ` Tudor Ambarus
[not found] ` <2023101137-fester-rerun-5c39@gregkh>
2023-10-11 9:30 ` Arnd Bergmann
[not found] ` <2023101126-stash-manor-7162@gregkh>
2023-10-11 10:19 ` Arnd Bergmann
2023-10-11 11:55 ` Peter Griffin
2023-10-11 12:07 ` Krzysztof Kozlowski
2023-10-11 9:22 ` Peter Griffin
2023-10-11 11:58 ` Linus Walleij
2023-10-11 12:09 ` Krzysztof Kozlowski
2023-10-11 13:27 ` Peter Griffin
2023-10-11 13:32 ` Krzysztof Kozlowski
2023-10-10 22:49 ` [PATCH v2 09/20] clk: samsung: clk-pll: Add support for pll_{0516,0517,518} Peter Griffin
2023-10-10 22:49 ` [PATCH v2 10/20] clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates Peter Griffin
2023-10-10 22:49 ` [PATCH v2 11/20] clk: samsung: clk-gs101: add CMU_APM support Peter Griffin
2023-10-10 22:49 ` [PATCH v2 12/20] clk: samsung: clk-gs101: Add support for CMU_MISC clock unit Peter Griffin
2023-10-10 22:49 ` [PATCH v2 13/20] pinctrl: samsung: Add filter selection support for alive banks Peter Griffin
2023-10-10 22:49 ` [PATCH v2 14/20] pinctrl: samsung: Add gs101 SoC pinctrl configuration Peter Griffin
2023-10-10 22:49 ` [PATCH v2 15/20] watchdog: s3c2410_wdt: Add support for Google tensor SoCs Peter Griffin
2023-10-10 23:56 ` Guenter Roeck
2023-10-11 14:43 ` Peter Griffin
2023-10-10 22:49 ` [PATCH v2 16/20] tty: serial: samsung: Add gs101 compatible and SoC data Peter Griffin
[not found] ` <2023101109-crispy-escapable-0801@gregkh>
2023-10-11 18:03 ` Peter Griffin
2023-10-10 22:49 ` [PATCH v2 17/20] arm64: dts: google: Add initial Google gs101 SoC support Peter Griffin
2023-10-10 22:49 ` [PATCH v2 18/20] arm64: dts: google: Add initial Oriole/pixel 6 board support Peter Griffin
2023-10-10 22:49 ` [PATCH v2 19/20] arm64: defconfig: Enable Google Tensor SoC Peter Griffin
2023-10-10 22:49 ` [PATCH v2 20/20] MAINTAINERS: add entry for " Peter Griffin
2023-10-11 6:10 ` [PATCH v2 00/20] Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board Tudor Ambarus
2023-10-11 8:16 ` Peter Griffin
2023-10-11 8:42 ` Tudor Ambarus
2023-10-11 14:16 ` Peter Griffin
2023-10-11 7:44 ` Greg KH
2023-10-11 9:06 ` Peter Griffin
2023-10-11 9:11 ` Greg KH
2023-10-11 12:11 ` Krzysztof Kozlowski
2023-10-11 12:10 ` Krzysztof Kozlowski
2023-11-02 22:32 ` Maksym Holovach
2023-11-03 13:11 ` Peter Griffin
2023-11-03 13:56 ` Maksym Holovach
2023-11-03 14:49 ` Krzysztof Kozlowski
2023-11-03 17:36 ` William McVicker
2023-11-03 20:05 ` William McVicker
2023-11-03 23:05 ` Maksym Holovach
2023-11-03 23:23 ` Maksym Holovach
2023-11-06 20:12 ` William McVicker
2023-11-05 12:52 ` Krzysztof Kozlowski
[not found] ` <2023110535-rare-underdone-b508@gregkh>
2023-11-05 13:14 ` Krzysztof Kozlowski
2023-11-04 17:55 ` Alim Akhtar
2023-11-06 13:36 ` Peter Griffin
2023-11-06 15:10 ` Henrik Grimler
2023-11-06 12:46 ` Peter Griffin [this message]
2023-11-06 13:46 ` Krzysztof Kozlowski
2023-11-06 19:42 ` William McVicker
2023-11-07 3:52 ` Alim Akhtar
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=CADrjBPqB5MOQeMV6uSJHLVyMJYWm7Nm_1XGSq331gPRfO1jkzg@mail.gmail.com \
--to=peter.griffin@linaro.org \
--cc=alim.akhtar@samsung.com \
--cc=andre.draszik@linaro.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=conor+dt@kernel.org \
--cc=cw00.choi@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=kernel-team@android.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=maksym.holovach.an.2022@lpnu.ua \
--cc=mturquette@baylibre.com \
--cc=olof@lixom.net \
--cc=robh+dt@kernel.org \
--cc=s.nawrocki@samsung.com \
--cc=saravanak@google.com \
--cc=sboyd@kernel.org \
--cc=semen.protsenko@linaro.org \
--cc=soc@kernel.org \
--cc=tomasz.figa@gmail.com \
--cc=tudor.ambarus@linaro.org \
--cc=will@kernel.org \
--cc=willmcvicker@google.com \
--cc=wim@linux-watchdog.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).