* [PATCH] drm/exynos: constify exynos_drm_crtc_ops structures
From: Daniel Vetter @ 2017-01-10 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483984493-25284-1-git-send-email-bhumirks@gmail.com>
On Mon, Jan 09, 2017 at 11:24:53PM +0530, Bhumika Goyal wrote:
> Declare exynos_drm_crtc_ops structures as const as they are only passed
> as an argument to the function exynos_drm_crtc_create. This argument is
> of type const struct exynos_drm_crtc_ops *, so exynos_drm_crtc_ops
> structures having this property can be declared const.
> Done using Coccinelle:
>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct exynos_drm_crtc_ops i at p={...};
>
> @ok@
> position p;
> identifier r.i;
> @@
> exynos_drm_crtc_create(...,&i at p,...)
>
> @bad@
> position p!={r.p,ok.p};
> identifier r.i;
> @@
> i at p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> +const
> struct exynos_drm_crtc_ops i;
>
> File size before:
> text data bss dec hex filename
> 5008 280 0 5288 14a8 exynos/exynos5433_drm_decon.o
>
> File size after:
> text data bss dec hex filename
> 5120 176 0 5296 14b0 exynos/exynos5433_drm_decon.o
>
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
Applied to drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 6ca1f31..12b9bf0 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -470,7 +470,7 @@ static void decon_clear_channels(struct exynos_drm_crtc *crtc)
> clk_disable_unprepare(ctx->clks[i]);
> }
>
> -static struct exynos_drm_crtc_ops decon_crtc_ops = {
> +static const struct exynos_drm_crtc_ops decon_crtc_ops = {
> .enable = decon_enable,
> .disable = decon_disable,
> .enable_vblank = decon_enable_vblank,
> --
> 1.9.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
From: John Crispin @ 2017-01-10 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d6bd3783-d124-9871-d3b4-93e366517895@suse.de>
(resend, hit the wrong reply button)
On 10/01/2017 10:48, Andreas F?rber wrote:
> Hi,
>
> Am 10.01.2017 um 08:00 schrieb John Crispin:
>> On 08/01/2017 14:30, Andreas F?rber wrote:
>>>
>>> Andreas F?rber (4):
>>> Documentation: devicetree: Add vendor prefix for AsiaRF
>>> Documentation: devicetree: arm: mediatek: Add Geek Force board
>>> ARM: dts: mt7623: Add Geek Force config
>>> MAINTAINERS: Extend ARM/Mediatek SoC support section
>>>
>>
>> Hi,
>>
>> i need to NAK this series. the asiarf board is nothing more than the
>> official MTK EVB with AsiaRF written on it. this board is already
>> supported by linux (arch/arm/boot/dts/mt7623-evb.dts) please extend the
>> EVB dts file nstead of adding a duplicate and letting the original
bitrot.
>
> Well, I disagree.
reading the rest of the email you seem to be quite agro about this.
>
> First of all I'm not letting "the original" bitrot, because I have
> nothing to do with that .dts! If anyone is to blame for letting it
> bitrot since February 2016, pick your own nose:
>
>
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/mt7623-evb.dts
what should i pick my nose about ? i made mt7623 work, then waited for
4.10-rc1 to be out for clk-mt2701 so that i can continue adding the
missing support
> Second, I have no Mediatek documentation or even picture to identify any
> similarities between my board and that Mediatek EVB, so no, I can't hack
> on the -evb.dts file. I wrote my .dts from scratch, not even having
> access to /proc/device-tree on its 3.10 kernel for comparison.
ok, that info is most likely under NDA
>
> Third, by your argumentation we shouldn't be adding, e.g., Odroid .dts
> files either because they were based on a Samsung SMDK, or .dts files
> for Amlogic TV boxes because they're almost identical to reference
> designs, etc.
> Users need to know which .dts file to choose, so having a sane .dts
> filename is warranted. Depending on how similar they are, one could
> either #include the -evb.dts or factor out a shared .dtsi, but that
> takes us back to the previous point of hardly anyone having access to
> EVB information to identify such a subset. Therefore duplicating trivial
> nodes is the method of choice for all practical purposes - mt7623.dtsi
> is getting reused just fine.
>
in that case add a dtsi file for the EVB and include it in your geek
board.dts and only update the compat string.
> Comparing our two .dts files, mine has two more UART nodes enabled, the
> U-Boot bootloader's baudrate set to actually get serial output, a
> different board compatible string for identification, and I chose the
> new dual-licensing header that is being requested for new DT files.
1) at the time we adde this the uart support was not ready
2) the bootloader i am using is a custom built one hence the random baudrate
3) you can just updae the license if you want to, no problem
> For lack of schematics I figured out UART1 by testing - continuity tests
> for GND, console=ttySx,115200n8 and trial-and-error for RX/TX. Obviously
> I can't do that for a board I don't have access to.
> UART2 and UART0 pins were clear, but only UART2 was obvious from ttyMT2.
you do have the EVB directly in front of you
> Do you actually have access to a Geek Force board yourself, or what are
> you basing your claims on? Mine looks different from the Indiegogo
> picture and thus has different identification from that on
> https://wikidevi.com/wiki/AsiaRF_WS2977 (WS3301, MT7623N RFB_V10).
i dont need the geek board as i have the EVB and they are identical
according to MTK
> If you confirm the EVB's baudrate I can happily send that part your way.
> I've seen 921600 on the Helio X20 96board for instance.
see above
> Also, none of what you've said justifies NAK'ing patch 4/4, which
> applies to any mt7* and arm64 .dts, including yours.
agreed, i never even mentioned 4/4
> While we're at it, I noticed that mainline has a "mediatek,mt7623-eth"
> network driver but no corresponding .dtsi node. Talk about bitrot...
the idea is that we work together to make thins optimal. this is not a
you or is right. this is about the FOSS peer review process. please dont
be so agro.
to me it seems suboptimal to support 2 dts files for the same board.
John
>
> Regards,
> Andreas
>
^ permalink raw reply
* [PATCH 4/4] dt-bindings: mfd: Add STM32F7 RCC numeric constants into DT include file
From: Alexandre Torgue @ 2017-01-10 10:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483711165-17149-5-git-send-email-gabriel.fernandez@st.com>
Hi Gabriel
On 01/06/2017 02:59 PM, gabriel.fernandez at st.com wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch lists STM32F7's RCC numeric constants.
> It will be used by clock and reset drivers, and DT bindings.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
can you please split this commit ? (one part for binding and another for DT)
Thanks in advance
Alex
> ---
> arch/arm/boot/dts/stm32f746.dtsi | 51 ++++++++--------
> include/dt-bindings/mfd/stm32f7-rcc.h | 112 ++++++++++++++++++++++++++++++++++
> 2 files changed, 138 insertions(+), 25 deletions(-)
> create mode 100644 include/dt-bindings/mfd/stm32f7-rcc.h
>
> diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
> index e05e131..09d6649 100644
> --- a/arch/arm/boot/dts/stm32f746.dtsi
> +++ b/arch/arm/boot/dts/stm32f746.dtsi
> @@ -44,6 +44,7 @@
> #include "armv7-m.dtsi"
> #include <dt-bindings/pinctrl/stm32f746-pinfunc.h>
> #include <dt-bindings/clock/stm32fx-clock.h>
> +#include <dt-bindings/mfd/stm32f7-rcc.h>
>
> / {
> clocks {
> @@ -77,7 +78,7 @@
> compatible = "st,stm32-timer";
> reg = <0x40000000 0x400>;
> interrupts = <28>;
> - clocks = <&rcc 0 128>;
> + clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM2)>;
> status = "disabled";
> };
>
> @@ -85,7 +86,7 @@
> compatible = "st,stm32-timer";
> reg = <0x40000400 0x400>;
> interrupts = <29>;
> - clocks = <&rcc 0 129>;
> + clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM3)>;
> status = "disabled";
> };
>
> @@ -93,7 +94,7 @@
> compatible = "st,stm32-timer";
> reg = <0x40000800 0x400>;
> interrupts = <30>;
> - clocks = <&rcc 0 130>;
> + clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM4)>;
> status = "disabled";
> };
>
> @@ -101,14 +102,14 @@
> compatible = "st,stm32-timer";
> reg = <0x40000c00 0x400>;
> interrupts = <50>;
> - clocks = <&rcc 0 131>;
> + clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM5)>;
> };
>
> timer6: timer at 40001000 {
> compatible = "st,stm32-timer";
> reg = <0x40001000 0x400>;
> interrupts = <54>;
> - clocks = <&rcc 0 132>;
> + clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM6)>;
> status = "disabled";
> };
>
> @@ -116,7 +117,7 @@
> compatible = "st,stm32-timer";
> reg = <0x40001400 0x400>;
> interrupts = <55>;
> - clocks = <&rcc 0 133>;
> + clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM7)>;
> status = "disabled";
> };
>
> @@ -124,7 +125,7 @@
> compatible = "st,stm32f7-usart", "st,stm32f7-uart";
> reg = <0x40004400 0x400>;
> interrupts = <38>;
> - clocks = <&rcc 0 145>;
> + clocks = <&rcc 1 CLK_USART2>;
> status = "disabled";
> };
>
> @@ -132,7 +133,7 @@
> compatible = "st,stm32f7-usart", "st,stm32f7-uart";
> reg = <0x40004800 0x400>;
> interrupts = <39>;
> - clocks = <&rcc 0 146>;
> + clocks = <&rcc 1 CLK_USART3>;
> status = "disabled";
> };
>
> @@ -140,7 +141,7 @@
> compatible = "st,stm32f7-uart";
> reg = <0x40004c00 0x400>;
> interrupts = <52>;
> - clocks = <&rcc 0 147>;
> + clocks = <&rcc 1 CLK_UART4>;
> status = "disabled";
> };
>
> @@ -148,7 +149,7 @@
> compatible = "st,stm32f7-uart";
> reg = <0x40005000 0x400>;
> interrupts = <53>;
> - clocks = <&rcc 0 148>;
> + clocks = <&rcc 1 CLK_UART5>;
> status = "disabled";
> };
>
> @@ -156,7 +157,7 @@
> compatible = "st,stm32f7-usart", "st,stm32f7-uart";
> reg = <0x40007800 0x400>;
> interrupts = <82>;
> - clocks = <&rcc 0 158>;
> + clocks = <&rcc 1 CLK_UART7>;
> status = "disabled";
> };
>
> @@ -164,7 +165,7 @@
> compatible = "st,stm32f7-usart", "st,stm32f7-uart";
> reg = <0x40007c00 0x400>;
> interrupts = <83>;
> - clocks = <&rcc 0 159>;
> + clocks = <&rcc 1 CLK_UART8>;
> status = "disabled";
> };
>
> @@ -172,7 +173,7 @@
> compatible = "st,stm32f7-usart", "st,stm32f7-uart";
> reg = <0x40011000 0x400>;
> interrupts = <37>;
> - clocks = <&rcc 0 164>;
> + clocks = <&rcc 1 CLK_USART1>;
> status = "disabled";
> };
>
> @@ -180,7 +181,7 @@
> compatible = "st,stm32f7-usart", "st,stm32f7-uart";
> reg = <0x40011400 0x400>;
> interrupts = <71>;
> - clocks = <&rcc 0 165>;
> + clocks = <&rcc 1 CLK_USART6>;
> status = "disabled";
> };
>
> @@ -215,7 +216,7 @@
> gpio-controller;
> #gpio-cells = <2>;
> reg = <0x0 0x400>;
> - clocks = <&rcc 0 256>;
> + clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOA)>;
> st,bank-name = "GPIOA";
> };
>
> @@ -223,7 +224,7 @@
> gpio-controller;
> #gpio-cells = <2>;
> reg = <0x400 0x400>;
> - clocks = <&rcc 0 257>;
> + clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOB)>;
> st,bank-name = "GPIOB";
> };
>
> @@ -231,7 +232,7 @@
> gpio-controller;
> #gpio-cells = <2>;
> reg = <0x800 0x400>;
> - clocks = <&rcc 0 258>;
> + clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOC)>;
> st,bank-name = "GPIOC";
> };
>
> @@ -239,7 +240,7 @@
> gpio-controller;
> #gpio-cells = <2>;
> reg = <0xc00 0x400>;
> - clocks = <&rcc 0 259>;
> + clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOD)>;
> st,bank-name = "GPIOD";
> };
>
> @@ -247,7 +248,7 @@
> gpio-controller;
> #gpio-cells = <2>;
> reg = <0x1000 0x400>;
> - clocks = <&rcc 0 260>;
> + clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOE)>;
> st,bank-name = "GPIOE";
> };
>
> @@ -255,7 +256,7 @@
> gpio-controller;
> #gpio-cells = <2>;
> reg = <0x1400 0x400>;
> - clocks = <&rcc 0 261>;
> + clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOF)>;
> st,bank-name = "GPIOF";
> };
>
> @@ -263,7 +264,7 @@
> gpio-controller;
> #gpio-cells = <2>;
> reg = <0x1800 0x400>;
> - clocks = <&rcc 0 262>;
> + clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOG)>;
> st,bank-name = "GPIOG";
> };
>
> @@ -271,7 +272,7 @@
> gpio-controller;
> #gpio-cells = <2>;
> reg = <0x1c00 0x400>;
> - clocks = <&rcc 0 263>;
> + clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOH)>;
> st,bank-name = "GPIOH";
> };
>
> @@ -279,7 +280,7 @@
> gpio-controller;
> #gpio-cells = <2>;
> reg = <0x2000 0x400>;
> - clocks = <&rcc 0 264>;
> + clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOI)>;
> st,bank-name = "GPIOI";
> };
>
> @@ -287,7 +288,7 @@
> gpio-controller;
> #gpio-cells = <2>;
> reg = <0x2400 0x400>;
> - clocks = <&rcc 0 265>;
> + clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOJ)>;
> st,bank-name = "GPIOJ";
> };
>
> @@ -295,7 +296,7 @@
> gpio-controller;
> #gpio-cells = <2>;
> reg = <0x2800 0x400>;
> - clocks = <&rcc 0 266>;
> + clocks = <&rcc 0 STM32F7_AHB1_CLOCK(GPIOK)>;
> st,bank-name = "GPIOK";
> };
>
> diff --git a/include/dt-bindings/mfd/stm32f7-rcc.h b/include/dt-bindings/mfd/stm32f7-rcc.h
> new file mode 100644
> index 0000000..e36cc69
> --- /dev/null
> +++ b/include/dt-bindings/mfd/stm32f7-rcc.h
> @@ -0,0 +1,112 @@
> +/*
> + * This header provides constants for the STM32F7 RCC IP
> + */
> +
> +#ifndef _DT_BINDINGS_MFD_STM32F7_RCC_H
> +#define _DT_BINDINGS_MFD_STM32F7_RCC_H
> +
> +/* AHB1 */
> +#define STM32F7_RCC_AHB1_GPIOA 0
> +#define STM32F7_RCC_AHB1_GPIOB 1
> +#define STM32F7_RCC_AHB1_GPIOC 2
> +#define STM32F7_RCC_AHB1_GPIOD 3
> +#define STM32F7_RCC_AHB1_GPIOE 4
> +#define STM32F7_RCC_AHB1_GPIOF 5
> +#define STM32F7_RCC_AHB1_GPIOG 6
> +#define STM32F7_RCC_AHB1_GPIOH 7
> +#define STM32F7_RCC_AHB1_GPIOI 8
> +#define STM32F7_RCC_AHB1_GPIOJ 9
> +#define STM32F7_RCC_AHB1_GPIOK 10
> +#define STM32F7_RCC_AHB1_CRC 12
> +#define STM32F7_RCC_AHB1_BKPSRAM 18
> +#define STM32F7_RCC_AHB1_DTCMRAM 20
> +#define STM32F7_RCC_AHB1_DMA1 21
> +#define STM32F7_RCC_AHB1_DMA2 22
> +#define STM32F7_RCC_AHB1_DMA2D 23
> +#define STM32F7_RCC_AHB1_ETHMAC 25
> +#define STM32F7_RCC_AHB1_ETHMACTX 26
> +#define STM32F7_RCC_AHB1_ETHMACRX 27
> +#define STM32FF_RCC_AHB1_ETHMACPTP 28
> +#define STM32F7_RCC_AHB1_OTGHS 29
> +#define STM32F7_RCC_AHB1_OTGHSULPI 30
> +
> +#define STM32F7_AHB1_RESET(bit) (STM32F7_RCC_AHB1_##bit + (0x10 * 8))
> +#define STM32F7_AHB1_CLOCK(bit) (STM32F7_RCC_AHB1_##bit)
> +
> +
> +/* AHB2 */
> +#define STM32F7_RCC_AHB2_DCMI 0
> +#define STM32F7_RCC_AHB2_CRYP 4
> +#define STM32F7_RCC_AHB2_HASH 5
> +#define STM32F7_RCC_AHB2_RNG 6
> +#define STM32F7_RCC_AHB2_OTGFS 7
> +
> +#define STM32F7_AHB2_RESET(bit) (STM32F7_RCC_AHB2_##bit + (0x14 * 8))
> +#define STM32F7_AHB2_CLOCK(bit) (STM32F7_RCC_AHB2_##bit + 0x20)
> +
> +/* AHB3 */
> +#define STM32F7_RCC_AHB3_FMC 0
> +#define STM32F7_RCC_AHB3_QSPI 1
> +
> +#define STM32F7_AHB3_RESET(bit) (STM32F7_RCC_AHB3_##bit + (0x18 * 8))
> +#define STM32F7_AHB3_CLOCK(bit) (STM32F7_RCC_AHB3_##bit + 0x40)
> +
> +/* APB1 */
> +#define STM32F7_RCC_APB1_TIM2 0
> +#define STM32F7_RCC_APB1_TIM3 1
> +#define STM32F7_RCC_APB1_TIM4 2
> +#define STM32F7_RCC_APB1_TIM5 3
> +#define STM32F7_RCC_APB1_TIM6 4
> +#define STM32F7_RCC_APB1_TIM7 5
> +#define STM32F7_RCC_APB1_TIM12 6
> +#define STM32F7_RCC_APB1_TIM13 7
> +#define STM32F7_RCC_APB1_TIM14 8
> +#define STM32F7_RCC_APB1_LPTIM1 9
> +#define STM32F7_RCC_APB1_WWDG 11
> +#define STM32F7_RCC_APB1_SPI2 14
> +#define STM32F7_RCC_APB1_SPI3 15
> +#define STM32F7_RCC_APB1_SPDIFRX 16
> +#define STM32F7_RCC_APB1_UART2 17
> +#define STM32F7_RCC_APB1_UART3 18
> +#define STM32F7_RCC_APB1_UART4 19
> +#define STM32F7_RCC_APB1_UART5 20
> +#define STM32F7_RCC_APB1_I2C1 21
> +#define STM32F7_RCC_APB1_I2C2 22
> +#define STM32F7_RCC_APB1_I2C3 23
> +#define STM32F7_RCC_APB1_I2C4 24
> +#define STM32F7_RCC_APB1_CAN1 25
> +#define STM32F7_RCC_APB1_CAN2 26
> +#define STM32F7_RCC_APB1_CEC 27
> +#define STM32F7_RCC_APB1_PWR 28
> +#define STM32F7_RCC_APB1_DAC 29
> +#define STM32F7_RCC_APB1_UART7 30
> +#define STM32F7_RCC_APB1_UART8 31
> +
> +#define STM32F7_APB1_RESET(bit) (STM32F7_RCC_APB1_##bit + (0x20 * 8))
> +#define STM32F7_APB1_CLOCK(bit) (STM32F7_RCC_APB1_##bit + 0x80)
> +
> +/* APB2 */
> +#define STM32F7_RCC_APB2_TIM1 0
> +#define STM32F7_RCC_APB2_TIM8 1
> +#define STM32F7_RCC_APB2_USART1 4
> +#define STM32F7_RCC_APB2_USART6 5
> +#define STM32F7_RCC_APB2_ADC1 8
> +#define STM32F7_RCC_APB2_ADC2 9
> +#define STM32F7_RCC_APB2_ADC3 10
> +#define STM32F7_RCC_APB2_SDMMC1 11
> +#define STM32F7_RCC_APB2_SPI1 12
> +#define STM32F7_RCC_APB2_SPI4 13
> +#define STM32F7_RCC_APB2_SYSCFG 14
> +#define STM32F7_RCC_APB2_TIM9 16
> +#define STM32F7_RCC_APB2_TIM10 17
> +#define STM32F7_RCC_APB2_TIM11 18
> +#define STM32F7_RCC_APB2_SPI5 20
> +#define STM32F7_RCC_APB2_SPI6 21
> +#define STM32F7_RCC_APB2_SAI1 22
> +#define STM32F7_RCC_APB2_SAI2 23
> +#define STM32F7_RCC_APB2_LTDC 26
> +
> +#define STM32F7_APB2_RESET(bit) (STM32F7_RCC_APB2_##bit + (0x24 * 8))
> +#define STM32F7_APB2_CLOCK(bit) (STM32F7_RCC_APB2_##bit + 0xA0)
> +
> +#endif /* _DT_BINDINGS_MFD_STM32F7_RCC_H */
>
^ permalink raw reply
* [QUESTION] Early Write Acknowledge for PCIe configuration space
From: John Garry @ 2017-01-10 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1882721.jqIYnAaWfQ@wuerfel>
On 09/01/2017 11:52, Arnd Bergmann wrote:
> On Monday, January 9, 2017 10:59:47 AM CET John Garry wrote:
>> On 06/01/2017 11:24, Arnd Bergmann wrote:
>>> On Friday, January 6, 2017 11:15:22 AM CET John Garry wrote:
>>>
>>> Probably nobody thought about this properly in the Linux drivers. The
>>> ARMv8 ARM sounds correct here.
>>>
>>> I/O space may have the same issue, as it also requires non-posted
>>> accesses.
>>
>> Right, so our HW team's recommendation - from ARM's memory model and
>> also PCIe order model - is that not only config space but also PCIe
>> memory mapped IO has the same attribute (nE).
>
> Just to be sure we are talking about the same thing: "PCIe memory
> mapped IO" could refer to either PCI I/O space or PCI memory space.
>
> As far as I can tell, PCI memory space should *not* be using the nE
> attribute, while PCI I/O space and PCI config space should.
> Does this match what your HW team recomments?
>
Yes, right, the config and IO space recommendation is nE and memory
space is E.
In response to Will:
> What's the rationale behind that recommendation?
As Arnd said, the reasoning is that one access type is non-posted
(config and IO) and the other (memory) is posted writes.
Thanks,
John
> Arnd
>
> .
>
^ permalink raw reply
* [PATCH v2 4/6] ARM: davinci: add skeleton for pdata-quirks
From: Sekhar Nori @ 2017-01-10 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109205531.3435-5-khilman@baylibre.com>
On Tuesday 10 January 2017 02:25 AM, Kevin Hilman wrote:
> Add skeleton pdata-quirks for for davinci.
s/for for/for
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Applied to v4.11/soc
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 5/6] ARM: davinci: da8xx: add pdata-quirks, use for VPIF capture
From: Sekhar Nori @ 2017-01-10 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109205531.3435-6-khilman@baylibre.com>
On Tuesday 10 January 2017 02:25 AM, Kevin Hilman wrote:
> For da8xx DT platforms, use pdata-quirks to add legacy platform data for
> vpif_capture driver.
>
> Passing legacy platform_data is required until the V4L2 framework, and
> subdevice drivers (such as the tvp514x) grow a way of selecting input
> and output routing (c.f. V4L2 s_routing API)
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> arch/arm/mach-davinci/Makefile | 2 +-
> arch/arm/mach-davinci/da8xx-dt.c | 2 +
> arch/arm/mach-davinci/pdata-quirks.c | 115 +++++++++++++++++++++++++++++++++++
> 3 files changed, 118 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
> index 0a2e6da45f28..df96ca9eab6d 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -21,7 +21,7 @@ obj-$(CONFIG_AINTC) += irq.o
> obj-$(CONFIG_CP_INTC) += cp_intc.o
>
> # Board specific
> -obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o
> +obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o pdata-quirks.o
This should be done in 4/6 along with addition of pdata-quirks.c
> obj-$(CONFIG_MACH_DAVINCI_EVM) += board-dm644x-evm.o
> obj-$(CONFIG_MACH_SFFSDR) += board-sffsdr.o
> obj-$(CONFIG_MACH_NEUROS_OSD2) += board-neuros-osd2.o
> diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
> index 9ee44da6eb7b..fe4a9e30d937 100644
> --- a/arch/arm/mach-davinci/da8xx-dt.c
> +++ b/arch/arm/mach-davinci/da8xx-dt.c
> @@ -42,6 +42,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
> OF_DEV_AUXDATA("ti,da830-ohci", 0x01e25000, "ohci-da8xx", NULL),
> OF_DEV_AUXDATA("ti,da830-musb", 0x01e00000, "musb-da8xx", NULL),
> OF_DEV_AUXDATA("ti,da830-usb-phy", 0x01c1417c, "da8xx-usb-phy", NULL),
> + OF_DEV_AUXDATA("ti,da850-vpif", 0x01e17000, "vpif", NULL),
> {}
> };
>
> @@ -62,6 +63,7 @@ static void __init da850_init_machine(void)
>
> of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
> davinci_pm_init();
> + pdata_quirks_init();
This too belongs to 4/6.
Rest of the patch looks good to me. But I cannot apply it until I get a
branch from Mauro with driver changes hosted.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v5 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
From: Alexandre Belloni @ 2017-01-10 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b686fa42-bbfb-dec2-460f-ef00869bc12e@axentia.se>
On 10/01/2017 at 10:52:56 +0100, Peter Rosin wrote :
> On 2017-01-10 10:29, Alexandre Belloni wrote:
> > Hi,
> >
> > This needs a commit message, please add one.
>
> There's not all that much to say, but ok, I'll add something.
>
It doesn't have to be long but it has to be present.
> > On 10/01/2017 at 09:08:51 +0100, Peter Rosin wrote :
> There's also the benefit of the increased chances of me getting
> notified of changes. I don't mind...
>
Do you expect changes coming from third parties? I'm fine with it
anyway.
> >> +&main {
> >> + clock-frequency = <12000000>;
> >> +};
> >> +
> >
> > I don't think this is needed
> >
> >
>
> "this"? The &main frequency, or all of them?
>
I meant just main
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] arm64: dma_mapping: allow PCI host driver to limit DMA mask
From: Arnd Bergmann @ 2017-01-10 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109205746.GA6274@lst.de>
On Monday, January 9, 2017 9:57:46 PM CET Christoph Hellwig wrote:
> > - architecture should stop breaking 64-bit DMA when driver attempts to
> > set 64-bit dma mask,
> >
> > - NVMe should issue proper blk_queue_bounce_limit() call based on what
> > is actually set mask,
>
> Or even better remove the call to dma_set_mask_and_coherent with
> DMA_BIT_MASK(32). NVMe is designed around having proper 64-bit DMA
> addressing, there is not point in trying to pretent it works without that
Agreed, let's just fail the probe() if DMA_BIT_MASK(64) fails, and
have swiotlb work around machines that for some reason need bounce
buffers.
> > - and blk_queue_bounce_limit() should also be fixed to actually set
> > 0xffffffff limit, instead of replacing it with (max_low_pfn <<
> > PAGE_SHIFT) as it does now.
>
> We need to kill off BLK_BOUNCE_HIGH, it just doesn't make sense to
> mix the highmem aspect with the addressing limits. In fact the whole
> block bouncing scheme doesn't make much sense at all these days, we
> should rely on swiotlb instead.
If we do this, we should probably have another look at the respective
NETIF_F_HIGHDMA support in the network stack, which does the same thing
and mixes up highmem on 32-bit architectures with the DMA address limit.
(side note: there are actually cases in which you have a 31-bit DMA
mask but 3 GB of lowmem using CONFIG_VMSPLIT_1G, so BLK_BOUNCE_HIGH
and !NETIF_F_HIGHDMA are both missing the limit, causing data corruption
without swiotlb).
Before we rely too much on swiotlb, we may also need to consider which
architectures today rely on bouncing in blk and network.
I see that we have CONFIG_ARCH_PHYS_ADDR_T_64BIT on a couple of
32-bit architectures without swiotlb (arc, arm, some mips32), and
there are several 64-bit architectures that do not have swiotlb
(alpha, parisc, s390, sparc). I believe that alpha, s390 and sparc
always use some form of IOMMU, but the other four apparently don't,
so we would need to add swiotlb support there to remove all the
bounce buffering in network and block layers.
Arnd
^ permalink raw reply
* [QUESTION] Early Write Acknowledge for PCIe configuration space
From: Gabriele Paoloni @ 2017-01-10 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3295d30c-0b71-d73b-fd53-c75a9e0b2bae@huawei.com>
> -----Original Message-----
> From: John Garry
> Sent: 10 January 2017 10:23
> To: Arnd Bergmann
> Cc: linux-arm-kernel at lists.infradead.org; catalin.marinas at arm.com; Will
> Deacon; Lorenzo Pieralisi; Gabriele Paoloni; Linuxarm; xuwei (O);
> Wangzhou (B); Shameerali Kolothum Thodi; Guohanjun (Hanjun Guo)
> Subject: Re: [QUESTION] Early Write Acknowledge for PCIe configuration
> space
>
> On 09/01/2017 11:52, Arnd Bergmann wrote:
> > On Monday, January 9, 2017 10:59:47 AM CET John Garry wrote:
> >> On 06/01/2017 11:24, Arnd Bergmann wrote:
> >>> On Friday, January 6, 2017 11:15:22 AM CET John Garry wrote:
> >>>
> >>> Probably nobody thought about this properly in the Linux drivers.
> The
> >>> ARMv8 ARM sounds correct here.
> >>>
> >>> I/O space may have the same issue, as it also requires non-posted
> >>> accesses.
> >>
> >> Right, so our HW team's recommendation - from ARM's memory model and
> >> also PCIe order model - is that not only config space but also PCIe
> >> memory mapped IO has the same attribute (nE).
> >
> > Just to be sure we are talking about the same thing: "PCIe memory
> > mapped IO" could refer to either PCI I/O space or PCI memory space.
> >
> > As far as I can tell, PCI memory space should *not* be using the nE
> > attribute, while PCI I/O space and PCI config space should.
> > Does this match what your HW team recomments?
> >
>
> Yes, right, the config and IO space recommendation is nE and memory
> space is E.
>
> In response to Will:
> > What's the rationale behind that recommendation?
>
> As Arnd said, the reasoning is that one access type is non-posted
> (config and IO) and the other (memory) is posted writes.
I think that the problem here is that if the CPU writes data to ECAM
or IO space mapped using the E attribute, the ack will come back to the
CPU before the data has actually been written to the EP. So effectively
doing so I think that we break the PCIe specs...
Cheers
Gab
>
> Thanks,
> John
>
> > Arnd
> >
> > .
> >
>
^ permalink raw reply
* [PATCH v2 4/6] ARM: davinci: add skeleton for pdata-quirks
From: Sekhar Nori @ 2017-01-10 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ffa4c887-d9eb-94d0-441f-ed0fa8ba038d@ti.com>
On Tuesday 10 January 2017 03:56 PM, Sekhar Nori wrote:
> On Tuesday 10 January 2017 02:25 AM, Kevin Hilman wrote:
>> Add skeleton pdata-quirks for for davinci.
>
> s/for for/for
>
>>
>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>
> Applied to v4.11/soc
After reviewing 5/6, I think some parts of that patch should actually
be part of basic pdata-quirks support addition. I have moved them here.
Here is the updated patch. Let me know if it looks fine.
Thanks,
Sekhar
---8<---
Author: Kevin Hilman <khilman@baylibre.com>
AuthorDate: Mon Jan 9 12:55:29 2017 -0800
Commit: Sekhar Nori <nsekhar@ti.com>
CommitDate: Tue Jan 10 16:12:22 2017 +0530
ARM: davinci: add skeleton for pdata-quirks
Add skeleton pdata-quirks for davinci.
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
[nsekhar at ti.com: move changes to build pdata-quirks.c and call
to pdata_quirks_init() to this patch]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index 0a2e6da45f28..df96ca9eab6d 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -21,7 +21,7 @@ obj-$(CONFIG_AINTC) += irq.o
obj-$(CONFIG_CP_INTC) += cp_intc.o
# Board specific
-obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o
+obj-$(CONFIG_MACH_DA8XX_DT) += da8xx-dt.o pdata-quirks.o
obj-$(CONFIG_MACH_DAVINCI_EVM) += board-dm644x-evm.o
obj-$(CONFIG_MACH_SFFSDR) += board-sffsdr.o
obj-$(CONFIG_MACH_NEUROS_OSD2) += board-neuros-osd2.o
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 9ee44da6eb7b..d2be1941a687 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -62,6 +62,7 @@ static void __init da850_init_machine(void)
of_platform_default_populate(NULL, da850_auxdata_lookup, NULL);
davinci_pm_init();
+ pdata_quirks_init();
}
static const char *const da850_boards_compat[] __initconst = {
diff --git a/arch/arm/mach-davinci/include/mach/common.h b/arch/arm/mach-davinci/include/mach/common.h
index 0b3c169758ed..037aa66bcac1 100644
--- a/arch/arm/mach-davinci/include/mach/common.h
+++ b/arch/arm/mach-davinci/include/mach/common.h
@@ -102,6 +102,8 @@ int davinci_pm_init(void);
static inline int davinci_pm_init(void) { return 0; }
#endif
+void __init pdata_quirks_init(void);
+
#define SRAM_SIZE SZ_128K
#endif /* __ARCH_ARM_MACH_DAVINCI_COMMON_H */
diff --git a/arch/arm/mach-davinci/pdata-quirks.c b/arch/arm/mach-davinci/pdata-quirks.c
new file mode 100644
index 000000000000..5b57da475065
--- /dev/null
+++ b/arch/arm/mach-davinci/pdata-quirks.c
@@ -0,0 +1,39 @@
+/*
+ * Legacy platform_data quirks
+ *
+ * Copyright (C) 2016 BayLibre, Inc
+ *
+ * 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.
+ */
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+
+#include <mach/common.h>
+
+struct pdata_init {
+ const char *compatible;
+ void (*fn)(void);
+};
+
+static void pdata_quirks_check(struct pdata_init *quirks)
+{
+ while (quirks->compatible) {
+ if (of_machine_is_compatible(quirks->compatible)) {
+ if (quirks->fn)
+ quirks->fn();
+ break;
+ }
+ quirks++;
+ }
+}
+
+static struct pdata_init pdata_quirks[] __initdata = {
+ { /* sentinel */ },
+};
+
+void __init pdata_quirks_init(void)
+{
+ pdata_quirks_check(pdata_quirks);
+}
^ permalink raw reply related
* [RFC PATCH] vring: Force use of DMA API for ARM-based systems
From: Jean-Philippe Brucker @ 2017-01-10 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109145437.GF21398@arm.com>
On 09/01/17 14:54, Will Deacon wrote:
> On Mon, Jan 09, 2017 at 11:24:04AM +0000, Robin Murphy wrote:
>> On 06/01/17 21:51, Andy Lutomirski wrote:
>>> On Fri, Jan 6, 2017 at 10:32 AM, Robin Murphy <robin.murphy@arm.com> wrote:
>>>> On 06/01/17 17:48, Jean-Philippe Brucker wrote:
>>>>> 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?
>>>>
>>>> Hmm, this looks more like the virtio_block device simply has the wrong
>>>> DMA mask to begin with. For virtio-pci we set the streaming DMA mask to
>>>> 64 bits - should a platform device not be similarly capable?
>>>
>>> If it's not, then turning off DMA API will cause random corruption.
>>> ISTM one way or another the bug is in either the DMA ops or in the
>>> driver initialization.
>>
>> OK, having looked a little deeper, I reckon virtio_mmio_probe() is
>> indeed missing a dma_set_mask() call compared to its PCI friends. The
>> only question then is where does virtio-mmio stand with respect to
>> legacy/modern/44-bit/64-bit etc.?
>
> Legacy virtio-mmio has a variable page granule (GuestPageSize), so the
> 44-bit limitation shouldn't apply. The legacy spec doesn't actually
> initialise GuestPageSize in the example initialisation sequence, but
> Linux does. Non-legacy uses absolute, 64-bit addresses regardless of
> transport, so yes, it might be as simple as adding:
>
> dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>
> to virtio_mmio_probe. Jean-Philippe -- does that fix things for you?
Yes, setting the DMA mask to 64 bits seems to fix my issue.
Thank,
Jean-Philippe
^ permalink raw reply
* NVMe vs DMA addressing limitations
From: Arnd Bergmann @ 2017-01-10 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110070719.GA17208@lst.de>
On Tuesday, January 10, 2017 8:07:20 AM CET Christoph Hellwig wrote:
> On Tue, Jan 10, 2017 at 09:47:21AM +0300, Nikita Yushchenko wrote:
> > I'm now working with HW that:
> > - is now way "low end" or "obsolete", it has 4G of RAM and 8 CPU cores,
> > and is being manufactured and developed,
> > - has 75% of it's RAM located beyond first 4G of address space,
> > - can't physically handle incoming PCIe transactions addressed to memory
> > beyond 4G.
>
> It might not be low end or obselete, but it's absolutely braindead.
> Your I/O performance will suffer badly for the life of the platform
> because someone tries to save 2 cents, and there is not much we can do
> about it.
Unfortunately it is a common problem for arm64 chips that were designed
by taking a 32-bit SoC and replacing the CPU core. The swiotlb is the
right workaround for this, and I think we all agree that we should
just make it work correctly.
Arnd
^ permalink raw reply
* [QUESTION] Arm64: Query L3 cache info via DT
From: Tan Xiaojun @ 2017-01-10 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <536f64cc-357c-40a1-b2a0-1db0c4280fc0@arm.com>
On 2017/1/10 18:01, Sudeep Holla wrote:
>
>
> On 10/01/17 08:50, Tan Xiaojun wrote:
>> I add this patch, and test in Hisilicon D02/D03. It can work well.
>>
>> I'm sorry to reply so late. I took some time to debug, because I am not familiar with the code.
>>
>>> + if (level < of_level) {
>>> + /*
>>> + * some external caches not specified in CLIDR_EL1
>>> + * the information may be available in the device tree
>>> + * only unified external caches are considered here
>>> + */
>>> + level = of_level;
>>> + leaves += (of_level - level);
>>
>> The above two lines need to exchange the location.
>>
>
> Ah crap, sorry for such a silly mistake.
> I will post proper patch(es) soon.
>
OK. Wait for your new patch. ^_^
Thanks.
Xiaojun.
^ permalink raw reply
* [PATCH v4 8/9] ARM: dts: stm32f4: Add external I2S clock
From: Alexandre Torgue @ 2017-01-10 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481638820-29324-9-git-send-email-gabriel.fernandez@st.com>
Hi
On 12/13/2016 03:20 PM, Gabriel FERNANDEZ wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch adds an external I2S clock in the DT.
> The I2S clock could be derived from an external I2S clock or by I2S pll.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index e4dae0e..7c7dfbd 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -68,6 +68,12 @@
> compatible = "fixed-clock";
> clock-frequency = <32000>;
> };
> +
> + clk_i2s_ckin: i2s-ckin {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <0>;
> + };
> };
>
> soc {
> @@ -362,7 +368,7 @@
> #clock-cells = <2>;
> compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
> reg = <0x40023800 0x400>;
> - clocks = <&clk_hse>;
> + clocks = <&clk_hse>, <&clk_i2s_ckin>;
> st,syscfg = <&pwrcfg>;
> };
>
>
Applied on stm32-dt-for-v4.11
Thanks
^ permalink raw reply
* [PATCH v4 9/9] ARM: dts: stm32f4: Include auxiliary stm32fx clock definition
From: Alexandre Torgue @ 2017-01-10 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481638820-29324-10-git-send-email-gabriel.fernandez@st.com>
hi
On 12/13/2016 03:20 PM, Gabriel FERNANDEZ wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch include auxiliary clock definition (clocks which are not derived
> from system clock.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index 7c7dfbd..041e3fc 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -48,6 +48,7 @@
> #include "skeleton.dtsi"
> #include "armv7-m.dtsi"
> #include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
> +#include <dt-bindings/clock/stm32fx-clock.h>
>
> / {
> clocks {
>
Applied on stm32-dt-for-v4.11
Thanks
^ permalink raw reply
* NVMe vs DMA addressing limitations
From: Arnd Bergmann @ 2017-01-10 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c4fd007c-3f07-fc2a-8cbb-7152f578609d@cogentembedded.com>
On Tuesday, January 10, 2017 10:31:47 AM CET Nikita Yushchenko wrote:
> Christoph, thanks for clear input.
>
> Arnd, I think that given this discussion, best short-term solution is
> indeed the patch I've submitted yesterday. That is, your version +
> coherent mask support. With that, set_dma_mask(DMA_BIT_MASK(64)) will
> succeed and hardware with work with swiotlb.
Ok, good.
> Possible next step is to teach swiotlb to dynamically allocate bounce
> buffers within entire arm64's ZONE_DMA.
That seems reasonable, yes. We probably have to do both, as there are
cases where a device has dma_mask smaller than ZONE_DMA but the swiotlb
bounce area is low enough to work anyway.
Another workaround me might need is to limit amount of concurrent DMA
in the NVMe driver based on some platform quirk. The way that NVMe works,
it can have very large amounts of data that is concurrently mapped into
the device. SWIOTLB is one case where this currently fails, but another
example would be old PowerPC servers that have a 256MB window of virtual
I/O addresses per VM guest in their IOMMU. Those will likely fail the same
way that your does.
> Also there is some hope that R-Car *can* iommu-translate addresses that
> PCIe module issues to system bus. Although previous attempts to make
> that working failed. Additional research is needed here.
Does this IOMMU support remapping data within a virtual machine? I believe
there are some that only do one of the two -- either you can have guest
machines with DMA access to their low memory, or you can remap data on
the fly in the host.
Arnd
^ permalink raw reply
* [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Young @ 2017-01-10 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484039631-25120-3-git-send-email-sean.wang@mediatek.com>
Hi Sean
Some more review comments.
On Tue, Jan 10, 2017 at 05:13:51PM +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> This patch adds driver for IR controller on MT7623 SoC.
> and should also work on similar Mediatek SoC. Currently
> testing successfully on NEC and SONY remote controller
> only but it should work on others (lirc, rc-5 and rc-6).
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> Reviewed-by: Sean Young <sean@mess.org>
> ---
> drivers/media/rc/Kconfig | 11 ++
> drivers/media/rc/Makefile | 1 +
> drivers/media/rc/mtk-cir.c | 326 +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 338 insertions(+)
> create mode 100644 drivers/media/rc/mtk-cir.c
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 629e8ca..9228479 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -235,6 +235,17 @@ config IR_MESON
> To compile this driver as a module, choose M here: the
> module will be called meson-ir.
>
> +config IR_MTK
> + tristate "Mediatek IR remote receiver"
> + depends on RC_CORE
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + ---help---
> + Say Y if you want to use the IR remote receiver available
> + on Mediatek SoCs.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called mtk-cir.
> +
> config IR_NUVOTON
> tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
> depends on PNP
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 3a984ee..a78570b 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -38,3 +38,4 @@ obj-$(CONFIG_RC_ST) += st_rc.o
> obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
> obj-$(CONFIG_IR_IMG) += img-ir/
> obj-$(CONFIG_IR_SERIAL) += serial_ir.o
> +obj-$(CONFIG_IR_MTK) += mtk-cir.o
> diff --git a/drivers/media/rc/mtk-cir.c b/drivers/media/rc/mtk-cir.c
> new file mode 100644
> index 0000000..f752f63
> --- /dev/null
> +++ b/drivers/media/rc/mtk-cir.c
> @@ -0,0 +1,326 @@
> +/*
> + * Driver for Mediatek IR Receiver Controller
> + *
> + * Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/reset.h>
> +#include <media/rc-core.h>
> +
> +#define MTK_IR_DEV KBUILD_MODNAME
You could remove this #define and just use KBUILD_MODNAME
> +
> +/* Register to enable PWM and IR */
> +#define MTK_CONFIG_HIGH_REG 0x0c
> +/* Enable IR pulse width detection */
> +#define MTK_PWM_EN BIT(13)
> +/* Enable IR hardware function */
> +#define MTK_IR_EN BIT(0)
> +
> +/* Register to setting sample period */
> +#define MTK_CONFIG_LOW_REG 0x10
> +/* Field to set sample period */
> +#define CHK_PERIOD DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, \
> + MTK_IR_CLK_PERIOD)
> +#define MTK_CHK_PERIOD (((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
> +#define MTK_CHK_PERIOD_MASK (GENMASK(20, 8))
> +
> +/* Register to clear state of state machine */
> +#define MTK_IRCLR_REG 0x20
> +/* Bit to restart IR receiving */
> +#define MTK_IRCLR BIT(0)
> +
> +/* Register containing pulse width data */
> +#define MTK_CHKDATA_REG(i) (0x88 + 4 * (i))
> +#define MTK_WIDTH_MASK (GENMASK(7, 0))
> +
> +/* Register to enable IR interrupt */
> +#define MTK_IRINT_EN_REG 0xcc
> +/* Bit to enable interrupt */
> +#define MTK_IRINT_EN BIT(0)
> +
> +/* Register to ack IR interrupt */
> +#define MTK_IRINT_CLR_REG 0xd0
> +/* Bit to clear interrupt status */
> +#define MTK_IRINT_CLR BIT(0)
> +
> +/* Maximum count of samples */
> +#define MTK_MAX_SAMPLES 0xff
> +/* Indicate the end of IR message */
> +#define MTK_IR_END(v, p) ((v) == MTK_MAX_SAMPLES && (p) == 0)
> +/* Number of registers to record the pulse width */
> +#define MTK_CHKDATA_SZ 17
> +/* Source clock frequency */
> +#define MTK_IR_BASE_CLK 273000000
> +/* Frequency after IR internal divider */
> +#define MTK_IR_CLK_FREQ (MTK_IR_BASE_CLK / 4)
> +/* Period for MTK_IR_CLK in ns*/
> +#define MTK_IR_CLK_PERIOD DIV_ROUND_CLOSEST(1000000000ul, \
> + MTK_IR_CLK_FREQ)
> +/* Sample period in ns */
> +#define MTK_IR_SAMPLE (MTK_IR_CLK_PERIOD * 0xc00)
> +
> +/* struct mtk_ir - This is the main datasructure for holding the state
> + * of the driver
> + * @dev: The device pointer
> + * @rc: The rc instrance
> + * @irq: The IRQ that we are using
> + * @base: The mapped register i/o base
> + * @clk: The clock that we are using
> + */
> +struct mtk_ir {
> + struct device *dev;
> + struct rc_dev *rc;
> + void __iomem *base;
> + int irq;
> + struct clk *clk;
> +};
> +
> +static void mtk_w32_mask(struct mtk_ir *ir, u32 val, u32 mask, unsigned int reg)
> +{
> + u32 tmp;
> +
> + tmp = __raw_readl(ir->base + reg);
> + tmp = (tmp & ~mask) | val;
> + __raw_writel(tmp, ir->base + reg);
> +}
> +
> +static void mtk_w32(struct mtk_ir *ir, u32 val, unsigned int reg)
> +{
> + __raw_writel(val, ir->base + reg);
> +}
> +
> +static u32 mtk_r32(struct mtk_ir *ir, unsigned int reg)
> +{
> + return __raw_readl(ir->base + reg);
> +}
> +
> +static inline void mtk_irq_disable(struct mtk_ir *ir, u32 mask)
> +{
> + u32 val;
> +
> + val = mtk_r32(ir, MTK_IRINT_EN_REG);
> + mtk_w32(ir, val & ~mask, MTK_IRINT_EN_REG);
> +}
> +
> +static inline void mtk_irq_enable(struct mtk_ir *ir, u32 mask)
> +{
> + u32 val;
> +
> + val = mtk_r32(ir, MTK_IRINT_EN_REG);
> + mtk_w32(ir, val | mask, MTK_IRINT_EN_REG);
> +}
> +
> +static irqreturn_t mtk_ir_irq(int irqno, void *dev_id)
> +{
> + struct mtk_ir *ir = dev_id;
> + u8 wid = 0;
> + u32 i, j, val;
> + DEFINE_IR_RAW_EVENT(rawir);
> +
> + mtk_irq_disable(ir, MTK_IRINT_EN);
The kernel guarantees that calls to the interrupt handler are serialised,
no need to disable the interrupt in the handler.
> +
> + /* Reset decoder state machine */
> + ir_raw_event_reset(ir->rc);
Not needed.
> +
> + /* First message must be pulse */
> + rawir.pulse = false;
pulse = true?
> +
> + /* Handle all pulse and space IR controller captures */
> + for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
> + val = mtk_r32(ir, MTK_CHKDATA_REG(i));
> + dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
> +
> + for (j = 0 ; j < 4 ; j++) {
> + wid = (val & (MTK_WIDTH_MASK << j * 8)) >> j * 8;
> + rawir.pulse = !rawir.pulse;
> + rawir.duration = wid * (MTK_IR_SAMPLE + 1);
> + ir_raw_event_store_with_filter(ir->rc, &rawir);
> + }
In v1 you would break out of the loop if the ir message was shorter, but
now you are always passing on 68 pulses and spaces. Is that right?
> + }
> +
> + /* The maximum number of edges the IR controller can
> + * hold is MTK_CHKDATA_SZ * 4. So if received IR messages
> + * is over the limit, the last incomplete IR message would
> + * be appended trailing space and still would be sent into
> + * ir-rc-raw to decode. That helps it is possible that it
> + * has enough information to decode a scancode even if the
> + * trailing end of the message is missing.
> + */
> + if (!MTK_IR_END(wid, rawir.pulse)) {
> + rawir.pulse = false;
> + rawir.duration = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
> + ir_raw_event_store_with_filter(ir->rc, &rawir);
> + }
> +
> + ir_raw_event_handle(ir->rc);
> +
> + /* Restart controller for the next receive */
> + mtk_w32_mask(ir, 0x1, MTK_IRCLR, MTK_IRCLR_REG);
> +
> + /* Clear interrupt status */
> + mtk_w32_mask(ir, 0x1, MTK_IRINT_CLR, MTK_IRINT_CLR_REG);
> +
> + /* Enable interrupt */
> + mtk_irq_enable(ir, MTK_IRINT_EN);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int mtk_ir_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *dn = dev->of_node;
> + struct resource *res;
> + struct mtk_ir *ir;
> + u32 val;
> + int ret = 0;
> + const char *map_name;
> +
> + ir = devm_kzalloc(dev, sizeof(struct mtk_ir), GFP_KERNEL);
> + if (!ir)
> + return -ENOMEM;
> +
> + ir->dev = dev;
> +
> + if (!of_device_is_compatible(dn, "mediatek,mt7623-cir"))
> + return -ENODEV;
> +
> + ir->clk = devm_clk_get(dev, "clk");
> + if (IS_ERR(ir->clk)) {
> + dev_err(dev, "failed to get a ir clock.\n");
> + return PTR_ERR(ir->clk);
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + ir->base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(ir->base)) {
> + dev_err(dev, "failed to map registers\n");
> + return PTR_ERR(ir->base);
> + }
> +
> + ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
> + if (!ir->rc) {
> + dev_err(dev, "failed to allocate device\n");
> + return -ENOMEM;
> + }
> +
> + ir->rc->priv = ir;
> + ir->rc->input_name = MTK_IR_DEV;
> + ir->rc->input_phys = MTK_IR_DEV "/input0";
> + ir->rc->input_id.bustype = BUS_HOST;
> + ir->rc->input_id.vendor = 0x0001;
> + ir->rc->input_id.product = 0x0001;
> + ir->rc->input_id.version = 0x0001;
> + map_name = of_get_property(dn, "linux,rc-map-name", NULL);
> + ir->rc->map_name = map_name ?: RC_MAP_EMPTY;
> + ir->rc->dev.parent = dev;
> + ir->rc->driver_name = MTK_IR_DEV;
> + ir->rc->allowed_protocols = RC_BIT_ALL;
> + ir->rc->rx_resolution = MTK_IR_SAMPLE;
> + ir->rc->timeout = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
> +
> + ret = devm_rc_register_device(dev, ir->rc);
Here you do devm_rc_register_device()
> + if (ret) {
> + dev_err(dev, "failed to register rc device\n");
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, ir);
> +
> + ir->irq = platform_get_irq(pdev, 0);
> + if (ir->irq < 0) {
> + dev_err(dev, "no irq resource\n");
> + return -ENODEV;
> + }
> +
> + /* Enable interrupt after proper hardware
> + * setup and IRQ handler registration
> + */
> + if (clk_prepare_enable(ir->clk)) {
> + dev_err(dev, "try to enable ir_clk failed\n");
> + ret = -EINVAL;
> + goto exit_clkdisable_clk;
> + }
> +
> + mtk_irq_disable(ir, MTK_IRINT_EN);
> +
> + ret = devm_request_irq(dev, ir->irq, mtk_ir_irq, 0, MTK_IR_DEV, ir);
> + if (ret) {
> + dev_err(dev, "failed request irq\n");
> + goto exit_clkdisable_clk;
> + }
> +
> + /* Enable IR and PWM */
> + val = mtk_r32(ir, MTK_CONFIG_HIGH_REG);
> + val |= MTK_PWM_EN | MTK_IR_EN;
> + mtk_w32(ir, val, MTK_CONFIG_HIGH_REG);
> +
> + /* Setting sample period */
> + mtk_w32_mask(ir, MTK_CHK_PERIOD, MTK_CHK_PERIOD_MASK,
> + MTK_CONFIG_LOW_REG);
> +
> + mtk_irq_enable(ir, MTK_IRINT_EN);
> +
> + dev_info(dev, "Initialized MT7623 IR driver, sample period = %luus\n",
> + DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, 1000));
> +
> + return 0;
> +
> +exit_clkdisable_clk:
> + clk_disable_unprepare(ir->clk);
> +
> + return ret;
> +}
> +
> +static int mtk_ir_remove(struct platform_device *pdev)
> +{
> + struct mtk_ir *ir = platform_get_drvdata(pdev);
> +
> + /* Avoid contention between remove handler and
> + * IRQ handler so that disabling IR interrupt and
> + * waiting for pending IRQ handler to complete
> + */
> + mtk_irq_disable(ir, MTK_IRINT_EN);
> + synchronize_irq(ir->irq);
> +
> + clk_disable_unprepare(ir->clk);
> +
> + rc_unregister_device(ir->rc);
Yet here you explicitly call rc_unregister_device(). Since it was registered
with the devm call, this call is not needed and will lead to double frees etc
> +
> + return 0;
> +}
> +
> +static const struct of_device_id mtk_ir_match[] = {
> + { .compatible = "mediatek,mt7623-cir" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, mtk_ir_match);
> +
> +static struct platform_driver mtk_ir_driver = {
> + .probe = mtk_ir_probe,
> + .remove = mtk_ir_remove,
> + .driver = {
> + .name = MTK_IR_DEV,
> + .of_match_table = mtk_ir_match,
> + },
> +};
> +
> +module_platform_driver(mtk_ir_driver);
> +
> +MODULE_DESCRIPTION("Mediatek IR Receiver Controller Driver");
> +MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
> +MODULE_LICENSE("GPL");
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v29 9/9] Documentation: dt: chosen properties for arm64 kdump
From: Will Deacon @ 2017-01-10 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228043734.27535-1-takahiro.akashi@linaro.org>
Hi James, Akashi,
On Wed, Dec 28, 2016 at 01:37:34PM +0900, AKASHI Takahiro wrote:
> From: James Morse <james.morse@arm.com>
>
> Add documentation for
> linux,crashkernel-base and crashkernel-size,
> linux,usable-memory-range
> linux,elfcorehdr
> used by arm64 kdump to decribe the kdump reserved area, and
> the elfcorehdr's location within it.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> [takahiro.akashi at linaro.org: added "linux,crashkernel-base" and "-size" ]
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Cc: devicetree at vger.kernel.org
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> ---
> Documentation/devicetree/bindings/chosen.txt | 50 ++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
I need an ack from Rob or Mark before I can merge this.
Will
^ permalink raw reply
* [PATCH v29 1/9] memblock: add memblock_cap_memory_range()
From: Will Deacon @ 2017-01-10 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228043525.27420-1-takahiro.akashi@linaro.org>
[adding some more folks to cc]
On Wed, Dec 28, 2016 at 01:35:25PM +0900, AKASHI Takahiro wrote:
> Add memblock_cap_memory_range() which will remove all the memblock regions
> except the memory range specified in the arguments. In addition, rework is
> done on memblock_mem_limit_remove_map() to re-implement it using
> memblock_cap_memory_range().
>
> This function, like memblock_mem_limit_remove_map(), will not remove
> memblocks with MEMMAP_NOMAP attribute as they may be mapped and accessed
> later as "device memory."
> See the commit a571d4eb55d8 ("mm/memblock.c: add new infrastructure to
> address the mem limit issue").
>
> This function is used, in a succeeding patch in the series of arm64 kdump
> suuport, to limit the range of usable memory, or System RAM, on crash dump
> kernel.
> (Please note that "mem=" parameter is of little use for this purpose.)
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Reviewed-by: Will Deacon <will.deacon@arm.com>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: linux-mm at kvack.org
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
> include/linux/memblock.h | 1 +
> mm/memblock.c | 44 +++++++++++++++++++++++++++++---------------
> 2 files changed, 30 insertions(+), 15 deletions(-)
Whilst this patch looks fine to me, it would be nice if Dennis (author of
memblock_mem_limit_remove_map) or one of the mm chaps could provide an ack
before I merge it via arm64.
Thanks,
Will
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 5b759c9acf97..fbfcacc50c29 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -333,6 +333,7 @@ phys_addr_t memblock_mem_size(unsigned long limit_pfn);
> phys_addr_t memblock_start_of_DRAM(void);
> phys_addr_t memblock_end_of_DRAM(void);
> void memblock_enforce_memory_limit(phys_addr_t memory_limit);
> +void memblock_cap_memory_range(phys_addr_t base, phys_addr_t size);
> void memblock_mem_limit_remove_map(phys_addr_t limit);
> bool memblock_is_memory(phys_addr_t addr);
> int memblock_is_map_memory(phys_addr_t addr);
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 7608bc305936..fea1688fef60 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -1514,11 +1514,37 @@ void __init memblock_enforce_memory_limit(phys_addr_t limit)
> (phys_addr_t)ULLONG_MAX);
> }
>
> +void __init memblock_cap_memory_range(phys_addr_t base, phys_addr_t size)
> +{
> + int start_rgn, end_rgn;
> + int i, ret;
> +
> + if (!size)
> + return;
> +
> + ret = memblock_isolate_range(&memblock.memory, base, size,
> + &start_rgn, &end_rgn);
> + if (ret)
> + return;
> +
> + /* remove all the MAP regions */
> + for (i = memblock.memory.cnt - 1; i >= end_rgn; i--)
> + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> + memblock_remove_region(&memblock.memory, i);
> +
> + for (i = start_rgn - 1; i >= 0; i--)
> + if (!memblock_is_nomap(&memblock.memory.regions[i]))
> + memblock_remove_region(&memblock.memory, i);
> +
> + /* truncate the reserved regions */
> + memblock_remove_range(&memblock.reserved, 0, base);
> + memblock_remove_range(&memblock.reserved,
> + base + size, (phys_addr_t)ULLONG_MAX);
> +}
> +
> void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> {
> - struct memblock_type *type = &memblock.memory;
> phys_addr_t max_addr;
> - int i, ret, start_rgn, end_rgn;
>
> if (!limit)
> return;
> @@ -1529,19 +1555,7 @@ void __init memblock_mem_limit_remove_map(phys_addr_t limit)
> if (max_addr == (phys_addr_t)ULLONG_MAX)
> return;
>
> - ret = memblock_isolate_range(type, max_addr, (phys_addr_t)ULLONG_MAX,
> - &start_rgn, &end_rgn);
> - if (ret)
> - return;
> -
> - /* remove all the MAP regions above the limit */
> - for (i = end_rgn - 1; i >= start_rgn; i--) {
> - if (!memblock_is_nomap(&type->regions[i]))
> - memblock_remove_region(type, i);
> - }
> - /* truncate the reserved regions */
> - memblock_remove_range(&memblock.reserved, max_addr,
> - (phys_addr_t)ULLONG_MAX);
> + memblock_cap_memory_range(0, max_addr);
> }
>
> static int __init_memblock memblock_search(struct memblock_type *type, phys_addr_t addr)
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
From: Sergei Shtylyov @ 2017-01-10 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110022131.31042-1-shuahkh@osg.samsung.com>
Hello!
On 01/10/2017 05:21 AM, Shuah Khan wrote:
> Fix dwc3_exynos_probe() to call clk_prepare_enable() only when suspend
> clock is specified. Call clk_disable_unprepare() from remove and probe
> error path only when susp_clk has been set from remove and probe error
> paths.
>
> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
> ---
> drivers/usb/dwc3/dwc3-exynos.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index e27899b..f97a3d7 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -131,8 +131,8 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
> if (IS_ERR(exynos->susp_clk)) {
> dev_info(dev, "no suspend clk specified\n");
> exynos->susp_clk = NULL;
> - }
> - clk_prepare_enable(exynos->susp_clk);
> + } else
> + clk_prepare_enable(exynos->susp_clk);
CodingStyle: need {} here as well since another branch has them.
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH v5 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
From: Peter Rosin @ 2017-01-10 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110104248.iscurq55d7n26gfd@piout.net>
On 2017-01-10 11:42, Alexandre Belloni wrote:
> On 10/01/2017 at 10:52:56 +0100, Peter Rosin wrote :
>> On 2017-01-10 10:29, Alexandre Belloni wrote:
>>> Hi,
>>>
>>> This needs a commit message, please add one.
>>
>> There's not all that much to say, but ok, I'll add something.
>>
>
> It doesn't have to be long but it has to be present.
Does it really? There are quite a few examples to contradict that,
and checkpatch doesn't complain. That's no proof of course...
As I said, I'll add something.
>>> On 10/01/2017 at 09:08:51 +0100, Peter Rosin wrote :
>> There's also the benefit of the increased chances of me getting
>> notified of changes. I don't mind...
>>
>
> Do you expect changes coming from third parties? I'm fine with it
> anyway.
Ok, I'll remember this and blame you for everything :-)
>>>> +&main {
>>>> + clock-frequency = <12000000>;
>>>> +};
>>>> +
>>>
>>> I don't think this is needed
>>>
>>>
>>
>> "this"? The &main frequency, or all of them?
>>
>
> I meant just main
Ok, I'll test with that change and then resend. Thanks!
Cheers,
peda
^ permalink raw reply
* [PATCH] coresight: STM: Balance enable/disable
From: Suzuki K Poulose @ 2017-01-10 11:21 UTC (permalink / raw)
To: linux-arm-kernel
The stm is automatically enabled when an application sets the policy
via ->link() call back by using coresight_enable(), which keeps the
refcount of the current users of the STM. However, the unlink() callback
issues stm_disable() directly, which leaves the STM turned off, without
the coresight layer knowing about it. This prevents any further uses
of the STM hardware as the coresight layer still thinks the STM is
turned on and doesn't issue an stm_enable(). Even manually enabling
the STM via sysfs can't really enable the hw.
e.g,
$ echo 1 > $CS_DEVS/$ETR/enable_sink
$ mkdir -p $CONFIG_FS/stp-policy/$source.0/stm_test/
$ echo 32768 65535 > $CONFIG_FS/stp-policy/$source.0/stm_test/channels
$ echo 64 > $CS_DEVS/$source/traceid
$ ./stm_app
Sending 64000 byte blocks of pattern 0 at 0us intervals
Success to map channel(32768~32783) to 0xffffa95fa000
Sending on channel 32768
$ dd if=/dev/$ETR of=~/trace.bin.1
597+1 records in
597+1 records out
305920 bytes (306 kB) copied, 0.399952 s, 765 kB/s
$ ./stm_app
Sending 64000 byte blocks of pattern 0 at 0us intervals
Success to map channel(32768~32783) to 0xffff7e9e2000
Sending on channel 32768
$ dd if=/dev/$ETR of=~/trace.bin.2
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.0232083 s, 0.0 kB/s
Note that we don't get any data from the ETR for the second session.
Also dmesg shows :
[ 77.520458] coresight-tmc 20800000.etr: TMC-ETR enabled
[ 77.537097] coresight-replicator etr_replicator at 20890000: REPLICATOR enabled
[ 77.558828] coresight-replicator main_replicator at 208a0000: REPLICATOR enabled
[ 77.581068] coresight-funnel 208c0000.main_funnel: FUNNEL inport 0 enabled
[ 77.602217] coresight-tmc 20840000.etf: TMC-ETF enabled
[ 77.618422] coresight-stm 20860000.stm: STM tracing enabled
[ 139.554252] coresight-stm 20860000.stm: STM tracing disabled
# End of first tracing session
[ 146.351135] coresight-tmc 20800000.etr: TMC read start
[ 146.514486] coresight-tmc 20800000.etr: TMC read end
# Note that the STM is not turned on via stm_generic_link()->coresight_enable()
# and hence none of the components are turned on.
[ 152.479080] coresight-tmc 20800000.etr: TMC read start
[ 152.542632] coresight-tmc 20800000.etr: TMC read end
This patch balances the unlink operation by using the coresight_disable(),
keeping the coresight layer in sync with the hardware state.
Fixes: commit 237483aa5cf43 ("coresight: stm: adding driver for CoreSight STM component")
Cc: Pratik Patel <pratikp@codeaurora.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Chunyan Zhang <zhang.chunyan@linaro.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable at vger.kernel.org # 4.7+
Reported-by: Robert Walker <robert.walker@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
drivers/hwtracing/coresight/coresight-stm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-stm.c b/drivers/hwtracing/coresight/coresight-stm.c
index 3524452..57b7330 100644
--- a/drivers/hwtracing/coresight/coresight-stm.c
+++ b/drivers/hwtracing/coresight/coresight-stm.c
@@ -356,7 +356,7 @@ static void stm_generic_unlink(struct stm_data *stm_data,
if (!drvdata || !drvdata->csdev)
return;
- stm_disable(drvdata->csdev, NULL);
+ coresight_disable(drvdata->csdev);
}
static phys_addr_t
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] memory: aemif: allow passing device lookup table as platform data
From: Sekhar Nori @ 2017-01-10 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483526167-24209-2-git-send-email-bgolaszewski@baylibre.com>
On Wednesday 04 January 2017 04:06 PM, Bartosz Golaszewski wrote:
> TI aemif driver creates its own subnodes of the device tree in order
> to guarantee that all child devices are probed after the AEMIF timing
> parameters are configured.
>
> Some devices (e.g. da850) use struct of_dev_auxdata for clock lookup
> but nodes created from within the aemif driver can't access the lookup
> table.
>
> Create a platform data structure that holds a pointer to
> of_dev_auxdata so that we can use it with of_platform_populate().
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
I did not really see any precedent to passing of_dev_auxdata as platform
data, but the idea looks fine to me, so:
Acked-by: Sekhar Nori <nsekhar@ti.com>
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v29 4/9] arm64: kdump: implement machine_crash_shutdown()
From: Will Deacon @ 2017-01-10 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161228043605.27470-3-takahiro.akashi@linaro.org>
On Wed, Dec 28, 2016 at 01:36:01PM +0900, AKASHI Takahiro wrote:
> Primary kernel calls machine_crash_shutdown() to shut down non-boot cpus
> and save registers' status in per-cpu ELF notes before starting crash
> dump kernel. See kernel_kexec().
> Even if not all secondary cpus have shut down, we do kdump anyway.
>
> As we don't have to make non-boot(crashed) cpus offline (to preserve
> correct status of cpus at crash dump) before shutting down, this patch
> also adds a variant of smp_send_stop().
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> Reviewed-by: James Morse <james.morse@arm.com>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/include/asm/hardirq.h | 2 +-
> arch/arm64/include/asm/kexec.h | 42 +++++++++++++++++++++++++-
> arch/arm64/include/asm/smp.h | 2 ++
> arch/arm64/kernel/machine_kexec.c | 56 ++++++++++++++++++++++++++++++++--
> arch/arm64/kernel/smp.c | 63 +++++++++++++++++++++++++++++++++++++++
> 5 files changed, 160 insertions(+), 5 deletions(-)
[...]
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index d050d720a1b4..cea009f2657d 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -148,6 +148,8 @@ static inline void cpu_panic_kernel(void)
> */
> bool cpus_are_stuck_in_kernel(void);
>
> +extern void smp_send_crash_stop(void);
> +
> #endif /* ifndef __ASSEMBLY__ */
>
> #endif /* ifndef __ASM_SMP_H */
> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> index bc96c8a7fc79..c60346d33bb1 100644
> --- a/arch/arm64/kernel/machine_kexec.c
> +++ b/arch/arm64/kernel/machine_kexec.c
> @@ -9,6 +9,9 @@
> * published by the Free Software Foundation.
> */
>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/kernel.h>
> #include <linux/kexec.h>
> #include <linux/smp.h>
>
> @@ -22,6 +25,7 @@
> extern const unsigned char arm64_relocate_new_kernel[];
> extern const unsigned long arm64_relocate_new_kernel_size;
>
> +static bool in_crash_kexec;
Do you actually need this bool? Why not call kexec_crash_loaded() instead?
Will
^ permalink raw reply
* [PATCH v5 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
From: Alexandre Belloni @ 2017-01-10 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <81d5b553-38db-5137-2eac-145cb2f76578@axentia.se>
On 10/01/2017 at 12:21:42 +0100, Peter Rosin wrote :
> On 2017-01-10 11:42, Alexandre Belloni wrote:
> > On 10/01/2017 at 10:52:56 +0100, Peter Rosin wrote :
> >> On 2017-01-10 10:29, Alexandre Belloni wrote:
> >>> Hi,
> >>>
> >>> This needs a commit message, please add one.
> >>
> >> There's not all that much to say, but ok, I'll add something.
> >>
> >
> > It doesn't have to be long but it has to be present.
>
> Does it really? There are quite a few examples to contradict that,
> and checkpatch doesn't complain. That's no proof of course...
>
> As I said, I'll add something.
>
There is public shaming for maintainers taking patches without a commit
message, that's enough for me to require a commit message ;)
https://lwn.net/Articles/560392/
> >>> On 10/01/2017 at 09:08:51 +0100, Peter Rosin wrote :
> >> There's also the benefit of the increased chances of me getting
> >> notified of changes. I don't mind...
> >>
> >
> > Do you expect changes coming from third parties? I'm fine with it
> > anyway.
>
> Ok, I'll remember this and blame you for everything :-)
>
Well, you can let it there, I was just not sure whether you were
expecting to see patches or just trying to make checkpatch happy. As
said, I'm fine with it.
> >>>> +&main {
> >>>> + clock-frequency = <12000000>;
> >>>> +};
> >>>> +
> >>>
> >>> I don't think this is needed
> >>>
> >>>
> >>
> >> "this"? The &main frequency, or all of them?
> >>
> >
> > I meant just main
>
> Ok, I'll test with that change and then resend. Thanks!
>
> Cheers,
> peda
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ 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