* [PATCH 0/2] Enable clock controllers on MSM
From: Kumar Gala @ 2014-01-23 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <878uu6y5im.fsf@paris.lan>
On Jan 23, 2014, at 11:25 AM, Kevin Hilman <khilman@linaro.org> wrote:
> Stephen Boyd <sboyd@codeaurora.org> writes:
>
>> These patches add the clock controller nodes, enable the clock drivers
>> on MSM based platforms, and hook it up enough to get the serial console
>> working. This is based on the merge of Mike's clk-next branch with
>> linux-next-20140116. The changes need the clk-next branch because that's
>> where the DTS include files landed.
>
> I forgot to repond to this earlier, but I tested this on top of -next
> and it gets the dragonboard booting w/mainline. Yay!
>
>> Perhaps this can be applied after 3.14-rc1 is out?
>
> Yeah, sounds good.
>
> Kevin
We?ll need arm-soc to pull in the clk changes from Mike?s tree for that.
> Stephen Boyd (2):
>> ARM: dts: msm: Add clock controller nodes and hook into uart
>> ARM: msm_defconfig: Enable MSM clock drivers
>>
>> arch/arm/boot/dts/qcom-msm8660-surf.dts | 11 +++++++++++
>> arch/arm/boot/dts/qcom-msm8960-cdp.dts | 18 ++++++++++++++++++
>> arch/arm/boot/dts/qcom-msm8974.dtsi | 24 ++++++++++++++++++++++++
>> arch/arm/configs/msm_defconfig | 4 ++++
>> 4 files changed, 57 insertions(+)
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Andreas Herrmann @ 2014-01-23 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3d0a888e122f490ba6bbc80b1aaa977c@BL2PR03MB468.namprd03.prod.outlook.com>
On Wed, Jan 22, 2014 at 07:07:40PM +0000, Varun Sethi wrote:
> > -----Original Message-----
> > From: Will Deacon [mailto:will.deacon at arm.com]
> > Sent: Wednesday, January 22, 2014 9:04 PM
> > To: Sethi Varun-B16395
> > Cc: Andreas Herrmann; iommu at lists.linux-foundation.org; linux-arm-
> > kernel at lists.infradead.org; Andreas Herrmann
> > Subject: Re: [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group
> > notifier block
> >
> > On Wed, Jan 22, 2014 at 01:54:11PM +0000, Varun Sethi wrote:
> > > > > > Ok, so are you suggesting that we perform the isolation mapping
> > > > > > in arm_smmu_add_device and drop the notifier altogether?
> > > > > I think that should be fine, until we want to delay mapping
> > > > > creation till driver bind time.
> > > >
> > > > Is there a hard dependency on that?
> > > >
> > > Not sure, may be Andreas can answer that.
> >
> > Ok. Andreas? I would have thought doing this *earlier* shouldn't be a
> > problem (the DMA ops must be swizzled before the driver is probed).
> >
> > > > > But the "isolate device" property should dictate iommu group
> > creation.
> > > >
> > > > The reason we added automatic group creation (per-device) is for
> > > > VFIO, which expects all devices to be in a group regardless of the
> > > > device isolation configuration.
> > > >
> > > IIUC, with the "isolate devices" property we ensure that there would
> > > be independent SMR and S2CR per device. Is that correct?
> >
> > Yes, as part of giving them independent sets of page tables. Initially
> > these tables don't have any valid mappings, but the dma-mapping API will
> > populate them in response to dma_map_*/dma_alloc/etc.
> >
> > Not sure what this has to do with us putting devices into their own
> > groups...
> [Sethi Varun-B16395] Devices in an iommu group would share the dma
> mapping, so shouldn't they be sharing the SMR and context registers?
I aggree with the context but SMRs won't be shared. I think you just
can say that a certain subset of the available SMRs will be used to
map all devices in an iommu group to the same context. Depending on
what streamIDs each device has you might have to use separate SMRs for
each device to map it to the same context.
> In case of the "isolate devices" property, each device would have
> its own SMR and context registers, thus allowing the devices to have
> independent mappings and allowing them to fall in separate iommu
> groups.
I aggree with Varun's view here. (Now that I take iommu groups into
consideration.)
But my goal with the "isolate devices" thing was twofold:
1. actual make use of SMMU for address translation for all master
devices (instead of just bypassing the SMMU)
plus
2. put each master into it's own domain to isolate it
The latter matches usage of separate iommu groups for devices. If we
now use the isolate devices property to just control whether master
devices fall into the same or separate iommu groups it seems to me we
would need to have another mechanism that triggers the creation of a
mapping for a group.
What do you think?
Andreas
^ permalink raw reply
* [PATCH v3 1/2] i2c: qup: Add device tree bindings information
From: Arnd Bergmann @ 2014-01-23 19:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <174308F1-FFD2-4CB3-AEA2-C423F90FB133@codeaurora.org>
On Thursday 23 January 2014, Matthew Locke wrote:
> The QUP IP block is the same across chips. Its possible there could be different versions of the IP block but its pretty stable now.
Do you know the version numbers of the IP block? That would be the ideal case. We just
fall back to using the SoC name in most cases because that's all that is publically
known.
Arnd
^ permalink raw reply
* [PATCH] Adding basic support for the INet-97F_Rev_02 board
From: David Lanzendörfer @ 2014-01-23 19:38 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds basic support for the INet-97F_Rev_02 board found in various
low cost consumer tablet devices (http://linux-sunxi.org/INet-97F_Rev_02)
Signed-off-by: David Lanzend?rfer <david.lanzendoerfer@o2s.ch>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun4i-a10-inet97fv2.dts | 106
++++++++++++++++++++++++++++++
2 files changed, 107 insertions(+)
create mode 100644 arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b663ed7..57ec008 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -253,6 +253,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += \
sun4i-a10-cubieboard.dtb \
sun4i-a10-mini-xplus.dtb \
sun4i-a10-hackberry.dtb \
+ sun4i-a10-inet97fv2.dtb \
sun5i-a10s-olinuxino-micro.dtb \
sun5i-a13-olinuxino.dtb \
sun5i-a13-olinuxino-micro.dtb \
diff --git a/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
new file mode 100644
index 0000000..82b4306
--- /dev/null
+++ b/arch/arm/boot/dts/sun4i-a10-inet97fv2.dts
@@ -0,0 +1,106 @@
+/*
+ * Copyright 2014 Open Source Support GmbH
+ *
+ * David Lanzend?rfer <david.lanzendoerfer@o2s.ch>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "sun4i-a10.dtsi"
+
+/ {
+ model = "INet-97F Rev 02";
+ compatible = "primux,inet97fv2", "allwinner,sun4i-a10";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ soc at 01c00000 {
+ mmc0: mmc at 01c0f000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>;
+ pinctrl-1 = <&mmc0_cd_pin_inet97fv2>;
+ cd-gpios = <&pio 7 1 0>; /* PH1 */
+ cd-mode = <1>;
+ status = "okay";
+ };
+
+ pinctrl at 01c20800 {
+ mmc0_cd_pin_inet97fv2: mmc0_cd_pin at 0 {
+ allwinner,pins = "PH1";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ usb1_vbus_pin: usb1_vbus_pin at 0 {
+ allwinner,pins = "PH6";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <0>;
+ allwinner,pull = <2>;
+ };
+
+ usb2_vbus_pin: usb2_vbus_pin at 0 {
+ allwinner,pins = "PH3";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <0>;
+ allwinner,pull = <2>;
+ };
+ };
+
+ uart0: serial at 01c28000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+ };
+
+ i2c0: i2c at 01c2ac00 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+ };
+
+ ehci0: ehci0 at 0x01c14000 {
+ vbus-supply = <®_usb1_vbus>;
+ status = "okay";
+ };
+
+ ehci1: ehci1 at 0x01c1c000 {
+ vbus-supply = <®_usb2_vbus>;
+ status = "okay";
+ };
+ };
+
+ regulators {
+ compatible = "simple-bus";
+
+ reg_usb1_vbus: usb1-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb1_vbus_pin>;
+ regulator-name = "usb1-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ gpio = <&pio 7 6 0>;
+ };
+
+ reg_usb2_vbus: usb2-vbus {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb2_vbus_pin>;
+ regulator-name = "usb2-vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ gpio = <&pio 7 3 0>;
+ };
+ };
+};
--
1.8.4
^ permalink raw reply related
* [PATCH] arm64: Add CONFIG_CC_STACKPROTECTOR
From: Laura Abbott @ 2014-01-23 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401231419110.1652@knanqh.ubzr>
On 1/23/2014 11:23 AM, Nicolas Pitre wrote:
> On Wed, 22 Jan 2014, Laura Abbott wrote:
>> On 1/22/2014 3:28 AM, Will Deacon wrote:
>>> On Tue, Jan 21, 2014 at 05:26:06PM +0000, Laura Abbott wrote:
>>>> @@ -288,6 +294,9 @@ struct task_struct *__switch_to(struct task_struct
>>>> @@ *prev,
>>>> {
>>>> struct task_struct *last;
>>>>
>>>> +#if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
>>>> + __stack_chk_guard = next->stack_canary;
>>>> +#endif
>>>
>>> I don't get the dependency on !SMP. Assumedly, the update of
>>> __stack_chk_guard would be racy otherwise, but that sounds solvable with
>>> atomics. Is the stack_canary updated periodically somewhere else?
>>>
>>
>> It has nothing to do with atomics, it's the fact that __stack_chk_guard is a
>> global variable and with SMP you can have n different processes running each
>> with a different canary (see kernel/fork.c, dup_task_struct) . c.f the commit
>> added by Nicolas Pitre:
>>
>> commit df0698be14c6683606d5df2d83e3ae40f85ed0d9
>> Author: Nicolas Pitre <nico@fluxnic.net>
>> Date: Mon Jun 7 21:50:33 2010 -0400
>>
>> ARM: stack protector: change the canary value per task
>>
>> A new random value for the canary is stored in the task struct whenever
>> a new task is forked. This is meant to allow for different canary
>> values
>> per task. On ARM, GCC expects the canary value to be found in a global
>> variable called __stack_chk_guard. So this variable has to be updated
>> with the value stored in the task struct whenever a task switch occurs.
>>
>> Because the variable GCC expects is global, this cannot work on SMP
>> unfortunately. So, on SMP, the same initial canary value is kept
>> throughout, making this feature a bit less effective although it is
>> still
>> useful.
>>
>> One way to overcome this GCC limitation would be to locate the
>> __stack_chk_guard variable into a memory page of its own for each CPU,
>> and then use TLB locking to have each CPU see its own page at the same
>> virtual address for each of them.
>>
>> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
>
> Did gcc for Aarch64 replicate the same global variable arrangement?
> That would be unfortunate...
>
Based on my experiments they did unfortunately do so.
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH-next] drivers/clk: make max77686 driver bool for now
From: Paul Gortmaker @ 2014-01-23 19:32 UTC (permalink / raw)
To: linux-arm-kernel
Commit 3966c947f45911e093114371462687134d5e8d40 ("clk: max77686:
Refactor driver data handling") added a call to __clk_get_hw()
but this function is not exported (as __<name> is typically a
private/internal thing).
Hence this driver fails to build modular, and has been causing
allmodconfig build breakage in arch outside of just ARM. Since
the only defconfig that uses it sets it as =y, lets just make
it non-modular for now.
Mike says that changes are pending to export similar functionality
in the future[1], so at that point in time, it can be returned to
tristate if desired.
[1] https://lkml.org/lkml/2014/1/20/21
Reported-by: SeongJae Park <sj38.park@gmail.com>
Cc: SeongJae Park <sj38.park@gmail.com>
Cc: Tomasz Figa <t.figa@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index efb508a..009fb9b 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -40,7 +40,7 @@ config COMMON_CLK_VERSATILE
- Versatile Express
config COMMON_CLK_MAX77686
- tristate "Clock driver for Maxim 77686 MFD"
+ bool "Clock driver for Maxim 77686 MFD"
depends on MFD_MAX77686
---help---
This driver supports Maxim 77686 crystal oscillator clock.
--
1.8.5.2
^ permalink raw reply related
* [PATCH 3/3] ARM: allow kernel to be loaded in middle of phymem
From: Russell King - ARM Linux @ 2014-01-23 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401231357520.1652@knanqh.ubzr>
On Thu, Jan 23, 2014 at 02:15:07PM -0500, Nicolas Pitre wrote:
> On Wed, 22 Jan 2014, Wang Nan wrote:
>
> > This patch allows the kernel to be loaded at the middle of kernel awared
> > physical memory. Before this patch, users must use mem= or device tree to cheat
> > kernel about the start address of physical memory.
> >
> > This feature is useful in some special cases, for example, building a crash
> > dump kernel. Without it, kernel command line, atag and devicetree must be
> > adjusted carefully, sometimes is impossible.
>
> With CONFIG_PATCH_PHYS_VIRT the value for PHYS_OFFSET is determined
> dynamically by rounding down the kernel image start address to the
> previous 16MB boundary. In the case of a crash kernel, this might be
> cleaner to simply readjust __pv_phys_offset during early boot and call
> fixup_pv_table(), and then reserve away the memory from the previous
> kernel. That will let you access that memory directly (with gdb for
> example) and no pointer address translation will be required.
We already have support in the kernel to ignore memory below the calculated
PHYS_OFFSET. See 571b14375019c3a66ef70d4d4a7083f4238aca30.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v3 02/11] iommu/arm-smmu: Introduce iommu_group notifier block
From: Andreas Herrmann @ 2014-01-23 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140122153352.GE14108@mudshark.cambridge.arm.com>
On Wed, Jan 22, 2014 at 03:33:52PM +0000, Will Deacon wrote:
> On Wed, Jan 22, 2014 at 01:54:11PM +0000, Varun Sethi wrote:
> > > > > Ok, so are you suggesting that we perform the isolation mapping in
> > > > > arm_smmu_add_device and drop the notifier altogether?
> > > > I think that should be fine, until we want to delay mapping creation
> > > > till driver bind time.
> > >
> > > Is there a hard dependency on that?
> > >
> > Not sure, may be Andreas can answer that.
>
> Ok. Andreas? I would have thought doing this *earlier* shouldn't be a
> problem (the DMA ops must be swizzled before the driver is probed).
Yes, I think, there is no hard dependency.
(But still have to double check whether arm_smmu_add_device can be
used instead of the notifier. Will finally see this when doing some
tests.)
> > > > But the "isolate device" property should dictate iommu group creation.
> > >
> > > The reason we added automatic group creation (per-device) is for VFIO,
> > > which expects all devices to be in a group regardless of the device
> > > isolation configuration.
> > >
> > IIUC, with the "isolate devices" property we ensure that there would be
> > independent SMR and S2CR per device. Is that correct?
>
> Yes, as part of giving them independent sets of page tables. Initially these
> tables don't have any valid mappings, but the dma-mapping API will populate
> them in response to dma_map_*/dma_alloc/etc.
>
> Not sure what this has to do with us putting devices into their own
> groups...
>
> Will
Andreas
^ permalink raw reply
* [PATCH] arm64: Add CONFIG_CC_STACKPROTECTOR
From: Nicolas Pitre @ 2014-01-23 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E00AFF.1060701@codeaurora.org>
On Wed, 22 Jan 2014, Laura Abbott wrote:
> On 1/22/2014 3:28 AM, Will Deacon wrote:
> > On Tue, Jan 21, 2014 at 05:26:06PM +0000, Laura Abbott wrote:
> > > @@ -288,6 +294,9 @@ struct task_struct *__switch_to(struct task_struct
> > > @@ *prev,
> > > {
> > > struct task_struct *last;
> > >
> > > +#if defined(CONFIG_CC_STACKPROTECTOR) && !defined(CONFIG_SMP)
> > > + __stack_chk_guard = next->stack_canary;
> > > +#endif
> >
> > I don't get the dependency on !SMP. Assumedly, the update of
> > __stack_chk_guard would be racy otherwise, but that sounds solvable with
> > atomics. Is the stack_canary updated periodically somewhere else?
> >
>
> It has nothing to do with atomics, it's the fact that __stack_chk_guard is a
> global variable and with SMP you can have n different processes running each
> with a different canary (see kernel/fork.c, dup_task_struct) . c.f the commit
> added by Nicolas Pitre:
>
> commit df0698be14c6683606d5df2d83e3ae40f85ed0d9
> Author: Nicolas Pitre <nico@fluxnic.net>
> Date: Mon Jun 7 21:50:33 2010 -0400
>
> ARM: stack protector: change the canary value per task
>
> A new random value for the canary is stored in the task struct whenever
> a new task is forked. This is meant to allow for different canary
> values
> per task. On ARM, GCC expects the canary value to be found in a global
> variable called __stack_chk_guard. So this variable has to be updated
> with the value stored in the task struct whenever a task switch occurs.
>
> Because the variable GCC expects is global, this cannot work on SMP
> unfortunately. So, on SMP, the same initial canary value is kept
> throughout, making this feature a bit less effective although it is
> still
> useful.
>
> One way to overcome this GCC limitation would be to locate the
> __stack_chk_guard variable into a memory page of its own for each CPU,
> and then use TLB locking to have each CPU see its own page at the same
> virtual address for each of them.
>
> Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Did gcc for Aarch64 replicate the same global variable arrangement?
That would be unfortunate...
Nicolas
^ permalink raw reply
* [PATCH V4 5/5] Documentation: power: reset: Add documentation for generic SYSCON reboot driver
From: Feng Kan @ 2014-01-23 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390504801-24483-1-git-send-email-fkan@apm.com>
Add documentation for generic SYSCON reboot driver.
Signed-off-by: Feng Kan <fkan@apm.com>
---
.../bindings/power/reset/syscon-reboot.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
diff --git a/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
new file mode 100644
index 0000000..e9eb1fe
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
@@ -0,0 +1,16 @@
+Generic SYSCON mapped register reset driver
+
+Required properties:
+- compatible: should contain "syscon-reboot"
+- regmap: this is phandle to the register map node
+- offset: offset in the register map for the reboot register
+- mask: the reset value written to the reboot register
+
+Examples:
+
+reboot {
+ compatible = "syscon-reboot";
+ regmap = <®mapnode>;
+ offset = <0x0>;
+ mask = <0x1>;
+};
--
1.7.6.1
^ permalink raw reply related
* [PATCH V4 4/5] arm64: Select reboot driver for X-Gene platform
From: Feng Kan @ 2014-01-23 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390504801-24483-1-git-send-email-fkan@apm.com>
Select reboot driver for X-Gene platform.
Signed-off-by: Feng Kan <fkan@apm.com>
---
arch/arm64/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index dd4327f..f43820f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -123,6 +123,8 @@ config ARCH_VEXPRESS
config ARCH_XGENE
bool "AppliedMicro X-Gene SOC Family"
+ select MFD_SYSCON
+ select POWER_RESET_SYSCON
help
This enables support for AppliedMicro X-Gene SOC Family
--
1.7.6.1
^ permalink raw reply related
* [PATCH V4 3/5] arm64: dts: Add X-Gene reboot driver dts node
From: Feng Kan @ 2014-01-23 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390504801-24483-1-git-send-email-fkan@apm.com>
Add X-Gene platform reboot driver dts node.
Signed-off-by: Feng Kan <fkan@apm.com>
---
arch/arm64/boot/dts/apm-storm.dtsi | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi b/arch/arm64/boot/dts/apm-storm.dtsi
index d37d736..4ef9d26 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -103,6 +103,11 @@
#size-cells = <2>;
ranges;
+ scu: system-clk-controller at 17000000 {
+ compatible = "apm,xgene-scu","syscon";
+ reg = <0x0 0x17000000 0x0 0x400>;
+ };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
@@ -187,5 +192,13 @@
interrupt-parent = <&gic>;
interrupts = <0x0 0x4c 0x4>;
};
+
+ reboot at 17000014 {
+ compatible = "syscon-reboot";
+ regmap = <&scu>;
+ offset = <0x14>;
+ mask = <0x1>;
+ };
+
};
};
--
1.7.6.1
^ permalink raw reply related
* [PATCH V4 2/5] power: reset: Remove X-Gene reboot driver
From: Feng Kan @ 2014-01-23 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390504801-24483-1-git-send-email-fkan@apm.com>
Remove X-Gene reboot driver.
Signed-off-by: Feng Kan <fkan@apm.com>
---
drivers/power/reset/Kconfig | 7 ---
drivers/power/reset/Makefile | 1 -
drivers/power/reset/xgene-reboot.c | 103 ------------------------------------
3 files changed, 0 insertions(+), 111 deletions(-)
delete mode 100644 drivers/power/reset/xgene-reboot.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 4501c02..13a5191 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -45,13 +45,6 @@ config POWER_RESET_VEXPRESS
Power off and reset support for the ARM Ltd. Versatile
Express boards.
-config POWER_RESET_XGENE
- bool "APM SoC X-Gene reset driver"
- depends on ARM64
- depends on POWER_RESET
- help
- Reboot support for the APM SoC X-Gene Eval boards.
-
config POWER_RESET_SYSCON
bool "Generic SYSCON regmap reset driver"
depends on MFD_SYSCON
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index f2c0327..a3137ff 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -3,5 +3,4 @@ obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
-obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
diff --git a/drivers/power/reset/xgene-reboot.c b/drivers/power/reset/xgene-reboot.c
deleted file mode 100644
index ecd55f8..0000000
--- a/drivers/power/reset/xgene-reboot.c
+++ /dev/null
@@ -1,103 +0,0 @@
-/*
- * AppliedMicro X-Gene SoC Reboot Driver
- *
- * Copyright (c) 2013, Applied Micro Circuits Corporation
- * Author: Feng Kan <fkan@apm.com>
- * Author: Loc Ho <lho@apm.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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- *
- * This driver provides system reboot functionality for APM X-Gene SoC.
- * For system shutdown, this is board specify. If a board designer
- * implements GPIO shutdown, use the gpio-poweroff.c driver.
- */
-#include <linux/io.h>
-#include <linux/of_device.h>
-#include <linux/of_address.h>
-#include <linux/platform_device.h>
-#include <linux/stat.h>
-#include <linux/slab.h>
-#include <asm/system_misc.h>
-
-struct xgene_reboot_context {
- struct platform_device *pdev;
- void *csr;
- u32 mask;
-};
-
-static struct xgene_reboot_context *xgene_restart_ctx;
-
-static void xgene_restart(char str, const char *cmd)
-{
- struct xgene_reboot_context *ctx = xgene_restart_ctx;
- unsigned long timeout;
-
- /* Issue the reboot */
- if (ctx)
- writel(ctx->mask, ctx->csr);
-
- timeout = jiffies + HZ;
- while (time_before(jiffies, timeout))
- cpu_relax();
-
- dev_emerg(&ctx->pdev->dev, "Unable to restart system\n");
-}
-
-static int xgene_reboot_probe(struct platform_device *pdev)
-{
- struct xgene_reboot_context *ctx;
-
- ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
- if (!ctx) {
- dev_err(&pdev->dev, "out of memory for context\n");
- return -ENODEV;
- }
-
- ctx->csr = of_iomap(pdev->dev.of_node, 0);
- if (!ctx->csr) {
- devm_kfree(&pdev->dev, ctx);
- dev_err(&pdev->dev, "can not map resource\n");
- return -ENODEV;
- }
-
- if (of_property_read_u32(pdev->dev.of_node, "mask", &ctx->mask))
- ctx->mask = 0xFFFFFFFF;
-
- ctx->pdev = pdev;
- arm_pm_restart = xgene_restart;
- xgene_restart_ctx = ctx;
-
- return 0;
-}
-
-static struct of_device_id xgene_reboot_of_match[] = {
- { .compatible = "apm,xgene-reboot" },
- {}
-};
-
-static struct platform_driver xgene_reboot_driver = {
- .probe = xgene_reboot_probe,
- .driver = {
- .name = "xgene-reboot",
- .of_match_table = xgene_reboot_of_match,
- },
-};
-
-static int __init xgene_reboot_init(void)
-{
- return platform_driver_register(&xgene_reboot_driver);
-}
-device_initcall(xgene_reboot_init);
--
1.7.6.1
^ permalink raw reply related
* [PATCH V4 1/5] power: reset: Add generic SYSCON register mapped reset
From: Feng Kan @ 2014-01-23 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390504801-24483-1-git-send-email-fkan@apm.com>
Add a generic SYSCON register mapped reset mechanism.
Signed-off-by: Feng Kan <fkan@apm.com>
---
drivers/power/reset/Kconfig | 7 +++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/syscon-reboot.c | 100 +++++++++++++++++++++++++++++++++++
3 files changed, 108 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/reset/syscon-reboot.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 9b3ea53..4501c02 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -51,3 +51,10 @@ config POWER_RESET_XGENE
depends on POWER_RESET
help
Reboot support for the APM SoC X-Gene Eval boards.
+
+config POWER_RESET_SYSCON
+ bool "Generic SYSCON regmap reset driver"
+ depends on MFD_SYSCON
+ depends on POWER_RESET
+ help
+ Reboot support for generic SYSCON mapped register reset.
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 3e6ed88..f2c0327 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
+obj-$(CONFIG_POWER_RESET_SYSCON) += syscon-reboot.o
diff --git a/drivers/power/reset/syscon-reboot.c b/drivers/power/reset/syscon-reboot.c
new file mode 100644
index 0000000..29ed908
--- /dev/null
+++ b/drivers/power/reset/syscon-reboot.c
@@ -0,0 +1,100 @@
+/*
+ * Generic Syscon Reboot Driver
+ *
+ * Copyright (c) 2013, Applied Micro Circuits Corporation
+ * Author: Feng Kan <fkan@apm.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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ *
+ * This driver provides system reboot functionality for APM X-Gene SoC.
+ * For system shutdown, this is board specify. If a board designer
+ * implements GPIO shutdown, use the gpio-poweroff.c driver.
+ */
+#include <linux/io.h>
+#include <linux/of_device.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/stat.h>
+#include <linux/slab.h>
+#include <linux/mfd/syscon.h>
+#include <linux/regmap.h>
+#include <linux/reboot.h>
+#include <asm/system_misc.h>
+
+struct syscon_reboot_context {
+ struct regmap *map;
+ u32 offset;
+ u32 mask;
+};
+
+static struct syscon_reboot_context *syscon_reboot_ctx;
+
+static void syscon_restart(enum reboot_mode reboot_mode, const char *cmd)
+{
+ struct syscon_reboot_context *ctx = syscon_reboot_ctx;
+ unsigned long timeout;
+
+ /* Issue the reboot */
+ if (ctx->map)
+ regmap_write(ctx->map, ctx->offset, ctx->mask);
+
+ timeout = jiffies + HZ;
+ while (time_before(jiffies, timeout))
+ cpu_relax();
+
+ pr_emerg("Unable to restart system\n");
+}
+
+static int syscon_reboot_probe(struct platform_device *pdev)
+{
+ struct syscon_reboot_context *ctx;
+ struct device *dev = &pdev->dev;
+
+ ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx) {
+ dev_err(&pdev->dev, "out of memory for context\n");
+ return -ENOMEM;
+ }
+
+ ctx->map = syscon_regmap_lookup_by_phandle(dev->of_node, "regmap");
+ if (IS_ERR(ctx->map))
+ return PTR_ERR(ctx->map);
+
+ if (of_property_read_u32(pdev->dev.of_node, "offset", &ctx->offset))
+ return -EINVAL;
+
+ if (of_property_read_u32(pdev->dev.of_node, "mask", &ctx->mask))
+ return -EINVAL;
+
+ arm_pm_restart = syscon_restart;
+ syscon_reboot_ctx = ctx;
+
+ return 0;
+}
+
+static struct of_device_id syscon_reboot_of_match[] = {
+ { .compatible = "syscon-reboot" },
+ {}
+};
+
+static struct platform_driver syscon_reboot_driver = {
+ .probe = syscon_reboot_probe,
+ .driver = {
+ .name = "syscon-reboot",
+ .of_match_table = syscon_reboot_of_match,
+ },
+};
+module_platform_driver(syscon_reboot_driver);
--
1.7.6.1
^ permalink raw reply related
* [PATCH V4 0/5] Add X-Gene platform reboot mechanism
From: Feng Kan @ 2014-01-23 19:19 UTC (permalink / raw)
To: linux-arm-kernel
Enable reboot driver for the X-Gene platform. Add generic syscon reboot
driver.
V4 Change:
- Remove old X-Gene reboot driver
- Add generic syscon reboot driver
- Add DTS and Kconfig for X-Gene reboot using syscon method
V3 Change:
- Remove the reboot driver's use of acpi resource patch.
- Change the reboot driver to use syscon to parse out
system clock register. Remove the old method of getting
register from the reboot driver directly.
- Remove documentation since its now simple.
V2 Change:
- Add support for using ACPI resource.
Feng Kan (5):
power: reset: Add generic SYSCON register mapped reset
power: reset: Remove X-Gene reboot driver
arm64: dts: Add X-Gene reboot driver dts node
arm64: Select reboot driver for X-Gene platform
Documentation: power: reset: Add documentation for generic SYSCON
reboot driver
.../bindings/power/reset/syscon-reboot.txt | 16 +++
arch/arm64/Kconfig | 2 +
arch/arm64/boot/dts/apm-storm.dtsi | 13 +++
drivers/power/reset/Kconfig | 8 +-
drivers/power/reset/Makefile | 2 +-
drivers/power/reset/syscon-reboot.c | 100 +++++++++++++++++++
drivers/power/reset/xgene-reboot.c | 103 --------------------
7 files changed, 136 insertions(+), 108 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/syscon-reboot.txt
create mode 100644 drivers/power/reset/syscon-reboot.c
delete mode 100644 drivers/power/reset/xgene-reboot.c
--
1.7.6.1
^ permalink raw reply
* [PATCH 3/3] ARM: allow kernel to be loaded in middle of phymem
From: Nicolas Pitre @ 2014-01-23 19:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390389916-8711-4-git-send-email-wangnan0@huawei.com>
On Wed, 22 Jan 2014, Wang Nan wrote:
> This patch allows the kernel to be loaded at the middle of kernel awared
> physical memory. Before this patch, users must use mem= or device tree to cheat
> kernel about the start address of physical memory.
>
> This feature is useful in some special cases, for example, building a crash
> dump kernel. Without it, kernel command line, atag and devicetree must be
> adjusted carefully, sometimes is impossible.
With CONFIG_PATCH_PHYS_VIRT the value for PHYS_OFFSET is determined
dynamically by rounding down the kernel image start address to the
previous 16MB boundary. In the case of a crash kernel, this might be
cleaner to simply readjust __pv_phys_offset during early boot and call
fixup_pv_table(), and then reserve away the memory from the previous
kernel. That will let you access that memory directly (with gdb for
example) and no pointer address translation will be required.
> Signed-off-by: Wang Nan <wangnan0@huawei.com>
> Cc: <stable@vger.kernel.org> # 3.4+
> Cc: Eric Biederman <ebiederm@xmission.com>
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Geng Hui <hui.geng@huawei.com>
> ---
> arch/arm/mm/init.c | 21 ++++++++++++++++++++-
> arch/arm/mm/mmu.c | 13 +++++++++++++
> mm/page_alloc.c | 7 +++++--
> 3 files changed, 38 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 3e8f106..4952726 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -334,9 +334,28 @@ void __init arm_memblock_init(struct meminfo *mi,
> {
> int i;
>
> - for (i = 0; i < mi->nr_banks; i++)
> + for (i = 0; i < mi->nr_banks; i++) {
> memblock_add(mi->bank[i].start, mi->bank[i].size);
>
> + /*
> + * In some special case, for example, building a crushdump
> + * kernel, we want the kernel to be loaded in the middle of
> + * physical memory. In such case, the physical memory before
> + * PHYS_OFFSET is awkward: it can't get directly mapped
> + * (because its address will be smaller than PAGE_OFFSET,
> + * disturbs user address space) also can't be mapped as
> + * HighMem. We reserve such pages here. The only way to access
> + * those pages is ioremap.
> + */
> + if (mi->bank[i].start < PHYS_OFFSET) {
> + unsigned long reserv_size = PHYS_OFFSET -
> + mi->bank[i].start;
> + if (reserv_size > mi->bank[i].size)
> + reserv_size = mi->bank[i].size;
> + memblock_reserve(mi->bank[i].start, reserv_size);
> + }
> + }
> +
> /* Register the kernel text, kernel data and initrd with memblock. */
> #ifdef CONFIG_XIP_KERNEL
> memblock_reserve(__pa(_sdata), _end - _sdata);
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 580ef2d..2a17c24 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1308,6 +1308,19 @@ static void __init map_lowmem(void)
> if (start >= end)
> break;
>
> + /*
> + * If this memblock contain memory before PAGE_OFFSET, memory
> + * before PAGE_OFFSET should't get directly mapped, see code
> + * in create_mapping(). However, memory after PAGE_OFFSET is
> + * occupyed by kernel and still need to be mapped.
> + */
> + if (__phys_to_virt(start) < PAGE_OFFSET) {
> + if (__phys_to_virt(end) > PAGE_OFFSET)
> + start = __virt_to_phys(PAGE_OFFSET);
> + else
> + break;
> + }
> +
> map.pfn = __phys_to_pfn(start);
> map.virtual = __phys_to_virt(start);
> map.length = end - start;
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 5248fe0..d2959e3 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4840,10 +4840,13 @@ static void __init_refok alloc_node_mem_map(struct pglist_data *pgdat)
> */
> if (pgdat == NODE_DATA(0)) {
> mem_map = NODE_DATA(0)->node_mem_map;
> -#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
> + /*
> + * In case of CONFIG_HAVE_MEMBLOCK_NODE_MAP or when kernel
> + * loaded at the middle of physical memory, mem_map should
> + * be adjusted.
> + */
> if (page_to_pfn(mem_map) != pgdat->node_start_pfn)
> mem_map -= (pgdat->node_start_pfn - ARCH_PFN_OFFSET);
> -#endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */
> }
> #endif
> #endif /* CONFIG_FLAT_NODE_MEM_MAP */
> --
> 1.8.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [PATCH v3 1/2] i2c: qup: Add device tree bindings information
From: Matthew Locke @ 2014-01-23 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJBEu8iLzE8-dXniZFytr6cQsprBYiYnJeXS2-80iy1Mw@mail.gmail.com>
Rob,
On Jan 20, 2014, at 8:10 AM, Rob Herring wrote:
> On Fri, Jan 17, 2014 at 5:03 PM, Bjorn Andersson
> <bjorn.andersson@sonymobile.com> wrote:
>> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
>>
>> The Qualcomm Universal Peripherial (QUP) wraps I2C mini-core and
>> provide input and output FIFO's for it. I2C controller can operate
>> as master with supported bus speeds of 100Kbps and 400Kbps.
>>
>> Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
>> [bjorn: reformulated part of binding description and cleaned up example]
>> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
>> ---
>
> Patch history?
>
>> .../devicetree/bindings/i2c/qcom,i2c-qup.txt | 41 ++++++++++++++++++++++
>> 1 file changed, 41 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
>>
>> diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
>> new file mode 100644
>> index 0000000..a99711b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
>> @@ -0,0 +1,41 @@
>> +Qualcomm Universal Peripheral (QUP) I2C controller
>> +
>> +Required properties:
>> + - compatible: Should be "qcom,i2c-qup".
>
> Seems a bit generic. All versions of the IP are exactly the same?
> "qcom,<chip>-i2c-qup" would be better.
The QUP IP block is the same across chips. Its possible there could be different versions of the IP block but its pretty stable now.
>
>> + - reg: Should contain QUP register address and length.
>> + - interrupts: Should contain I2C interrupt.
>> +
>> + - clocks: Should contain the core clock and the AHB clock.
>> + - clock-names: Should be "core" for the core clock and "iface" for the
>> + AHB clock.
>> +
>> + - #address-cells: Should be <1> Address cells for i2c device address
>> + - #size-cells: Should be <0> as i2c addresses have no size component
>> +
>> +Optional properties:
>> + - clock-frequency: Should specify the desired i2c bus clock frequency in Hz,
>> + default is 100kHz if omitted.
>> +
>> +Child nodes should conform to i2c bus binding.
>> +
>> +Example:
>> +
>> + i2c2: i2c at f9924000 {
>> + compatible = "qcom,i2c-qup";
>> + reg = <0xf9924000 0x1000>;
>> + interrupts = <0 96 0>;
>> +
>> + clocks = <&gcc_blsp1_qup2_i2c_apps_clk>, <&gcc_blsp1_ahb_clk>;
>> + clock-names = "core", "iface";
>> +
>> + clock-frequency = <355000>;
>> +
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + dummy at 60 {
>> + compatible = "dummy";
>> + reg = <0x60>;
>> + };
>> + };
>> +
>> --
>> 1.8.2.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH 4/5] ARM: S3C24XX: convert boards to use common restart function
From: Heiko Stübner @ 2014-01-23 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E164B6.5070206@samsung.com>
Am Donnerstag, 23. Januar 2014, 19:51:34 schrieb Tomasz Figa:
> On 23.01.2014 19:36, Heiko St?bner wrote:
> > Am Donnerstag, 23. Januar 2014, 19:12:04 schrieb Tomasz Figa:
> >> Hi Heiko,
> >>
> >> On 06.01.2014 19:40, Heiko St?bner wrote:
> >>> This converts all boards to use the new common restart function instead
> >>> of SoC specific ones.
> >>>
> >>> The mach-s3c2416-dt board now tries to setup either a swrst- or
> >>> watchdog-
> >>> reset so that it will be able to handle more s3c24xx-SoCs later on.
> >>
> >> [snip]
> >>
> >>> diff --git a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
> >>> b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c index 0a86953..88716fa4 100644
> >>> --- a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
> >>> +++ b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
> >>> @@ -24,6 +24,7 @@
> >>>
> >>> #include <plat/cpu.h>
> >>> #include <plat/pm.h>
> >>>
> >>> +#include <plat/watchdog-reset.h>
> >>>
> >>> #include "common.h"
> >>>
> >>> @@ -34,6 +35,14 @@ static void __init s3c2416_dt_map_io(void)
> >>>
> >>> static void __init s3c2416_dt_machine_init(void)
> >>> {
> >>>
> >>> + s3c24xx_swrst_reset_of_init();
> >>> +
> >>> +#ifdef CONFIG_SAMSUNG_WDT_RESET
> >>> + /* if no special swrst-device exists try to find a watchdog */
> >>> + if (!s3c24xx_swrst_reset_available())
> >>> + samsung_wdt_reset_of_init();
> >>> +#endif
> >>
> >> Hmm... I think it would be safe to assume availability of soft reset,
> >> especially if you could move the restart code to the clock driver.
> >
> > ok, so something like the following:
> >
> > the boards would simply use samsung_watchdog_reset, which should according
> > to the manuals be available on all architectures. And the ccf-driver on
> > appropriate architectures would simple replace the arm_pm_restart
> > callback with its own SoC specific one?
> >
> > For the s3c2412 this also means that the clock-logic would get simplified.
> >
> >
> > Like this, or do I overlook something?
>
> Hmm, this would mean a dependency on CONFIG_SAMSUNG_WDT_RESET then. Is
> there a need to fall back to it on platforms which support soft reset
> (assuming that CCF driver would always install its restart handler on
> applicable platforms)?
s3c2410, s3c2440 and s3c2442 do not have the swrst facility. They always use
samsung_wdt_reset.
In general, I want to try establishing some sort of general restart way, as in
the future one dt-board should hopefully be enough to cover all s3c24xx soc
variants.
> Note that you can make the restart field NULL in mach_desc in board files.
As I said above, this is mainly meant for the dt-case. The legacy-board files
are more or less only secondary, and the affected boards can of course then
have a NULL restart handle :-) .
So for this the dt-board could simply use the wdt-reset, which then gets
replaced by the ccf-based reset if appropriate.
Heiko
^ permalink raw reply
* [PATCH 4/5] ARM: S3C24XX: convert boards to use common restart function
From: Tomasz Figa @ 2014-01-23 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7172372.015CdWJg1F@phil>
On 23.01.2014 19:36, Heiko St?bner wrote:
> Am Donnerstag, 23. Januar 2014, 19:12:04 schrieb Tomasz Figa:
>> Hi Heiko,
>>
>> On 06.01.2014 19:40, Heiko St?bner wrote:
>>> This converts all boards to use the new common restart function instead
>>> of SoC specific ones.
>>>
>>> The mach-s3c2416-dt board now tries to setup either a swrst- or watchdog-
>>> reset so that it will be able to handle more s3c24xx-SoCs later on.
>>
>> [snip]
>>
>>> diff --git a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
>>> b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c index 0a86953..88716fa4 100644
>>> --- a/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
>>> +++ b/arch/arm/mach-s3c24xx/mach-s3c2416-dt.c
>>> @@ -24,6 +24,7 @@
>>>
>>> #include <plat/cpu.h>
>>> #include <plat/pm.h>
>>>
>>> +#include <plat/watchdog-reset.h>
>>>
>>> #include "common.h"
>>>
>>> @@ -34,6 +35,14 @@ static void __init s3c2416_dt_map_io(void)
>>>
>>> static void __init s3c2416_dt_machine_init(void)
>>> {
>>>
>>> + s3c24xx_swrst_reset_of_init();
>>> +
>>> +#ifdef CONFIG_SAMSUNG_WDT_RESET
>>> + /* if no special swrst-device exists try to find a watchdog */
>>> + if (!s3c24xx_swrst_reset_available())
>>> + samsung_wdt_reset_of_init();
>>> +#endif
>>
>> Hmm... I think it would be safe to assume availability of soft reset,
>> especially if you could move the restart code to the clock driver.
>
> ok, so something like the following:
>
> the boards would simply use samsung_watchdog_reset, which should according to
> the manuals be available on all architectures. And the ccf-driver on
> appropriate architectures would simple replace the arm_pm_restart callback
> with its own SoC specific one?
>
> For the s3c2412 this also means that the clock-logic would get simplified.
>
>
> Like this, or do I overlook something?
Hmm, this would mean a dependency on CONFIG_SAMSUNG_WDT_RESET then. Is
there a need to fall back to it on platforms which support soft reset
(assuming that CCF driver would always install its restart handler on
applicable platforms)?
Note that you can make the restart field NULL in mach_desc in board files.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH] ARM: OMAP4+: move errata initialization to omap4_pm_init_early
From: Tony Lindgren @ 2014-01-23 18:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874n4uy483.fsf@paris.lan>
* Kevin Hilman <khilman@linaro.org> [140123 09:55]:
> Grygorii Strashko <grygorii.strashko@ti.com> writes:
>
> > On 01/20/2014 10:06 PM, Nishanth Menon wrote:
> >> Move all OMAP4 PM errata initializations to centralized location in
> >> omap4_pm_init_early. This allows for users to utilize the erratas
> >> in various submodules as needed.
> >>
> > Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
> >
> > This patch fixes build failure caused by patch
> > https://patchwork.kernel.org/patch/3084521/
> > in case if SMP is not enabled.
>
> So does that mean that that patch can now be applied as is?
>
> We could sure use that fix (or equivalent) for CPUidle breakage on 4460.
Yeah, seems OK to me, feel free to apply it directly:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH V2 06/10] clk/samsung: add support for pll2650xx
From: Tomasz Figa @ 2014-01-23 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389099548-14649-7-git-send-email-rahul.sharma@samsung.com>
Hi Rahul,
On 07.01.2014 13:59, Rahul Sharma wrote:
> Add support for pll2650xx in samsung pll file. This pll variant
> is close to pll36xx but uses CON2 registers instead of CON1.
>
> Aud_pll in Exynos5260 is pll2650xx and uses this code.
>
> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
> ---
> drivers/clk/samsung/clk-pll.c | 101 +++++++++++++++++++++++++++++++++++++++++
> drivers/clk/samsung/clk-pll.h | 2 +-
> 2 files changed, 102 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
> index 08f85ae..35cbc60 100644
> --- a/drivers/clk/samsung/clk-pll.c
> +++ b/drivers/clk/samsung/clk-pll.c
> @@ -812,6 +812,101 @@ static const struct clk_ops samsung_pll2550xx_clk_min_ops = {
> .recalc_rate = samsung_pll2550xx_recalc_rate,
> };
>
> +/*
> + * PLL2650XX Clock Type
> + */
> +
> +/* Maximum lock time can be 3000 * PDIV cycles */
> +#define PLL2650XX_LOCK_FACTOR (3000)
> +
> +#define PLL2650XX_MDIV_SHIFT (9)
> +#define PLL2650XX_PDIV_SHIFT (3)
> +#define PLL2650XX_SDIV_SHIFT (0)
> +#define PLL2650XX_KDIV_SHIFT (0)
> +#define PLL2650XX_MDIV_MASK (0x1ff)
> +#define PLL2650XX_PDIV_MASK (0x3f)
> +#define PLL2650XX_SDIV_MASK (0x7)
> +#define PLL2650XX_KDIV_MASK (0xffff)
> +#define PLL2650XX_PLL_ENABLE_SHIFT (23)
> +#define PLL2650XX_PLL_LOCKTIME_SHIFT (21)
> +#define PLL2650XX_PLL_FOUTMASK_SHIFT (31)
For single bit fields it would be better to use simple definitions,
using BIT() macro, such as
#define PLL2650XX_PLL_ENABLE BIT(23)
and then using it with | or & ~ operators directly.
Also there is no need for parentheses around simple integers.
> +
> +static unsigned long samsung_pll2650xx_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct samsung_clk_pll *pll = to_clk_pll(hw);
> + u32 mdiv, pdiv, sdiv, pll_con0, pll_con2;
> + s16 kdiv;
> + u64 fvco = parent_rate;
> +
> + pll_con0 = __raw_readl(pll->con_reg);
> + pll_con2 = __raw_readl(pll->con_reg + 8);
> + mdiv = (pll_con0 >> PLL2650XX_MDIV_SHIFT) & PLL2650XX_MDIV_MASK;
> + pdiv = (pll_con0 >> PLL2650XX_PDIV_SHIFT) & PLL2650XX_PDIV_MASK;
> + sdiv = (pll_con0 >> PLL2650XX_SDIV_SHIFT) & PLL2650XX_SDIV_MASK;
> + kdiv = (s16)(pll_con2 & PLL2650XX_KDIV_MASK);
> +
> + fvco *= (mdiv << 16) + kdiv;
> + do_div(fvco, (pdiv << sdiv));
> + fvco >>= 16;
> +
> + return (unsigned long)fvco;
> +}
> +
> +static int samsung_pll2650xx_set_rate(struct clk_hw *hw, unsigned long drate,
> + unsigned long parent_rate)
> +{
> + struct samsung_clk_pll *pll = to_clk_pll(hw);
> + u32 tmp, pll_con0, pll_con2;
> + const struct samsung_pll_rate_table *rate;
> +
> + rate = samsung_get_pll_settings(pll, drate);
> + if (!rate) {
> + pr_err("%s: Invalid rate : %lu for pll clk %s\n", __func__,
> + drate, __clk_get_name(hw->clk));
> + return -EINVAL;
> + }
> +
> + pll_con0 = __raw_readl(pll->con_reg);
> + pll_con2 = __raw_readl(pll->con_reg + 8);
> +
> + /* Change PLL PMS values */
> + pll_con0 &= ~(PLL2650XX_MDIV_MASK << PLL2650XX_MDIV_SHIFT |
> + PLL2650XX_PDIV_MASK << PLL2650XX_PDIV_SHIFT |
> + PLL2650XX_SDIV_MASK << PLL2650XX_SDIV_SHIFT);
> + pll_con0 |= rate->mdiv << PLL2650XX_MDIV_SHIFT;
> + pll_con0 |= rate->pdiv << PLL2650XX_PDIV_SHIFT;
> + pll_con0 |= rate->sdiv << PLL2650XX_SDIV_SHIFT;
> + pll_con0 |= 1 << PLL2650XX_PLL_ENABLE_SHIFT;
> + pll_con0 |= 1 << PLL2650XX_PLL_FOUTMASK_SHIFT;
> +
> + pll_con2 &= ~(PLL2650XX_KDIV_MASK << PLL2650XX_KDIV_SHIFT);
> + pll_con2 |= ((~(rate->kdiv) + 1) & PLL2650XX_KDIV_MASK)
> + << PLL2650XX_KDIV_SHIFT;
Huh? This looks suspiciously. Why KDIV needs to be negated and increased
by 1?
> +
> + /* Set PLL lock time. */
> + __raw_writel(PLL2650XX_LOCK_FACTOR * rate->pdiv, pll->lock_reg);
> +
> + __raw_writel(pll_con0, pll->con_reg);
> + __raw_writel(pll_con2, pll->con_reg + 8);
> +
> + do {
> + tmp = __raw_readl(pll->con_reg);
> + } while (!(tmp & (0x1 << PLL2650XX_PLL_LOCKTIME_SHIFT)));
Is the right bit being checked here? On other PLLs it's 29th bit named
LOCK_STAT. Could you confirm this?
> +
> + return 0;
> +}
> +
> +static const struct clk_ops samsung_pll2650xx_clk_ops = {
> + .recalc_rate = samsung_pll2650xx_recalc_rate,
> + .set_rate = samsung_pll2650xx_set_rate,
> + .round_rate = samsung_pll_round_rate,
> +};
> +
> +static const struct clk_ops samsung_pll2650xx_clk_min_ops = {
> + .recalc_rate = samsung_pll2650xx_recalc_rate,
> +};
> +
> static void __init _samsung_clk_register_pll(struct samsung_clk_provider *ctx,
> struct samsung_pll_clock *pll_clk,
> void __iomem *base)
> @@ -895,6 +990,12 @@ static void __init _samsung_clk_register_pll(struct samsung_clk_provider *ctx,
> else
> init.ops = &samsung_pll2550xx_clk_ops;
> break;
> + case pll_2650xx:
> + if (!pll->rate_table)
> + init.ops = &samsung_pll2650xx_clk_min_ops;
> + else
> + init.ops = &samsung_pll2650xx_clk_ops;
> + break;
> default:
> pr_warn("%s: Unknown pll type for pll clk %s\n",
> __func__, pll_clk->name);
> diff --git a/drivers/clk/samsung/clk-pll.h b/drivers/clk/samsung/clk-pll.h
> index e106470..b326e94 100644
> --- a/drivers/clk/samsung/clk-pll.h
> +++ b/drivers/clk/samsung/clk-pll.h
> @@ -26,6 +26,7 @@ enum samsung_pll_type {
> pll_6552,
> pll_6553,
> pll_2550xx,
> + pll_2650xx,
> };
>
> #define PLL_35XX_RATE(_rate, _m, _p, _s) \
> @@ -93,5 +94,4 @@ struct samsung_pll_rate_table {
> extern struct clk * __init samsung_clk_register_pll2550x(const char *name,
> const char *pname, const void __iomem *reg_base,
> const unsigned long offset);
> -
Not a part of this change.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH V2 05/10] clk/samsung: add support for pll2550xx
From: Tomasz Figa @ 2014-01-23 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389099548-14649-6-git-send-email-rahul.sharma@samsung.com>
On 07.01.2014 13:59, Rahul Sharma wrote:
> From: Pankaj Dubey <pankaj.dubey@samsung.com>
>
> exynos5260 use pll2550xx and it has different bit fields
> for P,M,S values as compared to pll2550. Support for
> pll2550xx is added here.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
> Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
> ---
> drivers/clk/samsung/clk-pll.c | 108 +++++++++++++++++++++++++++++++++++++++++
> drivers/clk/samsung/clk-pll.h | 1 +
> 2 files changed, 109 insertions(+)
Acked-by: Tomasz Figa <t.figa@samsung.com>
Best regards,
Tomasz
^ permalink raw reply
* [PATCH V2 03/10] pinctrl: exynos: add exynos5260 SoC specific data
From: Tomasz Figa @ 2014-01-23 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3846194.a18yHpXxuP@wuerfel>
On 07.01.2014 14:31, Arnd Bergmann wrote:
> On Tuesday 07 January 2014 18:29:01 Rahul Sharma wrote:
>> From: Young-Gun Jang <yg1004.jang@samsung.com>
>>
>> Add Samsung Exynos5260 SoC specific data to enable pinctrl
>> support for all platforms based on EXYNOS5260.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> Signed-off-by: Young-Gun Jang <yg1004.jang@samsung.com>
>> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com>
>> Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
>
> On a similar note to the comment about the platform patch, I think
> it would be good to extend the DT binding in a way that allows
> you to describe the differences between the SoCs without having
> to change the driver every time a new model comes out.
>
> We still have to maintain backwards compatibility with the
> existing bindings I suppose, but I'd rather not see new ones
> added like this. I realize that there is a tradeoff between
> having too much information in DT when it is always fixed, and
> having too much hardcoded in the driver, and at some point there
> was a conscious decision to do it like this, but I fear the
> tradeoff has changed with the number of EXYNOS implementations
> that really only differ in their pin banks.
There isn't really too much data being added to the driver on per-SoC
basis. Anyway, I remember that when I was trying to move all the data to
DT long time ago when refactoring the driver, after a long discussion on
the ML it was decided that it is not really a good idea and so we have
the end result as we can see now.
Personally I'd prefer all the static data of struct samsung_pin_bank to
be located in DT, with each bank having a compatible string that would
translate to appropriate struct samsung_pin_bank_type, which is common
across multiple SoCs (basically all >= S5PV210), and parameters such as
pin-count, control-base, and geint-/weint-base (which would also imply
interrupt type) - name (which is used only for human readable text)
could be implied by node names. However that would mean quite
significant effort (and churn), especially considering the fact that we
need to maintain compatibility with existing bindings, due to "ABI
stability" (which I'm slowly losing my faith in), so I don't think it's
worth it.
So, from me:
Acked-by: Tomasz Figa <t.figa@samsung.com>
Best regards,
Tomasz
^ permalink raw reply
* [GIT PULL 6/6] ARM: driver updates for 3.14
From: Olof Johansson @ 2014-01-23 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390502188-16896-1-git-send-email-olof@lixom.net>
Updates of SoC-near drivers and other driver updates that makes more sense to
take through our tree.
The largest part of this is a conversion of device registration for some
renesas shmobile/sh devices over to use resources. This has required
coordination with the corresponding arch/sh changes, and we've agreed
to merge the arch/sh changes through our tree.
Added in this branch is support for Trusted Foundations secure firmware,
which is what is used on many of the commercial Nvidia Tegra products
that are in the market, including the Nvidia Shield. The code is local
to arch/arm at this time since it's uncertain whether it will be shared
with arm64 longer-term, if needed we will refactor later.
A couple of new RTC drivers used on ARM boards, merged through our tree
on request by the RTC maintainer.
... plus a bunch of smaller updates across the board, gpio conversions
----------------------------------------------------------------
The following changes since commit 3ec910bd3c138f8c3a454bc1ee5ff2d4f85ce307:
Merge branch 'next/boards' into HEAD
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/drivers-for-linus
for you to fetch changes up to cd2f43a1f7400a74a084094502f70df2e169c6e8:
Merge tag 'davinci-for-v3.14/watchdog' of git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into next/drivers
----------------------------------------------------------------
Alexandre Courbot (7):
ARM: add basic support for Trusted Foundations
of: add vendor prefix for Trusted Logic Mobility
of: add Trusted Foundations bindings documentation
ARM: tegra: add support for Trusted Foundations
ARM: tegra: split setting of CPU reset handler
ARM: tegra: set CPU reset handler using firmware
ARM: tegra: support Trusted Foundations by default
Arnaud Ebalard (1):
rtc: Add support for Intersil ISL12057 I2C RTC chip
Bastian Hecht (1):
serial: sh-sci: Add OF support
Carlo Caione (2):
ARM: sun4i/sun7i: DT documentation for RTC driver
ARM: sun4i/sun7i: RTC driver
Chander Kashyap (1):
irqchip: exynos-combiner: remove hard-coded irq_base value
Dan Carpenter (1):
bus: mvebu-mbus: potential forever loop in mvebu_mbus_init()
Ezequiel Garcia (1):
bus: mvebu-mbus: Remove deprecated comment
Grygorii Strashko (4):
gpio: davinci: get rid of DAVINCI_N_GPIO
gpio: introduce GPIO_DAVINCI kconfig option
gpio: davinci: use chained_irq_enter/chained_irq_exit API
gpio: davinci: don't create irq_domain in case of unbanked irqs
Ivan Khoronzhuk (1):
watchdog: davinci: rename platform driver to davinci-wdt
Ivan T. Ivanov (1):
usb: phy: msm: Move mach dependent code to platform data
KV Sujith (1):
gpio: davinci: add OF support
Kevin Hilman (2):
Merge tag 'renesas-usb-r8a66597-hcd-for-v3.14' of git://git.kernel.org/.../horms/renesas into next/drivers
Merge tag 'davinci-for-v3.14/watchdog' of git://git.kernel.org/.../nsekhar/linux-davinci into next/drivers
Lad, Prabhakar (3):
gpio: davinci: use {readl|writel}_relaxed() instead of __raw_*
gpio: davinci: convert to use irqdomain support.
gpio: davinci: remove unused variable intc_irq_num
Laurent Pinchart (7):
usb: r8a66597-hcd: Convert to clk_prepare/unprepare
sh: Declare SCIF register base and IRQ as resources
sh: sh772[34]: Set serial port sampling rate to 8 for SCIFA ports
sh: Don't set plat_sci_port scbrr_algo_id field
serial: sh-sci: Remove platform data scbrr_algo_id field
serial: sh-sci: Remove platform data mapbase and irqs fields
serial: sh-sci: Add device tree bindings documentation
Linus Walleij (4):
irqchip: versatile FPGA: support cascaded interrupts from DT
ARM: integrator: pass parent IRQ to the SIC
clk: versatile: pass a name to ICST clock provider
clk: versatile: fixup IM-PD1 clock implementation
Magnus Damm (2):
irqchip: renesas-irqc: Use lazy disable
irqchip: renesas-irqc: Enable mask on suspend
Nicolas Ferre (4):
crypto: atmel-aes - add support for Device Tree
crypto: atmel-tdes - add support for Device Tree
crypto: atmel-sha - add support for Device Tree
crypto: atmel-sha - add sha information to the log
Olof Johansson (16):
Merge tag 'mvebu-drivers-3.14' of git://git.infradead.org/linux-mvebu into next/drivers
Merge tag 's3c64xx-dmaengine' of git://git.kernel.org/.../broonie/misc into next/drivers
Merge branch 'at91/dt' into next/drivers
Merge tag 'at91-drivers' of git://github.com/at91linux/linux-at91 into next/drivers
Merge tag 'samsung-irq' of git://git.kernel.org/.../kgene/linux-samsung into next/drivers
Merge tag 'tegra-for-3.14-trusted-foundations' of git://git.kernel.org/.../tegra/linux into next/drivers
Merge tag 'sunxi-drivers-for-3.14' of https://github.com/mripard/linux into next/drivers
Merge tag 'renesas-irqc-for-v3.14' of git://git.kernel.org/.../horms/renesas into next/drivers
Merge branch 'renesas/drivers-sci2' into next/drivers
Merge tag 'renesas-sh-soc-for-v3.14' of git://git.kernel.org/.../horms/renesas into next/drivers
Merge tag 'renesas-sh-sci3-for-v3.14' of git://git.kernel.org/.../horms/renesas into next/drivers
Merge tag 'mvebu-drivers-3.14-2' of git://git.infradead.org/linux-mvebu into next/drivers
Merge tag 'davinci-for-v3.14/gpio' of git://git.kernel.org/.../nsekhar/linux-davinci into next/drivers
Merge tag 'sunxi-core-for-3.14' of https://github.com/mripard/linux into next/drivers
Merge tag 'integrator-for-v3.14' of git://git.kernel.org/.../linusw/linux-integrator into next/drivers
Merge branch 'qcom/drivers' into next/drivers
Sergei Shtylyov (1):
irq-renesas-irqc: simplify irq_set_type() method
Simon Horman (1):
Merge branch 'sh-soc' into sh-sci2-base
Stephen Boyd (2):
mmc: msm_sdcc: Limit driver to platforms that use it
tty: serial: Limit msm_serial_hs driver to platforms that use it
panchaxari (1):
ARM: integrator: Default enable ARM_PATCH_PHYS_VIRT, AUTO_ZRELADDR
.../arm/firmware/tlm,trusted-foundations.txt | 20 +
Documentation/devicetree/bindings/arm/tegra.txt | 5 +
.../bindings/arm/versatile-fpga-irq.txt | 5 +
.../devicetree/bindings/crypto/atmel-crypto.txt | 68 +++
.../devicetree/bindings/gpio/gpio-davinci.txt | 41 ++
.../devicetree/bindings/i2c/trivial-devices.txt | 1 +
.../devicetree/bindings/rtc/sunxi-rtc.txt | 17 +
.../bindings/serial/renesas,sci-serial.txt | 46 ++
.../devicetree/bindings/vendor-prefixes.txt | 2 +
arch/arm/Kconfig | 4 +
arch/arm/Makefile | 1 +
arch/arm/boot/dts/integratorcp.dts | 3 +
arch/arm/configs/tegra_defconfig | 1 +
arch/arm/firmware/Kconfig | 28 +
arch/arm/firmware/Makefile | 1 +
arch/arm/firmware/trusted_foundations.c | 81 +++
arch/arm/include/asm/trusted_foundations.h | 67 +++
arch/arm/mach-davinci/da830.c | 3 +-
arch/arm/mach-davinci/da850.c | 3 +-
arch/arm/mach-davinci/da8xx-dt.c | 2 +-
arch/arm/mach-davinci/devices-da8xx.c | 4 +-
arch/arm/mach-davinci/devices.c | 2 +-
arch/arm/mach-davinci/dm355.c | 3 +-
arch/arm/mach-davinci/dm365.c | 3 +-
arch/arm/mach-davinci/dm644x.c | 3 +-
arch/arm/mach-davinci/dm646x.c | 3 +-
arch/arm/mach-msm/board-msm7x30.c | 35 ++
arch/arm/mach-msm/board-qsd8x50.c | 35 ++
arch/arm/mach-tegra/Kconfig | 1 +
arch/arm/mach-tegra/reset.c | 40 +-
arch/arm/mach-tegra/tegra.c | 2 +
arch/sh/kernel/cpu/sh2/setup-sh7619.c | 30 +-
arch/sh/kernel/cpu/sh2a/setup-mxg.c | 10 +-
arch/sh/kernel/cpu/sh2a/setup-sh7201.c | 80 ++-
arch/sh/kernel/cpu/sh2a/setup-sh7203.c | 40 +-
arch/sh/kernel/cpu/sh2a/setup-sh7206.c | 40 +-
arch/sh/kernel/cpu/sh2a/setup-sh7264.c | 104 +++-
arch/sh/kernel/cpu/sh2a/setup-sh7269.c | 104 +++-
arch/sh/kernel/cpu/sh3/setup-sh7705.c | 20 +-
arch/sh/kernel/cpu/sh3/setup-sh770x.c | 30 +-
arch/sh/kernel/cpu/sh3/setup-sh7710.c | 20 +-
arch/sh/kernel/cpu/sh3/setup-sh7720.c | 20 +-
arch/sh/kernel/cpu/sh4/setup-sh4-202.c | 16 +-
arch/sh/kernel/cpu/sh4/setup-sh7750.c | 20 +-
arch/sh/kernel/cpu/sh4/setup-sh7760.c | 62 ++-
arch/sh/kernel/cpu/sh4a/setup-sh7343.c | 40 +-
arch/sh/kernel/cpu/sh4a/setup-sh7366.c | 10 +-
arch/sh/kernel/cpu/sh4a/setup-sh7722.c | 30 +-
arch/sh/kernel/cpu/sh4a/setup-sh7723.c | 63 ++-
arch/sh/kernel/cpu/sh4a/setup-sh7724.c | 63 ++-
arch/sh/kernel/cpu/sh4a/setup-sh7734.c | 72 ++-
arch/sh/kernel/cpu/sh4a/setup-sh7757.c | 30 +-
arch/sh/kernel/cpu/sh4a/setup-sh7763.c | 30 +-
arch/sh/kernel/cpu/sh4a/setup-sh7770.c | 100 ++--
arch/sh/kernel/cpu/sh4a/setup-sh7780.c | 22 +-
arch/sh/kernel/cpu/sh4a/setup-sh7785.c | 60 ++-
arch/sh/kernel/cpu/sh4a/setup-sh7786.c | 88 +++-
arch/sh/kernel/cpu/sh4a/setup-shx3.c | 48 +-
arch/sh/kernel/cpu/sh5/setup-sh5.c | 12 +-
drivers/bus/mvebu-mbus.c | 10 +-
drivers/clk/versatile/clk-icst.c | 3 +-
drivers/clk/versatile/clk-icst.h | 1 +
drivers/clk/versatile/clk-impd1.c | 88 +++-
drivers/clk/versatile/clk-integrator.c | 2 +-
drivers/clk/versatile/clk-realview.c | 6 +-
drivers/crypto/atmel-aes.c | 143 +++--
drivers/crypto/atmel-sha.c | 103 +++-
drivers/crypto/atmel-tdes.c | 143 +++--
drivers/gpio/Kconfig | 7 +
drivers/gpio/Makefile | 2 +-
drivers/gpio/gpio-davinci.c | 185 +++++--
drivers/irqchip/exynos-combiner.c | 15 +-
drivers/irqchip/irq-renesas-irqc.c | 21 +-
drivers/irqchip/irq-versatile-fpga.c | 15 +-
drivers/mmc/host/Kconfig | 2 +-
drivers/rtc/Kconfig | 18 +
drivers/rtc/Makefile | 2 +
drivers/rtc/rtc-isl12057.c | 310 +++++++++++
drivers/rtc/rtc-sunxi.c | 523 +++++++++++++++++++
drivers/tty/serial/Kconfig | 2 +-
drivers/tty/serial/sh-sci.c | 187 +++++--
drivers/usb/host/r8a66597-hcd.c | 4 +-
drivers/usb/phy/phy-msm-usb.c | 35 +-
drivers/watchdog/davinci_wdt.c | 4 +-
include/linux/platform_data/gpio-davinci.h | 3 +-
include/linux/serial_sci.h | 36 --
include/linux/usb/msm_hsusb.h | 3 +
87 files changed, 2914 insertions(+), 753 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt
create mode 100644 Documentation/devicetree/bindings/crypto/atmel-crypto.txt
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-davinci.txt
create mode 100644 Documentation/devicetree/bindings/rtc/sunxi-rtc.txt
create mode 100644 Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
create mode 100644 arch/arm/firmware/Kconfig
create mode 100644 arch/arm/firmware/Makefile
create mode 100644 arch/arm/firmware/trusted_foundations.c
create mode 100644 arch/arm/include/asm/trusted_foundations.h
create mode 100644 drivers/rtc/rtc-isl12057.c
create mode 100644 drivers/rtc/rtc-sunxi.c
^ permalink raw reply
* [GIT PULL 5/6] ARM: SoC board updates for 3.14
From: Olof Johansson @ 2014-01-23 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390502188-16896-1-git-send-email-olof@lixom.net>
This branch is reducing in size for every release since most board-related
changes have started happening in devicetrees now. Still, we have some things
going on here.
* Renesas platforms are still adding a bit more legacy device support, something
that should trail off shortly as they move to full DT.
* We group most defconfig updates into this branch out of old habits
* Removal of legacy OMAP2 platforms over to DT continues, and a handful of old
code is being removed here.
Conflicts:
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c:
Bugfix in later -rc conflicts with code removal. Remove both irqs[]
arrays.
----------------------------------------------------------------
The following changes since commit aef07284ff26becdff4ac000f05ab020a5cfe29c:
Merge branch 'next/dt' into HEAD
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/boards-for-linus
for you to fetch changes up to e41006c22eab8eb7763995e8a0be089b900b620b:
Merge tag 'omap-for-v3.14/dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/boards
----------------------------------------------------------------
Aaro Koskinen (1):
ARM: OMAP2+: dts: add n8x0 onenand
Bartlomiej Zolnierkiewicz (1):
ARM: exynos_defconfig: increase CONFIG_NR_CPUS value to 8
Ezequiel Garcia (2):
ARM: mvebu: config: Add GPIO connected LEDs support to defconfig
ARM: mvebu: config: Enable NAND support
Hiep Cao Minh (1):
ARM: shmobile: Lager:add SPI FLASH support on QSPI
Kevin Hilman (1):
Merge tag 'omap-for-v3.14/board-removal-safe' of git://git.kernel.org/.../tmlind/linux-omap into next/boards
Kuninori Morimoto (9):
ARM: shmobile: bockw: enable CONFIG_REGULATOR
ARM: shmobile: lager: add gpio regulator support on defconfig
ARM: shmobile: lager: fixup I2C device on defconfig
ARM: shmobile: bockw: use regulator for MMCIF
ARM: shmobile: bockw: fixup FPGA ioremap area
ARM: shmobile: bockw: add pin pull-up setting for SDHI
ARM: shmobile: armadillo: fixup FSI address size
ARM: shmobile: bockw: remove unused RSND_SSI_CLK_FROM_ADG
ARM: shmobile: lager: add gpio/fixed regulator for SDHI
Laurent Pinchart (16):
ARM: shmobile: genmai: Rename ARCH_SHMOBILE to ARCH_SHMOBILE_LEGACY
ARM: shmobile: mackerel: Use pinconf API to configure pin pull-down
ARM: Kconfig: Mention Renesas ARM SoCs instead of SH-Mobile
ARM: shmobile: armadillo800eva: Enable backlight control in defconfig
ARM: shmobile: koelsch: Add DU device
ARM: shmobile: armadillo: Set backlight enable GPIO
ARM: shmobile: lager-reference: Enable multiplaform kernel support
ARM: shmobile: koelsch-reference: Remove duplicate CCF initialization
ARM: shmobile: lager-reference: Instantiate clkdevs for SCIF and CMT
ARM: shmobile: koelsch-reference: Instantiate clkdevs for SCIF and CMT
ARM: shmobile: Remove non-multiplatform Lager reference support
ARM: shmobile: Remove non-multiplatform Koelsch reference support
ARM: shmobile: Let Lager multiplatform boot with Lager DTB
ARM: shmobile: Let Koelsch multiplatform boot with Koelsch DTB
ARM: shmobile: mackerel: Fix USBHS pinconf entry
ARM: dts: Split omap3 pinmux core device
Magnus Damm (14):
ARM: shmobile: Genmai defconfig
ARM: shmobile: Enable PFC/GPIO on the Koelsch board
ARM: shmobile: Add Koelsch LED6, LED7 and LED8 support
ARM: shmobile: Add Koelsch SW2 support
ARM: shmobile: r8a7791 Koelsch DT reference C bits
ARM: shmobile: Initial r8a7791 and Koelsch multiplatform support
ARM: shmobile: r7s72100 Genmai DT reference DTS bits
ARM: shmobile: r7s72100 Genmai DT reference C bits
ARM: shmobile: r7s72100 Genmai Multiplatform
ARM: shmobile: Use ->init_late() on Koelsch
ARM: shmobile: koelsch: mark GPIO keys as wake-up sources
ARM: shmobile: Hook up SW30-SW36 on Koelsch
ARM: shmobile: Use ->init_late() on Lager
ARM: shmobile: Add pinctrl_register_mappings() for Koelsch
Olof Johansson (13):
Merge tag 'renesas-defconfig-for-v3.14' of git://git.kernel.org/.../horms/renesas into next/boards
Merge tag 'mvebu-defconfig-3.14' of git://git.infradead.org/linux-mvebu into next/boards
Merge tag 'samsung-defconfig' of git://git.kernel.org/.../kgene/linux-samsung into next/boards
Merge tag 'mvebu-defconfig-3.14-2' of git://git.infradead.org/linux-mvebu into next/boards
Merge tag 'tegra-for-3.14-defconfig' of git://git.kernel.org/.../tegra/linux into next/boards
Merge tag 'tegra-for-3.14-defconfig-2' of git://git.kernel.org/.../tegra/linux into next/boards
Merge tag 'v3.13-rc5' into next/boards
Merge tag 'samsung-defconfig-2' of git://git.kernel.org/.../kgene/linux-samsung into next/boards
Merge tag 'renesas-boards-for-v3.14' of git://git.kernel.org/.../horms/renesas into next/boards
Merge tag 'renesas-defconfig2-for-v3.14' of git://git.kernel.org/.../horms/renesas into next/boards
Merge branch 'qcom/boards' into next/boards
Merge tag 'renesas-boards2-for-v3.14' of git://git.kernel.org/.../horms/renesas into next/boards
Merge tag 'omap-for-v3.14/dt-signed' of git://git.kernel.org/.../tmlind/linux-omap into next/boards
Paul Walmsley (1):
ARM: shmobile: mackerel: clk_round_rate() can return a zero to indicate an error
Rohit Vaswani (2):
ARM: msm: Add support for APQ8074 Dragonboard
defconfig: msm_defconfig: Enable CONFIG_ARCH_MSM8974
Sachin Kamat (1):
ARM: exynos_defconfig: Enable S2MPS11 voltage regulator
Sergei Shtylyov (4):
ARM: shmobile: marzen: enable HPB-DMAC in defconfig
ARM: shmobile: bockw: enable HPB-DMAC in defconfig
ARM: shmobile: Koelsch: enable Ether in defconfig
ARM: shmobile: Koelsch: add Ether support
Shinya Kuribayashi (2):
ARM: shmobile: lager: set .debounce_interval
ARM: shmobile: lager: mark GPIO keys as wake-up sources
Simon Horman (17):
ARM: shmobile: bockw: Do not set command line in defconfig
ARM: shmobile: marzen: Do not set command line in defconfig
ARM: shmobile: bockw: Do not disable CONFIG_INOTIFY_USER in defconfig
ARM: shmobile: marzen: Do not disable CONFIG_INOTIFY_USER in defconfig
ARM: shmobile: bockw: Enable CONFIG_VFP in defconfig
ARM: shmobile: marzen: Enable CONFIG_VFP in defconfig
ARM: shmobile: bockw: Do not enable CONFIG_DEVTMPFS defconfig
ARM: shmobile: marzen: Do not enable CONFIG_DEVTMPFS defconfig
ARM: shmobile: bockw: Enable CONFIG_PACKET in defconfig
ARM: shmobile: marzen: Enable CONFIG_PACKET in defconfig
ARM: shmobile: marzen: Do not enable CONFIG_SMC911X in defconfig
ARM: shmobile: kzm9d: Enable AUTO_ZRELADDR in defconfig
Merge tag 'renesas-cleanup-for-v3.14' into boards-base
ARM: shmobile: koelsch: set .debounce_interval
ARM: shmobile: koelsch: Enable CONFIG_PACKET in defconfig
ARM: shmobile: koelsch: Do not disable CONFIG_{INOTIFY_USER,UNIX} in defconfig
Merge branch 'heads/soc2' into boards2-base
Srinivas Kandagatla (1):
ARM: multi_v7_defconfig: Fix STi support
Stephen Boyd (1):
ARM: msm_defconfig: Enable restart driver
Stephen Warren (2):
ARM: tegra: tegra_defconfig updates
ARM: bcm2835: bcm2835_defconfig updates
Suman Anna (1):
ARM: dts: OMAP2: fix interrupt number for rng
Thierry Reding (1):
ARM: tegra: Enable DRM panel support
Thomas Petazzoni (1):
ARM: kirkwood: enable HIGHMEM in defconfig
Tony Lindgren (22):
mfd: twl-core: Fix passing of platform data in the device tree case
Merge branch 'dt-regressions' into omap-for-v3.13/fixes-take4
ARM: dts: Add basic device tree support for omap2430 sdp
ARM: dts: Add basic Nokia N8X0 support
ARM: dts: Add basic support for omap3 LDP zoom1 labrador
Merge branch 'omap-for-v3.13/fixes-take4' into omap-for-v3.14/board-removal
Merge branch 'omap-for-v3.14/dt' into omap-for-v3.14/board-removal
ARM: OMAP2+: Add support for board specific auxdata quirks
ARM: OMAP2+: Add device tree compatible revision checks for n8x0
ARM: OMAP2+: Make n8x0 behave better with device tree based booting
ARM: OMAP2+: Add quirks support for n8x0
ARM: OMAP2+: Remove legacy booting support for n8x0
ARM: OMAP2+: Remove board file for H4
ARM: OMAP2+: Remove legacy board file for 2430sdp
ARM: OMAP2+: Remove legacy mux code for omap2
ARM: OMAP2+: Remove legacy hwmod entries for omap2
Merge branch 'omap-for-v3.14/board-removal' into omap-for-v3.14/omap3-board-removal
ARM: OMAP2+: Add support for legacy auxdata for twl
ARM: OMAP2+: Use pdata quirks for emac on am3517
ARM: dts: Add basic devices on am3517-evm
ARM: dts: Add support for sbc-3xxx with cm-t3730
ARM: dts: Add omap specific pinctrl defines to use padconf addresses
arch/arm/Kconfig | 7 +-
arch/arm/boot/dts/Makefile | 17 +-
arch/arm/boot/dts/am3517-evm.dts | 29 +
arch/arm/boot/dts/omap2.dtsi | 2 +-
arch/arm/boot/dts/omap2420-n800.dts | 8 +
arch/arm/boot/dts/omap2420-n810-wimax.dts | 8 +
arch/arm/boot/dts/omap2420-n810.dts | 8 +
arch/arm/boot/dts/omap2420-n8x0-common.dtsi | 99 +++
arch/arm/boot/dts/omap2430-sdp.dts | 49 ++
arch/arm/boot/dts/omap3-beagle-xm.dts | 40 +-
arch/arm/boot/dts/omap3-beagle.dts | 40 +-
arch/arm/boot/dts/omap3-cm-t3730.dts | 104 +++
arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 95 +++
arch/arm/boot/dts/omap3-igep.dtsi | 2 -
arch/arm/boot/dts/omap3-igep0020.dts | 52 +-
arch/arm/boot/dts/omap3-igep0030.dts | 10 +-
arch/arm/boot/dts/omap3-ldp.dts | 231 ++++++
arch/arm/boot/dts/omap3-sb-t35.dtsi | 40 +
arch/arm/boot/dts/omap3-sbc-t3730.dts | 30 +
arch/arm/boot/dts/omap3-zoom3.dts | 23 +-
arch/arm/boot/dts/omap3.dtsi | 2 +-
arch/arm/boot/dts/omap34xx.dtsi | 13 +
arch/arm/boot/dts/omap36xx.dtsi | 11 +
arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 6 +
arch/arm/boot/dts/r7s72100-genmai-reference.dts | 31 +
arch/arm/configs/armadillo800eva_defconfig | 3 +
arch/arm/configs/bcm2835_defconfig | 37 +-
arch/arm/configs/bockw_defconfig | 10 +-
arch/arm/configs/exynos_defconfig | 3 +-
arch/arm/configs/genmai_defconfig | 116 +++
arch/arm/configs/kirkwood_defconfig | 1 +
arch/arm/configs/koelsch_defconfig | 25 +-
arch/arm/configs/kzm9d_defconfig | 1 +
arch/arm/configs/lager_defconfig | 3 +-
arch/arm/configs/marzen_defconfig | 10 +-
arch/arm/configs/msm_defconfig | 3 +
arch/arm/configs/multi_v7_defconfig | 3 +
arch/arm/configs/mvebu_defconfig | 3 +
arch/arm/configs/tegra_defconfig | 22 +-
arch/arm/mach-msm/board-dt.c | 9 +
arch/arm/mach-omap2/Kconfig | 13 -
arch/arm/mach-omap2/Makefile | 4 -
arch/arm/mach-omap2/board-2430sdp.c | 273 -------
arch/arm/mach-omap2/board-h4.c | 365 ---------
arch/arm/mach-omap2/board-n8x0.c | 234 ++----
arch/arm/mach-omap2/common-board-devices.h | 1 +
arch/arm/mach-omap2/common.h | 1 +
arch/arm/mach-omap2/msdi.c | 69 --
arch/arm/mach-omap2/mux.h | 2 -
arch/arm/mach-omap2/mux2420.c | 690 ----------------
arch/arm/mach-omap2/mux2420.h | 282 -------
arch/arm/mach-omap2/mux2430.c | 793 -------------------
arch/arm/mach-omap2/mux2430.h | 370 ---------
arch/arm/mach-omap2/omap_device.c | 2 +
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 137 ----
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 266 -------
.../omap_hwmod_2xxx_interconnect_data.c | 165 +---
.../mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 72 +-
arch/arm/mach-omap2/omap_hwmod_common_data.h | 5 -
arch/arm/mach-omap2/pdata-quirks.c | 138 +++-
arch/arm/mach-shmobile/Kconfig | 63 +-
arch/arm/mach-shmobile/Makefile | 5 +-
arch/arm/mach-shmobile/Makefile.boot | 4 +-
arch/arm/mach-shmobile/board-armadillo800eva.c | 7 +-
arch/arm/mach-shmobile/board-bockw-reference.c | 19 +-
arch/arm/mach-shmobile/board-bockw.c | 17 +-
arch/arm/mach-shmobile/board-genmai-reference.c | 49 ++
.../arm/mach-shmobile/board-koelsch-reference.c | 79 ++
arch/arm/mach-shmobile/board-koelsch.c | 190 ++++-
arch/arm/mach-shmobile/board-lager-reference.c | 34 +
arch/arm/mach-shmobile/board-lager.c | 151 +++-
arch/arm/mach-shmobile/board-mackerel.c | 21 +-
arch/arm/mach-shmobile/sh-gpio.h | 19 -
include/dt-bindings/pinctrl/omap.h | 20 +
include/sound/rcar_snd.h | 1 -
75 files changed, 1899 insertions(+), 3868 deletions(-)
create mode 100644 arch/arm/boot/dts/omap2420-n800.dts
create mode 100644 arch/arm/boot/dts/omap2420-n810-wimax.dts
create mode 100644 arch/arm/boot/dts/omap2420-n810.dts
create mode 100644 arch/arm/boot/dts/omap2420-n8x0-common.dtsi
create mode 100644 arch/arm/boot/dts/omap2430-sdp.dts
create mode 100644 arch/arm/boot/dts/omap3-cm-t3730.dts
create mode 100644 arch/arm/boot/dts/omap3-cm-t3x30.dtsi
create mode 100644 arch/arm/boot/dts/omap3-ldp.dts
create mode 100644 arch/arm/boot/dts/omap3-sb-t35.dtsi
create mode 100644 arch/arm/boot/dts/omap3-sbc-t3730.dts
create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts
create mode 100644 arch/arm/boot/dts/r7s72100-genmai-reference.dts
create mode 100644 arch/arm/configs/genmai_defconfig
delete mode 100644 arch/arm/mach-omap2/board-2430sdp.c
delete mode 100644 arch/arm/mach-omap2/board-h4.c
delete mode 100644 arch/arm/mach-omap2/mux2420.c
delete mode 100644 arch/arm/mach-omap2/mux2420.h
delete mode 100644 arch/arm/mach-omap2/mux2430.c
delete mode 100644 arch/arm/mach-omap2/mux2430.h
create mode 100644 arch/arm/mach-shmobile/board-genmai-reference.c
create mode 100644 arch/arm/mach-shmobile/board-koelsch-reference.c
^ 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