On Tue, 21 Nov 2023 at 10:32, Sam Protsenko semen.protsenko@linaro.org wrote:
On Mon, Nov 13, 2023 at 12:01 PM Simon Glass sjg@chromium.org wrote:
The 'port_id' seems to be needed for ARCH_EXYNOS4 boards. Because Exynos4 doesn't have proper DM clocks, it uses 'id' property to get corresponding UART clock frequency from its mach code.
Here is what's happening in the serial driver in case of Exynos4:
- get_uart_clk(port_id) is called
- which in turn calls exynos4_get_uart_clk(port_id)
- which uses "port_id" value to read corresponding bits of of
CLK_SRC_PERIL0 register 4. those bits are used to get corresponding PLL clock's frequency 5. which is in turn used to calculate UART clock rate 6. calculated rate is returned by get_uart_clk() to serial driver
So I don't see any *easy* way we can get rid of that id property.
The proper way of doing that would require converting Exynos4 clock code to CCF (enabling CONFIG_CLK_EXYNOS). Which of course also means implementing clocks in dts, akin to kernel's exynos4.dtsi. Then it'll be possible to get rid of 'id' property.
That sounds good!
Maybe I'm missing something, please let me know.
An easy way in the meantime would be to look at the compatible / reg property, e.g. here is a sketch:
static int get_id(ofnode node) { ulong addr = (ulong)plat->reg; if (ofnode_device_is_compatible(node, "samsung,exynos4210-uart")) { return (addr >> 16) & 0xf; ...
reg = <0x13800000 0x3c>; id = <0>; };
serail_1: serial@13810000 { compatible = "samsung,exynos4210-uart"; reg = <0x13810000 0x3c>; id = <1>; };
serial_2: serial@13820000 { compatible = "samsung,exynos4210-uart"; reg = <0x13820000 0x3c>; id = <2>; };
serial_3: serial@13830000 { compatible = "samsung,exynos4210-uart"; reg = <0x13830000 0x3c>; id = <3>; };
serial_4: serial@13840000 { compatible = "samsung,exynos4210-uart"; reg = <0x13840000 0x3c>; id = <4>;
To be honest, I'm a bit of busy right now working on U-Boot port for a new Exynos dev board, which I want to finalize and upstream ASAP. Do you think it's possible to take this one as is for now? At least it fixes one issue (fdtdec API and global data pointer).
Thanks!
Yes, OK with me.
Reviewed-by: Simon Glass sjg@chromium.org