* [PATCH v3 7/7] ARM: dts: stm32: add stm32 general purpose timer driver in DT
From: Benjamin Gaignard @ 2016-12-02 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480673842-20804-1-git-send-email-benjamin.gaignard@st.com>
Add general purpose timers and it sub-nodes into DT for stm32f4.
Define and enable pwm1 and pwm3 for stm32f469 discovery board
version 3:
- use "st,stm32-timer-trigger" in DT
version 2:
- use parameters to describe hardware capabilities
- do not use references for pwm and iio timer subnodes
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 333 +++++++++++++++++++++++++++++++++-
arch/arm/boot/dts/stm32f469-disco.dts | 28 +++
2 files changed, 360 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index bca491d..8c50d03 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -48,7 +48,7 @@
#include "skeleton.dtsi"
#include "armv7-m.dtsi"
#include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
-
+#include <dt-bindings/iio/timer/st,stm32-timer-triggers.h>
/ {
clocks {
clk_hse: clk-hse {
@@ -355,6 +355,21 @@
slew-rate = <2>;
};
};
+
+ pwm1_pins: pwm at 1 {
+ pins {
+ pinmux = <STM32F429_PA8_FUNC_TIM1_CH1>,
+ <STM32F429_PB13_FUNC_TIM1_CH1N>,
+ <STM32F429_PB12_FUNC_TIM1_BKIN>;
+ };
+ };
+
+ pwm3_pins: pwm at 3 {
+ pins {
+ pinmux = <STM32F429_PB4_FUNC_TIM3_CH1>,
+ <STM32F429_PB5_FUNC_TIM3_CH2>;
+ };
+ };
};
rcc: rcc at 40023810 {
@@ -426,6 +441,322 @@
interrupts = <80>;
clocks = <&rcc 0 38>;
};
+
+ gptimer1: gptimer1 at 40010000 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40010000 0x400>;
+ clocks = <&rcc 0 160>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm1 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ st,breakinput;
+ st,complementary;
+ status = "disabled";
+ };
+
+ timer1 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <27>;
+ st,input-triggers-names = TIM5_TRGO,
+ TIM2_TRGO,
+ TIM4_TRGO,
+ TIM3_TRGO;
+ st,output-triggers-names = TIM1_TRGO,
+ TIM1_CH1,
+ TIM1_CH2,
+ TIM1_CH3,
+ TIM1_CH4;
+ status = "disabled";
+ };
+ };
+
+ gptimer2: gptimer2 at 40000000 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40000000 0x400>;
+ clocks = <&rcc 0 128>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm2 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ st,32bits-counter;
+ status = "disabled";
+ };
+
+ timer2 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <28>;
+ st,input-triggers-names = TIM1_TRGO,
+ TIM8_TRGO,
+ TIM3_TRGO,
+ TIM4_TRGO;
+ st,output-triggers-names = TIM2_TRGO,
+ TIM2_CH1,
+ TIM2_CH2,
+ TIM2_CH3,
+ TIM2_CH4;
+ status = "disabled";
+ };
+ };
+
+ gptimer3: gptimer3 at 40000400 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40000400 0x400>;
+ clocks = <&rcc 0 129>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm3 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ status = "disabled";
+ };
+
+ timer3 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <29>;
+ st,input-triggers-names = TIM1_TRGO,
+ TIM8_TRGO,
+ TIM5_TRGO,
+ TIM4_TRGO;
+ st,output-triggers-names = TIM3_TRGO,
+ TIM3_CH1,
+ TIM3_CH2,
+ TIM3_CH3,
+ TIM3_CH4;
+ status = "disabled";
+ };
+ };
+
+ gptimer4: gptimer4 at 40000800 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40000800 0x400>;
+ clocks = <&rcc 0 130>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm4 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ status = "disabled";
+ };
+
+ timer4 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <30>;
+ st,input-triggers-names = TIM1_TRGO,
+ TIM2_TRGO,
+ TIM3_TRGO,
+ TIM8_TRGO;
+ st,output-triggers-names = TIM4_TRGO,
+ TIM4_CH1,
+ TIM4_CH2,
+ TIM4_CH3,
+ TIM4_CH4;
+ status = "disabled";
+ };
+ };
+
+ gptimer5: gptimer5 at 40000C00 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40000C00 0x400>;
+ clocks = <&rcc 0 131>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm5 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ st,32bits-counter;
+ status = "disabled";
+ };
+
+ timer5 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <50>;
+ st,input-triggers-names = TIM2_TRGO,
+ TIM3_TRGO,
+ TIM4_TRGO,
+ TIM8_TRGO;
+ st,output-triggers-names = TIM5_TRGO,
+ TIM5_CH1,
+ TIM5_CH2,
+ TIM5_CH3,
+ TIM5_CH4;
+ status = "disabled";
+ };
+ };
+
+ gptimer6: gptimer6 at 40001000 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40001000 0x400>;
+ clocks = <&rcc 0 132>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ timer6 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <54>;
+ st,output-triggers-names = TIM6_TRGO;
+ status = "disabled";
+ };
+ };
+
+ gptimer7: gptimer7 at 40001400 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40001400 0x400>;
+ clocks = <&rcc 0 133>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ timer7 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <55>;
+ st,output-triggers-names = TIM7_TRGO;
+ status = "disabled";
+ };
+ };
+
+ gptimer8: gptimer8 at 40010400 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40010400 0x400>;
+ clocks = <&rcc 0 161>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm8 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <4>;
+ st,complementary;
+ st,breakinput;
+ status = "disabled";
+ };
+
+ timer8 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <46>;
+ st,input-triggers-names = TIM1_TRGO,
+ TIM2_TRGO,
+ TIM4_TRGO,
+ TIM5_TRGO;
+ st,output-triggers-names = TIM8_TRGO,
+ TIM8_CH1,
+ TIM8_CH2,
+ TIM8_CH3,
+ TIM8_CH4;
+ status = "disabled";
+ };
+ };
+
+ gptimer9: gptimer9 at 40014000 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40014000 0x400>;
+ clocks = <&rcc 0 176>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm9 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <2>;
+ status = "disabled";
+ };
+
+ timer9 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <24>;
+ st,input-triggers-names = TIM2_TRGO,
+ TIM3_TRGO;
+ st,output-triggers-names = TIM9_TRGO,
+ TIM9_CH1,
+ TIM9_CH2;
+ status = "disabled";
+ };
+ };
+
+ gptimer10: gptimer10 at 40014400 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40014400 0x400>;
+ clocks = <&rcc 0 177>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm10 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <1>;
+ status = "disabled";
+ };
+ };
+
+ gptimer11: gptimer11 at 40014800 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40014800 0x400>;
+ clocks = <&rcc 0 178>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm11 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <1>;
+ status = "disabled";
+ };
+ };
+
+ gptimer12: gptimer12 at 40001800 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40001800 0x400>;
+ clocks = <&rcc 0 134>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm12 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <2>;
+ status = "disabled";
+ };
+
+ timer12 at 0 {
+ compatible = "st,stm32-timer-trigger";
+ interrupts = <43>;
+ st,input-triggers-names = TIM4_TRGO,
+ TIM5_TRGO;
+ st,output-triggers-names = TIM12_TRGO,
+ TIM12_CH1,
+ TIM12_CH2;
+ status = "disabled";
+ };
+ };
+
+ gptimer13: gptimer13 at 40001C00 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40001C00 0x400>;
+ clocks = <&rcc 0 135>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm13 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <1>;
+ status = "disabled";
+ };
+ };
+
+ gptimer14: gptimer14 at 40002000 {
+ compatible = "st,stm32-gptimer";
+ reg = <0x40002000 0x400>;
+ clocks = <&rcc 0 136>;
+ clock-names = "clk_int";
+ status = "disabled";
+
+ pwm14 at 0 {
+ compatible = "st,stm32-pwm";
+ st,pwm-num-chan = <1>;
+ status = "disabled";
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index 8a163d7..df4ca7e 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -81,3 +81,31 @@
&usart3 {
status = "okay";
};
+
+&gptimer1 {
+ status = "okay";
+
+ pwm1 at 0 {
+ pinctrl-0 = <&pwm1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ timer1 at 0 {
+ status = "okay";
+ };
+};
+
+&gptimer3 {
+ status = "okay";
+
+ pwm3 at 0 {
+ pinctrl-0 = <&pwm3_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ timer3 at 0 {
+ status = "okay";
+ };
+};
--
1.9.1
^ permalink raw reply related
* XHCI controller does not detect USB key insertion
From: Mason @ 2016-12-02 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87inr2vh2l.fsf@linux.intel.com>
On 02/12/2016 10:03, Felipe Balbi wrote:
> Mason wrote:
>
>> I'm trying out a SoC with a brand new USB controller, which is (supposedly)
>> a standard XHCI controller. In theory, I would just need to build the right
>> driver, and everything would auto-magically work, right?
>
> perhaps, but there might be needed initialization of other resources
> like PHYs and stuff like that.
Let me dive into additional details...
First of all, there is a register aptly called "USB3_RESET" which
is used to release several USB3-related blocks from reset.
Of course, that's the first register I tweaked :-)
There are *3* address ranges with USB3-related registers.
1) one called host_usb30_xhcl (I believe "xhcl" is a typo for "xhci")
This is the address I passed to the Linux driver. The first register
is CAPLENGTH_VERSION. I assume these are the standard XHCI registers.
(Last register is XHCL_EXTENDED_CAP3_USB3 at offset 0xc008)
2) one called host_usb30_port
This contains "Device and Port Specific Registers".
Is it standard?
How is Linux supposed to know where to find it?
Contains registers such as
Device Transaction Status
Device UTMI command and status for USB2
Set ISOC Delay
USB3 Function Notification
Rx DMA BD Start Address for Control Endpoint
EP Burst Size
Tx DMA BD Start Address Control Endpoint
EP $N IN/OUT
Device Notification Register
EP_Isochronous Timestamp
Are registers named LTSSM_TIMER_REGISTER{1,2,3} standard?
they have fields such as reg_12_ms_timeout (and other numbers like 2, 6, 100, 300)
3) one called host_usb30
This contains lower-level stuff
0x2e800 CONFIG
0x2e804 CONTROL
0x2e808 TEST
0x2e80c STATUS
0x2e810 CLK_RST_0
0x2e814 CLK_RST_1
0x2e818 PARAM_0
0x2e81c PARAM_1
0x2e820 PARAM_2
0x2e880 SNPS_CR_ADD
0x2e884 SNPS_CR_DATA
0x2e8c0 RESET_CTRL
I haven't touched any of these so far.
>> # lsusb -v
>> Bus 001 Device 001: ID 1d6b:0002
>> Bus 002 Device 001: ID 1d6b:0003
Isn't lsusb verbose supposed to print much more than that?
>> I'd like to hear suggestions about what I can tweak to fix the problem.
>
> go to your documentation and see if you have initialized
> everything. Which SoC is this?
(Sad face) All the documentation I have is in front of me, and nothing
is ringing a bell. This is a Sigma Designs SoC, with a Pravega XHCI
controller + Synopsys PHY.
The documentation I have:
Pravega_Dual_Mode_Datasheet_v10c.pdf (documents IP signals)
Pravega_Dual_Mode_Controller_Programmers_Reference_manual_v1.pdf (documents IP registers)
PHY databook (very low-level stuff)
SoC register mapping (for how the SoC maps the IP signals to registers)
So far, I'm stumped :-(
Regards.
^ permalink raw reply
* [RFC PATCH] PCI: designware: add host_init() error handling
From: Joao Pinto @ 2016-12-02 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480593077-15402-1-git-send-email-srinivas.kandagatla@linaro.org>
Hi Srinivas,
?s 11:51 AM de 12/1/2016, Srinivas Kandagatla escreveu:
> drivers/pci/host/pci-dra7xx.c | 4 +++-
> drivers/pci/host/pci-exynos.c | 4 +++-
> drivers/pci/host/pci-imx6.c | 4 +++-
> drivers/pci/host/pci-keystone.c | 4 +++-
> drivers/pci/host/pci-layerscape.c | 12 ++++++++----
> drivers/pci/host/pcie-armada8k.c | 4 +++-
> drivers/pci/host/pcie-designware-plat.c | 4 +++-
> drivers/pci/host/pcie-designware.c | 4 +++-
> drivers/pci/host/pcie-designware.h | 2 +-
> drivers/pci/host/pcie-qcom.c | 6 ++++--
> drivers/pci/host/pcie-spear13xx.c | 4 +++-
> 11 files changed, 37 insertions(+), 15 deletions(-)
>
Thanks for the patch!
In my opinion your idea is good but only qcom driver is able to detect failure
in the specific host init routine, all others have a 'return 0' even if
something not well init. I would recomend that we take this issue a bit further
and add the error checking to all specific pci drivers in order to make them as
robust as qcom'.
Thanks,
Joao
^ permalink raw reply
* XHCI controller does not detect USB key insertion
From: Greg KH @ 2016-12-02 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58414BC5.109@free.fr>
On Fri, Dec 02, 2016 at 11:24:05AM +0100, Mason wrote:
> >> # lsusb -v
> >> Bus 001 Device 001: ID 1d6b:0002
> >> Bus 002 Device 001: ID 1d6b:0003
>
> Isn't lsusb verbose supposed to print much more than that?
Yes, if you are using the usbutils version of 'lsusb', odds are this is
busybox, right?
And these are just the root hubs, that the USB controller driver creates
as "virtual" USB devices, they are not "real" USB devices on your bus.
hope this helps,
greg k-h
^ permalink raw reply
* [Linaro-acpi] [PATCH V1 1/2] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version
From: Robert Richter @ 2016-12-02 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <30ad6c65-4a4a-6346-00f6-11250133a251@semihalf.com>
On 02.12.16 11:06:24, Tomasz Nowicki wrote:
> On 02.12.2016 07:42, Duc Dang wrote:
> >@@ -98,16 +98,16 @@ struct mcfg_fixup {
> > { "CAVIUM", "THUNDERX", rev, seg, MCFG_BUS_ANY, \
> > &pci_thunder_ecam_ops }
> > /* SoC pass1.x */
> >- THUNDER_PEM_QUIRK(2, 0), /* off-chip devices */
> >- THUNDER_PEM_QUIRK(2, 1), /* off-chip devices */
> >- THUNDER_ECAM_QUIRK(2, 0),
> >- THUNDER_ECAM_QUIRK(2, 1),
> >- THUNDER_ECAM_QUIRK(2, 2),
> >- THUNDER_ECAM_QUIRK(2, 3),
> >- THUNDER_ECAM_QUIRK(2, 10),
> >- THUNDER_ECAM_QUIRK(2, 11),
> >- THUNDER_ECAM_QUIRK(2, 12),
> >- THUNDER_ECAM_QUIRK(2, 13),
> >+ THUNDER_PEM_QUIRK(2, 0UL), /* off-chip devices */
> >+ THUNDER_PEM_QUIRK(2, 1UL), /* off-chip devices */
> >+ THUNDER_ECAM_QUIRK(2, 0UL),
> >+ THUNDER_ECAM_QUIRK(2, 1UL),
> >+ THUNDER_ECAM_QUIRK(2, 2UL),
> >+ THUNDER_ECAM_QUIRK(2, 3UL),
> >+ THUNDER_ECAM_QUIRK(2, 10UL),
> >+ THUNDER_ECAM_QUIRK(2, 11UL),
> >+ THUNDER_ECAM_QUIRK(2, 12UL),
> >+ THUNDER_ECAM_QUIRK(2, 13UL),
> >
>
> The UL suffix is needed for *THUNDER_PEM_QUIRK* only. THUNDER_ECAM_QUIRK is
> fine.
We should better make the type cast part of the macro.
+ this:
---
#define THUNDER_MCFG_RES(addr, node) \
DEFINE_RES_MEM(addr + (node << 44), 0x39 * SZ_16M)
---
The args in the macro need parentheses.
-Robert
^ permalink raw reply
* [RFC PATCH 0/2] arm64: memory-hotplug: Add Memory Hotplug support
From: Will Deacon @ 2016-12-02 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <18021c70-a4a0-3007-c861-82ede74f965e@virtualopensystems.com>
On Fri, Dec 02, 2016 at 10:13:43AM +0100, Maciej Bielski wrote:
> Recently we have announced our effort on that:
> https://lkml.org/lkml/2016/11/17/49
>
> For now we have a working solution for hotplug and we are performing
> code cleanup to push the patches soon.
Are these intended to replace or extend Scott's patches? If the former,
please work with Scott's stuff as a base rather than posting a competing
series.
Will
^ permalink raw reply
* [RFC PATCH 0/2] arm64: memory-hotplug: Add Memory Hotplug support
From: Maciej Bielski @ 2016-12-02 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202104907.GB8266@arm.com>
On 02/12/2016 11:49, Will Deacon wrote:
> On Fri, Dec 02, 2016 at 10:13:43AM +0100, Maciej Bielski wrote:
>> Recently we have announced our effort on that:
>> https://lkml.org/lkml/2016/11/17/49
>>
>> For now we have a working solution for hotplug and we are performing
>> code cleanup to push the patches soon.
> Are these intended to replace or extend Scott's patches? If the former,
> please work with Scott's stuff as a base rather than posting a competing
> series.
In the piece of code provided by Scott I have seen similar steps to what
is done by us but our work went further since we have the mapping
created and everything is working via the sysfs interface. I am now
having closer look and comparing them.
>
> Will
--
Maciej Bielski
^ permalink raw reply
* [PATCH 1/2] arm64: Get rid of asm/opcodes.h
From: Catalin Marinas @ 2016-12-02 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480589074-809-2-git-send-email-marc.zyngier@arm.com>
On Thu, Dec 01, 2016 at 10:44:33AM +0000, Marc Zyngier wrote:
> The opcodes.h drags in a lot of definition from the 32bit port, most
> of which is not required at all. Clean things up a bit by moving
> the bare minimum of what is required next to the actual users,
> and drop the include file.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/include/asm/opcodes.h | 5 -----
> arch/arm64/include/asm/sysreg.h | 16 ++++++++++------
> arch/arm64/kernel/armv8_deprecated.c | 5 ++++-
> arch/arm64/kernel/insn.c | 1 -
I applied the first patch. I assume the second one, once it gets into
its final shape, will be merged via the Xen tree.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH 1/3] ARM: da850: fix infinite loop in clk_set_rate()
From: Sekhar Nori @ 2016-12-02 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480612516-18853-2-git-send-email-bgolaszewski@baylibre.com>
Hi Bartosz,
On Thursday 01 December 2016 10:45 PM, Bartosz Golaszewski wrote:
> The aemif clock is added twice to the lookup table in da850.c. This
> breaks the children list of pll0_sysclk3 as we're using the same list
> links in struct clk. When calling clk_set_rate(), we get stuck in
> propagate_rate().
>
> Simply add the clock once, but specify both the con_id and dev_id in
> the lookup entry.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The issue is real, but the fix is not going to be this simple, I am
afraid. This will break NAND on all da850 boards including LCDK.
The aemif clock is accessed in two ways. One by the
drivers/memory/ti-aemif.c, using ti-aemif as the device name and NULL
connection id. Second by drivers/mtd/nand/davinci_nand.c and
arch/arm/mach-davinci/aemif.c using davinci-nand as device id and with
"aemif" as the connection id.
We will need to match both. The only way to fix this without breaking
anything is to create two clocks for the two lookups above. Both cannot
be PSC clocks for the same PSC module as that would be racy. Instead
just create a new nand clock node which is a child of the aemif node and
inherits parent's clock rate.
Thanks,
Sekhar
^ permalink raw reply
* XHCI controller does not detect USB key insertion
From: Mason @ 2016-12-02 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202104208.GA8736@kroah.com>
On 02/12/2016 11:42, Greg KH wrote:
> On Fri, Dec 02, 2016 at 11:24:05AM +0100, Mason wrote:
>
>> # lsusb -v
>> Bus 001 Device 001: ID 1d6b:0002
>> Bus 002 Device 001: ID 1d6b:0003
>>
>> Isn't lsusb verbose supposed to print much more than that?
>
> Yes, if you are using the usbutils version of 'lsusb', odds are this is
> busybox, right?
Right. (You win a digital cookie.)
cd buildroot && make menuconfig
Drop BR2_PACKAGE_USBMOUNT (maybe it causes unexpected issues)
Add BR2_PACKAGE_USBUTILS (I want the real deal)
> And these are just the root hubs, that the USB controller driver creates
> as "virtual" USB devices, they are not "real" USB devices on your bus.
# lsusb --version
lsusb (usbutils) 007
I see there's a 008 version.
Am I missing out on important diagnostics?
# lsusb -v
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 3
bMaxPacketSize0 9
idVendor 0x1d6b Linux Foundation
idProduct 0x0003 3.0 root hub
bcdDevice 4.07
iManufacturer 3 Linux 4.7.0-rc6 xhci-hcd
iProduct 2 xHCI Host Controller
iSerial 1 30040000.usb3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 31
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
bMaxBurst 0
Hub Descriptor:
bLength 12
bDescriptorType 42
nNbrPorts 1
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
bHubDecLat 0.0 micro seconds
wHubDelay 0 nano seconds
DeviceRemovable 0x00
Hub Port Status:
Port 1: 0000.02a0 5Gbps power Rx.Detect
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 15
bNumDeviceCaps 1
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x00
wSpeedsSupported 0x0008
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 3
Lowest fully-functional device speed is SuperSpeed (5Gbps)
bU1DevExitLat 0 micro seconds
bU2DevExitLat 0 micro seconds
Device Status: 0x0001
Self Powered
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 4.07
iManufacturer 3 Linux 4.7.0-rc6 xhci-hcd
iProduct 2 xHCI Host Controller
iSerial 1 30040000.usb3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 9
bDescriptorType 41
nNbrPorts 1
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00
PortPwrCtrlMask 0xff
Hub Port Status:
Port 1: 0000.0100 power
Device Status: 0x0001
Self Powered
Does everything look normal?
Or are there any investigation-worthy nuggets?
Regards.
^ permalink raw reply
* [PATCH] trace: extend trace_clock to support arch_arm clock counter
From: Will Deacon @ 2016-12-02 11:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480666495-26536-1-git-send-email-sramana@codeaurora.org>
On Fri, Dec 02, 2016 at 01:44:55PM +0530, Srinivas Ramana wrote:
> Extend the trace_clock to support the arch timer cycle
> counter so that we can get the monotonic cycle count
> in the traces. This will help in correlating the traces with the
> timestamps/events in other subsystems in the soc which share
> this common counter for driving their timers.
I'm not sure I follow this reasoning. What's wrong with nanoseconds? In
particular, the "perf" trace_clock hangs off sched_clock, which should
be backed by the architected counter anyway. What does the cycle counter in
isolation tell you, given that the frequency isn't architected?
I think I'm missing something here.
Will
^ permalink raw reply
* XHCI controller does not detect USB key insertion
From: Greg KH @ 2016-12-02 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58415625.3020703@free.fr>
On Fri, Dec 02, 2016 at 12:08:21PM +0100, Mason wrote:
> On 02/12/2016 11:42, Greg KH wrote:
>
> > On Fri, Dec 02, 2016 at 11:24:05AM +0100, Mason wrote:
> >
> >> # lsusb -v
> >> Bus 001 Device 001: ID 1d6b:0002
> >> Bus 002 Device 001: ID 1d6b:0003
> >>
> >> Isn't lsusb verbose supposed to print much more than that?
> >
> > Yes, if you are using the usbutils version of 'lsusb', odds are this is
> > busybox, right?
>
> Right. (You win a digital cookie.)
Yeah!
{munch munch}
> cd buildroot && make menuconfig
> Drop BR2_PACKAGE_USBMOUNT (maybe it causes unexpected issues)
> Add BR2_PACKAGE_USBUTILS (I want the real deal)
>
> > And these are just the root hubs, that the USB controller driver creates
> > as "virtual" USB devices, they are not "real" USB devices on your bus.
>
> # lsusb --version
> lsusb (usbutils) 007
> I see there's a 008 version.
Wow, 008 was released in 2014, what type of old repo are you using that
has 007 as the "latest"?
And I really should go do a new update, lots of bug fixes have happened
since 2014...
> Am I missing out on important diagnostics?
Not really, if you are not doing a lot of USB 3-only device specific
work, which is where the majority of the changes have happened in the
past 2 years in the tool.
>
> # lsusb -v
>
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
<snip>
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
<snip>
> Does everything look normal?
Yes, two internal "virtual" hubs.
> Or are there any investigation-worthy nuggets?
You need to figure out why the driver isn't getting interrupts, that's
the main problem for your hardware at the moment, lsusb isn't going to
help you out at all with that...
good luck!
greg k-h
^ permalink raw reply
* [PATCH 3/3] ARM: da850: fix da850_set_pll0rate()
From: Sekhar Nori @ 2016-12-02 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480612516-18853-4-git-send-email-bgolaszewski@baylibre.com>
On Thursday 01 December 2016 10:45 PM, Bartosz Golaszewski wrote:
> This function is broken - its second argument is an index to the freq
> table, not the requested clock rate in Hz. It leads to an oops when
> called from clk_set_rate() since this argument isn't bounds checked
> either.
>
> Fix it by iterating over the array of supported frequencies and
> selecting a one that matches or returning -EINVAL for unsupported
> rates.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
When this function was written, it was written for speed. The only user
of setting pll0 rate is drivers/cpufreq/davinci-cpufreq.c (not sure how
you were trying to set pll0 rate). And that driver directly passes the
table index to the set_rate() function.
The idea was to optimize for speed in cpufreq driver and quickly index
into the pll data instead of searching through it.
But I agree, it is confusing and we are better off with maintainable
code. So, no problem with the patch, but this needs to be done along
with updates to cpufreq driver.
> ---
> arch/arm/mach-davinci/da850.c | 22 ++++++++++++++++++----
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> index 855b720..1c0f296 100644
> --- a/arch/arm/mach-davinci/da850.c
> +++ b/arch/arm/mach-davinci/da850.c
> @@ -1173,14 +1173,28 @@ static int da850_set_armrate(struct clk *clk, unsigned long index)
> return clk_set_rate(pllclk, index);
> }
>
> -static int da850_set_pll0rate(struct clk *clk, unsigned long index)
> +static int da850_set_pll0rate(struct clk *clk, unsigned long requested_rate)
Calling it just 'rate' is fine, IMO. The name of the function is enough
to suggest that its the rate to be set to.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 1/3] ARM: dts: at91: add dma1 definition to sama5d2
From: Alexandre Belloni @ 2016-12-02 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201104949.23985-1-nicolas.ferre@atmel.com>
On 01/12/2016 at 11:49:47 +0100, Nicolas Ferre wrote :
> The sama5d2 SoC has a second DMA controller and can be used just like DMA0.
> By default both DMA controllers are configured as "Secure" in
> MATRIX_SPSELR so we can use whichever we want in a "single Secure World"
> configuration.
> Surprisingly the DMA1 has a lower address than DMA0. To avoid confusion
> place it after DMA0 node anyway.
>
sama5d2.dtsi is probably the only one that is properly ordered and I
feel like we should keep it this way.
If one of the nodes is not ordered properly, other ones will follow...
We don't care about the name, it is just an alias. We only care about
the address.
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> arch/arm/boot/dts/sama5d2.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
> index ceb9783ff7e1..c791ce9c750c 100644
> --- a/arch/arm/boot/dts/sama5d2.dtsi
> +++ b/arch/arm/boot/dts/sama5d2.dtsi
> @@ -395,6 +395,16 @@
> clock-names = "dma_clk";
> };
>
> + /* Place dma1 here despite its address */
> + dma1: dma-controller at f0004000 {
> + compatible = "atmel,sama5d4-dma";
> + reg = <0xf0004000 0x1000>;
> + interrupts = <7 IRQ_TYPE_LEVEL_HIGH 0>;
> + #dma-cells = <1>;
> + clocks = <&dma1_clk>;
> + clock-names = "dma_clk";
> + };
> +
> pmc: pmc at f0014000 {
> compatible = "atmel,sama5d2-pmc", "syscon";
> reg = <0xf0014000 0x160>;
> --
> 2.9.0
>
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] Add crypto driver support for some MediaTek chips
From: mtk09577 @ 2016-12-02 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202081836.GA20128@Red>
Hello,
On Fri, 2016-12-02 at 09:18 +0100, Corentin Labbe wrote:
> Hello
>
> I have some minor comment inline
>
> On Fri, Dec 02, 2016 at 11:26:44AM +0800, Ryder Lee wrote:
> > This adds support for the MediaTek hardware accelerator on
> > mt7623/mt2701/mt8521p SoC.
> >
> > This driver currently implement:
> > - SHA1 and SHA2 family(HMAC) hash alogrithms.
> > - AES block cipher in CBC/ECB mode with 128/196/256 bits keys.
>
> I see also a PRNG but is seems not really used.
Yes, PRNG is not implemented yet, i will remove it temporarily.
> >
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > drivers/crypto/Kconfig | 17 +
> > drivers/crypto/Makefile | 1 +
> > drivers/crypto/mediatek/Makefile | 2 +
> > drivers/crypto/mediatek/mtk-aes.c | 734 +++++++++++++++++
> > drivers/crypto/mediatek/mtk-platform.c | 575 +++++++++++++
> > drivers/crypto/mediatek/mtk-platform.h | 230 ++++++
> > drivers/crypto/mediatek/mtk-regs.h | 194 +++++
> > drivers/crypto/mediatek/mtk-sha.c | 1384 ++++++++++++++++++++++++++++++++
> > 8 files changed, 3137 insertions(+)
> > create mode 100644 drivers/crypto/mediatek/Makefile
> > create mode 100644 drivers/crypto/mediatek/mtk-aes.c
> > create mode 100644 drivers/crypto/mediatek/mtk-platform.c
> > create mode 100644 drivers/crypto/mediatek/mtk-platform.h
> > create mode 100644 drivers/crypto/mediatek/mtk-regs.h
> > create mode 100644 drivers/crypto/mediatek/mtk-sha.c
> >
> > diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> > index 4d2b81f..5d9c803 100644
> > --- a/drivers/crypto/Kconfig
> > +++ b/drivers/crypto/Kconfig
> > @@ -553,6 +553,23 @@ config CRYPTO_DEV_ROCKCHIP
> > This driver interfaces with the hardware crypto accelerator.
> > Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
> >
> > +config CRYPTO_DEV_MEDIATEK
> > + tristate "MediaTek's Cryptographic Engine driver"
> > + depends on ARM && ARCH_MEDIATEK
> > + select NEON
> > + select KERNEL_MODE_NEON
> > + select ARM_CRYPTO
> > + select CRYPTO_AES
> > + select CRYPTO_BLKCIPHER
> > + select CRYPTO_SHA1_ARM_NEON
> > + select CRYPTO_SHA256_ARM
> > + select CRYPTO_SHA512_ARM
> > + select CRYPTO_HMAC
>
> Why do you select accelerated algos ?
> Adding COMPILE_TEST could be helpfull also.
Our Hardware has complex procedure on calculate HMAC, and it get a bad
performance.... So i decide to use ARM NEON instruction as fallback to
speedup it.
I will add COMPILE_TEST.
> [...]
> > +
> > +#include <linux/dma-mapping.h>
> > +#include <linux/scatterlist.h>
> > +#include <crypto/scatterwalk.h>
> > +#include <crypto/algapi.h>
> > +#include <crypto/aes.h>
> > +#include "mtk-platform.h"
> > +#include "mtk-regs.h"
> > +
>
> Sort headers in alphabetical order
>
> [...]
> > +
> > + mtk_aes_unregister_algs();
> > + mtk_aes_record_free(cryp);
> > +}
> > +EXPORT_SYMBOL(mtk_cipher_alg_release);
>
> Why not EXPORT_SYMBOL_GPL ?
> Furthermore do you really need it to be exported ?
My mistake. I will remove it.
> [...]
> > +
> > +#include <linux/init.h>
> > +#include <linux/module.h>
> > +#include <linux/kernel.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/pm_runtime.h>
> > +#include <linux/clk.h>
> > +#include <linux/platform_device.h>
> > +#include "mtk-platform.h"
> > +#include "mtk-regs.h"
> > +
>
> Sort headers in alphabetical order
>
> [...]
> > +
> > +static void mtk_prng_reseed(struct mtk_cryp *cryp)
> > +{
> > + /* 8 words to seed the PRNG to provide IVs */
> > + void __iomem *base = cryp->base;
> > + const u32 prng_key[8] = {0x48c24cfd, 0x6c07f742,
> > + 0xaee75681, 0x0f27c239,
> > + 0x79947198, 0xe2991275,
> > + 0x21ac3c7c, 0xd008c4b4};
>
> Why do you seed with thoses constant ?
>
> [...]
> > +
> > +static int mtk_accelerator_init(struct mtk_cryp *cryp)
> > +{
> > + int i, err;
> > +
> > + /* Initialize advanced interrupt controller(AIC) */
> > + for (i = 0; i < 5; i++) {
>
> I see this 5 for interrupt away, so perhaps a define could be used
>
> [...]
>
> here
>
> > + for (i = 0; i < 5; i++) {
> > + cryp->irq[i] = platform_get_irq(pdev, i);
> > + if (cryp->irq[i] < 0) {
> > + dev_err(cryp->dev, "no IRQ:%d resource info\n", i);
> > + return -ENXIO;
> > + }
> > + }
> [...]
> > +#ifndef __MTK_PLATFORM_H_
> > +#define __MTK_PLATFORM_H_
> > +
> > +#include <linux/crypto.h>
> > +#include <crypto/internal/hash.h>
> > +#include <linux/interrupt.h>
>
> Sort headers in alphabetical order
>
> [...]
> > +#define MTK_DESC_FIRST BIT(23)
> > +#define MTK_DESC_BUF_LEN(x) ((x) & 0x1ffff)
> > +#define MTK_DESC_CT_LEN(x) (((x) & 0xff) << 24)
> > +
> > +#define WORD(x) ((x) >> 2)
>
> dangerous and ambigous define
I will define a IRQ_NUM and modify ambiguous definition.
> [...]
> > +
> > +#include <linux/dma-mapping.h>
> > +#include <linux/scatterlist.h>
> > +#include <linux/crypto.h>
> > +#include <crypto/scatterwalk.h>
> > +#include <crypto/algapi.h>
> > +#include <crypto/sha.h>
> > +#include <crypto/internal/hash.h>
>
> Sort headers in alphabetical order
> [...]
> Generally more function comment could be helpfull.
I will sort all header and add more function comment.
Thanks for your review.
> Regards
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Dave Martin @ 2016-12-02 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3e8afc5a-1ba9-6369-462b-4f5a707d8b8a@redhat.com>
On Wed, Nov 30, 2016 at 01:38:28PM +0100, Florian Weimer wrote:
[...]
> We could add a system call to get the right stack size. But as it depends
> on VL, I'm not sure what it looks like. Particularly if you need determine
> the stack size before creating a thread that uses a specific VL setting.
I missed this point previously -- apologies for that.
What would you think of:
set_vl(vl_for_new_thread);
minsigstksz = get_minsigstksz();
set_vl(my_vl);
This avoids get_minsigstksz() requiring parameters -- which is mainly a
concern because the parameters tomorrow might be different from the
parameters today.
If it is possible to create the new thread without any SVE-dependent code,
then we could
set_vl(vl_for_new_thread);
new_thread_stack = malloc(get_minsigstksz());
new_thread = create_thread(..., new_thread_stack);
set_vl(my_vl);
which has the nice property that the new thread directly inherits the
configuration that was used for get_minsigstksz().
However, it would be necessary to prevent GCC from moving any code
across these statements -- in particular, SVE code that access VL-
dependent data spilled on the stack is liable to go wrong if reordered
with the above. So the sequence would need to go in an external
function (or a single asm...)
Failing that, we could maybe define some extensible struct to
get_minsigstksz().
Thoughts?
Cheers
---Dave
^ permalink raw reply
* [RFC PATCH] PCI: designware: add host_init() error handling
From: Srinivas Kandagatla @ 2016-12-02 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f2c8ebba-e51a-5f47-2d96-c75f7e086c0e@synopsys.com>
On 02/12/16 10:32, Joao Pinto wrote:
>
> Hi Srinivas,
>
> ?s 11:51 AM de 12/1/2016, Srinivas Kandagatla escreveu:
>> drivers/pci/host/pci-dra7xx.c | 4 +++-
>> drivers/pci/host/pci-exynos.c | 4 +++-
>> drivers/pci/host/pci-imx6.c | 4 +++-
>> drivers/pci/host/pci-keystone.c | 4 +++-
>> drivers/pci/host/pci-layerscape.c | 12 ++++++++----
>> drivers/pci/host/pcie-armada8k.c | 4 +++-
>> drivers/pci/host/pcie-designware-plat.c | 4 +++-
>> drivers/pci/host/pcie-designware.c | 4 +++-
>> drivers/pci/host/pcie-designware.h | 2 +-
>> drivers/pci/host/pcie-qcom.c | 6 ++++--
>> drivers/pci/host/pcie-spear13xx.c | 4 +++-
>> 11 files changed, 37 insertions(+), 15 deletions(-)
>>
>
> Thanks for the patch!
>
> In my opinion your idea is good but only qcom driver is able to detect failure
> in the specific host init routine, all others have a 'return 0' even if
> something not well init. I would recomend that we take this issue a bit further
> and add the error checking to all specific pci drivers in order to make them as
> robust as qcom'.
I totally agree with you, I can give this a go in next version.
Thanks,
srini
>
> Thanks,
> Joao
>
^ permalink raw reply
* [PATCH 1/2] Add crypto driver support for some MediaTek chips
From: Ryder Lee @ 2016-12-02 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202081836.GA20128@Red>
Hello,
On Fri, 2016-12-02 at 09:18 +0100, Corentin Labbe wrote:
> Hello
>
> I have some minor comment inline
>
> On Fri, Dec 02, 2016 at 11:26:44AM +0800, Ryder Lee wrote:
> > This adds support for the MediaTek hardware accelerator on
> > mt7623/mt2701/mt8521p SoC.
> >
> > This driver currently implement:
> > - SHA1 and SHA2 family(HMAC) hash alogrithms.
> > - AES block cipher in CBC/ECB mode with 128/196/256 bits keys.
>
> I see also a PRNG but is seems not really used.
Yes, PRNG is not implemented yet, i will remove it temporarily.
> >
> > Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> > ---
> > drivers/crypto/Kconfig | 17 +
> > drivers/crypto/Makefile | 1 +
> > drivers/crypto/mediatek/Makefile | 2 +
> > drivers/crypto/mediatek/mtk-aes.c | 734 +++++++++++++++++
> > drivers/crypto/mediatek/mtk-platform.c | 575 +++++++++++++
> > drivers/crypto/mediatek/mtk-platform.h | 230 ++++++
> > drivers/crypto/mediatek/mtk-regs.h | 194 +++++
> > drivers/crypto/mediatek/mtk-sha.c | 1384
++++++++++++++++++++++++++++++++
> > 8 files changed, 3137 insertions(+)
> > create mode 100644 drivers/crypto/mediatek/Makefile
> > create mode 100644 drivers/crypto/mediatek/mtk-aes.c
> > create mode 100644 drivers/crypto/mediatek/mtk-platform.c
> > create mode 100644 drivers/crypto/mediatek/mtk-platform.h
> > create mode 100644 drivers/crypto/mediatek/mtk-regs.h
> > create mode 100644 drivers/crypto/mediatek/mtk-sha.c
> >
> > diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> > index 4d2b81f..5d9c803 100644
> > --- a/drivers/crypto/Kconfig
> > +++ b/drivers/crypto/Kconfig
> > @@ -553,6 +553,23 @@ config CRYPTO_DEV_ROCKCHIP
> > This driver interfaces with the hardware crypto accelerator.
> > Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher
mode.
> >
> > +config CRYPTO_DEV_MEDIATEK
> > + tristate "MediaTek's Cryptographic Engine driver"
> > + depends on ARM && ARCH_MEDIATEK
> > + select NEON
> > + select KERNEL_MODE_NEON
> > + select ARM_CRYPTO
> > + select CRYPTO_AES
> > + select CRYPTO_BLKCIPHER
> > + select CRYPTO_SHA1_ARM_NEON
> > + select CRYPTO_SHA256_ARM
> > + select CRYPTO_SHA512_ARM
> > + select CRYPTO_HMAC
>
> Why do you select accelerated algos ?
> Adding COMPILE_TEST could be helpfull also.
Our Hardware has complex procedure on calculate HMAC, and it get a bad
performance.... So i decide to use ARM NEON instruction as fallback to
speedup it.
I will add COMPILE_TEST.
> [...]
> > +
> > +#include <linux/dma-mapping.h>
> > +#include <linux/scatterlist.h>
> > +#include <crypto/scatterwalk.h>
> > +#include <crypto/algapi.h>
> > +#include <crypto/aes.h>
> > +#include "mtk-platform.h"
> > +#include "mtk-regs.h"
> > +
>
> Sort headers in alphabetical order
>
> [...]
> > +
> > + mtk_aes_unregister_algs();
> > + mtk_aes_record_free(cryp);
> > +}
> > +EXPORT_SYMBOL(mtk_cipher_alg_release);
>
> Why not EXPORT_SYMBOL_GPL ?
> Furthermore do you really need it to be exported ?
My mistake. I will remove it.
> [...]
> > +
> > +#include <linux/init.h>
> > +#include <linux/module.h>
> > +#include <linux/kernel.h>
> > +#include <linux/mfd/syscon.h>
> > +#include <linux/pm_runtime.h>
> > +#include <linux/clk.h>
> > +#include <linux/platform_device.h>
> > +#include "mtk-platform.h"
> > +#include "mtk-regs.h"
> > +
>
> Sort headers in alphabetical order
>
> [...]
> > +
> > +static void mtk_prng_reseed(struct mtk_cryp *cryp)
> > +{
> > + /* 8 words to seed the PRNG to provide IVs */
> > + void __iomem *base = cryp->base;
> > + const u32 prng_key[8] = {0x48c24cfd, 0x6c07f742,
> > + 0xaee75681, 0x0f27c239,
> > + 0x79947198, 0xe2991275,
> > + 0x21ac3c7c, 0xd008c4b4};
>
> Why do you seed with thoses constant ?
>
> [...]
> > +
> > +static int mtk_accelerator_init(struct mtk_cryp *cryp)
> > +{
> > + int i, err;
> > +
> > + /* Initialize advanced interrupt controller(AIC) */
> > + for (i = 0; i < 5; i++) {
>
> I see this 5 for interrupt away, so perhaps a define could be used
>
> [...]
>
> here
>
> > + for (i = 0; i < 5; i++) {
> > + cryp->irq[i] = platform_get_irq(pdev, i);
> > + if (cryp->irq[i] < 0) {
> > + dev_err(cryp->dev, "no IRQ:%d resource info\n",
i);
> > + return -ENXIO;
> > + }
> > + }
> [...]
> > +#ifndef __MTK_PLATFORM_H_
> > +#define __MTK_PLATFORM_H_
> > +
> > +#include <linux/crypto.h>
> > +#include <crypto/internal/hash.h>
> > +#include <linux/interrupt.h>
>
> Sort headers in alphabetical order
>
> [...]
> > +#define MTK_DESC_FIRST BIT(23)
> > +#define MTK_DESC_BUF_LEN(x) ((x) & 0x1ffff)
> > +#define MTK_DESC_CT_LEN(x) (((x) & 0xff) << 24)
> > +
> > +#define WORD(x) ((x) >> 2)
>
> dangerous and ambigous define
I will define a IRQ_NUM and modify ambiguous definition.
> [...]
> > +
> > +#include <linux/dma-mapping.h>
> > +#include <linux/scatterlist.h>
> > +#include <linux/crypto.h>
> > +#include <crypto/scatterwalk.h>
> > +#include <crypto/algapi.h>
> > +#include <crypto/sha.h>
> > +#include <crypto/internal/hash.h>
>
> Sort headers in alphabetical order
> [...]
> Generally more function comment could be helpfull.
I will sort all header and add more function comment.
Thanks for your review.
> Regards
^ permalink raw reply
* [PATCH RESEND 2/2] gpio: axp209: add pinctrl support
From: Linus Walleij @ 2016-12-02 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f46c89f2-478b-93b8-5a66-12d1307d4514@free-electrons.com>
On Tue, Nov 29, 2016 at 11:13 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
> So basically:
>
> - first patch for adding pinctrl to the existing driver
> - second patch for moving the driver and binding from gpio to pinctrl
> subsystem
> - third patch for both removing Kconfig entry and Makefile rule from
> gpio subsystem, and adding a Kconfig entry and a Makefile rule in
> pinctrl subsystem
>
> Is that what you want?
No.
Make the patch moving it to pinctrl first. This will be the same as
the patch augmenting Kcongfig and Makefile or it will not compile.
Then a second patch to add the pinctrl features.
Yours,
Linus Walleij
^ permalink raw reply
* [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Arnd Bergmann @ 2016-12-02 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e15e76e2-b32d-a4d0-eb8b-850626a3946a@linaro.org>
On Friday, December 2, 2016 8:21:33 AM CET zhangfei wrote:
> Hi, Arnd
>
> On 2016?12?01? 20:05, Arnd Bergmann wrote:
> > On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
> >> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> >> + 0x20 0x10 /* 1: i2c1 */
> >> + 0x20 0x20 /* 2: i2c2 */
> >> + 0x20 0x8000000>; /* 3: i2c6 */
> >> + };
> >> +
> >> +Specifying reset lines connected to IP modules
> >> +==============================================
> >> +example:
> >> +
> >> + i2c0: i2c at ..... {
> >> + ...
> >> + resets = <&iomcu_rst 0>;
> >> + ...
> >> + };
> > I don't really like this approach, since now the information is
> > in two places. Why not put the data into the reset specifier
> > directly when it is used?
> Any example, still not understand.
> They are consumer and provider.
I mean in the i2c node, have
i2c0: i2c at ..... {
...
resets = <&iomcu_rst 0x20 0x8>;
...
}
> > Also the format seems a little too close to the actual register
> > layout and could be a little more abstract, using bit numbers instead
> > of a bitmask and register numbers instead of offsets.
> We use bit numbers first.
> But in the developing process, we found several bits may be required for
> one driver.
> And they may not be continuous as the bits may already be occupied.
> Directly using offset, we can set several bits together for simple, to
> give more flexibility.
> So after discussion, we directly use offset.
Can you give an example for why this is needed? Is this different
from a device that has multiple reset lines?
Arnd
^ permalink raw reply
* [PATCH] ARM/ARM64: defconfig: drop GPIO_SYSFS on multiplatforms
From: Linus Walleij @ 2016-12-02 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5151997.6RlLpvHqsO@wuerfel>
On Wed, Nov 30, 2016 at 11:04 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, November 24, 2016 3:57:52 PM CET Linus Walleij wrote:
>> The sysfs ABI to GPIO is marked obsolete and should not be
>> encouraged. Users should be encouraged to switch to using the
>> character device.
(...)
>> arch/arm/configs/multi_v5_defconfig | 1 -
>> arch/arm/configs/multi_v7_defconfig | 1 -
>> arch/arm64/configs/defconfig | 1 -
>
> Hmm, while this is a trivial change, we normally put the defconfig
> changes for arm and arm64 into two separate next/* branches.
>
> I've split the patch up accordingly and slightly modified the
> changelog text to match.
OK thanks a lot Arnd, I was a bit uncertain about that.
Yours,
Linus Walleij
^ permalink raw reply
* [RESEND PATCH] pinctrl: mt8173: set GPIO16 to usb iddig mode
From: Linus Walleij @ 2016-12-02 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480472491-4644-1-git-send-email-chunfeng.yun@mediatek.com>
On Wed, Nov 30, 2016 at 3:21 AM, Chunfeng Yun <chunfeng.yun@mediatek.com> wrote:
> the default mode of GPIO16 pin is gpio, when set EINT16 to
> IRQ_TYPE_LEVEL_HIGH, no interrupt is triggered, it can be
> fixed when set its default mode as usb iddig.
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Patch applied with Hongzhou's ACK!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 3/3] ARM: da850: fix da850_set_pll0rate()
From: Bartosz Golaszewski @ 2016-12-02 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4b1d65f7-d9a6-6d4e-00f5-2835b728661c@ti.com>
2016-12-02 12:20 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
> On Thursday 01 December 2016 10:45 PM, Bartosz Golaszewski wrote:
>> This function is broken - its second argument is an index to the freq
>> table, not the requested clock rate in Hz. It leads to an oops when
>> called from clk_set_rate() since this argument isn't bounds checked
>> either.
>>
>> Fix it by iterating over the array of supported frequencies and
>> selecting a one that matches or returning -EINVAL for unsupported
>> rates.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> When this function was written, it was written for speed. The only user
> of setting pll0 rate is drivers/cpufreq/davinci-cpufreq.c (not sure how
> you were trying to set pll0 rate). And that driver directly passes the
> table index to the set_rate() function.
>
Hi Sekhar, thanks for the hints.
The origin of this series is the default pll0 frequency set by
upstream u-boot which caused FIFO underflows in LCDC even with the
pixel clock well below 37.5 MHz. I had already sent a patch to the
u-boot mailing list, but thought I'd try setting the clock from within
tilcdc code. This is when I stumbled upon this issue.
I'll send a v2 of this series.
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [PATCH 06/12] usb: dwc3: omap: Replace the extcon API
From: Chanwoo Choi @ 2016-12-02 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fum6vh1p.fsf@linux.intel.com>
Hi Felipe,
2016-12-02 18:03 GMT+09:00 Felipe Balbi <balbi@kernel.org>:
>
> Hi,
>
> Chanwoo Choi <cw00.choi@samsung.com> writes:
>> Hi Felipe,
>>
>> On 2016? 11? 30? 19:36, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Chanwoo Choi <cw00.choi@samsung.com> writes:
>>>> This patch uses the resource-managed extcon API for extcon_register_notifier()
>>>> and replaces the deprecated extcon API as following:
>>>> - extcon_get_cable_state_() -> extcon_get_state()
>>>>
>>>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>
>>> Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
>>>
>>
>> Thanks for your review.
>>
>> Each patch has no any dependency among patches.
>> So, If possible, could you pick the patch6/8/9/10/11/12 on your tree?
>
> my tree is closed for v4.10, I can pick it up for v4.11
Thanks for your pickup to 4.11.
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH v3 7/7] ARM: dts: stm32: add stm32 general purpose timer driver in DT
From: Lee Jones @ 2016-12-02 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480673842-20804-8-git-send-email-benjamin.gaignard@st.com>
On Fri, 02 Dec 2016, Benjamin Gaignard wrote:
> Add general purpose timers and it sub-nodes into DT for stm32f4.
> Define and enable pwm1 and pwm3 for stm32f469 discovery board
>
> version 3:
> - use "st,stm32-timer-trigger" in DT
>
> version 2:
> - use parameters to describe hardware capabilities
> - do not use references for pwm and iio timer subnodes
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 333 +++++++++++++++++++++++++++++++++-
> arch/arm/boot/dts/stm32f469-disco.dts | 28 +++
> 2 files changed, 360 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index bca491d..8c50d03 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -48,7 +48,7 @@
> #include "skeleton.dtsi"
> #include "armv7-m.dtsi"
> #include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
> -
> +#include <dt-bindings/iio/timer/st,stm32-timer-triggers.h>
> / {
> clocks {
> clk_hse: clk-hse {
> @@ -355,6 +355,21 @@
> slew-rate = <2>;
> };
> };
> +
> + pwm1_pins: pwm at 1 {
> + pins {
> + pinmux = <STM32F429_PA8_FUNC_TIM1_CH1>,
> + <STM32F429_PB13_FUNC_TIM1_CH1N>,
> + <STM32F429_PB12_FUNC_TIM1_BKIN>;
> + };
> + };
> +
> + pwm3_pins: pwm at 3 {
> + pins {
> + pinmux = <STM32F429_PB4_FUNC_TIM3_CH1>,
> + <STM32F429_PB5_FUNC_TIM3_CH2>;
> + };
> + };
> };
>
> rcc: rcc at 40023810 {
> @@ -426,6 +441,322 @@
> interrupts = <80>;
> clocks = <&rcc 0 38>;
> };
> +
> + gptimer1: gptimer1 at 40010000 {
timer at xxxxxxx
Node names should be generic and not numbered.
I suggest that this isn't actually a timer either. Is contains a
timer (and a PWM), but in it's completeness it is not a timer per
say.
> + compatible = "st,stm32-gptimer";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm1 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,breakinput;
> + st,complementary;
> + status = "disabled";
> + };
> +
> + timer1 at 0 {
> + compatible = "st,stm32-timer-trigger";
> + interrupts = <27>;
> + st,input-triggers-names = TIM5_TRGO,
> + TIM2_TRGO,
> + TIM4_TRGO,
> + TIM3_TRGO;
I'm still dubious with matching by strings.
I'll take a look at the C code to see what the alternatives could be.
> + st,output-triggers-names = TIM1_TRGO,
> + TIM1_CH1,
> + TIM1_CH2,
> + TIM1_CH3,
> + TIM1_CH4;
> + status = "disabled";
> + };
> + };
> +
> + gptimer2: gptimer2 at 40000000 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40000000 0x400>;
> + clocks = <&rcc 0 128>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm2 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,32bits-counter;
> + status = "disabled";
> + };
> +
> + timer2 at 0 {
> + compatible = "st,stm32-timer-trigger";
> + interrupts = <28>;
> + st,input-triggers-names = TIM1_TRGO,
> + TIM8_TRGO,
> + TIM3_TRGO,
> + TIM4_TRGO;
> + st,output-triggers-names = TIM2_TRGO,
> + TIM2_CH1,
> + TIM2_CH2,
> + TIM2_CH3,
> + TIM2_CH4;
> + status = "disabled";
> + };
> + };
> +
> + gptimer3: gptimer3 at 40000400 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40000400 0x400>;
> + clocks = <&rcc 0 129>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm3 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + status = "disabled";
> + };
> +
> + timer3 at 0 {
> + compatible = "st,stm32-timer-trigger";
> + interrupts = <29>;
> + st,input-triggers-names = TIM1_TRGO,
> + TIM8_TRGO,
> + TIM5_TRGO,
> + TIM4_TRGO;
> + st,output-triggers-names = TIM3_TRGO,
> + TIM3_CH1,
> + TIM3_CH2,
> + TIM3_CH3,
> + TIM3_CH4;
> + status = "disabled";
> + };
> + };
> +
> + gptimer4: gptimer4 at 40000800 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40000800 0x400>;
> + clocks = <&rcc 0 130>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm4 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + status = "disabled";
> + };
> +
> + timer4 at 0 {
> + compatible = "st,stm32-timer-trigger";
> + interrupts = <30>;
> + st,input-triggers-names = TIM1_TRGO,
> + TIM2_TRGO,
> + TIM3_TRGO,
> + TIM8_TRGO;
> + st,output-triggers-names = TIM4_TRGO,
> + TIM4_CH1,
> + TIM4_CH2,
> + TIM4_CH3,
> + TIM4_CH4;
> + status = "disabled";
> + };
> + };
> +
> + gptimer5: gptimer5 at 40000C00 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40000C00 0x400>;
> + clocks = <&rcc 0 131>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm5 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,32bits-counter;
> + status = "disabled";
> + };
> +
> + timer5 at 0 {
> + compatible = "st,stm32-timer-trigger";
> + interrupts = <50>;
> + st,input-triggers-names = TIM2_TRGO,
> + TIM3_TRGO,
> + TIM4_TRGO,
> + TIM8_TRGO;
> + st,output-triggers-names = TIM5_TRGO,
> + TIM5_CH1,
> + TIM5_CH2,
> + TIM5_CH3,
> + TIM5_CH4;
> + status = "disabled";
> + };
> + };
> +
> + gptimer6: gptimer6 at 40001000 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40001000 0x400>;
> + clocks = <&rcc 0 132>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + timer6 at 0 {
> + compatible = "st,stm32-timer-trigger";
> + interrupts = <54>;
> + st,output-triggers-names = TIM6_TRGO;
> + status = "disabled";
> + };
> + };
> +
> + gptimer7: gptimer7 at 40001400 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40001400 0x400>;
> + clocks = <&rcc 0 133>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + timer7 at 0 {
> + compatible = "st,stm32-timer-trigger";
> + interrupts = <55>;
> + st,output-triggers-names = TIM7_TRGO;
> + status = "disabled";
> + };
> + };
> +
> + gptimer8: gptimer8 at 40010400 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40010400 0x400>;
> + clocks = <&rcc 0 161>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm8 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <4>;
> + st,complementary;
> + st,breakinput;
> + status = "disabled";
> + };
> +
> + timer8 at 0 {
> + compatible = "st,stm32-timer-trigger";
> + interrupts = <46>;
> + st,input-triggers-names = TIM1_TRGO,
> + TIM2_TRGO,
> + TIM4_TRGO,
> + TIM5_TRGO;
> + st,output-triggers-names = TIM8_TRGO,
> + TIM8_CH1,
> + TIM8_CH2,
> + TIM8_CH3,
> + TIM8_CH4;
> + status = "disabled";
> + };
> + };
> +
> + gptimer9: gptimer9 at 40014000 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40014000 0x400>;
> + clocks = <&rcc 0 176>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm9 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <2>;
> + status = "disabled";
> + };
> +
> + timer9 at 0 {
> + compatible = "st,stm32-timer-trigger";
> + interrupts = <24>;
> + st,input-triggers-names = TIM2_TRGO,
> + TIM3_TRGO;
> + st,output-triggers-names = TIM9_TRGO,
> + TIM9_CH1,
> + TIM9_CH2;
> + status = "disabled";
> + };
> + };
> +
> + gptimer10: gptimer10 at 40014400 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40014400 0x400>;
> + clocks = <&rcc 0 177>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm10 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <1>;
> + status = "disabled";
> + };
> + };
> +
> + gptimer11: gptimer11 at 40014800 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40014800 0x400>;
> + clocks = <&rcc 0 178>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm11 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <1>;
> + status = "disabled";
> + };
> + };
> +
> + gptimer12: gptimer12 at 40001800 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40001800 0x400>;
> + clocks = <&rcc 0 134>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm12 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <2>;
> + status = "disabled";
> + };
> +
> + timer12 at 0 {
> + compatible = "st,stm32-timer-trigger";
> + interrupts = <43>;
> + st,input-triggers-names = TIM4_TRGO,
> + TIM5_TRGO;
> + st,output-triggers-names = TIM12_TRGO,
> + TIM12_CH1,
> + TIM12_CH2;
> + status = "disabled";
> + };
> + };
> +
> + gptimer13: gptimer13 at 40001C00 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40001C00 0x400>;
> + clocks = <&rcc 0 135>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm13 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <1>;
> + status = "disabled";
> + };
> + };
> +
> + gptimer14: gptimer14 at 40002000 {
> + compatible = "st,stm32-gptimer";
> + reg = <0x40002000 0x400>;
> + clocks = <&rcc 0 136>;
> + clock-names = "clk_int";
> + status = "disabled";
> +
> + pwm14 at 0 {
> + compatible = "st,stm32-pwm";
> + st,pwm-num-chan = <1>;
> + status = "disabled";
> + };
> + };
> };
> };
>
> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
> index 8a163d7..df4ca7e 100644
> --- a/arch/arm/boot/dts/stm32f469-disco.dts
> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
> @@ -81,3 +81,31 @@
> &usart3 {
> status = "okay";
> };
> +
> +&gptimer1 {
> + status = "okay";
> +
> + pwm1 at 0 {
> + pinctrl-0 = <&pwm1_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> + };
> +
> + timer1 at 0 {
> + status = "okay";
> + };
> +};
This is a much *better* format than before.
I still don't like the '&' syntax though.
> +&gptimer3 {
> + status = "okay";
> +
> + pwm3 at 0 {
> + pinctrl-0 = <&pwm3_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> + };
> +
> + timer3 at 0 {
> + status = "okay";
> + };
> +};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ 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