* [PATCH 1/3] ARM: mvebu: remove unneeded ->map_io field for Armada 370/XP
From: Jason Cooper @ 2014-02-11 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392138433-12573-2-git-send-email-thomas.petazzoni@free-electrons.com>
On Tue, Feb 11, 2014 at 06:07:11PM +0100, Thomas Petazzoni wrote:
> The ->map_io() implementation of Armada 370/XP simply calls
> debug_ll_io_init(), which is exactly what the kernel does when
> ->map_io is NULL. Therefore, there is no need to have a specific
> ->map_io() implementation in Armada 370/XP.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> arch/arm/mach-mvebu/armada-370-xp.c | 6 ------
> 1 file changed, 6 deletions(-)
Applied to mvebu/soc with Gregory's Ack.
thx,
Jason.
^ permalink raw reply
* [PATCH v5 7/8] ARM: dts: sun5i: Add support for mmc
From: David Lanzendörfer @ 2014-02-11 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140211190543.4568.83517.stgit@dizzy-6.o2s.ch>
Signed-off-by: David Lanzend?rfer <david.lanzendoerfer@o2s.ch>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 30 +++++++++++++++
arch/arm/boot/dts/sun5i-a10s.dtsi | 44 ++++++++++++++++++++++
arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts | 15 ++++++++
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 15 ++++++++
arch/arm/boot/dts/sun5i-a13.dtsi | 37 +++++++++++++++++++
5 files changed, 141 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index 3c9f8b3..7189adf55 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -34,7 +34,37 @@
};
};
+ mmc0: mmc at 01c0f000 {
+ pinctrl-names = "default", "default";
+ pinctrl-0 = <&mmc0_pins_a>;
+ pinctrl-1 = <&mmc0_cd_pin_olinuxino_micro>;
+ cd-gpios = <&pio 6 1 0>; /* PG1 */
+ status = "okay";
+ };
+
+ mmc1: mmc at 01c10000 {
+ pinctrl-names = "default", "default";
+ pinctrl-0 = <&mmc1_pins_a>;
+ pinctrl-1 = <&mmc1_cd_pin_olinuxino_micro>;
+ cd-gpios = <&pio 6 13 0>; /* PG13 */
+ status = "okay";
+ };
+
pinctrl at 01c20800 {
+ mmc0_cd_pin_olinuxino_micro: mmc0_cd_pin at 0 {
+ allwinner,pins = "PG1";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ mmc1_cd_pin_olinuxino_micro: mmc1_cd_pin at 0 {
+ allwinner,pins = "PG13";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
led_pins_olinuxino: led_pins at 0 {
allwinner,pins = "PE3";
allwinner,function = "gpio_out";
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 327e87b..b6d1de0 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -293,6 +293,36 @@
#size-cells = <0>;
};
+ mmc0: mmc at 01c0f000 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <&ahb_gates 8>, <&mmc0_clk>;
+ clock-names = "ahb", "mod";
+ interrupts = <32>;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
+ mmc1: mmc at 01c10000 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c10000 0x1000>;
+ clocks = <&ahb_gates 9>, <&mmc1_clk>;
+ clock-names = "ahb", "mod";
+ interrupts = <33>;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
+ mmc2: mmc at 01c11000 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c11000 0x1000>;
+ clocks = <&ahb_gates 10>, <&mmc2_clk>;
+ clock-names = "ahb", "mod";
+ interrupts = <34>;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
intc: interrupt-controller at 01c20400 {
compatible = "allwinner,sun4i-ic";
reg = <0x01c20400 0x400>;
@@ -363,6 +393,20 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
+ mmc0_pins_a: mmc0 at 0 {
+ allwinner,pins = "PF0","PF1","PF2","PF3","PF4","PF5";
+ allwinner,function = "mmc0";
+ allwinner,drive = <3>;
+ allwinner,pull = <0>;
+ };
+
+ mmc1_pins_a: mmc1 at 0 {
+ allwinner,pins = "PG3","PG4","PG5","PG6","PG7","PG8";
+ allwinner,function = "mmc1";
+ allwinner,drive = <3>;
+ allwinner,pull = <0>;
+ };
};
timer at 01c20c00 {
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts b/arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts
index fe2ce0a..6ae5867 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts
@@ -20,7 +20,22 @@
compatible = "olimex,a13-olinuxino-micro", "allwinner,sun5i-a13";
soc at 01c00000 {
+ mmc0: mmc at 01c0f000 {
+ pinctrl-names = "default", "default";
+ pinctrl-0 = <&mmc0_pins_a>;
+ pinctrl-1 = <&mmc0_cd_pin_olinuxinom>;
+ cd-gpios = <&pio 6 0 0>; /* PG0 */
+ status = "okay";
+ };
+
pinctrl at 01c20800 {
+ mmc0_cd_pin_olinuxinom: mmc0_cd_pin at 0 {
+ allwinner,pins = "PG0";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
led_pins_olinuxinom: led_pins at 0 {
allwinner,pins = "PG9";
allwinner,function = "gpio_out";
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
index a4ba5ff..b23237b 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
@@ -19,7 +19,22 @@
compatible = "olimex,a13-olinuxino", "allwinner,sun5i-a13";
soc at 01c00000 {
+ mmc0: mmc at 01c0f000 {
+ pinctrl-names = "default", "default";
+ pinctrl-0 = <&mmc0_pins_a>;
+ pinctrl-1 = <&mmc0_cd_pin_olinuxino>;
+ cd-gpios = <&pio 6 0 0>; /* PG0 */
+ status = "okay";
+ };
+
pinctrl at 01c20800 {
+ mmc0_cd_pin_olinuxino: mmc0_cd_pin at 0 {
+ allwinner,pins = "PG0";
+ allwinner,function = "gpio_in";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
led_pins_olinuxino: led_pins at 0 {
allwinner,pins = "PG9";
allwinner,function = "gpio_out";
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index f49eb13..040d304 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -274,6 +274,36 @@
#size-cells = <1>;
ranges;
+ mmc0: mmc at 01c0f000 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <&ahb_gates 8>, <&mmc0_clk>;
+ clock-names = "ahb", "mod";
+ interrupts = <32>;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
+ mmc1: mmc at 01c10000 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c10000 0x1000>;
+ clocks = <&ahb_gates 9>, <&mmc1_clk>;
+ clock-names = "ahb", "mod";
+ interrupts = <33>;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
+ mmc2: mmc at 01c11000 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c11000 0x1000>;
+ clocks = <&ahb_gates 10>, <&mmc2_clk>;
+ clock-names = "ahb", "mod";
+ interrupts = <34>;
+ bus-width = <4>;
+ status = "disabled";
+ };
+
intc: interrupt-controller at 01c20400 {
compatible = "allwinner,sun4i-ic";
reg = <0x01c20400 0x400>;
@@ -326,6 +356,13 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
+ mmc0_pins_a: mmc0 at 0 {
+ allwinner,pins = "PF0","PF1","PF2","PF3","PF4","PF5";
+ allwinner,function = "mmc0";
+ allwinner,drive = <3>;
+ allwinner,pull = <0>;
+ };
};
timer at 01c20c00 {
^ permalink raw reply related
* [PATCH v5 8/8] ARM: sunxi: Add documentation for driver for SD/MMC hosts found on Allwinner sunxi SoCs
From: David Lanzendörfer @ 2014-02-11 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140211190543.4568.83517.stgit@dizzy-6.o2s.ch>
Signed-off-by: David Lanzend?rfer <david.lanzendoerfer@o2s.ch>
---
.../devicetree/bindings/mmc/sunxi-mmc.txt | 32 ++++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
new file mode 100644
index 0000000..2ebd8af
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
@@ -0,0 +1,32 @@
+* Allwinner sunxi MMC controller
+
+The highspeed MMC host controller on Allwinner SoCs provides an interface
+for MMC, SD and SDIO types of memory cards.
+
+Supported maximum speeds are the ones of the eMMC standard 4.5 as well
+as the speed of SD standard 3.0.
+Absolute maximum transfer rate is 200MB/s
+
+Required properties:
+- compatible: Should be "allwinner,<revision>-<chip>-mmc".
+ The supported chips include a10,a10s,13,a20 and a31,.
+- base registers are 0x1000 appart, so the base of mmc1
+ would be 0x01c0f000+0x1000=0x01c10000(see example)
+ and so on.
+- clocks requires the reference at the ahb clock gate
+ with the correct index (mmc0 -> 8, mmc1 -> 9, and so on)
+ as well as the reference to the correct mod0 clock.
+- interrupts requires the correct IRQ line
+ (mmc0 -> 32, mmc1 -> 33, and so on)
+
+Examples:
+
+mmc0: mmc at 01c0f000 {
+ compatible = "allwinner,sun5i-a13-mmc";
+ reg = <0x01c0f000 0x1000>;
+ clocks = <&ahb_gates 8>, <&mmc0_clk>;
+ clock-names = "ahb", "mod";
+ interrupts = <0 32 4>;
+ bus-width = <4>;
+ status = "disabled";
+};
^ permalink raw reply related
* [PATCH v2] ARM: asm: rename logical shift macros push pull into lspush lspull
From: Victor Kamensky @ 2014-02-11 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1402111253160.17677@knanqh.ubzr>
On 11 February 2014 09:58, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Tue, 11 Feb 2014, Dave Martin wrote:
>
>> On Tue, Feb 11, 2014 at 12:09:35PM -0500, Nicolas Pitre wrote:
>> > On Tue, 11 Feb 2014, Dave Martin wrote:
>> >
>> > > On Mon, Feb 10, 2014 at 04:30:01PM -0500, Nicolas Pitre wrote:
>> > > > On Mon, 10 Feb 2014, Victor Kamensky wrote:
>> > > >
>> > > > > Renames logical shift macros, 'push' and 'pull', defined in
>> > > > > arch/arm/include/asm/assembler.h, into 'lspush' and 'lspull'.
>> > > >
>> > > > I don't have any fundamental objection to the idea, except maybe for the
>> > > > actual names. I just can't come up with anything better though.
>> > >
>> > > For consistency with the get_byte_ stuff, how about:
>> > >
>> > > push -> towards_byte_0
>> > > pull -> from_byte_0
>> > >
>> > > That may make the purpose a little clearer, too.
>> >
>> > I don't know if
>> >
>> > mov r0, r1, from_byte_0 #8
>> >
>> > is that much clearer though.
>> >
>> > > (Assuming I've got them the right way around...)
>> >
>> > As you later noticed you got it wrong. :-)
>> > Most likely because "full from" and "push towards" are common english
>> > constructs.
>>
>> No more so than "pull towards" and "push from".
>
> OK. I'll trust you on that account.
>
>> I'll blame it on the fact that the get_byte_ macros have wrong-
>> endian numbering, which I didn't look at carefully enough ;)
>>
>> But I think we proved that my suggestion didn't really make things
>> easier to understand...
>
> What about:
>
> push -> next
> pull -> prev
>
> ?
>
> That would make:
>
> mov r0, r1, next #8
I am not native English speaker, so subtle details of your
discussion go above my head :). For me those tokens
were just symbols with specific meaning of logical shifts
and selected endianness. I'll do as you decide. Quick
grep over .S files under arch/arm seems 'next' and 'prev'
will be OK and I did build that confirms that.
One nit/question though: there are some cases where
'push' and 'pull' macros were used in macros and macro
parameters were also called 'push' and 'pull'. I.e something
like this:
mov r3, lr, pull #\pull
with rename 'pull' to 'lspull' I did not bother to rename
macro parameters because they are separate, have
just local context and 'lspull' is close to 'pull'. Resulting
proposed diff was:
- mov r3, lr, pull #\pull
+ mov r3, lr, lspull #\pull
I assume that if we change 'push -> next' and 'pull -> prev' I
will need to rename macro parameters in the same way.
So it will be:
+ mov r3, lr, prev #\prev
Is it correct?
Thanks,
Victor
>
> Nicolas
^ permalink raw reply
* [PATCH 2/3] ARM: mvebu: use GPIO DT defines in Armada 370/XP boards
From: Jason Cooper @ 2014-02-11 19:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392138433-12573-3-git-send-email-thomas.petazzoni@free-electrons.com>
On Tue, Feb 11, 2014 at 06:07:12PM +0100, Thomas Petazzoni wrote:
> Instead of harcoding 0 and 1 for the gpio specifications in the Armada
> 370/XP boards, use the <dt-bindings/gpio/gpio.h> header file and its
> GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW definitions.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> arch/arm/boot/dts/armada-370-mirabox.dts | 7 ++++---
> arch/arm/boot/dts/armada-370-rd.dts | 3 ++-
> arch/arm/boot/dts/armada-xp-axpwifiap.dts | 3 ++-
> arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 9 +++++----
> 4 files changed, 13 insertions(+), 9 deletions(-)
Patches 2 and 3 applied to mvebu/dt with Gregory's Ack's.
thx,
Jason.
^ permalink raw reply
* [PATCH 0/3] arm: at91: update defconfigs
From: Alexandre Belloni @ 2014-02-11 19:43 UTC (permalink / raw)
To: linux-arm-kernel
A few at91 defconfigs where not updated in a long time, refresh the configs for
at91sam9rl and at91sam9260/at91sam9g20.
Alexandre Belloni (3):
arm: at91sam9rl: refresh defconfig
arm: at91sam9260_9g20: remove useless configuration
arm: at91sam9260_9g20: refresh configuration
arch/arm/configs/at91sam9260_9g20_defconfig | 9 ++-------
arch/arm/configs/at91sam9rl_defconfig | 10 +++++++---
2 files changed, 9 insertions(+), 10 deletions(-)
--
1.8.3.2
^ permalink raw reply
* [PATCH 1/3] arm: at91sam9rl: refresh defconfig
From: Alexandre Belloni @ 2014-02-11 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392147841-7815-1-git-send-email-alexandre.belloni@free-electrons.com>
The defconfig for the at91sam9rl is quite old, refresh it:
- now uses EABI instead of OABI
- add devtmpfs support
- add UBI/UBIfs support
- remove a few config symbols that disappeared
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/configs/at91sam9rl_defconfig | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/configs/at91sam9rl_defconfig b/arch/arm/configs/at91sam9rl_defconfig
index 7cf87856d63c..e60f51afcf6a 100644
--- a/arch/arm/configs/at91sam9rl_defconfig
+++ b/arch/arm/configs/at91sam9rl_defconfig
@@ -1,8 +1,8 @@
-CONFIG_EXPERIMENTAL=y
# CONFIG_LOCALVERSION_AUTO is not set
# CONFIG_SWAP is not set
CONFIG_SYSVIPC=y
CONFIG_LOG_BUF_SHIFT=14
+CONFIG_EMBEDDED=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_SLAB=y
CONFIG_MODULES=y
@@ -15,20 +15,23 @@ CONFIG_ARCH_AT91SAM9RL=y
CONFIG_MACH_AT91SAM9RLEK=y
CONFIG_AT91_PROGRAMMABLE_CLOCKS=y
# CONFIG_ARM_THUMB is not set
+CONFIG_AEABI=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="mem=64M console=ttyS0,115200 initrd=0x21100000,17105363 root=/dev/ram0 rw"
-CONFIG_FPE_NWFPE=y
+CONFIG_AUTO_ZRELADDR=y
CONFIG_NET=y
CONFIG_UNIX=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_DATAFLASH=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_ATMEL=y
+CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=4
@@ -67,6 +70,7 @@ CONFIG_EXT2_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_TMPFS=y
+CONFIG_UBIFS_FS=y
CONFIG_CRAMFS=y
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_850=y
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/3] arm: at91sam9260_9g20: remove useless configuration
From: Alexandre Belloni @ 2014-02-11 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392147841-7815-1-git-send-email-alexandre.belloni@free-electrons.com>
A few configuration symbols are deprecated and disappeared a few versions ago,
remove them.
CONFIG_FPE_NWFPE depends on OABI_COMPAT which was not selected.
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/configs/at91sam9260_9g20_defconfig | 7 -------
1 file changed, 7 deletions(-)
diff --git a/arch/arm/configs/at91sam9260_9g20_defconfig b/arch/arm/configs/at91sam9260_9g20_defconfig
index 69b6928d3d9d..2c879bc29f86 100644
--- a/arch/arm/configs/at91sam9260_9g20_defconfig
+++ b/arch/arm/configs/at91sam9260_9g20_defconfig
@@ -32,15 +32,12 @@ CONFIG_AT91_PROGRAMMABLE_CLOCKS=y
CONFIG_AT91_SLOW_CLOCK=y
# CONFIG_ARM_THUMB is not set
CONFIG_AEABI=y
-CONFIG_LEDS=y
-CONFIG_LEDS_CPU=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_CMDLINE="mem=64M console=ttyS0,115200 initrd=0x21100000,3145728 root=/dev/ram0 rw"
CONFIG_AUTO_ZRELADDR=y
-CONFIG_FPE_NWFPE=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
@@ -59,7 +56,6 @@ CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_OF_PARTS=y
-CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_DATAFLASH=y
CONFIG_MTD_NAND=y
@@ -67,7 +63,6 @@ CONFIG_MTD_NAND_ATMEL=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=8192
-CONFIG_MISC_DEVICES=y
CONFIG_EEPROM_AT25=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
@@ -114,8 +109,6 @@ CONFIG_SND_PCM_OSS=y
CONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_VERBOSE_PROCFS is not set
CONFIG_USB=y
-CONFIG_USB_DEVICEFS=y
-# CONFIG_USB_DEVICE_CLASS is not set
CONFIG_USB_MON=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_STORAGE=y
--
1.8.3.2
^ permalink raw reply related
* [PATCH 3/3] arm: at91sam9260_9g20: refresh configuration
From: Alexandre Belloni @ 2014-02-11 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392147841-7815-1-git-send-email-alexandre.belloni@free-electrons.com>
Select CONFIG_EMBEDDED as it it useful for that board.
Also select CONFIG_MTD_UBI to really enable UBIfs (CONFIG_FS_UBIFS depends on
it).
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
---
arch/arm/configs/at91sam9260_9g20_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/at91sam9260_9g20_defconfig b/arch/arm/configs/at91sam9260_9g20_defconfig
index 2c879bc29f86..9d35cb2ddceb 100644
--- a/arch/arm/configs/at91sam9260_9g20_defconfig
+++ b/arch/arm/configs/at91sam9260_9g20_defconfig
@@ -3,6 +3,7 @@
CONFIG_SYSVIPC=y
CONFIG_LOG_BUF_SHIFT=14
CONFIG_BLK_DEV_INITRD=y
+CONFIG_EMBEDDED=y
CONFIG_SLAB=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
@@ -60,6 +61,7 @@ CONFIG_MTD_BLOCK=y
CONFIG_MTD_DATAFLASH=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_ATMEL=y
+CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=8192
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2] ARM: asm: rename logical shift macros push pull into lspush lspull
From: Victor Kamensky @ 2014-02-11 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA3XUr3Q8tr9-CzYHq_sfbFKSjNbrYYE8_H1-9ypnXo8HgUe2A@mail.gmail.com>
On 11 February 2014 11:36, Victor Kamensky <victor.kamensky@linaro.org> wrote:
> On 11 February 2014 09:58, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> On Tue, 11 Feb 2014, Dave Martin wrote:
>>
>>> On Tue, Feb 11, 2014 at 12:09:35PM -0500, Nicolas Pitre wrote:
>>> > On Tue, 11 Feb 2014, Dave Martin wrote:
>>> >
>>> > > On Mon, Feb 10, 2014 at 04:30:01PM -0500, Nicolas Pitre wrote:
>>> > > > On Mon, 10 Feb 2014, Victor Kamensky wrote:
>>> > > >
>>> > > > > Renames logical shift macros, 'push' and 'pull', defined in
>>> > > > > arch/arm/include/asm/assembler.h, into 'lspush' and 'lspull'.
>>> > > >
>>> > > > I don't have any fundamental objection to the idea, except maybe for the
>>> > > > actual names. I just can't come up with anything better though.
>>> > >
>>> > > For consistency with the get_byte_ stuff, how about:
>>> > >
>>> > > push -> towards_byte_0
>>> > > pull -> from_byte_0
>>> > >
>>> > > That may make the purpose a little clearer, too.
>>> >
>>> > I don't know if
>>> >
>>> > mov r0, r1, from_byte_0 #8
>>> >
>>> > is that much clearer though.
>>> >
>>> > > (Assuming I've got them the right way around...)
>>> >
>>> > As you later noticed you got it wrong. :-)
>>> > Most likely because "full from" and "push towards" are common english
>>> > constructs.
>>>
>>> No more so than "pull towards" and "push from".
>>
>> OK. I'll trust you on that account.
>>
>>> I'll blame it on the fact that the get_byte_ macros have wrong-
>>> endian numbering, which I didn't look at carefully enough ;)
>>>
>>> But I think we proved that my suggestion didn't really make things
>>> easier to understand...
>>
>> What about:
>>
>> push -> next
>> pull -> prev
>>
>> ?
>>
>> That would make:
>>
>> mov r0, r1, next #8
>
> I am not native English speaker, so subtle details of your
> discussion go above my head :). For me those tokens
> were just symbols with specific meaning of logical shifts
> and selected endianness. I'll do as you decide. Quick
> grep over .S files under arch/arm seems 'next' and 'prev'
> will be OK and I did build that confirms that.
Forgot to mention one detail. There is a case in
./nwfpe/entry.S file where 'next' is used as label name. I guess,
it should work if macro would rename it into lsl or lsr label
name. And/or we could rename the label.
Wondering ... whether idea to have those macros
name in way that coincides with English words would lead
us to some conflict earlier or latter. With this respect lspull
and lspush IMHO are somewhat better because they are
sort of abbreviations.
Thanks,
Victor
> One nit/question though: there are some cases where
> 'push' and 'pull' macros were used in macros and macro
> parameters were also called 'push' and 'pull'. I.e something
> like this:
>
> mov r3, lr, pull #\pull
>
> with rename 'pull' to 'lspull' I did not bother to rename
> macro parameters because they are separate, have
> just local context and 'lspull' is close to 'pull'. Resulting
> proposed diff was:
> - mov r3, lr, pull #\pull
> + mov r3, lr, lspull #\pull
>
> I assume that if we change 'push -> next' and 'pull -> prev' I
> will need to rename macro parameters in the same way.
> So it will be:
> + mov r3, lr, prev #\prev
> Is it correct?
>
> Thanks,
> Victor
>
>>
>> Nicolas
^ permalink raw reply
* [PATCH v2 1/5] drivers: of: add initialization code for reserved memory
From: Benjamin Herrenschmidt @ 2014-02-11 20:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140211190104.7E6C5C4140E@trevor.secretlab.ca>
On Tue, 2014-02-11 at 19:01 +0000, Grant Likely wrote:
> > except that the former IMHO better suits the definition of memory
> > region, which I see as a single contiguous range of memory and can be
> > simplified to have a single reg entry per region.
>
> My point is rather if multiple reg tuples are found in a reserved memory
> node, the kernel must respect them and reserve the memory. I'm not
> arguing about whether or not that makes for a good binding.
agreed.
Cheers,
Ben.
^ permalink raw reply
* [PATCH v2 1/5] drivers: of: add initialization code for reserved memory
From: Tomasz Figa @ 2014-02-11 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1392148971.3835.15.camel@pasglop>
On 11.02.2014 21:02, Benjamin Herrenschmidt wrote:
> On Tue, 2014-02-11 at 19:01 +0000, Grant Likely wrote:
>
>>> except that the former IMHO better suits the definition of memory
>>> region, which I see as a single contiguous range of memory and can be
>>> simplified to have a single reg entry per region.
>>
>> My point is rather if multiple reg tuples are found in a reserved memory
>> node, the kernel must respect them and reserve the memory. I'm not
>> arguing about whether or not that makes for a good binding.
>
> agreed.
My point is why, if the binding defines that just a single tuple should
be provided.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH] ARM: dts: omap3-n9 family: mark proper OMAP version
From: Nishanth Menon @ 2014-02-11 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140211185136.GG573@drone.musicnaut.iki.fi>
Aaro,
On 02/11/2014 12:51 PM, Aaro Koskinen wrote:
> Hi,
>
> On Tue, Feb 11, 2014 at 09:29:01AM -0600, Nishanth Menon wrote:
>> Nokia N900 uses OMAP3430 and N9/N950 uses OMAP3630. Mark SoC compatibilty
>> as per Documentation/devicetree/bindings/arm/omap/omap.txt else
>> N9/N950 will be probed as a OMAP3430 type device, since default ti,omap3
>> maps to OMAP3430 compatibility.
>
> I already sent & tested patches for this:
>
> http://marc.info/?l=linux-omap&m=139194800711362&w=2
> http://marc.info/?l=linux-omap&m=139194800011360&w=2
>
> The N9/N950 is mandatory for 3.14, as the boot hangs without it.
Thanks. Apologies on missing these, I caught these based on a git grep
on an unrelated thing.. I will ack your patches - they are obvious
regressions.
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 1/2] ARM: dts: N9/N950: fix boot hang with 3.14-rc1
From: Nishanth Menon @ 2014-02-11 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391947956-24462-1-git-send-email-aaro.koskinen@iki.fi>
On 02/09/2014 06:12 AM, Aaro Koskinen wrote:
> N9/N950 does not boot anymore with 3.14-rc1, because SoC compatible
> property is missing. Fix that.
>
> Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Reviewed-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/boot/dts/omap3-n9.dts | 2 +-
> arch/arm/boot/dts/omap3-n950.dts | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
> index 39828ce464ee..9938b5dc1909 100644
> --- a/arch/arm/boot/dts/omap3-n9.dts
> +++ b/arch/arm/boot/dts/omap3-n9.dts
> @@ -14,5 +14,5 @@
>
> / {
> model = "Nokia N9";
> - compatible = "nokia,omap3-n9", "ti,omap3";
> + compatible = "nokia,omap3-n9", "ti,omap36xx", "ti,omap3";
> };
> diff --git a/arch/arm/boot/dts/omap3-n950.dts b/arch/arm/boot/dts/omap3-n950.dts
> index b076a526b999..261c5589bfa3 100644
> --- a/arch/arm/boot/dts/omap3-n950.dts
> +++ b/arch/arm/boot/dts/omap3-n950.dts
> @@ -14,5 +14,5 @@
>
> / {
> model = "Nokia N950";
> - compatible = "nokia,omap3-n950", "ti,omap3";
> + compatible = "nokia,omap3-n950", "ti,omap36xx", "ti,omap3";
> };
>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 2/2] ARM: dts: N900: add missing compatible property
From: Nishanth Menon @ 2014-02-11 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391947956-24462-2-git-send-email-aaro.koskinen@iki.fi>
On 02/09/2014 06:12 AM, Aaro Koskinen wrote:
> Add missing compatible property to avoid problems in the future.
>
> Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Reviewed-by: Nishanth Menon <nm@ti.com>
> ---
> arch/arm/boot/dts/omap3-n900.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
> index 6fc85f963530..0bf40c90faba 100644
> --- a/arch/arm/boot/dts/omap3-n900.dts
> +++ b/arch/arm/boot/dts/omap3-n900.dts
> @@ -1,6 +1,6 @@
> /*
> * Copyright (C) 2013 Pavel Machek <pavel@ucw.cz>
> - * Copyright 2013 Aaro Koskinen <aaro.koskinen@iki.fi>
> + * Copyright (C) 2013-2014 Aaro Koskinen <aaro.koskinen@iki.fi>
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 (or later) as
> @@ -13,7 +13,7 @@
>
> / {
> model = "Nokia N900";
> - compatible = "nokia,omap3-n900", "ti,omap3";
> + compatible = "nokia,omap3-n900", "ti,omap3430", "ti,omap3";
>
> cpus {
> cpu at 0 {
>
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] ARM: tegra: dalmore: fix irq trigger type
From: Stefan Agner @ 2014-02-11 20:11 UTC (permalink / raw)
To: linux-arm-kernel
Trigger type needs to be IRQ_TYPE_LEVEL_HIGH since the interrupt
signal gets inverted by the PMC (configured by the invert-interrupt
property).
Signed-off-by: Stefan Agner <stefan@agner.ch>
---
I could not test that patch since I don't have such hardware.
However, I stumbled on that error while tracing a similar error
on Colibri T30.
arch/arm/boot/dts/tegra114-dalmore.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts b/arch/arm/boot/dts/tegra114-dalmore.dts
index 73aecfb..f5025fc 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -888,8 +888,9 @@
palmas: tps65913 at 58 {
compatible = "ti,palmas";
reg = <0x58>;
- interrupts = <0 86 IRQ_TYPE_LEVEL_LOW>;
+ /* active-low configured by PMC invert-interrupt */
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
#interrupt-cells = <2>;
interrupt-controller;
--
1.8.5.4
^ permalink raw reply related
* [PATCH v2 11/11] watchdog: xilinx: Remove no_timeout variable
From: Guenter Roeck @ 2014-02-11 20:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52d86e3f2b957411deafbdfbd4bf93bb78f491ac.1392101734.git.michal.simek@xilinx.com>
On Tue, Feb 11, 2014 at 07:55:54AM +0100, Michal Simek wrote:
> Remove no_timeout variable and check variables
> directly.
>
> Suggested-by: Rob Herring <robherring2@gmail.com>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* [PATCH v2 1/5] drivers: of: add initialization code for reserved memory
From: Josh Cartwright @ 2014-02-11 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52FA8245.5050707@gmail.com>
On Tue, Feb 11, 2014 at 09:04:21PM +0100, Tomasz Figa wrote:
>
>
> On 11.02.2014 21:02, Benjamin Herrenschmidt wrote:
> >On Tue, 2014-02-11 at 19:01 +0000, Grant Likely wrote:
> >
> >>>except that the former IMHO better suits the definition of memory
> >>>region, which I see as a single contiguous range of memory and can be
> >>>simplified to have a single reg entry per region.
> >>
> >>My point is rather if multiple reg tuples are found in a reserved memory
> >>node, the kernel must respect them and reserve the memory. I'm not
> >>arguing about whether or not that makes for a good binding.
> >
> >agreed.
>
> My point is why, if the binding defines that just a single tuple should be
> provided.
FWIW, the usecase I had mentioned in reply to Grant in the patch 5/5
thread [1] could make use of this. The shared memory region is split
into a main chunk and several "auxiliary" chunk, but collectively these
regions all share the same heap state.
Josh
1: http://lkml.kernel.org/r/20140205192502.GO20228 at joshc.qualcomm.com
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v2 07/11] watchdog: xilinx: Use of_property_read_u32
From: Guenter Roeck @ 2014-02-11 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7aa6e41032ebad0ffb2e1df20beb4f00e38d29e2.1392101734.git.michal.simek@xilinx.com>
On Tue, Feb 11, 2014 at 07:55:50AM +0100, Michal Simek wrote:
> Use of_property_read_u32 functions to clean probe function.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
[ ... ]
> +
> + if (enable_once)
> watchdog_set_nowayout(xilinx_wdt_wdd, true);
> - }
watchdog_set_nowayout(xilinx_wdt_wdd, enable_once);
would probably do as well (the function checks the flag as well).
Nitpick, so
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
^ permalink raw reply
* [PATCH] hwrng: msm: switch Kconfig to ARCH_QCOM depends
From: Kumar Gala @ 2014-02-11 20:21 UTC (permalink / raw)
To: linux-arm-kernel
This is the splits the Qualcomm MSM platform into legacy support that we will
not try and convert to multiplatform and multiplatform support.
- k
Changes from v2:
* Dropped ARCH_MSM depends from CLKSRC_QCOM, since we select it
* Fixed some grammar/typo's in commit messages
* kept smp ops code in platsmp.c to match what other mach's do
* Kept mach-qcom/Kconfig sorted alphabetically
Changes from v1:
* Added patch to remove hotplug.c
* Added patch to rename msm_ to qcom_
* Changes the Kconfig to drop CPU_V7
* used wfi() in cpu_die function
* Added git tree to MAINTAINERS file
Kumar Gala (5):
We've split Qualcomm MSM support into legacy and multiplatform. The RNG
driver is only relevant on the multiplatform supported SoCs so switch the
Kconfig depends to ARCH_QCOM.
CC: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
---
drivers/char/hw_random/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 2f2b084..289bd3a 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -343,7 +343,7 @@ config HW_RANDOM_TPM
config HW_RANDOM_MSM
tristate "Qualcomm MSM Random Number Generator support"
- depends on HW_RANDOM && ARCH_MSM
+ depends on HW_RANDOM && ARCH_QCOM
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on Qualcomm MSM SoCs.
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH] drm/msm: drop ARCH_MSM Kconfig depend
From: Kumar Gala @ 2014-02-11 20:21 UTC (permalink / raw)
To: linux-arm-kernel
The ARCH_MSM depend is redundant with ARCH_MSM8960, so we can remove it.
Additionally, we are splitting Qualcomm MSM support into legacy (ARCH_MSM)
and multiplatform (ARCH_QCOM). The MSM8960 with be ARCH_QCOM going forward
so dropping ARCH_MSM will work properly for the new ARCH_QCOM multiplatform
build.
Signed-off-by: Kumar Gala <galak@codeaurora.org>
---
David/Rob,
If you can ack this I'll send it via linux-qcom/arm-soc tree's
thanks
- k
drivers/gpu/drm/msm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index c69d1e0..b698497 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -3,7 +3,7 @@ config DRM_MSM
tristate "MSM DRM"
depends on DRM
depends on MSM_IOMMU
- depends on (ARCH_MSM && ARCH_MSM8960) || (ARM && COMPILE_TEST)
+ depends on ARCH_MSM8960 || (ARM && COMPILE_TEST)
select DRM_KMS_HELPER
select SHMEM
select TMPFS
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH] power: reset: msm - switch Kconfig to ARCH_QCOM depends
From: Kumar Gala @ 2014-02-11 20:22 UTC (permalink / raw)
To: linux-arm-kernel
We've split Qualcomm MSM support into legacy and multiplatform. The reset
driver is only relevant on the multiplatform supported SoCs so switch the
Kconfig depends to ARCH_QCOM.
Signed-off-by: Kumar Gala <galak@codeaurora.org>
---
Dmitry, David,
If you can ack this I'll send it via linux-qcom/arm-soc tree's
thanks
- k
drivers/power/reset/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 6d452a7..fa0e4e0 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -22,7 +22,7 @@ config POWER_RESET_GPIO
config POWER_RESET_MSM
bool "Qualcomm MSM power-off driver"
- depends on POWER_RESET && ARCH_MSM
+ depends on POWER_RESET && ARCH_QCOM
help
Power off and restart support for Qualcomm boards.
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH] gpio: msm: switch Kconfig to ARCH_QCOM depends
From: Kumar Gala @ 2014-02-11 20:22 UTC (permalink / raw)
To: linux-arm-kernel
We've split Qualcomm MSM support into legacy and multiplatform. The gpio
msm-v2 driver is only relevant on the multiplatform supported SoCs so
switch the Kconfig depends to ARCH_QCOM.
CC: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kumar Gala <galak@codeaurora.org>
---
Linus,
If you can ack this I'll send it via linux-qcom/arm-soc tree's
thanks
- k
drivers/gpio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 6973387..aa74949 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -192,7 +192,7 @@ config GPIO_MSM_V1
config GPIO_MSM_V2
tristate "Qualcomm MSM GPIO v2"
- depends on GPIOLIB && OF && ARCH_MSM
+ depends on GPIOLIB && OF && ARCH_QCOM
help
Say yes here to support the GPIO interface on ARM v7 based
Qualcomm MSM chips. Most of the pins on the MSM can be
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH v2 1/5] drivers: of: add initialization code for reserved memory
From: Tomasz Figa @ 2014-02-11 20:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140211201933.GI841@joshc.qualcomm.com>
On 11.02.2014 21:19, Josh Cartwright wrote:
> On Tue, Feb 11, 2014 at 09:04:21PM +0100, Tomasz Figa wrote:
>>
>>
>> On 11.02.2014 21:02, Benjamin Herrenschmidt wrote:
>>> On Tue, 2014-02-11 at 19:01 +0000, Grant Likely wrote:
>>>
>>>>> except that the former IMHO better suits the definition of memory
>>>>> region, which I see as a single contiguous range of memory and can be
>>>>> simplified to have a single reg entry per region.
>>>>
>>>> My point is rather if multiple reg tuples are found in a reserved memory
>>>> node, the kernel must respect them and reserve the memory. I'm not
>>>> arguing about whether or not that makes for a good binding.
>>>
>>> agreed.
>>
>> My point is why, if the binding defines that just a single tuple should be
>> provided.
>
> FWIW, the usecase I had mentioned in reply to Grant in the patch 5/5
> thread [1] could make use of this. The shared memory region is split
> into a main chunk and several "auxiliary" chunk, but collectively these
> regions all share the same heap state.
>
> Josh
>
> 1: http://lkml.kernel.org/r/20140205192502.GO20228 at joshc.qualcomm.com
>
The use case seems fine, but I believe it could be properly represented
in device tree using multiple single-reg regions as well, unless the
consumer can request a block of memory that crosses boundary of two
sub-regions specified by reg entries of single region.
Best regards,
Tomasz
^ permalink raw reply
* [PATCH v2] ARM: asm: rename logical shift macros push pull into lspush lspull
From: Nicolas Pitre @ 2014-02-11 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA3XUr3rhbooaTjDwhXVgWxnKV3-1fFNHGVTGsyAjpJrbxiQRQ@mail.gmail.com>
On Tue, 11 Feb 2014, Victor Kamensky wrote:
> On 11 February 2014 11:36, Victor Kamensky <victor.kamensky@linaro.org> wrote:
> > On 11 February 2014 09:58, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >> On Tue, 11 Feb 2014, Dave Martin wrote:
> >>
> >>> On Tue, Feb 11, 2014 at 12:09:35PM -0500, Nicolas Pitre wrote:
> >>> > On Tue, 11 Feb 2014, Dave Martin wrote:
> >>> >
> >>> > > On Mon, Feb 10, 2014 at 04:30:01PM -0500, Nicolas Pitre wrote:
> >>> > > > On Mon, 10 Feb 2014, Victor Kamensky wrote:
> >>> > > >
> >>> > > > > Renames logical shift macros, 'push' and 'pull', defined in
> >>> > > > > arch/arm/include/asm/assembler.h, into 'lspush' and 'lspull'.
> >>> > > >
> >>> > > > I don't have any fundamental objection to the idea, except maybe for the
> >>> > > > actual names. I just can't come up with anything better though.
> >>> > >
> >>> > > For consistency with the get_byte_ stuff, how about:
> >>> > >
> >>> > > push -> towards_byte_0
> >>> > > pull -> from_byte_0
> >>> > >
> >>> > > That may make the purpose a little clearer, too.
> >>> >
> >>> > I don't know if
> >>> >
> >>> > mov r0, r1, from_byte_0 #8
> >>> >
> >>> > is that much clearer though.
> >>> >
> >>> > > (Assuming I've got them the right way around...)
> >>> >
> >>> > As you later noticed you got it wrong. :-)
> >>> > Most likely because "full from" and "push towards" are common english
> >>> > constructs.
> >>>
> >>> No more so than "pull towards" and "push from".
> >>
> >> OK. I'll trust you on that account.
> >>
> >>> I'll blame it on the fact that the get_byte_ macros have wrong-
> >>> endian numbering, which I didn't look at carefully enough ;)
> >>>
> >>> But I think we proved that my suggestion didn't really make things
> >>> easier to understand...
> >>
> >> What about:
> >>
> >> push -> next
> >> pull -> prev
> >>
> >> ?
> >>
> >> That would make:
> >>
> >> mov r0, r1, next #8
> >
> > I am not native English speaker, so subtle details of your
> > discussion go above my head :). For me those tokens
> > were just symbols with specific meaning of logical shifts
> > and selected endianness. I'll do as you decide. Quick
> > grep over .S files under arch/arm seems 'next' and 'prev'
> > will be OK and I did build that confirms that.
>
> Forgot to mention one detail. There is a case in
> ./nwfpe/entry.S file where 'next' is used as label name. I guess,
> it should work if macro would rename it into lsl or lsr label
> name. And/or we could rename the label.
>
> Wondering ... whether idea to have those macros
> name in way that coincides with English words would lead
> us to some conflict earlier or latter. With this respect lspull
> and lspush IMHO are somewhat better because they are
> sort of abbreviations.
Agreed. I think it was worth exploring different alternatives, but
nothing really better came out.
Nicolas
^ 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