On Fri, 6 Aug 2021 at 15:48, Krzysztof Kozlowski
[off-list ref] wrote:

On 06/08/2021 14:32, Krzysztof Kozlowski wrote:

quoted

On 06/08/2021 14:07, Sam Protsenko wrote:

quoted

On Fri, 6 Aug 2021 at 10:49, Krzysztof Kozlowski
[off-list ref] wrote:

quoted

On 06/08/2021 01:06, Sam Protsenko wrote:

quoted

On Sat, 31 Jul 2021 at 12:03, Krzysztof Kozlowski
[off-list ref] wrote:

quoted

quoted

This patch adds minimal SoC support. Particular board device tree files
can include exynos850.dtsi file to get SoC related nodes, and then
reference those nodes further as needed.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
---
 .../boot/dts/exynos/exynos850-pinctrl.dtsi    | 782 ++++++++++++++++++
 arch/arm64/boot/dts/exynos/exynos850-usi.dtsi |  30 +
 arch/arm64/boot/dts/exynos/exynos850.dtsi     | 245 ++++++

Not buildable. Missing Makefile, missing DTS. Please submit with initial
DTS, otherwise no one is able to verify it even compiles.

This device is not available for purchase yet. I'll send the patch for
board dts once it's announced. I can do all the testing for now, if
you have any specific requests. Would it be possible for us to review
and apply only SoC support for now? Will send v2 soon...

What you propose is equal to adding a driver (C source code) without
ability to compile it. What's the point of having it in the kernel? It's
unverifiable, unbuildable and unusable.

Yes, I understand. That's adding code with no users, and it's not a
good practice.

quoted

We can review the DTSI however merging has to be with a DTS. Usually the
SoC vendor adds first an evalkit (e.g. SMDK board). Maybe you have one
for Exynos850? Otherwise if you cannot disclose the actual board, the
DTSI will have to wait. You can submit drivers, though.

Sure, let's go this way. I'll send v2 soon. Improving patches and
having Reviewed-by tag for those would good enough for me at this
point. I'll continue to prepare another Exynos850 related patches
until the actual board is announced, like proper clock driver, reset,
MMC, etc. Is it ok if I send those for a review too (so I can fix all
issues ahead)?

Sure, prepare all necessary drivers earlier. I suspect clocks will be a
real pain because of significant changes modeled in vendor kernel. I
remember Paweł Chmiel (+Cc) was doing something for these:
https://github.com/PabloPL/linux/tree/exynos7420

I mentioned before - you should also modify the chipid driver. Check
also other drivers in drivers/soc/samsung, although some are needed only
for suspend&resume.

Yes, in due course... There won't be much problems with chip-id
driver. But pretty much all platform drivers depend on clk, and that
one I'm afraid I'll have to implement from scratch. Will take me a
while, as vendor's codebase for clk driver is huge and depend on
another huge non-upstreamable abstraction layer framework they have,
and also they have kind of strange home brewed composite clocks...
Anyway, that's what I'm going to look into next.

Btw, I just sent v2 :)

You can also take a look at Exynos8895 efforts:
https://github.com/ivoszbg/linux/commits/for-upstream/exynos8895

Since knowledge, datasheets and efforts are quite spread all over, I
keep track of some work here:
https://exynos.wiki.kernel.org/community

Thanks, Krzysztof! I'm sure that info will help a lot with further
work, like clock driver.

Best regards,
Krzysztof