Re: [PATCH v5 0/2] Add Loongson-2K0300 processor support

[Yao Zi]

On Mon, Mar 23, 2026 at 12:33:31AM +0800, wjjsn wrote:
> On 3/22/26 21:15, Huacai Chen wrote:
> > On Sun, Mar 22, 2026 at 8:36 PM Yao Zi <me@xxxxxxxx> wrote:
> > > Also, previously Huacai expressed preference on delaying devicetree
> > > changes until basic drivers are ready[4], so anyway we should probably
> > > get driver patches merged first.
> > Yes, I confirm that.
> > 
> > Huacai
> > 
> 
> Hi Huacai and Yao,
> 
> I noticed that:
> 1. The current clock driver in mainline has some problems.
>   The pll_ddr is lower than the user_manual,

I'm not sure what do you mean. Do you observe lower clock frequency of
pll_ddr than the frequency specified in TRM (1GHz)? And if so, how?

clk-loongson2 doesn't have the ability to reclock hardware, but only
read out the frequency. PLL frequencies are all up to the bootloader.
So as long as you could confirm the values returned by recalc_rate()
match the register settings, there's nothing wrong in the clock driver.

Reclocking functionality could be introduced later. But even with
reclocking code, I doubt whether the DDR clock could be reclocked
at runtime since it supplies the memory controller.

>   the clk_apb_gate will
>   turn off by kernel while booting,though 16100000.serial is using

This is unlikely an issue in the clock driver, but rather the consumer
is doing something wrong, though I haven't seen similar issues when
working on the clock driver.

Please try booting the kernel with clk_ignore_unused, and check
/sys/kernel/debug/clk/clk_summary to see whether the serial correctly
acquires the apb gate clock. If not, one (and the most possible) reason
is both clock-frequency and clocks properties are specified in its
devicetree node, where 8250 driver would ignore the latter.

> 2. eiointc support for 2k0300 is missing.

This is expected. IOCSRs found on 2K0300 have a quite different layout
than previous generations of Loongson SoCs, and EIOINTC is in fact a
device located in IOCSR addressing space. We need to come up with a
better way to model the IOCSRs in devicetree, and it hasn't been done
yet.

> Is there any WIP (Work In Progress) tree I can follow?
> I'm happy to help with the development or testing.

Sorry there isn't one for now. I'm currently out of my lab, and could
only get things updated this weekend. Sorry for the inconvenience.

Regards,
Yao Zi