[PATCH v4 2/2] usb: musb: dsps, use devm_kzalloc
Replace kzalloc by devm_kzalloc and remove the kfree() calls.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/usb/musb/musb_dsps.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index d0a97d6..6cae0c8 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -668,7 +668,7 @@ static int dsps_probe(struct platform_device *pdev)
wrp = match-data;
/* allocate glue */
- glue = kzalloc(sizeof(*glue), GFP_KERNEL);
+ glue = devm_kzalloc(pdev-dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
dev_err(pdev-dev, unable to allocate glue memory\n);
return -ENOMEM;
@@ -696,7 +696,6 @@ err3:
pm_runtime_put(pdev-dev);
err2:
pm_runtime_disable(pdev-dev);
- kfree(glue);
return ret;
}
@@ -709,7 +708,6 @@ static int dsps_remove(struct platform_device *pdev)
/* disable usbss clocks */
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
- kfree(glue);
debugfs_remove_recursive(glue-dbgfs_root);
--
1.8.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] usb: musb: dsps, debugfs files
debugfs files to show the contents of important dsps registers.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/usb/musb/musb_dsps.c | 54
1 file changed, 54 insertions(+)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 593d3c9..d0a97d6 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -46,6 +46,8 @@
#include linux/of_irq.h
#include linux/usb/of.h
+#include linux/debugfs.h
+
#include musb_core.h
static const struct of_device_id musb_dsps_of_match[];
@@ -137,6 +139,26 @@ struct dsps_glue {
unsigned long last_timer;/* last timer data for each instance */
struct dsps_context context;
+ struct debugfs_regset32 regset;
+ struct dentry *dbgfs_root;
+};
+
+static const struct debugfs_reg32 dsps_musb_regs[] = {
+ { revision, 0x00 },
+ { control,0x14 },
+ { status, 0x18 },
+ { eoi,0x24 },
+ { intr0_stat, 0x30 },
+ { intr1_stat, 0x34 },
+ { intr0_set, 0x38 },
+ { intr1_set, 0x3c },
+ { txmode, 0x70 },
+ { rxmode, 0x74 },
+ { autoreq,0xd0 },
+ { srpfixtime, 0xd4 },
+ { tdown, 0xd8 },
+ { phy_utmi, 0xe0 },
+ { mode, 0xe8 },
};
static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -369,6 +391,30 @@ out:
return ret;
}
+static int dsps_musb_dbg_init(struct musb *musb, struct dsps_glue *glue)
+{
+ struct dentry *root;
+ struct dentry *file;
+ char buf[128];
+
+ sprintf(buf, %s.dsps, dev_name(musb-controller));
+ root = debugfs_create_dir(buf, NULL);
+ if (!root)
+ return -ENOMEM;
+ glue-dbgfs_root = root;
+
+ glue-regset.regs = dsps_musb_regs;
+ glue-regset.nregs = ARRAY_SIZE(dsps_musb_regs);
+ glue-regset.base = musb-ctrl_base;
+
+ file = debugfs_create_regset32(regdump, S_IRUGO, root, glue-regset);
+ if (!file) {
+ debugfs_remove_recursive(root);
+ return -ENOMEM;
+ }
+ return 0;
+}
+
static int dsps_musb_init(struct musb *musb)
{
struct device *dev = musb-controller;
@@ -378,6 +424,7 @@ static int dsps_musb_init(struct musb *musb)
void __iomem *reg_base;
struct resource *r;
u32 rev, val;
+ int ret;
r = platform_get_resource_byname(parent, IORESOURCE_MEM, control);
if (!r)
@@ -411,6 +458,10 @@ static int dsps_musb_init(struct musb *musb)
val = ~(1 wrp-otg_disable);
dsps_writel(musb-ctrl_base, wrp-phy_utmi, val);
+ ret = dsps_musb_dbg_init(musb, glue);
+ if (ret)
+ return ret;
+
return 0;
}
@@ -659,6 +710,9 @@ static int dsps_remove(struct platform_device *pdev)
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
kfree(glue);
+
+ debugfs_remove_recursive(glue-dbgfs_root);
+
return 0;
}
--
1.8.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/2] usb: musb dsps updates
Hi, The two remaining patches from the previous series usb: musb bugfixes. In v4 I used the device name for the debugfs root dir and added a commit message to the second patch. Regards, Markus Markus Pargmann (2): usb: musb: dsps, debugfs files usb: musb: dsps, use devm_kzalloc drivers/usb/musb/musb_dsps.c | 58 +--- 1 file changed, 55 insertions(+), 3 deletions(-) -- 1.8.5.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Issues with GPIO and wake from sleep
I have resisted contacting the list with regards to an issue I am having trying
to get what should be a simple part of my system working but I cannot find any
documentation or other posts to help.
I am using 3.6 kernel but have tried 3.12 to see if the issue has been
addressed in that but its exactly the same.
I am attempting to get a GPIO to wake my AM3517 system up from a suspend to
memory. I have tried with a few different options for GPIO’s
I have available GPIO-10, GPIO-28 and GPIO-30.
I started by using GPIO-28 and that would configure nicely and I set up the
interrupt handler and could see my debug when triggering the input (brilliant)
but for some reason I cannot use it to wake the system as it is not in the
correct group for wakeup. There is a note in the Tech Ref Man -
Only gpio_1, gpio_9, gpio_10, gpio_11, gpio_30, and gpio_31 can be used to
generate a direct wake-up event.
So have to use a different one. GPIO-30 cannot be used as that holds the system
in reset, so all that is left is GPIO-10.
All seems to be good for initialisation;
In the omap_board_mux I define
OMAP3_MUX(SYS_CLKOUT1, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_INPUT_PULLUP | OMAP_PIN_OFF_OUTPUT_LOW |
OMAP_PIN_OFF_WAKEUPENABLE),
Then the init function and interrupt handler;
/
*
* Board wakeup interrupt
*
/
#define IGNITION_GPIO 10
static irqreturn_t detect_irq(int irq, void *_data)
{
printk(%s: irq\n, __func__);
return IRQ_HANDLED;
}
static void enable_board_wakeup_source(void)
{
int irq;
int ret;
/* GPIO_10 interrupt line */
gpio_request(IGNITION_GPIO, gpio_10);
gpio_direction_input(IGNITION_GPIO);
omap_mux_init_gpio(IGNITION_GPIO, OMAP_PIN_INPUT_PULLUP |
OMAP_PIN_OFF_WAKEUPENABLE);
irq = gpio_to_irq(IGNITION_GPIO);
if (request_irq(irq, detect_irq, IRQF_TRIGGER_RISING, ignition,
NULL)) {
pr_err(* %s: request_irq() failed\n, __func__);
return;
}
if (enable_irq_wake(irq)) {
pr_err(* %s: irq_set_irq_wake() failed\n, __func__);
return;
}
pr_err(** %s: set irq %u\n, __func__, irq);
}
But when I try and trigger the input there is no IRQ handled and I also cannot
export the gpio in sys/class/
If I have a look at the mux it seems to be OK
# cd /debug/omap_mux/
# cat sys_clkout1
name: sys_clkout1.gpio_10 (0x48002a1a/0x9ea = 0x411c), b ag25, t NA
mode: OMAP_PIN_INPUT_PULLUP | OMAP_PIN_OFF_WAKEUPENABLE | OMAP_MUX_MODE4
signals: sys_clkout1 | NA | NA | NA | gpio_10 | NA | NA | safe_mode
There is definitely a problem as when I look at the state it says its high,
when the input is definitely 0V
# cat /debug/gpio
GPIOs 0-31, gpio:
gpio-0 (mpu6050-irq ) in lo
gpio-10 (gpio_10 ) in hi
gpio-25 (USB1 PHY reset ) out hi
I think there is something else taking over the pin, maybe the clock setup for
sys_clkout1.
Is there any way to make it just work for my config or make GPIO-28 work to
wake the system ?
Hope you have seen this before.
Kind Regards
Marc--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/18] ARM: dts: omap3-overo: Enable MMC2
Hello Javier On 01/09/2014 09:43 PM, Javier Martinez Canillas wrote: [adding Enric Balletbo to cc] Hello Florian, On Thu, Jan 9, 2014 at 1:48 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: MMC2 is used by the on-board WiFi module populated on some boards (based on Marvell Libertas 8688 SDIO). Note: currently WiFi only works on cold boot, as the module is not properly reset (missing binding for the GPIO reset). Have you looked at commit 0e9fd777 (ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO) ? If I remember correctly the LBEE1USJYC Wifi/BT combo module is basically a Marvell Libertas 8688 Wlan and Enric got soft reset working too by adding a GPIO property to the regulator for the reset GPIO. Hope it helps, Thank you, I got it working. It is a bit messy, as I have 3 GPIOs (poweron, wifi-reset and bt-reset). As a regulator can control only one GPIO, I had to define 3 regulators, and assigning them to the vmmc, vqmmc, and vmmc_aux. I hope that a better solution will pop-up in this thread [1]. It is a pity that the previous version of the GPIO-reset controller was not merged. Florian [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/294907 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Deadlock in do_page_fault() on ARM (old kernel)
On Wed, Jan 15, 2014 at 08:13:04PM -0500, Alan Ott wrote: So my questions are: 1. Why don't I see a full backtrace beyond the exception stack? It's the same when dump_stack() is called manually. No idea - it looks like you're not using frame pointers, but are using the unwinder. Full backtraces can always be created with frame pointers, it's just that unwinding seems unreliable. I think we do need to see the full backtrace here - from looking at the full state dump, I don't see any sign of the mmap_sem being held except by an attempt to process a fault, and two threads trying to do a sys_mmap_pgoff(). My suspicion therefore is that some other thread must have died while holding the mmap_sem, so there's probably a kernel oops earlier... that's my best guess at the moment without seeing the full backtrace. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 00/26] Migrate more OMAP DMA code to DMA engine
On Monday 13 January 2014 07:47 PM, Russell King - ARM Linux wrote: On Fri, Jan 10, 2014 at 05:46:20PM +0530, Sricharan R wrote: I tested this series on DRA7 with mmc peripheral dma and it looked fine. Some how dmaengine test cases were not fine. But that may not have anything to do with this series. I will check more on that and will come back with that results as well. Not fine in what sense? Sorry for delayed response. So in the case of dmaengine test case, it looks for channels with DMA_MEMCPY, DMA_XOR, DMA_PQ capabilities. But the omap-dma device is not registered with MEMCPY capabilities, hence the testcase fails as no channels are available. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Multiple CCR definitions
On Friday 17 January 2014 12:09 AM, Nishanth Menon wrote:
+linux-omap as well.
On Thu, Jan 16, 2014 at 7:07 AM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Tue, Sep 10, 2013 at 11:05 PM, Linux Kernel Mailing List
linux-ker...@vger.kernel.org wrote:
mmc: omap_hsmmc: use the generic config for omap2plus devices
OMAP's hs_mmc driver is used for MMC controller operation on many
omap2plus SoCs (OMAP2430, OMAP3, 4, 5 and AM335x).
Considering that the device tree entries are already present for these,
allow the driver to be built using the config ARCH_OMAP2PLUS rather
than individually adding a config for each SoC to enable the
support.
Use COMPILE_TEST to enable the build for other platforms.
Signed-off-by: Amarinder Bindra a-bin...@ti.com
Cc: Ezequiel Garcia ezequiel.gar...@free-electrons.com
Cc: Nishanth Menon n...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Balaji T K balaj...@ti.com
Signed-off-by: Chris Ball c...@laptop.org
---
drivers/mmc/host/Kconfig |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 84102bc..b8ce939 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -284,11 +284,11 @@ config MMC_OMAP
config MMC_OMAP_HS
tristate TI OMAP High Speed Multimedia Card Interface support
- depends on SOC_OMAP2430 || ARCH_OMAP3 || ARCH_OMAP4
+ depends on ARCH_OMAP2PLUS || COMPILE_TEST
sh-allmodconfig (http://kisskb.ellerman.id.au/kisskb/buildresult/10477672/):
include/linux/omap-dma.h:171:8: error: expected identifier before
numeric constant
make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1
It fails because sh #defines CCR, which is one of the enum values in
include/linux/omap-dma.h.
I expect a similar failure on blackfin, which also has #define CCR.
Possible solutions:
1. Rename CCR in sh/bfin to e.g. SH_CCR resp. BF_CCR.
2. Use depends on ARCH_OMAP2PLUS || (COMPILE_TEST ARM)
omap-dma.h will be needed until all OMAPs are converted to DT only boot.
So depends on ARCH_OMAP2PLUS || (COMPILE_TEST ARM) looks good to me
3. Stop using include/linux/omap-dma.h, as it says:
* Legacy OMAP DMA handling defines and functions
*
* NOTE: Do not use these any longer.
*
* Use the generic dmaengine functions as defined in
* include/linux/dmaengine.h.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/5] wl1251 device tree support
On Fri, Jan 17, 2014 at 02:45:15AM +0100, Sebastian Reichel wrote: On Mon, Jan 06, 2014 at 11:57:09PM +0100, Sebastian Reichel wrote: Hi John, The following patchset adds device tree support to the spi variant of the wl1251 driver. Luciano Coelho (1): wl1251: split wl251 platform data to a separate structure Sebastian Reichel (4): wl1251: move power GPIO handling into the driver wl1251: spi: add vio regulator support wl1251: spi: add device tree support Documentation: dt: wireless: Add wl1251 What's the status of this patchset? Tony prepared an immutable branch for patches 1+2 [0]. I think the other patches are also ok (at least there were no more complains from the DT binding maintainers). It would be nice to have wl1251 DT support in 3.14. [0] http://www.spinics.net/lists/linux-omap/msg101165.html -- Sebastian ping? I can't see it on wireless-next. I can't pull it because the branch is based on a later source than that of wireless-next. -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/18] ARM: dts: omap3-overo: Enable MMC2
Hello Florian, On Fri, Jan 17, 2014 at 10:22 AM, Florian Vaussard florian.vauss...@epfl.ch wrote: Hello Javier On 01/09/2014 09:43 PM, Javier Martinez Canillas wrote: [adding Enric Balletbo to cc] Hello Florian, On Thu, Jan 9, 2014 at 1:48 PM, Florian Vaussard florian.vauss...@epfl.ch wrote: MMC2 is used by the on-board WiFi module populated on some boards (based on Marvell Libertas 8688 SDIO). Note: currently WiFi only works on cold boot, as the module is not properly reset (missing binding for the GPIO reset). Have you looked at commit 0e9fd777 (ARM: dts: omap3-igep: Add support for LBEE1USJYC WiFi connected to SDIO) ? If I remember correctly the LBEE1USJYC Wifi/BT combo module is basically a Marvell Libertas 8688 Wlan and Enric got soft reset working too by adding a GPIO property to the regulator for the reset GPIO. Hope it helps, Thank you, I got it working. It is a bit messy, as I have 3 GPIOs (poweron, wifi-reset and bt-reset). As a regulator can control only one GPIO, I had to define 3 regulators, and assigning them to the vmmc, vqmmc, and vmmc_aux. I hope that a better solution will pop-up in this thread [1]. It is a pity that the previous version of the GPIO-reset controller was not merged. Glad to know that you got it working and yes it is a bit messy so let's hope that a cleaner solution will be the result of the current discussion on that thread. Florian [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/294907 Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM335x USB DMA seems broken on ISOC URBs
On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote: Hello, While doing some experiments with the stk1160 driver (for Easycap TV video capture devices), ran into problems using v3.13-rc4. The problem is that the stk1160 IRQ handler receives no URBs at all. When configuring with CONFIG_MUSB_PIO_ONLY this looks solved, but the bandwidth requirements are too large for PIO (it's a raw video device) and the video can't get captured. Interesting enough, using an old backported for v3.2 stk1160 driver, this same setup works with TI PSP v3.2 kernel. So, I guess it's some software bug in either the cppi41 dmaengine or the musb. I tried to compare the PSP to the mainline drivers but they seems *very* different and really beyond my understanding. Any ideas on how can I help debugging this? Ping? It would be good to hunt thig bug down. The TI PSP provided USB driver works fine so at least that's a starting point... -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issues with GPIO and wake from sleep
* Marc Murphy marcm...@marcm.co.uk [140117 04:32]: I have resisted contacting the list with regards to an issue I am having trying to get what should be a simple part of my system working but I cannot find any documentation or other posts to help. I am using 3.6 kernel but have tried 3.12 to see if the issue has been addressed in that but its exactly the same. I am attempting to get a GPIO to wake my AM3517 system up from a suspend to memory. I have tried with a few different options for GPIO’s I have available GPIO-10, GPIO-28 and GPIO-30. I started by using GPIO-28 and that would configure nicely and I set up the interrupt handler and could see my debug when triggering the input (brilliant) but for some reason I cannot use it to wake the system as it is not in the correct group for wakeup. There is a note in the Tech Ref Man - Only gpio_1, gpio_9, gpio_10, gpio_11, gpio_30, and gpio_31 can be used to generate a direct wake-up event. So have to use a different one. GPIO-30 cannot be used as that holds the system in reset, so all that is left is GPIO-10. All seems to be good for initialisation; I think you don't need the mux wake-up bits for the first GPIO bank, it's always powered. So just setting gpio10 as an interrupt should keep it working through suspend. The GPIO driver has it's own idle handling for the first bank, see _set_gpio_wakeup(). Maybe you just need to do set_irq_wake() in the interrupt number for gpio10? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/5] wl1251 device tree support
* John W. Linville linvi...@tuxdriver.com [140117 07:17]: On Fri, Jan 17, 2014 at 02:45:15AM +0100, Sebastian Reichel wrote: On Mon, Jan 06, 2014 at 11:57:09PM +0100, Sebastian Reichel wrote: Hi John, The following patchset adds device tree support to the spi variant of the wl1251 driver. Luciano Coelho (1): wl1251: split wl251 platform data to a separate structure Sebastian Reichel (4): wl1251: move power GPIO handling into the driver wl1251: spi: add vio regulator support wl1251: spi: add device tree support Documentation: dt: wireless: Add wl1251 What's the status of this patchset? Tony prepared an immutable branch for patches 1+2 [0]. I think the other patches are also ok (at least there were no more complains from the DT binding maintainers). It would be nice to have wl1251 DT support in 3.14. [0] http://www.spinics.net/lists/linux-omap/msg101165.html -- Sebastian ping? I can't see it on wireless-next. I can't pull it because the branch is based on a later source than that of wireless-next. Hmm I thought v3.13-rc1 was the base we agreed on the immutable branch. Care to explain what the issue is merging it in? AFAIK merging it fast forwards your branch to v3.13-rc1 and then you just need to do the pull request against v3.13-rc1. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Mike Turquette mturque...@linaro.org writes: [...] I took Tony's advice and fast-forwarded clk-next to -rc7 and applied Tero's series. This includes the AM3517 bits now. I've pushed this branch to clk-next-omap (force update) on my Linaro mirror. Can you do a final sanity test before I merge this into clk-next? I merged clk-next-omap into next-20140117 and build/boot tested omap2plus_defconfig, multi_v7_defconfig and multi_v7_defconfig+CONFIG_LPAE=y and all passed a basic boot test for omap5uevm. I'll add OMAP5 to the automated boot testing starting with the next linux-next. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
* Kevin Hilman khil...@linaro.org [140117 09:48]: Mike Turquette mturque...@linaro.org writes: [...] I took Tony's advice and fast-forwarded clk-next to -rc7 and applied Tero's series. This includes the AM3517 bits now. I've pushed this branch to clk-next-omap (force update) on my Linaro mirror. Can you do a final sanity test before I merge this into clk-next? I merged clk-next-omap into next-20140117 and build/boot tested omap2plus_defconfig, multi_v7_defconfig and multi_v7_defconfig+CONFIG_LPAE=y and all passed a basic boot test for omap5uevm. I'll add OMAP5 to the automated boot testing starting with the next linux-next. OK that's good news. Looks like omap1_defconfig build has now started failing though: vers/built-in.o: In function `omap5xxx_dt_clk_init': :(.init.text+0x846c): undefined reference to `omap2_clk_disable_autoidle_all' drivers/built-in.o: In function `am43xx_dt_clk_init': :(.init.text+0x856c): undefined reference to `omap2_clk_disable_autoidle_all' drivers/built-in.o:(.rodata+0xc3c4): undefined reference to `omap3_clkoutx2_recalc' drivers/built-in.o:(.rodata+0xc40c): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc410): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc41c): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc420): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc42c): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc430): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc470): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc474): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc480): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc4a0): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc4a4): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc4b0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc4b4): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc4c0): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc4c4): undefined reference to `omap3_dpll4_set_rate' drivers/built-in.o:(.rodata+0xc4e0): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc4e4): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc4f0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc4f4): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc500): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc504): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc530): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc540): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc560): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc564): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc570): undefined reference to `omap4_dpll_regm4xen_recalc' drivers/built-in.o:(.rodata+0xc574): undefined reference to `omap4_dpll_regm4xen_round_rate' drivers/built-in.o:(.rodata+0xc580): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc584): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc5b0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc5b4): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc5c0): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc5c4): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc63c): undefined reference to `omap2_dflt_clk_enable' drivers/built-in.o:(.rodata+0xc640): undefined reference to `omap2_dflt_clk_disable' drivers/built-in.o:(.rodata+0xc644): undefined reference to `omap2_dflt_clk_is_enabled' drivers/built-in.o:(.rodata+0xc728): undefined reference to `omap2_clkops_enable_clkdm' drivers/built-in.o:(.rodata+0xc72c): undefined reference to `omap2_clkops_disable_clkdm' drivers/built-in.o:(.rodata+0xc754): undefined reference to `omap2_init_clk_clkdm' drivers/built-in.o:(.rodata+0xc784): undefined reference to `omap2_dflt_clk_disable' drivers/built-in.o:(.rodata+0xc788): undefined reference to `omap2_dflt_clk_is_enabled' drivers/built-in.o:(.rodata+0xc7ac): undefined reference to `omap2_init_clk_clkdm' drivers/built-in.o:(.rodata+0xc7c0): undefined reference to `omap2_dflt_clk_enable' drivers/built-in.o:(.rodata+0xc7c4): undefined reference to `omap2_dflt_clk_disable' drivers/built-in.o:(.rodata+0xc7c8): undefined reference to `omap2_dflt_clk_is_enabled' drivers
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/17/2014 07:53 PM, Tony Lindgren wrote: * Kevin Hilman khil...@linaro.org [140117 09:48]: Mike Turquette mturque...@linaro.org writes: [...] I took Tony's advice and fast-forwarded clk-next to -rc7 and applied Tero's series. This includes the AM3517 bits now. I've pushed this branch to clk-next-omap (force update) on my Linaro mirror. Can you do a final sanity test before I merge this into clk-next? I think you accidentally merged wrong branch to clk-next-omap with the latest refresh. This is one is missing the build-fixes now, when it earlier had those in. The correct branch to merge was 3.13-rc7-dt-clks-v13-build-fixes. This also causes the build failure below for omap1. -Tero I merged clk-next-omap into next-20140117 and build/boot tested omap2plus_defconfig, multi_v7_defconfig and multi_v7_defconfig+CONFIG_LPAE=y and all passed a basic boot test for omap5uevm. I'll add OMAP5 to the automated boot testing starting with the next linux-next. OK that's good news. Looks like omap1_defconfig build has now started failing though: vers/built-in.o: In function `omap5xxx_dt_clk_init': :(.init.text+0x846c): undefined reference to `omap2_clk_disable_autoidle_all' drivers/built-in.o: In function `am43xx_dt_clk_init': :(.init.text+0x856c): undefined reference to `omap2_clk_disable_autoidle_all' drivers/built-in.o:(.rodata+0xc3c4): undefined reference to `omap3_clkoutx2_recalc' drivers/built-in.o:(.rodata+0xc40c): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc410): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc41c): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc420): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc42c): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc430): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc470): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc474): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc480): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc4a0): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc4a4): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc4b0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc4b4): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc4c0): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc4c4): undefined reference to `omap3_dpll4_set_rate' drivers/built-in.o:(.rodata+0xc4e0): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc4e4): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc4f0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc4f4): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc500): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc504): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc530): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc540): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc560): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc564): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc570): undefined reference to `omap4_dpll_regm4xen_recalc' drivers/built-in.o:(.rodata+0xc574): undefined reference to `omap4_dpll_regm4xen_round_rate' drivers/built-in.o:(.rodata+0xc580): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc584): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc5b0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc5b4): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc5c0): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc5c4): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc63c): undefined reference to `omap2_dflt_clk_enable' drivers/built-in.o:(.rodata+0xc640): undefined reference to `omap2_dflt_clk_disable' drivers/built-in.o:(.rodata+0xc644): undefined reference to `omap2_dflt_clk_is_enabled' drivers/built-in.o:(.rodata+0xc728): undefined reference to `omap2_clkops_enable_clkdm' drivers/built-in.o:(.rodata+0xc72c): undefined reference to `omap2_clkops_disable_clkdm' drivers/built-in.o:(.rodata+0xc754): undefined reference to `omap2_init_clk_clkdm' drivers/built-in.o:(.rodata+0xc784): undefined reference to `omap2_dflt_clk_disable' drivers/built-in.o:(.rodata+0xc788): undefined reference to `omap2_dflt_clk_is_enabled' drivers/built-in.o:(.rodata
Re: [PATCHv2 0/5] wl1251 device tree support
On Fri, Jan 17, 2014 at 09:44:16AM -0800, Tony Lindgren wrote: * John W. Linville linvi...@tuxdriver.com [140117 07:17]: On Fri, Jan 17, 2014 at 02:45:15AM +0100, Sebastian Reichel wrote: On Mon, Jan 06, 2014 at 11:57:09PM +0100, Sebastian Reichel wrote: Hi John, The following patchset adds device tree support to the spi variant of the wl1251 driver. Luciano Coelho (1): wl1251: split wl251 platform data to a separate structure Sebastian Reichel (4): wl1251: move power GPIO handling into the driver wl1251: spi: add vio regulator support wl1251: spi: add device tree support Documentation: dt: wireless: Add wl1251 What's the status of this patchset? Tony prepared an immutable branch for patches 1+2 [0]. I think the other patches are also ok (at least there were no more complains from the DT binding maintainers). It would be nice to have wl1251 DT support in 3.14. [0] http://www.spinics.net/lists/linux-omap/msg101165.html -- Sebastian ping? I can't see it on wireless-next. I can't pull it because the branch is based on a later source than that of wireless-next. Hmm I thought v3.13-rc1 was the base we agreed on the immutable branch. Care to explain what the issue is merging it in? I think I was clear -- the branch is based on a later source than that of wireless-next. AFAIK merging it fast forwards your branch to v3.13-rc1 and then you just need to do the pull request against v3.13-rc1. It's not a forward, it's a merge. And I don't want to do that in the wireless-next tree right now. Are you sending that branch for 3.14? Is there some reason that I have to have it in wireless-next? John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/17/2014 11:46 AM, Kevin Hilman wrote: Mike Turquette mturque...@linaro.org writes: [...] I took Tony's advice and fast-forwarded clk-next to -rc7 and applied Tero's series. This includes the AM3517 bits now. I've pushed this branch to clk-next-omap (force update) on my Linaro mirror. Can you do a final sanity test before I merge this into clk-next? I merged clk-next-omap into next-20140117 and build/boot tested omap2plus_defconfig, multi_v7_defconfig and multi_v7_defconfig+CONFIG_LPAE=y and all passed a basic boot test for omap5uevm. I'll add OMAP5 to the automated boot testing starting with the next linux-next. Here are my logs for the similar configuration(with few patches for legacy boot): next-db23a6c + next-20140117 (omap2plus_defconfig) 1: am335x-evm: Boot PASS: http://slexy.org/raw/s20pGXG1jF 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2ViUqyxYc 3: am3517-evm: Boot PASS: http://slexy.org/raw/s29qMTk2mS 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20aZ0oDHS 5: beag: Boot PASS: http://slexy.org/raw/s2DAKDwqRm 6: bone: Boot PASS: http://slexy.org/raw/s215UVEmq2 7: crane: No Image built - Missing platform support?: (pending merge from Benoit) 8: dra7: Boot PASS: http://slexy.org/raw/s2CbtBGGxE 9:ldp: Boot FAIL: http://slexy.org/raw/s20MOKNvPG (been seeing this behavior on and off for some days now.. not really a regression due to this series - need to debug this - could be setup issues). 10: panda: Boot PASS: http://slexy.org/raw/s20RHdfXjS 11:sdp2430: Boot PASS: http://slexy.org/raw/s21fR9cQap 12:sdp3430: Boot PASS: http://slexy.org/raw/s209eZfYlQ 13:sdp4430: Boot PASS: http://slexy.org/raw/s21jemvEcd 14: uevm: Boot PASS: http://slexy.org/raw/s20OumuRI8 TOTAL = 14 boards, Booted Boards = 12, No Boot boards = 2 clk-next-db23a6c + next-20140117 (multi_v7_defconfig) 1: am335x-evm: Boot PASS: http://slexy.org/raw/s21kek3KDX 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20b6Ypnpr 3: am3517-evm: Boot PASS: http://slexy.org/raw/s200aHOMA1 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2QwHWtLbB 5: beag: Boot PASS: http://slexy.org/raw/s2120qe2nJ 6: bone: Boot PASS: http://slexy.org/raw/s21SnQH1AY 7: crane: No Image built - Missing platform support?: 8: dra7: Boot FAIL: http://slexy.org/raw/s20HxBFzIr missing DRA7 in multi_v7 9:ldp: Boot PASS: http://slexy.org/raw/s21vjb9GeV 10: panda: Boot FAIL: http://slexy.org/raw/s2WahEfqVw kevin already reported this for CPU_IDLE enable 11:sdp2430: Boot FAIL: http://slexy.org/raw/s2ADmtqRhq * multi_v7 does not boot v6 based boards 12:sdp3430: Boot PASS: http://slexy.org/raw/s2qM9hxrfi 13:sdp4430: Boot PASS: http://slexy.org/raw/s2ubbIBRA7 14: uevm: Boot PASS: http://slexy.org/raw/s2Y9xESvfH TOTAL = 14 boards, Booted Boards = 10, No Boot boards = 4 clk-next-db23a6c + next-20140117 (multi_v7_defconfig + CONFIG_LPAE=y) 1: am335x-evm: Boot PASS: http://slexy.org/raw/s26sCQ0zqh 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20BDyQWdB 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21OPwGNo1 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20tpjF0ri 5: beag: Boot PASS: http://slexy.org/raw/s2jzkyRVaS 6: bone: Boot PASS: http://slexy.org/raw/s20XodcZtZ 7: crane: No Image built - Missing platform support?: 8: dra7: Boot FAIL: http://slexy.org/raw/s21cv8ni1H missing DRA7 in multi_v7 9:ldp: Boot PASS: http://slexy.org/raw/s22x4lqV3F 10: panda: Boot FAIL: http://slexy.org/raw/s200ETyoTB kevin already reported this for CPU_IDLE enable 11:sdp2430: Boot FAIL: http://slexy.org/raw/s2lw3baFwx * multi_v7 does not boot v6 based boards 12:sdp3430: Boot PASS: http://slexy.org/raw/s21i0TdsYs 13:sdp4430: Boot PASS: http://slexy.org/raw/s2DaYv6GVp 14: uevm: Boot PASS: http://slexy.org/raw/s2Q5IdWfMQ TOTAL = 14 boards, Booted Boards = 10, No Boot boards = 4 -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ARM: OMAP: clk-next-omap emergency fixes
Hi, Quick emergency band-aid for the build breakages introduced in clk-next by Mike. I didn't have time to test this out (Nishanth will provide some logs) and I will leave the decision whether/how to use these patches or not to Tony + Mike. I also pushed a test branch based on top of clk-next here: tree: https://github.com/t-kristo/linux-pm.git branch: clk-next-omap-fixes -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: DRA7XX: Add support for DRA7XX only build
SOC_DRA7XX was under wrong menu within Kconfig file, which prevented DRA7XX only build. Fixed the kconfig options for this SoC as we are there. voltage.c needs to be added to the DRA7XX build also, otherwise DRA7XX only build will fail. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/Kconfig | 18 ++ arch/arm/mach-omap2/Makefile |1 + 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index dc21df1..e65948a 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -76,6 +76,16 @@ config SOC_AM43XX select ARM_GIC select MACH_OMAP_GENERIC +config SOC_DRA7XX + bool TI DRA7XX + depends on ARCH_MULTI_V7 + select ARCH_OMAP2PLUS + select ARM_CPU_SUSPEND if PM + select ARM_GIC + select CPU_V7 + select HAVE_SMP + select HAVE_ARM_ARCH_TIMER + config ARCH_OMAP2PLUS bool select ARCH_HAS_BANDGAP @@ -128,14 +138,6 @@ config SOC_HAS_REALTIME_COUNTER depends on SOC_OMAP5 || SOC_DRA7XX default y -config SOC_DRA7XX - bool TI DRA7XX - select ARM_ARCH_TIMER - select CPU_V7 - select ARM_GIC - select HAVE_SMP - select COMMON_CLK - comment OMAP Core Type depends on ARCH_OMAP2 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 96a990f..8ebe9f3 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -132,6 +132,7 @@ obj-$(CONFIG_SOC_AM33XX)+= $(voltagedomain-common) obj-$(CONFIG_SOC_AM43XX) += $(voltagedomain-common) obj-$(CONFIG_SOC_OMAP5)+= $(voltagedomain-common) obj-$(CONFIG_SOC_OMAP5)+= voltagedomains54xx_data.o +obj-$(CONFIG_SOC_DRA7XX) += $(voltagedomain-common) # OMAP powerdomain framework powerdomain-common += powerdomain.o powerdomain-common.o -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: DRA7XX/AM43XX: randconfig fixes
DRA7XX and AM43XX were missing common clock code from the Makefile, which causes build breakage in DRA7XX / AM43XX only builds once clock support for these SoCs is added. Add the missing entries to the Makefile as preparation of this. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/Makefile |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 088305f..96a990f 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -191,6 +191,9 @@ obj-$(CONFIG_ARCH_OMAP4)+= dpll3xxx.o dpll44xx.o obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o obj-$(CONFIG_SOC_OMAP5)+= $(clock-common) obj-$(CONFIG_SOC_OMAP5)+= dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_DRA7XX) += $(clock-common) +obj-$(CONFIG_SOC_DRA7XX) += dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_AM43XX) += $(clock-common) dpll3xxx.o # OMAP2 clock rate set data (old OPP data) obj-$(CONFIG_SOC_OMAP2420) += opp2420_data.o -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] clk: ti: OMAP build fixes
Improper merge of TI clock driver resulted in build breakage for OMAP1 build, and various other TI single SoC builds. This patch fixes those by adding the missed Makefile tweaks. Signed-off-by: Tero Kristo t-kri...@ti.com --- drivers/clk/Makefile|2 +- drivers/clk/ti/Makefile | 17 + 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index 1f3143f..13c1e91 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -38,7 +38,7 @@ obj-$(CONFIG_PLAT_SAMSUNG)+= samsung/ obj-$(CONFIG_COMMON_CLK_XGENE) += clk-xgene.o obj-$(CONFIG_COMMON_CLK_KEYSTONE) += keystone/ obj-$(CONFIG_ARCH_SHMOBILE_MULTI) += shmobile/ -obj-$(CONFIG_ARCH_OMAP)+= ti/ +obj-$(CONFIG_ARCH_OMAP2PLUS) += ti/ obj-$(CONFIG_X86) += x86/ diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile index 007c3c2..4319d40 100644 --- a/drivers/clk/ti/Makefile +++ b/drivers/clk/ti/Makefile @@ -1,10 +1,11 @@ ifneq ($(CONFIG_OF),) -obj-y += clk.o dpll.o autoidle.o divider.o \ - fixed-factor.o gate.o clockdomain.o \ - composite.o mux.o apll.o clk-43xx.o -obj-$(CONFIG_SOC_AM33XX) += clk-33xx.o -obj-$(CONFIG_ARCH_OMAP3) += interface.o clk-3xxx.o -obj-$(CONFIG_ARCH_OMAP4) += clk-44xx.o -obj-$(CONFIG_SOC_OMAP5)+= clk-54xx.o -obj-$(CONFIG_SOC_DRA7XX) += clk-7xx.o +obj-y += clk.o autoidle.o clockdomain.o +clk-common = dpll.o composite.o divider.o gate.o \ + fixed-factor.o mux.o apll.o +obj-$(CONFIG_SOC_AM33XX) += $(clk-common) clk-33xx.o +obj-$(CONFIG_ARCH_OMAP3) += $(clk-common) interface.o clk-3xxx.o +obj-$(CONFIG_ARCH_OMAP4) += $(clk-common) clk-44xx.o +obj-$(CONFIG_SOC_OMAP5)+= $(clk-common) clk-54xx.o +obj-$(CONFIG_SOC_DRA7XX) += $(clk-common) clk-7xx.o +obj-$(CONFIG_SOC_AM43XX) += $(clk-common) clk-43xx.o endif -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Quoting Tero Kristo (2014-01-17 10:11:06) On 01/17/2014 07:53 PM, Tony Lindgren wrote: * Kevin Hilman khil...@linaro.org [140117 09:48]: Mike Turquette mturque...@linaro.org writes: [...] I took Tony's advice and fast-forwarded clk-next to -rc7 and applied Tero's series. This includes the AM3517 bits now. I've pushed this branch to clk-next-omap (force update) on my Linaro mirror. Can you do a final sanity test before I merge this into clk-next? I think you accidentally merged wrong branch to clk-next-omap with the latest refresh. This is one is missing the build-fixes now, when it earlier had those in. The correct branch to merge was 3.13-rc7-dt-clks-v13-build-fixes. This also causes the build failure below for omap1. You are right. I broke the OMAPs. I force updated clk-next-omap (and clk-next) with the correct branch this time. Regards, Mike -Tero I merged clk-next-omap into next-20140117 and build/boot tested omap2plus_defconfig, multi_v7_defconfig and multi_v7_defconfig+CONFIG_LPAE=y and all passed a basic boot test for omap5uevm. I'll add OMAP5 to the automated boot testing starting with the next linux-next. OK that's good news. Looks like omap1_defconfig build has now started failing though: vers/built-in.o: In function `omap5xxx_dt_clk_init': :(.init.text+0x846c): undefined reference to `omap2_clk_disable_autoidle_all' drivers/built-in.o: In function `am43xx_dt_clk_init': :(.init.text+0x856c): undefined reference to `omap2_clk_disable_autoidle_all' drivers/built-in.o:(.rodata+0xc3c4): undefined reference to `omap3_clkoutx2_recalc' drivers/built-in.o:(.rodata+0xc40c): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc410): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc41c): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc420): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc42c): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc430): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc470): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc474): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc480): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc4a0): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc4a4): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc4b0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc4b4): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc4c0): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc4c4): undefined reference to `omap3_dpll4_set_rate' drivers/built-in.o:(.rodata+0xc4e0): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc4e4): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc4f0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc4f4): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc500): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc504): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc530): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc540): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc560): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc564): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc570): undefined reference to `omap4_dpll_regm4xen_recalc' drivers/built-in.o:(.rodata+0xc574): undefined reference to `omap4_dpll_regm4xen_round_rate' drivers/built-in.o:(.rodata+0xc580): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc584): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc5b0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc5b4): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc5c0): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc5c4): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc63c): undefined reference to `omap2_dflt_clk_enable' drivers/built-in.o:(.rodata+0xc640): undefined reference to `omap2_dflt_clk_disable' drivers/built-in.o:(.rodata+0xc644): undefined reference to `omap2_dflt_clk_is_enabled' drivers/built-in.o:(.rodata+0xc728): undefined reference
Re: [PATCH 0/3] ARM: OMAP: clk-next-omap emergency fixes
Quoting Tero Kristo (2014-01-17 12:25:37) Hi, Quick emergency band-aid for the build breakages introduced in clk-next by Mike. I didn't have time to test this out (Nishanth will provide some logs) and I will leave the decision whether/how to use these patches or not to Tony + Mike. I also pushed a test branch based on top of clk-next here: tree: https://github.com/t-kristo/linux-pm.git branch: clk-next-omap-fixes Thanks Tero. I force updated the clk tree with the right branch, so these should not be necessary now. Regards, Mike -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/17/2014 02:58 PM, Mike Turquette wrote: Quoting Tero Kristo (2014-01-17 10:11:06) On 01/17/2014 07:53 PM, Tony Lindgren wrote: * Kevin Hilman khil...@linaro.org [140117 09:48]: Mike Turquette mturque...@linaro.org writes: [...] I took Tony's advice and fast-forwarded clk-next to -rc7 and applied Tero's series. This includes the AM3517 bits now. I've pushed this branch to clk-next-omap (force update) on my Linaro mirror. Can you do a final sanity test before I merge this into clk-next? I think you accidentally merged wrong branch to clk-next-omap with the latest refresh. This is one is missing the build-fixes now, when it earlier had those in. The correct branch to merge was 3.13-rc7-dt-clks-v13-build-fixes. This also causes the build failure below for omap1. You are right. I broke the OMAPs. I force updated clk-next-omap (and clk-next) with the correct branch this time. Build tests: omap1_defconfig: clk-next-6a0cad9: builds fine clk-next-6a0cad9 + next-20140117: http://slexy.org/view/s2HgtvUtAl disabling CONFIG_BT, builds fine Boot tests: clk-next-6a0cad9, clk-next-6a0cad9 + next-20140117 : No regressions seen Detailed Boot logs: clk-next-6a0cad9 omap2plus_defconfig: 1: am335x-evm: Boot PASS: http://slexy.org/raw/s21idEk2IZ 2: am335x-sk: Boot PASS: http://slexy.org/raw/s21Q4w8gWT 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21dT7y2CA 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2VFaOtuDP 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s20L0DBt1d 6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s20gKsdH3A 7: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ZXTJswqY 8: crane: No Image built - Missing platform support?: 9: dra7: Boot PASS: http://slexy.org/raw/s2XZfjQz67 10:ldp: No Image built - Missing platform support?: 11: panda-es: Boot PASS: http://slexy.org/raw/s2ESRQgBbc 12:sdp2430: No Image built - Missing platform support?: 13:sdp3430: Boot PASS: http://slexy.org/raw/s2YsAO3ZPJ 14:sdp4430: Boot PASS: http://slexy.org/raw/s2MxxggHkh 15: uevm: Boot PASS: http://slexy.org/raw/s2wJT0B7wf TOTAL = 15 boards, Booted Boards = 12, No Boot boards = 3 clk-next-6a0cad9 multi_v7_defconfig: 1: am335x-evm: Boot FAIL: http://slexy.org/raw/s21AXBDbM9 * regulator/mmc missing here 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s21pQPhupJ * regulator/mmc missing here 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21iM7TEiQ 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2pBD6nplU 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2X9mnCKhT 6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s21CjzZtZ6 7: beaglebone-black: Boot PASS: http://slexy.org/raw/s2vCfnss8N 8: crane: No Image built - Missing platform support?: 9: dra7: Boot FAIL: http://slexy.org/raw/s21Xn4t22A * DRA7 not enabled? 10:ldp: No Image built - Missing platform support?: 11: panda-es: Boot PASS: http://slexy.org/raw/s21ZoijL9i 12:sdp2430: No Image built - Missing platform support?: 13:sdp3430: Boot PASS: http://slexy.org/raw/s21rdIfh7S 14:sdp4430: Boot PASS: http://slexy.org/raw/s21HXFj9cw 15: uevm: Boot FAIL: http://slexy.org/raw/s21m26VdbI * regulator/mmc missing here TOTAL = 15 boards, Booted Boards = 8, No Boot boards = 7 clk-next-6a0cad9 multi_v7_defconfig+CONFIG_LPAE=y: 1: am335x-evm: Boot FAIL: http://slexy.org/raw/s21GIuprIx * regulator/mmc missing here 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s20Vy6K9Rg * regulator/mmc missing here 3: am3517-evm: Boot PASS: http://slexy.org/raw/s20jXaoTYq 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20bk4uHcb 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2gVGjYMXz 6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s26D0F2N1t 7: beaglebone-black: Boot PASS: http://slexy.org/raw/s2ThmugNzC 8: crane: No Image built - Missing platform support?: 9: dra7: Boot FAIL: http://slexy.org/raw/s21HdQFchd * DRA7 not enabled? 10:ldp: No Image built - Missing platform support?: 11: panda-es: Boot PASS: http://slexy.org/raw/s2042Y9Pyb 12:sdp2430: No Image built - Missing platform support?: 13:sdp3430: Boot PASS: http://slexy.org/raw/s2NCg8nLki 14:sdp4430: Boot PASS: http://slexy.org/raw/s25GxRkWcj 15: uevm: Boot FAIL: http://slexy.org/raw/s2Q7xBYM3a * regulator/mmc missing here TOTAL = 15 boards, Booted Boards = 8, No Boot boards = 7 clk-next-6a0cad9 + next-20140117 omap2plus_defconfig: 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2ll3LdMN2 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2jyAF2Och 3: am3517-evm: Boot PASS: http://slexy.org/raw/s20nPsCcUS 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2Rn7Vqh8x 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2frIhnu6Y 6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s2GNee8kHF 7: beaglebone-black: Boot PASS: http://slexy.org/raw/s2G7fD4rGD 8: crane: No Image built - Missing platform support?: (pending
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon n...@ti.com wrote: clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_LPAE=y: 1: am335x-evm: Boot PASS: http://slexy.org/raw/s21GRhEOj4 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20zcNsD8h 3: am3517-evm: Boot PASS: http://slexy.org/raw/s27U9IfRKR 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2zYyeonec 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21iCRjTHK 6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s20bPGL3Sz 7: beaglebone-black: Boot PASS: http://slexy.org/raw/s21AhFmkCk 8: crane: No Image built - Missing platform support?: 9: dra7: Boot FAIL: http://slexy.org/raw/s21Qh3sQRu * DRA7 not enabled? 10:ldp: Boot PASS: http://slexy.org/raw/s21fvBfBgs 11: panda-es: Boot FAIL: http://slexy.org/raw/s20RsgVUZJ * known issue (https://patchwork.kernel.org/patch/3084521/) 12:sdp2430: Boot FAIL: v6 platform - wont boot with multi_v7 13:sdp3430: Boot PASS: http://slexy.org/raw/s20rhjjBwe 14:sdp4430: Boot PASS: http://slexy.org/raw/s2My0UfNPm 15: uevm: Boot PASS: http://slexy.org/raw/s21aqF6eMN TOTAL = 15 boards, Booted Boards = 11, No Boot boards = 4 I have a hard time believing the above; A8/A9 boards are not bootable with CONFIG_LPAE=y... -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/17/2014 06:12 PM, Olof Johansson wrote: On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon n...@ti.com wrote: clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_LPAE=y: 1: am335x-evm: Boot PASS: http://slexy.org/raw/s21GRhEOj4 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20zcNsD8h 3: am3517-evm: Boot PASS: http://slexy.org/raw/s27U9IfRKR 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2zYyeonec 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21iCRjTHK 6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s20bPGL3Sz 7: beaglebone-black: Boot PASS: http://slexy.org/raw/s21AhFmkCk 8: crane: No Image built - Missing platform support?: 9: dra7: Boot FAIL: http://slexy.org/raw/s21Qh3sQRu * DRA7 not enabled? 10:ldp: Boot PASS: http://slexy.org/raw/s21fvBfBgs 11: panda-es: Boot FAIL: http://slexy.org/raw/s20RsgVUZJ * known issue (https://patchwork.kernel.org/patch/3084521/) 12:sdp2430: Boot FAIL: v6 platform - wont boot with multi_v7 13:sdp3430: Boot PASS: http://slexy.org/raw/s20rhjjBwe 14:sdp4430: Boot PASS: http://slexy.org/raw/s2My0UfNPm 15: uevm: Boot PASS: http://slexy.org/raw/s21aqF6eMN TOTAL = 15 boards, Booted Boards = 11, No Boot boards = 4 I have a hard time believing the above; A8/A9 boards are not bootable with CONFIG_LPAE=y... You are right! Drat!! I had CONFIG_LPAE=y in my script, not CONFIG_ARM_LPAE=y! Grrr... Retest in a around 30 mins.. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On Fri, Jan 17, 2014 at 4:19 PM, Nishanth Menon n...@ti.com wrote: On 01/17/2014 06:12 PM, Olof Johansson wrote: On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon n...@ti.com wrote: clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_LPAE=y: 1: am335x-evm: Boot PASS: http://slexy.org/raw/s21GRhEOj4 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20zcNsD8h 3: am3517-evm: Boot PASS: http://slexy.org/raw/s27U9IfRKR 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2zYyeonec 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21iCRjTHK 6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s20bPGL3Sz 7: beaglebone-black: Boot PASS: http://slexy.org/raw/s21AhFmkCk 8: crane: No Image built - Missing platform support?: 9: dra7: Boot FAIL: http://slexy.org/raw/s21Qh3sQRu * DRA7 not enabled? 10:ldp: Boot PASS: http://slexy.org/raw/s21fvBfBgs 11: panda-es: Boot FAIL: http://slexy.org/raw/s20RsgVUZJ * known issue (https://patchwork.kernel.org/patch/3084521/) 12:sdp2430: Boot FAIL: v6 platform - wont boot with multi_v7 13:sdp3430: Boot PASS: http://slexy.org/raw/s20rhjjBwe 14:sdp4430: Boot PASS: http://slexy.org/raw/s2My0UfNPm 15: uevm: Boot PASS: http://slexy.org/raw/s21aqF6eMN TOTAL = 15 boards, Booted Boards = 11, No Boot boards = 4 I have a hard time believing the above; A8/A9 boards are not bootable with CONFIG_LPAE=y... You are right! Drat!! I had CONFIG_LPAE=y in my script, not CONFIG_ARM_LPAE=y! Grrr... Retest in a around 30 mins.. It's not a huge concern though; it's unlikely that LPAE makes a functional difference on this patch series. It's still useful to catch warnings, etc (most likely printk formats and the like). -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Deadlock in do_page_fault() on ARM (old kernel)
On 01/17/2014 08:46 AM, Russell King - ARM Linux wrote: On Wed, Jan 15, 2014 at 08:13:04PM -0500, Alan Ott wrote: So my questions are: 1. Why don't I see a full backtrace beyond the exception stack? It's the same when dump_stack() is called manually. No idea - it looks like you're not using frame pointers, but are using the unwinder. Full backtraces can always be created with frame pointers, it's just that unwinding seems unreliable. Hi Russell, I managed to get frame pointers turned on, which in this kernel version, seems like it requires the unwinder to be turned off[1]. When I built with frame pointers, the backtraces show differently. It only shows the frames which were _not_ shown with the unwinder. Backtrace at [2]. As you can see, it shows the non-exception stack dumps ending at places which can't page fault (and if it did page fault in those locations, it wouldn't try to take the mmap_sem lock). Its as though it shows what's in the modules but not what's in the image, where with the unwinder, it showed what's in the image and not what's in the modules[3]. I think we do need to see the full backtrace here - from looking at the full state dump, I don't see any sign of the mmap_sem being held except by an attempt to process a fault, and two threads trying to do a sys_mmap_pgoff(). The lockdep printout at the end of [4] (which is the original log I sent the other day) shows do_page_fault() holding mmap_sem in six tasks and sys_mmap_pgoff() holding it in two. (I don't like the term held in the lockdep printout and believe it to mean held or waiting for, based on my analysis of the rw_semaphore code.) Each of those tasks seems to be blocking for it. My suspicion therefore is that some other thread must have died while holding the mmap_sem, so there's probably a kernel oops earlier... that's my best guess at the moment without seeing the full backtrace. There's no oops that I'm able to see. Each of the tasks which lockdep reports as holding mmap_sem are blocking for it. If some other task had taken it and then crashed, I assume lockdep would list the crashed task as also holding the resource in the printout. Thanks for having a look at this, Alan. [1] It seems a little strange to me even in the newest kernel: 1: lib/Kconfig.debug specifies FRAME_POINTER . The text of this instance shows up when one searches for FRAME_POINTER in menuconfig. It can become selected even though the dependencies listed here are not met. 2: arch/arm/Kconfig.debug also specifies FRAME_POINTER, with a dependency only on !THUMB2_KERNEL, defaulting to yes on !ARM_UNWIND 3: ARM doens't set ARCH_WANT_FRAME_POINTERS [2] http://www.signal11.us/~alan/stack_dump_with_frame_pointers.txt Note: This is a sysrq dump of the locks held at lockup time and then the automatic hung task detection. [3] The modules are being built in the standard way for out-of-tree: $(MAKE) -C $(PRJDIR)/linux M=$(CWD) modules [4] http://www.signal11.us/~alan/show-all-tasks-deadlock.txt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
On 01/17/2014 06:23 PM, Olof Johansson wrote: On Fri, Jan 17, 2014 at 4:19 PM, Nishanth Menon n...@ti.com wrote: On 01/17/2014 06:12 PM, Olof Johansson wrote: On Fri, Jan 17, 2014 at 4:02 PM, Nishanth Menon n...@ti.com wrote: clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_LPAE=y: 1: am335x-evm: Boot PASS: http://slexy.org/raw/s21GRhEOj4 2: am335x-sk: Boot PASS: http://slexy.org/raw/s20zcNsD8h 3: am3517-evm: Boot PASS: http://slexy.org/raw/s27U9IfRKR 4: am37x-evm: Boot PASS: http://slexy.org/raw/s2zYyeonec 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21iCRjTHK 6: beagleboard-xm: Boot PASS: http://slexy.org/raw/s20bPGL3Sz 7: beaglebone-black: Boot PASS: http://slexy.org/raw/s21AhFmkCk 8: crane: No Image built - Missing platform support?: 9: dra7: Boot FAIL: http://slexy.org/raw/s21Qh3sQRu * DRA7 not enabled? 10:ldp: Boot PASS: http://slexy.org/raw/s21fvBfBgs 11: panda-es: Boot FAIL: http://slexy.org/raw/s20RsgVUZJ * known issue (https://patchwork.kernel.org/patch/3084521/) 12:sdp2430: Boot FAIL: v6 platform - wont boot with multi_v7 13:sdp3430: Boot PASS: http://slexy.org/raw/s20rhjjBwe 14:sdp4430: Boot PASS: http://slexy.org/raw/s2My0UfNPm 15: uevm: Boot PASS: http://slexy.org/raw/s21aqF6eMN TOTAL = 15 boards, Booted Boards = 11, No Boot boards = 4 I have a hard time believing the above; A8/A9 boards are not bootable with CONFIG_LPAE=y... You are right! Drat!! I had CONFIG_LPAE=y in my script, not CONFIG_ARM_LPAE=y! Grrr... Retest in a around 30 mins.. It's not a huge concern though; it's unlikely that LPAE makes a functional difference on this patch series. It's still useful to catch warnings, etc (most likely printk formats and the like). I suppose, as expected: clk-next-6a0cad9 + next-20140117 multi_v7_defconfig + CONFIG_ARM_LPAE=y * .config = http://slexy.org/view/s208uSeQS8 * Build warnings: http://slexy.org/raw/s20n7YwbwN 1: am335x-evm: Boot FAIL: http://slexy.org/raw/s20tF2eUZG 2: am335x-sk: Boot FAIL: http://slexy.org/raw/s2uP65lOMQ 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s2Lx13gsFZ 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s2eOLXxvsT 5: am43xx-epos: Boot FAIL: http://slexy.org/raw/s24coJzGvR 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s240WznuPd 7: BeagleBone-Black: Boot FAIL: http://slexy.org/raw/s20NG2UVTU 8: crane: No Image built - Missing platform support?: 9: dra7: Boot FAIL: http://slexy.org/raw/s21T3RpHx2 ^^ might probably boot if we enable CONFIG_SOC_DRA7XX in multi_v7 (this is another A15 target) 10:ldp: Boot FAIL: http://slexy.org/raw/s2F4VO9hDM 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s20HpzT1jW 12:sdp2430: Boot FAIL: http://slexy.org/raw/s21snV1EvL 13:sdp3430: Boot FAIL: http://slexy.org/raw/s2FwkVfG5R 14:sdp4430: Boot FAIL: http://slexy.org/raw/s2xiWxlpTj 15: uevm: Boot PASS: http://slexy.org/raw/s2LWUOmfiG TOTAL = 15 boards, Booted Boards = 1, No Boot boards = 14 I am running a defconfig set check on next-20140117 and will do one with next-20140118 once that is ready for comparison results -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Deadlock in do_page_fault() on ARM (old kernel)
On Fri, Jan 17, 2014 at 07:57:16PM -0500, Alan Ott wrote: On 01/17/2014 08:46 AM, Russell King - ARM Linux wrote: My suspicion therefore is that some other thread must have died while holding the mmap_sem, so there's probably a kernel oops earlier... that's my best guess at the moment without seeing the full backtrace. There's no oops that I'm able to see. Each of the tasks which lockdep reports as holding mmap_sem are blocking for it. If some other task had taken it and then crashed, I assume lockdep would list the crashed task as also holding the resource in the printout. My point is this: - the five (or six) threads which are trying to take the mmap_sem in read-mode in the fault handler are all blocked on it - they haven't taken the lock, which will only happen because there's a pending writer. - of these in your original post, there are two which faulted from __copy_to_user_std(). __copy_to_user_std() doesn't take the mmap_sem - this is the non-uaccess-with-memcpy path. - the pending writers are the two threads in sys_mmap_pgoff(), both of which are blocked waiting to gain the write lock. - there are no *other* threads holding the mmap_sem lock. So... there's a question here how we got into this state - and frankly I don't know. What I do see from your latest dump is that there's two unknown modules there - something called rcu2m and another called buttoms, and there are two threads inside ioctls there. Both have faulted from the function at 0xc0d2a394 (which won't appear in the backtrace, but is most likely __copy_to_user_std.) So, in the absence of you saying anything about there being any preceding oopses, my conclusion now is that one of those modules is taking the mmap_sem itself, and is the culpret inducing this deadlock. Note that your dump ([2]) in your reply was just the hung task detector printing out the stacktrace for a few tasks, not the full all-threads stack dump which I was expecting. So I'm pulling out these conclusions from the very little information you're supplying. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was up to 13.2Mbit. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
