Hi,
On 2023/4/4 22:10, Emil Velikov wrote:
val = lsdc_crtc_rreg32(ldev, LSDC_CRTC0_CFG_REG, index);/* clear old dma step settings */val &= ~CFG_DMA_STEP_MASK;if (descp->chip == CHIP_LS7A2000) {/** Using large dma step as much as possible,* for improve hardware DMA efficiency.*/if (width_in_bytes % 256 == 0)val |= LSDC_DMA_STEP_256_BYTES;else if (width_in_bytes % 128 == 0)val |= LSDC_DMA_STEP_128_BYTES;else if (width_in_bytes % 64 == 0)val |= LSDC_DMA_STEP_64_BYTES;else /* width_in_bytes % 32 == 0 */val |= LSDC_DMA_STEP_32_BYTES;}clk_func->update(pixpll, &priv_state->pparms);Without knowing the hardware, the clk_func abstraction seems quite arbitrary and unnecessary. It should be introduced when there is a use-case for it.
The clk_func is necessary, clk_func->update() will eventually call ls7a1000_pixpll_param_update()
to generate pixel clock frequency required by the display device. There is a abstract because different
bridges chip/SoC variants has the different register to operate, either because the register offset changed
or the arrangement of specific bits field changed.
For the point view of the hardware, the PLL hardware belong to the bridge chip.
There is a clock tree which wrangler all of the PLL hardware, sub-device may partially share the hardware PLL.
The abstraction is used to suppress hardware variants which may change over time.
For ls7a1000, there is user manual document about the clock tree and PLL, see[1][2][3]
[1] https://loongson.github.io/LoongArch-Documentation/Loongson-7A1000-usermanua... [2] https://loongson.github.io/LoongArch-Documentation/Loongson-7A1000-usermanua... [3] https://loongson.github.io/LoongArch-Documentation/Loongson-7A1000-usermanua...