[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aJrTq775sXTrsepl@x1>
Date: Mon, 11 Aug 2025 22:39:55 -0700
From: Drew Fustini <fustini@...nel.org>
To: Michal Wilczynski <m.wilczynski@...sung.com>
Cc: Guo Ren <guoren@...nel.org>, Fu Wei <wefu@...hat.com>,
Philipp Zabel <p.zabel@...gutronix.de>,
Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, Icenowy Zheng <uwu@...nowy.me>
Subject: Re: [PATCH] reset: thead: Scope TH1520 reset driver to VO subsystem
On Sun, Aug 10, 2025 at 11:14:19PM +0200, Michal Wilczynski wrote:
> The reset controller driver for the TH1520 was using the generic
> compatible string "thead,th1520-reset". However, the current
> implementation only manages the resets for the Video Output (VO)
> subsystem.
Looking at Section 5.4 on Page 451 of the TH1520 System User Manual [1],
it does seem like we would ultimately need 6 separate nodes for reset
controllers:
0xFF_EF01_4000: AP_SUBSYS
0xFF_EC02_C000: MISC_SUBSYS
0xFF_E404_0000: VI_SUBSYS
0xFF_EF52_8000: VO_SUBSYS
0xFF_ECC3_0000: VP_SUBSYS
0xFF_EF04_0000: DSP_SUBSYS
Maybe we should take this opportunity to document the bindings for all
the resets that the REE (e.g. Linux) can control?
It seemed like that was overkill for the 2 resets needed for the GPU,
but, as Krzysztof noted in this thread, problems arise when bindings are
introduced that are not complete.
Thanks,
Drew
[1] https://git.beagleboard.org/beaglev-ahead/beaglev-ahead/-/blob/main/docs/TH1520%20System%20User%20Manual.pdf
Powered by blists - more mailing lists