* [PATCH 4/9] ARM: SPMP8000: Add ADC driver
From: Russell King - ARM Linux @ 2011-10-13 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013113506.GJ1098@sirena.org.uk>
On Thu, Oct 13, 2011 at 12:35:06PM +0100, Mark Brown wrote:
> On Thu, Oct 13, 2011 at 10:47:17AM +0100, Russell King - ARM Linux wrote:
> > On Mon, Oct 10, 2011 at 12:44:08PM +0100, Mark Brown wrote:
>
> > > At the minute it seems to me that arch/arm is as good a place as any
> > > really - currently this code is getting dumped wherever the main device
> > > is.
>
> > No it isn't - we want drivers out of arch/arm (it's already been a topic
> > of flame for Linus, so it's something that we should try _really_ hard
> > to avoid.)
>
> I said it was as good a place as any, I didn't say it was a good place.
I'm saying it is a *BAD* place. I'm saying that we've been flamed over
this several times before. We need to change our behaviour RIGHT NOW,
not continue on ignoring the problem, and demonstrating to Linus that
we don't take his concerns seriously.
If we can't find a place for it that's outside of arch/arm, then it
doesn't go in.
> I think we should just carry on as we are while the IIO work proceeds,
> either we'll decide that that's the way forward and we can then kick all
> the ADCs into there or we'll get fed up, decide that's never going to
> work then go and can do something else.
You mean like other stuff which is already in the kernel gets fixed?
It doesn't get fixed. We persist with per-driver private data structures
which multiply all over the place.
Look at what happened with MTD and the flash_platform_data structure.
That got ignored and instead people just continued merrily creating their
own private crap time and time again.
We can not continue like this. We can not continue to be soo permissive.
I'm now saying a big NO to this - I don't care that the "cat is already
out of the bag" - that's a defeatest attitude. I'm saying no *now* so
that there _is_ some kind of movement towards fixing this problem. I
don't care whether that means it shares an existing ADC drivers callback
data structures or what - I just don't want to see yet another driver
private data structure being created for NO REASON what so ever.
Or maybe you'd like to be on the receiving end of another Linus flame?
Some people would like to avoid such things - maybe you feed off them,
that's your decision. I personally am on the side of the folk who'd
like to avoid being on the receiving end of the next Linus flame.
So. No new drivers in arch/arm. And I'm going to be saying no to any
new per-driver data structures in mach/*.h for stuff which should be
generic which haven't been justified for why they need to be different
from someone elses.
^ permalink raw reply
* [PATCH] arm: fix handling of nr_cpus
From: Mark Salter @ 2011-10-13 12:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111012172628.GC21648@n2100.arm.linux.org.uk>
On Wed, 2011-10-12 at 18:26 +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 11, 2011 at 09:31:04AM -0400, Mark Salter wrote:
> > The current code duplicates the setup of the cpu_possible bitmap in the
> > platform smp_init_cpus() function. Unfortunately, all of those places
> > have the same bug where the nr_cpus kernel parameter is ignored. This patch
> > consolidates the duplicated code in one place and fixes it to honor the
> > nr_cpus parameter. This is accomplished by having smp_init_cpus() return
> > the platform specific number of cores so that the caller (setup_arch) can
> > set up the cpu_possible bitmap correctly for all platforms.
>
> Who says every platform we're going to see will always have CPUs 0..N ?
> It's entirely possible that someone might want to have CPUs 0, 2, 3 as
> possible CPUs but omit CPU1 for platform reasons.
Good point. We could do that by not setting the cpu_present bit for the
CPU we want to omit. Or we could leave the current platform cpu_possible
setup as-is and add something like:
for (i = nr_cpu_ids; i < NR_CPUS; i++)
set_cpu_possible(i, false);
to setup_arch after the call to smp_init_cpus.
--Mark
^ permalink raw reply
* [PATCH v9 0/3] Add support for tegra2 based ventana board
From: Peter De Schrijver @ 2011-10-13 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111012223643.GA5368@quad.lixom.net>
On Thu, Oct 13, 2011 at 12:36:43AM +0200, Olof Johansson wrote:
> On Wed, Oct 12, 2011 at 08:56:47AM -0700, Stephen Warren wrote:
> > pdeschrijver at nvidia.com wrote at Wednesday, October 12, 2011 5:53 AM:
> > > This patch set adds support for the tegra2 based ventana development board.
> > >
> > > Boot tested on ventana.
> > >
> > > Uses a table based approach to select the correct init function.
> > >
> > > Provoke kernel warning when no suitable pinmux table can be found.
> >
> > Whole series:
> >
> > Acked-by: Stephen Warren <swarren@nvidia.com>
> >
> > Thanks for following up on my picky comments:-)
>
> Yes, thanks Peter.
>
> Applied to for-3.2/features. I had to do some fixups since I applied it
> on top of some of Stephen's changes for gpio/pinmux, so please verify
> that I did the fixups correctly.
I just booted your tree on ventana. Works fine! Thanks!
Peter.
^ permalink raw reply
* [PATCH] ARM imx51: Add Armadeus systems APF51 support
From: julien.boibessot at free.fr @ 2011-10-13 13:33 UTC (permalink / raw)
To: linux-arm-kernel
From: Julien Boibessot <julien.boibessot@armadeus.com>
The APF51 is an i.M51 based System On Module that can be plugged on
several docking/development boards. Here only basic module support
is added (Ethernet, Serial, I2C & PMIC (Wolfson's WM8311)).
Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com>
Signed-off-by: Nicolas Colombain <nicolas.colombain@armadeus.com>
---
arch/arm/mach-mx5/Kconfig | 10 ++
arch/arm/mach-mx5/Makefile | 1 +
arch/arm/mach-mx5/board-apf51.c | 195 +++++++++++++++++++++++++++
arch/arm/plat-mxc/include/mach/uncompress.h | 4 +
4 files changed, 210 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mx5/board-apf51.c
diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
index 3d4c313..91400f3 100644
--- a/arch/arm/mach-mx5/Kconfig
+++ b/arch/arm/mach-mx5/Kconfig
@@ -169,6 +169,16 @@ config MACH_MX51_EFIKASB
Include support for Genesi Efika Smartbook. This includes specific
configurations for the board and its peripherals.
+config MACH_APF51
+ bool "Support Armadeus APF51 System On Module"
+ select SOC_IMX51
+ select IMX_HAVE_PLATFORM_IMX_UART
+ select IMX_HAVE_PLATFORM_IMX_I2C
+ select IMX_HAVE_PLATFORM_IMX2_WDT
+ help
+ Include support for Armadeus systems APF51 System On Module. This
+ includes specific configurations for the board and its peripherals.
+
comment "i.MX53 machines:"
config MACH_MX53_EVK
diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
index 9565304..1415913 100644
--- a/arch/arm/mach-mx5/Makefile
+++ b/arch/arm/mach-mx5/Makefile
@@ -21,3 +21,4 @@ obj-$(CONFIG_MX51_EFIKA_COMMON) += mx51_efika.o
obj-$(CONFIG_MACH_MX51_EFIKAMX) += board-mx51_efikamx.o
obj-$(CONFIG_MACH_MX51_EFIKASB) += board-mx51_efikasb.o
obj-$(CONFIG_MACH_MX50_RDP) += board-mx50_rdp.o
+obj-$(CONFIG_MACH_APF51) += board-apf51.o
diff --git a/arch/arm/mach-mx5/board-apf51.c b/arch/arm/mach-mx5/board-apf51.c
new file mode 100644
index 0000000..f3f22da
--- /dev/null
+++ b/arch/arm/mach-mx5/board-apf51.c
@@ -0,0 +1,195 @@
+/*
+ * Support for APF51 System On Module
+ * Copyright (C) 2010-2011 Armadeus systems <support@armadeus.com>
+ *
+ * Based on code which is:
+ * Copyright 2009-2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright (C) 2009-2010 Amit Kucheria <amit.kucheria@canonical.com>
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/gpio.h>
+#include <linux/irq.h>
+#include <linux/mfd/wm831x/core.h>
+#include <linux/mfd/wm831x/pdata.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/time.h>
+
+#include <mach/common.h>
+#include <mach/iomux-mx51.h>
+
+#include "devices-imx51.h"
+
+static iomux_v3_cfg_t apf51_pads[] = {
+ /* UART3 (Console) */
+ MX51_PAD_UART3_RXD__UART3_RXD,
+ MX51_PAD_UART3_TXD__UART3_TXD,
+
+ /* FEC */
+ MX51_PAD_DI_GP3__FEC_TX_ER,
+ MX51_PAD_DI2_PIN4__FEC_CRS,
+ MX51_PAD_DI2_PIN2__FEC_MDC,
+ MX51_PAD_DI2_PIN3__FEC_MDIO,
+ MX51_PAD_DI2_DISP_CLK__FEC_RDATA1,
+ MX51_PAD_DI_GP4__FEC_RDATA2,
+ MX51_PAD_DISP2_DAT0__FEC_RDATA3,
+ MX51_PAD_DISP2_DAT1__FEC_RX_ER,
+ MX51_PAD_DISP2_DAT6__FEC_TDATA1,
+ MX51_PAD_DISP2_DAT7__FEC_TDATA2,
+ MX51_PAD_DISP2_DAT8__FEC_TDATA3,
+ MX51_PAD_DISP2_DAT9__FEC_TX_EN,
+ MX51_PAD_DISP2_DAT10__FEC_COL,
+ MX51_PAD_DISP2_DAT11__FEC_RX_CLK,
+ MX51_PAD_DISP2_DAT12__FEC_RX_DV,
+ MX51_PAD_DISP2_DAT13__FEC_TX_CLK,
+ MX51_PAD_DISP2_DAT14__FEC_RDATA0,
+ MX51_PAD_DISP2_DAT15__FEC_TDATA0,
+ MX51_PAD_DI1_PIN11__GPIO3_0, /* FEC PHY reset line */
+
+ /* I2C2 */
+ MX51_PAD_EIM_D24__I2C2_SDA,
+ MX51_PAD_EIM_D27__I2C2_SCL,
+
+ /* PMIC */
+ MX51_PAD_GPIO1_4__GPIO1_4, /* WM8311 TOUCH_DETECT */
+ MX51_PAD_GPIO1_6__GPIO1_6, /* WM8311 TOUCH_EOC */
+ MX51_PAD_GPIO1_7__GPIO1_7, /* WM8311 IRQ */
+};
+
+#ifdef CONFIG_MFD_WM831X_I2C
+/* APF51 has a Wolfson PMIC on I2C2 */
+
+#define APF51_WM8311_TOUCH_DETECT_GPIO IMX_GPIO_NR(1, 4)
+#define APF51_WM8311_TOUCH_EOC_GPIO IMX_GPIO_NR(1, 6)
+#define APF51_WM8311_IRQ_GPIO IMX_GPIO_NR(1, 7)
+
+static struct gpio apf51_wm8311_gpios[] = {
+ { APF51_WM8311_IRQ_GPIO, GPIOF_IN, "wm8311_irq" },
+ { APF51_WM8311_TOUCH_DETECT_GPIO, GPIOF_IN, "wm8311_touch_detect" },
+ { APF51_WM8311_TOUCH_EOC_GPIO, GPIOF_IN, "wm8311_touch_eoc" },
+};
+
+static int apf51_wm8311_pre_init(struct wm831x *wm831x)
+{
+ int ret;
+
+ ret = gpio_request_array(apf51_wm8311_gpios,
+ ARRAY_SIZE(apf51_wm8311_gpios));
+ if (ret) {
+ pr_err("failed to get WM8311 GPIOs: %d\n", ret);
+ return ret;
+ }
+
+ irq_set_irq_type(gpio_to_irq(APF51_WM8311_IRQ_GPIO),
+ IRQF_TRIGGER_FALLING);
+ irq_set_irq_type(gpio_to_irq(APF51_WM8311_TOUCH_DETECT_GPIO),
+ IRQF_TRIGGER_FALLING);
+ irq_set_irq_type(gpio_to_irq(APF51_WM8311_TOUCH_EOC_GPIO),
+ IRQF_TRIGGER_FALLING);
+
+ return 0;
+}
+
+static int apf51_wm8311_post_init(struct wm831x *wm831x)
+{
+ /* Configure GPIO6: input, pwdmn 0, inverted, CMOS, enable, pullup */
+ wm831x_reg_write(wm831x, WM831X_GPIO6_CONTROL, 0xc080);
+
+ return 0;
+}
+
+static struct wm831x_status_pdata apf51_wm8311_led1_pdata = {
+ .default_src = WM831X_STATUS_PRESERVE,
+ .name = "LED1:red:",
+};
+
+static struct wm831x_status_pdata apf51_wm8311_led2_pdata = {
+ .default_src = WM831X_STATUS_PRESERVE,
+ .name = "LED2:green:",
+};
+
+static struct wm831x_touch_pdata apf51_wm8311_touch_pdata = {
+ .fivewire = 0,
+ .pressure = 1,
+ .data_irq = IMX_GPIO_TO_IRQ(APF51_WM8311_TOUCH_EOC_GPIO),
+ .pd_irq = IMX_GPIO_TO_IRQ(APF51_WM8311_TOUCH_DETECT_GPIO),
+};
+
+static struct wm831x_pdata apf51_wm8311_pdata = {
+ .pre_init = apf51_wm8311_pre_init,
+ .post_init = apf51_wm8311_post_init,
+ .irq_cmos = 1,
+ .irq_base = MXC_BOARD_IRQ_START,
+ .status = {
+ &apf51_wm8311_led1_pdata,
+ &apf51_wm8311_led2_pdata,
+ },
+ .touch = &apf51_wm8311_touch_pdata,
+};
+#endif /* CONFIG_MFD_WM831X_I2C */
+
+static const struct imxi2c_platform_data apf51_i2c1_data __initconst = {
+ .bitrate = 400000,
+};
+
+static struct i2c_board_info apf51_i2c1_devices[] __initdata = {
+#ifdef CONFIG_MFD_WM831X_I2C
+ {
+ I2C_BOARD_INFO("wm8311", 0x36),
+ .platform_data = &apf51_wm8311_pdata,
+ .irq = IMX_GPIO_TO_IRQ(APF51_WM8311_IRQ_GPIO),
+ },
+#endif
+};
+
+/*
+ * Board specific initialization.
+ */
+static void __init apf51_board_init(void)
+{
+ imx51_soc_init();
+
+#if defined(CONFIG_CPU_FREQ_IMX)
+ get_cpu_op = mx51_get_cpu_op;
+#endif
+ mxc_iomux_v3_setup_multiple_pads(apf51_pads,
+ ARRAY_SIZE(apf51_pads));
+
+ imx51_add_imx_uart(2, NULL);
+
+ imx51_add_imx_i2c(1, &apf51_i2c1_data);
+ i2c_register_board_info(1, apf51_i2c1_devices,
+ ARRAY_SIZE(apf51_i2c1_devices));
+
+ imx51_add_fec(NULL);
+
+ imx51_add_imx2_wdt(0, NULL);
+}
+
+static void __init apf51_timer_init(void)
+{
+ mx51_clocks_init(32768, 32768*1024, 0, 0);
+}
+
+static struct sys_timer apf51_timer = {
+ .init = apf51_timer_init,
+};
+
+MACHINE_START(APF51, "Armadeus APF51")
+ /* Maintainer: Julien Boibessot <julien.boibessot@armadeus.com> */
+ .map_io = mx51_map_io,
+ .init_early = imx51_init_early,
+ .init_irq = mx51_init_irq,
+ .timer = &apf51_timer,
+ .init_machine = apf51_board_init,
+MACHINE_END
diff --git a/arch/arm/plat-mxc/include/mach/uncompress.h b/arch/arm/plat-mxc/include/mach/uncompress.h
index 88fd404..09ac3ea 100644
--- a/arch/arm/plat-mxc/include/mach/uncompress.h
+++ b/arch/arm/plat-mxc/include/mach/uncompress.h
@@ -64,6 +64,7 @@ static inline void flush(void)
#define MX3X_UART2_BASE_ADDR 0x43F94000
#define MX3X_UART5_BASE_ADDR 0x43FB4000
#define MX51_UART1_BASE_ADDR 0x73fbc000
+#define MX51_UART3_BASE_ADDR 0x7000c000
#define MX50_UART1_BASE_ADDR 0x53fbc000
#define MX53_UART1_BASE_ADDR 0x53fbc000
@@ -111,6 +112,9 @@ static __inline__ void __arch_decomp_setup(unsigned long arch_id)
case MACH_TYPE_MX51_3DS:
uart_base = MX51_UART1_BASE_ADDR;
break;
+ case MACH_TYPE_APF51:
+ uart_base = MX51_UART3_BASE_ADDR;
+ break;
case MACH_TYPE_MX50_RDP:
uart_base = MX50_UART1_BASE_ADDR;
break;
--
1.7.4.1
^ permalink raw reply related
* [GIT PULL] DEBUG_LL platform updates for 3.2
From: Nicolas Pitre @ 2011-10-13 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013082836.GG21648@n2100.arm.linux.org.uk>
On Thu, 13 Oct 2011, Russell King - ARM Linux wrote:
> On Wed, Oct 12, 2011 at 10:30:11AM +0200, Arnd Bergmann wrote:
> > On Tuesday 11 October 2011 20:03:38 Nicolas Pitre wrote:
> > > On Tue, 11 Oct 2011, Arnd Bergmann wrote:
> > >
> > > > I've stuck them into the arm-soc tree for now, so we get linux-next
> > > > coverage, but I won't send them to Linus this way because then we
> > > > would get the same commits twice in the history.
> > >
> > > Could you please do the same with the following:
> > >
> > > git://git.linaro.org/people/nico/linux.git mach_memory_h
> > >
> > > Russell pulled it at some point, and dropped it due to concerns about
> > > repeated conflict resolutions (or so I presume). I just did a test
> > > merge between your for-next branch and the above and that looked trivial
> > > enough.
> >
> > Ok, done.
>
> Bypassing maintainers stinks - especially when there are unaddressed
> comments outstanding. Nicolas has "simplified" my objections in this
> request for you to pull - and has completely ignored the problem that
> it breaks ZBOOT_ROM by deleting the zreladdr definitions on EP93xx
> with no way for that to be provided.
I also told you that EP93xx doesn't use ZBOOT_ROM anywhere, and that
this was approved by the EP93xx maintainers.
Furthermore I said that I intended to make ZBOOT_ROM dependent on
CONFIG_PHYS_OFFSET, given that PHYS_OFFSEt and zreladdr are intimately
related which I also explained previously. This doesn't have to go in
right away though. But if this is one of your _requirements_, I'd have
appreciated you made it clearer instead of letting me to dry without any
feedback, especially when I re-re-re-pinged you last week and before.
So much for having lectured me on proper communication.
Nicolas
^ permalink raw reply
* [PATCH] ARM imx51: Add Armadeus systems APF51 support
From: Mark Brown @ 2011-10-13 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318512796-8126-1-git-send-email-julien.boibessot@free.fr>
On Thu, Oct 13, 2011 at 03:33:16PM +0200, julien.boibessot at free.fr wrote:
> +static struct gpio apf51_wm8311_gpios[] = {
> + { APF51_WM8311_IRQ_GPIO, GPIOF_IN, "wm8311_irq" },
> + { APF51_WM8311_TOUCH_DETECT_GPIO, GPIOF_IN, "wm8311_touch_detect" },
> + { APF51_WM8311_TOUCH_EOC_GPIO, GPIOF_IN, "wm8311_touch_eoc" },
> +};
> +static int apf51_wm8311_pre_init(struct wm831x *wm831x)
> +{
> + int ret;
> +
> + ret = gpio_request_array(apf51_wm8311_gpios,
> + ARRAY_SIZE(apf51_wm8311_gpios));
> + if (ret) {
> + pr_err("failed to get WM8311 GPIOs: %d\n", ret);
> + return ret;
> + }
These are all interrupts, if you need to request them as GPIOs then the
IRQ implementation is buggy.
> + irq_set_irq_type(gpio_to_irq(APF51_WM8311_IRQ_GPIO),
> + IRQF_TRIGGER_FALLING);
> + irq_set_irq_type(gpio_to_irq(APF51_WM8311_TOUCH_DETECT_GPIO),
> + IRQF_TRIGGER_FALLING);
> + irq_set_irq_type(gpio_to_irq(APF51_WM8311_TOUCH_EOC_GPIO),
> + IRQF_TRIGGER_FALLING);
Similarly here, request_threaded_irq() should be doing anything that's
needed.
> +static int apf51_wm8311_post_init(struct wm831x *wm831x)
> +{
> + /* Configure GPIO6: input, pwdmn 0, inverted, CMOS, enable, pullup */
> + wm831x_reg_write(wm831x, WM831X_GPIO6_CONTROL, 0xc080);
Use gpio_defaults in the platform data.
> +static struct wm831x_pdata apf51_wm8311_pdata = {
> + .pre_init = apf51_wm8311_pre_init,
> + .post_init = apf51_wm8311_post_init,
> + .irq_cmos = 1,
> + .irq_base = MXC_BOARD_IRQ_START,
> + .status = {
> + &apf51_wm8311_led1_pdata,
> + &apf51_wm8311_led2_pdata,
> + },
> + .touch = &apf51_wm8311_touch_pdata,
> +};
I'm surprised you've not got the ARM supply wired up to cpufreq, though
I don't know if the cpufreq driver for the CPU got merged.
^ permalink raw reply
* [PATCH] UART: add CSR SiRFprimaII SoC on-chip uart drivers
From: Barry Song @ 2011-10-13 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013105556.09d64d4d@bob.linux.org.uk>
Hi Alan,
Thanks for your quick feedback.
2011/10/13 Alan Cox <alan@linux.intel.com>:
> Looks basically ok but somewhat outdated for the tty layer. In
> particular it needs to be aware of the refcounting on tty objects and
> of the fact we allow arbitary baud rate handling
>
>> +static struct sirfsoc_baudrate_to_regv baudrate_to_regv[] = {
>
> const
agree
>
>> +static unsigned int
>> +sirfsoc_uart_pio_rx_chars(struct uart_port *port, unsigned int
>> max_rx_count) +{
>> + ? ? unsigned int ch, rx_count = 0;
>> + ? ? int temp;
>> + ? ? struct tty_struct *tty = port->state->port.tty;
>
> tty = tty_port_tty_get(&port->state->port);
>
> [the newer tty code is refcounting, also tty can be NULL here and needs
> h handling accordingly]
agree
>
>> + ? ? while (!(rd_regl(port, SIRFUART_RX_FIFO_STATUS) &
>> +
>> SIRFUART_FIFOEMPTY_MASK(port))) {
>> + ? ? ? ? ? ? temp =
>> tty_buffer_request_room(port->state->port.tty, 1);
>> + ? ? ? ? ? ? if (unlikely(temp == 0)) {
>> + ? ? ? ? ? ? ? ? ? ? port->icount.buf_overrun++;
>> + ? ? ? ? ? ? ? ? ? ? break;
>> + ? ? ? ? ? ? }
>
> You don't need to do this - just uart_insert_char. If we run out of mid
> layer buffering it's not a port overrun as such (ie a fifo exceeded)
> it's a system wide memory crunch and something pretty serious and
> bigger is going on.
>
>> + ? ? port->icount.rx += rx_count;
>> + ? ? tty_flip_buffer_push(tty);
>
> [Do these only if tty != NULL obviously)
>
> and
> ? ? ? ?tty_kref_put(tty);
>
agree
>
>
>> +static void sirfsoc_uart_set_termios(struct uart_port *port,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct ktermios *termios,
>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct ktermios *old)
>> +{
>
> If you don't support CMSPAR then clear the bit in the passed termios.
actually it is supported if you read codes again.
>
>> + ? ? for (ic = 0; ic < SIRFUART_BAUD_RATE_SUPPORT_NR; ic++)
>> + ? ? ? ? ? ? if (baud_rate == baudrate_to_regv[ic].baud_rate)
>> + ? ? ? ? ? ? ? ? ? ? clk_div_reg = baudrate_to_regv[ic].reg_val;
>> + ? ? if (clk_div_reg == 0)
>> + ? ? ? ? ? ? pr_err("SiRF UART: Cannot set Baud Rate (9600 ~
>> 4000000).\n");
>
> The baud rate is not guaranteed to be one the Bxxxxx values, you should
> be computing it not using a table.
Rong has changed it to contain both Bxxx table and non-Bxxx
calculation. For Bxxx values, get set from table.
otherwise, calculate.
> Also the pr_err means any user can fill the logs with junk.
>
> The correct behaviour here is
>
> ? ? ? ?compute the best timing for the baud rate requested
> ? ? ? ?compute the actual baud rate obtained
>
> then report it back to the caller
>
> ? ? ? ?if (tty_termios_baud_rate(termios))
> ? ? ? ? ? ? ? ?tty_termios_encode_baud_rate(termios, baud. baud);
agree
>
> The above assuming you set the same input and output rate
>
>
>
>> +static struct console sirfsoc_uart_console = {
>> + ? ? .name ? ? ? ? ? = "ttyS",
>
> ttyS is 8250 devces. Pick a new name for your own.
ok. most devices have names like ttySQ, ttySA, ttySG... since our SoC
is named SiRFprimaII, i'd like to have ttySI?
>
>>
>> + ? ? .dev_name ? ? ? = SIRFSOC_UART_NAME,
>> + ? ? .major ? ? ? ? ?= SIRFSOC_UART_MAJOR,
>> + ? ? .minor ? ? ? ? ?= SIRFSOC_UART_MINOR,
>
> Use dynamic allocations
>
>
>> +#define SIRFSOC_UART_NAME ? ? ? ? ? ? ? ? ? ?"ttyS"
>> +#define SIRFSOC_UART_MAJOR ? ? ? ? ? ? ? ? ? TTY_MAJOR
>> +#define SIRFSOC_UART_MINOR ? ? ? ? ? ? ? ? ? 64
>
> These values belong to an existing inerface, don't reuse the names like
> that, and please use dynamic allocation for the numbers
agree
>
>> +#define uart_tx_port_tty_invalid(port) ? \
>> + ? ? (((port)->state == NULL) || ((port)->state->port.tty ==
>> NULL))
>
> This has no locking so little meaning - what guarantees it doesn't
> change ?under or after the call. I suspect you want to be checking and
> referencing the tty in one shot as in the example I gave above for the
> rx fix.
agree.
-barry
^ permalink raw reply
* [GIT PULL] DEBUG_LL platform updates for 3.2
From: Russell King - ARM Linux @ 2011-10-13 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1110130932350.17040@xanadu.home>
On Thu, Oct 13, 2011 at 09:39:03AM -0400, Nicolas Pitre wrote:
> On Thu, 13 Oct 2011, Russell King - ARM Linux wrote:
>
> > On Wed, Oct 12, 2011 at 10:30:11AM +0200, Arnd Bergmann wrote:
> > > On Tuesday 11 October 2011 20:03:38 Nicolas Pitre wrote:
> > > > On Tue, 11 Oct 2011, Arnd Bergmann wrote:
> > > >
> > > > > I've stuck them into the arm-soc tree for now, so we get linux-next
> > > > > coverage, but I won't send them to Linus this way because then we
> > > > > would get the same commits twice in the history.
> > > >
> > > > Could you please do the same with the following:
> > > >
> > > > git://git.linaro.org/people/nico/linux.git mach_memory_h
> > > >
> > > > Russell pulled it at some point, and dropped it due to concerns about
> > > > repeated conflict resolutions (or so I presume). I just did a test
> > > > merge between your for-next branch and the above and that looked trivial
> > > > enough.
> > >
> > > Ok, done.
> >
> > Bypassing maintainers stinks - especially when there are unaddressed
> > comments outstanding. Nicolas has "simplified" my objections in this
> > request for you to pull - and has completely ignored the problem that
> > it breaks ZBOOT_ROM by deleting the zreladdr definitions on EP93xx
> > with no way for that to be provided.
>
> I also told you that EP93xx doesn't use ZBOOT_ROM anywhere, and that
> this was approved by the EP93xx maintainers.
It was not even discussed - or even the issue pointed out (I checked).
In any case, how can *anyone* know whether ZBOOT_ROM is used or not?
It's a facility that's there for users (not really for maintainers)
to enable.
> Furthermore I said that I intended to make ZBOOT_ROM dependent on
> CONFIG_PHYS_OFFSET, given that PHYS_OFFSEt and zreladdr are intimately
> related which I also explained previously.
Sorry, you're totally confused here - with your own work noless.
CONFIG_PHYS_OFFSET is a numeric setting, which is only available when the
dynamic p:v stuff is disabled. So, saying that ZBOOT_ROM is dependent on
CONFIG_PHYS_OFFSET is insane - it's completely the wrong symbol. So I'm
going to assume that you actually meant CONFIG_ARM_PATCH_PHYS_VIRT instead.
Now, the *TECHNICAL* point is that there is absolutely nothing wrong with
building a kernel with CONFIG_ARM_PATCH_PHYS_VIRT *enabled* and ZBOOT_ROM
also enabled. You get a kernel Image which can be loaded at different
addresses, and it'll work. You get a zImage which can also be loaded at
different addresses, and it'll also work. You can also put the zImage
into read-only memory.
However, ZBOOT_ROM is completely *INCOMPATIBLE* with AUTO_ZRELADDR. So
if anything, ZBOOT_ROM should depend on !AUTO_ZRELADDR *only*.
Given your vehement response when I raised that point, you don't want to
understand it, so I decided to postpone the issue until I had the
motivation to go head-to-head with you like I'm now doing - to make you
see sense.
Moreover, because you're encouraging maintainers to accept patches which
remove the zreladdr definitions and force-select AUTO_ZRELADDR, you're
actively killing off ZBOOT_ROM support, even though you said otherwise.
I suspect in a years time it won't be worth having anymore - because in
order to use it you'd have to hack the select statements out of the
Kconfig files.
> This doesn't have to go in
> right away though. But if this is one of your _requirements_, I'd have
> appreciated you made it clearer instead of letting me to dry without any
> feedback, especially when I re-re-re-pinged you last week and before.
Stop overstating your position. You never 're-re-re-pinged' - you sent
_one_ reminder only, which I did think about responding to, but in the
end I decided I didn't need any more flames from you at that time
(because I wouldn't be around to respond).
^ permalink raw reply
* [PATCH v2 01/14] ARM: tegra: annotate IO_*_VIRT pointers
From: Russell King - ARM Linux @ 2011-10-13 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318224484-2090-2-git-send-email-olof@lixom.net>
On Sun, Oct 09, 2011 at 10:27:51PM -0700, Olof Johansson wrote:
> +#ifdef __ASSEMBLY__
> +#define __IOVADDR(x) (x)
> +#else
> +#define __IOVADDR(x) ((void __force __iomem *)(x))
Please call this IOMEM() - see:
grep '#define *IOMEM' arch/arm/*/include/mach -r
for its establishment across several implementations.
^ permalink raw reply
* [PATCH 2/5] drivercore: Add driver probe deferral mechanism
From: Ming Lei @ 2011-10-13 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013040923.GE15829@ponder.secretlab.ca>
CC Rafael and linux-pm
On Thu, Oct 13, 2011 at 12:09 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Tue, Oct 11, 2011 at 08:29:18PM +0800, Ming Lei wrote:
>> On Tue, Oct 11, 2011 at 1:37 AM, Andrei Warkentin <awarkentin@vmware.com> wrote:
>> > Hi,
>> >
>> > ----- Original Message -----
>> >> From: "Greg KH" <greg@kroah.com>
>> >> To: "Josh Triplett" <josh@joshtriplett.org>
>> >> Cc: "G, Manjunath Kondaiah" <manjugk@ti.com>, linux-arm-kernel at lists.infradead.org, "Grant Likely"
>> >> <grant.likely@secretlab.ca>, linux-omap at vger.kernel.org, linux-mmc at vger.kernel.org, linux-kernel at vger.kernel.org,
>> >> "Dilan Lee" <dilee@nvidia.com>, "Mark Brown" <broonie@opensource.wolfsonmicro.com>, Manjunath at jasper.es
>> >> Sent: Saturday, October 8, 2011 11:55:02 AM
>> >> Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
>> >>
>> >
>> > I'm a bit of a fly on the wall here, but I'm curious how this impacts suspend/resume.
>> > device_initialize->device_pm_init are called from device_register, so certainly this
>> > patch doesn't also ensure that the PM ordering matches probe ordering, which is bound
>> > to break suspend, right? Was this ever tested with the OMAP target? Shouldn't the
>>
>> Inside device_add(), device_pm_add is called before bus_probe_device,
>> so the patch can't change the device order in pm list, and just change
>> the driver probe order.
>
> That's the way it works now, but can it be reworked? ?It would be
IMO, it depends on what shape you plan to rework. Currently, the
deferred probe may found a resource dependency, but I am not sure
that pm dependency is same with the resource dependency found
during probe.
> possible to adjust the list order after successful probe. ?However,
> I'm not clear on the ordering rules for the dpm_list. ?Right now it is
> explicitly ordered to have parents before children, but as already
> expressed, that doesn't accurately represent ordering constraints for
> multiple device dependancies.
Maybe we should understand the correct model of the ordering constraints
for the multiple device dependancies first, could you give a description or
some examples about it?
>
> So, reordering the list would probably require maintaining the
> existing parent-child ordering constraint, but to also shift
> devices (and any possible children?) to be after drivers that are
> already probed. ?That alone will be difficult to implement and get
> right, but maybe the constraints can be simplified. ?It needs some
> further thought.
>
> g.
>
>
thanks,
--
Ming Lei
^ permalink raw reply
* [PATCH 4/9] ARM: SPMP8000: Add ADC driver
From: Arnd Bergmann @ 2011-10-13 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013121745.GU21648@n2100.arm.linux.org.uk>
On Thursday 13 October 2011, Russell King - ARM Linux wrote:
> On Thu, Oct 13, 2011 at 12:35:06PM +0100, Mark Brown wrote:
> > On Thu, Oct 13, 2011 at 10:47:17AM +0100, Russell King - ARM Linux wrote:
> > > On Mon, Oct 10, 2011 at 12:44:08PM +0100, Mark Brown wrote:
> >
> > > > At the minute it seems to me that arch/arm is as good a place as any
> > > > really - currently this code is getting dumped wherever the main device
> > > > is.
> >
> > > No it isn't - we want drivers out of arch/arm (it's already been a topic
> > > of flame for Linus, so it's something that we should try really hard
> > > to avoid.)
> >
> > I said it was as good a place as any, I didn't say it was a good place.
>
> I'm saying it is a BAD place. I'm saying that we've been flamed over
> this several times before. We need to change our behaviour RIGHT NOW,
> not continue on ignoring the problem, and demonstrating to Linus that
> we don't take his concerns seriously.
>
> If we can't find a place for it that's outside of arch/arm, then it
> doesn't go in.
How about deferring the decision for now and putting it into
drivers/staging/adc, with a single TODO item listing "Work out proper
API"? After all, the reason this driver doesn't fit anywhere is that
there is no established subsystem for it, at least not outside of
staging.
AFAICT, the driver is not essential for spmp8000 systems, but you
would want to have it there in practice. It makes little sense to
put the driver into drivers/adc and then later change the interface
fundamentally again if we decide to go with drivers/iio/adc providing
the common abstraction lation.
Of course, if the spmp8000 adc driver gets put into staging, all its
dependencies (input, battery) also have to go there because no
regular driver must link against interfaces provided by a staging
driver.
Arnd
^ permalink raw reply
* [PATCH 2/5] ARM: s3c64xx: Add generic high resolution time support using PWM timers.
From: Russell King - ARM Linux @ 2011-10-13 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3260808.zUY9bHslbC@flatron>
On Wed, Aug 31, 2011 at 02:34:52PM +0200, Tomasz Figa wrote:
> +/*
> + * Clock source
> + */
> +
> +static struct clk *source_in;
> +static struct clk *source_div;
> +
> +static cycle_t s3c64xx_clocksource_read(struct clocksource *cs)
> +{
> + return (cycle_t) ~__raw_readl(S3C2410_TCNTO(PWM_SOURCE));
> +}
This looks like a very simple MMIO clocksource... This looks the
same as clocksource_mmio_readl_down().
> +
> +static void s3c64xx_clocksource_resume(struct clocksource *cs)
> +{
> + unsigned long pclk;
> + struct clk *tscaler;
> +
> + pclk = clk_get_rate(timerclk);
> + tscaler = clk_get_parent(source_div);
> + clk_set_rate(tscaler, pclk / 3);
> +
> + clk_set_rate(source_div, pclk / 6);
> + clk_set_parent(source_in, source_div);
> +
> + s3c64xx_pwm_init(PWM_SOURCE, TCNT_MAX);
> + s3c64xx_pwm_start(PWM_SOURCE, PERIODIC);
> +}
> +
> +static struct clocksource pwm_clocksource = {
> + .name = "s3c64xx_clksrc",
> + .rating = 250,
> + .read = s3c64xx_clocksource_read,
> + .mask = CLOCKSOURCE_MASK(32),
> + .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> + .resume = s3c64xx_clocksource_resume,
> +};
> +
> +static void __init s3c64xx_clocksource_init(void)
> +{
> + unsigned long clock_rate;
> +
> + clock_rate = clk_get_rate(source_in);
> +
> + s3c64xx_pwm_init(PWM_SOURCE, TCNT_MAX);
> + s3c64xx_pwm_start(PWM_SOURCE, PERIODIC);
> +
> + if (clocksource_register_hz(&pwm_clocksource, clock_rate))
> + panic("%s: can't register clocksource\n", pwm_clocksource.name);
Apart from the resume entry, this looks like it could use
drivers/clocksource/mmio.c - and so avoid yet another clocksource
creation.
Maybe adding some kind of resume support to mmio.c would be a good
idea?
^ permalink raw reply
* [PATCH] UART: add CSR SiRFprimaII SoC on-chip uart drivers
From: Alan Cox @ 2011-10-13 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4zvc=HaVURyARV0k6m7btfMjQo1frqmJa-OtE--eyCsFA@mail.gmail.com>
> >> +static struct console sirfsoc_uart_console = {
> >> + ? ? .name ? ? ? ? ? = "ttyS",
> >
> > ttyS is 8250 devces. Pick a new name for your own.
>
> ok. most devices have names like ttySQ, ttySA, ttySG... since our SoC
> is named SiRFprimaII, i'd like to have ttySI?
If nobody else is using it for anything mainstream sure. Or ttySiRF0 ..
etc might be more definitively unique
Alan
^ permalink raw reply
* [PATCH 4/9] ARM: SPMP8000: Add ADC driver
From: Mark Brown @ 2011-10-13 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201110131619.39303.arnd@arndb.de>
On Thu, Oct 13, 2011 at 04:19:39PM +0200, Arnd Bergmann wrote:
> Of course, if the spmp8000 adc driver gets put into staging, all its
> dependencies (input, battery) also have to go there because no
> regular driver must link against interfaces provided by a staging
> driver.
Yes, that's the big problem with this - it blocks the actual drivers.
Putting it in drivers/misc would be another option that sidesteps that.
^ permalink raw reply
* [PATCH] mmc: mmci: Do not release spinlock in request_end
From: Russell King - ARM Linux @ 2011-10-13 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318342001-26955-1-git-send-email-ulf.hansson@stericsson.com>
On Tue, Oct 11, 2011 at 04:06:41PM +0200, Ulf Hansson wrote:
> The patch "mmc: core: move ->request() call from atomic context",
> is the reason to why this change is possible. This simplifies the
> error handling code execution path quite a lot and potentially also
> fixes some error handling hang problems.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
This doesn't look right:
void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
{
if (err && cmd->retries) {
host->ops->request(host, mrq);
So, not dropping the spinlock results in calling the request function
with the spinlock held - and as the request function then goes on to
lock the spinlock, we will deadlock.
I don't see anything in current mainline which addresses this, so I'm
not able to queue this patch.
^ permalink raw reply
* [RFC/PATCH 3/7] ARM: ARM11 MPCore: {clean,flush}_pmd_entry are not preempt safe
From: Russell King - ARM Linux @ 2011-10-13 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6EB957F5-6E89-43F3-BAF3-A9E007BD896F@mvista.com>
On Tue, Oct 11, 2011 at 10:34:17PM -0400, George G. Davis wrote:
>
> On Oct 11, 2011, at 5:53 AM, Catalin Marinas wrote:
>
> > On Fri, Oct 07, 2011 at 03:38:37AM +0100, gdavis at mvista.com wrote:
> >> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> >> index 594d677..3c8253f 100644
> >> --- a/arch/arm/mm/mmu.c
> >> +++ b/arch/arm/mm/mmu.c
> >> @@ -567,12 +567,24 @@ static void __init alloc_init_section(pud_t *pud, unsigned long addr,
> >> if (addr & SECTION_SIZE)
> >> pmd++;
> >>
> >> + if (cache_ops_need_broadcast())
> >> + preempt_disable();
> >> do {
> >> *pmd = __pmd(phys | type->prot_sect);
> >> phys += SECTION_SIZE;
> >> } while (pmd++, addr += SECTION_SIZE, addr != end);
> >>
> >> + /* FIXME: Multiple PMD entries may be written above
> >> + * but only one cache line, up to 8 PMDs depending
> >> + * on the alignment of this mapping, is flushed below.
> >> + * IFF this mapping spans >8MiB, then only the first
> >> + * 8MiB worth of entries will be flushed. Entries
> >> + * above the 8MiB limit will not be flushed if I
> >> + * read this correctly.
> >> + */
> >> flush_pmd_entry(p);
> >> + if (cache_ops_need_broadcast())
> >> + preempt_enable();
> >
> > My reading of the create_mapping() code is that alloc_init_pud() and
> > alloc_init_section() are called with a 2MB range only (that's 2
> > entries) given by pgd_addr_end().
>
> You're correct of course. I initially stuck that FIXME note in there more as
> a reminder to review it more carefully. Alas, in my haste, I submitted as-is
> w/o checking parameter bounds passed from callers which do as you
> say, so it's never more than 2MiB in size. Thanks for the feedback.
> I'll remove that note.
Note also that the early bringup of MMU mappings (alloc_init_section
etc) are running before SMP bringup, so they're already bound to a
single CPU. So these shouldn't need 'fixing'.
^ permalink raw reply
* [PATCH 2/5] drivercore: Add driver probe deferral mechanism
From: Alan Stern @ 2011-10-13 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACVXFVNXyzzJw7UK+OFuDe23voQvyywoP9AvUsV=iPDFPO4fPw@mail.gmail.com>
On Thu, 13 Oct 2011, Ming Lei wrote:
> >> Inside device_add(), device_pm_add is called before bus_probe_device,
> >> so the patch can't change the device order in pm list, and just change
> >> the driver probe order.
> >
> > That's the way it works now, but can it be reworked? ?It would be
>
> IMO, it depends on what shape you plan to rework. Currently, the
> deferred probe may found a resource dependency, but I am not sure
> that pm dependency is same with the resource dependency found
> during probe.
>
> > possible to adjust the list order after successful probe. ?However,
> > I'm not clear on the ordering rules for the dpm_list. ?Right now it is
> > explicitly ordered to have parents before children, but as already
> > expressed, that doesn't accurately represent ordering constraints for
> > multiple device dependancies.
>
> Maybe we should understand the correct model of the ordering constraints
> for the multiple device dependancies first, could you give a description or
> some examples about it?
The requirement is that devices must be capable of resuming in the
order given by dpm_list, and they must be capable of suspending in
the reverse order.
Therefore if device A can't work unless device B is functional, then B
must come before A in dpm_list.
Alan Stern
^ permalink raw reply
* [RFC/PATCH 5/7] ARM: Move get_thread_info macro definition to <asm/assembler.h>
From: Russell King - ARM Linux @ 2011-10-13 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111012060433.GE188@mvista.com>
On Wed, Oct 12, 2011 at 02:04:33AM -0400, gdavis at mvista.com wrote:
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 78397d0..eaf4939 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -36,6 +36,20 @@
> .endm
> #endif /* !CONFIG_THUMB2_KERNEL */
>
> + .macro preempt_disable, tsk, cnt
> + get_thread_info \tsk
> + ldr \cnt, [\tsk, #TI_PREEMPT]
> + add \cnt, \cnt, #1
> + str \cnt, [\tsk, #TI_PREEMPT]
> + .endm
> +
> + .macro preempt_enable, tsk, cnt
> + get_thread_info \tsk
> + ldr \cnt, [\tsk, #TI_PREEMPT]
> + sub \cnt, \cnt, #1
> + str \cnt, [\tsk, #TI_PREEMPT]
> + .endm
> +
> /*
> * Endian independent macros for shifting bytes within registers.
> */
>
>
> Not as efficient as it could be but I imagine the macros could
> be written to support optional load of \tsk and/or optional \tmp
> parameters to cover other common cases.
It's actually not that simple either: if you disable preemption, then you
need to check for a preempt event after re-enabling preemption. The
C level code does this:
#define preempt_enable_no_resched() \
do { \
barrier(); \
dec_preempt_count(); \
} while (0)
#define preempt_check_resched() \
do { \
if (unlikely(test_thread_flag(TIF_NEED_RESCHED))) \
preempt_schedule(); \
} while (0)
#define preempt_enable() \
do { \
preempt_enable_no_resched(); \
barrier(); \
preempt_check_resched(); \
} while (0)
Note that preempt_schedule() will check the preempt count itself and
return immediately if non-zero or irqs are disabled.
^ permalink raw reply
* [PATCH] ARM imx51: Add Armadeus systems APF51 support
From: Shawn Guo @ 2011-10-13 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318512796-8126-1-git-send-email-julien.boibessot@free.fr>
On Thu, Oct 13, 2011 at 03:33:16PM +0200, julien.boibessot at free.fr wrote:
> From: Julien Boibessot <julien.boibessot@armadeus.com>
>
> The APF51 is an i.M51 based System On Module that can be plugged on
> several docking/development boards. Here only basic module support
> is added (Ethernet, Serial, I2C & PMIC (Wolfson's WM8311)).
>
> Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com>
> Signed-off-by: Nicolas Colombain <nicolas.colombain@armadeus.com>
NAK.
It makes no sense to add yet another non-dt board file for imx51 at
this point. Why not starting using device tree?
Regards,
Shawn
> ---
> arch/arm/mach-mx5/Kconfig | 10 ++
> arch/arm/mach-mx5/Makefile | 1 +
> arch/arm/mach-mx5/board-apf51.c | 195 +++++++++++++++++++++++++++
> arch/arm/plat-mxc/include/mach/uncompress.h | 4 +
> 4 files changed, 210 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-mx5/board-apf51.c
>
> diff --git a/arch/arm/mach-mx5/Kconfig b/arch/arm/mach-mx5/Kconfig
> index 3d4c313..91400f3 100644
> --- a/arch/arm/mach-mx5/Kconfig
> +++ b/arch/arm/mach-mx5/Kconfig
> @@ -169,6 +169,16 @@ config MACH_MX51_EFIKASB
> Include support for Genesi Efika Smartbook. This includes specific
> configurations for the board and its peripherals.
>
> +config MACH_APF51
> + bool "Support Armadeus APF51 System On Module"
> + select SOC_IMX51
> + select IMX_HAVE_PLATFORM_IMX_UART
> + select IMX_HAVE_PLATFORM_IMX_I2C
> + select IMX_HAVE_PLATFORM_IMX2_WDT
> + help
> + Include support for Armadeus systems APF51 System On Module. This
> + includes specific configurations for the board and its peripherals.
> +
> comment "i.MX53 machines:"
>
> config MACH_MX53_EVK
> diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
> index 9565304..1415913 100644
> --- a/arch/arm/mach-mx5/Makefile
> +++ b/arch/arm/mach-mx5/Makefile
> @@ -21,3 +21,4 @@ obj-$(CONFIG_MX51_EFIKA_COMMON) += mx51_efika.o
> obj-$(CONFIG_MACH_MX51_EFIKAMX) += board-mx51_efikamx.o
> obj-$(CONFIG_MACH_MX51_EFIKASB) += board-mx51_efikasb.o
> obj-$(CONFIG_MACH_MX50_RDP) += board-mx50_rdp.o
> +obj-$(CONFIG_MACH_APF51) += board-apf51.o
> diff --git a/arch/arm/mach-mx5/board-apf51.c b/arch/arm/mach-mx5/board-apf51.c
> new file mode 100644
> index 0000000..f3f22da
> --- /dev/null
> +++ b/arch/arm/mach-mx5/board-apf51.c
> @@ -0,0 +1,195 @@
> +/*
> + * Support for APF51 System On Module
> + * Copyright (C) 2010-2011 Armadeus systems <support@armadeus.com>
> + *
> + * Based on code which is:
> + * Copyright 2009-2010 Freescale Semiconductor, Inc. All Rights Reserved.
> + * Copyright (C) 2009-2010 Amit Kucheria <amit.kucheria@canonical.com>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include <linux/init.h>
> +#include <linux/platform_device.h>
> +#include <linux/gpio.h>
> +#include <linux/irq.h>
> +#include <linux/mfd/wm831x/core.h>
> +#include <linux/mfd/wm831x/pdata.h>
> +
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach/time.h>
> +
> +#include <mach/common.h>
> +#include <mach/iomux-mx51.h>
> +
> +#include "devices-imx51.h"
> +
> +static iomux_v3_cfg_t apf51_pads[] = {
> + /* UART3 (Console) */
> + MX51_PAD_UART3_RXD__UART3_RXD,
> + MX51_PAD_UART3_TXD__UART3_TXD,
> +
> + /* FEC */
> + MX51_PAD_DI_GP3__FEC_TX_ER,
> + MX51_PAD_DI2_PIN4__FEC_CRS,
> + MX51_PAD_DI2_PIN2__FEC_MDC,
> + MX51_PAD_DI2_PIN3__FEC_MDIO,
> + MX51_PAD_DI2_DISP_CLK__FEC_RDATA1,
> + MX51_PAD_DI_GP4__FEC_RDATA2,
> + MX51_PAD_DISP2_DAT0__FEC_RDATA3,
> + MX51_PAD_DISP2_DAT1__FEC_RX_ER,
> + MX51_PAD_DISP2_DAT6__FEC_TDATA1,
> + MX51_PAD_DISP2_DAT7__FEC_TDATA2,
> + MX51_PAD_DISP2_DAT8__FEC_TDATA3,
> + MX51_PAD_DISP2_DAT9__FEC_TX_EN,
> + MX51_PAD_DISP2_DAT10__FEC_COL,
> + MX51_PAD_DISP2_DAT11__FEC_RX_CLK,
> + MX51_PAD_DISP2_DAT12__FEC_RX_DV,
> + MX51_PAD_DISP2_DAT13__FEC_TX_CLK,
> + MX51_PAD_DISP2_DAT14__FEC_RDATA0,
> + MX51_PAD_DISP2_DAT15__FEC_TDATA0,
> + MX51_PAD_DI1_PIN11__GPIO3_0, /* FEC PHY reset line */
> +
> + /* I2C2 */
> + MX51_PAD_EIM_D24__I2C2_SDA,
> + MX51_PAD_EIM_D27__I2C2_SCL,
> +
> + /* PMIC */
> + MX51_PAD_GPIO1_4__GPIO1_4, /* WM8311 TOUCH_DETECT */
> + MX51_PAD_GPIO1_6__GPIO1_6, /* WM8311 TOUCH_EOC */
> + MX51_PAD_GPIO1_7__GPIO1_7, /* WM8311 IRQ */
> +};
> +
> +#ifdef CONFIG_MFD_WM831X_I2C
> +/* APF51 has a Wolfson PMIC on I2C2 */
> +
> +#define APF51_WM8311_TOUCH_DETECT_GPIO IMX_GPIO_NR(1, 4)
> +#define APF51_WM8311_TOUCH_EOC_GPIO IMX_GPIO_NR(1, 6)
> +#define APF51_WM8311_IRQ_GPIO IMX_GPIO_NR(1, 7)
> +
> +static struct gpio apf51_wm8311_gpios[] = {
> + { APF51_WM8311_IRQ_GPIO, GPIOF_IN, "wm8311_irq" },
> + { APF51_WM8311_TOUCH_DETECT_GPIO, GPIOF_IN, "wm8311_touch_detect" },
> + { APF51_WM8311_TOUCH_EOC_GPIO, GPIOF_IN, "wm8311_touch_eoc" },
> +};
> +
> +static int apf51_wm8311_pre_init(struct wm831x *wm831x)
> +{
> + int ret;
> +
> + ret = gpio_request_array(apf51_wm8311_gpios,
> + ARRAY_SIZE(apf51_wm8311_gpios));
> + if (ret) {
> + pr_err("failed to get WM8311 GPIOs: %d\n", ret);
> + return ret;
> + }
> +
> + irq_set_irq_type(gpio_to_irq(APF51_WM8311_IRQ_GPIO),
> + IRQF_TRIGGER_FALLING);
> + irq_set_irq_type(gpio_to_irq(APF51_WM8311_TOUCH_DETECT_GPIO),
> + IRQF_TRIGGER_FALLING);
> + irq_set_irq_type(gpio_to_irq(APF51_WM8311_TOUCH_EOC_GPIO),
> + IRQF_TRIGGER_FALLING);
> +
> + return 0;
> +}
> +
> +static int apf51_wm8311_post_init(struct wm831x *wm831x)
> +{
> + /* Configure GPIO6: input, pwdmn 0, inverted, CMOS, enable, pullup */
> + wm831x_reg_write(wm831x, WM831X_GPIO6_CONTROL, 0xc080);
> +
> + return 0;
> +}
> +
> +static struct wm831x_status_pdata apf51_wm8311_led1_pdata = {
> + .default_src = WM831X_STATUS_PRESERVE,
> + .name = "LED1:red:",
> +};
> +
> +static struct wm831x_status_pdata apf51_wm8311_led2_pdata = {
> + .default_src = WM831X_STATUS_PRESERVE,
> + .name = "LED2:green:",
> +};
> +
> +static struct wm831x_touch_pdata apf51_wm8311_touch_pdata = {
> + .fivewire = 0,
> + .pressure = 1,
> + .data_irq = IMX_GPIO_TO_IRQ(APF51_WM8311_TOUCH_EOC_GPIO),
> + .pd_irq = IMX_GPIO_TO_IRQ(APF51_WM8311_TOUCH_DETECT_GPIO),
> +};
> +
> +static struct wm831x_pdata apf51_wm8311_pdata = {
> + .pre_init = apf51_wm8311_pre_init,
> + .post_init = apf51_wm8311_post_init,
> + .irq_cmos = 1,
> + .irq_base = MXC_BOARD_IRQ_START,
> + .status = {
> + &apf51_wm8311_led1_pdata,
> + &apf51_wm8311_led2_pdata,
> + },
> + .touch = &apf51_wm8311_touch_pdata,
> +};
> +#endif /* CONFIG_MFD_WM831X_I2C */
> +
> +static const struct imxi2c_platform_data apf51_i2c1_data __initconst = {
> + .bitrate = 400000,
> +};
> +
> +static struct i2c_board_info apf51_i2c1_devices[] __initdata = {
> +#ifdef CONFIG_MFD_WM831X_I2C
> + {
> + I2C_BOARD_INFO("wm8311", 0x36),
> + .platform_data = &apf51_wm8311_pdata,
> + .irq = IMX_GPIO_TO_IRQ(APF51_WM8311_IRQ_GPIO),
> + },
> +#endif
> +};
> +
> +/*
> + * Board specific initialization.
> + */
> +static void __init apf51_board_init(void)
> +{
> + imx51_soc_init();
> +
> +#if defined(CONFIG_CPU_FREQ_IMX)
> + get_cpu_op = mx51_get_cpu_op;
> +#endif
> + mxc_iomux_v3_setup_multiple_pads(apf51_pads,
> + ARRAY_SIZE(apf51_pads));
> +
> + imx51_add_imx_uart(2, NULL);
> +
> + imx51_add_imx_i2c(1, &apf51_i2c1_data);
> + i2c_register_board_info(1, apf51_i2c1_devices,
> + ARRAY_SIZE(apf51_i2c1_devices));
> +
> + imx51_add_fec(NULL);
> +
> + imx51_add_imx2_wdt(0, NULL);
> +}
> +
> +static void __init apf51_timer_init(void)
> +{
> + mx51_clocks_init(32768, 32768*1024, 0, 0);
> +}
> +
> +static struct sys_timer apf51_timer = {
> + .init = apf51_timer_init,
> +};
> +
> +MACHINE_START(APF51, "Armadeus APF51")
> + /* Maintainer: Julien Boibessot <julien.boibessot@armadeus.com> */
> + .map_io = mx51_map_io,
> + .init_early = imx51_init_early,
> + .init_irq = mx51_init_irq,
> + .timer = &apf51_timer,
> + .init_machine = apf51_board_init,
> +MACHINE_END
> diff --git a/arch/arm/plat-mxc/include/mach/uncompress.h b/arch/arm/plat-mxc/include/mach/uncompress.h
> index 88fd404..09ac3ea 100644
> --- a/arch/arm/plat-mxc/include/mach/uncompress.h
> +++ b/arch/arm/plat-mxc/include/mach/uncompress.h
> @@ -64,6 +64,7 @@ static inline void flush(void)
> #define MX3X_UART2_BASE_ADDR 0x43F94000
> #define MX3X_UART5_BASE_ADDR 0x43FB4000
> #define MX51_UART1_BASE_ADDR 0x73fbc000
> +#define MX51_UART3_BASE_ADDR 0x7000c000
> #define MX50_UART1_BASE_ADDR 0x53fbc000
> #define MX53_UART1_BASE_ADDR 0x53fbc000
>
> @@ -111,6 +112,9 @@ static __inline__ void __arch_decomp_setup(unsigned long arch_id)
> case MACH_TYPE_MX51_3DS:
> uart_base = MX51_UART1_BASE_ADDR;
> break;
> + case MACH_TYPE_APF51:
> + uart_base = MX51_UART3_BASE_ADDR;
> + break;
> case MACH_TYPE_MX50_RDP:
> uart_base = MX50_UART1_BASE_ADDR;
> break;
> --
> 1.7.4.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 4/9] ARM: SPMP8000: Add ADC driver
From: Mark Brown @ 2011-10-13 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013121745.GU21648@n2100.arm.linux.org.uk>
On Thu, Oct 13, 2011 at 01:17:45PM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 13, 2011 at 12:35:06PM +0100, Mark Brown wrote:
> > I said it was as good a place as any, I didn't say it was a good place.
> I'm saying it is a *BAD* place. I'm saying that we've been flamed over
> this several times before. We need to change our behaviour RIGHT NOW,
> not continue on ignoring the problem, and demonstrating to Linus that
> we don't take his concerns seriously.
I think we're agreeing here...
> > I think we should just carry on as we are while the IIO work proceeds,
> > either we'll decide that that's the way forward and we can then kick all
> > the ADCs into there or we'll get fed up, decide that's never going to
> > work then go and can do something else.
> You mean like other stuff which is already in the kernel gets fixed?
> It doesn't get fixed. We persist with per-driver private data structures
> which multiply all over the place.
> Look at what happened with MTD and the flash_platform_data structure.
> That got ignored and instead people just continued merrily creating their
> own private crap time and time again.
The situation here is a bit different; there's people working on
handling these devices already but we can't point people at it as
something they can use yet. As soon as we've got something to point
people at we should absolutely be going and actively pushing them
towards it but right now we don't have that option.
> We can not continue like this. We can not continue to be soo permissive.
> I'm now saying a big NO to this - I don't care that the "cat is already
> out of the bag" - that's a defeatest attitude. I'm saying no *now* so
> that there _is_ some kind of movement towards fixing this problem. I
Half the problem that's being pointed out is that there is already
movement towards a solution for these devices, it's just not quite at
the point where it can be used for this class of devices yet. The point
with the existing drivers being there is that this isn't a new driver
setting a precedent, if we had chosen to merge the driver we'd simply be
taking a decision to avoid creating churn that disrupts the existing
work.
> don't care whether that means it shares an existing ADC drivers callback
> data structures or what - I just don't want to see yet another driver
> private data structure being created for NO REASON what so ever.
Well, what do we do then? I guess so long as it's outside arch/arm you
don't mind too much.
> Or maybe you'd like to be on the receiving end of another Linus flame?
> Some people would like to avoid such things - maybe you feed off them,
> that's your decision. I personally am on the side of the folk who'd
> like to avoid being on the receiving end of the next Linus flame.
On the other hand we also don't want to overreact and we don't want to
irritate people by just putting stuff into a different directory without
actually improving it. The goal isn't to troll Linus, the goal is to be
pragmatic about what we're actually achieving. It's similar to the
decision that was taken to allow platforms to proceed without the
generic clk API or device tree bindings for the clk API.
> So. No new drivers in arch/arm. And I'm going to be saying no to any
> new per-driver data structures in mach/*.h for stuff which should be
> generic which haven't been justified for why they need to be different
> from someone elses.
The driver specific data structures should probably just be moving to
include/linux/platform_data which is the approved location for that sort
of thing.
^ permalink raw reply
* [PATCH v2 1/7] clk: Add a generic clock infrastructure
From: Russell King - ARM Linux @ 2011-10-13 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316730422-20027-2-git-send-email-mturquette@ti.com>
On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
> struct clk_hw_ops {
> int (*prepare)(struct clk_hw *);
> void (*unprepare)(struct clk_hw *);
> int (*enable)(struct clk_hw *);
> void (*disable)(struct clk_hw *);
> unsigned long (*recalc_rate)(struct clk_hw *);
> int (*set_rate)(struct clk_hw *,
> unsigned long, unsigned long *);
> long (*round_rate)(struct clk_hw *, unsigned long);
> int (*set_parent)(struct clk_hw *, struct clk *);
> struct clk * (*get_parent)(struct clk_hw *);
> };
>
> Platform clock code can register a clock through clk_register, passing a
> set of operations, and a pointer to hardware-specific data:
>
> struct clk_hw_foo {
> struct clk_hw clk;
> void __iomem *enable_reg;
> };
Eww, no, this really isn't going to scale for platforms like OMAP - to
have all the operations indirected through a set of function pointers
for every clock just because the enable register (or enable bit) is
in a different position is completely absurd.
I'm not soo concerned about the increase in memory usage (for 100 to 200
clock definitions its only 4 to 8k) but what worries me the most is
initializing these damned things. It's an awful lot of initializers,
which means the potential for an awful lot of conflicts should something
change in this structure.
^ permalink raw reply
* [PATCH] atmel_lcdfb: support new-style palette format
From: Peter Korsgaard @ 2011-10-13 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1318507395-23143-1-git-send-email-jacmet@sunsite.dk>
>>>>> "Peter" == Peter Korsgaard <jacmet@sunsite.dk> writes:
Peter> The newer Atmel SoCs use normal 16bit 565 BGR/RGB for the palette data,
Peter> rather than the special intensity + 555 format.
Peter> Fill out palette data correctly on these devices, and at the same time
Peter> respect the RGB/BGR wiring mode.
Ups, wrong patch - This has RGB/BGR modes swapped. Will resend.
--
Bye, Peter Korsgaard
^ permalink raw reply
* [PATCH v2 4/7] clk: Add simple gated clock
From: Russell King - ARM Linux @ 2011-10-13 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316730422-20027-5-git-send-email-mturquette@ti.com>
On Thu, Sep 22, 2011 at 03:26:59PM -0700, Mike Turquette wrote:
> diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
> new file mode 100644
> index 0000000..a1d8e79
> --- /dev/null
> +++ b/drivers/clk/clk-gate.c
> @@ -0,0 +1,78 @@
> +/*
> + * Copyright (C) 2010-2011 Canonical Ltd <jeremy.kerr@canonical.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Simple clk gate implementation
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/module.h>
> +#include <asm/io.h>
linux/io.h please.
^ permalink raw reply
* [PATCHv2] atmel_lcdfb: support new-style palette format
From: Peter Korsgaard @ 2011-10-13 14:45 UTC (permalink / raw)
To: linux-arm-kernel
The newer Atmel SoCs use normal 16bit 565 BGR/RGB for the palette data,
rather than the special intensity + 555 format.
Fill out palette data correctly on these devices, and at the same time
respect the RGB/BGR wiring mode.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
---
Changes since v1:
- ATMEL_LCDC_WIRING_RGB/BGR was swapped
drivers/video/atmel_lcdfb.c | 32 ++++++++++++++++++++++++--------
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 63409c1..7ca3eaf 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -682,14 +682,30 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
case FB_VISUAL_PSEUDOCOLOR:
if (regno < 256) {
- val = ((red >> 11) & 0x001f);
- val |= ((green >> 6) & 0x03e0);
- val |= ((blue >> 1) & 0x7c00);
-
- /*
- * TODO: intensity bit. Maybe something like
- * ~(red[10] ^ green[10] ^ blue[10]) & 1
- */
+ if (cpu_is_at91sam9261() || cpu_is_at91sam9263()
+ || cpu_is_at91sam9rl()) {
+ /* old style I+BGR:555 */
+ val = ((red >> 11) & 0x001f);
+ val |= ((green >> 6) & 0x03e0);
+ val |= ((blue >> 1) & 0x7c00);
+
+ /*
+ * TODO: intensity bit. Maybe something like
+ * ~(red[10] ^ green[10] ^ blue[10]) & 1
+ */
+ } else {
+ /* new style BGR:565 / RGB:565 */
+ if (sinfo->lcd_wiring_mode ==
+ ATMEL_LCDC_WIRING_RGB) {
+ val = ((blue >> 11) & 0x001f);
+ val |= ((red >> 0) & 0xf800);
+ } else {
+ val = ((red >> 11) & 0x001f);
+ val |= ((blue >> 0) & 0xf800);
+ }
+
+ val |= ((green >> 5) & 0x07e0);
+ }
lcdc_writel(sinfo, ATMEL_LCDC_LUT(regno), val);
ret = 0;
--
1.7.6.3
^ permalink raw reply related
* [RFC/PATCH 5/7] ARM: Move get_thread_info macro definition to <asm/assembler.h>
From: Catalin Marinas @ 2011-10-13 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111013143420.GB21648@n2100.arm.linux.org.uk>
On Thu, Oct 13, 2011 at 03:34:20PM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 12, 2011 at 02:04:33AM -0400, gdavis at mvista.com wrote:
> > diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> > index 78397d0..eaf4939 100644
> > --- a/arch/arm/include/asm/assembler.h
> > +++ b/arch/arm/include/asm/assembler.h
> > @@ -36,6 +36,20 @@
> > .endm
> > #endif /* !CONFIG_THUMB2_KERNEL */
> >
> > + .macro preempt_disable, tsk, cnt
> > + get_thread_info \tsk
> > + ldr \cnt, [\tsk, #TI_PREEMPT]
> > + add \cnt, \cnt, #1
> > + str \cnt, [\tsk, #TI_PREEMPT]
> > + .endm
> > +
> > + .macro preempt_enable, tsk, cnt
> > + get_thread_info \tsk
> > + ldr \cnt, [\tsk, #TI_PREEMPT]
> > + sub \cnt, \cnt, #1
> > + str \cnt, [\tsk, #TI_PREEMPT]
> > + .endm
> > +
> > /*
> > * Endian independent macros for shifting bytes within registers.
> > */
> >
> >
> > Not as efficient as it could be but I imagine the macros could
> > be written to support optional load of \tsk and/or optional \tmp
> > parameters to cover other common cases.
>
> It's actually not that simple either: if you disable preemption, then you
> need to check for a preempt event after re-enabling preemption.
That's not easily possible in assembly as calling a function would
corrupt some registers. Is there any disadvantage with just doing the
equivalent of preempt_enable_no_resched() for a few asm cases where this
is needed?
--
Catalin
^ 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