* [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 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
* [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] 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 3/4] ARM: dts: stm32: stm32f7: Enable clocks for STM32F746 boards
From: Alexandre Torgue @ 2017-01-10 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483711165-17149-4-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 enables clocks for STM32F746 boards.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
In commit header, "stm32f7" is not usefull.
> arch/arm/boot/dts/stm32f746.dtsi | 29 +++++++++++++++++++++++++++--
> 1 file changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
> index f321ffe..e05e131 100644
> --- a/arch/arm/boot/dts/stm32f746.dtsi
> +++ b/arch/arm/boot/dts/stm32f746.dtsi
> @@ -43,6 +43,7 @@
> #include "skeleton.dtsi"
> #include "armv7-m.dtsi"
> #include <dt-bindings/pinctrl/stm32f746-pinfunc.h>
> +#include <dt-bindings/clock/stm32fx-clock.h>
This patch depends on another series not yet merged (maybe "[PATCH-next
... is a better header ?
>
> / {
> clocks {
> @@ -51,6 +52,24 @@
> compatible = "fixed-clock";
> clock-frequency = <0>;
> };
> +
> + clk-lse {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32768>;
> + };
> +
> + clk-lsi {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <32000>;
> + };
> +
> + clk_i2s_ckin: clk-i2s-ckin {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <48000000>;
> + };
> };
>
> soc {
> @@ -178,6 +197,11 @@
> interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>, <10>, <23>, <40>, <41>, <42>, <62>, <76>;
> };
>
> + pwrcfg: power-config at 40007000 {
> + compatible = "syscon";
> + reg = <0x40007000 0x400>;
> + };
> +
> pin-controller {
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -291,9 +315,10 @@
>
> rcc: rcc at 40023800 {
> #clock-cells = <2>;
> - compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
> + compatible = "st,stm32f746-rcc", "st,stm32-rcc";
> reg = <0x40023800 0x400>;
> - clocks = <&clk_hse>;
> + clocks = <&clk_hse>, <&clk_i2s_ckin>;
> + st,syscfg = <&pwrcfg>;
> };
> };
> };
>
^ permalink raw reply
* [PATCH] ARM: defconfig: include QCOM_EBI2 in multi_v7
From: Linus Walleij @ 2017-01-10 10:09 UTC (permalink / raw)
To: linux-arm-kernel
This adds the Qualcomm External Bus Interface 2 to the multi_v7
defconfig: it is hard for users to realize that this is a
required driver for getting things like ethernet, and a necessary
prerequisite to get the external bus discoverable on the
MSM8660/APQ8060 machines.
As regular users will likely want to have some ethernet and
other functionality up quickly, it makes sense to add this to
the multi_v7 defconfig.
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC folks: please just apply this wherever ARM multi_v7
defconfigs go if you're OK with it.
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index b01a43851294..267d0703caae 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -192,6 +192,7 @@ CONFIG_DEVTMPFS_MOUNT=y
CONFIG_DMA_CMA=y
CONFIG_CMA_SIZE_MBYTES=64
CONFIG_OMAP_OCP2SCP=y
+CONFIG_QCOM_EBI2=y
CONFIG_SIMPLE_PM_BUS=y
CONFIG_SUNXI_RSB=m
CONFIG_MTD=y
--
2.9.3
^ permalink raw reply related
* [PATCH v4 1/9] clk: stm32f4: Update DT bindings documentation
From: Alexandre Torgue @ 2017-01-10 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109193312.GN17126@codeaurora.org>
On 01/09/2017 08:33 PM, Stephen Boyd wrote:
> On 01/09, Alexandre Torgue wrote:
>> Hi Stephen,
>>
>> On 12/22/2016 01:10 AM, Stephen Boyd wrote:
>>> On 12/13, gabriel.fernandez at st.com wrote:
>>>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>>>
>>>> Creation of dt include file for specific stm32f4 clocks.
>>>> These specific clocks are not derived from system clock (SYSCLOCK)
>>>> We should use index 1 to use these clocks in DT.
>>>> e.g. <&rcc 1 CLK_LSI>
>>>>
>>>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>>>> Acked-by: Rob Herring <robh@kernel.org>
>>>> ---
>>>
>>> Applied to clk-stm32f4 and merged into clk-next.
>>>
>>
>> I'm preparing pull request branch for STM32 DT part. This patch is
>> also requested to build correctly DT patches. Do you know how could
>> we synchronize our pull request ?
>>
>
> clk-stm32f4 is stable and not going to be rebased, so you're good
> to base patches on it and send it off to arm-soc if the arm-soc
> maintainers agree to it. You can also base off an earlier part of
> the branch if you only need this first patch for example.
>
I will base my DT branch from 4.10-rc1 + this commit (seen with Arnd)
Thanks
^ permalink raw reply
* [QUESTION] Arm64: Query L3 cache info via DT
From: Sudeep Holla @ 2017-01-10 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5874A03A.9000901@huawei.com>
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.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] ARM: defconfig: qcom: add APQ8060 DragonBoard devices
From: Linus Walleij @ 2017-01-10 9:55 UTC (permalink / raw)
To: linux-arm-kernel
This default-enables the devices found on the APQ8060 DragonBoard
in the qcom_defconfig:
- EBI2 bus
- SMSC911x ethernet
- LEDs class and PM8058 LEDs driver, trigger and heartbeat
trigger (so we get heartbeat on the board by default)
- IIO framework, including the HRTimer trigger, KXSD9
accelerometer, MPU3050 gyroscope, AK8975 magnetometer and
BMP085 pressure sensor
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/configs/qcom_defconfig | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index 8c3a0108a231..eed314e39721 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -55,6 +55,7 @@ CONFIG_CFG80211=y
CONFIG_RFKILL=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_QCOM_EBI2=y
CONFIG_MTD=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_M25P80=y
@@ -71,6 +72,7 @@ CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_KS8851=y
+CONFIG_SMSC911X=y
CONFIG_MDIO_BITBANG=y
CONFIG_MDIO_GPIO=y
CONFIG_SLIP=y
@@ -151,6 +153,12 @@ CONFIG_MMC_QCOM_DML=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_SDHCI_MSM=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_PM8058=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_PM8XXX=y
CONFIG_DMADEVICES=y
@@ -171,6 +179,14 @@ CONFIG_QCOM_PM=y
CONFIG_QCOM_SMEM=y
CONFIG_QCOM_SMD=y
CONFIG_QCOM_SMD_RPM=y
+CONFIG_IIO=y
+CONFIG_IIO_BUFFER_CB=y
+CONFIG_IIO_SW_TRIGGER=y
+CONFIG_KXSD9=y
+CONFIG_MPU3050_I2C=y
+CONFIG_AK8975=y
+CONFIG_IIO_HRTIMER_TRIGGER=y
+CONFIG_BMP280=y
CONFIG_PHY_QCOM_APQ8064_SATA=y
CONFIG_PHY_QCOM_IPQ806X_SATA=y
CONFIG_EXT2_FS=y
--
2.9.3
^ permalink raw reply related
* [PATCH v5 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
From: Peter Rosin @ 2017-01-10 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170110092928.hwd4l4k3eyagepco@piout.net>
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.
> On 10/01/2017 at 09:08:51 +0100, Peter Rosin wrote :
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
>> ---
>> Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
>> MAINTAINERS | 8 +
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/at91-linea.dtsi | 53 +++++
>> arch/arm/boot/dts/at91-tse850-3.dts | 274 ++++++++++++++++++++++
>> 5 files changed, 355 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
>> create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
>> create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
>>
>> diff --git a/Documentation/devicetree/bindings/arm/axentia.txt b/Documentation/devicetree/bindings/arm/axentia.txt
>> new file mode 100644
>> index 000000000000..ea3fb96ae465
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/axentia.txt
>> @@ -0,0 +1,19 @@
>> +Device tree bindings for Axentia ARM devices
>> +============================================
>> +
>> +Linea CPU module
>> +----------------
>> +
>> +Required root node properties:
>> +compatible = "axentia,linea",
>> + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
>> +and following the rules from atmel-at91.txt for a sama5d31 SoC.
>> +
>> +
>> +TSE-850 v3 board
>> +----------------
>> +
>> +Required root node properties:
>> +compatible = "axentia,tse850v3", "axentia,linea",
>> + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
>> +and following the rules from above for the axentia,linea CPU module.
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 97b78cc5aa51..5c2ea6e9cd7f 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2346,6 +2346,14 @@ S: Maintained
>> F: Documentation/devicetree/bindings/sound/axentia,*
>> F: sound/soc/atmel/tse850-pcm5142.c
>>
>> +AXENTIA ARM DEVICES
>> +M: Peter Rosin <peda@axentia.se>
>> +L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>> +S: Maintained
>> +F: Documentation/devicetree/bindings/arm/axentia.txt
>> +F: arch/arm/boot/dts/at91-linea.dtsi
>> +F: arch/arm/boot/dts/at91-tse850-3.dts
>> +
>
> I don't think you need to add yourself to MAINTAINERS for two DTs if
> that is just to keep checkpatch happy, don't bother.
There's also the benefit of the increased chances of me getting
notified of changes. I don't mind...
>> AZ6007 DVB DRIVERV
>> M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
>> M: Mauro Carvalho Chehab <mchehab@kernel.org>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 9a7375c388a8..7632849866de 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
>> at91-kizbox2.dtb \
>> at91-sama5d2_xplained.dtb \
>> at91-sama5d3_xplained.dtb \
>> + at91-tse850-3.dtb \
>> sama5d31ek.dtb \
>> sama5d33ek.dtb \
>> sama5d34ek.dtb \
>> diff --git a/arch/arm/boot/dts/at91-linea.dtsi b/arch/arm/boot/dts/at91-linea.dtsi
>> new file mode 100644
>> index 000000000000..646feb0daa81
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/at91-linea.dtsi
>> @@ -0,0 +1,53 @@
>> +/*
>> + * at91-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
>> + *
>> + * Copyright (C) 2017 Axentia Technologies AB
>> + *
>> + * Author: Peter Rosin <peda@axentia.se>
>> + *
>> + * Licensed under GPLv2 or later.
>> + */
>> +
>> +#include "sama5d31.dtsi"
>> +
>> +/ {
>> + compatible = "axentia,linea",
>> + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
>> +
>> + memory {
>> + reg = <0x20000000 0x4000000>;
>> + };
>> +};
>> +
>> +&slow_xtal {
>> + clock-frequency = <32768>;
>> +};
>> +
>> +&main_xtal {
>> + clock-frequency = <12000000>;
>> +};
>> +
>> +&main {
>> + clock-frequency = <12000000>;
>> +};
>> +
>
> I don't think this is needed
>
>
"this"? The &main frequency, or all of them?
Cheers,
peda
^ permalink raw reply
* [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
From: Andreas Färber @ 2017-01-10 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <91f5ec74-1aa1-f2ad-24e9-14267cbe8498@phrozen.org>
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.
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
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.
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.
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.
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.
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).
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.
Also, none of what you've said justifies NAK'ing patch 4/4, which
applies to any mt7* and arm64 .dts, including yours.
While we're at it, I noticed that mainline has a "mediatek,mt7623-eth"
network driver but no corresponding .dtsi node. Talk about bitrot...
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH v2 3/6] ARM: dts: davinci: da850-lcdk: enable VPIF
From: Sekhar Nori @ 2017-01-10 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109205531.3435-4-khilman@baylibre.com>
On Tuesday 10 January 2017 02:25 AM, Kevin Hilman wrote:
> Enable VPIF for video captpure and configure input channel 0, used for
> composite input.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Applied to v4.11/dt
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 2/6] ARM: dts: davinci: da850-evm: enable VPIF
From: Sekhar Nori @ 2017-01-10 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109205531.3435-3-khilman@baylibre.com>
On Tuesday 10 January 2017 02:25 AM, Kevin Hilman wrote:
> Enable VPIF node for video capture, and configure ports. EVM board
> uses channel 0 for composite input and channel 1 S-Video input.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Applied to v4.11/dt
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: hw_breakpoint: blacklist Scorpion CPUs
From: Linus Walleij @ 2017-01-10 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483637556-3974-1-git-send-email-mark.rutland@arm.com>
On Thu, Jan 5, 2017 at 6:32 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On APQ8060, the kernel crashes in arch_hw_breakpoint_init, taking an
> undefined instruction trap within write_wb_reg. This is because Scorpion
> CPUs erroneously appear to set DBGPRSR.SPD when WFI is issued, even if
> the core is not powered down. When DBGPRSR.SPD is set, breakpoint and
> watchpoint registers are treated as undefined.
>
> It's possible to trigger similar crashes later on from userspace, by
> requesting the kernel to install a breakpoint or watchpoint, as we can
> go idle at any point between the reset of the debug registers and their
> later use. This has always been the case.
>
> Given that this has always been broken, no-one has complained until now,
> and there is no clear workaround, disable hardware breakpoints and
> watchpoints on Scorpion to avoid these issues.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Reported-by: Linus Walleij <linus.walleij@linaro.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: stable at vger.kernel.org
Dammit git send-email does not add people on Reported-by to the
CC list so I missed this.
It works like a charm however, thanks for looking into this:
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 1/6] ARM: dts: davinci: da850: VPIF: add node and muxing
From: Sekhar Nori @ 2017-01-10 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109205531.3435-2-khilman@baylibre.com>
On Tuesday 10 January 2017 02:25 AM, Kevin Hilman wrote:
> Add VPIF node an pins to da850 SoC. VPIF has two input channels which
s/an/and
> can be described using the standard DT ports and enpoints.
s/enpoints/endpoints
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> @@ -465,6 +488,7 @@
> status = "disabled";
> };
> };
> +
This seems like a stray newline addition. I dropped it while applying to
v4.11/dt
Thanks,
Sekhar
> aemif: aemif at 68000000 {
> compatible = "ti,da850-aemif";
> #address-cells = <2>;
>
^ permalink raw reply
* [PATCH v5 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
From: Alexandre Belloni @ 2017-01-10 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484035732-31635-2-git-send-email-peda@axentia.se>
Hi,
This needs a commit message, please add one.
On 10/01/2017 at 09:08:51 +0100, Peter Rosin wrote :
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
> MAINTAINERS | 8 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/at91-linea.dtsi | 53 +++++
> arch/arm/boot/dts/at91-tse850-3.dts | 274 ++++++++++++++++++++++
> 5 files changed, 355 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
> create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
> create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/axentia.txt b/Documentation/devicetree/bindings/arm/axentia.txt
> new file mode 100644
> index 000000000000..ea3fb96ae465
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/axentia.txt
> @@ -0,0 +1,19 @@
> +Device tree bindings for Axentia ARM devices
> +============================================
> +
> +Linea CPU module
> +----------------
> +
> +Required root node properties:
> +compatible = "axentia,linea",
> + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
> +and following the rules from atmel-at91.txt for a sama5d31 SoC.
> +
> +
> +TSE-850 v3 board
> +----------------
> +
> +Required root node properties:
> +compatible = "axentia,tse850v3", "axentia,linea",
> + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
> +and following the rules from above for the axentia,linea CPU module.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 97b78cc5aa51..5c2ea6e9cd7f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2346,6 +2346,14 @@ S: Maintained
> F: Documentation/devicetree/bindings/sound/axentia,*
> F: sound/soc/atmel/tse850-pcm5142.c
>
> +AXENTIA ARM DEVICES
> +M: Peter Rosin <peda@axentia.se>
> +L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> +S: Maintained
> +F: Documentation/devicetree/bindings/arm/axentia.txt
> +F: arch/arm/boot/dts/at91-linea.dtsi
> +F: arch/arm/boot/dts/at91-tse850-3.dts
> +
I don't think you need to add yourself to MAINTAINERS for two DTs if
that is just to keep checkpatch happy, don't bother.
> AZ6007 DVB DRIVERV
> M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> M: Mauro Carvalho Chehab <mchehab@kernel.org>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 9a7375c388a8..7632849866de 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
> at91-kizbox2.dtb \
> at91-sama5d2_xplained.dtb \
> at91-sama5d3_xplained.dtb \
> + at91-tse850-3.dtb \
> sama5d31ek.dtb \
> sama5d33ek.dtb \
> sama5d34ek.dtb \
> diff --git a/arch/arm/boot/dts/at91-linea.dtsi b/arch/arm/boot/dts/at91-linea.dtsi
> new file mode 100644
> index 000000000000..646feb0daa81
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91-linea.dtsi
> @@ -0,0 +1,53 @@
> +/*
> + * at91-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
> + *
> + * Copyright (C) 2017 Axentia Technologies AB
> + *
> + * Author: Peter Rosin <peda@axentia.se>
> + *
> + * Licensed under GPLv2 or later.
> + */
> +
> +#include "sama5d31.dtsi"
> +
> +/ {
> + compatible = "axentia,linea",
> + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
> +
> + memory {
> + reg = <0x20000000 0x4000000>;
> + };
> +};
> +
> +&slow_xtal {
> + clock-frequency = <32768>;
> +};
> +
> +&main_xtal {
> + clock-frequency = <12000000>;
> +};
> +
> +&main {
> + clock-frequency = <12000000>;
> +};
> +
I don't think this is needed
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [RESEND 2/3] ARM: davinci_all_defconfig: Enable PWM modules
From: Sekhar Nori @ 2017-01-10 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483978300-403-3-git-send-email-david@lechnology.com>
On Monday 09 January 2017 09:41 PM, David Lechner wrote:
> This enables PWM and the TI ECAP and EHRWPM modules. These are used on LEGO
> MINDSTORMS EV3.
>
> Signed-off-by: David Lechner <david@lechnology.com>
Applied to v4.11/defconfig
Thanks,
Sekhar
^ permalink raw reply
* [RESEND 1/3] ARM: davinci_all_defconfig: enable DA8xx pinconf
From: Sekhar Nori @ 2017-01-10 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483978300-403-2-git-send-email-david@lechnology.com>
On Monday 09 January 2017 09:41 PM, David Lechner wrote:
> This enables the DA8xx pinconf driver by default. It is needed by LEGO
> MINDSTORMS EV3.
>
> Signed-off-by: David Lechner <david@lechnology.com>
Applied to v4.11/defconfig
Thanks,
Sekhar
^ permalink raw reply
* [RESEND 3/3] ARM: davinci_all_defconfig: enable iio and ADS7950
From: Sekhar Nori @ 2017-01-10 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483978300-403-4-git-send-email-david@lechnology.com>
On Monday 09 January 2017 09:41 PM, David Lechner wrote:
> This enables the iio subsystem and the TI ADS7950 driver. This is used by
> LEGO MINDSTORMS EV3, which has an ADS7957 chip.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> arch/arm/configs/davinci_all_defconfig | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
> index 2b1967a..a899876 100644
> --- a/arch/arm/configs/davinci_all_defconfig
> +++ b/arch/arm/configs/davinci_all_defconfig
> @@ -200,6 +200,13 @@ CONFIG_TI_EDMA=y
> CONFIG_MEMORY=y
> CONFIG_TI_AEMIF=m
> CONFIG_DA8XX_DDRCTL=y
> +CONFIG_IIO=m
> +CONFIG_IIO_BUFFER_CB=m
> +CONFIG_IIO_SW_DEVICE=m
> +CONFIG_IIO_SW_TRIGGER=m
> +CONFIG_TI_ADS7950=m
> +CONFIG_IIO_HRTIMER_TRIGGER=m
> +CONFIG_IIO_SYSFS_TRIGGER=m
Hmm, there are some other comments I gave on the previous version I
don't see addressed. Can you please fix those or respond to those comments?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v8 0/5] Add support for the STM32F4 I2C
From: Linus Walleij @ 2017-01-10 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483607246-14771-1-git-send-email-cedric.madianga@gmail.com>
On Thu, Jan 5, 2017 at 10:07 AM, M'boumba Cedric Madianga
<cedric.madianga@gmail.com> wrote:
> This patchset adds support for the I2C controller embedded in STM32F4xx SoC.
> It enables I2C transfer in interrupt mode with Standard-mode and Fast-mode bus
> speed.
The whole series:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Looks perfect from my point of view now.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/3] arm64: dts: Pine64: add MMC support
From: kbuild test robot @ 2017-01-10 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484011353-21480-2-git-send-email-andre.przywara@arm.com>
Hi Andre,
[auto build test ERROR on mripard/sunxi/for-next]
[also build test ERROR on next-20170110]
[cannot apply to robh/for-next v4.10-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Andre-Przywara/arm64-dts-A64-board-MMC-support/20170110-124554
base: https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git sunxi/for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> Error: arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts:83.1-6 Label or path mmc0 not found
>> FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 33694 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170110/b272af74/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: sean.wang at mediatek.com @ 2017-01-10 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484039631-25120-1-git-send-email-sean.wang@mediatek.com>
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
+
+/* 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);
+
+ /* Reset decoder state machine */
+ ir_raw_event_reset(ir->rc);
+
+ /* First message must be pulse */
+ rawir.pulse = false;
+
+ /* 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);
+ }
+ }
+
+ /* 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);
+ 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);
+
+ 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 related
* [PATCH v2 1/2] Documentation: devicetree: Add document bindings for mtk-cir
From: sean.wang at mediatek.com @ 2017-01-10 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484039631-25120-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This patch adds documentation for devicetree bindings for
Mediatek consumer IR controller.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
.../devicetree/bindings/media/mtk-cir.txt | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt b/Documentation/devicetree/bindings/media/mtk-cir.txt
new file mode 100644
index 0000000..3850cbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
@@ -0,0 +1,24 @@
+Device-Tree bindings for Mediatek consumer IR controller found in
+Mediatek SoC family
+
+Required properties:
+- compatible : "mediatek,mt7623-cir"
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : should contain "clk" entries;
+- interrupts : should contain IR IRQ number;
+- reg : should contain IO map address for IR.
+
+Optional properties:
+- linux,rc-map-name : Remote control map name.
+
+Example:
+
+cir: cir at 10013000 {
+ compatible = "mediatek,mt7623-cir";
+ reg = <0 0x10013000 0 0x1000>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_IRRX>;
+ clock-names = "clk";
+ linux,rc-map-name = "rc-rc6-mce";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/2] media: rc: add support for IR receiver on MT7623 SoC
From: sean.wang at mediatek.com @ 2017-01-10 9:13 UTC (permalink / raw)
To: linux-arm-kernel
From: Sean Wang <sean.wang@mediatek.com>
This patchset introduces consumer IR (CIR) support on MT7623 SoC
that also works on other similar SoCs and implements raw mode for
more compatibility with different protocols. The driver simply
reports the duration of pulses and spaces to rc-core logic to
decode.
Changes since v1:
- change compatible string from "mediatek,mt7623-ir" into
"mediatek,mt7623-cir"
- use KBUILD_MODNAME to provide consistent device name used in driver.
- remove unused fields in struct mtk_ir.
- use synchronize_irq to give protection between IRQ handler and
remove handler.
- use devm_rc_allocate_device based on Andi Shyti's work.
- simplify error handling patch with devm_rc_register_device and devm_rc_allocate_device.
- remove unused spinlock.
- add comments about hardware limitation and related workarounds.
- enhance the caculation of sampling period for easiler assigned specific
value.
- refine git description.
- fix IR message handling between IR hardware and rc-core.
Sean Wang (2):
Documentation: devicetree: Add document bindings for mtk-cir
media: rc: add driver for IR remote receiver on MT7623 SoC
.../devicetree/bindings/media/mtk-cir.txt | 24 ++
drivers/media/rc/Kconfig | 11 +
drivers/media/rc/Makefile | 1 +
drivers/media/rc/mtk-cir.c | 326 +++++++++++++++++++++
4 files changed, 362 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
create mode 100644 drivers/media/rc/mtk-cir.c
--
2.7.4
^ permalink raw reply
* [PATCH v5 2/2] ARM: sama5_defconfig: add support for the Axentia TSE-850 board
From: Nicolas Ferre @ 2017-01-10 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484035732-31635-3-git-send-email-peda@axentia.se>
Le 10/01/2017 ? 09:08, Peter Rosin a ?crit :
> Signed-off-by: Peter Rosin <peda@axentia.se>
I know that most of the entries in this configuration file are direct
additions to the kernel but what about moving some of your additions to
modules?
Regards,
> ---
> arch/arm/configs/sama5_defconfig | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
> index aca8625b6fc9..bf5b3a73e38c 100644
> --- a/arch/arm/configs/sama5_defconfig
> +++ b/arch/arm/configs/sama5_defconfig
> @@ -131,7 +131,7 @@ CONFIG_GPIO_SYSFS=y
> CONFIG_POWER_SUPPLY=y
> CONFIG_BATTERY_ACT8945A=y
> CONFIG_POWER_RESET=y
> -# CONFIG_HWMON is not set
> +CONFIG_SENSORS_JC42=y
> CONFIG_WATCHDOG=y
> CONFIG_AT91SAM9X_WATCHDOG=y
> CONFIG_SAMA5D4_WATCHDOG=y
> @@ -142,6 +142,7 @@ CONFIG_REGULATOR=y
> CONFIG_REGULATOR_FIXED_VOLTAGE=y
> CONFIG_REGULATOR_ACT8865=y
> CONFIG_REGULATOR_ACT8945A=y
> +CONFIG_REGULATOR_PWM=y
> CONFIG_MEDIA_SUPPORT=y
> CONFIG_MEDIA_CAMERA_SUPPORT=y
> CONFIG_V4L_PLATFORM_DRIVERS=y
> @@ -164,6 +165,7 @@ CONFIG_SND_ATMEL_SOC=y
> CONFIG_SND_ATMEL_SOC_WM8904=y
> # CONFIG_HID_GENERIC is not set
> CONFIG_SND_ATMEL_SOC_PDMIC=y
> +CONFIG_SND_ATMEL_SOC_TSE850_PCM5142=y
> CONFIG_USB=y
> CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> CONFIG_USB_EHCI_HCD=y
> @@ -199,6 +201,9 @@ CONFIG_AT_XDMAC=y
> CONFIG_IIO=y
> CONFIG_AT91_ADC=y
> CONFIG_AT91_SAMA5D2_ADC=y
> +CONFIG_ENVELOPE_DETECTOR=y
> +CONFIG_DPOT_DAC=y
> +CONFIG_MCP4531=y
> CONFIG_PWM=y
> CONFIG_PWM_ATMEL=y
> CONFIG_PWM_ATMEL_HLCDC_PWM=y
>
--
Nicolas Ferre
^ 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