| Message ID | 20241223125553.3527812-1-m.wilczynski@samsung.com |
|---|---|
| Headers | show |
| Series | Enable drm/imagination BXM-4-64 Support for LicheePi 4A | expand |
On 23/12/2024 13:55, Michal Wilczynski wrote: > The kernel communicates with the E902 core through the mailbox > transport using AON firmware protocol. Add dt-bindings to document it > the dt node. > > Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> > --- > .../bindings/firmware/thead,th1520-aon.yaml | 59 +++++++++++++++++++ > MAINTAINERS | 1 + > 2 files changed, 60 insertions(+) > create mode 100644 Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml > > diff --git a/Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml b/Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml > new file mode 100644 > index 000000000000..ca4c276766a3 > --- /dev/null > +++ b/Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml > @@ -0,0 +1,59 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/firmware/thead,th1520-aon.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: T-HEAD TH1520 AON (Always-On) Firmware Node Drop "Node", unless this is somehow name of device (not a DT node). > + > +description: | > + The Always-On (AON) subsystem in the TH1520 SoC is responsible for managing > + low-power states, system wakeup events, and power management tasks. It is > + designed to operate independently in a dedicated power domain, allowing it to > + remain functional even during the SoC's deep sleep states. > + > + At the heart of the AON subsystem is the E902, a low-power core that executes > + firmware responsible for coordinating tasks such as power domain control, > + clock management, and system wakeup signaling. Communication between the main > + SoC and the AON subsystem is handled through a mailbox interface, which > + enables message-based interactions with the AON firmware. > + > +maintainers: > + - Michal Wilczynski <m.wilczynski@samsung.com> > + > +properties: > + compatible: > + const: thead,th1520-aon > + > + mboxes: > + maxItems: 1 > + > + mbox-names: > + items: > + - const: aon > + > + power-domain: > + $ref: /schemas/power/thead,th1520-power.yaml# > + description: Subnode representing the hardware power domain of the AON subsystem. > + > +additionalProperties: false > + > +required: > + - compatible > + - mboxes > + - mbox-names In all your bindings patches: "required" block goes before additional/unevaluatedProperties. See also example-schema. > + > +examples: > + - | > + firmware { > + aon: aon { Best regards, Krzysztof
On 23/12/2024 13:55, Michal Wilczynski wrote: > Add a YAML schema for the T-HEAD TH1520 SoC reset controller. This > controller manages resets for subsystems such as the GPU within the > TH1520 SoC. > > Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> > --- > .../bindings/reset/thead,th1520-reset.yaml | 45 +++++++++++++++++++ > MAINTAINERS | 2 + > .../dt-bindings/reset/thead,th1520-reset.h | 13 ++++++ > 3 files changed, 60 insertions(+) > create mode 100644 Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml > create mode 100644 include/dt-bindings/reset/thead,th1520-reset.h > > diff --git a/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml b/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml > new file mode 100644 > index 000000000000..46d0e6b8c712 > --- /dev/null > +++ b/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml > @@ -0,0 +1,45 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > + Drop blank line > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/reset/thead,th1520-reset.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: T-HEAD TH1520 SoC Reset Controller > + > +description: | Do not need '|' unless you need to preserve formatting. > + The T-HEAD TH1520 reset controller is a hardware block that asserts/deasserts > + resets for SoC subsystems. > + > +maintainers: > + - Michal Wilczynski <m.wilczynski@samsung.com> > + > +properties: > + compatible: > + enum: > + - thead,th1520-reset > + ... > RNBD BLOCK DRIVERS > diff --git a/include/dt-bindings/reset/thead,th1520-reset.h b/include/dt-bindings/reset/thead,th1520-reset.h > new file mode 100644 > index 000000000000..a4958b2ed710 > --- /dev/null > +++ b/include/dt-bindings/reset/thead,th1520-reset.h > @@ -0,0 +1,13 @@ > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */ > +/* > + * Copyright (c) 2024 Samsung Electronics Co., Ltd. > + * Author: Michal Wilczynski <m.wilczynski@samsung.com> > + */ > + > +#ifndef _DT_BINDINGS_TH1520_RESET_H > +#define _DT_BINDINGS_TH1520_RESET_H > + > +#define TH1520_RESET_ID_GPU 0 > +#define TH1520_RESET_NUM_IDS 1 Drop the NUM_IDS define. Number is not a binding. But this leads to another question: only one reset? Then reset-cells should be 0. > + > +#endif /* _DT_BINDINGS_TH1520_RESET_H */ Best regards, Krzysztof
Quoting Michal Wilczynski (2024-12-23 04:55:35) > The T-Head TH1520 SoC’s AP clock controller now needs two address ranges > to manage both the Application Processor (AP) and Video Output (VO) > subsystem clocks. Update the device tree bindings to require two `reg` > entries, one for the AP clocks and one for the VO clocks. > > Additionally, introduce new VO subsystem clock constants in the header > file. These constants will be used by the driver to control VO-related > components such as display and graphics units. > > Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> > --- [...] > diff --git a/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml b/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml > index 0129bd0ba4b3..f0df97a450ef 100644 > --- a/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml > +++ b/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml > @@ -47,7 +54,9 @@ examples: > #include <dt-bindings/clock/thead,th1520-clk-ap.h> > clock-controller@ef010000 { > compatible = "thead,th1520-clk-ap"; > - reg = <0xef010000 0x1000>; > + reg = <0xef010000 0x1000>, > + <0xff010000 0x1000>; I don't get it. Why not have two nodes and two devices? They have different register regions so likely they're different devices on the internal SoC bus. They may have the same input clks, but otherwise I don't see how they're the same node. > + reg-names = "ap-clks", "vo-clks"; > clocks = <&osc>; > #clock-cells = <1>; > };
On 12/24/24 09:53, Krzysztof Kozlowski wrote: > On Mon, Dec 23, 2024 at 12:50:59PM -0800, Stephen Boyd wrote: >> Quoting Michal Wilczynski (2024-12-23 04:55:35) >>> The T-Head TH1520 SoC’s AP clock controller now needs two address ranges >>> to manage both the Application Processor (AP) and Video Output (VO) >>> subsystem clocks. Update the device tree bindings to require two `reg` >>> entries, one for the AP clocks and one for the VO clocks. >>> >>> Additionally, introduce new VO subsystem clock constants in the header >>> file. These constants will be used by the driver to control VO-related >>> components such as display and graphics units. >>> >>> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> >>> --- >> [...] >>> diff --git a/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml b/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml >>> index 0129bd0ba4b3..f0df97a450ef 100644 >>> --- a/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml >>> +++ b/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml >>> @@ -47,7 +54,9 @@ examples: >>> #include <dt-bindings/clock/thead,th1520-clk-ap.h> >>> clock-controller@ef010000 { >>> compatible = "thead,th1520-clk-ap"; >>> - reg = <0xef010000 0x1000>; >>> + reg = <0xef010000 0x1000>, >>> + <0xff010000 0x1000>; >> >> I don't get it. Why not have two nodes and two devices? They have >> different register regions so likely they're different devices on the >> internal SoC bus. They may have the same input clks, but otherwise I >> don't see how they're the same node. > > That's a good point. Aren't here simply two different clock controllers? Yeah there are two clock controllers, based on the review comments I was trying to re-use the driver, but the driver can also be re-used to serve multiple nodes and multiple compatible and .data properties, if that's fine with you that's how it will look like in v3. Thanks, Michał > > Best regards, > Krzysztof > >
On 24/12/2024 10:23, Michal Wilczynski wrote: > > > On 12/24/24 09:53, Krzysztof Kozlowski wrote: >> On Mon, Dec 23, 2024 at 12:50:59PM -0800, Stephen Boyd wrote: >>> Quoting Michal Wilczynski (2024-12-23 04:55:35) >>>> The T-Head TH1520 SoC’s AP clock controller now needs two address ranges >>>> to manage both the Application Processor (AP) and Video Output (VO) >>>> subsystem clocks. Update the device tree bindings to require two `reg` >>>> entries, one for the AP clocks and one for the VO clocks. >>>> >>>> Additionally, introduce new VO subsystem clock constants in the header >>>> file. These constants will be used by the driver to control VO-related >>>> components such as display and graphics units. >>>> >>>> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> >>>> --- >>> [...] >>>> diff --git a/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml b/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml >>>> index 0129bd0ba4b3..f0df97a450ef 100644 >>>> --- a/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml >>>> +++ b/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml >>>> @@ -47,7 +54,9 @@ examples: >>>> #include <dt-bindings/clock/thead,th1520-clk-ap.h> >>>> clock-controller@ef010000 { >>>> compatible = "thead,th1520-clk-ap"; >>>> - reg = <0xef010000 0x1000>; >>>> + reg = <0xef010000 0x1000>, >>>> + <0xff010000 0x1000>; >>> >>> I don't get it. Why not have two nodes and two devices? They have >>> different register regions so likely they're different devices on the >>> internal SoC bus. They may have the same input clks, but otherwise I >>> don't see how they're the same node. >> >> That's a good point. Aren't here simply two different clock controllers? > > Yeah there are two clock controllers, based on the review comments I was > trying to re-use the driver, but the driver can also be re-used to serve > multiple nodes and multiple compatible and .data properties, if that's > fine with you that's how it will look like in v3. Yeah, please drop my review tag and rework it to have two different devices. Driver design should not influence DTS. Best regards, Krzysztof
The LicheePi 4A board, featuring the T-HEAD TH1520 SoC, includes an Imagination Technologies BXM-4-64 GPU. Initial support for this GPU was provided through a downstream driver [1]. Recently, efforts have been made to upstream support for the Rogue family GPUs, which the BXM-4-64 is part of [2]. While the initial upstream driver focused on the AXE-1-16 GPU, newer patches have introduced support for the BXS-4-64 GPU [3]. The modern upstream drm/imagination driver is expected to support the BXM-4-64 as well [4][5]. As this support is being developed, it's crucial to upstream the necessary glue code including clock and power-domain drivers so they're ready for integration with the drm/imagination driver. Recent Progress: Firmware Improvements: Since August, the vendor has provided updated firmware [6][7] that correctly initiates the firmware for the BXM-4-64. Mesa Driver Testing: The vendor-supplied Mesa driver [8] partially works with Vulkan examples, such as rendering a triangle using Sascha Willems' Vulkan samples [9]. Although the triangle isn't rendered correctly (only the blue background appears), shader job submissions function properly, and IOCTL calls are correctly invoked. For testing, we used the following resources: Kernel Source: Custom kernel with necessary modifications [10]. Mesa Driver: Vendor-provided Mesa implementation [11]. Dependencies: Testing required a functional Display Processing Unit (DPU) and HDMI driver, which are currently not upstreamed. Efforts are underway to upstream the DPU DC8200 driver used in StarFive boards [12], which is the same DPU used on the LicheePi 4A. Once the DPU and HDMI drivers are upstreamed, GPU support can be fully upstream. Testing Status: This series has been tested by performing a probe-only operation, confirming that the firmware begins execution. The probe function initiates firmware execution and waits for the firmware to flip a specific status bit. [ 12.637880] powervr ffef400000.gpu: [drm] loaded firmware powervr/rogue_36.52.104.182_v1.fw [ 12.648979] powervr ffef400000.gpu: [drm] FW version v1.0 (build 6645434 OS) [ 12.678906] [drm] Initialized powervr 1.0.0 for ffef400000.gpu on minor 0 Power Management: Full power management capabilities require implementing the T-HEAD SoC AON protocol messaging via the hardware mailbox. Support for the mailbox was merged in kernel 6.13 [13], and the AON protocol implementation is part of this series, since v2. Therefore this series support full power management capabilities for the GPU driver. Thanks Krzysztof and Stephen for taking the time to review the last revision ! Your guidance and the direction was very helpful. v2: Removed AP_SUBSYS clock refactoring commits (1-6): - instead of refactoring, I opted to extend the current driver and its associated device tree node to include support for a second address space. Expanded patchset scope to fully support power management capabilities: - introduced a new firmware driver to manage power-related operations. - rewrote the power-domain driver to function alongside the firmware driver. These nodes in the device tree lack direct address spaces, despite representing HW blocks. Control is achieved via firmware protocol messages transmitted through a mailbox to the E902 core. Implemented a reset controller for the TH1520 SoC: - developed a reset controller driver for the TH1520 to manage reset sequences. - updated the drm/imagination driver to act as a reset controller consumer. While this patchset is focused on the LPI4A board, the reset controller is designed to be useful for other boards, such as the BPI-3F, which also require a reset sequence after power-up. Updated dt-bindings: - added new dt-bindings for power, reset, and firmware nodes. - updated the powervr dt-binding to include reset support and new compatibles. - ran dtbs_check and dt_binding_check to ensure compliance. Addressed code quality: - resolved all checkpatch issues using --strict, except for the call to devm_clk_hw_register_gate_parent_data(). The current implementation remains preferable in this context, and clang-format aligns with this choice. Also included the mailbox device tree commit, already queued for 6.14 [14] for completeness. References: [1] Downstream Driver Source: https://gitlab.freedesktop.org/frankbinns/powervr/-/blob/cb1929932095649a24f051b9cfdd2cd2ceab35cb/drivers/gpu/drm/img-rogue/Kconfig [2] Initial Upstream Driver Series: https://lore.kernel.org/all/cover.1700668843.git.donald.robson@imgtec.com/ [3] BXS-4-64 GPU Support Patches: https://lore.kernel.org/all/20241105-sets-bxs-4-64-patch-v1-v1-0-4ed30e865892@imgtec.com/ [4] Firmware Issue Discussion 1: https://gitlab.freedesktop.org/imagination/linux-firmware/-/issues/1 [5] Firmware Issue Discussion 2: https://gitlab.freedesktop.org/imagination/linux-firmware/-/issues/2 [6] Firmware Update Commit 1: https://gitlab.freedesktop.org/imagination/linux-firmware/-/commit/6ac2247e9a1d1837af495fb6d0fbd6f35547c2d1 [7] Firmware Update Commit 2: https://gitlab.freedesktop.org/imagination/linux-firmware/-/commit/efbebc90f25adb2b2e1499e3cc24ea3f3c3e4f4c [8] Vendor-Provided Mesa Driver: https://gitlab.freedesktop.org/imagination/mesa/-/tree/dev/devinfo [9] Sascha Willems' Vulkan Samples: https://github.com/SaschaWillems/Vulkan [10] Test Kernel Source: https://github.com/mwilczy/linux/tree/2_December_reference_linux_kernel_imagination [11] Test Mesa Driver: https://github.com/mwilczy/mesa-reference [12] DPU DC8200 Driver Upstream Attempt: https://lore.kernel.org/all/20241120061848.196754-1-keith.zhao@starfivetech.com/ [13] Pull request kernel 6.13 for mailbox https://lore.kernel.org/all/CABb+yY33qnivK-PzqpSMgmtbFid4nS8wcNvP7wED9DXrYAyLKg@mail.gmail.com/ [14] Mailbox commit queued for 6.14 https://lore.kernel.org/all/20241104100734.1276116-4-m.wilczynski@samsung.com/ Michal Wilczynski (19): dt-bindings: clock: Add VO subsystem clocks and update address requirements clk: thead: Add clock support for VO subsystem in T-Head TH1520 SoC dt-bindings: power: thead,th1520: Add support for power domains dt-bindings: firmware: thead,th1520: Add support for firmware node firmware: thead: Add AON firmware protocol driver soc: thead: power-domain: Add power-domain driver for TH1520 riscv: Enable PM_GENERIC_DOMAINS for T-Head SoCs dt-bindings: reset: Add T-HEAD TH1520 SoC Reset Controller reset: thead: Add TH1520 reset controller driver drm/imagination: Add reset controller support for GPU initialization dt-bindings: gpu: Add 'resets' property for GPU initialization dt-bindings: gpu: Add compatibles for T-HEAD TH1520 GPU drm/imagination: Add support for IMG BXM-4-64 GPU drm/imagination: Enable PowerVR driver for RISC-V riscv: dts: thead: Extend device tree clk with VO reg riscv: dts: thead: Add mailbox node riscv: dts: thead: Introduce power domain nodes with aon firmware riscv: dts: thead: Introduce reset controller node riscv: dts: thead: Add GPU node to TH1520 device tree .../bindings/clock/thead,th1520-clk-ap.yaml | 15 +- .../bindings/firmware/thead,th1520-aon.yaml | 59 +++++ .../bindings/gpu/img,powervr-rogue.yaml | 38 +++- .../bindings/power/thead,th1520-power.yaml | 42 ++++ .../bindings/reset/thead,th1520-reset.yaml | 45 ++++ MAINTAINERS | 8 + arch/riscv/Kconfig.socs | 1 + arch/riscv/boot/dts/thead/th1520.dtsi | 54 ++++- drivers/clk/thead/clk-th1520-ap.c | 160 ++++++++++++-- drivers/firmware/Kconfig | 9 + drivers/firmware/Makefile | 1 + drivers/firmware/thead,th1520-aon.c | 203 ++++++++++++++++++ drivers/gpu/drm/imagination/Kconfig | 2 +- drivers/gpu/drm/imagination/pvr_device.c | 21 ++ drivers/gpu/drm/imagination/pvr_device.h | 9 + drivers/gpu/drm/imagination/pvr_drv.c | 1 + drivers/gpu/drm/imagination/pvr_power.c | 15 +- drivers/pmdomain/Kconfig | 1 + drivers/pmdomain/Makefile | 1 + drivers/pmdomain/thead/Kconfig | 12 ++ drivers/pmdomain/thead/Makefile | 2 + drivers/pmdomain/thead/th1520-pm-domains.c | 181 ++++++++++++++++ drivers/reset/Kconfig | 10 + drivers/reset/Makefile | 1 + drivers/reset/reset-th1520.c | 151 +++++++++++++ .../dt-bindings/clock/thead,th1520-clk-ap.h | 33 +++ .../dt-bindings/power/thead,th1520-power.h | 18 ++ .../dt-bindings/reset/thead,th1520-reset.h | 13 ++ .../linux/firmware/thead/thead,th1520-aon.h | 186 ++++++++++++++++ 29 files changed, 1266 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/firmware/thead,th1520-aon.yaml create mode 100644 Documentation/devicetree/bindings/power/thead,th1520-power.yaml create mode 100644 Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml create mode 100644 drivers/firmware/thead,th1520-aon.c create mode 100644 drivers/pmdomain/thead/Kconfig create mode 100644 drivers/pmdomain/thead/Makefile create mode 100644 drivers/pmdomain/thead/th1520-pm-domains.c create mode 100644 drivers/reset/reset-th1520.c create mode 100644 include/dt-bindings/power/thead,th1520-power.h create mode 100644 include/dt-bindings/reset/thead,th1520-reset.h create mode 100644 include/linux/firmware/thead/thead,th1520-aon.h