Thread (26 messages) 26 messages, 6 authors, 2016-09-17

Re: [PATCH V3] clk: bcm: Add driver for Northstar ILP clock

From: Ray Jui <hidden>
Date: 2016-08-10 20:38:26
Also in: linux-devicetree, lkml


On 8/10/2016 10:28 AM, Rafał Miłecki wrote:
On 10 August 2016 at 19:22, Jon Mason [off-list ref] wrote:
quoted
On Wed, Aug 10, 2016 at 8:05 AM, Rafał Miłecki [off-list ref] wrote:
quoted
diff --git a/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt b/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
new file mode 100644
index 0000000..a18c73f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
@@ -0,0 +1,40 @@
+Broadcom Northstar ILP clock
+============================
+
+This binding uses the common clock binding:
+    Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+This binding is used for ILP clock (sometimes referred as "slow clock")
+on Broadcom Northstar devices using Corex-A7 CPU.
+
+This clock is part of PMU (Power Management Unit), a Broadcom's device
+handing power-related aspects. Please note PMU contains more subdevices,
+ILP is only one of them.
+
+ILP's rate has to be calculated on runtime and it depends on ALP clock
+which has to be referenced.
+
+Required properties:
+- compatible: "brcm,ns-ilp"
+- reg: iomem address range of PMU (Power Management Unit)
+- reg-names: "pmu", the only needed & supported reg right now
+- clocks: has to reference an ALP clock
+- #clock-cells: should be <0>
+
+Example:
+
+pmu@18012000 {
+       compatible = "simple-bus";
+       ranges = <0x00000000 0x18012000 0x00001000>;
I don't see a corresponding DT entry in this patch, but 18012000 is
the PCI block.  So, I am concerned this will collide if used there.

I looked at the NS register reference guide, and I cannot find the
registers you are trying to reference.  Is this supposed to be
referencing the LCPLL clock registers in DMU?  If so, there is already
a driver in there for this (see drivers/clk/bcm/clk-nsp.c).
This patch is for BCM53573 family, not BCM4708 family you are looking at.

Found chip with id 53573, rev 0x02 and package 0x01
Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x36, class 0x0)
Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x38, class 0x0)
Core 2 found: PCIe Gen 2 (manuf 0x4BF, id 0x501, rev 0x05, class 0x0)
Core 3 found: ARM CA7 (manuf 0x4BF, id 0x847, rev 0x00, class 0x0)
Core 4 found: USB 2.0 Host (manuf 0x4BF, id 0x819, rev 0x05, class 0x0)
Core 5 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x08, class 0x0)
Core 6 found: I2S (manuf 0x4BF, id 0x834, rev 0x06, class 0x0)
Core 7 found: CNDS DDR2/3 memory controller (manuf 0x4BF, id 0x846,
rev 0x00, class 0x0)
Core 8 found: NAND flash controller (manuf 0x4BF, id 0x509, rev 0x01, class 0x0)
Core 9 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x38, class 0x0)
Core 10 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x08, class 0x0)
Core 11 found: I2S (manuf 0x4BF, id 0x834, rev 0x06, class 0x0)
Core 12 found: GCI (manuf 0x4BF, id 0x840, rev 0x08, class 0x0)
Core 13 found: PMU (manuf 0x4BF, id 0x827, rev 0x1C, class 0x0)
Out of curiosity, I searched the datasheet and found this is a wireless 
router SoC done by the WLAN team. It happens to share some peripherals 
with other iProc based SoCs.

I cannot find a code name for this SoC from our internal documents. I 
guess that name "Northstar" used here has confused both Jon and me.

Thanks,

Ray
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help