* [PATCH v2 2/5] arm64: Work around Falkor erratum 1003
From: Timur Tabi @ 2017-01-06 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fd82e2bf-5259-2fda-c931-1996387d779f@codeaurora.org>
Christopher Covington wrote:
>> > Looks like you've made an unrelated whitespace change that affected the entire table,
>> > not just the line you're adding.
> I'm making space for "QCOM_FALKOR_ERRATUM_1003".
Ok, but you're also shrinking the other columns. I think a better
solution is to make the macro shorter. QCOM_ERRATUM_FLK1003?
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
^ permalink raw reply
* [PATCH v2 4/5] arm64: Use __tlbi_dsb() macros in KVM code
From: Christopher Covington @ 2017-01-06 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103155756.GB14183@leverpostej>
On 01/03/2017 10:57 AM, Mark Rutland wrote:
> On Thu, Dec 29, 2016 at 05:43:34PM -0500, Christopher Covington wrote:
>> Refactor the KVM code to use the newly introduced __tlbi_dsb macros, which
>> will allow an errata workaround that repeats tlbi dsb sequences to only
>> change one location. This is not intended to change the generated assembly
>> and comparing before and after vmlinux objdump shows no functional changes.
@@ -32,7 +33,7 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
* whole of Stage-1. Weep...
*/
ipa >>= 12;
- asm volatile("tlbi ipas2e1is, %0" : : "r" (ipa));
+ __tlbi_dsb(ipas2e1is, ish, ipa);
/*
* We have to ensure completion of the invalidation at Stage-2,
>> @@ -40,9 +41,7 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
>> * complete (S1 + S2) walk based on the old Stage-2 mapping if
>> * the Stage-1 invalidation happened first.
>> */
>> - dsb(ish);
>
> Looks like this got accidentally removed. AFAICT it is still necessary.
Not removed, just hoisted above the comment block to the previous patch hunk.
>> - asm volatile("tlbi vmalle1is" : : );
>> - dsb(ish);
>> + __tlbi_dsb(vmalle1is, ish);
>> isb();
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 0/3] STM32F4 Clock binding fix & update
From: gabriel.fernandez at st.com @ 2017-01-06 15:52 UTC (permalink / raw)
To: linux-arm-kernel
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch-set includes:
- a fix to STM32F4_XXXX_CLOCK() macro
- an update of missing binding definition
- a patch to use STM32F4_XXXX_CLOCK() macro
Gabriel Fernandez (3):
dt-bindings: mfd: stm32f4: Fix STM32F4_XXXX_CLOCK() macro
dt-bindings: mfd: stm32f4: Add missing binding definition
ARM: dts: stm32: Use clock DT binding definition on stm32f429 family
arch/arm/boot/dts/stm32429i-eval.dts | 2 +-
arch/arm/boot/dts/stm32f429.dtsi | 66 +++++++++++++++++++----------------
include/dt-bindings/mfd/stm32f4-rcc.h | 24 +++++++++----
3 files changed, 53 insertions(+), 39 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH 1/3] dt-bindings: mfd: stm32f4: Fix STM32F4_XXXX_CLOCK() macro
From: gabriel.fernandez at st.com @ 2017-01-06 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483717934-21415-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
Macro to select a clock was not correct.
Offset of enable register starts at 0x30, then calculation to select
a bit is:
(@enable_reg - 0x30) / 4 * 32 + bit_to_select
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
Tested-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
---
include/dt-bindings/mfd/stm32f4-rcc.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h
index e98942d..f662b19 100644
--- a/include/dt-bindings/mfd/stm32f4-rcc.h
+++ b/include/dt-bindings/mfd/stm32f4-rcc.h
@@ -25,7 +25,7 @@
#define STM32F4_RCC_AHB1_OTGHS 29
#define STM32F4_AHB1_RESET(bit) (STM32F4_RCC_AHB1_##bit + (0x10 * 8))
-#define STM32F4_AHB1_CLOCK(bit) (STM32F4_RCC_AHB1_##bit + (0x30 * 8))
+#define STM32F4_AHB1_CLOCK(bit) (STM32F4_RCC_AHB1_##bit)
/* AHB2 */
@@ -36,13 +36,13 @@
#define STM32F4_RCC_AHB2_OTGFS 7
#define STM32F4_AHB2_RESET(bit) (STM32F4_RCC_AHB2_##bit + (0x14 * 8))
-#define STM32F4_AHB2_CLOCK(bit) (STM32F4_RCC_AHB2_##bit + (0x34 * 8))
+#define STM32F4_AHB2_CLOCK(bit) (STM32F4_RCC_AHB2_##bit + 0x20)
/* AHB3 */
#define STM32F4_RCC_AHB3_FMC 0
#define STM32F4_AHB3_RESET(bit) (STM32F4_RCC_AHB3_##bit + (0x18 * 8))
-#define STM32F4_AHB3_CLOCK(bit) (STM32F4_RCC_AHB3_##bit + (0x38 * 8))
+#define STM32F4_AHB3_CLOCK(bit) (STM32F4_RCC_AHB3_##bit + 0x40)
/* APB1 */
#define STM32F4_RCC_APB1_TIM2 0
@@ -72,7 +72,7 @@
#define STM32F4_RCC_APB1_UART8 31
#define STM32F4_APB1_RESET(bit) (STM32F4_RCC_APB1_##bit + (0x20 * 8))
-#define STM32F4_APB1_CLOCK(bit) (STM32F4_RCC_APB1_##bit + (0x40 * 8))
+#define STM32F4_APB1_CLOCK(bit) (STM32F4_RCC_APB1_##bit + 0x80)
/* APB2 */
#define STM32F4_RCC_APB2_TIM1 0
@@ -93,6 +93,6 @@
#define STM32F4_RCC_APB2_LTDC 26
#define STM32F4_APB2_RESET(bit) (STM32F4_RCC_APB2_##bit + (0x24 * 8))
-#define STM32F4_APB2_CLOCK(bit) (STM32F4_RCC_APB2_##bit + (0x44 * 8))
+#define STM32F4_APB2_CLOCK(bit) (STM32F4_RCC_APB2_##bit + 0xA0)
#endif /* _DT_BINDINGS_MFD_STM32F4_RCC_H */
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: mfd: stm32f4: Add missing binding definition
From: gabriel.fernandez at st.com @ 2017-01-06 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483717934-21415-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch adds missing binding definition (backupram, ethernet, otg,
qspi, adc & dsi)
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
include/dt-bindings/mfd/stm32f4-rcc.h | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/dt-bindings/mfd/stm32f4-rcc.h b/include/dt-bindings/mfd/stm32f4-rcc.h
index f662b19..082a81c 100644
--- a/include/dt-bindings/mfd/stm32f4-rcc.h
+++ b/include/dt-bindings/mfd/stm32f4-rcc.h
@@ -18,11 +18,17 @@
#define STM32F4_RCC_AHB1_GPIOJ 9
#define STM32F4_RCC_AHB1_GPIOK 10
#define STM32F4_RCC_AHB1_CRC 12
+#define STM32F4_RCC_AHB1_BKPSRAM 18
+#define STM32F4_RCC_AHB1_CCMDATARAM 20
#define STM32F4_RCC_AHB1_DMA1 21
#define STM32F4_RCC_AHB1_DMA2 22
#define STM32F4_RCC_AHB1_DMA2D 23
#define STM32F4_RCC_AHB1_ETHMAC 25
-#define STM32F4_RCC_AHB1_OTGHS 29
+#define STM32F4_RCC_AHB1_ETHMACTX 26
+#define STM32F4_RCC_AHB1_ETHMACRX 27
+#define STM32F4_RCC_AHB1_ETHMACPTP 28
+#define STM32F4_RCC_AHB1_OTGHS 29
+#define STM32F4_RCC_AHB1_OTGHSULPI 30
#define STM32F4_AHB1_RESET(bit) (STM32F4_RCC_AHB1_##bit + (0x10 * 8))
#define STM32F4_AHB1_CLOCK(bit) (STM32F4_RCC_AHB1_##bit)
@@ -40,6 +46,7 @@
/* AHB3 */
#define STM32F4_RCC_AHB3_FMC 0
+#define STM32F4_RCC_AHB3_QSPI 1
#define STM32F4_AHB3_RESET(bit) (STM32F4_RCC_AHB3_##bit + (0x18 * 8))
#define STM32F4_AHB3_CLOCK(bit) (STM32F4_RCC_AHB3_##bit + 0x40)
@@ -79,7 +86,9 @@
#define STM32F4_RCC_APB2_TIM8 1
#define STM32F4_RCC_APB2_USART1 4
#define STM32F4_RCC_APB2_USART6 5
-#define STM32F4_RCC_APB2_ADC 8
+#define STM32F4_RCC_APB2_ADC1 8
+#define STM32F4_RCC_APB2_ADC2 9
+#define STM32F4_RCC_APB2_ADC3 10
#define STM32F4_RCC_APB2_SDIO 11
#define STM32F4_RCC_APB2_SPI1 12
#define STM32F4_RCC_APB2_SPI4 13
@@ -91,6 +100,7 @@
#define STM32F4_RCC_APB2_SPI6 21
#define STM32F4_RCC_APB2_SAI1 22
#define STM32F4_RCC_APB2_LTDC 26
+#define STM32F4_RCC_APB2_DSI 27
#define STM32F4_APB2_RESET(bit) (STM32F4_RCC_APB2_##bit + (0x24 * 8))
#define STM32F4_APB2_CLOCK(bit) (STM32F4_RCC_APB2_##bit + 0xA0)
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: stm32: Use clock DT binding definition on stm32f429 family
From: gabriel.fernandez at st.com @ 2017-01-06 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483717934-21415-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch uses clock DT binding definition instead numerical values
for stm32f429 board.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
arch/arm/boot/dts/stm32429i-eval.dts | 2 +-
arch/arm/boot/dts/stm32f429.dtsi | 66 +++++++++++++++++++-----------------
2 files changed, 36 insertions(+), 32 deletions(-)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index 76f7206..4e31881 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -107,7 +107,7 @@
usbotg_hs_phy: usbphy {
#phy-cells = <0>;
compatible = "usb-nop-xceiv";
- clocks = <&rcc 0 30>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(OTGHSULPI)>;
clock-names = "main_clk";
};
};
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 041e3fc..1bacdfb 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -49,6 +49,7 @@
#include "armv7-m.dtsi"
#include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
#include <dt-bindings/clock/stm32fx-clock.h>
+#include <dt-bindings/mfd/stm32f4-rcc.h>
/ {
clocks {
@@ -82,7 +83,7 @@
compatible = "st,stm32-timer";
reg = <0x40000000 0x400>;
interrupts = <28>;
- clocks = <&rcc 0 128>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM2)>;
status = "disabled";
};
@@ -90,7 +91,7 @@
compatible = "st,stm32-timer";
reg = <0x40000400 0x400>;
interrupts = <29>;
- clocks = <&rcc 0 129>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM3)>;
status = "disabled";
};
@@ -98,7 +99,7 @@
compatible = "st,stm32-timer";
reg = <0x40000800 0x400>;
interrupts = <30>;
- clocks = <&rcc 0 130>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM4)>;
status = "disabled";
};
@@ -106,14 +107,14 @@
compatible = "st,stm32-timer";
reg = <0x40000c00 0x400>;
interrupts = <50>;
- clocks = <&rcc 0 131>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM5)>;
};
timer6: timer at 40001000 {
compatible = "st,stm32-timer";
reg = <0x40001000 0x400>;
interrupts = <54>;
- clocks = <&rcc 0 132>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM6)>;
status = "disabled";
};
@@ -121,7 +122,7 @@
compatible = "st,stm32-timer";
reg = <0x40001400 0x400>;
interrupts = <55>;
- clocks = <&rcc 0 133>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM7)>;
status = "disabled";
};
@@ -129,7 +130,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004400 0x400>;
interrupts = <38>;
- clocks = <&rcc 0 145>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART2)>;
status = "disabled";
};
@@ -137,7 +138,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004800 0x400>;
interrupts = <39>;
- clocks = <&rcc 0 146>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART3)>;
status = "disabled";
dmas = <&dma1 1 4 0x400 0x0>,
<&dma1 3 4 0x400 0x0>;
@@ -148,7 +149,7 @@
compatible = "st,stm32-uart";
reg = <0x40004c00 0x400>;
interrupts = <52>;
- clocks = <&rcc 0 147>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART4)>;
status = "disabled";
};
@@ -156,7 +157,7 @@
compatible = "st,stm32-uart";
reg = <0x40005000 0x400>;
interrupts = <53>;
- clocks = <&rcc 0 148>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART5)>;
status = "disabled";
};
@@ -164,7 +165,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40007800 0x400>;
interrupts = <82>;
- clocks = <&rcc 0 158>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART7)>;
status = "disabled";
};
@@ -172,7 +173,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40007c00 0x400>;
interrupts = <83>;
- clocks = <&rcc 0 159>;
+ clocks = <&rcc 0 STM32F4_APB1_CLOCK(UART8)>;
status = "disabled";
};
@@ -180,7 +181,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40011000 0x400>;
interrupts = <37>;
- clocks = <&rcc 0 164>;
+ clocks = <&rcc 0 STM32F4_APB2_CLOCK(USART1)>;
status = "disabled";
dmas = <&dma2 2 4 0x400 0x0>,
<&dma2 7 4 0x400 0x0>;
@@ -191,7 +192,7 @@
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40011400 0x400>;
interrupts = <71>;
- clocks = <&rcc 0 165>;
+ clocks = <&rcc 0 STM32F4_APB2_CLOCK(USART6)>;
status = "disabled";
};
@@ -226,7 +227,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x0 0x400>;
- clocks = <&rcc 0 0>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOA)>;
st,bank-name = "GPIOA";
};
@@ -234,7 +235,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x400 0x400>;
- clocks = <&rcc 0 1>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOB)>;
st,bank-name = "GPIOB";
};
@@ -242,7 +243,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x800 0x400>;
- clocks = <&rcc 0 2>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOC)>;
st,bank-name = "GPIOC";
};
@@ -250,7 +251,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0xc00 0x400>;
- clocks = <&rcc 0 3>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOD)>;
st,bank-name = "GPIOD";
};
@@ -258,7 +259,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x1000 0x400>;
- clocks = <&rcc 0 4>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOE)>;
st,bank-name = "GPIOE";
};
@@ -266,7 +267,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x1400 0x400>;
- clocks = <&rcc 0 5>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOF)>;
st,bank-name = "GPIOF";
};
@@ -274,7 +275,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x1800 0x400>;
- clocks = <&rcc 0 6>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOG)>;
st,bank-name = "GPIOG";
};
@@ -282,7 +283,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x1c00 0x400>;
- clocks = <&rcc 0 7>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOH)>;
st,bank-name = "GPIOH";
};
@@ -290,7 +291,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x2000 0x400>;
- clocks = <&rcc 0 8>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOI)>;
st,bank-name = "GPIOI";
};
@@ -298,7 +299,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x2400 0x400>;
- clocks = <&rcc 0 9>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOJ)>;
st,bank-name = "GPIOJ";
};
@@ -306,7 +307,7 @@
gpio-controller;
#gpio-cells = <2>;
reg = <0x2800 0x400>;
- clocks = <&rcc 0 10>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(GPIOK)>;
st,bank-name = "GPIOK";
};
@@ -384,7 +385,7 @@
<16>,
<17>,
<47>;
- clocks = <&rcc 0 21>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(DMA1)>;
#dma-cells = <4>;
};
@@ -399,7 +400,7 @@
<68>,
<69>,
<70>;
- clocks = <&rcc 0 22>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(DMA2)>;
#dma-cells = <4>;
st,mem2mem;
};
@@ -411,7 +412,9 @@
interrupts = <61>;
interrupt-names = "macirq";
clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx";
- clocks = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(ETHMAC)>,
+ <&rcc 0 STM32F4_AHB1_CLOCK(ETHMACTX)>,
+ <&rcc 0 STM32F4_AHB1_CLOCK(ETHMACRX)>;
st,syscon = <&syscfg 0x4>;
snps,pbl = <8>;
snps,mixed-burst;
@@ -422,7 +425,7 @@
compatible = "snps,dwc2";
reg = <0x40040000 0x40000>;
interrupts = <77>;
- clocks = <&rcc 0 29>;
+ clocks = <&rcc 0 STM32F4_AHB1_CLOCK(OTGHS)>;
clock-names = "otg";
status = "disabled";
};
@@ -431,12 +434,13 @@
compatible = "st,stm32-rng";
reg = <0x50060800 0x400>;
interrupts = <80>;
- clocks = <&rcc 0 38>;
+ clocks = <&rcc 0 STM32F4_AHB2_CLOCK(RNG)>;
+
};
};
};
&systick {
- clocks = <&rcc 1 0>;
+ clocks = <&rcc 1 SYSTICK>;
status = "okay";
};
--
1.9.1
^ permalink raw reply related
* [PATCH v3 5/5] drm/rockchip: Implement CRC debugfs API
From: Sean Paul @ 2017-01-06 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106143029.11553-6-tomeu.vizoso@collabora.com>
On Fri, Jan 6, 2017 at 9:30 AM, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
> Implement the .set_crc_source() callback and call the DP helpers
> accordingly to start and stop CRC capture.
>
> This is only done if this CRTC is currently using the eDP connector.
>
> v3: Remove superfluous check on rockchip_crtc_state->output_type
>
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> ---
>
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 48 +++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index fb5f001f51c3..5e19bef6d5b4 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -19,6 +19,7 @@
> #include <drm/drm_crtc_helper.h>
> #include <drm/drm_flip_work.h>
> #include <drm/drm_plane_helper.h>
> +#include <drm/bridge/analogix_dp.h>
>
> #include <linux/kernel.h>
> #include <linux/module.h>
> @@ -1105,6 +1106,52 @@ static void vop_crtc_destroy_state(struct drm_crtc *crtc,
> kfree(s);
> }
>
> +static struct drm_connector *vop_get_edp_connector(struct vop *vop)
> +{
> + struct drm_crtc *crtc = &vop->crtc;
> + struct drm_connector *connector;
> +
> + mutex_lock(&crtc->dev->mode_config.mutex);
> + drm_for_each_connector(connector, crtc->dev)
> + if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> + mutex_unlock(&crtc->dev->mode_config.mutex);
> + return connector;
> + }
> + mutex_unlock(&crtc->dev->mode_config.mutex);
> +
> + return NULL;
> +}
> +
> +static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
> + const char *source_name, size_t *values_cnt)
> +{
> + struct vop *vop = to_vop(crtc);
> + struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc->state);
> + struct drm_connector *connector;
> + int ret;
> +
> + connector = vop_get_edp_connector(vop);
> + if (!connector)
> + return -EINVAL;
> +
> + *values_cnt = 3;
> +
> + if (source_name &&
> + strcmp(source_name, "auto") == 0) {
> +
> + if (s->output_type != DRM_MODE_CONNECTOR_eDP)
> + return -EINVAL;
> +
> + ret = analogix_dp_start_crc(connector);
To pick up my thoughts from 1/5, you could do the following instead:
analogix_dp_start_crc(drm_crtc_index(crtc));
> + } else if (!source_name)
> +
> + ret = analogix_dp_stop_crc(connector);
> + else
> + ret = -EINVAL;
> +
> + return ret;
> +}
> +
> static const struct drm_crtc_funcs vop_crtc_funcs = {
> .set_config = drm_atomic_helper_set_config,
> .page_flip = drm_atomic_helper_page_flip,
> @@ -1112,6 +1159,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
> .reset = vop_crtc_reset,
> .atomic_duplicate_state = vop_crtc_duplicate_state,
> .atomic_destroy_state = vop_crtc_destroy_state,
> + .set_crc_source = vop_crtc_set_crc_source,
> };
>
> static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
> --
> 2.9.3
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Sean Paul, Software Engineer, Google / Chromium OS
^ permalink raw reply
* [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Tony Lindgren @ 2017-01-06 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483694849.3634.6.camel@phytec.de>
* Teresa Remmet <t.remmet@phytec.de> [170106 01:28]:
> Hello Brian,
>
> Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:
> > On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> > >
> > > * Tony Lindgren <tony@atomide.com> [170105 07:37]:
> > > >
> > > > * Teresa Remmet <t.remmet@phytec.de> [170105 06:57]:
> > > > >
> > > > > To improve NAND safety we updated the partition layout.
> > > > > Added barebox backup partition and removed kernel and oftree
> > > > > partition. They are kept in ubi now.
> > > > What about the users with earlier partition tables?
> > > >
> > > > Please read about "flag day" changes, typically they are not
> > > > acceptable.
> > > Adding Brian and Adam to Cc. Can you guys come up with some
> > > solution on this?
> > I don't have much context for this thread, and no I don't plan to
> > solve
> > your problems for you. But I can provide tips!
> >
> > >
> > > I'm suggesting we leave the kernel nodes empty and let u-boot
> > > populate them, so maybe you guys can discuss this on the related
> > > lists.
> > That's an option. I've worked with platforms that did something like
> > this, and that's really one of the only ways you can handle putting
> > partition information in the device tree. You're really hamstringing
> > yourself when you put all the partition information in the device
> > tree.
> > And it's just dumb once that gets codified in the kernel source tree.
> >
>
> In our case the bootloader does pass the partition table to the kernel.
> So it gets overwritten anyway. This was just more for backup,?
> if someone uses a different bootloader. But I'm fine with removing the
> nand partition table completely from the kernel device tree.
> Same with the SPI nor partition table.
>
> I will send patches for this.
OK thanks! Also thank you Brian for your comments.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 4/5] arm64: Use __tlbi_dsb() macros in KVM code
From: Mark Rutland @ 2017-01-06 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f5020a04-5fc7-26b5-1ded-c58e159bc722@codeaurora.org>
On Fri, Jan 06, 2017 at 10:51:53AM -0500, Christopher Covington wrote:
> On 01/03/2017 10:57 AM, Mark Rutland wrote:
> > On Thu, Dec 29, 2016 at 05:43:34PM -0500, Christopher Covington wrote:
> >> Refactor the KVM code to use the newly introduced __tlbi_dsb macros, which
> >> will allow an errata workaround that repeats tlbi dsb sequences to only
> >> change one location. This is not intended to change the generated assembly
> >> and comparing before and after vmlinux objdump shows no functional changes.
>
> @@ -32,7 +33,7 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
> * whole of Stage-1. Weep...
> */
> ipa >>= 12;
> - asm volatile("tlbi ipas2e1is, %0" : : "r" (ipa));
> + __tlbi_dsb(ipas2e1is, ish, ipa);
>
> /*
> * We have to ensure completion of the invalidation at Stage-2,
>
> >> @@ -40,9 +41,7 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
> >> * complete (S1 + S2) walk based on the old Stage-2 mapping if
> >> * the Stage-1 invalidation happened first.
> >> */
> >> - dsb(ish);
> >
> > Looks like this got accidentally removed. AFAICT it is still necessary.
>
> Not removed, just hoisted above the comment block to the previous patch hunk.
Ah, sorry. I hadn't spotted that it got folded into the __tlbi_dsb()
above.
Given the comment was previously attached to the DSB, it might make more
sense to fold it into the prior comment block, so that it remains
attached to the __tlbi_dsb(), which guarantees the completion that the
comment describes.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Adam Ford @ 2017-01-06 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106160222.GC2630@atomide.com>
On Fri, Jan 6, 2017 at 10:02 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Teresa Remmet <t.remmet@phytec.de> [170106 01:28]:
>> Hello Brian,
>>
>> Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:
>> > On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
>> > >
>> > > * Tony Lindgren <tony@atomide.com> [170105 07:37]:
>> > > >
>> > > > * Teresa Remmet <t.remmet@phytec.de> [170105 06:57]:
>> > > > >
>> > > > > To improve NAND safety we updated the partition layout.
>> > > > > Added barebox backup partition and removed kernel and oftree
>> > > > > partition. They are kept in ubi now.
>> > > > What about the users with earlier partition tables?
>> > > >
>> > > > Please read about "flag day" changes, typically they are not
>> > > > acceptable.
>> > > Adding Brian and Adam to Cc. Can you guys come up with some
>> > > solution on this?
>> > I don't have much context for this thread, and no I don't plan to
>> > solve
>> > your problems for you. But I can provide tips!
>> >
>> > >
>> > > I'm suggesting we leave the kernel nodes empty and let u-boot
>> > > populate them, so maybe you guys can discuss this on the related
>> > > lists.
>> > That's an option. I've worked with platforms that did something like
>> > this, and that's really one of the only ways you can handle putting
>> > partition information in the device tree. You're really hamstringing
>> > yourself when you put all the partition information in the device
>> > tree.
>> > And it's just dumb once that gets codified in the kernel source tree.
>> >
>>
>> In our case the bootloader does pass the partition table to the kernel.
>> So it gets overwritten anyway. This was just more for backup,
>> if someone uses a different bootloader. But I'm fine with removing the
>> nand partition table completely from the kernel device tree.
>> Same with the SPI nor partition table.
>>
>> I will send patches for this.
>
> OK thanks! Also thank you Brian for your comments.
>
Tony - I tested leaving the partition info as-is with the updates from
the bootloader and it works. Would you prefer that I match Brian and
remove the partition table completely, or should I just leave my board
alone?
I am good either way.
> Regards,
>
> Tony
adam
^ permalink raw reply
* [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Tony Lindgren @ 2017-01-06 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xL2n0qsg61i85o7DczanMH1E=HWhNvqUtTH9UhEVBvd8g@mail.gmail.com>
* Adam Ford <aford173@gmail.com> [170106 08:06]:
> On Fri, Jan 6, 2017 at 10:02 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * Teresa Remmet <t.remmet@phytec.de> [170106 01:28]:
> >> Hello Brian,
> >>
> >> Am Donnerstag, den 05.01.2017, 09:56 -0800 schrieb Brian Norris:
> >> > On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> >> > >
> >> > > * Tony Lindgren <tony@atomide.com> [170105 07:37]:
> >> > > >
> >> > > > * Teresa Remmet <t.remmet@phytec.de> [170105 06:57]:
> >> > > > >
> >> > > > > To improve NAND safety we updated the partition layout.
> >> > > > > Added barebox backup partition and removed kernel and oftree
> >> > > > > partition. They are kept in ubi now.
> >> > > > What about the users with earlier partition tables?
> >> > > >
> >> > > > Please read about "flag day" changes, typically they are not
> >> > > > acceptable.
> >> > > Adding Brian and Adam to Cc. Can you guys come up with some
> >> > > solution on this?
> >> > I don't have much context for this thread, and no I don't plan to
> >> > solve
> >> > your problems for you. But I can provide tips!
> >> >
> >> > >
> >> > > I'm suggesting we leave the kernel nodes empty and let u-boot
> >> > > populate them, so maybe you guys can discuss this on the related
> >> > > lists.
> >> > That's an option. I've worked with platforms that did something like
> >> > this, and that's really one of the only ways you can handle putting
> >> > partition information in the device tree. You're really hamstringing
> >> > yourself when you put all the partition information in the device
> >> > tree.
> >> > And it's just dumb once that gets codified in the kernel source tree.
> >> >
> >>
> >> In our case the bootloader does pass the partition table to the kernel.
> >> So it gets overwritten anyway. This was just more for backup,
> >> if someone uses a different bootloader. But I'm fine with removing the
> >> nand partition table completely from the kernel device tree.
> >> Same with the SPI nor partition table.
> >>
> >> I will send patches for this.
> >
> > OK thanks! Also thank you Brian for your comments.
> >
>
> Tony - I tested leaving the partition info as-is with the updates from
> the bootloader and it works. Would you prefer that I match Brian and
> remove the partition table completely, or should I just leave my board
> alone?
>
> I am good either way.
OK. How about let's remove the partitions from kernel for v4.11 as
clean-up then for cases where the bootloader might change them?
Regards,
Tony
^ permalink raw reply
* [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration
From: Lorenzo Pieralisi @ 2017-01-06 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <005f01d26763$450f9cc0$cf2ed640$@codeaurora.org>
On Thu, Jan 05, 2017 at 08:21:53PM +0530, Sricharan wrote:
> Hi,
>
> [...]
>
> >>>
> >>> With the thinking of taking this series through, would it be fine if i
> >>> cleanup the pci configure hanging outside and push it in to
> >>> of/acpi_iommu configure respectively ? This time with all neeeded for
> >>> ACPI added as well. Also on the last post of V4, Lorenzo commented
> >>> that it worked for him, although still the of_match_node equivalent in
> >>> ACPI has to be added. If i can get that, then i will add that as well
> >>> to make this complete.
> >>
> >> Question: I had a look into this and instead of fiddling about with the
> >> linker script entries in ACPI (ie IORT_ACPI_DECLARE - which I hope this
> >> patchset would help remove entirely), I think that the only check we
> >> need in IORT is, depending on what type of SMMU a given device is
> >> connected to, to check if the respective SMMU driver is compiled in the
> >> kernel and it will be probed, _eventually_.
> >>
> >> As Robin said, by the time a device is probed the respective SMMU
> >> devices are already created and registered with IORT kernel code or
> >> they will never be, so to understand if we should defer probing
> >> SMMU device creation is _not_ really a problem in ACPI.
> >>
> >> To check if a SMMU driver is enabled, do we really need a linker
> >> table ?
> >>
> >> Would not a check based on eg:
> >>
> >> /**
> >> * @type: IOMMU IORT node type of the IOMMU a device is connected to
> >> */
> >> static bool iort_iommu_driver_enabled(u8 type)
> >> {
> >> switch (type) {
> >> case ACPI_IORT_SMMU_V3:
> >> return IS_ENABLED(CONFIG_ARM_SMMU_V3);
> >
> >IS_BUILTIN(...)
> >
> >> case ACPI_IORT_SMMU:
> >> return IS_ENABLED(CONFIG_ARM_SMMU);
> >> default:
> >> pr_warn("Unknown IORT SMMU type\n");
> >
> >Might displaying the actual value be helfpul for debugging a broken IORT
> >table?
> >
> >> return false;
> >> }
> >> }
> >>
> >> be sufficient (it is a bit gross, agreed, but it is to understand if
> >> that's all we need) ? Is there anything I am missing ?
> >>
> >> Let me know, I will put together a patch for you I really do not
> >> want to block your series for this trivial niggle.
> >
> >Other than that, though, I like it :) IORT has a small, strictly
> >bounded, set of supported devices, so I really don't see the need to go
> >overboard putting it on parity with DT when something this neat and
> >simple will suffice.
> >
>
> Ok sure, looks correct for me as well in whole of the context here.
Ok, I put together a branch where you can find your original series
plus some ACPI patches for you to test and use:
git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iommu/probe-deferral
Feel free to post the additional patches I added along with your series
(that from what I gather you have reworked already) and please both have a
look if the deferral mechanism I put in place in ACPI makes sense to you.
Please CC linux-acpi upon posting, if you need help shout.
Lorenzo
^ permalink raw reply
* [PATCH 1/2] ARM: mm: fix set_memory_*() bounds checks
From: Dave Gerlach @ 2017-01-06 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129175920.GZ14217@n2100.armlinux.org.uk>
Russell,
On 11/29/2016 11:59 AM, Russell King - ARM Linux wrote:
> On Tue, Nov 29, 2016 at 09:25:19AM -0600, Dave Gerlach wrote:
>> Hi,
>> On 11/21/2016 10:08 AM, Russell King wrote:
>>> +static bool in_range(unsigned long start, unsigned long size,
>>> + unsigned long range_start, unsigned long range_end)
>>> +{
>>> + return start >= range_start && start < range_end &&
>>> + size <= range_end - start;
>>> +}
>>> +
>>> static int change_memory_common(unsigned long addr, int numpages,
>>> pgprot_t set_mask, pgprot_t clear_mask)
>>> {
>>> - unsigned long start = addr;
>>> - unsigned long size = PAGE_SIZE*numpages;
>>> - unsigned long end = start + size;
>>> + unsigned long start = addr & PAGE_SIZE;
>>
>> This doesn't work as is, I believe 'start' should be set to
>> PAGE_ALIGN(addr), addr & PAGE_SIZE as it is doesn't make sense. If I make
>> this change this code works ok.
>
> You're right, but we want to round 'addr' _down_, not up as PAGE_ALIGN()
> will do. So that should've been PAGE_MASK.
>
Do you plan to send an updated version of this patch? I'd be happy to
update it and resend.
Regards,
Dave
^ permalink raw reply
* [PATCH] clk: rockchip: Remove useless init of "grf" to -EPROBE_DEFER
From: Douglas Anderson @ 2017-01-06 16:31 UTC (permalink / raw)
To: linux-arm-kernel
When we used to defer setting the "grf" member to
rockchip_clk_get_grf() it was important to init the "grf" member to an
error value in rockchip_clk_init(). With recent changes, we now set
"grf" right in rockchip_clk_init() (two lines below the place where we
initted it). That makes the old init useless. Get rid of it.
Fixes: 6f339dc2719e ("clk: rockchip: lookup General Register Files in rockchip_clk_init")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
drivers/clk/rockchip/clk.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk.c b/drivers/clk/rockchip/clk.c
index 3abcbf441cc5..fe1d393cf678 100644
--- a/drivers/clk/rockchip/clk.c
+++ b/drivers/clk/rockchip/clk.c
@@ -344,7 +344,6 @@ struct rockchip_clk_provider * __init rockchip_clk_init(struct device_node *np,
ctx->clk_data.clks = clk_table;
ctx->clk_data.clk_num = nr_clks;
ctx->cru_node = np;
- ctx->grf = ERR_PTR(-EPROBE_DEFER);
spin_lock_init(&ctx->lock);
ctx->grf = syscon_regmap_lookup_by_phandle(ctx->cru_node,
--
2.11.0.390.gc69c2f50cf-goog
^ permalink raw reply related
* [RESEND PATCH] ARM: dts: stm32f469-disco: Fix memory size from 8MB to 16MB
From: Alexandre Torgue @ 2017-01-06 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118145845.30455-1-bmh@certi.org.br>
Hi Bruno,
On 11/18/2016 03:58 PM, Bruno Meirelles Herrera wrote:
> From: Bruno Herrera <bruherrera@gmail.com>
>
> This patch fix memory size to support 16MB of external SDRAM.
>
> Signed-off-by: Bruno Herrera <bruherrera@gmail.com>
> ---
> arch/arm/boot/dts/stm32f469-disco.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
> index 75f4303..fda12a4 100644
> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> @@ -58,7 +58,7 @@
> };
>
> memory {
> - reg = <0x00000000 0x800000>;
> + reg = <0x00000000 0x1000000>;
> };
>
> aliases {
>
After a little cosmetic change in commit header:
Applied on stm32-dt-for-v4.11-1
Thanks!
Alex
^ permalink raw reply
* [PATCH] ARM: OMAP1: DMA: Correct the number of logical channels
From: Tony Lindgren @ 2017-01-06 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105214750.g7d6kbaq7q4vgrug@raspberrypi-2.musicnaut.iki.fi>
* Aaro Koskinen <aaro.koskinen@iki.fi> [170105 13:48]:
> Hi,
>
> On Tue, Jan 03, 2017 at 01:22:34PM +0200, Peter Ujfalusi wrote:
> > OMAP1510, OMAP5910 and OMAP310 have only 9 logical channels.
> > OMAP1610, OMAP5912, OMAP1710, OMAP730, and OMAP850 have 16 logical channels
> > available.
> >
> > The wired 17 for the lch_count must have been used to cover the 16 + 1
> > dedicated LCD channel, in reality we can only use 9 or 16 channels.
> >
> > The d->chan_count is not used by the omap-dma stack, so we can skip the
> > setup. chan_count was configured to the number of logical channels and not
> > the actual number of physical channels anyways.
> >
> > Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>
> Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Applying into omap-for-v4.10/fixes thanks.
Tony
^ permalink raw reply
* [RESEND PATCH v1] ARM: dts: stm32f429: Add missing USART3 pin config to STM32F469I-DISCO board
From: Alexandre Torgue @ 2017-01-06 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118151033.30592-1-bmh@certi.org.br>
Hi Bruno,
On 11/18/2016 04:10 PM, Bruno Meirelles Herrera wrote:
> Including new STM32 maintainer. Rebased at stm32-dt-for-v4.10-1 and
> stm32-dt-for-v4.10-2 branches. It fix the port/pin initialization in
> case boot-loader does not configure/initialize the pins.
> Fixing line wrapping from last patch
>
> This patch adds USART3 pin configuration on PB10/PA11 pins
> for STM32F469I-DISCO board.
>
> Signed-off-by: Bruno Herrera <bruherrera@gmail.com>
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 13 +++++++++++++
> arch/arm/boot/dts/stm32f469-disco.dts | 2 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index e4dae0e..1b8b105 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -316,6 +316,19 @@
> };
> };
>
> + usart3_pins_a: usart3 at 0 {
> + pins1 {
> + pinmux = <STM32F429_PB10_FUNC_USART3_TX>;
> + bias-disable;
> + drive-push-pull;
> + slew-rate = <0>;
> + };
> + pins2 {
> + pinmux = <STM32F429_PB11_FUNC_USART3_RX>;
> + bias-disable;
> + };
> + };
> +
> usbotg_hs_pins_a: usbotg_hs at 0 {
> pins {
> pinmux = <STM32F429_PH4_FUNC_OTG_HS_ULPI_NXT>,
> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
> index 8877c00..75f4303 100644
> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> @@ -79,5 +79,7 @@
> };
>
> &usart3 {
> + pinctrl-0 = <&usart3_pins_a>;
> + pinctrl-names = "default";
> status = "okay";
> };
>
After a little cosmetic change in commit header:
Applied on stm32-dt-for-v4.11-1
Thanks!
Alex
^ permalink raw reply
* [PATCH v3] soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread
From: Tony Lindgren @ 2017-01-06 16:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483653615-24378-1-git-send-email-spjoshi@codeaurora.org>
* Sarangdhar Joshi <spjoshi@codeaurora.org> [170105 14:01]:
> The function wkup_m3_rproc_boot_thread waits for asynchronous
> firmware loading to parse the resource table before calling
> rproc_boot(). However, as the resource table parsing has been
> moved to rproc_boot(), there's no need to wait for the
> asynchronous firmware loading completion. So, drop this.
Applying into omap-for-v4.11/drivers thanks.
Tony
^ permalink raw reply
* [PATCH V6 04/10] arm64: exception: handle Synchronous External Abort
From: Baicar, Tyler @ 2017-01-06 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104135413.GE18193@arm.com>
Hi Will,
On 1/4/2017 6:54 AM, Will Deacon wrote:
> On Wed, Dec 07, 2016 at 02:48:17PM -0700, Tyler Baicar wrote:
>> SEA exceptions are often caused by an uncorrected hardware
>> error, and are handled when data abort and instruction abort
>> exception classes have specific values for their Fault Status
>> Code.
>> When SEA occurs, before killing the process, go through
>> the handlers registered in the notification list.
>> Update fault_info[] with specific SEA faults so that the
>> new SEA handler is used.
>>
>> Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org>
>> Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
>> Signed-off-by: Naveen Kaje <nkaje@codeaurora.org>
>> ---
>> arch/arm64/include/asm/system_misc.h | 13 ++++++++
>> arch/arm64/mm/fault.c | 58 +++++++++++++++++++++++++++++-------
>> 2 files changed, 61 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
>> index 57f110b..9040e1d 100644
>> --- a/arch/arm64/include/asm/system_misc.h
>> +++ b/arch/arm64/include/asm/system_misc.h
>> @@ -64,4 +64,17 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
>>
>> #endif /* __ASSEMBLY__ */
>>
>> +/*
>> + * The functions below are used to register and unregister callbacks
>> + * that are to be invoked when a Synchronous External Abort (SEA)
>> + * occurs. An SEA is raised by certain fault status codes that have
>> + * either data or instruction abort as the exception class, and
>> + * callbacks may be registered to parse or handle such hardware errors.
>> + *
>> + * Registered callbacks are run in an interrupt/atomic context. They
>> + * are not allowed to block or sleep.
>> + */
>> +int register_synchronous_ext_abort_notifier(struct notifier_block *nb);
>> +void unregister_synchronous_ext_abort_notifier(struct notifier_block *nb);
> I think that we may as well use the "SEA" acronym consistently in code,
> expanding it only for strings and comments, so these can be renamed to
> {register,unregister}_sea_notifier. That said, what is the use of having a
> notifier chain here as well as in the ghes code? If the ghes code is the
> only place to register a notifier, we may as well start simple and call that
> code directly, like we call handle_mm_fault directly for data aborts.
I originally used the acronym and got feedback to expand it, but I'll
revert back to just using the acronym.
Using a notifier here is consistent with the SCI error type in the GHES
code which is also only registered in
the GHES code. I can remove the notifier for SEA if you think making the
call directly is better here.
>> static const struct fault_info {
>> int (*fn)(unsigned long addr, unsigned int esr, struct pt_regs *regs);
>> int sig;
>> @@ -502,22 +540,22 @@ static const struct fault_info {
>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 permission fault" },
>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 permission fault" },
>> { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 permission fault" },
>> - { do_bad, SIGBUS, 0, "synchronous external abort" },
>> + { do_synch_ext_abort, SIGBUS, 0, "synchronous external abort" },
> Again, just stick with do_sea for the function name...
>
>> { do_bad, SIGBUS, 0, "unknown 17" },
>> { do_bad, SIGBUS, 0, "unknown 18" },
>> { do_bad, SIGBUS, 0, "unknown 19" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous abort (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous parity error" },
>> + { do_synch_ext_abort, SIGBUS, 0, "level 0 SEA (trans tbl walk)" },
> ... but there's no need to abbreviate "translation table walk" here. Long
> strings that run over 80 chars are fine. Similarly for "SEA".
I will expand this in the next patchset.
>> + { do_synch_ext_abort, SIGBUS, 0, "level 1 SEA (trans tbl walk)" },
>> + { do_synch_ext_abort, SIGBUS, 0, "level 2 SEA (trans tbl walk)" },
>> + { do_synch_ext_abort, SIGBUS, 0, "level 3 SEA (trans tbl walk)" },
>> + { do_synch_ext_abort, SIGBUS, 0, "synchronous parity or ECC err" },
>> { do_bad, SIGBUS, 0, "unknown 25" },
>> { do_bad, SIGBUS, 0, "unknown 26" },
>> { do_bad, SIGBUS, 0, "unknown 27" },
>> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
>> - { do_bad, SIGBUS, 0, "synchronous parity error (translation table walk)" },
>> + { do_synch_ext_abort, SIGBUS, 0, "level 0 synch parity error" },
>> + { do_synch_ext_abort, SIGBUS, 0, "level 1 synch parity error" },
>> + { do_synch_ext_abort, SIGBUS, 0, "level 2 synch parity error" },
>> + { do_synch_ext_abort, SIGBUS, 0, "level 3 synch parity error" },
> Please keep mention of "translation table walk", since we have exception
> levels too and it's confusing just saying "level n".
I will add them back in the next patchset.
Thanks,
Tyler
> Will
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 1/1] MMC: meson: avoid possible NULL dereference
From: Kevin Hilman @ 2017-01-06 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161223150108.9229-1-xypron.glpk@gmx.de>
Heinrich Schuchardt <xypron.glpk@gmx.de> writes:
> No actual segmentation faults were observed but the coding is
> at least inconsistent.
>
> irqreturn_t meson_mmc_irq():
>
> We should not dereference host before checking it.
>
> meson_mmc_irq_thread():
>
> If cmd or mrq are NULL we should not dereference them after
> writing a warning.
>
> Fixes: 51c5d8447bd7 MMC: meson: initial support for GX platforms
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Ulf, I assume you can pick this up directly for v4.10-rc?
Thanks,
Kevin
> ---
> drivers/mmc/host/meson-gx-mmc.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index b352760c041e..09739352834c 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -578,13 +578,15 @@ static irqreturn_t meson_mmc_irq(int irq, void *dev_id)
> {
> struct meson_host *host = dev_id;
> struct mmc_request *mrq;
> - struct mmc_command *cmd = host->cmd;
> + struct mmc_command *cmd;
> u32 irq_en, status, raw_status;
> irqreturn_t ret = IRQ_HANDLED;
>
> if (WARN_ON(!host))
> return IRQ_NONE;
>
> + cmd = host->cmd;
> +
> mrq = host->mrq;
>
> if (WARN_ON(!mrq))
> @@ -670,10 +672,10 @@ static irqreturn_t meson_mmc_irq_thread(int irq, void *dev_id)
> int ret = IRQ_HANDLED;
>
> if (WARN_ON(!mrq))
> - ret = IRQ_NONE;
> + return IRQ_NONE;
>
> if (WARN_ON(!cmd))
> - ret = IRQ_NONE;
> + return IRQ_NONE;
>
> data = cmd->data;
> if (data) {
^ permalink raw reply
* [PATCH v11 0/8] power: add power sequence library
From: Krzysztof Kozlowski @ 2017-01-06 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106151841.l6ehqmpben4ilkaf@kozik-lap>
On Fri, Jan 06, 2017 at 05:18:41PM +0200, Krzysztof Kozlowski wrote:
> On Thu, Jan 05, 2017 at 02:01:51PM +0800, Peter Chen wrote:
> > Hi all,
> >
> > This is a follow-up for my last power sequence framework patch set [1].
> > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> > power sequence instances will be added at postcore_initcall, the match
> > criteria is compatible string first, if the compatible string is not
> > matched between dts and library, it will try to use generic power sequence.
> >
> > The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> > if only one power sequence instance is needed, for more power sequences
> > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
> >
> > In future, if there are special power sequence requirements, the special
> > power sequence library can be created.
> >
> > This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> > two hot-plug devices to simulate this use case, the related binding
> > change is updated at patch [1/6], The udoo board changes were tested
> > using my last power sequence patch set.[3]
> >
> > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> > need to power on itself before it can be found by ULPI bus.
> >
> > [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> > [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> > [3] http://www.spinics.net/lists/linux-usb/msg142815.html
> >
>
> Unfortunately I was unable to utilize this library to solve Odroid U3
> usb3503/lan9730 power sequence (as a continuation of my old series [0][1]).
>
> The main problem is that power sequence instance (pwrseq_generic.c) is
> not a device. I don't get why it is not a device. It would be rather
> intuitive to me to make it a device. Also it would make life easier
> because you could use all device-like consumer APIs (of getting clocks,
> GPIOs etc). Since it is not a device, it is not possible to use
> regulator consumer API.
>
> I need a regulator because I need to toggle the power.
>
> Other encountered issue is that power sequence happens early, before the
> unused regulators are turned off by the system. However maybe this is
> the necessity from other point of view.
>
> My case is annoyingly over-complicated so I am slowly getting sertain
> that it is not generic. Anyway it looks like this:
>
> EHCI controller
> |
> |--HSIC0--lan9730 (reset is done only through regulator)
> |--HSIC1--usb3504 (it has a reset GPIO... but it is toggled by
> usb3504 driver)
>
> Overall, I want to reset the lan9730. This can be done only through
> power - buck8. buck8 state is an logical OR of register set by I2C and
> GPIO. Thus to turn it off, it is not sufficient just to set register to
> 0x0 because the GPIO is keeping it on. The best way is to switch the
> buck8 to gpio-enable-control thus only GPIO will be toggling it... still
> through the regulator consumer API (because it is an GPIO for the
> regulator, not for the reset!).
>
> However these two seems coupled. On invalid reset sequence, both chips
> die. The usb3504 has its own existing reset sequence and my findings
> show that it should happen after lan9730 reset sequence. Otherwise all
> devices might be lost...
Update - it's working! I skipped entirely the regulator API and I am
playing with its GPIO. This sounds like a hack but finally after few
days of different tries I was able to find a working, reproducible
solution. It turned out that the yours pwrseq is working quite good.
I'll send a follow-up for my board soon.
Best regards,
Krzysztof
>
> [0] http://www.spinics.net/lists/linux-mmc/msg37386.html
> [1] https://github.com/krzk/linux/commits/for-next/odroid-u3-usb3503-lan-boot-fixes-v4
>
^ permalink raw reply
* [PATCH v6 07/18] iommu: Implement reserved_regions iommu-group sysfs file
From: Auger Eric @ 2017-01-06 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106124816.GQ17255@8bytes.org>
Hi Joerg, Robin,
On 06/01/2017 13:48, Joerg Roedel wrote:
> On Fri, Jan 06, 2017 at 12:46:05PM +0100, Auger Eric wrote:
>> On 06/01/2017 12:00, Joerg Roedel wrote:
>
>>> I think it also makes sense to report the type of the reserved region.
>>
>> What is the best practice in that case? Shall we put the type enum
>> values as strings such as:
>> - direct
>> - nomap
>> - msi
>>
>> and document that in Documentation/ABI/testing/sysfs-kernel-iommu_groups
>
> Yes, a string would be good. An probably 'reserved' is a better name
> than nomap?
the iommu_insert_resv_region() function that builds the group reserved
region list sorts all regions and handles the case where there is an
overlap between regions. Current code does not care about the type of
regions. So in case a NOMAP region overlaps with a direct-mapped region,
what is reported to the user space is the superset and the type depends
on the overlap. This was suggested by Robin at some point to handle
overlaps.
I guess I should merge regions only in case the types equal?
I remember that Alex thought that user-space should not care so much
about the type of the regions so I tought it was better for the
user-space to have a minimal view of the regions.
On the other hand, this issue of merging regions of different types
should not happen often but I prefer to highlight the potential issue.
What is your guidance?
Thanks
Eric
>
>
> Joerg
>
^ permalink raw reply
* [PATCH] net: phy: dp83867: fix irq generation
From: Grygorii Strashko @ 2017-01-06 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <de3c3fb3-1244-76a5-ea5e-8ef1b83f25d4@gmail.com>
On 01/05/2017 04:10 PM, Florian Fainelli wrote:
> On 01/05/2017 12:48 PM, Grygorii Strashko wrote:
>> For proper IRQ generation by DP83867 phy the INT/PWDN pin has to be
>> programmed as an interrupt output instead of a Powerdown input in
>> Configuration Register 3 (CFG3), Address 0x001E, bit 7 INT_OE = 1. The
>> current driver doesn't do this and as result IRQs will not be generated by
>> DP83867 phy even if they are properly configured in DT.
>>
>> Hence, fix IRQ generation by properly configuring CFG3.INT_OE bit and
>> ensure that Link Status Change (LINK_STATUS_CHNG_INT) and Auto-Negotiation
>> Complete (AUTONEG_COMP_INT) interrupt are enabled. After this the DP83867
>> driver will work properly in interrupt enabled mode.
>>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
>> drivers/net/phy/dp83867.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
>> index 1b63924..e84ae08 100644
>> --- a/drivers/net/phy/dp83867.c
>> +++ b/drivers/net/phy/dp83867.c
>> @@ -29,6 +29,7 @@
>> #define MII_DP83867_MICR 0x12
>> #define MII_DP83867_ISR 0x13
>> #define DP83867_CTRL 0x1f
>> +#define DP83867_CFG3 0x1e
>>
>> /* Extended Registers */
>> #define DP83867_RGMIICTL 0x0032
>> @@ -98,6 +99,8 @@ static int dp83867_config_intr(struct phy_device *phydev)
>> micr_status |=
>> (MII_DP83867_MICR_AN_ERR_INT_EN |
>> MII_DP83867_MICR_SPEED_CHNG_INT_EN |
>> + MII_DP83867_MICR_AUTONEG_COMP_INT_EN |
>> + MII_DP83867_MICR_LINK_STS_CHNG_INT_EN |
>> MII_DP83867_MICR_DUP_MODE_CHNG_INT_EN |
>> MII_DP83867_MICR_SLEEP_MODE_CHNG_INT_EN);
>>
>> @@ -214,6 +217,13 @@ static int dp83867_config_init(struct phy_device *phydev)
>> }
>> }
>>
>> + /* Enable Interrupt output INT_OE in CFG3 register */
>> + if (phy_interrupt_is_valid(phydev)) {
>> + val = phy_read(phydev, DP83867_CFG3);
>> + val |= BIT(7);
>> + phy_write(phydev, DP83867_CFG3, val);
>> + }
>
> Don't you need to clear that bit in the case phy_interrupt_is_valid()
> returns false?
Not sure I need to touch it in this case - default value is 0
and Linux will not configure any IRQ.
>
> Other than that:
>
> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>
--
regards,
-grygorii
^ permalink raw reply
* [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Ladislav Michl @ 2017-01-06 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105175619.GA56877@google.com>
On Thu, Jan 05, 2017 at 09:56:20AM -0800, Brian Norris wrote:
[snip]
> The best solution would be to try to migrate away from static device
> tree representations of partition info entirely. UBI volumes are best
> where possible. If not, then some other kind of on-flash data structures
> (along the lines of a GPT) with a corresponding MTD partition parser is
> an OK alternative. Unfortunately, there isn't any good standard format
> for this on MTD, so it's typically all custom -- and so people use the
> easiest approach: device tree. And it's even more difficult with NAND,
> which has reliability problems, especially with static data (e.g., read
> disturb).
Just as a side note, there is some work in this area:
https://www.mail-archive.com/u-boot at lists.denx.de/msg232759.html
> Anyway, the parser solution is helpful only if one can properly fix the
> "flag day" first. And it requires a little bit more work to be generally
> useful; I posted some work for this over a year ago, but bikeshedding
> brought it down.
Best regards,
ladis
^ permalink raw reply
* [RFC PATCH] vring: Force use of DMA API for ARM-based systems
From: Jean-Philippe Brucker @ 2017-01-06 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482246864-16399-1-git-send-email-will.deacon@arm.com>
Hi Will,
On 20/12/16 15:14, Will Deacon wrote:
> Booting Linux on an ARM fastmodel containing an SMMU emulation results
> in an unexpected I/O page fault from the legacy virtio-blk PCI device:
>
> [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
> [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
> [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
> [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
> [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
> [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
> [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
>
> <system hangs failing to read partition table>
>
> This is because the virtio-blk is behind an SMMU, so we have consequently
> swizzled its DMA ops and configured the SMMU to translate accesses. This
> then requires the vring code to use the DMA API to establish translations,
> otherwise all transactions will result in fatal faults and termination.
>
> Given that ARM-based systems only see an SMMU if one is really present
> (the topology is all described by firmware tables such as device-tree or
> IORT), then we can safely use the DMA API for all virtio devices.
There is a problem with the platform block device on that same model.
Since it's not behind the SMMU, the DMA ops fall back to swiotlb, which
limits the number of mappings.
It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size
based on read-ahead setting") unlocked read-ahead, we quickly run into
the limit of swiotlb and panic:
[ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full
(sz: 491520 bytes)
[ 5.382452] virtio-mmio 1c130000.virtio_block: DMA: Out of SW-IOMMU
space for 491520 bytes
[ 5.382531] Kernel panic - not syncing: DMA: Random memory could be
DMA written
...
[ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0
[ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88
[ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88
[ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8
[ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8
...
[ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8
Commit 9491ae4 caps the read-ahead request to a limit set by the backing
device. For virtio-blk, it is infinite (as set by the call to
blk_queue_max_hw_sectors in virtblk_probe).
I'm not sure how to fix this. Setting an arbitrary sector limit in the
virtio-blk driver seems unfair to other users. Maybe we should check if
the device is behind a hardware IOMMU before using the DMA API?
Thanks,
Jean-Philippe
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> drivers/virtio/virtio_ring.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index ed9c9eeedfe5..06b91e29d1b7 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -159,6 +159,10 @@ static bool vring_use_dma_api(struct virtio_device *vdev)
> if (xen_domain())
> return true;
>
> + /* On ARM-based machines, the DMA ops will do the right thing */
> + if (IS_ENABLED(CONFIG_ARM) || IS_ENABLED(CONFIG_ARM64))
> + return true;
> +
> return false;
> }
>
>
^ 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