[PATCH v4 09/11] drm/hisilicon: Add support for external bridge

[Xinliang Liu]

Add support for external HDMI bridge.

v4: None.
v3:
- Fix a typo: s/exteranl/external.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 52 
 1 file changed, 52 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index 2837af01e935..1342d84d7c68 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -79,6 +79,7 @@ struct dsi_hw_ctx {
 
 struct dw_dsi {
struct drm_encoder encoder;
+   struct drm_bridge *bridge;
struct mipi_dsi_host host;
struct drm_display_mode cur_mode;
struct dsi_hw_ctx *ctx;
@@ -688,6 +689,25 @@ static int dsi_host_init(struct device *dev, struct dw_dsi 
*dsi)
return 0;
 }
 
+static int dsi_bridge_init(struct drm_device *dev, struct dw_dsi *dsi)
+{
+   struct drm_encoder *encoder = &dsi->encoder;
+   struct drm_bridge *bridge = dsi->bridge;
+   int ret;
+
+   /* associate the bridge to dsi encoder */
+   encoder->bridge = bridge;
+   bridge->encoder = encoder;
+
+   ret = drm_bridge_attach(dev, bridge);
+   if (ret) {
+   DRM_ERROR("failed to attach external bridge\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static int dsi_bind(struct device *dev, struct device *master, void *data)
 {
struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -703,6 +723,10 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
if (ret)
return ret;
 
+   ret = dsi_bridge_init(drm_dev, dsi);
+   if (ret)
+   return ret;
+
return 0;
 }
 
@@ -719,8 +743,36 @@ static const struct component_ops dsi_ops = {
 static int dsi_parse_dt(struct platform_device *pdev, struct dw_dsi *dsi)
 {
struct dsi_hw_ctx *ctx = dsi->ctx;
+   struct device_node *np = pdev->dev.of_node;
+   struct device_node *endpoint, *bridge_node;
+   struct drm_bridge *bridge;
struct resource *res;
 
+   /*
+* Get the endpoint node. In our case, dsi has one output port1
+* to which the external HDMI bridge is connected.
+*/
+   endpoint = of_graph_get_endpoint_by_regs(np, 1, -1);
+   if (!endpoint) {
+   DRM_ERROR("no valid endpoint node\n");
+   return -ENODEV;
+   }
+   of_node_put(endpoint);
+
+   bridge_node = of_graph_get_remote_port_parent(endpoint);
+   if (!bridge_node) {
+   DRM_ERROR("no valid bridge node\n");
+   return -ENODEV;
+   }
+   of_node_put(bridge_node);
+
+   bridge = of_drm_find_bridge(bridge_node);
+   if (!bridge) {
+   DRM_INFO("wait for external HDMI bridge driver.\n");
+   return -EPROBE_DEFER;
+   }
+   dsi->bridge = bridge;
+
ctx->dsi_cfg_clk = devm_clk_get(&pdev->dev, "pclk_dsi");
if (IS_ERR(ctx->dsi_cfg_clk)) {
DRM_ERROR("failed to get dsi plck clock\n");
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 10/11] MAINTAINERS: Add maintainer for hisilicon DRM driver

[Xinliang Liu]

Add maintainer and reviewer for hisilicon DRM driver.

v4:
- Add Chen Feng  as Designated reviewer.
v3: First version.

Signed-off-by: Xinliang Liu 
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4aa5467..730ebc571edf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3777,6 +3777,16 @@ S:   Maintained
 F: drivers/gpu/drm/gma500
 F: include/drm/gma500*
 
+DRM DRIVERS FOR HISILICON
+M: Xinliang Liu 
+R: Xinwei Kong 
+R: Chen Feng 
+L: dri-de...@lists.freedesktop.org
+T: git git://github.com/xin3liang/linux.git
+S: Maintained
+F: drivers/gpu/drm/hisilicon
+F: Documentation/devicetree/bindings/display/hisilicon
+
 DRM DRIVERS FOR NVIDIA TEGRA
 M: Thierry Reding 
 M: Terje Bergstr??m 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 11/11] arm64: dts: hisilicon: Add display subsystem DT nodes for hi6220

[Xinliang Liu]

Add ade, dsi and adv7533 DT nodes for hikey board.

Signed-off-by: Xinliang Liu 
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 44 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  | 53 ++
 2 files changed, 97 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 818525197508..5c3557c8e59b 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -39,3 +39,47 @@
 &uart3 {
label = "LS-UART1";
 };
+
+&ade {
+   status = "okay";
+};
+
+&dsi {
+   status = "ok";
+
+   ports {
+/* 1 for output port */
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   /* 0 for bridge, other value for panel */
+   dsi_out0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&adv7533_in>;
+   };
+   };
+   };
+};
+
+&i2c2 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "ok";
+
+   adv7533: adv7533@39 {
+   compatible = "adi,adv7533";
+   reg = <0x39>;
+   interrupt-parent = <&gpio1>;
+   interrupts = <1 2>;
+   pd-gpio = <&gpio0 4 0>;
+   adi,dsi-lanes = <4>;
+
+   port {
+   adv7533_in: endpoint {
+   remote-endpoint = <&dsi_out0>;
+   };
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index ad1f1ebcb05c..e50e81cdd242 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -209,5 +209,58 @@
clock-names = "uartclk", "apb_pclk";
status = "disabled";
};
+
+   ade: ade@f410 {
+   compatible = "hisilicon,hi6220-ade";
+   reg = <0x0 0xf410 0x0 0x7800>,
+ <0x0 0xf441 0x0 0x1000>,
+ <0x0 0xf452 0x0 0x1000>;
+   reg-names = "ade_base",
+   "media_base",
+   "media_noc_base";
+
+   interrupts = <0 115 4>; /* ldi interrupt */
+
+   clocks = <&media_ctrl HI6220_ADE_CORE>,
+<&media_ctrl HI6220_CODEC_JPEG>,
+<&media_ctrl HI6220_ADE_PIX_SRC>;
+   /*clock name*/
+   clock-names  = "clk_ade_core",
+  "clk_codec_jpeg",
+  "clk_ade_pix";
+
+   assigned-clocks = <&media_ctrl HI6220_ADE_CORE>,
+   <&media_ctrl HI6220_CODEC_JPEG>;
+   assigned-clock-rates = <36000>, <28800>;
+   dma-coherent;
+   status = "disabled";
+
+   port {
+   ade_out: endpoint {
+   remote-endpoint = <&dsi_in>;
+   };
+   };
+   };
+
+   dsi: dsi@f4107800 {
+   compatible = "hisilicon,hi6220-dsi";
+   reg = <0x0 0xf4107800 0x0 0x100>;
+   clocks = <&media_ctrl  HI6220_DSI_PCLK>;
+   clock-names = "pclk_dsi";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* 0 for input port */
+   port@0 {
+   reg = <0>;
+   dsi_in: endpoint {
+   remote-endpoint = <&ade_out>;
+   };
+   };
+   };
+   };
};
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 08/11] drm/hisilicon: Add designware dsi host driver

[Xinliang Liu]

Add DesignWare dsi host driver for hi6220 SoC.

v4: None.
v3: None.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 50 
 1 file changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
index 7c9423537b71..2837af01e935 100644
--- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -79,6 +79,7 @@ struct dsi_hw_ctx {
 
 struct dw_dsi {
struct drm_encoder encoder;
+   struct mipi_dsi_host host;
struct drm_display_mode cur_mode;
struct dsi_hw_ctx *ctx;
struct mipi_phy_params phy;
@@ -642,6 +643,51 @@ static int dw_drm_encoder_init(struct device *dev,
return 0;
 }
 
+static int dsi_host_attach(struct mipi_dsi_host *host,
+  struct mipi_dsi_device *mdsi)
+{
+   struct dw_dsi *dsi = host_to_dsi(host);
+
+   if (mdsi->lanes < 1 || mdsi->lanes > 4) {
+   DRM_ERROR("dsi device params invalid\n");
+   return -EINVAL;
+   }
+
+   dsi->lanes = mdsi->lanes;
+   dsi->format = mdsi->format;
+   dsi->mode_flags = mdsi->mode_flags;
+
+   return 0;
+}
+
+static int dsi_host_detach(struct mipi_dsi_host *host,
+  struct mipi_dsi_device *mdsi)
+{
+   /* do nothing */
+   return 0;
+}
+
+static const struct mipi_dsi_host_ops dsi_host_ops = {
+   .attach = dsi_host_attach,
+   .detach = dsi_host_detach,
+};
+
+static int dsi_host_init(struct device *dev, struct dw_dsi *dsi)
+{
+   struct mipi_dsi_host *host = &dsi->host;
+   int ret;
+
+   host->dev = dev;
+   host->ops = &dsi_host_ops;
+   ret = mipi_dsi_host_register(host);
+   if (ret) {
+   DRM_ERROR("failed to register dsi host\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 static int dsi_bind(struct device *dev, struct device *master, void *data)
 {
struct dsi_data *ddata = dev_get_drvdata(dev);
@@ -653,6 +699,10 @@ static int dsi_bind(struct device *dev, struct device 
*master, void *data)
if (ret)
return ret;
 
+   ret = dsi_host_init(dev, dsi);
+   if (ret)
+   return ret;
+
return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 07/11] drm/hisilicon: Add designware dsi encoder driver

[Xinliang Liu]

Add DesignWare MIPI DSI Host Controller v1.02 encoder driver
for hi6220 SoC.

v4: None.
v3:
- Rename file name to dw_drm_dsi.c
- Make encoder type as DRM_MODE_ENCODER_DSI.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
Signed-off-by: Xinwei Kong 
Signed-off-by: Andy Green 
---
 drivers/gpu/drm/hisilicon/kirin/Kconfig  |   1 +
 drivers/gpu/drm/hisilicon/kirin/Makefile |   3 +-
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 743 +++
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h |  83 +++
 4 files changed, 829 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h

diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig 
b/drivers/gpu/drm/hisilicon/kirin/Kconfig
index 3ac4b8edeac1..de0d454c5c13 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Kconfig
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -4,6 +4,7 @@ config DRM_HISI_KIRIN
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
+   select DRM_MIPI_DSI
help
  Choose this option if you have a hisilicon Kirin chipsets(hi6220).
  If M is selected the module will be called kirin-drm.
diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile 
b/drivers/gpu/drm/hisilicon/kirin/Makefile
index 2a61ab006ddb..5dcd0d4328b6 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Makefile
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -1,4 +1,5 @@
 kirin-drm-y := kirin_drm_drv.o \
-  kirin_drm_ade.o
+  kirin_drm_ade.o \
+  dw_drm_dsi.o
 
 obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c 
b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
new file mode 100644
index ..7c9423537b71
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
@@ -0,0 +1,743 @@
+/*
+ * DesignWare MIPI DSI Host Controller v1.02 driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ * Xinliang Liu 
+ * Xinliang Liu 
+ * Xinwei Kong 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dw_dsi_reg.h"
+
+#define MAX_TX_ESC_CLK(10)
+#define ROUND(x, y) ((x) / (y) + ((x) % (y) * 10 / (y) >= 5 ? 1 : 0))
+#define PHY_REF_CLK_RATE   1920
+#define PHY_REF_CLK_PERIOD_PS (10 / (PHY_REF_CLK_RATE / 1000))
+
+#define encoder_to_dsi(encoder) \
+   container_of(encoder, struct dw_dsi, encoder)
+#define host_to_dsi(host) \
+   container_of(host, struct dw_dsi, host)
+
+struct mipi_phy_params {
+   u32 clk_t_lpx;
+   u32 clk_t_hs_prepare;
+   u32 clk_t_hs_zero;
+   u32 clk_t_hs_trial;
+   u32 clk_t_wakeup;
+   u32 data_t_lpx;
+   u32 data_t_hs_prepare;
+   u32 data_t_hs_zero;
+   u32 data_t_hs_trial;
+   u32 data_t_ta_go;
+   u32 data_t_ta_get;
+   u32 data_t_wakeup;
+   u32 hstx_ckg_sel;
+   u32 pll_fbd_div5f;
+   u32 pll_fbd_div1f;
+   u32 pll_fbd_2p;
+   u32 pll_enbwt;
+   u32 pll_fbd_p;
+   u32 pll_fbd_s;
+   u32 pll_pre_div1p;
+   u32 pll_pre_p;
+   u32 pll_vco_750M;
+   u32 pll_lpf_rs;
+   u32 pll_lpf_cs;
+   u32 clklp2hs_time;
+   u32 clkhs2lp_time;
+   u32 lp2hs_time;
+   u32 hs2lp_time;
+   u32 clk_to_data_delay;
+   u32 data_to_clk_delay;
+   u32 lane_byte_clk_kHz;
+   u32 clk_division;
+};
+
+struct dsi_hw_ctx {
+   void __iomem *base;
+   struct clk *dsi_cfg_clk;
+};
+
+struct dw_dsi {
+   struct drm_encoder encoder;
+   struct drm_display_mode cur_mode;
+   struct dsi_hw_ctx *ctx;
+   struct mipi_phy_params phy;
+
+   u32 lanes;
+   enum mipi_dsi_pixel_format format;
+   unsigned long mode_flags;
+   bool enable;
+};
+
+struct dsi_data {
+   struct dw_dsi dsi;
+   struct dsi_hw_ctx ctx;
+};
+
+struct dsi_phy_range {
+   u32 min_range_kHz;
+   u32 max_range_kHz;
+   u32 pll_vco_750M;
+   u32 hstx_ckg_sel;
+};
+
+static const struct dsi_phy_range dphy_range_info[] = {
+   {   46875,62500,   1,7 },
+   {   62500,93750,   0,7 },
+   {   93750,   125000,   1,6 },
+   {  125000,   187500,   0,6 },
+   {  187500,   25,   1,5 },
+   {  25,   375000,   0,5 },
+   {  375000,   50,   1,4 },
+   {  50,   75,   0,4 },
+   {  75,  100,   1,0 },
+   { 100,  150,   0,0 }
+};
+
+static void dsi_get_phy_params(u32 phy_freq_kHz,
+  struct mipi_phy_params *phy)
+{
+   u32 ui = 0;
+   u32 cfg_clk_ps = 

[PATCH v4 06/11] drm/hisilicon: Add cma fbdev and hotplug

[Xinliang Liu]

Add cma Fbdev, Fbdev is legency and optional, you can enable/disable it by
configuring DRM_FBDEV_EMULATION.
Add hotplug.

v4: None.
v3: None.
v2:
- Use CONFIG_DRM_FBDEV_EMULATION instead of CONFIG_DRM_HISI_FBDEV.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 34 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  3 +++
 2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 723888feb760..d57b9fa0ce3e 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "kirin_drm_drv.h"
 
@@ -32,6 +33,13 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
struct kirin_drm_private *priv = dev->dev_private;
 
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+   if (priv->fbdev) {
+   drm_fbdev_cma_fini(priv->fbdev);
+   priv->fbdev = NULL;
+   }
+#endif
+   drm_kms_helper_poll_fini(dev);
drm_vblank_cleanup(dev);
dc_ops->cleanup(dev);
drm_mode_config_cleanup(dev);
@@ -41,8 +49,28 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
return 0;
 }
 
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
+{
+   struct kirin_drm_private *priv = dev->dev_private;
+
+   if (priv->fbdev) {
+   drm_fbdev_cma_hotplug_event(priv->fbdev);
+   } else {
+   priv->fbdev = drm_fbdev_cma_init(dev, 32,
+   dev->mode_config.num_crtc,
+   dev->mode_config.num_connector);
+   if (IS_ERR(priv->fbdev))
+   priv->fbdev = NULL;
+   }
+}
+#endif
+
 static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
.fb_create = drm_fb_cma_create,
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+   .output_poll_changed = kirin_fbdev_output_poll_changed,
+#endif
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
 };
@@ -98,6 +126,12 @@ static int kirin_drm_kms_init(struct drm_device *dev)
/* reset all the states of crtc/plane/encoder/connector */
drm_mode_config_reset(dev);
 
+   /* init kms poll for handling hpd */
+   drm_kms_helper_poll_init(dev);
+
+   /* force detection after connectors init */
+   (void)drm_helper_hpd_irq_event(dev);
+
return 0;
 
 err_unbind_all:
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
index 5a05ad6a81db..1a07caf8e7f4 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
@@ -21,6 +21,9 @@ struct kirin_dc_ops {
 
 struct kirin_drm_private {
struct drm_crtc *crtc[MAX_CRTC];
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+   struct drm_fbdev_cma *fbdev;
+#endif
 };
 
 extern const struct kirin_dc_ops ade_dc_ops;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 05/11] drm/hisilicon: Add vblank driver for ADE

[Xinliang Liu]

Add vblank irq handle.

v4: None.
v3:
- Remove hisi_get_crtc_from_index func.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 62 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 14 +-
 2 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index ff70f1c3dd78..2a12e14ea6ab 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -295,6 +295,59 @@ static void ade_set_medianoc_qos(struct ade_crtc *acrtc)
writel(val, reg);
 }
 
+static int ade_enable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+   struct kirin_drm_private *priv = dev->dev_private;
+   struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+   struct ade_hw_ctx *ctx = acrtc->ctx;
+   void __iomem *base = ctx->base;
+
+   if (!ctx->power_on)
+   (void)ade_power_up(ctx);
+
+   ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+   MASK(1), 1);
+
+   return 0;
+}
+
+static void ade_disable_vblank(struct drm_device *dev, unsigned int pipe)
+{
+   struct kirin_drm_private *priv = dev->dev_private;
+   struct ade_crtc *acrtc = to_ade_crtc(priv->crtc[pipe]);
+   struct ade_hw_ctx *ctx = acrtc->ctx;
+   void __iomem *base = ctx->base;
+
+   if (!ctx->power_on) {
+   DRM_ERROR("power is down! vblank disable fail\n");
+   return;
+   }
+
+   ade_update_bits(base + LDI_INT_EN, FRAME_END_INT_EN_OFST,
+   MASK(1), 0);
+}
+
+static irqreturn_t ade_irq_handler(int irq, void *data)
+{
+   struct ade_crtc *acrtc = data;
+   struct ade_hw_ctx *ctx = acrtc->ctx;
+   struct drm_crtc *crtc = &acrtc->base;
+   void __iomem *base = ctx->base;
+   u32 status;
+
+   status = readl(base + LDI_MSK_INT);
+   DRM_DEBUG_VBL("LDI IRQ: status=0x%X\n", status);
+
+   /* vblank irq */
+   if (status & BIT(FRAME_END_INT_EN_OFST)) {
+   ade_update_bits(base + LDI_INT_CLR, FRAME_END_INT_EN_OFST,
+   MASK(1), 1);
+   drm_crtc_handle_vblank(crtc);
+   }
+
+   return IRQ_HANDLED;
+}
+
 static void ade_display_enable(struct ade_crtc *acrtc)
 {
struct ade_hw_ctx *ctx = acrtc->ctx;
@@ -973,6 +1026,15 @@ int ade_drm_init(struct drm_device *dev)
if (ret)
return ret;
 
+   /* vblank irq init */
+   ret = devm_request_irq(dev->dev, ctx->irq, ade_irq_handler,
+  DRIVER_IRQ_SHARED, dev->driver->name, acrtc);
+   if (ret)
+   return ret;
+   dev->driver->get_vblank_counter = drm_vblank_no_hw_counter;
+   dev->driver->enable_vblank = ade_enable_vblank;
+   dev->driver->disable_vblank = ade_disable_vblank;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index 055729c1889c..723888feb760 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -32,6 +32,7 @@ static int kirin_drm_kms_cleanup(struct drm_device *dev)
 {
struct kirin_drm_private *priv = dev->dev_private;
 
+   drm_vblank_cleanup(dev);
dc_ops->cleanup(dev);
drm_mode_config_cleanup(dev);
devm_kfree(dev->dev, priv);
@@ -85,11 +86,22 @@ static int kirin_drm_kms_init(struct drm_device *dev)
goto err_dc_cleanup;
}
 
+   /* vblank init */
+   ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
+   if (ret) {
+   DRM_ERROR("failed to initialize vblank.\n");
+   goto err_unbind_all;
+   }
+   /* with irq_enabled = true, we can use the vblank feature. */
+   dev->irq_enabled = true;
+
/* reset all the states of crtc/plane/encoder/connector */
drm_mode_config_reset(dev);
 
return 0;
 
+err_unbind_all:
+   component_unbind_all(dev->dev, dev);
 err_dc_cleanup:
dc_ops->cleanup(dev);
 err_mode_config_cleanup:
@@ -123,7 +135,7 @@ static int kirin_gem_cma_dumb_create(struct drm_file *file,
 
 static struct drm_driver kirin_drm_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
- DRIVER_ATOMIC,
+ DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
.fops   = &kirin_drm_fops,
.set_busid  = drm_platform_set_busid,
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 01/11] drm/hisilicon: Add device tree binding for hi6220 display subsystem

[Xinliang Liu]

Add ADE display controller binding doc.
Add DesignWare DSI Host Controller v1.20a binding doc.

v4:
- Describe more specific of clocks and ports.
- Fix indentation.
v3:
- Make ade as the drm master node.
- Use assigned-clocks to set clock rate.
- Use ports to connect display relavant nodes.
v2:
- Move dt binding docs to bindings/display/hisilicon directory.

Signed-off-by: Xinwei Kong 
Signed-off-by: Xinliang Liu 
---
 .../bindings/display/hisilicon/dw-dsi.txt  | 77 ++
 .../bindings/display/hisilicon/hisi-ade.txt| 69 +++
 2 files changed, 146 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt

diff --git a/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt 
b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
new file mode 100644
index ..af6d702f3282
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
@@ -0,0 +1,77 @@
+Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
+
+A DSI Host Controller resides in the middle of display controller and external
+HDMI converter.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-dsi".
+- reg: physical base address and length of dsi controller's registers.
+- clocks: the clocks needed.
+- clock-names: the name of the clocks.
+- ports: contains DSI controller input and output sub port.
+  The input port connects to ADE output port with the reg value "0".
+  The output port with the reg value "1", it could connect to panel or
+  any other bridge endpoints. And the reg value for bridge endpoint is "0",
+  other values for panel endpoint.
+  See Documentation/devicetree/bindings/graph.txt for more device graph info.
+
+A example of HiKey board hi6220 SoC and board specific DT entry:
+Example:
+
+SoC specific:
+   dsi: dsi@f4107800 {
+   compatible = "hisilicon,hi6220-dsi";
+   reg = <0x0 0xf4107800 0x0 0x100>;
+   clocks = <&media_ctrl  HI6220_DSI_PCLK>;
+   clock-names = "pclk_dsi";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   /* 0 for input port */
+   port@0 {
+   reg = <0>;
+   dsi_in: endpoint {
+   remote-endpoint = <&ade_out>;
+   };
+   };
+   };
+   };
+
+
+Board specific:
+   &dsi {
+   status = "ok";
+
+   ports {
+   /* 1 for output port */
+   port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   /* 0 for bridge, other value for panel */
+   dsi_out0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&adv7533_in>;
+   };
+   };
+   };
+   };
+
+   &i2c2 {
+   ...
+
+   adv7533: adv7533@39 {
+   ...
+
+   port {
+   adv7533_in: endpoint {
+   remote-endpoint = <&dsi_out0>;
+   };
+   };
+   };
+   };
+
diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt 
b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
new file mode 100644
index ..1eff5a41b98d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
@@ -0,0 +1,69 @@
+Device-Tree bindings for hisilicon ADE display controller driver
+
+ADE (Advanced Display Engine) is the display controller which grab image
+data from memory, do composition, do post image processing, generate RGB
+timing stream and transfer to DSI.
+
+Required properties:
+- compatible: value should be "hisilicon,hi6220-ade".
+- reg: physical base address and length of the controller's registers.
+  Three reg ranges are used in ADE driver:
+  ADE reg range, value should be "<0x0 0xf410 0x0 0x7800>";
+  media subsystem reg range, value should be "<0x0 0xf441 0x0 0x1000>";
+  media subsystem NOC QoS reg range, value should be "<0x0 0xf452 0x0
+  0x1000>".
+- reg-names: name of physical base.Valuse should be "ade_base",
"media_base"
+  and "media_noc_base".
+- interrupt: the ldi vblank interrupt number used.
+- clocks: the clocks needed. Three clocks are used in ADE driver:
+  ADE core clock, value should be "<&media_ctrl HI6220_ADE_CORE>";
+  ADE pixe

[PATCH v4 04/11] drm/hisilicon: Add plane driver for ADE

[Xinliang Liu]

Add plane funcs and helper funcs for ADE.

v4: None.
v3:
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 535 +++-
 1 file changed, 534 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index b45149616716..ff70f1c3dd78 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -24,13 +24,23 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include "kirin_drm_drv.h"
 #include "kirin_ade_reg.h"
 
+#define PRIMARY_CH ADE_CH1 /* primary plane */
+#define OUT_OVLY   ADE_OVLY2 /* output overlay compositor */
+#define ADE_DEBUG  1
+
 #define to_ade_crtc(crtc) \
container_of(crtc, struct ade_crtc, base)
 
+#define to_ade_plane(plane) \
+   container_of(plane, struct ade_plane, base)
+
 struct ade_hw_ctx {
void __iomem  *base;
void __iomem  *media_base;
@@ -49,11 +59,76 @@ struct ade_crtc {
u32 out_format;
 };
 
+struct ade_plane {
+   struct drm_plane base;
+   void *ctx;
+   u8 ch; /* channel */
+};
+
 struct ade_data {
struct ade_crtc acrtc;
+   struct ade_plane aplane[ADE_CH_NUM];
struct ade_hw_ctx ctx;
 };
 
+/* ade-format info: */
+struct ade_format {
+   u32 pixel_format;
+   enum ade_fb_format ade_format;
+};
+
+static const struct ade_format ade_formats[] = {
+   /* 16bpp RGB: */
+   { DRM_FORMAT_RGB565, ADE_RGB_565 },
+   { DRM_FORMAT_BGR565, ADE_BGR_565 },
+   /* 24bpp RGB: */
+   { DRM_FORMAT_RGB888, ADE_RGB_888 },
+   { DRM_FORMAT_BGR888, ADE_BGR_888 },
+   /* 32bpp [A]RGB: */
+   { DRM_FORMAT_XRGB, ADE_XRGB_ },
+   { DRM_FORMAT_XBGR, ADE_XBGR_ },
+   { DRM_FORMAT_RGBA, ADE_RGBA_ },
+   { DRM_FORMAT_BGRA, ADE_BGRA_ },
+   { DRM_FORMAT_ARGB, ADE_ARGB_ },
+   { DRM_FORMAT_ABGR, ADE_ABGR_ },
+};
+
+static const u32 channel_formats1[] = {
+   /* channel 1,2,3,4 */
+   DRM_FORMAT_RGB565, DRM_FORMAT_BGR565, DRM_FORMAT_RGB888,
+   DRM_FORMAT_BGR888, DRM_FORMAT_XRGB, DRM_FORMAT_XBGR,
+   DRM_FORMAT_RGBA, DRM_FORMAT_BGRA, DRM_FORMAT_ARGB,
+   DRM_FORMAT_ABGR
+};
+
+u32 ade_get_channel_formats(u8 ch, const u32 **formats)
+{
+   switch (ch) {
+   case ADE_CH1:
+   *formats = channel_formats1;
+   return ARRAY_SIZE(channel_formats1);
+   default:
+   DRM_ERROR("no this channel %d\n", ch);
+   *formats = NULL;
+   return 0;
+   }
+}
+
+/* convert from fourcc format to ade format */
+static u32 ade_get_format(u32 pixel_format)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(ade_formats); i++)
+   if (ade_formats[i].pixel_format == pixel_format)
+   return ade_formats[i].ade_format;
+
+   /* not found */
+   DRM_ERROR("Not found pixel format!!fourcc_format= %d\n",
+ pixel_format);
+   return ADE_FORMAT_NOT_SUPPORT;
+}
+
 static void ade_update_reload_bit(void __iomem *base, u32 bit_num, u32 val)
 {
u32 bit_ofst, reg_num;
@@ -86,7 +161,7 @@ static void ade_init(struct ade_hw_ctx *ctx)
/* clear overlay */
writel(0, base + ADE_OVLY1_TRANS_CFG);
writel(0, base + ADE_OVLY_CTL);
-   writel(0, base + ADE_OVLYX_CTL(ADE_OVLY2));
+   writel(0, base + ADE_OVLYX_CTL(OUT_OVLY));
/* clear reset and reload regs */
writel(MASK(32), base + ADE_SOFT_RST_SEL(0));
writel(MASK(32), base + ADE_SOFT_RST_SEL(1));
@@ -144,6 +219,10 @@ static void ade_ldi_set_mode(struct ade_crtc *acrtc,
  mode->clock * 1000, ret);
adj_mode->clock = clk_get_rate(ctx->ade_pix_clk) / 1000;
 
+   /* set overlay compositor output size */
+   writel(((width - 1) << OUTPUT_XSIZE_OFST) | (height - 1),
+  base + ADE_OVLY_OUTPUT_SIZE(OUT_OVLY));
+
/* ctran6 setting */
writel(CTRAN_BYPASS_ON, base + ADE_CTRAN_DIS(ADE_CTRAN6));
 /* the configured value is actual value - 1 */
@@ -222,6 +301,10 @@ static void ade_display_enable(struct ade_crtc *acrtc)
void __iomem *base = ctx->base;
u32 out_fmt = acrtc->out_format;
 
+   /* enable output overlay compositor */
+   writel(ADE_ENABLE, base + ADE_OVLYX_CTL(OUT_OVLY));
+   ade_update_reload_bit(base, OVLY_OFST + OUT_OVLY, 0);
+
/* display source setting */
writel(DISP_SRC_OVLY2, base + ADE_DISP_SRC_CFG);
 
@@ -235,6 +318,97 @@ static void ade_display_enable(struct ade_crtc *acrtc)
writel(DSI_PCLK_ON, base + LDI_HDMI_DSI_GT);
 }
 
+#if ADE_DEBUG
+static void ade_rdma_dump_regs(void __iomem *base, u32 ch)
+{
+   u32 reg_ctrl, reg_addr, reg_size, reg_stride, reg_space, reg_en;
+   u32 val;
+
+

[PATCH v4 03/11] drm/hisilicon: Add crtc driver for ADE

[Xinliang Liu]

Add crtc funcs and helper funcs for ADE.

v4: None.
v3:
- Make ade as the master driver.
- Use port to connect with encoder.
- A few cleanup.
v2:
- Remove abtraction layer.

Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/hisilicon/kirin/Makefile|   3 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 280 +++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 458 
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  15 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |   8 +
 5 files changed, 763 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c

diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile 
b/drivers/gpu/drm/hisilicon/kirin/Makefile
index cb346de47d48..2a61ab006ddb 100644
--- a/drivers/gpu/drm/hisilicon/kirin/Makefile
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -1,3 +1,4 @@
-kirin-drm-y := kirin_drm_drv.o
+kirin-drm-y := kirin_drm_drv.o \
+  kirin_drm_ade.o
 
 obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
new file mode 100644
index ..78020747abfe
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
@@ -0,0 +1,280 @@
+/*
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#ifndef __KIRIN_ADE_REG_H__
+#define __KIRIN_ADE_REG_H__
+
+/*
+ * ADE Registers
+ */
+#define MASK(x)(BIT(x) - 1)
+
+#define ADE_CTRL   0x0004
+#define FRM_END_START_OFST 0
+#define FRM_END_START_MASK MASK(2)
+#define ADE_CTRL1  0x008C
+#define AUTO_CLK_GATE_EN_OFST  0
+#define AUTO_CLK_GATE_EN   BIT(0)
+#define ADE_ROT_SRC_CFG0x0010
+#define ADE_DISP_SRC_CFG   0x0018
+#define ADE_WDMA2_SRC_CFG  0x001C
+#define ADE_SEC_OVLY_SRC_CFG   0x0020
+#define ADE_WDMA3_SRC_CFG  0x0024
+#define ADE_OVLY1_TRANS_CFG0x002C
+#define ADE_EN 0x0100
+#define ADE_DISABLE0
+#define ADE_ENABLE 1
+#define INTR_MASK_CPU(x)   (0x0C10 + (x) * 0x4)
+#define ADE_FRM_DISGARD_CTRL   0x00A4
+/* reset and reload regs */
+#define ADE_SOFT_RST_SEL(x)(0x0078 + (x) * 0x4)
+#define ADE_RELOAD_DIS(x)  (0x00AC + (x) * 0x4)
+#define RDMA_OFST  0
+#define CLIP_OFST  15
+#define SCL_OFST   21
+#define CTRAN_OFST 24
+#define OVLY_OFST  37 /* 32+5 */
+/* channel regs */
+#define RD_CH_PE(x)(0x1000 + (x) * 0x80)
+#define RD_CH_CTRL(x)  (0x1004 + (x) * 0x80)
+#define RD_CH_ADDR(x)  (0x1008 + (x) * 0x80)
+#define RD_CH_SIZE(x)  (0x100C + (x) * 0x80)
+#define RD_CH_STRIDE(x)(0x1010 + (x) * 0x80)
+#define RD_CH_SPACE(x) (0x1014 + (x) * 0x80)
+#define RD_CH_PARTIAL_SIZE(x)  (0x1018 + (x) * 0x80)
+#define RD_CH_PARTIAL_SPACE(x) (0x101C + (x) * 0x80)
+#define RD_CH_EN(x)(0x1020 + (x) * 0x80)
+#define RD_CH_STATUS(x)(0x1024 + (x) * 0x80)
+#define RD_CH_DISP_CTRL0x1404
+#define RD_CH_DISP_ADDR0x1408
+#define RD_CH_DISP_SIZE0x140C
+#define RD_CH_DISP_STRIDE  0x1410
+#define RD_CH_DISP_SPACE   0x1414
+#define RD_CH_DISP_EN  0x142C
+/* clip regs */
+#define ADE_CLIP_DISABLE(x)(0x6800 + (x) * 0x100)
+#define ADE_CLIP_SIZE0(x)  (0x6804 + (x) * 0x100)
+#define ADE_CLIP_SIZE1(x)  (0x6808 + (x) * 0x100)
+#define ADE_CLIP_SIZE2(x)  (0x680C + (x) * 0x100)
+#define ADE_CLIP_CFG_OK(x) (0x6810 + (x) * 0x100)
+/* scale regs */
+#define ADE_SCL1_MUX_CFG   0x000C
+#define ADE_SCL2_SRC_CFG   0x0014
+#define ADE_SCL3_MUX_CFG   0x0008
+#define ADE_SCL_CTRL(x)(0x3000 + (x) * 0x800)
+#define ADE_SCL_HSP(x) (0x3004 + (x) * 0x800)
+#define ADE_SCL_UV_HSP(x)  (0x3008 + (x) * 0x800)
+#define ADE_SCL_VSP(x) (0x300C + (x) * 0x800)
+#define ADE_SCL_UV_VSP(x)  (0x3010 + (x) * 0x800)
+#define ADE_SCL_ORES(x)(0x3014 + (x) * 0x800)
+#define ADE_SCL_IRES(x)(0x3018 + (x) * 0x800)
+#define ADE_SCL_START(x)   (0x301C + (x) * 0x800)
+#define ADE_SCL_ERR(x)  

[PATCH v4 02/11] drm/hisilicon: Add hisilicon kirin drm master driver

[Xinliang Liu]

Add kirin DRM master driver for hi6220 SoC which used in HiKey board.
Add dumb buffer feature.
Add prime dmabuf feature.

v4: None.
v3:
- Move and rename all the files to kirin sub-directory.
  So that we could separate different seires SoCs' driver.
- Replace drm_platform_init, load, unload implementation.
v2:
- Remove abtraction layer.

Signed-off-by: Xinwei Kong 
Signed-off-by: Xinliang Liu 
---
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/hisilicon/Kconfig   |   5 +
 drivers/gpu/drm/hisilicon/Makefile  |   5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig |   9 +
 drivers/gpu/drm/hisilicon/kirin/Makefile|   3 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 321 
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |  20 ++
 8 files changed, 366 insertions(+)
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b50ae60f5f50..f5c5656e2547 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -277,3 +277,5 @@ source "drivers/gpu/drm/imx/Kconfig"
 source "drivers/gpu/drm/vc4/Kconfig"
 
 source "drivers/gpu/drm/etnaviv/Kconfig"
+
+source "drivers/gpu/drm/hisilicon/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 61766dec6a8d..60554832079c 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -74,3 +74,4 @@ obj-y += panel/
 obj-y  += bridge/
 obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
+obj-y  += hisilicon/
diff --git a/drivers/gpu/drm/hisilicon/Kconfig 
b/drivers/gpu/drm/hisilicon/Kconfig
new file mode 100644
index ..558c61b1b8e8
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+#
+# hisilicon drm device configuration.
+# Please keep this list sorted alphabetically
+
+source "drivers/gpu/drm/hisilicon/kirin/Kconfig"
diff --git a/drivers/gpu/drm/hisilicon/Makefile 
b/drivers/gpu/drm/hisilicon/Makefile
new file mode 100644
index ..e3f6d493c996
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for hisilicon drm drivers.
+# Please keep this list sorted alphabetically
+
+obj-$(CONFIG_DRM_HISI_KIRIN) += kirin/
diff --git a/drivers/gpu/drm/hisilicon/kirin/Kconfig 
b/drivers/gpu/drm/hisilicon/kirin/Kconfig
new file mode 100644
index ..3ac4b8edeac1
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/Kconfig
@@ -0,0 +1,9 @@
+config DRM_HISI_KIRIN
+   tristate "DRM Support for Hisilicon Kirin series SoCs Platform"
+   depends on DRM
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   help
+ Choose this option if you have a hisilicon Kirin chipsets(hi6220).
+ If M is selected the module will be called kirin-drm.
diff --git a/drivers/gpu/drm/hisilicon/kirin/Makefile 
b/drivers/gpu/drm/hisilicon/kirin/Makefile
new file mode 100644
index ..cb346de47d48
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/Makefile
@@ -0,0 +1,3 @@
+kirin-drm-y := kirin_drm_drv.o
+
+obj-$(CONFIG_DRM_HISI_KIRIN) += kirin-drm.o
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
new file mode 100644
index ..789ebd1f5922
--- /dev/null
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -0,0 +1,321 @@
+/*
+ * Hisilicon Kirin SoCs drm master driver
+ *
+ * Copyright (c) 2016 Linaro Limited.
+ * Copyright (c) 2014-2016 Hisilicon Limited.
+ *
+ * Author:
+ * Xinliang Liu 
+ * Xinliang Liu 
+ * Xinwei Kong 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "kirin_drm_drv.h"
+
+static struct kirin_dc_ops *dc_ops;
+
+static int kirin_drm_kms_cleanup(struct drm_device *dev)
+{
+   dc_ops->cleanup(dev);
+   drm_mode_config_cleanup(dev);
+
+   return 0;
+}
+
+static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
+   .fb_create = drm_fb_cma_create,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+};
+
+static void kirin_drm_mode_config_init(struct drm_device *dev)
+{
+   dev->mode_config.min_width = 0;
+   dev->mode_config.min_height = 0;
+
+   dev->mode_config.max_width = 2048;
+   de

[PATCH v4 00/11] Add DRM Driver for HiSilicon Kirin hi6220 SoC

[Xinliang Liu]

This patch set adds a new drm driver for HiSilicon Kirin hi6220 SoC.
Current testing and support board is Hikey board which is one of Linaro
96boards. It is an arm64 open source board. For more information about
this board, please access https://www.96boards.org.

Hardware Detail
---
  The display subsystem of Hi6220 SoC is shown as bellow:
 +-+   +--+ +-+ +-+
 | |   |  | | | | | 
 | FB  |-->|   ADE|>| DSI |>|   External  |
 | |   |  | | | |  HDMI/panel |
 +-+   +--+ +-+ +-+

- ADE(Advanced Display Engine) is the display controller. It contains 7
channels, 3 overlay compositors and a LDI.
  - A channel looks like: DMA-->clip-->scale-->ctrans(or called csc).
  - Overlay compositor is response to compose planes which come from 7
  channels and pass composed image to LDI.
  - LDI is response to generate timings and RGB data stream.
- DSI converts the RGB data stream from ADE to DSI packets.
- External HDMI/panel module is connected with DSI bus. Now Hikey use a
  ADI's ADV7533 external HDMI chip.

Change History
-
Changes in v4:
- Describe more specific of clocks and ports of binding docs.
- Fix indentation of binding docs.

Changes in v3:
- Move and rename all the files to kirin sub-directory.
  So that we could separate different seires SoCs' driver.
- Make ade as the drm master node.
- Replace drm_platform_init, load, unload implementation.
- Use assigned-clocks to set clock rate.
- Use ports to connect display relavant nodes.
- Rename hisi_drm_dsi.c to dw_drm_dsi.c
- Make encoder type as DRM_MODE_ENCODER_DSI.
- A few cleanup on regs and code.

Changes in v2:
- Remove abtraction layer of plane/crtc/encoder/connector.
- Refactor atomic implementation according to Daniel Vetter's guides:
http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html
http://blog.ffwll.ch/2015/09/xdc-2015-atomic-modesetting-for-drivers.html
http://blog.ffwll.ch/2015/08/atomic-modesetting-design-overview.html
- Use bridge instead of slave encoder to connect external HDMI.
- Move dt binding docs to bindings/display/hisilicon directory. 

Xinliang Liu (11):
  drm/hisilicon: Add device tree binding for hi6220 display subsystem
  drm/hisilicon: Add hisilicon kirin drm master driver
  drm/hisilicon: Add crtc driver for ADE
  drm/hisilicon: Add plane driver for ADE
  drm/hisilicon: Add vblank driver for ADE
  drm/hisilicon: Add cma fbdev and hotplug
  drm/hisilicon: Add designware dsi encoder driver
  drm/hisilicon: Add designware dsi host driver
  drm/hisilicon: Add support for external bridge
  MAINTAINERS: Add maintainer for hisilicon DRM driver
  arm64: dts: hisilicon: Add display subsystem DT nodes for hi6220

 .../bindings/display/hisilicon/dw-dsi.txt  |   77 ++
 .../bindings/display/hisilicon/hisi-ade.txt|   69 ++
 MAINTAINERS|   10 +
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts |   44 +
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |   53 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/hisilicon/Kconfig  |5 +
 drivers/gpu/drm/hisilicon/Makefile |5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig|   10 +
 drivers/gpu/drm/hisilicon/kirin/Makefile   |5 +
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c   |  845 
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h   |   83 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h|  280 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c| 1053 
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c|  382 +++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h|   31 +
 17 files changed, 2955 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

[Guenter Roeck]

On 02/05/2016 10:21 AM, Fu Wei wrote:

On 5 February 2016 at 22:42, Guenter Roeck  wrote:

On 02/05/2016 01:51 AM, Fu Wei wrote:


Hi Guenter,

On 4 February 2016 at 13:17, Guenter Roeck  wrote:


On 02/03/2016 03:00 PM, Fu Wei wrote:



On 4 February 2016 at 02:45, Timur Tabi  wrote:



Fu Wei wrote:




As you know I have made the pre-timeout support patch, If people like
it, i am happy to go on upstream it separately.

If we want to use pre-timeout here, user only can use get_pretimeout
and disable panic by setting pretimeout to 0
but user can not really set pretimeout, because "pre-timeout  ==
timeout / 2 (always)".
if user want to change pretimeout, he/she has to set_time instead.





Ok, I think patches 4 and 5 should be combined, and I think the Kconfig
entry should be removed and just use panic_enabled.




Agreed.



np, will do




NP, will update this patchset like that ,  thanks :-)



Also, if panic is enabled, the timeout needs to be adjusted accordingly
(to only panic after the entire timeout period has expired, not after
half of it). We can not panic the system after timeout / 2.



OK, my thought is

if panic is enabled :
|WOR---WS0WOR---WS1
|--timeout--(panic)--timeout-reset

if panic is disabled .
|WOR---WS0WOR---WS1
|-timeout-reset

   panic_enabled only can be configured when module is loaded by module
parameter

But user should know that max_timeout(panic_enable) =
max_timeout(panic_disable) / 2



That means you'll have to update max_timeout accordingly.


panic_enabled only can be configured when module is loaded, so we
don't need to update it.

max_timeout will only be set up in the init stage.

Does it make sense ? :-)


Not sure I understand your problem or question.

max_timeout will have to reflect the correct maximum timeout, under
all circumstances. It will have to be set to the correct value before
the watchdog driver is registered.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v16 1/6] fpga: add bindings document for fpga region

[Josh Cartwright]

Hey Alan-

First off, thanks for all of your (and others') work on this.

On Fri, Feb 05, 2016 at 03:29:58PM -0600, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> New bindings document for FPGA Region to support programming
> FPGA's under Device Tree control
> 
> Signed-off-by: Alan Tull 
> Signed-off-by: Moritz Fischer 
[..]
> ---
>  .../devicetree/bindings/fpga/fpga-region.txt   |  348 
> 
>  1 file changed, 348 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/fpga/fpga-region.txt
> 
> diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt 
> b/Documentation/devicetree/bindings/fpga/fpga-region.txt
> new file mode 100644
> index 000..ccd7127
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
[..]
> +FPGA Manager & FPGA Manager Framework
> + * An FPGA Manager is a hardware block that programs an FPGA under the 
> control
> +   of a host processor.
> + * The FPGA Manager Framework provides drivers and functions to program an
> +   FPGA.
> +
> +FPGA Bridge Framework
> + * Provides drivers and functions to control bridges that enable/disable
> +   data to the FPGA.
> + * FPGA Bridges should be disabled while the FPGA is being programmed to
> +   prevent spurious data on the bus.
> + * FPGA Bridges may not be needed in implementations where the FPGA Manager
> +   handles this.

It still seems strange for me architecturally for the FPGA Bridge to be
a first-class top-level concept in your architecture, as they are a
reflection of the SoC FPGA manager design.  That is, I would expect the
bridges not to be associated with the FPGA Region, but with the FPGA
manager.

Although, I will concede that you you've made it possible to not use
FPGA Bridges (like on Zynq where they aren't necessary), so maybe it
doesn't matter, just smells strangely.

> +Freeze Blocks
> + * Freeze Blocks function as FPGA Bridges within the FPGA fabric.  In the 
> case
> +   of PR, the buses from the processor are split within the FPGA.  Each PR
> +   region gets its own split of the buses, protected by an independently
> +   controlled Freeze Block.  Several busses may be connected to a single
> +   PR region; a Freeze Block controls the traffic of all these busses
> +   together.
> +
> +
[..]
> +Device Tree Examples
> +
> +
> +The intention of this section is to give some simple examples, focusing on
> +the placement of the elements detailed above, especially:
> + * FPGA Manager
> + * FPGA Bridges
> + * FPGA Region
> + * ranges
> + * target-path or target
> +
> +For the purposes of this section, I'm dividing the Device Tree into two 
> parts,
> +each with its own requirements.  The two parts are:
> + * The live DT prior to the overlay being added
> + * The DT overlay
> +
> +The live Device Tree must contain an FPGA Region, an FPGA Manager, and any 
> FPGA
> +Bridges.  The FPGA Region's "fpga-mgr" property specifies the manager by 
> phandle
> +to handle programming the FPGA.  If the FPGA Region is the child of another 
> FPGA
> +Region, the parent's FPGA Manager is used.  If FPGA Bridges need to be 
> involved,
> +they are specified in the FPGA Region by the "fpga-bridges" property.  During
> +FPGA programming, the FPGA Region will disable the bridges that are in its
> +"fpga-bridges" list and will re-enable them after FPGA programming has
> +succeeded.
> +
> +The Device Tree Overlay will contain:
> + * "target-path" or "target"
> +   The insertion point where the the contents of the overlay will go into the
> +   live tree.  target-path is a full path, while target is a phandle.
> + * "ranges"
> + * "firmware-name"
> +   Specifies the name of the FPGA image file on the firmware search
> +   path.  The search path is described in the firmware class documentation.
> + * "partial-reconfig"
> +   This binding is a boolean and should be present if partial reconfiguration
> +   is to be done.

Another architectural smell: there are categorically two different types
of properties here.  The first kind is those properties which describe
_what_ IP exists within the FPGA image (all of the nodes under the regions, 
etc).
The second kind of properties are those which describe _how_ the image
should be written (partial-reconfig, firmware-name).

It seems weird, but maybe it doesn't matter much.

Thanks,
  Josh


signature.asc
Description: PGP signature

[PATCH v16 3/6] ARM: socfpga: add bindings document for fpga bridge drivers

[atull]

From: Alan Tull 

Add bindings documentation for Altera SOCFPGA bridges:
 * fpga2sdram
 * fpga2hps
 * hps2fpga
 * lwhps2fpga

Signed-off-by: Alan Tull 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Dinh Nguyen 
---
v2:  separate into 2 documents for the 2 drivers
v12: bump version to line up with simple-fpga-bus version
 remove Linux specific notes such as references to sysfs
 move non-DT specific documentation elsewhere
 remove bindings that would have been used to pass configuration
 clean up formatting
v13: Remove 'label' property
 Change property from init-val to bridge-enable
 Fix email address
v14: Add resets
 Change order of bridges to put lw bridge (controlling bridge) first
v15: No change in this patch for v15 of this patch set
v16: Added regs property, cleaned up unit addresses
---
 .../bindings/fpga/altera-fpga2sdram-bridge.txt |   15 +++
 .../bindings/fpga/altera-hps2fpga-bridge.txt   |   47 
 2 files changed, 62 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt

diff --git 
a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt 
b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
new file mode 100644
index 000..4479a79
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
@@ -0,0 +1,15 @@
+Altera FPGA To SDRAM Bridge Driver
+
+Required properties:
+- compatible   : Should contain "altr,socfpga-fpga2sdram-bridge"
+
+Optional properties:
+- bridge-enable: 0 if driver should disable bridge at startup
+ 1 if driver should enable bridge at startup
+ Default is to leave bridge in current state.
+
+Example:
+   fpga2sdram_br {
+   compatible = "altr,socfpga-fpga2sdram-bridge";
+   bridge-enable = <0>;
+   };
diff --git a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt 
b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
new file mode 100644
index 000..e6b7474
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
@@ -0,0 +1,47 @@
+Altera FPGA/HPS Bridge Driver
+
+Required properties:
+- regs : base address and size for AXI bridge module
+- compatible   : Should contain one of:
+ "altr,socfpga-lwhps2fpga-bridge",
+ "altr,socfpga-hps2fpga-bridge", or
+ "altr,socfpga-fpga2hps-bridge"
+- reset-names  : Should contain one of:
+ "lwhps2fpga",
+ "hps2fpga", or
+ "fpga2hps"
+- resets   : Phandle and reset specifier for the reset listed in
+ reset-names
+- clocks   : Clocks used by this module.
+
+Optional properties:
+- bridge-enable: 0 if driver should disable bridge at startup.
+ 1 if driver should enable bridge at startup.
+ Default is to leave bridge in its current state.
+
+Example:
+   hps_fpgabridge0: fpgabridge@ff40 {
+   compatible = "altr,socfpga-lwhps2fpga-bridge";
+   reg = <0xff40 0x10>;
+   resets = <&rst LWHPS2FPGA_RESET>;
+   reset-names = "lwhps2fpga";
+   clocks = <&l4_main_clk>;
+   bridge-enable = <0>;
+   };
+
+   hps_fpgabridge1: fpgabridge@ff50 {
+   compatible = "altr,socfpga-hps2fpga-bridge";
+   reg = <0xff50 0x1>;
+   resets = <&rst HPS2FPGA_RESET>;
+   reset-names = "hps2fpga";
+   clocks = <&l4_main_clk>;
+   bridge-enable = <1>;
+   };
+
+   hps_fpgabridge2: fpgabridge@ff60 {
+   compatible = "altr,socfpga-fpga2hps-bridge";
+   reg = <0xff60 0x10>;
+   resets = <&rst FPGA2HPS_RESET>;
+   reset-names = "fpga2hps";
+   clocks = <&l4_main_clk>;
+   };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v16 0/6] Device Tree support for FPGA programming

[atull]

From: Alan Tull 

v16 Refactors the FPGA Area and FPGA Bus into single thing called an
FPGA Region and eliminates using simple-bus.  I'm using the word
"region" as it's a term is used in the literature of both the major
FPGA manufacturors.

Changes for v16:
* Refactor the FPGA Area and FPGA Bus into a FPGA Region.
* Don't use simple-bus.
* FPGA Managers and FPGA Bridges are now specified by phandle using the 
  "fpga-mgr" and "fpga-bridges" properties.  fpga-bridges can specify
  more than one bridge.
* Device Tree overlays should be targeted to a FPGA Region.
* The overlays need only contain firmware-name and the child nodes.
* To model a system containing >1 partial reconfiguration region,
  an overlay could add FPGA Regions to the base FPGA Regions.
* Child FPGA Regions inherit the parent FGPA Manager, but specify
  their own set of bridges if needes as partial reconfig regions
  will likely need their own bridges.
* All this is discussed in bindings/fpga/fpga-region.txt

One other highlight:
The little engine that runs this thing is a reconfig notifier
in fpga-region.c.  This notifier that will program an FPGA if a
"firmware-name" property gets added to a fpga-region.  Then
it will call of_platform_populate().  The current behavior in Linux
when a DT overlay is applied is that the reconfig notifications
go out in heirarchical order: first notifications are for the
properties, then notifications for the child nodes.  So an overlay
that adds a 'firmware-name' property and some child nodes to a
fpga-region will cause FPGA programming and child node
populating in the right order.

One issue with the dynamic DT stuff:
I've tried returning and error from the notifier if FPGA programming
fails; the error is noted on the console, but the child nodes
get probed anyway.


Alan Tull (6):
  fpga: add bindings document for fpga region
  add sysfs document for fpga bridge class
  ARM: socfpga: add bindings document for fpga bridge drivers
  fpga: add fpga bridge framework
  fpga: fpga-region: device tree control for FPGA
  ARM: socfpga: fpga bridge driver support

 Documentation/ABI/testing/sysfs-class-fpga-bridge  |   11 +
 .../bindings/fpga/altera-fpga2sdram-bridge.txt |   15 +
 .../bindings/fpga/altera-hps2fpga-bridge.txt   |   47 ++
 .../devicetree/bindings/fpga/fpga-region.txt   |  348 +++
 drivers/fpga/Kconfig   |   21 +
 drivers/fpga/Makefile  |7 +
 drivers/fpga/altera-fpga2sdram.c   |  174 
 drivers/fpga/altera-hps2fpga.c |  213 +
 drivers/fpga/fpga-bridge.c |  388 +
 drivers/fpga/fpga-region.c |  460 
 include/linux/fpga/fpga-bridge.h   |   55 +++
 11 files changed, 1739 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-bridge
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
 create mode 100644 Documentation/devicetree/bindings/fpga/fpga-region.txt
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c
 create mode 100644 drivers/fpga/fpga-bridge.c
 create mode 100644 drivers/fpga/fpga-region.c
 create mode 100644 include/linux/fpga/fpga-bridge.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v16 4/6] fpga: add fpga bridge framework

[atull]

From: Alan Tull 

This framework adds API functions for enabling/
disabling FPGA bridges under kernel control.

This allows the Linux kernel to disable FPGA bridges
during FPGA reprogramming and to enable FPGA bridges
when FPGA reprogramming is done.  This framework is
be manufacturer-agnostic, allowing it to be used in
interfaces that use the FPGA Manager Framework to
reprogram FPGA's.

The functions are:
* of_fpga_bridge_get
* fpga_bridge_put
   Get/put an exclusive reference to a FPGA bridge.

* fpga_bridge_enable
* fpga_bridge_disable
   Enable/Disable traffic through a bridge.

* fpga_bridge_register
* fpga_bridge_unregister
   Register/unregister a device-specific low level FPGA
   Bridge driver.

Get an exclusive reference to a bridge and add it to a list:
* fpga_bridge_get_to_list

To enable/disable/put a set of bridges that are on a list:
* fpga_bridges_enable
* fpga_bridges_disable
* fpga_bridges_put

Signed-off-by: Alan Tull 
---
v2:  Minor cleanup
v12: Bump version to line up with simple fpga bus
 Remove sysfs
 Improve get/put functions, get the low level driver too.
 Clean up class implementation
 Add kernel doc documentation
 Rename (un)register_fpga_bridge -> fpga_bridge_(un)register
v13: Add inlined empty functions for if not CONFIG_FPGA_BRIDGE
 Clean up debugging
 Remove unneeded #include in .h
 Remove unnecessary prints
 Remove 'label' DT binding.
 Document the mutex
v14: Allow bridges with no ops
 *const* struct fpga_bridge_ops
 Add functions to git/put/enable/disable list of bridges
 Add list node to struct fpga_bridge
 Do of_node_get/put in of_fpga_bridge_get()
 Add r/o attributes: name and state
v15: No change in this patch for v15 of this patch set
v16: Remove of_get_fpga_bus function
---
 drivers/fpga/Kconfig |7 +
 drivers/fpga/Makefile|3 +
 drivers/fpga/fpga-bridge.c   |  388 ++
 include/linux/fpga/fpga-bridge.h |   55 ++
 4 files changed, 453 insertions(+)
 create mode 100644 drivers/fpga/fpga-bridge.c
 create mode 100644 include/linux/fpga/fpga-bridge.h

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index c9b9fdf..b6cfd89 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -24,6 +24,13 @@ config FPGA_MGR_ZYNQ_FPGA
help
  FPGA manager driver support for Xilinx Zynq FPGAs.
 
+config FPGA_BRIDGE
+   bool "FPGA Bridge Framework"
+   depends on OF
+   help
+ Say Y here if you want to support bridges connected between host
+processors and FPGAs or between FPGAs.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8d83fc6..4baef00 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -8,3 +8,6 @@ obj-$(CONFIG_FPGA)  += fpga-mgr.o
 # FPGA Manager Drivers
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
+
+# FPGA Bridge Drivers
+obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
diff --git a/drivers/fpga/fpga-bridge.c b/drivers/fpga/fpga-bridge.c
new file mode 100644
index 000..5119d8e
--- /dev/null
+++ b/drivers/fpga/fpga-bridge.c
@@ -0,0 +1,388 @@
+/*
+ * FPGA Bridge Framework Driver
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_IDA(fpga_bridge_ida);
+static struct class *fpga_bridge_class;
+
+/* Lock for adding/removing bridges to linked lists*/
+spinlock_t bridge_list_lock;
+
+static int fpga_bridge_of_node_match(struct device *dev, const void *data)
+{
+   return dev->of_node == data;
+}
+
+/**
+ * fpga_bridge_enable - Enable transactions on the bridge
+ *
+ * @bridge: FPGA bridge
+ *
+ * Return: 0 for success, error code otherwise.
+ */
+int fpga_bridge_enable(struct fpga_bridge *bridge)
+{
+   dev_dbg(&bridge->dev, "enable\n");
+
+   if (bridge->br_ops && bridge->br_ops->enable_set)
+   return bridge->br_ops->enable_set(bridge, 1);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(fpga_bridge_enable);
+
+/**
+ * fpga_bridge_disable - Disable transactions on the bridge
+ *
+ * @bridge: FPGA bridge
+ *
+ * Return: 0 for success, error code otherwise.
+ */
+int fpga_bridge_disable(struct fpga_bridge *bridge)
+{

[PATCH v16 6/6] ARM: socfpga: fpga bridge driver support

[atull]

From: Alan Tull 

Supports Altera SOCFPGA bridges:
 * fpga2sdram
 * fpga2hps
 * hps2fpga
 * lwhps2fpga

Allows enabling/disabling the bridges through the FPGA
Bridge Framework API functions.

The fpga2sdram driver only supports enabling and disabling
of the ports that been configured early on.  This is due to
a hardware limitation where the read, write, and command
ports on the fpga2sdram bridge can only be reconfigured
while there are no transactions to the sdram, i.e. when
running out of OCRAM before the kernel boots.

Device tree property 'init-val' configures the driver to
enable or disable the bridge during probe.  If the property
does not exist, the driver will leave the bridge in its
current state.

Signed-off-by: Alan Tull 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Dinh Nguyen 
---
v2:  Use resets instead of directly writing reset registers
v12: Bump version to align with simple-fpga-bus version
 Get rid of the sysfs interface
 fpga2sdram: get configuration stored in handoff register
v13: Remove unneeded WARN_ON
 Change property from init-val to bridge-enable
 Checkpatch cleanup
 Fix email address
v14: use module_platform_driver
 remove unused struct field and some #defines
 don't really need exclamation points on error msgs
 *const* struct fpga_bridge_ops
v15: No change in this patch for v15 of this patch set
v16: No change in this patch for v16 of this patch set
---
 drivers/fpga/Kconfig |7 ++
 drivers/fpga/Makefile|1 +
 drivers/fpga/altera-fpga2sdram.c |  174 +++
 drivers/fpga/altera-hps2fpga.c   |  213 ++
 4 files changed, 395 insertions(+)
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index c419d4b..45fd823 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -38,6 +38,13 @@ config FPGA_BRIDGE
  Say Y here if you want to support bridges connected between host
 processors and FPGAs or between FPGAs.
 
+config SOCFPGA_FPGA_BRIDGE
+   bool "Altera SoCFPGA FPGA Bridges"
+   depends on ARCH_SOCFPGA && FPGA_BRIDGE
+   help
+ Say Y to enable drivers for FPGA bridges for Altera SOCFPGA
+ devices.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8d746c3..e658436 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)  += zynq-fpga.o
 
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
+obj-$(CONFIG_SOCFPGA_FPGA_BRIDGE)  += altera-hps2fpga.o altera-fpga2sdram.o
 
 # High Level Interfaces
 obj-$(CONFIG_FPGA_REGION)  += fpga-region.o
diff --git a/drivers/fpga/altera-fpga2sdram.c b/drivers/fpga/altera-fpga2sdram.c
new file mode 100644
index 000..91f4a40
--- /dev/null
+++ b/drivers/fpga/altera-fpga2sdram.c
@@ -0,0 +1,174 @@
+/*
+ * FPGA to SDRAM Bridge Driver for Altera SoCFPGA Devices
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+/*
+ * This driver manages a bridge between an FPGA and the SDRAM used by the ARM
+ * host processor system (HPS).
+ *
+ * The bridge contains 4 read ports, 4 write ports, and 6 command ports.
+ * Reconfiguring these ports requires that no SDRAM transactions occur during
+ * reconfiguration.  The code reconfiguring the ports cannot run out of SDRAM
+ * nor can the FPGA access the SDRAM during reconfiguration.  This driver does
+ * not support reconfiguring the ports.  The ports are configured by code
+ * running out of on chip ram before Linux is started and the configuration
+ * is passed in a handoff register in the system manager.
+ *
+ * This driver supports enabling and disabling of the configured ports, which
+ * allows for safe reprogramming of the FPGA, assuming that the new FPGA image
+ * uses the same port configuration.  Bridges must be disabled before
+ * reprogramming the FPGA and re-enabled after the FPGA has been programmed.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ALT_SDR_CTL_FPGAPORTRST_OFST   0x80
+#define ALT_SDR_CTL_FPGAPORTRST_PORTRSTN_MSK   0x3fff
+#define ALT_SDR_CTL_FPGAPORTRST_RD_SHIFT   0
+#define ALT_SDR_CTL_FPGAPOR

[PATCH v16 5/6] fpga: fpga-region: device tree control for FPGA

[atull]

From: Alan Tull 

FPGA Regions support programming FPGA under control of the Device
Tree.

Signed-off-by: Alan Tull 
---
v9:  initial version (this patch added during rest of patchset's v9)
v10: request deferral if fpga mgr or bridges not available yet
 cleanup as fpga manager core goes into the real kernel
 Don't assume bridges are disabled before programming FPGA
 Don't hang onto reference for fpga manager
 Move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
 Use fpga bridges framework.
v13: If no bridges are specified, assume we don't need any.
 Clean up debug messages
 Some dev_info -> dev_dbg
 Remove unneeded #include
 Fix size of array of pointers
 Don't need to specify .owner
 Use common binding: firmware-name
v14: OK it's not a simple bus.  Call it "FPGA Area"
 Remove bindings that specify FPGA manager and FPGA bridges
 Use parent FPGA bridge and bridges that are its peers
 Use ancestor FPGA Manager
v15: Add altr,fpga-bus implementation
 Change compatible string "fpga-area" -> "altr,fpga-area"
v16: Much changes as FPGA Areas and Busses become FPGA Regions
 Add reconfig notifier, don't rely on simple-bus
---
 drivers/fpga/Kconfig   |7 +
 drivers/fpga/Makefile  |3 +
 drivers/fpga/fpga-region.c |  460 
 3 files changed, 470 insertions(+)
 create mode 100644 drivers/fpga/fpga-region.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index b6cfd89..c419d4b 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -13,6 +13,13 @@ config FPGA
 
 if FPGA
 
+config FPGA_REGION
+   bool "FPGA Region"
+   depends on OF
+   help
+FPGA Regions allow loading FPGA images under control of
+the Device Tree.
+
 config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 4baef00..8d746c3 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -11,3 +11,6 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)  += zynq-fpga.o
 
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
+
+# High Level Interfaces
+obj-$(CONFIG_FPGA_REGION)  += fpga-region.o
diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
new file mode 100644
index 000..eb4d3a6
--- /dev/null
+++ b/drivers/fpga/fpga-region.c
@@ -0,0 +1,460 @@
+/*
+ * FPGA Region - Device Tree support for FPGA programming under Linux
+ *
+ *  Copyright (C) 2013-2016 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct fpga_region - FPGA Region structure
+ * @dev: FPGA Region device
+ * @mutex: enforces exclusive reference to region
+ * @bridge_list: list of FPGA bridges specified in region
+ */
+struct fpga_region {
+   struct device dev;
+   struct mutex mutex; /* for exclusive reference to region */
+   struct list_head bridge_list;
+};
+
+#define to_fpga_region(d) container_of(d, struct fpga_region, dev)
+
+static DEFINE_IDA(fpga_region_ida);
+static struct class *fpga_region_class;
+
+static const struct of_device_id fpga_region_of_match[] = {
+   { .compatible = "fpga-region", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, fpga_region_of_match);
+
+static int fpga_region_of_node_match(struct device *dev, const void *data)
+{
+   return dev->of_node == data;
+}
+
+/**
+ * fpga_region_find - find FPGA region
+ * @np: device node of FPGA Region
+ * Caller will need to put_device(®ion->dev) when done.
+ * Returns FPGA Region struct or NULL
+ */
+static struct fpga_region *fpga_region_find(struct device_node *np)
+{
+   struct device *dev;
+
+   dev = class_find_device(fpga_region_class, NULL, np,
+   fpga_region_of_node_match);
+   if (!dev) {
+   pr_err("%s did not find FPGA Region in class: %s\n", __func__,
+  np->full_name);
+   return NULL;
+   }
+
+   return to_fpga_region(dev);
+}
+
+/**
+ * fpga_region_get - get an exclusive reference to a fpga region
+ * @region: FPGA Region struct
+ *
+ * Caller should call fpga_region_put() when done with region.
+ *
+ * Return fpga_region struct if successf

[PATCH v16 2/6] add sysfs document for fpga bridge class

[atull]

From: Alan Tull 

Add documentation for new FPGA bridge class's sysfs interface.

Signed-off-by: Alan Tull 
--
v15: Document added in v15 of patch set
v16: No change to this patch in v16 of patch set
---
 Documentation/ABI/testing/sysfs-class-fpga-bridge |   11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-bridge

diff --git a/Documentation/ABI/testing/sysfs-class-fpga-bridge 
b/Documentation/ABI/testing/sysfs-class-fpga-bridge
new file mode 100644
index 000..312ae2c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-fpga-bridge
@@ -0,0 +1,11 @@
+What:  /sys/class/fpga_bridge//name
+Date:  January 2016
+KernelVersion: 4.5
+Contact:   Alan Tull 
+Description:   Name of low level FPGA bridge driver.
+
+What:  /sys/class/fpga_bridge//state
+Date:  January 2016
+KernelVersion: 4.5
+Contact:   Alan Tull 
+Description:   Show bridge state as "enabled" or "disabled"
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v16 1/6] fpga: add bindings document for fpga region

[atull]

From: Alan Tull 

New bindings document for FPGA Region to support programming
FPGA's under Device Tree control

Signed-off-by: Alan Tull 
Signed-off-by: Moritz Fischer 
---
v9:  initial version added to this patchset
v10: s/fpga/FPGA/g
 replace DT overlay example with slightly more complicated example
 move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
 Changed to use FPGA bridges framework instead of resets
 for bridges.
v13: bridge@0xff2 -> bridge@ff20, etc
 Leave out directly talking about overlays
 Remove regs and clocks directly under simple-fpga-bus in example
 Use common "firmware-name" binding instead of "fpga-firmware"
v14: Use firmware-name in bindings description
 Call it FPGA Area
 Remove bindings that specify FPGA Manager and FPGA Bridges
v15: Cleanup as per Rob's comments
 Combine usage doc with bindings document
 Document as being Altera specific
 Additions and changes to add FPGA Bus
v16: Reworked to document FPGA Regions
 rename altera-fpga-bus-fpga-area.txt -> fpga-region.txt
 Remove references that made it sound exclusive to Altera
 Remove altr, prefix from fpga-bus and fpga-area compatible strings
 Added Moritz' usage example with Xilinx
 Cleaned up unit addresses
---
 .../devicetree/bindings/fpga/fpga-region.txt   |  348 
 1 file changed, 348 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/fpga-region.txt

diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt 
b/Documentation/devicetree/bindings/fpga/fpga-region.txt
new file mode 100644
index 000..ccd7127
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
@@ -0,0 +1,348 @@
+FPGA Region Device Tree Binding
+
+Alan Tull 2016
+
+ CONTENTS
+ - Introduction
+ - Terminology
+ - Overview
+ - Constraints
+ - FPGA Region
+ - Supported Use Models
+ - Sequence
+ - Device Tree Examples
+
+
+Introduction
+
+
+FPGA Regions are introduced as a way to solve the problem of how to program an
+FPGA under an operating system and have the new hardware show up in the device
+tree.  By adding these bindings to the Device Tree, a system can have the
+information needed to program the FPGA and add the desired hardware, and also
+the information about the devices to be added to the Device Tree once the
+programming has succeeded.
+
+
+Terminology
+===
+
+Full Reconfiguration
+ * The entire FPGA is programmed.
+
+Partial Reconfiguration (PR)
+Partial Reconfiguration Region (PRR)
+ * The FPGA is divided into regions.  Each of these regions can be programmed
+   while the rest of the FPGA is not affected.  Not all FPGA's support this.
+ * PRR's may vary in size and in the connections at their edge.  The image
+   that is loaded into a PRR must fit and must use a subset of the region's
+   connections.
+
+Base image
+ * An FPGA image that is designed to do full reconfiguration of the FPGA.
+ * A base image may set up a set of regions to allow for partial
+   reconfiguration.
+
+Persona
+ * An FPGA image that is designed to be loaded into a PRR.  There may be
+   any number of personas designed to fit into a PRR, but only one at at time
+   may be loaded.
+ * A persona may create more regions.
+
+FPGA Manager & FPGA Manager Framework
+ * An FPGA Manager is a hardware block that programs an FPGA under the control
+   of a host processor.
+ * The FPGA Manager Framework provides drivers and functions to program an
+   FPGA.
+
+FPGA Bridge Framework
+ * Provides drivers and functions to control bridges that enable/disable
+   data to the FPGA.
+ * FPGA Bridges should be disabled while the FPGA is being programmed to
+   prevent spurious data on the bus.
+ * FPGA Bridges may not be needed in implementations where the FPGA Manager
+   handles this.
+
+Freeze Blocks
+ * Freeze Blocks function as FPGA Bridges within the FPGA fabric.  In the case
+   of PR, the buses from the processor are split within the FPGA.  Each PR
+   region gets its own split of the buses, protected by an independently
+   controlled Freeze Block.  Several busses may be connected to a single
+   PR region; a Freeze Block controls the traffic of all these busses
+   together.
+
+
+Overview
+
+
+This binding introduces the FPGA Region.
+
+An FPGA Region references the devices needed to be able to program an FPGA
+device.  The base FPGA Region in the device tree is required to include a
+property with a phandle to an FPGA Manager.  This region may also contain a
+property that has a list of FPGA Bridge phandles, if needed.  Child FPGA 
Regions
+inherit the parent's FPGA Manager but specify their own bridges.
+
+The base FPGA Region supports full reconfiguration of the FPGA device.  If the
+FPGA image loaded contains the logic that creates a set of Partial
+Reconfiguration Regions, then the DT that programs the FPGA should also add a
+set of FPGA Regi

[PATCH v4 3/3] rtc-pcf2123: implement read_offset and set_offset

[Joshua Clayton]

pcf2123 has an offset register, which can be used to make minor
adjustments to the clock rate to compensate for temperature or
a crystal that is not exactly right.

Signed-off-by: Joshua Clayton 
---
 drivers/rtc/rtc-pcf2123.c | 57 +++
 1 file changed, 57 insertions(+)

diff --git a/drivers/rtc/rtc-pcf2123.c b/drivers/rtc/rtc-pcf2123.c
index d9a44ad..da27738 100644
--- a/drivers/rtc/rtc-pcf2123.c
+++ b/drivers/rtc/rtc-pcf2123.c
@@ -100,6 +100,7 @@
 /* PCF2123_REG_OFFSET BITS */
 #define OFFSET_SIGN_BITBIT(6)  /* 2's complement sign bit */
 #define OFFSET_COARSE  BIT(7)  /* Coarse mode offset */
+#define OFFSET_STEP(2170)  /* Offset step in parts per billion */
 
 /* READ/WRITE ADDRESS BITS */
 #define PCF2123_WRITE  BIT(4)
@@ -206,6 +207,59 @@ static ssize_t pcf2123_store(struct device *dev, struct 
device_attribute *attr,
return count;
 }
 
+static int pcf2123_read_offset(struct device *dev, long *offset)
+{
+   int ret;
+   s8 reg;
+
+   ret = pcf2123_read(dev, PCF2123_REG_OFFSET, ®, 1);
+   if (ret < 0)
+   return ret;
+
+   if (reg & OFFSET_COARSE)
+   reg <<= 1; /* multiply by 2 and sign extend */
+   else
+   reg |= (reg & OFFSET_SIGN_BIT) << 1; /* sign extend only */
+
+   *offset = ((long)reg) * OFFSET_STEP;
+
+   return 0;
+}
+
+/*
+ * The offset register is a 7 bit signed value with a coarse bit in bit 7.
+ * The main difference between the two is normal offset adjusts the first
+ * second of n minutes every other hour, with 61, 62 and 63 being shoved
+ * into the 60th minute.
+ * The coarse adjustment does the same, but every hour.
+ * the two overlap, with every even normal offset value corresponding
+ * to a coarse offset. Based on this algorithm, it seems that despite the
+ * name, coarse offset is a better fit for overlapping values.
+ */
+static int pcf2123_set_offset(struct device *dev, long offset)
+{
+   s8 reg;
+
+   if (offset > OFFSET_STEP * 127)
+   reg = 127;
+   else if (offset < OFFSET_STEP * -128)
+   reg = -128;
+   else
+   reg = (s8)((offset + (OFFSET_STEP >> 1)) / OFFSET_STEP);
+
+   /* choose fine offset only for odd values in the normal range */
+   if (reg & 1 && reg <= 63 && reg >= -64) {
+   /* Normal offset. Clear the coarse bit */
+   reg &= ~OFFSET_COARSE;
+   } else {
+   /* Coarse offset. Divide by 2 and set the coarse bit */
+   reg >>= 1;
+   reg |= OFFSET_COARSE;
+   }
+
+   return pcf2123_write_reg(dev, PCF2123_REG_OFFSET, reg);
+}
+
 static int pcf2123_rtc_read_time(struct device *dev, struct rtc_time *tm)
 {
u8 rxbuf[7];
@@ -314,6 +368,9 @@ static int pcf2123_reset(struct device *dev)
 static const struct rtc_class_ops pcf2123_rtc_ops = {
.read_time  = pcf2123_rtc_read_time,
.set_time   = pcf2123_rtc_set_time,
+   .read_offset= pcf2123_read_offset,
+   .set_offset = pcf2123_set_offset,
+
 };
 
 static int pcf2123_probe(struct spi_device *spi)
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/3] rtc: implement a sysfs interface for clock offset

[Joshua Clayton]

clock offset may be set and read in decimal parts per billion
attribute is /sys/class/rtc/rtcN/offset
The attribute is only visible for rtcs that have set_offset implemented.

Signed-off-by: Joshua Clayton 
---
 Documentation/rtc.txt   |  6 ++
 drivers/rtc/rtc-sysfs.c | 35 ++-
 2 files changed, 40 insertions(+), 1 deletion(-)

diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt
index 8446f1e..ddc3660 100644
--- a/Documentation/rtc.txt
+++ b/Documentation/rtc.txt
@@ -157,6 +157,12 @@ wakealarm:  The time at which the clock will generate a 
system wakeup
 the epoch by default, or if there's a leading +, seconds in the
 future, or if there is a leading +=, seconds ahead of the 
current
 alarm.
+offset: The amount which the rtc clock has been adjusted in 
firmware.
+Visible only if the driver supports clock offset adjustment.
+The unit is parts per billion, i.e. The number of clock ticks
+which are added to or removed from the rtc's base clock per
+billion ticks. A positive value makes a day pass more slowly,
+longer, and a negative value makes a day pass more quickly.
 
 IOCTL INTERFACE
 ---
diff --git a/drivers/rtc/rtc-sysfs.c b/drivers/rtc/rtc-sysfs.c
index 463e286..63b9fb1 100644
--- a/drivers/rtc/rtc-sysfs.c
+++ b/drivers/rtc/rtc-sysfs.c
@@ -218,6 +218,34 @@ wakealarm_store(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_RW(wakealarm);
 
+static ssize_t
+offset_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+   ssize_t retval;
+   long offset;
+
+   retval = rtc_read_offset(to_rtc_device(dev), &offset);
+   if (retval == 0)
+   retval = sprintf(buf, "%ld\n", offset);
+
+   return retval;
+}
+
+static ssize_t
+offset_store(struct device *dev, struct device_attribute *attr,
+const char *buf, size_t n)
+{
+   ssize_t retval;
+   long offset;
+
+   retval = kstrtol(buf, 10, &offset);
+   if (retval == 0)
+   retval = rtc_set_offset(to_rtc_device(dev), offset);
+
+   return (retval < 0) ? retval : n;
+}
+static DEVICE_ATTR_RW(offset);
+
 static struct attribute *rtc_attrs[] = {
&dev_attr_name.attr,
&dev_attr_date.attr,
@@ -226,6 +254,7 @@ static struct attribute *rtc_attrs[] = {
&dev_attr_max_user_freq.attr,
&dev_attr_hctosys.attr,
&dev_attr_wakealarm.attr,
+   &dev_attr_offset.attr,
NULL,
 };
 
@@ -249,9 +278,13 @@ static umode_t rtc_attr_is_visible(struct kobject *kobj,
struct rtc_device *rtc = to_rtc_device(dev);
umode_t mode = attr->mode;
 
-   if (attr == &dev_attr_wakealarm.attr)
+   if (attr == &dev_attr_wakealarm.attr) {
if (!rtc_does_wakealarm(rtc))
mode = 0;
+   } else if (attr == &dev_attr_offset.attr) {
+   if (!rtc->ops->set_offset)
+   mode = 0;
+   }
 
return mode;
 }
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/3] rtc: Add functions to set and read rtc offset

[Joshua Clayton]

A number of rtc devices, such as the NXP pcf2123 include a facility
to adjust the clock in order to compensate for temperature or a
crystal, capacitor, etc, that results in the rtc clock not running
at exactly 32.768 kHz.

Data sheets I have seen refer to this as a clock offset, and measure it
in parts per million, however they often reference ppm to 2 digits of
precision, which makes integer ppm less than ideal.

We use parts per billion, which more than covers the precision needed
and works nicely within 32 bits

Signed-off-by: Joshua Clayton 
---
 drivers/rtc/interface.c | 54 +
 include/linux/rtc.h |  4 
 2 files changed, 58 insertions(+)

diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 5836751..9ef5f6f 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -939,4 +939,58 @@ void rtc_timer_cancel(struct rtc_device *rtc, struct 
rtc_timer *timer)
mutex_unlock(&rtc->ops_lock);
 }
 
+/**
+ * rtc_read_offset - Read the amount of rtc offset in parts per billion
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * see below for details.
+ *
+ * Kernel interface to read rtc clock offset
+ * Returns 0 on success, or a negative number on error.
+ * If read_offset() is not implemented for the rtc, return -EINVAL
+ */
+int rtc_read_offset(struct rtc_device *rtc, long *offset)
+{
+   int ret;
+
+   if (!rtc->ops)
+   return -ENODEV;
+
+   if (!rtc->ops->read_offset)
+   return -EINVAL;
+
+   mutex_lock(&rtc->ops_lock);
+   ret = rtc->ops->read_offset(rtc->dev.parent, offset);
+   mutex_unlock(&rtc->ops_lock);
+   return ret;
+}
 
+/**
+ * rtc_set_offset - Adjusts the duration of the average second
+ * @ rtc: rtc device to be used
+ * @ offset: the offset in parts per billion
+ *
+ * Some rtc's allow an adjustment to the average duration of a second
+ * to compensate for differences in the actual clock rate due to temperature,
+ * the crystal, capacitor, etc.
+ *
+ * Kernel interface to adjust an rtc clock offset.
+ * Return 0 on success, or a negative number on error.
+ * If the rtc offset is not setable (or not implemented), return -EINVAL
+ */
+int rtc_set_offset(struct rtc_device *rtc, long offset)
+{
+   int ret;
+
+   if (!rtc->ops)
+   return -ENODEV;
+
+   if (!rtc->ops->set_offset)
+   return -EINVAL;
+
+   mutex_lock(&rtc->ops_lock);
+   ret = rtc->ops->set_offset(rtc->dev.parent, offset);
+   mutex_unlock(&rtc->ops_lock);
+   return ret;
+}
diff --git a/include/linux/rtc.h b/include/linux/rtc.h
index 3359f04..b693ada 100644
--- a/include/linux/rtc.h
+++ b/include/linux/rtc.h
@@ -89,6 +89,8 @@ struct rtc_class_ops {
int (*set_mmss)(struct device *, unsigned long secs);
int (*read_callback)(struct device *, int data);
int (*alarm_irq_enable)(struct device *, unsigned int enabled);
+   int (*read_offset)(struct device *, long *offset);
+   int (*set_offset)(struct device *, long offset);
 };
 
 #define RTC_DEVICE_NAME_SIZE 20
@@ -208,6 +210,8 @@ void rtc_timer_init(struct rtc_timer *timer, void (*f)(void 
*p), void *data);
 int rtc_timer_start(struct rtc_device *rtc, struct rtc_timer *timer,
ktime_t expires, ktime_t period);
 void rtc_timer_cancel(struct rtc_device *rtc, struct rtc_timer *timer);
+int rtc_read_offset(struct rtc_device *rtc, long *offset);
+int rtc_set_offset(struct rtc_device *rtc, long offset);
 void rtc_timer_do_work(struct work_struct *work);
 
 static inline bool is_leap_year(unsigned int year)
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

[Fu Wei]

On 5 February 2016 at 22:42, Guenter Roeck  wrote:
> On 02/05/2016 01:51 AM, Fu Wei wrote:
>>
>> Hi Guenter,
>>
>> On 4 February 2016 at 13:17, Guenter Roeck  wrote:
>>>
>>> On 02/03/2016 03:00 PM, Fu Wei wrote:


 On 4 February 2016 at 02:45, Timur Tabi  wrote:
>
>
> Fu Wei wrote:
>>
>>
>>
>> As you know I have made the pre-timeout support patch, If people like
>> it, i am happy to go on upstream it separately.
>>
>> If we want to use pre-timeout here, user only can use get_pretimeout
>> and disable panic by setting pretimeout to 0
>> but user can not really set pretimeout, because "pre-timeout  ==
>> timeout / 2 (always)".
>> if user want to change pretimeout, he/she has to set_time instead.
>
>
>
>
> Ok, I think patches 4 and 5 should be combined, and I think the Kconfig
> entry should be removed and just use panic_enabled.
>>>
>>>
>>>
>>> Agreed.
>>
>>
>> np, will do
>>


 NP, will update this patchset like that ,  thanks :-)

>>>
>>> Also, if panic is enabled, the timeout needs to be adjusted accordingly
>>> (to only panic after the entire timeout period has expired, not after
>>> half of it). We can not panic the system after timeout / 2.
>>
>>
>> OK, my thought is
>>
>> if panic is enabled :
>> |WOR---WS0WOR---WS1
>> |--timeout--(panic)--timeout-reset
>>
>> if panic is disabled .
>> |WOR---WS0WOR---WS1
>> |-timeout-reset
>>
>>   panic_enabled only can be configured when module is loaded by module
>> parameter
>>
>> But user should know that max_timeout(panic_enable) =
>> max_timeout(panic_disable) / 2
>>
>
> That means you'll have to update max_timeout accordingly.

panic_enabled only can be configured when module is loaded, so we
don't need to update it.

max_timeout will only be set up in the init stage.

Does it make sense ? :-)

>
>>>
>>> I am not too happy with the parameter name (panic_enabled). How about
>>> "action", to match machzwd ?
>>
>>
>> yes, makes sense. Maybe we can do something  like this:
>>
>> /*
>>   * action refers to action taken when watchdog gets WS0
>>   * 0 = SKIP
>>   * 1 = PANIC
>>   * defaults to SKIP (0)
>>   */
>> static int action;
>> module_param(action, int, 0);
>> MODULE_PARM_DESC(action, "after watchdog gets WS0 interrupt, do: "
>> "0 = SKIP(*)  1 = PANIC");
>>
> Yes, though I would suggest to use lower case letters.

yes,  NP, will do , Thanks :-)

>
> Thanks,
> Guenter
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Mathieu Poirier]

On 5 February 2016 at 05:52, Alexander Shishkin
 wrote:
> Chunyan Zhang  writes:
>
>> From: Mathieu Poirier 
>>
>> Some architecture like ARM assign masterIDs statically at the HW design
>> phase, making masterID manipulation in the generic STM core irrelevant.
>>
>> This patch adds a new 'mstatic' flag to struct stm_data that tells the
>> core that this specific STM device doesn't need explicit masterID
>> management.
>
> So why do we need this patch? If your STM only has master 42 allocated
> for software sources, simply set sw_start = 42, sw_end = 42 and you're
> good to go, software will have exactly one channel to choose from. See
> also the comment from :

On ARM each source, i.e entity capable of accessing STM channels, has
a different master ID set in HW.  We can't assume the IDs are
contiguous and from a SW point of view there is no way to probe the
values.

>
>  * @sw_start:   first STP master available to software
>  * @sw_end: last STP master available to software
>
> particularly the "available to software" part. Any other kinds of
> masters the STM class code doesn't care about (yet).
>
>> In the core sw_start/end of masterID are set to '1',
>> i.e there is only one masterID to deal with.
>
> This is also a completely arbitrary and unnecessary requirement. Again,
> you can set both to 42 and it will still work.

True - any value will do. The important thing to remember is that on
ARM, there is only one masterID channel (from an STM core point of
view).  But we could also proceed differently, see below for more
details.

>
>> Also this patch depends on [1], so that the number of masterID
>> is '1' too.
>>
>> Finally the lower and upper bound for masterIDs as presented
>> in ($SYSFS)/class/stm/XYZ.stm/masters and
>> ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
>> are set to '-1'.  That way users can't confuse them with
>> architecture where masterID management is required (where any
>> other value would be valid).
>
> Why is this a good idea? Having the actual master there will allow
> software to know what it is and also tell the decoding side what it is
> (assuming you have more than one source in the STP stream, it might not
> be easy to figure out, unless you know it in advance).

In the ARM world masterIDs are irrelevant so why bother with them?
Writing a '-1' simply highlight this reality.

Another way of approaching the problem would be to change sw_start/end
to a bitfield that represent the valid masterIDs but in my opinion, it
is a lot of code churn for information that isn't used outside of the
decoder.

Thanks,
Mathieu

>
> I don't see how one master statically assigned to software sources is
> different from two masters or 32 masters. And I don't see any benefit of
> hiding the master id from userspace. Am I missing something?
>
> Regards,
> --
> Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Mike Leach]

Hi,

I think a quick clarification of the ARM hardware STM architecture may be of 
value here.

The ARM hardware STM, when implemented as recommend in a hardware design, the 
master IDs are not under driver control, but have a hardwire association with 
source devices in the system. The master IDs are hardwired to individual cores 
and core security states, and there could be other IDs associated with hardware 
trace sources requiring output via the hardware STM. (an example of this is the 
ARM Juno development board).

Therefore in multi-core systems many masters may be associated with a single 
software STM stream. A user-space application running on Core 1, may have a 
master ID of 0x11 in the STPv2 trace stream, but if this application is context 
switched and later continues running on Core 2, then master ID could change to 
0x21.  Masters identify a hardware source in this scheme, the precise values 
used will be implementation dependent.

So the number of masters "available to the software" depends on your 
interpretation of the phrase.
If you mean "master IDs on which software trace will appear" then that will be 
many - it depends on which core is running the application. However as 
described above, this is not predictable by any decoder, and the master set 
used may not be contiguous.
If you mean "master IDs selectable/allocated by the driver" then that will be 0 
- the driver has no control, and possibly no knowledge of which master is 
associated with the current execution context. (this is of course system 
dependent - it may well be possible to have some configuration database 
associating cores with hardware IDs, but this will be implementation and board 
support dependant).

Therefore, there is a requirement to tell both the user-space STM client and 
decoder that not only is master ID management not needed - it is in fact not 
possible and the key to identify the software source for a given STM packet is 
the channel alone. In addition we have a nominal single Master ID "available to 
the software", to satisfy the requirements of the generic ST module API.

So on Juno for example, while we do have 128 masters, each with 65536 channels, 
the master allocation is not visible to system software - each core sees a 
single master with 65536 channels. Therefore differentiation between software 
sources in the STM trace is by channel number allocations only.

Best Regards

Mike.


Mike Leach   +44 (0)1254 893911 (Direct)
Principal Engineer   +44 (0)1254 893900 (Main)
Arm Blackburn Design Centre  +44 (0)1254 893901 (Fax)
Belthorn House
Walker Rdmailto:mike.le...@arm.com
Guide
Blackburn
BB1 2QE



> -Original Message-
> From: Alexander Shishkin [mailto:alexander.shish...@linux.intel.com]
> Sent: 05 February 2016 12:52
> To: Chunyan Zhang; mathieu.poir...@linaro.org
> Cc: r...@kernel.org; broo...@kernel.org; prat...@codeaurora.org;
> nicolas.gu...@st.com; cor...@lwn.net; Mark Rutland; Mike Leach;
> t...@ti.com; Al Grant; zhang.l...@gmail.com; linux-ker...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-...@vger.kernel.org; linux-
> d...@vger.kernel.org
> Subject: Re: [PATCH V2 3/6] stm class: provision for statically assigned
> masterIDs
>
> Chunyan Zhang  writes:
>
> > From: Mathieu Poirier 
> >
> > Some architecture like ARM assign masterIDs statically at the HW design
> > phase, making masterID manipulation in the generic STM core irrelevant.
> >
> > This patch adds a new 'mstatic' flag to struct stm_data that tells the
> > core that this specific STM device doesn't need explicit masterID
> > management.
>
> So why do we need this patch? If your STM only has master 42 allocated
> for software sources, simply set sw_start = 42, sw_end = 42 and you're
> good to go, software will have exactly one channel to choose from. See
> also the comment from :
>
>  * @sw_start:   first STP master available to software
>  * @sw_end: last STP master available to software
>
> particularly the "available to software" part. Any other kinds of
> masters the STM class code doesn't care about (yet).
>
> > In the core sw_start/end of masterID are set to '1',
> > i.e there is only one masterID to deal with.
>
> This is also a completely arbitrary and unnecessary requirement. Again,
> you can set both to 42 and it will still work.
>
> > Also this patch depends on [1], so that the number of masterID
> > is '1' too.
> >
> > Finally the lower and upper bound for masterIDs as presented
> > in ($SYSFS)/class/stm/XYZ.stm/masters and
> > ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
> > are set to '-1'.  That way users can't confuse them with
> > architecture where masterID management is required (where any
> > other value would be valid).
>
> Why is this a good idea? H

Re: module: s390: keep mod_arch_specific for livepatch modules

[Miroslav Benes]

On Thu, 4 Feb 2016, Josh Poimboeuf wrote:

> On Wed, Feb 03, 2016 at 08:37:52PM -0500, Jessica Yu wrote:
> > +++ Jessica Yu [03/02/16 20:11 -0500]:
> > >Livepatch needs to utilize the symbol information contained in the
> > >mod_arch_specific struct in order to be able to call the s390
> > >apply_relocate_add() function to apply relocations. Keep a reference to
> > >syminfo if the module is a livepatch module. Remove the redundant vfree()
> > >in module_finalize() since module_arch_freeing_init() (which also frees
> > >those structures) is called in do_init_module(). If the module isn't a
> > >livepatch module, we free the structures in module_arch_freeing_init() as
> > >usual.
> > >
> > >Signed-off-by: Jessica Yu 
> > >---
> > >arch/s390/kernel/module.c | 7 +--
> > >1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > I must note that I have verified that the patchset boots on s390 and
> > that the sample livepatch module still works ...so that's good, but
> > not saying much since what we really want is to test the relocation
> > code. The kpatch build scripts however currently only support x86, so
> > the next step is for me to port the kpatch scripts to s390 before I
> > can really test this patchset. This in itself might take a while, so
> > in the meantime I'd like to just collect another round of comments and
> > feedback for v4.
> 
> I haven't reviewed the code yet, but otherwise I'm thinking it would
> actually be fine to merge this patch set before testing with s390
> relocations.  They aren't implemented on s390 today anyway, so there
> can't be a regression if nobody is using it.

I asked Jessica to test it with s390 relocations. It would be great to 
know it works on an architecture which originally inspired this patch set. 
However it should not be a blocker. There are advantages apart from this 
and we can happily merge it before testing.

I am going to review the patch set early next week...

Miroslav
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

[Guenter Roeck]

On 02/05/2016 01:51 AM, Fu Wei wrote:

Hi Guenter,

On 4 February 2016 at 13:17, Guenter Roeck  wrote:

On 02/03/2016 03:00 PM, Fu Wei wrote:


On 4 February 2016 at 02:45, Timur Tabi  wrote:


Fu Wei wrote:



As you know I have made the pre-timeout support patch, If people like
it, i am happy to go on upstream it separately.

If we want to use pre-timeout here, user only can use get_pretimeout
and disable panic by setting pretimeout to 0
but user can not really set pretimeout, because "pre-timeout  ==
timeout / 2 (always)".
if user want to change pretimeout, he/she has to set_time instead.




Ok, I think patches 4 and 5 should be combined, and I think the Kconfig
entry should be removed and just use panic_enabled.



Agreed.


np, will do




NP, will update this patchset like that ,  thanks :-)



Also, if panic is enabled, the timeout needs to be adjusted accordingly
(to only panic after the entire timeout period has expired, not after
half of it). We can not panic the system after timeout / 2.


OK, my thought is

if panic is enabled :
|WOR---WS0WOR---WS1
|--timeout--(panic)--timeout-reset

if panic is disabled .
|WOR---WS0WOR---WS1
|-timeout-reset

  panic_enabled only can be configured when module is loaded by module parameter

But user should know that max_timeout(panic_enable) =
max_timeout(panic_disable) / 2



That means you'll have to update max_timeout accordingly.



I am not too happy with the parameter name (panic_enabled). How about
"action", to match machzwd ?


yes, makes sense. Maybe we can do something  like this:

/*
  * action refers to action taken when watchdog gets WS0
  * 0 = SKIP
  * 1 = PANIC
  * defaults to SKIP (0)
  */
static int action;
module_param(action, int, 0);
MODULE_PARM_DESC(action, "after watchdog gets WS0 interrupt, do: "
"0 = SKIP(*)  1 = PANIC");


Yes, though I would suggest to use lower case letters.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 6/6] coresight-stm: adding driver for CoreSight STM component

[Arnd Bergmann]

On Friday 05 February 2016 15:06:20 Alexander Shishkin wrote:
> Chunyan Zhang  writes:
> 
> > +#ifndef CONFIG_64BIT
> > +static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
> > +{
> > + asm volatile("strd %1, %0"
> > +  : "+Qo" (*(volatile u64 __force *)addr)
> > +  : "r" (val));
> > +}
> 
> Is it really ok to do this for all !64bit arms, inside a driver, just
> like that? I'm not an expert, but I'm pretty sure there's more to it.

It's normally device dependent whether this works or not, on 32-bit
architectures, a 64-bit access to an I/O bus tends to get split into
two 32 bit accesses and the order might not be the as what was
intended.

We have functions in include/linux/io-64-nonatomic-hi-lo.h
and include/linux/io-64-nonatomic-lo-hi.h that are meant to
do this right. Maybe the driver can be changed to use whichever
one is correct for it.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

[Thomas Petazzoni]

Hello,

On Fri, 5 Feb 2016 07:08:23 -0600, Timur Tabi wrote:

> > I'm quite certainly missing something completely obvious here, but how
> > can you get the WS1 interrupt*after*  raising a panic? Aren't all
> > interrupts disabled and the system fully halted once you get a panic(),
> > especially when raised from an interrupt handler? If that's the case,
> > how can the system continue to do things, such as receiving the WS1
> > interrupt and resetting ?
> 
> Typically, WS1 is not an interrupt.  Instead, it's a hard system-level 
> reset.

Ah, right, true. I missed that aspect because on my HW, triggering a
system-level reset on WS1 is optional. I can actually get an interrupt
on both WS0 and WS1, and no reset at all.

But a normal configuration indeed involves having the WS1 event
configured in HW to be a system-level reset.

So, OK, it makes sense. Thanks for the clarification!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

[Thomas Petazzoni]

Hello,

On Fri, 5 Feb 2016 17:51:52 +0800, Fu Wei wrote:

> OK, my thought is
> 
> if panic is enabled :
> |WOR---WS0WOR---WS1
> |--timeout--(panic)--timeout-reset

I'm quite certainly missing something completely obvious here, but how
can you get the WS1 interrupt *after* raising a panic? Aren't all
interrupts disabled and the system fully halted once you get a panic(),
especially when raised from an interrupt handler? If that's the case,
how can the system continue to do things, such as receiving the WS1
interrupt and resetting ?

Again, I'm probably missing something obvious, but I'm interested to
understand the reasoning here.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

[Timur Tabi]

Thomas Petazzoni wrote:

if panic is enabled :
>|WOR---WS0WOR---WS1
>|--timeout--(panic)--timeout-reset



I'm quite certainly missing something completely obvious here, but how
can you get the WS1 interrupt*after*  raising a panic? Aren't all
interrupts disabled and the system fully halted once you get a panic(),
especially when raised from an interrupt handler? If that's the case,
how can the system continue to do things, such as receiving the WS1
interrupt and resetting ?


Typically, WS1 is not an interrupt.  Instead, it's a hard system-level 
reset.


The hardware is capable of generating an interrupt for both WS0 and WS1. 
 However, the ACPI table only contains one interrupt value, and it's 
not clear whether that's supposed to be the WS0 interrupt or the WS1 
interrupts.


So this whole thing does assume a specfic watchdog configuration.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 6/6] coresight-stm: adding driver for CoreSight STM component

[Alexander Shishkin]

Chunyan Zhang  writes:

> +#ifndef CONFIG_64BIT
> +static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
> +{
> + asm volatile("strd %1, %0"
> +  : "+Qo" (*(volatile u64 __force *)addr)
> +  : "r" (val));
> +}

Is it really ok to do this for all !64bit arms, inside a driver, just
like that? I'm not an expert, but I'm pretty sure there's more to it.

Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 1/6] stm class: Add ioctl get_options interface

[Alexander Shishkin]

Chunyan Zhang  writes:

> There is already an interface of set_options, but no get_options yet.
> Before setting any options, one would may want to see the current
> status of that option by means of get_options interface. This
> interface has been used in CoreSight STM driver.
>
> Signed-off-by: Chunyan Zhang 
> ---
>  drivers/hwtracing/stm/core.c | 11 +++
>  include/linux/stm.h  |  3 +++
>  include/uapi/linux/stm.h |  1 +
>  3 files changed, 15 insertions(+)
>
> diff --git a/drivers/hwtracing/stm/core.c b/drivers/hwtracing/stm/core.c
> index b6445d9..86bb4e3 100644
> --- a/drivers/hwtracing/stm/core.c
> +++ b/drivers/hwtracing/stm/core.c
> @@ -571,6 +571,17 @@ stm_char_ioctl(struct file *file, unsigned int cmd, 
> unsigned long arg)
>   options);
>  
>   break;
> +
> + case STP_GET_OPTIONS:
> + if (stm_data->get_options)
> + err = stm_data->get_options(stm_data,
> + stmf->output.master,
> + stmf->output.channel,
> + stmf->output.nr_chans,
> + &options);
> +
> + return copy_to_user((void __user *)arg, &options, sizeof(u64));

The return value of copy_to_user() is not what you assume it is.

Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 3/6] stm class: provision for statically assigned masterIDs

[Alexander Shishkin]

Chunyan Zhang  writes:

> From: Mathieu Poirier 
>
> Some architecture like ARM assign masterIDs statically at the HW design
> phase, making masterID manipulation in the generic STM core irrelevant.
>
> This patch adds a new 'mstatic' flag to struct stm_data that tells the
> core that this specific STM device doesn't need explicit masterID
> management.

So why do we need this patch? If your STM only has master 42 allocated
for software sources, simply set sw_start = 42, sw_end = 42 and you're
good to go, software will have exactly one channel to choose from. See
also the comment from :

 * @sw_start:   first STP master available to software
 * @sw_end: last STP master available to software

particularly the "available to software" part. Any other kinds of
masters the STM class code doesn't care about (yet).

> In the core sw_start/end of masterID are set to '1',
> i.e there is only one masterID to deal with.

This is also a completely arbitrary and unnecessary requirement. Again,
you can set both to 42 and it will still work.

> Also this patch depends on [1], so that the number of masterID
> is '1' too.
>
> Finally the lower and upper bound for masterIDs as presented
> in ($SYSFS)/class/stm/XYZ.stm/masters and
> ($SYSFS)/../stp-policy/XYZ.stm.my_policy/some_device/masters
> are set to '-1'.  That way users can't confuse them with
> architecture where masterID management is required (where any
> other value would be valid).

Why is this a good idea? Having the actual master there will allow
software to know what it is and also tell the decoding side what it is
(assuming you have more than one source in the STP stream, it might not
be easy to figure out, unless you know it in advance).

I don't see how one master statically assigned to software sources is
different from two masters or 32 masters. And I don't see any benefit of
hiding the master id from userspace. Am I missing something?

Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

[Fu Wei]

Hi Guenter,

On 4 February 2016 at 13:17, Guenter Roeck  wrote:
> On 02/03/2016 03:00 PM, Fu Wei wrote:
>>
>> On 4 February 2016 at 02:45, Timur Tabi  wrote:
>>>
>>> Fu Wei wrote:


 As you know I have made the pre-timeout support patch, If people like
 it, i am happy to go on upstream it separately.

 If we want to use pre-timeout here, user only can use get_pretimeout
 and disable panic by setting pretimeout to 0
 but user can not really set pretimeout, because "pre-timeout  ==
 timeout / 2 (always)".
 if user want to change pretimeout, he/she has to set_time instead.
>>>
>>>
>>>
>>> Ok, I think patches 4 and 5 should be combined, and I think the Kconfig
>>> entry should be removed and just use panic_enabled.
>
>
> Agreed.

np, will do

>>
>>
>> NP, will update this patchset like that ,  thanks :-)
>>
>
> Also, if panic is enabled, the timeout needs to be adjusted accordingly
> (to only panic after the entire timeout period has expired, not after
> half of it). We can not panic the system after timeout / 2.

OK, my thought is

if panic is enabled :
|WOR---WS0WOR---WS1
|--timeout--(panic)--timeout-reset

if panic is disabled .
|WOR---WS0WOR---WS1
|-timeout-reset

 panic_enabled only can be configured when module is loaded by module parameter

But user should know that max_timeout(panic_enable) =
max_timeout(panic_disable) / 2

>
> I am not too happy with the parameter name (panic_enabled). How about
> "action", to match machzwd ?

yes, makes sense. Maybe we can do something  like this:

/*
 * action refers to action taken when watchdog gets WS0
 * 0 = SKIP
 * 1 = PANIC
 * defaults to SKIP (0)
 */
static int action;
module_param(action, int, 0);
MODULE_PARM_DESC(action, "after watchdog gets WS0 interrupt, do: "
"0 = SKIP(*)  1 = PANIC");


>
> Thanks,
> Guenter
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 5/5] Watchdog: ARM SBSA Generic Watchdog half timeout panic support

[Fu Wei]

On 5 February 2016 at 00:43, Timur Tabi  wrote:
> Mathieu Poirier wrote:
>>>
>>> >+#ifdef CONFIG_ARM_SBSA_WATCHDOG_PANIC
>>> >+   irq = platform_get_irq(pdev, 0);
>>> >+   if (irq < 0) {
>>> >+   dev_err(dev, "unable to get ws0 interrupt.\n");
>>> >+   return irq;
>>> >+   }
>>> >+#endif
>>> >+
>>
>> Can't the driver revert to single stage mode if platform_get_irq()
>> fails?  That way the value of 'irq' can be tested throughout the
>> _probe() function and the #ifdefs removed.
>
>
> I like that idea.  The same can be done with the devm_request_irq() call.
> It should definitely still display a warning if the command-line option is
> set but no interrupt is available.

Yes, I agree with that too, brilliant idea, this will be in v11 patchset



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver

[Fu Wei]

On 5 February 2016 at 00:25, Mathieu Poirier  wrote:
> On 3 February 2016 at 10:18,   wrote:
>> From: Fu Wei 
>>
>> According to Server Base System Architecture (SBSA) specification,
>> the SBSA Generic Watchdog has two stage timeouts: the first signal (WS0)
>> is for alerting the system by interrupt, the second one (WS1) is a real
>> hardware reset.
>>
>> This patch initially implements a simple single stage watchdog driver:
>> when the timeout is reached, your system will be reset by the second
>> signal (WS1).
>> The first signal (WS0) is ignored in this driver.
>>
>> This driver bases on linux kernel watchdog framework, so it can get
>> timeout from module parameter and FDT at the driver init stage.
>>
>> Signed-off-by: Fu Wei 
>> Reviewed-by: Graeme Gregory 
>> Tested-by: Pratyush Anand 
>> ---
>>  drivers/watchdog/Kconfig |  17 +++
>>  drivers/watchdog/Makefile|   1 +
>>  drivers/watchdog/sbsa_gwdt.c | 322 
>> +++
>>  3 files changed, 340 insertions(+)
>>
>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>> index 4f0e7be..4ab1b05 100644
>> --- a/drivers/watchdog/Kconfig
>> +++ b/drivers/watchdog/Kconfig
>> @@ -201,6 +201,23 @@ config ARM_SP805_WATCHDOG
>>   ARM Primecell SP805 Watchdog timer. This will reboot your system 
>> when
>>   the timeout is reached.
>>
>> +config ARM_SBSA_WATCHDOG
>> +   tristate "ARM SBSA Generic Watchdog"
>> +   depends on ARM64
>> +   depends on ARM_ARCH_TIMER
>> +   select WATCHDOG_CORE
>> +   help
>> + ARM SBSA Generic Watchdog has two stage timeouts:
>> + the first signal (WS0) is for alerting the system by interrupt,
>> + the second one (WS1) is a real hardware reset.
>> + More details: ARM DEN0029B - Server Base System Architecture (SBSA)
>> +
>> + This is a simple single stage driver: when the timeout is reached,
>> + your system will be reset by WS1. The first signal (WS0) is 
>> ignored.
>> +
>> + To compile this driver as module, choose M here: The module
>> + will be called sbsa_gwdt.
>> +
>>  config ASM9260_WATCHDOG
>> tristate "Alphascale ASM9260 watchdog"
>> depends on MACH_ASM9260
>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
>> index f566753..f9826d4 100644
>> --- a/drivers/watchdog/Makefile
>> +++ b/drivers/watchdog/Makefile
>> @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
>>
>>  # ARM Architecture
>>  obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
>> +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o
>>  obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o
>>  obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
>>  obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
>> diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
>> new file mode 100644
>> index 000..5a2dba3
>> --- /dev/null
>> +++ b/drivers/watchdog/sbsa_gwdt.c
>> @@ -0,0 +1,322 @@
>> +/*
>> + * SBSA(Server Base System Architecture) Generic Watchdog driver
>> + *
>> + * Copyright (c) 2015, Linaro Ltd.
>> + * Author: Fu Wei 
>> + * Suravee Suthikulpanit 
>> + * Al Stone 
>> + * Timur Tabi 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License 2 as published
>> + * by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * This SBSA Generic watchdog driver is a single stage timeout version.
>> + * Since this watchdog timer has two stages, and each stage is determined
>> + * by WOR. So the timeout is (WOR * 2).
>> + * When first timeout is reached, WS0 is triggered, the interrupt
>> + * triggered by WS0 will be ignored, then the second watch period starts;
>> + * when second timeout is reached, then WS1 is triggered, system reset.
>> + *
>> + * More details about the hardware specification of this device:
>> + * ARM DEN0029B - Server Base System Architecture (SBSA)
>> + *
>> + * SBSA GWDT: |WOR---WS0WOR---WS1
>> + *|timeoutreset
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* SBSA Generic Watchdog register definitions */
>> +/* refresh frame */
>> +#define SBSA_GWDT_WRR  0x000
>> +
>> +/* control frame */
>> +#define SBSA_GWDT_WCS  0x000
>> +#define SBSA_GWDT_WOR  0x008
>> +#define SBSA_GWDT_WCV  0x010
>> +
>> +/* refresh/control frame */
>> +#define SBSA_GWDT_W_IIDR   0xfcc
>> +#define SBSA_GWDT_IDR 

Re: [PATCH v10 4/5] Watchdog: introduce ARM SBSA watchdog driver

[Fu Wei]

Hi

On 5 February 2016 at 00:46, Guenter Roeck  wrote:
> On 02/04/2016 08:37 AM, Timur Tabi wrote:
>>
>> Will Deacon wrote:

 +static int sbsa_gwdt_keepalive(struct watchdog_device *wdd)
 >+{
 >+struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
 >+
 >+/*
 >+* Writing WRR for an explicit watchdog refresh.
 >+* You can write anyting(like 0xc0ffee).
 >+*/
 >+writel(0xc0ffee, gwdt->refresh_base + SBSA_GWDT_WRR);
 >+
 >+return 0;
 >+}
>>>
>>> You might get in trouble for that. 0xd09f00d is probably less poisonous.
>>>
>>> http://www.petpoisonhelpline.com/poison/caffeine/
>>
>>
>> Any reason why we can't just keep it simple and write 0?
>
>
> +1

yes, we can, just "0" would be fine, will do.

Thanks :-)

>
> Guenter
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html