From: Yao Zi <me@ziyao.cc>
To: wjjsn <wjjsn@qq.com>, Huacai Chen <chenhuacai@kernel.org>
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
kernel@xen0n.name, devicetree@vger.kernel.org,
loongarch@lists.linux.dev, linux-kernel@vger.kernel.org,
wjjsn <2858482031@qq.com>
Subject: Re: [PATCH v5 0/2] Add Loongson-2K0300 processor support
Date: Mon, 23 Mar 2026 02:42:43 +0000 [thread overview]
Message-ID: <acCoo_ZrTmZGZH5d@pie> (raw)
In-Reply-To: <tencent_CA7176E8823B957F1AEB15254D17904D5505@qq.com>
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@ziyao.cc> 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
next prev parent reply other threads:[~2026-03-23 2:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-22 7:13 [PATCH v5 0/2] Add Loongson-2K0300 processor support wjjsn
2026-03-22 12:35 ` Yao Zi
2026-03-22 13:15 ` Huacai Chen
2026-03-22 16:33 ` wjjsn
2026-03-23 2:42 ` Yao Zi [this message]
2026-03-24 15:09 ` wjjsn
2026-03-24 15:23 ` wjjsn
2026-03-24 16:55 ` Yao Zi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acCoo_ZrTmZGZH5d@pie \
--to=me@ziyao.cc \
--cc=2858482031@qq.com \
--cc=chenhuacai@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel@xen0n.name \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=robh@kernel.org \
--cc=wjjsn@qq.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox