* [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
From: Felipe Balbi @ 2011-10-03 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3529819.LQllWhb43D@wuerfel>
Hi,
On Mon, Oct 03, 2011 at 11:40:26AM +0200, Arnd Bergmann wrote:
> On Monday 03 October 2011 01:10:51 Felipe Balbi wrote:
> > Anyway, I'll take your patches in, but their too late for this merge
> > window I already sent my last pull to Greg.
>
> No problem. I need the full set of arm-randconfig patches upstream in order
> to make randconfig work in general, and that's not happening for 3.2
> anyway. Right now, I'm just trying to as many patches as possible into
> maintainer trees.
>
> Is your tree part of linux-next, or will it only show up after the merge
> window once Greg has pulled your first set for 3.3?
My tree isn't in linux-next yet so my patches go to Greg and from there
to -next.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20111003/fd2867bf/attachment.sig>
^ permalink raw reply
* [PATCH V2] AT91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-03 10:00 UTC (permalink / raw)
To: linux-arm-kernel
Create a new device tree source file for Atmel at91sam9g45 SoC family.
The Evaluation Kit at91sam9m10g45ek includes it.
This first basic support will be populated as drivers and boards will be
converted to device tree.
Contains serial, dma and interrupt controllers.
The generic board file still takes advantage of platform data for early serial
init. As we need a storage media and the NAND flash driver is not converted to
DT yet, we keep old initialization for it.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
V2: foundation for AT91SAM generic support
- device tree focused board file
- inclusion of USART DT support
- early USART and NAND still using platform data
arch/arm/boot/dts/at91sam9g45.dtsi | 103 +++++++++++++++++++++++++
arch/arm/boot/dts/at91sam9m10g45ek.dts | 37 +++++++++
arch/arm/mach-at91/Kconfig | 11 +++
arch/arm/mach-at91/Makefile | 3 +
arch/arm/mach-at91/Makefile.boot | 2 +
arch/arm/mach-at91/at91sam9g45_devices.c | 24 +++++--
arch/arm/mach-at91/board-dt.c | 122 ++++++++++++++++++++++++++++++
7 files changed, 296 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/boot/dts/at91sam9g45.dtsi
create mode 100644 arch/arm/boot/dts/at91sam9m10g45ek.dts
create mode 100644 arch/arm/mach-at91/board-dt.c
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
new file mode 100644
index 0000000..7d3341f
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -0,0 +1,103 @@
+/*
+ * at91sam9g45.dtsi - Device Tree Include file for AT91SAM9G45 family SoC
+ * applies to AT91SAM9G45, AT91SAM9M10,
+ * AT91SAM9G46, AT91SAM9M11 SoC
+ *
+ * Copyright (C) 2011 Atmel,
+ * 2011 Nicolas Ferre <nicolas.ferre@atmel.com>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "Atmel AT91SAM9G45 family SoC";
+ compatible = "atmel,at91sam9g45";
+ interrupt-parent = <&aic>;
+
+ aliases {
+ serial0 = &dbgu;
+ serial1 = &usart0;
+ serial2 = &usart1;
+ serial3 = &usart2;
+ serial4 = &usart3;
+ };
+ cpus {
+ cpu at 0 {
+ compatible = "arm,arm926ejs";
+ };
+ };
+
+ memory {
+ reg = <0x70000000 0x10000000>;
+ };
+
+ ahb {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ apb {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ aic: interrupt-controller at fffff000 {
+ #interrupt-cells = <1>;
+ compatible = "atmel,at91rm9200-aic";
+ interrupt-controller;
+ reg = <0xfffff000 0x200>;
+ };
+
+ dma: dma-controller at ffffec00 {
+ compatible = "atmel,at91sam9g45-hdmac";
+ reg = <0xffffec00 0x200>;
+ interrupts = <21>;
+ atmel,hdmac-nr-channels = <8>;
+ atmel,hdmac-cap-memcpy;
+ atmel,hdmac-cap-slave;
+ };
+
+ dbgu: serial at ffffee00 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xffffee00 0x200>;
+ interrupts = <1>;
+ };
+
+ usart0: serial at fff8c000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff8c000 0x4000>;
+ interrupts = <7>;
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ };
+
+ usart1: serial at fff90000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff90000 0x4000>;
+ interrupts = <8>;
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ };
+
+ usart2: serial at fff94000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff94000 0x4000>;
+ interrupts = <9>;
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ };
+
+ usart3: serial at fff98000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff98000 0x4000>;
+ interrupts = <10>;
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts b/arch/arm/boot/dts/at91sam9m10g45ek.dts
new file mode 100644
index 0000000..cf743de
--- /dev/null
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -0,0 +1,37 @@
+/*
+ * at91sam9m10g45ek.dts - Device Tree file for AT91SAM9M10G45-EK board
+ *
+ * Copyright (C) 2011 Atmel,
+ * 2011 Nicolas Ferre <nicolas.ferre@atmel.com>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+/include/ "at91sam9g45.dtsi"
+
+/ {
+ model = "Atmel AT91SAM9M10G45-EK";
+ compatible = "atmel,at91sam9m10g45ek", "atmel,at91sam9g45", "atmel,at91sam9";
+
+ chosen {
+ bootargs = "mem=64M console=ttyS0,115200 mtdparts=atmel_nand:4M(bootstrap/uboot/kernel)ro,60M(rootfs),-(data) root=/dev/mtdblock1 rw rootfstype=jffs2";
+ };
+
+ memory {
+ reg = <0x70000000 0x4000000>;
+ };
+
+ ahb {
+ apb {
+ usart0: serial at fff8c000 {
+ status = "disabled";
+ };
+ usart2: serial at fff94000 {
+ status = "disabled";
+ };
+ usart3: serial at fff98000 {
+ status = "disabled";
+ };
+ };
+ };
+};
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 2248467..4b59d96 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -442,6 +442,17 @@ endif
# ----------------------------------------------------------
+comment "Generic Board Type"
+
+config MACH_AT91SAM_DT
+ bool "Atmel AT91SAM Evaluation Kits with device-tree support"
+ select USE_OF
+ help
+ Select this if you want to experiment device-tree with
+ an Atmel Evaluation Kit.
+
+# ----------------------------------------------------------
+
comment "AT91 Board Options"
config MTD_AT91_DATAFLASH_CARD
diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index bf57e8b..3ff245e 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -74,6 +74,9 @@ obj-$(CONFIG_MACH_SNAPPER_9260) += board-snapper9260.o
# AT91SAM9G45 board-specific support
obj-$(CONFIG_MACH_AT91SAM9M10G45EK) += board-sam9m10g45ek.o
+# AT91SAM board with device-tree
+obj-$(CONFIG_MACH_AT91SAM_DT) += board-dt.o
+
# AT91CAP9 board-specific support
obj-$(CONFIG_MACH_AT91CAP9ADK) += board-cap9adk.o
diff --git a/arch/arm/mach-at91/Makefile.boot b/arch/arm/mach-at91/Makefile.boot
index 3462b81..d278863 100644
--- a/arch/arm/mach-at91/Makefile.boot
+++ b/arch/arm/mach-at91/Makefile.boot
@@ -16,3 +16,5 @@ else
params_phys-y := 0x20000100
initrd_phys-y := 0x20410000
endif
+
+dtb-$(CONFIG_MACH_AT91SAM_DT) += at91sam9m10g45ek.dtb
diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c
index bb84040..27276b8 100644
--- a/arch/arm/mach-at91/at91sam9g45_devices.c
+++ b/arch/arm/mach-at91/at91sam9g45_devices.c
@@ -69,9 +69,16 @@ static struct platform_device at_hdmac_device = {
void __init at91_add_device_hdmac(void)
{
- dma_cap_set(DMA_MEMCPY, atdma_pdata.cap_mask);
- dma_cap_set(DMA_SLAVE, atdma_pdata.cap_mask);
- platform_device_register(&at_hdmac_device);
+ struct device_node *of_node =
+ of_find_node_by_name(NULL, "dma-controller");
+
+ if (of_node) {
+ of_node_put(of_node);
+ } else {
+ dma_cap_set(DMA_MEMCPY, atdma_pdata.cap_mask);
+ dma_cap_set(DMA_SLAVE, atdma_pdata.cap_mask);
+ platform_device_register(&at_hdmac_device);
+ }
}
#else
void __init at91_add_device_hdmac(void) {}
@@ -1556,10 +1563,15 @@ void __init at91_set_serial_console(unsigned portnr)
void __init at91_add_device_serial(void)
{
int i;
+ struct device_node *of_node = of_find_node_by_name(NULL, "serial");
- for (i = 0; i < ATMEL_MAX_UART; i++) {
- if (at91_uarts[i])
- platform_device_register(at91_uarts[i]);
+ if (of_node) {
+ of_node_put(of_node);
+ } else {
+ for (i = 0; i < ATMEL_MAX_UART; i++) {
+ if (at91_uarts[i])
+ platform_device_register(at91_uarts[i]);
+ }
}
if (!atmel_default_console_device)
diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
new file mode 100644
index 0000000..7bcb9a9
--- /dev/null
+++ b/arch/arm/mach-at91/board-dt.c
@@ -0,0 +1,122 @@
+/*
+ * Setup code for AT91SAM Evaluation Kits with Device Tree support
+ *
+ * Covers: * AT91SAM9G45-EKES board
+ * * AT91SAM9M10-EKES board
+ * * AT91SAM9M10G45-EK board
+ *
+ * Copyright (C) 2011 Atmel,
+ * 2011 Nicolas Ferre <nicolas.ferre@atmel.com>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/irqdomain.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+
+#include <mach/hardware.h>
+#include <mach/board.h>
+#include <mach/gpio.h>
+#include <mach/system_rev.h>
+#include <mach/at91sam9_smc.h>
+
+#include <asm/setup.h>
+#include <asm/irq.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/mach/irq.h>
+
+#include "sam9_smc.h"
+#include "generic.h"
+
+
+static void __init ek_init_early(void)
+{
+ /* Initialize processor: 12.000 MHz crystal */
+ at91_initialize(12000000);
+
+ /* DGBU on ttyS0. (Rx & Tx only) */
+ at91_register_uart(0, 0, 0);
+
+ /* USART0 not connected on the -EK board */
+ /* USART1 on ttyS2. (Rx, Tx, RTS, CTS) */
+ at91_register_uart(AT91SAM9G45_ID_US1, 2, ATMEL_UART_CTS | ATMEL_UART_RTS);
+
+ /* set serial console to ttyS0 (ie, DBGU) */
+ at91_set_serial_console(0);
+}
+
+/* det_pin is not connected */
+static struct atmel_nand_data __initdata ek_nand_data = {
+ .ale = 21,
+ .cle = 22,
+ .rdy_pin = AT91_PIN_PC8,
+ .enable_pin = AT91_PIN_PC14,
+};
+
+static struct sam9_smc_config __initdata ek_nand_smc_config = {
+ .ncs_read_setup = 0,
+ .nrd_setup = 2,
+ .ncs_write_setup = 0,
+ .nwe_setup = 2,
+
+ .ncs_read_pulse = 4,
+ .nrd_pulse = 4,
+ .ncs_write_pulse = 4,
+ .nwe_pulse = 4,
+
+ .read_cycle = 7,
+ .write_cycle = 7,
+
+ .mode = AT91_SMC_READMODE | AT91_SMC_WRITEMODE | AT91_SMC_EXNWMODE_DISABLE,
+ .tdf_cycles = 3,
+};
+
+static void __init ek_add_device_nand(void)
+{
+ ek_nand_data.bus_width_16 = board_have_nand_16bit();
+ /* setup bus-width (8 or 16) */
+ if (ek_nand_data.bus_width_16)
+ ek_nand_smc_config.mode |= AT91_SMC_DBW_16;
+ else
+ ek_nand_smc_config.mode |= AT91_SMC_DBW_8;
+
+ /* configure chip-select 3 (NAND) */
+ sam9_smc_configure(3, &ek_nand_smc_config);
+
+ at91_add_device_nand(&ek_nand_data);
+}
+
+static const struct of_device_id aic_of_match[] __initconst = {
+ { .compatible = "atmel,at91rm9200-aic", },
+ {},
+};
+
+static void __init at91_dt_device_init(void)
+{
+ irq_domain_generate_simple(aic_of_match, 0xfffff000, 0);
+
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+
+ /* NAND */
+ ek_add_device_nand();
+}
+
+static const char *at91_dt_board_compat[] __initdata = {
+ "atmel,at91sam9m10g45ek",
+ NULL
+};
+
+DT_MACHINE_START(at91sam9m10g45ek_dt, "Atmel AT91SAM (Device Tree)")
+ /* Maintainer: Atmel */
+ .timer = &at91sam926x_timer,
+ .map_io = at91_map_io,
+ .init_early = ek_init_early,
+ .init_irq = at91_init_irq_default,
+ .init_machine = at91_dt_device_init,
+ .dt_compat = at91_dt_board_compat,
+MACHINE_END
--
1.7.3
^ permalink raw reply related
* [PATCH] ARM: S3C2410: Remove section mismatch warning
From: Russell King - ARM Linux @ 2011-10-03 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317634841-23339-1-git-send-email-tushar.behera@linaro.org>
On Mon, Oct 03, 2011 at 03:10:41PM +0530, Tushar Behera wrote:
> Some of the functions and structures did not have _init or __initdata
> attributes, even though they were referenced from functions / structures
> with those attribute, resulting in section mismatches.
Firstly - it's a good idea to include the warnings which you're fixing
in the commit log text, so that people know exactly what is being fixed.
> diff --git a/arch/arm/mach-s3c2410/usb-simtec.c b/arch/arm/mach-s3c2410/usb-simtec.c
> index 29bd3d9..3a1028c 100644
> --- a/arch/arm/mach-s3c2410/usb-simtec.c
> +++ b/arch/arm/mach-s3c2410/usb-simtec.c
> @@ -104,7 +104,7 @@ static struct s3c2410_hcd_info usb_simtec_info __initdata = {
> };
>
>
> -int usb_simtec_init(void)
> +int __init usb_simtec_init(void)
> {
> int ret;
>
This one looks fine.
> diff --git a/arch/arm/mach-s3c2416/irq.c b/arch/arm/mach-s3c2416/irq.c
> index 28ad20d..153cb2f 100644
> --- a/arch/arm/mach-s3c2416/irq.c
> +++ b/arch/arm/mach-s3c2416/irq.c
> @@ -234,7 +234,7 @@ static int __init s3c2416_irq_add(struct sys_device *sysdev)
> return 0;
> }
>
> -static struct sysdev_driver s3c2416_irq_driver = {
> +static struct sysdev_driver s3c2416_irq_driver __initdata = {
> .add = s3c2416_irq_add,
> };
>
I remain entirely unconvinced that this is correct. As a result of
the "sysdev_driver_register(&s3c2416_sysclass, &s3c2416_irq_driver);"
call, this structure is placed on a list.
If this structure is marked __initdata, then the memory behind the
structure will be freed and overwritten - however, it's still on a
list which might be walked. Such a walk would cause a kernel oops
or might even be an exploitable security hole if that page ends up
in userspace - especially as said structure contains function calls
which would be called in privileged mode.
The same comment applies to the other sysdev driver structures you're
marking __initdata too.
^ permalink raw reply
* [PATCH 26/30] ARM: omap: add board autoselection
From: Arnd Bergmann @ 2011-10-03 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E898010.80208@ti.com>
On Monday 03 October 2011 11:27:44 Cousson, Benoit wrote:
> >
> > In the long run, I'd hope we can just get rid of these for subarchitectures
> > that support device tree probing and make the device tree based machine
> > description unconditional.
>
> This is really our goal, we will have soon the board-generic.c for that,
> someone will just have to migrate these ~30 board files to device tree
> DTS files
For the purpose of build-time validation using randconfig, there is no
problem in keeping some board files forever, as long as the generic board
file is always built-in.
Arnd
^ permalink raw reply
* [PATCH 03/30] video/omap: fix build dependencies
From: Arnd Bergmann @ 2011-10-03 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317625175.2026.8.camel@deskari>
On Monday 03 October 2011 09:59:35 Tomi Valkeinen wrote:
> On Sun, 2011-10-02 at 16:45 +0200, Arnd Bergmann wrote:
> > Four of the LCD panel drivers depend on the backlight class,
> > so add the dependency in Kconfig.
> > Selecting the BACKLIGHT_CLASS_DEVICE symbol does not generally
> > work since it has other dependencies.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
>
> This looks ok to me. If it's fine to you, I'll queue this patch in my
> DSS tree to prevent possible conflicts.
Yes, that's good.
Thanks,
Arnd
^ permalink raw reply
* [RFC PATCH] tty/serial: atmel_serial: add device tree support
From: Nicolas Ferre @ 2011-10-03 9:51 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
Hi,
Here is a first attempt to add device tree support to atmel_serial driver.
RS485 data are not handled for the moment. My feeling is that they should be
added as a generic DT biding set.
.../devicetree/bindings/tty/serial/atmel-usart.txt | 27 +++++++++
drivers/tty/serial/atmel_serial.c | 56 +++++++++++++++++---
2 files changed, 75 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
diff --git a/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
new file mode 100644
index 0000000..a49d9a1
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/atmel-usart.txt
@@ -0,0 +1,27 @@
+* Atmel Universal Synchronous Asynchronous Receiver/Transmitter (USART)
+
+Required properties:
+- compatible: Should be "atmel,<chip>-usart"
+ The compatible <chip> indicated will be the first SoC to support an
+ additional mode or an USART new feature.
+- reg: Should contain registers location and length
+- interrupts: Should contain interrupt
+
+Optional properties:
+- atmel,use-dma-rx: use of PDC or DMA for receiving data
+- atmel,use-dma-tx: use of PDC or DMA for transmitting data
+
+<chip> compatible description:
+- at91rm9200: legacy USART support
+- at91sam9260: generic USART implementation for SAM9 SoCs
+
+Example:
+
+ usart0: serial at fff8c000 {
+ compatible = "atmel,at91sam9260-usart";
+ reg = <0xfff8c000 0x4000>;
+ interrupts = <7>;
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ };
+
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 453cdb5..65f56c3 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -33,6 +33,8 @@
#include <linux/sysrq.h>
#include <linux/tty_flip.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/dma-mapping.h>
#include <linux/atmel_pdc.h>
#include <linux/atmel_serial.h>
@@ -162,6 +164,16 @@ static struct atmel_uart_port atmel_ports[ATMEL_MAX_UART];
static struct console atmel_console;
#endif
+#if defined(CONFIG_OF)
+static const struct of_device_id atmel_serial_dt_ids[] = {
+ { .compatible = "atmel,at91rm9200-usart" },
+ { .compatible = "atmel,at91sam9260-usart" },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, atmel_serial_dt_ids);
+#endif
+
static inline struct atmel_uart_port *
to_atmel_uart_port(struct uart_port *uart)
{
@@ -1413,14 +1425,31 @@ static struct uart_ops atmel_pops = {
static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
struct platform_device *pdev)
{
+ struct device_node *np = pdev->dev.of_node;
struct uart_port *port = &atmel_port->uart;
struct atmel_uart_data *pdata = pdev->dev.platform_data;
+ int ret;
+
+ if (np) {
+ ret = of_alias_get_id(np, "serial");
+ if (ret >= 0)
+ port->line = ret;
+ if (of_get_property(np, "atmel,use-dma-rx", NULL))
+ atmel_port->use_dma_rx = 1;
+ if (of_get_property(np, "atmel,use-dma-tx", NULL))
+ atmel_port->use_dma_tx = 1;
+ } else {
+ port->line = pdata->num;
+
+ atmel_port->use_dma_rx = pdata->use_dma_rx;
+ atmel_port->use_dma_tx = pdata->use_dma_tx;
+ atmel_port->rs485 = pdata->rs485;
+ }
port->iotype = UPIO_MEM;
port->flags = UPF_BOOT_AUTOCONF;
port->ops = &atmel_pops;
port->fifosize = 1;
- port->line = pdata->num;
port->dev = &pdev->dev;
port->mapbase = pdev->resource[0].start;
port->irq = pdev->resource[1].start;
@@ -1430,7 +1459,7 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
memset(&atmel_port->rx_ring, 0, sizeof(atmel_port->rx_ring));
- if (pdata->regs) {
+ if (pdata && pdata->regs) {
/* Already mapped by setup code */
port->membase = pdata->regs;
} else {
@@ -1447,10 +1476,6 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
/* only enable clock when USART is in use */
}
- atmel_port->use_dma_rx = pdata->use_dma_rx;
- atmel_port->use_dma_tx = pdata->use_dma_tx;
- atmel_port->rs485 = pdata->rs485;
-
/* Use TXEMPTY for interrupt when rs485 else TXRDY or ENDTX|TXBUFE */
if (atmel_port->rs485.flags & SER_RS485_ENABLED)
atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
@@ -1710,13 +1735,27 @@ static int atmel_serial_resume(struct platform_device *pdev)
static int __devinit atmel_serial_probe(struct platform_device *pdev)
{
struct atmel_uart_port *port;
+ struct device_node *np = pdev->dev.of_node;
struct atmel_uart_data *pdata = pdev->dev.platform_data;
void *data;
int ret;
BUILD_BUG_ON(ATMEL_SERIAL_RINGSIZE & (ATMEL_SERIAL_RINGSIZE - 1));
- port = &atmel_ports[pdata->num];
+ if (np) {
+ ret = of_alias_get_id(np, "serial");
+ if (ret < 0)
+ goto err;
+ } else {
+ if (pdata) {
+ ret = pdata->num;
+ } else {
+ ret = -ENODEV;
+ goto err;
+ }
+ }
+
+ port = &atmel_ports[ret];
port->backup_imr = 0;
atmel_init_port(port, pdev);
@@ -1763,7 +1802,7 @@ err_alloc_ring:
clk_put(port->clk);
port->clk = NULL;
}
-
+err:
return ret;
}
@@ -1796,6 +1835,7 @@ static struct platform_driver atmel_serial_driver = {
.driver = {
.name = "atmel_usart",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(atmel_serial_dt_ids),
},
};
--
1.7.3
^ permalink raw reply related
* [PATCH 02/30] video/omap: fix dependencies
From: Arnd Bergmann @ 2011-10-03 9:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317624830.2026.6.camel@deskari>
On Monday 03 October 2011 09:53:50 Tomi Valkeinen wrote:
> Your patch will conflict with both of those changes. Is it ok for you to
> drop this patch, and I'll make a new one on top of my changes to clean
> up the Makefile in a similar way than you did? The new patch wouldn't
> make it in the next merge window, though, but I don't think this patch
> is fixing any bigger bug, so perhaps it's not so urgent.
Sure, no problem. I'll put it into my "hacks" branch then, so I can
still do randconfig builds and we get back to it later.
Arnd
^ permalink raw reply
* [PATCH 08/30] ARM: omap2+: fix building without i2c
From: Arnd Bergmann @ 2011-10-03 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1110021928170.4611@utopia.booyaka.com>
On Sunday 02 October 2011 19:31:25 Paul Walmsley wrote:
> Nice catch. I think the bug is different, though. omap_i2c_reset should
> never be NULL: that code is intended to execute even when
> CONFIG_I2C_OMAP=n. The idea is to prevent the IP block from interfering
> with the rest of the kernel even if the driver is not compiled in, no
> matter how the bootloader or previous OS programmed the IP block.
>
> I'd suggest something like the following patch instead.
>
>
> - Paul
>
> From: Paul Walmsley <paul@pwsan.com>
> Date: Sun, 2 Oct 2011 19:15:10 -0600
> Subject: [PATCH] ARM: omap2+: fix build breakage when CONFIG_I2C_OMAP=n
>
> arch/arm/mach-omap2/Makefile incorrectly skips compilation of the I2C
> IP block reset code when CONFIG_I2C_OMAP=n. Fix by unconditionally
> compiling arch/arm/mach-omap2/i2c.o, which is needed on all OMAP2+ platforms.
>
> Problem noted by Arnd Bergmann <arnd@arndb.de>.
Ok, looks better. You should also drop patch 6 "ARM: omap: fix build with
CONFIG_I2C_OMAP disabled" then.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* [PATCH 3/3] tty/serial: atmel_serial: __devinit_p for probe function
From: Nicolas Ferre @ 2011-10-03 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4355360.0xR5ZY7sEk@wuerfel>
On 10/03/2011 11:36 AM, Arnd Bergmann :
> On Monday 03 October 2011 12:11:19 Nicolas Ferre wrote:
>> }
>>
>> static struct platform_driver atmel_serial_driver = {
>> - .probe = atmel_serial_probe,
>> + .probe = __devinit_p(atmel_serial_probe),
>> .remove = __devexit_p(atmel_serial_remove),
>> .suspend = atmel_serial_suspend,
>> .resume = atmel_serial_resume,
>
> Still wrong: __devinit_p does not exist and is not needed.
OMG, the not-enouth-coffee syndrome... twice!
So we forget all this and I try to increase my signal/noise ratio ;-)
Bye,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v2] OMAP2PLUS: DSS: Ensure DSS works correctly if display is enabled in bootloader
From: Cousson, Benoit @ 2011-10-03 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1317630070.2026.27.camel@deskari>
Hi Tomi,
On 10/3/2011 10:21 AM, Valkeinen, Tomi wrote:
> Hi Paul,
>
> On Sun, 2011-10-02 at 22:45 -0600, Paul Walmsley wrote:
[...]
>> +struct omap_dss_dispc_dev_attr {
>> + u8 manager_count;
>> + bool has_framedonetv_irq;
>> +};
>> +
>> +#endif
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>> index 09d9395..8e32cb3 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
>> @@ -945,6 +945,7 @@ static struct omap_hwmod omap2420_dss_dispc_hwmod = {
>> .slaves_cnt = ARRAY_SIZE(omap2420_dss_dispc_slaves),
>> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
>> .flags = HWMOD_NO_IDLEST,
>> + .dev_attr =&omap2_3_dss_dispc_dev_attr
>> };
>
> I didn't know you can add arbitrary data like that to hwmods. What kind
> of data is it meant for? Can the data be used by the driver, or is it
> meant just for arch stuff?
It was added in order to add HW related information for an IP.
So most of the time, this is use for IP version, since this information
is not necessarily accessible from the IP itself. Some time it can be
the number of entries in the mailbox IP that will change depending of
the version too.
> I'm wondering this as we have a complex mechanism in the dss driver to
> find out about the differences of DSS hardware
> (drivers/video/omap2/dss/dss_features.[ch]). The dss_features system is
> currently part of the driver, but should be moved under arch/arm/*omap*
> at some point, and this hwmod dev_attr sounds like it could possibly be
> a right place to handle these.
Please note that I made that kind of comment to Archit when he started
submitted this dss_feature series. That feature management mechanism
could have been useful for any other IPs / driver at that time.
> I looked at how the dev_attrs are used, and all of them seemed to be
> very small, a few fields at max. The DSS features set is, on the other
> hand, quite big amount of data, and meant for the driver.
That's why, most of the time, only the version is in the dev_attr, and
the various information that will depend of that version are stored in
the driver.
But at that time, device tree was not there...
Now, the whole dev_attr stuff will be replaced because device tree is
able to provide the driver any kind of custom information that can be
retrieved directly from the driver without having to use a pdata in
between. So I'm not sure it worth spending too much time on that feature
stuff.
As an example here is the ongoing GPIO DT migration:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg56505.html
3.2 will have the basic DT support using hwmod as a backend, but the
idea is that for 3.3, we start removing some information from hwmod to
rely on device tree only.
Regards,
Benoit
^ permalink raw reply
* [PATCH 3/3] tty/serial: atmel_serial: __devinit_p for probe function
From: Nicolas Ferre @ 2011-10-03 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b371e80a96a36d962fb8806c2bd7aa20bb688b88.1317634987.git.nicolas.ferre@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/tty/serial/atmel_serial.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index a652f8f..453cdb5 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1789,7 +1789,7 @@ static int __devexit atmel_serial_remove(struct platform_device *pdev)
}
static struct platform_driver atmel_serial_driver = {
- .probe = atmel_serial_probe,
+ .probe = __devexit_p(atmel_serial_probe),
.remove = __devexit_p(atmel_serial_remove),
.suspend = atmel_serial_suspend,
.resume = atmel_serial_resume,
--
1.7.3
^ permalink raw reply related
* [PATCH 2/3] tty/serial: atmel_serial: whitespace and braces modifications
From: Nicolas Ferre @ 2011-10-03 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b371e80a96a36d962fb8806c2bd7aa20bb688b88.1317634987.git.nicolas.ferre@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/tty/serial/atmel_serial.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 08b5273..a652f8f 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1430,10 +1430,10 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
memset(&atmel_port->rx_ring, 0, sizeof(atmel_port->rx_ring));
- if (pdata->regs)
+ if (pdata->regs) {
/* Already mapped by setup code */
port->membase = pdata->regs;
- else {
+ } else {
port->flags |= UPF_IOREMAP;
port->membase = NULL;
}
@@ -1447,9 +1447,10 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
/* only enable clock when USART is in use */
}
- atmel_port->use_dma_rx = pdata->use_dma_rx;
- atmel_port->use_dma_tx = pdata->use_dma_tx;
+ atmel_port->use_dma_rx = pdata->use_dma_rx;
+ atmel_port->use_dma_tx = pdata->use_dma_tx;
atmel_port->rs485 = pdata->rs485;
+
/* Use TXEMPTY for interrupt when rs485 else TXRDY or ENDTX|TXBUFE */
if (atmel_port->rs485.flags & SER_RS485_ENABLED)
atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
--
1.7.3
^ permalink raw reply related
* [PATCH 1/3] tty/serial: atmel_serial: change platform_data variable name
From: Nicolas Ferre @ 2011-10-03 9:46 UTC (permalink / raw)
To: linux-arm-kernel
Easier to follow if platform_data name is pdata.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
drivers/tty/serial/atmel_serial.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index af9b781..08b5273 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1414,13 +1414,13 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
struct platform_device *pdev)
{
struct uart_port *port = &atmel_port->uart;
- struct atmel_uart_data *data = pdev->dev.platform_data;
+ struct atmel_uart_data *pdata = pdev->dev.platform_data;
port->iotype = UPIO_MEM;
port->flags = UPF_BOOT_AUTOCONF;
port->ops = &atmel_pops;
port->fifosize = 1;
- port->line = data->num;
+ port->line = pdata->num;
port->dev = &pdev->dev;
port->mapbase = pdev->resource[0].start;
port->irq = pdev->resource[1].start;
@@ -1430,9 +1430,9 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
memset(&atmel_port->rx_ring, 0, sizeof(atmel_port->rx_ring));
- if (data->regs)
+ if (pdata->regs)
/* Already mapped by setup code */
- port->membase = data->regs;
+ port->membase = pdata->regs;
else {
port->flags |= UPF_IOREMAP;
port->membase = NULL;
@@ -1447,9 +1447,9 @@ static void __devinit atmel_init_port(struct atmel_uart_port *atmel_port,
/* only enable clock when USART is in use */
}
- atmel_port->use_dma_rx = data->use_dma_rx;
- atmel_port->use_dma_tx = data->use_dma_tx;
- atmel_port->rs485 = data->rs485;
+ atmel_port->use_dma_rx = pdata->use_dma_rx;
+ atmel_port->use_dma_tx = pdata->use_dma_tx;
+ atmel_port->rs485 = pdata->rs485;
/* Use TXEMPTY for interrupt when rs485 else TXRDY or ENDTX|TXBUFE */
if (atmel_port->rs485.flags & SER_RS485_ENABLED)
atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
--
1.7.3
^ permalink raw reply related
* [RFC] Need help deciphering reboot modes!
From: Will Deacon @ 2011-10-03 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110930191847.GA11710@n2100.arm.linux.org.uk>
Hi Russell,
Thanks for getting back to me.
On Fri, Sep 30, 2011 at 08:18:48PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 30, 2011 at 01:57:25PM +0100, Will Deacon wrote:
> > As part of my kexec work, I've been looking at the machine_restart path
> > on ARM and, more specifically, the use of the reboot_mode character that
> > gets passed around and ultimately ignored.
>
> It gets ignored because platform maintainers are a lazy bunch of people
> and don't want to write any more code than they absolutely have to.
>
> Overall, it is meant as a hint to the platform code about what reboot
> method to use.
Right, ok.
> > It seems that the following mode characters are used:
> >
> > 0 -> Currently used by kexec as a dummy argument given that it is
> > ignored anyway.
>
> No idea what that means, afaik it's never been used.
I think it's just a lazy kexec implementation. Passing 's' would make more
sense.
> > 'h' -> The default assignment to reboot_mode and that used by
> > machine_restart. For some reason, reboot_mode can also be
> > overridden on the command line. I would guess that this means
> > "hard".
>
> It does mean 'hard' and it tells platforms which have the option (the
> early ones do!) to use some hardware method to provoke the machine into
> rebooting.
So in terms of setup_mm_for_reboot (which takes the reboot mode as a
parameter), the 'h' mode should ensure that we don't remap kernelspace
as 1:1 because we need to poke hardware (alternatively we could poke the
hardware using its physical address).
> > 's' -> A supported option by mioa701 (mach-pxa) and mach-s3c24xx. I
> > would guess that this means "soft".
>
> This means to reboot by vectoring through the reset vector - so it is
> 'soft'.
And in this case we want to identity map as much as possible so the MMU-off
path works properly.
> > 'g' -> A supported option by spitz and tosa (both mach-pxa). I can't
> > begin to imagine what it might stand for.
>
> 'gpio', using a gpio signal to cause the reboot rather than setting up
> a watchdog or something to cause it.
Can we get rid of this option in favour of 'h'? I'm not sure I see the
distinction and I think the platform can handle it itself. I posted a patch
here but I'm unable to test it:
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-September/067560.html
> Note that as I say above, it is only a hint - if you pass 's' for soft,
> a platform can still elect to do a hard reboot if it knows that soft
> reboots just don't work on the platform.
Hmm, this could be problematic with the memory mapping bits I mentioned
above. Going from 's' -> 'h' will only work if physical addresses are used
to access the hardware and going from 'h' -> 's' will only work if the
physical address of the reset code is less than PAGE_OFFSET. We could
introduce a new flag for setup_mm_for_reboot, but that feels slightly
redundant given that we already have the mode option.
What do you reckon?
Cheers,
Will
^ permalink raw reply
* [PATCH 00/30] ARM/omap: omap specific randconfig fixes
From: Santosh Shilimkar @ 2011-10-03 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7246478.IyGHQ24uSq@wuerfel>
On Monday 03 October 2011 02:52 PM, Arnd Bergmann wrote:
> On Monday 03 October 2011 10:35:25 Santosh Shilimkar wrote:
>
>>> The entire set is also available from
>>> git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/omap
>>>
>>> but I have not yet pulled them into the for-next branch.
>>>
>> Do you have any scripts to create these randconfigs ?
>> These are useful to run on newer set of patches also to get all
>> builds right first place.
>
> Yes, see the for-next+randconfig branch of
> git://git.linaro.org/people/arnd/arm-soc.git. It has all my patches
> and a randconfig.sh script.
>
> Right now, I'm trying to get a baseline upstream, since I have around 150
> patches that are needed to always build ten platforms successfully.
>
Ok. Will have a look at it.
> The main problem is that you basically need all the patches I did in order
> to find regressions, and some of the device driver patches are not currently
> in a state where I could submit them. I hope that by the time of the 3.3
> merge window, I have enough patches upstream that you no longer need to
> pull in an extra tree.
>
Sounds like a plan and having these scripts working on mainline kernel
would be really great to test new set dependencies.
Thanks a lot for the patches.
Segards
Santosh
^ permalink raw reply
* [PATCH] ARM: S3C2410: Remove section mismatch warning
From: Tushar Behera @ 2011-10-03 9:40 UTC (permalink / raw)
To: linux-arm-kernel
Some of the functions and structures did not have _init or __initdata
attributes, even though they were referenced from functions / structures
with those attribute, resulting in section mismatches.
Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
---
The patch is rebased on v3.1-rc8.
The patch has only been build tested, they are not boot tested on any
hardware.
arch/arm/mach-s3c2410/usb-simtec.c | 2 +-
arch/arm/mach-s3c2410/usb-simtec.h | 2 +-
arch/arm/mach-s3c2416/irq.c | 2 +-
arch/arm/mach-s3c2440/clock.c | 4 ++--
arch/arm/mach-s3c2443/irq.c | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-s3c2410/usb-simtec.c b/arch/arm/mach-s3c2410/usb-simtec.c
index 29bd3d9..3a1028c 100644
--- a/arch/arm/mach-s3c2410/usb-simtec.c
+++ b/arch/arm/mach-s3c2410/usb-simtec.c
@@ -104,7 +104,7 @@ static struct s3c2410_hcd_info usb_simtec_info __initdata = {
};
-int usb_simtec_init(void)
+int __init usb_simtec_init(void)
{
int ret;
diff --git a/arch/arm/mach-s3c2410/usb-simtec.h b/arch/arm/mach-s3c2410/usb-simtec.h
index 03842ed..43cc88f 100644
--- a/arch/arm/mach-s3c2410/usb-simtec.h
+++ b/arch/arm/mach-s3c2410/usb-simtec.h
@@ -12,5 +12,5 @@
* published by the Free Software Foundation.
*/
-extern int usb_simtec_init(void);
+extern int __init usb_simtec_init(void);
diff --git a/arch/arm/mach-s3c2416/irq.c b/arch/arm/mach-s3c2416/irq.c
index 28ad20d..153cb2f 100644
--- a/arch/arm/mach-s3c2416/irq.c
+++ b/arch/arm/mach-s3c2416/irq.c
@@ -234,7 +234,7 @@ static int __init s3c2416_irq_add(struct sys_device *sysdev)
return 0;
}
-static struct sysdev_driver s3c2416_irq_driver = {
+static struct sysdev_driver s3c2416_irq_driver __initdata = {
.add = s3c2416_irq_add,
};
diff --git a/arch/arm/mach-s3c2440/clock.c b/arch/arm/mach-s3c2440/clock.c
index f9e6bda..3b3bec5 100644
--- a/arch/arm/mach-s3c2440/clock.c
+++ b/arch/arm/mach-s3c2440/clock.c
@@ -108,7 +108,7 @@ static struct clk s3c2440_clk_ac97 = {
.ctrlbit = S3C2440_CLKCON_CAMERA,
};
-static int s3c2440_clk_add(struct sys_device *sysdev)
+static int __init s3c2440_clk_add(struct sys_device *sysdev)
{
struct clk *clock_upll;
struct clk *clock_h;
@@ -137,7 +137,7 @@ static int s3c2440_clk_add(struct sys_device *sysdev)
return 0;
}
-static struct sysdev_driver s3c2440_clk_driver = {
+static struct sysdev_driver s3c2440_clk_driver __initdata = {
.add = s3c2440_clk_add,
};
diff --git a/arch/arm/mach-s3c2443/irq.c b/arch/arm/mach-s3c2443/irq.c
index 83ecb11..1d483d9 100644
--- a/arch/arm/mach-s3c2443/irq.c
+++ b/arch/arm/mach-s3c2443/irq.c
@@ -265,7 +265,7 @@ static int __init s3c2443_irq_add(struct sys_device *sysdev)
return 0;
}
-static struct sysdev_driver s3c2443_irq_driver = {
+static struct sysdev_driver s3c2443_irq_driver __initdata = {
.add = s3c2443_irq_add,
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH 15/30] usb/musb: use a Kconfig choice to pick the right DMA method
From: Arnd Bergmann @ 2011-10-03 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111002221050.GA25790@legolas.emea.dhcp.ti.com>
On Monday 03 October 2011 01:10:51 Felipe Balbi wrote:
> Anyway, I'll take your patches in, but their too late for this merge
> window I already sent my last pull to Greg.
No problem. I need the full set of arm-randconfig patches upstream in order
to make randconfig work in general, and that's not happening for 3.2
anyway. Right now, I'm just trying to as many patches as possible into
maintainer trees.
Is your tree part of linux-next, or will it only show up after the merge
window once Greg has pulled your first set for 3.3?
Arnd
^ permalink raw reply
* [PATCH 3/3] tty/serial: atmel_serial: __devinit_p for probe function
From: Arnd Bergmann @ 2011-10-03 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d7c2023edfbeb3d21bccd5b997f7806874b01b04.1317636473.git.nicolas.ferre@atmel.com>
On Monday 03 October 2011 12:11:19 Nicolas Ferre wrote:
> }
>
> static struct platform_driver atmel_serial_driver = {
> - .probe = atmel_serial_probe,
> + .probe = __devinit_p(atmel_serial_probe),
> .remove = __devexit_p(atmel_serial_remove),
> .suspend = atmel_serial_suspend,
> .resume = atmel_serial_resume,
Still wrong: __devinit_p does not exist and is not needed.
What bug are you trying to fix here?
Arnd
^ permalink raw reply
* [PATCH 28/30] ARM: omap: select CPU_FREQ_TABLE where needed
From: Santosh Shilimkar @ 2011-10-03 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5173921.eT2vCfT35d@wuerfel>
On Monday 03 October 2011 02:45 PM, Arnd Bergmann wrote:
> On Monday 03 October 2011 11:09:33 Santosh Shilimkar wrote:
>>> diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
>>> index bb8f4a6..f7ef9f4 100644
>>> --- a/arch/arm/plat-omap/Kconfig
>>> +++ b/arch/arm/plat-omap/Kconfig
>>> @@ -217,6 +217,11 @@ config OMAP_PM_NOOP
>>>
>>> endchoice
>>>
>>> +config OMAP_CPU_FREQ
>>> + def_bool "y"
>>> + depends on CPU_FREQ
>>> + select CPU_FREQ_TABLE
>>> +
>>> endmenu
>> With CPUFREQ series from Kevin [1], I don't think we need this any-more.
>
> I guess if it's needed, it should at least be moved to the new cpufreq
> location.
>
Probably you are right. CPU_FREQ_TABLE is selected today if
CPU_FREQ_STAT or CPU_FREQ_GOV_ONDEMAND is selected. Without these two
enabled, in won't be selected.
>> More so, I didn't find OMAP_CPU_FREQ is being used anywhere on mainline.
>
> Yes, OMAP_CPU_FREQ is a symbol that is intentionally unused, with the
> only purpose of selecting CPU_FREQ_TABLE if any omap platform together
> with CPU_FREQ is enabled.
>
I see. This wasn't clear to me.
> Let's drop this patch for now, if it is still needed as I think, I can
> do a patch during the 3.2 cycle for the right location.
>
Ok.
Regards
Santosh
^ permalink raw reply
* [PATCH] ARM: EXYNOS: Add ARCH_EXYNOS and reorganize arch/arm/mach-exynos
From: Arnd Bergmann @ 2011-10-03 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAH9JG2UNwZxDTPnwjohxhCumKZx_mWcPUn2rROjmjmROoxF07w@mail.gmail.com>
On Monday 03 October 2011 13:02:16 Kyungmin Park wrote:
> I'm afraid to change machine directory name again. mach-s5pv310 ->
> mach-exynos4 -> mach-exynos.
> As I remember linus blamed the renaming the file names are happened
> frequently at ARM
I tend to agree with this. While the new name does make more sense,
I would first like to see the bigger plan. If you are eventually
planning to consolidate all of mach-s5p64x0, mach-s5pc100, mach-s5pv210,
mach-exynos4 and plat-s5p into one common mach-s5p or mach-exynos
directory, I'm all for that because it reduces code duplication
and work required for the overall cross-subarchitecture single zimage
work.
Simply renaming something because the name does not quite fit entirely
should be done very carefully.
Arnd
^ permalink raw reply
* [PATCH 26/30] ARM: omap: add board autoselection
From: Cousson, Benoit @ 2011-10-03 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3656685.pM1zNST8gQ@wuerfel>
On 10/3/2011 11:11 AM, Arnd Bergmann wrote:
> On Monday 03 October 2011 10:58:23 Santosh Shilimkar wrote:
>>> +config MACH_OMAP_AUTO_BOARD
>>> + def_bool y
>>> + depends on !MACH_OMAP2_TUSB6010
>>> + depends on !MACH_OMAP_H4
>>> + depends on !MACH_OMAP_APOLLON
>>> + depends on !MACH_OMAP_APOLLON
>>> + depends on !MACH_OMAP_2430SDP
>>> + depends on !MACH_OMAP3_BEAGLE
>>> + depends on !MACH_DEVKIT8000
>>> + depends on !MACH_OMAP_LDP
>>> + depends on !MACH_OMAP3530_LV_SOM
>>> + depends on !MACH_OMAP3_TORPEDO
>>> + depends on !MACH_OVERO
>>> + depends on !MACH_OMAP3EVM
>>> + depends on !MACH_OMAP3517EVM
>>> + depends on !MACH_CRANEBOARD
>>> + depends on !MACH_OMAP3_PANDORA
>>> + depends on !MACH_OMAP3_TOUCHBOOK
>>> + depends on !MACH_NOKIA_N8X0
>>> + depends on !MACH_NOKIA_RM680
>>> + depends on !MACH_NOKIA_RX51
>>> + depends on !MACH_OMAP_ZOOM2
>>> + depends on !MACH_OMAP_ZOOM3
>>> + depends on !MACH_CM_T35
>>> + depends on !MACH_CM_T3517
>>> + depends on !MACH_IGEP0020
>>> + depends on !MACH_IGEP0030
>>> + depends on !MACH_SBC3530
>>> + depends on !MACH_OMAP_3630SDP
>>> + depends on !MACH_TI8168EVM
>>> + depends on !MACH_OMAP4_PANDA
>> Do we need all above 'depends on *' ?
>> Even if they get selected for one of the below
>> ARCH along with default machine, build should be happy.
>> Right ?
>
> I'm not too happy with having to maintain a list for each subarchitecture,
> when each one has the same problem. In general, I would really like to have
> the flexibility to disable all but any one board, which requires either
> maintaining a list like the above, or expressing the same like
>
> config MACH_OMAP_AUTO_BOARD
> def_bool y
> depends on !MACH_OMAP_BOARD_SELECTED
> select MACH_OMAP_GENERIC if ARCH_OMAP2
> select MACH_OMAP_3430SDP if ARCH_OMAP3&& !ARCH_OMAP2
> select MACH_OMAP_4430SDP if ARCH_OMAP4&& !ARCH_OMAP3&& !ARCH_OMAP2
>
> and adding a 'select MACH_OMAP_BOARD_SELECTED' for each one. Slightly more
> to write but perhaps a little less error-prone.
>
> In the long run, I'd hope we can just get rid of these for subarchitectures
> that support device tree probing and make the device tree based machine
> description unconditional.
This is really our goal, we will have soon the board-generic.c for that,
someone will *just* have to migrate these ~30 board files to device tree
DTS files :-)
Regards,
Benoit
^ permalink raw reply
* [PATCH 2/3] define ARM-specific dma_coherent_write_sync
From: Jon Masters @ 2011-10-03 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111003084407.GC18195@e102109-lin.cambridge.arm.com>
On Oct 3, 2011, at 4:44 AM, Catalin Marinas wrote:
> On Mon, Oct 03, 2011 at 02:40:19AM +0100, Jon Masters wrote:
>> On Sep 6, 2011, at 11:02 AM, Mark Salter wrote:
>>> In any case, the current thinking is that the original problem with
>>> the USB performance seen on cortex A9 multicore is probably something
>>> more than just write buffer delays. Once the original problem is better
>>> understood, we can take another look at this patch if it is still
>>> needed.
>>
>> Thanks again for looking into this Mark. My understanding is that this
>> is still being investigated. I'll followup with ARM to see how that's
>> going since I've heard nothing recently :) Meanwhile, we're continuing
>> to carry a hack based on these patches in Fedora ARM kernels.
>
> Not talking about hardware specifics here, the architecture (though
> ARMv7 onwards) mandates that the write buffer is eventually drained. But
> doesn't state any upper limit, so it could even be half a second.
<snip mechanics of dma_coherent_write_sync, etc.>
I guess my main question is, do you think this is just a write buffer delay? If you do, then we should definitely get back to this question of defining DMA extensions. But are we sure that's what this is?
Mark: did you have any more insight into this recently?
Jon.
^ permalink raw reply
* [PATCH 00/30] ARM/omap: omap specific randconfig fixes
From: Arnd Bergmann @ 2011-10-03 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E894295.5000608@ti.com>
On Monday 03 October 2011 10:35:25 Santosh Shilimkar wrote:
> > The entire set is also available from
> > git pull git://git.linaro.org/people/arnd/arm-soc.git randconfig/omap
> >
> > but I have not yet pulled them into the for-next branch.
> >
> Do you have any scripts to create these randconfigs ?
> These are useful to run on newer set of patches also to get all
> builds right first place.
Yes, see the for-next+randconfig branch of
git://git.linaro.org/people/arnd/arm-soc.git. It has all my patches
and a randconfig.sh script.
Right now, I'm trying to get a baseline upstream, since I have around 150
patches that are needed to always build ten platforms successfully.
The main problem is that you basically need all the patches I did in order
to find regressions, and some of the device driver patches are not currently
in a state where I could submit them. I hope that by the time of the 3.3
merge window, I have enough patches upstream that you no longer need to
pull in an extra tree.
Thanks a lot for your review of the omap set!
Arnd
^ permalink raw reply
* [PATCH 26/30] ARM: omap: add board autoselection
From: Santosh Shilimkar @ 2011-10-03 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3656685.pM1zNST8gQ@wuerfel>
On Monday 03 October 2011 02:41 PM, Arnd Bergmann wrote:
> On Monday 03 October 2011 10:58:23 Santosh Shilimkar wrote:
>>> +config MACH_OMAP_AUTO_BOARD
>>> + def_bool y
>>> + depends on !MACH_OMAP2_TUSB6010
>>> + depends on !MACH_OMAP_H4
>>> + depends on !MACH_OMAP_APOLLON
>>> + depends on !MACH_OMAP_APOLLON
>>> + depends on !MACH_OMAP_2430SDP
>>> + depends on !MACH_OMAP3_BEAGLE
>>> + depends on !MACH_DEVKIT8000
>>> + depends on !MACH_OMAP_LDP
>>> + depends on !MACH_OMAP3530_LV_SOM
>>> + depends on !MACH_OMAP3_TORPEDO
>>> + depends on !MACH_OVERO
>>> + depends on !MACH_OMAP3EVM
>>> + depends on !MACH_OMAP3517EVM
>>> + depends on !MACH_CRANEBOARD
>>> + depends on !MACH_OMAP3_PANDORA
>>> + depends on !MACH_OMAP3_TOUCHBOOK
>>> + depends on !MACH_NOKIA_N8X0
>>> + depends on !MACH_NOKIA_RM680
>>> + depends on !MACH_NOKIA_RX51
>>> + depends on !MACH_OMAP_ZOOM2
>>> + depends on !MACH_OMAP_ZOOM3
>>> + depends on !MACH_CM_T35
>>> + depends on !MACH_CM_T3517
>>> + depends on !MACH_IGEP0020
>>> + depends on !MACH_IGEP0030
>>> + depends on !MACH_SBC3530
>>> + depends on !MACH_OMAP_3630SDP
>>> + depends on !MACH_TI8168EVM
>>> + depends on !MACH_OMAP4_PANDA
>> Do we need all above 'depends on *' ?
>> Even if they get selected for one of the below
>> ARCH along with default machine, build should be happy.
>> Right ?
>
> I'm not too happy with having to maintain a list for each subarchitecture,
> when each one has the same problem. In general, I would really like to have
> the flexibility to disable all but any one board, which requires either
> maintaining a list like the above, or expressing the same like
>
Ok.
> config MACH_OMAP_AUTO_BOARD
> def_bool y
> depends on !MACH_OMAP_BOARD_SELECTED
> select MACH_OMAP_GENERIC if ARCH_OMAP2
> select MACH_OMAP_3430SDP if ARCH_OMAP3 && !ARCH_OMAP2
> select MACH_OMAP_4430SDP if ARCH_OMAP4 && !ARCH_OMAP3 && !ARCH_OMAP2
>
> and adding a 'select MACH_OMAP_BOARD_SELECTED' for each one. Slightly more
> to write but perhaps a little less error-prone.
>
> In the long run, I'd hope we can just get rid of these for subarchitectures
> that support device tree probing and make the device tree based machine
> description unconditional.
>
I see your point. Sounds a good idea to me.
Regards
Santosh
^ permalink raw reply
* [PATCH 20/30] media/omap_vout: disable driver for now
From: Arnd Bergmann @ 2011-10-03 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E8951B7.7010106@ti.com>
On Monday 03 October 2011 11:39:59 Archit Taneja wrote:
>
> A fix for this is already in the master branch of Mauro's tree:
>
> git://linuxtv.org/media_tree.git
>
> with the commit id:
>
> 5ebbf72dc51bd3b481aa91fea37a7157da5fc548
>
> I am guessing this would during the 3.2 merge window.
Ok, thanks for the info! We can drop this then.
Arnd
^ 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