From: wjjsn <wjjsn@qq.com>
To: Yao Zi <me@ziyao.cc>, 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: Tue, 24 Mar 2026 23:09:16 +0800 [thread overview]
Message-ID: <tencent_414FBFBEE2A4510232AB52CE665C04A6C20A@qq.com> (raw)
In-Reply-To: <acCoo_ZrTmZGZH5d@pie>
On 3/23/26 10:42, Yao Zi wrote:
> On Mon, Mar 23, 2026 at 12:33:31AM +0800, wjjsn wrote:
>> On 3/22/26 21:15, Huacai Chen wrote:
>> 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.
I observed that 'clk_ddr_div' operates at 800MHz instead of the 1GHz
specified in the manual, and 'clk_dev_div' operates at 100MHz instead of
the 200MHz specified in the manual. However, you mentioned that these
settings are determined by the bootloader, so everything now makes sense
>> 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.
>
When I use 'clocks = <&clk LS2K0300_CLK_DEV_DIV>;', the system log
gets stuck at the message about closing unused clocks, and there are no
further logs. It seems like the clock for the serial port is being
closed. However, if I set the parameter to not close unused clocks as a
startup parameter, the serial port can continue to be used. If I use
'clocks = <&clk LS2K0300_CLK_APB_GATE>;', then the clock for the serial
port is not closed and can start normally. I have not specified the
clock frequency in the device tree
>> 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.
Okay, if you have a public repository, please let me know. If I have
time, I would be happy to help with testing
Regards,
wjjsn
next prev parent reply other threads:[~2026-03-24 15:09 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
2026-03-24 15:09 ` wjjsn [this message]
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=tencent_414FBFBEE2A4510232AB52CE665C04A6C20A@qq.com \
--to=wjjsn@qq.com \
--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=me@ziyao.cc \
--cc=robh@kernel.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).