* [PATCH 0/3] Add STM32 SPI support on stm32mp157c
From: Amelie Delaunay @ 2018-05-17 14:21 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds STM32 SPI support on stm32mp157c SoC.
SPI1, available on GPIO expansion connector, is kept disabled, so these
pins can be used as GPIOs by default.
Amelie Delaunay (3):
ARM: dts: stm32: add STM32 SPI support on stm32mp157c
ARM: dts: stm32: add SPI1 support on stm32mp157c-ev1
ARM: multi_v7_defconfig: enable STM32 SPI
arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 16 +++++-
arch/arm/boot/dts/stm32mp157c-ev1.dts | 6 +++
arch/arm/boot/dts/stm32mp157c.dtsi | 84 +++++++++++++++++++++++++++++++
arch/arm/configs/multi_v7_defconfig | 1 +
4 files changed, 106 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* [PATCH] arm: bcm2835: Add the PMU to the devicetree.
From: Vince Weaver @ 2018-05-17 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517131727.29263-1-eric@anholt.net>
On Thu, 17 May 2018, Eric Anholt wrote:
> diff --git a/arch/arm/boot/dts/bcm2837.dtsi b/arch/arm/boot/dts/bcm2837.dtsi
> index 7704bb029605..1f5e5c782835 100644
> --- a/arch/arm/boot/dts/bcm2837.dtsi
> +++ b/arch/arm/boot/dts/bcm2837.dtsi
> @@ -17,6 +17,12 @@
> };
> };
>
> + arm-pmu {
> + compatible = "arm,cortex-a53-pmu", "arm,cortex-a7-pmu";
> + interrupt-parent = <&local_intc>;
> + interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
why this and not
arm-pmu {
compatible = "arm,armv8-pmuv3";
interrupt-parent = <&local_intc>;
interrupts = <9>;
};
which works, though when I didn't get very far when I submitted the patch
to add this last August.
Vince
^ permalink raw reply
* [PATCH] i2c: i2c-stm32f7: fix documentation typo
From: Wolfram Sang @ 2018-05-17 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526026825-2996-1-git-send-email-pierre-yves.mordret@st.com>
On Fri, May 11, 2018 at 10:20:25AM +0200, Pierre-Yves MORDRET wrote:
> Some data structure members were either misspelled or missing.
>
> Fixes: aeb068c572 ("i2c: i2c-stm32f7: add driver")
> Fixes: 380b8a85e7 ("i2c: i2c-stm32f7: Add initial SMBus protocols support")
> Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
Applied to for-next, thanks!
-------------- 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/20180517/3a20af97/attachment.sig>
^ permalink raw reply
* [PATCH v5 4/4] drm/rockchip: support dp training outside dp firmware
From: Sean Paul @ 2018-05-17 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526548680-2552-4-git-send-email-hl@rock-chips.com>
On Thu, May 17, 2018 at 05:18:00PM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if software training fail, keep firmware
> training as a fallback if sw training fails.
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> Changes in v4:
> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() follow Sean suggest
> Changes in v5:
> - fix some whitespcae issue
>
> drivers/gpu/drm/rockchip/Makefile | 3 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
> drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 ++++++++++++++++++++++++
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 31 +-
> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
> 6 files changed, 505 insertions(+), 13 deletions(-)
> create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
>
> diff --git a/drivers/gpu/drm/rockchip/Makefile b/drivers/gpu/drm/rockchip/Makefile
> index a314e21..b932f62 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -9,7 +9,8 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
> rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>
> rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> -rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o \
> + cdn-dp-link-training.o
> rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
> rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index cce64c1..d9d0d4d 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -629,11 +629,13 @@ static void cdn_dp_encoder_enable(struct drm_encoder *encoder)
> goto out;
> }
> }
> -
> - ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> - if (ret) {
> - DRM_DEV_ERROR(dp->dev, "Failed to idle video %d\n", ret);
> - goto out;
> + if (dp->use_fw_training == true) {
> + ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_IDLE);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to idle video %d\n", ret);
> + goto out;
> + }
> }
>
> ret = cdn_dp_config_video(dp);
> @@ -642,11 +644,15 @@ static void cdn_dp_encoder_enable(struct drm_encoder *encoder)
> goto out;
> }
>
> - ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> - if (ret) {
> - DRM_DEV_ERROR(dp->dev, "Failed to valid video %d\n", ret);
> - goto out;
> + if (dp->use_fw_training == true) {
> + ret = cdn_dp_set_video_status(dp, CONTROL_VIDEO_VALID);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to valid video %d\n", ret);
> + goto out;
> + }
> }
> +
> out:
> mutex_unlock(&dp->lock);
> }
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index 46159b2..77a9793 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -84,6 +84,7 @@ struct cdn_dp_device {
> bool connected;
> bool active;
> bool suspended;
> + bool use_fw_training;
>
> const struct firmware *fw; /* cdn dp firmware */
> unsigned int fw_version; /* cdn fw version */
> @@ -106,6 +107,7 @@ struct cdn_dp_device {
> u8 ports;
> u8 lanes;
> int active_port;
> + u8 train_set[4];
>
> u8 dpcd[DP_RECEIVER_CAP_SIZE];
> bool sink_has_audio;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> new file mode 100644
> index 0000000..73c3290
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> @@ -0,0 +1,420 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong <zyw@rock-chips.com>
> + */
> +
> +#include <linux/device.h>
> +#include <linux/delay.h>
> +#include <linux/phy/phy.h>
> +#include <soc/rockchip/rockchip_phy_typec.h>
> +
> +#include "cdn-dp-core.h"
> +#include "cdn-dp-reg.h"
> +
> +static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
> +{
> + struct cdn_dp_port *port = dp->port[dp->active_port];
> + struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
You ignored Brian's comment on the previous patch:
This is still antithetical to the PHY framework; you're assuming that
this is a particular type of PHY here.
FWIW, the mediatek drm driver also assumes a certain PHY type. A quick grep of
drivers/ shows that the only other non-phy/ driver using this function
(pinctrl-tegra-xusb.c) also casts it.
Sean
> +
> + int rate = drm_dp_bw_code_to_link_rate(dp->link.rate);
> + u8 swing = (dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) >>
> + DP_TRAIN_VOLTAGE_SWING_SHIFT;
> + u8 pre_emphasis = (dp->train_set[0] & DP_TRAIN_PRE_EMPHASIS_MASK)
> + >> DP_TRAIN_PRE_EMPHASIS_SHIFT;
> +
> + tcphy->typec_phy_config(port->phy, rate, dp->link.num_lanes,
> + swing, pre_emphasis);
> +}
> +
> +static int cdn_dp_set_pattern(struct cdn_dp_device *dp, uint8_t dp_train_pat)
> +{
> + u32 phy_config, global_config;
> + int ret;
> + uint8_t pattern = dp_train_pat & DP_TRAINING_PATTERN_MASK;
> +
> + global_config = NUM_LANES(dp->link.num_lanes - 1) | SST_MODE |
> + GLOBAL_EN | RG_EN | ENC_RST_DIS | WR_VHSYNC_FALL;
> +
> + phy_config = DP_TX_PHY_ENCODER_BYPASS(0) |
> + DP_TX_PHY_SKEW_BYPASS(0) |
> + DP_TX_PHY_DISPARITY_RST(0) |
> + DP_TX_PHY_LANE0_SKEW(0) |
> + DP_TX_PHY_LANE1_SKEW(1) |
> + DP_TX_PHY_LANE2_SKEW(2) |
> + DP_TX_PHY_LANE3_SKEW(3) |
> + DP_TX_PHY_10BIT_ENABLE(0);
> +
> + if (pattern != DP_TRAINING_PATTERN_DISABLE) {
> + global_config |= NO_VIDEO;
> + phy_config |= DP_TX_PHY_TRAINING_ENABLE(1) |
> + DP_TX_PHY_SCRAMBLER_BYPASS(1) |
> + DP_TX_PHY_TRAINING_PATTERN(pattern);
> + }
> +
> + ret = cdn_dp_reg_write(dp, DP_FRAMER_GLOBAL_CONFIG, global_config);
> + if (ret) {
> + DRM_ERROR("fail to set DP_FRAMER_GLOBAL_CONFIG, error: %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = cdn_dp_reg_write(dp, DP_TX_PHY_CONFIG_REG, phy_config);
> + if (ret) {
> + DRM_ERROR("fail to set DP_TX_PHY_CONFIG_REG, error: %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = cdn_dp_reg_write(dp, DPTX_LANE_EN, BIT(dp->link.num_lanes) - 1);
> + if (ret) {
> + DRM_ERROR("fail to set DPTX_LANE_EN, error: %d\n", ret);
> + return ret;
> + }
> +
> + if (drm_dp_enhanced_frame_cap(dp->dpcd))
> + ret = cdn_dp_reg_write(dp, DPTX_ENHNCD, 1);
> + else
> + ret = cdn_dp_reg_write(dp, DPTX_ENHNCD, 0);
> + if (ret)
> + DRM_ERROR("failed to set DPTX_ENHNCD, error: %x\n", ret);
> +
> + return ret;
> +}
> +
> +static u8 cdn_dp_pre_emphasis_max(u8 voltage_swing)
> +{
> + switch (voltage_swing & DP_TRAIN_VOLTAGE_SWING_MASK) {
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_0:
> + return DP_TRAIN_PRE_EMPH_LEVEL_3;
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_1:
> + return DP_TRAIN_PRE_EMPH_LEVEL_2;
> + case DP_TRAIN_VOLTAGE_SWING_LEVEL_2:
> + return DP_TRAIN_PRE_EMPH_LEVEL_1;
> + default:
> + return DP_TRAIN_PRE_EMPH_LEVEL_0;
> + }
> +}
> +
> +static void cdn_dp_get_adjust_train(struct cdn_dp_device *dp,
> + uint8_t link_status[DP_LINK_STATUS_SIZE])
> +{
> + int i;
> + uint8_t v = 0, p = 0;
> + uint8_t preemph_max;
> +
> + for (i = 0; i < dp->link.num_lanes; i++) {
> + v = max(v, drm_dp_get_adjust_request_voltage(link_status, i));
> + p = max(p, drm_dp_get_adjust_request_pre_emphasis(link_status,
> + i));
> + }
> +
> + if (v >= VOLTAGE_LEVEL_2)
> + v = VOLTAGE_LEVEL_2 | DP_TRAIN_MAX_SWING_REACHED;
> +
> + preemph_max = cdn_dp_pre_emphasis_max(v);
> + if (p >= preemph_max)
> + p = preemph_max | DP_TRAIN_MAX_PRE_EMPHASIS_REACHED;
> +
> + for (i = 0; i < dp->link.num_lanes; i++)
> + dp->train_set[i] = v | p;
> +}
> +
> +/*
> + * Pick training pattern for channel equalization. Training Pattern 3 for HBR2
> + * or 1.2 devices that support it, Training Pattern 2 otherwise.
> + */
> +static u32 cdn_dp_select_chaneq_pattern(struct cdn_dp_device *dp)
> +{
> + u32 training_pattern = DP_TRAINING_PATTERN_2;
> +
> + /*
> + * cdn dp support HBR2 also support TPS3. TPS3 support is also mandatory
> + * for downstream devices that support HBR2. However, not all sinks
> + * follow the spec.
> + */
> + if (drm_dp_tps3_supported(dp->dpcd))
> + training_pattern = DP_TRAINING_PATTERN_3;
> + else
> + DRM_DEBUG_KMS("5.4 Gbps link rate without sink TPS3 support\n");
> +
> + return training_pattern;
> +}
> +
> +
> +static bool cdn_dp_link_max_vswing_reached(struct cdn_dp_device *dp)
> +{
> + int lane;
> +
> + for (lane = 0; lane < dp->link.num_lanes; lane++)
> + if ((dp->train_set[lane] & DP_TRAIN_MAX_SWING_REACHED) == 0)
> + return false;
> +
> + return true;
> +}
> +
> +static int cdn_dp_update_link_train(struct cdn_dp_device *dp)
> +{
> + int ret;
> +
> + cdn_dp_set_signal_levels(dp);
> +
> + ret = drm_dp_dpcd_write(&dp->aux, DP_TRAINING_LANE0_SET,
> + dp->train_set, dp->link.num_lanes);
> + if (ret != dp->link.num_lanes)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int cdn_dp_set_link_train(struct cdn_dp_device *dp,
> + uint8_t dp_train_pat)
> +{
> + uint8_t buf[sizeof(dp->train_set) + 1];
> + int ret, len;
> +
> + buf[0] = dp_train_pat;
> + if ((dp_train_pat & DP_TRAINING_PATTERN_MASK) ==
> + DP_TRAINING_PATTERN_DISABLE) {
> + /* don't write DP_TRAINING_LANEx_SET on disable */
> + len = 1;
> + } else {
> + /* DP_TRAINING_LANEx_SET follow DP_TRAINING_PATTERN_SET */
> + memcpy(buf + 1, dp->train_set, dp->link.num_lanes);
> + len = dp->link.num_lanes + 1;
> + }
> +
> + ret = drm_dp_dpcd_write(&dp->aux, DP_TRAINING_PATTERN_SET,
> + buf, len);
> + if (ret != len)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int cdn_dp_reset_link_train(struct cdn_dp_device *dp,
> + uint8_t dp_train_pat)
> +{
> + int ret;
> +
> + memset(dp->train_set, 0, sizeof(dp->train_set));
> +
> + cdn_dp_set_signal_levels(dp);
> +
> + ret = cdn_dp_set_pattern(dp, dp_train_pat);
> + if (ret)
> + return ret;
> +
> + return cdn_dp_set_link_train(dp, dp_train_pat);
> +}
> +
> +/* Enable corresponding port and start training pattern 1 */
> +static int cdn_dp_link_training_clock_recovery(struct cdn_dp_device *dp)
> +{
> + u8 voltage;
> + u8 link_status[DP_LINK_STATUS_SIZE];
> + u32 voltage_tries, max_vswing_tries;
> + int ret;
> +
> + /* clock recovery */
> + ret = cdn_dp_reset_link_train(dp, DP_TRAINING_PATTERN_1 |
> + DP_LINK_SCRAMBLING_DISABLE);
> + if (ret) {
> + DRM_ERROR("failed to start link train\n");
> + return ret;
> + }
> +
> + voltage_tries = 1;
> + max_vswing_tries = 0;
> + for (;;) {
> + drm_dp_link_train_clock_recovery_delay(dp->dpcd);
> + if (drm_dp_dpcd_read_link_status(&dp->aux, link_status) !=
> + DP_LINK_STATUS_SIZE) {
> + DRM_ERROR("failed to get link status\n");
> + return -EINVAL;
> + }
> +
> + if (drm_dp_clock_recovery_ok(link_status, dp->link.num_lanes)) {
> + DRM_DEBUG_KMS("clock recovery OK\n");
> + return 0;
> + }
> +
> + if (voltage_tries >= 5) {
> + DRM_DEBUG_KMS("Same voltage tried 5 times\n");
> + return -EINVAL;
> + }
> +
> + if (max_vswing_tries >= 1) {
> + DRM_DEBUG_KMS("Max Voltage Swing reached\n");
> + return -EINVAL;
> + }
> +
> + voltage = dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK;
> +
> + /* Update training set as requested by target */
> + cdn_dp_get_adjust_train(dp, link_status);
> + if (cdn_dp_update_link_train(dp)) {
> + DRM_ERROR("failed to update link training\n");
> + return -EINVAL;
> + }
> +
> + if ((dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) ==
> + voltage)
> + ++voltage_tries;
> + else
> + voltage_tries = 1;
> +
> + if (cdn_dp_link_max_vswing_reached(dp))
> + ++max_vswing_tries;
> + }
> +}
> +
> +static int cdn_dp_link_training_channel_equalization(struct cdn_dp_device *dp)
> +{
> + int tries, ret;
> + u32 training_pattern;
> + uint8_t link_status[DP_LINK_STATUS_SIZE];
> +
> + training_pattern = cdn_dp_select_chaneq_pattern(dp);
> + training_pattern |= DP_LINK_SCRAMBLING_DISABLE;
> +
> + ret = cdn_dp_set_pattern(dp, training_pattern);
> + if (ret)
> + return ret;
> +
> + ret = cdn_dp_set_link_train(dp, training_pattern);
> + if (ret) {
> + DRM_ERROR("failed to start channel equalization\n");
> + return ret;
> + }
> +
> + for (tries = 0; tries < 5; tries++) {
> + drm_dp_link_train_channel_eq_delay(dp->dpcd);
> + if (drm_dp_dpcd_read_link_status(&dp->aux, link_status) !=
> + DP_LINK_STATUS_SIZE) {
> + DRM_ERROR("failed to get link status\n");
> + break;
> + }
> +
> + /* Make sure clock is still ok */
> + if (!drm_dp_clock_recovery_ok(link_status,
> + dp->link.num_lanes)) {
> + DRM_DEBUG_KMS("Clock recovery check failed\n");
> + break;
> + }
> +
> + if (drm_dp_channel_eq_ok(link_status, dp->link.num_lanes)) {
> + DRM_DEBUG_KMS("Channel EQ done\n");
> + return 0;
> + }
> +
> + /* Update training set as requested by target */
> + cdn_dp_get_adjust_train(dp, link_status);
> + if (cdn_dp_update_link_train(dp)) {
> + DRM_ERROR("failed to update link training\n");
> + break;
> + }
> + }
> +
> + /* Try 5 times, else fail and try at lower BW */
> + if (tries == 5)
> + DRM_DEBUG_KMS("Channel equalization failed 5 times\n");
> +
> + return -EINVAL;
> +}
> +
> +static int cdn_dp_stop_link_train(struct cdn_dp_device *dp)
> +{
> + int ret = cdn_dp_set_pattern(dp, DP_TRAINING_PATTERN_DISABLE);
> +
> + if (ret)
> + return ret;
> +
> + return cdn_dp_set_link_train(dp, DP_TRAINING_PATTERN_DISABLE);
> +}
> +
> +static int cdn_dp_get_lower_link_rate(struct cdn_dp_device *dp)
> +{
> + switch (dp->link.rate) {
> + case DP_LINK_BW_1_62:
> + return -EINVAL;
> + case DP_LINK_BW_2_7:
> + dp->link.rate = DP_LINK_BW_1_62;
> + break;
> + case DP_LINK_BW_5_4:
> + dp->link.rate = DP_LINK_BW_2_7;
> + break;
> + default:
> + dp->link.rate = DP_LINK_BW_5_4;
> + break;
> + }
> +
> + return 0;
> +}
> +
> +int cdn_dp_software_train_link(struct cdn_dp_device *dp)
> +{
> + int ret, stop_err;
> + u8 link_config[2];
> + u32 rate, sink_max, source_max;
> +
> + 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;
> + }
> +
> + source_max = dp->lanes;
> + sink_max = drm_dp_max_lane_count(dp->dpcd);
> + dp->link.num_lanes = min(source_max, sink_max);
> +
> + source_max = drm_dp_bw_code_to_link_rate(CDN_DP_MAX_LINK_RATE);
> + sink_max = drm_dp_max_link_rate(dp->dpcd);
> + rate = min(source_max, sink_max);
> + dp->link.rate = drm_dp_link_rate_to_bw_code(rate);
> +
> + link_config[0] = 0;
> + link_config[1] = 0;
> + if (dp->dpcd[DP_MAIN_LINK_CHANNEL_CODING] & 0x01)
> + link_config[1] = DP_SET_ANSI_8B10B;
> + drm_dp_dpcd_write(&dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2);
> +
> + while (true) {
> +
> + /* Write the link configuration data */
> + link_config[0] = dp->link.rate;
> + link_config[1] = dp->link.num_lanes;
> + if (drm_dp_enhanced_frame_cap(dp->dpcd))
> + link_config[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> + drm_dp_dpcd_write(&dp->aux, DP_LINK_BW_SET, link_config, 2);
> +
> + ret = cdn_dp_link_training_clock_recovery(dp);
> + if (ret) {
> + if (!cdn_dp_get_lower_link_rate(dp))
> + continue;
> +
> + DRM_ERROR("training clock recovery failed: %d\n", ret);
> + break;
> + }
> +
> + ret = cdn_dp_link_training_channel_equalization(dp);
> + if (ret) {
> + if (!cdn_dp_get_lower_link_rate(dp))
> + continue;
> +
> + DRM_ERROR("training channel eq failed: %d\n", ret);
> + break;
> + }
> +
> + break;
> + }
> +
> + stop_err = cdn_dp_stop_link_train(dp);
> + if (stop_err) {
> + DRM_ERROR("stop training fail, error: %d\n", stop_err);
> + return stop_err;
> + }
> +
> + return ret;
> +}
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> index 979355d..e1273e6 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> @@ -17,7 +17,9 @@
> #include <linux/delay.h>
> #include <linux/io.h>
> #include <linux/iopoll.h>
> +#include <linux/phy/phy.h>
> #include <linux/reset.h>
> +#include <soc/rockchip/rockchip_phy_typec.h>
>
> #include "cdn-dp-core.h"
> #include "cdn-dp-reg.h"
> @@ -189,7 +191,7 @@ static int cdn_dp_mailbox_send(struct cdn_dp_device *dp, u8 module_id,
> return 0;
> }
>
> -static int cdn_dp_reg_write(struct cdn_dp_device *dp, u16 addr, u32 val)
> +int cdn_dp_reg_write(struct cdn_dp_device *dp, u16 addr, u32 val)
> {
> u8 msg[6];
>
> @@ -609,6 +611,31 @@ int cdn_dp_train_link(struct cdn_dp_device *dp)
> {
> int ret;
>
> + /*
> + * DP firmware uses fixed phy config values to do training, but some
> + * boards need to adjust these values to fit for their unique hardware
> + * design. So if the phy is using custom config values, do software
> + * link training instead of relying on firmware, if software training
> + * fail, keep firmware training as a fallback if sw training fails.
> + */
> + ret = cdn_dp_software_train_link(dp);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to do software training %d\n", ret);
> + goto do_fw_training;
> + }
> + ret = cdn_dp_reg_write(dp, SOURCE_HDTX_CAR, 0xf);
> + if (ret) {
> + DRM_DEV_ERROR(dp->dev,
> + "Failed to write SOURCE_HDTX_CAR register %d\n", ret);
> + goto do_fw_training;
> + }
> + dp->use_fw_training = false;
> + return 0;
> +
> +do_fw_training:
> + dp->use_fw_training = true;
> + DRM_DEV_DEBUG_KMS(dp->dev, "use fw training\n");
> ret = cdn_dp_training_start(dp);
> if (ret) {
> DRM_DEV_ERROR(dp->dev, "Failed to start training %d\n", ret);
> @@ -623,7 +650,7 @@ int cdn_dp_train_link(struct cdn_dp_device *dp)
>
> DRM_DEV_DEBUG_KMS(dp->dev, "rate:0x%x, lanes:%d\n", dp->link.rate,
> dp->link.num_lanes);
> - return ret;
> + return 0;
> }
>
> int cdn_dp_set_video_status(struct cdn_dp_device *dp, int active)
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.h b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> index 6580b11..3420771 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.h
> @@ -137,7 +137,7 @@
> #define HPD_EVENT_MASK 0x211c
> #define HPD_EVENT_DET 0x2120
>
> -/* dpyx framer addr */
> +/* dptx framer addr */
> #define DP_FRAMER_GLOBAL_CONFIG 0x2200
> #define DP_SW_RESET 0x2204
> #define DP_FRAMER_TU 0x2208
> @@ -431,6 +431,40 @@
> /* Reference cycles when using lane clock as reference */
> #define LANE_REF_CYC 0x8000
>
> +/* register CM_VID_CTRL */
> +#define LANE_VID_REF_CYC(x) (((x) & (BIT(24) - 1)) << 0)
> +#define NMVID_MEAS_TOLERANCE(x) (((x) & 0xf) << 24)
> +
> +/* register DP_TX_PHY_CONFIG_REG */
> +#define DP_TX_PHY_TRAINING_ENABLE(x) ((x) & 1)
> +#define DP_TX_PHY_TRAINING_TYPE_PRBS7 (0 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_TPS1 (1 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_TPS2 (2 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_TPS3 (3 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_TPS4 (4 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_PLTPAT (5 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_D10_2 (6 << 1)
> +#define DP_TX_PHY_TRAINING_TYPE_HBR2CPAT (8 << 1)
> +#define DP_TX_PHY_TRAINING_PATTERN(x) ((x) << 1)
> +#define DP_TX_PHY_SCRAMBLER_BYPASS(x) (((x) & 1) << 5)
> +#define DP_TX_PHY_ENCODER_BYPASS(x) (((x) & 1) << 6)
> +#define DP_TX_PHY_SKEW_BYPASS(x) (((x) & 1) << 7)
> +#define DP_TX_PHY_DISPARITY_RST(x) (((x) & 1) << 8)
> +#define DP_TX_PHY_LANE0_SKEW(x) (((x) & 7) << 9)
> +#define DP_TX_PHY_LANE1_SKEW(x) (((x) & 7) << 12)
> +#define DP_TX_PHY_LANE2_SKEW(x) (((x) & 7) << 15)
> +#define DP_TX_PHY_LANE3_SKEW(x) (((x) & 7) << 18)
> +#define DP_TX_PHY_10BIT_ENABLE(x) (((x) & 1) << 21)
> +
> +/* register DP_FRAMER_GLOBAL_CONFIG */
> +#define NUM_LANES(x) ((x) & 3)
> +#define SST_MODE (0 << 2)
> +#define RG_EN (0 << 4)
> +#define GLOBAL_EN BIT(3)
> +#define NO_VIDEO BIT(5)
> +#define ENC_RST_DIS BIT(6)
> +#define WR_VHSYNC_FALL BIT(7)
> +
> enum voltage_swing_level {
> VOLTAGE_LEVEL_0,
> VOLTAGE_LEVEL_1,
> @@ -476,6 +510,7 @@ 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_reg_write(struct cdn_dp_device *dp, u16 addr, u32 val);
> 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,
> @@ -489,4 +524,5 @@ int cdn_dp_config_video(struct cdn_dp_device *dp);
> int cdn_dp_audio_stop(struct cdn_dp_device *dp, struct audio_info *audio);
> int cdn_dp_audio_mute(struct cdn_dp_device *dp, bool enable);
> int cdn_dp_audio_config(struct cdn_dp_device *dp, struct audio_info *audio);
> +int cdn_dp_software_train_link(struct cdn_dp_device *dp);
> #endif /* _CDN_DP_REG_H */
> --
> 2.7.4
>
--
Sean Paul, Software Engineer, Google / Chromium OS
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Geert Uytterhoeven @ 2018-05-17 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOtvUMee+cn+=bEuB5iBiU9yeSsCiDPDwej8Uw-_3wVP4fagpA@mail.gmail.com>
Hi Gilad,
On Thu, May 17, 2018 at 3:41 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> On Thu, May 17, 2018 at 4:35 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>>> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
>>> <geert@linux-m68k.org> wrote:
>>>> However, even with your clock patch, the signature checking fails for me,
>>>> on both R-Car H3 ES1.0 and ES2.0.
>>>> Does this need changes to the ARM Trusted Firmware, to allow Linux to
>>>> access the public SCEG module?
>>>
>>> Well, this is actually something different. If you look you will
>>> notice that my patch was part of a 3 part patch series,
>>> the first of which disabled this test.
>>
>> Sorry, I had completely forgotten about the first patch from the series.
>> With that applied, it continues:
>>
>> ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version
>> 0x00000000, Driver version 4.0
>> ccree e6601000.crypto: Cache params previous: 0x00000777
>> ccree e6601000.crypto: Cache params current: 0x00000000
>> (expect: 0x00000000)
>> alg: No test for cts1(cbc(aes)) (cts1-cbc-aes-ccree)
>> alg: No test for authenc(xcbc(aes),cbc(aes))
>> (authenc-xcbc-aes-cbc-aes-ccree)
>> alg: No test for authenc(xcbc(aes),rfc3686(ctr(aes)))
>> (authenc-xcbc-aes-rfc3686-ctr-aes-ccree)
>> ccree e6601000.crypto: ARM ccree device initialized
>>
>> Is HW version 0x00000000 expected?
>
> It's related to the problem with reading the wrong register I've
> mentioned before.
OK.
>>> If you take all the 3 patches, it will work.
>>
>> is there an easy way to test proper operation?
>
> The lines of the form " alg: No test for cts1(cbc(aes))
> (cts1-cbc-aes-ccree)" indicates
> you have the Crypto API testmgr enable (or rather not disabled would
> be more accurate) so every
> cryptographic algorithm except those specified in these messages was
> tested with test
> vectors from crypto/testmgr.c upon registration. If you don't seen
> failure warnings, it works.
OK.
> You can also check /proc/crypto for all the algorithm with ccree
> listed as their driver and check
> that their test passed.
OK, in that case everything works as expected, on both R-Car H3 ES1.0 and
ES2.0.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Gilad Ben-Yossef @ 2018-05-17 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdX5quhZzaPkcrtB4CuHWeaKsyF1SustjB9V0SWw_SzXVg@mail.gmail.com>
On Thu, May 17, 2018 at 4:35 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Gilad,
>
> On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>>> However, even with your clock patch, the signature checking fails for me,
>>> on both R-Car H3 ES1.0 and ES2.0.
>>> Does this need changes to the ARM Trusted Firmware, to allow Linux to
>>> access the public SCEG module?
>>
>> Well, this is actually something different. If you look you will
>> notice that my patch was part of a 3 part patch series,
>> the first of which disabled this test.
>
> Sorry, I had completely forgotten about the first patch from the series.
> With that applied, it continues:
>
> ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version
> 0x00000000, Driver version 4.0
> ccree e6601000.crypto: Cache params previous: 0x00000777
> ccree e6601000.crypto: Cache params current: 0x00000000
> (expect: 0x00000000)
> alg: No test for cts1(cbc(aes)) (cts1-cbc-aes-ccree)
> alg: No test for authenc(xcbc(aes),cbc(aes))
> (authenc-xcbc-aes-cbc-aes-ccree)
> alg: No test for authenc(xcbc(aes),rfc3686(ctr(aes)))
> (authenc-xcbc-aes-rfc3686-ctr-aes-ccree)
> ccree e6601000.crypto: ARM ccree device initialized
>
> Is HW version 0x00000000 expected?
It's related to the problem with reading the wrong register I've
mentioned before.
>
>> If you take all the 3 patches, it will work.
>
> is there an easy way to test proper operation?
The lines of the form " alg: No test for cts1(cbc(aes))
(cts1-cbc-aes-ccree)" indicates
you have the Crypto API testmgr enable (or rather not disabled would
be more accurate) so every
cryptographic algorithm except those specified in these messages was
tested with test
vectors from crypto/testmgr.c upon registration. If you don't seen
failure warnings, it works.
You can also check /proc/crypto for all the algorithm with ccree
listed as their driver and check
that their test passed.
> I enabled CONFIG_CRYPT_TEST, and did insmod tcrypt.ko, but I mostly see
> "Failed to load transform" messages.
>
tcrypt.ko is a rather crude developer tool. It has hard coded lists of
test for different algorithms that does
not take into account if some crypto algs are enagled in the build or
not. It's more of a stress test.
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* [PATCH v3 07/12] ACPI / APEI: Make the nmi_fixmap_idx per-ghes to allow multiple in_nmi() users
From: Borislav Petkov @ 2018-05-17 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <39bde8c5-4dfb-c1b9-02a4-ba467539ea24@codeaurora.org>
On Wed, May 16, 2018 at 11:38:16AM -0400, Tyler Baicar wrote:
> I haven't seen a deadlock from that, but it looks possible. What if
> the ghes_proc() call in ghes_probe() is moved before the second switch
> statement? That way it is before the NMI/IRQ/poll is setup. At quick
> glance I think that should avoid the deadlock and still provide the
> functionality that call was added for. I can test that out if you all
> agree.
Makes sense but please audit it properly before doing the change. That
code is full of landmines and could use a proper scrubbing first.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH v3 07/12] ACPI / APEI: Make the nmi_fixmap_idx per-ghes to allow multiple in_nmi() users
From: Borislav Petkov @ 2018-05-17 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7c871e15-689c-226d-760d-dd92614de2e9@arm.com>
On Wed, May 16, 2018 at 03:51:14PM +0100, James Morse wrote:
> The first two overload existing architectural behavior, the third improves all
> this with a third standard option. Its the standard story!
:-)
> I thought this was safe because its just ghes_copy_tofrom_phys()s access to the
> fixmap slots that needs mutual exclusion.
>
> Polled and all the IRQ flavours are kept apart by the spin_lock_irqsave(), and
> the NMIs have their own fixmap entry. (This is fine until there is more than
> once source of NMI)
For example:
ghes_probe()
switch (generic->notify.type) {
...
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_add(ghes);
}
...
ghes_proc();
ghes_read_estatus();
spin_lock_irqsave(&ghes_ioremap_lock_irq, flags);
memcpy...
-> NMI
ghes_notify_nmi();
ghes_read_estatus();
..
if (in_nmi) {
raw_spin_lock(&ghes_ioremap_lock_nmi);
...
<- NMI
ghes->estatus from above, before the NMI fired, has gotten some nice
scribbling over. AFAICT.
Now, I don't know whether this can happen with the ARM facilities but if
they're NMI-like, I don't see why not.
Which means, that this code is not really reentrant and if should be
fixed to be callable from different contexts, then it should use private
buffers and be careful about locking.
Oh, and that
if (in_nmi)
lock()
else
lock_irqsave()
pattern is really yucky. And it is an explosion waiting to happen.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Geert Uytterhoeven @ 2018-05-17 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOtvUMdVNX_vBRofpc5rNiVL-a1NvWMDyWSOaXKYPkm57wkR_A@mail.gmail.com>
Hi Gilad,
On Thu, May 17, 2018 at 3:09 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> However, even with your clock patch, the signature checking fails for me,
>> on both R-Car H3 ES1.0 and ES2.0.
>> Does this need changes to the ARM Trusted Firmware, to allow Linux to
>> access the public SCEG module?
>
> Well, this is actually something different. If you look you will
> notice that my patch was part of a 3 part patch series,
> the first of which disabled this test.
Sorry, I had completely forgotten about the first patch from the series.
With that applied, it continues:
ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version
0x00000000, Driver version 4.0
ccree e6601000.crypto: Cache params previous: 0x00000777
ccree e6601000.crypto: Cache params current: 0x00000000
(expect: 0x00000000)
alg: No test for cts1(cbc(aes)) (cts1-cbc-aes-ccree)
alg: No test for authenc(xcbc(aes),cbc(aes))
(authenc-xcbc-aes-cbc-aes-ccree)
alg: No test for authenc(xcbc(aes),rfc3686(ctr(aes)))
(authenc-xcbc-aes-rfc3686-ctr-aes-ccree)
ccree e6601000.crypto: ARM ccree device initialized
Is HW version 0x00000000 expected?
> If you take all the 3 patches, it will work.
is there an easy way to test proper operation?
I enabled CONFIG_CRYPT_TEST, and did insmod tcrypt.ko, but I mostly see
"Failed to load transform" messages.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
* [PATCH V6 10/12] ARM: dts: ipq8074: Add peripheral nodes
From: kbuild test robot @ 2018-05-17 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526475004-10341-11-git-send-email-sricharan@codeaurora.org>
Hi Sricharan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.17-rc5]
[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/Sricharan-R/ARM-dts-ipq-updates-to-enable-a-few-peripherals/20180517-155124
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
Note: the linux-review/Sricharan-R/ARM-dts-ipq-updates-to-enable-a-few-peripherals/20180517-155124 HEAD 1e054800261138fd8f0f8f93340f5781ff622233 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
arch/arm64/boot/dts/qcom/ipq8074-hk01.dtb: ERROR (duplicate_label): /soc/pinctrl at 1000000/serial4_pinmux: Duplicate label 'serial_4_pins' on /soc/pinctrl at 1000000/serial4_pinmux and /soc/pinctrl at 1000000/serial4-pinmux
>> ERROR: Input tree has errors, aborting (use -f to force output)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 38151 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180517/78988781/attachment-0001.gz>
^ permalink raw reply
* Delivery Status Notification (Failure)
From: Pintu Kumar @ 2018-05-17 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOuPNLiZJrDveOHWwvJQ+JLg+j6FOk74oQBKaEq0oqY6w0ko=A@mail.gmail.com>
On Mon, May 14, 2018 at 7:58 PM, Pintu Kumar <pintu.ping@gmail.com> wrote:
>
> On Mon, May 14, 2018 at 6:41 PM, Lucas Stach <l.stach@pengutronix.de> wrote:
> > Am Montag, den 14.05.2018, 17:42 +0530 schrieb Pintu Kumar:
> >> Hi,
> >>
> >> Is there any work around possible to set IRQ affinity for some GPIO
> >> interrupt ?
> >> How to avoid CPU0 to receive the current GPIO interrupt ?
> >> How do we assign GPIO interrupts to any CPU other than CPU0 ?
> >> Is it possible to isolate CPU0 for a sometime, from my GPIO driver so
> >> that GPIO interrupt can be served by another CPU ?
> >>
> >> Need your inputs to decide whether it is still possible to set
> >> affinity for GPIO interrupt, or its impossible ?
> >
> > This is not possible. The GPIO IRQs are aggregated into one GPC/GIC IRQ
> > line per GPIO bank, so it is not possible to change affinity of a
> > single GPIO interrupt to another CPU.
>
> OK. Thanks for your confirmation.
>
> > Best we could do is change the
> > affinity of the whole bank,
>
Hi,
I found that the driver is responsible for setting GPIO bank in i.MX7:
https://elixir.bootlin.com/linux/v4.2/source/drivers/gpio/gpio-mxc.c
However I still dont know how to set the cpumask for one of the GPIO Bank.
>From this link, it seems it is possible to set affinity for a GPIO IRQ.
https://community.nxp.com/thread/303144
But when I try it form my GPIO138 (GPIO5_IO10) it did not help.
So, as you said, I wanted to change affinity for the whole GPIO bank and try it.
Please give me some pointers.
Thanks
> OK. How can we do this on the fly from my driver code.
> If you have any reference please let me know.
> This is required only for experimental purpose to prove the point to be mgmt.
> My idea is, from the driver, change the affinity of the whole bank.
> So, the GPIO interrupt can be delivered on to this specific CPU bank.
> Once I am done, I will revert back to the old bank.
> Please give me some hint on how to do this from my kernel module....
>
>
> > but given the limited usefulness of
> > something like that, nobody bothered to implement such a thing.
> >
> > Regards,
> > Lucas
> >
> >>
> >>
> >> On Fri, May 11, 2018 at 8:07 PM, Pintu Kumar <pintu.ping@gmail.com>
> >> wrote:
> >> > On Fri, May 11, 2018 at 6:34 PM, Lucas Stach <l.stach@pengutronix.d
> >> > e> wrote:
> >> > > Am Freitag, den 11.05.2018, 13:39 +0100 schrieb Russell King -
> >> > > ARM Linux:
> >> > > > On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote:
> >> > > > > Hi,
> >> > > > >
> >> > > > > I need one help.
> >> > > > > I am using i.MX7 Sabre board with kernel version 4.1.15
> >> > > > >
> >> > > > > Let's say I am interested in GPIO number: 21
> >> > > > > I wanted to set CPU affinity for particular GPIO->IRQ number,
> >> > > > > so I
> >> > > > > tried the below steps:
> >> > > > > root at 10:~# echo 21 > /sys/class/gpio/export
> >> > > > > root at 10:~# echo "rising" > /sys/class/gpio/gpio21/edge
> >> > > > > root at 10:~# cat /proc/interrupts | grep 21
> >> > > > > 47: 0 0 gpio-mxc 21 Edge gpiolib
> >> > > > > root at 10:~# cat /sys/class/gpio/gpio21/direction
> >> > > > > in
> >> > > > > root at 10:~# cat /proc/irq/47/smp_affinity
> >> > > > > 3
> >> > > > > root at 10:~# echo 2 > /proc/irq/47/smp_affinity
> >> > > > > -bash: echo: write error: Input/output error
> >> > > > >
> >> > > > > But I get input/output error.
> >> > > > > When I debug further, found that irq_can_set_affinity is
> >> > > > > returning 0:
> >> > > > > [ 0.000000] genirq: irq_can_set_affinity (0): balance: 1,
> >> > > > > irq_data.chip: a81b7e48, irq_set_affinity: (null)
> >> > > > > [ 0.000000] write_irq_affinity: FAIL
> >> > > > >
> >> > > > > I also tried first setting /proc/irq/default_smp_affinity to
> >> > > > > 2 (from 3).
> >> > > > > This change is working, but the smp_affinity setting for the
> >> > > > > new IRQ
> >> > > > > is not working.
> >> > > > >
> >> > > > > When I try to set smp_affinity for mmc0, then it works.
> >> > > > > # cat /proc/interrupts | grep mmc
> >> > > > > 295: 55 0 GPCV2 22 Edge mmc0
> >> > > > > 296: 0 0 GPCV2 23 Edge mmc1
> >> > > > > 297: 52 0 GPCV2 24 Edge mmc2
> >> > > > >
> >> > > > > root at 10:~# echo 2 > /proc/irq/295/smp_affinity
> >> > > > > root at 10:~#
> >> > > > >
> >> > > > >
> >> > > > > So, I wanted to know what are the conditions for which
> >> > > > > setting
> >> > > > > smp_affinity for an IRQ will work ?
> >> > > > >
> >> > > > > Is there any way by which I can set CPU affinity to a GPIO ->
> >> > > > > IRQ ?
> >> > > > > Whether, irq_set_affinity_hint() will work in this case ?
> >> > > >
> >> > > > IRQ affinity is only supported where interrupts are _directly_
> >> > > > wired to
> >> > > > the GIC. It's the GIC which does the interrupt steering to the
> >> > > > CPU
> >> > > > cores.
> >> > > >
> >> > > > Interrupts on downstream interrupt controllers (such as GPCV2)
> >> > > > have no
> >> > > > ability to be directed independently to other CPUs - the only
> >> > > > possible
> >> > > > way to change the mapping is to move _all_ interrupts on that
> >> > > > controller,
> >> > > > and any downstream chained interrupts at GIC level.
> >> > > >
> >> > > > Hence why Interrupt 295 has no irq_set_affinity function: there
> >> > > > is no way
> >> > > > for the interrupt controller itself to change the affinity of
> >> > > > the input
> >> > > > interrupt.
> >> > >
> >> > > The GPCv2 though is a secondary IRQ controller which has a 1:1
> >> > > mapping
> >> > > of its input IRQs to the upstream GIC IRQ lines. Affinity can
> >> > > thus be
> >> > > handled by forwarding the request to the GIC by
> >> > > irq_chip_set_affinity_parent().
> >> > >
> >> > > As this is handled correctly in the upstream kernel since the
> >> > > first
> >> > > commit introducing support for the GPCv2, it seems the issue is
> >> > > only
> >> > > present in some downstream kernel.
> >> > >
> >> >
> >> > OK. Thanks so much for your reply.
> >> >
> >> > I saw some of the drivers using irq_set_affinity_hint() to force
> >> > the
> >> > IRQ affinity to a particular CPU.
> >> > This is the sample:
> >> > {
> >> > cpumask_clear(mask);
> >> > cpumask_set_cpu(cpu, mask);
> >> > irq_set_affinity_hint(irq, mask);
> >> > }
> >> >
> >> > Whether this logic will work for a particular GPIO pin ?
> >> >
>
> >> >
> >> > > Regards,
> >> > > Lucas
^ permalink raw reply
* [PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
From: Sinan Kaya @ 2018-05-17 13:22 UTC (permalink / raw)
To: linux-arm-kernel
A host bridge is allowed to remap BAR addresses using _TRA attribute in
_CRS windows.
pci_bus 0000:00: root bus resource [mem 0x80100100000-0x8011fffffff window] (bus address [0x00100000-0x1fffffff])
pci 0000:02:00.0: reg 0x10: [mem 0x8011e000000-0x8011effffff]
When a VGA device is behind such a host bridge and the resource is
translated efifb driver is trying to do ioremap against bus address
rather than the resource address and is failing to probe.
efifb driver is having difficulty locating the base address from BAR
address when
efifb: probing for efifb
efifb: cannot reserve video memory at 0x1e000000
efifb: framebuffer at 0x1e000000, using 1920k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
Use the host bridge offset information to convert bus address to
resource address in the fixup.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/video/fbdev/efifb.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 46a4484..ea68d5c 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -428,6 +428,8 @@ static void efifb_fixup_resources(struct pci_dev *dev)
{
u64 base = screen_info.lfb_base;
u64 size = screen_info.lfb_size;
+ struct pci_bus_region region;
+ struct resource res;
int i;
if (efifb_pci_dev || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
@@ -439,6 +441,14 @@ static void efifb_fixup_resources(struct pci_dev *dev)
if (!base)
return;
+ region.start = base;
+ region.end = base + size - 1;
+ res.start = 0;
+ res.flags = IORESOURCE_MEM;
+ pcibios_bus_to_resource(dev->bus, &res, ®ion);
+ if (res.start)
+ base = res.start;
+
for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
struct resource *res = &dev->resource[i];
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Geert Uytterhoeven @ 2018-05-17 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVM55S7+PdnKusX-qkTxioc=0kQ6EGSbwv+kbLk5RCUYw@mail.gmail.com>
On Thu, May 17, 2018 at 12:16 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Thu, May 17, 2018 at 10:01 AM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>> On Wed, May 16, 2018 at 10:43 AM, Simon Horman <horms@verge.net.au> wrote:
>>> On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
>>>> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>>>> > Add bindings for CryptoCell instance in the SoC.
>>>> >
>>>> > Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>>>>
>>>> Thanks for your patch!
>>>>
>>>> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>>> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>>> > @@ -528,6 +528,14 @@
>>>> > status = "disabled";
>>>> > };
>>>> >
>>>> > + arm_cc630p: crypto at e6601000 {
>>>> > + compatible = "arm,cryptocell-630p-ree";
>>>> > + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
>>>> > + #interrupt-cells = <2>;
>>>>
>>>> I believe the #interrupt-cells property is not needed.
>>>>
>>>> > + reg = <0x0 0xe6601000 0 0x1000>;
>>>> > + clocks = <&cpg CPG_MOD 229>;
>
> Missing "power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;", as
> the Secure Engine is part of the CPG/MSSR clock domain (see below [*]).
And missing "resets = <&cpg 229>;", as the module is tied to the CPG/MSSR
reset controller.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
* [PATCH] arm: bcm2835: Add the PMU to the devicetree.
From: Eric Anholt @ 2018-05-17 13:17 UTC (permalink / raw)
To: linux-arm-kernel
The a53 and a7 counters seem to match up, so we advertise a7 so that
arm32 can probe.
Signed-off-by: Eric Anholt <eric@anholt.net>
---
arch/arm/boot/dts/bcm2837.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2837.dtsi b/arch/arm/boot/dts/bcm2837.dtsi
index 7704bb029605..1f5e5c782835 100644
--- a/arch/arm/boot/dts/bcm2837.dtsi
+++ b/arch/arm/boot/dts/bcm2837.dtsi
@@ -17,6 +17,12 @@
};
};
+ arm-pmu {
+ compatible = "arm,cortex-a53-pmu", "arm,cortex-a7-pmu";
+ interrupt-parent = <&local_intc>;
+ interrupts = <9 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupt-parent = <&local_intc>;
--
2.17.0
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Gilad Ben-Yossef @ 2018-05-17 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517090438.pqggltzkcdhzktsp@verge.net.au>
On Thu, May 17, 2018 at 12:04 PM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, May 17, 2018 at 11:01:57AM +0300, Gilad Ben-Yossef wrote:
>> On Wed, May 16, 2018 at 10:43 AM, Simon Horman <horms@verge.net.au> wrote:
>> > On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
>> >> Hi Gilad,
>> >>
>> >> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>> >> > Add bindings for CryptoCell instance in the SoC.
>> >> >
>> >> > Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>> >>
>> >> Thanks for your patch!
>> >>
>> >> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> >> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>> >> > @@ -528,6 +528,14 @@
>> >> > status = "disabled";
>> >> > };
>> >> >
>> >> > + arm_cc630p: crypto at e6601000 {
>> >> > + compatible = "arm,cryptocell-630p-ree";
>> >> > + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
>> >> > + #interrupt-cells = <2>;
>> >>
>> >> I believe the #interrupt-cells property is not needed.
>> >>
>> >> > + reg = <0x0 0xe6601000 0 0x1000>;
>> >> > + clocks = <&cpg CPG_MOD 229>;
>> >> > + };
>> >>
>> >> The rest looks good, but I cannot verify the register block.
>> >>
>> >> > +
>> >> > i2c3: i2c at e66d0000 {
>> >> > #address-cells = <1>;
>> >> > #size-cells = <0>;
>> >
>> > Thanks, I have applied this after dropping the #interrupt-cells property.
>>
>> Thanks you!
>>
>> Alas, it will not work without the clk patch (the previous one in the
>> series) so they need to be
>> taken or dropped together.
>
> I think its fine if it does not yet work.
> But not if its causes things that previously worked to stop working.
Based on the further discussion with Geert my recommendation is to
drop my patch for now,
take Geert CR clock patch and I will follow up next week with a v2
that fixes the clock
handing as discussed with Geert.
Many thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* [PATCH v2 02/40] iommu/sva: Bind process address spaces to devices
From: Jonathan Cameron @ 2018-05-17 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180511190641.23008-3-jean-philippe.brucker@arm.com>
On Fri, 11 May 2018 20:06:03 +0100
Jean-Philippe Brucker <jean-philippe.brucker@arm.com> wrote:
> Add bind() and unbind() operations to the IOMMU API. Bind() returns a
> PASID that drivers can program in hardware, to let their devices access an
> mm. This patch only adds skeletons for the device driver API, most of the
> implementation is still missing.
>
> IOMMU groups with more than one device aren't supported for SVA at the
> moment. There may be P2P traffic between devices within a group, which
> cannot be seen by an IOMMU (note that supporting PASID doesn't add any
> form of isolation with regard to P2P). Supporting groups would require
> calling bind() for all bound processes every time a device is added to a
> group, to perform sanity checks (e.g. ensure that new devices support
> PASIDs at least as big as those already allocated in the group).
Is it worth adding an explicit comment on this reasoning (or a minimal subset
of it) at the check for the number of devices in the group?
It's well laid out here, but might not be so obvious if someone is reading
the code in the future.
>It also
> means making sure that reserved ranges (IOMMU_RESV_*) of all devices are
> carved out of processes. This is already tricky with single devices, but
> becomes very difficult with groups. Since SVA-capable devices are expected
> to be cleanly isolated, and since we don't have any way to test groups or
> hot-plug, we only allow singular groups for now.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Otherwise, looks good to me.
>
> ---
> v1->v2: remove iommu_sva_bind/unbind_group
> ---
> drivers/iommu/iommu-sva.c | 27 +++++++++++++
> drivers/iommu/iommu.c | 83 +++++++++++++++++++++++++++++++++++++++
> include/linux/iommu.h | 37 +++++++++++++++++
> 3 files changed, 147 insertions(+)
>
> diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> index 8b4afb7c63ae..8d98f9c09864 100644
> --- a/drivers/iommu/iommu-sva.c
> +++ b/drivers/iommu/iommu-sva.c
> @@ -93,6 +93,8 @@ int iommu_sva_device_shutdown(struct device *dev)
> if (!domain)
> return -ENODEV;
>
> + __iommu_sva_unbind_dev_all(dev);
> +
> mutex_lock(&dev->iommu_param->lock);
> param = dev->iommu_param->sva_param;
> dev->iommu_param->sva_param = NULL;
> @@ -108,3 +110,28 @@ int iommu_sva_device_shutdown(struct device *dev)
> return 0;
> }
> EXPORT_SYMBOL_GPL(iommu_sva_device_shutdown);
> +
> +int __iommu_sva_bind_device(struct device *dev, struct mm_struct *mm,
> + int *pasid, unsigned long flags, void *drvdata)
> +{
> + return -ENOSYS; /* TODO */
> +}
> +EXPORT_SYMBOL_GPL(__iommu_sva_bind_device);
> +
> +int __iommu_sva_unbind_device(struct device *dev, int pasid)
> +{
> + return -ENOSYS; /* TODO */
> +}
> +EXPORT_SYMBOL_GPL(__iommu_sva_unbind_device);
> +
> +/**
> + * __iommu_sva_unbind_dev_all() - Detach all address spaces from this device
> + * @dev: the device
> + *
> + * When detaching @device from a domain, IOMMU drivers should use this helper.
> + */
> +void __iommu_sva_unbind_dev_all(struct device *dev)
> +{
> + /* TODO */
> +}
> +EXPORT_SYMBOL_GPL(__iommu_sva_unbind_dev_all);
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 9e28d88c8074..bd2819deae5b 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -2261,3 +2261,86 @@ int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids)
> return 0;
> }
> EXPORT_SYMBOL_GPL(iommu_fwspec_add_ids);
> +
> +/**
> + * iommu_sva_bind_device() - Bind a process address space to a device
> + * @dev: the device
> + * @mm: the mm to bind, caller must hold a reference to it
> + * @pasid: valid address where the PASID will be stored
> + * @flags: bond properties
> + * @drvdata: private data passed to the mm exit handler
> + *
> + * Create a bond between device and task, allowing the device to access the mm
> + * using the returned PASID. If unbind() isn't called first, a subsequent bind()
> + * for the same device and mm fails with -EEXIST.
> + *
> + * iommu_sva_device_init() must be called first, to initialize the required SVA
> + * features. @flags is a subset of these features.
> + *
> + * The caller must pin down using get_user_pages*() all mappings shared with the
> + * device. mlock() isn't sufficient, as it doesn't prevent minor page faults
> + * (e.g. copy-on-write).
> + *
> + * On success, 0 is returned and @pasid contains a valid ID. Otherwise, an error
> + * is returned.
> + */
> +int iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, int *pasid,
> + unsigned long flags, void *drvdata)
> +{
> + int ret = -EINVAL;
> + struct iommu_group *group;
> +
> + if (!pasid)
> + return -EINVAL;
> +
> + group = iommu_group_get(dev);
> + if (!group)
> + return -ENODEV;
> +
> + /* Ensure device count and domain don't change while we're binding */
> + mutex_lock(&group->mutex);
> + if (iommu_group_device_count(group) != 1)
> + goto out_unlock;
> +
> + ret = __iommu_sva_bind_device(dev, mm, pasid, flags, drvdata);
> +
> +out_unlock:
> + mutex_unlock(&group->mutex);
> + iommu_group_put(group);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_sva_bind_device);
> +
> +/**
> + * iommu_sva_unbind_device() - Remove a bond created with iommu_sva_bind_device
> + * @dev: the device
> + * @pasid: the pasid returned by bind()
> + *
> + * Remove bond between device and address space identified by @pasid. Users
> + * should not call unbind() if the corresponding mm exited (as the PASID might
> + * have been reallocated for another process).
> + *
> + * The device must not be issuing any more transaction for this PASID. All
> + * outstanding page requests for this PASID must have been flushed to the IOMMU.
> + *
> + * Returns 0 on success, or an error value
> + */
> +int iommu_sva_unbind_device(struct device *dev, int pasid)
> +{
> + int ret = -EINVAL;
> + struct iommu_group *group;
> +
> + group = iommu_group_get(dev);
> + if (!group)
> + return -ENODEV;
> +
> + mutex_lock(&group->mutex);
> + ret = __iommu_sva_unbind_device(dev, pasid);
> + mutex_unlock(&group->mutex);
> +
> + iommu_group_put(group);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(iommu_sva_unbind_device);
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 2efe7738bedb..da59c20c4f12 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -613,6 +613,10 @@ void iommu_fwspec_free(struct device *dev);
> int iommu_fwspec_add_ids(struct device *dev, u32 *ids, int num_ids);
> const struct iommu_ops *iommu_ops_from_fwnode(struct fwnode_handle *fwnode);
>
> +extern int iommu_sva_bind_device(struct device *dev, struct mm_struct *mm,
> + int *pasid, unsigned long flags, void *drvdata);
> +extern int iommu_sva_unbind_device(struct device *dev, int pasid);
> +
> #else /* CONFIG_IOMMU_API */
>
> struct iommu_ops {};
> @@ -932,12 +936,29 @@ static inline int iommu_sva_invalidate(struct iommu_domain *domain,
> return -EINVAL;
> }
>
> +static inline int iommu_sva_bind_device(struct device *dev,
> + struct mm_struct *mm, int *pasid,
> + unsigned long flags, void *drvdata)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int iommu_sva_unbind_device(struct device *dev, int pasid)
> +{
> + return -ENODEV;
> +}
> +
> #endif /* CONFIG_IOMMU_API */
>
> #ifdef CONFIG_IOMMU_SVA
> extern int iommu_sva_device_init(struct device *dev, unsigned long features,
> unsigned int max_pasid);
> extern int iommu_sva_device_shutdown(struct device *dev);
> +extern int __iommu_sva_bind_device(struct device *dev, struct mm_struct *mm,
> + int *pasid, unsigned long flags,
> + void *drvdata);
> +extern int __iommu_sva_unbind_device(struct device *dev, int pasid);
> +extern void __iommu_sva_unbind_dev_all(struct device *dev);
> #else /* CONFIG_IOMMU_SVA */
> static inline int iommu_sva_device_init(struct device *dev,
> unsigned long features,
> @@ -950,6 +971,22 @@ static inline int iommu_sva_device_shutdown(struct device *dev)
> {
> return -ENODEV;
> }
> +
> +static inline int __iommu_sva_bind_device(struct device *dev,
> + struct mm_struct *mm, int *pasid,
> + unsigned long flags, void *drvdata)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int __iommu_sva_unbind_device(struct device *dev, int pasid)
> +{
> + return -ENODEV;
> +}
> +
> +static inline void __iommu_sva_unbind_dev_all(struct device *dev)
> +{
> +}
> #endif /* CONFIG_IOMMU_SVA */
>
> #endif /* __LINUX_IOMMU_H */
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: r8a7795: add ccree binding
From: Gilad Ben-Yossef @ 2018-05-17 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVM55S7+PdnKusX-qkTxioc=0kQ6EGSbwv+kbLk5RCUYw@mail.gmail.com>
On Thu, May 17, 2018 at 1:16 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Gilad,
>
> On Thu, May 17, 2018 at 10:01 AM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>> On Wed, May 16, 2018 at 10:43 AM, Simon Horman <horms@verge.net.au> wrote:
>>> On Tue, May 15, 2018 at 04:50:44PM +0200, Geert Uytterhoeven wrote:
>>>> On Tue, May 15, 2018 at 2:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
>>>> > Add bindings for CryptoCell instance in the SoC.
>>>> >
>>>> > Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
>>>>
>>>> Thanks for your patch!
>>>>
>>>> > --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>>> > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
>>>> > @@ -528,6 +528,14 @@
>>>> > status = "disabled";
>>>> > };
>>>> >
>>>> > + arm_cc630p: crypto at e6601000 {
>>>> > + compatible = "arm,cryptocell-630p-ree";
>>>> > + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
>>>> > + #interrupt-cells = <2>;
>>>>
>>>> I believe the #interrupt-cells property is not needed.
>>>>
>>>> > + reg = <0x0 0xe6601000 0 0x1000>;
>>>> > + clocks = <&cpg CPG_MOD 229>;
>
> Missing "power-domains = <&sysc R8A7795_PD_ALWAYS_ON>;", as
> the Secure Engine is part of the CPG/MSSR clock domain (see below [*]).
Thank you. I didn't get this information from Renesas :-)
>
>>>> > + };
>>>>
>>>> The rest looks good, but I cannot verify the register block.
>>>>
>>>> > +
>>>> > i2c3: i2c at e66d0000 {
>>>> > #address-cells = <1>;
>>>> > #size-cells = <0>;
>>>
>>> Thanks, I have applied this after dropping the #interrupt-cells property.
>>
>> Thanks you!
>>
>> Alas, it will not work without the clk patch (the previous one in the
>> series) so they need to be
>> taken or dropped together.
>
> Indeed. From a quick glance, it looks like drivers/crypto/ccree/cc_driver.c
> does not distinguish between the absence of the clock property, and an
> actual error in getting the clock, and never considers any error a failure
> (incl. -PROBE_DEFER).
>
> As of_clk_get() returns -ENOENT for both a missing clock property and a
> missing clock, you should use (devm_)clk_get() instead, and distinguish
> between NULL (no clock property) and IS_ERR() (actual failure -> abort).
>
Thank you, this is very valuable. I will do as you suggested.
> Hence in the absence of the clock patch, the driver accesses the crypto
> engine while its module clock is turned off, leading to:
>
> ccree e6601000.crypto: Invalid CC signature: SIGNATURE=0x00000000
> != expected=0xDCC63000
>
> You must be lucky, though, usually you get an imprecise external abort
> later, crashing the whole system ;-)
>
> So I think this patch should be dropped for now.
>
> However, even with your clock patch, the signature checking fails for me,
> on both R-Car H3 ES1.0 and ES2.0.
> Does this need changes to the ARM Trusted Firmware, to allow Linux to
> access the public SCEG module?
Well, this is actually something different. If you look you will
notice that my patch was part of a 3 part patch series,
the first of which disabled this test.
If you take all the 3 patches, it will work.
To make things more interesting, I have since sending the patch
learned WHY the test does not work, so disabling
it is not needed - to make a long story short, I was reading the wrong
register that just happens to have the right value
in our FPGA based tests systems but does not in the real silicon
implementations.
But you are right - if the clock is not enabled and you are try to
read from the register the system does freeze.
I will send a fixed v2. based on your patch enabling the CR clock.
>
> [*] More on the subject of clock control:
> At least for Renesas SoCs, where the module is part of a clock domain, and
> can be controlled automatically by Runtime PM, you could drop the explicit
> clock control, and use Runtime PM instead
> (pm_runtime_{enable,get_sync,put,disable}()). That would allow the driver
> to work on systems with any kind of PM Domains, too.
> Depending on the other platforms that include a CryptoCell and their
> (non)reliance on PM Domains, you may have to keep the explicit clock
> handling, in addition to Runtime PM.
>
> To decrease power consumption, I suggest to move the clock and/or Runtime
> PM handling to the routines that actually use the hardware, instead of
> powering the module in the probe routine.
>
This is very interesting and I will give it a try.
Thanks again!
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* [GIT PULL 3/3] DaVinci defconfig updates for v4.18
From: Sekhar Nori @ 2018-05-17 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517130845.863-1-nsekhar@ti.com>
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/nsekhar/linux-davinci.git tags/davinci-for-v4.18/defconfig
for you to fetch changes up to e081c754ad4b8665364fcfb07b8bec5289f23dd8:
ARM: davinci_all_defconfig: enable support for remoteproc drivers (2018-04-23 20:24:23 +0530)
----------------------------------------------------------------
Enable DA8XX remoteproc driver support in davinci_all_defconfig
----------------------------------------------------------------
Bartosz Golaszewski (1):
ARM: davinci_all_defconfig: enable support for remoteproc drivers
arch/arm/configs/davinci_all_defconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
^ permalink raw reply
* [GIT PULL 2/3] DaVinci device-tree updates for v4.18
From: Sekhar Nori @ 2018-05-17 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517130845.863-1-nsekhar@ti.com>
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/nsekhar/linux-davinci.git tags/davinci-for-v4.18/dt
for you to fetch changes up to fe9d2a40d995dc1da042a4fcd7813239d063554d:
ARM: dts: da850-evm: add WP and CD to MMC (2018-05-16 16:36:51 +0530)
----------------------------------------------------------------
DaVinci device-tree updates for v4.18
* DA850 EVM gains USB support, SD card write-protect, card detect
and some clean-up
* Support for gpio-ranges makes using gpios from DT much easier
* Lego EV3 clean-up
----------------------------------------------------------------
Adam Ford (3):
ARM: dts: da850-evm: Enable usb_phy, usb0 and usb1
ARM: dts: da850-evm: use phandles to extend nodes
ARM: dts: da850-evm: add WP and CD to MMC
David Lechner (2):
ARM: dts: da850: use gpio-ranges
ARM: dts: da850-lego-ev3: remove unnecessary gpio-keys properties
arch/arm/boot/dts/da850-evm.dts | 298 +++++++++++++++++++----------------
arch/arm/boot/dts/da850-lego-ev3.dts | 83 +---------
arch/arm/boot/dts/da850.dtsi | 154 ++++++++++++++++++
3 files changed, 319 insertions(+), 216 deletions(-)
^ permalink raw reply
* [GIT PULL 1/3] DaVinci SoC updates for v4.18
From: Sekhar Nori @ 2018-05-17 13:08 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/nsekhar/linux-davinci.git tags/davinci-for-v4.18/soc
for you to fetch changes up to ccfadbb759bed3cc40336e2c486e619e3bf8590b:
Merge branch 'v4.18/nand-cs-simplification' into v4.18/soc (2018-05-02 15:04:15 +0530)
----------------------------------------------------------------
DaVinci SoC support updates for v4.18
Mainly contains patches to move NAND chipselect to platform data
(currently platform device id is being used). These patches have
been acked by NAND maintainer and because of the driver dependency
an immutable branch has been provided to Boris.
The other patch is to remove an unnecessary postcore_initcall() on
DM644x which is needed for common clock framework conversion.
----------------------------------------------------------------
Bartosz Golaszewski (12):
mtd: rawnand: davinci: store the core chipselect number in platform data
ARM: davinci: da830-evm: specify the chipselect in davinci_nand_pdata
ARM: davinci: da850-evm: specify the chipselect in davinci_nand_pdata
ARM: davinci: dm355-evm: specify the chipselect in davinci_nand_pdata
ARM: davinci: dm355-leopard: specify the chipselect in davinci_nand_pdata
ARM: davinci: dm365-evm: specify the chipselect in davinci_nand_pdata
ARM: davinci: dm644x-evm: specify the chipselect in davinci_nand_pdata
ARM: davinci: mityomapl138: specify the chipselect in davinci_nand_pdata
ARM: davinci: dm646x-evm: specify the chipselect in davinci_nand_pdata
ARM: davinci: neuros-osd2: specify the chipselect in davinci_nand_pdata
mtd: rawnand: davinci: stop using pdev->id as chipselect
ARM: davinci: aemif: stop using pdev->id as nand chipselect
Sekhar Nori (2):
ARM: davinci: dm644x: remove unnecessary postcore_initcall()
Merge branch 'v4.18/nand-cs-simplification' into v4.18/soc
arch/arm/mach-davinci/aemif.c | 8 ++++----
arch/arm/mach-davinci/board-da830-evm.c | 1 +
arch/arm/mach-davinci/board-da850-evm.c | 1 +
arch/arm/mach-davinci/board-dm355-evm.c | 1 +
arch/arm/mach-davinci/board-dm355-leopard.c | 1 +
arch/arm/mach-davinci/board-dm365-evm.c | 1 +
arch/arm/mach-davinci/board-dm644x-evm.c | 3 +++
arch/arm/mach-davinci/board-dm646x-evm.c | 1 +
arch/arm/mach-davinci/board-mityomapl138.c | 1 +
arch/arm/mach-davinci/board-neuros-osd2.c | 3 +++
arch/arm/mach-davinci/board-sffsdr.c | 2 ++
arch/arm/mach-davinci/davinci.h | 1 +
arch/arm/mach-davinci/dm644x.c | 13 +++----------
drivers/mtd/nand/raw/davinci_nand.c | 6 +++---
include/linux/platform_data/mtd-davinci.h | 10 ++++++++++
15 files changed, 36 insertions(+), 17 deletions(-)
^ permalink raw reply
* [RFC PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge
From: Sinan Kaya @ 2018-05-17 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74ae2347-464c-ddc1-3cb9-f928692e792f@arm.com>
On 5/17/2018 6:17 AM, Robin Murphy wrote:
>> +??? }
>> +
>
> Is this not pretty much just pcibios_bus_to_resource()?
>
Agreed, let me convert the code to use pcibios_bus_to_resource() API.
I wasn't aware of its existence.
> Robin.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 0/3] ASoC: stm32: sai: add support of iec958 controls
From: Olivier MOYSAN @ 2018-05-17 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180417111733.GG8973@sirena.org.uk>
Hello Takashi,
On 04/17/2018 01:17 PM, Mark Brown wrote:
> On Tue, Apr 17, 2018 at 08:29:17AM +0000, Olivier MOYSAN wrote:
>
>> I guess the blocking patch in this patchset is the patch "add IEC958
>> channel status control helper". This patch has been reviewed several
>> times, but did not get a ack so far.
>> If you think these helpers will not be merged, I will reintegrate the
>> corresponding code in stm driver.
>> Please let me know, if I need to prepare a v2 without helpers, or if we
>> can go further in the review of iec helpers patch ?
>
> I don't mind either way but you're right here, I'm waiting for Takashi
> to review the first patch. I'd probably be OK with it just integrated
> into the driver if we have to go that way though.
>
Kind reminder.
Would you have some comments on this patchset ?
Thanks
olivier
^ permalink raw reply
* [GIT PULL] ARM: mvebu: arm for v4.18 (#1)
From: Gregory CLEMENT @ 2018-05-17 12:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the first pull request for arm for mvebu for v4.18.
As I feared, there were (trivial) merge issues due to the defconfig
update in linux-next. The best place to solve them is in your tree, so
as soon as you will pull this, I will remove from my mvebu/for-next
branch.
Gregory
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.infradead.org/linux-mvebu.git tags/mvebu-arm-4.18-1
for you to fetch changes up to 95fbfe2f63d0838fed56d2f93604f205719bc51c:
ARM: multi_v7_defconfig: Add Marvell NAND controller support (2018-05-16 19:38:34 +0200)
----------------------------------------------------------------
mvebu arm for 4.18 (part 1)
Updating multi_v7_defconfig and adding marvell NAND controller
support.
----------------------------------------------------------------
Gregory CLEMENT (2):
ARM: multi_v7_defconfig: Update with current configuration
ARM: multi_v7_defconfig: Add Marvell NAND controller support
arch/arm/configs/multi_v7_defconfig | 369 +++++++++++++++---------------------
1 file changed, 153 insertions(+), 216 deletions(-)
^ permalink raw reply
* [PATCH 1/3] crypto: ccree: drop signature register check
From: Gilad Ben-Yossef @ 2018-05-17 12:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526387370-17142-2-git-send-email-gilad@benyossef.com>
Herbert,
On Tue, May 15, 2018 at 3:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> We were using the content of the signature register as a sanity
> check for the hardware functioning but it turns out not all
> implementers use the same values so the check is giving false
> negative on certain SoCs and so we drop it.
>
Please drop this patch. I have found a better fix and will send a v2 soon.
Thanks,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
-- Jean-Baptiste Queru
^ permalink raw reply
* [PATCH] KVM: arm/arm64: add WARN_ON if size is not PAGE_SIZE aligned in unmap_stage2_range
From: Jia He @ 2018-05-17 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <698b0355-d430-86b8-cd09-83c6d9e566f8@arm.com>
Hi Suzuki
On 5/17/2018 4:17 PM, Suzuki K Poulose Wrote:
>
> Hi Jia,
>
> On 17/05/18 07:11, Jia He wrote:
>> I ever met a panic under memory pressure tests(start 20 guests and run
>> memhog in the host).
>
> Please avoid using "I" in the commit description and preferably stick to
> an objective description.
Thanks for the pointing
>
>>
>> The root cause might be what I fixed at [1]. But from arm kvm points of
>> view, it would be better we caught the exception earlier and clearer.
>>
>> If the size is not PAGE_SIZE aligned, unmap_stage2_range might unmap the
>> wrong(more or less) page range. Hence it caused the "BUG: Bad page
>> state"
>
> I don't see why we should ever panic with a "positive" size value. Anyways,
> the unmap requests must be in units of pages. So this check might be useful.
>
>
good question,
After further digging, maybe we need to harden the break condition as below?
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 7f6a944..dac9b2e 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -217,7 +217,7 @@ static void unmap_stage2_ptes(struct kvm *kvm, pmd_t *pmd,
put_page(virt_to_page(pte));
}
- } while (pte++, addr += PAGE_SIZE, addr != end);
+ } while (pte++, addr += PAGE_SIZE, addr < end);
basically verified in my armv8a server
--
Cheers,
Jia
> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>
>>
>> [1] https://lkml.org/lkml/2018/5/3/1042
>>
>> Signed-off-by: jia.he at hxt-semitech.com
>> ---
>> ? virt/kvm/arm/mmu.c | 2 ++
>> ? 1 file changed, 2 insertions(+)
>>
>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>> index 7f6a944..8dac311 100644
>> --- a/virt/kvm/arm/mmu.c
>> +++ b/virt/kvm/arm/mmu.c
>> @@ -297,6 +297,8 @@ static void unmap_stage2_range(struct kvm *kvm,
>> phys_addr_t start, u64 size)
>> ????? phys_addr_t next;
>> ? ????? assert_spin_locked(&kvm->mmu_lock);
>> +??? WARN_ON(size & ~PAGE_MASK);
>> +
>> ????? pgd = kvm->arch.pgd + stage2_pgd_index(addr);
>> ????? do {
>> ????????? /*
>>
>
>
^ 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