Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1719648 > unrolled thread

[PATCH v3 0/2] SoC driver for Broadcom STB DPFE

Started byMarkus Mayer <code@mmayer.net>
First post2017-08-25 01:40 +0200
Last post2017-08-25 03:00 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH v3 0/2] SoC driver for Broadcom STB DPFE Markus Mayer <code@mmayer.net> - 2017-08-25 01:40 +0200
    [PATCH v3 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors Markus Mayer <code@mmayer.net> - 2017-08-25 01:40 +0200
    Re: [PATCH v3 0/2] SoC driver for Broadcom STB DPFE Florian Fainelli <f.fainelli@gmail.com> - 2017-08-25 03:00 +0200

#1719648 — [PATCH v3 0/2] SoC driver for Broadcom STB DPFE

FromMarkus Mayer <code@mmayer.net>
Date2017-08-25 01:40 +0200
Subject[PATCH v3 0/2] SoC driver for Broadcom STB DPFE
Message-ID<ui9Tb-4MH-7@gated-at.bofh.it>
From: Markus Mayer <mmayer@broadcom.com>

This series introduces a driver to interact with the Broadcom STB DDR
PHY Front End (DPFE), specifically to communicate with the DCPU that is
part of the DDR PHY and which is running its own firmware.

The DCPU provides information such as DRAM refresh rate, which can be
used as indirect indicator for the DRAM temperature (the higher the
refresh rate, the hotter the RAM).

The series was previously submitted as HWMON driver[1]. It has been
removed from that subsystem, because it doesn't provide any standard
HWMON data due to hardware design properties, and is now implemented as
SoC driver.

Changes since v2:
  - moved driver from drivers/soc/bcm/brcmstb to drivers/memory
  - renamed the driver from dpfe.c to brcmstb_dpfe.c
  - added le32_to_cpu() in a few places (where be32_to_cpu() calls
    already existed)
  - added a little blurb what the le32_to_cpu()/be32_to_cpu() business
    is all about

Changes since v1:
  - binding simplified to use one node with three memory regions
    instead of three nodes with one region
  - no longer part of the HWMON subsystem
  - better error handling and error reporting to userland
  - uses [readl|writel]_relaxed() directly, since there is no need for
    wrappers doing endian conversion
  - re-download firmware upon "resume"
  - minor changes to improve clarity

[1] https://lkml.org/lkml/2017/4/18/640

Markus Mayer (2):
  dt/bindings: Add bindings for Broadcom STB DRAM Sensors
  memory: brcmstb: Add driver for DPFE

 .../bindings/memory-controllers/brcm,dpfe-cpu.txt  |  27 +
 MAINTAINERS                                        |   8 +
 drivers/memory/Makefile                            |   1 +
 drivers/memory/brcmstb_dpfe.c                      | 701 +++++++++++++++++++++
 4 files changed, 737 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt
 create mode 100644 drivers/memory/brcmstb_dpfe.c

-- 
2.7.4

[toc] | [next] | [standalone]


#1719649 — [PATCH v3 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors

FromMarkus Mayer <code@mmayer.net>
Date2017-08-25 01:40 +0200
Subject[PATCH v3 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors
Message-ID<ui9Tc-4MH-19@gated-at.bofh.it>
In reply to#1719648
From: Markus Mayer <mmayer@broadcom.com>

Provide bindings for the Broadcom STB DDR PHY Front End (DPFE).

Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Acked-by: Rob Herring <robh@kernel.org>
---
 .../bindings/memory-controllers/brcm,dpfe-cpu.txt  | 27 ++++++++++++++++++++++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt

diff --git a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt
new file mode 100644
index 0000000..82d923e
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt
@@ -0,0 +1,27 @@
+DDR PHY Front End (DPFE) for Broadcom STB
+=========================================
+
+DPFE and the DPFE firmware provide an interface for the host CPU to
+communicate with the DCPU, which resides inside the DDR PHY.
+
+There are three memory regions for interacting with the DCPU. These are
+specified in a single reg property.
+
+Required properties:
+  - compatible: must be "brcm,bcm7271-dpfe-cpu", "brcm,bcm7268-dpfe-cpu"
+    or "brcm,dpfe-cpu"
+  - reg: must reference three register ranges
+      - start address and length of the DCPU register space
+      - start address and length of the DCPU data memory space
+      - start address and length of the DCPU instruction memory space
+  - reg-names: must contain "dpfe-cpu", "dpfe-dmem", and "dpfe-imem";
+        they must be in the same order as the register declarations
+
+Example:
+	dpfe_cpu0: dpfe-cpu@f1132000 {
+		compatible = "brcm,bcm7271-dpfe-cpu", "brcm,dpfe-cpu";
+		reg =  <0xf1132000 0x180
+			0xf1134000 0x1000
+			0xf1138000 0x4000>;
+		reg-names = "dpfe-cpu", "dpfe-dmem", "dpfe-imem";
+	};
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]


#1719690

FromFlorian Fainelli <f.fainelli@gmail.com>
Date2017-08-25 03:00 +0200
Message-ID<uib8C-5ry-7@gated-at.bofh.it>
In reply to#1719648
On 08/24/2017 04:36 PM, Markus Mayer wrote:
> From: Markus Mayer <mmayer@broadcom.com>
> 
> This series introduces a driver to interact with the Broadcom STB DDR
> PHY Front End (DPFE), specifically to communicate with the DCPU that is
> part of the DDR PHY and which is running its own firmware.
> 
> The DCPU provides information such as DRAM refresh rate, which can be
> used as indirect indicator for the DRAM temperature (the higher the
> refresh rate, the hotter the RAM).
> 
> The series was previously submitted as HWMON driver[1]. It has been
> removed from that subsystem, because it doesn't provide any standard
> HWMON data due to hardware design properties, and is now implemented as
> SoC driver.
> 
> Changes since v2:
>   - moved driver from drivers/soc/bcm/brcmstb to drivers/memory
>   - renamed the driver from dpfe.c to brcmstb_dpfe.c
>   - added le32_to_cpu() in a few places (where be32_to_cpu() calls
>     already existed)
>   - added a little blurb what the le32_to_cpu()/be32_to_cpu() business
>     is all about
> 
> Changes since v1:
>   - binding simplified to use one node with three memory regions
>     instead of three nodes with one region
>   - no longer part of the HWMON subsystem
>   - better error handling and error reporting to userland
>   - uses [readl|writel]_relaxed() directly, since there is no need for
>     wrappers doing endian conversion
>   - re-download firmware upon "resume"
>   - minor changes to improve clarity
> 
> [1] https://lkml.org/lkml/2017/4/18/640

Applied, thanks Markus! Will get that resubmitted in a short while:

https://github.com/Broadcom/stblinux/commits/drivers/next
-- 
Florian

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web