| Message ID | 20231010224928.2296997-1-peter.griffin@linaro.org |
|---|---|
| Headers | show |
| Series | Add minimal Tensor/GS101 SoC support and Oriole/Pixel6 board | expand |
Hi, Peter, On 10/10/23 23:49, Peter Griffin wrote: > Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl > compatible` I tried to narrow the interrupts check to > google,gs101-pinctrl but I still see a warning: gs101-oriole.dtb: > pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long If anyone can > educate me on what I've done wrong here it would be most appreciated! I guess the initial definition of the number of interrupts should include the largest min/maxItems. I no longer see the warning with this change: diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml index 2464bc43aacb..6dc648490668 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml @@ -59,7 +59,8 @@ properties: interrupts: description: Required for GPIO banks supporting external GPIO interrupts. - maxItems: 1 + minItems: 1 + maxItems: 50 power-domains: maxItems: 1
On Tue, Oct 10, 2023 at 11:49:08PM +0100, Peter Griffin wrote: > Hi folks, > > Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all > the review feedback received so far. > > This series adds initial SoC support for the GS101 SoC and also initial board > support for Pixel 6 phone (Oriole). > > The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro > (raven) phones. Currently DT is added for the gs101 SoC and Oriole. > As you can see from the patches the SoC is based on a Samsung Exynos SoC, > and therefore lots of the low level Exynos drivers can be re-used. > > The support added in this series consists of: > * cpus > * pinctrl > * some CCF implementation > * watchdog > * uart > * gpio So you have sent a patch series that crosses multiple subsystems, who is supposed to be taking these patches? Or do you not want them actually merged? confused, greg k-h
Hi Tudor, Thanks for your reply. On Wed, 11 Oct 2023 at 07:10, Tudor Ambarus <tudor.ambarus@linaro.org> wrote: > > Hi, Peter, > > On 10/10/23 23:49, Peter Griffin wrote: > > Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl > > compatible` I tried to narrow the interrupts check to > > google,gs101-pinctrl but I still see a warning: gs101-oriole.dtb: > > pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long If anyone can > > educate me on what I've done wrong here it would be most appreciated! > > I guess the initial definition of the number of interrupts should > include the largest min/maxItems. I no longer see the warning with this > change: Yes that is how it was in v1. The review feedback though was to narrow the scope to just google,gs101-pinctrl compatible using if: then: else: which is what I can't get to work properly. regards, Peter. > > diff --git > a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml > b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml > index 2464bc43aacb..6dc648490668 100644 > --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml > +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml > @@ -59,7 +59,8 @@ properties: > interrupts: > description: > Required for GPIO banks supporting external GPIO interrupts. > - maxItems: 1 > + minItems: 1 > + maxItems: 50 > > power-domains: > maxItems: 1
On 10/11/23 09:16, Peter Griffin wrote: > Hi Tudor, > > Thanks for your reply. > > On Wed, 11 Oct 2023 at 07:10, Tudor Ambarus <tudor.ambarus@linaro.org> wrote: >> >> Hi, Peter, >> >> On 10/10/23 23:49, Peter Griffin wrote: >>> Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl >>> compatible` I tried to narrow the interrupts check to >>> google,gs101-pinctrl but I still see a warning: gs101-oriole.dtb: >>> pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long If anyone can >>> educate me on what I've done wrong here it would be most appreciated! >> >> I guess the initial definition of the number of interrupts should >> include the largest min/maxItems. I no longer see the warning with this >> change: > > Yes that is how it was in v1. The review feedback though was to narrow > the scope to just google,gs101-pinctrl compatible using if: then: else: which > is what I can't get to work properly. > Right. The diff that I sent is on top of your changes (patch 6/20). I expect that when the interrupts property is defined it should include the min/maxItems of all the available SoCs. Then use "if Soc" to narrow the range.
Hi, Greg, On 10/11/23 08:48, Greg KH wrote: > On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote: >> Add dedicated google-gs101-uart compatible to the dt-schema for >> representing uart of the Google Tensor gs101 SoC. >> >> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> >> --- >> Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml >> index 8bd88d5cbb11..72471ebe5734 100644 >> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml >> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml >> @@ -19,11 +19,13 @@ properties: >> compatible: >> oneOf: >> - items: >> + - const: google,gs101-uart >> - const: samsung,exynosautov9-uart >> - const: samsung,exynos850-uart >> - enum: >> - apple,s5l-uart >> - axis,artpec8-uart >> + - google,gs101-uart > > These shouldn't be needed, just declare the device as the same as what We should have SoC specific compatibles so that any further quirks or incompatibilities can be easily addressed. It's not only the IP itself that can differ, it's also the integration of the IP into the final product that could have an influence on the behavior. Cheers, ta > the chip really is (i.e. a samsung uart), that way no .yaml or kernel > driver changes are needed at all. >
Hi Greg, Thanks for your reply! On Wed, 11 Oct 2023 at 08:44, Greg KH <greg@kroah.com> wrote: > > On Tue, Oct 10, 2023 at 11:49:08PM +0100, Peter Griffin wrote: > > Hi folks, > > > > Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all > > the review feedback received so far. > > > > This series adds initial SoC support for the GS101 SoC and also initial board > > support for Pixel 6 phone (Oriole). > > > > The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro > > (raven) phones. Currently DT is added for the gs101 SoC and Oriole. > > As you can see from the patches the SoC is based on a Samsung Exynos SoC, > > and therefore lots of the low level Exynos drivers can be re-used. > > > > The support added in this series consists of: > > * cpus > > * pinctrl > > * some CCF implementation > > * watchdog > > * uart > > * gpio > > So you have sent a patch series that crosses multiple subsystems, who is > supposed to be taking these patches? Or do you not want them actually > merged? Krzysztof indicated here: https://lore.kernel.org/all/b1598405-b01f-426a-aaba-89f2d2dc9c2e@linaro.org/ that he would like to be the one applying the entire series through the Samsung SoC tree. If that's fine with everyone (it's OK with me). kind regards, Peter.
On Wed, Oct 11, 2023 at 10:06:18AM +0100, Peter Griffin wrote: > Hi Greg, > > Thanks for your reply! > > On Wed, 11 Oct 2023 at 08:44, Greg KH <greg@kroah.com> wrote: > > > > On Tue, Oct 10, 2023 at 11:49:08PM +0100, Peter Griffin wrote: > > > Hi folks, > > > > > > Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all > > > the review feedback received so far. > > > > > > This series adds initial SoC support for the GS101 SoC and also initial board > > > support for Pixel 6 phone (Oriole). > > > > > > The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro > > > (raven) phones. Currently DT is added for the gs101 SoC and Oriole. > > > As you can see from the patches the SoC is based on a Samsung Exynos SoC, > > > and therefore lots of the low level Exynos drivers can be re-used. > > > > > > The support added in this series consists of: > > > * cpus > > > * pinctrl > > > * some CCF implementation > > > * watchdog > > > * uart > > > * gpio > > > > So you have sent a patch series that crosses multiple subsystems, who is > > supposed to be taking these patches? Or do you not want them actually > > merged? > > Krzysztof indicated here: > https://lore.kernel.org/all/b1598405-b01f-426a-aaba-89f2d2dc9c2e@linaro.org/ > that he would like to be the one applying the entire series through the Samsung > SoC tree. If that's fine with everyone (it's OK with me). As the serial changes are not ok (see my comments on them), I don't think they should be going through any tree at this point in time :) Also, in your 00/XX email, say what tree you expect them to go through so we have a chance to know that please. thanks, greg k-h
Hi Greg, Thanks for your review feedback! On Wed, 11 Oct 2023 at 08:48, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote: > > Add dedicated google-gs101-uart compatible to the dt-schema for > > representing uart of the Google Tensor gs101 SoC. > > > > Signed-off-by: Peter Griffin <peter.griffin@linaro.org> > > --- > > Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml > > index 8bd88d5cbb11..72471ebe5734 100644 > > --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml > > +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml > > @@ -19,11 +19,13 @@ properties: > > compatible: > > oneOf: > > - items: > > + - const: google,gs101-uart > > - const: samsung,exynosautov9-uart > > - const: samsung,exynos850-uart > > - enum: > > - apple,s5l-uart > > - axis,artpec8-uart > > + - google,gs101-uart > > These shouldn't be needed, just declare the device as the same as what > the chip really is (i.e. a samsung uart), that way no .yaml or kernel > driver changes are needed at all. What you describe is actually how I had it in the v1 submission, which is also similar to what exynosautov9.dtsi is doing by re-using the "samsung,exynos850-uart" compatible, and associated data in the driver. However the review feedback in v1 from Krzysztof and Tudor was to add a dedicated compatible for it. I guess I could have re-used the existing EXYNOS850_SERIAL_DRV_DATA structure though rather than duplicating that as well. I'll let Krzysztof comment on why a dedicated compatible is required. regards, Peter
On Wed, Oct 11, 2023, at 10:57, Greg KH wrote: > On Wed, Oct 11, 2023 at 09:49:07AM +0100, Tudor Ambarus wrote: >> On 10/11/23 08:48, Greg KH wrote: >> > On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote: >> >> Add dedicated google-gs101-uart compatible to the dt-schema for >> >> representing uart of the Google Tensor gs101 SoC. >> >> >> >> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> >> >> --- >> >> Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++ >> >> 1 file changed, 2 insertions(+) >> >> >> >> oneOf: >> >> - items: >> >> + - const: google,gs101-uart >> >> - const: samsung,exynosautov9-uart >> >> - const: samsung,exynos850-uart >> >> - enum: >> >> - apple,s5l-uart >> >> - axis,artpec8-uart >> >> + - google,gs101-uart >> > >> > These shouldn't be needed, just declare the device as the same as what >> >> We should have SoC specific compatibles so that any further quirks or >> incompatibilities can be easily addressed. > > "further" work on quirks or incompatibilities can be added when they are > found and needed. We don't add stuff for no good reason to the kernel. > >> It's not only the IP itself >> that can differ, it's also the integration of the IP into the final >> product that could have an influence on the behavior. > > This is for the Pixel 6, a device that is no longer even shipping. The > "final product" is long stable, so this should not be an issue. The driver does have soc specific settings for each compatible string, in this case it looks like it overrides the FIFO size based on driver specific data and the order in which the ports are probed [1]. I don't understand why the driver does this, but my impression is that if we wanted to change it to no longer rely on that data, we'd also need a new compatible string. Ideally, the actual compatible list in the DTB lists both the specific implementation (google,gs101-uart) in order to allow such hacks if needed, and a more generic string (e.g. "samsung,exynos850-uart" for an older device that is entirely compatible) in order to not actually need driver changes. Arnd [1] https://lore.kernel.org/linux-arm-kernel/20231010224928.2296997-17-peter.griffin@linaro.org/
On Wed, Oct 11, 2023, at 11:42, Greg Kroah-Hartman wrote: > On Wed, Oct 11, 2023 at 11:30:25AM +0200, Arnd Bergmann wrote: >> On Wed, Oct 11, 2023, at 10:57, Greg KH wrote: >> > >> >> It's not only the IP itself >> >> that can differ, it's also the integration of the IP into the final >> >> product that could have an influence on the behavior. >> > >> > This is for the Pixel 6, a device that is no longer even shipping. The >> > "final product" is long stable, so this should not be an issue. >> >> The driver does have soc specific settings for each compatible >> string, in this case it looks like it overrides the FIFO size >> based on driver specific data and the order in which the >> ports are probed [1]. I don't understand why the driver does >> this, but my impression is that if we wanted to change it to no >> longer rely on that data, we'd also need a new compatible >> string. > > As I reviewed that patch already, it is just duplicating an existing > quirk/device that the driver already supports, so there is no need for > any "new device type" to be added to that driver, just use the existing > hardware description in the dt and all should be fine. The thing is, I suspect that the FIFO size override is actually wrong for the exynos850 as well, and is almost certainly wrong for both exynosautov9 and google-gs101: - The driver overrides an exynos850 compatible uart to use a 256 byte FIFO on whichever port is probed first, 64 byte on the next three ports, and the setting from DT on any later ones, falling back to 16 bytes if the DT does not set anything. - exynos850 only actually has three of these ports, not four. It does not lists FIFO size in the dts at all. - exynosautov9 has a total of 11 ports, each of these compatible with both "samsung,exynosautov9-uart" as the specific value and "samsung,exynos850-uart" as the generic fallback. The DT lists a FIFO size of 256 bytes for ports 0, 1, and 6, but lists FIFO size 64 for each of the other ones. - google-gs101 only lists a single uart in the dts, and sets it to a 256 byte FIFO. - testla-fsd claims to be compatible with exynos4210, which also overrides the first two ports in probe order to 256 and 64 bytes respectively (like exynos850), but it only has two ports. - artpec8 has a separate compatible string so it overrides all ports to 64 bytes. I don't know why probe order would have anything to do with this, so most likely these are all the same thing and should just put a fixed FIFO size into the DT for each port instance. Arnd
Hi Arnd, Thanks for your feedback. On Wed, 11 Oct 2023 at 11:19, Arnd Bergmann <arnd@arndb.de> wrote: > > On Wed, Oct 11, 2023, at 11:42, Greg Kroah-Hartman wrote: > > On Wed, Oct 11, 2023 at 11:30:25AM +0200, Arnd Bergmann wrote: > >> On Wed, Oct 11, 2023, at 10:57, Greg KH wrote: > >> > > >> >> It's not only the IP itself > >> >> that can differ, it's also the integration of the IP into the final > >> >> product that could have an influence on the behavior. > >> > > >> > This is for the Pixel 6, a device that is no longer even shipping. The > >> > "final product" is long stable, so this should not be an issue. > >> > >> The driver does have soc specific settings for each compatible > >> string, in this case it looks like it overrides the FIFO size > >> based on driver specific data and the order in which the > >> ports are probed [1]. I don't understand why the driver does > >> this, but my impression is that if we wanted to change it to no > >> longer rely on that data, we'd also need a new compatible > >> string. > > > > As I reviewed that patch already, it is just duplicating an existing > > quirk/device that the driver already supports, so there is no need for > > any "new device type" to be added to that driver, just use the existing > > hardware description in the dt and all should be fine. > > The thing is, I suspect that the FIFO size override is actually > wrong for the exynos850 as well, and is almost certainly wrong > for both exynosautov9 and google-gs101: > > - The driver overrides an exynos850 compatible uart to use a > 256 byte FIFO on whichever port is probed first, 64 byte > on the next three ports, and the setting from DT on any > later ones, falling back to 16 bytes if the DT does not set > anything. > > - exynos850 only actually has three of these ports, not > four. It does not lists FIFO size in the dts at all. > > - exynosautov9 has a total of 11 ports, each of these > compatible with both "samsung,exynosautov9-uart" as > the specific value and "samsung,exynos850-uart" as > the generic fallback. The DT lists a FIFO size of 256 > bytes for ports 0, 1, and 6, but lists FIFO size 64 > for each of the other ones. > > - google-gs101 only lists a single uart in the dts, > and sets it to a 256 byte FIFO. > > - testla-fsd claims to be compatible with exynos4210, > which also overrides the first two ports in probe > order to 256 and 64 bytes respectively (like exynos850), > but it only has two ports. > > - artpec8 has a separate compatible string so it overrides > all ports to 64 bytes. > > I don't know why probe order would have anything to do > with this, so most likely these are all the same thing > and should just put a fixed FIFO size into the DT for > each port instance. I agree, I just looked again at gs101 and in total we can have 19 uarts on this SoC. 3 of them are 256byte rx/tx fifo and the other 16 have 64byte tx/rx fifo size, but this is a SoC design choice and has nothing to do with probe order. I will update in v3 to get fifo size from DT. regards, Peter.
On Wed, Oct 11, 2023 at 9:48 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > - enum: > > - apple,s5l-uart > > - axis,artpec8-uart > > + - google,gs101-uart > > These shouldn't be needed, just declare the device as the same as what > the chip really is (i.e. a samsung uart), that way no .yaml or kernel > driver changes are needed at all. We strive to have these as unique as possible, as it is a hardware description. It is fine to write drivers in Linux or any other OS just being aware of a "courser" idea of what UART this is, in this case would have looked something like this: compatible = "google,gs101-uart", "samsung-uart"; And the driver would be able to match to just the latter string (these are listed in "particularity order"). BUT! The binding authors chose not to go that path, instead they have one unique compatible string per hardware/integration version, essentially per-SoC. So in this case it is just: compatible = "google,gs101-uart"; It is kind of impossible to fix now as well, because these bindings are already deployed. So they are like a BIOS: written in stone. It is possible to add dual compatibles for this *and following* variants, but I don't know how Krzysztof feels about that, and as others point out, probably knowledge of the exact SoC is necessary. Yours, Linus Walleij
On 11/10/2023 10:57, Greg KH wrote: > On Wed, Oct 11, 2023 at 09:49:07AM +0100, Tudor Ambarus wrote: >> Hi, Greg, >> >> On 10/11/23 08:48, Greg KH wrote: >>> On Tue, Oct 10, 2023 at 11:49:16PM +0100, Peter Griffin wrote: >>>> Add dedicated google-gs101-uart compatible to the dt-schema for >>>> representing uart of the Google Tensor gs101 SoC. >>>> >>>> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> >>>> --- >>>> Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++ >>>> 1 file changed, 2 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml >>>> index 8bd88d5cbb11..72471ebe5734 100644 >>>> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml >>>> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml >>>> @@ -19,11 +19,13 @@ properties: >>>> compatible: >>>> oneOf: >>>> - items: >>>> + - const: google,gs101-uart >>>> - const: samsung,exynosautov9-uart >>>> - const: samsung,exynos850-uart >>>> - enum: >>>> - apple,s5l-uart >>>> - axis,artpec8-uart >>>> + - google,gs101-uart >>> >>> These shouldn't be needed, just declare the device as the same as what >> >> We should have SoC specific compatibles so that any further quirks or >> incompatibilities can be easily addressed. > > "further" work on quirks or incompatibilities can be added when they are > found and needed. We don't add stuff for no good reason to the kernel. With a Devicetree bindings maintainer hat: We expect the device-specific compatible in all bindings, followed by fallback. The fallback is used by the driver, the device-specific for any future needs. This is the practice we follow everywhere and recommend everywhere since some time. It is also documented here: https://elixir.bootlin.com/linux/v6.6-rc5/source/Documentation/devicetree/bindings/writing-bindings.rst#L42 Best regards, Krzysztof
On 11/10/2023 09:44, Greg KH wrote: > On Tue, Oct 10, 2023 at 11:49:08PM +0100, Peter Griffin wrote: >> Hi folks, >> >> Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all >> the review feedback received so far. >> >> This series adds initial SoC support for the GS101 SoC and also initial board >> support for Pixel 6 phone (Oriole). >> >> The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro >> (raven) phones. Currently DT is added for the gs101 SoC and Oriole. >> As you can see from the patches the SoC is based on a Samsung Exynos SoC, >> and therefore lots of the low level Exynos drivers can be re-used. >> >> The support added in this series consists of: >> * cpus >> * pinctrl >> * some CCF implementation >> * watchdog >> * uart >> * gpio > > So you have sent a patch series that crosses multiple subsystems, who is > supposed to be taking these patches? Or do you not want them actually > merged? Me, through Samsung SoC -> ARM SoC. The cover letter could say that. Best regards, Krzysztof
On 11/10/2023 11:11, Greg KH wrote: >>> >>> So you have sent a patch series that crosses multiple subsystems, who is >>> supposed to be taking these patches? Or do you not want them actually >>> merged? >> >> Krzysztof indicated here: >> https://lore.kernel.org/all/b1598405-b01f-426a-aaba-89f2d2dc9c2e@linaro.org/ >> that he would like to be the one applying the entire series through the Samsung >> SoC tree. If that's fine with everyone (it's OK with me). > > As the serial changes are not ok (see my comments on them), I don't > think they should be going through any tree at this point in time :) Yes, of course, I still need (or will need) your Ack. > > Also, in your 00/XX email, say what tree you expect them to go through > so we have a chance to know that please. +1 Best regards, Krzysztof
Hi Krzysztof, Thanks for your review. On Wed, 11 Oct 2023 at 13:09, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 11/10/2023 00:49, Peter Griffin wrote: > > Add dedicated google-gs101-uart compatible to the dt-schema for > > representing uart of the Google Tensor gs101 SoC. > > > > Signed-off-by: Peter Griffin <peter.griffin@linaro.org> > > --- > > Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml > > index 8bd88d5cbb11..72471ebe5734 100644 > > --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml > > +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml > > @@ -19,11 +19,13 @@ properties: > > compatible: > > oneOf: > > - items: > > + - const: google,gs101-uart > > You just broke existing users. > > It does not look like you tested the DTS against bindings. Please run > `make dtbs_check W=1` (see > Documentation/devicetree/bindings/writing-schema.rst or > https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/ > for instructions). > Will fix in v3 fyi I've been running with make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dt_binding_check DT_SCHEMA_FILES=google make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- dt_binding_check DT_SCHEMA_FILES=samsung make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y W=1 google/gs101-oriole.dtb But clearly that wasn't enough to catch this. `make dtbs_check W=1` takes a long time and gives so much output. I suppose adding a few of the other exynos based boards should still be fairly quick and hopefully catch things like this. For example adding make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y W=1 exynos/exynos850-e850-96.dtb make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y W=1 exynos/exynos5433-tm2.dtb make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y W=1 exynos/exynosautov9-sadk.dtb regards, Peter.
On 11/10/2023 15:27, Peter Griffin wrote: > Hi Krzysztof, > > Thanks for your review. > > On Wed, 11 Oct 2023 at 13:09, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: >> >> On 11/10/2023 00:49, Peter Griffin wrote: >>> Add dedicated google-gs101-uart compatible to the dt-schema for >>> representing uart of the Google Tensor gs101 SoC. >>> >>> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> >>> --- >>> Documentation/devicetree/bindings/serial/samsung_uart.yaml | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml >>> index 8bd88d5cbb11..72471ebe5734 100644 >>> --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml >>> +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml >>> @@ -19,11 +19,13 @@ properties: >>> compatible: >>> oneOf: >>> - items: >>> + - const: google,gs101-uart >> >> You just broke existing users. >> >> It does not look like you tested the DTS against bindings. Please run >> `make dtbs_check W=1` (see >> Documentation/devicetree/bindings/writing-schema.rst or >> https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/ >> for instructions). >> > > Will fix in v3 > > fyi I've been running with > > make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- > dt_binding_check DT_SCHEMA_FILES=google > make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- > dt_binding_check DT_SCHEMA_FILES=samsung > make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y > W=1 google/gs101-oriole.dtb > > But clearly that wasn't enough to catch this. None of the commands above test existing DTS... >`make dtbs_check W=1` > takes a long time > and gives so much output. I suppose adding a few of the other exynos > based boards should > still be fairly quick and hopefully catch things like this. For example adding > > make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y > W=1 exynos/exynos850-e850-96.dtb > make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y > W=1 exynos/exynos5433-tm2.dtb > make -j$js ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- CHECK_DTBS=y > W=1 exynos/exynosautov9-sadk.dtb > > regards, > > Peter. Best regards, Krzysztof
Hi Tudor, Thanks for your review feedback. On Wed, 11 Oct 2023 at 09:42, Tudor Ambarus <tudor.ambarus@linaro.org> wrote: > > > > On 10/11/23 09:16, Peter Griffin wrote: > > Hi Tudor, > > > > Thanks for your reply. > > > > On Wed, 11 Oct 2023 at 07:10, Tudor Ambarus <tudor.ambarus@linaro.org> wrote: > >> > >> Hi, Peter, > >> > >> On 10/10/23 23:49, Peter Griffin wrote: > >>> Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl > >>> compatible` I tried to narrow the interrupts check to > >>> google,gs101-pinctrl but I still see a warning: gs101-oriole.dtb: > >>> pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long If anyone can > >>> educate me on what I've done wrong here it would be most appreciated! > >> > >> I guess the initial definition of the number of interrupts should > >> include the largest min/maxItems. I no longer see the warning with this > >> change: > > > > Yes that is how it was in v1. The review feedback though was to narrow > > the scope to just google,gs101-pinctrl compatible using if: then: else: which > > is what I can't get to work properly. > > > > Right. The diff that I sent is on top of your changes (patch 6/20). > I expect that when the interrupts property is defined it should include > the min/maxItems of all the available SoCs. Then use "if Soc" to narrow > the range. Ah I see, yes thanks Tudor! I will incorporate this in v3. regards, Peter
Hi Guenter, Thanks for your review. On Wed, 11 Oct 2023 at 00:56, Guenter Roeck <linux@roeck-us.net> wrote: > > On Tue, Oct 10, 2023 at 11:49:23PM +0100, Peter Griffin wrote: > > This patch adds the compatibles and drvdata for the Google > > gs101 & gs201 SoCs found in Pixel 6 and Pixel 7 phones. Similar > > to Exynos850 it has two watchdog instances, one for each cluster > > and has some control bits in PMU registers. > > > > The watchdog IP found in gs101 SoCs also supports a few > > additional bits/features in the WTCON register which we add > > support for and an additional register detailed below. > > > > dbgack-mask - Enables masking WDT interrupt and reset request > > according to asserted DBGACK input > > > > windowed-mode - Enabled Windowed watchdog mode > > > > Windowed watchdog mode also has an additional register WTMINCNT. > > If windowed watchdog is enabled and you reload WTCNT when the > > value is greater than WTMINCNT, it prompts interrupt or reset > > request as if the watchdog time has expired. > > I am a bit lost with this one. The patch adds QUIRK_HAS_WTMINCNT_REG > but doesn't use it. It also adds S3C2410_WTMINCNT but does not use it > either. > > What is the point of doing that ? It is just confusing. Good spot, it seems I lost a few hunks from this patch at some point, sorry about that. I will update and send a v3. regards, Peter.
Hi, all I wanted to inquire about how do you all feel about calling this SoC by the Google "gs101" name. 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. Yours, - Markuss On 10/11/23 01:49, Peter Griffin wrote: > Hi folks, > > Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all > the review feedback received so far. > > This series adds initial SoC support for the GS101 SoC and also initial board > support for Pixel 6 phone (Oriole). > > The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro > (raven) phones. Currently DT is added for the gs101 SoC and Oriole. > As you can see from the patches the SoC is based on a Samsung Exynos SoC, > and therefore lots of the low level Exynos drivers can be re-used. > > The support added in this series consists of: > * cpus > * pinctrl > * some CCF implementation > * watchdog > * uart > * gpio > > This is enough to boot through to a busybox initramfs and shell using an > upstream kernel though :) More platform support will be added over the > following weeks and months. > > Note 1: I've removed the dtbo overlay from v2 submission and will re-submit once > I have appropriate documentation for it. > > Note 2: I've left the bootargs in dts with earlycon for now, for two reasons. > 1) The bootloader hangs if bootargs isn't present in the dtb as it tries to > re-write this with additional bootargs. > 2) there is a issue whereby the full serial console doesn't come up properly > if earlycon isn't also specified. This issue needs further investigation. > > Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible` > I tried to narrow the interrupts check to google,gs101-pinctrl but I still see > a warning: > gs101-oriole.dtb: pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long > > If anyone can educate me on what I've done wrong here it would be most > appreciated! > > kind regards, > > Peter. > > Changes since v1: > - Remove irq/gs101.h and replace macros with irq numbers globally > - exynos-pmu - keep alphabetical order > - add cmu_apm to clock bindings documentation > - sysreg bindings - remove superfluous `google,gs101-sysreg` > - watchdog bindings - Alphanumerical order, update gs201 comment > - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC > - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order > - samsung,pinctrl- add google,gs101-wakeup-eint compatible > - clk-pll: fixup typos > - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate) > - clk-gs101: fix alphabetical order > - clk-gs101: cmu_apm: fixup typo and missing empty entry > - clk-gs101: cmu_misc: remove clocks that were being registerred twice > - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON bitfield > - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins as well > - pinctrl: gs101: rename bank_type_6/7 structs to be more specific, split from filter > - watchdog: s3c2410_wdt: remove dev_info prints > - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node name, blank lines > add SoC node, split dts and dtsi into separate patches, remove 'DVT' suffix > - gs101-oriole.dtso: Remove overlay until board_id is documented properly > - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones > - gpio-keys: update linux,code to use input-event-code macros > - add dedicated gs101-uart compatible > > Peter Griffin (20): > dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible > dt-bindings: clock: Add Google gs101 clock management unit bindings > dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG > compatibles to GS101 > dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings > dt-bindings: arm: google: Add bindings for Google ARM platforms > dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible > dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible > dt-bindings: serial: samsung: Add google-gs101-uart compatible > clk: samsung: clk-pll: Add support for pll_{0516,0517,518} > clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates > clk: samsung: clk-gs101: add CMU_APM support > clk: samsung: clk-gs101: Add support for CMU_MISC clock unit > pinctrl: samsung: Add filter selection support for alive banks > pinctrl: samsung: Add gs101 SoC pinctrl configuration > watchdog: s3c2410_wdt: Add support for Google tensor SoCs > tty: serial: samsung: Add gs101 compatible and SoC data > arm64: dts: google: Add initial Google gs101 SoC support > arm64: dts: google: Add initial Oriole/pixel 6 board support > arm64: defconfig: Enable Google Tensor SoC > MAINTAINERS: add entry for Google Tensor SoC > > .../devicetree/bindings/arm/google.yaml | 46 + > .../bindings/clock/google,gs101-clock.yaml | 125 + > .../samsung,pinctrl-wakeup-interrupt.yaml | 2 + > .../bindings/pinctrl/samsung,pinctrl.yaml | 19 + > .../bindings/serial/samsung_uart.yaml | 2 + > .../bindings/soc/samsung/exynos-pmu.yaml | 2 + > .../soc/samsung/samsung,exynos-sysreg.yaml | 6 + > .../bindings/watchdog/samsung-wdt.yaml | 10 +- > MAINTAINERS | 10 + > arch/arm64/Kconfig.platforms | 6 + > arch/arm64/boot/dts/Makefile | 1 + > arch/arm64/boot/dts/google/Makefile | 4 + > arch/arm64/boot/dts/google/gs101-oriole.dts | 79 + > arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 ++++++++++ > arch/arm64/boot/dts/google/gs101-pinctrl.h | 32 + > arch/arm64/boot/dts/google/gs101.dtsi | 503 ++++ > arch/arm64/configs/defconfig | 1 + > drivers/clk/samsung/Kconfig | 9 + > drivers/clk/samsung/Makefile | 2 + > drivers/clk/samsung/clk-gs101.c | 2164 +++++++++++++++++ > drivers/clk/samsung/clk-pll.c | 9 +- > drivers/clk/samsung/clk-pll.h | 3 + > .../pinctrl/samsung/pinctrl-exynos-arm64.c | 163 ++ > drivers/pinctrl/samsung/pinctrl-exynos.c | 84 +- > drivers/pinctrl/samsung/pinctrl-exynos.h | 41 + > drivers/pinctrl/samsung/pinctrl-samsung.c | 4 + > drivers/pinctrl/samsung/pinctrl-samsung.h | 24 + > drivers/tty/serial/samsung_tty.c | 12 + > drivers/watchdog/s3c2410_wdt.c | 104 +- > include/dt-bindings/clock/google,gs101.h | 232 ++ > 30 files changed, 4961 insertions(+), 13 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/google.yaml > create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml > create mode 100644 arch/arm64/boot/dts/google/Makefile > create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts > create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi > create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h > create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi > create mode 100644 drivers/clk/samsung/clk-gs101.c > create mode 100644 include/dt-bindings/clock/google,gs101.h >
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. > > 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. 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. regards, Peter. > > Yours, > > - Markuss > > On 10/11/23 01:49, Peter Griffin wrote: > > Hi folks, > > > > Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all > > the review feedback received so far. > > > > This series adds initial SoC support for the GS101 SoC and also initial board > > support for Pixel 6 phone (Oriole). > > > > The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro > > (raven) phones. Currently DT is added for the gs101 SoC and Oriole. > > As you can see from the patches the SoC is based on a Samsung Exynos SoC, > > and therefore lots of the low level Exynos drivers can be re-used. > > > > The support added in this series consists of: > > * cpus > > * pinctrl > > * some CCF implementation > > * watchdog > > * uart > > * gpio > > > > This is enough to boot through to a busybox initramfs and shell using an > > upstream kernel though :) More platform support will be added over the > > following weeks and months. > > > > Note 1: I've removed the dtbo overlay from v2 submission and will re-submit once > > I have appropriate documentation for it. > > > > Note 2: I've left the bootargs in dts with earlycon for now, for two reasons. > > 1) The bootloader hangs if bootargs isn't present in the dtb as it tries to > > re-write this with additional bootargs. > > 2) there is a issue whereby the full serial console doesn't come up properly > > if earlycon isn't also specified. This issue needs further investigation. > > > > Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible` > > I tried to narrow the interrupts check to google,gs101-pinctrl but I still see > > a warning: > > gs101-oriole.dtb: pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long > > > > If anyone can educate me on what I've done wrong here it would be most > > appreciated! > > > > kind regards, > > > > Peter. > > > > Changes since v1: > > - Remove irq/gs101.h and replace macros with irq numbers globally > > - exynos-pmu - keep alphabetical order > > - add cmu_apm to clock bindings documentation > > - sysreg bindings - remove superfluous `google,gs101-sysreg` > > - watchdog bindings - Alphanumerical order, update gs201 comment > > - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC > > - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order > > - samsung,pinctrl- add google,gs101-wakeup-eint compatible > > - clk-pll: fixup typos > > - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate) > > - clk-gs101: fix alphabetical order > > - clk-gs101: cmu_apm: fixup typo and missing empty entry > > - clk-gs101: cmu_misc: remove clocks that were being registerred twice > > - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON bitfield > > - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins as well > > - pinctrl: gs101: rename bank_type_6/7 structs to be more specific, split from filter > > - watchdog: s3c2410_wdt: remove dev_info prints > > - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node name, blank lines > > add SoC node, split dts and dtsi into separate patches, remove 'DVT' suffix > > - gs101-oriole.dtso: Remove overlay until board_id is documented properly > > - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones > > - gpio-keys: update linux,code to use input-event-code macros > > - add dedicated gs101-uart compatible > > > > Peter Griffin (20): > > dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible > > dt-bindings: clock: Add Google gs101 clock management unit bindings > > dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG > > compatibles to GS101 > > dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings > > dt-bindings: arm: google: Add bindings for Google ARM platforms > > dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible > > dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible > > dt-bindings: serial: samsung: Add google-gs101-uart compatible > > clk: samsung: clk-pll: Add support for pll_{0516,0517,518} > > clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates > > clk: samsung: clk-gs101: add CMU_APM support > > clk: samsung: clk-gs101: Add support for CMU_MISC clock unit > > pinctrl: samsung: Add filter selection support for alive banks > > pinctrl: samsung: Add gs101 SoC pinctrl configuration > > watchdog: s3c2410_wdt: Add support for Google tensor SoCs > > tty: serial: samsung: Add gs101 compatible and SoC data > > arm64: dts: google: Add initial Google gs101 SoC support > > arm64: dts: google: Add initial Oriole/pixel 6 board support > > arm64: defconfig: Enable Google Tensor SoC > > MAINTAINERS: add entry for Google Tensor SoC > > > > .../devicetree/bindings/arm/google.yaml | 46 + > > .../bindings/clock/google,gs101-clock.yaml | 125 + > > .../samsung,pinctrl-wakeup-interrupt.yaml | 2 + > > .../bindings/pinctrl/samsung,pinctrl.yaml | 19 + > > .../bindings/serial/samsung_uart.yaml | 2 + > > .../bindings/soc/samsung/exynos-pmu.yaml | 2 + > > .../soc/samsung/samsung,exynos-sysreg.yaml | 6 + > > .../bindings/watchdog/samsung-wdt.yaml | 10 +- > > MAINTAINERS | 10 + > > arch/arm64/Kconfig.platforms | 6 + > > arch/arm64/boot/dts/Makefile | 1 + > > arch/arm64/boot/dts/google/Makefile | 4 + > > arch/arm64/boot/dts/google/gs101-oriole.dts | 79 + > > arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 ++++++++++ > > arch/arm64/boot/dts/google/gs101-pinctrl.h | 32 + > > arch/arm64/boot/dts/google/gs101.dtsi | 503 ++++ > > arch/arm64/configs/defconfig | 1 + > > drivers/clk/samsung/Kconfig | 9 + > > drivers/clk/samsung/Makefile | 2 + > > drivers/clk/samsung/clk-gs101.c | 2164 +++++++++++++++++ > > drivers/clk/samsung/clk-pll.c | 9 +- > > drivers/clk/samsung/clk-pll.h | 3 + > > .../pinctrl/samsung/pinctrl-exynos-arm64.c | 163 ++ > > drivers/pinctrl/samsung/pinctrl-exynos.c | 84 +- > > drivers/pinctrl/samsung/pinctrl-exynos.h | 41 + > > drivers/pinctrl/samsung/pinctrl-samsung.c | 4 + > > drivers/pinctrl/samsung/pinctrl-samsung.h | 24 + > > drivers/tty/serial/samsung_tty.c | 12 + > > drivers/watchdog/s3c2410_wdt.c | 104 +- > > include/dt-bindings/clock/google,gs101.h | 232 ++ > > 30 files changed, 4961 insertions(+), 13 deletions(-) > > create mode 100644 Documentation/devicetree/bindings/arm/google.yaml > > create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml > > create mode 100644 arch/arm64/boot/dts/google/Makefile > > create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts > > create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi > > create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h > > create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi > > create mode 100644 drivers/clk/samsung/clk-gs101.c > > create mode 100644 include/dt-bindings/clock/google,gs101.h > >
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. >> >> 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. 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. > > 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. 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? 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. > > regards, > > Peter. > > > >> Yours, >> >> - Markuss >> >> On 10/11/23 01:49, Peter Griffin wrote: >>> Hi folks, >>> >>> Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all >>> the review feedback received so far. >>> >>> This series adds initial SoC support for the GS101 SoC and also initial board >>> support for Pixel 6 phone (Oriole). >>> >>> The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro >>> (raven) phones. Currently DT is added for the gs101 SoC and Oriole. >>> As you can see from the patches the SoC is based on a Samsung Exynos SoC, >>> and therefore lots of the low level Exynos drivers can be re-used. >>> >>> The support added in this series consists of: >>> * cpus >>> * pinctrl >>> * some CCF implementation >>> * watchdog >>> * uart >>> * gpio >>> >>> This is enough to boot through to a busybox initramfs and shell using an >>> upstream kernel though :) More platform support will be added over the >>> following weeks and months. >>> >>> Note 1: I've removed the dtbo overlay from v2 submission and will re-submit once >>> I have appropriate documentation for it. >>> >>> Note 2: I've left the bootargs in dts with earlycon for now, for two reasons. >>> 1) The bootloader hangs if bootargs isn't present in the dtb as it tries to >>> re-write this with additional bootargs. >>> 2) there is a issue whereby the full serial console doesn't come up properly >>> if earlycon isn't also specified. This issue needs further investigation. >>> >>> Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible` >>> I tried to narrow the interrupts check to google,gs101-pinctrl but I still see >>> a warning: >>> gs101-oriole.dtb: pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long >>> >>> If anyone can educate me on what I've done wrong here it would be most >>> appreciated! >>> >>> kind regards, >>> >>> Peter. >>> >>> Changes since v1: >>> - Remove irq/gs101.h and replace macros with irq numbers globally >>> - exynos-pmu - keep alphabetical order >>> - add cmu_apm to clock bindings documentation >>> - sysreg bindings - remove superfluous `google,gs101-sysreg` >>> - watchdog bindings - Alphanumerical order, update gs201 comment >>> - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC >>> - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order >>> - samsung,pinctrl- add google,gs101-wakeup-eint compatible >>> - clk-pll: fixup typos >>> - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate) >>> - clk-gs101: fix alphabetical order >>> - clk-gs101: cmu_apm: fixup typo and missing empty entry >>> - clk-gs101: cmu_misc: remove clocks that were being registerred twice >>> - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON bitfield >>> - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins as well >>> - pinctrl: gs101: rename bank_type_6/7 structs to be more specific, split from filter >>> - watchdog: s3c2410_wdt: remove dev_info prints >>> - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node name, blank lines >>> add SoC node, split dts and dtsi into separate patches, remove 'DVT' suffix >>> - gs101-oriole.dtso: Remove overlay until board_id is documented properly >>> - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones >>> - gpio-keys: update linux,code to use input-event-code macros >>> - add dedicated gs101-uart compatible >>> >>> Peter Griffin (20): >>> dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible >>> dt-bindings: clock: Add Google gs101 clock management unit bindings >>> dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG >>> compatibles to GS101 >>> dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings >>> dt-bindings: arm: google: Add bindings for Google ARM platforms >>> dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible >>> dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible >>> dt-bindings: serial: samsung: Add google-gs101-uart compatible >>> clk: samsung: clk-pll: Add support for pll_{0516,0517,518} >>> clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates >>> clk: samsung: clk-gs101: add CMU_APM support >>> clk: samsung: clk-gs101: Add support for CMU_MISC clock unit >>> pinctrl: samsung: Add filter selection support for alive banks >>> pinctrl: samsung: Add gs101 SoC pinctrl configuration >>> watchdog: s3c2410_wdt: Add support for Google tensor SoCs >>> tty: serial: samsung: Add gs101 compatible and SoC data >>> arm64: dts: google: Add initial Google gs101 SoC support >>> arm64: dts: google: Add initial Oriole/pixel 6 board support >>> arm64: defconfig: Enable Google Tensor SoC >>> MAINTAINERS: add entry for Google Tensor SoC >>> >>> .../devicetree/bindings/arm/google.yaml | 46 + >>> .../bindings/clock/google,gs101-clock.yaml | 125 + >>> .../samsung,pinctrl-wakeup-interrupt.yaml | 2 + >>> .../bindings/pinctrl/samsung,pinctrl.yaml | 19 + >>> .../bindings/serial/samsung_uart.yaml | 2 + >>> .../bindings/soc/samsung/exynos-pmu.yaml | 2 + >>> .../soc/samsung/samsung,exynos-sysreg.yaml | 6 + >>> .../bindings/watchdog/samsung-wdt.yaml | 10 +- >>> MAINTAINERS | 10 + >>> arch/arm64/Kconfig.platforms | 6 + >>> arch/arm64/boot/dts/Makefile | 1 + >>> arch/arm64/boot/dts/google/Makefile | 4 + >>> arch/arm64/boot/dts/google/gs101-oriole.dts | 79 + >>> arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 ++++++++++ >>> arch/arm64/boot/dts/google/gs101-pinctrl.h | 32 + >>> arch/arm64/boot/dts/google/gs101.dtsi | 503 ++++ >>> arch/arm64/configs/defconfig | 1 + >>> drivers/clk/samsung/Kconfig | 9 + >>> drivers/clk/samsung/Makefile | 2 + >>> drivers/clk/samsung/clk-gs101.c | 2164 +++++++++++++++++ >>> drivers/clk/samsung/clk-pll.c | 9 +- >>> drivers/clk/samsung/clk-pll.h | 3 + >>> .../pinctrl/samsung/pinctrl-exynos-arm64.c | 163 ++ >>> drivers/pinctrl/samsung/pinctrl-exynos.c | 84 +- >>> drivers/pinctrl/samsung/pinctrl-exynos.h | 41 + >>> drivers/pinctrl/samsung/pinctrl-samsung.c | 4 + >>> drivers/pinctrl/samsung/pinctrl-samsung.h | 24 + >>> drivers/tty/serial/samsung_tty.c | 12 + >>> drivers/watchdog/s3c2410_wdt.c | 104 +- >>> include/dt-bindings/clock/google,gs101.h | 232 ++ >>> 30 files changed, 4961 insertions(+), 13 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/arm/google.yaml >>> create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml >>> create mode 100644 arch/arm64/boot/dts/google/Makefile >>> create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts >>> create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi >>> create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h >>> create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi >>> create mode 100644 drivers/clk/samsung/clk-gs101.c >>> create mode 100644 include/dt-bindings/clock/google,gs101.h >>> - Maksym
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 >> <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. >>> >>> 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. > > 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. > > 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? 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. > > 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
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 > >> <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. > >>> > >>> 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 >
On 11/03/2023, William McVicker wrote: > 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 > > >> <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. > > >>> > > >>> 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). Sorry, I need to correct this after talking to more people. The Exynos9845 is the name that Samsung LSI refers to as the gs101 SoC. However, it was made exclusively for Google with Google-designed IP. Since this chip is exclusive to the Pixel device line-up, it would make sense to use the well known name that is used by Google in the Pixel factory kernel. Regards, Will > > > > > > > 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 > >
Hi William, On 11/3/23 19:36, William McVicker wrote: > 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 >>>> <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. >>>>> >>>>> 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. How is that relevant? I believe it is none of the kernel concerns, it's up to the user to do whatever with the built .dtb files. Also I do not see an issue in having a file list of all the .dtbo files you might want. > >> 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? One clear benefit would be the ease of maintaining all the SoC files at once. It's not that it is a benefit of having it in the Exynos folder, it's more like that there's no benefit in having a separate folder, and that also comes with some additional issues. As I said earlier, it's pretty similar to the Raspberry Pi 5 example: It contains Raspberry's in-house IP, but it's still called properly Broadcom. The only difference is that Raspberry does not want its name on the chip, but Google does, despite it being just as custom as the Raspberry SoC is. The company's policy should not be a factor for this decision, in my opinion. However as you've added, gs101 is the same thing as Exynos9845, so I believe there's no question that the Exynos name should be specified somewhere too, because this is what's literally wired in hardware, and not just a "well-known name that is used by Google in the Pixel factory kernel". I agree though that just specifying the internal E9845 name could mislead some people, but GS101 is a similarly obscure name, and not even the real name of the hardware. > > 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 >> Yours, Maksym
I believe I misunderstood your point, and now that I'm reading it again I believe grouping device trees based on device manufacturer is definitely an interesting idea and it would definitely make sense for e.g. x86, where there's basically two big SoC vendors and all the DTBs for the motherboards in just those two folders would result in cluttering issues, however it is not currently done in arm64/boot/dts, where the subfolders are per-platform (exynos, qcom, mtk, tegra, ...) - with an exception of Tesla, which perhaps should be also corrected (also CONFIG_ARCH makes it clear what those directory names are actually meant to represent). If you think the current approach should be changed, it should be changed for all device-trees, and the CONFIG_ARCH_* should be also renamed, but also we'd need to convince everyone that this approach is superior to others... Maybe the solution to this is to have arch/arm64/boot/dts/exynos/google with Google's boards, and to have the SoC .dtsi files in arch/arm64/boot/dts/exynos, but I'm not sure. Additionally, I believe using .dtbo files like that (per board variant) is not really expected, instead each board should have its own .dtb file, compiled from a board .dts file which includes the SoC .dtsi file but this is not up to me to judge... On 11/4/23 01:05, Maksym Holovach wrote: > Hi William, > > On 11/3/23 19:36, William McVicker wrote: >> 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 >>>>> <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. >>>>>> >>>>>> 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. > > How is that relevant? > > I believe it is none of the kernel concerns, it's up to the user to do > whatever with the built .dtb files. > > Also I do not see an issue in having a file list of all the .dtbo > files you might want. >> >>> 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? > > One clear benefit would be the ease of maintaining all the SoC files > at once. It's not that it is a benefit of having it in the Exynos > folder, it's more like that there's no benefit in having a separate > folder, and that also comes with some additional issues. > > As I said earlier, it's pretty similar to the Raspberry Pi 5 example: > It contains Raspberry's in-house IP, but it's still called properly > Broadcom. The only difference is that Raspberry does not want its name > on the chip, but Google does, despite it being just as custom as the > Raspberry SoC is. The company's policy should not be a factor for this > decision, in my opinion. > > However as you've added, gs101 is the same thing as Exynos9845, so I > believe there's no question that the Exynos name should be specified > somewhere too, because this is what's literally wired in hardware, and > not just a "well-known name that is used by Google in the Pixel > factory kernel". > > I agree though that just specifying the internal E9845 name could > mislead some people, but GS101 is a similarly obscure name, and not > even the real name of the hardware. > >> >> 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 >>> > Yours, > > Maksym > Yours, Maksym
Hi Krzysztof Thanks for CCing me to the tread, I have not yet looked into the patches (as those never landed in my inbox). > -----Original Message----- > From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Sent: Friday, November 3, 2023 8:19 PM > To: Maksym Holovach <maksym.holovach.an.2022@lpnu.ua>; Peter Griffin > <peter.griffin@linaro.org> > 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 > > 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 > >> <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. > >>> > >>> 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. > > > > 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_j5B > FKxXxXKCT8PFQ@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.co > m/ > Yes it is, IMO SoC belongs to a “vendor”. Just because it uses some common IPs, does not make it belong to the some base family (in this case Exynos). I have being working on Exynos since Exynos4 days (and most of the Exynos series you have also worked on) and many more “vendor” specific SoC, like FSD etc. And you know, it is not the IPs which differentiates SoC but it is SoC micro architecture which differentiate various SoC and hence should be considered as different SoC. > >> 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. > You are right, the final product name should be used, which is, in case of FSD is FDS [1] and may be same is true for GS101 (I am not sure about GS101 though). [1] https://www.autopilotreview.com/tesla-custom-ai-chips-hardware-3/ > > > > 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? > > 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. > Just to keep things simple, IMO it should belong to "vendor" as they are the one who has or knows the current and future uses/plans for SoC/SoCs. Because an IP can be sourced from many/any IP vendors. AFA maintenance is concerns, people who is/are doing upstreaming does have an entry in the MAINTAINERS list for the SoC. > > > > 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... > Thanks Again. > 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
On 03/11/2023 18:36, William McVicker wrote: >> >> 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. None of existing platforms do it. Nowhere. All chromebooks are split per SoC, not "how DTBs should be used and distributed". There is no google, no Chromebook directory. None of Samsung phones have it. No Samsung-phone directory. None of Google phones have Pixel directory. You are now trying to introduce completely new rule, not existing in any upstream platform. > What is the benefit of adding the gs101 board files under > the exynos folder? To make it easier for us to maintain. You won't be maintaining any of these platforms. None of Google folks contributed patches or maintained any of these platforms so far, so it is up to upstream community to decide what is the most convenience way to maintain the kernel sources. Best regards, Krzysztof
On 05/11/2023 14:08, Greg KH wrote: > On Sun, Nov 05, 2023 at 01:52:22PM +0100, Krzysztof Kozlowski wrote: >> On 03/11/2023 18:36, William McVicker wrote: >> >>>> >>>> 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. >> >> None of existing platforms do it. Nowhere. All chromebooks are split per >> SoC, not "how DTBs should be used and distributed". There is no google, >> no Chromebook directory. None of Samsung phones have it. No >> Samsung-phone directory. None of Google phones have Pixel directory. > > but for code we have: > drivers/patform/chrome/ > drivers/firmware/google/ > drivers/net/ethernet/google/ > > don't know if that matters or not, but thought I would mention it... Yes, for the drivers for the similar hardware we have it. We have drivers for Chromebook's Embedded Controller - let's put it in one place, so that maintenance and review will be easier. Now for DTS, the common hardware is not "Samsung phones", but "Samsung SoC". We organize it like: 1. Samsung phones with Samsung SoC -> arm64/dts/samsung 2. Samsung phones with Qualcomm SoC -> arm64/dts/qcom because the main common part is the SoC, not the rest of the phone. There is no reviewer or maintainer for Samsung phones. There is no need for such. No benefits, almost not many common parts except some touchscreen. Why Google Pixel suddenly should be exception from the way we handle DTS of all ARM64 platforms? Best regards, Krzysztof
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
Hi Krzysztof, On Fri, 3 Nov 2023 at 14:49, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> 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 > >> <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. > >>> > >>> 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. > > > > 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. RPi ISP is named 'raspberrypi,pispbe' in RPi downstream drivers. See linux/drivers/media/platform/raspberrypi/pisp_be/ in RPi tree. > > 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/ Thanks for those references. I know nothing about Tesla FSD SoC internals I'm afraid. But it seems plausible to me that you would not goto the expense of designing your own SoC if something existed off the shelf you could just buy. I suspect the original SoC series for Tesla, Tensor etc tend to look very "exynos" centric as it is the non differentiating bits of IP, but also the IP that is required first to bring up the platform. > > >> 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 that was the correct decision IMO, and it is a very similar situation here as far as I'm concerned. Most people don't know Tensor G1 SoC as Exynos 9845. > > > > > 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? > > 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). There is more Google IP than TPU but I see the point you're making. > > 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. Or multiple big pieces of IP. Does having it all under the exynos directory help you somehow with maintenance? Has having Alim maintain tesla-fsd in a separate directory caused issues? I structured it like this as I thought it would scale better, and also because it was consistent with what you had accepted previously for other Exynos derived SoCs like Tesla. > > > > > 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. Sorry about that. I can add Alim and others to CC next time around. I didn't notice he was listed as a reviewer of Exynos. I thought it was only for Tesla FSD SoC. My apologies Alim! Thanks, Peter.
On 06/11/2023 13:46, Peter Griffin wrote: >> >> 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. These are all common to Exynos and usually they use Exynos-specific glue, so we consider them all Exynos-specific. > > 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. Not that different. Broadcom designed previous chip. Samsung designed previous chip. Broadcom designed BCM2717 with RPi ISP. Samsung designed GS101 with Tensor NPU and other blocks. >>> >>> 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. That's fine. What I don't agree is with putting it into Google, because Google wants to have all its phones in one place. That's not the argument we used for any other SoCs or products. We do not make decisions based on marketing or packaging wishes of some company. Otherwise Samsung phones will be together. Toradex boards (also spanning over NXP and TI) as well. Chromebooks DTS as well (oh, Doug would be happy, I guess :) ). And so on. > >> >> 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. I agreed on Tesla FSD in its own place mainly because of arguments provided that time: it's entirely different architecture. These arguments were not backed by actual facts or proofs, though. The upstreamed parts of FSD turned out to be... only Exynos specific. There is literally nothing non-Exynos in upstream. Therefore knowing the outcome I would say: put FSD into samsung directory. About GS101 I have the same questions - how similar it is? I am pretty sure that 95% of upstreamed code (DTS and drivers) will be Exynos-like (except for missing upstream support for generations of Exynos SoC!). But I cannot really judge and I am not going to investigate downstream code to figure this out. Thus if you insist that SoC architecture and core features are quite different from Exynos family, then sure, I can live with it. Best regards, Krzysztof
Hi all, On Mon, Nov 06, 2023 at 01:36:24PM +0000, Peter Griffin wrote: > Hi Krzysztof, > > On Fri, 3 Nov 2023 at 14:49, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> 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. [ ... ] > > >> 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 that was the correct decision IMO, and it is a very similar > situation here > as far as I'm concerned. Most people don't know Tensor G1 SoC as Exynos > 9845. I am not sure if Exynos 3830 and the like would be *that* confusing to users. It does not seem like the internal names (like Exynos 3830) are well guarded secret. The wikipedia article for Exynos even sort of gives these names for recent Exynos models, Exynos 850 is called S5E3830 for example, see section for Exynos 800: https://en.wikipedia.org/wiki/Exynos#Exynos_800_series Exynos 9845/S5E9845 is not mentioned in the article though. [ ... ] > > > 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? > > > > 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). > > There is more Google IP than TPU but I see the point you're making. > > > > > 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. > > Or multiple big pieces of IP. > > Does having it all under the exynos directory help you somehow with > maintenance? Has having Alim maintain tesla-fsd in a separate directory > caused issues? > > I structured it like this as I thought it would scale better, and also > because it was > consistent with what you had accepted previously for other Exynos derived SoCs > like Tesla. Another small benefit of putting GS101 in exynos/ is that it makes it easier for future contributors to find the code. If someone is for example trying to add mainline support for their Samsung Galaxy S21 (Exynos 2100/Exynos 9840) and want to find somewhat related boards to draw inspiration from then it is not clear at a first glance that google/gs101-* are (somewhat) related. [ ... ] > Thanks, > > Peter. Best regards, Henrik Grimler
Hi Krzysztof, On 11/06/2023, Krzysztof Kozlowski wrote: > On 06/11/2023 13:46, Peter Griffin wrote: > >> > >> 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. > > These are all common to Exynos and usually they use Exynos-specific > glue, so we consider them all Exynos-specific. > > > > > 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. > > Not that different. > Broadcom designed previous chip. > Samsung designed previous chip. > Broadcom designed BCM2717 with RPi ISP. > Samsung designed GS101 with Tensor NPU and other blocks. > > >>> > >>> 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. > > That's fine. What I don't agree is with putting it into Google, because > Google wants to have all its phones in one place. That's not the > argument we used for any other SoCs or products. > > We do not make decisions based on marketing or packaging wishes of some > company. Otherwise Samsung phones will be together. Toradex boards (also > spanning over NXP and TI) as well. Chromebooks DTS as well (oh, Doug > would be happy, I guess :) ). And so on. > > > > >> > >> 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. > > I agreed on Tesla FSD in its own place mainly because of arguments > provided that time: it's entirely different architecture. These > arguments were not backed by actual facts or proofs, though. The > upstreamed parts of FSD turned out to be... only Exynos specific. There > is literally nothing non-Exynos in upstream. Therefore knowing the > outcome I would say: put FSD into samsung directory. > > About GS101 I have the same questions - how similar it is? I am pretty > sure that 95% of upstreamed code (DTS and drivers) will be Exynos-like > (except for missing upstream support for generations of Exynos SoC!). > But I cannot really judge and I am not going to investigate downstream > code to figure this out. Thus if you insist that SoC architecture and > core features are quite different from Exynos family, then sure, I can > live with it. I honestly don't care too much about where the DT files are stored -- arch/arm64/boot/dts/exynos vs .../dts/google. I didn't think this would be such a hot topic! If this makes it easier for you to maintain, then so be it. Just to note, I do understand what I proposed is something new -- group DT files based on product owner vs original SoC designer -- and think it warrants consideration since it does make it easier to distinguish which DT files are associated with each product as well as package and distribute them easily, but that can be a discussion for another time when we get more upstreamed. Thanks, Will > > Best regards, > Krzysztof >
Hi Maksym, On 11/04/2023, Maksym Holovach wrote: > I believe I misunderstood your point, and now that I'm reading it again I > believe grouping device trees based on device manufacturer is definitely an > interesting idea and it would definitely make sense for e.g. x86, where > there's basically two big SoC vendors and all the DTBs for the motherboards > in just those two folders would result in cluttering issues, however it is > not currently done in arm64/boot/dts, where the subfolders are per-platform > (exynos, qcom, mtk, tegra, ...) - with an exception of Tesla, which perhaps > should be also corrected (also CONFIG_ARCH makes it clear what those > directory names are actually meant to represent). > > If you think the current approach should be changed, it should be changed > for all device-trees, and the CONFIG_ARCH_* should be also renamed, but also > we'd need to convince everyone that this approach is superior to others... > > Maybe the solution to this is to have arch/arm64/boot/dts/exynos/google with > Google's boards, and to have the SoC .dtsi files in > arch/arm64/boot/dts/exynos, but I'm not sure. Honesty, I don't care too much about where the files are kept. I agree it makes sense to keep them with the other Exynos DT files due to similarities with the other Exynos SoCs. I think the grouping based on vendor under the exynos folder make a lot of sense though considering how many DT files we will accumulate over time. > > Additionally, I believe using .dtbo files like that (per board variant) is > not really expected, instead each board should have its own .dtb file, > compiled from a board .dts file which includes the SoC .dtsi file but this > is not up to me to judge... This is something we (Peter and I) are wanting to discuss at LPC next week. We've included it in our slides and hope there will be enough folks there to have a good discussion. > > On 11/4/23 01:05, Maksym Holovach wrote: > > Hi William, > > > > On 11/3/23 19:36, William McVicker wrote: > > > 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 > > > > > > <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. > > > > > > > > > > > > > > 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. > > > > How is that relevant? > > > > I believe it is none of the kernel concerns, it's up to the user to do > > whatever with the built .dtb files. > > > > Also I do not see an issue in having a file list of all the .dtbo files > > you might want. I think organizing the DT files based on a product is relevant because it makes it easier to identify what files are associated with the final product(s). Leaving it up to the user just means you are forcing everyone to roll their own scripts to re-organize/postprocess the kernel artifacts for their products. I think it would be nice to be able to configure the kernel build to generate artifacts that are directly usable on the device. > > > > > > > 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? > > > > One clear benefit would be the ease of maintaining all the SoC files at > > once. It's not that it is a benefit of having it in the Exynos folder, > > it's more like that there's no benefit in having a separate folder, and > > that also comes with some additional issues. > > > > As I said earlier, it's pretty similar to the Raspberry Pi 5 example: It > > contains Raspberry's in-house IP, but it's still called properly > > Broadcom. The only difference is that Raspberry does not want its name > > on the chip, but Google does, despite it being just as custom as the > > Raspberry SoC is. The company's policy should not be a factor for this > > decision, in my opinion. > > > > However as you've added, gs101 is the same thing as Exynos9845, so I > > believe there's no question that the Exynos name should be specified > > somewhere too, because this is what's literally wired in hardware, and > > not just a "well-known name that is used by Google in the Pixel factory > > kernel". > > > > I agree though that just specifying the internal E9845 name could > > mislead some people, but GS101 is a similarly obscure name, and not even > > the real name of the hardware. gs101 is used in the downstream drivers as well as referenced in online materials referring to Pixel 6 (just search for "Google gs101"). In addition, gs101 is used by the Android userspace to refer to the SoC that Pixel 6/6 Pro/6a use. The same goes for gs201 and zuma. So I think it's important to keep the names consistent. I don't think the Exynos 9845 is ever referenced in the Android vendor userspace nor is it ever used by tech bloggers/writer/ enthusiast developers when referring to the Pixel 6 device. So if upstream decides to use the term 9845, they will just be introducing even more confusion. I also want to point out that I don't really like the Tensor name either. This is equivalent to the "Snapdragon" marketing name that is not used either in the Qualcomm device tree. In my opinion, gs101 is equivant to the "msmXYZ" and "smXYZ" names, e.g. msm8996 and sm8650. Thanks, Will > > > > > > > > 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 > > > > > > Yours, > > > > Maksym > > > Yours, > > Maksym >
Hi Peter > -----Original Message----- > From: Peter Griffin <peter.griffin@linaro.org> > Sent: Monday, November 6, 2023 6:16 PM > 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 > > 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. > 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
Hi folks, Firstly, thanks to everyone who reviewed the v1 series! V2 incorporates all the review feedback received so far. This series adds initial SoC support for the GS101 SoC and also initial board support for Pixel 6 phone (Oriole). The gs101 / Tensor SoC is also used in Pixel6a (bluejay) and Pixel 6 Pro (raven) phones. Currently DT is added for the gs101 SoC and Oriole. As you can see from the patches the SoC is based on a Samsung Exynos SoC, and therefore lots of the low level Exynos drivers can be re-used. The support added in this series consists of: * cpus * pinctrl * some CCF implementation * watchdog * uart * gpio This is enough to boot through to a busybox initramfs and shell using an upstream kernel though :) More platform support will be added over the following weeks and months. Note 1: I've removed the dtbo overlay from v2 submission and will re-submit once I have appropriate documentation for it. Note 2: I've left the bootargs in dts with earlycon for now, for two reasons. 1) The bootloader hangs if bootargs isn't present in the dtb as it tries to re-write this with additional bootargs. 2) there is a issue whereby the full serial console doesn't come up properly if earlycon isn't also specified. This issue needs further investigation. Note 3: In `dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible` I tried to narrow the interrupts check to google,gs101-pinctrl but I still see a warning: gs101-oriole.dtb: pinctrl@174d0000: interrupts: [[0, 0, 4],[..] is too long If anyone can educate me on what I've done wrong here it would be most appreciated! kind regards, Peter. Changes since v1: - Remove irq/gs101.h and replace macros with irq numbers globally - exynos-pmu - keep alphabetical order - add cmu_apm to clock bindings documentation - sysreg bindings - remove superfluous `google,gs101-sysreg` - watchdog bindings - Alphanumerical order, update gs201 comment - samsung,pinctrl.yaml - add new "if:then:else:" to narrow for google SoC - samsung,pinctrl-wakeup-interrupt.yaml - Alphanumerical order - samsung,pinctrl- add google,gs101-wakeup-eint compatible - clk-pll: fixup typos - clk-gs101: fix kernel test robot warnings (add 2 new clocks,dividers,gate) - clk-gs101: fix alphabetical order - clk-gs101: cmu_apm: fixup typo and missing empty entry - clk-gs101: cmu_misc: remove clocks that were being registerred twice - pinctrl: filter sel: rename/reorder variables, add comment for FLTCON bitfield - pinctrl: filter sel: avoid setting reserved bits by loop over FLTCON1 pins as well - pinctrl: gs101: rename bank_type_6/7 structs to be more specific, split from filter - watchdog: s3c2410_wdt: remove dev_info prints - gs101.dtsi/oriole.dts: order by unit node, remove underscores from node name, blank lines add SoC node, split dts and dtsi into separate patches, remove 'DVT' suffix - gs101-oriole.dtso: Remove overlay until board_id is documented properly - Add GS101_PIN_* macros to gs101-pinctrl.h instead of using Exynos ones - gpio-keys: update linux,code to use input-event-code macros - add dedicated gs101-uart compatible Peter Griffin (20): dt-bindings: soc: samsung: exynos-pmu: Add gs101 compatible dt-bindings: clock: Add Google gs101 clock management unit bindings dt-bindings: soc: google: exynos-sysreg: add dedicated SYSREG compatibles to GS101 dt-bindings: watchdog: Document Google gs101 & gs201 watchdog bindings dt-bindings: arm: google: Add bindings for Google ARM platforms dt-bindings: pinctrl: samsung: add google,gs101-pinctrl compatible dt-bindings: pinctrl: samsung: add gs101-wakeup-eint compatible dt-bindings: serial: samsung: Add google-gs101-uart compatible clk: samsung: clk-pll: Add support for pll_{0516,0517,518} clk: samsung: clk-gs101: Add cmu_top registers, plls, mux and gates clk: samsung: clk-gs101: add CMU_APM support clk: samsung: clk-gs101: Add support for CMU_MISC clock unit pinctrl: samsung: Add filter selection support for alive banks pinctrl: samsung: Add gs101 SoC pinctrl configuration watchdog: s3c2410_wdt: Add support for Google tensor SoCs tty: serial: samsung: Add gs101 compatible and SoC data arm64: dts: google: Add initial Google gs101 SoC support arm64: dts: google: Add initial Oriole/pixel 6 board support arm64: defconfig: Enable Google Tensor SoC MAINTAINERS: add entry for Google Tensor SoC .../devicetree/bindings/arm/google.yaml | 46 + .../bindings/clock/google,gs101-clock.yaml | 125 + .../samsung,pinctrl-wakeup-interrupt.yaml | 2 + .../bindings/pinctrl/samsung,pinctrl.yaml | 19 + .../bindings/serial/samsung_uart.yaml | 2 + .../bindings/soc/samsung/exynos-pmu.yaml | 2 + .../soc/samsung/samsung,exynos-sysreg.yaml | 6 + .../bindings/watchdog/samsung-wdt.yaml | 10 +- MAINTAINERS | 10 + arch/arm64/Kconfig.platforms | 6 + arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/google/Makefile | 4 + arch/arm64/boot/dts/google/gs101-oriole.dts | 79 + arch/arm64/boot/dts/google/gs101-pinctrl.dtsi | 1275 ++++++++++ arch/arm64/boot/dts/google/gs101-pinctrl.h | 32 + arch/arm64/boot/dts/google/gs101.dtsi | 503 ++++ arch/arm64/configs/defconfig | 1 + drivers/clk/samsung/Kconfig | 9 + drivers/clk/samsung/Makefile | 2 + drivers/clk/samsung/clk-gs101.c | 2164 +++++++++++++++++ drivers/clk/samsung/clk-pll.c | 9 +- drivers/clk/samsung/clk-pll.h | 3 + .../pinctrl/samsung/pinctrl-exynos-arm64.c | 163 ++ drivers/pinctrl/samsung/pinctrl-exynos.c | 84 +- drivers/pinctrl/samsung/pinctrl-exynos.h | 41 + drivers/pinctrl/samsung/pinctrl-samsung.c | 4 + drivers/pinctrl/samsung/pinctrl-samsung.h | 24 + drivers/tty/serial/samsung_tty.c | 12 + drivers/watchdog/s3c2410_wdt.c | 104 +- include/dt-bindings/clock/google,gs101.h | 232 ++ 30 files changed, 4961 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/google.yaml create mode 100644 Documentation/devicetree/bindings/clock/google,gs101-clock.yaml create mode 100644 arch/arm64/boot/dts/google/Makefile create mode 100644 arch/arm64/boot/dts/google/gs101-oriole.dts create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.dtsi create mode 100644 arch/arm64/boot/dts/google/gs101-pinctrl.h create mode 100644 arch/arm64/boot/dts/google/gs101.dtsi create mode 100644 drivers/clk/samsung/clk-gs101.c create mode 100644 include/dt-bindings/clock/google,gs101.h