* [PATCH v2 10/12] drm/sun4i: Implement A83T HDMI driver
From: Jernej Skrabec @ 2018-01-10 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110192512.19684-1-jernej.skrabec@siol.net>
A83T has DW HDMI IP block with a custom PHY similar to Synopsys gen2
HDMI PHY.
Only video output was tested, while HW also supports audio and CEC.
Support for them will be added later.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
drivers/gpu/drm/sun4i/Kconfig | 9 +
drivers/gpu/drm/sun4i/Makefile | 4 +
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 183 ++++++++++++++++++++
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 51 ++++++
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 302 +++++++++++++++++++++++++++++++++
5 files changed, 549 insertions(+)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
create mode 100644 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 882d85db9053..7327da3bc94f 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -40,6 +40,15 @@ config DRM_SUN4I_BACKEND
do some alpha blending and feed graphics to TCON. If M is
selected the module will be called sun4i-backend.
+config DRM_SUN8I_DW_HDMI
+ tristate "Support for Allwinner version of DesignWare HDMI"
+ depends on DRM_SUN4I
+ select DRM_DW_HDMI
+ help
+ Choose this option if you have an Allwinner SoC with the
+ DesignWare HDMI controller with custom HDMI PHY. If M is
+ selected the module will be called sun8i_dw_hdmi.
+
config DRM_SUN8I_MIXER
tristate "Support for Allwinner Display Engine 2.0 Mixer"
default MACH_SUN8I
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 2b37a6abbb1d..a7c47d9aa64d 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,6 +9,9 @@ sun4i-drm-hdmi-y += sun4i_hdmi_enc.o
sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
+sun8i-drm-hdmi-y += sun8i_dw_hdmi.o
+sun8i-drm-hdmi-y += sun8i_hdmi_phy.o
+
sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
sun8i_vi_layer.o sun8i_ui_scaler.o \
sun8i_vi_scaler.o sun8i_csc.o
@@ -26,4 +29,5 @@ obj-$(CONFIG_DRM_SUN4I) += sun6i_drc.o
obj-$(CONFIG_DRM_SUN4I_BACKEND) += sun4i-backend.o
obj-$(CONFIG_DRM_SUN4I_HDMI) += sun4i-drm-hdmi.o
+obj-$(CONFIG_DRM_SUN8I_DW_HDMI) += sun8i-drm-hdmi.o
obj-$(CONFIG_DRM_SUN8I_MIXER) += sun8i-mixer.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
new file mode 100644
index 000000000000..afb9f5f988a9
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -0,0 +1,183 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Jernej Skrabec <jernej.skrabec@siol.net>
+ */
+
+#include <linux/component.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+#include <drm/drm_of.h>
+#include <drm/drmP.h>
+#include <drm/drm_crtc_helper.h>
+
+#include "sun8i_dw_hdmi.h"
+
+static void sun8i_dw_hdmi_encoder_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adj_mode)
+{
+ struct sun8i_dw_hdmi *hdmi = encoder_to_sun8i_dw_hdmi(encoder);
+
+ sun8i_hdmi_phy_update_clock(hdmi->phy, mode->crtc_clock * 1000);
+}
+
+static const struct drm_encoder_helper_funcs
+sun8i_dw_hdmi_encoder_helper_funcs = {
+ .mode_set = sun8i_dw_hdmi_encoder_mode_set,
+};
+
+static const struct drm_encoder_funcs sun8i_dw_hdmi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
+static enum drm_mode_status
+sun8i_dw_hdmi_mode_valid(struct drm_connector *connector,
+ const struct drm_display_mode *mode)
+{
+ if (mode->clock > 297000)
+ return MODE_BAD;
+
+ return MODE_OK;
+}
+
+static void sun8i_dw_hdmi_deinit(const struct dw_hdmi_plat_data *plat_data)
+{
+ struct sun8i_dw_hdmi *hdmi = plat_data_to_sun8i_dw_hdmi(plat_data);
+
+ sun8i_hdmi_phy_remove(hdmi);
+
+ reset_control_assert(hdmi->rst_ctrl);
+}
+
+static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
+ void *data)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dw_hdmi_plat_data *plat_data;
+ struct drm_device *drm = data;
+ struct device_node *phy_node;
+ struct drm_encoder *encoder;
+ struct sun8i_dw_hdmi *hdmi;
+ int ret;
+
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
+ hdmi = devm_kzalloc(&pdev->dev, sizeof(*hdmi), GFP_KERNEL);
+ if (!hdmi)
+ return -ENOMEM;
+
+ plat_data = &hdmi->plat_data;
+ hdmi->dev = &pdev->dev;
+ encoder = &hdmi->encoder;
+
+ encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
+ /*
+ * If we failed to find the CRTC(s) which this encoder is
+ * supposed to be connected to, it's because the CRTC has
+ * not been registered yet. Defer probing, and hope that
+ * the required CRTC is added later.
+ */
+ if (encoder->possible_crtcs == 0)
+ return -EPROBE_DEFER;
+
+ hdmi->rst_ctrl = devm_reset_control_get(dev, "ctrl");
+ if (IS_ERR(hdmi->rst_ctrl)) {
+ dev_err(dev, "Could not get ctrl reset control\n");
+ return PTR_ERR(hdmi->rst_ctrl);
+ }
+
+ ret = reset_control_deassert(hdmi->rst_ctrl);
+ if (ret) {
+ dev_err(dev, "Could not deassert ctrl reset control\n");
+ return ret;
+ }
+
+ phy_node = of_parse_phandle(dev->of_node, "phys", 0);
+ if (!phy_node) {
+ dev_err(dev, "Can't found PHY phandle\n");
+ goto err_assert_ctrl_reset;
+ }
+
+ ret = sun8i_hdmi_phy_probe(hdmi, phy_node);
+ of_node_put(phy_node);
+ if (ret) {
+ dev_err(dev, "Couldn't get the HDMI PHY\n");
+ goto err_assert_ctrl_reset;
+ }
+
+ drm_encoder_helper_add(encoder, &sun8i_dw_hdmi_encoder_helper_funcs);
+ drm_encoder_init(drm, encoder, &sun8i_dw_hdmi_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
+
+ sun8i_hdmi_phy_init(hdmi->phy);
+
+ plat_data->deinit = &sun8i_dw_hdmi_deinit;
+ plat_data->mode_valid = &sun8i_dw_hdmi_mode_valid;
+ plat_data->phy_ops = sun8i_hdmi_phy_get_ops();
+ plat_data->phy_name = "sun8i_dw_hdmi_phy";
+ plat_data->phy_data = hdmi->phy;
+
+ ret = dw_hdmi_bind(pdev, encoder, plat_data);
+
+ /*
+ * If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
+ * which would have called the encoder cleanup. Do it manually.
+ */
+ if (ret)
+ goto cleanup_encoder;
+
+ return 0;
+
+cleanup_encoder:
+ drm_encoder_cleanup(encoder);
+ sun8i_hdmi_phy_remove(hdmi);
+err_assert_ctrl_reset:
+ reset_control_assert(hdmi->rst_ctrl);
+
+ return ret;
+}
+
+static void sun8i_dw_hdmi_unbind(struct device *dev, struct device *master,
+ void *data)
+{
+ return dw_hdmi_unbind(dev);
+}
+
+static const struct component_ops sun8i_dw_hdmi_ops = {
+ .bind = sun8i_dw_hdmi_bind,
+ .unbind = sun8i_dw_hdmi_unbind,
+};
+
+static int sun8i_dw_hdmi_probe(struct platform_device *pdev)
+{
+ return component_add(&pdev->dev, &sun8i_dw_hdmi_ops);
+}
+
+static int sun8i_dw_hdmi_remove(struct platform_device *pdev)
+{
+ component_del(&pdev->dev, &sun8i_dw_hdmi_ops);
+
+ return 0;
+}
+
+static const struct of_device_id sun8i_dw_hdmi_dt_ids[] = {
+ { .compatible = "allwinner,sun8i-a83t-dw-hdmi" },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, sun8i_dw_hdmi_dt_ids);
+
+struct platform_driver sun8i_dw_hdmi_pltfm_driver = {
+ .probe = sun8i_dw_hdmi_probe,
+ .remove = sun8i_dw_hdmi_remove,
+ .driver = {
+ .name = "sun8i-dw-hdmi",
+ .of_match_table = sun8i_dw_hdmi_dt_ids,
+ },
+};
+module_platform_driver(sun8i_dw_hdmi_pltfm_driver);
+
+MODULE_AUTHOR("Jernej Skrabec <jernej.skrabec@siol.net>");
+MODULE_DESCRIPTION("Allwinner DW HDMI bridge");
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
new file mode 100644
index 000000000000..77a97f199333
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
@@ -0,0 +1,51 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Jernej Skrabec <jernej.skrabec@siol.net>
+ */
+
+#ifndef _SUN8I_DW_HDMI_H_
+#define _SUN8I_DW_HDMI_H_
+
+#include <drm/bridge/dw_hdmi.h>
+#include <drm/drm_encoder.h>
+#include <linux/clk.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+
+struct sun8i_hdmi_phy {
+ struct clk *clk_bus;
+ struct clk *clk_mod;
+ struct clk *clk_tmds;
+ struct regmap *regs;
+ struct reset_control *rst_phy;
+};
+
+struct sun8i_dw_hdmi {
+ struct device *dev;
+ struct drm_encoder encoder;
+ struct sun8i_hdmi_phy *phy;
+ struct dw_hdmi_plat_data plat_data;
+ struct reset_control *rst_ctrl;
+};
+
+static inline struct sun8i_dw_hdmi *
+encoder_to_sun8i_dw_hdmi(struct drm_encoder *encoder)
+{
+ return container_of(encoder, struct sun8i_dw_hdmi, encoder);
+}
+
+static inline struct sun8i_dw_hdmi *
+plat_data_to_sun8i_dw_hdmi(const struct dw_hdmi_plat_data *plat_data)
+{
+ return container_of(plat_data, struct sun8i_dw_hdmi, plat_data);
+}
+
+int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node);
+void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi);
+
+void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy);
+const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void);
+void sun8i_hdmi_phy_update_clock(struct sun8i_hdmi_phy *phy,
+ unsigned long rate);
+
+#endif /* _SUN8I_DW_HDMI_H_ */
diff --git a/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
new file mode 100644
index 000000000000..2555e488c5c5
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
@@ -0,0 +1,302 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Jernej Skrabec <jernej.skrabec@siol.net>
+ */
+
+#include <linux/of_address.h>
+
+#include "sun8i_dw_hdmi.h"
+
+#define SUN8I_HDMI_PHY_DBG_CTRL_REG 0x0000
+#define SUN8I_HDMI_PHY_DBG_CTRL_PX_LOCK BIT(0)
+#define SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK GENMASK(15, 8)
+#define SUN8I_HDMI_PHY_DBG_CTRL_POL(val) (val << 8)
+#define SUN8I_HDMI_PHY_DBG_CTRL_ADDR_MASK GENMASK(23, 16)
+#define SUN8I_HDMI_PHY_DBG_CTRL_ADDR(addr) (addr << 16)
+
+#define SUN8I_HDMI_PHY_REXT_CTRL_REG 0x0004
+#define SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN BIT(31)
+
+#define SUN8I_HDMI_PHY_READ_EN_REG 0x0010
+#define SUN8I_HDMI_PHY_READ_EN_MAGIC 0x54524545
+
+#define SUN8I_HDMI_PHY_UNSCRAMBLE_REG 0x0014
+#define SUN8I_HDMI_PHY_UNSCRAMBLE_MAGIC 0x42494E47
+
+/*
+ * Address can be actually any value. Here is set to same value as
+ * it is set in BSP driver.
+ */
+#define I2C_ADDR 0x69
+
+static int sun8i_hdmi_phy_config(struct dw_hdmi *hdmi, void *data,
+ struct drm_display_mode *mode)
+{
+ struct sun8i_hdmi_phy *phy = (struct sun8i_hdmi_phy *)data;
+ u32 val = 0;
+ int ret;
+
+ ret = clk_enable(phy->clk_tmds);
+ if (ret)
+ return ret;
+
+ if ((mode->flags & DRM_MODE_FLAG_NHSYNC) &&
+ (mode->flags & DRM_MODE_FLAG_NHSYNC)) {
+ val = 0x03;
+ }
+
+ regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
+ SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK,
+ SUN8I_HDMI_PHY_DBG_CTRL_POL(val));
+
+ regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_REXT_CTRL_REG,
+ SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN,
+ SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN);
+
+ /* power down */
+ dw_hdmi_phy_gen2_txpwron(hdmi, 0);
+ dw_hdmi_phy_gen2_pddq(hdmi, 1);
+
+ dw_hdmi_phy_reset(hdmi);
+
+ dw_hdmi_phy_gen2_pddq(hdmi, 0);
+
+ dw_hdmi_phy_i2c_set_addr(hdmi, I2C_ADDR);
+
+ /*
+ * Values are taken from BSP HDMI driver. Although AW didn't
+ * release any documentation, explanation of this values can
+ * be found in i.MX 6Dual/6Quad Reference Manual.
+ */
+ if (mode->crtc_clock <= 27000) {
+ dw_hdmi_phy_i2c_write(hdmi, 0x01e0, 0x06);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0000, 0x15);
+ dw_hdmi_phy_i2c_write(hdmi, 0x08da, 0x10);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0007, 0x19);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0318, 0x0e);
+ dw_hdmi_phy_i2c_write(hdmi, 0x8009, 0x09);
+ } else if (mode->crtc_clock <= 74250) {
+ dw_hdmi_phy_i2c_write(hdmi, 0x0540, 0x06);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0005, 0x15);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0000, 0x10);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0007, 0x19);
+ dw_hdmi_phy_i2c_write(hdmi, 0x02b5, 0x0e);
+ dw_hdmi_phy_i2c_write(hdmi, 0x8009, 0x09);
+ } else if (mode->crtc_clock <= 148500) {
+ dw_hdmi_phy_i2c_write(hdmi, 0x04a0, 0x06);
+ dw_hdmi_phy_i2c_write(hdmi, 0x000a, 0x15);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0000, 0x10);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0002, 0x19);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0021, 0x0e);
+ dw_hdmi_phy_i2c_write(hdmi, 0x8029, 0x09);
+ } else {
+ dw_hdmi_phy_i2c_write(hdmi, 0x0000, 0x06);
+ dw_hdmi_phy_i2c_write(hdmi, 0x000f, 0x15);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0000, 0x10);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0002, 0x19);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0000, 0x0e);
+ dw_hdmi_phy_i2c_write(hdmi, 0x802b, 0x09);
+ }
+
+ dw_hdmi_phy_i2c_write(hdmi, 0x0000, 0x1e);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0000, 0x13);
+ dw_hdmi_phy_i2c_write(hdmi, 0x0000, 0x17);
+
+ dw_hdmi_phy_gen2_txpwron(hdmi, 1);
+
+ return 0;
+};
+
+static void sun8i_hdmi_phy_disable(struct dw_hdmi *hdmi, void *data)
+{
+ struct sun8i_hdmi_phy *phy = (struct sun8i_hdmi_phy *)data;
+
+ dw_hdmi_phy_gen2_txpwron(hdmi, 0);
+ dw_hdmi_phy_gen2_pddq(hdmi, 1);
+
+ regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_REXT_CTRL_REG,
+ SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN, 0);
+
+ clk_disable(phy->clk_tmds);
+}
+
+static const struct dw_hdmi_phy_ops sun8i_hdmi_phy_ops = {
+ .init = &sun8i_hdmi_phy_config,
+ .disable = &sun8i_hdmi_phy_disable,
+ .read_hpd = &dw_hdmi_phy_read_hpd,
+ .update_hpd = &dw_hdmi_phy_update_hpd,
+ .setup_hpd = &dw_hdmi_phy_setup_hpd,
+};
+
+void sun8i_hdmi_phy_init(struct sun8i_hdmi_phy *phy)
+{
+ /* enable read access to HDMI controller */
+ regmap_write(phy->regs, SUN8I_HDMI_PHY_READ_EN_REG,
+ SUN8I_HDMI_PHY_READ_EN_MAGIC);
+
+ /* unscramble register offsets */
+ regmap_write(phy->regs, SUN8I_HDMI_PHY_UNSCRAMBLE_REG,
+ SUN8I_HDMI_PHY_UNSCRAMBLE_MAGIC);
+
+ regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
+ SUN8I_HDMI_PHY_DBG_CTRL_PX_LOCK,
+ SUN8I_HDMI_PHY_DBG_CTRL_PX_LOCK);
+
+ /*
+ * Set PHY I2C address. It must match to the address set by
+ * dw_hdmi_phy_set_slave_addr().
+ */
+ regmap_update_bits(phy->regs, SUN8I_HDMI_PHY_DBG_CTRL_REG,
+ SUN8I_HDMI_PHY_DBG_CTRL_ADDR_MASK,
+ SUN8I_HDMI_PHY_DBG_CTRL_ADDR(I2C_ADDR));
+}
+
+const struct dw_hdmi_phy_ops *sun8i_hdmi_phy_get_ops(void)
+{
+ return &sun8i_hdmi_phy_ops;
+}
+
+void sun8i_hdmi_phy_update_clock(struct sun8i_hdmi_phy *phy,
+ unsigned long rate)
+{
+ clk_set_rate(phy->clk_tmds, rate);
+}
+
+static struct regmap_config sun8i_hdmi_phy_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = SUN8I_HDMI_PHY_UNSCRAMBLE_REG,
+ .name = "phy"
+};
+
+static const struct of_device_id sun8i_hdmi_phy_of_table[] = {
+ { .compatible = "allwinner,sun8i-a83t-hdmi-phy" },
+ { /* sentinel */ }
+};
+
+int sun8i_hdmi_phy_probe(struct sun8i_dw_hdmi *hdmi, struct device_node *node)
+{
+ struct device *dev = hdmi->dev;
+ struct sun8i_hdmi_phy *phy;
+ struct resource res;
+ void __iomem *regs;
+ int ret;
+
+ if (!of_match_node(sun8i_hdmi_phy_of_table, node)) {
+ dev_err(dev, "Incompatible HDMI PHY\n");
+ return -EINVAL;
+ }
+
+ phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
+ if (!phy)
+ return -ENOMEM;
+
+ ret = of_address_to_resource(node, 0, &res);
+ if (ret) {
+ dev_err(dev, "phy: Couldn't get our resources\n");
+ return ret;
+ }
+
+ regs = devm_ioremap_resource(dev, &res);
+ if (IS_ERR(regs)) {
+ dev_err(dev, "Couldn't map the HDMI PHY registers\n");
+ return PTR_ERR(regs);
+ }
+
+ phy->regs = devm_regmap_init_mmio(dev, regs,
+ &sun8i_hdmi_phy_regmap_config);
+ if (IS_ERR(phy->regs)) {
+ dev_err(dev, "Couldn't create the HDMI PHY regmap\n");
+ return PTR_ERR(phy->regs);
+ }
+
+ phy->clk_bus = of_clk_get_by_name(node, "bus");
+ if (IS_ERR(phy->clk_bus)) {
+ dev_err(dev, "Could not get bus clock\n");
+ return PTR_ERR(phy->clk_bus);
+ }
+
+ phy->clk_mod = of_clk_get_by_name(node, "mod");
+ if (IS_ERR(phy->clk_mod)) {
+ dev_err(dev, "Could not get mod clock\n");
+ ret = PTR_ERR(phy->clk_mod);
+ goto err_put_clk_bus;
+ }
+
+ phy->clk_tmds = of_clk_get_by_name(node, "tmds");
+ if (IS_ERR(phy->clk_tmds)) {
+ dev_err(dev, "Could not get tmds clock\n");
+ ret = PTR_ERR(phy->clk_tmds);
+ goto err_put_clk_mod;
+ }
+
+ phy->rst_phy = of_reset_control_get_shared(node, "phy");
+ if (IS_ERR(phy->rst_phy)) {
+ dev_err(dev, "Could not get phy reset control\n");
+ ret = PTR_ERR(phy->rst_phy);
+ goto err_put_clk_tmds;
+ }
+
+ ret = reset_control_deassert(phy->rst_phy);
+ if (ret) {
+ dev_err(dev, "Cannot deassert phy reset control: %d\n", ret);
+ goto err_put_rst_phy;
+ }
+
+ ret = clk_prepare_enable(phy->clk_bus);
+ if (ret) {
+ dev_err(dev, "Cannot enable bus clock: %d\n", ret);
+ goto err_deassert_rst_phy;
+ }
+
+ ret = clk_prepare_enable(phy->clk_mod);
+ if (ret) {
+ dev_err(dev, "Cannot enable mod clock: %d\n", ret);
+ goto err_disable_clk_bus;
+ }
+
+ ret = clk_prepare(phy->clk_tmds);
+ if (ret) {
+ dev_err(dev, "Cannot prepare tmds clock: %d\n", ret);
+ goto err_disable_clk_mod;
+ }
+
+ hdmi->phy = phy;
+
+ return 0;
+
+err_disable_clk_mod:
+ clk_disable_unprepare(phy->clk_mod);
+err_disable_clk_bus:
+ clk_disable_unprepare(phy->clk_bus);
+err_deassert_rst_phy:
+ reset_control_assert(phy->rst_phy);
+err_put_rst_phy:
+ reset_control_put(phy->rst_phy);
+err_put_clk_tmds:
+ clk_put(phy->clk_tmds);
+err_put_clk_mod:
+ clk_put(phy->clk_mod);
+err_put_clk_bus:
+ clk_put(phy->clk_bus);
+
+ return ret;
+}
+
+void sun8i_hdmi_phy_remove(struct sun8i_dw_hdmi *hdmi)
+{
+ struct sun8i_hdmi_phy *phy = hdmi->phy;
+
+ clk_unprepare(phy->clk_tmds);
+ clk_disable_unprepare(phy->clk_mod);
+ clk_disable_unprepare(phy->clk_bus);
+
+ reset_control_assert(phy->rst_phy);
+
+ reset_control_put(phy->rst_phy);
+
+ clk_put(phy->clk_tmds);
+ clk_put(phy->clk_mod);
+ clk_put(phy->clk_bus);
+}
--
2.15.1
^ permalink raw reply related
* [PATCH v2 11/12] ARM: dts: sun8i: a83t: Add HDMI display pipeline
From: Jernej Skrabec @ 2018-01-10 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110192512.19684-1-jernej.skrabec@siol.net>
This commit adds all bits necessary for HDMI on A83T - mixer1, tcon1,
hdmi, hdmi phy and hdmi pinctrl entries.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 119 +++++++++++++++++++++++++++++++++++++-
1 file changed, 118 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 7f4955a5fab7..c2638966d338 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -155,7 +155,7 @@
de: display-engine {
compatible = "allwinner,sun8i-a83t-display-engine";
- allwinner,pipelines = <&mixer0>;
+ allwinner,pipelines = <&mixer0>, <&mixer1>;
status = "disabled";
};
@@ -208,6 +208,32 @@
};
};
+ mixer1: mixer at 1200000 {
+ compatible = "allwinner,sun8i-a83t-de2-mixer-1";
+ reg = <0x01200000 0x100000>;
+ clocks = <&display_clocks CLK_BUS_MIXER1>,
+ <&display_clocks CLK_MIXER1>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_WB>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer1_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer1_out_tcon1: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&tcon1_in_mixer1>;
+ };
+ };
+ };
+ };
+
syscon: syscon at 1c00000 {
compatible = "allwinner,sun8i-a83t-system-controller",
"syscon";
@@ -256,6 +282,43 @@
};
};
+ tcon1: lcd-controller at 1c0d000 {
+ compatible = "allwinner,sun8i-a83t-tcon-tv";
+ reg = <0x01c0d000 0x1000>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_TCON1>, <&ccu CLK_TCON1>;
+ clock-names = "ahb", "tcon-ch1";
+ resets = <&ccu RST_BUS_TCON1>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon1_in: port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon1_in_mixer1: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&mixer1_out_tcon1>;
+ };
+ };
+
+ tcon1_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon1_out_hdmi: endpoint at 1 {
+ reg = <1>;
+ remote-endpoint = <&hdmi_in_tcon1>;
+ };
+ };
+ };
+ };
+
mmc0: mmc at 1c0f000 {
compatible = "allwinner,sun8i-a83t-mmc",
"allwinner,sun7i-a20-mmc";
@@ -427,6 +490,11 @@
drive-strength = <40>;
};
+ hdmi_pins: hdmi-pins {
+ pins = "PH6", "PH7", "PH8";
+ function = "hdmi";
+ };
+
i2c0_pins: i2c0-pins {
pins = "PH0", "PH1";
function = "i2c0";
@@ -685,6 +753,55 @@
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
};
+ hdmi: hdmi at 1ee0000 {
+ compatible = "allwinner,sun8i-a83t-dw-hdmi";
+ reg = <0x01ee0000 0x10000>;
+ reg-io-width = <1>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_SLOW>;
+ clock-names = "iahb", "isfr";
+ resets = <&ccu RST_BUS_HDMI1>;
+ reset-names = "ctrl";
+ phys = <&hdmi_phy>;
+ phy-names = "hdmi-phy";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_pins>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hdmi_in: port at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ hdmi_in_tcon1: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&tcon1_out_hdmi>;
+ };
+ };
+
+ hdmi_out: port at 1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+ };
+ };
+
+ hdmi_phy: hdmi-phy at 1ef0000 {
+ compatible = "allwinner,sun8i-a83t-hdmi-phy";
+ reg = <0x01ef0000 0x10000>;
+ clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_SLOW>,
+ <&ccu CLK_HDMI>;
+ clock-names = "bus", "mod", "tmds";
+ resets = <&ccu RST_BUS_HDMI0>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ };
+
r_intc: interrupt-controller at 1f00c00 {
compatible = "allwinner,sun8i-a83t-r-intc",
"allwinner,sun6i-a31-r-intc";
--
2.15.1
^ permalink raw reply related
* [PATCH v2 12/12] ARM: dts: sun8i: a83t: Enable HDMI on BananaPi M3
From: Jernej Skrabec @ 2018-01-10 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110192512.19684-1-jernej.skrabec@siol.net>
BananaPi M3 includes HDMI connector, so add support for it.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 6550bf0e594b..00e47423cd07 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -60,6 +60,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
reg_usb1_vbus: reg-usb1-vbus {
compatible = "regulator-fixed";
regulator-name = "usb1-vbus";
@@ -82,6 +93,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
/* Terminus Tech FE 1.1s 4-port USB 2.0 hub here */
status = "okay";
@@ -100,6 +115,16 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&mdio {
rgmii_phy: ethernet-phy at 1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.15.1
^ permalink raw reply related
* [PATCH v3 02/13] arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry
From: Will Deacon @ 2018-01-10 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109171700.GA18100@infradead.org>
On Tue, Jan 09, 2018 at 09:17:00AM -0800, Christoph Hellwig wrote:
> On Mon, Jan 08, 2018 at 05:32:27PM +0000, Will Deacon wrote:
> > Although CONFIG_UNMAP_KERNEL_AT_EL0 does make KASLR more robust, it's
> > actually more useful as a mitigation against speculation attacks that
> > can leak arbitrary kernel data to userspace through speculation.
> >
> > Reword the Kconfig help message to reflect this, and make the option
> > depend on EXPERT so that it is on by default for the majority of users.
>
> I still haven't heard an anwer on why this isn't using
> CONFIG_PAGE_TABLE_ISOLATION but instead reinvents its own symbol.
Mainly because this code was written before CONFIG_PAGE_TABLE_ISOLATION had
been proposed and I wanted to avoid confusion with the ongoing backports
just to align on the naming for an arch-specific config option. We could
CONFIG_PAGE_TABLE_ISOLATION and make it select CONFIG_UNMAP_KERNEL_AT_EL) if
you like, but worth noting that this is default 'y' anyway and depends on
EXPERT.
Will
^ permalink raw reply
* [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers
From: Jae Hyun Yoo @ 2018-01-10 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110191703.GA20248@kroah.com>
On 1/10/2018 11:17 AM, Greg KH wrote:
> On Wed, Jan 10, 2018 at 11:14:34AM -0800, Jae Hyun Yoo wrote:
>> On 1/10/2018 2:17 AM, Greg KH wrote:
>>> On Tue, Jan 09, 2018 at 02:31:20PM -0800, Jae Hyun Yoo wrote:
>>>> From: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
>>>>
>>>> Hello,
>>>>
>>>> This patch set provides support for PECI of AST2400/2500 which can give us PECI
>>>> functionalities such as temperature monitoring, platform manageability,
>>>> processor diagnostics and failure analysis. Also provides generic peci.h and
>>>> peci_ioctl.h headers to provide compatibility to peci drivers that can be
>>>> implemented later e.g. Nuvoton's BMC SoC family.
>>>
>>> What is the "dev-4.10" in the subject for? 4.10 is really old and
>>> obsolete :(
>>>
>>> thanks,
>>>
>>> greg k-h
>>>
>>
>> I made this patch set on top of the v4.10 which OpenBmc project is currently
>> using. I'll rebase this patch set onto the current kernel.org mainline.
>
> What is "OpenBmc", and why are they using an obsolete and insecure
> kernel for their project? That seems like a very foolish thing to do...
>
> thanks,
>
> greg k-h
>
OpenBmc is an open source project to create a highly extensible
framework for BMC (Board Management Controller) software for data-center
computer systems:
https://github.com/openbmc
Its current mainline is v4.10 but it is being kept upgrading so it will
be upgraded to the latest stable or long-term version soon.
Thanks,
Jae
^ permalink raw reply
* [PATCH linux dev-4.10 3/6] drivers/misc: Add driver for Aspeed PECI and generic PECI headers
From: Jae Hyun Yoo @ 2018-01-10 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110101840.GB5822@kroah.com>
On 1/10/2018 2:18 AM, Greg KH wrote:
> On Tue, Jan 09, 2018 at 02:31:23PM -0800, Jae Hyun Yoo wrote:
>> This commit adds driver implementation for Aspeed PECI. Also adds
>> generic peci.h and peci_ioctl.h files to provide compatibility
>> to peci drivers that can be implemented later e.g. Nuvoton's BMC
>> SoC family.
>
> We don't add code that could be used "sometime in the future". Only
> include stuff that we use now.
>
> Please fix up this series based on that and resubmit. There should not
> be any need for any uapi file then, right?
>
> thanks,
>
> greg k-h
>
These header files are being used in this patch set as well. I meant,
these files also can be used for the future implementation to provide
compatibility. I will update the commit message.
Thanks,
Jae
^ permalink raw reply
* [PATCH linux dev-4.10 3/6] drivers/misc: Add driver for Aspeed PECI and generic PECI headers
From: Jae Hyun Yoo @ 2018-01-10 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110102011.GC5822@kroah.com>
On 1/10/2018 2:20 AM, Greg KH wrote:
> On Tue, Jan 09, 2018 at 02:31:23PM -0800, Jae Hyun Yoo wrote:
>> +#pragma pack(push, 1)
>> +struct peci_xfer_msg {
>> + unsigned char client_addr;
>> + unsigned char tx_len;
>> + unsigned char rx_len;
>> + unsigned char tx_buf[MAX_BUFFER_SIZE];
>> + unsigned char rx_buf[MAX_BUFFER_SIZE];
>> +};
>> +#pragma pack(pop)
>
> For any structure that crosses the user/kernel boundry, you _HAVE_ to
> use the "__" variant. So for here you would use __u8 instead of
> "unsigned char" in order for things to work properly.
>
> I'm guessing you didn't test this all out on a mixed 32/64 bit system?
>
> Please fix up and test to ensure that it all works properly before
> resubmitting.
>
> thanks,
>
> greg k-h
>
Thanks for your pointing it out. I'll fix this.
Thanks a lot,
Jae
^ permalink raw reply
* [PATCH v2 2/2] phy: rockchip-emmc: use regmap_read_poll_timeout to poll dllrdy
From: Doug Anderson @ 2018-01-10 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515569879-31808-3-git-send-email-wxt@rock-chips.com>
Hi,
On Tue, Jan 9, 2018 at 11:37 PM, Caesar Wang <wxt@rock-chips.com> wrote:
> From: Shawn Lin <shawn.lin@rock-chips.com>
>
> Just use the API instead of open-coding it, no functional change
> intended.
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
> Reviewed-by: Brian Norris <briannorris@chromium.org>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
>
> ---
>
> Changes in v2:
> - As Brian commented on https://patchwork.kernel.org/patch/10139891/,
> changed the note and added to print error value with
> regmap_read_poll_timeout API.
>
> drivers/phy/rockchip/phy-rockchip-emmc.c | 33 +++++++++++---------------------
> 1 file changed, 11 insertions(+), 22 deletions(-)
See comments in Shawn's v2. AKA: <https://patchwork.kernel.org/patch/10154797/>
^ permalink raw reply
* [PATCH v2 1/2] phy: rockchip-emmc: retry calpad busy trimming
From: Doug Anderson @ 2018-01-10 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515569879-31808-2-git-send-email-wxt@rock-chips.com>
Hi,
On Tue, Jan 9, 2018 at 11:37 PM, Caesar Wang <wxt@rock-chips.com> wrote:
> From: Shawn Lin <shawn.lin@rock-chips.com>
>
> It turns out that 5us isn't enough for all cases, so let's
> retry some more times to wait for caldone.
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
> Tested-by: Ziyuan Xu <xzy.xu@rock-chips.com>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> ---
>
> Changes in v2:
> - print the return valut with regmap_read_poll_timeout failing.
I agree with Brian that it was quite confusing to see a v2 from both
you and Shawn.
> drivers/phy/rockchip/phy-rockchip-emmc.c | 27 +++++++++++++++++----------
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-emmc.c b/drivers/phy/rockchip/phy-rockchip-emmc.c
> index f1b24f1..574838f 100644
> --- a/drivers/phy/rockchip/phy-rockchip-emmc.c
> +++ b/drivers/phy/rockchip/phy-rockchip-emmc.c
> @@ -76,6 +76,10 @@
> #define PHYCTRL_OTAPDLYSEL_MASK 0xf
> #define PHYCTRL_OTAPDLYSEL_SHIFT 0x7
>
> +#define PHYCTRL_IS_CALDONE(x) \
> + ((((x) >> PHYCTRL_CALDONE_SHIFT) & \
> + PHYCTRL_CALDONE_MASK) == PHYCTRL_CALDONE_DONE)
> +
> struct rockchip_emmc_phy {
> unsigned int reg_offset;
> struct regmap *reg_base;
> @@ -90,6 +94,7 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
> unsigned int freqsel = PHYCTRL_FREQSEL_200M;
> unsigned long rate;
> unsigned long timeout;
> + int ret;
>
> /*
> * Keep phyctrl_pdb and phyctrl_endll low to allow
> @@ -160,17 +165,19 @@ static int rockchip_emmc_phy_power(struct phy *phy, bool on_off)
> PHYCTRL_PDB_SHIFT));
>
> /*
> - * According to the user manual, it asks driver to
> - * wait 5us for calpad busy trimming
> + * According to the user manual, it asks driver to wait 5us for
> + * calpad busy trimming. However it is documented that this value is
> + * PVT(A.K.A process,voltage and temperature) relevant, so some
> + * failure cases are found which indicates we should be more tolerant
> + * to calpad busy trimming.
> */
> - udelay(5);
> - regmap_read(rk_phy->reg_base,
> - rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
> - &caldone);
> - caldone = (caldone >> PHYCTRL_CALDONE_SHIFT) & PHYCTRL_CALDONE_MASK;
> - if (caldone != PHYCTRL_CALDONE_DONE) {
> - pr_err("rockchip_emmc_phy_power: caldone timeout.\n");
> - return -ETIMEDOUT;
> + ret = regmap_read_poll_timeout(rk_phy->reg_base,
> + rk_phy->reg_offset + GRF_EMMCPHY_STATUS,
> + caldone, PHYCTRL_IS_CALDONE(caldone),
> + 5, 50);
>
> + if (ret) {
> + pr_err("%s: caldone timeout, ret=%d\n", __func__, ret);
In Shawn's v2, AKA <https://patchwork.kernel.org/patch/10154795/>,
this says "caldone failed", which I like better since not all failures
will be timeouts.
^ permalink raw reply
* [RFC PATCH] drivers: soc: xilinx: Add ZynqMP power domain driver
From: Jolly Shah @ 2018-01-10 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOFm3uFGuhBzXRrnuaFbdmjXSfq8Gm+Of93e3ovzdTZN1YaF9g@mail.gmail.com>
Thanks Philippe for review,
> -----Original Message-----
> From: Philippe Ombredanne [mailto:pombredanne at nexb.com]
> Sent: Tuesday, January 09, 2018 4:48 AM
> To: Jolly Shah <JOLLYS@xilinx.com>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>; Andy Gross
> <andy.gross@linaro.org>; Shawn Guo <shawnguo@kernel.org>;
> geert+renesas at glider.be; Bjorn Andersson <bjorn.andersson@linaro.org>; Sean
> Wang <sean.wang@mediatek.com>; Marek Szyprowski
> <m.szyprowski@samsung.com>; Michal Simek <michal.simek@xilinx.com>;
> moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE <linux-arm-
> kernel at lists.infradead.org>; LKML <linux-kernel@vger.kernel.org>; Jolly Shah
> <JOLLYS@xilinx.com>; Rajan Vaja <RAJANV@xilinx.com>
> Subject: Re: [RFC PATCH] drivers: soc: xilinx: Add ZynqMP power domain driver
>
> Jolly,
>
> On Mon, Jan 8, 2018 at 11:12 PM, Jolly Shah <jolly.shah@xilinx.com> wrote:
> > The zynqmp-genpd driver communicates the usage requirements for
> > logical power domains / devices to the platform FW.
> > FW is responsible for choosing appropriate power states, taking Linux'
> > usage information into account.
> >
> > Signed-off-by: Jolly Shah <jollys@xilinx.com>
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > ---
>
> <snip>
>
> > --- /dev/null
> > +++ b/drivers/soc/xilinx/zynqmp/pm_domains.c
> > @@ -0,0 +1,343 @@
> > +/*
> > + * ZynqMP Generic PM domain support
> > + *
> > + * Copyright (C) 2014-2017 Xilinx, Inc.
> > + *
> > + * Davorin Mista <davorin.mista@aggios.com>
> > + * Jolly Shah <jollys@xilinx.com>
> > + * Rajan Vaja <rajanv@xilinx.com>
> > + *
> > + * SPDX-License-Identifier: GPL-2.0+
> > + */
>
> This tag should be on the fist line as this:
>
> // SPDX-License-Identifier: GPL-2.0+
>
> --
> Cordially
> Philippe Ombredanne
Will fix it in next version
^ permalink raw reply
* [PATCH 1/3] ARM: dts: enable L2 cache parity and ecc on db-xc3-24g4xg board
From: Chris Packham @ 2018-01-10 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87y3l66s0r.fsf@free-electrons.com>
Hi Gregory,
On 10/01/18 21:24, Gregory CLEMENT wrote:
> Hi Chris,
>
> On mar., janv. 09 2018, Chris Packham <chris.packham@alliedtelesis.co.nz> wrote:
>
> Could you have add a (even small) message in the commit log?
>
> Also could you improve the title by specify that it applies on
> armada-xp, like this:
>
> ARM: dts: armada-xp: enable L2 cache parity and ecc on db-xc3-24g4xg
>
Will do.
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>> ---
>> arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
>> index 06fce35d7491..00ca489fc788 100644
>> --- a/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
>> +++ b/arch/arm/boot/dts/armada-xp-db-xc3-24g4xg.dts
>> @@ -70,6 +70,11 @@
>> };
>> };
>>
>> +&L2 {
>> + arm,parity-enable;
>> + marvell,ecc-enable;
>
> It is not a problem for me to already applied the device tree change
> even if the driver is not merged yet. But I would like to have an
> acked-by on this new property by either a device tree maintainer or at
> least the EDAC maintainer, of course having both acked-by would be
> perfect ! :)
Thanks, I was hoping you would say that. That way I can keep this
independent of the EDAC driver changes.
>
> Thanks,
>
> Gregory
>
>
>
>
>> +};
>> +
>> &devbus_bootcs {
>> status = "okay";
>>
>> --
>> 2.15.1
>>
>
^ permalink raw reply
* [RFC PATCH 2/2] drivers: clk: Add ZynqMP clock driver
From: Jolly Shah @ 2018-01-10 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOFm3uFnzp4xPW=65A5Xyshaj-6PJx94PLi_nm4+c+csFznz-g@mail.gmail.com>
Hi Philippe,
Thanks for the review.
Will fix all SPDX tags in next version.
Thanks,
Jolly Shah
> -----Original Message-----
> From: Philippe Ombredanne [mailto:pombredanne at nexb.com]
> Sent: Tuesday, January 09, 2018 4:53 AM
> To: Jolly Shah <JOLLYS@xilinx.com>
> Cc: Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
> <sboyd@codeaurora.org>; Michal Simek <michal.simek@xilinx.com>; linux-
> clk at vger.kernel.org; moderated list:ARM/FREESCALE IMX / MXC ARM
> ARCHITECTURE <linux-arm-kernel@lists.infradead.org>; LKML <linux-
> kernel at vger.kernel.org>; Jolly Shah <JOLLYS@xilinx.com>; Rajan Vaja
> <RAJANV@xilinx.com>; Tejas Patel <TEJASP@xilinx.com>; Shubhrajyoti Datta
> <shubhraj@xilinx.com>
> Subject: Re: [RFC PATCH 2/2] drivers: clk: Add ZynqMP clock driver
>
> Jolly,
>
> On Mon, Jan 8, 2018 at 11:16 PM, Jolly Shah <jolly.shah@xilinx.com> wrote:
> > This patch adds CCF compliant clock driver for ZynqMP.
> > Clock driver queries supported clock information from
> > firmware and regiters pll and output clocks with CCF.
> >
> > Signed-off-by: Jolly Shah <jollys@xilinx.com>
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > Signed-off-by: Tejas Patel <tejasp@xilinx.com>
> > Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
> > ---
>
> <snip>
>
>
> > .../devicetree/bindings/clock/zynq_mpsoc.txt | 163 +++++
> > drivers/clk/Kconfig | 1 +
> > drivers/clk/Makefile | 1 +
> > drivers/clk/zynqmp/Kconfig | 8 +
> > drivers/clk/zynqmp/Makefile | 3 +
> > drivers/clk/zynqmp/clk-gate-zynqmp.c | 158 +++++
> > drivers/clk/zynqmp/clk-mux-zynqmp.c | 190 ++++++
> > drivers/clk/zynqmp/clkc.c | 707 +++++++++++++++++++++
> > drivers/clk/zynqmp/divider.c | 239 +++++++
> > drivers/clk/zynqmp/pll.c | 384 +++++++++++
> > include/linux/clk/zynqmp.h | 46 ++
> > 11 files changed, 1900 insertions(+)
> > create mode 100644
> Documentation/devicetree/bindings/clock/zynq_mpsoc.txt
> > create mode 100644 drivers/clk/zynqmp/Kconfig
> > create mode 100644 drivers/clk/zynqmp/Makefile
> > create mode 100644 drivers/clk/zynqmp/clk-gate-zynqmp.c
> > create mode 100644 drivers/clk/zynqmp/clk-mux-zynqmp.c
> > create mode 100644 drivers/clk/zynqmp/clkc.c
> > create mode 100644 drivers/clk/zynqmp/divider.c
> > create mode 100644 drivers/clk/zynqmp/pll.c
> > create mode 100644 include/linux/clk/zynqmp.h
> >
^ permalink raw reply
* [PATCH 05/10] perf tools: Add support for decoding CoreSight trace data
From: Mathieu Poirier @ 2018-01-10 20:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110055926.GE16554@leoy-linaro>
On 9 January 2018 at 22:59, Leo Yan <leo.yan@linaro.org> wrote:
> Hi Mike,
>
> On Tue, Jan 09, 2018 at 12:09:58PM +0000, Mike Leach wrote:
>> Hi Leo,
>>
>> The OCSD_GEN_TRC_ELEM_ADDR_NACC element indicates that the decoder
>> does not have an code image mapping for the address contained in the
>> trace, at the location described by this element. the payload for the
>> NACC element is the memory location it could not address.
>> This means that it cannot correctly follow the instruction execution
>> sequence described by the individual trace packets.
>>
>> The dump option works because we do not need to follow the execution
>> sequence to dump raw trace packets.
>>
>> It is not clear to me if the perf script option as you specified is
>> mapping the vmlinux image into the decoder.
>
> I only can say that the 'perf script' has loaded symbol list by the
> option '--kallsyms ./System.map'. Here have one corner case is for
> option '-k vmlinux', at my side I build 'perf' tool without linking
> libelf, so perf cannot directly parse kernel symbol. If the perf
> tool is built with linking libelf, then we can directly load kernel
> symbol mapping from vmlinux and don't need specifiy option
> '--kallsyms ./System.map' anymore.
>
> Could you point which perf code will pass vmlinux mapping to the
> decoder? I don't know this before. After some debugging I only found
> perf relies on OpenCSD to return back OCSD_GEN_TRC_ELEM_INSTR_RANGE
> and then perf will do symbol/sym_off analysis, otherwise it will skip
> symbol analysis.
I have hit this problem before when trying to decode kernel traces.
When using the --kallsyms option the kernel's base address isn't
correctly set and from there no symbols can be decoded (the same
happens on PT). Looking into the root cause of the problem is on my
(long) list of things to do. In the mean time try with only the -k
vmlinux option and see how far that gets you.
Mathieu
>
> BTW, I use the same 'perf script' command with OpenCSD v0.7.5, it
> can return back OCSD_GEN_TRC_ELEM_INSTR_RANGE but not
> OCSD_GEN_TRC_ELEM_ADDR_NACC so it can print out kernel symbol, this
> is for using the same perf.data and vmlinux files.
>
> Thanks,
> Leo Yan
>
>> On 30 December 2017 at 00:33, Leo Yan <leo.yan@linaro.org> wrote:
>> > Hi Mathieu, Mike,
>> >
>> > On Fri, Dec 15, 2017 at 09:44:54AM -0700, Mathieu Poirier wrote:
>> >> Adding functionality to create a CoreSight trace decoder capable
>> >> of decoding trace data pushed by a client application.
>> >>
>> >> Co-authored-by: Tor Jeremiassen <tor@ti.com>
>> >> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>> >> ---
>> >> tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 119 ++++++++++++++++++++++++
>> >> 1 file changed, 119 insertions(+)
>> >>
>> >> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> >> index 6a4c86b1431f..57b020b0b36f 100644
>> >> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> >> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> >> @@ -200,6 +200,121 @@ static void cs_etm_decoder__clear_buffer(struct cs_etm_decoder *decoder)
>> >> }
>> >> }
>> >>
>> >> +static ocsd_datapath_resp_t
>> >> +cs_etm_decoder__buffer_packet(struct cs_etm_decoder *decoder,
>> >> + const ocsd_generic_trace_elem *elem,
>> >> + const u8 trace_chan_id,
>> >> + enum cs_etm_sample_type sample_type)
>> >> +{
>> >> + u32 et = 0;
>> >> + struct int_node *inode = NULL;
>> >> +
>> >> + if (decoder->packet_count >= MAX_BUFFER - 1)
>> >> + return OCSD_RESP_FATAL_SYS_ERR;
>> >> +
>> >> + /* Search the RB tree for the cpu associated with this traceID */
>> >> + inode = intlist__find(traceid_list, trace_chan_id);
>> >> + if (!inode)
>> >> + return OCSD_RESP_FATAL_SYS_ERR;
>> >> +
>> >> + et = decoder->tail;
>> >> + decoder->packet_buffer[et].sample_type = sample_type;
>> >> + decoder->packet_buffer[et].start_addr = elem->st_addr;
>> >> + decoder->packet_buffer[et].end_addr = elem->en_addr;
>> >> + decoder->packet_buffer[et].exc = false;
>> >> + decoder->packet_buffer[et].exc_ret = false;
>> >> + decoder->packet_buffer[et].cpu = *((int *)inode->priv);
>> >> +
>> >> + /* Wrap around if need be */
>> >> + et = (et + 1) & (MAX_BUFFER - 1);
>> >> +
>> >> + decoder->tail = et;
>> >> + decoder->packet_count++;
>> >> +
>> >> + if (decoder->packet_count == MAX_BUFFER - 1)
>> >> + return OCSD_RESP_WAIT;
>> >> +
>> >> + return OCSD_RESP_CONT;
>> >> +}
>> >> +
>> >> +static ocsd_datapath_resp_t cs_etm_decoder__gen_trace_elem_printer(
>> >> + const void *context,
>> >> + const ocsd_trc_index_t indx __maybe_unused,
>> >> + const u8 trace_chan_id __maybe_unused,
>> >> + const ocsd_generic_trace_elem *elem)
>> >> +{
>> >> + ocsd_datapath_resp_t resp = OCSD_RESP_CONT;
>> >> + struct cs_etm_decoder *decoder = (struct cs_etm_decoder *) context;
>> >
>> > After apply this patch set and build 'perf' tool with linking
>> > OpenCSDv0.8.0 libs, I can everytime OpenCSD parses 'elem->elem_type'
>> > is OCSD_GEN_TRC_ELEM_ADDR_NACC but not OCSD_GEN_TRC_ELEM_INSTR_RANGE.
>> >
>> > As result, the 'perf' tool can dump the raw data with '-D' option but
>> > it cannot analyze the symbol and symbol offset with below command:
>> >
>> > ./perf script -v -a -F cpu,event,ip,sym,symoff -i ./perf.data -k vmlinux
>> > --kallsyms ./System.map
>> >
>> > Have uploaded perf.data/vmlinux/System.map in the folder:
>> > http://people.linaro.org/~leo.yan/binaries/perf_4.15_r4/
>> >
>> > Thanks,
>> > Leo Yan
>> >
>> >> + switch (elem->elem_type) {
>> >> + case OCSD_GEN_TRC_ELEM_UNKNOWN:
>> >> + break;
>> >> + case OCSD_GEN_TRC_ELEM_NO_SYNC:
>> >> + decoder->trace_on = false;
>> >> + break;
>> >> + case OCSD_GEN_TRC_ELEM_TRACE_ON:
>> >> + decoder->trace_on = true;
>> >> + break;
>> >> + case OCSD_GEN_TRC_ELEM_INSTR_RANGE:
>> >> + resp = cs_etm_decoder__buffer_packet(decoder, elem,
>> >> + trace_chan_id,
>> >> + CS_ETM_RANGE);
>> >> + break;
>> >> + case OCSD_GEN_TRC_ELEM_EXCEPTION:
>> >> + decoder->packet_buffer[decoder->tail].exc = true;
>> >> + break;
>> >> + case OCSD_GEN_TRC_ELEM_EXCEPTION_RET:
>> >> + decoder->packet_buffer[decoder->tail].exc_ret = true;
>> >> + break;
>> >> + case OCSD_GEN_TRC_ELEM_PE_CONTEXT:
>> >> + case OCSD_GEN_TRC_ELEM_EO_TRACE:
>> >> + case OCSD_GEN_TRC_ELEM_ADDR_NACC:
>> >> + case OCSD_GEN_TRC_ELEM_TIMESTAMP:
>> >> + case OCSD_GEN_TRC_ELEM_CYCLE_COUNT:
>> >> + case OCSD_GEN_TRC_ELEM_ADDR_UNKNOWN:
>> >> + case OCSD_GEN_TRC_ELEM_EVENT:
>> >> + case OCSD_GEN_TRC_ELEM_SWTRACE:
>> >> + case OCSD_GEN_TRC_ELEM_CUSTOM:
>> >> + default:
>> >> + break;
>> >> + }
>> >> +
>> >> + return resp;
>> >> +}
>> >> +
>> >> +static int cs_etm_decoder__create_etm_packet_decoder(
>> >> + struct cs_etm_trace_params *t_params,
>> >> + struct cs_etm_decoder *decoder)
>> >> +{
>> >> + const char *decoder_name;
>> >> + ocsd_etmv4_cfg trace_config_etmv4;
>> >> + void *trace_config;
>> >> + u8 csid;
>> >> +
>> >> + switch (t_params->protocol) {
>> >> + case CS_ETM_PROTO_ETMV4i:
>> >> + cs_etm_decoder__gen_etmv4_config(t_params, &trace_config_etmv4);
>> >> + decoder_name = OCSD_BUILTIN_DCD_ETMV4I;
>> >> + trace_config = &trace_config_etmv4;
>> >> + break;
>> >> + default:
>> >> + return -1;
>> >> + }
>> >> +
>> >> + if (ocsd_dt_create_decoder(decoder->dcd_tree,
>> >> + decoder_name,
>> >> + OCSD_CREATE_FLG_FULL_DECODER,
>> >> + trace_config, &csid))
>> >> + return -1;
>> >> +
>> >> + if (ocsd_dt_set_gen_elem_outfn(decoder->dcd_tree,
>> >> + cs_etm_decoder__gen_trace_elem_printer,
>> >> + decoder))
>> >> + return -1;
>> >> +
>> >> + return 0;
>> >> +}
>> >> +
>> >> static int
>> >> cs_etm_decoder__create_etm_decoder(struct cs_etm_decoder_params *d_params,
>> >> struct cs_etm_trace_params *t_params,
>> >> @@ -208,6 +323,10 @@ cs_etm_decoder__create_etm_decoder(struct cs_etm_decoder_params *d_params,
>> >> if (d_params->operation == CS_ETM_OPERATION_PRINT)
>> >> return cs_etm_decoder__create_etm_packet_printer(t_params,
>> >> decoder);
>> >> + else if (d_params->operation == CS_ETM_OPERATION_DECODE)
>> >> + return cs_etm_decoder__create_etm_packet_decoder(t_params,
>> >> + decoder);
>> >> +
>> >> return -1;
>> >> }
>> >>
>> >> --
>> >> 2.7.4
>> >>
>> >
>> > _______________________________________________
>> > linux-arm-kernel mailing list
>> > linux-arm-kernel at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>>
>>
>> --
>> Mike Leach
>> Principal Engineer, ARM Ltd.
>> Blackburn Design Centre. UK
^ permalink raw reply
* [PATCH 2/3] ARM: dts: mvebu: add sdram controller node to Armada-38x
From: Chris Packham @ 2018-01-10 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87tvvu6ro6.fsf@free-electrons.com>
On 10/01/18 21:31, Gregory CLEMENT wrote:
> Hi Chris,
>
> On mar., janv. 09 2018, Chris Packham <chris.packham@alliedtelesis.co.nz> wrote:
>
>> The Armada-38x uses an SDRAM controller that is compatible with the
>> Armada-XP. The key difference is the width of the bus (XP is 64/32, 38x
>> is 32/16). The SDRAM controller registers are the same between the two
>> SoCs.
>>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>> ---
>> arch/arm/boot/dts/armada-38x.dtsi | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/armada-38x.dtsi b/arch/arm/boot/dts/armada-38x.dtsi
>> index 00ff549d4e39..6d34c5ec178f 100644
>> --- a/arch/arm/boot/dts/armada-38x.dtsi
>> +++ b/arch/arm/boot/dts/armada-38x.dtsi
>> @@ -138,6 +138,11 @@
>> #size-cells = <1>;
>> ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
>>
>> + sdramc at 1400 {
>
> Could you add a label? Thanks to this it would be possible to
> enable/disable it at board level in a esay way.
>
Sure. Any suggestions for a name better than "sdramc:"?
It's probably worth adding the same label to armada-xp.dtsi and
armada-xp-98dx3236.dtsi.
>> + compatible = "marvell,armada-xp-sdram-controller";
>> + reg = <0x1400 0x500>;
>
> What about adding status = "disabled" ?
>
> Thanks to this we can enable it at board level only if we really want
> it, it would avoid nasty regression on boards that don't need it, if an
> issue occurs. Unless you are sure that it is completely safe to enable
> it for everyone.
The EDAC driver (which is default n) will not probe the device if ECC
has not been enabled so that should be safe.
Other than the EDAC driver the only other code that looks at this is in
arch/arm/mach-mvebu/pm.c and it almost seems like an omission that this
code is not active on armada-38x. The armada-38x platforms I have access
to don't use suspend/resume so I can't verify this.
^ permalink raw reply
* [RFC PATCH] drivers: soc: xilinx: Add ZynqMP PM driver
From: Jolly Shah @ 2018-01-10 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515467395.31546.11.camel@mtkswgap22>
Thanks Sean for review,
> -----Original Message-----
> From: Sean Wang [mailto:sean.wang at mediatek.com]
> Sent: Monday, January 08, 2018 7:10 PM
> To: Jolly Shah <JOLLYS@xilinx.com>
> Cc: matthias.bgg at gmail.com; andy.gross at linaro.org; shawnguo at kernel.org;
> geert+renesas at glider.be; bjorn.andersson at linaro.org;
> m.szyprowski at samsung.com; michal.simek at xilinx.com; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; Jolly Shah
> <JOLLYS@xilinx.com>; Rajan Vaja <RAJANV@xilinx.com>
> Subject: Re: [RFC PATCH] drivers: soc: xilinx: Add ZynqMP PM driver
>
> On Mon, 2018-01-08 at 14:10 -0800, Jolly Shah wrote:
> > Add ZynqMP PM driver. PM driver provides power management support for
> > ZynqMP.
> >
> > Signed-off-by: Jolly Shah <jollys@xilinx.com>
> > Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
> > ---
> > .../bindings/soc/xilinx/xlnx,zynqmp-pm.txt | 15 ++
>
>
> The patch should be split into two: one is for dt-bindings part and the other is for
> driver part. Where dt-binding part should require additionally to send to Rob and
> Cc. devicetree at vger.kernel.org.
>
Sure. Will do it in next version.
> > diff --git a/drivers/soc/xilinx/zynqmp/Makefile
> > b/drivers/soc/xilinx/zynqmp/Makefile
> > new file mode 100644
> > index 0000000..98034f7
> > --- /dev/null
> > +++ b/drivers/soc/xilinx/zynqmp/Makefile
> > @@ -0,0 +1 @@
> > +obj-$(CONFIG_ZYNQMP_PM) += pm.o
> > diff --git a/drivers/soc/xilinx/zynqmp/pm.c
> > b/drivers/soc/xilinx/zynqmp/pm.c new file mode 100644 index
> > 0000000..7178fb5
> > --- /dev/null
> > +++ b/drivers/soc/xilinx/zynqmp/pm.c
> > @@ -0,0 +1,265 @@
> > +/*
> > + * Xilinx Zynq MPSoC Power Management
> > + *
> > + * Copyright (C) 2014-2017 Xilinx, Inc.
>
> should include 2018 ?
>
Will fix in next version
> > + if (!eemi_ops || !eemi_ops->get_api_version)
> > + return -ENXIO;
> > +
> > + eemi_ops->get_api_version(&pm_api_version);
> > +
> > + /* Check PM API version number */
> > + if (pm_api_version != ZYNQMP_PM_VERSION)
> > + return -ENODEV;
> > +
> > + irq = platform_get_irq(pdev, 0);
> > + if (irq <= 0)
> > + return -ENXIO;
> > +
> > + ret = request_irq(irq, zynqmp_pm_isr, IRQF_SHARED, DRIVER_NAME,
> pdev);
> > + if (ret) {
> > + dev_err(&pdev->dev, "request_irq '%d' failed with %d\n",
> > + irq, ret);
> > + return ret;
> > + }
>
>
> how about use devm_request_irq to simplify error path?
Will change in next version
Thanks,
Jolly Shah
^ permalink raw reply
* [PATCH] ARM: pxa/tosa-bt: add MODULE_LICENSE tag
From: Robert Jarzmik @ 2018-01-10 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110162816.431038-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> Without this tag, we get a build warning:
>
> WARNING: modpost: missing MODULE_LICENSE() in arch/arm/mach-pxa/tosa-bt.o
>
> For completeness, I'm also adding author and description fields.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Queued into pxa/for-next, thanks.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers
From: Greg KH @ 2018-01-10 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8997e43c-683e-418d-4e2b-1fe3fefe254e@linux.intel.com>
On Wed, Jan 10, 2018 at 11:30:05AM -0800, Jae Hyun Yoo wrote:
> On 1/10/2018 11:17 AM, Greg KH wrote:
> > On Wed, Jan 10, 2018 at 11:14:34AM -0800, Jae Hyun Yoo wrote:
> > > On 1/10/2018 2:17 AM, Greg KH wrote:
> > > > On Tue, Jan 09, 2018 at 02:31:20PM -0800, Jae Hyun Yoo wrote:
> > > > > From: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
> > > > >
> > > > > Hello,
> > > > >
> > > > > This patch set provides support for PECI of AST2400/2500 which can give us PECI
> > > > > functionalities such as temperature monitoring, platform manageability,
> > > > > processor diagnostics and failure analysis. Also provides generic peci.h and
> > > > > peci_ioctl.h headers to provide compatibility to peci drivers that can be
> > > > > implemented later e.g. Nuvoton's BMC SoC family.
> > > >
> > > > What is the "dev-4.10" in the subject for? 4.10 is really old and
> > > > obsolete :(
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > > >
> > >
> > > I made this patch set on top of the v4.10 which OpenBmc project is currently
> > > using. I'll rebase this patch set onto the current kernel.org mainline.
> >
> > What is "OpenBmc", and why are they using an obsolete and insecure
> > kernel for their project? That seems like a very foolish thing to do...
> >
> > thanks,
> >
> > greg k-h
> >
>
> OpenBmc is an open source project to create a highly extensible framework
> for BMC (Board Management Controller) software for data-center computer
> systems:
> https://github.com/openbmc
>
> Its current mainline is v4.10 but it is being kept upgrading so it will be
> upgraded to the latest stable or long-term version soon.
Why hasn't it been updated in the year since 4.10 was released? That's
a _very_ long time to be running on a totally insecure kernel, and no
new development should ever be done on old kernels, that's even crazier
(as we can't go back in time and accept patches for new features to old
releases...)
It sounds like the openbmc project needs to learn how to manage their
kernels a whole lot better, who do I need to go poke about this?
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 2/2] i2c: mv64xxx: Fix clock resource by adding an optional bus clock
From: Andrew Lunn @ 2018-01-10 20:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110170743.27082-3-gregory.clement@free-electrons.com>
On Wed, Jan 10, 2018 at 06:07:43PM +0100, Gregory CLEMENT wrote:
> On Armada 7K/8K we need to explicitly enable the bus clock. The bus clock
> is optional because not all the SoCs need them but at least for Armada
> 7K/8K it is actually mandatory.
>
> The binding documentation is updating accordingly.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> .../devicetree/bindings/i2c/i2c-mv64xxx.txt | 20 ++++++++++++++++++++
> drivers/i2c/busses/i2c-mv64xxx.c | 12 +++++++++++-
> 2 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> index 5c30026921ae..a835b724c738 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
> @@ -25,6 +25,15 @@ default frequency is 100kHz
> whenever you're using the "allwinner,sun6i-a31-i2c"
> compatible.
>
> + - clocks: : pointers to the reference clocks for this device, the first
> + one is the one used for the clock on the i2c bus, the second
> + one is the clock used for the functional part of the
> + controller
> +
> + - clock-names : names of used clocks, mandatory if the second clock is
> + : used, the name must be "core", and "axi_clk" (the latter is
> + only for Armada 7K/8K).
Hi Gregory
Are these two clocks related?
Ethernet on Dove needs two clocks enabled.
static const struct clk_gating_soc_desc dove_gating_desc[] __initconst = {
{ "usb0", NULL, 0, 0 },
{ "usb1", NULL, 1, 0 },
{ "ge", "gephy", 2, 0 },
{ "sata", NULL, 3, 0 },
ge has a parent clock gephy. When you enable ge, the common clock code
walks up the tree of clocks, so will also turn on gephy.
Does this child/parent relationship exist with these i2c clocks?
Andrew
^ permalink raw reply
* [PATCH net-next 1/2 v10] net: ethernet: Add DT bindings for the Gemini ethernet
From: David Miller @ 2018-01-10 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109221053.927-1-linus.walleij@linaro.org>
From: Linus Walleij <linus.walleij@linaro.org>
Date: Tue, 9 Jan 2018 23:10:52 +0100
> This adds the device tree bindings for the Gemini ethernet
> controller. It is pretty straight-forward, using standard
> bindings and modelling the two child ports as child devices
> under the parent ethernet controller device.
>
> Cc: devicetree at vger.kernel.org
> Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com>
> Cc: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Applied.
^ permalink raw reply
* [PATCH net-next 2/2 v10] net: ethernet: Add a driver for Gemini gigabit ethernet
From: David Miller @ 2018-01-10 20:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109221053.927-2-linus.walleij@linaro.org>
From: Linus Walleij <linus.walleij@linaro.org>
Date: Tue, 9 Jan 2018 23:10:53 +0100
> The Gemini ethernet has been around for years as an out-of-tree
> patch used with the NAS boxen and routers built on StorLink
> SL3512 and SL3516, later Storm Semiconductor, later Cortina
> Systems. These ASICs are still being deployed and brand new
> off-the-shelf systems using it can easily be acquired.
>
> The full name of the IP block is "Net Engine and Gigabit
> Ethernet MAC" commonly just called "GMAC".
>
> The hardware block contains a common TCP Offload Enginer (TOE)
> that can be used by both MACs. The current driver does not use
> it.
>
> Cc: Tobias Waldvogel <tobias.waldvogel@gmail.com>
> Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Applied.
^ permalink raw reply
* [PATCH net-next 2/2 v10] net: ethernet: Add a driver for Gemini gigabit ethernet
From: David Miller @ 2018-01-10 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110.154113.1759667248487481665.davem@davemloft.net>
Actually I had to revert these two patches, this stuff doesn't even
build.
[davem at dhcp-10-15-49-227 net-next]$ make -s -j16
In file included from ./include/linux/printk.h:329:0,
from ./include/linux/kernel.h:14,
from ./include/linux/list.h:9,
from ./include/linux/module.h:9,
from drivers/net/ethernet/cortina/gemini.c:16:
drivers/net/ethernet/cortina/gemini.c: In function ?geth_freeq_alloc_map_page?:
drivers/net/ethernet/cortina/gemini.c:821:21: warning: format ?%x? expects argument of type ?unsigned int?, but argument 5 has type ?dma_addr_t {aka long long unsigned int}? [-Wformat=]
dev_dbg(geth->dev, "page %d, DMA addr: %08x, page %p\n",
^
./include/linux/dynamic_debug.h:135:39: note: in definition of macro ?dynamic_dev_dbg?
__dynamic_dev_dbg(&descriptor, dev, fmt, \
^~~
drivers/net/ethernet/cortina/gemini.c:821:2: note: in expansion of macro ?dev_dbg?
dev_dbg(geth->dev, "page %d, DMA addr: %08x, page %p\n",
^~~~~~~
drivers/net/ethernet/cortina/gemini.c: In function ?gmac_rx?:
drivers/net/ethernet/cortina/gemini.c:1410:50: warning: format ?%x? expects argument of type ?unsigned int?, but argument 3 has type ?dma_addr_t {aka long long unsigned int}? [-Wformat=]
dev_err(geth->dev, "could not find mapping %08x (page = %08x, page off = %08x)\n",
~~~^
%08llx
drivers/net/ethernet/cortina/gemini.c:1410:63: warning: format ?%x? expects argument of type ?unsigned int?, but argument 4 has type ?long long unsigned int? [-Wformat=]
dev_err(geth->dev, "could not find mapping %08x (page = %08x, page off = %08x)\n",
~~~^
%08llx
drivers/net/ethernet/cortina/gemini.c: In function ?gemini_ethernet_port_probe?:
drivers/net/ethernet/cortina/gemini.c:2456:28: warning: format ?%x? expects argument of type ?unsigned int?, but argument 4 has type ?resource_size_t {aka long long unsigned int}? [-Wformat=]
"irq %d, DMA @ 0x%08x, GMAC @ 0x%08x\n",
~~~^
%08llx
port->irq, dmares->start,
~~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2456:43: warning: format ?%x? expects argument of type ?unsigned int?, but argument 5 has type ?resource_size_t {aka long long unsigned int}? [-Wformat=]
"irq %d, DMA @ 0x%08x, GMAC @ 0x%08x\n",
~~~^
%08llx
drivers/net/ethernet/cortina/gemini.c:2458:8:
gmacres->start);
~~~~~~~~~~~~~~
In file included from drivers/net/ethernet/cortina/gemini.c:16:0:
drivers/net/ethernet/cortina/gemini.c: At top level:
./include/linux/module.h:129:42: error: redefinition of ?__inittest?
static inline initcall_t __maybe_unused __inittest(void) \
^
./include/linux/device.h:1513:1: note: in expansion of macro ?module_init?
module_init(__driver##_init); \
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2567:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:129:42: note: previous definition of ?__inittest? was here
static inline initcall_t __maybe_unused __inittest(void) \
^
./include/linux/device.h:1513:1: note: in expansion of macro ?module_init?
module_init(__driver##_init); \
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2495:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_port_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:131:6: error: redefinition of ?init_module?
int init_module(void) __attribute__((alias(#initfn)));
^
./include/linux/device.h:1513:1: note: in expansion of macro ?module_init?
module_init(__driver##_init); \
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2567:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:131:6: note: previous definition of ?init_module? was here
int init_module(void) __attribute__((alias(#initfn)));
^
./include/linux/device.h:1513:1: note: in expansion of macro ?module_init?
module_init(__driver##_init); \
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2495:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_port_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:135:42: error: redefinition of ?__exittest?
static inline exitcall_t __maybe_unused __exittest(void) \
^
./include/linux/device.h:1518:1: note: in expansion of macro ?module_exit?
module_exit(__driver##_exit);
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2567:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:135:42: note: previous definition of ?__exittest? was here
static inline exitcall_t __maybe_unused __exittest(void) \
^
./include/linux/device.h:1518:1: note: in expansion of macro ?module_exit?
module_exit(__driver##_exit);
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2495:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_port_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:137:7: error: redefinition of ?cleanup_module?
void cleanup_module(void) __attribute__((alias(#exitfn)));
^
./include/linux/device.h:1518:1: note: in expansion of macro ?module_exit?
module_exit(__driver##_exit);
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2567:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_driver);
^~~~~~~~~~~~~~~~~~~~~~
./include/linux/module.h:137:7: note: previous definition of ?cleanup_module? was here
void cleanup_module(void) __attribute__((alias(#exitfn)));
^
./include/linux/device.h:1518:1: note: in expansion of macro ?module_exit?
module_exit(__driver##_exit);
^~~~~~~~~~~
./include/linux/platform_device.h:228:2: note: in expansion of macro ?module_driver?
module_driver(__platform_driver, platform_driver_register, \
^~~~~~~~~~~~~
drivers/net/ethernet/cortina/gemini.c:2495:1: note: in expansion of macro ?module_platform_driver?
module_platform_driver(gemini_ethernet_port_driver);
^~~~~~~~~~~~~~~~~~~~~~
make[4]: *** [scripts/Makefile.build:317: drivers/net/ethernet/cortina/gemini.o] Error 1
make[3]: *** [scripts/Makefile.build:569: drivers/net/ethernet/cortina] Error 2
make[3]: *** Waiting for unfinished jobs....
^ permalink raw reply
* [PATCH 2/2] soc: imx: gpc: Do not pass static memory as platform data
From: Stefan Agner @ 2018-01-10 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110161608.13015-2-andrew.smirnov@gmail.com>
On 2018-01-10 17:16, Andrey Smirnov wrote:
> Platform device core assumes the ownership of dev.platform_data as
> well as that it is dynamically allocated and it will try to kfree it
> as a part of platform_device_release(). Change the code to pass
> kzalloc'ed chunk of memory instead of a pointer to a static memory to
> avoid causing a BUG() when calling platform_device_put().
I tried to get around that by setting platform_data to null before
unregistring the device, see:
https://marc.info/?l=linux-arm-kernel&m=151553216030129&w=2
This solutions still seems to miss unregistering the platform devices,
which shows when binding the driver again:
root at colibri-imx6:~# echo 20dc000.gpc >
/sys/bus/platform/drivers/imx-gpc/unbind
[ 80.702627] imx-pgc-pd imx-pgc-power-domain.0: Dropping the link to
20dc000.gpc
[ 80.710808] genpd_remove: unable to remove PU
[ 80.716408] imx-pgc-pd imx-pgc-power-domain.1: Dropping the link to
20dc000.gpc
root at colibri-imx6:~# find /sys -name *pgc-power*
/sys/devices/soc0/soc/2000000.aips-bus/20dc000.gpc/imx-pgc-power-domain.0
/sys/devices/soc0/soc/2000000.aips-bus/20dc000.gpc/imx-pgc-power-domain.1
/sys/bus/platform/devices/imx-pgc-power-domain.0
/sys/bus/platform/devices/imx-pgc-power-domain.1
root at colibri-imx6:~# echo 20dc000.gpc >
/sys/bus/platform/drivers/imx-gpc/bind
[ 89.002754] ------------[ cut here ]------------
[ 89.007411] WARNING: CPU: 0 PID: 516 at fs/sysfs/dir.c:31
sysfs_warn_dup+0x64/0x74
[ 89.015057] sysfs: cannot create duplicate filename
'/devices/soc0/soc/2000000.aips-bus/20dc000.gpc/imx-pgc-power-domain.0'
>
> The problem can be reproduced by artificially enabling the error path
> of platform_device_add() call (around line 452).
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Stefan Agner <stefan@agner.ch>
> Cc: Lucas Stach <l.stach@pengutronix.de>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> ---
>
> This patch is a follow up to fix one of the bugs discussed in
> lkml.kernel.org/r/3f836677c6e98aaf01bc1ac8c3410083 at agner.ch
>
> drivers/soc/imx/gpc.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index 47e7aa963dbb..ec8b79abebac 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -18,6 +18,7 @@
> #include <linux/pm_domain.h>
> #include <linux/regmap.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/slab.h>
>
> #define GPC_CNTR 0x000
>
> @@ -428,13 +429,19 @@ static int imx_gpc_probe(struct platform_device *pdev)
> if (domain_index >= of_id_data->num_domains)
> continue;
>
> - domain = &imx_gpc_domains[domain_index];
> + domain = kzalloc(sizeof(*domain), GFP_KERNEL);
I guess you could use just kalloc here since you memcpy below.
--
Stefan
> + if (!domain) {
> + of_node_put(np);
> + return -ENOMEM;
> + }
> + memcpy(domain, &imx_gpc_domains[domain_index], sizeof(*domain));
> domain->regmap = regmap;
> domain->ipg_rate_mhz = ipg_rate_mhz;
>
> pd_pdev = platform_device_alloc("imx-pgc-power-domain",
> domain_index);
> if (!pd_pdev) {
> + kfree(domain);
> of_node_put(np);
> return -ENOMEM;
> }
^ permalink raw reply
* [PATCH 0/7] ARM: dts: STi: Fix DT dtc warnings
From: Arnd Bergmann @ 2018-01-10 20:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20f04806-2f33-3c16-d790-4a93c4c7187a@st.com>
On Wed, Jan 10, 2018 at 6:17 PM, Patrice CHOTARD <patrice.chotard@st.com> wrote:
> Hi Arnd
>
> On 01/10/2018 04:52 PM, Arnd Bergmann wrote:
>> On Wed, Jan 10, 2018 at 9:21 AM, <patrice.chotard@st.com> wrote:
>>> From: Patrice Chotard <patrice.chotard@st.com>
>>>
>>> This series fixes all dtc warnings related to STi platforms dt files.
>>> It has been triggered by Rob Herring [1]
>>>
>>> [1] https://www.spinics.net/lists/devicetree/msg206209.html
>>>
>>> For most of implicated node, a simple move outside the soc node
>>> solves the warnings.
>>>
>>> Patrice Chotard (7):
>>> ARM: dts: STi: fix bindings notation
>>> ARM: dts: STi: Add gpio polarity for "hdmi,hpd-gpio" property
>>> ARM: dts: STi: Move clocks without reg outside soc
>>> ARM: dts: STi: Move leds node outside soc node
>>> ARM: dts: STi: Move usb2_picophyX nodes without reg out of soc
>>> ARM: dts: STi: Move sound related nodes without reg out of soc
>>> ARM: dts: STi: Add fake reg property for sti-display-subsystem
>>
>> Thanks a lot for addressing these!
>>
>> As far as I can tell, there is one patch in particular that addresses a warning
>> we get at the default warning level: "ARM: dts: STi: Add gpio polarity for
>> "hdmi,hpd-gpio" property". Should we merge that one for 4.15 to get closer
>> to a clean build again? I'm not sure whether we can address the other
>
> How do you want to proceed with this particular patch ?
> Do you want me to send a pull-request with this patch ?
>
> Patrice
I'd just pick it up directly into the arm-soc fixes branch if that
works for you.
Arnd
^ permalink raw reply
* [PATCH] phy: work around 'phys' references to usb-phy devices
From: Arnd Bergmann @ 2018-01-10 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aa02104b-d80d-8b12-4403-b5cedc23f03a@ti.com>
On Mon, Jan 8, 2018 at 7:32 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> Hi Arnd,
>
> On Monday 08 January 2018 06:31 PM, Arnd Bergmann wrote:
>> Stefan Wahren reports a problem with a warning fix that was merged
>> for v4.15: we had lots of device nodes with a 'phys' property pointing
>> to a device node that is not compliant with the binding documented in
>> Documentation/devicetree/bindings/phy/phy-bindings.txt
>>
>> This generally works because USB HCD drivers that support both the generic
>> phy subsystem and the older usb-phy subsystem ignore most errors from
>> phy_get() and related calls and then use the usb-phy driver instead.
>>
>> However, usb_add_hcd() (along with the respective functions in dwc2 and
>> dwc3) propagate the EPROBE_DEFER return code so we can try again whenever
>> the driver gets loaded. In case the driver is written for the usb-phy
>> subsystem (like usb-generic-phy aka usb-nop-xceiv), we will never load
>> a generic-phy driver for it, and keep failing here.
>>
>> There is only a small number of remaining usb-phy drivers that support
>> device tree, so this adds a workaround by providing a full list of the
>> potentially affected drivers, and always failing the probe with -ENODEV
>> here, which is the same behavior that we used to get with incorrect
>> device tree files. Since we generally want older kernels to also want
>> to work with the fixed devicetree files, it would be good to backport
>> the patch into stable kernels as well (3.13+ are possibly affected).
>> Reverting back to the DTS sources that work would in theory fix USB
>> support for now, but in the long run we'd run into the same problem
>> again when the drivers get ported from usb-phy to generic-phy.
>>
>> Fixes: 014d6da6cb25 ("ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells")
>> Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
>> Cc: stable at vger.kernel.org
>> Cc: Stefan Wahren <stefan.wahren@i2se.com>
>> Cc: Felipe Balbi <balbi@kernel.org>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> This obviously needs to be tested, I wrote this up as a reply to
>> Stefan's bug report. I'm fairly sure that I covered all usb-phy
>> driver strings here. My goal is to have a fix merged into 4.15
>> rather than reverting all the DT fixes.
>
> Shouldn't the fix be in phy consumer drivers to not return error if it's able
> to find the phy either using usb-phy or generic phy?
Stefan has posted a patch to that effect now, but I fear that might be
a little fragile, in particular this short before the release with the
regression
in place.
The main problem is that we'd have to change the generic
usb_add_hcd() function in addition to dwc2 and dwc3 to ignore
-EPROBE_DEFER from phy_get() whenever usb_get_phy_dev()
has already succeeded.
If there is any HCD that relies on usb_add_hcd() to get both the
usb_phy and the phy structures, and it may need to defer probing
when the latter one isn't ready yet, that fix would break another
driver.
>> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
>> index b4964b067aec..bb4dd2a2de2d 100644
>> --- a/drivers/phy/phy-core.c
>> +++ b/drivers/phy/phy-core.c
>> @@ -387,6 +387,24 @@ int phy_calibrate(struct phy *phy)
>> }
>> EXPORT_SYMBOL_GPL(phy_calibrate);
>>
>> +static struct of_device_id __maybe_unused legacy_usbphy[] = {
>> + { .compatible = "fsl,imx23-usbphy" },
>> + { .compatible = "fsl,imx6q-usbphy" },
>> + { .compatible = "fsl,imx6sl-usbphy" },
>> + { .compatible = "fsl,imx6sx-usbphy" },
>> + { .compatible = "fsl,imx6ul-usbphy" },
>> + { .compatible = "fsl,vf610-usbphy" },
>> + { .compatible = "nvidia,tegra20-usb-phy" },
>> + { .compatible = "nvidia,tegra30-usb-phy" },
>> + { .compatible = "nxp,isp1301" },
>> + { .compatible = "ti,am335x-usb-ctrl-module" },
>> + { .compatible = "ti,am335x-usb-phy" },
>> + { .compatible = "ti,keystone-usbphy" },
>> + { .compatible = "ti,twl6030-usb" },
>> + { .compatible = "usb-nop-xceiv" },
>> + {},
>
> "ti,am335x-usb-ctrl-module" and "ti,twl6030-usb" are not phys.
Ok, I see.
Arnd
^ permalink raw reply
* [PATCH] arm64: dts: socfpga: add missing interrupt-parent
From: Arnd Bergmann @ 2018-01-10 21:04 UTC (permalink / raw)
To: linux-arm-kernel
The PMU node has no working interrupt, as shown by this dtc warning:
arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dtb: Warning (interrupts_property): Missing interrupt-parent for /pmu
This adds an interrupt-parent property so we can correct parse
that interrupt number.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
If this looks ok, I'd apply it directly to the fixes branch
for 4.15, as the warning is one that was introduced in this
release.
---
arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index 7c9bdc7ab50b..9db19314c60c 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -66,6 +66,7 @@
<&cpu1>,
<&cpu2>,
<&cpu3>;
+ interrupt-parent = <&intc>;
};
psci {
--
2.9.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox