[PATCH 1/4] dt-bindings: reset: thead,th1520-reset: Add controllers for more subsys

Philipp Zabel p.zabel at pengutronix.de
Tue Sep 2 06:57:02 PDT 2025


On Di, 2025-09-02 at 15:44 +0200, Krzysztof Kozlowski wrote:
> On 02/09/2025 11:04, Yao Zi wrote:
> > On Tue, Sep 02, 2025 at 10:27:53AM +0200, Krzysztof Kozlowski wrote:
> > > On Mon, Sep 01, 2025 at 04:23:17AM +0000, Yao Zi wrote:
> > > > +/* VO Subsystem */
> > > >  #define TH1520_RESET_ID_GPU		0
> > > >  #define TH1520_RESET_ID_GPU_CLKGEN	1
> > > > -#define TH1520_RESET_ID_NPU		2
> > > > -#define TH1520_RESET_ID_WDT0		3
> > > > -#define TH1520_RESET_ID_WDT1		4
> > > 
> > > This is ABI break and deserves explanation and its own patchset.
> > 
> > The registers in control of TH1520_RESET_ID_{NPU,WDT0,WDT1} don't belong
> > to the VO reset controller (documented as "thead,th1520-reset"), and
> > thus cannot be implemented by it. They're in fact AP subsystem resets,
> > which gets supported in Linux with this series.
> > 
> > Is it okay for you to separate a patch to delete these wrong IDs and add
> > them back for the AP reset controller latter? Anyway, I should have
> > provided more information about these three resets. Thanks for catching
> > this.
> 
> So feels like separate patch dropping these resets with above explanation.

They happen to be reintroduced with exactly the same values, just for
the AP subsystem reset controller:

+/* AP Subsystem */
+#define TH1520_RESET_ID_BROM			0
+#define TH1520_RESET_ID_C910_TOP		1
+#define TH1520_RESET_ID_NPU			2
+#define TH1520_RESET_ID_WDT0			3
+#define TH1520_RESET_ID_WDT1			4
[...]
+/* VO Subsystem */
 #define TH1520_RESET_ID_GPU		0
 #define TH1520_RESET_ID_GPU_CLKGEN	1
-#define TH1520_RESET_ID_NPU		2
-#define TH1520_RESET_ID_WDT0		3
-#define TH1520_RESET_ID_WDT1		4

regards
Philipp



More information about the linux-riscv mailing list