Page MenuHomeFreeBSD

arm64: NXP add LS1088a clockgen support
ClosedPublic

Authored by bz on Jun 28 2022, 12:08 AM.
Tags
None
Referenced Files
F103265064: D35617.diff
Fri, Nov 22, 7:57 PM
Unknown Object (File)
Thu, Nov 14, 1:19 PM
Unknown Object (File)
Wed, Nov 13, 8:05 PM
Unknown Object (File)
Oct 10 2024, 8:05 PM
Unknown Object (File)
Sep 28 2024, 12:56 PM
Unknown Object (File)
Sep 27 2024, 9:28 PM
Unknown Object (File)
Sep 27 2024, 12:33 AM
Unknown Object (File)
Sep 24 2024, 4:29 AM

Details

Summary

Add a driver for NXP LS1088a clockgen support which passes
configuration information to QorIQ clockgen class.
The implementaiton started off from a copy of ls1028 support and was
adjusted accordingly.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 46143
Build 43032: arc lint + arc unit

Event Timeline

bz requested review of this revision.Jun 28 2022, 12:08 AM

I found one minor issue. Even though it's under HWACCEL3 ifdef, I think it should be fixed.

sys/arm64/qoriq/clk/ls1088a_clkgen.c
169–176

According to the doc, Cluster PLL2 divide-by-2 is selected when the value in HWA3CSR is equal to 6, not 2, so ls1088a_cga_pll2_div2 should be placed at ls1088a_hwaccel3_parent_names[6]. I think that ls1088a_cga_pll2_div3 should be the next element in the array. I am not 100% sure though, as it seems that there is an error in the document itself (both divide-by-2 and divide-by-3 are selected by 0110 according to the doc and that's impossible)

bz marked an inline comment as done.

Fix ls1088a_hwaccel3_parent_names using the correct offsets
in the array for pll2_div[23] as pointed out by dgr.

sys/arm64/qoriq/clk/ls1088a_clkgen.c
169–176

I see the same in my version for pll[12]_div2 and pll[12]_div3 for HWA[123]CSR in 4.4.2.4 Fields. And Reserved starting at 111 rather than at 1000.
I'll update this one; good catch!

How is '#ifdef HWACCEL3' compatible with the generic kernel and why do we need it at all?

In D35617#809144, @mmel wrote:

How is '#ifdef HWACCEL3' compatible with the generic kernel and why do we need it at all?

It's simply there to disable the code for now; while it's in the spec, I could not see anything using it. I can spell it `#ifdef __notyet__` if you prefer that.

And why didn't you leave it enabled? IMHO all HWACCEL blocks look the same, so the risk of a possible error is minimal.

Enable HWACCEL3 as well as suggested by @mmel.

This revision is now accepted and ready to land.Jul 1 2022, 2:52 PM
This revision was automatically updated to reflect the committed changes.