On 9/20/26 1:21 PM, Krzysztof Kozlowski wrote:
On Fri, Sep 18, 2026 at 11:52:31AM -0500, Alex Elder wrote:
+description: |
I suppose I don't need the '|' here either.
+ The Toshiba TC9564 is an SoC accessed by a host system through the
+ upstream PCIe port on the PCIe switch it implements. The switch
+ includes an embedded PCIe endpoint that provides access to various
+ SoC peripherals (including a clock/reset controller) via its BARs.
+
+ The SoC is represented using a devicetree PCI endpoint bus, so the
+ clock controller is bound to its driver using a platform driver
Do not mention drivers here. Just say that host can access clocks etc
via PCI.
Daniel and I discussed this this morning, and in the next version
I'll explain things from a little different perspective, and I
think it will help keep this focused on the hardware.
This particular binding should not even mention anything about
PCI. Using the PCI endpoint bus means that the devices can be
bound based on compatible string (i.e. with platform drivers),
with no knowledge of access being provided by PCI.
But then more questions. This is PCI, yes? So how are the clocks from
PCI routed BACK to the main soc, which would justify having this in DTS
in the first place?
This clock+reset controller is one of several IP blocks
within an SoC (Toshiba TC9564). Most of these clock and
reset signals control things internal to this SoC, but at
least one clock signal and a few reset lines are exposed
externally, allowing them to be used by the platform that
incorporates the SoC.
Ultimately the TC9564 SoC has a single 25 MHz input clock,
and internal to the SoC there is an internal PLL that then
drives other clocks at rates derived from that. We can
only enable/disable the clocks (we have no rate control).
But I think you have more and deeper questions too.
We are using the *PCI endpoint bus* model to represent this
SoC. To me it seems that there is not full agreement on
some aspects of this model.
It is a weird situation, where the use of this *software*
model provides a means of more completely describing (using
devicetree) details of the hardware "behind" a PCI endpoint.
Despite PCI doing its own enumeration, PCI_DYNAMIC_OF_NODES
allows the PCI hierarchy to *also* have devicetree nodes
representing bridges and endpoints.
Building on that, a PCI function with a devicetree node
can include a "pci-ep-bus" sub-node. That sub-node
provides a place to describe IP blocks (devices) that
can be accessed via the endpoint bus.
In our case, in addition to this clock+reset device, the
TC9564 SoC implements a UART, a GPIO controller, a network
interface, and so on. All of these are accessed via the
endpoint bus associated with the PCI function's BAR 4
address space.
So this model differs from "normal" PCI devices in that a
single PCI endpoint (function) can expose more than just
one capability (in contrast with, for example, a PCI
function that implements only an Ethernet interface).
+ compatible string. All of the clocks are simple gate clocks.
+
+ A total of 21 clocks are implemented, though two of these are not
+ controllable. Access to the clock controller relies on PCIe being
+ functional, so the PCIe clock is assumed to be always on. Similarly,
+ the PCIe controller relies on I2C, so the I2C clock is also assumed
+ to be always on.
+
+ In addition, 13 resets are implemented. Similar to clocks, the PCIe
+ and I2C resets are assumed to be deasserted and cannot be controlled.
+
+ Clock and reset ids are defined in <dt-bindings/clock/toshiba,tc9564.h>.
+
+properties:
+ compatible:
+ const: toshiba,tc9564-clock
+
+ reg:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - "#clock-cells"
+ - "#reset-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/toshiba,tc9564.h>
+
+ clock@1004 {
+ compatible = "toshiba,tc9564-clock";
+ reg = <0x1004 0x20>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
No resources except small address space, so does not look like a
separate device and should be folded into the parent node.
Modeling the TC9564 as an SoC using pci-ep-bus, this
*is* sensibly a separate device.
We actually started with everything rolled into the
stmmac networking driver, but after some discussion
we concluded that the pci-ep-bus model would be simpler
(and other than some challenges related to it being a
relatively new thing, it *is* quite a bit simpler and
better partitioned).
-Alex
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index b2d3257b8f892..66d0e7e65adcb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27670,6 +27670,13 @@ F:
Documentation/devicetree/bindings/media/i2c/toshiba,tc358743.txt
F: drivers/media/i2c/tc358743*
F: include/media/i2c/tc358743.h
+TOSHIBA TC9564 CLOCK DRIVER
+M: Alex Elder <[email protected]>
+M: Daniel Thompson <[email protected]>
+S: Maintained
+F: Documentation/devicetree/bindings/clock/toshiba,tc9564-clock.yaml
+F: include/dt-bindings/clock/toshiba,tc9564.h
+
TOSHIBA TC9564 PCI DRIVER
M: Alex Elder <[email protected]>
M: Daniel Thompson <[email protected]>
diff --git a/include/dt-bindings/clock/toshiba,tc9564.h
b/include/dt-bindings/clock/toshiba,tc9564.h
new file mode 100644
index 0000000000000..75732fddd3025
--- /dev/null
+++ b/include/dt-bindings/clock/toshiba,tc9564.h
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+/*
+ * Copyright (C) 2026 by RISCstar Solutions Corporation. All rights reserved.
+ */
+
+#ifndef __ClOCK_TOSHIBA_TC9564_H__
+#define __ClOCK_TOSHIBA_TC9564_H__
+
+/* Clock IDs */
+
+#define CLOCK_MCU 0
+#define CLOCK_INTC 1
+/* #define CLOCK_PCIE 2 */
+/* #define CLOCK_I2C 3 */
Drop both, and SRAM is number 2. Or enable and implement them.
Best regards,
Krzysztof
