* [PATCH v4 2/4] Documentation: bindings: add phy_config for Rockchip USB Type-C PHY
From: Lin Huang @ 2018-05-15 3:22 UTC (permalink / raw)
To: seanpaul, airlied, zyw
Cc: dianders, briannorris, linux-rockchip, heiko, daniel.vetter,
jani.nikula, dri-devel, linux-arm-kernel, linux-kernel, eballetbo,
robh+dt, devicetree, Lin Huang
In-Reply-To: <1526354560-23135-1-git-send-email-hl@rock-chips.com>
If want to do training outside DP Firmware, need phy voltage swing
and pre_emphasis value.
Signed-off-by: Lin Huang <hl@rock-chips.com>
---
Changes in v2:
- None
Changes in v3:
- modify property description and add this property to Example
Change in v4:
- None
.../devicetree/bindings/phy/phy-rockchip-typec.txt | 29 +++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
index 960da7f..af298f2 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-typec.txt
@@ -17,7 +17,8 @@ Required properties:
Optional properties:
- extcon : extcon specifier for the Power Delivery
-
+ - rockchip,phy_config : A list of voltage swing(mv) and pre-emphasis
+ (dB) pairs.
Required nodes : a sub-node is required for each port the phy provides.
The sub-node name is used to identify dp or usb3 port,
and shall be the following entries:
@@ -50,6 +51,19 @@ Example:
<&cru SRST_P_UPHY0_TCPHY>;
reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+ rockchip,phy_config =<0x2a 0x00
+ 0x1f 0x15
+ 0x14 0x22
+ 0x02 0x2b
+ 0x21 0x00
+ 0x12 0x15
+ 0x02 0x22
+ 0 0
+ 0x15 0x00
+ 0x00 0x15
+ 0 0
+ 0 0>;
+
tcphy0_dp: dp-port {
#phy-cells = <0>;
};
@@ -74,6 +88,19 @@ Example:
<&cru SRST_P_UPHY1_TCPHY>;
reset-names = "uphy", "uphy-pipe", "uphy-tcphy";
+ rockchip,phy_config =<0x2a 0x00
+ 0x1f 0x15
+ 0x14 0x22
+ 0x02 0x2b
+ 0x21 0x00
+ 0x12 0x15
+ 0x02 0x22
+ 0 0
+ 0x15 0x00
+ 0x00 0x15
+ 0 0
+ 0 0>;
+
tcphy1_dp: dp-port {
#phy-cells = <0>;
};
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/4] drm/rockchip: add transfer function for cdn-dp
From: Lin Huang @ 2018-05-15 3:22 UTC (permalink / raw)
To: seanpaul, airlied, zyw
Cc: dianders, briannorris, linux-rockchip, heiko, daniel.vetter,
jani.nikula, dri-devel, linux-arm-kernel, linux-kernel, eballetbo,
robh+dt, devicetree, Lin Huang
From: Chris Zhong <zyw@rock-chips.com>
We may support training outside firmware, so we need support
dpcd read/write to get the message or do some setting with
display.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Lin Huang <hl@rock-chips.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Enric Balletbo <enric.balletbo@collabora.com>
---
Changes in v2:
- update patch following Enric suggest
Changes in v3:
- None
Changes in v4:
- None
drivers/gpu/drm/rockchip/cdn-dp-core.c | 55 +++++++++++++++++++++++----
drivers/gpu/drm/rockchip/cdn-dp-core.h | 1 +
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 69 ++++++++++++++++++++++++++++++----
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 14 ++++++-
4 files changed, 122 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index c6fbdcd..cce64c1 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -176,8 +176,8 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp, u8 *sink_count)
u8 value;
*sink_count = 0;
- ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, &value, 1);
- if (ret)
+ ret = drm_dp_dpcd_read(&dp->aux, DP_SINK_COUNT, &value, 1);
+ if (ret < 0)
return ret;
*sink_count = DP_GET_SINK_COUNT(value);
@@ -374,9 +374,9 @@ static int cdn_dp_get_sink_capability(struct cdn_dp_device *dp)
if (!cdn_dp_check_sink_connection(dp))
return -ENODEV;
- ret = cdn_dp_dpcd_read(dp, DP_DPCD_REV, dp->dpcd,
- DP_RECEIVER_CAP_SIZE);
- if (ret) {
+ ret = drm_dp_dpcd_read(&dp->aux, DP_DPCD_REV, dp->dpcd,
+ sizeof(dp->dpcd));
+ if (ret < 0) {
DRM_DEV_ERROR(dp->dev, "Failed to get caps %d\n", ret);
return ret;
}
@@ -582,8 +582,8 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device *dp)
if (!port || !dp->link.rate || !dp->link.num_lanes)
return false;
- if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
- DP_LINK_STATUS_SIZE)) {
+ if (drm_dp_dpcd_read_link_status(&dp->aux, link_status) !=
+ DP_LINK_STATUS_SIZE) {
DRM_ERROR("Failed to get link status\n");
return false;
}
@@ -1012,6 +1012,40 @@ static int cdn_dp_pd_event(struct notifier_block *nb,
return NOTIFY_DONE;
}
+static ssize_t cdn_dp_aux_transfer(struct drm_dp_aux *aux,
+ struct drm_dp_aux_msg *msg)
+{
+ struct cdn_dp_device *dp = container_of(aux, struct cdn_dp_device, aux);
+ int ret;
+ u8 status;
+
+ switch (msg->request & ~DP_AUX_I2C_MOT) {
+ case DP_AUX_NATIVE_WRITE:
+ case DP_AUX_I2C_WRITE:
+ case DP_AUX_I2C_WRITE_STATUS_UPDATE:
+ ret = cdn_dp_dpcd_write(dp, msg->address, msg->buffer,
+ msg->size);
+ break;
+ case DP_AUX_NATIVE_READ:
+ case DP_AUX_I2C_READ:
+ ret = cdn_dp_dpcd_read(dp, msg->address, msg->buffer,
+ msg->size);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ status = cdn_dp_get_aux_status(dp);
+ if (status == AUX_STATUS_ACK)
+ msg->reply = DP_AUX_NATIVE_REPLY_ACK;
+ else if (status == AUX_STATUS_NACK)
+ msg->reply = DP_AUX_NATIVE_REPLY_NACK;
+ else if (status == AUX_STATUS_DEFER)
+ msg->reply = DP_AUX_NATIVE_REPLY_DEFER;
+
+ return ret;
+}
+
static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
{
struct cdn_dp_device *dp = dev_get_drvdata(dev);
@@ -1030,6 +1064,13 @@ static int cdn_dp_bind(struct device *dev, struct device *master, void *data)
dp->active = false;
dp->active_port = -1;
dp->fw_loaded = false;
+ dp->aux.name = "DP-AUX";
+ dp->aux.transfer = cdn_dp_aux_transfer;
+ dp->aux.dev = dev;
+
+ ret = drm_dp_aux_register(&dp->aux);
+ if (ret)
+ return ret;
INIT_WORK(&dp->event_work, cdn_dp_pd_event_work);
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h b/drivers/gpu/drm/rockchip/cdn-dp-core.h
index f57e296..46159b2 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
@@ -78,6 +78,7 @@ struct cdn_dp_device {
struct platform_device *audio_pdev;
struct work_struct event_work;
struct edid *edid;
+ struct drm_dp_aux aux;
struct mutex lock;
bool connected;
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index eb3042c..979355d 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -221,7 +221,12 @@ static int cdn_dp_reg_write_bit(struct cdn_dp_device *dp, u16 addr,
sizeof(field), field);
}
-int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
+/*
+ * Returns the number of bytes transferred on success, or a negative
+ * error code on failure. -ETIMEDOUT is returned if mailbox message was
+ * not send successfully;
+ */
+ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
{
u8 msg[5], reg[5];
int ret;
@@ -247,24 +252,41 @@ int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
goto err_dpcd_read;
ret = cdn_dp_mailbox_read_receive(dp, data, len);
+ if (!ret)
+ return len;
err_dpcd_read:
+ DRM_DEV_ERROR(dp->dev, "dpcd read failed: %d\n", ret);
return ret;
}
-int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
+#define CDN_AUX_HEADER_SIZE 5
+#define CDN_AUX_MSG_SIZE 20
+/*
+ * Returns the number of bytes transferred on success, or a negative error
+ * code on failure. -ETIMEDOUT is returned if mailbox message was not send
+ * success; -EINVAL is returned if get the wrong data size after message
+ * is sent
+ */
+ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len)
{
- u8 msg[6], reg[5];
+ u8 msg[CDN_AUX_MSG_SIZE + CDN_AUX_HEADER_SIZE];
+ u8 reg[CDN_AUX_HEADER_SIZE];
int ret;
- msg[0] = 0;
- msg[1] = 1;
+ if (WARN_ON(len > CDN_AUX_MSG_SIZE) || WARN_ON(len <= 0))
+ return -EINVAL;
+
+ msg[0] = (len >> 8) & 0xff;
+ msg[1] = len & 0xff;
msg[2] = (addr >> 16) & 0xff;
msg[3] = (addr >> 8) & 0xff;
msg[4] = addr & 0xff;
- msg[5] = value;
+
+ memcpy(msg + CDN_AUX_HEADER_SIZE, data, len);
+
ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_DP_TX, DPTX_WRITE_DPCD,
- sizeof(msg), msg);
+ CDN_AUX_HEADER_SIZE + len, msg);
if (ret)
goto err_dpcd_write;
@@ -277,8 +299,12 @@ int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
if (ret)
goto err_dpcd_write;
- if (addr != (reg[2] << 16 | reg[3] << 8 | reg[4]))
+ if ((len != (reg[0] << 8 | reg[1])) ||
+ (addr != (reg[2] << 16 | reg[3] << 8 | reg[4]))) {
ret = -EINVAL;
+ } else {
+ return len;
+ }
err_dpcd_write:
if (ret)
@@ -286,6 +312,33 @@ int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value)
return ret;
}
+int cdn_dp_get_aux_status(struct cdn_dp_device *dp)
+{
+ u8 status;
+ int ret;
+
+ ret = cdn_dp_mailbox_send(dp, MB_MODULE_ID_DP_TX,
+ DPTX_GET_LAST_AUX_STAUS, 0, NULL);
+ if (ret)
+ goto err_get_hpd;
+
+ ret = cdn_dp_mailbox_validate_receive(dp, MB_MODULE_ID_DP_TX,
+ DPTX_GET_LAST_AUX_STAUS,
+ sizeof(status));
+ if (ret)
+ goto err_get_hpd;
+
+ ret = cdn_dp_mailbox_read_receive(dp, &status, sizeof(status));
+ if (ret)
+ goto err_get_hpd;
+
+ return status;
+
+err_get_hpd:
+ DRM_DEV_ERROR(dp->dev, "get aux status failed: %d\n", ret);
+ return ret;
+}
+
int cdn_dp_load_firmware(struct cdn_dp_device *dp, const u32 *i_mem,
u32 i_size, const u32 *d_mem, u32 d_size)
{
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.h b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
index c4bbb4a83..6580b11 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.h
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
@@ -328,6 +328,13 @@
#define GENERAL_BUS_SETTINGS 0x03
#define GENERAL_TEST_ACCESS 0x04
+/* AUX status*/
+#define AUX_STATUS_ACK 0
+#define AUX_STATUS_NACK 1
+#define AUX_STATUS_DEFER 2
+#define AUX_STATUS_SINK_ERROR 3
+#define AUX_STATUS_BUS_ERROR 4
+
#define DPTX_SET_POWER_MNG 0x00
#define DPTX_SET_HOST_CAPABILITIES 0x01
#define DPTX_GET_EDID 0x02
@@ -469,8 +476,11 @@ int cdn_dp_set_host_cap(struct cdn_dp_device *dp, u8 lanes, bool flip);
int cdn_dp_event_config(struct cdn_dp_device *dp);
u32 cdn_dp_get_event(struct cdn_dp_device *dp);
int cdn_dp_get_hpd_status(struct cdn_dp_device *dp);
-int cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr, u8 value);
-int cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr, u8 *data, u16 len);
+ssize_t cdn_dp_dpcd_write(struct cdn_dp_device *dp, u32 addr,
+ u8 *data, u16 len);
+ssize_t cdn_dp_dpcd_read(struct cdn_dp_device *dp, u32 addr,
+ u8 *data, u16 len);
+int cdn_dp_get_aux_status(struct cdn_dp_device *dp);
int cdn_dp_get_edid_block(void *dp, u8 *edid,
unsigned int block, size_t length);
int cdn_dp_train_link(struct cdn_dp_device *dp);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 5/5] hisi: Consolidate the Kconfigs for the CLOCK_STUB and the MAILBOX
From: Leo Yan @ 2018-05-15 2:53 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Jassi Brar, Arnd Bergmann, Olof Johansson,
Daniel Lezcano, linux-arm-kernel, devicetree, linux-kernel,
linux-clk
Cc: Leo Yan
In-Reply-To: <1526352795-6991-1-git-send-email-leo.yan@linaro.org>
From: Daniel Lezcano <daniel.lezcano@linaro.org>
The current defconfig is inconsistent as it selects the mailbox and
the clock for the hi6220 and the hi3660 without having their Kconfigs
making sure the dependencies are correct. It ends up when selecting
different versions for the kernel (for example when git bisecting)
those options disappear and they don't get back, leading to unexpected
behaviors. In our case, the cpufreq driver does no longer work because
the clock fails to initialize due to the clock stub and the mailbox
missing.
In order to have the dependencies correctly set when defaulting, let's
do the same as commit 3a49afb84ca074e ("clk: enable hi655x common clk
automatically") where we select automatically the driver when the
parent driver is selected. With sensible defaults in place, we can leave
other choices for EXPERT.
Acked-by: Stephen Boyd <sboyd@kernel.org>
Acked-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
arch/arm64/configs/defconfig | 1 -
drivers/clk/hisilicon/Kconfig | 13 ++++++++-----
drivers/mailbox/Kconfig | 12 ++++++++----
3 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ecf6137..1d9d8b9 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -549,7 +549,6 @@ CONFIG_HWSPINLOCK_QCOM=y
CONFIG_ARM_MHU=y
CONFIG_PLATFORM_MHU=y
CONFIG_BCM2835_MBOX=y
-CONFIG_HI6220_MBOX=y
CONFIG_QCOM_APCS_IPC=y
CONFIG_ROCKCHIP_IOMMU=y
CONFIG_TEGRA_IOMMU_SMMU=y
diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
index 1bd4355..becdb1d 100644
--- a/drivers/clk/hisilicon/Kconfig
+++ b/drivers/clk/hisilicon/Kconfig
@@ -44,14 +44,17 @@ config RESET_HISI
Build reset controller driver for HiSilicon device chipsets.
config STUB_CLK_HI6220
- bool "Hi6220 Stub Clock Driver"
- depends on COMMON_CLK_HI6220 && MAILBOX
- default ARCH_HISI
+ bool "Hi6220 Stub Clock Driver" if EXPERT
+ depends on (COMMON_CLK_HI6220 || COMPILE_TEST)
+ depends on MAILBOX
+ default COMMON_CLK_HI6220
help
Build the Hisilicon Hi6220 stub clock driver.
config STUB_CLK_HI3660
- bool "Hi3660 Stub Clock Driver"
- depends on COMMON_CLK_HI3660 && MAILBOX
+ bool "Hi3660 Stub Clock Driver" if EXPERT
+ depends on (COMMON_CLK_HI3660 || COMPILE_TEST)
+ depends on MAILBOX
+ default COMMON_CLK_HI3660
help
Build the Hisilicon Hi3660 stub clock driver.
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index a2bb274..567cd02 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -109,16 +109,20 @@ config TI_MESSAGE_MANAGER
platform has support for the hardware block.
config HI3660_MBOX
- tristate "Hi3660 Mailbox"
- depends on ARCH_HISI && OF
+ tristate "Hi3660 Mailbox" if EXPERT
+ depends on (ARCH_HISI || COMPILE_TEST)
+ depends on OF
+ default ARCH_HISI
help
An implementation of the hi3660 mailbox. It is used to send message
between application processors and other processors/MCU/DSP. Select
Y here if you want to use Hi3660 mailbox controller.
config HI6220_MBOX
- tristate "Hi6220 Mailbox"
- depends on ARCH_HISI
+ tristate "Hi6220 Mailbox" if EXPERT
+ depends on (ARCH_HISI || COMPILE_TEST)
+ depends on OF
+ default ARCH_HISI
help
An implementation of the hi6220 mailbox. It is used to send message
between application processors and MCU. Say Y here if you want to
--
1.9.1
^ permalink raw reply related
* [PATCH v2 4/5] arm64: dts: hi3660: Add thermal cooling management
From: Leo Yan @ 2018-05-15 2:53 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Jassi Brar, Arnd Bergmann, Olof Johansson,
Daniel Lezcano, linux-arm-kernel, devicetree, linux-kernel,
linux-clk
Cc: Tao Wang, Leo Yan
In-Reply-To: <1526352795-6991-1-git-send-email-leo.yan@linaro.org>
From: Tao Wang <jean.wangtao@linaro.org>
Add nodes and properties for thermal cooling management support.
Signed-off-by: Tao Wang <jean.wangtao@linaro.org>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 44 +++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index a39da09..e20edd9 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/hi3660-clock.h>
+#include <dt-bindings/thermal/thermal.h>
/ {
compatible = "hisilicon,hi3660";
@@ -64,6 +65,8 @@
capacity-dmips-mhz = <592>;
clocks = <&stub_clock HI3660_CLK_STUB_CLUSTER0>;
operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
+ dynamic-power-coefficient = <110>;
};
cpu1: cpu@1 {
@@ -112,6 +115,8 @@
capacity-dmips-mhz = <1024>;
clocks = <&stub_clock HI3660_CLK_STUB_CLUSTER1>;
operating-points-v2 = <&cluster1_opp>;
+ #cooling-cells = <2>;
+ dynamic-power-coefficient = <550>;
};
cpu5: cpu@101 {
@@ -1073,5 +1078,44 @@
interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>;
#thermal-sensor-cells = <1>;
};
+
+ thermal-zones {
+
+ cls0: cls0 {
+ polling-delay = <1000>;
+ polling-delay-passive = <100>;
+ sustainable-power = <4500>;
+
+ /* sensor ID */
+ thermal-sensors = <&tsensor 1>;
+
+ trips {
+ threshold: trip-point@0 {
+ temperature = <65000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+
+ target: trip-point@1 {
+ temperature = <75000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&target>;
+ contribution = <1024>;
+ cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ map1 {
+ trip = <&target>;
+ contribution = <512>;
+ cooling-device = <&cpu4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/5] arm64: dts: hi3660: Add CPU frequency scaling support
From: Leo Yan @ 2018-05-15 2:53 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Jassi Brar, Arnd Bergmann, Olof Johansson,
Daniel Lezcano, linux-arm-kernel, devicetree, linux-kernel,
linux-clk
Cc: Leo Yan
In-Reply-To: <1526352795-6991-1-git-send-email-leo.yan@linaro.org>
Add two CPU OPP tables, one table is corresponding to one cluster,
which allow CPU frequency scaling on hi3660 platforms.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 86 +++++++++++++++++++++++++++++++
1 file changed, 86 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index 3a3bcff..a39da09 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -62,6 +62,8 @@
next-level-cache = <&A53_L2>;
cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <592>;
+ clocks = <&stub_clock HI3660_CLK_STUB_CLUSTER0>;
+ operating-points-v2 = <&cluster0_opp>;
};
cpu1: cpu@1 {
@@ -72,6 +74,8 @@
next-level-cache = <&A53_L2>;
cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <592>;
+ clocks = <&stub_clock HI3660_CLK_STUB_CLUSTER0>;
+ operating-points-v2 = <&cluster0_opp>;
};
cpu2: cpu@2 {
@@ -82,6 +86,8 @@
next-level-cache = <&A53_L2>;
cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <592>;
+ clocks = <&stub_clock HI3660_CLK_STUB_CLUSTER0>;
+ operating-points-v2 = <&cluster0_opp>;
};
cpu3: cpu@3 {
@@ -92,6 +98,8 @@
next-level-cache = <&A53_L2>;
cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_0>;
capacity-dmips-mhz = <592>;
+ clocks = <&stub_clock HI3660_CLK_STUB_CLUSTER0>;
+ operating-points-v2 = <&cluster0_opp>;
};
cpu4: cpu@100 {
@@ -102,6 +110,8 @@
next-level-cache = <&A73_L2>;
cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_1>;
capacity-dmips-mhz = <1024>;
+ clocks = <&stub_clock HI3660_CLK_STUB_CLUSTER1>;
+ operating-points-v2 = <&cluster1_opp>;
};
cpu5: cpu@101 {
@@ -112,6 +122,8 @@
next-level-cache = <&A73_L2>;
cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_1>;
capacity-dmips-mhz = <1024>;
+ clocks = <&stub_clock HI3660_CLK_STUB_CLUSTER1>;
+ operating-points-v2 = <&cluster1_opp>;
};
cpu6: cpu@102 {
@@ -122,6 +134,8 @@
next-level-cache = <&A73_L2>;
cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_1>;
capacity-dmips-mhz = <1024>;
+ clocks = <&stub_clock HI3660_CLK_STUB_CLUSTER1>;
+ operating-points-v2 = <&cluster1_opp>;
};
cpu7: cpu@103 {
@@ -132,6 +146,8 @@
next-level-cache = <&A73_L2>;
cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP_1>;
capacity-dmips-mhz = <1024>;
+ clocks = <&stub_clock HI3660_CLK_STUB_CLUSTER1>;
+ operating-points-v2 = <&cluster1_opp>;
};
idle-states {
@@ -174,6 +190,76 @@
};
};
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <533000000>;
+ opp-microvolt = <700000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp01 {
+ opp-hz = /bits/ 64 <999000000>;
+ opp-microvolt = <800000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp02 {
+ opp-hz = /bits/ 64 <1402000000>;
+ opp-microvolt = <900000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp03 {
+ opp-hz = /bits/ 64 <1709000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp04 {
+ opp-hz = /bits/ 64 <1844000000>;
+ opp-microvolt = <1100000>;
+ clock-latency-ns = <300000>;
+ };
+ };
+
+ cluster1_opp: opp_table1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp10 {
+ opp-hz = /bits/ 64 <903000000>;
+ opp-microvolt = <700000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp11 {
+ opp-hz = /bits/ 64 <1421000000>;
+ opp-microvolt = <800000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp12 {
+ opp-hz = /bits/ 64 <1805000000>;
+ opp-microvolt = <900000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp13 {
+ opp-hz = /bits/ 64 <2112000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp14 {
+ opp-hz = /bits/ 64 <2362000000>;
+ opp-microvolt = <1100000>;
+ clock-latency-ns = <300000>;
+ };
+ };
+
gic: interrupt-controller@e82b0000 {
compatible = "arm,gic-400";
reg = <0x0 0xe82b1000 0 0x1000>, /* GICD */
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/5] arm64: dts: hi3660: Add stub clock node
From: Leo Yan @ 2018-05-15 2:53 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Jassi Brar, Arnd Bergmann, Olof Johansson,
Daniel Lezcano, linux-arm-kernel, devicetree, linux-kernel,
linux-clk
Cc: Kaihua Zhong, Leo Yan
In-Reply-To: <1526352795-6991-1-git-send-email-leo.yan@linaro.org>
From: Kaihua Zhong <zhongkaihua@huawei.com>
Add stub clock node for hi3660 platform.
Reviewed-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Kaihua Zhong <zhongkaihua@huawei.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index b9e7c91..3a3bcff 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -282,6 +282,13 @@
#mbox-cells = <3>;
};
+ stub_clock: stub_clock@e896b500 {
+ compatible = "hisilicon,hi3660-stub-clk";
+ reg = <0x0 0xe896b500 0x0 0x0100>;
+ #clock-cells = <1>;
+ mboxes = <&mailbox 13 3 0>;
+ };
+
dual_timer0: timer@fff14000 {
compatible = "arm,sp804", "arm,primecell";
reg = <0x0 0xfff14000 0x0 0x1000>;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/5] arm64: dts: hi3660: Add mailbox node
From: Leo Yan @ 2018-05-15 2:53 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Jassi Brar, Arnd Bergmann, Olof Johansson,
Daniel Lezcano, linux-arm-kernel, devicetree, linux-kernel,
linux-clk
Cc: Kaihua Zhong, Leo Yan
In-Reply-To: <1526352795-6991-1-git-send-email-leo.yan@linaro.org>
From: Kaihua Zhong <zhongkaihua@huawei.com>
Add the mailbox controller node for hi3660 platform.
Signed-off-by: Kaihua Zhong <zhongkaihua@huawei.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
---
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
index ec3eb8e..b9e7c91 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3660.dtsi
@@ -274,6 +274,14 @@
#reset-cells = <2>;
};
+ mailbox: mailbox@e896b000 {
+ compatible = "hisilicon,hi3660-mbox";
+ reg = <0x0 0xe896b000 0x0 0x1000>;
+ interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
+ #mbox-cells = <3>;
+ };
+
dual_timer0: timer@fff14000 {
compatible = "arm,sp804", "arm,primecell";
reg = <0x0 0xfff14000 0x0 0x1000>;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 0/5] Hi3660: enable power management features
From: Leo Yan @ 2018-05-15 2:53 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Mark Rutland, Michael Turquette,
Stephen Boyd, Jassi Brar, Arnd Bergmann, Olof Johansson,
Daniel Lezcano, linux-arm-kernel, devicetree, linux-kernel,
linux-clk
Cc: Leo Yan
Since hi3660 drivers have been merged into Linux kernel (mailbox driver is in
Linux-next branch and other drivers are existed in Linux mainline kernel), so
this patch series is to enable power management features on hi3660.
This patch series includes device tree binding for mailbox, stub clock and CPU
OPPs, and has one patch to consolidate the Kconfigs for driver modules.
This patch set have been tested on Hikey960 and also verified the patch 'hisi:
Consolidate the Kconfigs for the CLOCK_STUB and the MAILBOX' for Hikey620.
Changes from v1:
* Changed patch subject from "dts: arm64: hi3660" to "arm64: dts: hi3660".
Daniel Lezcano (1):
hisi: Consolidate the Kconfigs for the CLOCK_STUB and the MAILBOX
Kaihua Zhong (2):
arm64: dts: hi3660: Add mailbox node
arm64: dts: hi3660: Add stub clock node
Leo Yan (1):
arm64: dts: hi3660: Add CPU frequency scaling support
Tao Wang (1):
arm64: dts: hi3660: Add thermal cooling management
arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 145 ++++++++++++++++++++++++++++++
arch/arm64/configs/defconfig | 1 -
drivers/clk/hisilicon/Kconfig | 13 +--
drivers/mailbox/Kconfig | 12 ++-
4 files changed, 161 insertions(+), 10 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH] ARM: dts: chromecast: override bad bootloader memory info
From: Jisheng Zhang @ 2018-05-15 2:29 UTC (permalink / raw)
To: Thomas Hebb
Cc: linux-kernel, Sebastian Hesselbarth, Rob Herring, Mark Rutland,
moderated list:ARM/Synaptics Berlin SoC support,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20180514215645.17592-2-tommyhebb@gmail.com>
Hi,
On Mon, 14 May 2018 17:56:45 -0400 Thomas Hebb wrote:
> On the Chromecast, the bootloader provides us with an ATAG_MEM of
> start=0x01000000 and size=0x3eff8000. This is clearly incorrect, as the
> range given encompasses nearly a GiB but the Chromecast only has 512MiB
> of RAM! Additionally, this causes the kernel to be decompressed at
> 0x00008000, below the claimed beginning of RAM, and so the boot fails.
>
> Since the existing ATAG parsing code runs before the kernel is even
> decompressed and irrevocably patches the device tree, don't even try
This means you enabled ARM_ATAG_DTB_COMPAT. could we disable it instead?
The ATAG is useless when we provide dtb. And IIRC, the ATAG is provided due
to legacy history code.
Thanks
> to bypass it. Instead, use the "linux,usable-memory" property instead
> of the "reg" property to define the real range. The ATAG code only
> overwrites reg, but linux,usable-memory is checked first in the OF
> driver, so the fact that reg gets changed makes no difference.
>
> Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
> ---
> arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
> index 20f31cdeaf38..54221f55bfa2 100644
> --- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
> +++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
> @@ -52,7 +52,17 @@
>
> memory@0 {
> device_type = "memory";
> - reg = <0x00000000 0x20000000>; /* 512 MB */
> +
> + /*
> + * We're using "linux,usable-memory" instead of "reg" here
> + * because the (signed and encrypted) bootloader that shipped
> + * with this device provides an incorrect memory range in
> + * ATAG_MEM. Linux helpfully overrides the "reg" property with
> + * data from the ATAG, so we can't specify the proper range
> + * normally. Fortunately, this alternate property is checked
> + * first by the OF driver, so we can (ab)use it instead.
> + */
> + linux,usable-memory = <0x00000000 0x20000000>; /* 512 MB */
> };
>
> leds {
^ permalink raw reply
* RE: [PATCH/RFC v3 1/4] base: devcon: add a new API to find the graph
From: Yoshihiro Shimoda @ 2018-05-15 2:19 UTC (permalink / raw)
To: Heikki Krogerus
Cc: gregkh@linuxfoundation.org, robh+dt@kernel.org,
mark.rutland@arm.com, hdegoede@redhat.com,
andy.shevchenko@gmail.com, linux-usb@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20180514132740.GE21435@kuha.fi.intel.com>
Hi Heikki,
> From: Heikki Krogerus, Sent: Monday, May 14, 2018 10:28 PM
>
> On Mon, May 14, 2018 at 06:15:57PM +0900, Yoshihiro Shimoda wrote:
<snip>
> > diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
> > index d427e80..5a0da33 100644
> > --- a/drivers/base/devcon.c
> > +++ b/drivers/base/devcon.c
<snip>
> > +static int generic_graph_match(struct device *dev, void *fwnode)
> > +{
> > + return dev->fwnode == fwnode;
> > +}
> > +
> > +/**
> > + * device_connection_find_by_graph - Find two devices connected together
> > + * @dev: Device to find connected device
> > + * @port: identifier of the @dev port node
> > + * @endpoint: identifier of the @dev endpoint node
> > + *
> > + * Find a connection with @port and @endpoint by using graph between @dev and
> > + * another device. On success returns handle to the device that is connected
> > + * to @dev, with the reference count for the found device incremented. Returns
> > + * NULL if no matching connection was found, or ERR_PTR(-EPROBE_DEFER) when
> > + * a connection was found but the other device has not been enumerated yet.
> > + */
> > +struct device *device_connection_find_by_graph(struct device *dev, u32 port,
> > + u32 endpoint)
> > +{
> > + struct bus_type *bus;
> > + struct fwnode_handle *remote;
> > + struct device *conn;
> > +
> > + remote = fwnode_graph_get_remote_node(dev_fwnode(dev), port, endpoint);
> > + if (!remote)
> > + return NULL;
> > +
> > + for (bus = generic_match_buses[0]; bus; bus++) {
> > + conn = bus_find_device(bus, NULL, remote, generic_graph_match);
> > + if (conn)
> > + return conn;
> > + }
> > +
> > + /*
> > + * We only get called if a connection was found, tell the caller to
> > + * wait for the other device to show up.
> > + */
> > + return ERR_PTR(-EPROBE_DEFER);
> > +}
> > +EXPORT_SYMBOL_GPL(device_connection_find_by_graph);
>
> Why do we need more API for walking through the graph?
I thought there is difficult to find if a device has multiple ports or endpoints.
So, I'd like to use port and endpoint number for finding a device.
> I'm not sure exactly sure what is going on here, I'll try to study
> your patches more when I have time, but the approach looks wrong. That
> function looks like a helper, but just not that useful one.
>
> We really should be able to use the existing functions. In practice
> device_connection_find_match() should eventually parse the graph, then
> fallback to build-in connections if no graph is found. Otherwise
> parsing graph here is not really useful at all.
I think using device_connection_find_match() for finding the graph becomes complicated.
The current arguments of the function is the below:
void *device_connection_find_match(struct device *dev, const char *con_id,
void *data,
void *(*match)(struct device_connection *con,
int ep, void *data))
If finding the graph, the following arguments will be not used.
- con_id
- *con and ep of "match" arguments.
This is because these arguments are for the build-in connections.
So, should I modify the arguments of the function for finding both
the graph and built-in connections somehow?
Best regards,
Yoshihiro Shimoda
>
> Thanks,
>
> --
> heikki
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 3/3] drm/tinydrm: new driver for ILI9341 display panels
From: David Lechner @ 2018-05-15 1:43 UTC (permalink / raw)
To: dri-devel, devicetree
Cc: Mark Rutland, limor, David Lechner, linux-kernel, Rob Herring,
Nitin Patil
In-Reply-To: <20180515014349.26226-1-david@lechnology.com>
This adds a new driver for display panels that use the Ilitek ILI9341
controller. It currently supports a single display panel, namely
the YX240QV29-T (e.g. Adafruit 2.4" TFT).
The init sequence is from the Adafruit Python library for the ILI9341
controller. https://github.com/adafruit/Adafruit_Python_ILI9341
Signed-off-by: David Lechner <david@lechnology.com>
---
MAINTAINERS | 6 +
drivers/gpu/drm/tinydrm/Kconfig | 10 ++
drivers/gpu/drm/tinydrm/Makefile | 1 +
drivers/gpu/drm/tinydrm/ili9341.c | 239 ++++++++++++++++++++++++++++++
4 files changed, 256 insertions(+)
create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c
diff --git a/MAINTAINERS b/MAINTAINERS
index bc219de9cbee..ffa099abbd79 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4480,6 +4480,12 @@ S: Maintained
F: drivers/gpu/drm/tinydrm/ili9225.c
F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
+DRM DRIVER FOR ILITEK ILI9341 PANELS
+M: David Lechner <david@lechnology.com>
+S: Maintained
+F: drivers/gpu/drm/tinydrm/ili9341.c
+F: Documentation/devicetree/bindings/display/ilitek,ili9341.txt
+
DRM DRIVER FOR INTEL I810 VIDEO CARDS
S: Orphan / Obsolete
F: drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 4592a5e3f20b..7a8008b0783f 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -20,6 +20,16 @@ config TINYDRM_ILI9225
If M is selected the module will be called ili9225.
+config TINYDRM_ILI9341
+ tristate "DRM support for ILI9341 display panels"
+ depends on DRM_TINYDRM && SPI
+ select TINYDRM_MIPI_DBI
+ help
+ DRM driver for the following Ilitek ILI9341 panels:
+ * YX240QV29-T 2.4" 240x320 TFT (Adafruit 2.4")
+
+ If M is selected the module will be called ili9341.
+
config TINYDRM_MI0283QT
tristate "DRM support for MI0283QT"
depends on DRM_TINYDRM && SPI
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 49a111929724..14d99080665a 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_TINYDRM_MIPI_DBI) += mipi-dbi.o
# Displays
obj-$(CONFIG_TINYDRM_ILI9225) += ili9225.o
+obj-$(CONFIG_TINYDRM_ILI9341) += ili9341.o
obj-$(CONFIG_TINYDRM_MI0283QT) += mi0283qt.o
obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
obj-$(CONFIG_TINYDRM_ST7586) += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/ili9341.c b/drivers/gpu/drm/tinydrm/ili9341.c
new file mode 100644
index 000000000000..2ce4244a68c3
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/ili9341.c
@@ -0,0 +1,239 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * DRM driver for Ilitek ILI9341 panels
+ *
+ * Copyright 2018 David Lechner <david@lechnology.com>
+ *
+ * Based on mi0283qt.c:
+ * Copyright 2016 Noralf Trønnes
+ */
+
+#include <linux/backlight.h>
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/property.h>
+#include <linux/regulator/consumer.h>
+#include <linux/spi/spi.h>
+
+#include <drm/drm_fb_helper.h>
+#include <drm/drm_modeset_helper.h>
+#include <drm/drm_gem_framebuffer_helper.h>
+#include <drm/tinydrm/mipi-dbi.h>
+#include <drm/tinydrm/tinydrm-helpers.h>
+#include <video/mipi_display.h>
+
+#define ILI9341_FRMCTR1 0xb1
+#define ILI9341_DISCTRL 0xb6
+#define ILI9341_ETMOD 0xb7
+
+#define ILI9341_PWCTRL1 0xc0
+#define ILI9341_PWCTRL2 0xc1
+#define ILI9341_VMCTRL1 0xc5
+#define ILI9341_VMCTRL2 0xc7
+#define ILI9341_PWCTRLA 0xcb
+#define ILI9341_PWCTRLB 0xcf
+
+#define ILI9341_PGAMCTRL 0xe0
+#define ILI9341_NGAMCTRL 0xe1
+#define ILI9341_DTCTRLA 0xe8
+#define ILI9341_DTCTRLB 0xea
+#define ILI9341_PWRSEQ 0xed
+
+#define ILI9341_EN3GAM 0xf2
+#define ILI9341_PUMPCTRL 0xf7
+
+#define ILI9341_MADCTL_BGR BIT(3)
+#define ILI9341_MADCTL_MV BIT(5)
+#define ILI9341_MADCTL_MX BIT(6)
+#define ILI9341_MADCTL_MY BIT(7)
+
+static void yx240qv29_enable(struct drm_simple_display_pipe *pipe,
+ struct drm_crtc_state *crtc_state,
+ struct drm_plane_state *plane_state)
+{
+ struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
+ struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
+ u8 addr_mode;
+ int ret;
+
+ DRM_DEBUG_KMS("\n");
+
+ ret = mipi_dbi_poweron_conditional_reset(mipi);
+ if (ret < 0)
+ return;
+ if (ret == 1)
+ goto out_enable;
+
+ mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_OFF);
+
+ mipi_dbi_command(mipi, ILI9341_PWCTRLB, 0x00, 0xc1, 0x30);
+ mipi_dbi_command(mipi, ILI9341_PWRSEQ, 0x64, 0x03, 0x12, 0x81);
+ mipi_dbi_command(mipi, ILI9341_DTCTRLA, 0x85, 0x00, 0x78);
+ mipi_dbi_command(mipi, ILI9341_PWCTRLA, 0x39, 0x2c, 0x00, 0x34, 0x02);
+ mipi_dbi_command(mipi, ILI9341_PUMPCTRL, 0x20);
+ mipi_dbi_command(mipi, ILI9341_DTCTRLB, 0x00, 0x00);
+
+ /* Power Control */
+ mipi_dbi_command(mipi, ILI9341_PWCTRL1, 0x23);
+ mipi_dbi_command(mipi, ILI9341_PWCTRL2, 0x10);
+ /* VCOM */
+ mipi_dbi_command(mipi, ILI9341_VMCTRL1, 0x3e, 0x28);
+ mipi_dbi_command(mipi, ILI9341_VMCTRL2, 0x86);
+
+ /* Memory Access Control */
+ mipi_dbi_command(mipi, MIPI_DCS_SET_PIXEL_FORMAT, MIPI_DCS_PIXEL_FMT_16BIT);
+
+ /* Frame Rate */
+ mipi_dbi_command(mipi, ILI9341_FRMCTR1, 0x00, 0x1b);
+
+ /* Gamma */
+ mipi_dbi_command(mipi, ILI9341_EN3GAM, 0x00);
+ mipi_dbi_command(mipi, MIPI_DCS_SET_GAMMA_CURVE, 0x01);
+ mipi_dbi_command(mipi, ILI9341_PGAMCTRL,
+ 0x0f, 0x31, 0x2b, 0x0c, 0x0e, 0x08, 0x4e, 0xf1,
+ 0x37, 0x07, 0x10, 0x03, 0x0e, 0x09, 0x00);
+ mipi_dbi_command(mipi, ILI9341_NGAMCTRL,
+ 0x00, 0x0e, 0x14, 0x03, 0x11, 0x07, 0x31, 0xc1,
+ 0x48, 0x08, 0x0f, 0x0c, 0x31, 0x36, 0x0f);
+
+ /* DDRAM */
+ mipi_dbi_command(mipi, ILI9341_ETMOD, 0x07);
+
+ /* Display */
+ mipi_dbi_command(mipi, ILI9341_DISCTRL, 0x08, 0x82, 0x27, 0x00);
+ mipi_dbi_command(mipi, MIPI_DCS_EXIT_SLEEP_MODE);
+ msleep(100);
+
+ mipi_dbi_command(mipi, MIPI_DCS_SET_DISPLAY_ON);
+ msleep(100);
+
+out_enable:
+ switch (mipi->rotation) {
+ default:
+ addr_mode = ILI9341_MADCTL_MX;
+ break;
+ case 90:
+ addr_mode = ILI9341_MADCTL_MV;
+ break;
+ case 180:
+ addr_mode = ILI9341_MADCTL_MY;
+ break;
+ case 270:
+ addr_mode = ILI9341_MADCTL_MV | ILI9341_MADCTL_MY |
+ ILI9341_MADCTL_MX;
+ break;
+ }
+ addr_mode |= ILI9341_MADCTL_BGR;
+ mipi_dbi_command(mipi, MIPI_DCS_SET_ADDRESS_MODE, addr_mode);
+ mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
+}
+
+static const struct drm_simple_display_pipe_funcs ili9341_pipe_funcs = {
+ .enable = yx240qv29_enable,
+ .disable = mipi_dbi_pipe_disable,
+ .update = tinydrm_display_pipe_update,
+ .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
+};
+
+static const struct drm_display_mode yx240qv29_mode = {
+ TINYDRM_MODE(240, 320, 37, 49),
+};
+
+DEFINE_DRM_GEM_CMA_FOPS(ili9341_fops);
+
+static struct drm_driver ili9341_driver = {
+ .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
+ DRIVER_ATOMIC,
+ .fops = &ili9341_fops,
+ TINYDRM_GEM_DRIVER_OPS,
+ .lastclose = drm_fb_helper_lastclose,
+ .debugfs_init = mipi_dbi_debugfs_init,
+ .name = "ili9341",
+ .desc = "Ilitek ILI9341",
+ .date = "20180514",
+ .major = 1,
+ .minor = 0,
+};
+
+static const struct of_device_id ili9341_of_match[] = {
+ { .compatible = "noname,yx240qv29" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ili9341_of_match);
+
+static const struct spi_device_id ili9341_id[] = {
+ { "yx240qv29", 0 },
+ { },
+};
+MODULE_DEVICE_TABLE(spi, ili9341_id);
+
+static int ili9341_probe(struct spi_device *spi)
+{
+ struct device *dev = &spi->dev;
+ struct mipi_dbi *mipi;
+ struct gpio_desc *dc;
+ u32 rotation = 0;
+ int ret;
+
+ mipi = devm_kzalloc(dev, sizeof(*mipi), GFP_KERNEL);
+ if (!mipi)
+ return -ENOMEM;
+
+ mipi->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(mipi->reset)) {
+ DRM_DEV_ERROR(dev, "Failed to get gpio 'reset'\n");
+ return PTR_ERR(mipi->reset);
+ }
+
+ dc = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW);
+ if (IS_ERR(dc)) {
+ DRM_DEV_ERROR(dev, "Failed to get gpio 'dc'\n");
+ return PTR_ERR(dc);
+ }
+
+ mipi->regulator = devm_regulator_get(dev, "power");
+ if (IS_ERR(mipi->regulator))
+ return PTR_ERR(mipi->regulator);
+
+ mipi->backlight = devm_of_find_backlight(dev);
+ if (IS_ERR(mipi->backlight))
+ return PTR_ERR(mipi->backlight);
+
+ device_property_read_u32(dev, "rotation", &rotation);
+
+ ret = mipi_dbi_spi_init(spi, mipi, dc);
+ if (ret)
+ return ret;
+
+ ret = mipi_dbi_init(&spi->dev, mipi, &ili9341_pipe_funcs,
+ &ili9341_driver, &yx240qv29_mode, rotation);
+ if (ret)
+ return ret;
+
+ spi_set_drvdata(spi, mipi);
+
+ return devm_tinydrm_register(&mipi->tinydrm);
+}
+
+static void ili9341_shutdown(struct spi_device *spi)
+{
+ struct mipi_dbi *mipi = spi_get_drvdata(spi);
+
+ tinydrm_shutdown(&mipi->tinydrm);
+}
+
+static struct spi_driver ili9341_spi_driver = {
+ .driver = {
+ .name = "ili9341",
+ .of_match_table = ili9341_of_match,
+ },
+ .id_table = ili9341_id,
+ .probe = ili9341_probe,
+ .shutdown = ili9341_shutdown,
+};
+module_spi_driver(ili9341_spi_driver);
+
+MODULE_DESCRIPTION("Ilitek ILI9341 DRM driver");
+MODULE_AUTHOR("David Lechner <david@lechnology.com>");
+MODULE_LICENSE("GPL");
--
2.17.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: new binding for Ilitek ILI9341 display panels
From: David Lechner @ 2018-05-15 1:43 UTC (permalink / raw)
To: dri-devel, devicetree
Cc: Mark Rutland, limor, David Lechner, linux-kernel, Rob Herring,
Nitin Patil
In-Reply-To: <20180515014349.26226-1-david@lechnology.com>
This adds a new binding for Ilitek ILI9341 display panels. It includes
a compatible string for one display (more can be added in the future).
The vendor prefix "noname" is used because the vendor is not known.
The YX240QV29-T panel[1] is found, for example, in an Adafruit breakout
board[2] and in Mindsensors' PiStorms[3].
[1]: https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf
[2]: https://www.adafruit.com/product/2478
[3]: http://www.mindsensors.com/stem-with-robotics/13-pistorms-v2-base-kit-raspberry-pi-brain-for-lego-robot
Signed-off-by: David Lechner <david@lechnology.com>
---
.../bindings/display/ilitek,ili9341.txt | 27 +++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt
diff --git a/Documentation/devicetree/bindings/display/ilitek,ili9341.txt b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
new file mode 100644
index 000000000000..0fc90b2dd732
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ilitek,ili9341.txt
@@ -0,0 +1,27 @@
+Ilitek ILI9341 display panels
+
+This binding is for display panels using an Ilitek ILI9341 controller in SPI
+mode.
+
+Required properties:
+- compatible: "noname,yx240qv29", "ilitek,ili9341"
+- dc-gpios: D/C pin
+- reset-gpios: Reset pin
+
+The node for this driver must be a child node of a SPI controller, hence
+all mandatory properties described in ../spi/spi-bus.txt must be specified.
+
+Optional properties:
+- rotation: panel rotation in degrees counter clockwise (0,90,180,270)
+- backlight: phandle of the backlight device attached to the panel
+
+Example:
+ display@0{
+ compatible = "noname,yx240qv29", "ilitek,ili9341";
+ reg = <0>;
+ spi-max-frequency = <32000000>;
+ dc-gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio0 8 GPIO_ACTIVE_HIGH>;
+ rotation = <270>;
+ backlight = <&backlight>;
+ };
--
2.17.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 1/3] MAINTAINERS: fix path to ilitek, ili9225 device tree bindings
From: David Lechner @ 2018-05-15 1:43 UTC (permalink / raw)
To: dri-devel, devicetree
Cc: Mark Rutland, limor, David Lechner, linux-kernel, Rob Herring,
Nitin Patil
In-Reply-To: <20180515014349.26226-1-david@lechnology.com>
This fixes the path to the ilitek,ili9225 device tree binding file.
Signed-off-by: David Lechner <david@lechnology.com>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 334a00350922..bc219de9cbee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4478,7 +4478,7 @@ DRM DRIVER FOR ILITEK ILI9225 PANELS
M: David Lechner <david@lechnology.com>
S: Maintained
F: drivers/gpu/drm/tinydrm/ili9225.c
-F: Documentation/devicetree/bindings/display/ili9225.txt
+F: Documentation/devicetree/bindings/display/ilitek,ili9225.txt
DRM DRIVER FOR INTEL I810 VIDEO CARDS
S: Orphan / Obsolete
--
2.17.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 0/3] drm/tinydrm: new dirver for ILI9341 displays
From: David Lechner @ 2018-05-15 1:43 UTC (permalink / raw)
To: dri-devel, devicetree
Cc: Mark Rutland, limor, David Lechner, linux-kernel, Rob Herring,
Nitin Patil
This series adds a new tinydrm driver for the Ilitek ILI9341 controller and
a 2.4" display panel that uses this controller.
A few things to note here:
* The datasheet for this display[1] doesn't have a vendor mentioned on it
anywhere, so I have used "noname" as the vendor prefix. If someone has a
better suggestion, please speak up.
* The driver is basically a copy of mi0283qt.c with a new init sequence,
a different physical panel size, fixed (as in corrected) rotation handling,
and dropped PM (since I don't have a way to test it). Do we want to try to
share code with these two drivers (it's not much)?
* The MAINTAINERS patch for ili9225 is included so we don't end up with a merge
conflict later on.
[1]: https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf
David Lechner (3):
MAINTAINERS: fix path to ilitek,ili9225 device tree bindings
dt-bindings: new binding for Ilitek ILI9341 display panels
drm/tinydrm: new driver for ILI9341 display panels
.../bindings/display/ilitek,ili9341.txt | 27 ++
MAINTAINERS | 8 +-
drivers/gpu/drm/tinydrm/Kconfig | 10 +
drivers/gpu/drm/tinydrm/Makefile | 1 +
drivers/gpu/drm/tinydrm/ili9341.c | 239 ++++++++++++++++++
5 files changed, 284 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/display/ilitek,ili9341.txt
create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c
--
2.17.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers
From: Dmitry Torokhov @ 2018-05-15 0:26 UTC (permalink / raw)
To: Florian Fainelli
Cc: Rob Herring, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, devicetree, Jeffy Chen,
Enric Balletbo i Serra, Joseph Lo, Doug Berger, Rafael J. Wysocki
In-Reply-To: <299a564f-f2eb-aa5a-067e-688424b91e58@gmail.com>
On Mon, May 14, 2018 at 04:46:41PM -0700, Florian Fainelli wrote:
> On 04/25/2018 11:14 AM, Dmitry Torokhov wrote:
> > On Wed, Apr 25, 2018 at 10:00:31AM -0500, Rob Herring wrote:
> >> On Tue, Apr 24, 2018 at 5:58 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>> Hi Linus, Rafael, all
> >>>
> >>> Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which
> >>> gets invoked when the system is brought into poweroff aka S5. So far so
> >>> good, except that we also wish to use gpio_keys.c as a possible wake-up
> >>> source, so we may have a number of GPIO pins declared as gpio-keys that
> >>> allow the system to wake-up from deep slumber.
> >>>
> >>> Recently we noticed that we could easily get into a state where
> >>> gpio-brcmstb.c::brcmstb_gpio_shutdown() gets called first, and then
> >>> gpio_keys.c::gpio_keys_suspend() gets called later, which is too late to
> >>> have the enable_irq_wake() call do anything sensible since we have
> >>> suspend its parent interrupt controller before. This is completely
> >>> expected unfortunately because these two drivers are both platform
> >>> device instances with no connection to one another except via Device
> >>> Tree and the use of the GPIOLIB APIs.
> >>>
> >>> First solution is to make sure that gpio-keys nodes are declared in
> >>> Device Tree *before* the GPIO controller. This works because Device Tree
> >>> nodes are probed in the order in which they are declared in Device Tree
> >>> and that directly influences the order in which platform devices are
> >>> created. Problem with that is that this is easy to miss and it may not
> >>> work with overlays, kexec reconstructing DT etc. etc.
> >>
> >> I'm going to make of_platform_populate randomize the order it creates devices...
> >>
> >>> Another possible solution would be have the GPIO controller nodes have
> >>> the GPIO consumers nodes such as gpio-keys, gpio-leds etc., and that
> >>> would allow the Linux device driver model to create an appropriate
> >>> child/parent relationship. This would unfortunately require Device Tree
> >>> changes everywhere to make that consistent, and it would be a special
> >>> case, because not all GPIO consumers are eligible as child nodes of
> >>> their parent GPIO controller, there are plenty of other consumers that
> >>> are not suitable for being moved under a parent GPIO controller node.
> >>> This would also mean that we need to "probe" GPIO controller nodes to
> >>> populate their child nodes (e.g: of_platform_bus_populate).
> >>>
> >>> I am thinking a more generic solution might involve some more complex
> >>> tracking of the provider <-> consumer, but there is room for breakage.
> >>
> >> That's what device connections are for. It probably just needs the
> >> GPIO core to create the links. (but I've not looked into it at all).
> >
> > Not all APIs accept device as parameter to easily create links. But I
> > wonder, for cases like this, if we could not simply move the device to
> > the end of the dpm list after successful binding it to a driver. The
> > assumption that when GOPIs or other resources are not ready they'll
> > return -EPROBE_DEFER and probing would fail.
>
> Dmitry, do you see any reason why we are enabling the gpio_keys.c button
> interrupts for wake-up during suspend/resume only, and not right from
> the probe() function?
>
> button->wakeup is effectively read-only past the probe function, if we
> moved the logic to enable/disable the interrupts that would greatly
> simplify things. I am assuming whomever added that functionality must
> have been worried about spurious wake-up events somehow and wanted to do
> it as late as possible?
Florian, device_may_wakeup() is not constant (it may be changed via
sysfs), and when the driver was written we did not have
dev_pm_set_wake_irq() that can be used in probe() and handles wakeup
flag changing, so we had to arm wake IRQs in suspend. And even now, with
support of different interrupt triggers for normal operation and wakeup
action, we need to reprogram interrupts in suspend.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/4] PCI: dwc: Add support for EP mode
From: kbuild test robot @ 2018-05-15 0:04 UTC (permalink / raw)
Cc: kbuild-all, bhelgaas, lorenzo.pieralisi, Joao.Pinto, jingoohan1,
kishon, robh+dt, mark.rutland, linux-pci, linux-kernel,
devicetree, Gustavo Pimentel
In-Reply-To: <dbfaccc9902e43b659584e4638a26549a363292a.1526314398.git.gustavo.pimentel@synopsys.com>
[-- Attachment #1: Type: text/plain, Size: 4558 bytes --]
Hi Gustavo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on pci/next]
[also build test ERROR on v4.17-rc5 next-20180514]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Gustavo-Pimentel/Add-DesignWare-EP-support/20180515-072113
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from drivers/pci/dwc/pcie-designware.h:19:0,
from drivers/pci/dwc/pcie-designware-ep.c:11:
drivers/pci/dwc/pcie-designware-ep.c: In function 'dw_pcie_ep_init':
>> drivers/pci/dwc/pcie-designware-ep.c:415:37: error: 'BAR0' undeclared (first use in this function); did you mean 'BAR_0'?
EPC_FEATURE_SET_BAR(epc->features, BAR0);
^
include/linux/pci-epc.h:99:41: note: in definition of macro 'EPC_FEATURE_SET_BAR'
(features |= (EPC_FEATURE_BAR_MASK & (bar << 1)))
^~~
drivers/pci/dwc/pcie-designware-ep.c:415:37: note: each undeclared identifier is reported only once for each function it appears in
EPC_FEATURE_SET_BAR(epc->features, BAR0);
^
include/linux/pci-epc.h:99:41: note: in definition of macro 'EPC_FEATURE_SET_BAR'
(features |= (EPC_FEATURE_BAR_MASK & (bar << 1)))
^~~
vim +415 drivers/pci/dwc/pcie-designware-ep.c
334
335 int dw_pcie_ep_init(struct dw_pcie_ep *ep)
336 {
337 int ret;
338 void *addr;
339 struct pci_epc *epc;
340 struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
341 struct device *dev = pci->dev;
342 struct device_node *np = dev->of_node;
343
344 if (!pci->dbi_base || !pci->dbi_base2) {
345 dev_err(dev, "dbi_base/dbi_base2 is not populated\n");
346 return -EINVAL;
347 }
348
349 ret = of_property_read_u32(np, "num-ib-windows", &ep->num_ib_windows);
350 if (ret < 0) {
351 dev_err(dev, "unable to read *num-ib-windows* property\n");
352 return ret;
353 }
354 if (ep->num_ib_windows > MAX_IATU_IN) {
355 dev_err(dev, "invalid *num-ib-windows*\n");
356 return -EINVAL;
357 }
358
359 ret = of_property_read_u32(np, "num-ob-windows", &ep->num_ob_windows);
360 if (ret < 0) {
361 dev_err(dev, "unable to read *num-ob-windows* property\n");
362 return ret;
363 }
364 if (ep->num_ob_windows > MAX_IATU_OUT) {
365 dev_err(dev, "invalid *num-ob-windows*\n");
366 return -EINVAL;
367 }
368
369 ep->ib_window_map = devm_kzalloc(dev, sizeof(long) *
370 BITS_TO_LONGS(ep->num_ib_windows),
371 GFP_KERNEL);
372 if (!ep->ib_window_map)
373 return -ENOMEM;
374
375 ep->ob_window_map = devm_kzalloc(dev, sizeof(long) *
376 BITS_TO_LONGS(ep->num_ob_windows),
377 GFP_KERNEL);
378 if (!ep->ob_window_map)
379 return -ENOMEM;
380
381 addr = devm_kzalloc(dev, sizeof(phys_addr_t) * ep->num_ob_windows,
382 GFP_KERNEL);
383 if (!addr)
384 return -ENOMEM;
385 ep->outbound_addr = addr;
386
387 if (ep->ops->ep_init)
388 ep->ops->ep_init(ep);
389
390 epc = devm_pci_epc_create(dev, &epc_ops);
391 if (IS_ERR(epc)) {
392 dev_err(dev, "failed to create epc device\n");
393 return PTR_ERR(epc);
394 }
395
396 ret = of_property_read_u8(np, "max-functions", &epc->max_functions);
397 if (ret < 0)
398 epc->max_functions = 1;
399
400 ret = __pci_epc_mem_init(epc, ep->phys_base, ep->addr_size,
401 ep->page_size);
402 if (ret < 0) {
403 dev_err(dev, "Failed to initialize address space\n");
404 return ret;
405 }
406
407 ep->msi_mem = pci_epc_mem_alloc_addr(epc, &ep->msi_mem_phys,
408 epc->mem->page_size);
409 if (!ep->msi_mem) {
410 dev_err(dev, "Failed to reserve memory for MSI\n");
411 return -ENOMEM;
412 }
413
414 epc->features = EPC_FEATURE_NO_LINKUP_NOTIFIER;
> 415 EPC_FEATURE_SET_BAR(epc->features, BAR0);
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 62943 bytes --]
^ permalink raw reply
* Re: Lack of suspend/resume/shutdown ordering between GPIO providers and consumers
From: Florian Fainelli @ 2018-05-14 23:46 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring
Cc: linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM,
devicetree, Jeffy Chen, Enric Balletbo i Serra, Joseph Lo,
Doug Berger, Rafael J. Wysocki
In-Reply-To: <20180425181435.GA200812@dtor-ws>
On 04/25/2018 11:14 AM, Dmitry Torokhov wrote:
> On Wed, Apr 25, 2018 at 10:00:31AM -0500, Rob Herring wrote:
>> On Tue, Apr 24, 2018 at 5:58 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>> Hi Linus, Rafael, all
>>>
>>> Our GPIO controller driver: gpio-brcmstb.c has a shutdown callback which
>>> gets invoked when the system is brought into poweroff aka S5. So far so
>>> good, except that we also wish to use gpio_keys.c as a possible wake-up
>>> source, so we may have a number of GPIO pins declared as gpio-keys that
>>> allow the system to wake-up from deep slumber.
>>>
>>> Recently we noticed that we could easily get into a state where
>>> gpio-brcmstb.c::brcmstb_gpio_shutdown() gets called first, and then
>>> gpio_keys.c::gpio_keys_suspend() gets called later, which is too late to
>>> have the enable_irq_wake() call do anything sensible since we have
>>> suspend its parent interrupt controller before. This is completely
>>> expected unfortunately because these two drivers are both platform
>>> device instances with no connection to one another except via Device
>>> Tree and the use of the GPIOLIB APIs.
>>>
>>> First solution is to make sure that gpio-keys nodes are declared in
>>> Device Tree *before* the GPIO controller. This works because Device Tree
>>> nodes are probed in the order in which they are declared in Device Tree
>>> and that directly influences the order in which platform devices are
>>> created. Problem with that is that this is easy to miss and it may not
>>> work with overlays, kexec reconstructing DT etc. etc.
>>
>> I'm going to make of_platform_populate randomize the order it creates devices...
>>
>>> Another possible solution would be have the GPIO controller nodes have
>>> the GPIO consumers nodes such as gpio-keys, gpio-leds etc., and that
>>> would allow the Linux device driver model to create an appropriate
>>> child/parent relationship. This would unfortunately require Device Tree
>>> changes everywhere to make that consistent, and it would be a special
>>> case, because not all GPIO consumers are eligible as child nodes of
>>> their parent GPIO controller, there are plenty of other consumers that
>>> are not suitable for being moved under a parent GPIO controller node.
>>> This would also mean that we need to "probe" GPIO controller nodes to
>>> populate their child nodes (e.g: of_platform_bus_populate).
>>>
>>> I am thinking a more generic solution might involve some more complex
>>> tracking of the provider <-> consumer, but there is room for breakage.
>>
>> That's what device connections are for. It probably just needs the
>> GPIO core to create the links. (but I've not looked into it at all).
>
> Not all APIs accept device as parameter to easily create links. But I
> wonder, for cases like this, if we could not simply move the device to
> the end of the dpm list after successful binding it to a driver. The
> assumption that when GOPIs or other resources are not ready they'll
> return -EPROBE_DEFER and probing would fail.
Dmitry, do you see any reason why we are enabling the gpio_keys.c button
interrupts for wake-up during suspend/resume only, and not right from
the probe() function?
button->wakeup is effectively read-only past the probe function, if we
moved the logic to enable/disable the interrupts that would greatly
simplify things. I am assuming whomever added that functionality must
have been worried about spurious wake-up events somehow and wanted to do
it as late as possible?
Thanks
--
Florian
^ permalink raw reply
* Re: [RFC PATCH 02/10] dt-bindings: devfreq: rk3399_dmc: Add rockchip,pmu phandle.
From: Chanwoo Choi @ 2018-05-14 22:20 UTC (permalink / raw)
To: Enric Balletbo i Serra, MyungJoo Ham, Kyungmin Park, Rob Herring,
Will Deacon, Heiko Stuebner, Michael Turquette, Stephen Boyd,
Sandy Huang, David Airlie
Cc: linux-pm, linux-kernel, Derek Basehore, linux-clk, linux-rockchip,
dri-devel, Lin Huang, kernel, Sean Paul, linux-arm-kernel,
devicetree, Mark Rutland
In-Reply-To: <20180514211610.26618-3-enric.balletbo@collabora.com>
Hi,
On 2018년 05월 15일 06:16, Enric Balletbo i Serra wrote:
> The Rockchip DMC (Dynamic Memory Interface) needs to access to the PMU
> general register files to know the DRAM type, so add a phandle to the
> syscon that manages these registers.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> ---
>
> Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> index 0ec68141f85a..951789c0cdd6 100644
> --- a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> @@ -12,6 +12,8 @@ Required properties:
> for details.
> - center-supply: DMC supply node.
> - status: Marks the node enabled/disabled.
> +- rockchip,pmu: Phandle to the syscon managing the "PMU general register
> + files".
>
> Optional properties:
> - interrupts: The CPU interrupt number. The interrupt specifier
>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: Collapse usb support into one node
From: Stephen Boyd @ 2018-05-14 22:10 UTC (permalink / raw)
To: moderated list:ARM64 PORT AARCH64 ARCHITECTURE,
open list:ARM/QUALCOMM SUPPORT, open list:ARM/QUALCOMM SUPPORT,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Andy Gross, Catalin Marinas, David Brown, Mark Rutland,
Rob Herring, Will Deacon, open list
Cc: Yossi Mansharoff
In-Reply-To: <1523973390-2387-1-git-send-email-yossim@codeaurora.org>
Quoting Yossi Mansharoff (2018-04-17 06:56:30)
> We currently have three device nodes for the same USB hardware
> block, as evident by the reuse of the same reg address multiple
> times. Now that the chipidea driver fully supports OTG with the
> MSM wrapper we can collapse all these nodes into one USB device
> node, reflecting the true nature of the hardware.
None of this makes sense. Commit text is totally bogus now.
>
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 9ff8487..1505921 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -371,18 +372,18 @@
> adp-disable;
> hnp-disable;
> srp-disable;
> - dr_mode = "host";
> - pinctrl-names = "default";
> - pinctrl-0 = <&usb_sw_sel_pm>;
> + mux-controls = <&usb_switch>;
> + mux-control-names = "usb_switch";
> +
> ulpi {
> phy {
> v1p8-supply = <&pm8916_l7>;
> v3p3-supply = <&pm8916_l13>;
> - extcon = <&usb_id>;
> };
> };
> };
>
> +
Why the newline?
> lpass@7708000 {
> status = "okay";
> };
> @@ -512,11 +513,17 @@
>
> usb_id: usb-id {
> compatible = "linux,extcon-usb-gpio";
> - vbus-gpio = <&msmgpio 121 GPIO_ACTIVE_HIGH>;
> + id-gpio = <&msmgpio 121 GPIO_ACTIVE_HIGH>;
Hmm?
> pinctrl-names = "default";
> pinctrl-0 = <&usb_id_default>;
> };
>
> + usb_switch: usb-switch {
> + compatible = "gpio-mux";
Needs a better compatible string for the actual mux part. The gpio-mux
can come after that because it's generic, but it's good to record the
actual mux part too.
> + mux-gpios = <&pm8916_gpios 4 GPIO_ACTIVE_HIGH>;
> + #mux-control-cells = <0>;
> + };
^ permalink raw reply
* [PATCH 2/2] ARM: dts: chromecast: use PWM for LEDs
From: Thomas Hebb @ 2018-05-14 21:58 UTC (permalink / raw)
To: linux-kernel
Cc: Thomas Hebb, Jisheng Zhang, Sebastian Hesselbarth, Rob Herring,
Mark Rutland, moderated list:ARM/Synaptics Berlin SoC support,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <da60a97a0c6f754faa1f996334b3568ddb2f5ed0.1526334654.git.tommyhebb@gmail.com>
Control the Chromecast's two LEDs using PWM instead of GPIO pins. This
allows for variable brightness.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
---
.../boot/dts/berlin2cd-google-chromecast.dts | 20 ++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
index 54221f55bfa2..fb71e5436420 100644
--- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
+++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
@@ -66,18 +66,21 @@
};
leds {
- compatible = "gpio-leds";
+ compatible = "pwm-leds";
+ pinctrl-0 = <&ledpwm_pmux>;
+ pinctrl-names = "default";
white {
label = "white";
- gpios = <&portc 1 GPIO_ACTIVE_HIGH>;
- default-state = "keep";
+ pwms = <&pwm 0 600000 0>;
+ max-brightness = <255>;
+ linux,default-trigger = "default-on";
};
red {
label = "red";
- gpios = <&portc 2 GPIO_ACTIVE_HIGH>;
- default-state = "keep";
+ pwms = <&pwm 1 600000 0>;
+ max-brightness = <255>;
};
};
};
@@ -96,3 +99,10 @@
&usb_phy1 { status = "okay"; };
&usb1 { status = "okay"; };
+
+&soc_pinctrl {
+ ledpwm_pmux: ledpwm-pmux {
+ groups = "G0";
+ function = "pwm";
+ };
+};
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v4 6/6] devfreq: rk3399_dmc: fix spelling mistakes.
From: Chanwoo Choi @ 2018-05-14 21:57 UTC (permalink / raw)
To: myungjoo.ham, Enric Balletbo i Serra, Kyungmin Park,
robh+dt@kernel.org
Cc: devicetree@vger.kernel.org, ulf.hansson@linaro.org,
heiko@sntech.de, linux-pm@vger.kernel.org, dbasehore@chromium.org,
linux-kernel@vger.kernel.org, groeck@chromium.org,
kernel@collabora.com, hl@rock-chips.com
In-Reply-To: <20180514102355epcms1p5baf3df2741827f9b9bf3e1de37e27880@epcms1p5>
On 2018년 05월 14일 19:23, MyungJoo Ham wrote:
>> Fix some spelling mistakes in error and debug messages.
>>
>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>> ---
>>
>> Changes in v4:
>> - [6/6] Introduce this new patch that fixes some spelling.
>>
>> Changes in v3: None
>> Changes in v2: None
>>
>> drivers/devfreq/rk3399_dmc.c | 12 ++++++------
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Maybe, when you apply this patch on devfreq.git,
you are missing the my reviewed-by tag.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* [PATCH] ARM: dts: chromecast: override bad bootloader memory info
From: Thomas Hebb @ 2018-05-14 21:56 UTC (permalink / raw)
To: linux-kernel
Cc: Thomas Hebb, Jisheng Zhang, Sebastian Hesselbarth, Rob Herring,
Mark Rutland, moderated list:ARM/Synaptics Berlin SoC support,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
On the Chromecast, the bootloader provides us with an ATAG_MEM of
start=0x01000000 and size=0x3eff8000. This is clearly incorrect, as the
range given encompasses nearly a GiB but the Chromecast only has 512MiB
of RAM! Additionally, this causes the kernel to be decompressed at
0x00008000, below the claimed beginning of RAM, and so the boot fails.
Since the existing ATAG parsing code runs before the kernel is even
decompressed and irrevocably patches the device tree, don't even try
to bypass it. Instead, use the "linux,usable-memory" property instead
of the "reg" property to define the real range. The ATAG code only
overwrites reg, but linux,usable-memory is checked first in the OF
driver, so the fact that reg gets changed makes no difference.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
---
arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
index 20f31cdeaf38..54221f55bfa2 100644
--- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
+++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
@@ -52,7 +52,17 @@
memory@0 {
device_type = "memory";
- reg = <0x00000000 0x20000000>; /* 512 MB */
+
+ /*
+ * We're using "linux,usable-memory" instead of "reg" here
+ * because the (signed and encrypted) bootloader that shipped
+ * with this device provides an incorrect memory range in
+ * ATAG_MEM. Linux helpfully overrides the "reg" property with
+ * data from the ATAG, so we can't specify the proper range
+ * normally. Fortunately, this alternate property is checked
+ * first by the OF driver, so we can (ab)use it instead.
+ */
+ linux,usable-memory = <0x00000000 0x20000000>; /* 512 MB */
};
leds {
--
2.17.0
^ permalink raw reply related
* Re: [PATCH 2/2] media: i2c: mt9t112: Add device tree support
From: Sakari Ailus @ 2018-05-14 21:50 UTC (permalink / raw)
To: jacopo mondi
Cc: Jacopo Mondi, hans.verkuil, mchehab, robh+dt, linux-media,
devicetree, linux-kernel
In-Reply-To: <20180514143044.GK5956@w540>
Hi Jacopo,
On Mon, May 14, 2018 at 04:30:44PM +0200, jacopo mondi wrote:
> Hi Sakari,
>
> On Mon, May 07, 2018 at 12:32:19PM +0300, Sakari Ailus wrote:
> > Hi Jacopo,
> >
> > On Wed, Apr 25, 2018 at 01:00:14PM +0200, Jacopo Mondi wrote:
>
> [snip]
>
> > > static int mt9t112_probe(struct i2c_client *client,
> > > const struct i2c_device_id *did)
> > > {
> > > struct mt9t112_priv *priv;
> > > int ret;
> > >
> > > - if (!client->dev.platform_data) {
> > > + if (!client->dev.of_node && !client->dev.platform_data) {
> > > dev_err(&client->dev, "mt9t112: missing platform data!\n");
> > > return -EINVAL;
> > > }
> > > @@ -1081,23 +1118,39 @@ static int mt9t112_probe(struct i2c_client *client,
> > > if (!priv)
> > > return -ENOMEM;
> > >
> > > - priv->info = client->dev.platform_data;
> > > priv->init_done = false;
> > > -
> > > - v4l2_i2c_subdev_init(&priv->subdev, client, &mt9t112_subdev_ops);
> > > -
> > > - priv->clk = devm_clk_get(&client->dev, "extclk");
> > > - if (PTR_ERR(priv->clk) == -ENOENT) {
> > > + priv->dev = &client->dev;
> > > +
> > > + if (client->dev.platform_data) {
> > > + priv->info = client->dev.platform_data;
> > > +
> > > + priv->clk = devm_clk_get(&client->dev, "extclk");
> >
> > extclk needs to be documented in DT binding documentation.
> >
> > > + if (PTR_ERR(priv->clk) == -ENOENT) {
> > > + priv->clk = NULL;
> > > + } else if (IS_ERR(priv->clk)) {
> > > + dev_err(&client->dev,
> > > + "Unable to get clock \"extclk\"\n");
> > > + return PTR_ERR(priv->clk);
> > > + }
> > > + } else {
> > > + /*
> > > + * External clock frequencies != 24MHz are only supported
> > > + * for non-OF systems.
> > > + */
> >
> > Shouldn't you actually set the frequency? Or perhaps even better to check
> > it, and use assigned-clocks and assigned-clock-rates properties?
> >
>
> I might be confused, but my intention was to use an external clock
> reference, with a configurable frequency only in the platform data use
> case. As you can see in this 'else' branch, in OF case, the priv->clk
> field is null, and all the PLL and clock computations are performed
> assuming a 24MHz input clock.
>
> In my opinion, as the driver when running on OF systems does not
> get any reference to 'extclk' clock, it should not be documented in
> bindings. Do you agree?
Uh, isn't the clock generally controlled by the driver on OF-based systems?
You could assign the frequency in DT though, and not in the driver, but
that should be documented in binding documentation.
The register configuration the driver does not appear to be dependent on
the clock frequency, which suggests that it is only applicable to a
particular frequency --- 24 MHz?
>
> Thanks
> j
>
> > > priv->clk = NULL;
> > > - } else if (IS_ERR(priv->clk)) {
> > > - dev_err(&client->dev, "Unable to get clock \"extclk\"\n");
> > > - return PTR_ERR(priv->clk);
> > > + priv->info = &mt9t112_default_pdata_24MHz;
> > > +
> > > + ret = mt9t112_parse_dt(priv);
> > > + if (ret)
> > > + return ret;
> > > }
> > >
> > > - priv->standby_gpio = devm_gpiod_get_optional(&client->dev, "standby",
> > > + v4l2_i2c_subdev_init(&priv->subdev, client, &mt9t112_subdev_ops);
> > > +
> > > + priv->standby_gpio = devm_gpiod_get_optional(&client->dev, "powerdown",
> > > GPIOD_OUT_HIGH);
> > > if (IS_ERR(priv->standby_gpio)) {
> > > - dev_err(&client->dev, "Unable to get gpio \"standby\"\n");
> > > + dev_err(&client->dev, "Unable to get gpio \"powerdown\"\n");
> > > return PTR_ERR(priv->standby_gpio);
> > > }
> > >
> > > @@ -1124,9 +1177,19 @@ static const struct i2c_device_id mt9t112_id[] = {
> > > };
> > > MODULE_DEVICE_TABLE(i2c, mt9t112_id);
> > >
> > > +#if IS_ENABLED(CONFIG_OF)
> > > +static const struct of_device_id mt9t112_of_match[] = {
> > > + { .compatible = "micron,mt9t111", },
> > > + { .compatible = "micron,mt9t112", },
> > > + { /* sentinel */ },
> > > +};
> > > +MODULE_DEVICE_TABLE(of, mt9t112_of_match);
> > > +#endif
> > > +
> > > static struct i2c_driver mt9t112_i2c_driver = {
> > > .driver = {
> > > .name = "mt9t112",
> > > + .of_match_table = of_match_ptr(mt9t112_of_match),
> >
> > No need to use of_match_ptr().
> >
> > > },
> > > .probe = mt9t112_probe,
> > > .remove = mt9t112_remove,
> >
> > --
> > Sakari Ailus
> > e-mail: sakari.ailus@iki.fi
--
Sakari Ailus
e-mail: sakari.ailus@iki.fi
^ permalink raw reply
* Re: [PATCH 12/12] of/platform: make the OF code aware of early platform drivers
From: Geert Uytterhoeven @ 2018-05-14 21:32 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sekhar Nori, Kevin Hilman, David Lechner, Michael Turquette,
Stephen Boyd, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Yoshinori Sato, Rich Felker, Andy Shevchenko, Marc Zyngier,
Rafael J . Wysocki, Peter Rosin, Jiri Slaby, Thomas Gleixner,
Daniel Lezcano, Magnus Damm, Johan Hovold, Rob Herring, Frank
In-Reply-To: <20180511162028.20616-13-brgl@bgdev.pl>
Hi Bartosz,
On Fri, May 11, 2018 at 6:20 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Check the relevant flag in the device node and skip the allocation
> part for devices that were populated early.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Thanks for your patch!
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -196,9 +197,17 @@ static struct platform_device *of_platform_device_create_pdata(
> of_node_test_and_set_flag(np, OF_POPULATED))
> return NULL;
>
> - dev = of_device_alloc(np, bus_id, parent);
> - if (!dev)
> - goto err_clear_flag;
> + if (of_node_check_flag(np, OF_POPULATED_EARLY)) {
> + dev = of_early_to_platform_device(np);
> + if (IS_ERR(dev))
> + goto err_clear_flag;
> +
> + of_device_init(dev, np, bus_id, parent);
> + } else {
> + dev = of_device_alloc(np, bus_id, parent);
> + if (!dev)
> + goto err_clear_flag;
> + }
The above may become cleaner if:
1. of_early_to_platform_device() would return NULL instead -ENOENT,
2. of_device_alloc() would be split in alloc and init phases, too.
Then you can do:
dev = of_node_check_flag(np, OF_POPULATED_EARLY)
? of_early_to_platform_device(np)
: __of_device_alloc(np, bus_id, parent);
if (!dev)
goto err_clear_flag;
of_device_init(dev, np, bus_id, parent);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 09/12] platform/early: add an init section for early driver data
From: Geert Uytterhoeven @ 2018-05-14 21:29 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sekhar Nori, Kevin Hilman, David Lechner, Michael Turquette,
Stephen Boyd, Arnd Bergmann, Greg Kroah-Hartman, Mark Rutland,
Yoshinori Sato, Rich Felker, Andy Shevchenko, Marc Zyngier,
Rafael J . Wysocki, Peter Rosin, Jiri Slaby, Thomas Gleixner,
Daniel Lezcano, Magnus Damm, Johan Hovold, Rob Herring, Frank
In-Reply-To: <20180511162028.20616-10-brgl@bgdev.pl>
Hi Bartosz,
On Fri, May 11, 2018 at 6:20 PM, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> Provide a separate section in which pointers to early platform driver
> structs will be stored.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Thanks for your patch!
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -214,6 +214,16 @@
> #define CPU_METHOD_OF_TABLES() OF_TABLE(CONFIG_SMP, cpu_method)
> #define CPUIDLE_METHOD_OF_TABLES() OF_TABLE(CONFIG_CPU_IDLE, cpuidle_method)
>
> +#ifdef CONFIG_EARLY_PLATFORM
> +#define EARLY_PLATFORM_DRIVERS_TABLE() \
> + . = ALIGN(8); \
Should this use STRUCT_ALIGN() instead?
> + VMLINUX_SYMBOL(__early_platform_drivers_table) = .; \
> + KEEP(*(__early_platform_drivers_table)) \
> + VMLINUX_SYMBOL(__early_platform_drivers_table_end) = .;
> +#else
> +#define EARLY_PLATFORM_DRIVERS_TABLE()
> +#endif
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
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