* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: Daniel Walker @ 2011-02-11 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8yaipwql1wf.fsf@huya.qualcomm.com>
On Fri, 2011-02-11 at 13:03 -0800, David Brown wrote:
> On Fri, Feb 11 2011, Steve Muckle wrote:
>
> > On 02/11/11 12:42, Daniel Walker wrote:
> >>> static struct resource msm_iommu_jpegd_resources[] = {
> >>> {
> >>> - .start = MSM_IOMMU_JPEGD_PHYS,
> >>> - .end = MSM_IOMMU_JPEGD_PHYS + MSM_IOMMU_JPEGD_SIZE - 1,
> >>> + .start = 0x07300000,
> >>> + .end = 0x07300000 + SZ_1M - 1,
> >>
> >> Looks worse .. Just put the macros into a static header file for both.
> >
> > Why bother defining macros for these if they only appear here? I don't
> > think that adds any value or readability - these addresses are clearly
> > the physical area for the msm_iommu_jpegd. It just makes it more
> > annoying to have to look up the values in a separate file if you are
> > wondering what they are.
>
> I want to chime in with a second on this. Defining names for constants
> serves several purposes:
>
> - It gives meaning to the constants.
>
> - It allows the definition to be centralized if the value is used in
> one place.
>
> If the constants are initializers in a table, it satisfies both of these
> reasons. Adding #defines for these constants does nothing other than
> cause an extra indirection that the reader of the code has to make.
>
> If they were used in more than one place, we could justify the
> definition, but in this case, the definition just obscures the code
> slightly.
It only obscures the constant, which no one really looks at anyway. in
general it's better design to hide constant like this, because people
don't work naturally with numbers like this.
A good example might be if all these constants are enumerated in a
header file, but aren't all used. In that case it would be fairly easy
to add a new resource without even know what the constant is just by
following the pattern.
I think in general this series just makes this iommu code very much
8660/8960 only code, but what about the potential next iteration of SoC
that uses very similar code to this with all new constants. So this
doesn't seem forward thinking to me.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ permalink raw reply
* [RFC] Inter-processor Mailboxes Drivers
From: Meador Inge @ 2011-02-11 21:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi All,
I am currently working on building AMP systems using OpenMCAPI
(https://bitbucket.org/hollisb/openmcapi/wiki/Home) as the
inter-processor communication mechanism. With OpenMCAPI we, of course,
need a way to send messages to various cores. On some Freescale PPC
platforms (e.g. P1022DS, MPC8572DS), we have been using message
registers to do this work. Recently, I was looking at the OMAP4
mailboxes to gear up for moving into ARM based platforms.
With that, I noticed 'arch/arm/plat-omap/mailbox.c'. This is very
specific to the OMAP4 boards. I am looking at designing a new set of
drivers to expose a mailbox service to userspace that will be used
for inter-processor communication. This would entail the traditional
generic/specific driver split:
1. Hardware specific bits somewhere under '.../arch/*'. Drivers
for the MPIC message registers on Power and OMAP4 mailboxes, for
example.
2. A higher level driver under '.../drivers/mailbox/*'. That the
pieces in (1) would register with. This piece would expose the
main kernel API.
3. Userspace interfaces for accessing the mailboxes. A
'/dev/mailbox1', '/dev/mailbox2', etc... mapping, for example.
Now I have the following questions:
1. Do others see value in this?
2. Does something like this already exist?
3. Is someone else already working on this?
Any feedback will be greatly appreciated.
--
Meador Inge | meador_inge AT mentor.com
Mentor Embedded | http://www.mentor.com/embedded-software
^ permalink raw reply
* [PATCH] PM: Allow pm_runtime_suspend() to succeed during system suspend
From: Rafael J. Wysocki @ 2011-02-11 21:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ei7e9uhy.fsf@ti.com>
On Friday, February 11, 2011, Kevin Hilman wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Monday, January 31, 2011, Rafael J. Wysocki wrote:
> >> On Monday, January 31, 2011, Alan Stern wrote:
> >> > On Mon, 31 Jan 2011, Kevin Hilman wrote:
> >> >
> >> > > I understand how this works, but frankly I'm still a bit fuzzy on why.
> >> > >
> >> > > I guess I'm still missing a good understanding of what "interfering with a
> >> > > system power transition" means, and why a runtime suspend qualifies as
> >> > > interfering but not a runtime resume.
> >> >
> >> > These are good questions. Rafael implemented this design originally;
> >> > my contribution was only to warn him of the potential for problems.
> >> > Therefore he should explain the rationale for the design.
> >>
> >> The reason why runtime resume is allowed during system power transitions is
> >> because in some cases during system suspend we simply have to resume devices
> >> that were previously runtime-suspended (for example, the PCI bus type does
> >> that).
> >>
> >> The reason why runtime suspend is not allowed during system power transitions
> >> if the following race:
> >>
> >> - A device has been suspended via a system suspend callback.
> >> - The runtime PM framework executes a (scheduled) suspend on that device,
> >> not knowing that it's already been suspended, which potentially results in
> >> accessing the device's registers in a low-power state.
> >>
> >> Now, it can be avoided if every driver does the right thing and checks whether
> >> the device is already suspended in its runtime suspend callback, but that would
> >> kind of defeat the purpose of the runtime PM framework, at least partially.
> >
> > In fact, I've just realized that the above race cannot really occur, because
> > pm_wq is freezable, so I'm proposing the following change.
> >
> > Of course, it still doesn't prevent user space from disabling the runtime PM
> > framework's helpers via /sys/devices/.../power/control.
> >
> > Thanks,
> > Rafael
> >
> >
> > ---
> > From: Rafael J. Wysocki <rjw@sisk.pl>
> > Subject: PM: Allow pm_runtime_suspend() to succeed during system suspend
> >
> > The dpm_prepare() function increments the runtime PM reference
> > counters of all devices to prevent pm_runtime_suspend() from
> > executing subsystem-level callbacks. However, this was supposed to
> > guard against a specific race condition that cannot happen, because
> > the power management workqueue is freezable, so pm_runtime_suspend()
> > can only be called synchronously during system suspend and we can
> > rely on subsystems and device drivers to avoid doing that
> > unnecessarily.
> >
> > Make dpm_prepare() drop the runtime PM reference to each device
> > after making sure that runtime resume is not pending for it.
> >
> > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> > ---
>
> Yes!
>
> Acked-by: Kevin Hilman <khilman@ti.com>
Well, I hope you realize that it doesn't help you a lot?
Rafael
^ permalink raw reply
* [PATCH] mx31: add support for the bugbase 1.3 from buglabs
From: Marc Kleine-Budde @ 2011-02-11 21:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297458388-23361-1-git-send-email-GNUtoo@no-log.org>
On 02/11/2011 10:06 PM, Denis 'GNUtoo' Carikli wrote:
> This work was based on bug-linux-2.6.30.patch that can be found
> in buglabs's svn here:
> svn://bugcamp.net/bug/branches/izzy/experimental
>
> Note that the hardware schematics and documentations can be obtained
> here: http://www.bugcommunity.com/wiki/index.php/BUGbase
>
> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
> ---
> arch/arm/mach-mx3/Kconfig | 9 +++
> arch/arm/mach-mx3/Makefile | 1 +
> arch/arm/mach-mx3/mach-mx31bugbase.c | 75 +++++++++++++++++++++++++++
> arch/arm/plat-mxc/include/mach/uncompress.h | 4 ++
> 4 files changed, 89 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-mx3/mach-mx31bugbase.c
>
> diff --git a/arch/arm/mach-mx3/Kconfig b/arch/arm/mach-mx3/Kconfig
> index de80d98..4f57f13 100644
> --- a/arch/arm/mach-mx3/Kconfig
> +++ b/arch/arm/mach-mx3/Kconfig
> @@ -199,6 +199,15 @@ config MACH_KZM_ARM11_01
> Include support for KZM-ARM11-01. This includes specific
> configurations for the board and its peripherals.
>
> +config MACH_BUG
> + bool "Support Buglabs BUGBase platform"
> + select SOC_IMX31
> + select IMX_HAVE_PLATFORM_IMX_UART
> + default y
> + help
> + Include support for BUGBase 1.3 platform. This includes specific
> + configurations for the board and its peripherals.
> +
> config MACH_EUKREA_CPUIMX35
> bool "Support Eukrea CPUIMX35 Platform"
> select SOC_IMX35
> diff --git a/arch/arm/mach-mx3/Makefile b/arch/arm/mach-mx3/Makefile
> index bc7294f..98e5eb3 100644
> --- a/arch/arm/mach-mx3/Makefile
> +++ b/arch/arm/mach-mx3/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_MACH_PCM043) += mach-pcm043.o
> obj-$(CONFIG_MACH_ARMADILLO5X0) += mach-armadillo5x0.o
> obj-$(CONFIG_MACH_MX35_3DS) += mach-mx35_3ds.o
> obj-$(CONFIG_MACH_KZM_ARM11_01) += mach-kzm_arm11_01.o
> +obj-$(CONFIG_MACH_BUG) += mach-mx31bugbase.o
> obj-$(CONFIG_MACH_EUKREA_CPUIMX35) += mach-cpuimx35.o
> obj-$(CONFIG_MACH_EUKREA_MBIMXSD35_BASEBOARD) += eukrea_mbimxsd-baseboard.o
> obj-$(CONFIG_MACH_VPR200) += mach-vpr200.o
> diff --git a/arch/arm/mach-mx3/mach-mx31bugbase.c b/arch/arm/mach-mx3/mach-mx31bugbase.c
> new file mode 100644
> index 0000000..1d8ca1c
> --- /dev/null
> +++ b/arch/arm/mach-mx3/mach-mx31bugbase.c
> @@ -0,0 +1,75 @@
> +/*
> + * Copyright (C) 2000 Deep Blue Solutions Ltd
> + * Copyright (C) 2002 Shane Nay (shane at minirl.com)
> + * Copyright 2005-2007 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/platform_device.h>
> +
> +#include <mach/iomux-mx3.h>
> +#include <mach/imx-uart.h>
> +#include <mach/hardware.h>
> +#include <mach/common.h>
> +
> +#include <asm/mach/time.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach-types.h>
> +
> +#include "devices-imx31.h"
> +
> +static struct imxuart_platform_data uart_pdata = {
> + .flags = IMXUART_HAVE_RTSCTS,
> +};
> +
> +static unsigned int uart5_pins[] = {
> + MX31_PIN_PC_RST__CTS5,
> + MX31_PIN_PC_VS2__RTS5,
> + MX31_PIN_PC_BVD2__TXD5,
> + MX31_PIN_PC_BVD1__RXD5,
> +};
> +
> +static inline void mx31bug_init_imx_uart(void)
> +{
> + mxc_iomux_setup_multiple_pins(uart5_pins,
> + ARRAY_SIZE(uart5_pins), "uart-4");
> + imx31_add_imx_uart4(&uart_pdata);
> +}
> +
> +/*!
> + * Board specific initialization.
> + */
> +static void __init mx31bug_board_init(void)
> +{
> + mx31bug_init_imx_uart();
> +}
> +
> +
> +static void __init mx31bug_timer_init(void)
> +{
> + mx31_clocks_init(26000000);
> +}
> +
> +static struct sys_timer mx31bug_timer = {
> + .init = mx31bug_timer_init,
> +};
> +
> +MACHINE_START(BUG, "BugLabs BUGBase")
> + .boot_params = MX3x_PHYS_OFFSET + 0x100,
> + .map_io = mx31_map_io,
> + .init_early = imx31_init_early,
here slipped some spaces in
> + .init_irq = mx31_init_irq,
> + .timer = &mx31bug_timer,
dito
> + .init_machine = mx31bug_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 e634d6c..b45f534 100644
> --- a/arch/arm/plat-mxc/include/mach/uncompress.h
> +++ b/arch/arm/plat-mxc/include/mach/uncompress.h
> @@ -62,6 +62,7 @@ static inline void flush(void)
> #define MX2X_UART1_BASE_ADDR 0x1000a000
> #define MX3X_UART1_BASE_ADDR 0x43F90000
> #define MX3X_UART2_BASE_ADDR 0x43F94000
> +#define MX3X_UART5_BASE_ADDR 0x43FB4000
> #define MX51_UART1_BASE_ADDR 0x73fbc000
> #define MX50_UART1_BASE_ADDR 0x53fbc000
> #define MX53_UART1_BASE_ADDR 0x53fbc000
> @@ -102,6 +103,9 @@ static __inline__ void __arch_decomp_setup(unsigned long arch_id)
> case MACH_TYPE_MAGX_ZN5:
> uart_base = MX3X_UART2_BASE_ADDR;
> break;
> + case MACH_TYPE_BUG:
> + uart_base = MX3X_UART5_BASE_ADDR;
> + break;
> case MACH_TYPE_MX51_BABBAGE:
> case MACH_TYPE_EUKREA_CPUIMX51SD:
> case MACH_TYPE_MX51_3DS:
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110211/d522a02e/attachment.sig>
^ permalink raw reply
* [PATCH] mx31: add support for the bugbase 1.3 from buglabs
From: Uwe Kleine-König @ 2011-02-11 21:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297458388-23361-1-git-send-email-GNUtoo@no-log.org>
On Fri, Feb 11, 2011 at 10:06:28PM +0100, Denis 'GNUtoo' Carikli wrote:
> This work was based on bug-linux-2.6.30.patch that can be found
> in buglabs's svn here:
> svn://bugcamp.net/bug/branches/izzy/experimental
>
> Note that the hardware schematics and documentations can be obtained
> here: http://www.bugcommunity.com/wiki/index.php/BUGbase
>
> Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
> ---
> arch/arm/mach-mx3/Kconfig | 9 +++
> arch/arm/mach-mx3/Makefile | 1 +
> arch/arm/mach-mx3/mach-mx31bugbase.c | 75 +++++++++++++++++++++++++++
> arch/arm/plat-mxc/include/mach/uncompress.h | 4 ++
> 4 files changed, 89 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-mx3/mach-mx31bugbase.c
>
> diff --git a/arch/arm/mach-mx3/Kconfig b/arch/arm/mach-mx3/Kconfig
> index de80d98..4f57f13 100644
> --- a/arch/arm/mach-mx3/Kconfig
> +++ b/arch/arm/mach-mx3/Kconfig
> @@ -199,6 +199,15 @@ config MACH_KZM_ARM11_01
> Include support for KZM-ARM11-01. This includes specific
> configurations for the board and its peripherals.
>
> +config MACH_BUG
> + bool "Support Buglabs BUGBase platform"
> + select SOC_IMX31
> + select IMX_HAVE_PLATFORM_IMX_UART
> + default y
> + help
> + Include support for BUGBase 1.3 platform. This includes specific
> + configurations for the board and its peripherals.
> +
> config MACH_EUKREA_CPUIMX35
> bool "Support Eukrea CPUIMX35 Platform"
> select SOC_IMX35
> diff --git a/arch/arm/mach-mx3/Makefile b/arch/arm/mach-mx3/Makefile
> index bc7294f..98e5eb3 100644
> --- a/arch/arm/mach-mx3/Makefile
> +++ b/arch/arm/mach-mx3/Makefile
> @@ -20,6 +20,7 @@ obj-$(CONFIG_MACH_PCM043) += mach-pcm043.o
> obj-$(CONFIG_MACH_ARMADILLO5X0) += mach-armadillo5x0.o
> obj-$(CONFIG_MACH_MX35_3DS) += mach-mx35_3ds.o
> obj-$(CONFIG_MACH_KZM_ARM11_01) += mach-kzm_arm11_01.o
> +obj-$(CONFIG_MACH_BUG) += mach-mx31bugbase.o
I'd like to have the file name matching the MACH variable. That is
mach-bug.c
> obj-$(CONFIG_MACH_EUKREA_CPUIMX35) += mach-cpuimx35.o
> obj-$(CONFIG_MACH_EUKREA_MBIMXSD35_BASEBOARD) += eukrea_mbimxsd-baseboard.o
> obj-$(CONFIG_MACH_VPR200) += mach-vpr200.o
> diff --git a/arch/arm/mach-mx3/mach-mx31bugbase.c b/arch/arm/mach-mx3/mach-mx31bugbase.c
> new file mode 100644
> index 0000000..1d8ca1c
> --- /dev/null
> +++ b/arch/arm/mach-mx3/mach-mx31bugbase.c
> @@ -0,0 +1,75 @@
> +/*
> + * Copyright (C) 2000 Deep Blue Solutions Ltd
> + * Copyright (C) 2002 Shane Nay (shane at minirl.com)
> + * Copyright 2005-2007 Freescale Semiconductor, Inc. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/platform_device.h>
> +
> +#include <mach/iomux-mx3.h>
> +#include <mach/imx-uart.h>
> +#include <mach/hardware.h>
> +#include <mach/common.h>
> +
> +#include <asm/mach/time.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach-types.h>
> +
> +#include "devices-imx31.h"
> +
> +static struct imxuart_platform_data uart_pdata = {
> + .flags = IMXUART_HAVE_RTSCTS,
> +};
can be const and __initconst and lacks a prefix
> +
> +static unsigned int uart5_pins[] = {
> + MX31_PIN_PC_RST__CTS5,
> + MX31_PIN_PC_VS2__RTS5,
> + MX31_PIN_PC_BVD2__TXD5,
> + MX31_PIN_PC_BVD1__RXD5,
> +};
can be const and __initconst and lacks a prefix, but see below.
> +
> +static inline void mx31bug_init_imx_uart(void)
> +{
> + mxc_iomux_setup_multiple_pins(uart5_pins,
> + ARRAY_SIZE(uart5_pins), "uart-4");
> + imx31_add_imx_uart4(&uart_pdata);
> +}
can be __init. I'd prefer a prefix of bug, not mx31bug, because that
matches the machine id.
> +
> +/*!
no doxygen style comments in the kernel please
> + * Board specific initialization.
> + */
> +static void __init mx31bug_board_init(void)
> +{
> + mx31bug_init_imx_uart();
I assume your machine doesn't only have an uart. If so, I'd suggest to
rename uart5_pins (which lacks a prefix btw) to mx31bug_pins and put the
mxc_iomux_setup_multiple_pins into mx31bug_board_init. Then
mx31bug_init_imx_uart only has imx31_add_imx_uart4 which then can better
go directly into mx31bug_board_init, too.
> +}
> +
> +
You can remove one of these two empty lines.
> +static void __init mx31bug_timer_init(void)
> +{
> + mx31_clocks_init(26000000);
> +}
> +
> +static struct sys_timer mx31bug_timer = {
> + .init = mx31bug_timer_init,
> +};
> +
> +MACHINE_START(BUG, "BugLabs BUGBase")
> + .boot_params = MX3x_PHYS_OFFSET + 0x100,
BTW, if you have a decent bootloader, you don't need this line.
> + .map_io = mx31_map_io,
> + .init_early = imx31_init_early,
> + .init_irq = mx31_init_irq,
> + .timer = &mx31bug_timer,
> + .init_machine = mx31bug_board_init,
please use tabs consistently for indention. And if you use a single
space before the = here (which is totally ok, even prefered by me), then
do the same in mx31bug_timer, please.
> +MACHINE_END
> diff --git a/arch/arm/plat-mxc/include/mach/uncompress.h b/arch/arm/plat-mxc/include/mach/uncompress.h
> index e634d6c..b45f534 100644
> --- a/arch/arm/plat-mxc/include/mach/uncompress.h
> +++ b/arch/arm/plat-mxc/include/mach/uncompress.h
> @@ -62,6 +62,7 @@ static inline void flush(void)
> #define MX2X_UART1_BASE_ADDR 0x1000a000
> #define MX3X_UART1_BASE_ADDR 0x43F90000
> #define MX3X_UART2_BASE_ADDR 0x43F94000
> +#define MX3X_UART5_BASE_ADDR 0x43FB4000
> #define MX51_UART1_BASE_ADDR 0x73fbc000
> #define MX50_UART1_BASE_ADDR 0x53fbc000
> #define MX53_UART1_BASE_ADDR 0x53fbc000
> @@ -102,6 +103,9 @@ static __inline__ void __arch_decomp_setup(unsigned long arch_id)
> case MACH_TYPE_MAGX_ZN5:
> uart_base = MX3X_UART2_BASE_ADDR;
> break;
> + case MACH_TYPE_BUG:
> + uart_base = MX3X_UART5_BASE_ADDR;
> + break;
> case MACH_TYPE_MX51_BABBAGE:
> case MACH_TYPE_EUKREA_CPUIMX51SD:
> case MACH_TYPE_MX51_3DS:
> --
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] mx31: add support for the bugbase 1.3 from buglabs
From: Uwe Kleine-König @ 2011-02-11 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297458816.18578.5.camel@gnutoo-laptop>
On Fri, Feb 11, 2011 at 10:13:36PM +0100, Denis 'GNUtoo' Carikli wrote:
> > diff --git a/arch/arm/plat-mxc/include/mach/uncompress.h b/arch/arm/plat-mxc/include/mach/uncompress.h
> > index e634d6c..b45f534 100644
> > --- a/arch/arm/plat-mxc/include/mach/uncompress.h
> > +++ b/arch/arm/plat-mxc/include/mach/uncompress.h
> > @@ -62,6 +62,7 @@ static inline void flush(void)
> > #define MX2X_UART1_BASE_ADDR 0x1000a000
> > #define MX3X_UART1_BASE_ADDR 0x43F90000
> > #define MX3X_UART2_BASE_ADDR 0x43F94000
> > +#define MX3X_UART5_BASE_ADDR 0x43FB4000
> > #define MX51_UART1_BASE_ADDR 0x73fbc000
> > #define MX50_UART1_BASE_ADDR 0x53fbc000
> > #define MX53_UART1_BASE_ADDR 0x53fbc000
> > @@ -102,6 +103,9 @@ static __inline__ void __arch_decomp_setup(unsigned long arch_id)
> > case MACH_TYPE_MAGX_ZN5:
> > uart_base = MX3X_UART2_BASE_ADDR;
> > break;
> > + case MACH_TYPE_BUG:
> > + uart_base = MX3X_UART5_BASE_ADDR;
> > + break;
> > case MACH_TYPE_MX51_BABBAGE:
> > case MACH_TYPE_EUKREA_CPUIMX51SD:
> > case MACH_TYPE_MX51_3DS:
> That seem not to crash, but I wonder if it's really useful:
> Basically I see u-boot loading the kernel, then I have
> > Uncompressing Linux...
> Then I wait some seconds
> Then I see that line beeing complretted with:
> > done, booting the kernel.
> Then the rest of the messages are displayed very fast,
> along with initramfs loading messages and I finally get a shell.
That means you'd prefer no output? Some time ago we even got some more
dots during decompression, I'd like to get these back.
The only downside of these outputs I can imagine is to save the time it
takes to get them out of the serial. But if you really care, you might
want to evaluate the possibility to let U-Boot uncompress your kernel.
(Depending on some parameters of your hardware this might or might not
be faster for you.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: David Brown @ 2011-02-11 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297458889.4852.24.camel@m0nster>
On Fri, Feb 11 2011, Daniel Walker wrote:
> On Fri, 2011-02-11 at 13:03 -0800, David Brown wrote:
>> On Fri, Feb 11 2011, Steve Muckle wrote:
>> If they were used in more than one place, we could justify the
>> definition, but in this case, the definition just obscures the code
>> slightly.
Someone debugging it will look at the constant. In fact, in general,
the only person looking at this structure will want to know the value in
the table. Indirecting it through a pointer only serves to hide it from
the person who wants to know the value.
> A good example might be if all these constants are enumerated in a
> header file, but aren't all used. In that case it would be fairly easy
> to add a new resource without even know what the constant is just by
> following the pattern.
This I definitely want to avoid. I have seen header files with hundreds
of thousands of register definitions, where only a few were used.
> I think in general this series just makes this iommu code very much
> 8660/8960 only code, but what about the potential next iteration of SoC
> that uses very similar code to this with all new constants. So this
> doesn't seem forward thinking to me.
The table would have the different addresses in it. My point is that
the resource table _is_ the definition of the addres. Nothing is gained
by inventing yet another name and putting that somewhere else.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH RFC] ARM: MPCore v6_early_abort enhancement
From: Valentine Barshak @ 2011-02-11 21:54 UTC (permalink / raw)
To: linux-arm-kernel
SWP instruction sets bit 11 in DFSR, in case of data fault on SMP MPCore.
So v6_early_abort doesn't need erratum 326103 workaround for MPCore.
Signed-off-by: Valentine Barshak <vbarshak@mvista.com>
diff --git a/arch/arm/mm/abort-ev6.S b/arch/arm/mm/abort-ev6.S
index f332df7..590d061 100644
--- a/arch/arm/mm/abort-ev6.S
+++ b/arch/arm/mm/abort-ev6.S
@@ -30,8 +30,10 @@ ENTRY(v6_early_abort)
mrc p15, 0, r0, c6, c0, 0 @ get FAR
/*
* Faulty SWP instruction on 1136 doesn't set bit 11 in DFSR (erratum 326103).
- * The test below covers all the write situations, including Java bytecodes
+ * The test below covers all the write situations, including Java bytecodes.
+ * However SMP MPCore doesn't have this erratum.
*/
+#ifndef CONFIG_SMP
bic r1, r1, #1 << 11 @ clear bit 11 of FSR
tst r3, #PSR_J_BIT @ Java?
movne pc, lr
@@ -43,6 +45,7 @@ ENTRY(v6_early_abort)
do_ldrd_abort
tst r3, #1 << 20 @ L = 0 -> write
orreq r1, r1, #1 << 11 @ yes.
+#endif /* !CONFIG_SMP */
mov pc, lr
^ permalink raw reply related
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: Daniel Walker @ 2011-02-11 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8yad3mykzks.fsf@huya.qualcomm.com>
On Fri, 2011-02-11 at 13:53 -0800, David Brown wrote:
> On Fri, Feb 11 2011, Daniel Walker wrote:
>
> > On Fri, 2011-02-11 at 13:03 -0800, David Brown wrote:
> >> On Fri, Feb 11 2011, Steve Muckle wrote:
>
> >> If they were used in more than one place, we could justify the
> >> definition, but in this case, the definition just obscures the code
> >> slightly.
>
> Someone debugging it will look at the constant. In fact, in general,
> the only person looking at this structure will want to know the value in
> the table. Indirecting it through a pointer only serves to hide it from
> the person who wants to know the value.
Like I said in my example, people looking at the code won't always be
debugging.
> > A good example might be if all these constants are enumerated in a
> > header file, but aren't all used. In that case it would be fairly easy
> > to add a new resource without even know what the constant is just by
> > following the pattern.
>
> This I definitely want to avoid. I have seen header files with hundreds
> of thousands of register definitions, where only a few were used.
I think your thinking of stuff that's not properly grouped.
> > I think in general this series just makes this iommu code very much
> > 8660/8960 only code, but what about the potential next iteration of SoC
> > that uses very similar code to this with all new constants. So this
> > doesn't seem forward thinking to me.
>
> The table would have the different addresses in it. My point is that
> the resource table _is_ the definition of the addres. Nothing is gained
> by inventing yet another name and putting that somewhere else.
In my example I showed you there is something to be gained by doing
this. As you said already there isn't must lost in doing it this way.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ permalink raw reply
* [PATCH 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Shawn Guo @ 2011-02-11 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19794.17994.381937.158944@ipc1.ka-ro>
Hi Lothar,
On Wed, Feb 09, 2011 at 08:46:18AM +0100, Lothar Wa?mann wrote:
> Hi Shawn,
>
> Shawn Guo writes:
> > This adds the mmc host driver for Freescale MXS-based SoC i.MX23/28.
> > The driver calls into mxs-dma via generic dmaengine api for both pio
> > and data transfer.
> >
> > Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
> > ---
> > arch/arm/mach-mxs/include/mach/mmc.h | 15 +
> > drivers/mmc/host/Kconfig | 9 +
> > drivers/mmc/host/Makefile | 1 +
> > drivers/mmc/host/mxs-mmc.c | 884 ++++++++++++++++++++++++++++++++++
> > 4 files changed, 909 insertions(+), 0 deletions(-)
> > create mode 100644 arch/arm/mach-mxs/include/mach/mmc.h
> > create mode 100644 drivers/mmc/host/mxs-mmc.c
> >
> I've run the mmc-test kernel module with this driver on our TX28
> module which fails in the following tests:
> |mmc0: Test case 15. Correct xfer_size at write (start failure)...
> |mmc0: Result: ERROR (-110)
> |mmc0: Test case 16. Correct xfer_size at read (start failure)...
> |mmc0: Result: ERROR (-110)
> |mmc0: Test case 17. Correct xfer_size at write (midway failure)...
> |mmc0: Result: ERROR (-110)
> |mmc0: Test case 18. Correct xfer_size at read (midway failure)...
> |mmc0: Result: ERROR (-110)
>
> Could you try the test on your hardware?
>
I'm new to this test. I enabled MMC_TEST but did not see "test"
under /sys for mmc. Can you please elaborate how to launch this
test? Thanks.
Regards,
Shawn
^ permalink raw reply
* [PATCH 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Shawn Guo @ 2011-02-11 22:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <19793.11232.308502.128439@ipc1.ka-ro>
Hi Lothar,
On Tue, Feb 08, 2011 at 12:41:20PM +0100, Lothar Wa?mann wrote:
> Hi,
>
> Shawn Guo writes:
> [...]
> > +static int mxs_mmc_remove(struct platform_device *pdev)
> > +{
> > + struct mmc_host *mmc = platform_get_drvdata(pdev);
> > + struct mxs_mmc_host *host = mmc_priv(mmc);
> > +
> > + platform_set_drvdata(pdev, NULL);
> > +
> > + mmc_remove_host(mmc);
> > +
> > + del_timer(&host->timer);
> > +
> > + free_irq(host->irq, host);
> > +
> > + if (host->dmach)
> > + dma_release_channel(host->dmach);
> > +
> > + clk_disable(host->clk);
> > + clk_put(host->clk);
> > +
> > + iounmap(host->base);
> > +
> > + mmc_free_host(mmc);
> > +
> > + release_mem_region(host->res->start, resource_size(host->res));
> >
> When compiled with CONFIG_PAGE_POISON this leads to:
> |mmc0: card cdef removed
> |Unable to handle kernel paging request at virtual address 6b6b6b6b
> |pgd = c6ea4000
> |[6b6b6b6b] *pgd=00000000
> |Internal error: Oops: 1 [#1] PREEMPT
> |last sysfs file: /sys/module/mxs_mmc/refcnt
> |Modules linked in: mxs_mmc(-) evdev nand nand_ids nand_ecc tsc2007 pca953x
> |CPU: 0 Not tainted (2.6.37-karo+ #100)
> |PC is at mxs_mmc_remove+0x78/0x94 [mxs_mmc]
> |LR is at mark_held_locks+0x5c/0x84
> |pc : [<bf03310c>] lr : [<c0071da0>] psr: 20000013
> |sp : c6e33ef8 ip : 6b6b6b6b fp : be825a38
> |r10: 00000000 r9 : c6e32000 r8 : c0037888
> |r7 : 00591700 r6 : c78d24bc r5 : c6c6ea80 r4 : c6c6ed60
> |r3 : 6b6b6b6b r2 : 00000040 r1 : c6d833d0 r0 : c043af18
> |Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> |Control: 0005317f Table: 46ea4000 DAC: 00000015
> |Process modprobe (pid: 1217, stack limit = 0xc6e32270)
> |Stack: (0xc6e33ef8 to 0xc6e34000)
> |3ee0: c78d2488 bf034100
> |3f00: c78d24bc c0237034 c78d2488 c0235e68 c78d2488 bf034100 c78d24bc c0235f34
> |3f20: bf034100 00000080 c045c3e8 c02351c4 bf034138 00000080 c6e33f44 c007de4c
> |3f40: be82599c 5f73786d 00636d6d 00000000 c01efdf0 c6d830c0 c6d830c0 c03195ec
> |3f60: 00000001 c6dddbd8 c6e33f7c c0045fc4 c6d830c0 c00377d8 00000001 00000081
> |3f80: 60000010 c00720d4 be825a2c 00000000 00000001 be825a2c 005916b0 00000001
> |3fa0: 00000081 c00376c0 be825a2c 005916b0 00591700 00000080 be825994 00000000
> |3fc0: be825a2c 005916b0 00000001 00000081 00591700 0000c69c 005916bc be825a38
> |3fe0: 00591520 be8259a0 0000a42c 402aee3c 60000010 00591700 aaaaaaaa aaaaaaaa
> |[<bf03310c>] (mxs_mmc_remove+0x78/0x94 [mxs_mmc]) from [<c0237034>] (platform_drv_remove+0x18/0x1c)
> |[<c0237034>] (platform_drv_remove+0x18/0x1c) from [<c0235e68>] (__device_release_driver+0x64/0xa4)
> |[<c0235e68>] (__device_release_driver+0x64/0xa4) from [<c0235f34>] (driver_detach+0x8c/0xb4)
> |[<c0235f34>] (driver_detach+0x8c/0xb4) from [<c02351c4>] (bus_remove_driver+0x8c/0xb4)
> |[<c02351c4>] (bus_remove_driver+0x8c/0xb4) from [<c007de4c>] (sys_delete_module+0x1f4/0x260)
> |[<c007de4c>] (sys_delete_module+0x1f4/0x260) from [<c00376c0>] (ret_fast_syscall+0x0/0x38)
> |Code: e1a00005 eb48cd47 e5943008 e59f0014 (e8930006)
> |---[ end trace bb06175839554c3b ]---
> indicating a use_after_free BUG!
Thanks for catching this.
> The struct mxs_mmc_host has been already freed here by the
> preceding mmc_free_host() call. This should be:
> struct resource *res = host->res;
> ...
> mmc_free_host(mmc);
> release_mem_region(res->start, resource_size(res));
>
How about fixing it like below?
release_mem_region(host->res->start, resource_size(host->res));
mmc_free_host(mmc);
Regards,
Shawn
^ permalink raw reply
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: Daniel Walker @ 2011-02-11 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297456098-3241-2-git-send-email-stepanm@codeaurora.org>
On Fri, 2011-02-11 at 12:28 -0800, Stepan Moskovchenko wrote:
> Make the IOMMU platform data target-independent in
> preparation for adding MSM8960 IOMMU support. The IOMMU
> configuration on MSM8x60 and MSM8960 is identical and the
> same platform data can be used for both.
>
> Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
> ---
> arch/arm/mach-msm/Makefile | 4 +-
> .../{devices-msm8x60-iommu.c => devices-iommu.c} | 54 +++++++++----------
> arch/arm/mach-msm/include/mach/msm_iomap-8x60.h | 36 -------------
> 3 files changed, 28 insertions(+), 66 deletions(-)
> rename arch/arm/mach-msm/{devices-msm8x60-iommu.c => devices-iommu.c} (93%)
If it's like what you and David are suggesting I think you would need a
SoC designation in the filename ..
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Andrei Warkentin @ 2011-02-11 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimjQfuNU-_rZTjAPrjxJhb=3kReVysBKoPE6Q4o@mail.gmail.com>
On Wed, Feb 9, 2011 at 2:37 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> [Quoting in verbatin so the orginal mail hits linux-mmc, this is very
> interesting!]
>
> 2011/2/8 Andrei Warkentin <andreiw@motorola.com>:
>> Hi,
>>
>> I'm not sure if this is the best place to bring this up, but Russel's
>> name is on a fair share of drivers/mmc code, and there does seem to be
>> quite a bit of MMC-related discussions. Excuse me in advance if this
>> isn't the right forum :-).
>>
>> Certain MMC vendors (maybe even quite a bit of them) use a pretty
>> rigid buffering scheme when it comes to handling writes. There is
>> usually a buffer A for random accesses, and a buffer B for sequential
>> accesses. For certain Toshiba parts, it looks like buffer A is 8KB
>> wide, with buffer B being 4MB wide, and all accesses larger than 8KB
>> effectively equating to 4MB accesses. Worse, consecutive small (8k)
>> writes are treated as one large sequential access, once again ending
>> up in buffer B, thus necessitating out-of-order writing to work around
>> this.
>>
>> What this means is decreased life span for the parts, and it also
>> means a performance impact on small writes, but the first item is much
>> more crucial, especially for smaller parts.
>>
>> As I've mentioned, probably more vendors are affected. How about a
>> generic MMC_BLOCK quirk that splits the requests (and optionally
>> reorders) them? The thresholds would then be adjustable as
>> module/kernel parameters based on manfid. I'm asking because I have a
>> patch now, but its ugly and hardcoded against a specific manufacturer.
>
> There is a quirk API so that specific quirks can be flagged for certain
> vendors and cards, e.g. some Toshibas in this case. e.g. grep the
> kernel source for MMC_QUIRK_BLKSZ_FOR_BYTE_MODE.
>
> But as Russell says this probably needs to be signalled up to the
> block layer to be handled properly.
>
> Why don't you post the code you have today as an RFC: patch,
> I think many will be interested?
>
> Yours,
> Linus Walleij
>
I think it's worthwhile to make make the upper block layers aware of
MMC (and apparently other flash memory) limitations, but I think as a
first step it could make sense (for me) to reformat the patch I am
attaching into something that looks better.
Don't take the attached patch too seriously :-).
Thanks,
A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: toshiba_emmc_opt.patch
Type: text/x-diff
Size: 8737 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110211/426789b7/attachment.bin>
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Andrei Warkentin @ 2011-02-11 22:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102091013.56670.arnd@arndb.de>
On Wed, Feb 9, 2011 at 3:13 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 09 February 2011 09:37:40 Linus Walleij wrote:
>> [Quoting in verbatin so the orginal mail hits linux-mmc, this is very
>> interesting!]
>>
>> 2011/2/8 Andrei Warkentin <andreiw@motorola.com>:
>> > Hi,
>> >
>> > I'm not sure if this is the best place to bring this up, but Russel's
>> > name is on a fair share of drivers/mmc code, and there does seem to be
>> > quite a bit of MMC-related discussions. Excuse me in advance if this
>> > isn't the right forum :-).
>> >
>> > Certain MMC vendors (maybe even quite a bit of them) use a pretty
>> > rigid buffering scheme when it comes to handling writes. There is
>> > usually a buffer A for random accesses, and a buffer B for sequential
>> > accesses. For certain Toshiba parts, it looks like buffer A is 8KB
>> > wide, with buffer B being 4MB wide, and all accesses larger than 8KB
>> > effectively equating to 4MB accesses. Worse, consecutive small (8k)
>> > writes are treated as one large sequential access, once again ending
>> > up in buffer B, thus necessitating out-of-order writing to work around
>> > this.
>
> It's more complex, but I now have a pretty good understanding of
> what the flash media actually do, after doing a lot of benchmarking.
> Most of my results so far are documented on
>
> https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashCardSurvey
>
> but I still need to write about the more recent discoveries.
>
> What you describe as buffer A is the "page size" of the underlying
> flash. It depends on the size and brand of the NAND flash chip and
> can be anywhere between 2 KB and 16 KB for modern cards, depending
> on how they combine multiple chips and planes within the chips.
>
> What you describe as buffer B is sometime called an "erase block
> group" or an "allocation unit". This is the smallest unit that
> gets kept in a global lookup table in the medium and can be anywhere
> between 1 MB and 8 MB for cards larger than 4 GB, or as small as
> 128 KB (a single erase block) for smaller media, as far as I have
> seen. When you don't write full aligned allocation units, the
> card will have to eventually do garbage collection on the allocation
> unit, which can take a long time (many milliseconds).
>
> Most cards have a third size, typically somewhere between 32 and 128 KB,
> which is the optimimum size for writes. While you can do linear
> writes to the card in page size units (writing an allocation unit
> from start to finish), doing random access within the allocation unit
> will be much faster doing larger writes.
>
>> > What this means is decreased life span for the parts, and it also
>> > means a performance impact on small writes, but the first item is much
>> > more crucial, especially for smaller parts.
>> >
>> > As I've mentioned, probably more vendors are affected. How about a
>> > generic MMC_BLOCK quirk that splits the requests (and optionally
>> > reorders) them? The thresholds would then be adjustable as
>> > module/kernel parameters based on manfid. I'm asking because I have a
>> > patch now, but its ugly and hardcoded against a specific manufacturer.
>
> It's not just MMC specific: USB flash drives, CF cards and even cheap
> PATA or SATA SSDs have the same patterns. I think this will need
> to be solved on a higher level, in the block device elevator code
> and in the file systems.
>
>> There is a quirk API so that specific quirks can be flagged for certain
>> vendors and cards, e.g. some Toshibas in this case. e.g. grep the
>> kernel source for MMC_QUIRK_BLKSZ_FOR_BYTE_MODE.
>>
>> But as Russell says this probably needs to be signalled up to the
>> block layer to be handled properly.
>>
>> Why don't you post the code you have today as an RFC: patch,
>> I think many will be interested?
>
> Yes, I agree, that would be good. Also, I'd be interested to see the
> output of 'head /sys/block/mmcblk0/device/*' on that card. I'm guessing
> that the manufacturer ID of 0x0002 is Toshiba, and these are indeed
> the worst cards that I have seen so far, because they can not do
> random access within an allocation unit, and they can not write to
> multiple allocation units alternating (# open AUs linear is "1" in
> my wiki table), while most cards can do at least two.
>
> Andrei, I'm certainly interested in working with you on this.
> The point you brought up about the toshiba cards being especially
> bad is certainly vald, even if we do something better in the block
> layer, we need to have a way to detect the worst-case scenario,
> so we can work around that.
>
> ? ? ? ?Arnd
>
Arnd,
Yes, this is a Toshiba card. I've sent the patch as a reply to Linus' email.
cid - 02010053454d3332479070cc51451d00
csd - d00f00320f5903ffffffffff92404000
erase_size - 524288
fwrev - 0x0
hwrev - 0x0
manfid - 0x000002
name - SEM32G
oemid - 0x0100
preferred_erase_size - 2097152
^ permalink raw reply
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: David Brown @ 2011-02-11 22:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297462350.4852.31.camel@m0nster>
On Fri, Feb 11 2011, Daniel Walker wrote:
> On Fri, 2011-02-11 at 12:28 -0800, Stepan Moskovchenko wrote:
>> Make the IOMMU platform data target-independent in
>> preparation for adding MSM8960 IOMMU support. The IOMMU
>> configuration on MSM8x60 and MSM8960 is identical and the
>> same platform data can be used for both.
>>
>> Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
>> ---
>> arch/arm/mach-msm/Makefile | 4 +-
>> .../{devices-msm8x60-iommu.c => devices-iommu.c} | 54 +++++++++----------
>> arch/arm/mach-msm/include/mach/msm_iomap-8x60.h | 36 -------------
>> 3 files changed, 28 insertions(+), 66 deletions(-)
>> rename arch/arm/mach-msm/{devices-msm8x60-iommu.c => devices-iommu.c} (93%)
>
> If it's like what you and David are suggesting I think you would need a
> SoC designation in the filename ..
It is functionality that will be shared across multiple socs. Putting
the name of a specific soc would just be misleading. Currently, it's
our only iommu. Support for another family that uses a different iommu
could perhaps call it iommu2.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH RFC] ARM: MPCore v6_early_abort enhancement
From: Russell King - ARM Linux @ 2011-02-11 22:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110211215421.GA29361@mvista.com>
On Sat, Feb 12, 2011 at 12:54:21AM +0300, Valentine Barshak wrote:
> SWP instruction sets bit 11 in DFSR, in case of data fault on SMP MPCore.
> So v6_early_abort doesn't need erratum 326103 workaround for MPCore.
NAK. When building a SMP kernel which also supports v6 CPUs, this will
cause v6 CPUs to break.
^ permalink raw reply
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: Daniel Walker @ 2011-02-11 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8ya7hd6kxk1.fsf@huya.qualcomm.com>
On Fri, 2011-02-11 at 14:37 -0800, David Brown wrote:
> On Fri, Feb 11 2011, Daniel Walker wrote:
>
> > On Fri, 2011-02-11 at 12:28 -0800, Stepan Moskovchenko wrote:
> >> Make the IOMMU platform data target-independent in
> >> preparation for adding MSM8960 IOMMU support. The IOMMU
> >> configuration on MSM8x60 and MSM8960 is identical and the
> >> same platform data can be used for both.
> >>
> >> Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
> >> ---
> >> arch/arm/mach-msm/Makefile | 4 +-
> >> .../{devices-msm8x60-iommu.c => devices-iommu.c} | 54 +++++++++----------
> >> arch/arm/mach-msm/include/mach/msm_iomap-8x60.h | 36 -------------
> >> 3 files changed, 28 insertions(+), 66 deletions(-)
> >> rename arch/arm/mach-msm/{devices-msm8x60-iommu.c => devices-iommu.c} (93%)
> >
> > If it's like what you and David are suggesting I think you would need a
> > SoC designation in the filename ..
>
> It is functionality that will be shared across multiple socs. Putting
> the name of a specific soc would just be misleading. Currently, it's
> our only iommu. Support for another family that uses a different iommu
> could perhaps call it iommu2.
Your missing my point. I'm saying it doesn't look flexible enough to
allow support for multiple SoCs .. Is everything going to be identical
across all the supported socs ?
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ permalink raw reply
* [PATCH RFC] ARM: MPCore v6_early_abort enhancement
From: George G. Davis @ 2011-02-11 22:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110211223844.GB31356@n2100.arm.linux.org.uk>
Hi,
On Fri, Feb 11, 2011 at 10:38:44PM +0000, Russell King - ARM Linux wrote:
> On Sat, Feb 12, 2011 at 12:54:21AM +0300, Valentine Barshak wrote:
> > SWP instruction sets bit 11 in DFSR, in case of data fault on SMP MPCore.
> > So v6_early_abort doesn't need erratum 326103 workaround for MPCore.
>
> NAK. When building a SMP kernel which also supports v6 CPUs, this will
> cause v6 CPUs to break.
Since the SWP erratum only affects ARM1136 (UP) processors, how will this
break ARM11 MPCore (v6) processors? Are you referring to unified kernels
which support both UP and SMP machines? I reckon that's a recent feature
to be able to boot SMP kernels on UP machines. Perhaps if that's
why you're against this, then we need to have a separate config
option to specifically enable this ARM1136 erratum workaround? Or
at least only perform the workaround for certain processor IDs?
Thanks!
--
Regards,
George
^ permalink raw reply
* [PATCH v5 0/5] omap: mailbox: hwmod support
From: Kevin Hilman @ 2011-02-11 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1296674843-12718-1-git-send-email-omar.ramirez@ti.com>
Omar Ramirez Luna <omar.ramirez@ti.com> writes:
> Mailbox hwmod support for OMAP 2,3,4.
>
> This was tested on OMAP3 (3430, 3630), minor testing
> was made on OMAP4.
>
> No testing on OMAP2 since I don't have the hardware.
To help in testing, I wrote a simple mailbox loopback test module for
OMAP2/3/4 that I used to do send and receive messages on the MPU. This
can be used to test the mailbox without any DSP software.
I tested it against l-o master branch and found a couple bugs in the
mailbox driver (patches posted earlier today.)
With those patches plus my test I can send & receieve a series of
messages on the MPU, which is enough to sanity test the basic sending
and receiving messages on the MPU.
I've tested the master branch, now it's your turn to use this test
module to validate this hmod conversion series.
The test module is available here:
git://gitorious.org/omap-test/mailbox.git
Note that the current mailbox driver has hard-coded settings for the
receiver of messages. While this should be configurable at runtime, I'm
not an expert on the mailbox IP so my test module includes a kernel
patch that changes these hard-coded settings of the first mbox (dsp on
OMAP2/3, mailbox-1 on OMAP4) so that my loopback tester will work.
Kevin
^ permalink raw reply
* [PATCH] mx31: add support for the bugbase 1.3 from buglabs
From: Denis 'GNUtoo' Carikli @ 2011-02-11 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110211213954.GK27982@pengutronix.de>
On Fri, 2011-02-11 at 22:39 +0100, Uwe Kleine-K?nig wrote:
> On Fri, Feb 11, 2011 at 10:13:36PM +0100, Denis 'GNUtoo' Carikli wrote:
> > > diff --git a/arch/arm/plat-mxc/include/mach/uncompress.h b/arch/arm/plat-mxc/include/mach/uncompress.h
> > > index e634d6c..b45f534 100644
> > > --- a/arch/arm/plat-mxc/include/mach/uncompress.h
> > > +++ b/arch/arm/plat-mxc/include/mach/uncompress.h
> > > @@ -62,6 +62,7 @@ static inline void flush(void)
> > > #define MX2X_UART1_BASE_ADDR 0x1000a000
> > > #define MX3X_UART1_BASE_ADDR 0x43F90000
> > > #define MX3X_UART2_BASE_ADDR 0x43F94000
> > > +#define MX3X_UART5_BASE_ADDR 0x43FB4000
> > > #define MX51_UART1_BASE_ADDR 0x73fbc000
> > > #define MX50_UART1_BASE_ADDR 0x53fbc000
> > > #define MX53_UART1_BASE_ADDR 0x53fbc000
> > > @@ -102,6 +103,9 @@ static __inline__ void __arch_decomp_setup(unsigned long arch_id)
> > > case MACH_TYPE_MAGX_ZN5:
> > > uart_base = MX3X_UART2_BASE_ADDR;
> > > break;
> > > + case MACH_TYPE_BUG:
> > > + uart_base = MX3X_UART5_BASE_ADDR;
> > > + break;
> > > case MACH_TYPE_MX51_BABBAGE:
> > > case MACH_TYPE_EUKREA_CPUIMX51SD:
> > > case MACH_TYPE_MX51_3DS:
> > That seem not to crash, but I wonder if it's really useful:
> > Basically I see u-boot loading the kernel, then I have
> > > Uncompressing Linux...
> > Then I wait some seconds
> > Then I see that line beeing complretted with:
> > > done, booting the kernel.
> > Then the rest of the messages are displayed very fast,
> > along with initramfs loading messages and I finally get a shell.
> That means you'd prefer no output?
I should have misunderstood something, but I believed that that
uncompress.h was for early printk.
And so I expected printk to be printed on serial console immediately,
not waiting for the serial port to be initialized again(as it is already
initialized by the u-boot bootloader).
Denis.
^ permalink raw reply
* [PATCH 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Shawn Guo @ 2011-02-11 23:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102101817.42099.arnd@arndb.de>
On Thu, Feb 10, 2011 at 06:17:41PM +0100, Arnd Bergmann wrote:
> On Friday 11 February 2011, Shawn Guo wrote:
> >
> > > > + struct mxs_dma_data dma_data;
> > >
> > > Why do you need host specific DMA structures? Please stick to
> > > the generic dma-engine API if possible.
> > >
> > I'm sticking to the generic dmaengine api. The mxs dma hardware
> > has separate irq line for every single dma channel, which needs to
> > be told by client driver.
>
> I'm not convinced, it still sounds like a layering violation to
> have specific information about the DMA controller in the
> platform data of a driver using the dma engine API.
>
It sounds like something about the dma controller, but it really
belongs to dma client device e.g. ssp here. Every single dma client
device has two dma related resources, dma channel and dma irq, which
should be defined in client device data.
> Why can't you put the interrupt number into the platform data of
> the dma engine device? Your filter function already identifies
> the number of the DMA channel.
>
We have 16 channels for dma-apbh and dma-apbx respectively. And each
channel has fixed peripheral device and irq. You think we can define
2 x 16 x (channel number + channel irq) in dma engine driver? I'm
afraid not. The channel number can be identified in filter function
because dmaengine core code and mxs dma hw are indexing the channel
in the same way, so that the sw channel id can be used to address hw
channel, otherwise we have to pass hw channel id to dma driver just
like what we do with irq.
> > > > +static irqreturn_t mxs_mmc_irq_handler(int irq, void *dev_id)
> > > > +{
> > > > + struct mxs_mmc_host *host = dev_id;
> > > > + u32 stat;
> > > > +
> > > > + stat = __raw_readl(host->base + HW_SSP_CTRL1);
> > > > + __mxs_clrl(stat & MXS_MMC_IRQ_BITS, host->base + HW_SSP_CTRL1);
> > > > +
> > > > + if (host->cmd && (stat & MXS_MMC_ERR_BITS))
> > > > + host->status = __raw_readl(host->base + HW_SSP_STATUS);
> > > > +
> > > > + if ((stat & BM_SSP_CTRL1_SDIO_IRQ) && (stat & BM_SSP_CTRL1_SDIO_IRQ_EN))
> > > > + mmc_signal_sdio_irq(host->mmc);
> > > > +
> > > > + return IRQ_HANDLED;
> > > > +}
> > >
> > > You use spin_lock_irqsave in mxs_mmc_enable_sdio_irq, but don't
> > > actually use the spinlock in the interrupt handler. This means
> > > that either your interrupt handler is broken because it doesn't
> > > lock, or that you don't actually need the _irqsave part.
> > >
> > I do not understand this one. I'm seeing mxcmmc and pxamci use
> > spin_lock_irqsave/irqrestore in the similar way.
>
> The difference is that e.g. mxcmci_irq() takes the spinlock that is
> used to protect the host->use_sdio flag, serializing the the
> code that initializes sdio with the code that uses it.
>
> [Actually, mxcmci_irq() also looks wrong, because it releases the
> spinlock before calling mmc_signal_sdio_irq(), so sdio may be
> disabled by then, but that is a slightly different bug]
>
> What I meant is that you take care to avoid getting into the
> interrupt handler while holding the spinlock, but in the handler,
> you don't check if the lock is held. It can't be correct to
> serialize just half the cases.
>
Thanks for the explanation. Please help review the fix below to see
if I understand the comment correctly.
if ((stat & BM_SSP_CTRL1_SDIO_IRQ) && (stat & BM_SSP_CTRL1_SDIO_IRQ_EN)) {
spin_lock_irqsave(&host->lock, flags);
mmc_signal_sdio_irq(host->mmc);
spin_unlock_irqrestore(&host->lock, flags);
}
Regards,
Shawn
^ permalink raw reply
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: David Brown @ 2011-02-11 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297464456.4852.34.camel@m0nster>
On Fri, Feb 11 2011, Daniel Walker wrote:
> On Fri, 2011-02-11 at 14:37 -0800, David Brown wrote:
>> It is functionality that will be shared across multiple socs. Putting
>> the name of a specific soc would just be misleading. Currently, it's
>> our only iommu. Support for another family that uses a different iommu
>> could perhaps call it iommu2.
>
> Your missing my point. I'm saying it doesn't look flexible enough to
> allow support for multiple SoCs .. Is everything going to be identical
> across all the supported socs ?
It wouldn't help, though. If the addresses differ across targets, we
don't want defines that are conditionally defined, so we would need
multiple tables, giving the address for specific targets. Still no
reason to have an indirection on the names.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Linus Walleij @ 2011-02-11 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102091013.56670.arnd@arndb.de>
2011/2/9 Arnd Bergmann <arnd@arndb.de>:
> Most of my results so far are documented on
> https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashCardSurvey
H'm! That's an interesting resource indeed. When you write
"From measurements, it appears that the size in which data is
managed is typically 64 kb on SD cards" and "the size of the
medium is always a multiple of entire allocation groups, and
the most common size today is 4 MB" and then list
Size, Allocation Unit, Write Size, Page Size, FAT Location,
open AUs linear, open AUs random, Algorithm.
How exactly do you measure that?
I'm sort of smelling a card-probe.git with this tool that you
can run on your device and get out data like that listed
in your table. We have a rather large stash of cards we can
probe for you to get that kind of data out if it is useful, and
I believe other Linaro members may have such stuff too,
if empirical data is usefult to your work.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 0/5] ARM: omap[34]: Thumb-2 compatibility fixes
From: Kevin Hilman @ 2011-02-11 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297263683-10621-1-git-send-email-dave.martin@linaro.org>
Hi Dave,
Dave Martin <dave.martin@linaro.org> writes:
> This set of patches, along with some other patches under
> discussion on alkml, should enable omap3 and omap4 kernels to be
> built with CONFIG_THUMB2_KERNEL.
OK, I tried some more testing with your 'dirty' branch merged with my PM
branch.
Compiled in ARM mode, everything worked as expected on my 3530/omap3evm,
including off-mode (in suspend and idle). My 3630 (Zoom3) also can't do
CORE off due to i583, but MPU, PER etc. all can hit off.
To rebuild in Thumb-2 mode, I disabled OMAP2 support and added Thumb-2
mode:
CONFIG_ARCH_OMAP2=n
CONFIG_THUMB2_KERNEL=y
then tested on 3530/omap3evm. Testing suspend/resume to retention
seemed to work fine. However, enabling retention during idle[1] hung
someplace (didn't debug further.)
I also tried off-mode, and suspend/resume to off didn't even work.
I didn't have time to debug this any further, so this is just to report
raw test results.
Hope that helps,
Kevin
[1] Here's what's needed to attempt low-power states during idle
# UART timeouts: omap-serial (4th UART only on OMAP36xx and OMAP4)
echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout
echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout
# enable low-power states during idle
echo 1 > /debug/pm_debug/sleep_while_idle
[2] to enable off-mode
echo 1 > /debug/pm_debug/enable_off_mode
^ permalink raw reply
* [PATCH 2/3] msm: iommu: Generalize platform data for multiple targets
From: Daniel Walker @ 2011-02-11 23:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8ya1v3ekvqg.fsf@huya.qualcomm.com>
On Fri, 2011-02-11 at 15:16 -0800, David Brown wrote:
> On Fri, Feb 11 2011, Daniel Walker wrote:
>
> > On Fri, 2011-02-11 at 14:37 -0800, David Brown wrote:
>
> >> It is functionality that will be shared across multiple socs. Putting
> >> the name of a specific soc would just be misleading. Currently, it's
> >> our only iommu. Support for another family that uses a different iommu
> >> could perhaps call it iommu2.
> >
> > Your missing my point. I'm saying it doesn't look flexible enough to
> > allow support for multiple SoCs .. Is everything going to be identical
> > across all the supported socs ?
>
> It wouldn't help, though. If the addresses differ across targets, we
> don't want defines that are conditionally defined, so we would need
> multiple tables, giving the address for specific targets. Still no
> reason to have an indirection on the names.
I'm talking about the whole deal here, this whole patch series. It
doesn't seem like this has been thought out too well.
Daniel
--
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum.
^ 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