* [PATCH 0/2] ARM: OMAP: SmartReflex: pass device dependent data via platform data
From: Jean Pihet @ 2012-10-05 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r4pdst5n.fsf@deeprootsystems.com>
On Fri, Oct 5, 2012 at 1:40 AM, Kevin Hilman
<khilman@deeprootsystems.com> wrote:
> jean.pihet at newoldbits.com writes:
>
>> From: Jean Pihet <j-pihet@ti.com>
>>
>> Remove the device dependent code (ex. cpu_is_xxx()) and settings
>> from the driver code and instead pass them via the platform
>> data. This allows a clean separation of the driver code and the platform
>> code, as required by the move of the platform header files to
>> include/linux/platform_data.
>>
>> Note about the smartreflex functional clocks: the smartreflex fclks
>> are derived from sys_clk and have the same name as the main_clk from
>> the hwmod entry, in order for the SmartReflex driver to request the
>> fclk (using clk_get(dev, "fck")).
>>
>> Based on mainline 3.6.0. Boot tested on OMAP3&4 platforms.
>
> Thanks, queuing this version for v3.8 (branch: for_3.8/pm/sr)
Thanks!
Jean
>
> Kevin
>
> P.S. in the future, It helps reviewers and maintainers if there's some
> versioning in the patches (e.g. PATCH v3 0/2]), especially when updated
> versions come in quick succession. Thanks.
>
^ permalink raw reply
* [PATCH 04/12] video: exynos: warnings in exynos_dp_core.c
From: Jingoo Han @ 2012-10-05 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348868177-21205-5-git-send-email-arnd@arndb.de>
On Saturday, September 29, 2012 6:36 AM Arnd Bergmann wrote
>
> Something is wrong with the exynos_dp_core logic, and gcc
> emits a warning about this. An array is declared in
> exynos_dp_process_equalizer_training with length '2',
> and exynos_dp_channel_eq_ok tries to access the third
> element of it.
>
> This patch is certainly not correct, but hopefully helps
> highlight the actual problem. The problem apparently was
> introduced by d5c0eed01 "video: exynos_dp: adjust voltage
> swing and pre-emphasis during Link Training".
>
> This is what we get in exynos_defconfig:
> drivers/video/exynos/exynos_dp_core.c: In function 'exynos_dp_process_equalizer_training':
> drivers/video/exynos/exynos_dp_core.c:341:13: warning: array subscript is above array bounds [-Warray-
> bounds]
Hi Arnd Bergmann,
This problem was fixed. So, this patch is not necessary.
As you mentioned, this problem was introduced by d5c0eed01
"video: exynos_dp: adjust voltage swing and pre-emphasis
during Link Training".
However, this problem was resolved by e75478b "video: exynos_dp:
replace link_status with link_align to check channel equalization".
The patch was merged to 'fbdev-next', and will be merged to
'3.7-rc1', soon. Thank you.
Best regards,
Jingoo Han
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
> ---
> drivers/video/exynos/exynos_dp_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/exynos/exynos_dp_core.c b/drivers/video/exynos/exynos_dp_core.c
> index cdc1398..358b595 100644
> --- a/drivers/video/exynos/exynos_dp_core.c
> +++ b/drivers/video/exynos/exynos_dp_core.c
> @@ -542,7 +542,7 @@ reduce_link_rate:
>
> static int exynos_dp_process_equalizer_training(struct exynos_dp_device *dp)
> {
> - u8 link_status[2];
> + u8 link_status[3];
> u8 link_align[3];
> int lane;
> int lane_count;
> --
> 1.7.10
^ permalink raw reply
* [RFC] arm/mm: add a protection when flushing anonymous pages
From: Andrew Yan-Pai Chen @ 2012-10-05 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANj_sbADwtPR6cgk05QkmvrSUOOQRYXB9vPB6KATKEmwcN8UrA@mail.gmail.com>
On Tue, Oct 2, 2012 at 3:07 PM, Andrew Yan-Pai Chen
<yanpai.chen@gmail.com> wrote:
> On Mon, Oct 1, 2012 at 11:50 AM, Jason Lin <kernel.jason@gmail.com> wrote:
>>
>> Dear all:
>> By the way, I used the CPU with VIPT cache.
>> Thanks.
>>
>> 2012/10/1 Jason Lin <kernel.jason@gmail.com>:
>> > Dear all:
>> > When I do LTP direct I/O tests, it produced a cache coherence issue
>> > caused by flush_pfn_alias() (arch/arm/mm/flush.c).
>> > I think we should to disable preemption or lock before setting page
>> > table and enable preemption or unlock after flushing pages
>> >
>> > Any comments are appreciated.
>> > Thanks.
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> [RFC PATCH] make flush_pfn_alias() nonpreemptible
>
> Since flush_pfn_alias() is preemptible, it is possible to be
> preempted just after set_top_pte() is done. If the process
> which preempts the previous happened to invoke flush_pfn_alias()
> with the same colour vaddr as that of the previous, the same
> top pte will be overwritten. When switching back to the previous,
> it attempts to flush cache lines with incorrect mapping. Then
> no lines (or wrong lines) will be flushed because of the nature
> of vipt caches.
>
> diff --git a/arch/arm/mm/flush.c b/arch/arm/mm/flush.c
> index 40ca11e..bd07918 100644
> --- a/arch/arm/mm/flush.c
> +++ b/arch/arm/mm/flush.c
> @@ -27,6 +27,8 @@ static void flush_pfn_alias(unsigned long pfn,
> unsigned long vaddr)
> unsigned long to = FLUSH_ALIAS_START + (CACHE_COLOUR(vaddr) <<
> PAGE_SHIFT);
> const int zero = 0;
>
> + preempt_disable();
> +
> set_top_pte(to, pfn_pte(pfn, PAGE_KERNEL));
>
> asm( "mcrr p15, 0, %1, %0, c14\n"
> @@ -34,6 +36,8 @@ static void flush_pfn_alias(unsigned long pfn,
> unsigned long vaddr)
> :
> : "r" (to), "r" (to + PAGE_SIZE - L1_CACHE_BYTES), "r" (zero)
> : "cc");
> +
> + preempt_enable();
> }
>
> --
> Regards,
> Andrew
Hi Russell,
We met the problem when running the direct I/O test (diotest03) in LTP
testsuite on PB1176.
And we got the error messages:
bufcmp: offset 224: Expected: 0x1b, got 0x1a
diotest03 1 TFAIL : comparsion failed; child=11 offset=1069056
diotest03 2 TFAIL : Read Direct-child 11 failed
...
The error was gone after applying this patch.
Any idea would be appreciated.
--
Regards,
Andrew
^ permalink raw reply
* [PATCH] spi/pl022: Activate resourses before deactivate them in suspend
From: Ulf Hansson @ 2012-10-05 7:43 UTC (permalink / raw)
To: linux-arm-kernel
From: Ulf Hansson <ulf.hansson@linaro.org>
To be able to deactivate resourses in suspend, the resourses must
first be surely active. This is done with a pm_runtime_get_sync.
Once the resourses are restored to active state again in resume,
the runtime pm usage count can be decreased with a pm_runtime_put.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
---
drivers/spi/spi-pl022.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 9194641..c3590e0 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2350,6 +2350,8 @@ static int pl022_suspend(struct device *dev)
dev_warn(dev, "cannot suspend master\n");
return ret;
}
+
+ pm_runtime_get_sync(dev);
pl022_suspend_resources(pl022);
dev_dbg(dev, "suspended\n");
@@ -2362,6 +2364,7 @@ static int pl022_resume(struct device *dev)
int ret;
pl022_resume_resources(pl022);
+ pm_runtime_put(dev);
/* Start the queue running */
ret = spi_master_resume(pl022->master);
--
1.7.10
^ permalink raw reply related
* [PATCH 14/24] USB: ohci: merge ohci_finish_controller_resume with ohci_resume
From: Nicolas Ferre @ 2012-10-05 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349363872-27004-15-git-send-email-florian@openwrt.org>
On 10/04/2012 05:17 PM, Florian Fainelli :
> Merge ohci_finish_controller_resume with ohci_resume as suggested by Alan
> Stern. Since ohci_finish_controller_resume no longer exists, update the
> various OHCI drivers to call ohci_resume() instead. Some drivers used to set
> themselves the bit HCD_FLAG_HW_ACCESSIBLE, which is now handled by
> ohci_resume().
>
> Signed-off-by: Florian Fainelli <florian@openwrt.org>
> ---
> drivers/usb/host/ohci-at91.c | 2 +-
Seems ok for AT91, so
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks Florian, bye,
> drivers/usb/host/ohci-ep93xx.c | 2 +-
> drivers/usb/host/ohci-exynos.c | 5 +----
> drivers/usb/host/ohci-hcd.c | 41 +++++++++++++++++++++++++++++++++++--
> drivers/usb/host/ohci-hub.c | 42 --------------------------------------
> drivers/usb/host/ohci-omap.c | 2 +-
> drivers/usb/host/ohci-platform.c | 2 +-
> drivers/usb/host/ohci-pxa27x.c | 2 +-
> drivers/usb/host/ohci-s3c2410.c | 3 +--
> drivers/usb/host/ohci-spear.c | 2 +-
> drivers/usb/host/ohci-tmio.c | 2 +-
> 11 files changed, 48 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
> index 0bf72f9..908d84a 100644
> --- a/drivers/usb/host/ohci-at91.c
> +++ b/drivers/usb/host/ohci-at91.c
> @@ -705,7 +705,7 @@ static int ohci_hcd_at91_drv_resume(struct platform_device *pdev)
> if (!clocked)
> at91_start_clock();
>
> - ohci_finish_controller_resume(hcd);
> + ohci_resume(hcd, false);
> return 0;
> }
> #else
> diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
> index dbfbd1d..a982f04 100644
> --- a/drivers/usb/host/ohci-ep93xx.c
> +++ b/drivers/usb/host/ohci-ep93xx.c
> @@ -194,7 +194,7 @@ static int ohci_hcd_ep93xx_drv_resume(struct platform_device *pdev)
>
> ep93xx_start_hc(&pdev->dev);
>
> - ohci_finish_controller_resume(hcd);
> + ohci_resume(hcd, false);
> return 0;
> }
> #endif
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> index fc3091b..53c5a989 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -252,10 +252,7 @@ static int exynos_ohci_resume(struct device *dev)
> if (pdata && pdata->phy_init)
> pdata->phy_init(pdev, S5P_USB_PHY_HOST);
>
> - /* Mark hardware accessible again as we are out of D3 state by now */
> - set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
> -
> - ohci_finish_controller_resume(hcd);
> + ohci_resume(hcd, false);
>
> return 0;
> }
> diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
> index 5d30992..568bdb3 100644
> --- a/drivers/usb/host/ohci-hcd.c
> +++ b/drivers/usb/host/ohci-hcd.c
> @@ -1003,13 +1003,50 @@ static int __maybe_unused ohci_suspend(struct usb_hcd *hcd, bool do_wakeup)
>
> static int __maybe_unused ohci_resume(struct usb_hcd *hcd, bool hibernated)
> {
> + struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> + int port;
> + bool need_reinit = false;
> +
> set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
>
> /* Make sure resume from hibernation re-enumerates everything */
> if (hibernated)
> - ohci_usb_reset(hcd_to_ohci(hcd));
> + ohci_usb_reset(ohci);
> +
> + /* See if the controller is already running or has been reset */
> + ohci->hc_control = ohci_readl(ohci, &ohci->regs->control);
> + if (ohci->hc_control & (OHCI_CTRL_IR | OHCI_SCHED_ENABLES)) {
> + need_reinit = true;
> + } else {
> + switch (ohci->hc_control & OHCI_CTRL_HCFS) {
> + case OHCI_USB_OPER:
> + case OHCI_USB_RESET:
> + need_reinit = true;
> + }
> + }
> +
> + /* If needed, reinitialize and suspend the root hub */
> + if (need_reinit) {
> + spin_lock_irq(&ohci->lock);
> + ohci_rh_resume(ohci);
> + ohci_rh_suspend(ohci, 0);
> + spin_unlock_irq(&ohci->lock);
> + }
> +
> + /* Normally just turn on port power and enable interrupts */
> + else {
> + ohci_dbg(ohci, "powerup ports\n");
> + for (port = 0; port < ohci->num_ports; port++)
> + ohci_writel(ohci, RH_PS_PPS,
> + &ohci->regs->roothub.portstatus[port]);
> +
> + ohci_writel(ohci, OHCI_INTR_MIE, &ohci->regs->intrenable);
> + ohci_readl(ohci, &ohci->regs->intrenable);
> + msleep(20);
> + }
> +
> + usb_hcd_resume_root_hub(hcd);
>
> - ohci_finish_controller_resume(hcd);
> return 0;
> }
>
> diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
> index 2f3619e..db09dae 100644
> --- a/drivers/usb/host/ohci-hub.c
> +++ b/drivers/usb/host/ohci-hub.c
> @@ -316,48 +316,6 @@ static int ohci_bus_resume (struct usb_hcd *hcd)
> return rc;
> }
>
> -/* Carry out the final steps of resuming the controller device */
> -static void __maybe_unused ohci_finish_controller_resume(struct usb_hcd *hcd)
> -{
> - struct ohci_hcd *ohci = hcd_to_ohci(hcd);
> - int port;
> - bool need_reinit = false;
> -
> - /* See if the controller is already running or has been reset */
> - ohci->hc_control = ohci_readl(ohci, &ohci->regs->control);
> - if (ohci->hc_control & (OHCI_CTRL_IR | OHCI_SCHED_ENABLES)) {
> - need_reinit = true;
> - } else {
> - switch (ohci->hc_control & OHCI_CTRL_HCFS) {
> - case OHCI_USB_OPER:
> - case OHCI_USB_RESET:
> - need_reinit = true;
> - }
> - }
> -
> - /* If needed, reinitialize and suspend the root hub */
> - if (need_reinit) {
> - spin_lock_irq(&ohci->lock);
> - ohci_rh_resume(ohci);
> - ohci_rh_suspend(ohci, 0);
> - spin_unlock_irq(&ohci->lock);
> - }
> -
> - /* Normally just turn on port power and enable interrupts */
> - else {
> - ohci_dbg(ohci, "powerup ports\n");
> - for (port = 0; port < ohci->num_ports; port++)
> - ohci_writel(ohci, RH_PS_PPS,
> - &ohci->regs->roothub.portstatus[port]);
> -
> - ohci_writel(ohci, OHCI_INTR_MIE, &ohci->regs->intrenable);
> - ohci_readl(ohci, &ohci->regs->intrenable);
> - msleep(20);
> - }
> -
> - usb_hcd_resume_root_hub(hcd);
> -}
> -
> /* Carry out polling-, autostop-, and autoresume-related state changes */
> static int ohci_root_hub_state_changes(struct ohci_hcd *ohci, int changed,
> int any_connected, int rhsc_status)
> diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
> index f8b2d91..9fab4d8 100644
> --- a/drivers/usb/host/ohci-omap.c
> +++ b/drivers/usb/host/ohci-omap.c
> @@ -530,7 +530,7 @@ static int ohci_omap_resume(struct platform_device *dev)
> ohci->next_statechange = jiffies;
>
> omap_ohci_clock_power(1);
> - ohci_finish_controller_resume(hcd);
> + ohci_resume(hcd, false);
> return 0;
> }
>
> diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
> index 1caaf65..99d1755 100644
> --- a/drivers/usb/host/ohci-platform.c
> +++ b/drivers/usb/host/ohci-platform.c
> @@ -203,7 +203,7 @@ static int ohci_platform_resume(struct device *dev)
> return err;
> }
>
> - ohci_finish_controller_resume(hcd);
> + ohci_resume(hcd, false);
> return 0;
> }
>
> diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
> index 77f4402..8bffde3 100644
> --- a/drivers/usb/host/ohci-pxa27x.c
> +++ b/drivers/usb/host/ohci-pxa27x.c
> @@ -591,7 +591,7 @@ static int ohci_hcd_pxa27x_drv_resume(struct device *dev)
> /* Select Power Management Mode */
> pxa27x_ohci_select_pmm(ohci, inf->port_mode);
>
> - ohci_finish_controller_resume(hcd);
> + ohci_resume(hcd, false);
> return 0;
> }
>
> diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
> index 664c869..8af53c6 100644
> --- a/drivers/usb/host/ohci-s3c2410.c
> +++ b/drivers/usb/host/ohci-s3c2410.c
> @@ -524,8 +524,7 @@ static int ohci_hcd_s3c2410_drv_resume(struct device *dev)
>
> s3c2410_start_hc(pdev, hcd);
>
> - set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
> - ohci_finish_controller_resume(hcd);
> + ohci_resume(hcd, false);
>
> return 0;
> }
> diff --git a/drivers/usb/host/ohci-spear.c b/drivers/usb/host/ohci-spear.c
> index fc7305e..d607be3 100644
> --- a/drivers/usb/host/ohci-spear.c
> +++ b/drivers/usb/host/ohci-spear.c
> @@ -231,7 +231,7 @@ static int spear_ohci_hcd_drv_resume(struct platform_device *dev)
> ohci->next_statechange = jiffies;
>
> spear_start_ohci(ohci_p);
> - ohci_finish_controller_resume(hcd);
> + ohci_resume(hcd, false);
> return 0;
> }
> #endif
> diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c
> index 60c2b07..2c9ab8f 100644
> --- a/drivers/usb/host/ohci-tmio.c
> +++ b/drivers/usb/host/ohci-tmio.c
> @@ -352,7 +352,7 @@ static int ohci_hcd_tmio_drv_resume(struct platform_device *dev)
>
> spin_unlock_irqrestore(&tmio->lock, flags);
>
> - ohci_finish_controller_resume(hcd);
> + ohci_resume(hcd, false);
>
> return 0;
> }
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] ARM: EXYNOS: Remove wrong I2S0 clock from peril clock
From: Sangsu Park @ 2012-10-05 7:37 UTC (permalink / raw)
To: linux-arm-kernel
Remove I2S0 clk from peril since peril clock doesn't have I2S0 clk for EXYNOS4.
Audio Subsystem block has I2S0 clk.
Signed-off-by: Sangsu Park <sangsu4u.park@samsung.com>
---
arch/arm/mach-exynos/clock-exynos4.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos4.c
b/arch/arm/mach-exynos/clock-exynos4.c
index 6a45c9a..fa8a134 100644
--- a/arch/arm/mach-exynos/clock-exynos4.c
+++ b/arch/arm/mach-exynos/clock-exynos4.c
@@ -613,11 +613,6 @@ static struct clk exynos4_init_clocks_off[] = {
.ctrlbit = (1 << 18),
}, {
.name = "iis",
- .devname = "samsung-i2s.0",
- .enable = exynos4_clk_ip_peril_ctrl,
- .ctrlbit = (1 << 19),
- }, {
- .name = "iis",
.devname = "samsung-i2s.1",
.enable = exynos4_clk_ip_peril_ctrl,
.ctrlbit = (1 << 20),
--
1.7.9.5
^ permalink raw reply related
* alignment faults in 3.6
From: Russell King - ARM Linux @ 2012-10-05 7:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506E1762.3010601@gmail.com>
On Thu, Oct 04, 2012 at 06:10:26PM -0500, Rob Herring wrote:
> I would think the scheduling while atomic messages are harmless in this
> case. However, in addition to spewing out BUG messages this commit also
> seems to eventually cause a kernel panic in __napi_complete. That panic
> seems to go away if I put barrier() between the 2 accesses above which
> eliminates the alignment faults. I haven't figured that part out yet.
>
> There's at least a couple of problems here:
>
> This seems like an overly aggressive compiler optimization considering
> unaligned accesses are not supported by ldm/stm.
>
> The alignment fault handler should handle kernel address faults atomically.
This is bad news. do_alignment() can be called in almost any kernel
context, and it must work. die() and oops dumps - specifically dump_mem()
and dump_instr() will suffer from exactly the same problem.
Will, can you take a look please?
^ permalink raw reply
* [PATCHv4] Input: keypad: Add smsc ece1099 keypad driver
From: Sourav Poddar @ 2012-10-05 7:26 UTC (permalink / raw)
To: linux-arm-kernel
From: G, Manjunath Kondaiah <manjugk@ti.com>
SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
supports a keypad scan matrix of 23*8.This driver uses this
device as a keypad driver.
Tested on omap5430 evm with 3.6-rc6 custom kernel.
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: G, Manjunath Kondaiah <manjugk@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
---
This patch was posted as a series initially
http://www.spinics.net/lists/linux-omap/msg78772.html
But the parent mfd driver has beeen already picked by mfd maintainer.
So this patch can now posted as an standalone patch.
v3->v4:
Fix Dmitry's comments:
- Error patch(input_free_device/input_unregister_device).
- Few cleanups.
- Included INPUT_MATRIXKMAP
drivers/input/keyboard/Kconfig | 12 +
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/smsc-ece1099-keypad.c | 303 ++++++++++++++++++++++++++
3 files changed, 316 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/keyboard/smsc-ece1099-keypad.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index c50fa75..e370b03 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -593,6 +593,18 @@ config KEYBOARD_TWL4030
To compile this driver as a module, choose M here: the
module will be called twl4030_keypad.
+config KEYBOARD_SMSC
+ tristate "SMSC ECE1099 keypad support"
+ depends on I2C
+ select INPUT_MATRIXKMAP
+ help
+ Say Y here if your board use the smsc keypad controller
+ for omap5 defconfig. It's safe to say enable this
+ even on boards that don't use the keypad controller.
+
+ To compile this driver as a module, choose M here: the
+ module will be called smsc-ece1099-keypad.
+
config KEYBOARD_XTKBD
tristate "XT keyboard"
select SERIO
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 44e7600..0f2aa26 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
obj-$(CONFIG_KEYBOARD_TNETV107X) += tnetv107x-keypad.o
obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
+obj-$(CONFIG_KEYBOARD_SMSC) += smsc-ece1099-keypad.o
obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
diff --git a/drivers/input/keyboard/smsc-ece1099-keypad.c b/drivers/input/keyboard/smsc-ece1099-keypad.c
new file mode 100644
index 0000000..a4a0dfe
--- /dev/null
+++ b/drivers/input/keyboard/smsc-ece1099-keypad.c
@@ -0,0 +1,303 @@
+/*
+ * SMSC_ECE1099 Keypad driver
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.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.
+ */
+
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/input.h>
+#include <linux/gpio.h>
+#include <linux/slab.h>
+#include <linux/jiffies.h>
+#include <linux/input/matrix_keypad.h>
+#include <linux/delay.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/smsc.h>
+#include <linux/of_gpio.h>
+#include <linux/of.h>
+
+#define KEYPRESS_TIME 200
+
+struct smsc_keypad {
+ struct smsc *smsc;
+ struct matrix_keymap_data *keymap_data;
+ unsigned int last_key_state[16];
+ unsigned int last_col;
+ unsigned int last_key_ms[16];
+ unsigned short *keymap;
+ struct i2c_client *client;
+ struct input_dev *input;
+ int rows, cols;
+ int row_shift;
+ bool no_autorepeat;
+ unsigned irq;
+ struct device *dev;
+};
+
+static void smsc_kp_scan(struct smsc_keypad *kp)
+{
+ struct input_dev *input = kp->input;
+ int i, j;
+ int row, col;
+ int temp, code;
+ unsigned int new_state[16];
+ unsigned int bits_changed;
+ int this_ms;
+
+ smsc_write(kp->dev, SMSC_KP_INT_MASK, 0x00);
+ smsc_write(kp->dev, SMSC_KP_INT_STAT, 0xFF);
+
+ /* Scan for row and column */
+ for (i = 0; i < kp->cols; i++) {
+ smsc_write(kp->dev, SMSC_KP_OUT, SMSC_KSO_EVAL + i);
+ /* Read Row Status */
+ smsc_read(kp->dev, SMSC_KP_IN, &temp);
+ if (temp == 0xFF)
+ continue;
+
+ col = i;
+ for (j = 0; j < kp->rows; j++) {
+ if ((temp & 0x01) != 0x00) {
+ temp = temp >> 1;
+ continue;
+ }
+
+ row = j;
+ new_state[col] = (1 << row);
+ bits_changed = kp->last_key_state[col] ^ new_state[col];
+ this_ms = jiffies_to_msecs(jiffies);
+ if (bits_changed != 0 || (!bits_changed &&
+ ((this_ms - kp->last_key_ms[col]) >= KEYPRESS_TIME))) {
+ code = MATRIX_SCAN_CODE(row, col, kp->row_shift);
+ input_event(input, EV_MSC, MSC_SCAN, code);
+ input_report_key(input, kp->keymap[code], 1);
+ input_report_key(input, kp->keymap[code], 0);
+ kp->last_key_state[col] = new_state[col];
+ if (kp->last_col != col)
+ kp->last_key_state[kp->last_col] = 0;
+ kp->last_key_ms[col] = this_ms;
+ }
+ temp = temp >> 1;
+ }
+ }
+ input_sync(input);
+
+ smsc_write(kp->dev, SMSC_KP_INT_MASK, 0xFF);
+
+ /* Set up Low Power Mode (Wake-up) (0xFB) */
+ smsc_write(kp->dev, SMSC_WKUP_CTRL, SMSC_KP_SET_LOW_PWR);
+
+ /*Enable Keypad Scan (generate interrupt on key press) (0x40)*/
+ smsc_write(kp->dev, SMSC_KP_OUT, SMSC_KSO_ALL_LOW);
+}
+
+static irqreturn_t do_kp_irq(int irq, void *_kp)
+{
+ struct smsc_keypad *kp = _kp;
+ int int_status;
+
+ smsc_read(kp->dev, SMSC_KP_INT_STAT, &int_status);
+ if (int_status)
+ smsc_kp_scan(kp);
+
+ return IRQ_HANDLED;
+}
+
+#ifdef CONFIG_OF
+static int __devinit smsc_keypad_parse_dt(struct device *dev,
+ struct smsc_keypad *kp)
+{
+ struct device_node *np = dev->of_node;
+
+ if (!np) {
+ dev_err(dev, "missing DT data");
+ return -EINVAL;
+ }
+
+ of_property_read_u32(np, "keypad,num-rows", &kp->rows);
+ of_property_read_u32(np, "keypad,num-columns", &kp->cols);
+ if (!kp->rows || !kp->cols) {
+ dev_err(dev, "number of keypad rows/columns not specified\n");
+ return -EINVAL;
+ }
+
+ if (of_property_read_bool(np, "linux,input-no-autorepeat"))
+ kp->no_autorepeat = true;
+
+ return 0;
+}
+#else
+static inline int smsc_keypad_parse_dt(struct device *dev,
+ struct smsc_keypad *kp)
+{
+ return -ENOSYS;
+}
+#endif
+
+static int __devinit
+smsc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct smsc *smsc = dev_get_drvdata(pdev->dev.parent);
+ struct input_dev *input;
+ struct smsc_keypad *kp;
+ int ret = 0;
+ int i, max_keys, row_shift;
+ int irq;
+ int addr;
+
+ kp = devm_kzalloc(dev, sizeof(*kp), GFP_KERNEL);
+
+ input = input_allocate_device();
+ if (!kp || !input) {
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ ret = smsc_keypad_parse_dt(&pdev->dev, kp);
+ if (ret)
+ goto err1;
+
+ /* Get the debug Device */
+ kp->input = input;
+ kp->smsc = smsc;
+ kp->irq = platform_get_irq(pdev, 0);
+ kp->dev = dev;
+
+ /* setup input device */
+ __set_bit(EV_KEY, input->evbit);
+
+ /* Enable auto repeat feature of Linux input subsystem */
+ if (!kp->no_autorepeat)
+ __set_bit(EV_REP, input->evbit);
+
+ input_set_capability(input, EV_MSC, MSC_SCAN);
+ input->name = "SMSC Keypad";
+ input->phys = "smsc_keypad/input0";
+ input->dev.parent = &pdev->dev;
+ input->id.bustype = BUS_HOST;
+ input->id.vendor = 0x0001;
+ input->id.product = 0x0001;
+ input->id.version = 0x0003;
+
+ /* Mask all GPIO interrupts (0x37-0x3B) */
+ for (addr = SMSC_GPIO_INT_MASK_START;
+ addr < SMSC_GPIO_INT_MASK_START + 4; addr++)
+ smsc_write(dev, addr, 0);
+
+ /* Set all outputs high (0x05-0x09) */
+ for (addr = SMSC_GPIO_DATA_OUT_START;
+ addr < SMSC_GPIO_DATA_OUT_START + 4; addr++)
+ smsc_write(dev, addr, 0xff);
+
+ /* Clear all GPIO interrupts (0x32-0x36) */
+ for (addr = SMSC_GPIO_INT_STAT_START;
+ addr < SMSC_GPIO_INT_STAT_START + 4; addr++)
+ smsc_write(dev, addr, 0xff);
+
+ /* Configure the smsc pins as Keyboard scan Input */
+ for (i = 0; i <= kp->rows; i++) {
+ addr = 0x12 + i;
+ smsc_write(dev, addr, SMSC_KP_KSI);
+ }
+
+ /* Configure the smsc pins as Keyboard scan output */
+ for (i = 0; i <= kp->cols; i++) {
+ addr = 0x1A + i;
+ smsc_write(dev, addr, SMSC_KP_KSO);
+ }
+
+ smsc_write(dev, SMSC_KP_INT_STAT, SMSC_KP_SET_HIGH);
+ smsc_write(dev, SMSC_WKUP_CTRL, SMSC_KP_SET_LOW_PWR);
+ smsc_write(dev, SMSC_KP_OUT, SMSC_KSO_ALL_LOW);
+
+ row_shift = get_count_order(kp->cols);
+ max_keys = kp->rows << row_shift;
+
+ kp->row_shift = row_shift;
+ kp->keymap = devm_kzalloc(dev, max_keys * sizeof(kp->keymap[0]),
+ GFP_KERNEL);
+ if (!kp->keymap) {
+ dev_err(&pdev->dev, "Not enough memory for keymap\n");
+ ret = -ENOMEM;
+ }
+
+ ret = matrix_keypad_build_keymap(NULL, NULL, kp->rows,
+ kp->cols, kp->keymap, input);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to build keymap\n");
+ goto err1;
+ }
+
+ /*
+ * This ISR will always execute in kernel thread context because of
+ * the need to access the SMSC over the I2C bus.
+ */
+ ret = devm_request_threaded_irq(dev, kp->irq, NULL, do_kp_irq,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT, pdev->name, kp);
+ if (ret) {
+ dev_dbg(&pdev->dev, "request_irq failed for irq no=%d\n",
+ irq);
+ goto err1;
+ }
+
+ /* Enable smsc keypad interrupts */
+ ret = smsc_write(dev, SMSC_KP_INT_MASK, 0xff);
+ if (ret < 0)
+ goto err2;
+
+ ret = input_register_device(input);
+ if (ret) {
+ dev_err(kp->dev,
+ "Unable to register twl4030 keypad device\n");
+ goto err2;
+ }
+
+ return 0;
+
+err2:
+ free_irq(kp->irq, kp);
+err1:
+ input_free_device(input);
+ return ret;
+}
+
+static int __devexit smsc_remove(struct platform_device *pdev)
+{
+ struct smsc_keypad *kp = platform_get_drvdata(pdev);
+ input_unregister_device(kp->input);
+
+ return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id smsc_keypad_dt_match[] = {
+ { .compatible = "smsc,keypad" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, smsc_keypad_dt_match);
+#endif
+
+static struct platform_driver smsc_driver = {
+ .driver = {
+ .name = "smsc-keypad",
+ .of_match_table = of_match_ptr(smsc_keypad_dt_match),
+ .owner = THIS_MODULE,
+ },
+ .probe = smsc_probe,
+ .remove = __devexit_p(smsc_remove),
+};
+
+module_platform_driver(smsc_driver);
+
+MODULE_AUTHOR("G Kondaiah Manjunath <manjugk@ti.com>");
+MODULE_DESCRIPTION("SMSC ECE1099 Keypad driver");
+MODULE_LICENSE("GPL v2");
--
1.7.1
^ permalink raw reply related
* [PATCH v1 01/14] media: s5p-hdmi: add HPD GPIO to platform data
From: Kyungmin Park @ 2012-10-05 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001301cda20c$d7691db0$863b5910$%dae@samsung.com>
Hi Mauro,
If you don't mind can we merge this patch at drm tree? the remainig
patches will be merged by Tomasz S.
To Marek & Tomasz,
Can you give your acks?
Thank you,
Kyungmin Park
On 10/4/12, Inki Dae <inki.dae@samsung.com> wrote:
> Hello Media guys,
>
> This is dependent of exynos drm patch set to be merged to mainline so if
> there is no problem then please, give me ack so that I can merge this patch
> with exynos drm patch set.
>
> Thanks,
> Inki Dae
>
>> -----Original Message-----
>> From: RAHUL SHARMA [mailto:rahul.sharma at samsung.com]
>> Sent: Thursday, October 04, 2012 4:40 PM
>> To: Tomasz Stanislawski; Kyungmin Park; linux-arm-
>> kernel at lists.infradead.org; linux-media at vger.kernel.org
>> Cc: In-Ki Dae; SUNIL JOSHI; r.sh.open at gmail.com
>> Subject: Re: [PATCH v1 01/14] media: s5p-hdmi: add HPD GPIO to platform
>> data
>>
>> Hi Mr. Tomasz, Mr. Park, list,
>>
>> First patch in the following set belongs to s5p-media, rest to
>> exynos-drm.
>> Please review the media patch so that It can be merged for mainline.
>>
>> regards,
>> Rahul Sharma
>>
>> On Thu, Oct 4, 2012 at 9:12 PM, Rahul Sharma <rahul.sharma@samsung.com>
>> wrote:
>> > From: Tomasz Stanislawski <t.stanislaws@samsung.com>
>> >
>> > This patch extends s5p-hdmi platform data by a GPIO identifier for
>> > Hot-Plug-Detection pin.
>> >
>> > Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com>
>> > Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
>> > ---
>> > include/media/s5p_hdmi.h | 2 ++
>> > 1 files changed, 2 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
>> > index 361a751..181642b 100644
>> > --- a/include/media/s5p_hdmi.h
>> > +++ b/include/media/s5p_hdmi.h
>> > @@ -20,6 +20,7 @@ struct i2c_board_info;
>> > * @hdmiphy_info: template for HDMIPHY I2C device
>> > * @mhl_bus: controller id for MHL control bus
>> > * @mhl_info: template for MHL I2C device
>> > + * @hpd_gpio: GPIO for Hot-Plug-Detect pin
>> > *
>> > * NULL pointer for *_info fields indicates that
>> > * the corresponding chip is not present
>> > @@ -29,6 +30,7 @@ struct s5p_hdmi_platform_data {
>> > struct i2c_board_info *hdmiphy_info;
>> > int mhl_bus;
>> > struct i2c_board_info *mhl_info;
>> > + int hpd_gpio;
>> > };
>> >
>> > #endif /* S5P_HDMI_H */
>> > --
>> > 1.7.0.4
>> >
>> >
>> > _______________________________________________
>> > linux-arm-kernel mailing list
>> > linux-arm-kernel at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* alignment faults in 3.6
From: Russell King - ARM Linux @ 2012-10-05 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAG5Tg6V0Vj9HTy3=AU-q+Qa3DuJs6R1Kw+3uOWU_jOGfkgyXzw@mail.gmail.com>
On Fri, Oct 05, 2012 at 03:25:16AM +0100, Mans Rullgard wrote:
> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
> > This struct is the IP header, so a struct ptr is just set to the
> > beginning of the received data. Since ethernet headers are 14 bytes,
> > often the IP header is not aligned unless the NIC can place the frame at
> > a 2 byte offset (which is something I need to investigate). So this
> > function cannot make any assumptions about the alignment. Does the ABI
> > define structs have some minimum alignment? Does the struct need to be
> > declared as packed or something?
>
> The ABI defines the alignment of structs as the maximum alignment of its
> members. Since this struct contains 32-bit members, the alignment for the
> whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
> might be unaligned (in addition to removing any holes within).
This has come up before in the past.
The Linux network folk will _not_ allow - in any shape or form - for
this struct to be marked packed (it's the struct which needs to be
marked packed) because by doing so, it causes GCC to issue byte loads/
stores on architectures where there isn't a problem, and that decreases
the performance of the Linux IP stack unnecessarily.
I don't think there's going to be a satisfactory answer to this issue.
I think we're going to be stuck between GCC people saying that the
kernel is buggy, and the network people refusing to fix this as they
have done in the past.
^ permalink raw reply
* [PATCH] ARM : i.MX27 : split code for allocation of ressources of camera and eMMA
From: javier Martin @ 2012-10-05 6:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C+NNQr0mo6P2cKx4RxFoQPyYuPZq4eFUZnvi_7gTRkBQ@mail.gmail.com>
Hi Fabio,
On 4 October 2012 16:07, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Javier,
>
> On Wed, Sep 5, 2012 at 3:20 PM, Fabio Estevam <festevam@gmail.com> wrote:
>
>> Sylwester suggested me this patch and it fixed the issue:
>> http://git.linuxtv.org/snawrocki/media.git/commitdiff/458b9b5ab8cb970887c9d1f1fddf88399b2d9ef2
>>
>> Now ov2640 probes correctly on mx31pdk, but on mx27pdk I have:
>>
>> soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
>> mx2-camera mx2-camera.0: Camera driver attached to camera 0
>> ov2640 0-0030: Product ID error fb:fb
>> mx2-camera mx2-camera.0: Camera driver detached from camera 0
>> mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock
>> frequency: 66500000
>>
>> This works fine in 3.4.10 and I suspect this problem is due to the imx
>> clock conversion as the csi clock frequency looks incorrect.
>>
>> Javier,
>>
> Could you please confirm if your camera works with the latest kernel?
>
> If so, could you please your log below?
>
> Not sure if the clock frequency below is correct.
>
>> soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
>> mx2-camera mx2-camera.0: Camera driver attached to camera 0
>> ov2640 0-0030: Product ID error fb:fb
>> mx2-camera mx2-camera.0: Camera driver detached from camera 0
>> mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock
>> frequency: 66500000
>
No, it isn't. Kernel 3.6 works properly in our Visstrim M10 board and
the CSI clock frequency is the same as yours:
soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
mx2-camera mx2-camera.0: Camera driver attached to camera 0
ov7670 0-0021: chip found @ 0x42 (imx-i2c)
mx2-camera mx2-camera.0: Invalid format code #1: 4098
mx2-camera mx2-camera.0: Invalid format code #1: 4098
mx2-camera mx2-camera.0: Camera driver detached from camera 0
mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock
frequency: 66500000
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
^ permalink raw reply
* [PATCH] ARM: Push selects for TWD/SCU into machine entries
From: Santosh Shilimkar @ 2012-10-05 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121005011237.GA17182@verge.net.au>
On Friday 05 October 2012 06:42 AM, Simon Horman wrote:
> On Thu, Oct 04, 2012 at 02:41:46PM +0530, Santosh Shilimkar wrote:
>> On Thursday 04 October 2012 02:20 PM, Stephen Boyd wrote:
>>> The TWD and SCU configs are selected by default as long as
>>> SCORPIONMP is false and/or MCT is false. Implementing the logic
>>> this way certainly saves lines in the Kconfig but it precludes
>>> those machines which select SCORPIONMP or MCT from participating
>>> in the single zImage effort because when those machines are
>>> combined with other SMP capable machines the TWD and SCU are no
>>> longer selected.
>>>
>>> Push the select out to the machine entries so that we can compile
>>> these machines together and still select the appropriate configs.
>>>
>>> Signed-off-by: Stephen Boyd<sboyd@codeaurora.org>
>>> Cc: David Brown<davidb@codeaurora.org>
>>> Cc: Kukjin Kim<kgene.kim@samsung.com>
>>> Cc: Linus Walleij<linus.walleij@linaro.org>
>>> Cc: Pawel Moll<pawel.moll@arm.com>
>>> Cc: Rob Herring<rob.herring@calxeda.com>
>>> Cc: Russell King<linux@arm.linux.org.uk>
>>> Cc: Sascha Hauer<kernel@pengutronix.de>
>>> Cc: Shiraz Hashim<shiraz.hashim@st.com>
>>> Cc: Simon Horman<horms@verge.net.au>
>>> Cc: Srinidhi Kasagar<srinidhi.kasagar@stericsson.com>
>>> Cc: Stephen Warren<swarren@wwwdotorg.org>
>>> Cc: Tony Lindgren<tony@atomide.com>
>>> Cc: Viresh Kumar<viresh.linux@gmail.com>
>>> ---
>>>
>>> Does OMAP5 need to select TWD? I suspect not if it uses the
>>> architected timers.
>>>
>> Nope. OMAP5 don't use TWD. Infact the external SCU is also used
>> for A9 SOCs. You might want to check other A15 SOCS for SCU as
>> well.
>
> In that case I am a bit confused by the following result:
>
> # git checkout v3.6
> # ARCH=arm make omap2plus_defconfig
> # grep '(SOC_OMAP5|_SCU|_TWD|CONFIG_SMP|CONFIG_LOCAL_TIMERS)=' .config
> CONFIG_SOC_OMAP5=y
> CONFIG_SMP=y
> CONFIG_HAVE_ARM_SCU=y
> CONFIG_HAVE_ARM_TWD=y
> CONFIG_LOCAL_TIMERS=y
Thats because omap2plus_defconfig build all the OMAP machines together
including OMAP4 and OMAP5.
Regards
Santosh
^ permalink raw reply
* [PATCH 09/16] ARM: OMAP: Split plat/mmc.h into local headers and platform_data
From: Venkatraman S @ 2012-10-05 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004220454.26676.10131.stgit@muffinssi.local>
On Fri, Oct 5, 2012 at 3:34 AM, Tony Lindgren <tony@atomide.com> wrote:
> We need to remove this from plat for ARM common zImage
> support.
>
> Cc: Chris Ball <cjb@laptop.org>
> Cc: Venkatraman S <svenkatr@ti.com>
> Cc: linux-mmc at vger.kernel.org
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Thanks Tony. I suppose this should go into your tree..
Acked-by: Venkatraman S <svenkatr@ti.com>
> ---
> arch/arm/mach-omap1/board-h2-mmc.c | 5 +--
> arch/arm/mach-omap1/board-h3-mmc.c | 3 +-
> arch/arm/mach-omap1/board-htcherald.c | 2 +
> arch/arm/mach-omap1/board-innovator.c | 2 +
> arch/arm/mach-omap1/board-nokia770.c | 2 +
> arch/arm/mach-omap1/board-sx1-mmc.c | 3 +-
> arch/arm/mach-omap1/devices.c | 2 +
> arch/arm/mach-omap1/mmc.h | 18 +++++++++++
> arch/arm/mach-omap2/board-4430sdp.c | 2 +
> arch/arm/mach-omap2/board-n8x0.c | 2 +
> arch/arm/mach-omap2/board-omap4panda.c | 2 +
> arch/arm/mach-omap2/board-rm680.c | 2 +
> arch/arm/mach-omap2/hsmmc.c | 2 +
> arch/arm/mach-omap2/mmc.h | 23 ++++++++++++++
> arch/arm/mach-omap2/msdi.c | 2 +
> arch/arm/mach-omap2/omap4-common.c | 2 +
> arch/arm/mach-omap2/omap_hwmod_2420_data.c | 2 +
> arch/arm/mach-omap2/omap_hwmod_2430_data.c | 2 +
> arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 2 +
> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +
> drivers/mmc/host/omap.c | 3 +-
> drivers/mmc/host/omap_hsmmc.c | 2 +
> include/linux/platform_data/mmc-omap.h | 45 +---------------------------
> 24 files changed, 67 insertions(+), 67 deletions(-)
> create mode 100644 arch/arm/mach-omap1/mmc.h
> create mode 100644 arch/arm/mach-omap2/mmc.h
^ permalink raw reply
* [PATCH 06/15] KVM: ARM: Initial skeleton to compile KVM support
From: Rusty Russell @ 2012-10-05 6:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000301cda230$91eb4fa0$b5c1eee0$@samsung.com>
Min-gyu Kim <mingyu84.kim@samsung.com> writes:
>> -----Original Message-----
>> From: kvm-owner at vger.kernel.org [mailto:kvm-owner at vger.kernel.org] On
>> Behalf Of Christoffer Dall
>> Sent: Monday, October 01, 2012 4:22 AM
>> To: Will Deacon
>> Cc: kvm at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>> kvmarm at lists.cs.columbia.edu; rusty.russell at linaro.org; avi at redhat.com;
>> marc.zyngier at arm.com
>> Subject: Re: [PATCH 06/15] KVM: ARM: Initial skeleton to compile KVM
>> support
>>
>> On Thu, Sep 27, 2012 at 10:13 AM, Will Deacon <will.deacon@arm.com> wrote:
>> > On Wed, Sep 26, 2012 at 02:43:14AM +0100, Christoffer Dall wrote:
>> >> >> +static inline enum vcpu_mode vcpu_mode(struct kvm_vcpu *vcpu) {
>> >> >> + u8 mode = __vcpu_mode(vcpu->arch.regs.cpsr);
>> >> >> + BUG_ON(mode == 0xf);
>> >> >> + return mode;
>> >> >> +}
>> >> >
>> >> > I noticed that you have a fair few BUG_ONs throughout the series.
>> >> > Fair enough, but for hyp code is that really the right thing to do?
>> >> > Killing the guest could make more sense, perhaps?
>> >>
>> >> the idea is to have BUG_ONs that are indeed BUG_ONs that we want to
>> >> catch explicitly on the host. We have had a pass over the code to
>> >> change all the BUG_ONs that can be provoked by the guest and inject
>> >> the proper exceptions into the guest in this case. If you find places
>> >> where this is not the case, it should be changed, and do let me know.
>> >
>> > Ok, so are you saying that a BUG_ON due to some detected inconsistency
>> > with one guest may not necessarily terminate the other guests? BUG_ONs
>> > in the host seem like a bad idea if the host is able to continue with
>> > a subset of guests.
>> >
>>
>> No, I'm saying a BUG_ON is an actual BUG, it should not happen and there
>> should be nowhere where a guest can cause a BUG_ON to occur in the host,
>> because that would be a bug.
>>
>> We basically never kill a guest unless really extreme things happen (like
>> we cannot allocate a pte, in which case we return -ENOMEM). If a guest
>> does something really weird, that guest will receive the appropriate
>> exception (undefined, prefetch abort, ...)
>>
>
> I agree with Will. It seems to be overreacting to kill the entire system.
No. If we manage to put the guest in an undefined state, we don't know
what has happened. Something has gone horribly wrong. Most likely,
vcpu isn't a vcpu pointer at all, or has been so horribly corrupted that
"killing the guest" is just a complicated way of messing ourselves up
further.
The system by this stage is so damaged that we're best off panicing, and
avoiding corrupting things further.
Cheers,
Rusty.
^ permalink raw reply
* [PATCH 1/3] mfd: dbx500: Export prmcu_request_ape_opp_100_voltage
From: Linus Walleij @ 2012-10-05 6:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348497799-32143-2-git-send-email-ulf.hansson@stericsson.com>
On Mon, Sep 24, 2012 at 4:43 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> This function needs to be exported to let clients be able to
> request the ape opp 100 voltage.
>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* alignment faults in 3.6
From: Khem Raj @ 2012-10-05 5:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506E4E23.4020803@gmail.com>
On Oct 4, 2012, at 8:04 PM, Rob Herring <robherring2@gmail.com> wrote:
> On 10/04/2012 09:25 PM, Mans Rullgard wrote:
>> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
>>> On 10/04/2012 08:26 PM, Mans Rullgard wrote:
>>>> On 5 October 2012 01:58, Michael Hope <michael.hope@linaro.org> wrote:
>>>>> On 5 October 2012 12:10, Rob Herring <robherring2@gmail.com> wrote:
>>>>>> I've been scratching my head with a "scheduling while atomic" bug I
>>>>>> started seeing on 3.6. I can easily reproduce this problem when doing a
>>>>>> wget on my system. It ultimately seems to be a combination of factors.
>>>>>> The "scheduling while atomic" bug is triggered in do_alignment which
>>>>>> gets triggered by this code in net/ipv4/af_inet.c, line 1356:
>>>>>>
>>>>>> id = ntohl(*(__be32 *)&iph->id);
>>>>>> flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (id ^ IP_DF));
>>>>>> id >>= 16;
>>>>>>
>>>>>> This code compiles into this using "gcc version 4.6.3 (Ubuntu/Linaro
>>>>>> 4.6.3-1ubuntu5)":
>>>>>>
>>>>>> c02ac020: e8920840 ldm r2, {r6, fp}
>>>>>> c02ac024: e6bfbf3b rev fp, fp
>>>>>> c02ac028: e6bf6f36 rev r6, r6
>>>>>> c02ac02c: e22bc901 eor ip, fp, #16384 ; 0x4000
>>>>>> c02ac030: e0266008 eor r6, r6, r8
>>>>>> c02ac034: e18c6006 orr r6, ip, r6
>>>>>>
>>>>>> which generates alignment faults on the ldm. These are silent until this
>>>>>> commit is applied:
>>>>>
>>>>> Hi Rob. I assume that iph is something like:
>>>>>
>>>>> struct foo {
>>>>> u32 x;
>>>>> char id[8];
>>>>> };
>>>>>
>>>>> struct foo *iph;
>>>>>
>>>>> GCC merged the two adjacent loads of x and id into one ldm. This is
>>>>> an ARM specific optimisation done in load_multiple_sequence() and
>>>>> enabled with -fpeephole2.
>>>>>
>>>>> I think the assembly is correct - GCC knows that iph is aligned and
>>>>> knows the offsets of both x and id. Happy to be corrected if I'm
>>>>> wrong, but I think the assembly is valid given the C code.
>>>>
>>>> The struct looks like this:
>>>>
>>>> struct iphdr {
>>>> #if defined(__LITTLE_ENDIAN_BITFIELD)
>>>> __u8 ihl:4,
>>>> version:4;
>>>> #elif defined (__BIG_ENDIAN_BITFIELD)
>>>> __u8 version:4,
>>>> ihl:4;
>>>> #else
>>>> #error "Please fix <asm/byteorder.h>"
>>>> #endif
>>>> __u8 tos;
>>>> __be16 tot_len;
>>>> __be16 id;
>>>> __be16 frag_off;
>>>> __u8 ttl;
>>>> __u8 protocol;
>>>> __sum16 check;
>>>> __be32 saddr;
>>>> __be32 daddr;
>>>> /*The options start here. */
>>>> };
>>>>
>>>> In a normal build (there's some magic for special checkers) __be32 is a plain
>>>> __u32 so the struct should be at least 4-byte aligned. If somehow it is not,
>>>> that is the real bug.
>>>
>>> This struct is the IP header, so a struct ptr is just set to the
>>> beginning of the received data. Since ethernet headers are 14 bytes,
>>> often the IP header is not aligned unless the NIC can place the frame at
>>> a 2 byte offset (which is something I need to investigate). So this
>>> function cannot make any assumptions about the alignment. Does the ABI
>>> define structs have some minimum alignment? Does the struct need to be
>>> declared as packed or something?
>>
>> The ABI defines the alignment of structs as the maximum alignment of its
>> members. Since this struct contains 32-bit members, the alignment for the
>> whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
>> might be unaligned (in addition to removing any holes within).
>
> Unfortunately, declaring the struct or __be32* cast as packed have no
> effect. I still get an ldm emitted.
what is value of r2 ? and can you pastebin the .i file somewhere ?
>
> Rob
>
> _______________________________________________
> 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 v2 0/7] uio_pruss cleanup and platform support
From: Hebbar, Gururaja @ 2012-10-05 4:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121003150058.GB11180@beef>
Matt,
On Wed, Oct 03, 2012 at 20:30:58, Porter, Matt wrote:
> On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote:
> > Changes since v1:
> > - Replaced uio_pruss private SRAM API use with genalloc
> > - Added DA850 platform device and clock support
> > - Added DA850 L3 RAM gen_pool support
> > - Split out DT binding
> >
> > This series enables uio_pruss on both DA850 and AM33xx. The driver
> > previously was not enabled by any platform and the private SRAM API
> > was accessing an invalid SRAM bank for use on DA850. For AM33xx,
> > DT, pinctrl, and runtime PM support are added since AM33xx only
> > boots via DT.
>
> I'm dropping AM33xx/OMAP support from v3 for this series
Just for my clarification, I believe you will be taking up AM33xx/OMAP
SRAM support later once you have completed supporting DaVinci. Right?
> since the
> focus has turned to fixing Davinci SRAM to provide genalloc support
> and the associated use of that in the driver.
>
> I'll have a separate series with AM33xx support since dealing cleanly
> with external resets on OMAP is a bigger issue.
>
> -Matt
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
Regards,
Gururaja
^ permalink raw reply
* [PATCH] ARM: bcm2835: fix typos in DT binding documentation
From: Olof Johansson @ 2012-10-05 4:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349227597-5187-1-git-send-email-swarren@wwwdotorg.org>
On Tue, Oct 2, 2012 at 6:26 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> The compatible value shouldn't include ".txt", which was probably cut
> and paste from the filename.
>
> Reported-by: Domenico Andreoli <cavokz@gmail.com>
> Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Applied to fixes.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: soc: late platform updates
From: Olof Johansson @ 2012-10-05 3:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
This branch contains late updates to OMAP and Marvell platforms (kirkwood,
dove, mvebu) that came in after we had done the big multiplatform merges,
so they were kept separate from the rest, and not separated into the
traditional topics of cleanup/driver/platform features. They have been
included in linux-next: kirkwood since -rc7, OMAP since right when the
merge window opened.
There will be trivial add/add merge conflicts in drivers/pinctrl/Makefile
and Kconfig.
For OMAP, the updates are:
- Runtime PM conversions for the GPMC and RNG IP blocks
- Preparation patches for the OMAP common clock framework conversion
- clkdev alias additions required by other drivers
- Performance Monitoring Unit (PMU) support for OMAP2, 3, and non-4430 OMAP4
- OMAP hwmod code and data improvements
- Preparation patches for the IOMMU runtime PM conversion
- Preparation patches for OMAP4 full-chip retention support
For Kirkwood/Dove/mvebu:
- New driver for "address decoder controller" for mvebu, which
is a piece of hardware that configures addressable devices and
peripherals. First user is the boot rom aperture on armada XP since
it is needed for SMP support.
- New device tree bindings for peripherals such as gpio-fan, iconnect
nand, mv_cesa and the above address decoder controller.
- Some defconfig updates, mostly to enable new DT boards and a few drivers.
- New drivers using the pincontrol subsystem for dove, kirkwood and mvebu
- New clean gpio driver for mvebu
----------------------------------------------------------------
The following changes since commit 8b2d65066100b8df10c6e7805e61751b966045d7:
Merge branch 'next/defconfig' into HEAD
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/soc-late
for you to fetch changes up to 54d69df5849ec2e660aa12ac75562618c10fb499:
Merge branch 'late/kirkwood' into late/soc
----------------------------------------------------------------
Afzal Mohammed (3):
ARM: OMAP2/3: hwmod data: add gpmc
ARM: OMAP2+: gpmc: Adapt to HWMOD
ARM: OMAP2+: gpmc: minimal driver support
Alan M Butler (1):
ARM: Kirkwood: Iomega ix2-200 DT support
Andrew Lunn (1):
Crypto: CESA: Add support for DT based instantiation.
AnilKumar Ch (1):
ARM: OMAP2+: AM33XX: clock data: Add clkdev alias for cpu0
Arnaud Patard (2):
ARM: Kirkwood: Describe iconnect keys in DT.
ARM: Kirkwood: Describe iconnect nand in DT.
Benoit Cousson (1):
ARM: OMAP4: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs entries
Igor Grinberg (1):
ARM: OMAP: hwmod code: remove unused hwmod function prototypes
Jamie Lentin (3):
hwmon: Add devicetree bindings to gpio-fan
ARM: kirkwood: Use devicetree to define DNS-32[05] fan
ARM: kirkwood: Trim excess #includes in board-dnskw.c
Jason Cooper (2):
ARM: Kirkwood: update defconfig
ARM: Kirkwood: add DT boards to defconfig
Jon Hunter (7):
ARM: OMAP2420: Cosmetic fix for timer clock aliases
ARM: OMAP4: Add timer clock aliases for device-tree
ARM: OMAP: Add a timer attribute for timers that can interrupt the DSP
ARM: OMAP3: hwmod data: Add debugss HWMOD data
ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD
ARM: OMAP2+: PMU: Add runtime PM support
ARM: OMAP4460/4470: PMU: Enable PMU for OMAP4460/70
Kishon Vijay Abraham I (1):
ARM: OMAP4: hwmod data: make *phy_48m* as the main_clk of ocp2scp
Michael Jones (1):
ARM: OMAP3: clock data: remove obsolete comment
Mike Turquette (1):
ARM: OMAP4: cm: add bitfield width values
Ming Lei (1):
ARM: OMAP4430: PMU: prepare to create PMU device via HWMOD
Olof Johansson (12):
Merge branch 'next/cleanup' into late/kirkwood
Merge branch 'next/multiplatform' into late/kirkwood
Merge branch 'kirkwood/boards' of git://git.infradead.org/users/jcooper/linux into late/kirkwood
Merge branch 'kirkwood/defconfig' of git://git.infradead.org/users/jcooper/linux into late/kirkwood
Merge branch 'kirkwood/dt' of git://git.infradead.org/users/jcooper/linux into late/kirkwood
Merge branch 'kirkwood/cleanup' of git://git.infradead.org/users/jcooper/linux into late/kirkwood
Merge branch 'kirkwood/addr_decode' of git://git.infradead.org/users/jcooper/linux into late/kirkwood
Merge branch 'kirkwood/drivers' of git://git.infradead.org/users/jcooper/linux into late/kirkwood
ARM: kirkwood: move new dtbs to common Makefile
ARM: kirkwood: dockstar: fix header include
Merge tag 'omap-devel-late-for-v3.7' of git://git.kernel.org/.../tmlind/linux-omap into late/soc
Merge branch 'late/kirkwood' into late/soc
Omar Ramirez Luna (5):
ARM: OMAP2+: omap_device: expose hwmod assert/deassert to omap devices
ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabled
ARM: OMAP: hwmod: revise deassert sequence
ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selected
ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
Paul Walmsley (19):
Merge tag 'cleanup-fixes-for-v3.7' into test_v3.6-rc6_cff3.7_odaf3.7
Merge tag 'omap-devel-am33xx-for-v3.7' into test_v3.6-rc6_cff3.7_odaf3.7
ARM: OMAP3: clock data: Add the USB TLL clocks device name
ARM: OMAP2+: clock data: add some aliases for use by CPUFreq only
SPI: OMAP: remove unnecessary includes of plat/clock.h
Merge tag 'omap-cleanup-b-for-3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7
Merge tag 'cleanup-fixes-for-v3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7
Merge tag 'omap-devel-am33xx-for-v3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7
Merge branch 'clock_devel_3.7' into hwmod_prcm_clock_a_3.7
ARM: OMAP4+: hwmod code: remove clkdm requirement in _omap4_wait_target_*()
ARM: OMAP2+: hwmod code: convert missing clockdomain warnings to debug messages
ARM: OMAP4: hwmod data: add missing HWMOD_NO_IDLEST flags to some PRCM IP blocks
ARM: OMAP3: hwmod data: add mmu data for iva and isp
ARM: OMAP2xxx: hwmod/CM: add RNG integration data
hwrng: OMAP: store per-device data in per-device variables, not file statics
hwrng: OMAP: convert to use runtime PM
ARM: OMAP: split OMAP1, OMAP2+ RNG device registration
hwrng: OMAP: remove SoC restrictions from driver registration
ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU clockdomain idle problems
Rajendra Nayak (3):
ARM: omap: clk: add clk_prepare and clk_unprepare
ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage
ARM: OMAP2+: clock: Remove all direct dereferencing of struct clk
Rob Herring (1):
ARM: mvebu: fix build breaks from multi-platform conversion
Russell King (1):
ARM: Dove: allow PCI to be disabled
Sebastian Hesselbarth (11):
ARM: kirkwood: DT board setup for Seagate FreeAgent Dockstar
ARM: kirkwood: DT descriptor for Seagate FreeAgent Dockstar
ARM: dove: unify clock setup
ARM: dove: add clock gating control
ARM: dove: add crypto engine
ARM: dove: add device tree based machine descriptor
ARM: dove: add device tree descriptors
ARM: dove: SolidRun CuBox DT
pinctrl: mvebu: pinctrl driver core
pinctrl: mvebu: dove pinctrl driver
pinctrl: mvebu: kirkwood pinctrl driver
Tero Kristo (4):
ARM: OMAP4: powerdomain: add support for reading prev logic and mem states
ARM: OMAP4: hwmod data: add support for lostcontext_mask
ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context status
ARM: OMAP3: hwmod data: add sad2d hwmod
Thomas Petazzoni (30):
arm: add documentation describing Marvell families of SoC
arm: mach-dove: use plus instead of or for address definitions
arm: mach-kirkwood: use plus instead of or for address definitions
arm: mach-mv78xx0: use plus instead of or for address definitions
arm: mach-orion5x: use plus instead of or for address definitions
arm: mach-dove: use IOMEM() for base address definitions
arm: mach-kirkwood: use IOMEM() for base address definitions
arm: mach-mv78xx0: use IOMEM() for base address definitions
arm: mach-orion5x: use IOMEM() for base address definitions
arm: mach-mvebu: use IOMEM() for base address definitions
arm: plat-orion: use void __iomem pointers for UART registration functions
arm: plat-orion: use void __iomem pointers for MPP functions
arm: plat-orion: use void __iomem pointers for time functions
arm: plat-orion: use void __iomem pointers for addr-map functions
arm: plat-orion: introduce PLAT_ORION_LEGACY hidden config option
arm: plat-orion: make bridge_virt_base non-const to support DT use case
arm: mvebu: add basic address decoding support to Armada 370/XP
arm: mvebu: add address decoding controller to the DT
pinctrl: mvebu: add pinctrl driver for Armada 370
pinctrl: mvebu: add pinctrl driver for Armada XP
ARM: mvebu: Add pinctrl support to Armada XP SoCs
ARM: mvebu: Add pinctrl support to Armada 370 SoC
ARM: mvebu: adjust Armada XP evaluation board DTS
arm: mvebu: split Kconfig options for Armada 370 and XP
arm: mvebu: select the pinctrl drivers for Armada 370 and Armada XP platforms
gpio: introduce gpio-mvebu driver for Marvell SoCs
Documentation: add description of DT binding for the gpio-mvebu driver
arm: mvebu: use GPIO support now that a driver is available
arm: mvebu: add DT information for GPIO banks on Armada 370 and XP
arm: mvebu: add gpio support in defconfig
Tony Lindgren (1):
Merge tag 'omap-devel-b-c-2-for-3.7' of git://git.kernel.org/.../pjw/omap-pending into devel-late
Vaibhav Hiremath (1):
ARM: AM33XX: cm: Add bit-field width values
Valentin Longchamp (1):
ARM: initial DTS support for km_kirkwood
.../devicetree/bindings/crypto/mv_cesa.txt | 20 +
.../devicetree/bindings/gpio/gpio-fan.txt | 25 +
.../devicetree/bindings/gpio/gpio-mvebu.txt | 53 ++
.../pinctrl/marvell,armada-370-pinctrl.txt | 95 +++
.../pinctrl/marvell,armada-xp-pinctrl.txt | 100 +++
.../bindings/pinctrl/marvell,dove-pinctrl.txt | 72 ++
.../pinctrl/marvell,kirkwood-pinctrl.txt | 279 +++++++
.../bindings/pinctrl/marvell,mvebu-pinctrl.txt | 46 ++
arch/arm/Kconfig | 15 +-
arch/arm/boot/dts/Makefile | 6 +
arch/arm/boot/dts/armada-370-xp.dtsi | 5 +
arch/arm/boot/dts/armada-370.dtsi | 44 ++
arch/arm/boot/dts/armada-xp-db.dts | 4 +-
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 57 ++
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 70 ++
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 70 ++
arch/arm/boot/dts/dove-cm-a510.dts | 38 +
arch/arm/boot/dts/dove-cubox.dts | 42 ++
arch/arm/boot/dts/dove-dove-db.dts | 38 +
arch/arm/boot/dts/dove.dtsi | 143 ++++
arch/arm/boot/dts/kirkwood-dnskw.dtsi | 10 +
arch/arm/boot/dts/kirkwood-dockstar.dts | 57 ++
arch/arm/boot/dts/kirkwood-iconnect.dts | 50 +-
arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 105 +++
arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 29 +
arch/arm/boot/dts/kirkwood.dtsi | 12 +-
arch/arm/configs/kirkwood_defconfig | 38 +-
arch/arm/configs/mvebu_defconfig | 2 +
arch/arm/mach-dove/Kconfig | 7 +
arch/arm/mach-dove/Makefile | 4 +-
arch/arm/mach-dove/common.c | 157 +++-
arch/arm/mach-dove/common.h | 4 +
arch/arm/mach-dove/include/mach/bridge-regs.h | 16 +-
arch/arm/mach-dove/include/mach/dove.h | 126 ++--
arch/arm/mach-dove/include/mach/pm.h | 54 +-
arch/arm/mach-dove/irq.c | 10 +-
arch/arm/mach-dove/pcie.c | 6 +-
arch/arm/mach-kirkwood/Kconfig | 21 +
arch/arm/mach-kirkwood/Makefile | 3 +
arch/arm/mach-kirkwood/addr-map.c | 3 +-
arch/arm/mach-kirkwood/board-dnskw.c | 35 -
arch/arm/mach-kirkwood/board-dockstar.c | 61 ++
arch/arm/mach-kirkwood/board-dt.c | 14 +-
arch/arm/mach-kirkwood/board-iconnect.c | 48 --
arch/arm/mach-kirkwood/board-iomega_ix2_200.c | 57 ++
arch/arm/mach-kirkwood/board-km_kirkwood.c | 57 ++
arch/arm/mach-kirkwood/common.c | 8 +-
arch/arm/mach-kirkwood/common.h | 18 +
.../mach-kirkwood/include/mach/bridge-regs.h | 20 +-
arch/arm/mach-kirkwood/include/mach/kirkwood.h | 112 +--
arch/arm/mach-kirkwood/irq.c | 9 +-
arch/arm/mach-kirkwood/pcie.c | 12 +-
arch/arm/mach-kirkwood/ts41x-setup.c | 3 +-
arch/arm/mach-mv78xx0/addr-map.c | 6 +-
arch/arm/mach-mv78xx0/common.c | 4 +-
.../arm/mach-mv78xx0/include/mach/bridge-regs.h | 12 +-
arch/arm/mach-mv78xx0/include/mach/mv78xx0.h | 86 +--
arch/arm/mach-mv78xx0/irq.c | 9 +-
arch/arm/mach-mv78xx0/pcie.c | 12 +-
arch/arm/mach-mvebu/Kconfig | 20 +-
arch/arm/mach-mvebu/Makefile | 5 +-
arch/arm/mach-mvebu/addr-map.c | 134 ++++
arch/arm/mach-mvebu/armada-370-xp.c | 2 +-
arch/arm/mach-mvebu/armada-370-xp.h | 2 +-
arch/arm/mach-mvebu/include/mach/gpio.h | 1 +
arch/arm/mach-omap1/devices.c | 28 +
arch/arm/mach-omap1/timer.c | 2 +-
arch/arm/mach-omap2/Makefile | 1 +
arch/arm/mach-omap2/board-apollon.c | 4 +-
arch/arm/mach-omap2/board-h4.c | 6 +-
arch/arm/mach-omap2/board-omap4panda.c | 2 +-
arch/arm/mach-omap2/clkt2xxx_apll.c | 2 +-
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 10 +-
arch/arm/mach-omap2/clkt34xx_dpll3m2.c | 20 +-
arch/arm/mach-omap2/clkt_clksel.c | 86 ++-
arch/arm/mach-omap2/clkt_dpll.c | 26 +-
arch/arm/mach-omap2/clock.c | 9 +-
arch/arm/mach-omap2/clock2420_data.c | 24 +-
arch/arm/mach-omap2/clock2430_data.c | 23 +
arch/arm/mach-omap2/clock33xx_data.c | 1 +
arch/arm/mach-omap2/clock3xxx.c | 8 +-
arch/arm/mach-omap2/clock3xxx_data.c | 37 +-
arch/arm/mach-omap2/clock44xx_data.c | 21 +
arch/arm/mach-omap2/clockdomain.c | 17 +
arch/arm/mach-omap2/clockdomain.h | 20 +-
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 49 +-
arch/arm/mach-omap2/clockdomain44xx.c | 11 +
arch/arm/mach-omap2/clockdomains3xxx_data.c | 7 +-
arch/arm/mach-omap2/clockdomains44xx_data.c | 3 +-
arch/arm/mach-omap2/cm-regbits-33xx.h | 158 +++-
arch/arm/mach-omap2/cm-regbits-34xx.h | 2 +
arch/arm/mach-omap2/cm-regbits-44xx.h | 411 ++++++++--
arch/arm/mach-omap2/cm2xxx_3xxx.c | 2 +-
arch/arm/mach-omap2/cm2xxx_3xxx.h | 1 +
arch/arm/mach-omap2/control.h | 1 +
arch/arm/mach-omap2/devices.c | 39 +-
arch/arm/mach-omap2/display.c | 4 +-
arch/arm/mach-omap2/dpll3xxx.c | 48 +-
arch/arm/mach-omap2/gpmc.c | 194 +++--
arch/arm/mach-omap2/omap_hwmod.c | 138 +++-
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 19 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 19 +
.../omap_hwmod_2xxx_interconnect_data.c | 17 +
.../mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 110 ++-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 280 ++++++-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 243 +++++-
arch/arm/mach-omap2/omap_hwmod_common_data.h | 6 +-
arch/arm/mach-omap2/pm.c | 5 +-
arch/arm/mach-omap2/pmu.c | 95 +++
arch/arm/mach-omap2/powerdomain44xx.c | 61 +-
arch/arm/mach-omap2/prcm-common.h | 2 +
arch/arm/mach-orion5x/addr-map.c | 3 +-
arch/arm/mach-orion5x/common.c | 4 +-
arch/arm/mach-orion5x/dns323-setup.c | 2 +-
.../arm/mach-orion5x/include/mach/bridge-regs.h | 20 +-
arch/arm/mach-orion5x/include/mach/orion5x.h | 56 +-
arch/arm/mach-orion5x/irq.c | 5 +-
arch/arm/mach-orion5x/pci.c | 6 +-
arch/arm/plat-omap/clock.c | 27 -
arch/arm/plat-omap/include/plat/clock.h | 5 +
arch/arm/plat-omap/include/plat/dmtimer.h | 1 +
arch/arm/plat-omap/include/plat/iommu.h | 15 +
arch/arm/plat-omap/include/plat/omap_device.h | 4 +
arch/arm/plat-omap/include/plat/omap_hwmod.h | 26 +-
arch/arm/plat-omap/omap_device.c | 59 +-
arch/arm/plat-orion/Makefile | 10 +-
arch/arm/plat-orion/addr-map.c | 11 +-
arch/arm/plat-orion/common.c | 12 +-
arch/arm/plat-orion/include/plat/addr-map.h | 4 +-
arch/arm/plat-orion/include/plat/common.h | 8 +-
arch/arm/plat-orion/include/plat/mpp.h | 2 +-
arch/arm/plat-orion/include/plat/time.h | 4 +-
arch/arm/plat-orion/mpp.c | 6 +-
arch/arm/plat-orion/time.c | 8 +-
drivers/char/hw_random/omap-rng.c | 121 +--
drivers/crypto/mv_cesa.c | 17 +-
drivers/gpio/Kconfig | 6 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-mvebu.c | 679 +++++++++++++++++
drivers/hwmon/gpio-fan.c | 120 +++
drivers/pinctrl/Kconfig | 22 +
drivers/pinctrl/Makefile | 5 +
drivers/pinctrl/pinctrl-armada-370.c | 421 +++++++++++
drivers/pinctrl/pinctrl-armada-xp.c | 468 ++++++++++++
drivers/pinctrl/pinctrl-dove.c | 620 +++++++++++++++
drivers/pinctrl/pinctrl-kirkwood.c | 472 ++++++++++++
drivers/pinctrl/pinctrl-mvebu.c | 754 +++++++++++++++++++
drivers/pinctrl/pinctrl-mvebu.h | 192 +++++
drivers/spi/spi-omap-100k.c | 2 -
drivers/spi/spi-omap2-mcspi.c | 1 -
150 files changed, 8269 insertions(+), 885 deletions(-)
create mode 100644 Documentation/devicetree/bindings/crypto/mv_cesa.txt
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-fan.txt
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
create mode 100644 arch/arm/boot/dts/armada-xp-mv78230.dtsi
create mode 100644 arch/arm/boot/dts/armada-xp-mv78260.dtsi
create mode 100644 arch/arm/boot/dts/armada-xp-mv78460.dtsi
create mode 100644 arch/arm/boot/dts/dove-cm-a510.dts
create mode 100644 arch/arm/boot/dts/dove-cubox.dts
create mode 100644 arch/arm/boot/dts/dove-dove-db.dts
create mode 100644 arch/arm/boot/dts/dove.dtsi
create mode 100644 arch/arm/boot/dts/kirkwood-dockstar.dts
create mode 100644 arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts
create mode 100644 arch/arm/boot/dts/kirkwood-km_kirkwood.dts
create mode 100644 arch/arm/mach-kirkwood/board-dockstar.c
create mode 100644 arch/arm/mach-kirkwood/board-iomega_ix2_200.c
create mode 100644 arch/arm/mach-kirkwood/board-km_kirkwood.c
create mode 100644 arch/arm/mach-mvebu/addr-map.c
create mode 100644 arch/arm/mach-mvebu/include/mach/gpio.h
create mode 100644 arch/arm/mach-omap2/pmu.c
create mode 100644 drivers/gpio/gpio-mvebu.c
create mode 100644 drivers/pinctrl/pinctrl-armada-370.c
create mode 100644 drivers/pinctrl/pinctrl-armada-xp.c
create mode 100644 drivers/pinctrl/pinctrl-dove.c
create mode 100644 drivers/pinctrl/pinctrl-kirkwood.c
create mode 100644 drivers/pinctrl/pinctrl-mvebu.c
create mode 100644 drivers/pinctrl/pinctrl-mvebu.h
^ permalink raw reply
* [GIT PULL] ARM: soc: defconfig updates
From: Olof Johansson @ 2012-10-05 3:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d:
Linux 3.6-rc4 (2012-09-01 10:39:58 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/defconfig
for you to fetch changes up to 3536c27c0fbe41f731ab6f61217ef95d0bdf2e05:
Merge branch 'next/defconfig-samsung' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into next/defconfig (2012-09-20 16:49:54 -0700)
----------------------------------------------------------------
ARM: soc: defconfig updates
This might be the last time we do a standalone defconfig branch,
since we now prefer to get them with the rest of the subarch updates
instead. These add a handful of useful options on various platforms,
enable new boards and SoCs, etc.
----------------------------------------------------------------
Fabio Estevam (6):
ARM: mxs_defconfig: Enable USB host
ARM: mxs_defconfig: Add LED, PWM and MTD_CHAR support
ARM: mxs_defconfig: Add framebuffer support
ARM: imx_v6_v7_defconfig: Add Chipidea USB driver support
ARM: imx_v6_v7_defconfig: Remove CONFIG_DEFAULT_MMAP_MIN_ADDR
ARM: mxs_defconfig: Add SPI and LRADC support
Kukjin Kim (1):
ARM: s3c6400_defconfig: enable more boards in defconfig
Olof Johansson (6):
Merge branch 'defconfig' of git://git.kernel.org/.../horms/renesas into next/defconfig
Merge branch 'lpc32xx/defconfig' of git://git.antcom.de/linux-2.6 into next/defconfig
Merge tag 'mxs-defconfig-3.7' of git://git.linaro.org/people/shawnguo/linux-2.6 into next/defconfig
Merge tag 'imx-defconfig' of git://git.pengutronix.de/git/imx/linux-2.6 into next/defconfig
Merge tag 'tegra-for-3.7-defconfig' of git://git.kernel.org/.../swarren/linux-tegra into next/defconfig
Merge branch 'next/defconfig-samsung' of git://git.kernel.org/.../kgene/linux-samsung into next/defconfig
Roland Stigge (1):
ARM: LPC32xx: Defconfig update
Simon Horman (1):
ARM: mach-shmobile: marzen: defconfig update
Stephen Warren (1):
ARM: tegra: defconfig updates
arch/arm/configs/imx_v6_v7_defconfig | 4 +++-
arch/arm/configs/lpc32xx_defconfig | 7 +++++--
arch/arm/configs/marzen_defconfig | 15 ++++++++++-----
arch/arm/configs/mxs_defconfig | 36 +++++++++++++++++++++++++++++++++++-
arch/arm/configs/s3c6400_defconfig | 3 +++
arch/arm/configs/tegra_defconfig | 51 ++++++++++++++++++++++++++++++++++++++++++---------
6 files changed, 98 insertions(+), 18 deletions(-)
^ permalink raw reply
* linux-next: manual merge of the arm-soc tree with the arm64 tree
From: Stephen Rothwell @ 2012-10-05 3:32 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm64/include/asm/unistd32.h between commit cce72b4219ee ("arm64:
Use the generic compat_sys_sendfile() implementation") from the arm64
tree and commit 890139529d45 ("UAPI: Fix the guards on various
asm/unistd.h files") from the arm-soc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
diff --cc arch/arm64/include/asm/unistd32.h
index ec61180,3ba1f1a..0000000
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@@ -754,6 -752,3 +752,4 @@@ __SYSCALL(__NR_syncfs, sys_syncfs
#define __ARCH_WANT_SYS_SIGPENDING
#define __ARCH_WANT_SYS_SIGPROCMASK
#define __ARCH_WANT_COMPAT_SYS_RT_SIGSUSPEND
+#define __ARCH_WANT_COMPAT_SYS_SENDFILE
-
- #endif /* __ASM_UNISTD32_H */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121005/7d8ec9f4/attachment-0001.sig>
^ permalink raw reply
* alignment faults in 3.6
From: Rob Herring @ 2012-10-05 3:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAG5Tg6V0Vj9HTy3=AU-q+Qa3DuJs6R1Kw+3uOWU_jOGfkgyXzw@mail.gmail.com>
On 10/04/2012 09:25 PM, Mans Rullgard wrote:
> On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
>> On 10/04/2012 08:26 PM, Mans Rullgard wrote:
>>> On 5 October 2012 01:58, Michael Hope <michael.hope@linaro.org> wrote:
>>>> On 5 October 2012 12:10, Rob Herring <robherring2@gmail.com> wrote:
>>>>> I've been scratching my head with a "scheduling while atomic" bug I
>>>>> started seeing on 3.6. I can easily reproduce this problem when doing a
>>>>> wget on my system. It ultimately seems to be a combination of factors.
>>>>> The "scheduling while atomic" bug is triggered in do_alignment which
>>>>> gets triggered by this code in net/ipv4/af_inet.c, line 1356:
>>>>>
>>>>> id = ntohl(*(__be32 *)&iph->id);
>>>>> flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (id ^ IP_DF));
>>>>> id >>= 16;
>>>>>
>>>>> This code compiles into this using "gcc version 4.6.3 (Ubuntu/Linaro
>>>>> 4.6.3-1ubuntu5)":
>>>>>
>>>>> c02ac020: e8920840 ldm r2, {r6, fp}
>>>>> c02ac024: e6bfbf3b rev fp, fp
>>>>> c02ac028: e6bf6f36 rev r6, r6
>>>>> c02ac02c: e22bc901 eor ip, fp, #16384 ; 0x4000
>>>>> c02ac030: e0266008 eor r6, r6, r8
>>>>> c02ac034: e18c6006 orr r6, ip, r6
>>>>>
>>>>> which generates alignment faults on the ldm. These are silent until this
>>>>> commit is applied:
>>>>
>>>> Hi Rob. I assume that iph is something like:
>>>>
>>>> struct foo {
>>>> u32 x;
>>>> char id[8];
>>>> };
>>>>
>>>> struct foo *iph;
>>>>
>>>> GCC merged the two adjacent loads of x and id into one ldm. This is
>>>> an ARM specific optimisation done in load_multiple_sequence() and
>>>> enabled with -fpeephole2.
>>>>
>>>> I think the assembly is correct - GCC knows that iph is aligned and
>>>> knows the offsets of both x and id. Happy to be corrected if I'm
>>>> wrong, but I think the assembly is valid given the C code.
>>>
>>> The struct looks like this:
>>>
>>> struct iphdr {
>>> #if defined(__LITTLE_ENDIAN_BITFIELD)
>>> __u8 ihl:4,
>>> version:4;
>>> #elif defined (__BIG_ENDIAN_BITFIELD)
>>> __u8 version:4,
>>> ihl:4;
>>> #else
>>> #error "Please fix <asm/byteorder.h>"
>>> #endif
>>> __u8 tos;
>>> __be16 tot_len;
>>> __be16 id;
>>> __be16 frag_off;
>>> __u8 ttl;
>>> __u8 protocol;
>>> __sum16 check;
>>> __be32 saddr;
>>> __be32 daddr;
>>> /*The options start here. */
>>> };
>>>
>>> In a normal build (there's some magic for special checkers) __be32 is a plain
>>> __u32 so the struct should be at least 4-byte aligned. If somehow it is not,
>>> that is the real bug.
>>
>> This struct is the IP header, so a struct ptr is just set to the
>> beginning of the received data. Since ethernet headers are 14 bytes,
>> often the IP header is not aligned unless the NIC can place the frame at
>> a 2 byte offset (which is something I need to investigate). So this
>> function cannot make any assumptions about the alignment. Does the ABI
>> define structs have some minimum alignment? Does the struct need to be
>> declared as packed or something?
>
> The ABI defines the alignment of structs as the maximum alignment of its
> members. Since this struct contains 32-bit members, the alignment for the
> whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
> might be unaligned (in addition to removing any holes within).
Unfortunately, declaring the struct or __be32* cast as packed have no
effect. I still get an ldm emitted.
Rob
^ permalink raw reply
* alignment faults in 3.6
From: Mans Rullgard @ 2012-10-05 2:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506E3E58.80703@gmail.com>
On 5 October 2012 02:56, Rob Herring <robherring2@gmail.com> wrote:
> On 10/04/2012 08:26 PM, Mans Rullgard wrote:
>> On 5 October 2012 01:58, Michael Hope <michael.hope@linaro.org> wrote:
>>> On 5 October 2012 12:10, Rob Herring <robherring2@gmail.com> wrote:
>>>> I've been scratching my head with a "scheduling while atomic" bug I
>>>> started seeing on 3.6. I can easily reproduce this problem when doing a
>>>> wget on my system. It ultimately seems to be a combination of factors.
>>>> The "scheduling while atomic" bug is triggered in do_alignment which
>>>> gets triggered by this code in net/ipv4/af_inet.c, line 1356:
>>>>
>>>> id = ntohl(*(__be32 *)&iph->id);
>>>> flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (id ^ IP_DF));
>>>> id >>= 16;
>>>>
>>>> This code compiles into this using "gcc version 4.6.3 (Ubuntu/Linaro
>>>> 4.6.3-1ubuntu5)":
>>>>
>>>> c02ac020: e8920840 ldm r2, {r6, fp}
>>>> c02ac024: e6bfbf3b rev fp, fp
>>>> c02ac028: e6bf6f36 rev r6, r6
>>>> c02ac02c: e22bc901 eor ip, fp, #16384 ; 0x4000
>>>> c02ac030: e0266008 eor r6, r6, r8
>>>> c02ac034: e18c6006 orr r6, ip, r6
>>>>
>>>> which generates alignment faults on the ldm. These are silent until this
>>>> commit is applied:
>>>
>>> Hi Rob. I assume that iph is something like:
>>>
>>> struct foo {
>>> u32 x;
>>> char id[8];
>>> };
>>>
>>> struct foo *iph;
>>>
>>> GCC merged the two adjacent loads of x and id into one ldm. This is
>>> an ARM specific optimisation done in load_multiple_sequence() and
>>> enabled with -fpeephole2.
>>>
>>> I think the assembly is correct - GCC knows that iph is aligned and
>>> knows the offsets of both x and id. Happy to be corrected if I'm
>>> wrong, but I think the assembly is valid given the C code.
>>
>> The struct looks like this:
>>
>> struct iphdr {
>> #if defined(__LITTLE_ENDIAN_BITFIELD)
>> __u8 ihl:4,
>> version:4;
>> #elif defined (__BIG_ENDIAN_BITFIELD)
>> __u8 version:4,
>> ihl:4;
>> #else
>> #error "Please fix <asm/byteorder.h>"
>> #endif
>> __u8 tos;
>> __be16 tot_len;
>> __be16 id;
>> __be16 frag_off;
>> __u8 ttl;
>> __u8 protocol;
>> __sum16 check;
>> __be32 saddr;
>> __be32 daddr;
>> /*The options start here. */
>> };
>>
>> In a normal build (there's some magic for special checkers) __be32 is a plain
>> __u32 so the struct should be at least 4-byte aligned. If somehow it is not,
>> that is the real bug.
>
> This struct is the IP header, so a struct ptr is just set to the
> beginning of the received data. Since ethernet headers are 14 bytes,
> often the IP header is not aligned unless the NIC can place the frame at
> a 2 byte offset (which is something I need to investigate). So this
> function cannot make any assumptions about the alignment. Does the ABI
> define structs have some minimum alignment? Does the struct need to be
> declared as packed or something?
The ABI defines the alignment of structs as the maximum alignment of its
members. Since this struct contains 32-bit members, the alignment for the
whole struct becomes 32 bits as well. Declaring it as packed tells gcc it
might be unaligned (in addition to removing any holes within).
--
Mans Rullgard / mru
^ permalink raw reply
* [PATCH v2 06/14] KVM: ARM: Memory virtualization setup
From: Min-gyu Kim @ 2012-10-05 2:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001091042.49198.93241.stgit@ubuntu>
> -----Original Message-----
> From: kvm-owner at vger.kernel.org [mailto:kvm-owner at vger.kernel.org] On
> Behalf Of Christoffer Dall
> Sent: Monday, October 01, 2012 6:11 PM
> To: kvm at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
> kvmarm at lists.cs.columbia.edu
> Cc: Marc Zyngier
> Subject: [PATCH v2 06/14] KVM: ARM: Memory virtualization setup
>
> +static void stage2_set_pte(struct kvm *kvm, struct kvm_mmu_memory_cache
> *cache,
> + phys_addr_t addr, const pte_t *new_pte) {
> + pgd_t *pgd;
> + pud_t *pud;
> + pmd_t *pmd;
> + pte_t *pte, old_pte;
> +
> + /* Create 2nd stage page table mapping - Level 1 */
> + pgd = kvm->arch.pgd + pgd_index(addr);
> + pud = pud_offset(pgd, addr);
> + if (pud_none(*pud)) {
> + if (!cache)
> + return; /* ignore calls from kvm_set_spte_hva */
> + pmd = mmu_memory_cache_alloc(cache);
> + pud_populate(NULL, pud, pmd);
> + pmd += pmd_index(addr);
> + get_page(virt_to_page(pud));
> + } else
> + pmd = pmd_offset(pud, addr);
> +
> + /* Create 2nd stage page table mapping - Level 2 */
> + if (pmd_none(*pmd)) {
> + if (!cache)
> + return; /* ignore calls from kvm_set_spte_hva */
> + pte = mmu_memory_cache_alloc(cache);
> + clean_pte_table(pte);
> + pmd_populate_kernel(NULL, pmd, pte);
> + pte += pte_index(addr);
> + get_page(virt_to_page(pmd));
> + } else
> + pte = pte_offset_kernel(pmd, addr);
> +
> + /* Create 2nd stage page table mapping - Level 3 */
> + old_pte = *pte;
> + set_pte_ext(pte, *new_pte, 0);
> + if (pte_present(old_pte))
> + __kvm_tlb_flush_vmid(kvm);
> + else
> + get_page(virt_to_page(pte));
> +}
I'm not sure about the 3-level page table, but isn't it necessary to
clean the page table for 2nd level?
There are two mmu_memory_cache_alloc calls. One has following clean_pte_table
and the other doesn't have.
And why do you ignore calls from kvm_set_spte_hva? It is supposed to happen when
host moves the page, right? Then you ignore the case because it can be handled
later when fault actually happens? Is there any other reason that I miss?
^ permalink raw reply
* alignment faults in 3.6
From: Rob Herring @ 2012-10-05 1:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAG5Tg6Wuybruc31x1eh6mFafsg=7cOgYLgpZUBuJUo75ap3osQ@mail.gmail.com>
On 10/04/2012 08:26 PM, Mans Rullgard wrote:
> On 5 October 2012 01:58, Michael Hope <michael.hope@linaro.org> wrote:
>> On 5 October 2012 12:10, Rob Herring <robherring2@gmail.com> wrote:
>>> I've been scratching my head with a "scheduling while atomic" bug I
>>> started seeing on 3.6. I can easily reproduce this problem when doing a
>>> wget on my system. It ultimately seems to be a combination of factors.
>>> The "scheduling while atomic" bug is triggered in do_alignment which
>>> gets triggered by this code in net/ipv4/af_inet.c, line 1356:
>>>
>>> id = ntohl(*(__be32 *)&iph->id);
>>> flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (id ^ IP_DF));
>>> id >>= 16;
>>>
>>> This code compiles into this using "gcc version 4.6.3 (Ubuntu/Linaro
>>> 4.6.3-1ubuntu5)":
>>>
>>> c02ac020: e8920840 ldm r2, {r6, fp}
>>> c02ac024: e6bfbf3b rev fp, fp
>>> c02ac028: e6bf6f36 rev r6, r6
>>> c02ac02c: e22bc901 eor ip, fp, #16384 ; 0x4000
>>> c02ac030: e0266008 eor r6, r6, r8
>>> c02ac034: e18c6006 orr r6, ip, r6
>>>
>>> which generates alignment faults on the ldm. These are silent until this
>>> commit is applied:
>>
>> Hi Rob. I assume that iph is something like:
>>
>> struct foo {
>> u32 x;
>> char id[8];
>> };
>>
>> struct foo *iph;
>>
>> GCC merged the two adjacent loads of x and id into one ldm. This is
>> an ARM specific optimisation done in load_multiple_sequence() and
>> enabled with -fpeephole2.
>>
>> I think the assembly is correct - GCC knows that iph is aligned and
>> knows the offsets of both x and id. Happy to be corrected if I'm
>> wrong, but I think the assembly is valid given the C code.
>
> The struct looks like this:
>
> struct iphdr {
> #if defined(__LITTLE_ENDIAN_BITFIELD)
> __u8 ihl:4,
> version:4;
> #elif defined (__BIG_ENDIAN_BITFIELD)
> __u8 version:4,
> ihl:4;
> #else
> #error "Please fix <asm/byteorder.h>"
> #endif
> __u8 tos;
> __be16 tot_len;
> __be16 id;
> __be16 frag_off;
> __u8 ttl;
> __u8 protocol;
> __sum16 check;
> __be32 saddr;
> __be32 daddr;
> /*The options start here. */
> };
>
> In a normal build (there's some magic for special checkers) __be32 is a plain
> __u32 so the struct should be at least 4-byte aligned. If somehow it is not,
> that is the real bug.
This struct is the IP header, so a struct ptr is just set to the
beginning of the received data. Since ethernet headers are 14 bytes,
often the IP header is not aligned unless the NIC can place the frame at
a 2 byte offset (which is something I need to investigate). So this
function cannot make any assumptions about the alignment. Does the ABI
define structs have some minimum alignment? Does the struct need to be
declared as packed or something?
Rob
^ 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