* [PATCH 5/5] RFC: ARM64: dts: Add Low-Speed Connector to ZCU100
From: Linus Walleij @ 2018-06-18 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074556.6944-1-linus.walleij@linaro.org>
This adds the low-speed connector to the ZCU100 rev C device
tree (also known as the Ultra96 board).
This is a proof-of-concept only, showing how it is possible
to populate a Secure96 board using the other patches in the
series.
If you comment out or delete the board {} node, you can
populate/depopulate the board from sysfs instead.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
.../boot/dts/xilinx/zynqmp-zcu100-revC.dts | 27 +++++++++++++++++--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
index d62276e0e0a9..fc30497f248d 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
@@ -110,6 +110,28 @@
compatible = "mmc-pwrseq-simple";
reset-gpios = <&gpio 7 GPIO_ACTIVE_LOW>; /* WIFI_EN */
};
+
+ lscon: connector {
+ compatible = "96boards,low-speed-connector";
+ i2c0 = <&i2csw_0>;
+ i2c1 = <&i2csw_1>;
+ spi = <&spi0>;
+ gpios = <&gpio 36 GPIO_ACTIVE_HIGH>, /* GPIO-A */
+ <&gpio 37 GPIO_ACTIVE_HIGH>, /* GPIO-B */
+ <&gpio 39 GPIO_ACTIVE_HIGH>, /* GPIO-C */
+ <&gpio 40 GPIO_ACTIVE_HIGH>, /* GPIO-D */
+ <&gpio 44 GPIO_ACTIVE_HIGH>, /* GPIO-E */
+ <&gpio 45 GPIO_ACTIVE_HIGH>, /* GPIO-F */
+ <&gpio 78 GPIO_ACTIVE_HIGH>, /* GPIO-G */
+ <&gpio 79 GPIO_ACTIVE_HIGH>, /* GPIO-H */
+ <&gpio 80 GPIO_ACTIVE_HIGH>, /* GPIO-I */
+ <&gpio 81 GPIO_ACTIVE_HIGH>, /* GPIO-J */
+ <&gpio 82 GPIO_ACTIVE_HIGH>, /* GPIO-K */
+ <&gpio 83 GPIO_ACTIVE_HIGH>; /* GPIO-L */
+ board {
+ compatible = "96boards,secure96";
+ };
+ };
};
&dcc {
@@ -134,8 +156,9 @@
"USB1_DIR", "USB1_DATA2", "USB1_NXT", "USB1_DATA0", "USB1_DATA1",
"USB1_STP", "USB1_DATA3", "USB1_DATA4", "USB1_DATA5", "USB1_DATA6",
"USB_DATA7", "WLAN_IRQ", "PMIC_IRQ", /* MIO end and EMIO start */
- "", "",
- "", "", "", "", "", "", "", "", "", "",
+ "GPIO-G", "GPIO-H",
+ "GPIO-I", "GPIO-J", "GPIO-K", "GPIO-L",
+ "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "",
"", "", "", "", "", "", "", "", "", "",
--
2.17.0
^ permalink raw reply related
* [PATCH v3 24/27] devicetree: fix a series of wrong file references
From: Alexandre Torgue @ 2018-06-18 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bce1b59268ac2d659fd7cb37f89285ef2acc8316.1528990947.git.mchehab+samsung@kernel.org>
On 06/14/2018 06:09 PM, Mauro Carvalho Chehab wrote:
> As files got renamed, their references broke.
>
> Manually fix a series of broken refs at the DT bindings.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
For stm32 part:
Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>
Thanks
Alex
> .../devicetree/bindings/input/rmi4/rmi_2d_sensor.txt | 2 +-
> Documentation/devicetree/bindings/mfd/sun6i-prcm.txt | 2 +-
> .../devicetree/bindings/pci/hisilicon-pcie.txt | 2 +-
> Documentation/devicetree/bindings/pci/kirin-pcie.txt | 2 +-
> .../devicetree/bindings/pci/pci-keystone.txt | 4 ++--
> .../devicetree/bindings/sound/st,stm32-i2s.txt | 2 +-
> .../devicetree/bindings/sound/st,stm32-sai.txt | 2 +-
> MAINTAINERS | 12 ++++++------
> 8 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> index f2c30c8b725d..9afffbdf6e28 100644
> --- a/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> +++ b/Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt
> @@ -12,7 +12,7 @@ Additional documentation for F11 can be found at:
> http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
>
> Optional Touch Properties:
> -Description in Documentation/devicetree/bindings/input/touch
> +Description in Documentation/devicetree/bindings/input/touchscreen
> - touchscreen-inverted-x
> - touchscreen-inverted-y
> - touchscreen-swapped-x-y
> diff --git a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
> index 4d21ffdb0fc1..daa091c2e67b 100644
> --- a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
> +++ b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
> @@ -8,7 +8,7 @@ Required properties:
> - reg: The PRCM registers range
>
> The prcm node may contain several subdevices definitions:
> - - see Documentation/devicetree/clk/sunxi.txt for clock devices
> + - see Documentation/devicetree/bindings/clock/sunxi.txt for clock devices
> - see Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt for reset
> controller devices
>
> diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> index 7bf9df047a1e..0dcb87d6554f 100644
> --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> @@ -3,7 +3,7 @@ HiSilicon Hip05 and Hip06 PCIe host bridge DT description
> HiSilicon PCIe host controller is based on the Synopsys DesignWare PCI core.
> It shares common functions with the PCIe DesignWare core driver and inherits
> common properties defined in
> -Documentation/devicetree/bindings/pci/designware-pci.txt.
> +Documentation/devicetree/bindings/pci/designware-pcie.txt.
>
> Additional properties are described here:
>
> diff --git a/Documentation/devicetree/bindings/pci/kirin-pcie.txt b/Documentation/devicetree/bindings/pci/kirin-pcie.txt
> index 6e217c63123d..6bbe43818ad5 100644
> --- a/Documentation/devicetree/bindings/pci/kirin-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/kirin-pcie.txt
> @@ -3,7 +3,7 @@ HiSilicon Kirin SoCs PCIe host DT description
> Kirin PCIe host controller is based on the Synopsys DesignWare PCI core.
> It shares common functions with the PCIe DesignWare core driver and
> inherits common properties defined in
> -Documentation/devicetree/bindings/pci/designware-pci.txt.
> +Documentation/devicetree/bindings/pci/designware-pcie.txt.
>
> Additional properties are described here:
>
> diff --git a/Documentation/devicetree/bindings/pci/pci-keystone.txt b/Documentation/devicetree/bindings/pci/pci-keystone.txt
> index 7e05487544ed..3d4a209b0fd0 100644
> --- a/Documentation/devicetree/bindings/pci/pci-keystone.txt
> +++ b/Documentation/devicetree/bindings/pci/pci-keystone.txt
> @@ -3,9 +3,9 @@ TI Keystone PCIe interface
> Keystone PCI host Controller is based on the Synopsys DesignWare PCI
> hardware version 3.65. It shares common functions with the PCIe DesignWare
> core driver and inherits common properties defined in
> -Documentation/devicetree/bindings/pci/designware-pci.txt
> +Documentation/devicetree/bindings/pci/designware-pcie.txt
>
> -Please refer to Documentation/devicetree/bindings/pci/designware-pci.txt
> +Please refer to Documentation/devicetree/bindings/pci/designware-pcie.txt
> for the details of DesignWare DT bindings. Additional properties are
> described here as well as properties that are not applicable.
>
> diff --git a/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt b/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt
> index 4bda52042402..58c341300552 100644
> --- a/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt
> +++ b/Documentation/devicetree/bindings/sound/st,stm32-i2s.txt
> @@ -18,7 +18,7 @@ Required properties:
> See Documentation/devicetree/bindings/dma/stm32-dma.txt.
> - dma-names: Identifier for each DMA request line. Must be "tx" and "rx".
> - pinctrl-names: should contain only value "default"
> - - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/pinctrl-stm32.txt
> + - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
>
> Optional properties:
> - resets: Reference to a reset controller asserting the reset controller
> diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt
> index f301cdf0b7e6..3a3fc506e43a 100644
> --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt
> +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt
> @@ -37,7 +37,7 @@ SAI subnodes required properties:
> "tx": if sai sub-block is configured as playback DAI
> "rx": if sai sub-block is configured as capture DAI
> - pinctrl-names: should contain only value "default"
> - - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/pinctrl-stm32.txt
> + - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt
>
> SAI subnodes Optional properties:
> - st,sync: specify synchronization mode.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 67641f5bb373..69c9e9924902 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6965,7 +6965,7 @@ IIO MULTIPLEXER
> M: Peter Rosin <peda@axentia.se>
> L: linux-iio at vger.kernel.org
> S: Maintained
> -F: Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
> +F: Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
> F: drivers/iio/multiplexer/iio-mux.c
>
> IIO SUBSYSTEM AND DRIVERS
> @@ -9695,7 +9695,7 @@ MXSFB DRM DRIVER
> M: Marek Vasut <marex@denx.de>
> S: Supported
> F: drivers/gpu/drm/mxsfb/
> -F: Documentation/devicetree/bindings/display/mxsfb-drm.txt
> +F: Documentation/devicetree/bindings/display/mxsfb.txt
>
> MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE)
> M: Chris Lee <christopher.lee@cspi.com>
> @@ -10884,7 +10884,7 @@ M: Will Deacon <will.deacon@arm.com>
> L: linux-pci at vger.kernel.org
> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> -F: Documentation/devicetree/bindings/pci/controller-generic-pci.txt
> +F: Documentation/devicetree/bindings/pci/host-generic-pci.txt
> F: drivers/pci/controller/pci-host-common.c
> F: drivers/pci/controller/pci-host-generic.c
>
> @@ -11065,7 +11065,7 @@ M: Xiaowei Song <songxiaowei@hisilicon.com>
> M: Binghui Wang <wangbinghui@hisilicon.com>
> L: linux-pci at vger.kernel.org
> S: Maintained
> -F: Documentation/devicetree/bindings/pci/pcie-kirin.txt
> +F: Documentation/devicetree/bindings/pci/kirin-pcie.txt
> F: drivers/pci/controller/dwc/pcie-kirin.c
>
> PCIE DRIVER FOR HISILICON STB
> @@ -12456,7 +12456,7 @@ L: linux-crypto at vger.kernel.org
> L: linux-samsung-soc at vger.kernel.org
> S: Maintained
> F: drivers/crypto/exynos-rng.c
> -F: Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt
> +F: Documentation/devicetree/bindings/rng/samsung,exynos4-rng.txt
>
> SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER
> M: ?ukasz Stelmach <l.stelmach@samsung.com>
> @@ -13570,7 +13570,7 @@ F: drivers/*/stm32-*timer*
> F: drivers/pwm/pwm-stm32*
> F: include/linux/*/stm32-*tim*
> F: Documentation/ABI/testing/*timer-stm32
> -F: Documentation/devicetree/bindings/*/stm32-*timer
> +F: Documentation/devicetree/bindings/*/stm32-*timer*
> F: Documentation/devicetree/bindings/pwm/pwm-stm32*
>
> STMMAC ETHERNET DRIVER
>
^ permalink raw reply
* [PATCH v4 0/3] Add controls for VP8/VP9 profile
From: Keiichi Watanabe @ 2018-06-18 7:58 UTC (permalink / raw)
To: linux-arm-kernel
Here is the 4th revision of the patch set that adds controls for VP8/VP9
profiles. Please see v3 cover letter for more details.
<https://lkml.org/lkml/2018/6/14/132>
In this version, I changed the contents that pointed out by Stanimir and Hans.
Changelog
----------
Version 4 changes:
- Remove unnecessary changes in venus drivers.
- Remove unnecessary blank lines in documentations.
- Fix typo and grammar mistakes.
Version 3 changes:
- Add V4L2_CID_MPEG_VIDEO_VP8_PROFILE in v4l2-controls.
- Make V4L2_CID_MPEG_VIDEO_VPX_PROFILE to be an alias of
V4L2_CID_MPEG_VIDEO_VP8_PROFILE.
- Fix the use of V4L2_CID_MPEG_VIDEO_VPX_PROFILE in venus/s5p_mfc drivers.
- Small fix in mtk_vcodec_dec.
Version 2 changes:
- Support V4L2_CID_MPEG_VIDEO_VP9_PROFILE in MediaTek decoder's driver.
Version 1 changes:
- Add V4L2_CID_MPEG_VIDEO_VP9_PROFILE in v4l2-controls.
Keiichi Watanabe (3):
media: v4l2-ctrl: Change control for VP8 profile to menu control
media: v4l2-ctrl: Add control for VP9 profile
media: mtk-vcodec: Support VP9 profile in decoder
.../media/uapi/v4l/extended-controls.rst | 48 +++++++++++++++++--
.../platform/mtk-vcodec/mtk_vcodec_dec.c | 5 ++
.../media/platform/qcom/venus/vdec_ctrls.c | 10 ++--
drivers/media/platform/qcom/venus/venc.c | 4 +-
.../media/platform/qcom/venus/venc_ctrls.c | 10 ++--
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 15 +++---
drivers/media/v4l2-core/v4l2-ctrls.c | 23 ++++++++-
include/uapi/linux/v4l2-controls.h | 18 ++++++-
8 files changed, 110 insertions(+), 23 deletions(-)
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply
* [PATCH v4 1/3] media: v4l2-ctrl: Change control for VP8 profile to menu control
From: Keiichi Watanabe @ 2018-06-18 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618075854.12881-1-keiichiw@chromium.org>
Add a menu control V4L2_CID_MPEG_VIDEO_VP8_PROFILE for VP8 profile and make
V4L2_CID_MPEG_VIDEO_VPX_PROFILE an alias of it. This new control is used to
select the desired profile for VP8 encoder and query for supported profiles by
VP8 encoder/decoder.
Though we have originally a control V4L2_CID_MPEG_VIDEO_VPX_PROFILE and its name
contains 'VPX', it works only for VP8 because supported profiles usually differ
between VP8 and VP9. In addition, this control cannot be used for querying since
it is not a menu control but an integer control, which cannot return an
arbitrary set of supported profiles.
The new control V4L2_CID_MPEG_VIDEO_VP8_PROFILE is a menu control as with
controls for other codec profiles. (e.g. H264)
In addition, this patch also fixes the use of V4L2_CID_MPEG_VIDEO_VPX_PROFILE in
drivers of Qualcomm's venus and Samsung's s5p-mfc.
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
---
.../media/uapi/v4l/extended-controls.rst | 25 ++++++++++++++++---
.../media/platform/qcom/venus/vdec_ctrls.c | 10 +++++---
drivers/media/platform/qcom/venus/venc.c | 4 +--
.../media/platform/qcom/venus/venc_ctrls.c | 10 +++++---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 15 ++++++-----
drivers/media/v4l2-core/v4l2-ctrls.c | 12 ++++++++-
include/uapi/linux/v4l2-controls.h | 11 +++++++-
7 files changed, 64 insertions(+), 23 deletions(-)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
index 03931f9b1285..01ef31a934b4 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1955,9 +1955,28 @@ enum v4l2_vp8_golden_frame_sel -
``V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (integer)``
Quantization parameter for a P frame for VP8.
-``V4L2_CID_MPEG_VIDEO_VPX_PROFILE (integer)``
- Select the desired profile for VPx encoder. Acceptable values are 0,
- 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
+.. _v4l2-mpeg-video-vp8-profile:
+
+``V4L2_CID_MPEG_VIDEO_VP8_PROFILE``
+ (enum)
+
+enum v4l2_mpeg_video_vp8_profile -
+ This control allows selecting the profile for VP8 encoder.
+ This is also used to enumerate supported profiles by VP8 encoder or decoder.
+ Possible values are:
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_0``
+ - Profile 0
+ * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_1``
+ - Profile 1
+ * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_2``
+ - Profile 2
+ * - ``V4L2_MPEG_VIDEO_VP8_PROFILE_3``
+ - Profile 3
High Efficiency Video Coding (HEVC/H.265) Control Reference
diff --git a/drivers/media/platform/qcom/venus/vdec_ctrls.c b/drivers/media/platform/qcom/venus/vdec_ctrls.c
index 032839bbc967..f4604b0cd57e 100644
--- a/drivers/media/platform/qcom/venus/vdec_ctrls.c
+++ b/drivers/media/platform/qcom/venus/vdec_ctrls.c
@@ -29,7 +29,7 @@ static int vdec_op_s_ctrl(struct v4l2_ctrl *ctrl)
break;
case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
ctr->profile = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_H264_LEVEL:
@@ -54,7 +54,7 @@ static int vdec_op_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
switch (ctrl->id) {
case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
case V4L2_CID_MPEG_VIDEO_MPEG4_PROFILE:
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
ret = hfi_session_get_property(inst, ptype, &hprop);
if (!ret)
ctr->profile = hprop.profile_level.profile;
@@ -130,8 +130,10 @@ int vdec_ctrl_init(struct venus_inst *inst)
if (ctrl)
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
- ctrl = v4l2_ctrl_new_std(&inst->ctrl_handler, &vdec_ctrl_ops,
- V4L2_CID_MPEG_VIDEO_VPX_PROFILE, 0, 3, 1, 0);
+ ctrl = v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &vdec_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_3,
+ 0, V4L2_MPEG_VIDEO_VP8_PROFILE_0);
if (ctrl)
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
diff --git a/drivers/media/platform/qcom/venus/venc.c b/drivers/media/platform/qcom/venus/venc.c
index 6b2ce479584e..cba6ef1e2d04 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -223,7 +223,7 @@ static int venc_v4l2_to_hfi(int id, int value)
case V4L2_MPEG_VIDEO_H264_ENTROPY_MODE_CABAC:
return HFI_H264_ENTROPY_CABAC;
}
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
switch (value) {
case 0:
default:
@@ -756,7 +756,7 @@ static int venc_set_properties(struct venus_inst *inst)
level = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_H264_LEVEL,
ctr->level.h264);
} else if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_VP8) {
- profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_VPX_PROFILE,
+ profile = venc_v4l2_to_hfi(V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
ctr->profile.vpx);
level = 0;
} else if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_MPEG4) {
diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c b/drivers/media/platform/qcom/venus/venc_ctrls.c
index 21e938a28662..459101728d26 100644
--- a/drivers/media/platform/qcom/venus/venc_ctrls.c
+++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
@@ -101,7 +101,7 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_H264_PROFILE:
ctr->profile.h264 = ctrl->val;
break;
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
ctr->profile.vpx = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_MPEG4_LEVEL:
@@ -248,6 +248,11 @@ int venc_ctrl_init(struct venus_inst *inst)
V4L2_MPEG_VIDEO_MULTI_SICE_MODE_MAX_BYTES,
0, V4L2_MPEG_VIDEO_MULTI_SLICE_MODE_SINGLE);
+ v4l2_ctrl_new_std_menu(&inst->ctrl_handler, &venc_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_3,
+ 0, V4L2_MPEG_VIDEO_VP8_PROFILE_0);
+
v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
V4L2_CID_MPEG_VIDEO_BITRATE, BITRATE_MIN, BITRATE_MAX,
BITRATE_STEP, BITRATE_DEFAULT);
@@ -256,9 +261,6 @@ int venc_ctrl_init(struct venus_inst *inst)
V4L2_CID_MPEG_VIDEO_BITRATE_PEAK, BITRATE_MIN, BITRATE_MAX,
BITRATE_STEP, BITRATE_DEFAULT_PEAK);
- v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
- V4L2_CID_MPEG_VIDEO_VPX_PROFILE, 0, 3, 1, 0);
-
v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops,
V4L2_CID_MPEG_VIDEO_H264_I_FRAME_QP, 1, 51, 1, 26);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 570f391f2cfd..3ad4f5073002 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -692,12 +692,12 @@ static struct mfc_control controls[] = {
.default_value = 10,
},
{
- .id = V4L2_CID_MPEG_VIDEO_VPX_PROFILE,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .minimum = 0,
- .maximum = 3,
- .step = 1,
- .default_value = 0,
+ .id = V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
+ .type = V4L2_CTRL_TYPE_MENU,
+ .minimum = V4L2_MPEG_VIDEO_VP8_PROFILE_0,
+ .maximum = V4L2_MPEG_VIDEO_VP8_PROFILE_3,
+ .default_value = V4L2_MPEG_VIDEO_VP8_PROFILE_0,
+ .menu_skip_mask = 0,
},
{
.id = V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP,
@@ -2057,7 +2057,7 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:
p->codec.vp8.rc_p_frame_qp = ctrl->val;
break;
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
p->codec.vp8.profile = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:
@@ -2711,4 +2711,3 @@ void s5p_mfc_enc_init(struct s5p_mfc_ctx *ctx)
f.fmt.pix_mp.pixelformat = DEF_DST_FMT_ENC;
ctx->dst_fmt = find_format(&f, MFC_FMT_ENC);
}
-
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index d29e45516eb7..e7e6340b395e 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -431,6 +431,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Use Previous Specific Frame",
NULL,
};
+ static const char * const vp8_profile[] = {
+ "0",
+ "1",
+ "2",
+ "3",
+ NULL,
+ };
static const char * const flash_led_mode[] = {
"Off",
@@ -614,6 +621,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
return vpx_golden_frame_sel;
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
+ return vp8_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
case V4L2_CID_DV_TX_MODE:
@@ -839,7 +848,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_MAX_QP: return "VPX Maximum QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP: return "VPX I-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP: return "VPX P-Frame QP Value";
- case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX Profile";
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE: return "VP8 Profile";
/* HEVC controls */
case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value";
@@ -1180,6 +1189,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
case V4L2_CID_DEINTERLACING_MODE:
case V4L2_CID_TUNE_DEEMPHASIS:
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
+ case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
case V4L2_CID_DETECT_MD_MODE:
case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 8d473c979b61..2001823c3072 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -587,7 +587,16 @@ enum v4l2_vp8_golden_frame_sel {
#define V4L2_CID_MPEG_VIDEO_VPX_MAX_QP (V4L2_CID_MPEG_BASE+508)
#define V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP (V4L2_CID_MPEG_BASE+509)
#define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (V4L2_CID_MPEG_BASE+510)
-#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE (V4L2_CID_MPEG_BASE+511)
+
+#define V4L2_CID_MPEG_VIDEO_VP8_PROFILE (V4L2_CID_MPEG_BASE+511)
+enum v4l2_mpeg_video_vp8_profile {
+ V4L2_MPEG_VIDEO_VP8_PROFILE_0 = 0,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_1 = 1,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_2 = 2,
+ V4L2_MPEG_VIDEO_VP8_PROFILE_3 = 3,
+};
+/* Deprecated alias for compatibility reasons. */
+#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE V4L2_CID_MPEG_VIDEO_VP8_PROFILE
/* CIDs for HEVC encoding. */
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v4 2/3] media: v4l2-ctrl: Add control for VP9 profile
From: Keiichi Watanabe @ 2018-06-18 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618075854.12881-1-keiichiw@chromium.org>
Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for VP9 profiles. This control
allows selecting the desired profile for VP9 encoder and querying for supported
profiles by VP9 encoder/decoder.
Though this control is similar to V4L2_CID_MPEG_VIDEO_VP8_PROFILE, we need to
separate this control from it because supported profiles usually differ between
VP8 and VP9.
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
---
.../media/uapi/v4l/extended-controls.rst | 23 +++++++++++++++++++
drivers/media/v4l2-core/v4l2-ctrls.c | 11 +++++++++
include/uapi/linux/v4l2-controls.h | 7 ++++++
3 files changed, 41 insertions(+)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst b/Documentation/media/uapi/v4l/extended-controls.rst
index 01ef31a934b4..9f7312bf3365 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1978,6 +1978,29 @@ enum v4l2_mpeg_video_vp8_profile -
* - ``V4L2_MPEG_VIDEO_VP8_PROFILE_3``
- Profile 3
+.. _v4l2-mpeg-video-vp9-profile:
+
+``V4L2_CID_MPEG_VIDEO_VP9_PROFILE``
+ (enum)
+
+enum v4l2_mpeg_video_vp9_profile -
+ This control allows selecting the profile for VP9 encoder.
+ This is also used to enumerate supported profiles by VP9 encoder or decoder.
+ Possible values are:
+
+.. flat-table::
+ :header-rows: 0
+ :stub-columns: 0
+
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_0``
+ - Profile 0
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_1``
+ - Profile 1
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_2``
+ - Profile 2
+ * - ``V4L2_MPEG_VIDEO_VP9_PROFILE_3``
+ - Profile 3
+
High Efficiency Video Coding (HEVC/H.265) Control Reference
-----------------------------------------------------------
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index e7e6340b395e..eacfab7574dc 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -438,6 +438,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"3",
NULL,
};
+ static const char * const vp9_profile[] = {
+ "0",
+ "1",
+ "2",
+ "3",
+ NULL,
+ };
static const char * const flash_led_mode[] = {
"Off",
@@ -623,6 +630,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return vpx_golden_frame_sel;
case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
return vp8_profile;
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
+ return vp9_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
case V4L2_CID_DV_TX_MODE:
@@ -849,6 +858,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_I_FRAME_QP: return "VPX I-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP: return "VPX P-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VP8_PROFILE: return "VP8 Profile";
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE: return "VP9 Profile";
/* HEVC controls */
case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value";
@@ -1190,6 +1200,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
case V4L2_CID_TUNE_DEEMPHASIS:
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
case V4L2_CID_MPEG_VIDEO_VP8_PROFILE:
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
case V4L2_CID_DETECT_MD_MODE:
case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 2001823c3072..f03d3214eec2 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -597,6 +597,13 @@ enum v4l2_mpeg_video_vp8_profile {
};
/* Deprecated alias for compatibility reasons. */
#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE V4L2_CID_MPEG_VIDEO_VP8_PROFILE
+#define V4L2_CID_MPEG_VIDEO_VP9_PROFILE (V4L2_CID_MPEG_BASE+512)
+enum v4l2_mpeg_video_vp9_profile {
+ V4L2_MPEG_VIDEO_VP9_PROFILE_0 = 0,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_1 = 1,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_2 = 2,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_3 = 3,
+};
/* CIDs for HEVC encoding. */
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH v4 3/3] media: mtk-vcodec: Support VP9 profile in decoder
From: Keiichi Watanabe @ 2018-06-18 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618075854.12881-1-keiichiw@chromium.org>
Add V4L2_CID_MPEG_VIDEO_VP9_PROFILE control in MediaTek decoder's
driver. MediaTek decoder only supports profile 0 for now.
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 86f0a7134365..ba986232b953 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -1400,6 +1400,11 @@ int mtk_vcodec_dec_ctrls_setup(struct mtk_vcodec_ctx *ctx)
V4L2_CID_MIN_BUFFERS_FOR_CAPTURE,
0, 32, 1, 1);
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
+ v4l2_ctrl_new_std_menu(&ctx->ctrl_hdl,
+ &mtk_vcodec_dec_ctrl_ops,
+ V4L2_CID_MPEG_VIDEO_VP9_PROFILE,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_0,
+ 0, V4L2_MPEG_VIDEO_VP9_PROFILE_0);
if (ctx->ctrl_hdl.error) {
mtk_v4l2_err("Adding control failed %d",
--
2.18.0.rc1.244.gcf134e6275-goog
^ permalink raw reply related
* [PATCH 4.16 178/279] spi: bcm2835aux: ensure interrupts are enabled for shared handler
From: Greg Kroah-Hartman @ 2018-06-18 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618080608.851973560@linuxfoundation.org>
4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rob Herring <robh@kernel.org>
[ Upstream commit bc519d9574618e47a0c788000fb78da95e18d953 ]
The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
DT change which breaks compatibility with older kernels. The AUX irqchip
was already rejected for upstream[1] and the DT change would break
working systems if the DTB is updated to a newer one. The latter issue
was brought to my attention by Alex Graf.
The root cause however is a bug in the shared handler. Shared handlers
must check that interrupts are actually enabled before servicing the
interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled.
[1] https://patchwork.kernel.org/patch/9781221/
Cc: Alexander Graf <agraf@suse.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list at broadcom.com
Cc: linux-spi at vger.kernel.org
Cc: linux-rpi-kernel at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/spi/spi-bcm2835aux.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -184,6 +184,11 @@ static irqreturn_t bcm2835aux_spi_interr
struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
irqreturn_t ret = IRQ_NONE;
+ /* IRQ may be shared, so return if our interrupts are disabled */
+ if (!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_CNTL1) &
+ (BCM2835_AUX_SPI_CNTL1_TXEMPTY | BCM2835_AUX_SPI_CNTL1_IDLE)))
+ return ret;
+
/* check if we have data to read */
while (bs->rx_len &&
(!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_STAT) &
^ permalink raw reply
* [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm
From: Stefan Agner @ 2018-06-18 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074320.GS3438@phenom.ffwll.local>
On 18.06.2018 09:43, Daniel Vetter wrote:
> On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote:
>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>> > On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>> >> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>> >>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>> >>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>> >>>> <leonard.crestez@nxp.com> wrote:
>> >
>> >>>>> The FBDEV driver uses the same name and both can't be registered at the
>> >>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>> >>>>
>> >>>> Stefan sent the same patch a few days ago:
>> >>>
>> >>> In that thread there is a proposal for removing the old fbdev/mxsfb
>> >>> driver entirely.
>> >>>
>> >>> That would break old DTBs, isn't this generally considered bad? Also,
>> >>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>> >>>
>> >>> What my series does is make both drivers work with the same kernel
>> >>> image and turns the choice into a board-level dtb decision. Supporting
>> >>> everything at once seems desirable to me and it allows for a very
>> >>> smooth upgrade path.
>> >>
>> >> Having two drivers in the kernel with different set of bugs is always bad.
>> >>
>> >>> The old driver could be removed later, after all users are converted.
>> >>
>> >> Both drivers were in for long enough already. And let's be realistic,
>> >> how many MX23/MX28 users of old DTs with new kernels are there who
>> >> cannot update the DT as well ?
>> >
>> > Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>> > bindings are also used by 3rd-party boards for imx6/7:
>> > * imx6sx-nitrogen6sx
>> > * imx6ul-geam
>> > * imx6ul-isiot
>> > * imx6ul-opos6uldev
>> > * imx6ul-pico-hobbit
>> > * imx6ul-tx6ul
>> > * imx7d-nitrogen7
>>
>> Er, yes, a handful of boards which could be updated :)
>>
>> > Converting everything might be quite a bit of work, and explicitly
>> > supporting old bindings is also work.
>>
>> Does adding support for old bindings justify the effort invested ? I
>> doubt so, it only adds more code to maintain.
>>
>> > It is very confusing that there is a whole set of displays for imx6/7
>> > which are supported by upstream but only with a non-default config.
>> > While it is extremely common in the embedded field to have custom
>> > configs the default one in the kernel should try to "just work".
>> >
>> > Couldn't this patch series be considered a bugfix? It was also
>> > surprisingly small.
>>
>> I think it's just a workaround which allows you to postpone the real
>> fix, and I don't like that.
>
> Yeah agreed, imo the proper fix here would be to either update the dts for
> the affected boards and/or make mxsfb accept the old dt bindings for
> backwards compat. Artificially extending the life of the fbdev drivers
> seems silly.
We shouldn't have merged a DRM driver with a driver name which conflicts
with an existing driver... If anything, this is artificially shortening
the lifetime of the fbdev driver :-)
Again, I am ok with removing the driver. I just think it is silly to do
it just because of the conflicting driver name.
Maybe Sascha, original author of the mxs fbdev driver has an opinion on
this?
--
Stefan
^ permalink raw reply
* [PATCH 4.16 222/279] perf cs-etm: Support unknown_thread in cs_etm_auxtrace
From: Greg Kroah-Hartman @ 2018-06-18 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618080608.851973560@linuxfoundation.org>
4.16-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leo Yan <leo.yan@linaro.org>
[ Upstream commit 46d53620044f7b574c0f3216f8b4f2ce3559ce31 ]
CoreSight doesn't allocate thread structure for unknown_thread in ETM
auxtrace, so unknown_thread is NULL pointer. If the perf data doesn't
contain valid tid and then cs_etm__mem_access() uses unknown_thread
instead as thread handler, this results in a segmentation fault when
thread__find_addr_map() accesses the thread handler.
This commit creates a new thread data which is used by unknown_thread, so
CoreSight tracing can roll back to use unknown_thread if perf data
doesn't include valid thread info. This commit also releases thread
data for initialization failure case and for normal auxtrace free flow.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Link: http://lkml.kernel.org/r/1525924920-4381-1-git-send-email-leo.yan at linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/perf/util/cs-etm.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -212,6 +212,7 @@ static void cs_etm__free(struct perf_ses
for (i = 0; i < aux->num_cpu; i++)
zfree(&aux->metadata[i]);
+ thread__zput(aux->unknown_thread);
zfree(&aux->metadata);
zfree(&aux);
}
@@ -980,6 +981,23 @@ int cs_etm__process_auxtrace_info(union
etm->auxtrace.free = cs_etm__free;
session->auxtrace = &etm->auxtrace;
+ etm->unknown_thread = thread__new(999999999, 999999999);
+ if (!etm->unknown_thread)
+ goto err_free_queues;
+
+ /*
+ * Initialize list node so that at thread__zput() we can avoid
+ * segmentation fault at list_del_init().
+ */
+ INIT_LIST_HEAD(&etm->unknown_thread->node);
+
+ err = thread__set_comm(etm->unknown_thread, "unknown", 0);
+ if (err)
+ goto err_delete_thread;
+
+ if (thread__init_map_groups(etm->unknown_thread, etm->machine))
+ goto err_delete_thread;
+
if (dump_trace) {
cs_etm__print_auxtrace_info(auxtrace_info->priv, num_cpu);
return 0;
@@ -994,16 +1012,18 @@ int cs_etm__process_auxtrace_info(union
err = cs_etm__synth_events(etm, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
err = auxtrace_queues__process_index(&etm->queues, session);
if (err)
- goto err_free_queues;
+ goto err_delete_thread;
etm->data_queued = etm->queues.populated;
return 0;
+err_delete_thread:
+ thread__zput(etm->unknown_thread);
err_free_queues:
auxtrace_queues__free(&etm->queues);
session->auxtrace = NULL;
^ permalink raw reply
* [PATCH 4.14 116/189] spi: bcm2835aux: ensure interrupts are enabled for shared handler
From: Greg Kroah-Hartman @ 2018-06-18 8:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618081209.254234434@linuxfoundation.org>
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rob Herring <robh@kernel.org>
[ Upstream commit bc519d9574618e47a0c788000fb78da95e18d953 ]
The BCM2835 AUX SPI has a shared interrupt line (with AUX UART).
Downstream fixes this with an AUX irqchip to demux the IRQ sources and a
DT change which breaks compatibility with older kernels. The AUX irqchip
was already rejected for upstream[1] and the DT change would break
working systems if the DTB is updated to a newer one. The latter issue
was brought to my attention by Alex Graf.
The root cause however is a bug in the shared handler. Shared handlers
must check that interrupts are actually enabled before servicing the
interrupt. Add a check that the TXEMPTY or IDLE interrupts are enabled.
[1] https://patchwork.kernel.org/patch/9781221/
Cc: Alexander Graf <agraf@suse.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list at broadcom.com
Cc: linux-spi at vger.kernel.org
Cc: linux-rpi-kernel at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/spi/spi-bcm2835aux.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/spi/spi-bcm2835aux.c
+++ b/drivers/spi/spi-bcm2835aux.c
@@ -184,6 +184,11 @@ static irqreturn_t bcm2835aux_spi_interr
struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
irqreturn_t ret = IRQ_NONE;
+ /* IRQ may be shared, so return if our interrupts are disabled */
+ if (!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_CNTL1) &
+ (BCM2835_AUX_SPI_CNTL1_TXEMPTY | BCM2835_AUX_SPI_CNTL1_IDLE)))
+ return ret;
+
/* check if we have data to read */
while (bs->rx_len &&
(!(bcm2835aux_rd(bs, BCM2835_AUX_SPI_STAT) &
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: imx6qdl-sabreauto: Add sensors
From: Leonard Crestez @ 2018-06-18 8:15 UTC (permalink / raw)
To: linux-arm-kernel
The following sensors are on I2C3 on the baseboard:
* isil,isl29023 light sensor
* fsl,mag3110 magnetometer
* fsl,mma8451 accelerometer
Added under i2cmux/i2c at 1 because they're not otherwise accessible.
These are all supported by iio with following configs:
* CONFIG_SENSORS_ISL29018
* CONFIG_MAG3110
* CONFIG_MMA8452
Tested with raw reads from iio sysfs.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
Changes since v1:
* adjusted node names (Fabio)
Link: https://lkml.org/lkml/2018/6/7/970
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 0e28e36ddbb2..a59a0fd1eb02 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -153,10 +153,31 @@
compatible = "maxim,max7310";
reg = <0x34>;
gpio-controller;
#gpio-cells = <2>;
};
+
+ light-sensor at 44 {
+ compatible = "isil,isl29023";
+ reg = <0x44>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <17 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+ magnetometer at e {
+ compatible = "fsl,mag3110";
+ reg = <0x0e>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <29 IRQ_TYPE_EDGE_RISING>;
+ };
+
+ accelerometer at 1c {
+ compatible = "fsl,mma8451";
+ reg = <0x1c>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <31 IRQ_TYPE_LEVEL_LOW>;
+ };
};
};
};
&ipu1_csi0_from_ipu1_csi0_mux {
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/2] ARM: imx_v6_v7_defconfig: Enable imx6qdl-sabreauto sensors
From: Leonard Crestez @ 2018-06-18 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1be8dc197f842d3be31a15315594a25c8ad8f298.1529309235.git.leonard.crestez@nxp.com>
CONFIG_SENSORS_ISL29018 supports isil,il29023 light sensor
CONFIG_MMA8452 supports fsl,mma8451 accelerometer
CONFIG_MAG3110 for fsl,mag3110 is already enabled
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
Changes since v1:
* Added "ARM:" prefix in title (Fabio)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f70507ab91ee..a647cbb0e59f 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -372,12 +372,14 @@ CONFIG_MXS_DMA=y
CONFIG_STAGING=y
CONFIG_STAGING_MEDIA=y
CONFIG_VIDEO_IMX_MEDIA=y
CONFIG_COMMON_CLK_PWM=y
CONFIG_IIO=y
+CONFIG_MMA8452=y
CONFIG_IMX7D_ADC=y
CONFIG_VF610_ADC=y
+CONFIG_SENSORS_ISL29018=y
CONFIG_MAG3110=y
CONFIG_MPL3115=y
CONFIG_PWM=y
CONFIG_PWM_FSL_FTM=y
CONFIG_PWM_IMX=y
--
2.17.1
^ permalink raw reply related
* [PATCH] Revert "drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE"
From: Maxime Ripard @ 2018-06-18 8:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613081647.31183-1-paul.kocialkowski@bootlin.com>
On Wed, Jun 13, 2018 at 10:16:47AM +0200, Paul Kocialkowski wrote:
> This reverts commit 2c17a4368aad2b88b68e4390c819e226cf320f70.
>
> The offending commit triggers a run-time fault when accessing the panel
> element of the sun4i_tcon structure when no such panel is attached.
>
> It was apparently assumed in said commit that a panel is always used with
> the TCON. Although it is often the case, this is not always true.
> For instance a bridge might be used instead of a panel.
>
> This issue was discovered using an A13-OLinuXino, that uses the TCON
> in RGB mode for a simple DAC-based VGA bridge.
>
> Cc: stable at vger.kernel.org
> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Applied, thanks
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180618/9bd97802/attachment.sig>
^ permalink raw reply
* Charge counter on droid 4
From: Tony Lindgren @ 2018-06-18 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618074023.GA16955@amd>
* Pavel Machek <pavel@ucw.cz> [180618 07:43]:
>
> So... there are mA, mAh values. Those come from hardware, and I
> believe we should keep them.
>
> But there are also mW, mWh values, which are synthetic. Userland can
> compute them from mV, mA values... and it is confusing that kernel
> provides them. (My tendency was to start computing these synthetic
> values in userland, to compare them with "real hardware" values from
> kernel. But then I looked at kernel implementation, and realized they
> are synthetic, tooo...)
Hmm mWh value is based on the hardware sampled shunt
values and number of samples gathered between the
two readings. I'd rather call the calculated values
based on userland reading mV and mA values "synthetic" :)
Regards,
Tony
^ permalink raw reply
* [PATCH] mtd: nand: raw: atmel: add module param to avoid using dma
From: Boris Brezillon @ 2018-06-18 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180329131054.22506-1-peda@axentia.se>
On Thu, 29 Mar 2018 15:10:54 +0200
Peter Rosin <peda@axentia.se> wrote:
> On a sama5d31 with a Full-HD dual LVDS panel (132MHz pixel clock) NAND
> flash accesses have a tendency to cause display disturbances. Add a
> module param to disable DMA from the NAND controller, since that fixes
> the display problem for me.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
Miquel, can you queue this one to nand/next.
> ---
> drivers/mtd/nand/raw/atmel/nand-controller.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
> index b2f00b398490..2ff7a77c7b8e 100644
> --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> @@ -129,6 +129,11 @@
> #define DEFAULT_TIMEOUT_MS 1000
> #define MIN_DMA_LEN 128
>
> +static bool atmel_nand_avoid_dma __read_mostly;
> +
> +MODULE_PARM_DESC(avoiddma, "Avoid using DMA");
> +module_param_named(avoiddma, atmel_nand_avoid_dma, bool, 0400);
> +
> enum atmel_nand_rb_type {
> ATMEL_NAND_NO_RB,
> ATMEL_NAND_NATIVE_RB,
> @@ -1977,7 +1982,7 @@ static int atmel_nand_controller_init(struct atmel_nand_controller *nc,
> return ret;
> }
>
> - if (nc->caps->has_dma) {
> + if (nc->caps->has_dma && !atmel_nand_avoid_dma) {
> dma_cap_mask_t mask;
>
> dma_cap_zero(mask);
^ permalink raw reply
* [PATCH v3 00/14] ARM: pxa: switch to DMA slave maps
From: Boris Brezillon @ 2018-06-18 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617170217.24177-1-robert.jarzmik@free.fr>
Hi Robert,
On Sun, 17 Jun 2018 19:02:03 +0200
Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> As I gathered almost all the required acks, this is an information only post
> before queuing to the PXA tree.
We'll need an immutable branch/tag containing those changes, just in
case other conflicting changes get submitted to the NAND driver.
Thanks,
Boris
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: mailbox: provide imx-mailbox documentation
From: Leonard Crestez @ 2018-06-18 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615095107.24610-3-o.rempel@pengutronix.de>
On Fri, 2018-06-15 at 11:51 +0200, Oleksij Rempel wrote:
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> ---
> .../bindings/mailbox/imx-mailbox.txt | 35 +++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
A recent patch was posted which adds a similar but different binding
for the MU on 8qm/8qxp SOCs:
https://patchwork.kernel.org/patch/10468885/
Looking at manuals side-by-side the hardware seems to be the same so
there should be a single binding. Right?
That series I pointed to uses the MU to implement a communication with
a special "SCU" core which runs NXP firmware for handling details like
power management. However imx8 socs also have other MUs and M4 cores
for customers to use pretty exactly like they would on 7d.
The hardware exposes a very generic interface and my impression is that
drivers for the MU are actually highly specific to what is on the
other side of the MU. For example your driver code seems to be mapping
the 4 MU registers to separate "channels" but for SCU messages are
written in all registers in a round-robin way.
Shouldn't your MU-using driver be a separate node which references the
MU by phandle? Like in this patch:
https://patchwork.kernel.org/patch/10468887/
> diff --git a/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt b/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
> new file mode 100644
> index 000000000000..1577b86f1206
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/imx-mailbox.txt
> @@ -0,0 +1,35 @@
> +i.MX Messaging Unit
> +===================
> +
> +The i.MX Messaging Unit (MU) contains two register sets: "A" and "B". In most
> +cases they are accessible from all Processor Units. On one hand, at least for
> +mailbox functionality, it makes no difference which application or processor is
> +using which set of the MU. On other hand, the register sets for each of the MU
> +parts are not identical.
> +
> +Required properties:
> +- compatible : Shell be one of:
> + "fsl,imx7s-mu-a" and "fsl,imx7s-mu-b" for i.MX7S or i.MX7D
> +- reg : physical base address of the mailbox and length of
> + memory mapped region.
> +- #mbox-cells: Common mailbox binding property to identify the number
> + of cells required for the mailbox specifier. Should be 1.
> +- interrupts : The interrupt number
> +- clocks : phandle to the input clock.
> +
> +Example:
> + mu0a: mailbox at 30aa0000 {
> + compatible = "fsl,imx7s-mu-a";
> + reg = <0x30aa0000 0x28>;
> + interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> + #mbox-cells = <1>;
> + };
> +
> + mu0b: mailbox at 30ab0000 {
> + compatible = "fsl,imx7s-mu-b";
> + reg = <0x30ab0000 0x28>;
> + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX7D_MU_ROOT_CLK>;
> + #mbox-cells = <1>;
> + };
^ permalink raw reply
* [PATCH V2 4/4] soc: imx: add SC firmware IPC and APIs
From: Leonard Crestez @ 2018-06-18 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529239789-26849-5-git-send-email-aisheng.dong@nxp.com>
On Sun, 2018-06-17 at 20:49 +0800, Dong Aisheng wrote:
> The System Controller Firmware (SCFW) is a low-level system function
> which runs on a dedicated Cortex-M core to provide power, clock, and
> resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
> (QM, QP), and i.MX8QX (QXP, DX).
>
> This patch adds the SC firmware service APIs used by the system.
> It mainly consists of two parts:
> 1) Implementation of the IPC functions using MUs (client side).
> 2) SCU firmware services APIs implemented based on RPC calls
Most of the code in this patch is auto-generated but some of it (like
ipc.c) is not. Maybe that part should go to a separate patch?
It's otherwise difficult to tell which parts of this +5000 line patch
should be looked at by a human.
^ permalink raw reply
* [PATCH v2] mmc: sdhci-of-arasan: Add quirk for unstable clocks
From: Ulf Hansson @ 2018-06-18 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615081830.zrgx6arwn6ga27gu@laureti-dev>
On 15 June 2018 at 10:18, Helmut Grohne <h.grohne@intenta.de> wrote:
> Some controllers immediately report SDHCI_CLOCK_INT_STABLE after
> enabling the clock even when the clock is not stable. When used in
> conjunction with older/slower cards, this can result in:
>
> mmc0: error -84 whilst initialising SD card
>
> When the stable reporting is broken, we simply wait for the maximum
> stabilization period.
>
> Signed-off-by: Helmut Grohne <h.grohne@intenta.de>
> ---
> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 2 ++
Please split this. DT doc should be a separate patch.
Otherwise this looks good to me.
Kind regards
Uffe
> drivers/mmc/host/sdhci-of-arasan.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+)
>
> Changes since v1 (RFC):
> * Use an arasan-specific quirk in the ->set_clock() callback as requested by
> Adrian Hunter.
>
> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> index 60481bfc3d31..c0e0f04a8504 100644
> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
> @@ -39,6 +39,8 @@ Optional Properties:
> - xlnx,fails-without-test-cd: when present, the controller doesn't work when
> the CD line is not connected properly, and the line is not connected
> properly. Test mode can be used to force the controller to function.
> + - xlnx,int-clock-stable-broken: when present, the controller always reports
> + that the internal clock is stable even when it is not.
>
> Example:
> sdhci at e0100000 {
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index c33a5f7393bd..f7fe26c75150 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -102,6 +102,9 @@ struct sdhci_arasan_data {
>
> /* Controller does not have CD wired and will not function normally without */
> #define SDHCI_ARASAN_QUIRK_FORCE_CDTEST BIT(0)
> +/* Controller immediately reports SDHCI_CLOCK_INT_STABLE after enabling the
> + * internal clock even when the clock isn't stable */
> +#define SDHCI_ARASAN_QUIRK_CLOCK_UNSTABLE BIT(1)
> };
>
> static const struct sdhci_arasan_soc_ctl_map rk3399_soc_ctl_map = {
> @@ -207,6 +210,16 @@ static void sdhci_arasan_set_clock(struct sdhci_host *host, unsigned int clock)
>
> sdhci_set_clock(host, clock);
>
> + if (sdhci_arasan->quirks & SDHCI_ARASAN_QUIRK_CLOCK_UNSTABLE)
> + /*
> + * Some controllers immediately report SDHCI_CLOCK_INT_STABLE
> + * after enabling the clock even though the clock is not
> + * stable. Trying to use a clock without waiting here results
> + * in EILSEQ while detecting some older/slower cards. The
> + * chosen delay is the maximum delay from sdhci_set_clock.
> + */
> + msleep(20);
> +
> if (ctrl_phy) {
> phy_power_on(sdhci_arasan->phy);
> sdhci_arasan->is_phy_on = true;
> @@ -759,6 +772,9 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> if (of_property_read_bool(np, "xlnx,fails-without-test-cd"))
> sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_FORCE_CDTEST;
>
> + if (of_property_read_bool(np, "xlnx,int-clock-stable-broken"))
> + sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_CLOCK_UNSTABLE;
> +
> pltfm_host->clk = clk_xin;
>
> if (of_device_is_compatible(pdev->dev.of_node,
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH] soc: imx: gpc: fix PDN delay & improve readability
From: Sven Schmitt @ 2018-06-18 9:01 UTC (permalink / raw)
To: linux-arm-kernel
- imx6_pm_domain_power_off(): reads iso and iso2sw
from GPC_PGC_PUPSCR_OFFS which stores the power up delays
=> use GPC_PGC_PDNSCR_OFFS for the correct delays
- remove unused #defines
- struct imx_pm_domain: introduce cntr_pup_bit
to replace usage of cntr_pdn_bit+1 in imx6_pm_domain_power_on()
- GPC_PGC_DOMAIN_*: made consistent use of index defines
Signed-off-by: Sven Schmitt <sven.schmitt@mixed-mode.de>
---
drivers/soc/imx/gpc.c | 41 ++++++++++++++++++++---------------------
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
index c4d35f32af8d..b92377c75ddf 100644
--- a/drivers/soc/imx/gpc.c
+++ b/drivers/soc/imx/gpc.c
@@ -24,15 +24,6 @@
#define GPC_PGC_CTRL_OFFS 0x0
#define GPC_PGC_PUPSCR_OFFS 0x4
#define GPC_PGC_PDNSCR_OFFS 0x8
-#define GPC_PGC_SW2ISO_SHIFT 0x8
-#define GPC_PGC_SW_SHIFT 0x0
-
-#define GPC_PGC_GPU_PDN 0x260
-#define GPC_PGC_GPU_PUPSCR 0x264
-#define GPC_PGC_GPU_PDNSCR 0x268
-
-#define GPU_VPU_PUP_REQ BIT(1)
-#define GPU_VPU_PDN_REQ BIT(0)
#define GPC_CLK_MAX 6
@@ -46,6 +37,7 @@ struct imx_pm_domain {
int num_clks;
unsigned int reg_offs;
signed char cntr_pdn_bit;
+ signed char cntr_pup_bit;
unsigned int ipg_rate_mhz;
unsigned int flags;
};
@@ -66,7 +58,7 @@ static int imx6_pm_domain_power_off(struct generic_pm_domain *genpd)
return -EBUSY;
/* Read ISO and ISO2SW power down delays */
- regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS, &val);
+ regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PDNSCR_OFFS, &val);
iso = val & 0x3f;
iso2sw = (val >> 8) & 0x3f;
@@ -116,7 +108,7 @@ static int imx6_pm_domain_power_on(struct generic_pm_domain *genpd)
sw2iso = (val >> 8) & 0x3f;
/* Request GPC to power up domain */
- val = BIT(pd->cntr_pdn_bit + 1);
+ val = BIT(pd->cntr_pup_bit);
regmap_update_bits(pd->regmap, GPC_CNTR, val, val);
/* Wait ISO + ISO2SW IPG clock cycles */
@@ -241,22 +233,24 @@ static struct platform_driver imx_pgc_power_domain_driver = {
};
builtin_platform_driver(imx_pgc_power_domain_driver)
-#define GPC_PGC_DOMAIN_ARM 0
-#define GPC_PGC_DOMAIN_PU 1
-#define GPC_PGC_DOMAIN_DISPLAY 2
-
static struct genpd_power_state imx6_pm_domain_pu_state = {
.power_off_latency_ns = 25000,
.power_on_latency_ns = 2000000,
};
+#define GPC_PGC_DOMAIN_ARM 0
+#define GPC_PGC_DOMAIN_PU 1
+#define GPC_PGC_DOMAIN_DISPLAY 2
+#define GPC_PGC_DOMAIN_PCI 3
+
static struct imx_pm_domain imx_gpc_domains[] = {
- {
+ [GPC_PGC_DOMAIN_ARM] {
.base = {
.name = "ARM",
.flags = GENPD_FLAG_ALWAYS_ON,
},
- }, {
+ },
+ [GPC_PGC_DOMAIN_PU] {
.base = {
.name = "PU",
.power_off = imx6_pm_domain_power_off,
@@ -266,7 +260,9 @@ static struct imx_pm_domain imx_gpc_domains[] = {
},
.reg_offs = 0x260,
.cntr_pdn_bit = 0,
- }, {
+ .cntr_pup_bit = 1,
+ },
+ [GPC_PGC_DOMAIN_DISPLAY] {
.base = {
.name = "DISPLAY",
.power_off = imx6_pm_domain_power_off,
@@ -274,7 +270,9 @@ static struct imx_pm_domain imx_gpc_domains[] = {
},
.reg_offs = 0x240,
.cntr_pdn_bit = 4,
- }, {
+ .cntr_pup_bit = 5,
+ },
+ [GPC_PGC_DOMAIN_PCI] {
.base = {
.name = "PCI",
.power_off = imx6_pm_domain_power_off,
@@ -282,6 +280,7 @@ static struct imx_pm_domain imx_gpc_domains[] = {
},
.reg_offs = 0x200,
.cntr_pdn_bit = 6,
+ .cntr_pup_bit = 7,
},
};
@@ -326,8 +325,8 @@ static const struct regmap_config imx_gpc_regmap_config = {
};
static struct generic_pm_domain *imx_gpc_onecell_domains[] = {
- &imx_gpc_domains[0].base,
- &imx_gpc_domains[1].base,
+ &imx_gpc_domains[GPC_PGC_DOMAIN_ARM].base,
+ &imx_gpc_domains[GPC_PGC_DOMAIN_PU].base,
};
static struct genpd_onecell_data imx_gpc_onecell_data = {
--
2.17.1
^ permalink raw reply related
* [PATCH] ARM: dts: rockchip: convert rk3288 to operating-points-v2
From: Viresh Kumar @ 2018-06-18 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617131808.30283-1-heiko@sntech.de>
On 17-06-18, 15:18, Heiko Stuebner wrote:
> + cpu_opp_table: cpu-opp-table {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp00 {
Most of the platforms write it as "opp-126000000". Maybe follow the same
nomenclature ?
--
viresh
^ permalink raw reply
* [PATCH] soc: imx: gpc: fix PDN delay & improve readability
From: Lucas Stach @ 2018-06-18 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529312474617.59395@mixed-mode.de>
Am Montag, den 18.06.2018, 09:01 +0000 schrieb Sven Schmitt:
> - imx6_pm_domain_power_off(): reads iso and iso2sw
> ? from GPC_PGC_PUPSCR_OFFS which stores the power up delays
> ? => use GPC_PGC_PDNSCR_OFFS for the correct delays
>
> - remove unused #defines
>
> - struct imx_pm_domain: introduce cntr_pup_bit
> ? to replace usage of cntr_pdn_bit+1 in imx6_pm_domain_power_on()
I'm not sure I see the value in that one.
Otherwise this change looks fine.
Regards,
Lucas
>
> - GPC_PGC_DOMAIN_*: made consistent use of index defines
>
> Signed-off-by: Sven Schmitt <sven.schmitt@mixed-mode.de>
> ---
> ?drivers/soc/imx/gpc.c | 41 ++++++++++++++++++++---------------------
> ?1 file changed, 20 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> index c4d35f32af8d..b92377c75ddf 100644
> --- a/drivers/soc/imx/gpc.c
> +++ b/drivers/soc/imx/gpc.c
> @@ -24,15 +24,6 @@
> ?#define GPC_PGC_CTRL_OFFS 0x0
> ?#define GPC_PGC_PUPSCR_OFFS 0x4
> ?#define GPC_PGC_PDNSCR_OFFS 0x8
> -#define GPC_PGC_SW2ISO_SHIFT 0x8
> -#define GPC_PGC_SW_SHIFT 0x0
> -
> -#define GPC_PGC_GPU_PDN 0x260
> -#define GPC_PGC_GPU_PUPSCR 0x264
> -#define GPC_PGC_GPU_PDNSCR 0x268
> -
> -#define GPU_VPU_PUP_REQ BIT(1)
> -#define GPU_VPU_PDN_REQ BIT(0)
> ?
> ?#define GPC_CLK_MAX 6
> ?
> @@ -46,6 +37,7 @@ struct imx_pm_domain {
> ? int num_clks;
> ? unsigned int reg_offs;
> ? signed char cntr_pdn_bit;
> + signed char cntr_pup_bit;
> ? unsigned int ipg_rate_mhz;
> ? unsigned int flags;
> ?};
> @@ -66,7 +58,7 @@ static int imx6_pm_domain_power_off(struct
> generic_pm_domain *genpd)
> ? return -EBUSY;
> ?
> ? /* Read ISO and ISO2SW power down delays */
> - regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PUPSCR_OFFS,
> &val);
> + regmap_read(pd->regmap, pd->reg_offs + GPC_PGC_PDNSCR_OFFS,
> &val);
> ? iso = val & 0x3f;
> ? iso2sw = (val >> 8) & 0x3f;
> ?
> @@ -116,7 +108,7 @@ static int imx6_pm_domain_power_on(struct
> generic_pm_domain *genpd)
> ? sw2iso = (val >> 8) & 0x3f;
> ?
> ? /* Request GPC to power up domain */
> - val = BIT(pd->cntr_pdn_bit + 1);
> + val = BIT(pd->cntr_pup_bit);
> ? regmap_update_bits(pd->regmap, GPC_CNTR, val, val);
> ?
> ? /* Wait ISO + ISO2SW IPG clock cycles */
> @@ -241,22 +233,24 @@ static struct platform_driver
> imx_pgc_power_domain_driver = {
> ?};
> ?builtin_platform_driver(imx_pgc_power_domain_driver)
> ?
> -#define GPC_PGC_DOMAIN_ARM 0
> -#define GPC_PGC_DOMAIN_PU 1
> -#define GPC_PGC_DOMAIN_DISPLAY 2
> -
> ?static struct genpd_power_state imx6_pm_domain_pu_state = {
> ? .power_off_latency_ns = 25000,
> ? .power_on_latency_ns = 2000000,
> ?};
> ?
> +#define GPC_PGC_DOMAIN_ARM 0
> +#define GPC_PGC_DOMAIN_PU 1
> +#define GPC_PGC_DOMAIN_DISPLAY 2
> +#define GPC_PGC_DOMAIN_PCI 3
> +
> ?static struct imx_pm_domain imx_gpc_domains[] = {
> - {
> + [GPC_PGC_DOMAIN_ARM] {
> ? .base = {
> ? .name = "ARM",
> ? .flags = GENPD_FLAG_ALWAYS_ON,
> ? },
> - }, {
> + },
> + [GPC_PGC_DOMAIN_PU] {
> ? .base = {
> ? .name = "PU",
> ? .power_off = imx6_pm_domain_power_off,
> @@ -266,7 +260,9 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> ? },
> ? .reg_offs = 0x260,
> ? .cntr_pdn_bit = 0,
> - }, {
> + .cntr_pup_bit = 1,
> + },
> + [GPC_PGC_DOMAIN_DISPLAY] {
> ? .base = {
> ? .name = "DISPLAY",
> ? .power_off = imx6_pm_domain_power_off,
> @@ -274,7 +270,9 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> ? },
> ? .reg_offs = 0x240,
> ? .cntr_pdn_bit = 4,
> - }, {
> + .cntr_pup_bit = 5,
> + },
> + [GPC_PGC_DOMAIN_PCI] {
> ? .base = {
> ? .name = "PCI",
> ? .power_off = imx6_pm_domain_power_off,
> @@ -282,6 +280,7 @@ static struct imx_pm_domain imx_gpc_domains[] = {
> ? },
> ? .reg_offs = 0x200,
> ? .cntr_pdn_bit = 6,
> + .cntr_pup_bit = 7,
> ? },
> ?};
> ?
> @@ -326,8 +325,8 @@ static const struct regmap_config
> imx_gpc_regmap_config = {
> ?};
> ?
> ?static struct generic_pm_domain *imx_gpc_onecell_domains[] = {
> - &imx_gpc_domains[0].base,
> - &imx_gpc_domains[1].base,
> + &imx_gpc_domains[GPC_PGC_DOMAIN_ARM].base,
> + &imx_gpc_domains[GPC_PGC_DOMAIN_PU].base,
> ?};
> ?
> ?static struct genpd_onecell_data imx_gpc_onecell_data = {
^ permalink raw reply
* [PATCH 1/2] media: stm32-dcmi: drop unnecessary while(1) loop
From: Hugues FRUCHET @ 2018-06-18 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528824138-19089-1-git-send-email-hofrat@osadl.org>
Hi Nicholas,
thanks for patch !
On 06/12/2018 07:22 PM, Nicholas Mc Guire wrote:
> The while(1) is effectively useless as all possible paths within it
> return thus there is no way to loop.
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Acked-by: Hugues Fruchet <hugues.fruchet@st.com>
> ---
>
> This is not actually fixing any bug - the while(1){ } will not hurt here
> it is though simply unnecessary. Found during code review.
>
> The diff output is not very readable - essentially only the outer
> while(1){ } was removed.
>
> Patch was compile tested with: x86_64_defconfig, MEDIA_SUPPORT=y
> MEDIA_CAMERA_SUPPORT=y, V4L_PLATFORM_DRIVERS=y, OF=y, COMPILE_TEST=y
> CONFIG_VIDEO_STM32_DCMI=y
> (There are a number of sparse warnings - not related to the changes though)
>
> Patch is against 4.17.0 (localversion-next is next-20180608)
>
> drivers/media/platform/stm32/stm32-dcmi.c | 28 +++++++++++++---------------
> 1 file changed, 13 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
> index 2e1933d..70b81d2 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -1605,23 +1605,21 @@ static int dcmi_graph_parse(struct stm32_dcmi *dcmi, struct device_node *node)
> struct device_node *ep = NULL;
> struct device_node *remote;
>
> - while (1) {
> - ep = of_graph_get_next_endpoint(node, ep);
> - if (!ep)
> - return -EINVAL;
> -
> - remote = of_graph_get_remote_port_parent(ep);
> - if (!remote) {
> - of_node_put(ep);
> - return -EINVAL;
> - }
> + ep = of_graph_get_next_endpoint(node, ep);
> + if (!ep)
> + return -EINVAL;
>
> - /* Remote node to connect */
> - dcmi->entity.node = remote;
> - dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> - dcmi->entity.asd.match.fwnode = of_fwnode_handle(remote);
> - return 0;
> + remote = of_graph_get_remote_port_parent(ep);
> + if (!remote) {
> + of_node_put(ep);
> + return -EINVAL;
> }
> +
> + /* Remote node to connect */
> + dcmi->entity.node = remote;
> + dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> + dcmi->entity.asd.match.fwnode = of_fwnode_handle(remote);
> + return 0;
> }
>
> static int dcmi_graph_init(struct stm32_dcmi *dcmi)
>
BR,
Hugues.
^ permalink raw reply
* Charge counter on droid 4
From: Pavel Machek @ 2018-06-18 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618082858.GO112168@atomide.com>
On Mon 2018-06-18 01:28:58, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [180618 07:43]:
> >
> > So... there are mA, mAh values. Those come from hardware, and I
> > believe we should keep them.
> >
> > But there are also mW, mWh values, which are synthetic. Userland can
> > compute them from mV, mA values... and it is confusing that kernel
> > provides them. (My tendency was to start computing these synthetic
> > values in userland, to compare them with "real hardware" values from
> > kernel. But then I looked at kernel implementation, and realized they
> > are synthetic, tooo...)
>
> Hmm mWh value is based on the hardware sampled shunt
> values and number of samples gathered between the
> two readings. I'd rather call the calculated values
> based on userland reading mV and mA values "synthetic" :)
As far as I know, shunt resistors provide you with current (mA) not
power (mW) measurement... and cpcap-battery computes power_now as
voltage * current. I'd rather have kernel tell me "hardware can't
measure power" and do "voltage*current" computation in userspace.
So I'm proposing to apply patch below.
Best regards,
Pavel
+++ b/drivers/power/supply/cpcap-battery.c
@@ -490,24 +490,6 @@ static int cpcap_battery_get_property(struct power_supply *psy,
case POWER_SUPPLY_PROP_CHARGE_COUNTER:
val->intval = latest->counter_uah;
break;
- case POWER_SUPPLY_PROP_POWER_NOW:
- tmp = (latest->voltage / 10000) * latest->current_ua;
- val->intval = div64_s64(tmp, 100);
- break;
- case POWER_SUPPLY_PROP_POWER_AVG:
- if (cached) {
- tmp = cpcap_battery_cc_get_avg_current(ddata);
- tmp *= (latest->voltage / 10000);
- val->intval = div64_s64(tmp, 100);
- break;
- }
- sample = latest->cc.sample - previous->cc.sample;
- accumulator = latest->cc.accumulator - previous->cc.accumulator;
- tmp = cpcap_battery_cc_to_ua(ddata, sample, accumulator,
- latest->cc.offset);
- tmp *= ((latest->voltage + previous->voltage) / 20000);
- val->intval = div64_s64(tmp, 100);
- break;
case POWER_SUPPLY_PROP_CAPACITY_LEVEL:
if (cpcap_battery_full(ddata))
val->intval = POWER_SUPPLY_CAPACITY_LEVEL_FULL;
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180618/be105e1c/attachment.sig>
^ permalink raw reply
* [PATCH v2 0/2] Add R8A77980/Condor PCIe support
From: Simon Horman @ 2018-06-18 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b37d458c-071a-833a-2057-be8a07c880be@cogentembedded.com>
On Thu, Jun 14, 2018 at 10:16:32PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20180614v2-v4.17' tag. We're adding the R8A77980 PCIe related
> device nodes and then enable PCIe on the Condor board. These patches depend
> on the R8A77980 PCIe PHY driver support in order to work properly. Note that
> in case the PCIe PHY driver is not enabled, the kernel will BUG() due to I/O
> space page leak in the PCIe driver...
Is that problem specific to the presence of PCIe nodes for
condor/r8a77980 or is it also true of other (R-Car) boards where
PCIe is enabled?
Regardless, it sounds like these patches expose a kernel bug.
Is it being fixed?
>
> [1/2] arm64: dts: renesas: r8a77980: add PCIe support
> [2/2] arm64: dts: renesas: condor: add PCIe support
>
> WBR, Sergei
>
^ 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