[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