> -----Original Message----- > From: Krzysztof Kozlowski <krzk@kernel.org> > Sent: Monday, July 21, 2025 12:10 PM > To: SeonGu Kang <ksk4725@coasia.com>; Jesper Nilsson > <jesper.nilsson@axis.com>; Michael Turquette <mturquette@baylibre.com>; > Stephen Boyd <sboyd@kernel.org>; Rob Herring <robh@kernel.org>; > Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley > <conor+dt@kernel.org>; Sylwester Nawrocki <s.nawrocki@samsung.com>; > Chanwoo Choi <cw00.choi@samsung.com>; Alim Akhtar > <alim.akhtar@samsung.com>; Linus Walleij <linus.walleij@linaro.org>; > Tomasz Figa <tomasz.figa@gmail.com>; Catalin Marinas > <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>; Arnd Bergmann > <arnd@arndb.de> > Cc: kenkim <kenkim@coasia.com>; Jongshin Park <pjsin865@coasia.com>; > GunWoo Kim <gwk1013@coasia.com>; HaGyeong Kim > <hgkim05@coasia.com>; GyoungBo Min <mingyoungbo@coasia.com>; > SungMin Park <smn1196@coasia.com>; Pankaj Dubey > <pankaj.dubey@samsung.com>; Shradha Todi <shradha.t@samsung.com>; > Ravi Patel <ravi.patel@samsung.com>; Inbaraj E <inbaraj.e@samsung.com>; > Swathi K S <swathi.ks@samsung.com>; Hrishikesh > <hrishikesh.d@samsung.com>; Dongjin Yang <dj76.yang@samsung.com>; > Sang Min Kim <hypmean.kim@samsung.com>; linux-kernel@vger.kernel.org; > linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; > linux-arm-kernel@axis.com; linux-clk@vger.kernel.org; > devicetree@vger.kernel.org; linux-gpio@vger.kernel.org; soc@lists.linux.dev > Subject: Re: [PATCH 00/16] Add support for the Axis ARTPEC-8 SoC > > On 21/07/2025 06:50, SeonGu Kang wrote: > > 2025-07-10 (목), 09:07 +0200, Krzysztof Kozlowski: > >> On 10/07/2025 02:20, ksk4725@coasia.com wrote: > >>> From: SeonGu Kang <ksk4725@coasia.com> > >>> > >>> Add basic support for the Axis ARTPEC-8 SoC. > >>> This SoC contains four Cortex-A53 CPUs and other several IPs. > >>> > >>> Patches 1 to 10 provide the support for the clock controller, which > >>> is similar to other Samsung SoCs. > >>> > >> You should explain here (and in DTS patches or the bindings) the > >> hardware, that this is Samsung SoC. > >> > >> You could also explain the differences from Exynos and proposed > >> handling of patches (because this is odd) > >> > >> Also, entire patchset has wrong and incomplete SoBs. Your SoB is > >> missing everywhere, others have wrong order. > >> > >> Please read submitting patches first. > >> > > > > This Custom SoC is owned by the Axis (OEM) and manufactured by the > > Samsung (ODM). It has standard Samsung specific IP blocks. > > > It is designed by Samsung. It is Samsung SoC. > > Anyway, don't explain to me, but in your patchset. Hi Krzysztof, Thank you for your review comments on the ARTPEC-8 platform patches. I'd like to add more context about the ARTPEC-8 SoC to help clarify its relationship with Exynos. Here are the key details about ARTPEC-8: - Manufactured by Samsung Foundry - SoC architecture is owned by Axis Communications - On similar model as Tesla's FSD chip owned by Tesla and manufactured and by Samsung - IPs from both Samsung and Axis Communications Samsung-provided IPs: - UART - Ethernet (Vendor: Synopsys) - Same IP has been integrated as integrated in FSD Chip - SDIO - SPI - HSI2C - I2S - CMU (Clock Management Unit) Follows same CMU HW architecture as Exynos SoC have - Pinctrl (GPIO) - PCIe (Vendor: Synopsys) Though Exynos, FSD, ARTPEC have same DesignWare Controller, the glue/wrapper layer around DWC Core has differences across these SoCs. All manufactured by Samsung, but differences are there in HW design and for different products. For the same reason PCIe patch refactoring effort is being put by us [1] to streamline single Exynos driver which can support all Samsung manufactured SoCs having DWC PCIe controller. [1]: https://patchwork.ozlabs.org/project/linux-pci/patch/20250625165229.3458-2-shradha.t@samsung.com/ Axis-provided IPs: - VIP (Image Sensor Processing IP) - VPP (Video Post Processing) - GPU - CDC (Video Encoder) As part of the upstreaming effort, Samsung and Coasia (DSP) team will work together to upstream basic SoC support and Samsung IPs support. The Axis team will be the primary maintainer for the ARTPEC-8 SoC codebase. Given that ARTPEC-8 is a distinct SoC with its own set of IPs, we believe it's reasonable to create a separate directory for it, similar to FSD. We will remove Samsung and Coasia teams from the maintainers list in v2 and only Axis team will be maintainer. Maintainer list for previous generation of Axis chips (ARM based) is already present, so this will be merged into that. Please let us know if this explanation addresses your concerns. We'll update the commit message and cover letter accordingly. Thanks, Pankaj Dubey > > Best regards, > Krzysztof
On 06/08/2025 10:22, Pankaj Dubey wrote: > > >> -----Original Message----- >> From: Krzysztof Kozlowski <krzk@kernel.org> >> Sent: Monday, July 21, 2025 12:10 PM >> To: SeonGu Kang <ksk4725@coasia.com>; Jesper Nilsson >> <jesper.nilsson@axis.com>; Michael Turquette <mturquette@baylibre.com>; >> Stephen Boyd <sboyd@kernel.org>; Rob Herring <robh@kernel.org>; >> Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley >> <conor+dt@kernel.org>; Sylwester Nawrocki <s.nawrocki@samsung.com>; >> Chanwoo Choi <cw00.choi@samsung.com>; Alim Akhtar >> <alim.akhtar@samsung.com>; Linus Walleij <linus.walleij@linaro.org>; >> Tomasz Figa <tomasz.figa@gmail.com>; Catalin Marinas >> <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>; Arnd Bergmann >> <arnd@arndb.de> >> Cc: kenkim <kenkim@coasia.com>; Jongshin Park <pjsin865@coasia.com>; >> GunWoo Kim <gwk1013@coasia.com>; HaGyeong Kim >> <hgkim05@coasia.com>; GyoungBo Min <mingyoungbo@coasia.com>; >> SungMin Park <smn1196@coasia.com>; Pankaj Dubey >> <pankaj.dubey@samsung.com>; Shradha Todi <shradha.t@samsung.com>; >> Ravi Patel <ravi.patel@samsung.com>; Inbaraj E <inbaraj.e@samsung.com>; >> Swathi K S <swathi.ks@samsung.com>; Hrishikesh >> <hrishikesh.d@samsung.com>; Dongjin Yang <dj76.yang@samsung.com>; >> Sang Min Kim <hypmean.kim@samsung.com>; linux-kernel@vger.kernel.org; >> linux-arm-kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; >> linux-arm-kernel@axis.com; linux-clk@vger.kernel.org; >> devicetree@vger.kernel.org; linux-gpio@vger.kernel.org; soc@lists.linux.dev >> Subject: Re: [PATCH 00/16] Add support for the Axis ARTPEC-8 SoC >> >> On 21/07/2025 06:50, SeonGu Kang wrote: >>> 2025-07-10 (목), 09:07 +0200, Krzysztof Kozlowski: >>>> On 10/07/2025 02:20, ksk4725@coasia.com wrote: >>>>> From: SeonGu Kang <ksk4725@coasia.com> >>>>> >>>>> Add basic support for the Axis ARTPEC-8 SoC. >>>>> This SoC contains four Cortex-A53 CPUs and other several IPs. >>>>> >>>>> Patches 1 to 10 provide the support for the clock controller, which >>>>> is similar to other Samsung SoCs. >>>>> >>>> You should explain here (and in DTS patches or the bindings) the >>>> hardware, that this is Samsung SoC. >>>> >>>> You could also explain the differences from Exynos and proposed >>>> handling of patches (because this is odd) >>>> >>>> Also, entire patchset has wrong and incomplete SoBs. Your SoB is >>>> missing everywhere, others have wrong order. >>>> >>>> Please read submitting patches first. >>>> >>> >>> This Custom SoC is owned by the Axis (OEM) and manufactured by the >>> Samsung (ODM). It has standard Samsung specific IP blocks. >> >> >> It is designed by Samsung. It is Samsung SoC. >> >> Anyway, don't explain to me, but in your patchset. > > Hi Krzysztof, > > Thank you for your review comments on the ARTPEC-8 platform patches. > I'd like to add more context about the ARTPEC-8 SoC to help clarify its > relationship with Exynos. > > Here are the key details about ARTPEC-8: > - Manufactured by Samsung Foundry > - SoC architecture is owned by Axis Communications > - On similar model as Tesla's FSD chip owned by Tesla and > manufactured and by Samsung > - IPs from both Samsung and Axis Communications > > Samsung-provided IPs: > - UART > - Ethernet (Vendor: Synopsys) > - Same IP has been integrated as integrated in FSD Chip > - SDIO > - SPI > - HSI2C > - I2S > - CMU (Clock Management Unit) > Follows same CMU HW architecture as Exynos SoC have > - Pinctrl (GPIO) > - PCIe (Vendor: Synopsys) > Though Exynos, FSD, ARTPEC have same DesignWare Controller, > the glue/wrapper layer around DWC Core has differences across > these SoCs. All manufactured by Samsung, but differences are there > in HW design and for different products. For the same reason PCIe patch > refactoring effort is being put by us [1] to streamline single Exynos driver > which can support all Samsung manufactured SoCs having DWC PCIe controller. > [1]: https://patchwork.ozlabs.org/project/linux-pci/patch/20250625165229.3458-2-shradha.t@samsung.com/ So entire base of the SoC is Samsung. > > Axis-provided IPs: > - VIP (Image Sensor Processing IP) > - VPP (Video Post Processing) > - GPU > - CDC (Video Encoder) > > As part of the upstreaming effort, Samsung and Coasia (DSP) team will work together > to upstream basic SoC support and Samsung IPs support. > The Axis team will be the primary maintainer for the ARTPEC-8 SoC codebase. Don't know what do you mean by "primary", but I want to be clear: this classifies as Samsung SoC, so I will be maintaining and overlooking it just like I maintain and take care about all Samsung SoCs. Otherwise you will be introducing errors and warnings or, in best case different style. And this already happened if I did not object! Also SAME strict DT compliance profile will be applied. (see more on that below) > > Given that ARTPEC-8 is a distinct SoC with its own set of IPs, we believe it's reasonable > to create a separate directory for it, similar to FSD. No. It was a mistake for FSD to keep it separate why? Because there is no single non-Samsung stuff there. I am afraid exactly the same will happen there. Based on above list of blocks this should be done like Google is done, so it goes as subdirectory of samsung (exynos). Can be called axis or artpec-8. To clarify: Only this SoC, not others which are not Samsung. > > We will remove Samsung and Coasia teams from the maintainers list in v2 and only > Axis team will be maintainer. A bit unexpected or rather: just use names of people who WILL be maintaining it. If this is Jesper and Lars, great. Just don't add entries just because they are managers. > > Maintainer list for previous generation of Axis chips (ARM based) is already present, > so this will be merged into that. Existing Artpec entry does not have tree mentioned, so if you choose above, you must not add the tree, since the tree is provided by Samsung SoC. OTOH, how are you going to add there strict DT compliance? Existing axis is not following this, but artpec-8, as a Samsung derivative, MUST FOLLOW strict DT compliance. And this should be clearly marked in maintainer entry, just like everywhere else. > > Please let us know if this explanation addresses your concerns. > We'll update the commit message and cover letter accordingly. Best regards, Krzysztof
> Subject: Re: [PATCH 00/16] Add support for the Axis ARTPEC-8 SoC > > On 06/08/2025 10:22, Pankaj Dubey wrote: > > > > > >> -----Original Message----- > >> From: Krzysztof Kozlowski <krzk@kernel.org> > >> Sent: Monday, July 21, 2025 12:10 PM > >> To: SeonGu Kang <ksk4725@coasia.com>; Jesper Nilsson > >> <jesper.nilsson@axis.com>; Michael Turquette > <mturquette@baylibre.com>; > >> Stephen Boyd <sboyd@kernel.org>; Rob Herring <robh@kernel.org>; > >> Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley > >> <conor+dt@kernel.org>; Sylwester Nawrocki > <s.nawrocki@samsung.com>; > >> Chanwoo Choi <cw00.choi@samsung.com>; Alim Akhtar > >> <alim.akhtar@samsung.com>; Linus Walleij <linus.walleij@linaro.org>; > >> Tomasz Figa <tomasz.figa@gmail.com>; Catalin Marinas > >> <catalin.marinas@arm.com>; Will Deacon <will@kernel.org>; Arnd > Bergmann > >> <arnd@arndb.de> > >> Cc: kenkim <kenkim@coasia.com>; Jongshin Park <pjsin865@coasia.com>; > >> GunWoo Kim <gwk1013@coasia.com>; HaGyeong Kim > >> <hgkim05@coasia.com>; GyoungBo Min <mingyoungbo@coasia.com>; > >> SungMin Park <smn1196@coasia.com>; Pankaj Dubey > >> <pankaj.dubey@samsung.com>; Shradha Todi > <shradha.t@samsung.com>; > >> Ravi Patel <ravi.patel@samsung.com>; Inbaraj E > <inbaraj.e@samsung.com>; > >> Swathi K S <swathi.ks@samsung.com>; Hrishikesh > >> <hrishikesh.d@samsung.com>; Dongjin Yang <dj76.yang@samsung.com>; > >> Sang Min Kim <hypmean.kim@samsung.com>; linux- > kernel@vger.kernel.org; > >> linux-arm-kernel@lists.infradead.org; linux-samsung- > soc@vger.kernel.org; > >> linux-arm-kernel@axis.com; linux-clk@vger.kernel.org; > >> devicetree@vger.kernel.org; linux-gpio@vger.kernel.org; > soc@lists.linux.dev > >> Subject: Re: [PATCH 00/16] Add support for the Axis ARTPEC-8 SoC > >> > >> On 21/07/2025 06:50, SeonGu Kang wrote: > >>> 2025-07-10 (목), 09:07 +0200, Krzysztof Kozlowski: > >>>> On 10/07/2025 02:20, ksk4725@coasia.com wrote: > >>>>> From: SeonGu Kang <ksk4725@coasia.com> > >>>>> > >>>>> Add basic support for the Axis ARTPEC-8 SoC. > >>>>> This SoC contains four Cortex-A53 CPUs and other several IPs. > >>>>> > >>>>> Patches 1 to 10 provide the support for the clock controller, which > >>>>> is similar to other Samsung SoCs. > >>>>> > >>>> You should explain here (and in DTS patches or the bindings) the > >>>> hardware, that this is Samsung SoC. > >>>> > >>>> You could also explain the differences from Exynos and proposed > >>>> handling of patches (because this is odd) > >>>> > >>>> Also, entire patchset has wrong and incomplete SoBs. Your SoB is > >>>> missing everywhere, others have wrong order. > >>>> > >>>> Please read submitting patches first. > >>>> > >>> > >>> This Custom SoC is owned by the Axis (OEM) and manufactured by the > >>> Samsung (ODM). It has standard Samsung specific IP blocks. > >> > >> > >> It is designed by Samsung. It is Samsung SoC. > >> > >> Anyway, don't explain to me, but in your patchset. > > > > Hi Krzysztof, > > > > Thank you for your review comments on the ARTPEC-8 platform patches. > > I'd like to add more context about the ARTPEC-8 SoC to help clarify its > > relationship with Exynos. > > > > Here are the key details about ARTPEC-8: > > - Manufactured by Samsung Foundry > > - SoC architecture is owned by Axis Communications > > - On similar model as Tesla's FSD chip owned by Tesla and > > manufactured and by Samsung > > - IPs from both Samsung and Axis Communications > > > > Samsung-provided IPs: > > - UART > > - Ethernet (Vendor: Synopsys) > > - Same IP has been integrated as integrated in FSD Chip > > - SDIO > > - SPI > > - HSI2C > > - I2S > > - CMU (Clock Management Unit) > > Follows same CMU HW architecture as Exynos SoC have > > - Pinctrl (GPIO) > > - PCIe (Vendor: Synopsys) > > Though Exynos, FSD, ARTPEC have same DesignWare Controller, > > the glue/wrapper layer around DWC Core has differences across > > these SoCs. All manufactured by Samsung, but differences are there > > in HW design and for different products. For the same reason PCIe > patch > > refactoring effort is being put by us [1] to streamline single Exynos > driver > > which can support all Samsung manufactured SoCs having DWC PCIe > controller. > > [1]: https://protect2.fireeye.com/v1/url?k=8a8233e4-d5190ae8- > 8a83b8ab-000babff3563-7bd7c9980190e0e8&q=1&e=2e04cfd4-33cf-4f00- > a970- > 7dcbf1d780ec&u=https%3A%2F%2Fpatchwork.ozlabs.org%2Fproject%2Flinu > x-pci%2Fpatch%2F20250625165229.3458-2-shradha.t%40samsung.com%2F > > So entire base of the SoC is Samsung. Yes, if we are saying this based on the core IPs (CMU, Pinctrl) and the fact that it is manufactured by Samsung. > > > > > Axis-provided IPs: > > - VIP (Image Sensor Processing IP) > > - VPP (Video Post Processing) > > - GPU > > - CDC (Video Encoder) > > > > As part of the upstreaming effort, Samsung and Coasia (DSP) team will > work together > > to upstream basic SoC support and Samsung IPs support. > > The Axis team will be the primary maintainer for the ARTPEC-8 SoC > codebase. > > Don't know what do you mean by "primary", but I want to be clear: this > classifies as Samsung SoC, so I will be maintaining and overlooking it > just like I maintain and take care about all Samsung SoCs. Otherwise you > will be introducing errors and warnings or, in best case different > style. And this already happened if I did not object! > By "primary" I mean as it is product of Axis, and only Axis will be having access to this SoCs in future they will be responsible to maintain it and add support for. > Also SAME strict DT compliance profile will be applied. (see more on > that below) > > > > > Given that ARTPEC-8 is a distinct SoC with its own set of IPs, we believe it's > reasonable > > to create a separate directory for it, similar to FSD. > > No. It was a mistake for FSD to keep it separate why? Because there is > no single non-Samsung stuff there. I am afraid exactly the same will > happen there. > I am not sure, why you are saying this as a mistake, in case next version of FSD or ARTPEC is manufactured (ODM) by another vendor in that case, won't it create problems? For example ARTPEC-6/7 (ARM based) have their own directories as "arch/arm/boot/dts/axis/" These were not Samsung (ODM) manufactures SoCs. But ARTPEC-8/9 (ARM64) based SoCs are samsung manufactured. What if the next version say ARTPEC-10 is not samsung manufactured, so different version of products (SoCs) from same vendor (OEM), in this case Axis, will have code in separate directories and with different maintainers? > Based on above list of blocks this should be done like Google is done, > so it goes as subdirectory of samsung (exynos). Can be called axis or > artpec-8. I will suggest to keep axis, knowing the fact that sooner after artpec-8 patches gets approved and merged we have plan to upstream artpec-9 (ARM64, Samsung manufactured) as well. > > To clarify: Only this SoC, not others which are not Samsung. > > > > > We will remove Samsung and Coasia teams from the maintainers list in v2 > and only > > Axis team will be maintainer. > > A bit unexpected or rather: just use names of people who WILL be > maintaining it. If this is Jesper and Lars, great. Just don't add > entries just because they are managers. AFAIK, Jesper will be taking care. > > > > > Maintainer list for previous generation of Axis chips (ARM based) is already > present, > > so this will be merged into that. > > Existing Artpec entry does not have tree mentioned, so if you choose > above, you must not add the tree, since the tree is provided by Samsung SoC. > OK > OTOH, how are you going to add there strict DT compliance? Existing axis > is not following this, but artpec-8, as a Samsung derivative, MUST > FOLLOW strict DT compliance. And this should be clearly marked in > maintainer entry, just like everywhere else. > As I said this is tricky situation, though artpec-8 is derivative of samsung, we can't confirm if future versions (> 9) will be samsung derivative. But this would be case for all such custom ASIC manufactured by samsung, so I would like to understand how this will be handled? > > > > > Please let us know if this explanation addresses your concerns. > > We'll update the commit message and cover letter accordingly. > > > Best regards, > Krzysztof
On 06/08/2025 11:05, Pankaj Dubey wrote: > >> Also SAME strict DT compliance profile will be applied. (see more on >> that below) >> >>> >>> Given that ARTPEC-8 is a distinct SoC with its own set of IPs, we believe it's >> reasonable >>> to create a separate directory for it, similar to FSD. >> >> No. It was a mistake for FSD to keep it separate why? Because there is >> no single non-Samsung stuff there. I am afraid exactly the same will >> happen there. >> > > I am not sure, why you are saying this as a mistake, in case next version of FSD My mistake that I agreed on that, based on promise that "there will be non Samsung stuff" and that "non Samsung stuff" never happened. > or ARTPEC is manufactured (ODM) by another vendor in that case, won't it > create problems? No problems here. Non-Samsung Artpec/Axis soc will not go there. It will go the top-level axis directory, just like artpec-6 > > For example ARTPEC-6/7 (ARM based) have their own directories as "arch/arm/boot/dts/axis/" > These were not Samsung (ODM) manufactures SoCs. > > But ARTPEC-8/9 (ARM64) based SoCs are samsung manufactured. What if the next version say > ARTPEC-10 is not samsung manufactured, so different version of products (SoCs) from > same vendor (OEM), in this case Axis, will have code in separate directories and with different maintainers? It will be the same with Google Pixel for whatever they decide in the future. dts/exynos/google/ + dts/google/. I know that this is not ideal, but for me grouping samsung stuff together is far more important, because there is much, much more to share between two SoCs designed by Samsung, than Axis-9 and future non-Samsung Axis-10. And I have `git grep` as argument: git grep compatible -- arch/arm64/boot/dts/tesla/ and point me to any Tesla IP. Zero results. > >> Based on above list of blocks this should be done like Google is done, >> so it goes as subdirectory of samsung (exynos). Can be called axis or >> artpec-8. > > I will suggest to keep axis, knowing the fact that sooner after artpec-8 patches gets approved and merged > we have plan to upstream artpec-9 (ARM64, Samsung manufactured) as well. > >> >> To clarify: Only this SoC, not others which are not Samsung. >> >>> >>> We will remove Samsung and Coasia teams from the maintainers list in v2 >> and only >>> Axis team will be maintainer. >> >> A bit unexpected or rather: just use names of people who WILL be >> maintaining it. If this is Jesper and Lars, great. Just don't add >> entries just because they are managers. > > AFAIK, Jesper will be taking care. > >> >>> >>> Maintainer list for previous generation of Axis chips (ARM based) is already >> present, >>> so this will be merged into that. >> >> Existing Artpec entry does not have tree mentioned, so if you choose >> above, you must not add the tree, since the tree is provided by Samsung SoC. >> > > OK > >> OTOH, how are you going to add there strict DT compliance? Existing axis >> is not following this, but artpec-8, as a Samsung derivative, MUST >> FOLLOW strict DT compliance. And this should be clearly marked in >> maintainer entry, just like everywhere else. >> > > As I said this is tricky situation, though artpec-8 is derivative of samsung, we can't confirm > if future versions (> 9) will be samsung derivative. > > But this would be case for all such custom ASIC manufactured by samsung, so I would like to > understand how this will be handled? I suggest to do the same as Google and when I say Google in this email, I mean Pixel/GS101. Google was easier because there was no prior entry and Axis has, so you will have two Axis entries. But I don't see how we can add clean-dts profiles to the existing Axis entry, if you decide to include Artpec-8 in that one. Best regards, Krzysztof
> Subject: Re: [PATCH 00/16] Add support for the Axis ARTPEC-8 SoC > > On 06/08/2025 11:05, Pankaj Dubey wrote: > > > >> Also SAME strict DT compliance profile will be applied. (see more on > >> that below) > >> > >>> > >>> Given that ARTPEC-8 is a distinct SoC with its own set of IPs, we believe > it's > >> reasonable > >>> to create a separate directory for it, similar to FSD. > >> > >> No. It was a mistake for FSD to keep it separate why? Because there is > >> no single non-Samsung stuff there. I am afraid exactly the same will > >> happen there. > >> > > > > I am not sure, why you are saying this as a mistake, in case next version of > FSD > > > My mistake that I agreed on that, based on promise that "there will be > non Samsung stuff" and that "non Samsung stuff" never happened. > I am not authorized to comment on FSD's non Samsung stuff at this moment. But I got your point. > > or ARTPEC is manufactured (ODM) by another vendor in that case, won't it > > create problems? > > > No problems here. Non-Samsung Artpec/Axis soc will not go there. It will > go the top-level axis directory, just like artpec-6 > Okay, understood. I assume Axis team will be fine with this approach. Let me align with them internally and address all the review comments in v2. > > > > > For example ARTPEC-6/7 (ARM based) have their own directories as > "arch/arm/boot/dts/axis/" > > These were not Samsung (ODM) manufactures SoCs. > > > > But ARTPEC-8/9 (ARM64) based SoCs are samsung manufactured. What if > the next version say > > ARTPEC-10 is not samsung manufactured, so different version of products > (SoCs) from > > same vendor (OEM), in this case Axis, will have code in separate directories > and with different maintainers? > > It will be the same with Google Pixel for whatever they decide in the > future. dts/exynos/google/ + dts/google/. > > I know that this is not ideal, but for me grouping samsung stuff > together is far more important, because there is much, much more to > share between two SoCs designed by Samsung, than Axis-9 and future > non-Samsung Axis-10. And I have `git grep` as argument: > git grep compatible -- arch/arm64/boot/dts/tesla/ > > and point me to any Tesla IP. Zero results. > > > > > >> Based on above list of blocks this should be done like Google is done, > >> so it goes as subdirectory of samsung (exynos). Can be called axis or > >> artpec-8. > > > > I will suggest to keep axis, knowing the fact that sooner after artpec-8 > patches gets approved and merged > > we have plan to upstream artpec-9 (ARM64, Samsung manufactured) as > well. > > > >> > >> To clarify: Only this SoC, not others which are not Samsung. > >> > >>> > >>> We will remove Samsung and Coasia teams from the maintainers list in > v2 > >> and only > >>> Axis team will be maintainer. > >> > >> A bit unexpected or rather: just use names of people who WILL be > >> maintaining it. If this is Jesper and Lars, great. Just don't add > >> entries just because they are managers. > > > > AFAIK, Jesper will be taking care. > > > >> > >>> > >>> Maintainer list for previous generation of Axis chips (ARM based) is > already > >> present, > >>> so this will be merged into that. > >> > >> Existing Artpec entry does not have tree mentioned, so if you choose > >> above, you must not add the tree, since the tree is provided by Samsung > SoC. > >> > > > > OK > > > >> OTOH, how are you going to add there strict DT compliance? Existing axis > >> is not following this, but artpec-8, as a Samsung derivative, MUST > >> FOLLOW strict DT compliance. And this should be clearly marked in > >> maintainer entry, just like everywhere else. > >> > > > > As I said this is tricky situation, though artpec-8 is derivative of samsung, we > can't confirm > > if future versions (> 9) will be samsung derivative. > > > > But this would be case for all such custom ASIC manufactured by samsung, > so I would like to > > understand how this will be handled? > > > I suggest to do the same as Google and when I say Google in this email, > I mean Pixel/GS101. Google was easier because there was no prior entry > and Axis has, so you will have two Axis entries. But I don't see how we > can add clean-dts profiles to the existing Axis entry, if you decide to > include Artpec-8 in that one. > Okay we will have separate dts profile aligned with Exynos DT compliance for ARM64 based Axis SoCs which are manufactured by Samsung at this moment. > > Best regards, > Krzysztof
On Thu, Aug 07, 2025 at 12:26:27PM +0530, Pankaj Dubey wrote > > Subject: Re: [PATCH 00/16] Add support for the Axis ARTPEC-8 SoC > > On 06/08/2025 11:05, Pankaj Dubey wrote: > > > or ARTPEC is manufactured (ODM) by another vendor in that case, won't it > > > create problems? > > > > > > No problems here. Non-Samsung Artpec/Axis soc will not go there. It will > > go the top-level axis directory, just like artpec-6 > > > > Okay, understood. I assume Axis team will be fine with this approach. > Let me align with them internally and address all the review comments in v2. Just for the record, Axis has no problem in having the ARTPEC-8 / ARTPEC-9 in the Samsung directory, while the older ARTPEC-6 / ARTPEC-7 and any other future chips will be separate. /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nilsson@axis.com
On Wed, Aug 6, 2025, at 11:23, Krzysztof Kozlowski wrote: > On 06/08/2025 11:05, Pankaj Dubey wrote: >> >> or ARTPEC is manufactured (ODM) by another vendor in that case, won't it >> create problems? > > > No problems here. Non-Samsung Artpec/Axis soc will not go there. It will > go the top-level axis directory, just like artpec-6 Agreed. We did have a case where something gradually changed instead of changing ODMs entirely: Apple A4 was mostly an Exynos-family chip but A18 is not. If Axis turns into the next Apple and ARTPEC-23 is far enough removed from ARTPEC-9 to no longer fit into the same family as Exynos/Tensor/FSD, we can still reconsider the decision in a decade. Arnd
© 2016 - 2025 Red Hat, Inc.