* [PATCH] ARM: vexpress: initial device tree support
From: Rob Herring @ 2011-09-21 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316596786-2539-1-git-send-email-dave.martin@linaro.org>
Dave,
On 09/21/2011 04:19 AM, Dave Martin wrote:
> This patch implements initial support for booting using a flattened
> device tree on the Versatile Express platform.
>
> Eventually, it should be possible to present a single, core-tile-
> independent board, but in this transitional patch the baseboard +
> Cortex-A9x4 core tile combination is the only directly supported
> platform, since the implementation is not yet fully generic.
>
> For now, clocks and timers are not handled via the device tree.
> Implementation of these can follow in later patches.
>
> Thanks to Lorenzo Pieralisi, Grant Likely and Pawe? Moll for their
> help and contributions.
>
> Signed-off-by: Dave Martin <dave.martin@linaro.org>
> Acked-by: Pawe? Moll <Pawel.Moll@arm.com>
> ---
>
> There are some outstanding issues which need to be discussed, listed
> below.
>
> * This patch is not currently based on the GIC bindings being
> discussed by Rob Herring et al. Once that discussion reaches a
> conclusion, it should be straightforward to rebase onto the result.
>
> * The following added bindings are not present upstream and need
> documentation / discussion:
>
> * arm,vexpress -- the global board binding for all platform
> combinations using the Versatile Express motherboard.
>
> * arm,vexpress-v2p-ca9 -- the specific binding for the Versatile
> Express motherboard with Cortex-A9x4 core tile installed. It
> is only mentioned as the most-specific match in vexpress-v2p-
> ca9.dts
>
> Since it's intended that the motherboard code should be fully
> generic, and because no other core tiles are upstream yet,
> perhaps we can get rid of this binding right away.
>
> * edid -- It should be possible to have a fairly generic binding
> for EDID interfaces, but none seems to exist yet. Discussion
> is needed regarding what form this should take.
>
> This might more appropriately be called "ddc" (or some
> variation on that), since EDID seems only to describe the
> format of the ID data retrievable via this interface; not the
> interface itself.
>
> * arm,vexpress-flash -- Needed because of the requirement to
> provide the physmap_flash driver with a special .set_vpp
> handler.
>
> * idt,89hpes32h8 -- This is the IDT 89HPES32H8 PCI express
> interconnect switch. This isn't needed for the Versatile
> Express to work, but would be needed if using PCI-e peripherals
> for real. I expect that more driver support needs to go
> upstream before this is actually usable.
>
> * nxp,isp1761 -- The driver support for this is already upstream
> (with some minor issues for ARM support).
>
> * arm,amba-bus -- widely used by other boards and patchsets, but
> seems not to be documented.
>
This should be dropped. There's not really any bus component to an amba
bus. All the probing info is within the primecell peripherals.
> * The following bindings for ARM primecell peripherals are used
> elsewhere but not documented. They should be pretty simple and
> uncontraversial.
> * arm,pl031
> * arm,pl041
> * arm,pl050
> * arm,pl180
> * arm,sp805
>
Plus pl011, pl010, sp804, pl022, pl061
> Rob Herring suggested documenting simple bindings for these
> (and others) along with his initial amba device tree probe
> patches, but these bindings don't seem to be documented
> upstream for now.
>
pl330 went the other route with a file for itself. That may be better to
avoid conflicts. But yes, ARM should document all their peripherals. ;)
I'll do the ones on highbank if you want to do the rest on VExp.
>
> * Shawn Guo's smsc911x patch is needed for Ethernet to work. This is
> headed upstream but not yet in mainline. It is available in -next.
>
> * Minor patches are needed to the isp1760 and pata_generic drivers,
> to allow OF-based initialisation across a wider group of
> architectures. These are being discussed independently, but are
> not yet accepted for merging upstream.
>
> * Most core-tile peripherals are currently not described in the core-
> tile device tree fragment. This is a lower-priority issue since
> the motherboard code already autodetects the core-tile (though only
> one core-tile is fully upstream at the moment).
>
> * Static peripheral mappings are not yet handled in a generic way in
> the board support code. This is a prerequisite for supporting
> multiple core-tiles int the same kernel. It well need to get fixed
> later, when extra core tile support is merged (or before).
>
> Pawe? Moll is looking into this separately.
>
> * The Kconfig logic for ensuring that at least one boot protocol and
> at least one core tile are selected is a bit ugly. Suggestions for
> improving this are certainly welcome.
>
> arch/arm/Kconfig | 1 +
> arch/arm/boot/dts/vexpress-v2m-legacy.dtsi | 163 ++++++++++++++++++++++++++++
> arch/arm/boot/dts/vexpress-v2p-ca9.dts | 80 ++++++++++++++
> arch/arm/configs/vexpress_defconfig | 1 +
> arch/arm/mach-vexpress/Kconfig | 45 ++++++++-
> arch/arm/mach-vexpress/ct-ca9x4.c | 7 ++
> arch/arm/mach-vexpress/v2m.c | 54 +++++++++-
> 7 files changed, 349 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/boot/dts/vexpress-v2m-legacy.dtsi
> create mode 100644 arch/arm/boot/dts/vexpress-v2p-ca9.dts
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 5ebc5d9..a6e90d5 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -282,6 +282,7 @@ config ARCH_VERSATILE
>
> config ARCH_VEXPRESS
> bool "ARM Ltd. Versatile Express family"
> + select ARCH_VEXPRESS_SANE_CONFIG
> select ARCH_WANT_OPTIONAL_GPIOLIB
> select ARM_AMBA
> select ARM_TIMER_SP804
> diff --git a/arch/arm/boot/dts/vexpress-v2m-legacy.dtsi b/arch/arm/boot/dts/vexpress-v2m-legacy.dtsi
> new file mode 100644
> index 0000000..fd6e4e4
> --- /dev/null
> +++ b/arch/arm/boot/dts/vexpress-v2m-legacy.dtsi
> @@ -0,0 +1,163 @@
> +// ARM Ltd. Versatile Express Motherboard V2M-P1 (HBI-0190D)
> +// Legacy memory map
Not sure, but C++ style comments are probably frowned upon in dts too.
> +
> +/ {
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + serial2 = &uart2;
> + serial3 = &uart3;
> + i2c0 = &i2c0;
> + i2c1 = &i2c1;
> + };
> +
> + motherboard {
> + compatible = "simple-bus";
> + #address-cells = <2>; // SMB chipselect number and offset
> + #size-cells = <1>;
> + #interrupt-cells = <1>;
> +
> + flash at 0,00000000 {
> + compatible = "arm,vexpress-flash", "cfi-flash";
> + reg = <0 0x00000000 0x04000000
> + 1 0x00000000 0x04000000>;
> + bank-width = <4>;
> + };
> +
> + psram at 2,00000000 {
> + compatible = "mtd-ram";
> + reg = <2 0x00000000 0x02000000>;
> + bank-width = <4>;
> + };
> +
> + ethernet at 3,02000000 {
> + compatible = "smsc,lan9118", "smsc,lan9115";
> + reg = <3 0x02000000 0x10000>;
> + reg-io-width = <4>;
> + interrupts = <15>;
> + smsc,irq-active-high;
> + smsc,irq-push-pull;
> + };
> +
> + usb at 3,03000000 {
> + compatible = "nxp,usb-isp1761";
> + reg = <3 0x03000000 0x20000>;
> + interrupts = <16>;
> + port1-otg;
> + };
> +
> + peripherals at 7,00000000 {
> + compatible = "arm,amba-bus", "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 7 0 0x20000>;
> +
> + // PCI-E I2C bus
> + i2c0: i2c at 02000 {
> + compatible = "arm,versatile-i2c";
> + reg = <0x02000 0x1000>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pcie-switch at 60 {
> + compatible = "idt,89hpes32h8";
> + reg = <0x60>;
> + };
> + };
> +
> + aaci at 04000 {
> + compatible = "arm,pl041", "arm,primecell";
> + reg = <0x04000 0x1000>;
> + interrupts = <11>;
> + };
> +
> + mmci at 05000 {
> + compatible = "arm,pl180", "arm,primecell";
> + reg = <0x05000 0x1000>;
> + interrupts = <9 10>;
> + };
> +
> + kmi at 06000 {
> + compatible = "arm,pl050", "arm,primecell";
> + reg = <0x06000 0x1000>;
> + interrupts = <12>;
> + };
> +
> + kmi at 07000 {
> + compatible = "arm,pl050", "arm,primecell";
> + reg = <0x07000 0x1000>;
> + interrupts = <13>;
> + };
> +
> + uart0: uart at 09000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x09000 0x1000>;
> + interrupts = <5>;
> + };
> +
> + uart1: uart at 0a000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0a000 0x1000>;
> + interrupts = <6>;
> + };
> +
> + uart2: uart at 0b000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0b000 0x1000>;
> + interrupts = <7>;
> + };
> +
> + uart3: uart at 0c000 {
> + compatible = "arm,pl011", "arm,primecell";
> + reg = <0x0c000 0x1000>;
> + interrupts = <8>;
> + };
> +
> + wdt at 0f000 {
> + compatible = "arm,sp805", "arm,primecell";
> + reg = <0x0f000 0x1000>;
> + interrupts = <0>;
> + };
> +
> + // Timer init is hardcoded in v2m_timer_init(), for now.
> + // timer at 11000 {
> + // compatible = "arm,arm-sp804";
arm,sp804 is more consistent. I believe the sp804 does have the periphid
registers, so arm,primecell should also be added.
> + // reg = <0x11000 0x1000>;
> + // interrupts = <2>;
> + // };
> +
> + // timer at 12000 {
> + // compatible = "arm,arm-sp804";
> + // reg = <0x12000 0x1000>;
> + // };
Just because Linux is not using it, doesn't mean you should comment it out.
> +
> + // DVI I2C bus (DDC)
> + i2c1: i2c at 16000 {
> + compatible = "arm,versatile-i2c";
> + reg = <0x16000 0x1000>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + edid at 50 {
> + compatible = "edid";
> + reg = <0x50>;
> + };
> + };
> +
> + rtc at 17000 {
> + compatible = "arm,pl031", "arm,primecell";
> + reg = <0x017000 0x1000>;
> + interrupts = <4>;
> + };
> +
> + compact-flash at 1a000 {
> + compatible = "ata-generic";
> + reg = <0x1a000 0x100
> + 0x1a100 0xf00>;
> + reg-shift = <2>;
> + };
> + };
> + };
> +};
> diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> new file mode 100644
> index 0000000..059be97
> --- /dev/null
> +++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts
> @@ -0,0 +1,80 @@
> +// ARM Ltd. Versatile Express Corex-A9 (Quad Core) Core Tile V2P-CA9 (HBI-0191B)
> +
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + model = "ARM Versatile Express (Cortex-A9 Quad Core Tile)";
> + compatible = "arm,vexpress-v2p-ca9", "arm,vexpress";
> + interrupt-parent = <&intc>;
> +
> + memory {
> + device_type = "memory";
> + reg = <0x60000000 0x40000000>;
> + };
> +
> + intc: interrupt-controller at 1e001000 {
> + compatible = "arm,cortex-a9-gic";
> + #interrupt-cells = <2>;
> + #address-cells = <0>;
> + interrupt-controller;
> + reg = <0x1e001000 0x1000>,
> + <0x1e000100 0x100>;
> + };
Is this really all by itself? It should be in the sub-tree of the
appropriate bus.
You need an "interrupt-parent;" line so the parent is not itself.
> +
> + motherboard {
> + ranges = <0 0 0x40000000 0x04000000
> + 1 0 0x44000000 0x04000000
> + 2 0 0x48000000 0x04000000
> + 3 0 0x4c000000 0x04000000
> + 7 0 0x10000000 0x00020000>;
> +
> + interrupt-map-mask = <0 0 63>;
> + interrupt-map = <0 0 0 &intc 32 8
> + 0 0 1 &intc 33 4
> + 0 0 2 &intc 34 4
> + 0 0 3 &intc 35 4
> + 0 0 4 &intc 36 4
> + 0 0 5 &intc 37 4
> + 0 0 6 &intc 38 4
> + 0 0 7 &intc 39 4
> + 0 0 8 &intc 40 4
> + 0 0 9 &intc 41 4
> + 0 0 10 &intc 42 4
> + 0 0 11 &intc 43 4
> + 0 0 12 &intc 44 4
> + 0 0 13 &intc 45 4
> + 0 0 14 &intc 46 4
> + 0 0 15 &intc 47 4
> + 0 0 16 &intc 48 4
> + 0 0 17 &intc 49 4
> + 0 0 18 &intc 50 4
> + 0 0 19 &intc 51 4
> + 0 0 20 &intc 52 4
> + 0 0 21 &intc 53 4
> + 0 0 22 &intc 54 4
> + 0 0 23 &intc 55 4
> + 0 0 24 &intc 56 4
> + 0 0 25 &intc 57 4
> + 0 0 26 &intc 58 4
> + 0 0 27 &intc 59 4
> + 0 0 28 &intc 60 4
> + 0 0 29 &intc 61 4
> + 0 0 30 &intc 62 4
> + 0 0 31 &intc 63 4
> + 0 0 32 &intc 64 4
> + 0 0 33 &intc 65 4
> + 0 0 34 &intc 66 4
> + 0 0 35 &intc 67 4
> + 0 0 36 &intc 68 4
> + 0 0 37 &intc 69 4
> + 0 0 38 &intc 70 4
> + 0 0 39 &intc 71 4
> + 0 0 40 &intc 72 4
> + 0 0 41 &intc 73 4
> + 0 0 42 &intc 74 4>;
> + };
> +};
> +
> +/include/ "vexpress-v2m-legacy.dtsi"
> diff --git a/arch/arm/configs/vexpress_defconfig b/arch/arm/configs/vexpress_defconfig
> index f2de51f..6c3c5f6 100644
> --- a/arch/arm/configs/vexpress_defconfig
> +++ b/arch/arm/configs/vexpress_defconfig
> @@ -22,6 +22,7 @@ CONFIG_MODULE_UNLOAD=y
> # CONFIG_IOSCHED_DEADLINE is not set
> # CONFIG_IOSCHED_CFQ is not set
> CONFIG_ARCH_VEXPRESS=y
> +CONFIG_ARCH_VEXPRESS_ATAGS=y
> CONFIG_ARCH_VEXPRESS_CA9X4=y
> # CONFIG_SWP_EMULATE is not set
> CONFIG_SMP=y
> diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> index 9311484..ea64630 100644
> --- a/arch/arm/mach-vexpress/Kconfig
> +++ b/arch/arm/mach-vexpress/Kconfig
> @@ -1,12 +1,55 @@
> menu "Versatile Express platform type"
> depends on ARCH_VEXPRESS
>
> +# ARCH_VEXPRESS ensures a sane minimal config is selected by selecting
> +# ARCH_VEXPRESS_SANE_CONFIG.
> +# Extend the logic here when adding new core tiles.
> +
> +config ARCH_VEXPRESS_SANE_CONFIG
> + bool
> + select ARCH_VEXPRESS_CA9X4
> + select ARCH_VEXPRESS_ATAGS if !ARCH_VEXPRESS_DT
> +
> +
> +comment "At least one boot type must be selected"
> +
> +config ARCH_VEXPRESS_ATAGS
> + bool "Boot via ATAGs"
> + default y
> + help
> + This option enables support for the board using the standard
> + ATAGs boot protocol.
> +
> + If your bootloader supports FDT-based booting and you do not
> + intend ever to boot via the traditional ATAGs method, you can say
> + N here.
> +
> +config ARCH_VEXPRESS_DT
> + bool "Boot via Device Tree"
> + select USE_OF
> + help
> + This option enables support for the board, and enables booting
> + via a Flattened Device Tree provided by the bootloader.
> +
> + If your bootloader supports FDT-based booting, you can say Y
> + here, otherwise, say N.
> +
> +
> +# Core Tile support options
> +
> +comment "At least one core tile must be selected"
> +
> config ARCH_VEXPRESS_CA9X4
> - bool "Versatile Express Cortex-A9x4 tile"
> + bool "Versatile Express Cortex-A9x4 Core Tile"
> + default y
> select CPU_V7
> select ARM_GIC
> select ARM_ERRATA_720789
> select ARM_ERRATA_751472
> select ARM_ERRATA_753970
> + help
> + Include support for the Cortex-A9x4 Core Tile (HBI-0191B).
> +
> + If unsure, say Y.
>
> endmenu
> diff --git a/arch/arm/mach-vexpress/ct-ca9x4.c b/arch/arm/mach-vexpress/ct-ca9x4.c
> index bfd32f5..e2fe2c9 100644
> --- a/arch/arm/mach-vexpress/ct-ca9x4.c
> +++ b/arch/arm/mach-vexpress/ct-ca9x4.c
> @@ -9,6 +9,7 @@
> #include <linux/amba/bus.h>
> #include <linux/amba/clcd.h>
> #include <linux/clkdev.h>
> +#include <linux/irqdomain.h>
>
> #include <asm/hardware/arm_timer.h>
> #include <asm/hardware/cache-l2x0.h>
> @@ -59,10 +60,16 @@ static void __init ct_ca9x4_map_io(void)
> iotable_init(ct_ca9x4_io_desc, ARRAY_SIZE(ct_ca9x4_io_desc));
> }
>
> +static const struct of_device_id gic_of_match[] __initconst = {
> + { .compatible = "arm,cortex-a9-gic", },
> + {}
> +};
> +
> static void __init ct_ca9x4_init_irq(void)
> {
> gic_init(0, 29, MMIO_P2V(A9_MPCORE_GIC_DIST),
> MMIO_P2V(A9_MPCORE_GIC_CPU));
> + irq_domain_generate_simple(gic_of_match, A9_MPCORE_GIC_DIST, 0);
> }
>
> #if 0
> diff --git a/arch/arm/mach-vexpress/v2m.c b/arch/arm/mach-vexpress/v2m.c
> index 9e6b93b..6defce6 100644
> --- a/arch/arm/mach-vexpress/v2m.c
> +++ b/arch/arm/mach-vexpress/v2m.c
> @@ -6,6 +6,8 @@
> #include <linux/amba/mmci.h>
> #include <linux/io.h>
> #include <linux/init.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> #include <linux/platform_device.h>
> #include <linux/ata_platform.h>
> #include <linux/smsc911x.h>
> @@ -118,7 +120,7 @@ int v2m_cfg_read(u32 devfn, u32 *data)
> return !!(val & SYS_CFG_ERR);
> }
>
> -
> +#ifdef CONFIG_ARCH_VEXPRESS_ATAGS
> static struct resource v2m_pcie_i2c_resource = {
> .start = V2M_SERIAL_BUS_PCI,
> .end = V2M_SERIAL_BUS_PCI + SZ_4K - 1,
> @@ -200,6 +202,7 @@ static struct platform_device v2m_usb_device = {
> .num_resources = ARRAY_SIZE(v2m_usb_resources),
> .dev.platform_data = &v2m_usb_config,
> };
> +#endif /* CONFIG_ARCH_VEXPRESS_ATAGS */
>
> static void v2m_flash_set_vpp(struct platform_device *pdev, int on)
> {
> @@ -211,6 +214,7 @@ static struct physmap_flash_data v2m_flash_data = {
> .set_vpp = v2m_flash_set_vpp,
> };
>
> +#ifdef CONFIG_ARCH_VEXPRESS_ATAGS
> static struct resource v2m_flash_resources[] = {
> {
> .start = V2M_NOR0,
> @@ -254,6 +258,7 @@ static struct platform_device v2m_cf_device = {
> .num_resources = ARRAY_SIZE(v2m_pata_resources),
> .dev.platform_data = &v2m_pata_data,
> };
> +#endif /* CONFIG_ARCH_VEXPRESS_ATAGS */
>
> static unsigned int v2m_mmci_status(struct device *dev)
> {
> @@ -265,6 +270,7 @@ static struct mmci_platform_data v2m_mmci_data = {
> .status = v2m_mmci_status,
> };
>
> +#ifdef CONFIG_ARCH_VEXPRESS_ATAGS
> static AMBA_DEVICE(aaci, "mb:aaci", V2M_AACI, NULL);
> static AMBA_DEVICE(mmci, "mb:mmci", V2M_MMCI, &v2m_mmci_data);
> static AMBA_DEVICE(kmi0, "mb:kmi0", V2M_KMI0, NULL);
> @@ -288,6 +294,7 @@ static struct amba_device *v2m_amba_devs[] __initdata = {
> &wdt_device,
> &rtc_device,
> };
> +#endif /* CONFIG_ARCH_VEXPRESS_ATAGS */
>
>
> static long v2m_osc_round(struct clk *clk, unsigned long rate)
> @@ -415,6 +422,8 @@ static void __init v2m_init_irq(void)
> ct_desc->init_irq();
> }
>
> +
> +#ifdef CONFIG_ARCH_VEXPRESS_ATAGS
> static void __init v2m_init(void)
> {
> int i;
> @@ -443,3 +452,46 @@ MACHINE_START(VEXPRESS, "ARM-Versatile Express")
> .timer = &v2m_timer,
> .init_machine = v2m_init,
> MACHINE_END
> +#endif /* CONFIG_ARCH_VEXPRESS_ATAGS */
> +
> +#ifdef CONFIG_ARCH_VEXPRESS_DT
> +struct of_dev_auxdata v2m_dt_auxdata_lookup[] __initdata = {
> + OF_DEV_AUXDATA("arm,vexpress-flash", V2M_NOR0, "physmap-flash", &v2m_flash_data),
> + OF_DEV_AUXDATA("arm,primecell", V2M_AACI, "mb:aaci", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_WDT, "mb:wdt", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_MMCI, "mb:mmci", &v2m_mmci_data),
> + OF_DEV_AUXDATA("arm,primecell", V2M_KMI0, "mb:kmi0", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_KMI1, "mb:kmi1", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_UART0, "mb:uart0", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_UART1, "mb:uart1", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_UART2, "mb:uart2", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_UART3, "mb:uart3", NULL),
> + OF_DEV_AUXDATA("arm,primecell", V2M_RTC, "mb:rtc", NULL),
> + {}
> +};
> +
> +static void __init v2m_dt_init(void)
> +{
> + of_platform_populate(NULL, of_default_bus_match_table,
> + v2m_dt_auxdata_lookup, NULL);
> +
> + pm_power_off = v2m_power_off;
> + arm_pm_restart = v2m_restart;
> +
> + ct_desc->init_tile();
> +}
> +
> +static const char *v2m_dt_match[] __initconst = {
> + "arm,vexpress",
> + NULL,
> +};
> +
> +DT_MACHINE_START(VEXPRESS_DT, "ARM Versatile Express")
> + .map_io = v2m_map_io,
> + .init_early = v2m_init_early,
> + .init_irq = v2m_init_irq,
> + .timer = &v2m_timer,
> + .init_machine = v2m_dt_init,
> + .dt_compat = v2m_dt_match,
> +MACHINE_END
> +#endif /* CONFIG_ARCH_VEXPRESS_DT */
All the ifdefs are really ugly. Most people are creating new board_dt.c
file and copying over pieces they need. Once DT support is on par with
the old file, the old file can be deleted.
Rob
^ permalink raw reply
* [PATCH] arm: Add unwinding annotations for 64bit division functions
From: Dave Martin @ 2011-09-21 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110921115553.GF17169@n2100.arm.linux.org.uk>
On Wed, Sep 21, 2011 at 12:55:53PM +0100, Russell King - ARM Linux wrote:
> On Wed, Sep 21, 2011 at 12:39:09PM +0100, Dave Martin wrote:
> > Talking to Catalin a bit more, it sounds like prefetch aborts should not
> > happen in kernel code, and data aborts should not happen when accessing
> > the kernel stack.
>
> No faults should happen in kernel code, except for:
>
> 1. instructions specifically marked in the exception table, which are used
> to access user memory.
> 2. instructions causing an 'undefined instruction' exception.
>
> Standard ARM instructions like 'add', 'mov' etc should _never_ fault,
> and if they do that means your core isn't executing ARM instructions
> correctly (eg, the hardware design is faulty.)
>
> Instructions such as VFP, kprobes tracing, etc are expected fault
> locations, and those are fairly well controlled where they can be placed.
> With things like ftrace, it certainly is the case that the unwinder can
> theoretically be called from almost anywhere in a function.
>
> So I suggest that this does need to be fixed, and you can't rely on
> "prefetch aborts should not happen". That's true of prefetch aborts
> but not of other aborts.
The important thing for the unwinder is that it can't cope well with faults
happening in the save/restore sequences at function entry and exit, and
we may not cope well with functions which don't have a simple SAVE,
EXECUTE, RESTORE, RETURN structure.
My gut feeling is that neither (1) or (2) should happen in those sequences,
and VFP faults should not happen in these sequences because the kernel
should not contain VFP code except in particular controlled locations.
For things like kprobes which allow a trap to be set at a function's entry
point we do have a problem: if we try to backtrace from this point, the
backtracer will see we are in that function and will assume that the
function's state saving code has already executed. It might be simple
to work around this particular case by making the unwinder intelligent
enough to realise that if backtracing from the first instruction of a
function, none of the function's state save code can have executed yet.
^ permalink raw reply
* [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
From: Rob Clark @ 2011-09-21 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000d01cc785b$cc5cc290$651647b0$%szyprowski@samsung.com>
On Wed, Sep 21, 2011 at 7:41 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>> I'm not entirely sure what will happen w/ dma_alloc_coherent, etc, if
>> the global CMA pool is exhausted.
>>
>> Marek? ?I guess you know what would happen?
>
> The allocation will simply fail and dma_alloc_coherent will return NULL.
>
Ok, so we should probably setup device private pools so that userspace
cannot allocate so much buffer memory that dma_alloc_coherent fails
for other devices..
This is what I've done so far for omapdrm driver, although it is part
of the other patch that adds the platform-device..
Thx
BR,
-R
^ permalink raw reply
* [PATCH V2 1/3] ARM: EXYNOS4: Add TVOUT support for SMDKV310
From: Hatim R.V. @ 2011-09-21 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E79DC49.1050407@samsung.com>
Hello Tomasz Stanislawski,
On Wed, Sep 21, 2011 at 6:14 PM, Tomasz Stanislawski
<t.stanislaws@samsung.com> wrote:
> On 09/21/2011 02:06 PM, Kukjin Kim wrote:
>>
>> Hatim Ali wrote:
>>>
>>> Add support for TVOUT on SMDKV310 board.
>>>
>>> Signed-off-by: Hatim Ali<hatim.rv@samsung.com>
>>> ---
>>> Changes since V1:
>>> Incorporated changes as suggested by Tomasz Stanislawski
>>> - Added ?GPIO settings for hot-plug detection.
>>> - Added setting hdmi and mixer's parent for TV power domain.
>>>
>>> ?arch/arm/mach-exynos4/Kconfig ? ? ? ? | ? ?2 ++
>>> ?arch/arm/mach-exynos4/mach-smdkv310.c | ? 25
>>> +++++++++++++++++++++++++
>>> ?2 files changed, 27 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos4/Kconfig
>>> b/arch/arm/mach-exynos4/Kconfig
>>> index 3b594fe..0bf0fe04 100644
>>> --- a/arch/arm/mach-exynos4/Kconfig
>>> +++ b/arch/arm/mach-exynos4/Kconfig
>>> @@ -131,6 +131,7 @@ config MACH_SMDKV310
>>> ? ? ? ?select S3C_DEV_RTC
>>> ? ? ? ?select S3C_DEV_WDT
>>> ? ? ? ?select S3C_DEV_I2C1
>>> + ? ? ? select S5P_DEV_I2C_HDMIPHY
>>> ? ? ? ?select S5P_DEV_MFC
>>> ? ? ? ?select S3C_DEV_HSMMC
>>> ? ? ? ?select S3C_DEV_HSMMC1
>>> @@ -140,6 +141,7 @@ config MACH_SMDKV310
>>> ? ? ? ?select EXYNOS4_DEV_AHCI
>>> ? ? ? ?select SAMSUNG_DEV_KEYPAD
>>> ? ? ? ?select EXYNOS4_DEV_PD
>>> + ? ? ? select S5P_DEV_TV
>>> ? ? ? ?select SAMSUNG_DEV_PWM
>>> ? ? ? ?select EXYNOS4_DEV_SYSMMU
>>> ? ? ? ?select EXYNOS4_SETUP_FIMD0
>>> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
>>> exynos4/mach-smdkv310.c
>>> index 7ce4d8b..50de270 100644
>>> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
>>> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
>>> @@ -239,6 +239,7 @@ static struct platform_device *smdkv310_devices[]
>>> __initdata = {
>>> ? ? ? ?&s3c_device_hsmmc2,
>>> ? ? ? ?&s3c_device_hsmmc3,
>>> ? ? ? ?&s3c_device_i2c1,
>>> + ? ? ? &s5p_device_i2c_hdmiphy,
>>> ? ? ? ?&s3c_device_rtc,
>>> ? ? ? ?&s3c_device_wdt,
>>> ? ? ? ?&exynos4_device_ac97,
>>> @@ -262,6 +263,8 @@ static struct platform_device *smdkv310_devices[]
>>> __initdata = {
>>> ? ? ? ?&smdkv310_lcd_lte480wv,
>>> ? ? ? ?&smdkv310_smsc911x,
>>> ? ? ? ?&exynos4_device_ahci,
>>> + ? ? ? &s5p_device_hdmi,
>>> + ? ? ? &s5p_device_mixer,
>>> ?};
>>>
>>> ?static void __init smdkv310_smsc911x_init(void)
>>> @@ -298,6 +301,25 @@ static struct platform_pwm_backlight_data
>>> smdkv310_bl_data = {
>>> ? ? ? ?.pwm_period_ns ?= 1000,
>>> ?};
>>>
>>> +static void s5p_tv_setup(void)
>>> +{
>>> + ? ? ? int ret;
>>> +
>>> + ? ? ? /* direct HPD to HDMI chip */
>>> + ? ? ? ret = gpio_request(EXYNOS4_GPX3(7), "hpd-plug");
>>> +
>>> + ? ? ? if (!ret) {
>
> Maybe we should generate WARN_ON(1) here. Failure of gpio request indicate
> that
> board was configued not correctly.
Ok. will add this in my next patch.
>>>
>>> + ? ? ? ? ? ? ? gpio_direction_input(EXYNOS4_GPX3(7));
>>> + ? ? ? ? ? ? ? s3c_gpio_cfgpin_range(EXYNOS4_GPX3(7),
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1, S3C_GPIO_SFN(3));
>>
>> Why do you use 's3c_gpio_cfgpin_range()' for just one gpio pin not
>> range...?
>>
>>> + ? ? ? } else
>>> + ? ? ? ? ? ? ? pr_err("Failed to request gpio for hpd: %d\n", ret);
>>
>> According to coding style, should be added { and } around above.
>>
>>> +
>>> + ? ? ? /* setup dependencies between TV devices */
>>> + ? ? ? s5p_device_hdmi.dev.parent =&exynos4_device_pd[PD_TV].dev;
>>> + ? ? ? s5p_device_mixer.dev.parent =&exynos4_device_pd[PD_TV].dev;
>>> +}
>>> +
>>> ?static void __init smdkv310_map_io(void)
>>> ?{
>>> ? ? ? ?s5p_init_io(NULL, 0, S5P_VA_CHIPID);
>>> @@ -327,6 +349,9 @@ static void __init smdkv310_machine_init(void)
>>> ? ? ? ?samsung_bl_set(&smdkv310_bl_gpio_info,&smdkv310_bl_data);
>>> ? ? ? ?s5p_fimd0_set_platdata(&smdkv310_lcd0_pdata);
>>>
>>> + ? ? ? s5p_tv_setup();
>>> + ? ? ? s5p_i2c_hdmiphy_set_platdata(NULL);
>>> +
>>> ? ? ? ?platform_add_devices(smdkv310_devices,
>>> ARRAY_SIZE(smdkv310_devices));
>>> ? ? ? ?s5p_device_mfc.dev.parent =&exynos4_device_pd[PD_MFC].dev;
>>> ?}
>>> --
>>> 1.7.2.3
>>
>> Thanks.
>>
>> Best regards,
>> Kgene.
>> --
>> Kukjin Kim<kgene.kim@samsung.com>, Senior Engineer,
>> SW Solution Development Team, Samsung Electronics Co., Ltd.
>>
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 7/8] ARM: integrate CMA with DMA-mapping subsystem
From: Marek Szyprowski @ 2011-09-21 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMjpGUch=ogFQwBLqOukKVnyh60600jw5tMq-KYeNGSZ2PLQpA@mail.gmail.com>
Hello,
On Thursday, September 08, 2011 7:27 PM Mike Frysinger wrote:
> On Fri, Aug 19, 2011 at 10:27, Marek Szyprowski wrote:
> > arch/arm/include/asm/device.h | 3 +
> > arch/arm/include/asm/dma-contiguous.h | 33 +++
>
> seems like these would be good asm-generic/ additions rather than arm
Only some of them can be really moved to asm-generic imho. The following
lines are definitely architecture specific:
void dma_contiguous_early_fixup(phys_addr_t base, unsigned long size);
Some other archs might define empty fixup function. Right now only ARM
architecture is the real client of the CMA. IMHO if any other arch stats
using CMA, some of the CMA definitions can be then moved to asm-generic.
Right now I wanted to keep it as simple as possible.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH V2 1/3] ARM: EXYNOS4: Add TVOUT support for SMDKV310
From: Hatim R.V. @ 2011-09-21 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E79E122.2000600@samsung.com>
Hi Sylwester,
On Wed, Sep 21, 2011 at 6:35 PM, Sylwester Nawrocki
<s.nawrocki@samsung.com> wrote:
> Hi Hatim,
>
> On 09/21/2011 07:44 AM, Hatim Ali wrote:
>> Add support for TVOUT on SMDKV310 board.
>>
>> Signed-off-by: Hatim Ali <hatim.rv@samsung.com>
>> ---
> ...
>> diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-exynos4/mach-smdkv310.c
>> index 7ce4d8b..50de270 100644
>> --- a/arch/arm/mach-exynos4/mach-smdkv310.c
>> +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
>> @@ -239,6 +239,7 @@ static struct platform_device *smdkv310_devices[] __initdata = {
>> ? ? ? &s3c_device_hsmmc2,
>> ? ? ? &s3c_device_hsmmc3,
>> ? ? ? &s3c_device_i2c1,
>> + ? ? &s5p_device_i2c_hdmiphy,
>> ? ? ? &s3c_device_rtc,
>> ? ? ? &s3c_device_wdt,
>> ? ? ? &exynos4_device_ac97,
>> @@ -262,6 +263,8 @@ static struct platform_device *smdkv310_devices[] __initdata = {
>> ? ? ? &smdkv310_lcd_lte480wv,
>> ? ? ? &smdkv310_smsc911x,
>> ? ? ? &exynos4_device_ahci,
>> + ? ? &s5p_device_hdmi,
>> + ? ? &s5p_device_mixer,
>> ?};
>>
>> ?static void __init smdkv310_smsc911x_init(void)
>> @@ -298,6 +301,25 @@ static struct platform_pwm_backlight_data smdkv310_bl_data = {
>> ? ? ? .pwm_period_ns ?= 1000,
>> ?};
>>
>> +static void s5p_tv_setup(void)
>> +{
>> + ? ? int ret;
>> +
>> + ? ? /* direct HPD to HDMI chip */
>> + ? ? ret = gpio_request(EXYNOS4_GPX3(7), "hpd-plug");
>> +
>> + ? ? if (!ret) {
>> + ? ? ? ? ? ? gpio_direction_input(EXYNOS4_GPX3(7));
>
> Since you're probably going to be reworking this anyway, I think gpio_request_one
> could be used here for simplicity.
Thanks for your suggestion. Will change accordingly.
>
> --
> Regards,
> Sylwester
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [GIT PULL] omap cleanup part1 for v3.2 merge window
From: Tony Lindgren @ 2011-09-21 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2241590.uiCS2D9jjt@wuerfel>
Kevin,
* Arnd Bergmann <arnd@arndb.de> [110921 01:55]:
> On Tuesday 20 September 2011 23:46:11 Arnd Bergmann wrote:
>
> > It seems that you replace the #ifdef in the board-flash.c file
> > with a similar #ifdef in the header that replaces this with an
> > empty inline function when the object is not built.
>
> Found another similar problem over night, presumably in the voltage series:
>
> arch/arm/mach-omap2/built-in.o: In function `pwrdm_register_pwrdms':
> twl-common.c:(.text+0x5e20): undefined reference to `voltdm_lookup'
> twl-common.c:(.text+0x5e40): undefined reference to `voltdm_add_pwrdm'
> arch/arm/mach-omap2/built-in.o: In function `omap2_init_common_infrastructure':
> twl-common.c:(.init.text+0x3a4): undefined reference to `omap2xxx_voltagedomains_init'
> twl-common.c:(.init.text+0x3c8): undefined reference to `omap3xxx_voltagedomains_init'
> arch/arm/mach-omap2/built-in.o: In function `omap2_set_init_voltage':
> twl-common.c:(.init.text+0x13c8): undefined reference to `voltdm_lookup'
> arch/arm/mach-omap2/built-in.o: In function `omap3_twl_init':
> twl-common.c:(.init.text+0x1f44): undefined reference to `voltdm_lookup'
> twl-common.c:(.init.text+0x1f4c): undefined reference to `voltdm_lookup'
Can you take a look at this one?
Tony
^ permalink raw reply
* [PATCH 15/19] plat-pxa: break out GPIO driver specifics
From: Eric Miao @ 2011-09-21 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbGfhZnLaP9p27T1qbD0NVsW7Spp9ZVbR6zEGBSFU+M9g@mail.gmail.com>
On Tue, Sep 20, 2011 at 4:45 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Aug 10, 2011 at 4:38 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
>> On Wed, Aug 10, 2011 at 8:18 PM, Linus Walleij
>> <linus.walleij@stericsson.com> wrote:
>>> From: Linus Walleij <linus.walleij@linaro.org>
>>>
>>> The <mach/gpio.h> file is included from upper directories
>>> and deal with generic GPIO and gpiolib stuff. Break out the
>>> platform and driver specific defines and functions into its own
>>> header file.
>>>
>>> Cc: Eric Miao <eric.y.miao@gmail.com>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> I think there is better way around this, am working on it with several
>> patches already, will release soon.
>
> Anything happening on this front or shall I update this patch set?
Hi Linus,
Several cleanup patches in my local tree but I didn't manage to find
time to finish the series. Please go ahead update the patch set. We
can fix the problems later.
Haojian,
Could you help on generalize the GPIO support code for PXA? Generally,
the goals are:
1. independent of <mach/gpio.h>, i.e. no #include <mach/gpio.h> so
to support multiple sub-arch in a single kernel, that's to say - possible
to build a single kernel supporting both mach-pxa/ and mach-mmp/
2. as a result of 1), independent of <plat/gpio.h>
Thanks
- eric
>
> Yours,
> Linus Walleij
>
^ permalink raw reply
* [PATCH 2/8] mm: alloc_contig_freed_pages() added
From: Dave Hansen @ 2011-09-21 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <op.v15tv0183l0zgt@mnazarewicz-glaptop>
On Wed, 2011-09-21 at 15:17 +0200, Michal Nazarewicz wrote:
> > This 'struct page *'++ stuff is OK, but only for small, aligned areas.
> > For at least some of the sparsemem modes (non-VMEMMAP), you could walk
> > off of the end of the section_mem_map[] when you cross a MAX_ORDER
> > boundary. I'd feel a little bit more comfortable if pfn_to_page() was
> > being done each time, or only occasionally when you cross a section
> > boundary.
>
> I'm fine with that. I've used pointer arithmetic for performance reasons
> but if that may potentially lead to bugs then obviously pfn_to_page()
> should be used
pfn_to_page() on x86 these days is usually:
#define __pfn_to_page(pfn) (vmemmap + (pfn))
Even for the non-vmemmap sparsemem it stays pretty quick because the
section array is in cache as you run through the loop.
There are ways to _minimize_ the number of pfn_to_page() calls by
checking when you cross a section boundary, or even at a
MAX_ORDER_NR_PAGES boundary. But, I don't think it's worth the trouble.
-- Dave
^ permalink raw reply
* [PATCH 00/10] hwspinlock-next
From: Arnd Bergmann @ 2011-09-21 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110920231340.GT18894@atomide.com>
On Wednesday 21 September 2011, Tony Lindgren wrote:
> * Ohad Ben-Cohen <ohad@wizery.com> [110920 01:34]:
> > On Mon, Sep 12, 2011 at 7:46 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> >
> > I'm wondering how hwspinlock updates like this should go upstream.
> >
> > The first hwspinlock batch was picked by Tony, because it involved a
> > bulk of OMAP changes.
> >
> > Hwspinlock isn't OMAP-specific anymore though (we gained support for
> > STE's u8500) and the vast majority of changes are in drivers/. We're
> > still very much ARM-related, though this may change too at some point
> > (c6x has a similar "hardware semaphore" peripheral like the u8500
> > does).
> >
> > Tony, if you're still willing to pick up these updates I'd be happy to
> > send you pull requests of course.
>
> I'd prefer for Greg to take these as these are drivers.
>
> If he's not taking it at this point based on it being ARM only,
> I can take it then.
Sorry for replying late, I had accidentally ignored the entire thread.
My feeling is that it would be best for Ohad to send these directly
to Linus, since it's basically a standalone subsystem and he's listed
as the maintainer (well, after this series at least).
I'm also fine with any of the other paths like
ohad->GregKH->torvalds
ohad->arnd->torvalds
ohad->tmlind->torvalds
ohad->tmlind->arnd->torvalds
Arnd
^ permalink raw reply
* [PATCH] ARM: vexpress: initial device tree support
From: Dave Martin @ 2011-09-21 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E79E588.6010703@gmail.com>
On Wed, Sep 21, 2011 at 08:24:24AM -0500, Rob Herring wrote:
> Dave,
>
> On 09/21/2011 04:19 AM, Dave Martin wrote:
> > This patch implements initial support for booting using a flattened
> > device tree on the Versatile Express platform.
> >
> > Eventually, it should be possible to present a single, core-tile-
> > independent board, but in this transitional patch the baseboard +
> > Cortex-A9x4 core tile combination is the only directly supported
> > platform, since the implementation is not yet fully generic.
> >
> > For now, clocks and timers are not handled via the device tree.
> > Implementation of these can follow in later patches.
> >
> > Thanks to Lorenzo Pieralisi, Grant Likely and Pawe? Moll for their
> > help and contributions.
> >
> > Signed-off-by: Dave Martin <dave.martin@linaro.org>
> > Acked-by: Pawe? Moll <Pawel.Moll@arm.com>
> > ---
> >
> > There are some outstanding issues which need to be discussed, listed
> > below.
> >
> > * This patch is not currently based on the GIC bindings being
> > discussed by Rob Herring et al. Once that discussion reaches a
> > conclusion, it should be straightforward to rebase onto the result.
> >
> > * The following added bindings are not present upstream and need
> > documentation / discussion:
> >
> > * arm,vexpress -- the global board binding for all platform
> > combinations using the Versatile Express motherboard.
> >
> > * arm,vexpress-v2p-ca9 -- the specific binding for the Versatile
> > Express motherboard with Cortex-A9x4 core tile installed. It
> > is only mentioned as the most-specific match in vexpress-v2p-
> > ca9.dts
> >
> > Since it's intended that the motherboard code should be fully
> > generic, and because no other core tiles are upstream yet,
> > perhaps we can get rid of this binding right away.
> >
> > * edid -- It should be possible to have a fairly generic binding
> > for EDID interfaces, but none seems to exist yet. Discussion
> > is needed regarding what form this should take.
> >
> > This might more appropriately be called "ddc" (or some
> > variation on that), since EDID seems only to describe the
> > format of the ID data retrievable via this interface; not the
> > interface itself.
> >
> > * arm,vexpress-flash -- Needed because of the requirement to
> > provide the physmap_flash driver with a special .set_vpp
> > handler.
> >
> > * idt,89hpes32h8 -- This is the IDT 89HPES32H8 PCI express
> > interconnect switch. This isn't needed for the Versatile
> > Express to work, but would be needed if using PCI-e peripherals
> > for real. I expect that more driver support needs to go
> > upstream before this is actually usable.
> >
> > * nxp,isp1761 -- The driver support for this is already upstream
> > (with some minor issues for ARM support).
> >
> > * arm,amba-bus -- widely used by other boards and patchsets, but
> > seems not to be documented.
> >
>
> This should be dropped. There's not really any bus component to an amba
> bus. All the probing info is within the primecell peripherals.
So, just use "simple-bus"?
> > * The following bindings for ARM primecell peripherals are used
> > elsewhere but not documented. They should be pretty simple and
> > uncontraversial.
> > * arm,pl031
> > * arm,pl041
> > * arm,pl050
> > * arm,pl180
> > * arm,sp805
> >
>
> Plus pl011, pl010, sp804, pl022, pl061
It looks like I missed pl011 and sp804 (though I don't currently declare
the timers in the device tree because of the way they are initialised).
> > Rob Herring suggested documenting simple bindings for these
> > (and others) along with his initial amba device tree probe
> > patches, but these bindings don't seem to be documented
> > upstream for now.
> >
>
> pl330 went the other route with a file for itself. That may be better to
> avoid conflicts. But yes, ARM should document all their peripherals. ;)
>
> I'll do the ones on highbank if you want to do the rest on VExp.
OK, I'll try to propose documentation for these:
* arm,pl011
* arm,pl031
* arm,pl041
* arm,pl050
* arm,pl180
* arm,sp804
* arm,sp805
...if you can pick the other ones that are relevant to highbank -- thanks.
>
> >
> > * Shawn Guo's smsc911x patch is needed for Ethernet to work. This is
> > headed upstream but not yet in mainline. It is available in -next.
> >
> > * Minor patches are needed to the isp1760 and pata_generic drivers,
> > to allow OF-based initialisation across a wider group of
> > architectures. These are being discussed independently, but are
> > not yet accepted for merging upstream.
> >
> > * Most core-tile peripherals are currently not described in the core-
> > tile device tree fragment. This is a lower-priority issue since
> > the motherboard code already autodetects the core-tile (though only
> > one core-tile is fully upstream at the moment).
> >
> > * Static peripheral mappings are not yet handled in a generic way in
> > the board support code. This is a prerequisite for supporting
> > multiple core-tiles int the same kernel. It well need to get fixed
> > later, when extra core tile support is merged (or before).
> >
> > Pawe? Moll is looking into this separately.
> >
> > * The Kconfig logic for ensuring that at least one boot protocol and
> > at least one core tile are selected is a bit ugly. Suggestions for
> > improving this are certainly welcome.
> >
> > arch/arm/Kconfig | 1 +
> > arch/arm/boot/dts/vexpress-v2m-legacy.dtsi | 163 ++++++++++++++++++++++++++++
> > arch/arm/boot/dts/vexpress-v2p-ca9.dts | 80 ++++++++++++++
> > arch/arm/configs/vexpress_defconfig | 1 +
> > arch/arm/mach-vexpress/Kconfig | 45 ++++++++-
> > arch/arm/mach-vexpress/ct-ca9x4.c | 7 ++
> > arch/arm/mach-vexpress/v2m.c | 54 +++++++++-
> > 7 files changed, 349 insertions(+), 2 deletions(-)
> > create mode 100644 arch/arm/boot/dts/vexpress-v2m-legacy.dtsi
> > create mode 100644 arch/arm/boot/dts/vexpress-v2p-ca9.dts
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 5ebc5d9..a6e90d5 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -282,6 +282,7 @@ config ARCH_VERSATILE
> >
> > config ARCH_VEXPRESS
> > bool "ARM Ltd. Versatile Express family"
> > + select ARCH_VEXPRESS_SANE_CONFIG
> > select ARCH_WANT_OPTIONAL_GPIOLIB
> > select ARM_AMBA
> > select ARM_TIMER_SP804
> > diff --git a/arch/arm/boot/dts/vexpress-v2m-legacy.dtsi b/arch/arm/boot/dts/vexpress-v2m-legacy.dtsi
> > new file mode 100644
> > index 0000000..fd6e4e4
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/vexpress-v2m-legacy.dtsi
> > @@ -0,0 +1,163 @@
> > +// ARM Ltd. Versatile Express Motherboard V2M-P1 (HBI-0190D)
> > +// Legacy memory map
>
> Not sure, but C++ style comments are probably frowned upon in dts too.
>
> > +
> > +/ {
> > + aliases {
> > + serial0 = &uart0;
> > + serial1 = &uart1;
> > + serial2 = &uart2;
> > + serial3 = &uart3;
> > + i2c0 = &i2c0;
> > + i2c1 = &i2c1;
> > + };
> > +
> > + motherboard {
> > + compatible = "simple-bus";
> > + #address-cells = <2>; // SMB chipselect number and offset
> > + #size-cells = <1>;
> > + #interrupt-cells = <1>;
> > +
> > + flash at 0,00000000 {
> > + compatible = "arm,vexpress-flash", "cfi-flash";
> > + reg = <0 0x00000000 0x04000000
> > + 1 0x00000000 0x04000000>;
> > + bank-width = <4>;
> > + };
> > +
> > + psram at 2,00000000 {
> > + compatible = "mtd-ram";
> > + reg = <2 0x00000000 0x02000000>;
> > + bank-width = <4>;
> > + };
> > +
> > + ethernet at 3,02000000 {
> > + compatible = "smsc,lan9118", "smsc,lan9115";
> > + reg = <3 0x02000000 0x10000>;
> > + reg-io-width = <4>;
> > + interrupts = <15>;
> > + smsc,irq-active-high;
> > + smsc,irq-push-pull;
> > + };
> > +
> > + usb at 3,03000000 {
> > + compatible = "nxp,usb-isp1761";
> > + reg = <3 0x03000000 0x20000>;
> > + interrupts = <16>;
> > + port1-otg;
> > + };
> > +
> > + peripherals at 7,00000000 {
> > + compatible = "arm,amba-bus", "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 7 0 0x20000>;
> > +
> > + // PCI-E I2C bus
> > + i2c0: i2c at 02000 {
> > + compatible = "arm,versatile-i2c";
> > + reg = <0x02000 0x1000>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + pcie-switch at 60 {
> > + compatible = "idt,89hpes32h8";
> > + reg = <0x60>;
> > + };
> > + };
> > +
> > + aaci at 04000 {
> > + compatible = "arm,pl041", "arm,primecell";
> > + reg = <0x04000 0x1000>;
> > + interrupts = <11>;
> > + };
> > +
> > + mmci at 05000 {
> > + compatible = "arm,pl180", "arm,primecell";
> > + reg = <0x05000 0x1000>;
> > + interrupts = <9 10>;
> > + };
> > +
> > + kmi at 06000 {
> > + compatible = "arm,pl050", "arm,primecell";
> > + reg = <0x06000 0x1000>;
> > + interrupts = <12>;
> > + };
> > +
> > + kmi at 07000 {
> > + compatible = "arm,pl050", "arm,primecell";
> > + reg = <0x07000 0x1000>;
> > + interrupts = <13>;
> > + };
> > +
> > + uart0: uart at 09000 {
> > + compatible = "arm,pl011", "arm,primecell";
> > + reg = <0x09000 0x1000>;
> > + interrupts = <5>;
> > + };
> > +
> > + uart1: uart at 0a000 {
> > + compatible = "arm,pl011", "arm,primecell";
> > + reg = <0x0a000 0x1000>;
> > + interrupts = <6>;
> > + };
> > +
> > + uart2: uart at 0b000 {
> > + compatible = "arm,pl011", "arm,primecell";
> > + reg = <0x0b000 0x1000>;
> > + interrupts = <7>;
> > + };
> > +
> > + uart3: uart at 0c000 {
> > + compatible = "arm,pl011", "arm,primecell";
> > + reg = <0x0c000 0x1000>;
> > + interrupts = <8>;
> > + };
> > +
> > + wdt at 0f000 {
> > + compatible = "arm,sp805", "arm,primecell";
> > + reg = <0x0f000 0x1000>;
> > + interrupts = <0>;
> > + };
> > +
> > + // Timer init is hardcoded in v2m_timer_init(), for now.
> > + // timer at 11000 {
> > + // compatible = "arm,arm-sp804";
>
> arm,sp804 is more consistent. I believe the sp804 does have the periphid
> registers, so arm,primecell should also be added.
Do you mean "does not have"? If so, the periphid will be needed -- thanks for
pointing it out in that case.
I will make the names consistent. These were pasted from someone Lorenzo's
older patches, and failed to sport e the inconsistency since I wasn't
actually making use of these entries yet.
> > + // reg = <0x11000 0x1000>;
> > + // interrupts = <2>;
> > + // };
> > +
> > + // timer at 12000 {
> > + // compatible = "arm,arm-sp804";
> > + // reg = <0x12000 0x1000>;
> > + // };
>
> Just because Linux is not using it, doesn't mean you should comment it out.
^ permalink raw reply
* [PATCH] ARM: vexpress: initial device tree support
From: Pawel Moll @ 2011-09-21 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110921142425.GE2872@arm.com>
> OK, I'll try to propose documentation for these:
> * arm,pl180
You can skip this one - I'll add the description together with the MMCI
driver bindings (it will be 180 and 181, by the way :-)
> > > + // Timer init is hardcoded in v2m_timer_init(), for now.
> > > + // timer at 11000 {
> > > + // compatible = "arm,arm-sp804";
> >
> > arm,sp804 is more consistent. I believe the sp804 does have the periphid
> > registers, so arm,primecell should also be added.
>
> Do you mean "does not have"? If so, the periphid will be needed -- thanks for
> pointing it out in that case.
I think Rob meant it should be
compatible = "arm,sp804", "arm,primecell",
as SP804 contains the PrimeCell periphid registers, so will be
recognized by amba bus driver.
> I will make the names consistent. These were pasted from someone Lorenzo's
> older patches, and failed to sport e the inconsistency since I wasn't
> actually making use of these entries yet.
>
> > > + // reg = <0x11000 0x1000>;
> > > + // interrupts = <2>;
> > > + // };
> > > +
> > > + // timer at 12000 {
> > > + // compatible = "arm,arm-sp804";
> > > + // reg = <0x12000 0x1000>;
> > > + // };
> >
> > Just because Linux is not using it, doesn't mean you should comment it out.
>
> From the point of view of describing the hardware, yes. However, I was
> a bit worried that if sp804 is turned into a full driver, it will get
> initialised twice -- once explicitly and once in of_platform_populate()...
> at least until the baord code is adapted to work properly with the new
> driver.
>
> Commenting these entries out for now seemed a good idea to avoid the flag-day
> hazard. Am I being too cautious?
I think you are ;-) Besides my static-mapping-rework is already using
those...
Cheers!
Pawe?
^ permalink raw reply
* [PATCH v7 01/26] gpio/omap: remove dependency on gpio_bank_count
From: Tony Lindgren @ 2011-09-21 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-2-git-send-email-tarun.kanti@ti.com>
* Tarun Kanti DebBarma <tarun.kanti@ti.com> [110913 05:29]:
> From: Charulatha V <charu@ti.com>
>
> The gpio_bank_count is the count of number of GPIO devices in a SoC. Remove this
> dependency from the driver by using list. Also remove the dependency on array of
> pointers to gpio_bank struct of all GPIO devices.
>
> Signed-off-by: Charulatha V <charu@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v7 04/26] gpio/omap: fix pwrdm_post_transition call sequence
From: Tony Lindgren @ 2011-09-21 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-5-git-send-email-tarun.kanti@ti.com>
* Tarun Kanti DebBarma <tarun.kanti@ti.com> [110913 05:29]:
> From: Charulatha V <charu@ti.com>
>
> The context lost count is modified in omap_sram_idle() path when
> pwrdm_post_transition() is called. But pwrdm_post_transition() is called
> only after omap_gpio_resume_after_idle() is called. Correct this so that
> context lost count is modified before calling omap_gpio_resume_after_idle().
>
> This would be useful when OMAP GPIO save/restore context is called by
> the OMAP GPIO driver itself.
>
> Signed-off-by: Charulatha V <charu@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
This should be acked by Kevin, looks OK to me:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v7 05/26] gpio/omap: handle save/restore context in GPIO driver
From: Tony Lindgren @ 2011-09-21 14:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-6-git-send-email-tarun.kanti@ti.com>
* Tarun Kanti DebBarma <tarun.kanti@ti.com> [110913 05:29]:
> From: Charulatha V <charu@ti.com>
>
> Modify omap_gpio_prepare_for_idle() & omap_gpio_resume_after_idle() functions
> to handle save context & restore context respectively in the OMAP GPIO driver
> itself instead of calling these functions from pm specific files.
> For this, in gpio_prepare_for_idle(), call *_get_context_loss_count() and in
> gpio_resume_after_idle() call it again. If the count is different, do restore
> context. The workaround_enabled flag is no more required and is removed.
>
> Signed-off-by: Charulatha V <charu@ti.com>
> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
This to should be also acked by Kevin, looks OK to me:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v7 06/26] gpio/omap: make non-wakeup GPIO part of pdata
From: Tony Lindgren @ 2011-09-21 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-7-git-send-email-tarun.kanti@ti.com>
* Tarun Kanti DebBarma <tarun.kanti@ti.com> [110913 05:30]:
> From: Charulatha V <charu@ti.com>
>
> Non-wakeup GPIOs are available only in OMAP2. Avoid cpu_is checks by making
> non_wakeup_gpios as part of pdata.
>
> Signed-off-by: Charulatha V <charu@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v2] dmaengine: add CSR SiRFprimaII DMAC driver
From: Arnd Bergmann @ 2011-09-21 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316166960-20964-1-git-send-email-Baohua.Song@csr.com>
Hi Barry,
I just looked at the driver again and stumbled over a potential race:
On Friday 16 September 2011, Barry Song wrote:
> +
> +/* Execute all queued DMA descriptors */
> +static void sirfsoc_dma_execute(struct sirfsoc_dma_chan *schan)
> +{
> + struct sirfsoc_dma *sdma = dma_chan_to_sirfsoc_dma(&schan->chan);
> + int cid = schan->chan.chan_id;
> + struct sirfsoc_dma_desc *sdesc = NULL;
> +
> + sdesc = list_first_entry(&schan->queued, struct sirfsoc_dma_desc,
> + node);
> + /* Move the first queued descriptor to active list */
> + list_move_tail(&schan->queued, &schan->active);
> +
> + /* Start the DMA transfer */
> + writel_relaxed(sdesc->width, sdma->base + SIRFSOC_DMA_WIDTH_0 + cid * 4);
> + writel_relaxed(cid | (schan->mode << SIRFSOC_DMA_MODE_CTRL_BIT) |
> + (schan->direction << SIRFSOC_DMA_DIR_CTRL_BIT),
> + sdma->base + cid * 0x10 + SIRFSOC_DMA_CH_CTRL);
> + writel_relaxed(sdesc->xlen, sdma->base + cid * 0x10 + SIRFSOC_DMA_CH_XLEN);
> + writel_relaxed(sdesc->ylen, sdma->base + cid * 0x10 + SIRFSOC_DMA_CH_YLEN);
> + writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_INT_EN) | (1 << cid),
> + sdma->base + SIRFSOC_DMA_INT_EN);
> + writel_relaxed(schan->addr >> 2, sdma->base + cid * 0x10 + SIRFSOC_DMA_CH_ADDR);
> +}
I think you need to add a memory write barrier somewhere in here, because
writel_relaxed() does not flush out the CPUs write buffers, unlike writel().
Theoretically, you might be starting a DMA that reads from coherent memory
but the data is still stuck in the CPU. I assume that the last writel_relaxed()
is the access that actually starts the DMA, so it should be airtight once you
replace that with writel().
> +/* Interrupt handler */
> +static irqreturn_t sirfsoc_dma_irq(int irq, void *data)
> +{
> + struct sirfsoc_dma *sdma = data;
> + struct sirfsoc_dma_chan *schan;
> + u32 is;
> + int ch;
> +
> + is = readl_relaxed(sdma->base + SIRFSOC_DMA_CH_INT);
> + while ((ch = fls(is) - 1) >= 0) {
> + is &= ~(1 << ch);
> + writel_relaxed(1 << ch, sdma->base + SIRFSOC_DMA_CH_INT);
> + schan = &sdma->channels[ch];
> +
> + spin_lock(&schan->lock);
> +
> + /* Execute queued descriptors */
> + list_splice_tail_init(&schan->active, &schan->completed);
> + if (!list_empty(&schan->queued))
> + sirfsoc_dma_execute(schan);
> +
> + spin_unlock(&schan->lock);
> + }
Similarly, readl_relaxed() does might not force in inbound DMA to be
completed, causing you to call the tasklet before the data is visible
to the CPU. While your hardware might have better guarantees, the
API you are using does not. It should be find when you replace the
first read_relaxed with readl() here.
Arnd
^ permalink raw reply
* [PATCH v7 07/26] gpio/omap: avoid cpu checks during module ena/disable
From: Tony Lindgren @ 2011-09-21 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-8-git-send-email-tarun.kanti@ti.com>
* Tarun Kanti DebBarma <tarun.kanti@ti.com> [110913 05:30]:
> From: Charulatha V <charu@ti.com>
>
> Remove cpu-is checks while enabling/disabling OMAP GPIO module during a gpio
> request/free.
>
> Signed-off-by: Charulatha V <charu@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v7 08/26] gpio/omap: further cleanup using wkup_en register
From: Tony Lindgren @ 2011-09-21 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-9-git-send-email-tarun.kanti@ti.com>
* Tarun Kanti DebBarma <tarun.kanti@ti.com> [110913 05:29]:
> Wakeup enable register offset initialized according to OMAP versions
> during device registration. Use this to avoid version checks.
> Starting with OMAP4, legacy registers should not be used in combination
> with the updated regsiters. Use wkup_en register consistently for
> all SoCs wherever applicable.
>
> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
> Signed-off-by: Charulatha V <charu@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [Linaro-mm-sig] [PATCH 1/2] ARM: initial proof-of-concept IOMMU mapper for DMA-mapping
From: Marek Szyprowski @ 2011-09-21 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <594816116217195c28de13accaf1f9f2.squirrel@www.codeaurora.org>
Hello,
On Thursday, September 08, 2011 6:42 PM Laura Abbott wrote:
> Hi, a few comments
> On Fri, September 2, 2011 6:56 am, Marek Szyprowski wrote:
> ...
> > +
> > +struct dma_iommu_mapping {
> > + /* iommu specific data */
> > + struct iommu_domain *domain;
> > +
> > + void *bitmap;
>
> In the earlier version of this patch you had this as a genpool instead of
> just doing the bitmaps manually. Is there a reason genpool can't be used
> to get the iova addresses?
IMHO genpool was a bit overkill in this case and required some additional
patches for aligned allocations. In the next version I also want to extend
this bitmap based allocator to dynamically resize the bitmap for more than
one page if the io address space gets exhausted.
> > + size_t bits;
> > + unsigned int order;
> > + dma_addr_t base;
> > +
> > + struct mutex lock;
> > +};
> <snip>
> > +int arm_iommu_attach_device(struct device *dev, dma_addr_t base, size_t
> > size, int order)
> > +{
> > + unsigned int count = (size >> PAGE_SHIFT) - order;
> > + unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
> > + struct dma_iommu_mapping *mapping;
> > + int err = -ENOMEM;
> > +
> > + mapping = kzalloc(sizeof(struct dma_iommu_mapping), GFP_KERNEL);
> > + if (!mapping)
> > + goto err;
> > +
> > + mapping->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
> > + if (!mapping->bitmap)
> > + goto err2;
> > +
> > + mapping->base = base;
> > + mapping->bits = bitmap_size;
> > + mapping->order = order;
> > + mutex_init(&mapping->lock);
> > +
> > + mapping->domain = iommu_domain_alloc();
> > + if (!mapping->domain)
> > + goto err3;
> > +
> > + err = iommu_attach_device(mapping->domain, dev);
> > + if (err != 0)
> > + goto err4;
> > +
> > + dev->archdata.mapping = mapping;
> > + set_dma_ops(dev, &iommu_ops);
> > +
> > + printk(KERN_INFO "Attached IOMMU controller to %s device.\n",
> > dev_name(dev));
> > + return 0;
> > +
> > +err4:
> > + iommu_domain_free(mapping->domain);
> > +err3:
> > + kfree(mapping->bitmap);
> > +err2:
> > + kfree(mapping);
> > +err:
> > + return -ENOMEM;
> > +}
> > +EXPORT_SYMBOL(arm_iommu_attach_device);
> > +
> > +#endif
> Attach makes the assumption that each iommu device will exist in a
> separate domain. What if multiple devices want to use the same iommu
> domain? The msm iommu implementation has many different iommu devices but
> many of these will need the same buffer to be mapped in each context so
> currently many devices share the same domain. Without this, the same map
> call would need to happen for each device, which creates extra map calls
> and overhead.
Ah, right. I forgot about the case when devices need to share one domain.
Moving iommu_domain_alloc out of arm_iommu_attach_device and giving that
function just a pointer to the iommu domain should solve this issue. I will
change this in the next version of the patches.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
^ permalink raw reply
* [PATCH v7 09/26] gpio/omap: use level/edge detect reg offsets
From: Tony Lindgren @ 2011-09-21 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-10-git-send-email-tarun.kanti@ti.com>
* Tarun Kanti DebBarma <tarun.kanti@ti.com> [110913 05:29]:
> By adding level and edge detection register offsets and then initializing them
> correctly according to OMAP versions during device registrations we can now remove
> lot of revision checks in these functions.
>
> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
> Signed-off-by: Charulatha V <charu@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v7 10/26] gpio/omap: remove hardcoded offsets in context save/restore
From: Tony Lindgren @ 2011-09-21 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-11-git-send-email-tarun.kanti@ti.com>
* Tarun Kanti DebBarma <tarun.kanti@ti.com> [110913 05:29]:
> It is not required to use hard-coded offsets any more in context save and
> restore functions and instead use the generic offsets which have been correctly
> initialized during device registration.
>
> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
> Signed-off-by: Charulatha V <charu@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v7 11/26] gpio/omap: cleanup set_gpio_triggering function
From: Tony Lindgren @ 2011-09-21 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-12-git-send-email-tarun.kanti@ti.com>
* Tarun Kanti DebBarma <tarun.kanti@ti.com> [110913 05:29]:
> Getting rid of ifdefs within the function by adding register offset intctrl
> and associating OMAPXXXX_GPIO_INT_CONTROL in respective SoC specific files.
> Also, use wkup_status register consistently instead of referring to wakeup
> clear and wakeup set register offsets.
>
> Signed-off-by: Charulatha V <charu@ti.com>
> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v7 12/26] gpio/omap: cleanup omap_gpio_mod_init function
From: Tony Lindgren @ 2011-09-21 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-13-git-send-email-tarun.kanti@ti.com>
* Tarun Kanti DebBarma <tarun.kanti@ti.com> [110913 05:30]:
> With register offsets now defined for respective OMAP versions we can get rid
> of cpu_class_* checks. This function now has common initialization code for
> all OMAP versions. Initialization specific to OMAP16xx has been moved within
> omap16xx_gpio_init().
>
> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
> Signed-off-by: Charulatha V <charu@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v7 13/26] gpio/omap: use pinctrl offset instead of macro
From: Tony Lindgren @ 2011-09-21 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315918979-26173-14-git-send-email-tarun.kanti@ti.com>
* Tarun Kanti DebBarma <tarun.kanti@ti.com> [110913 05:29]:
> From: Charulatha V <charu@ti.com>
>
> Use regs->pinctrl field instead of using the macro OMAP1510_GPIO_PIN_CONTROL
>
> Signed-off-by: Charulatha V <charu@ti.com>
> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox