W dniu 06.08.2021 o 14:32, Krzysztof Kozlowski pisze:
On 06/08/2021 14:07, Sam Protsenko wrote:
On Fri, 6 Aug 2021 at 10:49, Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxxxxx> wrote:
On 06/08/2021 01:06, Sam Protsenko wrote:
On Sat, 31 Jul 2021 at 12:03, Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxxxxx> wrote:
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@xxxxxxxxxx>
---
.../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.
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.
BTW, Paweł,
How is your Exynos7420 progress? :)
Hi
Sadly i had to postpone it for a while. Maybe will have more time now to
get back to it.
About clock driver. In vendor sources there is clk driver with something
called virtual clocks (different than real ones). That driver calls
another driver called pwrcal, responsible for real manipulation of
clocks in hardware. This one has info about real clocks and also
additional info about for example rate for some of them, which is read
from binary from memory, by another driver called ect_parser in case of
devices at which i did looked.
In my case i was able to find some more info about real clocks there -
for example register names and offsets
https://github.com/krzk/linux-vendor-backup/blob/mokee/android-3.18-samsung-galaxy-s7-sm-g930f-exynos8890/drivers/soc/samsung/pwrcal/S5E8890/S5E8890-cmusfr.h
and some clocks hierarchy info inside
https://github.com/krzk/linux-vendor-backup/blob/mokee/android-3.18-samsung-galaxy-s7-sm-g930f-exynos8890/drivers/soc/samsung/pwrcal/S5E8890/S5E8890-cmu.c
but there was still many info missing.
Finding a way (which could be applied to other Exynos SOC) to "convert"
or use that vendor code and turn it into mainline driver, especially
without TRM which is not available for all/most of them, would be great.
I'm wondering if Exynos850 device has the same issue as on 7420 (and
probably 8890/7578 and maybe also other 64 bit Exynos devices) - broken
firmware. For example i had to specify in dts timer clock frequency, on
few devices there is also a problem with timer registers not properly
configured by FW, which probably won't be fixed by vendor and patches
with workaround for it in kernel were rejected :/.
And should I maybe add RFC tag for those?
No need. Drivers can be merged before DTS users.
Best regards,
Krzysztof
