* [PATCH v1 5/7] drm/mediatek: implement connection from BLS to DPI0
From: Bibby Hsieh @ 2018-05-14 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514075243.5442-1-bibby.hsieh@mediatek.com>
Modify display driver to support connection from BLS to DPI.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index 8130f3dab661..289a68c6731f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -35,6 +35,7 @@
#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030
#define DISP_REG_CONFIG_OUT_SEL 0x04c
#define DISP_REG_CONFIG_DSI_SEL 0x050
+#define DISP_REG_CONFIG_DPI_SEL 0x064
#define DISP_REG_MUTEX_EN(n) (0x20 + 0x20 * (n))
#define DISP_REG_MUTEX(n) (0x24 + 0x20 * (n))
@@ -84,7 +85,10 @@
#define OVL_MOUT_EN_RDMA 0x1
#define BLS_TO_DSI_RDMA1_TO_DPI1 0x8
+#define BLS_TO_DPI_RDMA1_TO_DSI 0x2
#define DSI_SEL_IN_BLS 0x0
+#define DPI_SEL_IN_BLS 0x0
+#define DSI_SEL_IN_RDMA 0x1
struct mtk_disp_mutex {
int id;
@@ -189,9 +193,17 @@ static void mtk_ddp_sout_sel(void __iomem *config_regs,
enum mtk_ddp_comp_id cur,
enum mtk_ddp_comp_id next)
{
- if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0)
+ if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DSI0) {
writel_relaxed(BLS_TO_DSI_RDMA1_TO_DPI1,
config_regs + DISP_REG_CONFIG_OUT_SEL);
+ } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
+ writel_relaxed(BLS_TO_DPI_RDMA1_TO_DSI,
+ config_regs + DISP_REG_CONFIG_OUT_SEL);
+ writel_relaxed(DSI_SEL_IN_RDMA,
+ config_regs + DISP_REG_CONFIG_DSI_SEL);
+ writel_relaxed(DPI_SEL_IN_BLS,
+ config_regs + DISP_REG_CONFIG_DPI_SEL);
+ }
}
void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
--
2.12.5
^ permalink raw reply related
* [PATCH v1 4/7] drm/mediatek: add hdmi driver for different hardware
From: Bibby Hsieh @ 2018-05-14 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514075243.5442-1-bibby.hsieh@mediatek.com>
From: chunhui dai <chunhui.dai@mediatek.com>
This patch adds hdmi driver suppot for both MT2701 and MT7623.
And also support other (existing or future) chips that use
the same binding and driver.
Signed-off-by: Chunhui Dai <chunhui.dai@mediatek.com>
---
drivers/gpu/drm/mediatek/Makefile | 4 +-
drivers/gpu/drm/mediatek/mtk_hdmi.c | 91 +++++---
drivers/gpu/drm/mediatek/mtk_hdmi.h | 28 +++
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c | 157 +++++++++++++
drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 1 +
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 307 +++++++++++++++++++++++++
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 129 +----------
7 files changed, 568 insertions(+), 149 deletions(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile
index ce83c396a742..44464893c1cb 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -18,6 +18,8 @@ obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o
mediatek-drm-hdmi-objs := mtk_cec.o \
mtk_hdmi.o \
mtk_hdmi_ddc.o \
- mtk_mt8173_hdmi_phy.o
+ mtk_mt2701_hdmi_phy.o \
+ mtk_mt8173_hdmi_phy.o \
+ mtk_hdmi_phy.o
obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 59a11026dceb..85e280962aad 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -233,6 +233,7 @@ static void mtk_hdmi_hw_vid_black(struct mtk_hdmi *hdmi, bool black)
static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi *hdmi, bool enable)
{
struct arm_smccc_res res;
+ struct mtk_hdmi_phy *hdmi_phy = phy_get_drvdata(hdmi->phy);
/*
* MT8173 HDMI hardware has an output control bit to enable/disable HDMI
@@ -240,8 +241,13 @@ static void mtk_hdmi_hw_make_reg_writable(struct mtk_hdmi *hdmi, bool enable)
* The ARM trusted firmware provides an API for the HDMI driver to set
* this control bit to enable HDMI output in supervisor mode.
*/
- arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904, 0x80000000,
- 0, 0, 0, 0, 0, &res);
+ if (hdmi_phy->conf && hdmi_phy->conf->tz_enabled)
+ arm_smccc_smc(MTK_SIP_SET_AUTHORIZED_SECURE_REG, 0x14000904,
+ 0x80000000, 0, 0, 0, 0, 0, &res);
+ else
+ regmap_update_bits(hdmi->sys_regmap,
+ hdmi->sys_offset + HDMI_SYS_CFG20,
+ HDMI_PSECUR_EN, enable ? 0 : HDMI_PSECUR_EN);
regmap_update_bits(hdmi->sys_regmap, hdmi->sys_offset + HDMI_SYS_CFG20,
HDMI_PCLK_FREE_RUN, enable ? HDMI_PCLK_FREE_RUN : 0);
@@ -1437,6 +1443,7 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
struct platform_device *cec_pdev;
struct regmap *regmap;
struct resource *mem;
+ const char *phy_name;
int ret;
ret = mtk_hdmi_get_all_clk(hdmi, np);
@@ -1445,9 +1452,20 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
return ret;
}
+ ret = of_property_read_string(np, "phy-names", &phy_name);
+ if (ret < 0) {
+ dev_err(dev, "Failed to read phy-names: %d\n", ret);
+ return ret;
+ }
+ hdmi->phy = devm_phy_get(dev, phy_name);
+ if (IS_ERR(hdmi->phy)) {
+ ret = PTR_ERR(hdmi->phy);
+ dev_err(dev, "Failed to get HDMI PHY: %d\n", ret);
+ return ret;
+ }
+
/* The CEC module handles HDMI hotplug detection */
- cec_np = of_find_compatible_node(np->parent, NULL,
- "mediatek,mt8173-cec");
+ cec_np = of_parse_phandle(np, "cec", 0);
if (!cec_np) {
dev_err(dev, "Failed to find CEC node\n");
return -EINVAL;
@@ -1486,8 +1504,14 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
return PTR_ERR(hdmi->regs);
remote = of_graph_get_remote_node(np, 1, 0);
- if (!remote)
- return -EINVAL;
+ if (!remote) {
+ i2c_np = of_parse_phandle(np, "ddc-i2c-bus", 0);
+ if (!i2c_np) {
+ dev_err(dev, "Failed to find ddc-i2c-bus node\n");
+ return -EINVAL;
+ }
+ goto find_ddc_adpt;
+ }
if (!of_device_is_compatible(remote, "hdmi-connector")) {
hdmi->next_bridge = of_drm_find_bridge(remote);
@@ -1507,6 +1531,7 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
}
of_node_put(remote);
+find_ddc_adpt:
hdmi->ddc_adpt = of_find_i2c_adapter_by_node(i2c_np);
if (!hdmi->ddc_adpt) {
dev_err(dev, "Failed to get ddc i2c adapter by node\n");
@@ -1575,6 +1600,11 @@ static int mtk_hdmi_audio_hw_params(struct device *dev, void *data,
hdmi_params.aud_i2s_fmt = HDMI_I2S_MODE_I2S_24BIT;
hdmi_params.aud_mclk = HDMI_AUD_MCLK_128FS;
break;
+ case HDMI_SPDIF:
+ hdmi_params.aud_codec = HDMI_AUDIO_CODING_TYPE_PCM;
+ hdmi_params.aud_sampe_size = HDMI_AUDIO_SAMPLE_SIZE_16;
+ hdmi_params.aud_input_type = HDMI_AUD_INPUT_SPDIF;
+ break;
default:
dev_err(hdmi->dev, "%s: Invalid DAI format %d\n", __func__,
daifmt->fmt);
@@ -1650,15 +1680,16 @@ static void mtk_hdmi_register_audio_driver(struct device *dev)
.max_i2s_channels = 2,
.i2s = 1,
};
- struct platform_device *pdev;
-
- pdev = platform_device_register_data(dev, HDMI_CODEC_DRV_NAME,
- PLATFORM_DEVID_AUTO, &codec_data,
- sizeof(codec_data));
- if (IS_ERR(pdev))
+ static struct platform_device *pdev;
+
+ if (!pdev) {
+ pdev = platform_device_register_data(dev, HDMI_CODEC_DRV_NAME,
+ PLATFORM_DEVID_NONE,
+ &codec_data,
+ sizeof(codec_data));
+ DRM_INFO("%s driver bound to HDMI\n", HDMI_CODEC_DRV_NAME);
+ }
return;
-
- DRM_INFO("%s driver bound to HDMI\n", HDMI_CODEC_DRV_NAME);
}
static int mtk_drm_hdmi_probe(struct platform_device *pdev)
@@ -1672,18 +1703,12 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev)
return -ENOMEM;
hdmi->dev = dev;
+ mtk_hdmi_register_audio_driver(dev);
ret = mtk_hdmi_dt_parse_pdata(hdmi, pdev);
if (ret)
return ret;
- hdmi->phy = devm_phy_get(dev, "hdmi");
- if (IS_ERR(hdmi->phy)) {
- ret = PTR_ERR(hdmi->phy);
- dev_err(dev, "Failed to get HDMI PHY: %d\n", ret);
- return ret;
- }
-
platform_set_drvdata(pdev, hdmi);
ret = mtk_hdmi_output_init(hdmi);
@@ -1692,8 +1717,6 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev)
return ret;
}
- mtk_hdmi_register_audio_driver(dev);
-
hdmi->bridge.funcs = &mtk_hdmi_bridge_funcs;
hdmi->bridge.of_node = pdev->dev.of_node;
drm_bridge_add(&hdmi->bridge);
@@ -1704,7 +1727,6 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev)
goto err_bridge_remove;
}
- dev_dbg(dev, "mediatek hdmi probe success\n");
return 0;
err_bridge_remove:
@@ -1773,8 +1795,25 @@ static struct platform_driver * const mtk_hdmi_drivers[] = {
static int __init mtk_hdmitx_init(void)
{
- return platform_register_drivers(mtk_hdmi_drivers,
- ARRAY_SIZE(mtk_hdmi_drivers));
+ int ret;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(mtk_hdmi_drivers); i++) {
+ ret = platform_driver_register(mtk_hdmi_drivers[i]);
+ if (ret < 0) {
+ pr_err("Failed to register %s driver: %d\n",
+ mtk_hdmi_drivers[i]->driver.name, ret);
+ goto err;
+ }
+ }
+
+ return 0;
+
+err:
+ while (--i >= 0)
+ platform_driver_unregister(mtk_hdmi_drivers[i]);
+
+ return ret;
}
static void __exit mtk_hdmitx_exit(void)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.h b/drivers/gpu/drm/mediatek/mtk_hdmi.h
index 6371b3de1ff6..a4546b83329f 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.h
@@ -13,11 +13,39 @@
*/
#ifndef _MTK_HDMI_CTRL_H
#define _MTK_HDMI_CTRL_H
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/platform_device.h>
+#include <linux/phy/phy.h>
+
+struct mtk_hdmi_phy_conf {
+ bool tz_enabled;
+ const struct clk_ops *hdmi_phy_clk_ops;
+ const struct phy_ops *hdmi_phy_dev_ops;
+};
+
+struct mtk_hdmi_phy {
+ void __iomem *regs;
+ struct device *dev;
+ struct mtk_hdmi_phy_conf *conf;
+ struct clk *pll;
+ struct clk_hw pll_hw;
+ unsigned long pll_rate;
+ unsigned char drv_imp_clk;
+ unsigned char drv_imp_d2;
+ unsigned char drv_imp_d1;
+ unsigned char drv_imp_d0;
+ unsigned int ibias;
+ unsigned int ibias_up;
+};
struct platform_driver;
extern struct platform_driver mtk_cec_driver;
extern struct platform_driver mtk_hdmi_ddc_driver;
extern struct platform_driver mtk_hdmi_phy_driver;
+extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf;
+extern struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf;
+
#endif /* _MTK_HDMI_CTRL_H */
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
new file mode 100644
index 000000000000..325790abd469
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Jie Qiu <jie.qiu@mediatek.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of_platform.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/phy/phy.h>
+#include "mtk_hdmi.h"
+
+static void mtk_hdmi_phy_clk_get_ops(struct mtk_hdmi_phy *hdmi_phy,
+ const struct clk_ops **ops)
+{
+ if (hdmi_phy && hdmi_phy->conf && hdmi_phy->conf->hdmi_phy_clk_ops)
+ *ops = hdmi_phy->conf->hdmi_phy_clk_ops;
+ else
+ dev_err(hdmi_phy->dev, "Failed to get clk ops of phy\n");
+}
+
+static const struct phy_ops *
+mtk_hdmi_phy_dev_get_ops(const struct mtk_hdmi_phy *hdmi_phy)
+{
+ if (hdmi_phy && hdmi_phy->conf && hdmi_phy->conf->hdmi_phy_dev_ops)
+ return hdmi_phy->conf->hdmi_phy_dev_ops;
+ dev_err(hdmi_phy->dev, "Failed to get dev ops of phy\n");
+ return NULL;
+}
+
+static int mtk_hdmi_phy_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct mtk_hdmi_phy *hdmi_phy;
+ struct resource *mem;
+ struct clk *ref_clk;
+ const char *ref_clk_name;
+ struct clk_init_data clk_init = {
+ .num_parents = 1,
+ .parent_names = (const char * const *)&ref_clk_name,
+ .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
+ };
+
+ struct phy *phy;
+ struct phy_provider *phy_provider;
+ int ret;
+
+ hdmi_phy = devm_kzalloc(dev, sizeof(*hdmi_phy), GFP_KERNEL);
+ if (!hdmi_phy)
+ return -ENOMEM;
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ hdmi_phy->regs = devm_ioremap_resource(dev, mem);
+ if (IS_ERR(hdmi_phy->regs)) {
+ ret = PTR_ERR(hdmi_phy->regs);
+ dev_err(dev, "Failed to get memory resource: %d\n", ret);
+ return ret;
+ }
+
+ ref_clk = devm_clk_get(dev, "pll_ref");
+ if (IS_ERR(ref_clk)) {
+ ret = PTR_ERR(ref_clk);
+ dev_err(&pdev->dev, "Failed to get PLL reference clock: %d\n",
+ ret);
+ return ret;
+ }
+ ref_clk_name = __clk_get_name(ref_clk);
+
+ ret = of_property_read_string(dev->of_node, "clock-output-names",
+ &clk_init.name);
+ if (ret < 0) {
+ dev_err(dev, "Failed to read clock-output-names: %d\n", ret);
+ return ret;
+ }
+
+ hdmi_phy->dev = dev;
+ hdmi_phy->conf =
+ (struct mtk_hdmi_phy_conf *)of_device_get_match_data(dev);
+ mtk_hdmi_phy_clk_get_ops(hdmi_phy, &clk_init.ops);
+ hdmi_phy->pll_hw.init = &clk_init;
+ hdmi_phy->pll = devm_clk_register(dev, &hdmi_phy->pll_hw);
+ if (IS_ERR(hdmi_phy->pll)) {
+ ret = PTR_ERR(hdmi_phy->pll);
+ dev_err(dev, "Failed to register PLL: %d\n", ret);
+ return ret;
+ }
+
+ ret = of_property_read_u32(dev->of_node, "mediatek,ibias",
+ &hdmi_phy->ibias);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Failed to get ibias: %d\n", ret);
+ return ret;
+ }
+
+ ret = of_property_read_u32(dev->of_node, "mediatek,ibias_up",
+ &hdmi_phy->ibias_up);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Failed to get ibias up: %d\n", ret);
+ return ret;
+ }
+
+ dev_info(dev, "Using default TX DRV impedance: 4.2k/36\n");
+ hdmi_phy->drv_imp_clk = 0x30;
+ hdmi_phy->drv_imp_d2 = 0x30;
+ hdmi_phy->drv_imp_d1 = 0x30;
+ hdmi_phy->drv_imp_d0 = 0x30;
+
+ phy = devm_phy_create(dev, NULL, mtk_hdmi_phy_dev_get_ops(hdmi_phy));
+ if (IS_ERR(phy)) {
+ dev_err(dev, "Failed to create HDMI PHY\n");
+ return PTR_ERR(phy);
+ }
+ phy_set_drvdata(phy, hdmi_phy);
+
+ phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+ if (IS_ERR(phy_provider)) {
+ dev_err(dev, "Failed to register HDMI PHY\n");
+ return PTR_ERR(phy_provider);
+ }
+
+ return of_clk_add_provider(dev->of_node, of_clk_src_simple_get,
+ hdmi_phy->pll);
+}
+
+static int mtk_hdmi_phy_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static const struct of_device_id mtk_hdmi_phy_match[] = {
+ { .compatible = "mediatek,mt2701-hdmi-phy",
+ .data = &mtk_hdmi_phy_2701_conf,
+ },
+ { .compatible = "mediatek,mt8173-hdmi-phy",
+ .data = &mtk_hdmi_phy_8173_conf,
+ },
+ {},
+};
+
+struct platform_driver mtk_hdmi_phy_driver = {
+ .probe = mtk_hdmi_phy_probe,
+ .remove = mtk_hdmi_phy_remove,
+ .driver = {
+ .name = "mediatek-hdmi-phy",
+ .of_match_table = mtk_hdmi_phy_match,
+ },
+};
+
+MODULE_DESCRIPTION("MediaTek HDMI PHY Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
index a5cb07d12c9c..e53c6646571c 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_regs.h
@@ -227,6 +227,7 @@
#define DEEP_COLOR_EN BIT(0)
#define HDMI_AUDIO_TEST_SEL BIT(8)
#define HDMI2P0_EN BIT(11)
+#define HDMI_PSECUR_EN BIT(15)
#define HDMI_OUT_FIFO_EN BIT(16)
#define HDMI_OUT_FIFO_CLK_INV BIT(17)
#define MHL_MODE_ON BIT(28)
diff --git a/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
new file mode 100644
index 000000000000..8af5e6c1aecc
--- /dev/null
+++ b/drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *Copyright (c) 2018 MediaTek Inc.
+ *Author: Chunhui Dai <chunhui.dai@mediatek.com>
+ */
+
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/debugfs.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of_platform.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/phy/phy.h>
+#include "mtk_hdmi.h"
+
+#define HDMI_CON0 0x00
+#define RG_HDMITX_DRV_IBIAS (0)
+#define RG_HDMITX_DRV_IBIAS_MASK (0x3F << 0)
+#define RG_HDMITX_EN_SER (12)
+#define RG_HDMITX_EN_SER_MASK (0x0F << 12)
+#define RG_HDMITX_EN_SLDO (16)
+#define RG_HDMITX_EN_SLDO_MASK (0x0F << 16)
+#define RG_HDMITX_EN_PRED (20)
+#define RG_HDMITX_EN_PRED_MASK (0x0F << 20)
+#define RG_HDMITX_EN_IMP (24)
+#define RG_HDMITX_EN_IMP_MASK (0x0F << 24)
+#define RG_HDMITX_EN_DRV (28)
+#define RG_HDMITX_EN_DRV_MASK (0x0F << 28)
+
+#define HDMI_CON1 0x04
+#define RG_HDMITX_PRED_IBIAS (18)
+#define RG_HDMITX_PRED_IBIAS_MASK (0x0F << 18)
+#define RG_HDMITX_PRED_IMP (0x01 << 22)
+#define RG_HDMITX_DRV_IMP (26)
+#define RG_HDMITX_DRV_IMP_MASK (0x3F << 26)
+
+#define HDMI_CON2 0x08
+#define RG_HDMITX_EN_TX_CKLDO (0x01 << 0)
+#define RG_HDMITX_EN_TX_POSDIV (0x01 << 1)
+#define RG_HDMITX_TX_POSDIV (3)
+#define RG_HDMITX_TX_POSDIV_MASK (0x03 << 3)
+#define RG_HDMITX_EN_MBIAS (0x01 << 6)
+#define RG_HDMITX_MBIAS_LPF_EN (0x01 << 7)
+
+#define HDMI_CON4 0x10
+#define RG_HDMITX_RESERVE_MASK (0xFFFFFFFF << 0)
+
+#define HDMI_CON6 0x18
+#define RG_HTPLL_BR (0)
+#define RG_HTPLL_BR_MASK (0x03 << 0)
+#define RG_HTPLL_BC (2)
+#define RG_HTPLL_BC_MASK (0x03 << 2)
+#define RG_HTPLL_BP (4)
+#define RG_HTPLL_BP_MASK (0x0F << 4)
+#define RG_HTPLL_IR (8)
+#define RG_HTPLL_IR_MASK (0x0F << 8)
+#define RG_HTPLL_IC (12)
+#define RG_HTPLL_IC_MASK (0x0F << 12)
+#define RG_HTPLL_POSDIV (16)
+#define RG_HTPLL_POSDIV_MASK (0x03 << 16)
+#define RG_HTPLL_PREDIV (18)
+#define RG_HTPLL_PREDIV_MASK (0x03 << 18)
+#define RG_HTPLL_FBKSEL (20)
+#define RG_HTPLL_FBKSEL_MASK (0x03 << 20)
+#define RG_HTPLL_RLH_EN (0x01 << 22)
+#define RG_HTPLL_FBKDIV (24)
+#define RG_HTPLL_FBKDIV_MASK (0x7F << 24)
+#define RG_HTPLL_EN (0x01 << 31)
+
+#define HDMI_CON7 0x1c
+#define RG_HTPLL_AUTOK_EN (0x01 << 23)
+#define RG_HTPLL_DIVEN (28)
+#define RG_HTPLL_DIVEN_MASK (0x07 << 28)
+
+static inline struct mtk_hdmi_phy *to_mtk_hdmi_pll(struct clk_hw *hw)
+{
+ return container_of(hw, struct mtk_hdmi_phy, pll_hw);
+}
+
+static inline void mtk_hdmi_pll_mask(struct mtk_hdmi_phy *hdmi_phy, u32 offset,
+ u32 val, u32 mask)
+{
+ u32 tmp = readl(hdmi_phy->regs + offset) & ~mask;
+
+ tmp |= (val & mask);
+ writel(tmp, hdmi_phy->regs + offset);
+}
+
+static int mtk_hdmi_pll_enable(struct clk_hw *hw)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_pll(hw);
+
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON7, RG_HTPLL_AUTOK_EN,
+ RG_HTPLL_AUTOK_EN);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, 0, RG_HTPLL_RLH_EN);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, (0x3 << RG_HTPLL_POSDIV),
+ RG_HTPLL_POSDIV_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_MBIAS,
+ RG_HDMITX_EN_MBIAS);
+ usleep_range(80, 100);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, RG_HTPLL_EN, RG_HTPLL_EN);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_CKLDO,
+ RG_HDMITX_EN_TX_CKLDO);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, (0xf << RG_HDMITX_EN_SLDO),
+ RG_HDMITX_EN_SLDO_MASK);
+ usleep_range(80, 100);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN,
+ RG_HDMITX_MBIAS_LPF_EN);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV,
+ RG_HDMITX_EN_TX_POSDIV);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, (0xf << RG_HDMITX_EN_SER),
+ RG_HDMITX_EN_SER_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, (0xf << RG_HDMITX_EN_PRED),
+ RG_HDMITX_EN_PRED_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, (0xf << RG_HDMITX_EN_DRV),
+ RG_HDMITX_EN_DRV_MASK);
+ usleep_range(80, 100);
+ return 0;
+}
+
+static void mtk_hdmi_pll_disable(struct clk_hw *hw)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_pll(hw);
+
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, 0, RG_HDMITX_EN_DRV_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, 0, RG_HDMITX_EN_PRED_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, 0, RG_HDMITX_EN_SER_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, 0, RG_HDMITX_EN_TX_POSDIV);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, 0, RG_HDMITX_MBIAS_LPF_EN);
+ usleep_range(80, 100);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, 0, RG_HDMITX_EN_SLDO_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, 0, RG_HDMITX_EN_TX_CKLDO);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, 0, RG_HTPLL_EN);
+ usleep_range(80, 100);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, 0, RG_HDMITX_EN_MBIAS);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, 0, RG_HTPLL_POSDIV_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, 0, RG_HTPLL_RLH_EN);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON7, 0, RG_HTPLL_AUTOK_EN);
+ usleep_range(80, 100);
+}
+
+static int mtk_hdmi_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_pll(hw);
+ u32 pos_div;
+
+ if (rate <= 64000000)
+ pos_div = 3;
+ else if (rate <= 12800000)
+ pos_div = 1;
+ else
+ pos_div = 1;
+
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, (0x3 << RG_HTPLL_PREDIV),
+ RG_HTPLL_PREDIV_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, (0x3 << RG_HTPLL_POSDIV),
+ RG_HTPLL_POSDIV_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IC),
+ RG_HTPLL_IC_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_IR),
+ RG_HTPLL_IR_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, (pos_div << RG_HDMITX_TX_POSDIV),
+ RG_HDMITX_TX_POSDIV_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, (1 << RG_HTPLL_FBKSEL),
+ RG_HTPLL_FBKSEL_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, (19 << RG_HTPLL_FBKDIV),
+ RG_HTPLL_FBKDIV_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON7, (0x2 << RG_HTPLL_DIVEN),
+ RG_HTPLL_DIVEN_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, (0xc << RG_HTPLL_BP),
+ RG_HTPLL_BP_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, (0x2 << RG_HTPLL_BC),
+ RG_HTPLL_BC_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, (0x1 << RG_HTPLL_BR),
+ RG_HTPLL_BR_MASK);
+
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON1, 0, RG_HDMITX_PRED_IMP);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON1, (0x3 << RG_HDMITX_PRED_IBIAS),
+ RG_HDMITX_PRED_IBIAS_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, (0x0 << RG_HDMITX_EN_IMP),
+ RG_HDMITX_EN_IMP_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON1, (0x28 << RG_HDMITX_DRV_IMP),
+ RG_HDMITX_DRV_IMP_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON4, 0x28, RG_HDMITX_RESERVE_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, (0xa << RG_HDMITX_DRV_IBIAS),
+ RG_HDMITX_DRV_IBIAS_MASK);
+ return 0;
+}
+
+static long mtk_hdmi_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_pll(hw);
+
+ hdmi_phy->pll_rate = rate;
+ return rate;
+}
+
+static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_pll(hw);
+
+ return hdmi_phy->pll_rate;
+}
+
+static const struct clk_ops mtk_hdmi_phy_pll_ops = {
+ .enable = mtk_hdmi_pll_enable,
+ .disable = mtk_hdmi_pll_disable,
+ .set_rate = mtk_hdmi_pll_set_rate,
+ .round_rate = mtk_hdmi_pll_round_rate,
+ .recalc_rate = mtk_hdmi_pll_recalc_rate,
+};
+
+static void mtk_hdmi_phy_enable_tmds(struct mtk_hdmi_phy *hdmi_phy)
+{
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON7, RG_HTPLL_AUTOK_EN,
+ RG_HTPLL_AUTOK_EN);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, 0, RG_HTPLL_RLH_EN);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, (0x3 << RG_HTPLL_POSDIV),
+ RG_HTPLL_POSDIV_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_MBIAS,
+ RG_HDMITX_EN_MBIAS);
+ usleep_range(80, 100);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, RG_HTPLL_EN, RG_HTPLL_EN);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_CKLDO,
+ RG_HDMITX_EN_TX_CKLDO);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, (0xf << RG_HDMITX_EN_SLDO),
+ RG_HDMITX_EN_SLDO_MASK);
+ usleep_range(80, 100);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, RG_HDMITX_MBIAS_LPF_EN,
+ RG_HDMITX_MBIAS_LPF_EN);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, RG_HDMITX_EN_TX_POSDIV,
+ RG_HDMITX_EN_TX_POSDIV);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, (0xf << RG_HDMITX_EN_SER),
+ RG_HDMITX_EN_SER_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, (0xf << RG_HDMITX_EN_PRED),
+ RG_HDMITX_EN_PRED_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, (0xf << RG_HDMITX_EN_DRV),
+ RG_HDMITX_EN_DRV_MASK);
+ usleep_range(80, 100);
+}
+
+static void mtk_hdmi_phy_disable_tmds(struct mtk_hdmi_phy *hdmi_phy)
+{
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, 0, RG_HDMITX_EN_DRV_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, 0, RG_HDMITX_EN_PRED_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, 0, RG_HDMITX_EN_SER_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, 0, RG_HDMITX_EN_TX_POSDIV);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, 0, RG_HDMITX_MBIAS_LPF_EN);
+ usleep_range(80, 100);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON0, 0, RG_HDMITX_EN_SLDO_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, 0, RG_HDMITX_EN_TX_CKLDO);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, 0, RG_HTPLL_EN);
+ usleep_range(80, 100);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON2, 0, RG_HDMITX_EN_MBIAS);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, 0, RG_HTPLL_POSDIV_MASK);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON6, 0, RG_HTPLL_RLH_EN);
+ mtk_hdmi_pll_mask(hdmi_phy, HDMI_CON7, 0, RG_HTPLL_AUTOK_EN);
+ usleep_range(80, 100);
+}
+
+static int mtk_hdmi_phy_power_on(struct phy *phy)
+{
+ struct mtk_hdmi_phy *hdmi_phy = phy_get_drvdata(phy);
+ int ret;
+
+ ret = clk_prepare_enable(hdmi_phy->pll);
+ if (ret < 0)
+ return ret;
+
+ mtk_hdmi_phy_enable_tmds(hdmi_phy);
+
+ return 0;
+}
+
+static int mtk_hdmi_phy_power_off(struct phy *phy)
+{
+ struct mtk_hdmi_phy *hdmi_phy = phy_get_drvdata(phy);
+
+ mtk_hdmi_phy_disable_tmds(hdmi_phy);
+ clk_disable_unprepare(hdmi_phy->pll);
+
+ return 0;
+}
+
+static const struct phy_ops mtk_hdmi_phy_dev_ops = {
+ .power_on = mtk_hdmi_phy_power_on,
+ .power_off = mtk_hdmi_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+struct mtk_hdmi_phy_conf mtk_hdmi_phy_2701_conf = {
+ .tz_enabled = false,
+ .hdmi_phy_clk_ops = &mtk_hdmi_phy_pll_ops,
+ .hdmi_phy_dev_ops = &mtk_hdmi_phy_dev_ops,
+};
+
+MODULE_AUTHOR("Chunhui Dai <chunhui.dai@mediatek.com>");
+MODULE_DESCRIPTION("MediaTek HDMI PHY Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 51cb9cfb6646..1a35fdd405d8 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -21,6 +21,7 @@
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
#include <linux/types.h>
+#include "mtk_hdmi.h"
#define HDMI_CON0 0x00
#define RG_HDMITX_PLL_EN BIT(31)
@@ -123,20 +124,6 @@
#define RGS_HDMITX_5T1_EDG (0xf << 4)
#define RGS_HDMITX_PLUG_TST BIT(0)
-struct mtk_hdmi_phy {
- void __iomem *regs;
- struct device *dev;
- struct clk *pll;
- struct clk_hw pll_hw;
- unsigned long pll_rate;
- u8 drv_imp_clk;
- u8 drv_imp_d2;
- u8 drv_imp_d1;
- u8 drv_imp_d0;
- u32 ibias;
- u32 ibias_up;
-};
-
static const u8 PREDIV[3][4] = {
{0x0, 0x0, 0x0, 0x0}, /* 27Mhz */
{0x1, 0x1, 0x1, 0x1}, /* 74Mhz */
@@ -367,7 +354,7 @@ static unsigned long mtk_hdmi_pll_recalc_rate(struct clk_hw *hw,
return hdmi_phy->pll_rate;
}
-static const struct clk_ops mtk_hdmi_pll_ops = {
+static const struct clk_ops mtk_hdmi_phy_pll_ops = {
.prepare = mtk_hdmi_pll_prepare,
.unprepare = mtk_hdmi_pll_unprepare,
.set_rate = mtk_hdmi_pll_set_rate,
@@ -414,118 +401,16 @@ static int mtk_hdmi_phy_power_off(struct phy *phy)
return 0;
}
-static const struct phy_ops mtk_hdmi_phy_ops = {
+static const struct phy_ops mtk_hdmi_phy_dev_ops = {
.power_on = mtk_hdmi_phy_power_on,
.power_off = mtk_hdmi_phy_power_off,
.owner = THIS_MODULE,
};
-static int mtk_hdmi_phy_probe(struct platform_device *pdev)
-{
- struct device *dev = &pdev->dev;
- struct mtk_hdmi_phy *hdmi_phy;
- struct resource *mem;
- struct clk *ref_clk;
- const char *ref_clk_name;
- struct clk_init_data clk_init = {
- .ops = &mtk_hdmi_pll_ops,
- .num_parents = 1,
- .parent_names = (const char * const *)&ref_clk_name,
- .flags = CLK_SET_RATE_PARENT | CLK_SET_RATE_GATE,
- };
- struct phy *phy;
- struct phy_provider *phy_provider;
- int ret;
-
- hdmi_phy = devm_kzalloc(dev, sizeof(*hdmi_phy), GFP_KERNEL);
- if (!hdmi_phy)
- return -ENOMEM;
-
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- hdmi_phy->regs = devm_ioremap_resource(dev, mem);
- if (IS_ERR(hdmi_phy->regs)) {
- ret = PTR_ERR(hdmi_phy->regs);
- dev_err(dev, "Failed to get memory resource: %d\n", ret);
- return ret;
- }
-
- ref_clk = devm_clk_get(dev, "pll_ref");
- if (IS_ERR(ref_clk)) {
- ret = PTR_ERR(ref_clk);
- dev_err(&pdev->dev, "Failed to get PLL reference clock: %d\n",
- ret);
- return ret;
- }
- ref_clk_name = __clk_get_name(ref_clk);
-
- ret = of_property_read_string(dev->of_node, "clock-output-names",
- &clk_init.name);
- if (ret < 0) {
- dev_err(dev, "Failed to read clock-output-names: %d\n", ret);
- return ret;
- }
-
- hdmi_phy->pll_hw.init = &clk_init;
- hdmi_phy->pll = devm_clk_register(dev, &hdmi_phy->pll_hw);
- if (IS_ERR(hdmi_phy->pll)) {
- ret = PTR_ERR(hdmi_phy->pll);
- dev_err(dev, "Failed to register PLL: %d\n", ret);
- return ret;
- }
-
- ret = of_property_read_u32(dev->of_node, "mediatek,ibias",
- &hdmi_phy->ibias);
- if (ret < 0) {
- dev_err(&pdev->dev, "Failed to get ibias: %d\n", ret);
- return ret;
- }
-
- ret = of_property_read_u32(dev->of_node, "mediatek,ibias_up",
- &hdmi_phy->ibias_up);
- if (ret < 0) {
- dev_err(&pdev->dev, "Failed to get ibias up: %d\n", ret);
- return ret;
- }
-
- dev_info(dev, "Using default TX DRV impedance: 4.2k/36\n");
- hdmi_phy->drv_imp_clk = 0x30;
- hdmi_phy->drv_imp_d2 = 0x30;
- hdmi_phy->drv_imp_d1 = 0x30;
- hdmi_phy->drv_imp_d0 = 0x30;
-
- phy = devm_phy_create(dev, NULL, &mtk_hdmi_phy_ops);
- if (IS_ERR(phy)) {
- dev_err(dev, "Failed to create HDMI PHY\n");
- return PTR_ERR(phy);
- }
- phy_set_drvdata(phy, hdmi_phy);
-
- phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
- if (IS_ERR(phy_provider))
- return PTR_ERR(phy_provider);
-
- hdmi_phy->dev = dev;
- return of_clk_add_provider(dev->of_node, of_clk_src_simple_get,
- hdmi_phy->pll);
-}
-
-static int mtk_hdmi_phy_remove(struct platform_device *pdev)
-{
- return 0;
-}
-
-static const struct of_device_id mtk_hdmi_phy_match[] = {
- { .compatible = "mediatek,mt8173-hdmi-phy", },
- {},
-};
-
-struct platform_driver mtk_hdmi_phy_driver = {
- .probe = mtk_hdmi_phy_probe,
- .remove = mtk_hdmi_phy_remove,
- .driver = {
- .name = "mediatek-hdmi-phy",
- .of_match_table = mtk_hdmi_phy_match,
- },
+struct mtk_hdmi_phy_conf mtk_hdmi_phy_8173_conf = {
+ .tz_enabled = true,
+ .hdmi_phy_clk_ops = &mtk_hdmi_phy_pll_ops,
+ .hdmi_phy_dev_ops = &mtk_hdmi_phy_dev_ops,
};
MODULE_AUTHOR("Jie Qiu <jie.qiu@mediatek.com>");
--
2.12.5
^ permalink raw reply related
* [PATCH v1 3/7] drm/mediatek: add dpi driver for mt2701 and mt7623
From: Bibby Hsieh @ 2018-05-14 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514075243.5442-1-bibby.hsieh@mediatek.com>
From: chunhui dai <chunhui.dai@mediatek.com>
This patch adds dpi driver suppot for both mt2701 and mt7623.
And also support other (existing or future) chips that use
the same binding and driver.
Signed-off-by: chunhui dai <chunhui.dai@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 24 ++++++++++++++++++++++--
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 2b8b34c72697..e1af1d0d213d 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -640,8 +640,7 @@ static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)
}
drm_encoder_helper_add(&dpi->encoder, &mtk_dpi_encoder_helper_funcs);
- /* Currently DPI0 is fixed to be driven by OVL1 */
- dpi->encoder.possible_crtcs = BIT(1);
+ dpi->encoder.possible_crtcs = BIT(0) | BIT(1);
dpi->encoder.bridge->encoder = &dpi->encoder;
ret = drm_bridge_attach(&dpi->encoder, dpi->encoder.bridge, NULL);
if (ret) {
@@ -690,12 +689,33 @@ static unsigned int mt8173_calculate_factor(int clock)
return 2 * 3;
}
+static unsigned int mt2701_calculate_factor(int clock)
+{
+ if (clock <= 64000)
+ return 16;
+ else if (clock <= 128000)
+ return 8;
+ else if (clock <= 256000)
+ return 4;
+ else
+ return 2;
+}
+
static const struct mtk_dpi_conf mt8173_conf = {
.cal_factor = mt8173_calculate_factor,
.reg_h_fre_con = 0xe0,
};
+static const struct mtk_dpi_conf mt2701_conf = {
+ .cal_factor = mt2701_calculate_factor,
+ .reg_h_fre_con = 0xb0,
+ .edge_sel_en = true,
+};
+
static const struct of_device_id mtk_dpi_of_ids[] = {
+ { .compatible = "mediatek,mt2701-dpi",
+ .data = &mt2701_conf,
+ },
{ .compatible = "mediatek,mt8173-dpi",
.data = &mt8173_conf,
},
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index a2ca90fc403c..f4fb86ab7b8d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -372,6 +372,7 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ .compatible = "mediatek,mt8173-disp-ufoe", .data = (void *)MTK_DISP_UFOE },
{ .compatible = "mediatek,mt2701-dsi", .data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt8173-dsi", .data = (void *)MTK_DSI },
+ { .compatible = "mediatek,mt2701-dpi", .data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt8173-dpi", .data = (void *)MTK_DPI },
{ .compatible = "mediatek,mt2701-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8173-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
--
2.12.5
^ permalink raw reply related
* [PATCH v1 2/7] drm/mediatek: fix to get right bridge for dpi encoder
From: Bibby Hsieh @ 2018-05-14 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514075243.5442-1-bibby.hsieh@mediatek.com>
From: chunhui dai <chunhui.dai@mediatek.com>
1, dpi is an encoder, there is an bridge in the struct
of decoder, we could use it.
2, using of_graph_get_remote_port_parent to get right
bridge in device tree.
Signed-off-by: chunhui dai <chunhui.dai@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 0a44ab175422..2b8b34c72697 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -63,7 +63,6 @@ enum mtk_dpi_out_color_format {
struct mtk_dpi {
struct mtk_ddp_comp ddp_comp;
struct drm_encoder encoder;
- struct drm_bridge *bridge;
void __iomem *regs;
struct device *dev;
struct clk *engine_clk;
@@ -643,8 +642,8 @@ static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)
/* Currently DPI0 is fixed to be driven by OVL1 */
dpi->encoder.possible_crtcs = BIT(1);
-
- ret = drm_bridge_attach(&dpi->encoder, dpi->bridge, NULL);
+ dpi->encoder.bridge->encoder = &dpi->encoder;
+ ret = drm_bridge_attach(&dpi->encoder, dpi->encoder.bridge, NULL);
if (ret) {
dev_err(dev, "Failed to attach bridge: %d\n", ret);
goto err_cleanup;
@@ -709,7 +708,7 @@ static int mtk_dpi_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct mtk_dpi *dpi;
struct resource *mem;
- struct device_node *bridge_node;
+ struct device_node *ep, *bridge_node;
int comp_id;
const struct of_device_id *match;
int ret;
@@ -759,15 +758,21 @@ static int mtk_dpi_probe(struct platform_device *pdev)
return -EINVAL;
}
- bridge_node = of_graph_get_remote_node(dev->of_node, 0, 0);
- if (!bridge_node)
+ ep = of_graph_get_next_endpoint(dev->of_node, NULL);
+ if (ep) {
+ bridge_node = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
+ }
+ if (!bridge_node) {
+ dev_err(dev, "Failed to find bridge node\n");
return -ENODEV;
+ }
dev_info(dev, "Found bridge node: %pOF\n", bridge_node);
- dpi->bridge = of_drm_find_bridge(bridge_node);
+ dpi->encoder.bridge = of_drm_find_bridge(bridge_node);
of_node_put(bridge_node);
- if (!dpi->bridge)
+ if (!dpi->encoder.bridge)
return -EPROBE_DEFER;
comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DPI);
--
2.12.5
^ permalink raw reply related
* [PATCH v1 1/7] drm/mediatek: move dpi private data to device
From: Bibby Hsieh @ 2018-05-14 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180514075243.5442-1-bibby.hsieh@mediatek.com>
From: chunhui dai <chunhui.dai@mediatek.com>
move clock factor and edge enable setting to private data.
Signed-off-by: chunhui dai <chunhui.dai@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 82 ++++++++++++++++++++++++++-------
drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 2 +-
2 files changed, 66 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index e80a603e5fb0..993dc44368bd 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -71,11 +71,13 @@ struct mtk_dpi {
struct clk *tvd_clk;
int irq;
struct drm_display_mode mode;
+ const struct mtk_dpi_conf *conf;
enum mtk_dpi_out_color_format color_format;
enum mtk_dpi_out_yc_map yc_map;
enum mtk_dpi_out_bit_num bit_num;
enum mtk_dpi_out_channel_swap channel_swap;
bool power_sta;
+ int refcount;
u8 power_ctl;
};
@@ -115,6 +117,12 @@ struct mtk_dpi_yc_limit {
u16 c_bottom;
};
+struct mtk_dpi_conf {
+ unsigned int (*cal_factor)(int clock);
+ const u32 reg_h_fre_con;
+ bool edge_sel_en;
+};
+
static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
{
u32 tmp = readl(dpi->regs + offset) & ~mask;
@@ -340,7 +348,13 @@ static void mtk_dpi_config_swap_input(struct mtk_dpi *dpi, bool enable)
static void mtk_dpi_config_2n_h_fre(struct mtk_dpi *dpi)
{
- mtk_dpi_mask(dpi, DPI_H_FRE_CON, H_FRE_2N, H_FRE_2N);
+ mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, H_FRE_2N, H_FRE_2N);
+}
+
+static void mtk_dpi_config_disable_edge(struct mtk_dpi *dpi)
+{
+ if (dpi->conf->edge_sel_en)
+ mtk_dpi_mask(dpi, dpi->conf->reg_h_fre_con, 0, EDGE_SEL_EN);
}
static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
@@ -368,6 +382,12 @@ static void mtk_dpi_config_color_format(struct mtk_dpi *dpi,
static void mtk_dpi_power_off(struct mtk_dpi *dpi, enum mtk_dpi_power_ctl pctl)
{
+ if (WARN_ON(dpi->refcount == 0))
+ return;
+
+ if (--dpi->refcount != 0)
+ return;
+
dpi->power_ctl &= ~pctl;
if ((dpi->power_ctl & DPI_POWER_START) ||
@@ -385,16 +405,19 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi, enum mtk_dpi_power_ctl pctl)
static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum mtk_dpi_power_ctl pctl)
{
- int ret;
+ int ret = 0;
+
+ if (++dpi->refcount != 1)
+ return 0;
dpi->power_ctl |= pctl;
if (!(dpi->power_ctl & DPI_POWER_START) &&
!(dpi->power_ctl & DPI_POWER_ENABLE))
- return 0;
+ goto err_refcount;
if (dpi->power_sta)
- return 0;
+ goto err_refcount;
ret = clk_prepare_enable(dpi->engine_clk);
if (ret) {
@@ -416,6 +439,8 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum mtk_dpi_power_ctl pctl)
clk_disable_unprepare(dpi->engine_clk);
err_eng:
dpi->power_ctl &= ~pctl;
+err_refcount:
+ dpi->refcount--;
return ret;
}
@@ -433,16 +458,13 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
unsigned long pll_rate;
unsigned int factor;
+ if (!dpi) {
+ dev_err(dpi->dev, "invalid argument\n");
+ return -EINVAL;
+ }
/* let pll_rate can fix the valid range of tvdpll (1G~2GHz) */
pix_rate = 1000UL * mode->clock;
- if (mode->clock <= 27000)
- factor = 16 * 3;
- else if (mode->clock <= 84000)
- factor = 8 * 3;
- else if (mode->clock <= 167000)
- factor = 4 * 3;
- else
- factor = 2 * 3;
+ factor = dpi->conf->cal_factor(mode->clock);
pll_rate = pix_rate * factor;
dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n",
@@ -518,6 +540,7 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
mtk_dpi_config_yc_map(dpi, dpi->yc_map);
mtk_dpi_config_color_format(dpi, dpi->color_format);
mtk_dpi_config_2n_h_fre(dpi);
+ mtk_dpi_config_disable_edge(dpi);
mtk_dpi_sw_reset(dpi, false);
return 0;
@@ -656,6 +679,31 @@ static const struct component_ops mtk_dpi_component_ops = {
.unbind = mtk_dpi_unbind,
};
+static unsigned int mt8173_calculate_factor(int clock)
+{
+ if (clock <= 27000)
+ return 16 * 3;
+ else if (clock <= 74250)
+ return 8 * 3;
+ else if (clock <= 167000)
+ return 4 * 3;
+ else
+ return 2 * 3;
+}
+
+static const struct mtk_dpi_conf mt8173_conf = {
+ .cal_factor = mt8173_calculate_factor,
+ .reg_h_fre_con = 0xe0,
+};
+
+static const struct of_device_id mtk_dpi_of_ids[] = {
+ { .compatible = "mediatek,mt8173-dpi",
+ .data = &mt8173_conf,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, mtk_dpi_of_ids);
+
static int mtk_dpi_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -663,13 +711,18 @@ static int mtk_dpi_probe(struct platform_device *pdev)
struct resource *mem;
struct device_node *bridge_node;
int comp_id;
+ const struct of_device_id *match;
int ret;
+ match = of_match_node(mtk_dpi_of_ids, dev->of_node);
+ if (!match)
+ return -ENODEV;
dpi = devm_kzalloc(dev, sizeof(*dpi), GFP_KERNEL);
if (!dpi)
return -ENOMEM;
dpi->dev = dev;
+ dpi->conf = (struct mtk_dpi_conf *)match->data;
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dpi->regs = devm_ioremap_resource(dev, mem);
@@ -748,11 +801,6 @@ static int mtk_dpi_remove(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id mtk_dpi_of_ids[] = {
- { .compatible = "mediatek,mt8173-dpi", },
- {}
-};
-
struct platform_driver mtk_dpi_driver = {
.probe = mtk_dpi_probe,
.remove = mtk_dpi_remove,
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi_regs.h b/drivers/gpu/drm/mediatek/mtk_dpi_regs.h
index 4b6ad4751a31..d9db8c4cacd7 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi_regs.h
+++ b/drivers/gpu/drm/mediatek/mtk_dpi_regs.h
@@ -223,6 +223,6 @@
#define ESAV_CODE2 (0xFFF << 0)
#define ESAV_CODE3_MSB BIT(16)
-#define DPI_H_FRE_CON 0xE0
+#define EDGE_SEL_EN BIT(5)
#define H_FRE_2N BIT(25)
#endif /* __MTK_DPI_REGS_H */
--
2.12.5
^ permalink raw reply related
* [PATCH v1 0/7] drm/mediatek: support hdmi output for mt2701 and mt7623
From: Bibby Hsieh @ 2018-05-14 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In order to support HDMI on mt2701,
we have to make some modifications.
1) Add the HDMI driver.
2) Add the DPI driver.
3) Add a mechanism that config output component by dts.
Changes since v0:
- Correct some typos in commit message.
- Fixup the build warning (tmp variable didn't be initialized)
Bibby Hsieh (3):
drm/mediatek: implement connection from BLS to DPI0
drm/mediatek: add a error return value when clock driver has been
prepared
drm/mediatek: config component output by device node port
chunhui dai (4):
drm/mediatek: move dpi private data to device
drm/mediatek: fix to get right bridge for dpi encoder
drm/mediatek: add dpi driver for mt2701 and mt7623
drm/mediatek: add hdmi driver for different hardware
drivers/gpu/drm/mediatek/Makefile | 4 +-
drivers/gpu/drm/mediatek/mtk_dpi.c | 125 +++++++---
drivers/gpu/drm/mediatek/mtk_dpi_regs.h | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 14 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 38 ++-
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 4 +-
drivers/gpu/drm/mediatek/mtk_hdmi.c | 88 +++++--
drivers/gpu/drm/mediatek/mtk_hdmi.h | 28 +++
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c | 157 +++++++++++++
drivers/gpu/drm/mediatek/mtk_hdmi_regs.h | 1 +
drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c | 307 +++++++++++++++++++++++++
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 129 +----------
13 files changed, 716 insertions(+), 183 deletions(-)
create mode 100644 drivers/gpu/drm/mediatek/mtk_hdmi_phy.c
create mode 100644 drivers/gpu/drm/mediatek/mtk_mt2701_hdmi_phy.c
--
2.12.5
^ permalink raw reply
* [PATCH 3/9] soc: fsl: set rcpm bit for FTM
From: Yinbo Zhu @ 2018-05-14 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM4PR0401MB16995DFED0376ACE0DD5E7A78F9F0@AM4PR0401MB1699.eurprd04.prod.outlook.com>
-----Original Message-----
From: Leo Li
Sent: 2018?5?12? 1:00
To: Yinbo Zhu <yinbo.zhu@nxp.com>; Yinbo Zhu <yinbo.zhu@nxp.com>; Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>; Catalin Marinas ) <catalin.marinas@arm.com>; Will Deacon ) <will.deacon@arm.com>; Lorenzo Pieralisi ) <lorenzo.pieralisi@arm.com>
Cc: Xiaobo Xie <xiaobo.xie@nxp.com>; Ran Wang <ran.wang_1@nxp.com>; Daniel Lezcano <daniel.lezcano@linaro.org>; Thomas Gleixner <tglx@linutronix.de>; Shawn Guo <shawnguo@kernel.org>; Madalin-cristian Bucur <madalin.bucur@nxp.com>; Z.q. Hou <zhiqiang.hou@nxp.com>; Jerry Huang <jerry.huang@nxp.com>; M.h. Lian <minghuan.lian@nxp.com>; Qiang Zhao <qiang.zhao@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>; Jiaheng Fan <jiaheng.fan@nxp.com>; Po Liu <po.liu@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Horia Geant? <horia.geanta@nxp.com>; Priyanka Jain <priyanka.jain@nxp.com>; Sumit Garg <sumit.garg@nxp.com>; costi <constantin.tudor@freescale.com>; Bogdan Purcareata <bogdan.purcareata@nxp.com>; open list:CLOCKSOURCE, CLOCKEVENT DRIVERS <linux-kernel@vger.kernel.org>; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>; linux-arm-kernel at lists.infradead.org; open list:FREESCALE SOC DRIVERS <linuxppc-dev@lists.ozlabs.org>; Andy Tang <andy.tang@nxp.com>; Ying Zhang <ying.zhang22455@nxp.com>
Subject: RE: [PATCH 3/9] soc: fsl: set rcpm bit for FTM
> -----Original Message-----
> From: Yinbo Zhu [mailto:yinbo.zhu at nxp.com]
> Sent: Thursday, May 10, 2018 10:35 PM
> To: Yinbo Zhu <yinbo.zhu@nxp.com>; Rob Herring <robh+dt@kernel.org>;
> Mark Rutland <mark.rutland@arm.com>; Catalin Marinas )
> <catalin.marinas@arm.com>; Will Deacon ) <will.deacon@arm.com>;
> Lorenzo Pieralisi ) <lorenzo.pieralisi@arm.com>; Leo Li
> <leoyang.li@nxp.com>
> Cc: Xiaobo Xie <xiaobo.xie@nxp.com>; Ran Wang <ran.wang_1@nxp.com>;
> Daniel Lezcano <daniel.lezcano@linaro.org>; Thomas Gleixner
> <tglx@linutronix.de>; Shawn Guo <shawnguo@kernel.org>;
> Madalin-cristian Bucur <madalin.bucur@nxp.com>; Z.q. Hou
> <zhiqiang.hou@nxp.com>; Jerry Huang <jerry.huang@nxp.com>; M.h. Lian
> <minghuan.lian@nxp.com>; Qiang Zhao <qiang.zhao@nxp.com>; Fabio
> Estevam <fabio.estevam@nxp.com>; Jiaheng Fan <jiaheng.fan@nxp.com>; Po
> Liu <po.liu@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>; Horia Geant?
> <horia.geanta@nxp.com>; Priyanka Jain <priyanka.jain@nxp.com>; Sumit
> Garg <sumit.garg@nxp.com>; costi <constantin.tudor@freescale.com>;
> Bogdan Purcareata <bogdan.purcareata@nxp.com>; Meng Yi
> <meng.yi@nxp.com>; Wang Dongsheng <dongsheng.wang@nxp.com>; open
> list:CLOCKSOURCE, CLOCKEVENT DRIVERS <linux-kernel@vger.kernel.org>;
> open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> <devicetree@vger.kernel.org>; linux-arm-kernel at lists.infradead.org;
> open list:FREESCALE SOC DRIVERS <linuxppc-dev@lists.ozlabs.org>; Andy
> Tang <andy.tang@nxp.com>; Ying Zhang <ying.zhang22455@nxp.com>
> Subject: [PATCH 3/9] soc: fsl: set rcpm bit for FTM
>
> From: Zhang Ying-22455 <ying.zhang22455@nxp.com>
>
> Set RCPM for FTM when using FTM as wakeup source. Because the RCPM
> module of each platform has different big-end and little-end mode,
> there need to set RCPM depending on the platform.
>
> Signed-off-by: Zhang Ying-22455 <ying.zhang22455@nxp.com>
> Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
> ---
> .../devicetree/bindings/timer/fsl,ftm-timer.txt | 7 ++
> drivers/soc/fsl/layerscape/ftm_alarm.c | 92 ++++++++++++++++++-
> 2 files changed, 94 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> index aa8c402..15ead58 100644
> --- a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> +++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
> @@ -3,6 +3,13 @@ Freescale FlexTimer Module (FTM) Timer Required
> properties:
>
> - compatible : should be "fsl,ftm-timer"
>Hi Yingbo,
>This is a change that breaks backward compatibility and not acceptable.
Hi leo,
This patch if I keep the change as inner patch and push it to dash-linnux but I will not push it to upstream, It's okay?
As far as I know, there was a other patch and file for replace the file and that the patch is already on the upstream
https://patchwork.kernel.org/patch/9391293/
> + Possible compatibles for ARM:
> + "fsl,ls1012a-ftm"
> + "fsl,ls1021a-ftm"
> + "fsl,ls1043a-ftm"
> + "fsl,ls1046a-ftm"
> + "fsl,ls1088a-ftm"
> + "fsl,ls208xa-ftm"
> - reg : Specifies base physical address and size of the register sets for the
> clock event device and clock source device.
> - interrupts : Should be the clock event device interrupt.
> diff --git a/drivers/soc/fsl/layerscape/ftm_alarm.c
> b/drivers/soc/fsl/layerscape/ftm_alarm.c
> index 6f9882f..811dcfa 100644
> --- a/drivers/soc/fsl/layerscape/ftm_alarm.c
> +++ b/drivers/soc/fsl/layerscape/ftm_alarm.c
>There is no such file in the mainline kernel. So it looks like the patch set is
> based on some internal git repo instead of the upstream Linux kernel. This kind of patches
> shouldn't be sent to the upstream mailing list for review.
>Regards,
>Leo
This patch will not to upstream.
Regards,
Yinbo.
^ permalink raw reply
* 答复: reply: [PATCH v3 1/2] PCI: kirin: Add MSI support
From: songxiaowei @ 2018-05-14 7:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VfHfUCNKNun4-bb2BhwV6D9jg2+hzVjrDER+af0SrzqjA@mail.gmail.com>
Hi Andy Shevchenko
> -----????-----
> ???: Andy Shevchenko [mailto:andy.shevchenko at gmail.com]
> ????: 2018?5?14? 15:17
> ???: songxiaowei <songxiaowei@hisilicon.com>
> ??: chenyao (F) <chenyao11@huawei.com>; Wangbinghui
> <wangbinghui@hisilicon.com>; Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>;
> Bjorn Helgaas <bhelgaas@google.com>; xuwei (O) <xuwei5@huawei.com>;
> Rob Herring <robh+dt@kernel.org>; Mark Rutland <mark.rutland@arm.com>;
> Catalin Marinas <catalin.marinas@arm.com>; Will Deacon
> <will.deacon@arm.com>; linux-pci at vger.kernel.org; Linux Kernel Mailing List
> <linux-kernel@vger.kernel.org>; linux-arm Mailing List
> <linux-arm-kernel@lists.infradead.org>; devicetree
> <devicetree@vger.kernel.org>; dimitrysh at google.com;
> guodong.xu at linaro.org; Suzhuangluan <suzhuangluan@hisilicon.com>; Kongfei
> <kongfei@hisilicon.com>
> ??: Re: reply: [PATCH v3 1/2] PCI: kirin: Add MSI support
>
> On Mon, May 14, 2018 at 4:11 AM, songxiaowei <songxiaowei@hisilicon.com>
> wrote:
>
> >> > + int ret;
> >> > +
> >> > + if (IS_ENABLED(CONFIG_PCI_MSI)) {
> >>
> >> > + pci->pp.msi_irq = platform_get_irq(pdev, 0);
> >> > + if (pci->pp.msi_irq < 0) {
> >> > + dev_err(&pdev->dev, "failed to get MSI IRQ
> >> (%d)\n",
> >> > + pci->pp.msi_irq);
> >>
> >> > + return -ENODEV;
> >>
> >> Why shadowing actual error code?
> > [songxiaowei] Sorry, I can't get your point about this, would you explain it
> for me.
>
> platform_get_irq() returns either correct IRQ number or negative error code.
> In the code above you shadow the actual error (as returned by that
> call) by -ENODEV. Any reason why?
>
[songxiaowei] I guess the reason is that she wanted to keep the same with other hosts,
So, you'd like to use "return pci->pp.msi_irq " instead of " return -ENODEV ".
> --
> With Best Regards,
> Andy Shevchenko
Thanks a lot,
Xiaowei.
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: jacopo mondi @ 2018-05-14 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513125755.GQ18974@bigcity.dyn.berto.se>
Hi Niklas,
On Sun, May 13, 2018 at 02:57:55PM +0200, Niklas S?derlund wrote:
> Hi Jacopo,
>
> Thanks for your patch.
>
> On 2018-05-11 12:00:02 +0200, Jacopo Mondi wrote:
> > Describe HDMI input connected to VIN4 interface for R-Car D3 Draak
> > development board.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > ---
> > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 68 ++++++++++++++++++++++++++
> > 1 file changed, 68 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > index d03f194..e0ce462 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> > @@ -59,6 +59,17 @@
> > };
> > };
> >
> > + hdmi-in {
> > + compatible = "hdmi-connector";
> > + type = "a";
> > +
> > + port {
> > + hdmi_con_in: endpoint {
> > + remote-endpoint = <&adv7612_in>;
> > + };
> > + };
> > + };
> > +
> > memory at 48000000 {
> > device_type = "memory";
> > /* first 128MB is reserved for secure area. */
> > @@ -142,6 +153,11 @@
> > groups = "usb0";
> > function = "usb0";
> > };
> > +
> > + vin4_pins: vin4 {
> > + groups = "vin4_data24", "vin4_sync", "vin4_clk", "vin4_clkenb";
> > + function = "vin4";
> > + };
> > };
> >
> > &i2c0 {
> > @@ -154,6 +170,35 @@
> > reg = <0x50>;
> > pagesize = <8>;
> > };
> > +
> > + hdmi-decoder at 4c {
> > + compatible = "adi,adv7612";
> > + reg = <0x4c>;
> > + default-input = <0>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port at 0 {
> > + reg = <0>;
> > + adv7612_in: endpoint {
> > + remote-endpoint = <&hdmi_con_in>;
> > + };
> > + };
> > +
> > + port at 2 {
> > + reg = <2>;
> > + adv7612_out: endpoint {
> > + pclk-sample = <0>;
> > + hsync-active = <0>;
> > + vsync-active = <0>;
>
> This differs from the Gen2 DT bindings which is a very similar hardware
> setup using the same components. Defining these properties will make the
> bus marked as V4L2_MBUS_PARALLEL instead of V4L2_MBUS_BT656.
And that's what we want....
>
> This will change how the hardware is configured for capture if the media
> bus is in a UYVY format, see VNMC_INF register in rvin_setup(). Maybe
> this it not an issue here but still I'm curious to why this differ
> between Gen2 and Gen3 :-)
Actually this won't impact the VIN configuration as this is the
'remote endpoint' from VIN perspective and the properties used to
configure the interface are the ones in the 'local endpoint'.
>
> > +
> > + remote-endpoint = <&vin4_in>;
> > + };
> > + };
> > + };
> > + };
> > };
> >
> > &i2c1 {
> > @@ -246,3 +291,26 @@
> > timeout-sec = <60>;
> > status = "okay";
> > };
> > +
> > +&vin4 {
> > + pinctrl-0 = <&vin4_pins>;
> > + pinctrl-names = "default";
> > +
> > + status = "okay";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port at 0 {
> > + reg = <0>;
> > +
> > + vin4_in: endpoint {
> > + hsync-active = <0>;
> > + vsync-active = <0>;
>
> Comparing this to the Gen2 bindings some properties are missing,
>
> bus-width = <24>;
> pclk-sample = <1>;
> data-active = <1>;
The VIN driver does not parse them, so there is no value in having
them there, if not confusing people as it happened to me reading the
Gen2 DT.
>
> This is not a big deal as the VIN driver don't use these properties so
> no functional change should come of this but still a difference.
Exactly.
On a side note. I have not seen a way to configure the pixel clock
sampling level in the interface datasheet. The register used to
configure synchronism signals polarities is VnDMR2, and there I read
we can configure HSYNC/VSYNC and CLOCKENB (which is data enable, not
pixel clock) polarities. Is it configured through some other
register?
>
> Over all I'm happy with this change but before I add my tag I would like
> to understand why it differs from the Gen2 configuration for the adv7612
> properties.
>
> Also on a side not it is possible with hardware switches on the board
> switch the VIN4 source to a completely different pipeline CVBS connector
> -> adv7180 -> VIN4. But I think it's best we keep the HDMI as default as
> this seems to be how the boards are shipped. But maybe mentioning this
> in the commit message would not hurt if you end-up resending the patch.
Oh I see. SW-49 to SW-52 enables the HDMI input, SW53-SW54 CVBS one.
And actually, reading the 'initial setting of slide switches' in the
Draak board manual, it turns out that the board default configuration
is with CVBS input selected... What should we do here? reflect
defaults in the DT, or prioritize HDMI?
Thanks
j
>
> > +
> > + remote-endpoint = <&adv7612_out>;
> > + };
> > + };
> > + };
> > +};
> > --
> > 2.7.4
> >
>
> --
> Regards,
> Niklas S?derlund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180514/5816d47b/attachment-0001.sig>
^ permalink raw reply
* [RFC PATCH] driver core: make deferring probe forever optional
From: Alexander Graf @ 2018-05-14 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaYN-wKErERP_65T2NH6L-+8O_ugSgg7pXfkaLkn1A2KQ@mail.gmail.com>
On 05/14/2018 12:01 AM, Linus Walleij wrote:
> On Wed, May 9, 2018 at 11:44 AM, Alexander Graf <agraf@suse.de> wrote:
>> On 05/07/2018 08:31 PM, Bjorn Andersson wrote:
>>> Can you please name platform that has enough support for Alexander to
>>> care about backwards and forwards compatibility but lacks a pinctrl
>>> driver.
>> ZynqMP is one example that immediately comes to my mind. I'm sure there are
>> others too.
> Why isn't that using drivers/pinctrl/pinctrl-zynq.c?
>
> How is it so very different from (old) Zynq as it is already using
> the same GPIO driver?
That one is very simple: ZynqMP is usually an AMP system where Linux
doesn't have full knowledge of the overall system. IIUC they have a tiny
microblaze (PMU) that does the actual full system configuration for
peripherals that may interfere with each other. This architecture also
allows for safety critical code to run alongside a (less safe) Linux system.
I think we'll see architectures like this pop up more over time. TI
Sitara has similar issues. I know that Jailhouse ran into exactly that
problem before. I also know that during Linaro Connect Budapest even the
OP-TEE people realized the current model is bad, because Linux may
control pins/clocks/etc of devices that the secure world wants to use.
So I actually believe we will see more SoCs in the future that may even
start with Linux controllable pinctrl or no pinctrl driver but then will
move to firmware controlled drivers once it starts being necessary.
Alex
^ permalink raw reply
* [PATCH 6/8] serial: Add Tegra Combined UART driver
From: Mikko Perttunen @ 2018-05-14 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75VeJcqaiWUVr=oXEH5YurY3yCDdE1eeoWumo6jCa_4PWEQ@mail.gmail.com>
On 14.05.2018 01:20, Andy Shevchenko wrote:
> On Sun, May 13, 2018 at 9:04 PM, Mikko Perttunen <cyndis@kapsi.fi> wrote:
>> On 05/13/2018 05:16 PM, Andy Shevchenko wrote:
>>>
>>> On Tue, May 8, 2018 at 2:44 PM, Mikko Perttunen <mperttunen@nvidia.com>
>>> wrote:
>>>>
>>>> The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows
>>>> multiplexing multiple "virtual UARTs" into a single hardware serial
>>>> port. The TCU is the primary serial port on Tegra194 devices.
>>>>
>>>> Add a TCU driver utilizing the mailbox framework, as the used mailboxes
>>>> are part of Tegra HSP blocks that are already controlled by the Tegra
>>>> HSP mailbox driver.
>
>>>> +static void tegra_tcu_uart_set_mctrl(struct uart_port *port, unsigned
>>>> int mctrl)
>>>> +{
>>>
>>>
>>>> + (void)port;
>>>> + (void)mctrl;
>>>
>>>
>>> Huh?
>>
>>
>> The serial core calls these callbacks without checking if they are set. They
>> don't make sense for this driver so they are stubbed out.
>
> My question why do you need these ugly lines? I'm pretty sure no other
> driver with stubs using such style.
It's my personal style, being explicit about unused variables in this
way - I don't consider them ugly. But I can certainly remove them for
the next version.
>
>>>> +}
>
>>>> + if (written == 3) {
>>>> + value |= 3 << 24;
>>>> + value |= BIT(26);
>>>> + mbox_send_message(tcu->tx, &value);
>>>
>>>
>>>> + }
>>>
>>>
>>> (1)
>>>
>>>> + }
>>>> +
>>>> + if (written) {
>>>> + value |= written << 24;
>>>> + value |= BIT(26);
>>>> + mbox_send_message(tcu->tx, &value);
>>>> + }
>>>
>>>
>>> (2)
>>>
>>> These are code duplications.
>>
>>
>> Indeed - the length of the duplicated code is so short, and the instances
>> are so close to each other, that I don't find it necessary (or clearer) to
>> have an extra function.
>
> It makes sense. Consider to refactor other way w/o duplication then.
I'll see if I can refactor it out.
>
>>>> +static void tegra_tcu_uart_set_termios(struct uart_port *port,
>>>> + struct ktermios *new,
>>>> + struct ktermios *old)
>>>> +{
>>>> + (void)port;
>>>> + (void)new;
>>>> + (void)old;
>>>> +}
>>>
>>>
>>> Remove those unused stub contents.
>>
>>
>> Sure. I had these here so that we don't get unused parameter warnings, but I
>> can just as well remove the parameter names.
>
> What warnings? How did you get them? We have them disabled as far as I
> know even with W=1.
May be - it's just a habit, maybe from other projects where the warning
is enabled.
>
>>
>>>
>>>> + return uart_set_options(&tegra_tcu_uart_port, cons,
>>>> + 115200, 'n', 8, 'n');
>>>
>>>
>>> Can't it be one line?
>>
>>
>> It would be a total of 81 characters in length on one line, so no.
>
> So, yes. 1 character doesn't prevent us make the readability better.
> Please, put to one line.
>
Ok, I'll change this.
Thanks,
Mikko
^ permalink raw reply
* [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Maxime Ripard @ 2018-05-14 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66F_Ho2OZdrF3p6xe9mQ=zJZ_KjE9MnW1VmWs9jw65eEg@mail.gmail.com>
On Sun, May 13, 2018 at 09:59:22PM -0700, Chen-Yu Tsai wrote:
> On Sun, May 13, 2018 at 1:29 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Sun, May 13, 2018 at 01:11:08PM -0700, Chen-Yu Tsai wrote:
> >> On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> >> >> > Hi Chen-Yu
> >> >> >
> >> >> > Are these delays the MAC applies? Not the PHY. It would be good to
> >> >> > make it clear here these are MAC imposed delays.
> >> >>
> >> >> Yes these are applied on the MAC side. Being described in the device
> >> >> tree bindings for the MAC, I thought this was implied to be the case?
> >> >> Are there known exceptions?
> >> >
> >> > There is frequent confusion with this. Most of the time, the PHY does
> >> > the delay, not the MAC, based on the phy-mode. So the MAC doing it is
> >> > an exception in itself.
> >> >
> >> > Do you actually need these delays for the board you adding support
> >> > for? Does the PHY not support adding the needed delays? If you don't
> >> > need the delays, i would not even implement them.
> >>
> >> Yes this is already used on the Bananapi M3. This patch merely reformats
> >> the description and adds a note saying this only applies to RGMII mode.
> >
> > Yes, the current code is needed for the Bananapi M3. But you have
> > another patch which extends the code to support a smaller range. Do
> > you have a board which actually needs this? If not, i would not add
> > that new code.
>
> IIRC the delay on the PHY side is either 2ns or none. The delay on the
> MAC side here is an order smaller, likely fine tuning to cope with board
> design deficiencies.
>
> Currently no other board requires this, but this is already part of the
> binding. The new stuff limits the range for a specific SoC, simply because
> that is the range supported by the control register. Not implementing, i.e.
> supporting the whole range from the property, which might get truncated,
> doesn't make much sense to me.
With that driver we don't, but the previous design had the same
feature and it was used on more boards. It was simply initialized
statically in U-Boot, and not in Linux through the DT like it is done
here.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180514/e639ce99/attachment.sig>
^ permalink raw reply
* reply: [PATCH v3 1/2] PCI: kirin: Add MSI support
From: Andy Shevchenko @ 2018-05-14 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <99B4C6BADD9E3241B25E52B02BA737C54127E3BF@DGGEMA505-MBS.china.huawei.com>
On Mon, May 14, 2018 at 4:11 AM, songxiaowei <songxiaowei@hisilicon.com> wrote:
>> > + int ret;
>> > +
>> > + if (IS_ENABLED(CONFIG_PCI_MSI)) {
>>
>> > + pci->pp.msi_irq = platform_get_irq(pdev, 0);
>> > + if (pci->pp.msi_irq < 0) {
>> > + dev_err(&pdev->dev, "failed to get MSI IRQ
>> (%d)\n",
>> > + pci->pp.msi_irq);
>>
>> > + return -ENODEV;
>>
>> Why shadowing actual error code?
> [songxiaowei] Sorry, I can't get your point about this, would you explain it for me.
platform_get_irq() returns either correct IRQ number or negative error code.
In the code above you shadow the actual error (as returned by that
call) by -ENODEV. Any reason why?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] ARM: dts: socfpga: Fix NAND controller node compatible
From: Steffen Trumtrar @ 2018-05-14 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510125223.16056-1-marex@denx.de>
Marek Vasut <marex@denx.de> writes:
> The compatible string for the Denali NAND controller is
> incorrect,
> fix it by replacing it with one matching the DT bindings and the
> driver.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Fixes: d837a80d19 ("ARM: dts: socfpga: add nand controller
> nodes")
> Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> Cc: Dinh Nguyen <dinguyen@kernel.org>
> ---
> arch/arm/boot/dts/socfpga.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/socfpga.dtsi
> b/arch/arm/boot/dts/socfpga.dtsi
> index 7e24dc8e82d4..d697f5062624 100644
> --- a/arch/arm/boot/dts/socfpga.dtsi
> +++ b/arch/arm/boot/dts/socfpga.dtsi
> @@ -744,7 +744,7 @@
> nand0: nand at ff900000 {
> #address-cells = <0x1>;
> #size-cells = <0x1>;
> - compatible = "denali,denali-nand-dt";
> + compatible = "altr,socfpga-denali-nand";
> reg = <0xff900000 0x100000>,
> <0xffb80000 0x10000>;
> reg-names = "nand_data", "denali_reg";
Ack. As the binding was changed after d837a80d19 this is obviously
correct.
@Dinh: Maybe you also want to cleanup the socfpga_arria10.dtsi? It
has
both compatibles, but the "denali,denali-nand-dt" seems to be
obsolete.
Thanks,
Steffen
--
Pengutronix e.K. | Steffen Trumtrar
|
Industrial Linux Solutions |
http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone:
+49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax:
+49-5121-206917-5555 |
^ permalink raw reply
* Allwinner A64: Issue on external rtc clock to wifi chip
From: Jagan Teki @ 2018-05-14 7:07 UTC (permalink / raw)
To: linux-arm-kernel
Hi Maxime and All,
We are trying to bring-up AP6330 Wifi chip for A64 board. We noticed
to have an external rtc clock has driven from wifi chip.
So the devicetree is configured according to this as below.
/ {
wifi_pwrseq: wifi-pwrseq {
compatible = "mmc-pwrseq-simple";
clocks = <&rtc 1>;
clock-names = "ext_clock";
reset-gpios = <&r_pio 0 2 GPIO_ACTIVE_LOW>; /* PL2 */
post-power-on-delay-ms = <400>;
};
};
&rtc {
clock-output-names = "rtc-osc32k", "rtc-osc32k-out";
clocks = <&osc32k>;
#clock-cells = <1>;
};
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
vmmc-supply = <®_dcdc1>;
vqmmc-supply = <®_eldo1>;
mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
non-removable;
status = "okay";
brcmf: wifi at 1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
interrupt-parent = <&r_pio>;
interrupts = <0 3 IRQ_TYPE_LEVEL_LOW>; /* WL-WAKE-AP: PL3 */
interrupt-names = "host-wake";
};
};
And observed rtc-osc32k-out clock is never enabled[1] and the value of
LOSC_OUT_GATING is 0x0 which eventually not enabling
LOSC_OUT_GATING_EN
Pls. let us know if we miss anything here?
[1] https://paste.ubuntu.com/p/X2By4q8kD2/
Jagan.
--
Jagan Teki
Senior Linux Kernel Engineer | Amarula Solutions
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
^ permalink raw reply
* [GIT PULL] i.MX fixes for 4.17
From: Shawn Guo @ 2018-05-14 6:33 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fixes-4.17
for you to fetch changes up to 6d3299aef7df7225ecff653feedafb5d1646998b:
ARM: dts: imx51-zii-rdu1: fix touchscreen bindings (2018-05-11 13:50:27 +0800)
----------------------------------------------------------------
i.MX fixes for 4.17:
- Add missing 'fsl,sec-era' property for i.MX7S device tree CAAM node,
as the era information is used in various places inside CAAM driver.
- There are a few errors in imx51-zii-rdu1 device tree touchscreen
node. Fix them to get touchscreen actually work.
----------------------------------------------------------------
Fabio Estevam (1):
ARM: dts: imx7s: Pass the 'fsl,sec-era' property
Nikita Yushchenko (1):
ARM: dts: imx51-zii-rdu1: fix touchscreen bindings
arch/arm/boot/dts/imx51-zii-rdu1.dts | 6 +++---
arch/arm/boot/dts/imx7s.dtsi | 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH v2 04/13] soc: rockchip: power-domain: Fix wrong value when power up pd
From: Greg KH @ 2018-05-14 6:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268578-9361-1-git-send-email-zhangqing@rock-chips.com>
On Mon, May 14, 2018 at 11:29:38AM +0800, Elaine Zhang wrote:
> From: Finley Xiao <finley.xiao@rock-chips.com>
>
> Solve the pd could only ever turn off but never turn them on again,
> If the pd registers have the writemask bits.
>
> Fix up the code error for commit:
> commit 79bb17ce8edb3141339b5882e372d0ec7346217c
> Author: Elaine Zhang <zhangqing@rock-chips.com>
> Date: Fri Dec 23 11:47:52 2016 +0800
>
> soc: rockchip: power-domain: Support domain control in hiword-registers
>
> New Rockchips SoCs may have their power-domain control in registers
> using a writemask-based access scheme (upper 16bit being the write
> mask). So add a DOMAIN_M type and handle this case accordingly.
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>
> Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
> ---
> drivers/soc/rockchip/pm_domains.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
^ permalink raw reply
* [PATCH V3] ARM: dts: da850-evm: Enable LCD and Backlight
From: Sekhar Nori @ 2018-05-14 5:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513232033.22571-1-aford173@gmail.com>
Hi Adam,
On Monday 14 May 2018 04:50 AM, Adam Ford wrote:
> When using the board files the LCD works, but not with the DT.
> This adds enables the original da850-evm to work with the same
> LCD in device tree mode.
>
> The EVM has a gpio for the regulator and a gpio enable. The LCD and
> the vpif display pins are mutually exclusive, so if using the LCD,
> do not load the vpif driver.
Its not sufficient just note this in patch description.
a) Disable (status = "disabled") the VPIF node which clashes for pins
with LCD.
b) Add a comment on top of the status = "disabled" giving information on
how user can enable it (disable lcdc node and then change to status =
"okay").
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> ---
> V3: Fix errant GPIO, label GPIO pins, and rename the regulator to be more explict to
> backlight which better matches the schematic. Updated the description to explain
> that it cannot be used at the same time as the vpif driver.
>
> V2: Add regulator and GPIO enable pins. Remove PWM backlight and replace with GPIO
>
> diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
> index 2e817da37fdb..3f1c8be07efe 100644
> --- a/arch/arm/boot/dts/da850-evm.dts
> +++ b/arch/arm/boot/dts/da850-evm.dts
> @@ -27,6 +27,50 @@
> spi0 = &spi1;
> };
>
> + backlight {
> + compatible = "gpio-backlight";
> + enable-gpios = <&gpio 7 GPIO_ACTIVE_HIGH>; /* GP0[7] */
The gpio-backlight binding does not describe a property called
enable-gpios. It should just be gpios.
a) Are you using gpio-backlight because you are not able to get the PWM
to work?
b) What is GP0[7] connected to in the schematic you have? In the
schematic I have I see LCD_PWM0 is connected to
SPI1_SCS[0]/EPWM1B/GP2[14]/TM64P3_IN12.
c) The /* GP0[7] */ comment is not really useful on its own as it can be
computed. What I wanted to see is the schematic symbol like "LCD_PWM0".
Same for other places like this below.
> @@ -35,6 +79,16 @@
> regulator-boot-on;
> };
>
> + backlight_reg: backlight-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "lcd_backlight_pwr";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio 47 GPIO_ACTIVE_HIGH>; /* GP2[15] */
> + regulator-always-on;
Why should this regulator never be disabled?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Icenowy Zheng @ 2018-05-14 5:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66F_Ho2OZdrF3p6xe9mQ=zJZ_KjE9MnW1VmWs9jw65eEg@mail.gmail.com>
? 2018?5?14? GMT+08:00 ??12:59:22, Chen-Yu Tsai <wens@csie.org> ??:
>On Sun, May 13, 2018 at 1:29 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> On Sun, May 13, 2018 at 01:11:08PM -0700, Chen-Yu Tsai wrote:
>>> On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>>> >> > Hi Chen-Yu
>>> >> >
>>> >> > Are these delays the MAC applies? Not the PHY. It would be good
>to
>>> >> > make it clear here these are MAC imposed delays.
>>> >>
>>> >> Yes these are applied on the MAC side. Being described in the
>device
>>> >> tree bindings for the MAC, I thought this was implied to be the
>case?
>>> >> Are there known exceptions?
>>> >
>>> > There is frequent confusion with this. Most of the time, the PHY
>does
>>> > the delay, not the MAC, based on the phy-mode. So the MAC doing it
>is
>>> > an exception in itself.
>>> >
>>> > Do you actually need these delays for the board you adding support
>>> > for? Does the PHY not support adding the needed delays? If you
>don't
>>> > need the delays, i would not even implement them.
>>>
>>> Yes this is already used on the Bananapi M3. This patch merely
>reformats
>>> the description and adds a note saying this only applies to RGMII
>mode.
>>
>> Yes, the current code is needed for the Bananapi M3. But you have
>> another patch which extends the code to support a smaller range. Do
>> you have a board which actually needs this? If not, i would not add
>> that new code.
>
>IIRC the delay on the PHY side is either 2ns or none. The delay on the
>MAC side here is an order smaller, likely fine tuning to cope with
>board
>design deficiencies.
And the weird thing is that the delay fails to work on some batches
of RTL8211E, notably many cases are shown on Pine A64+
board.
P.S. The delay is intended to be set via wires on PCB, other than
by software. Although Realtek provided some magic numbers
to Pine64, in order to fix the network problem due to PHY
delay failure.
>
>Currently no other board requires this, but this is already part of the
>binding. The new stuff limits the range for a specific SoC, simply
>because
>that is the range supported by the control register. Not implementing,
>i.e.
>supporting the whole range from the property, which might get
>truncated,
>doesn't make much sense to me.
>
>Regards
>ChenYu
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/2] arm64: Clear the stack
From: Mark Rutland @ 2018-05-14 5:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f180b312-d1cf-3992-4e89-9632c1674cd6@linux.com>
On Sun, May 13, 2018 at 11:40:07AM +0300, Alexander Popov wrote:
> It seems that previously I was very "lucky" to accidentally have those MIN_STACK_LEFT,
> call trace depth and oops=panic together to experience a hang on stack overflow
> during BUG().
>
>
> When I run my test in a loop _without_ VMAP_STACK, I manage to corrupt the neighbour
> processes with BUG() handling overstepping the stack boundary. It's a pity, but
> I have an idea.
I think that in the absence of VMAP_STACK, there will always be cases where we
*could* corrupt a neighbouring stack, but I agree that trying to minimize that
possibility would be good.
> In kernel/sched/core.c we already have:
>
> #ifdef CONFIG_SCHED_STACK_END_CHECK
> if (task_stack_end_corrupted(prev))
> panic("corrupted stack end detected inside scheduler\n");
> #endif
>
> So what would you think if I do the following in check_alloca():
>
> if (size >= stack_left) {
> #if !defined(CONFIG_VMAP_STACK) && defined(CONFIG_SCHED_STACK_END_CHECK)
> panic("alloca over the kernel stack boundary\n");
> #else
> BUG();
> #endif
Given this is already out-of-line, how about we always use panic(), regardless
of VMAP_STACK and SCHED_STACK_END_CHECK? i.e. just
if (unlikely(size >= stack_left))
panic("alloca over the kernel stack boundary");
If we have VMAP_STACK selected, and overflow during the panic, it's the same as
if we overflowed during the BUG(). It's likely that panic() will use less stack
space than BUG(), and the compiler can put the call in a slow path that
shouldn't affect most calls, so in all cases it's likely preferable.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v6 3/6] kernel/reboot.c: export pm_power_off_prepare
From: Oleksij Rempel @ 2018-05-14 5:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a431b0e1-f4f4-1439-f0bf-736018c6ab0c@pengutronix.de>
On 14.05.2018 06:33, Oleksij Rempel wrote:
>
>
> On 12.05.2018 13:13, Rafael J. Wysocki wrote:
>> On Friday, May 4, 2018 8:50:52 PM CEST Oleksij Rempel wrote:
>>> Hallo Andrew,
>>> I need your ACK or NACK for this patch.
>>>
>>> This function is used to configure external PMIC to interpret
>>> signal which will be triggered by pm_power_off as power off.
>>> Since same signal can be used for stand by, I linked PMIC configuration
>>> with pm_power_off_prepare to avoid possible conflicts.
>>>
>>> On Mon, Mar 05, 2018 at 11:25:20AM +0100, Oleksij Rempel wrote:
>>>> Export pm_power_off_prepare. It is needed to implement power off on
>>>> Freescale/NXP iMX6 based boards with external power management
>>>> integrated circuit (PMIC).
>>>>
>>>> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>>>> ---
>>>> kernel/reboot.c | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/kernel/reboot.c b/kernel/reboot.c
>>>> index e4ced883d8de..350be6baa60d 100644
>>>> --- a/kernel/reboot.c
>>>> +++ b/kernel/reboot.c
>>>> @@ -49,6 +49,7 @@ int reboot_force;
>>>> */
>>>>
>>>> void (*pm_power_off_prepare)(void);
>>>> +EXPORT_SYMBOL(pm_power_off_prepare);
>>
>> Why not EXPORT_SYMBOL_GPL() ?
>
> No special reason. Fixed.
> Any other comments?
>
Or with other words, will it be enough to get your Signed-of-by for this
patch?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180514/3f63f47f/attachment-0001.sig>
^ permalink raw reply
* [PATCH RESEND net-next v2 1/8] dt-bindings: net: dwmac-sun8i: Clean up clock delay chain descriptions
From: Chen-Yu Tsai @ 2018-05-14 4:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180513202938.GH12738@lunn.ch>
On Sun, May 13, 2018 at 1:29 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> On Sun, May 13, 2018 at 01:11:08PM -0700, Chen-Yu Tsai wrote:
>> On Sun, May 13, 2018 at 1:05 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> >> > Hi Chen-Yu
>> >> >
>> >> > Are these delays the MAC applies? Not the PHY. It would be good to
>> >> > make it clear here these are MAC imposed delays.
>> >>
>> >> Yes these are applied on the MAC side. Being described in the device
>> >> tree bindings for the MAC, I thought this was implied to be the case?
>> >> Are there known exceptions?
>> >
>> > There is frequent confusion with this. Most of the time, the PHY does
>> > the delay, not the MAC, based on the phy-mode. So the MAC doing it is
>> > an exception in itself.
>> >
>> > Do you actually need these delays for the board you adding support
>> > for? Does the PHY not support adding the needed delays? If you don't
>> > need the delays, i would not even implement them.
>>
>> Yes this is already used on the Bananapi M3. This patch merely reformats
>> the description and adds a note saying this only applies to RGMII mode.
>
> Yes, the current code is needed for the Bananapi M3. But you have
> another patch which extends the code to support a smaller range. Do
> you have a board which actually needs this? If not, i would not add
> that new code.
IIRC the delay on the PHY side is either 2ns or none. The delay on the
MAC side here is an order smaller, likely fine tuning to cope with board
design deficiencies.
Currently no other board requires this, but this is already part of the
binding. The new stuff limits the range for a specific SoC, simply because
that is the range supported by the control register. Not implementing, i.e.
supporting the whole range from the property, which might get truncated,
doesn't make much sense to me.
Regards
ChenYu
^ permalink raw reply
* [PATCH v6 3/6] kernel/reboot.c: export pm_power_off_prepare
From: Oleksij Rempel @ 2018-05-14 4:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1937901.oyadCYFYNo@aspire.rjw.lan>
On 12.05.2018 13:13, Rafael J. Wysocki wrote:
> On Friday, May 4, 2018 8:50:52 PM CEST Oleksij Rempel wrote:
>> Hallo Andrew,
>> I need your ACK or NACK for this patch.
>>
>> This function is used to configure external PMIC to interpret
>> signal which will be triggered by pm_power_off as power off.
>> Since same signal can be used for stand by, I linked PMIC configuration
>> with pm_power_off_prepare to avoid possible conflicts.
>>
>> On Mon, Mar 05, 2018 at 11:25:20AM +0100, Oleksij Rempel wrote:
>>> Export pm_power_off_prepare. It is needed to implement power off on
>>> Freescale/NXP iMX6 based boards with external power management
>>> integrated circuit (PMIC).
>>>
>>> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
>>> ---
>>> kernel/reboot.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/kernel/reboot.c b/kernel/reboot.c
>>> index e4ced883d8de..350be6baa60d 100644
>>> --- a/kernel/reboot.c
>>> +++ b/kernel/reboot.c
>>> @@ -49,6 +49,7 @@ int reboot_force;
>>> */
>>>
>>> void (*pm_power_off_prepare)(void);
>>> +EXPORT_SYMBOL(pm_power_off_prepare);
>
> Why not EXPORT_SYMBOL_GPL() ?
No special reason. Fixed.
Any other comments?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180514/8e85cd06/attachment.sig>
^ permalink raw reply
* [PATCH v2 13/13] soc: rockchip: power-domain: add power domain support for px30
From: Elaine Zhang @ 2018-05-14 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
From: Finley Xiao <finley.xiao@rock-chips.com>
This driver is modified to support PX30 SoC.
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
drivers/soc/rockchip/pm_domains.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/soc/rockchip/pm_domains.c b/drivers/soc/rockchip/pm_domains.c
index 90dcd5e21ae6..d0c5615132e3 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -18,6 +18,7 @@
#include <linux/clk.h>
#include <linux/regmap.h>
#include <linux/mfd/syscon.h>
+#include <dt-bindings/power/px30-power.h>
#include <dt-bindings/power/rk3036-power.h>
#include <dt-bindings/power/rk3128-power.h>
#include <dt-bindings/power/rk3228-power.h>
@@ -114,6 +115,9 @@ struct rockchip_pmu {
.active_wakeup = wakeup, \
}
+#define DOMAIN_PX30(pwr, status, req, wakeup) \
+ DOMAIN_M(pwr, status, req, (req) + 16, req, wakeup)
+
#define DOMAIN_RK3288(pwr, status, req, wakeup) \
DOMAIN(pwr, status, req, req, (req) + 16, wakeup)
@@ -712,6 +716,17 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
return error;
}
+static const struct rockchip_domain_info px30_pm_domains[] = {
+ [PX30_PD_USB] = DOMAIN_PX30(5, 5, 10, false),
+ [PX30_PD_SDCARD] = DOMAIN_PX30(8, 8, 9, false),
+ [PX30_PD_GMAC] = DOMAIN_PX30(10, 10, 6, false),
+ [PX30_PD_MMC_NAND] = DOMAIN_PX30(11, 11, 5, false),
+ [PX30_PD_VPU] = DOMAIN_PX30(12, 12, 14, false),
+ [PX30_PD_VO] = DOMAIN_PX30(13, 13, 7, false),
+ [PX30_PD_VI] = DOMAIN_PX30(14, 14, 8, false),
+ [PX30_PD_GPU] = DOMAIN_PX30(15, 15, 2, false),
+};
+
static const struct rockchip_domain_info rk3036_pm_domains[] = {
[RK3036_PD_MSCH] = DOMAIN_RK3036(14, 23, 30, true),
[RK3036_PD_CORE] = DOMAIN_RK3036(13, 17, 24, false),
@@ -811,6 +826,17 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
[RK3399_PD_SDIOAUDIO] = DOMAIN_RK3399(31, 31, 29, true),
};
+static const struct rockchip_pmu_info px30_pmu = {
+ .pwr_offset = 0x18,
+ .status_offset = 0x20,
+ .req_offset = 0x64,
+ .idle_offset = 0x6c,
+ .ack_offset = 0x6c,
+
+ .num_domains = ARRAY_SIZE(px30_pm_domains),
+ .domain_info = px30_pm_domains,
+};
+
static const struct rockchip_pmu_info rk3036_pmu = {
.req_offset = 0x148,
.idle_offset = 0x14c,
@@ -915,6 +941,10 @@ static int rockchip_pm_domain_probe(struct platform_device *pdev)
static const struct of_device_id rockchip_pm_domain_dt_match[] = {
{
+ .compatible = "rockchip,px30-power-controller",
+ .data = (void *)&px30_pmu,
+ },
+ {
.compatible = "rockchip,rk3036-power-controller",
.data = (void *)&rk3036_pmu,
},
--
1.9.1
^ permalink raw reply related
* [PATCH v2 12/13] dt-bindings: add binding for px30 power domains
From: Elaine Zhang @ 2018-05-14 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526268455-9133-1-git-send-email-zhangqing@rock-chips.com>
From: Finley Xiao <finley.xiao@rock-chips.com>
Add binding documentation for the power domains
found on Rockchip PX30 SoCs.
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
---
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
index affe36dcfa17..5d49d0a2ff29 100644
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -5,6 +5,7 @@ powered up/down by software based on different application scenes to save power.
Required properties for power domain controller:
- compatible: Should be one of the following.
+ "rockchip,px30-power-controller" - for PX30 SoCs.
"rockchip,rk3036-power-controller" - for RK3036 SoCs.
"rockchip,rk3128-power-controller" - for RK3128 SoCs.
"rockchip,rk3228-power-controller" - for RK3228 SoCs.
@@ -20,6 +21,7 @@ Required properties for power domain controller:
Required properties for power domain sub nodes:
- reg: index of the power domain, should use macros in:
+ "include/dt-bindings/power/px30-power.h" - for PX30 type power domain.
"include/dt-bindings/power/rk3036-power.h" - for RK3036 type power domain.
"include/dt-bindings/power/rk3128-power.h" - for RK3128 type power domain.
"include/dt-bindings/power/rk3228-power.h" - for RK3228 type power domain.
@@ -99,6 +101,7 @@ Node of a device using power domains must have a power-domains property,
containing a phandle to the power device node and an index specifying which
power domain to use.
The index should use macros in:
+ "include/dt-bindings/power/px30-power.h" - for px30 type power domain.
"include/dt-bindings/power/rk3036-power.h" - for rk3036 type power domain.
"include/dt-bindings/power/rk3128-power.h" - for rk3128 type power domain.
"include/dt-bindings/power/rk3128-power.h" - for rk3228 type power domain.
--
1.9.1
^ 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