* [PATCH] ARM: kirkwood: DT board setup for Network Space v2 and parents
From: Stephen Warren @ 2012-10-04 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004075335.GY31897@kw.sim.vm.gnt>
On 10/04/2012 01:53 AM, Simon Guinot wrote:
> On Thu, Oct 04, 2012 at 07:54:43AM +0200, Andrew Lunn wrote:
>>>>> --- a/arch/arm/mach-kirkwood/board-dt.c +++
>>>>> b/arch/arm/mach-kirkwood/board-dt.c @@ -96,6 +96,11 @@
>>>>> static void __init kirkwood_dt_init(void) if
>>>>> (of_machine_is_compatible("keymile,km_kirkwood"))
>>>>> km_kirkwood_init();
>>>>>
>>>>> + if (of_machine_is_compatible("lacie,inetspace_v2") || +
>>>>> of_machine_is_compatible("lacie,netspace_v2") || +
>>>>> of_machine_is_compatible("lacie,netspace_max_v2")) +
>>>>> ns2_init(); + of_platform_populate(NULL,
>>>>> kirkwood_dt_match_table, kirkwood_auxdata_lookup, NULL);
>>>>
>>>> I'm not a DT policy expert. Could this be one compatibility
>>>> string for all the boards? Maybe ask on the DT mainline
>>>> list?
>>>
>>> Maybe I could use "lacie,ns2_common" as a compatibility string.
>>> But this does not match any existing device. I don't know if it
>>> is correct.
>>
>> Hi Simon
>>
>> I did a bit of looking around. For kirkwood, we already have two
>> boards sharing the same compatibility string. kirkwood-dns320.dts
>> and kirkwood-dns325.dts both have dlink,dns-kirkwood and this is
>> what the board-dt.c matches on.
>>
>> For the tegra20 soc, all boards match on nvidia,tegra20, and that
>> is the only compatibility string in board-dt-tegra20.c.
nvidia,tegra20 is the compatible value for the SoC itself, so
naturally any Tegra20-based board has that.
>> So i don't see any problem having just one compatibility string
>> here.
>>
>> The question is, what is the appropriate name. How common is
>> this common C code? Are there ns2 where this C code is not
>> appropriate. One thing to remember is that most of this C code
>> will soon disappear and become DT. All the mpp will be replaced
>> with pinctrl in 3.8. I hope we can get the Ethernet setup in DT
>> as well. You are working on ns2_led, so all the C code will be
>> replaced by DT. So all we are really left with is power off GPIO
>> handling.
>>
>> So i think the danger of using lacie,ns2_common, and then finding
>> it does not work with some other ns2 device is quite low.
lacie,ns2_common doesn't sound like a HW description, but rather a SW
invention. DT should be describing purely the HW. If there's no common
HW between these compatible boards (which seems unlikely), then there
shouldn't be a shared compatible value.
>> What do you think?
>
> The status for this ns2 boards is more or less end-of-life. I mean,
> this boards are no longer in production. So I think it is safe to
> consider the code inside board-ns2.c as common and shareable
> between ns2, is2 and ns2max.
>
> Once this file will be removed, the compatibility checks will be
> removed as well. But one could easily forget to remove the useless
> compatibility string "lacie,ns2_common" from the dts...
If that value is added to the DT, it should not be removed, and the
kernel should continue to support it indefinitely.
^ permalink raw reply
* [PATCH v4 2/6] misc: Generic on-chip SRAM allocation driver
From: Matt Porter @ 2012-10-04 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347021828-23034-3-git-send-email-p.zabel@pengutronix.de>
On Fri, Sep 07, 2012 at 02:43:44PM +0200, Philipp Zabel wrote:
> This driver requests and remaps a memory region as configured in the
> device tree. It serves memory from this region via the genalloc API.
>
> Other drivers can retrieve the genalloc pool from a phandle pointing
> to this drivers' device node in the device tree.
<snip>
> + sram->pool = gen_pool_create(PAGE_SHIFT, -1);
> + if (!sram->pool)
> + return -ENOMEM;
As mentioned in the uio_pruss/genalloc discussion, removing the
hardcoded minimum allocation order will allow this to be used for
a number of other cases. The most notable is moving mach-davinci/
off of its own genalloc-based SRAM arch driver. Some of the davinci
SoCs have very small SRAMs and need the ability to allocate a smaller
chunk.
Here's a build-tested patch to add this option:
>From 6eced8c31eba2f86e72e854cf404d8f58fbeba85 Mon Sep 17 00:00:00 2001
From: Matt Porter <mporter@ti.com>
Date: Thu, 4 Oct 2012 11:08:02 -0400
Subject: [PATCH] misc: sram: add support for configurable allocation order
Adds support for setting the genalloc pool's minimum allocation
order via DT or platform data. The allocation order is optional
for both the DT property and platform data case. If it is not
present then the order defaults to PAGE_SHIFT to preserve the
current behavior.
Signed-off-by: Matt Porter <mporter@ti.com>
---
Documentation/devicetree/bindings/misc/sram.txt | 12 ++++++++++-
drivers/misc/sram.c | 14 ++++++++++++-
include/linux/platform_data/sram.h | 25 +++++++++++++++++++++++
3 files changed, 49 insertions(+), 2 deletions(-)
create mode 100644 include/linux/platform_data/sram.h
diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
index b64136c..b1705ec 100644
--- a/Documentation/devicetree/bindings/misc/sram.txt
+++ b/Documentation/devicetree/bindings/misc/sram.txt
@@ -8,10 +8,20 @@ Required properties:
- reg : SRAM iomem address range
-Example:
+Optional properties:
+
+- alloc-order : Minimum allocation order for the SRAM pool
+
+Examples:
+
+sram: sram at 5c000000 {
+ compatible = "sram";
+ reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
+};
sram: sram at 5c000000 {
compatible = "sram";
reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
+ alloc-order = <9>; /* Minimum 512 byte allocation */
};
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 7a363f2..3bf8ed3 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -26,6 +26,7 @@
#include <linux/platform_device.h>
#include <linux/spinlock.h>
#include <linux/genalloc.h>
+#include <linux/platform_data/sram.h>
struct sram_dev {
struct gen_pool *pool;
@@ -37,6 +38,7 @@ static int __devinit sram_probe(struct platform_device *pdev)
struct sram_dev *sram;
struct resource *res;
unsigned long size;
+ u32 alloc_order = PAGE_SHIFT;
int ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -53,7 +55,17 @@ static int __devinit sram_probe(struct platform_device *pdev)
if (!sram)
return -ENOMEM;
- sram->pool = gen_pool_create(PAGE_SHIFT, -1);
+ if (pdev->dev.of_node)
+ of_property_read_u32(pdev->dev.of_node,
+ "alloc-order", &alloc_order);
+ else
+ if (pdev->dev.platform_data) {
+ struct sram_pdata *pdata = pdev->dev.platform_data;
+ if (pdata->alloc_order)
+ alloc_order = pdata->alloc_order;
+ }
+
+ sram->pool = gen_pool_create(alloc_order, -1);
if (!sram->pool)
return -ENOMEM;
diff --git a/include/linux/platform_data/sram.h b/include/linux/platform_data/sram.h
new file mode 100644
index 0000000..e17bdaa
--- /dev/null
+++ b/include/linux/platform_data/sram.h
@@ -0,0 +1,25 @@
+/*
+ * include/linux/platform_data/sram.h
+ *
+ * Platform data for generic sram 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 as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _SRAM_H_
+#define _SRAM_H_
+
+struct sram_pdata {
+ unsigned alloc_order; /* Optional: driver defaults to PAGE_SHIFT */
+};
+
+#endif /* _SRAM_H_ */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 17/24 v2] ARM: cns3xxx: use OHCI platform driver
From: Florian Fainelli @ 2012-10-04 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349363872-27004-1-git-send-email-florian@openwrt.org>
Since both the EHCI and OHCI platform drivers use the same power_{on,off}
callbacks, rename them to cns3xx_usb_power_{on,off} to show that they are
shared.
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
No changes since v1
arch/arm/mach-cns3xxx/cns3420vb.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-cns3xxx/cns3420vb.c b/arch/arm/mach-cns3xxx/cns3420vb.c
index 906094c..8a00cee8 100644
--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -25,6 +25,7 @@
#include <linux/mtd/physmap.h>
#include <linux/mtd/partitions.h>
#include <linux/usb/ehci_pdriver.h>
+#include <linux/usb/ohci_pdriver.h>
#include <asm/setup.h>
#include <asm/mach-types.h>
#include <asm/hardware/gic.h>
@@ -127,7 +128,7 @@ static struct resource cns3xxx_usb_ehci_resources[] = {
static u64 cns3xxx_usb_ehci_dma_mask = DMA_BIT_MASK(32);
-static int csn3xxx_usb_ehci_power_on(struct platform_device *pdev)
+static int csn3xxx_usb_power_on(struct platform_device *pdev)
{
/*
* EHCI and OHCI share the same clock and power,
@@ -148,7 +149,7 @@ static int csn3xxx_usb_ehci_power_on(struct platform_device *pdev)
return 0;
}
-static void csn3xxx_usb_ehci_power_off(struct platform_device *pdev)
+static void csn3xxx_usb_power_off(struct platform_device *pdev)
{
/*
* EHCI and OHCI share the same clock and power,
@@ -162,8 +163,8 @@ static void csn3xxx_usb_ehci_power_off(struct platform_device *pdev)
static struct usb_ehci_pdata cns3xxx_usb_ehci_pdata = {
.port_power_off = 1,
- .power_on = csn3xxx_usb_ehci_power_on,
- .power_off = csn3xxx_usb_ehci_power_off,
+ .power_on = csn3xxx_usb_power_on,
+ .power_off = csn3xxx_usb_power_off,
};
static struct platform_device cns3xxx_usb_ehci_device = {
@@ -191,13 +192,20 @@ static struct resource cns3xxx_usb_ohci_resources[] = {
static u64 cns3xxx_usb_ohci_dma_mask = DMA_BIT_MASK(32);
+static struct usb_ohci_pdata cns3xxx_usb_ohci_pdata = {
+ .num_ports = 1,
+ .power_on = csn3xxx_usb_power_on,
+ .power_off = csn3xxx_usb_power_off,
+};
+
static struct platform_device cns3xxx_usb_ohci_device = {
- .name = "cns3xxx-ohci",
+ .name = "ohci-platform",
.num_resources = ARRAY_SIZE(cns3xxx_usb_ohci_resources),
.resource = cns3xxx_usb_ohci_resources,
.dev = {
.dma_mask = &cns3xxx_usb_ohci_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = &cns3xxx_usb_ohci_pdata,
},
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 14/24] USB: ohci: merge ohci_finish_controller_resume with ohci_resume
From: Florian Fainelli @ 2012-10-04 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349363872-27004-1-git-send-email-florian@openwrt.org>
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 +-
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;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 09/24 v2] ARM: cns3xxx: use ehci platform driver
From: Florian Fainelli @ 2012-10-04 15:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349363872-27004-1-git-send-email-florian@openwrt.org>
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
No change since v1
arch/arm/mach-cns3xxx/cns3420vb.c | 44 ++++++++++++++++++++++++++++++++++++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-cns3xxx/cns3420vb.c b/arch/arm/mach-cns3xxx/cns3420vb.c
index 2c5fb4c..906094c 100644
--- a/arch/arm/mach-cns3xxx/cns3420vb.c
+++ b/arch/arm/mach-cns3xxx/cns3420vb.c
@@ -24,6 +24,7 @@
#include <linux/mtd/mtd.h>
#include <linux/mtd/physmap.h>
#include <linux/mtd/partitions.h>
+#include <linux/usb/ehci_pdriver.h>
#include <asm/setup.h>
#include <asm/mach-types.h>
#include <asm/hardware/gic.h>
@@ -32,6 +33,7 @@
#include <asm/mach/time.h>
#include <mach/cns3xxx.h>
#include <mach/irqs.h>
+#include <mach/pm.h>
#include "core.h"
#include "devices.h"
@@ -125,13 +127,53 @@ static struct resource cns3xxx_usb_ehci_resources[] = {
static u64 cns3xxx_usb_ehci_dma_mask = DMA_BIT_MASK(32);
+static int csn3xxx_usb_ehci_power_on(struct platform_device *pdev)
+{
+ /*
+ * EHCI and OHCI share the same clock and power,
+ * resetting twice would cause the 1st controller been reset.
+ * Therefore only do power up at the first up device, and
+ * power down at the last down device.
+ *
+ * Set USB AHB INCR length to 16
+ */
+ if (atomic_inc_return(&usb_pwr_ref) == 1) {
+ cns3xxx_pwr_power_up(1 << PM_PLL_HM_PD_CTRL_REG_OFFSET_PLL_USB);
+ cns3xxx_pwr_clk_en(1 << PM_CLK_GATE_REG_OFFSET_USB_HOST);
+ cns3xxx_pwr_soft_rst(1 << PM_SOFT_RST_REG_OFFST_USB_HOST);
+ __raw_writel((__raw_readl(MISC_CHIP_CONFIG_REG) | (0X2 << 24)),
+ MISC_CHIP_CONFIG_REG);
+ }
+
+ return 0;
+}
+
+static void csn3xxx_usb_ehci_power_off(struct platform_device *pdev)
+{
+ /*
+ * EHCI and OHCI share the same clock and power,
+ * resetting twice would cause the 1st controller been reset.
+ * Therefore only do power up at the first up device, and
+ * power down@the last down device.
+ */
+ if (atomic_dec_return(&usb_pwr_ref) == 0)
+ cns3xxx_pwr_clk_dis(1 << PM_CLK_GATE_REG_OFFSET_USB_HOST);
+}
+
+static struct usb_ehci_pdata cns3xxx_usb_ehci_pdata = {
+ .port_power_off = 1,
+ .power_on = csn3xxx_usb_ehci_power_on,
+ .power_off = csn3xxx_usb_ehci_power_off,
+};
+
static struct platform_device cns3xxx_usb_ehci_device = {
- .name = "cns3xxx-ehci",
+ .name = "ehci-platform",
.num_resources = ARRAY_SIZE(cns3xxx_usb_ehci_resources),
.resource = cns3xxx_usb_ehci_resources,
.dev = {
.dma_mask = &cns3xxx_usb_ehci_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = &cns3xxx_usb_ehci_pdata,
},
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH] pwm: Get rid of HAVE_PWM
From: Lars-Peter Clausen @ 2012-10-04 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349330819-11924-1-git-send-email-thierry.reding@avionic-design.de>
On 10/04/2012 08:06 AM, Thierry Reding wrote:
> [...]
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 331d574..b38f23d 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -219,7 +219,8 @@ config MACH_JZ4740
> select GENERIC_GPIO
> select ARCH_REQUIRE_GPIOLIB
> select SYS_HAS_EARLY_PRINTK
> - select HAVE_PWM
> + select PWM
> + select PWM_JZ4740
> select HAVE_CLK
> select GENERIC_IRQ_CHIP
I'm not sure if this is such a good idea, not all jz4740 based board
necessarily require PWM.
- Lars
^ permalink raw reply
* [PATCH 12/17] ARM: iop13xx: mark iop13xx_scan_bus as __devinit
From: Greg KH @ 2012-10-04 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210041032.20300.arnd@arndb.de>
On Thu, Oct 04, 2012 at 10:32:20AM +0000, Arnd Bergmann wrote:
> (+Greg)
>
> On Tuesday 02 October 2012, Bjorn Helgaas wrote:
> >
> > On Tue, Oct 2, 2012 at 10:36 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > > pci_scan_root_bus is __devinit, so iop13xx_scan_bus has to be the
> > > same in order to safely call it. This is ok because the function
> > > itself is only called from the hwpci->scan callback.
> > >
> > > WARNING: vmlinux.o(.text+0x10138): Section mismatch in reference from the function iop13xx_scan_bus() to the function .devinit.text:pci_scan_root_bus()
> > > The function iop13xx_scan_bus() references
> > > the function __devinit pci_scan_root_bus().
> > > This is often because iop13xx_scan_bus lacks a __devinit
> > > annotation or the annotation of pci_scan_root_bus is wrong.
> >
> > With CONFIG_HOTPLUG going away (I think the current state is that it
> > is always set to "y"), __devinit will effectively become a no-op, so I
> > expect we'll remove it from pci_scan_root_bus().
> >
> > Therefore, I would skip this patch and live with the warning a little longer.
>
> Hmm, I'm just trying to get rid of all build time warnings in the defconfigs
> right now, and modpost still complains about the section mismatches. I have
> a bunch more of these patches, but it would also be fine with me if we can
> patch mostpost to ignore these cases.
>
> I've also redone the analysis that Greg cited in the commit message for
> 45f035ab9b8 "CONFIG_HOTPLUG should be always on"
>
> It is quite hard to disable it these days, and even if you do, it
> only saves you about 200 bytes. However, if it is disabled, lots of
> bugs show up because it is almost never tested if the option is disabled.
>
> My test case (ARM omap2plus_defconfig, one of the most common configurations)
> shows these size -A differences:
>
>
>
> section nohotplug hotplug difference
> .head.text 392 392 0
> .text 4829940 4881140 51200
> .rodata 1630360 1633056 2696
> __ksymtab 25720 25720 0
> __ksymtab_gpl 17096 17136 40
> __kcrctab 12860 12860 0
> __kcrctab_gpl 8548 8568 20
> __ksymtab_stri 96427 96509 82
> __init_rodata 0 9800 9800
> __param 2320 2320 0
> __modver 716 364 -352
> .ARM.unwind_idx 160360 160792 432
> .ARM.unwind_tab 24312 24312 0
> .init.text 234632 195688 -38944
> .exit.text 8680 5116 -3564
> .init.proc.info 312 312 0
> .init.arch.info 2964 2964 0
> .init.tagtable 72 72 0
> .init.smpalt 776 776 0
> .init.pv_table 880 880 0
> .init.data 123356 111348 -12008
> .exit.data 0 0 0
> .data..percpu 12928 12928 0
> .data 560160 562688 2528
> .notes 36 36 0
> .bss 5605324 5605580 256
>
> total 13359171 13371357 12186
> after boot 13001183 13054521 53338
>
> That is over 50kb difference after discarding the init sections,
> significantly more than the 200 bytes that Greg found.
> The point about lack of testing is still valid of course, and I'm
> not saying we need to keep the option around, but it's really
> not as obvious as before. An argument in favor of removing the
> __devinit logic is that these 50kb is still just 0.4% of the
> kernel size.
>
> For the five ARM defconfig files that actually turn off hotplug,
> the absolute numbers are a bit lower, but the percentage is similar.
>
> This is the amount of space wasted by enabling on CONFIG_HOTPLUG
> on them, in bytes after discarding the init sections, and as a
> percentage of the vmlinux size:
>
> at91x40_defconfig 3448 0.27%
> edb7211_defconfig 8912 0.41%
> footbridge_defconfig 33347 0.97%
> fortunet_defconfig 4592 0.25%
> pleb_defconfig 7405 0.28%
>
> Footbridge is the only config among these that enables PCI and USB, so
> it has a bunch more drivers that actually have notable functions that
> can be discarded.
USB drivers should not be having anything discarded if CONFIG_HOTPLUG is
disabled (it shouldn't be disabled for USB systems, unless someone isn't
going to plug a USB device into the system after it comes up, which is
one of the main confusions here.)
As for PCI, that seems like a lot of code getting thrown away, it would
be interesting to figure out why that is.
My plans are to now start unwinding the CONFIG_HOTPLUG dependancies. If
a driver subsystem really does want to throw away sections (like PCI
will if CONFIG_PCI_HOTPLUG is not enabled), then it should be able to.
But I imagine all of the real savings will be in the bus cores, not the
individual drivers, unless they have huge module_init() functions.
Thanks for the numbers, I'll look into this more in the coming weeks.
greg k-h
^ permalink raw reply
* usb: uhci-platform driver fails after patch changes during merge
From: Greg KH @ 2012-10-04 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349333716.7905.1.camel@gitbox>
On Thu, Oct 04, 2012 at 07:55:16PM +1300, Tony Prisk wrote:
> On Thu, 2012-10-04 at 19:38 +1300, Tony Prisk wrote:
> > Mike,
> >
> > I see someone made changes to the uhci-platform.c driver I submitted
> > during v3.7 which results in it not working on mach-vt8500.
> >
> > Could you clarify why the changes were made, and what the suggested
> > resolution would be to solve the problem that it introduced?
> >
> > Lines indicated by ---> below were removed from the patch, which means
> > that on arch-vt8500 there is no dma_mask set, and its fails to
> > communicate with attached devices.
> >
> > Regards
> >
> > Tony P
> >
> >
> > static int __devinit uhci_hcd_platform_probe(struct platform_device
> > *pdev)
> > ...
> > if (usb_disabled())
> > return -ENODEV;
> > --->
> > /* Right now device-tree probed devices don't get dma_mask set.
> > * Since shared usb code relies on it, set it here for now.
> > * Once we have dma capability bindings this can go away.
> > */
> > if (!pdev->dev.dma_mask)
> > pdev->dev.dma_mask = &platform_uhci_dma_mask;
> > --->
> > hcd = usb_create_hcd(&uhci_platform_hc_driver, &pdev->dev,
> > pdev->name);
> > ...
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> Greg,
>
> This message was intended for you rather than Mike. Could you clarify
> what happened and the expected resolution?
I don't know, this should be directed at the person who made the change
that is causing the problem, and the linux-usb at vger.kernel.org mailing
list.
Who changed the patch? What patch exactly are you referring to? Who
signed off on it? Where was it discussed?
thanks,
greg k-h
^ permalink raw reply
* [PATCH 0/7] Add support for Freescale's mc34708 to mc13xxx driver
From: Uwe Kleine-König @ 2012-10-04 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004135130.GC5554@sortiz-mobl>
Hi,
On Thu, Oct 04, 2012 at 03:51:30PM +0200, Samuel Ortiz wrote:
> Did you send it to my samuel.ortiz at intel.com email ? I never look at it when
> going through my MFD backlog, which is why it was not applied. Which is why it
> won't be part of the 3.7 merge window, sorry about that.
I don't know why I picked that one up, but probably it's because this
address shows up in several commits:
$ git log --grep=samuel.ortiz at intel.com | grep Samuel | sort | uniq -c
18 Acked-by: Samuel Ortiz <samuel.ortiz@intel.com>
12 Author: Samuel Ortiz <sameo@linux.intel.com>
27 Author: Samuel Ortiz <samuel.ortiz@intel.com>
4 Cc: Samuel Ortiz <samuel.ortiz@intel.com>
1 Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
50 Signed-off-by: Samuel Ortiz <samuel.ortiz@intel.com>
and one of these just happend to be the first I looked at.
hmm, *shrug*
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM : i.MX27 : split code for allocation of ressources of camera and eMMA
From: Fabio Estevam @ 2012-10-04 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CAvwwGEwbZE2VS49tpWOYxAR_qQkfKhswPaofSrni92A@mail.gmail.com>
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,
>
> Can you get your camera working on visstrim board using linux-next or
> 3.6-rc4? Any patches I am missing?
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
Thanks,
Fabio Estevam
^ permalink raw reply
* [PATCH v3 0/6] uio_pruss cleanup and platform support
From: Philipp Zabel @ 2012-10-04 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004135433.GI11149@beef>
On Thu, Oct 04, 2012 at 09:54:33AM -0400, Matt Porter wrote:
> *sigh*, I see now. I looked at v2 and got wrapped up in the DT use case
> and missed your platform device support. I think it will work just fine
> for us to use in a "phase 2" of this work, replacing the backend of
> davinci sram allocation with this as Sekhar seems to be open to.
>
> > > I do see it moving to your driver exclusively, but I wanted to make this
> > > series focused on only getting rid of the private SRAM API using the
> > > existing pdata framework that's already there. I think once
> > > gen_pool_find_by_phys() goes upstream we can switch to that and get the
> > > address from a resource in the !DT case. I guess we should see if Sekhar
> > > would like to see this happen in two steps or just have us depend on
> > > the gen_pool_find_by_phys() patch now.
> >
> > Thanks, I'm glad you are aware of the sram driver and consider it useful.
> >
> > > BTW, I was going to post a patch for your driver to allow
> > > configurability of the allocation order, but have been busy with other
> > > things. We'll eventually need that when switching to it as the
> > > hardcoded page size order isn't going to work for all cases.
> >
> > Good point.
>
> I think this is the only blocker to DaVinci adopting it once it goes
> upstream. I can add a patch in your driver thread if that helps.
Yes, that would be welcome.
regards
Philipp
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v3 0/6] uio_pruss cleanup and platform support
From: Matt Porter @ 2012-10-04 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004133553.GA5151@pengutronix.de>
On Thu, Oct 04, 2012 at 03:35:53PM +0200, Philipp Zabel wrote:
> On Thu, Oct 04, 2012 at 08:42:53AM -0400, Matt Porter wrote:
> > > I think the generic SRAM/genalloc driver (https://lkml.org/lkml/2012/9/7/282)
> > > could be useful to map the L3RAM on Davinci.
> > > With the gen_pool lookup patch (https://lkml.org/lkml/2012/9/7/284) the
> > > uio_pruss driver could then use the gen_pool_find_by_phys() (or
> > > of_get_named_gen_pool() for initialization from device tree) to
> > > retrieve the struct gen_pool*.
> > >
> > > This way you could avoid handing it over via platform data and you could
> > > get rid of arch/arm/mach-davinci/{sram.c,include/mach/sram.h} completely.
> >
> > I did miss the gen_pool_find_by_phys() call in that series. That does
> > look useful. I actually mentioned your series in an earlier posting
> > since I like it,
>
> That I did miss.
>
> > but since the initialization of the driver was inherently
> > tied to DT it's not usable for DaVinci that's just starting to convert
> > to DT and needs !DT support as well.
>
> There should be no dependency on DT in the sram driver. It just requests
> and remaps the first given iomem resource and creates a gen_pool from that.
> This should work just as well for the !DT case.
> Maybe it's just my choice of patch series subject gave you that
> impression? If there's a real issue for !DT, I should fix it.
*sigh*, I see now. I looked at v2 and got wrapped up in the DT use case
and missed your platform device support. I think it will work just fine
for us to use in a "phase 2" of this work, replacing the backend of
davinci sram allocation with this as Sekhar seems to be open to.
> > I do see it moving to your driver exclusively, but I wanted to make this
> > series focused on only getting rid of the private SRAM API using the
> > existing pdata framework that's already there. I think once
> > gen_pool_find_by_phys() goes upstream we can switch to that and get the
> > address from a resource in the !DT case. I guess we should see if Sekhar
> > would like to see this happen in two steps or just have us depend on
> > the gen_pool_find_by_phys() patch now.
>
> Thanks, I'm glad you are aware of the sram driver and consider it useful.
>
> > BTW, I was going to post a patch for your driver to allow
> > configurability of the allocation order, but have been busy with other
> > things. We'll eventually need that when switching to it as the
> > hardcoded page size order isn't going to work for all cases.
>
> Good point.
I think this is the only blocker to DaVinci adopting it once it goes
upstream. I can add a patch in your driver thread if that helps.
-Matt
^ permalink raw reply
* [PATCH] ARM: davinci: dm644x: fix out range signal for ED
From: Prabhakar Lad @ 2012-10-04 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506D3704.4060102@ti.com>
Sekhar
On Thu, Oct 4, 2012 at 12:43 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> On 10/4/2012 10:22 AM, Prabhakar Lad wrote:
>> Hi Sekhar,
>>
>> On Wed, Oct 3, 2012 at 4:08 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>>> On 10/3/2012 12:05 PM, Prabhakar wrote:
>>>> From: Lad, Prabhakar <prabhakar.lad@ti.com>
>>>>
>>>> while testing display on dm644x, for ED out-range signals
>>>> was observed. This patch fixes appropriate clock setting
>>>> for ED.
>>>
>>> Can you please clarify what you mean by "out range signal"? Are there
>>> any user visible artifacts on the display? What was the clock being
>>> provided earlier and what is the value after this patch?
>>>
>>> Also, is the issue severe enough that this patch should be applied to
>>> stable tree as well?
>>>
>> Ideally a clock of 54Mhz is required for enhanced definition to
>> work, which it was actually set to but while testing I noticed
>> out-of-range signal. The out-of-range signal is often caused
>> when the field rate is above the rate that the television will handle.
>> When this is the case the TV or monitor displays "Out-Of-Range Signal".
>>
>> Reducing the clock fixed it. now the clock is set to 27Mhz.
>
> So, is the requirement for ED 54MHz or lower? Still trying to explain
> myself how 27MHz is working where a 54MHz is required. I guess there is
> also a lower limit on what the frequency should be?
>
Ideally its 54Mhz, but I see in the datasheet for AD7342/3 [1] it can also
work at 27Mhz too.
Regards,
--Prabhakar
[1] http://www.analog.com/static/imported-files/data_sheets/ADV7342_7343.pdf
> Sorry I am not familiar will all the video concepts, hence the questions.
>
> Thanks,
> Sekhar
^ permalink raw reply
* [PATCH 0/7] Add support for Freescale's mc34708 to mc13xxx driver
From: Samuel Ortiz @ 2012-10-04 13:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5BqZpy5Cz0BxbpdOY=sjMjhSOjfQZmJ4j7Xwe6Q7x6Yig@mail.gmail.com>
Hi Fabio,
On Thu, Oct 04, 2012 at 10:01:21AM -0300, Fabio Estevam wrote:
> Hi Samuel,
>
> On Wed, Sep 5, 2012 at 11:22 AM, Fabio Estevam <festevam@gmail.com> wrote:
> > Hi Samuel,
> >
> > On Thu, Jul 12, 2012 at 8:02 PM, Marc Reilly <marc@cpdesign.com.au> wrote:
> >> Hi Uwe,
> >>
> >>> This series was tested on a Phytec pcm038 (mc13783 on spi) using
> >>> traditional boot (i.e. not dt) and on a i.MX53 based machine (mc34708 on
> >>> i2c) using dt boot.
> >>>
> >>> Philippe's patches are already in next, they are just included here for
> >>> those who want to test the patches. The 'mfd/mc13xxx: drop modifying
> >>> driver's id_table in probe' was already sent out yesterday and is
> >>> included here because the last patch depends on it.
> >>>
> >>
> >> For all patches (that don't already have it):
> >> Acked-by: Marc Reilly <marc@cpdesign.com.au>
> >
> > Can this series be applied?
>
> Any comments on this series, please?
Did you send it to my samuel.ortiz at intel.com email ? I never look at it when
going through my MFD backlog, which is why it was not applied. Which is why it
won't be part of the 3.7 merge window, sorry about that.
> I want to add mc34708 support to mx53qsb and need this series to be applied.
I understand. I'll queue it to my for-next branch as soon as the merge window
is closed.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* [PATCH 1/3] mfd: dbx500: Export prmcu_request_ape_opp_100_voltage
From: Samuel Ortiz @ 2012-10-04 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348497799-32143-2-git-send-email-ulf.hansson@stericsson.com>
Hi Ulf,
On Mon, Sep 24, 2012 at 04:43:17PM +0200, Ulf Hansson 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: Samuel Ortiz <sameo@linux.intel.com>
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* [kvmarm] [PATCH 06/15] KVM: ARM: Initial skeleton to compile KVM support
From: Avi Kivity @ 2012-10-04 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20120925152055.GC28728@mudshark.cambridge.arm.com>
On 09/25/2012 05:20 PM, Will Deacon wrote:
>> + case KVM_GET_REG_LIST: {
>> + struct kvm_reg_list __user *user_list = argp;
>> + struct kvm_reg_list reg_list;
>> + unsigned n;
>> +
>> + if (copy_from_user(®_list, user_list, sizeof reg_list))
>> + return -EFAULT;
>> + n = reg_list.n;
>> + reg_list.n = kvm_arm_num_regs(vcpu);
>> + if (copy_to_user(user_list, ®_list, sizeof reg_list))
>> + return -EFAULT;
>> + if (n < reg_list.n)
>> + return -E2BIG;
>> + return kvm_arm_copy_reg_indices(vcpu, user_list->reg);
>
> kvm_reg_list sounds like it could be done using a regset instead.
Wouldn't those regsets be userspace oriented?
For example, the GPRs returned here include all the shadowed interrupt
registers (or however they're called) while most user oriented APIs
would only include the user visible registers.
FWIW, we're trying to move to an architecture independent ABI for KVM
registers, but that's a lot of work since we need to make sure all the
weird x86 registers (and non-register state) fit into that. Maybe that
ABI will be regset based, but I don't want to block the ARM port on this.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* [PATCH v3 0/6] uio_pruss cleanup and platform support
From: Philipp Zabel @ 2012-10-04 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121004124253.GC11149@beef>
On Thu, Oct 04, 2012 at 08:42:53AM -0400, Matt Porter wrote:
> > I think the generic SRAM/genalloc driver (https://lkml.org/lkml/2012/9/7/282)
> > could be useful to map the L3RAM on Davinci.
> > With the gen_pool lookup patch (https://lkml.org/lkml/2012/9/7/284) the
> > uio_pruss driver could then use the gen_pool_find_by_phys() (or
> > of_get_named_gen_pool() for initialization from device tree) to
> > retrieve the struct gen_pool*.
> >
> > This way you could avoid handing it over via platform data and you could
> > get rid of arch/arm/mach-davinci/{sram.c,include/mach/sram.h} completely.
>
> I did miss the gen_pool_find_by_phys() call in that series. That does
> look useful. I actually mentioned your series in an earlier posting
> since I like it,
That I did miss.
> but since the initialization of the driver was inherently
> tied to DT it's not usable for DaVinci that's just starting to convert
> to DT and needs !DT support as well.
There should be no dependency on DT in the sram driver. It just requests
and remaps the first given iomem resource and creates a gen_pool from that.
This should work just as well for the !DT case.
Maybe it's just my choice of patch series subject gave you that
impression? If there's a real issue for !DT, I should fix it.
> I do see it moving to your driver exclusively, but I wanted to make this
> series focused on only getting rid of the private SRAM API using the
> existing pdata framework that's already there. I think once
> gen_pool_find_by_phys() goes upstream we can switch to that and get the
> address from a resource in the !DT case. I guess we should see if Sekhar
> would like to see this happen in two steps or just have us depend on
> the gen_pool_find_by_phys() patch now.
Thanks, I'm glad you are aware of the sram driver and consider it useful.
> BTW, I was going to post a patch for your driver to allow
> configurability of the allocation order, but have been busy with other
> things. We'll eventually need that when switching to it as the
> hardcoded page size order isn't going to work for all cases.
Good point.
regards
Philipp
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 06/15] KVM: ARM: Initial skeleton to compile KVM support
From: Christoffer Dall @ 2012-10-04 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <000301cda230$91eb4fa0$b5c1eee0$@samsung.com>
On Thu, Oct 4, 2012 at 9:02 AM, Min-gyu Kim <mingyu84.kim@samsung.com> wrote:
>
>
>> -----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:
>> >> On 09/25/2012 11:20 AM, Will Deacon wrote:
>> >> >> +/* Multiprocessor Affinity Register */
>> >> >> +#define MPIDR_CPUID (0x3 << 0)
>> >> >
>> >> > I'm fairly sure we already have code under arch/arm/ for dealing
>> >> > with the mpidr. Let's re-use that rather than reinventing it here.
>> >> >
>> >>
>> >> I see some defines in topology.c - do you want some of these factored
>> >> out into a header file that we can then also use from kvm? If so,
> where?
>> >
>> > I guess either in topology.h or a new header (topology-bits.h).
>> >
>> >> >> +#define EXCEPTION_NONE 0
>> >> >> +#define EXCEPTION_RESET 0x80
>> >> >> +#define EXCEPTION_UNDEFINED 0x40
>> >> >> +#define EXCEPTION_SOFTWARE 0x20
>> >> >> +#define EXCEPTION_PREFETCH 0x10
>> >> >> +#define EXCEPTION_DATA 0x08
>> >> >> +#define EXCEPTION_IMPRECISE 0x04
>> >> >> +#define EXCEPTION_IRQ 0x02
>> >> >> +#define EXCEPTION_FIQ 0x01
>> >> >
>> >> > Why the noise?
>> >> >
>> >>
>> >> these are simply cruft from a previous life of KVM/ARM.
>> >
>> > Ok, then please get rid of them.
>> >
>> >> >> +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.
>
> From the code above, BUG_ON case clearly points out that there happened a
> serious bug case. However, killing the corresponding VM may not cause any
> further problem.
> Then leave some logs for debugging and killing the VM seems to be enough.
>
> Let's assume KVM for ARM is distributed with a critical bug.
> If the case is defended by BUG_ON, it will cause host to shutdown.
> If the case is defended by killing VM, it will cause VM to shutdown.
> In my opinion, latter case seems to be better.
>
> I looked for a guide on BUG_ON and found this:
> http://yarchive.net/comp/linux/BUG.html
>
>
I completely agree with all this, no further argument is needed. The
point of a BUG_ON is to explicitly state the reason for a bug that
will anyhow cause the host kernel to overall malfunction. The above
bug_on statement is long gone (see new patches), and if you see other
cases like this, the code should have been tested and we can remove
the BUG_ON.
>> >> >
>> >> >> +static inline u32 *vcpu_pc(struct kvm_vcpu *vcpu) {
>> >> >> + return vcpu_reg(vcpu, 15); }
>> >> >
>> >> > If you stick a struct pt_regs into struct kvm_regs, you could reuse
>> >> > ARM_pc here etc.
>> >> >
>> >>
>> >> I prefer not to, because we'd have those registers presumably for usr
>> >> mode and then we only define the others explicit. I think it's much
>> >> clearer to look at kvm_regs today.
>> >
>> > I disagree and think that you should reuse as much of the arch/arm/
>> > code as possible. Not only does it make it easier to read by people
>> > who are familiar with that code (and in turn get you more reviewers)
>> > but it also means that we limit the amount of duplication that we have.
>>
>> Reusing a struct just for the sake of reusing is not necessarily an
>> improvement. Some times it complicates things, and some times it's
>> misleading. To me, pt_regs carry the meaning that these are the registers
>> for a user space process that traps into the kernel - in KVM we emulate a
>> virtual CPU and that current definition is quite clear.
>>
>> The argument that more people will review the code if the struct contains
>> a pt_regs field rather than a usr_regs field is completely invalid,
>> because I'm sure everyone that reviews virtualization code will know that
>> user mode is a mode on the cpu and it has some registers and this is the
>> state we store when we context switch a VM - pt_regs could be read as the
>> regs that we stored in the mode that the VM happened to be in when we took
>> an exception, which I would think is crazy, and probably not what you
>> suggest.
>>
>> Writing the literal 15 for the PC register is not really a problem in
>> terms of duplication - it's nothing that requires separate maintenance.
>>
>> At this point the priority should really be correctness, readability, and
>> performance, imho.
>>
>> >
>> > I think Marc (CC'd) had a go at this with some success.
>> >
>>
>> great, if this improves the code, then I suggest someone rebases an
>> appropriate patch and sends it to the kvmarm mailing list so we can have a
>> look at it, but there are users out there looking to try kvm/arm and we
>> should try to give it to them.
>>
>> >> >> +#ifndef __ARM_KVM_HOST_H__
>> >> >> +#define __ARM_KVM_HOST_H__
>> >> >> +
>> >> >> +#include <asm/kvm.h>
>> >> >> +
>> >> >> +#define KVM_MAX_VCPUS 4
>> >> >
>> >> > NR_CPUS?
>> >> >
>> >>
>> >> well this is defined by KVM generic code, and is common for other
>> >> architecture.
>> >
>> > I mean #define KVM_MAX_CPUS NR_CPUS. The 4 seems arbitrary.
>> >
>> >> >> +int __attribute_const__ kvm_target_cpu(void) {
>> >> >> + unsigned int midr;
>> >> >> +
>> >> >> + midr = read_cpuid_id();
>> >> >> + switch ((midr >> 4) & 0xfff) {
>> >> >> + case KVM_ARM_TARGET_CORTEX_A15:
>> >> >> + return KVM_ARM_TARGET_CORTEX_A15;
>> >> >
>> >> > I have this code already in perf_event.c. Can we move it somewhere
>> >> > common and share it? You should also check that the implementor field
>> is 0x41.
>> >> >
>> >>
>> >> by all means, you can probably suggest a good place better than I
> can...
>> >
>> > cputype.h?
>> >
>> >> >> +#include <linux/module.h>
>> >> >> +
>> >> >> +EXPORT_SYMBOL_GPL(smp_send_reschedule);
>> >> >
>> >> > Erm...
>> >> >
>> >> > We already have arch/arm/kernel/armksyms.c for exports -- please use
>> that.
>> >> > However, exporting such low-level operations sounds like a bad
>> >> > idea. How realistic is kvm-as-a-module on ARM anyway?
>> >> >
>> >>
>> >> at this point it's broken, so I'll just remove this and leave this
>> >> for a fun project for some poor soul at some point if anyone ever
>> >> needs half the code outside the kernel as a module (the other half
>> >> needs to be compiled in anyway)
>> >
>> > Ok, that suits me. If it's broken, let's not include it in the initial
>> > submission.
>> >
>> >> >> +int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct
>> >> >> +kvm_regs *regs) {
>> >> >> + return -EINVAL;
>> >> >> +}
>> >> >> +
>> >> >> +int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct
>> >> >> +kvm_regs *regs) {
>> >> >> + return -EINVAL;
>> >> >> +}
>> >> >
>> >> > Again, all looks like this should be implemented using regsets from
>> >> > what I can tell.
>> >> >
>> >>
>> >> this API has been discussed to death on the KVM lists, and we can of
>> >> course revive that if the regset makes it nicer - I'd prefer getting
>> >> this upstream the way that it is now though, where GET_REG / SET_REG
>> >> seems to be the way forward from a KVM perspective.
>> >
>> > I'm sure the API has been discussed, but I've not seen that
>> > conversation and I'm also not aware about whether or not regsets were
>> > considered as a possibility for this stuff. The advantages of using them
>> are:
>> >
>> > 1. It's less code for the arch to implement (and most of what
> you
>> > need, you already have).
>> >
>> > 2. You can move the actual copying code into core KVM, like we
>> have
>> > for ptrace.
>> >
>> > 3. New KVM ports (e.g. arm64) can reuse the core copying code
>> > easily.
>> >
>> > Furthermore, some registers (typically) floating point and GPRs will
>> > already have regsets for the ptrace code, so that can be reused if you
>> > share the datatypes.
>> >
>> > The big problem with getting things upstream and then changing it
>> > later is that you will break the ABI. I highly doubt that's feasible,
>> > so can we not just use regsets from the start for ARM?
>> >
>> >> >> +int kvm_reset_vcpu(struct kvm_vcpu *vcpu) {
>> >> >> + struct kvm_regs *cpu_reset;
>> >> >> +
>> >> >> + switch (vcpu->arch.target) {
>> >> >> + case KVM_ARM_TARGET_CORTEX_A15:
>> >> >> + if (vcpu->vcpu_id > a15_max_cpu_idx)
>> >> >> + return -EINVAL;
>> >> >> + cpu_reset = &a15_regs_reset;
>> >> >> + vcpu->arch.midr = read_cpuid_id();
>> >> >> + break;
>> >> >> + default:
>> >> >> + return -ENODEV;
>> >> >> + }
>> >> >> +
>> >> >> + /* Reset core registers */
>> >> >> + memcpy(&vcpu->arch.regs, cpu_reset,
>> >> >> + sizeof(vcpu->arch.regs));
>> >> >> +
>> >> >> + /* Reset CP15 registers */
>> >> >> + kvm_reset_coprocs(vcpu);
>> >> >> +
>> >> >> + return 0;
>> >> >> +}
>> >> >
>> >> > This is a nice way to plug in new CPUs but the way the rest of the
>> >> > code is currently written, all the ARMv7 and Cortex-A15 code is
>> >> > merged together. I
>> >> > *strongly* suggest you isolate this from the start, as it will help
>> >> > you see what is architected and what is implementation-specific.
>> >> >
>> >>
>> >> not entirely sure what you mean. You want a separate coproc.c file
>> >> for
>> >> Cortex-A15 specific stuff like coproc_a15.c?
>> >
>> > Indeed. I think it will make adding new CPUs a lot clearer and
>> > separate the architecture from the implementation.
>> >
>> > Cheers,
>> >
>> > Will
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in the body
>> of a message to majordomo at vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 1/1] mtd: st fsmc_nand: pass the ale and cmd resource via resource
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-04 13:14 UTC (permalink / raw)
To: linux-arm-kernel
Do not use the platform_data to pass resource and be smart in the drivers.
Just pass it via resource
Switch to devm_request_and_ioremap at the sametime
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Vipin Kumar <vipin.kumar@st.com>
Cc: linux-mtd at lists.infradead.org
---
.../devicetree/bindings/mtd/fsmc-nand.txt | 12 +++---
arch/arm/boot/dts/spear13xx.dtsi | 10 ++---
arch/arm/boot/dts/spear300.dtsi | 8 ++--
arch/arm/boot/dts/spear310.dtsi | 8 ++--
arch/arm/boot/dts/spear320.dtsi | 8 ++--
arch/arm/boot/dts/spear600.dtsi | 8 ++--
arch/arm/mach-u300/core.c | 14 ++++++-
drivers/mtd/nand/fsmc_nand.c | 44 +++++---------------
include/linux/mtd/fsmc.h | 3 --
9 files changed, 49 insertions(+), 66 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
index e2c663b..e3ea32e 100644
--- a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
@@ -3,9 +3,7 @@
Required properties:
- compatible : "st,spear600-fsmc-nand"
- reg : Address range of the mtd chip
-- reg-names: Should contain the reg names "fsmc_regs" and "nand_data"
-- st,ale-off : Chip specific offset to ALE
-- st,cle-off : Chip specific offset to CLE
+- reg-names: Should contain the reg names "fsmc_regs", "nand_data", "nand_addr" and "nand_cmd"
Optional properties:
- bank-width : Width (in bytes) of the device. If not present, the width
@@ -19,10 +17,10 @@ Example:
#address-cells = <1>;
#size-cells = <1>;
reg = <0xd1800000 0x1000 /* FSMC Register */
- 0xd2000000 0x4000>; /* NAND Base */
- reg-names = "fsmc_regs", "nand_data";
- st,ale-off = <0x20000>;
- st,cle-off = <0x10000>;
+ 0xd2000000 0x0010 /* NAND Base DATA */
+ 0xd2020000 0x0010 /* NAND Base ADDR */
+ 0xd2010000 0x0010>; /* NAND Base CMD */
+ reg-names = "fsmc_regs", "nand_data", "nand_addr", "nand_cmd";
bank-width = <1>;
nand-skip-bbtscan;
diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
index f7b84ac..14a6d15 100644
--- a/arch/arm/boot/dts/spear13xx.dtsi
+++ b/arch/arm/boot/dts/spear13xx.dtsi
@@ -104,15 +104,15 @@
compatible = "st,spear600-fsmc-nand";
#address-cells = <1>;
#size-cells = <1>;
- reg = <0xb0000000 0x1000 /* FSMC Register */
- 0xb0800000 0x0010>; /* NAND Base */
- reg-names = "fsmc_regs", "nand_data";
+ reg = <0xb0000000 0x1000 /* FSMC Register*/
+ 0xb0800000 0x0010 /* NAND Base DATA */
+ 0xb0820000 0x0010 /* NAND Base ADDR */
+ 0xb0810000 0x0010>; /* NAND Base CMD */
+ reg-names = "fsmc_regs", "nand_data", "nand_addr", "nand_cmd";
interrupts = <0 20 0x4
0 21 0x4
0 22 0x4
0 23 0x4>;
- st,ale-off = <0x20000>;
- st,cle-off = <0x10000>;
status = "disabled";
};
diff --git a/arch/arm/boot/dts/spear300.dtsi b/arch/arm/boot/dts/spear300.dtsi
index ed3627c..bc43638 100644
--- a/arch/arm/boot/dts/spear300.dtsi
+++ b/arch/arm/boot/dts/spear300.dtsi
@@ -38,10 +38,10 @@
#address-cells = <1>;
#size-cells = <1>;
reg = <0x94000000 0x1000 /* FSMC Register */
- 0x80000000 0x0010>; /* NAND Base */
- reg-names = "fsmc_regs", "nand_data";
- st,ale-off = <0x20000>;
- st,cle-off = <0x10000>;
+ 0x80000000 0x0010 /* NAND Base DATA */
+ 0x80020000 0x0010 /* NAND Base ADDR */
+ 0x80010000 0x0010>; /* NAND Base CMD */
+ reg-names = "fsmc_regs", "nand_data", "nand_addr", "nand_cmd";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/spear310.dtsi b/arch/arm/boot/dts/spear310.dtsi
index 62fc4fb..7840e52 100644
--- a/arch/arm/boot/dts/spear310.dtsi
+++ b/arch/arm/boot/dts/spear310.dtsi
@@ -32,10 +32,10 @@
#address-cells = <1>;
#size-cells = <1>;
reg = <0x44000000 0x1000 /* FSMC Register */
- 0x40000000 0x0010>; /* NAND Base */
- reg-names = "fsmc_regs", "nand_data";
- st,ale-off = <0x10000>;
- st,cle-off = <0x20000>;
+ 0x40000000 0x0010 /* NAND Base DATA */
+ 0x40020000 0x0010 /* NAND Base ADDR */
+ 0x40010000 0x0010>; /* NAND Base CMD */
+ reg-names = "fsmc_regs", "nand_data", "nand_addr", "nand_cmd";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/spear320.dtsi b/arch/arm/boot/dts/spear320.dtsi
index 1f49d69..5ad8206 100644
--- a/arch/arm/boot/dts/spear320.dtsi
+++ b/arch/arm/boot/dts/spear320.dtsi
@@ -38,10 +38,10 @@
#address-cells = <1>;
#size-cells = <1>;
reg = <0x4c000000 0x1000 /* FSMC Register */
- 0x50000000 0x0010>; /* NAND Base */
- reg-names = "fsmc_regs", "nand_data";
- st,ale-off = <0x20000>;
- st,cle-off = <0x10000>;
+ 0x50000000 0x0010 /* NAND Base DATA */
+ 0x50020000 0x0010 /* NAND Base ADDR */
+ 0x50010000 0x0010>; /* NAND Base CMD */
+ reg-names = "fsmc_regs", "nand_data", "nand_addr", "nand_cmd";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/spear600.dtsi b/arch/arm/boot/dts/spear600.dtsi
index a3c36e4..4ecc66f 100644
--- a/arch/arm/boot/dts/spear600.dtsi
+++ b/arch/arm/boot/dts/spear600.dtsi
@@ -67,10 +67,10 @@
#address-cells = <1>;
#size-cells = <1>;
reg = <0xd1800000 0x1000 /* FSMC Register */
- 0xd2000000 0x4000>; /* NAND Base */
- reg-names = "fsmc_regs", "nand_data";
- st,ale-off = <0x20000>;
- st,cle-off = <0x10000>;
+ 0xd2000000 0x0010 /* NAND Base DATA */
+ 0xd2020000 0x0010 /* NAND Base ADDR */
+ 0xd2010000 0x0010>; /* NAND Base CMD */
+ reg-names = "fsmc_regs", "nand_data", "nand_addr", "nand_cmd";
status = "disabled";
};
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index ef6f602..527bcc2 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -252,6 +252,18 @@ static struct resource rtc_resources[] = {
*/
static struct resource fsmc_resources[] = {
{
+ .name = "nand_addr",
+ .start = U300_NAND_CS0_PHYS_BASE + PLAT_NAND_ALE,
+ .end = U300_NAND_CS0_PHYS_BASE + PLAT_NAND_ALE + SZ_16K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .name = "nand_cmd",
+ .start = U300_NAND_CS0_PHYS_BASE + PLAT_NAND_CLE,
+ .end = U300_NAND_CS0_PHYS_BASE + PLAT_NAND_CLE + SZ_16K - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ {
.name = "nand_data",
.start = U300_NAND_CS0_PHYS_BASE,
.end = U300_NAND_CS0_PHYS_BASE + SZ_16K - 1,
@@ -1496,8 +1508,6 @@ static struct fsmc_nand_platform_data nand_platform_data = {
.nr_partitions = ARRAY_SIZE(u300_partitions),
.options = NAND_SKIP_BBTSCAN,
.width = FSMC_NAND_BW8,
- .ale_off = PLAT_NAND_ALE,
- .cle_off = PLAT_NAND_CLE,
};
static struct platform_device nand_device = {
diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index 38d2624..cb86450 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
@@ -876,8 +876,6 @@ static int __devinit fsmc_nand_probe_config_dt(struct platform_device *pdev,
return -EINVAL;
}
}
- of_property_read_u32(np, "st,ale-off", &pdata->ale_off);
- of_property_read_u32(np, "st,cle-off", &pdata->cle_off);
if (of_get_property(np, "nand-skip-bbtscan", NULL))
pdata->options = NAND_SKIP_BBTSCAN;
@@ -935,41 +933,28 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
if (!res)
return -EINVAL;
- if (!devm_request_mem_region(&pdev->dev, res->start, resource_size(res),
- pdev->name)) {
- dev_err(&pdev->dev, "Failed to get memory data resourse\n");
- return -ENOENT;
- }
-
- host->data_pa = (dma_addr_t)res->start;
- host->data_va = devm_ioremap(&pdev->dev, res->start,
- resource_size(res));
+ host->data_va = devm_request_and_ioremap(&pdev->dev, res);
if (!host->data_va) {
dev_err(&pdev->dev, "data ioremap failed\n");
return -ENOMEM;
}
+ host->data_pa = (dma_addr_t)res->start;
- if (!devm_request_mem_region(&pdev->dev, res->start + pdata->ale_off,
- resource_size(res), pdev->name)) {
- dev_err(&pdev->dev, "Failed to get memory ale resourse\n");
- return -ENOENT;
- }
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_addr");
+ if (!res)
+ return -EINVAL;
- host->addr_va = devm_ioremap(&pdev->dev, res->start + pdata->ale_off,
- resource_size(res));
+ host->addr_va = devm_request_and_ioremap(&pdev->dev, res);
if (!host->addr_va) {
dev_err(&pdev->dev, "ale ioremap failed\n");
return -ENOMEM;
}
- if (!devm_request_mem_region(&pdev->dev, res->start + pdata->cle_off,
- resource_size(res), pdev->name)) {
- dev_err(&pdev->dev, "Failed to get memory cle resourse\n");
- return -ENOENT;
- }
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_cmd");
+ if (!res)
+ return -EINVAL;
- host->cmd_va = devm_ioremap(&pdev->dev, res->start + pdata->cle_off,
- resource_size(res));
+ host->cmd_va = devm_request_and_ioremap(&pdev->dev, res);
if (!host->cmd_va) {
dev_err(&pdev->dev, "ale ioremap failed\n");
return -ENOMEM;
@@ -979,14 +964,7 @@ static int __init fsmc_nand_probe(struct platform_device *pdev)
if (!res)
return -EINVAL;
- if (!devm_request_mem_region(&pdev->dev, res->start, resource_size(res),
- pdev->name)) {
- dev_err(&pdev->dev, "Failed to get memory regs resourse\n");
- return -ENOENT;
- }
-
- host->regs_va = devm_ioremap(&pdev->dev, res->start,
- resource_size(res));
+ host->regs_va = devm_request_and_ioremap(&pdev->dev, res);
if (!host->regs_va) {
dev_err(&pdev->dev, "regs ioremap failed\n");
return -ENOMEM;
diff --git a/include/linux/mtd/fsmc.h b/include/linux/mtd/fsmc.h
index b200292..d6ed61e 100644
--- a/include/linux/mtd/fsmc.h
+++ b/include/linux/mtd/fsmc.h
@@ -155,9 +155,6 @@ struct fsmc_nand_platform_data {
unsigned int width;
unsigned int bank;
- /* CLE, ALE offsets */
- unsigned int cle_off;
- unsigned int ale_off;
enum access_mode mode;
void (*select_bank)(uint32_t bank, uint32_t busw);
--
1.7.10.4
^ permalink raw reply related
* [PATCH] serial: i.MX: evaluate linux,stdout-path property
From: Sascha Hauer @ 2012-10-04 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506D84BD.5010000@gmail.com>
On Thu, Oct 04, 2012 at 07:44:45AM -0500, Rob Herring wrote:
> On 10/04/2012 05:39 AM, Sascha Hauer wrote:
> > devicetrees may have the linux,stdout-path property to specify the
> > console. This patch adds support to the i.MX serial driver for this.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> >
> > I was originally looking for a more generic way to handle this, but
> > since a struct console has no device associated to it, it's not
> > possible to match a console with a device in a generic way. So we
>
> Could we add a device ptr to struct console?
I think not. Looking at some drivers they register a console very early
when there is no device available (even if there will be a device later
when the uart driver probes)
> > #ifdef CONFIG_OF
> > /*
> > + * Check if this device matches the linux,stdout-path property
> > + * in the chosen node. return true if yes, false otherwise
> > + */
> > +static int serial_imx_is_stdoutpath(struct platform_device *pdev)
>
> Couldn't this function be generic? Just move
> IS_ENABLED(CONFIG_SERIAL_IMX_CONSOLE) outside this function. Arguably,
> the presence of the property or not could replace the config option all
> together.
>
> And use a struct device so this can work with devices other than
> platform devices (i.e. amba).
Ok, makes sense.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v3 0/6] uio_pruss cleanup and platform support
From: Matt Porter @ 2012-10-04 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506D8720.8040004@ti.com>
On Thu, Oct 04, 2012 at 06:24:56PM +0530, Sekhar Nori wrote:
> On 10/4/2012 6:12 PM, Matt Porter wrote:
> > On Thu, Oct 04, 2012 at 11:11:45AM +0200, Philipp Zabel wrote:
> >> Hi Matt,
> >>
> >> On 10/3/12, Matt Porter <mporter@ti.com> wrote:
> >>> This series enables uio_pruss on DA850 and removes use of the
> >>> private SRAM API by the driver. The driver previously was not
> >>> enabled by any platform and the private SRAM API was accessing
> >>> an invalid SRAM bank.
> >>
> >> have you seen my SRAM patch series at https://lkml.org/lkml/2012/9/7/281
> >> "Add device tree support for on-chip SRAM" ?
> >
> > Yes.
> >
> >> I think the generic SRAM/genalloc driver (https://lkml.org/lkml/2012/9/7/282)
> >> could be useful to map the L3RAM on Davinci.
> >> With the gen_pool lookup patch (https://lkml.org/lkml/2012/9/7/284) the
> >> uio_pruss driver could then use the gen_pool_find_by_phys() (or
> >> of_get_named_gen_pool() for initialization from device tree) to
> >> retrieve the struct gen_pool*.
> >>
> >> This way you could avoid handing it over via platform data and you could
> >> get rid of arch/arm/mach-davinci/{sram.c,include/mach/sram.h} completely.
> >
> > I did miss the gen_pool_find_by_phys() call in that series. That does
> > look useful. I actually mentioned your series in an earlier posting
> > since I like it, but since the initialization of the driver was inherently
> > tied to DT it's not usable for DaVinci that's just starting to convert
> > to DT and needs !DT support as well.
> >
> > I do see it moving to your driver exclusively, but I wanted to make this
> > series focused on only getting rid of the private SRAM API using the
> > existing pdata framework that's already there. I think once
> > gen_pool_find_by_phys() goes upstream we can switch to that and get the
> > address from a resource in the !DT case. I guess we should see if Sekhar
> > would like to see this happen in two steps or just have us depend on
> > the gen_pool_find_by_phys() patch now.
>
> I prefer going with this series now and switching to the SRAM driver
> once it is available mainline.
Ok, thanks. In that case, I'll also plan to keep the davinci-pcm series
using the same approach for now too.
-Matt
^ permalink raw reply
* [PATCH v3 5/6] ARM: davinci: Add support for PRUSS on DA850
From: Matt Porter @ 2012-10-04 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <506D7F95.2030401@ti.com>
On Thu, Oct 04, 2012 at 05:52:45PM +0530, Sekhar Nori wrote:
> On 10/3/2012 8:25 PM, Matt Porter wrote:
> > Adds PRUSS clock, registers the L3RAM pool, and registers the
> > platform device for uio_pruss on DA850.
> >
> > Signed-off-by: Matt Porter <mporter@ti.com>
>
> I am interested in knowing how this patch was tested.
I'll add similar test information in the commit that I mention in
my other reply. Basically, I use the examples in the PRU package
downloadable from ti.com. There's a PRU_memAccessL3andDDR example
which will fail miserably if the uio_pruss driver SRAM resource
is not configured properly. With the complete series in place, it's
able to complete execution successfully, communicating via the
shared sram pool.
> > ---
> > arch/arm/mach-davinci/board-da850-evm.c | 12 +++++
> > arch/arm/mach-davinci/da850.c | 7 +++
> > arch/arm/mach-davinci/devices-da8xx.c | 66 ++++++++++++++++++++++++++++
> > arch/arm/mach-davinci/include/mach/da8xx.h | 2 +
> > 4 files changed, 87 insertions(+)
> >
> > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
> > index 1295e61..acc6e84 100644
> > --- a/arch/arm/mach-davinci/board-da850-evm.c
> > +++ b/arch/arm/mach-davinci/board-da850-evm.c
> > @@ -29,6 +29,7 @@
> > #include <linux/regulator/machine.h>
> > #include <linux/regulator/tps6507x.h>
> > #include <linux/input/tps6507x-ts.h>
> > +#include <linux/platform_data/uio_pruss.h>
> > #include <linux/spi/spi.h>
> > #include <linux/spi/flash.h>
> > #include <linux/delay.h>
> > @@ -42,6 +43,7 @@
> > #include <mach/da8xx.h>
> > #include <linux/platform_data/mtd-davinci.h>
> > #include <mach/mux.h>
> > +#include <mach/sram.h>
> > #include <linux/platform_data/mtd-davinci-aemif.h>
> > #include <linux/platform_data/spi-davinci.h>
>
> I know you did not introduce the mess, but can you include a patch to
> fix the mixture of mach/ and linux/ includes here? mach/ includes should
> follow the linux/ includes.
Ok. Yeah, I agree it's a mess there.
> > @@ -1253,6 +1255,10 @@ static __init int da850_wl12xx_init(void)
> >
> > #endif /* CONFIG_DA850_WL12XX */
> >
> > +struct uio_pruss_pdata da8xx_pruss_uio_pdata = {
> > + .pintc_base = 0x4000,
> > +};
> > +
> > #define DA850EVM_SATA_REFCLKPN_RATE (100 * 1000 * 1000)
> >
> > static __init void da850_evm_init(void)
> > @@ -1339,6 +1345,12 @@ static __init void da850_evm_init(void)
> > pr_warning("da850_evm_init: lcdcntl mux setup failed: %d\n",
> > ret);
> >
> > + da8xx_pruss_uio_pdata.l3ram_pool = sram_get_gen_pool();
>
> I wonder if this platform data should still be called l3ram pool. L3RAM
> is OMAP terminology. May be just call it sram_pool? Also this patch
> should follow 6/6 to prevent build breakage.
I agree, I'll change to sram_pool. I went back and forth on this because
I found even the userspace PRU tools had it called L3...I think it's
wise just say sram and avoid confusion. I'll move the patch too.
> > + ret = da8xx_register_pruss_uio(&da8xx_pruss_uio_pdata);
> > + if (ret)
> > + pr_warning("pruss_uio initialization failed: %d\n",
> > + ret);
> > +
> > /* Handle board specific muxing for LCD here */
> > ret = davinci_cfg_reg_list(da850_evm_lcdc_pins);
> > if (ret)
> > diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
> > index d8d69de..7c01d31 100644
> > --- a/arch/arm/mach-davinci/da850.c
> > +++ b/arch/arm/mach-davinci/da850.c
>
> Can you separate out board and SoC changes into different patches?
Ok, yes.
> > @@ -212,6 +212,12 @@ static struct clk tptc2_clk = {
> > .flags = ALWAYS_ENABLED,
> > };
> >
> > +static struct clk pruss_clk = {
> > + .name = "pruss",
> > + .parent = &pll0_sysclk2,
> > + .lpsc = DA8XX_LPSC0_PRUSS,
> > +};
> > +
> > static struct clk uart0_clk = {
> > .name = "uart0",
> > .parent = &pll0_sysclk2,
> > @@ -378,6 +384,7 @@ static struct clk_lookup da850_clks[] = {
> > CLK(NULL, "tptc1", &tptc1_clk),
> > CLK(NULL, "tpcc1", &tpcc1_clk),
> > CLK(NULL, "tptc2", &tptc2_clk),
> > + CLK(NULL, "pruss", &pruss_clk),
>
> This is actually incorrect since we should use device name rather than
> con_id for matching the clock. If there is just one clock that the
> driver needs, connection id should be NULL. Looking at the driver now,
> the clk_get() call seems to pass a valid device pointer. So, I wonder
> how you are able to look up the clock even with a NULL device name.
Hrm, I'll look into this. This part was a not looked at closely, just a
quick copy/paste/modify and worked as tested with the PRU examples so
I didn't look further. I'll look again let you know why it actually works.
I'm guessing I got lucky here, and should be a simple fix.
> > CLK(NULL, "uart0", &uart0_clk),
> > CLK(NULL, "uart1", &uart1_clk),
> > CLK(NULL, "uart2", &uart2_clk),
> > diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
> > index bd2f72b..7c2e0d2 100644
> > --- a/arch/arm/mach-davinci/devices-da8xx.c
> > +++ b/arch/arm/mach-davinci/devices-da8xx.c
> > @@ -518,6 +518,72 @@ void __init da8xx_register_mcasp(int id, struct snd_platform_data *pdata)
> > }
> > }
> >
> > +#define DA8XX_PRUSS_MEM_BASE 0x01C30000
>
> In this file all base addresses are added at the top of the file. The
> defines are sorted in ascending order of address. If that's broken, its
> all my fault, but please don't add to the breakage when adding this entry :)
Ok :) Will fix.
> > +
> > +static struct resource da8xx_pruss_resources[] = {
> > + {
> > + .start = DA8XX_PRUSS_MEM_BASE,
> > + .end = DA8XX_PRUSS_MEM_BASE + 0xFFFF,
> > + .flags = IORESOURCE_MEM,
> > + },
> > + {
> > + .start = IRQ_DA8XX_EVTOUT0,
> > + .end = IRQ_DA8XX_EVTOUT0,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + {
> > + .start = IRQ_DA8XX_EVTOUT1,
> > + .end = IRQ_DA8XX_EVTOUT1,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + {
> > + .start = IRQ_DA8XX_EVTOUT2,
> > + .end = IRQ_DA8XX_EVTOUT2,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + {
> > + .start = IRQ_DA8XX_EVTOUT3,
> > + .end = IRQ_DA8XX_EVTOUT3,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + {
> > + .start = IRQ_DA8XX_EVTOUT4,
> > + .end = IRQ_DA8XX_EVTOUT4,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + {
> > + .start = IRQ_DA8XX_EVTOUT5,
> > + .end = IRQ_DA8XX_EVTOUT5,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + {
> > + .start = IRQ_DA8XX_EVTOUT6,
> > + .end = IRQ_DA8XX_EVTOUT6,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + {
> > + .start = IRQ_DA8XX_EVTOUT7,
> > + .end = IRQ_DA8XX_EVTOUT7,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > +};
> > +
> > +static struct platform_device da8xx_pruss_uio_dev = {
> > + .name = "pruss_uio",
> > + .id = -1,
> > + .num_resources = ARRAY_SIZE(da8xx_pruss_resources),
> > + .resource = da8xx_pruss_resources,
> > + .dev = {
> > + .coherent_dma_mask = 0xffffffff,
>
> DMA_BIT_MASK(32)?
Yeah, more copy/paste/modify stuff. I'll fix that.
-Matt
^ permalink raw reply
* [PATCH] ARM: Push selects for TWD/SCU into machine entries
From: Rob Herring @ 2012-10-04 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349340644-13937-1-git-send-email-sboyd@codeaurora.org>
On 10/04/2012 03:50 AM, 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.
I think this is the wrong direction as I'd like to see the platform
selects shrink. I believe the local timers are run-time enabled now, so
can't we just drop the condition and always select TWD and SCU for
multi-platform?
Or perhaps we need a CortexA9 config symbol that selects V7, GIC, TWD,
SCU, SMP, PL310, errata, etc. rather than duplicating those for every
platform.
Rob
> 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.
>
> arch/arm/Kconfig | 8 ++++++--
> arch/arm/mach-exynos/Kconfig | 2 ++
> arch/arm/mach-highbank/Kconfig | 1 +
> arch/arm/mach-imx/Kconfig | 2 ++
> arch/arm/mach-msm/Kconfig | 7 ++-----
> arch/arm/mach-omap2/Kconfig | 4 ++++
> arch/arm/mach-realview/Kconfig | 8 ++++++++
> arch/arm/mach-vexpress/Kconfig | 2 ++
> arch/arm/plat-spear/Kconfig | 2 ++
> 9 files changed, 29 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index e85f2b6..303ce90 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -639,6 +639,8 @@ config ARCH_TEGRA
> select GENERIC_GPIO
> select HAVE_CLK
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select MIGHT_HAVE_CACHE_L2X0
> select ARCH_HAS_CPUFREQ
> select USE_OF
> @@ -686,6 +688,8 @@ config ARCH_SHMOBILE
> select CLKDEV_LOOKUP
> select HAVE_MACH_CLKDEV
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select GENERIC_CLOCKEVENTS
> select MIGHT_HAVE_CACHE_L2X0
> select NO_IOPORT
> @@ -882,6 +886,8 @@ config ARCH_U8500
> select ARCH_REQUIRE_GPIOLIB
> select ARCH_HAS_CPUFREQ
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select MIGHT_HAVE_CACHE_L2X0
> help
> Support for ST-Ericsson's Ux500 architecture
> @@ -1507,7 +1513,6 @@ config SMP
> depends on HAVE_SMP
> depends on MMU
> select USE_GENERIC_SMP_HELPERS
> - select HAVE_ARM_SCU if !ARCH_MSM_SCORPIONMP
> help
> This enables support for systems with more than one CPU. If you have
> a system with only one CPU, like most personal computers, say N. If
> @@ -1620,7 +1625,6 @@ config LOCAL_TIMERS
> bool "Use local timer interrupts"
> depends on SMP
> default y
> - select HAVE_ARM_TWD if (!ARCH_MSM_SCORPIONMP && !EXYNOS4_MCT)
> help
> Enable support for local timers on SMP platforms, rather then the
> legacy IPI broadcast method. Local timers allows the system
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 4372075..8f97e92 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -15,6 +15,7 @@ config ARCH_EXYNOS4
> bool "SAMSUNG EXYNOS4"
> default y
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> select MIGHT_HAVE_CACHE_L2X0
> help
> Samsung EXYNOS4 SoCs based systems
> @@ -22,6 +23,7 @@ config ARCH_EXYNOS4
> config ARCH_EXYNOS5
> bool "SAMSUNG EXYNOS5"
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> help
> Samsung EXYNOS5 (Cortex-A15) SoC based systems
>
> diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
> index 0e1d0a4..f1ad1f0 100644
> --- a/arch/arm/mach-highbank/Kconfig
> +++ b/arch/arm/mach-highbank/Kconfig
> @@ -11,5 +11,6 @@ config ARCH_HIGHBANK
> select GENERIC_CLOCKEVENTS
> select HAVE_ARM_SCU
> select HAVE_SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select SPARSE_IRQ
> select USE_OF
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 519ed57..13f765c 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -759,6 +759,8 @@ config SOC_IMX6Q
> select HAVE_IMX_MMDC
> select HAVE_IMX_SRC
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select MFD_SYSCON
> select PINCTRL
> select PINCTRL_IMX6Q
> diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
> index 7902de15..5bff882 100644
> --- a/arch/arm/mach-msm/Kconfig
> +++ b/arch/arm/mach-msm/Kconfig
> @@ -44,7 +44,7 @@ endchoice
>
> config ARCH_MSM8X60
> bool "MSM8X60"
> - select ARCH_MSM_SCORPIONMP
> + select HAVE_SMP
> select ARM_GIC
> select CPU_V7
> select MSM_V2_TLMM
> @@ -55,7 +55,7 @@ config ARCH_MSM8X60
>
> config ARCH_MSM8960
> bool "MSM8960"
> - select ARCH_MSM_SCORPIONMP
> + select HAVE_SMP
> select ARM_GIC
> select CPU_V7
> select MSM_V2_TLMM
> @@ -68,9 +68,6 @@ config MSM_HAS_DEBUG_UART_HS
>
> config MSM_SOC_REV_A
> bool
> -config ARCH_MSM_SCORPIONMP
> - bool
> - select HAVE_SMP
>
> config ARCH_MSM_ARM11
> bool
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index a6219ea..b618748 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -58,7 +58,9 @@ config ARCH_OMAP4
> select CPU_V7
> select ARM_GIC
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> select LOCAL_TIMERS if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select PL310_ERRATA_588369
> select PL310_ERRATA_727915
> select ARM_ERRATA_720789
> @@ -75,6 +77,8 @@ config SOC_OMAP5
> select CPU_V7
> select ARM_GIC
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select ARM_CPU_SUSPEND if PM
> select SOC_HAS_REALTIME_COUNTER
> select ARM_ARCH_TIMER
> diff --git a/arch/arm/mach-realview/Kconfig b/arch/arm/mach-realview/Kconfig
> index c593be4..0c019b7 100644
> --- a/arch/arm/mach-realview/Kconfig
> +++ b/arch/arm/mach-realview/Kconfig
> @@ -13,6 +13,8 @@ config REALVIEW_EB_A9MP
> depends on MACH_REALVIEW_EB
> select CPU_V7
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select MIGHT_HAVE_CACHE_L2X0
> help
> Enable support for the Cortex-A9MPCore tile fitted to the
> @@ -24,6 +26,8 @@ config REALVIEW_EB_ARM11MP
> select CPU_V6K
> select ARCH_HAS_BARRIERS if SMP
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select MIGHT_HAVE_CACHE_L2X0
> help
> Enable support for the ARM11MPCore tile fitted to the Realview(R)
> @@ -44,6 +48,8 @@ config MACH_REALVIEW_PB11MP
> select ARM_GIC
> select HAVE_PATA_PLATFORM
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select MIGHT_HAVE_CACHE_L2X0
> select ARCH_HAS_BARRIERS if SMP
> help
> @@ -86,6 +92,8 @@ config MACH_REALVIEW_PBX
> select ARM_GIC
> select HAVE_PATA_PLATFORM
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select MIGHT_HAVE_CACHE_L2X0
> select ARCH_SPARSEMEM_ENABLE if CPU_V7 && !REALVIEW_HIGH_PHYS_OFFSET
> select ZONE_DMA if SPARSEMEM
> diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> index c952960..4f8e0db 100644
> --- a/arch/arm/mach-vexpress/Kconfig
> +++ b/arch/arm/mach-vexpress/Kconfig
> @@ -11,6 +11,8 @@ config ARCH_VEXPRESS
> select HAVE_CLK
> select HAVE_PATA_PLATFORM
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select ICST
> select MIGHT_HAVE_CACHE_L2X0
> select NO_IOPORT
> diff --git a/arch/arm/plat-spear/Kconfig b/arch/arm/plat-spear/Kconfig
> index 4404f82..a090ea3 100644
> --- a/arch/arm/plat-spear/Kconfig
> +++ b/arch/arm/plat-spear/Kconfig
> @@ -14,6 +14,8 @@ config ARCH_SPEAR13XX
> select CPU_V7
> select USE_OF
> select HAVE_SMP
> + select HAVE_ARM_SCU if SMP
> + select HAVE_ARM_TWD if LOCAL_TIMERS
> select MIGHT_HAVE_CACHE_L2X0
> select PINCTRL
> help
>
^ permalink raw reply
* [PATCH 06/15] KVM: ARM: Initial skeleton to compile KVM support
From: Min-gyu Kim @ 2012-10-04 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANM98qKidvG_sOHM197F+1EDtEFTGnLksCJo=12T36JE3u6R4w@mail.gmail.com>
> -----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:
> >> On 09/25/2012 11:20 AM, Will Deacon wrote:
> >> >> +/* Multiprocessor Affinity Register */
> >> >> +#define MPIDR_CPUID (0x3 << 0)
> >> >
> >> > I'm fairly sure we already have code under arch/arm/ for dealing
> >> > with the mpidr. Let's re-use that rather than reinventing it here.
> >> >
> >>
> >> I see some defines in topology.c - do you want some of these factored
> >> out into a header file that we can then also use from kvm? If so,
where?
> >
> > I guess either in topology.h or a new header (topology-bits.h).
> >
> >> >> +#define EXCEPTION_NONE 0
> >> >> +#define EXCEPTION_RESET 0x80
> >> >> +#define EXCEPTION_UNDEFINED 0x40
> >> >> +#define EXCEPTION_SOFTWARE 0x20
> >> >> +#define EXCEPTION_PREFETCH 0x10
> >> >> +#define EXCEPTION_DATA 0x08
> >> >> +#define EXCEPTION_IMPRECISE 0x04
> >> >> +#define EXCEPTION_IRQ 0x02
> >> >> +#define EXCEPTION_FIQ 0x01
> >> >
> >> > Why the noise?
> >> >
> >>
> >> these are simply cruft from a previous life of KVM/ARM.
> >
> > Ok, then please get rid of them.
> >
> >> >> +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.
>From the code above, BUG_ON case clearly points out that there happened a
serious bug case. However, killing the corresponding VM may not cause any
further problem.
Then leave some logs for debugging and killing the VM seems to be enough.
Let's assume KVM for ARM is distributed with a critical bug.
If the case is defended by BUG_ON, it will cause host to shutdown.
If the case is defended by killing VM, it will cause VM to shutdown.
In my opinion, latter case seems to be better.
I looked for a guide on BUG_ON and found this:
http://yarchive.net/comp/linux/BUG.html
> >> >
> >> >> +static inline u32 *vcpu_pc(struct kvm_vcpu *vcpu) {
> >> >> + return vcpu_reg(vcpu, 15); }
> >> >
> >> > If you stick a struct pt_regs into struct kvm_regs, you could reuse
> >> > ARM_pc here etc.
> >> >
> >>
> >> I prefer not to, because we'd have those registers presumably for usr
> >> mode and then we only define the others explicit. I think it's much
> >> clearer to look at kvm_regs today.
> >
> > I disagree and think that you should reuse as much of the arch/arm/
> > code as possible. Not only does it make it easier to read by people
> > who are familiar with that code (and in turn get you more reviewers)
> > but it also means that we limit the amount of duplication that we have.
>
> Reusing a struct just for the sake of reusing is not necessarily an
> improvement. Some times it complicates things, and some times it's
> misleading. To me, pt_regs carry the meaning that these are the registers
> for a user space process that traps into the kernel - in KVM we emulate a
> virtual CPU and that current definition is quite clear.
>
> The argument that more people will review the code if the struct contains
> a pt_regs field rather than a usr_regs field is completely invalid,
> because I'm sure everyone that reviews virtualization code will know that
> user mode is a mode on the cpu and it has some registers and this is the
> state we store when we context switch a VM - pt_regs could be read as the
> regs that we stored in the mode that the VM happened to be in when we took
> an exception, which I would think is crazy, and probably not what you
> suggest.
>
> Writing the literal 15 for the PC register is not really a problem in
> terms of duplication - it's nothing that requires separate maintenance.
>
> At this point the priority should really be correctness, readability, and
> performance, imho.
>
> >
> > I think Marc (CC'd) had a go at this with some success.
> >
>
> great, if this improves the code, then I suggest someone rebases an
> appropriate patch and sends it to the kvmarm mailing list so we can have a
> look at it, but there are users out there looking to try kvm/arm and we
> should try to give it to them.
>
> >> >> +#ifndef __ARM_KVM_HOST_H__
> >> >> +#define __ARM_KVM_HOST_H__
> >> >> +
> >> >> +#include <asm/kvm.h>
> >> >> +
> >> >> +#define KVM_MAX_VCPUS 4
> >> >
> >> > NR_CPUS?
> >> >
> >>
> >> well this is defined by KVM generic code, and is common for other
> >> architecture.
> >
> > I mean #define KVM_MAX_CPUS NR_CPUS. The 4 seems arbitrary.
> >
> >> >> +int __attribute_const__ kvm_target_cpu(void) {
> >> >> + unsigned int midr;
> >> >> +
> >> >> + midr = read_cpuid_id();
> >> >> + switch ((midr >> 4) & 0xfff) {
> >> >> + case KVM_ARM_TARGET_CORTEX_A15:
> >> >> + return KVM_ARM_TARGET_CORTEX_A15;
> >> >
> >> > I have this code already in perf_event.c. Can we move it somewhere
> >> > common and share it? You should also check that the implementor field
> is 0x41.
> >> >
> >>
> >> by all means, you can probably suggest a good place better than I
can...
> >
> > cputype.h?
> >
> >> >> +#include <linux/module.h>
> >> >> +
> >> >> +EXPORT_SYMBOL_GPL(smp_send_reschedule);
> >> >
> >> > Erm...
> >> >
> >> > We already have arch/arm/kernel/armksyms.c for exports -- please use
> that.
> >> > However, exporting such low-level operations sounds like a bad
> >> > idea. How realistic is kvm-as-a-module on ARM anyway?
> >> >
> >>
> >> at this point it's broken, so I'll just remove this and leave this
> >> for a fun project for some poor soul at some point if anyone ever
> >> needs half the code outside the kernel as a module (the other half
> >> needs to be compiled in anyway)
> >
> > Ok, that suits me. If it's broken, let's not include it in the initial
> > submission.
> >
> >> >> +int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct
> >> >> +kvm_regs *regs) {
> >> >> + return -EINVAL;
> >> >> +}
> >> >> +
> >> >> +int kvm_arch_vcpu_ioctl_set_regs(struct kvm_vcpu *vcpu, struct
> >> >> +kvm_regs *regs) {
> >> >> + return -EINVAL;
> >> >> +}
> >> >
> >> > Again, all looks like this should be implemented using regsets from
> >> > what I can tell.
> >> >
> >>
> >> this API has been discussed to death on the KVM lists, and we can of
> >> course revive that if the regset makes it nicer - I'd prefer getting
> >> this upstream the way that it is now though, where GET_REG / SET_REG
> >> seems to be the way forward from a KVM perspective.
> >
> > I'm sure the API has been discussed, but I've not seen that
> > conversation and I'm also not aware about whether or not regsets were
> > considered as a possibility for this stuff. The advantages of using them
> are:
> >
> > 1. It's less code for the arch to implement (and most of what
you
> > need, you already have).
> >
> > 2. You can move the actual copying code into core KVM, like we
> have
> > for ptrace.
> >
> > 3. New KVM ports (e.g. arm64) can reuse the core copying code
> > easily.
> >
> > Furthermore, some registers (typically) floating point and GPRs will
> > already have regsets for the ptrace code, so that can be reused if you
> > share the datatypes.
> >
> > The big problem with getting things upstream and then changing it
> > later is that you will break the ABI. I highly doubt that's feasible,
> > so can we not just use regsets from the start for ARM?
> >
> >> >> +int kvm_reset_vcpu(struct kvm_vcpu *vcpu) {
> >> >> + struct kvm_regs *cpu_reset;
> >> >> +
> >> >> + switch (vcpu->arch.target) {
> >> >> + case KVM_ARM_TARGET_CORTEX_A15:
> >> >> + if (vcpu->vcpu_id > a15_max_cpu_idx)
> >> >> + return -EINVAL;
> >> >> + cpu_reset = &a15_regs_reset;
> >> >> + vcpu->arch.midr = read_cpuid_id();
> >> >> + break;
> >> >> + default:
> >> >> + return -ENODEV;
> >> >> + }
> >> >> +
> >> >> + /* Reset core registers */
> >> >> + memcpy(&vcpu->arch.regs, cpu_reset,
> >> >> + sizeof(vcpu->arch.regs));
> >> >> +
> >> >> + /* Reset CP15 registers */
> >> >> + kvm_reset_coprocs(vcpu);
> >> >> +
> >> >> + return 0;
> >> >> +}
> >> >
> >> > This is a nice way to plug in new CPUs but the way the rest of the
> >> > code is currently written, all the ARMv7 and Cortex-A15 code is
> >> > merged together. I
> >> > *strongly* suggest you isolate this from the start, as it will help
> >> > you see what is architected and what is implementation-specific.
> >> >
> >>
> >> not entirely sure what you mean. You want a separate coproc.c file
> >> for
> >> Cortex-A15 specific stuff like coproc_a15.c?
> >
> > Indeed. I think it will make adding new CPUs a lot clearer and
> > separate the architecture from the implementation.
> >
> > Cheers,
> >
> > Will
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in the body
> of a message to majordomo at vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/7] Add support for Freescale's mc34708 to mc13xxx driver
From: Fabio Estevam @ 2012-10-04 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5AVP1L-6A7cmV-kQEfG1C+vczFKT=sQbFtLJDaGau0kRg@mail.gmail.com>
Hi Samuel,
On Wed, Sep 5, 2012 at 11:22 AM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Samuel,
>
> On Thu, Jul 12, 2012 at 8:02 PM, Marc Reilly <marc@cpdesign.com.au> wrote:
>> Hi Uwe,
>>
>>> This series was tested on a Phytec pcm038 (mc13783 on spi) using
>>> traditional boot (i.e. not dt) and on a i.MX53 based machine (mc34708 on
>>> i2c) using dt boot.
>>>
>>> Philippe's patches are already in next, they are just included here for
>>> those who want to test the patches. The 'mfd/mc13xxx: drop modifying
>>> driver's id_table in probe' was already sent out yesterday and is
>>> included here because the last patch depends on it.
>>>
>>
>> For all patches (that don't already have it):
>> Acked-by: Marc Reilly <marc@cpdesign.com.au>
>
> Can this series be applied?
Any comments on this series, please?
I want to add mc34708 support to mx53qsb and need this series to be applied.
^ 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