* [PATCH V8 1/9] iommu: add IOMMU_PRIV attribute
From: Sricharan R @ 2017-01-02 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483362764-11990-1-git-send-email-sricharan@codeaurora.org>
From: Mitchel Humpherys <mitchelh@codeaurora.org>
Add the IOMMU_PRIV attribute, which is used to indicate privileged
mappings.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Acked-by: Will Deacon <will.deacon@arm.com>
---
include/linux/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 0ff5111..8c15ada 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -31,6 +31,7 @@
#define IOMMU_CACHE (1 << 2) /* DMA cache coherency */
#define IOMMU_NOEXEC (1 << 3)
#define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
+#define IOMMU_PRIV (1 << 5) /* privileged */
struct iommu_ops;
struct iommu_group;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH V8 0/9] Add support for privileged mappings
From: Sricharan R @ 2017-01-02 13:12 UTC (permalink / raw)
To: linux-arm-kernel
This series is a resend of the V5 that Mitch sent sometime back [2]
All the patches are the same and i have just rebased. Redid patch [3],
as it does not apply in this code base. Added a couple of more patches
[4], [5] from Robin for adding the privileged attributes to armv7s format
and arm-smmuv3 revert. Added a patch for passing in the privileged
attributes from arm32 dma-mapping apis as well.
The following patch to the ARM SMMU driver:
commit d346180e70b91b3d5a1ae7e5603e65593d4622bc
Author: Robin Murphy <robin.murphy@arm.com>
Date: Tue Jan 26 18:06:34 2016 +0000
iommu/arm-smmu: Treat all device transactions as unprivileged
started forcing all SMMU transactions to come through as "unprivileged".
The rationale given was that:
(1) There is no way in the IOMMU API to even request privileged
mappings.
(2) It's difficult to implement a DMA mapper that correctly models the
ARM VMSAv8 behavior of unprivileged-writeable =>
privileged-execute-never.
This series rectifies (1) by introducing an IOMMU API for privileged
mappings and implements it in io-pgtable-arm.
This series rectifies (2) by introducing a new dma attribute
(DMA_ATTR_PRIVILEGED) for users of the DMA API that need privileged
mappings which are inaccessible to lesser-privileged execution levels, and
implements it in the arm64 IOMMU DMA mapper. The one known user (pl330.c)
is converted over to the new attribute.
Jordan and Jeremy can provide more info on the use case if needed, but the
high level is that it's a security feature to prevent attacks such as [1].
Note that, i tested this on arm64 with arm-smmuv2, short descriptor changes,
tested this on arm32 platform as well and do not have an platform to test
this with arm-smmuv3.
[1] https://github.com/robclark/kilroy
[2] https://lkml.org/lkml/2016/7/27/590
[3] https://patchwork.kernel.org/patch/9250493/
[4] http://www.linux-arm.org/git?p=linux-rm.git;a=commit;h=1291bd74f05d31da1dab3df02987cba5bd25849b
[5] http://www.linux-arm.org/git?p=linux-rm.git;a=commit;h=a79c1c6333f26849dba418cd92de26b60f5954f3
Changelog:
v7..v8
- Added a patch for passing in the privileged attributes from arm32
dma-mapping apis as well.
v6..v7
- Added couple of more patches, picked up acks, updated commit log
v5..v6
- Rebased all the patches and redid 6/6 as it does not apply in
this code base.
v4..v5
- Simplified patch 4/6 (suggested by Robin Murphy).
v3..v4
- Rebased and reworked on linux next due to the dma attrs rework going
on over there. Patches changed: 3/6, 4/6, and 5/6.
v2..v3
- Incorporated feedback from Robin:
* Various comments and re-wordings.
* Use existing bit definitions for IOMMU_PRIV implementation
in io-pgtable-arm.
* Renamed and redocumented dma_direction_to_prot.
* Don't worry about executability in new DMA attr.
v1..v2
- Added a new DMA attribute to make executable privileged mappings
work, and use that in the pl330 driver (suggested by Will).
Jeremy Gebben (1):
iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag
Mitchel Humpherys (4):
iommu: add IOMMU_PRIV attribute
common: DMA-mapping: add DMA_ATTR_PRIVILEGED attribute
arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED
dmaengine: pl330: Make sure microcode is privileged
Robin Murphy (2):
iommu/io-pgtable-arm-v7s: Add support for the IOMMU_PRIV flag
Revert "iommu/arm-smmu: Set PRIVCFG in stage 1 STEs"
Sricharan R (2):
arm/dma-mapping: Implement DMA_ATTR_PRIVILEGED
iommu/arm-smmu: Set privileged attribute to 'default' instead of
'unprivileged'
Documentation/DMA-attributes.txt | 10 +++++++
arch/arm/mm/dma-mapping.c | 60 +++++++++++++++++++-------------------
arch/arm64/mm/dma-mapping.c | 6 ++--
drivers/dma/pl330.c | 5 ++--
drivers/iommu/arm-smmu-v3.c | 7 +----
drivers/iommu/arm-smmu.c | 2 +-
drivers/iommu/dma-iommu.c | 12 ++++++--
drivers/iommu/io-pgtable-arm-v7s.c | 6 +++-
drivers/iommu/io-pgtable-arm.c | 5 +++-
include/linux/dma-iommu.h | 3 +-
include/linux/dma-mapping.h | 7 +++++
include/linux/iommu.h | 1 +
12 files changed, 76 insertions(+), 48 deletions(-)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] DTS: MCCMON6: IMX: Provide support for iMX6Q based Liebherr mccmon6 board
From: Vladimir Zapolskiy @ 2017-01-02 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482794396-16153-1-git-send-email-l.majewski@majess.pl>
Hello Lukasz,
On 12/27/2016 01:19 AM, Lukasz Majewski wrote:
> Signed-off-by: Lukasz Majewski <l.majewski@majess.pl>
please add a commit message with a short description of the change.
Also change subject line to "ARM: dts: imx6q: Add mccmon6 board support".
> ---
> MCCMON6 board support depends on following patches:
>
> 1. "video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()"
> http://patchwork.ozlabs.org/patch/708844/
>
> 2. "pwm: imx: Provide atomic operation for IMX PWM driver"
> http://patchwork.ozlabs.org/patch/708847/ - http://patchwork.ozlabs.org/patch/708843/
>
>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6q-mccmon6.dts | 469 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 470 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6q-mccmon6.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index c558ba7..7ce1080 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -382,6 +382,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6q-h100.dtb \
> imx6q-hummingboard.dtb \
> imx6q-icore-rqs.dtb \
> + imx6q-mccmon6.dtb \
> imx6q-marsboard.dtb \
Please add a new line preserving alphabetical order.
> imx6q-nitrogen6x.dtb \
> imx6q-nitrogen6_max.dtb \
> diff --git a/arch/arm/boot/dts/imx6q-mccmon6.dts b/arch/arm/boot/dts/imx6q-mccmon6.dts
> new file mode 100644
> index 0000000..7445d01
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-mccmon6.dts
> @@ -0,0 +1,469 @@
> +/*
> + * Copyright 2016
Copyright holder is missing.
> + *
> + * Author: Lukasz Majewski <l.majewski@majess.pl>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
Please add an empty line here to improve readability.
> +/dts-v1/;
Please add an empty line here to improve readability.
> +#include "imx6q.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/pwm/pwm.h>
> +
> +/ {
> + model = "Monitor6 i.MX6 Quad Board";
Missing hardware vendor name.
> + compatible = "mccmon6", "fsl,imx6q";
Missing hardware vendor prefix before "mccmon6".
> +
> + memory {
> + reg = <0x10000000 0x80000000>;
> + };
> +
> + ethernet0 {
> + status = "okay";
> + };
It looks like a useless device node, you have a description of &fec already.
> +
> + backlight_lvds: backlight {
> + compatible = "pwm-backlight";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_display>;
I would recommend to rename "pinctrl_display" to "pinctrl_backlight".
> + pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
This should work when extension to the i.MX PWM driver is merged.
> + brightness-levels = < 0 1 2 3 4 5 6 7 8 9
> + 10 11 12 13 14 15 16 17 18 19
> + 20 21 22 23 24 25 26 27 28 29
> + 30 31 32 33 34 35 36 37 38 39
> + 40 41 42 43 44 45 46 47 48 49
> + 50 51 52 53 54 55 56 57 58 59
> + 60 61 62 63 64 65 66 67 68 69
> + 70 71 72 73 74 75 76 77 78 79
> + 80 81 82 83 84 85 86 87 88 89
> + 90 91 92 93 94 95 96 97 98 99
> + 100 101 102 103 104 105 106 107 108 109
> + 110 111 112 113 114 115 116 117 118 119
> + 120 121 122 123 124 125 126 127 128 129
> + 130 131 132 133 134 135 136 137 138 139
> + 140 141 142 143 144 145 146 147 148 149
> + 150 151 152 153 154 155 156 157 158 159
> + 160 161 162 163 164 165 166 167 168 169
> + 170 171 172 173 174 175 176 177 178 179
> + 180 181 182 183 184 185 186 187 188 189
> + 190 191 192 193 194 195 196 197 198 199
> + 200 201 202 203 204 205 206 207 208 209
> + 210 211 212 213 214 215 216 217 218 219
> + 220 221 222 223 224 225 226 227 228 229
> + 230 231 232 233 234 235 236 237 238 239
> + 240 241 242 243 244 245 246 247 248 249
> + 250 251 252 253 254 255>;
I'm not sure that actually need such a long list of brightness levels.
> + default-brightness-level = <50>;
> + enable-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
> + };
> +
> + reg_lvds: regulator-lvds {
> + compatible = "regulator-fixed";
> + regulator-name = "lvds_ppen";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + gpio = <&gpio1 19 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + panel-lvds0 {
> + compatible = "innolux,g121x1-l03";
> + backlight = <&backlight_lvds>;
> + power-supply = <®_lvds>;
> +
> + port {
> + panel_in_lvds0: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> + };
> +};
> +
> +&i2c1 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c1>;
> + status = "okay";
> +};
> +
> +&i2c2 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c2>;
> + status = "okay";
> +
> + pmic: pfuze100 at 08 {
> + compatible = "fsl,pfuze100";
> + reg = <0x08>;
> +
> + regulators {
> + sw1a_reg: sw1ab {
> + regulator-min-microvolt = <300000>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw1c_reg: sw1c {
> + regulator-min-microvolt = <300000>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw2_reg: sw2 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <3950000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3a_reg: sw3a {
> + regulator-min-microvolt = <400000>;
> + regulator-max-microvolt = <1975000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3b_reg: sw3b {
> + regulator-min-microvolt = <400000>;
> + regulator-max-microvolt = <1975000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw4_reg: sw4 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + swbst_reg: swbst {
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5150000>;
> + };
> +
> + snvs_reg: vsnvs {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vref_reg: vrefddr {
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vgen1_reg: vgen1 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1550000>;
> + };
> +
> + vgen2_reg: vgen2 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1550000>;
> + };
> +
> + vgen3_reg: vgen3 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + vgen4_reg: vgen4 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vgen5_reg: vgen5 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vgen6_reg: vgen6 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> + };
> + };
> +};
> +
> +&iomuxc {
> + pinctrl-names = "default";
> +
> + imx6q-mccmon6 {
> +
Please drop the empty line above.
> + pinctrl_enet: enetgrp {
> + fsl,pins = <
> + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
> + MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
> + MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0
> + MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0
> + MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0
> + MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0
> + MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0
> + MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
> + MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
> + MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0
> + MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0
> + MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0
> + MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
> + MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
> + MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
> + MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
> + MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
> + >;
> + };
> +
> + pinctrl_i2c1: i2c1grp {
> + fsl,pins = <
> + MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001b8b1
> + MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_i2c2: i2c2grp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
> + MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_uart1: uart1grp {
> + fsl,pins = <
> + MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
> + MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
> + >;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
> + MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
> + MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
> + MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
> + MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
> + MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
> + >;
> + };
> +
> + pinctrl_usdhc3: usdhc3grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
> + MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
> + MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
> + MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
> + MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
> + MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
> + MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
> + MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
> + MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
> + MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
> + MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
> + >;
> + };
> +
> + pinctrl_weim_cs0: weimcs0grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_CS0__EIM_CS0_B 0xb0b1
> + >;
> + };
> +
> + pinctrl_weim_nor: weimnorgrp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_OE__EIM_OE_B 0xb0b1
> + MX6QDL_PAD_EIM_RW__EIM_RW 0xb0b1
> + MX6QDL_PAD_EIM_WAIT__EIM_WAIT_B 0xb060
> + MX6QDL_PAD_EIM_D16__EIM_DATA16 0x1b0b0
> + MX6QDL_PAD_EIM_D17__EIM_DATA17 0x1b0b0
> + MX6QDL_PAD_EIM_D18__EIM_DATA18 0x1b0b0
> + MX6QDL_PAD_EIM_D19__EIM_DATA19 0x1b0b0
> + MX6QDL_PAD_EIM_D20__EIM_DATA20 0x1b0b0
> + MX6QDL_PAD_EIM_D21__EIM_DATA21 0x1b0b0
> + MX6QDL_PAD_EIM_D22__EIM_DATA22 0x1b0b0
> + MX6QDL_PAD_EIM_D23__EIM_DATA23 0x1b0b0
> + MX6QDL_PAD_EIM_D24__EIM_DATA24 0x1b0b0
> + MX6QDL_PAD_EIM_D25__EIM_DATA25 0x1b0b0
> + MX6QDL_PAD_EIM_D26__EIM_DATA26 0x1b0b0
> + MX6QDL_PAD_EIM_D27__EIM_DATA27 0x1b0b0
> + MX6QDL_PAD_EIM_D28__EIM_DATA28 0x1b0b0
> + MX6QDL_PAD_EIM_D29__EIM_DATA29 0x1b0b0
> + MX6QDL_PAD_EIM_D30__EIM_DATA30 0x1b0b0
> + MX6QDL_PAD_EIM_D31__EIM_DATA31 0x1b0b0
> + MX6QDL_PAD_EIM_A23__EIM_ADDR23 0xb0b1
> + MX6QDL_PAD_EIM_A22__EIM_ADDR22 0xb0b1
> + MX6QDL_PAD_EIM_A21__EIM_ADDR21 0xb0b1
> + MX6QDL_PAD_EIM_A20__EIM_ADDR20 0xb0b1
> + MX6QDL_PAD_EIM_A19__EIM_ADDR19 0xb0b1
> + MX6QDL_PAD_EIM_A18__EIM_ADDR18 0xb0b1
> + MX6QDL_PAD_EIM_A17__EIM_ADDR17 0xb0b1
> + MX6QDL_PAD_EIM_A16__EIM_ADDR16 0xb0b1
> + MX6QDL_PAD_EIM_DA15__EIM_AD15 0xb0b1
> + MX6QDL_PAD_EIM_DA14__EIM_AD14 0xb0b1
> + MX6QDL_PAD_EIM_DA13__EIM_AD13 0xb0b1
> + MX6QDL_PAD_EIM_DA12__EIM_AD12 0xb0b1
> + MX6QDL_PAD_EIM_DA11__EIM_AD11 0xb0b1
> + MX6QDL_PAD_EIM_DA10__EIM_AD10 0xb0b1
> + MX6QDL_PAD_EIM_DA9__EIM_AD09 0xb0b1
> + MX6QDL_PAD_EIM_DA8__EIM_AD08 0xb0b1
> + MX6QDL_PAD_EIM_DA7__EIM_AD07 0xb0b1
> + MX6QDL_PAD_EIM_DA6__EIM_AD06 0xb0b1
> + MX6QDL_PAD_EIM_DA5__EIM_AD05 0xb0b1
> + MX6QDL_PAD_EIM_DA4__EIM_AD04 0xb0b1
> + MX6QDL_PAD_EIM_DA3__EIM_AD03 0xb0b1
> + MX6QDL_PAD_EIM_DA2__EIM_AD02 0xb0b1
> + MX6QDL_PAD_EIM_DA1__EIM_AD01 0xb0b1
> + MX6QDL_PAD_EIM_DA0__EIM_AD00 0xb0b1
> + >;
> + };
> +
> + pinctrl_ecspi3: ecspi3grp {
> + fsl,pins = <
> + MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
> + MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
> + MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
> + >;
> + };
> +
> + pinctrl_ecspi3_cs: ecspi3cs {
> + fsl,pins = <
> + MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x80000000
> + >;
> + };
> + pinctrl_ecspi3_flwp: ecspi3flwp {
> + fsl,pins = <
> + MX6QDL_PAD_DISP0_DAT6__GPIO4_IO27 0x80000000
> + >;
> + };
> +
> + pinctrl_uart4: uart4grp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
> + MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
> + MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B 0x1b0b1
> + MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B 0x1b0b1
> + >;
> + };
> +
> + pinctrl_display: dispgrp {
> + fsl,pins = <
> + /* BLEN_OUT */
> + MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
> + /* LVDS_PPEN_OUT */
> + MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x1b0b0
This GPIO should be moved to a pinctrl group of regulator-lvds device node.
> + >;
> + };
> +
> + pinctrl_pwm2: pwm2grp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_1__PWM2_OUT 0x1b0b1
> + >;
> + };
Please sort out all pinctrl_* nodes alphabetically.
> + };
> +};
> +
> +&fec {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet>;
> + phy-mode = "rgmii";
> + phy-reset-gpios = <&gpio1 27 0>;
GPIO1_27 has no pad configuration in pinctrl_enet.
> + interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
> + <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
> + status = "okay";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1>;
Should you add "uart-has-rtscts" property?
> + status = "okay";
> +};
> +
> +&usdhc2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc2>;
> + cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
bus-width = <4>;
You should consider to add the GPIO1_4 into pinctrl_usdhc2 group.
> + status = "okay";
> +};
> +
> +&usdhc3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc3>;
> + bus-width = <8>;
> + status = "okay";
No "cd-gpios" property, should you add "non-removable" property then?
> +};
> +
> +&weim {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_weim_nor &pinctrl_weim_cs0>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <0 0 0x08000000 0x08000000>;
> + status = "okay";
> +
> + nor at 0,0 {
> + compatible = "cfi-flash";
> + reg = <0 0 0x02000000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + bank-width = <2>;
> + use-advanced-sector-protection;
> + fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
> + 0x0000c000 0x1404a38e 0x00000000>;
> + };
> +};
> +
> +&ecspi3 {
> + fsl,spi-num-chipselects = <1>;
This property is obsoleted, please remove it.
> + cs-gpios = <&gpio4 24 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs &pinctrl_ecspi3_flwp>;
> + status = "okay";
> +
> + flash: s25sl032p at 0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "spansion,s25sl032p", "jedec,spi-nor";
> + spi-max-frequency = <40000000>;
> + reg = <0>;
> + };
> +};
> +
> +&uart4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart4>;
> + status = "okay";
Should you add "uart-has-rtscts" property?
> +};
> +
> +&ldb {
> + status = "okay";
> +
> + lvds0: lvds-channel at 0 {
> + fsl,data-mapping = "spwg";
> + fsl,data-width = <24>;
> + status = "okay";
> +
> + port at 4 {
> + reg = <4>;
> +
> + lvds0_out: endpoint {
> + remote-endpoint = <&panel_in_lvds0>;
> + };
> + };
> + };
> +};
> +
> +&pwm2 {
> + #pwm-cells = <3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm2>;
> + status = "okay";
> +};
>
Please sort out all device nodes but &iomuxc alphabetically:
* iomuxc
* ecspi3
* fec
* i2c1
* i2c2
* ldb
* pwm2
* uart1
* uart4
* usdhc2
* usdhc3
* weim
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH 1/2] ARM: hyp-stub: improve ABI
From: Russell King - ARM Linux @ 2017-01-02 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161217120707.GA72718@MBP.local>
On Sat, Dec 17, 2016 at 12:07:11PM +0000, Catalin Marinas wrote:
> On Thu, Dec 15, 2016 at 06:57:18PM +0000, Russell King - ARM Linux wrote:
> > On Thu, Dec 15, 2016 at 03:37:15PM +0000, Marc Zyngier wrote:
> > > And this interface exists for the sole purpose of enabling KVM. Call it
> > > a hypervisor if you wish, but its usefulness is doubtful on its own.
>
> IMO, the interface between EL1 and EL2 _is_ ABI. However, it should not
> be confused with a *stable* ABI like the one we expose to user. Since
> all users of the EL2 ABI live inside the kernel (either on the EL1 or
> EL2 side), we are free to change it as long as everything is updated
> simultaneously. I don't see this any different from other in-kernel ABI
> like that exposed to loadable modules (for the latter, we have the
> advantage of a partly self-documenting ABI as part of the C language).
>
> I would welcome some documentation for the EL2 ABI as well, especially
> since head.S and the KVM counterpart is maintained by different people.
Well, it seems that different people within ARM have different opinions
on this subject - that makes it extremely hard to make progress on this.
As you're all local to each other, please can you hash it out amongst
yourselves and come to some sort of concensus!
> > What's also coming clear is that there's very few people who understand
> > all the interactions here, and the whole thing seems to be an undocumented
> > mess. Something needs to change there - people need to stop shovelling
> > half baked crap into the kernel. KVM have the privilege of being able to
> > push ARM stuff directly, I now see that was a very big mistake.
> >
> > So, I want KVM further changes to come through my tree once this merge
> > window is over -
>
> I'm afraid I strongly disagree. There are a few reasons neither you nor
> me gatekeep the KVM port: (a) the ARM KVM maintainers know a lot more
> about KVM than either of us, (b) the KVM code under arch/arm is reused
> by arm64 and (c) you or I would certainly become a bottleneck. There is
> a lot more to KVM support on ARM than the hyp stub and realistically you
> won't have the time to review all the stuff that comes your way.
I don't think so - in general the statistics for arch/arm/kvm are very
quiet - there's a bigger update once in a while:
v4.1: 8 files changed, 281 insertions(+), 150 deletions(-)
v4.2: 7 files changed, 56 insertions(+), 38 deletions(-)
v4.3: 8 files changed, 59 insertions(+), 41 deletions(-)
v4.4: 6 files changed, 95 insertions(+), 50 deletions(-)
v4.5: 6 files changed, 97 insertions(+), 50 deletions(-)
v4.6: 22 files changed, 1203 insertions(+), 1307 deletions(-)
v4.7: 5 files changed, 351 insertions(+), 262 deletions(-)
v4.8: 9 files changed, 134 insertions(+), 163 deletions(-)
v4.9: 12 files changed, 209 insertions(+), 159 deletions(-)
In terms of number of commits:
v4.1: 17
v4.2: 14
v4.3: 15
v4.4: 13
v4.5: 9
v4.6: 48
v4.7: 18
v4.8: 22
v4.9: 17
So there isn't much going on there.
> > Let's start with some documentation on the KVM hypervisor interfaces on
> > 32-bit ARM. Documentation/virtual/kvm/hypercalls.txt already contains
> > some for x86, s390 and PPC, so that would be a good place to document
> > the ARM side. Arguably, that should have already been done.
>
> I'm all for documenting the interface.
>
> (even though Will and I co-maintain arch/arm64, I deliberately kept his
> name out of the above as I haven't had the chance to ask for his
> opinion on this matter, which may as well differ)
Well, I started discussing this with Will before I produced the patch,
and Will thought that the ABI was entirely localised within hyp-stub.S.
This is exactly my point: very few people seem to have a proper
understanding of this (as illustrated by the number of different
opinions people appear to hold over various parts of the code), which
makes it very difficult for problems to get fixed.
Either we need more people to have an understanding (so if one of them
gets run over by a bus, we're not left floundering around) or we need
it to be documented - even if it's just a simple comment "the ABI in
this file is shared with XYZ, if you change the ABI here, also update
XYZ too."
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Hanjun Guo @ 2017-01-02 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0h3d5ZUxJXhgz74fSDR=AKTg_Of2knaONF_e2dr6Q-PsA@mail.gmail.com>
On 01/01/2017 04:45 AM, Rafael J. Wysocki wrote:
> On Fri, Dec 30, 2016 at 11:50 AM, Hanjun Guo <guohanjun@huawei.com> wrote:
[...]
>>
>> So how about just add the code as below?
>
> Works for me.
OK, will send out the updated patch set soon.
>
>> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
>> index 11e63dd..37a8dfe 100644
>> --- a/drivers/acpi/glue.c
>> +++ b/drivers/acpi/glue.c
>> @@ -316,7 +316,8 @@ static int acpi_platform_notify(struct device *dev)
>> if (!adev)
>> goto out;
>>
>> + if (dev->bus == &platform_bus_type)
>> + acpi_configure_pmsi_domain(dev);
>>
>> if (type && type->setup)
>> type->setup(dev);
Thanks for your comments.
Hanjun
^ permalink raw reply
* [PATCH v2 2/3] dmaeninge: xilinx_dma: Fix bug in multiple frame stores scenario in vdma
From: Appana Durga Kedareswara Rao @ 2017-01-02 11:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a269409d-103e-1650-5df6-cc8743ed62cf@synopsys.com>
Hi Jose Miguel Abreu,
Thanks for the review....
Sorry for the delay in the reply please see comments inline...
> > if (chan->has_sg) {
> > dma_ctrl_write(chan, XILINX_DMA_REG_TAILDESC,
> > tail_segment->phys);
> > + list_splice_tail_init(&chan->pending_list, &chan->active_list);
> > + chan->desc_pendingcount = 0;
> > } else {
> > struct xilinx_vdma_tx_segment *segment, *last = NULL;
> > - int i = 0;
> > + int i = 0, j = 0;
> >
> > if (chan->desc_submitcount < chan->num_frms)
> > i = chan->desc_submitcount;
> >
> > - list_for_each_entry(segment, &desc->segments, node) {
> > - if (chan->ext_addr)
> > - vdma_desc_write_64(chan,
> > -
> XILINX_VDMA_REG_START_ADDRESS_64(i++),
> > - segment->hw.buf_addr,
> > - segment->hw.buf_addr_msb);
> > - else
> > - vdma_desc_write(chan,
> > -
> XILINX_VDMA_REG_START_ADDRESS(i++),
> > - segment->hw.buf_addr);
> > -
> > - last = segment;
> > + for (j = 0; j < chan->num_frms; ) {
> > + list_for_each_entry(segment, &desc->segments, node)
> {
> > + if (chan->ext_addr)
> > + vdma_desc_write_64(chan,
> > +
> XILINX_VDMA_REG_START_ADDRESS_64(i++),
> > + segment->hw.buf_addr,
> > + segment->hw.buf_addr_msb);
> > + else
> > + vdma_desc_write(chan,
> > +
> XILINX_VDMA_REG_START_ADDRESS(i++),
> > + segment->hw.buf_addr);
> > +
> > + last = segment;
> > + }
> > + list_del(&desc->node);
> > + list_add_tail(&desc->node, &chan->active_list);
> > + j++;
> > + if (list_empty(&chan->pending_list) ||
> > + (i == chan->num_frms))
> > + break;
> > + desc = list_first_entry(&chan->pending_list,
> > + struct
> xilinx_dma_tx_descriptor,
> > + node);
> > }
> >
> > if (!last)
> > @@ -1081,20 +1094,14 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_dma_chan *chan)
> > vdma_desc_write(chan, XILINX_DMA_REG_FRMDLY_STRIDE,
> > last->hw.stride);
> > vdma_desc_write(chan, XILINX_DMA_REG_VSIZE, last-
> >hw.vsize);
>
> What if we reach here and j < num_frms? It can happen because if
> the pending list is empty the loop breaks. Then VDMA will start
> with framebuffers having address 0x0. You should only program
> vsize when j > num_frms or when we have already previously set
> the framebuffers (i.e. when submitcount has already been
> incremented num_frms at least once).
In case of j < num_frms VDMA won't start the frame buffer having address 0
As we are programming the VDMA buffer address based on the desc_submitcount value only i.e. i.
Code snippet in the driver doing this:
list_for_each_entry(segment, &desc->segments, node) {
if (chan->ext_addr)
vdma_desc_write_64(chan,
XILINX_VDMA_REG_START_ADDRESS_64(i++),
segment->hw.buf_addr,
segment->hw.buf_addr_msb);
else
vdma_desc_write(chan,
XILINX_VDMA_REG_START_ADDRESS(i++),
segment->hw.buf_addr);
last = segment;
}
Initially desc_submitcount will be zero.
Let's assume h/w is configured for 10 frames and user submitted only 5 frames.
And triggered the VDMA h/w using issue_pending in this case desc_submitcount will be 5.
desc_submitcount will become zero again only when
User submits more frames than h/w capable or user submit frames up to h/w capable.
If my understanding is wrong could you please elaborate the race condition that you are talking above?
Regards,
Kedar.
>
> Best regards,
> Jose Miguel Abreu
>
^ permalink raw reply
* [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Harini Katakam @ 2017-01-02 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102113155.GA16373@localhost.localdomain>
Hi Richard,
On Mon, Jan 2, 2017 at 5:01 PM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Mon, Jan 02, 2017 at 09:36:10AM +0000, Rafal Ozieblo wrote:
>> According Cadence Hardware team:
>> "It is just that some customers prefer to have the time in the descriptors as that is provided per frame.
>> The registers are simply overwritten when a new event frame is transmitted/received and so software could miss it."
>> The question is are you sure that you read timestamp for current frame? (not for the next frame).
>
> AFAICT, having the time stamp in the descriptor is not universally
> supported. Looking at the Xilinx Zynq 7000 TRM, I can't find any
> mention of this.
>
> This Cadence IP core is a complete disaster.
>
> Unless someone can tell us how this IP works in all of its
> incarnations, this series is going nowhere.
>From the revision history of Cadence spec, all versions starting
r1p02 have ability to include timestamp in descriptors.
For previous versions the event register is the only option.
But yes, there have been multiple enhancements and
bug fixes in this IP w.r.t PTP making each implementation
different.
Regards,
Harini
^ permalink raw reply
* [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2017-01-02 11:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BN3PR07MB2516815EDE69ACDCE27F81A3C96F0@BN3PR07MB2516.namprd07.prod.outlook.com>
On Mon, Jan 02, 2017 at 09:36:10AM +0000, Rafal Ozieblo wrote:
> According Cadence Hardware team:
> "It is just that some customers prefer to have the time in the descriptors as that is provided per frame.
> The registers are simply overwritten when a new event frame is transmitted/received and so software could miss it."
> The question is are you sure that you read timestamp for current frame? (not for the next frame).
AFAICT, having the time stamp in the descriptor is not universally
supported. Looking at the Xilinx Zynq 7000 TRM, I can't find any
mention of this.
This Cadence IP core is a complete disaster.
Unless someone can tell us how this IP works in all of its
incarnations, this series is going nowhere.
Thanks,
Richard
^ permalink raw reply
* [PATCH v7 5/5] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
From: Sekhar Nori @ 2017-01-02 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481623759-12786-6-git-send-email-bgolaszewski@baylibre.com>
On Tuesday 13 December 2016 03:39 PM, Bartosz Golaszewski wrote:
> At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
> is 37.5 MHz[1]. We must filter out any mode for which the calculated
> pixel clock rate would exceed this value.
>
> Specify the max-pixelclock property for the display node for
> da850-lcdk.
>
> [1] http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_LCD_Controller_(LCDC)_Throughput_and_Optimization_Techniques
This wiki page is not really a TI datasheet and can change without
notice. I changed this to refer to
http://www.ti.com/lit/ds/symlink/am1808.pdf (SPRS653E, revised March
2014), table 6-110.
Applied to v4.11/dt
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge
From: Peter Senna Tschudin @ 2017-01-02 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4232c88a99f44a24287d04d74b891e2eb139864c.1483301745.git.peter.senna@collabora.com>
On 01 January, 2017 21:24 CET, Peter Senna Tschudin <peter.senna@collabora.com> wrote:
[ ... ]
> +static void ge_b850v3_lvds_dp_detach(struct drm_bridge *bridge)
> +{
> + struct ge_b850v3_lvds_dp *ptn_bridge
> + = bridge_to_ge_b850v3_lvds_dp(bridge);
> + struct i2c_client *ge_b850v3_lvds_dp_i2c
> + = ptn_bridge->ge_b850v3_lvds_dp_i2c;
> +
> + /* Disable interrupts */
> + i2c_smbus_write_word_data(ge_b850v3_lvds_dp_i2c,
> + STDP4028_DPTX_IRQ_EN_REG, ~STDP4028_DPTX_IRQ_CONFIG);
~STDP4028_DPTX_IRQ_CONFIG? Argh! Will fix this and resend after reviews...
[ ... ]
^ permalink raw reply
* [PATCH v7 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
From: Sekhar Nori @ 2017-01-02 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0ad07b84-7f5a-6467-e310-52c3efc66d3d@ti.com>
On Wednesday 14 December 2016 03:24 PM, Tomi Valkeinen wrote:
> On 13/12/16 12:09, Bartosz Golaszewski wrote:
>> Add the vga-bridge node to the board DT together with corresponding
>> ports and vga connector. This allows to retrieve the edid info from
>> the display automatically.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> ---
>> arch/arm/boot/dts/da850-lcdk.dts | 51 ++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 51 insertions(+)
>
> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Applied to v4.11/dt with Tomi's reviewed-by.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx
From: Nicolas Ferre @ 2017-01-02 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213162756.16139-1-richard.genoud@gmail.com>
Le 13/12/2016 ? 17:27, Richard Genoud a ?crit :
> If we don't disable the transmitter in atmel_stop_tx, the DMA buffer
> continues to send data until it is emptied.
> This cause problems with the flow control (CTS is asserted and data are
> still sent).
>
> So, disabling the transmitter in atmel_stop_tx is a sane thing to do.
>
> Tested on at91sam9g35-cm(DMA)
> Tested for regressions on sama5d2-xplained(Fifo) and at91sam9g20ek(PDC)
>
> Cc: <stable@vger.kernel.org> (beware, this won't apply before 4.3)
> Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/tty/serial/atmel_serial.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> NB: this is not for the 4.10 merge window, I'm just sending it now to
> have some comments if someone is againts it.
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 168b10cad47b..f9d42de5ab2d 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -481,6 +481,14 @@ static void atmel_stop_tx(struct uart_port *port)
> /* disable PDC transmit */
> atmel_uart_writel(port, ATMEL_PDC_PTCR, ATMEL_PDC_TXTDIS);
> }
> +
> + /*
> + * Disable the transmitter.
> + * This is mandatory when DMA is used, otherwise the DMA buffer
> + * is fully transmitted.
> + */
> + atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXDIS);
> +
> /* Disable interrupts */
> atmel_uart_writel(port, ATMEL_US_IDR, atmel_port->tx_done_mask);
>
> @@ -513,6 +521,9 @@ static void atmel_start_tx(struct uart_port *port)
>
> /* Enable interrupts */
> atmel_uart_writel(port, ATMEL_US_IER, atmel_port->tx_done_mask);
> +
> + /* re-enable the transmitter */
> + atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN);
> }
>
> /*
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Sekhar Nori @ 2017-01-02 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dbb47a8f-07be-19d6-e77b-f5c06fd39c61@codeaurora.org>
Hi Archit,
On Wednesday 14 December 2016 10:35 AM, Archit Taneja wrote:
>
>
> On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
>> THS8135 is a configurable video DAC, but no configuration is actually
>> necessary to make it work.
>>
>> For now use the dumb-vga-dac driver to support it.
>
> Queued to drm-misc-next
This patch and 2/5 are not in v4.10 kernel. Did you mean to queue them
to v4.10?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v7 1/5] ARM: dts: da850: rename the display node label
From: Sekhar Nori @ 2017-01-02 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <750eaa32-ca29-b140-eec6-cec4350cf304@ti.com>
On Wednesday 14 December 2016 03:27 PM, Tomi Valkeinen wrote:
> On 13/12/16 12:09, Bartosz Golaszewski wrote:
>> The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
>> The label is also 'display', but change it to 'lcdc' to make it clear
>> what the underlying hardware is.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>> ---
>> arch/arm/boot/dts/da850.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 104155d..6b0ef3d 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -458,7 +458,7 @@
>> dma-names = "tx", "rx";
>> };
>>
>> - display: display at 213000 {
>> + lcdc: display at 213000 {
>> compatible = "ti,da850-tilcdc";
>> reg = <0x213000 0x1000>;
>> interrupts = <52>;
>>
>
> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Applied with Tomi's reviewed-by.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v7 2/2] ARM: davinci: da8xx: Fix sleeping function called from invalid context
From: Sekhar Nori @ 2017-01-02 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481302773-14181-2-git-send-email-abailon@baylibre.com>
On Friday 09 December 2016 10:29 PM, Alexandre Bailon wrote:
> Everytime the usb20 phy is enabled, there is a
> "sleeping function called from invalid context" BUG.
> In addition, there is a recursive locking happening
> because of the recurse call to clk_enable().
>
> clk_enable() from arch/arm/mach-davinci/clock.c uses spin_lock_irqsave()
> before to invoke the callback usb20_phy_clk_enable().
> usb20_phy_clk_enable() uses clk_get() and clk_enable_prepapre()
> which may sleep.
> replace clk_prepare_enable() by davinci_clk_enable().
>
> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
> Suggested-by: David Lechner <david@lechnology.com>
Applied to 'fixes' branch.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v7 1/2] provide lock-less versions of clk_{enable|disable}
From: Sekhar Nori @ 2017-01-02 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5112fcf8-8a10-bfd3-3c37-c3a956eacd15@ti.com>
On Sunday 18 December 2016 09:21 PM, Sekhar Nori wrote:
> ARM: davinci: Make __clk_{enable,disable} functions public
>
> In some cases, there is a need to enable a clock as part of clock
> enable callback of a different clock. For example, USB 2.0 PHY clock
> enable requires USB 2.0 clock to be enabled. In this case, it is safe to
> instead call __clk_enable() since the clock framework lock is already
> taken. calling clk_enable() causes recursive locking error.
>
> A similar case arises in the clock disable path.
>
> To enable such usage, make __clk_{enable,disable} functions publicly
> available outside of clock.c. Also, call them
> davinci_clk_{enable|disable} now to be consistent with how other
> davinci-specific clock functions are named.
>
> Note that these functions are not exported to drivers. They are meant
> for usage in platform specific clock management code.
Applied to 'fixes' with above commit text.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: dts: da850-lcdk: add gpio-keys
From: Sekhar Nori @ 2017-01-02 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482141234-11546-1-git-send-email-bgolaszewski@baylibre.com>
On Monday 19 December 2016 03:23 PM, Bartosz Golaszewski wrote:
> Add a gpio-keys node for two user buttons present on the board.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied to v4.11/dt
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: imx: Add rtc support to i.MX31 PDK board.
From: Fabio Estevam @ 2017-01-02 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483352282-28970-1-git-send-email-lilja.magnus@gmail.com>
On Mon, Jan 2, 2017 at 8:18 AM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
> Enable support for i.MX31 RTC on the PDK board.
>
> Tested on actual hardware.
>
> Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH] bus: da850-mstpri: fix my e-mail address
From: Sekhar Nori @ 2017-01-02 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482141491-26924-1-git-send-email-bgolaszewski@baylibre.com>
On Monday 19 December 2016 03:28 PM, Bartosz Golaszewski wrote:
> I noticed my e-mail address is wrong in this one. This patch fixes it.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied to v4.11/fixes-non-critical
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: imx: Add rtc support to i.MX31 PDK board.
From: Magnus Lilja @ 2017-01-02 10:18 UTC (permalink / raw)
To: linux-arm-kernel
Enable support for i.MX31 RTC on the PDK board.
Tested on actual hardware.
Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
---
arch/arm/mach-imx/mach-mx31_3ds.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-imx/mach-mx31_3ds.c b/arch/arm/mach-imx/mach-mx31_3ds.c
index 12b8a52..c6a12ac 100644
--- a/arch/arm/mach-imx/mach-mx31_3ds.c
+++ b/arch/arm/mach-imx/mach-mx31_3ds.c
@@ -710,6 +710,7 @@ static void __init mx31_3ds_init(void)
imx31_add_imx_keypad(&mx31_3ds_keymap_data);
imx31_add_imx2_wdt();
+ imx31_add_mxc_rtc();
imx31_add_imx_i2c0(&mx31_3ds_i2c0_data);
imx31_add_spi_imx0(&spi0_pdata);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 4/4] ARM: da850: fix da850_set_pll0rate()
From: Sekhar Nori @ 2017-01-02 10:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481124138-27337-5-git-send-email-bgolaszewski@baylibre.com>
On Wednesday 07 December 2016 08:52 PM, Bartosz Golaszewski wrote:
> This function is confusing - its second argument is an index to the
> freq table, not the requested clock rate in Hz, but it's used as the
> set_rate callback for the pll0 clock. It leads to an oops when the
> caller doesn't know the internals and passes the rate in Hz as
> argument instead of the cpufreq index since this argument isn't bounds
> checked either.
>
> Fix it by iterating over the array of supported frequencies and
> selecting a one that matches or returning -EINVAL for unsupported
> rates.
>
> Also: update the davinci cpufreq driver. It's the only user of this
> clock and currently it passes the cpufreq table index to
> clk_set_rate(), which is confusing. Make it pass the requested clock
> rate in Hz.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied to v4.11/fixes-non-critical
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2] drivers: remoteproc: constify rproc_ops structures
From: Bjorn Andersson @ 2017-01-02 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483267417-7850-1-git-send-email-bhumirks@gmail.com>
On Sun 01 Jan 02:43 PST 2017, Bhumika Goyal wrote:
> Declare rproc_ops structures as const as they are only passed as an
> argument to the function rproc_alloc. This argument is of type const, so
> rproc_ops structures having this property can be declared const too.
Thanks Bhumika, applied.
Regards,
Bjorn
^ permalink raw reply
* [RFC 1/4] mm: remove unused TASK_SIZE_OF()
From: Kirill A. Shutemov @ 2017-01-02 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161230155634.8692-2-dsafonov@virtuozzo.com>
On Fri, Dec 30, 2016 at 06:56:31PM +0300, Dmitry Safonov wrote:
> All users of TASK_SIZE_OF(tsk) have migrated to mm->task_size or
> TASK_SIZE_MAX since:
> commit d696ca016d57 ("x86/fsgsbase/64: Use TASK_SIZE_MAX for
> FSBASE/GSBASE upper limits"),
> commit a06db751c321 ("pagemap: check permissions and capabilities at
> open time"),
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-mips at linux-mips.org
> Cc: linux-parisc at vger.kernel.org
> Cc: linuxppc-dev at lists.ozlabs.org
> Cc: linux-s390 at vger.kernel.org
> Cc: sparclinux at vger.kernel.org
> Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
I've noticed this too.
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
--
Kirill A. Shutemov
^ permalink raw reply
* How should we handle variable address space sizes (Re: [RFC 3/4] x86/mm: define TASK_SIZE as current->mm->task_size)
From: Kirill A. Shutemov @ 2017-01-02 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALCETrXMCVOmVcQYxF_ghPdEjLuNNqbcnoRKRVpJegsQ=SPEFQ@mail.gmail.com>
On Fri, Dec 30, 2016 at 06:11:05PM -0800, Andy Lutomirski wrote:
> On Fri, Dec 30, 2016 at 7:56 AM, Dmitry Safonov <dsafonov@virtuozzo.com> wrote:
> > Keep task's virtual address space size as mm_struct field which
> > exists for a long time - it's initialized in setup_new_exec()
> > depending on the new task's personality.
> > This way TASK_SIZE will always be the same as current->mm->task_size.
> > Previously, there could be an issue about different values of
> > TASK_SIZE and current->mm->task_size: e.g, a 32-bit process can unset
> > ADDR_LIMIT_3GB personality (with personality syscall) and
> > so TASK_SIZE will be 4Gb, which is larger than mm->task_size = 3Gb.
> > As TASK_SIZE *and* current->mm->task_size are used both in code
> > frequently, this difference creates a subtle situations, for example:
> > one can mmap addresses > 3Gb, but they will be hidden in
> > /proc/pid/pagemap as it checks mm->task_size.
> > I've moved initialization of mm->task_size earlier in setup_new_exec()
> > as arch_pick_mmap_layout() initializes mmap_legacy_base with
> > TASK_UNMAPPED_BASE, which depends on TASK_SIZE.
>
> I don't like this patch so much because I think that we should figure
> out how this will all work in the long run first. I've added some
> more people to the thread because other arches have similar issues and
> because x86 is about to get considerably more complicated (choices
> include 3GB, 4GB, 47-bit, and 56-bit (the latter IIRC)).
>
> Here are a few of my thoughts on the matter. This isn't all that well
> thought out:
>
> The address space limit, especially if CRIU is in play, isn't really a
> hard limit. For example, you could allocate high memory then lower
> the limit. Similarly, I see no reason that an x32 program should be
> forbidden from mapping some high addresses or, similarly, that an i386
> program can't (if it really wanted to) do a 64-bit mmap() and get a
> high address.
>
> On that note, can we just *delete* the task_size check from pagemap?
> It's been there since the very beginning:
>
> commit 85863e475e59afb027b0113290e3796ee6020b7d
> Author: Matt Mackall <mpm@selenic.com>
> Date: Mon Feb 4 22:29:04 2008 -0800
>
> maps4: add /proc/pid/pagemap interface
>
> and there's no explanation for why it's needed.
>
> So maybe we should have a *number* (not a bit) that indicates the
> maximum address that mmap() will return unless an override is in use.
> Since common practice seems to be to stick this in the personality
> field, we may need some fancy encoding. Executing a setuid binary
> needs to reset to the default, and personality handles that.
If we want to be able to specify arbitrary address as maximum, a fancy
encoding would need to claim 51 bits (63 VA - 12 in-page address) on x86
from the persona flag.
To me, it's stretching personality interface too far.
Maybe it's easier to reset the rlimit for suid binaries?
--
Kirill A. Shutemov
^ permalink raw reply
* [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
From: Rafal Ozieblo @ 2017-01-02 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481720175-12703-1-git-send-email-andrei.pistirica@microchip.com>
> -----Original Message-----
> From: Rafal Ozieblo
> Sent: 28 grudnia 2016 14:23
> Subject: RE: [RFC PATCH net-next v4 1/2] macb: Add 1588 support in Cadence GEM.
>
> > +static void gem_ptp_tx_hwtstamp(struct macb *bp, struct sk_buff *skb,
> > + int peer_ev)
> > +{
> > + struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
> > + struct timespec64 ts;
> > + u64 ns;
> > +
> > + /* PTP Peer Event Frame packets */
> > + if (peer_ev) {
> > + ts.tv_sec = gem_readl(bp, PEFTSL);
> > + ts.tv_nsec = gem_readl(bp, PEFTN);
> > +
> > + /* PTP Event Frame packets */
> > + } else {
> > + ts.tv_sec = gem_readl(bp, EFTSL);
> > + ts.tv_nsec = gem_readl(bp, EFTN);
> > + }
> I'm wondering what is a difference between timestamp in transmit buffer descriptor (Word 2 and 3) and PTP Event Frame Transmitted Seconds/Nanoseconds Register (0x1E0, 0x1E4).
>
According Cadence Hardware team:
"It is just that some customers prefer to have the time in the descriptors as that is provided per frame.
The registers are simply overwritten when a new event frame is transmitted/received and so software could miss it."
The question is are you sure that you read timestamp for current frame? (not for the next frame).
^ 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