Re: next boot: 34 pass, 5 fail (next-20140122)
Hello, On 01/23/2014 07:23 AM, Tero Kristo wrote: On 01/23/2014 03:35 AM, Kevin Hilman wrote: On Wed, Jan 22, 2014 at 4:46 PM, Kevin's boot bot khil...@linaro.org wrote: Automated DT boot report for various ARM defconfigs. Tree/Branch: next Git describe: next-20140122 Failed boot tests (console logs at the end) === omap3-tobi,3730storm: FAIL:omap2plus_defconfig [...] omap3-tobi,3730storm: FAIL:multi_v7_defconfig These OMAP3 failures are new regressions. Full failure boot log attached. Bisected down to: cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 is the first bad commit commit cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 Author: Tero Kristo t-kri...@ti.com Date: Tue Oct 22 11:53:02 2013 +0300 ARM: OMAP2+: io: use new clock init API clk_init is now separated to a common function which gets called for all SoC:s, which initializes the DT clocks and calls the SoC specific clock init. Signed-off-by: Tero Kristo t-kri...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Mike Turquette mturque...@linaro.org Kevin Hi, I think this is because the tobi board is including wrong omap3-soc.dtsi file (omap34xx.dtsi) through omap3-overo.dtsi. The board should include omap36xx.dtsi at least based on the boot log: [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) The problem is that the Overo (processor card on the Tobi extension board) can have a variety of processor depending on the exact model: - OMAP 35xx (1st generation: Air, Earth, Fire, Sand, Tide, Water, FE) - OMAP 3730 - AM/DM 37xx omap3-overo.dtsi includes omap34xx.dtsi to be compatible with the first generation. omap34xx.dtsi | - omap3-overo.dtsi (processor card) | - omap3-tobi.dtsi (expansion board) What is the fundamental incompatibility here? If we have to specifically include omap36xx for newer Overo, it will become hard to maintain as it will double the number of Overo / expansion boards possibilities. Regards, Florian -- 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 4/4] power_supply: bq24261 charger driver
On Thursday, January 23, 2014 2:20 AM, Jenny TC wrote: This patch introduces BQ24261 charger driver. The driver makes use of power supply charging driver to setup charging. So the driver does hardware abstraction and handles h/w specific corner cases. The charging logic resides with power supply charging driver Signed-off-by: Jenny TC jenny...@intel.com Hi Jenny, Thank you for including me. I added some minor comments. :-) --- drivers/power/Kconfig | 10 + drivers/power/Makefile|1 + drivers/power/bq24261_charger.c | 1447 + include/linux/power/bq24261_charger.h | 33 + 4 files changed, 1491 insertions(+) create mode 100644 drivers/power/bq24261_charger.c create mode 100644 include/linux/power/bq24261_charger.h diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 655457b..3f32f61 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -408,6 +408,16 @@ config BATTERY_GOLDFISH Say Y to enable support for the battery and AC power in the Goldfish emulator. +config BQ24261_CHARGER + tristate BQ24261 charger driver + select POWER_SUPPLY_CHARGER + depends on I2C + help + Say Y to include support for BQ24261 Charger driver. This driver + makes use of power supply charging driver. So the driver gives + the charger hardware abstraction only. Charging logic is abstracted + in the power supply charging driver. + source drivers/power/reset/Kconfig endif # POWER_SUPPLY diff --git a/drivers/power/Makefile b/drivers/power/Makefile index 77535fd..6d184c8 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -59,4 +59,5 @@ obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o obj-$(CONFIG_POWER_AVS) += avs/ obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o +obj-$(CONFIG_BQ24261_CHARGER)+= bq24261_charger.o obj-$(CONFIG_POWER_RESET)+= reset/ diff --git a/drivers/power/bq24261_charger.c b/drivers/power/bq24261_charger.c new file mode 100644 index 000..6ac063b --- /dev/null +++ b/drivers/power/bq24261_charger.c @@ -0,0 +1,1447 @@ +/* + * bq24261_charger.c - BQ24261 Charger I2C client driver + * + * Copyright (C) 2011 Intel Corporation + * + * ~~ + * + * 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 of the License. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * ~~ + * Author: Jenny TC jenny...@intel.com + */ +#define DEBUG Please insert one line between the comment and the #define. +#include linux/version.h +#include linux/kernel.h +#include linux/module.h +#include linux/err.h +#include linux/init.h +#include linux/interrupt.h +#include linux/slab.h +#include linux/device.h +#include linux/i2c.h +#include linux/power_supply.h +#include linux/pm_runtime.h +#include linux/io.h +#include linux/sched.h +#include linux/delay.h +#include linux/usb/otg.h +#include linux/power/power_supply_charger.h +#include linux/power/bq24261_charger.h +#include linux/seq_file.h Would you re-order these headers alphabetically? It enhances the readability. + +#include asm/intel_scu_ipc.h + +#define DEV_NAME bq24261_charger +#define DEV_MANUFACTURER TI +#define MODEL_NAME_SIZE 8 +#define DEV_MANUFACTURER_NAME_SIZE 4 + +#define EXCEPTION_MONITOR_DELAY (60 * HZ) +#define WDT_RESET_DELAY (15 * HZ) + +/* BQ24261 registers */ +#define BQ24261_STAT_CTRL0_ADDR 0x00 +#define BQ24261_CTRL_ADDR0x01 +#define BQ24261_BATT_VOL_CTRL_ADDR 0x02 +#define BQ24261_VENDOR_REV_ADDR 0x03 +#define BQ24261_TERM_FCC_ADDR0x04 +#define BQ24261_VINDPM_STAT_ADDR 0x05 +#define BQ24261_ST_NTC_MON_ADDR 0x06 + +#define BQ24261_RESET_MASK (0x01 7) +#define BQ24261_RESET_ENABLE (0x01 7) + +#define BQ24261_FAULT_MASK 0x07 +#define BQ24261_STAT_MASK(0x03 4) +#define BQ24261_BOOST_MASK (0x01 6) +#define BQ24261_TMR_RST_MASK (0x01 7) +#define BQ24261_TMR_RST (0x01 7) + +#define BQ24261_ENABLE_BOOST (0x01 6) + +#define BQ24261_VOVP 0x01 +#define BQ24261_LOW_SUPPLY 0x02 +#define BQ24261_THERMAL_SHUTDOWN 0x03 +#define BQ24261_BATT_TEMP_FAULT 0x04 +#define BQ24261_TIMER_FAULT 0x05
Re: next boot: 34 pass, 5 fail (next-20140122)
On 01/23/2014 10:14 AM, Florian Vaussard wrote: Hello, On 01/23/2014 07:23 AM, Tero Kristo wrote: On 01/23/2014 03:35 AM, Kevin Hilman wrote: On Wed, Jan 22, 2014 at 4:46 PM, Kevin's boot bot khil...@linaro.org wrote: Automated DT boot report for various ARM defconfigs. Tree/Branch: next Git describe: next-20140122 Failed boot tests (console logs at the end) === omap3-tobi,3730storm: FAIL:omap2plus_defconfig [...] omap3-tobi,3730storm: FAIL:multi_v7_defconfig These OMAP3 failures are new regressions. Full failure boot log attached. Bisected down to: cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 is the first bad commit commit cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 Author: Tero Kristo t-kri...@ti.com Date: Tue Oct 22 11:53:02 2013 +0300 ARM: OMAP2+: io: use new clock init API clk_init is now separated to a common function which gets called for all SoC:s, which initializes the DT clocks and calls the SoC specific clock init. Signed-off-by: Tero Kristo t-kri...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Mike Turquette mturque...@linaro.org Kevin Hi, I think this is because the tobi board is including wrong omap3-soc.dtsi file (omap34xx.dtsi) through omap3-overo.dtsi. The board should include omap36xx.dtsi at least based on the boot log: [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) The problem is that the Overo (processor card on the Tobi extension board) can have a variety of processor depending on the exact model: - OMAP 35xx (1st generation: Air, Earth, Fire, Sand, Tide, Water, FE) - OMAP 3730 - AM/DM 37xx omap3-overo.dtsi includes omap34xx.dtsi to be compatible with the first generation. omap34xx.dtsi | - omap3-overo.dtsi (processor card) | - omap3-tobi.dtsi (expansion board) What is the fundamental incompatibility here? If we have to specifically include omap36xx for newer Overo, it will become hard to maintain as it will double the number of Overo / expansion boards possibilities. Well, you get different board declaration inside mach-omap2/board-generic.c for omap34xx vs omap36xx. The clock data issues can be fixed by adding cpu_is_omap34xx() vs. cpu_is_omap3630() checks within the mach-omap2/io.c file, but this is probably for Tony/Kevin to comment whether we can/should do that. -Tero Regards, Florian -- 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 1/4] power_supply: Add inlmt,iterm, min/max temp props
On Thursday, January 23, 2014 2:20 AM, Jenny TC wrote: Add new power supply properties for input current, charge termination current, min and max temperature POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature POWER_SUPPLY_PROP_INLMT - input current limit programmed by charger. Indicates the input current for a charging source. POWER_SUPPLY_PROP_CHARGE_TERM_CUR - Charge termination current used to detect the end of charge condition Change-Id: Ifb40662bbfa24387ac7493ffa7ce01c6fae7e800 Please remove this 'Change-Id' from the commit message. Best regards, Jingoo Han Signed-off-by: Jenny TC jenny...@intel.com --- Documentation/power/power_supply_class.txt |6 ++ drivers/power/power_supply_sysfs.c |4 include/linux/power_supply.h |4 3 files changed, 14 insertions(+) -- 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: next boot: 34 pass, 5 fail (next-20140122)
On 01/23/2014 10:00 AM, Tero Kristo wrote: On 01/23/2014 10:14 AM, Florian Vaussard wrote: Hello, On 01/23/2014 07:23 AM, Tero Kristo wrote: On 01/23/2014 03:35 AM, Kevin Hilman wrote: On Wed, Jan 22, 2014 at 4:46 PM, Kevin's boot bot khil...@linaro.org wrote: Automated DT boot report for various ARM defconfigs. Tree/Branch: next Git describe: next-20140122 Failed boot tests (console logs at the end) === omap3-tobi,3730storm: FAIL:omap2plus_defconfig [...] omap3-tobi,3730storm: FAIL:multi_v7_defconfig These OMAP3 failures are new regressions. Full failure boot log attached. Bisected down to: cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 is the first bad commit commit cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 Author: Tero Kristo t-kri...@ti.com Date: Tue Oct 22 11:53:02 2013 +0300 ARM: OMAP2+: io: use new clock init API clk_init is now separated to a common function which gets called for all SoC:s, which initializes the DT clocks and calls the SoC specific clock init. Signed-off-by: Tero Kristo t-kri...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Mike Turquette mturque...@linaro.org Kevin Hi, I think this is because the tobi board is including wrong omap3-soc.dtsi file (omap34xx.dtsi) through omap3-overo.dtsi. The board should include omap36xx.dtsi at least based on the boot log: [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) The problem is that the Overo (processor card on the Tobi extension board) can have a variety of processor depending on the exact model: - OMAP 35xx (1st generation: Air, Earth, Fire, Sand, Tide, Water, FE) - OMAP 3730 - AM/DM 37xx omap3-overo.dtsi includes omap34xx.dtsi to be compatible with the first generation. omap34xx.dtsi | - omap3-overo.dtsi (processor card) | - omap3-tobi.dtsi (expansion board) What is the fundamental incompatibility here? If we have to specifically include omap36xx for newer Overo, it will become hard to maintain as it will double the number of Overo / expansion boards possibilities. Well, you get different board declaration inside mach-omap2/board-generic.c for omap34xx vs omap36xx. The clock data issues can be fixed by adding cpu_is_omap34xx() vs. cpu_is_omap3630() checks within the mach-omap2/io.c file, but this is probably for Tony/Kevin to comment whether we can/should do that. I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing the include to omap36xx.dtsi do not fix the issue. I still get the external abort on non-linefetch (full log here [1]). Florian [1] http://pastebin.com/43ys4TUA -- 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: next boot: 34 pass, 5 fail (next-20140122)
On 01/23/2014 10:15 AM, Florian Vaussard wrote: On 01/23/2014 10:00 AM, Tero Kristo wrote: On 01/23/2014 10:14 AM, Florian Vaussard wrote: Hello, On 01/23/2014 07:23 AM, Tero Kristo wrote: On 01/23/2014 03:35 AM, Kevin Hilman wrote: On Wed, Jan 22, 2014 at 4:46 PM, Kevin's boot bot khil...@linaro.org wrote: Automated DT boot report for various ARM defconfigs. Tree/Branch: next Git describe: next-20140122 Failed boot tests (console logs at the end) === omap3-tobi,3730storm: FAIL:omap2plus_defconfig [...] omap3-tobi,3730storm: FAIL:multi_v7_defconfig These OMAP3 failures are new regressions. Full failure boot log attached. Bisected down to: cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 is the first bad commit commit cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 Author: Tero Kristo t-kri...@ti.com Date: Tue Oct 22 11:53:02 2013 +0300 ARM: OMAP2+: io: use new clock init API clk_init is now separated to a common function which gets called for all SoC:s, which initializes the DT clocks and calls the SoC specific clock init. Signed-off-by: Tero Kristo t-kri...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Mike Turquette mturque...@linaro.org Kevin Hi, I think this is because the tobi board is including wrong omap3-soc.dtsi file (omap34xx.dtsi) through omap3-overo.dtsi. The board should include omap36xx.dtsi at least based on the boot log: [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) The problem is that the Overo (processor card on the Tobi extension board) can have a variety of processor depending on the exact model: - OMAP 35xx (1st generation: Air, Earth, Fire, Sand, Tide, Water, FE) - OMAP 3730 - AM/DM 37xx omap3-overo.dtsi includes omap34xx.dtsi to be compatible with the first generation. omap34xx.dtsi | - omap3-overo.dtsi (processor card) | - omap3-tobi.dtsi (expansion board) What is the fundamental incompatibility here? If we have to specifically include omap36xx for newer Overo, it will become hard to maintain as it will double the number of Overo / expansion boards possibilities. Well, you get different board declaration inside mach-omap2/board-generic.c for omap34xx vs omap36xx. The clock data issues can be fixed by adding cpu_is_omap34xx() vs. cpu_is_omap3630() checks within the mach-omap2/io.c file, but this is probably for Tony/Kevin to comment whether we can/should do that. I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing the include to omap36xx.dtsi do not fix the issue. I still get the external abort on non-linefetch (full log here [1]). So the issue is clearly caused by the hwmod warning just before the panic I think: omap_hwmod: usb_tll_hs: enabled state can only be entered from initialized, idle, or disabled state usb_tll_hs is thus not enabled, and we get a panic when trying to read the revision register ver = usbtll_read(tll-base, OMAP_USBTLL_REVISION); at drivers/mfd/omap-usb-tll.c:237. I do not know enough about hwmod to efficiently debug why usb_tll_hs is not _HWMOD_STATE_INITIALIZED before trying to enable it. Are we missing some DT data? Florian -- 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
I have tried all sorts of configurations now and still cannot get the system to wake from GPIO. The confusing thing is that if I use the power managements tests via debugfs I can make the system sleep and wakeup using the timer, so the suspend and wake is configured and working. Using either method of configuring the GPIO to be an interrupt and wakeup source OR a GPIO key with wakeup capability results in the system just sitting there in the suspended state. I know the GPIO and IRQ is working as I see the count increment in /proc/interrupts I have tried debugging with JTAG but not having any luck because the core enters a power down state so therefore disconnects the JTAG and the debug session hangs. I have also removed all devices going back to a very basic system thinking drivers are causing the suspend resume issue but still it stays in the sleep state. All the references I can find online do not assist in getting a solution for me. Is there anyone out there that has managed to successfully get the wake from suspend to memory working via a GPIO on a 3.x kernel ? i am getting close to running out of options to make this system work. Help appreciated and may help others out there with a similar issue. Kind Regards Marc From: Tony Lindgren [t...@atomide.com] Sent: 17 January 2014 17:39 To: Marc Murphy Cc: linux-omap@vger.kernel.org Subject: 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: next boot: 34 pass, 5 fail (next-20140122)
On 01/23/2014 11:41 AM, Florian Vaussard wrote: On 01/23/2014 10:15 AM, Florian Vaussard wrote: On 01/23/2014 10:00 AM, Tero Kristo wrote: On 01/23/2014 10:14 AM, Florian Vaussard wrote: Hello, On 01/23/2014 07:23 AM, Tero Kristo wrote: On 01/23/2014 03:35 AM, Kevin Hilman wrote: On Wed, Jan 22, 2014 at 4:46 PM, Kevin's boot bot khil...@linaro.org wrote: Automated DT boot report for various ARM defconfigs. Tree/Branch: next Git describe: next-20140122 Failed boot tests (console logs at the end) === omap3-tobi,3730storm: FAIL:omap2plus_defconfig [...] omap3-tobi,3730storm: FAIL:multi_v7_defconfig These OMAP3 failures are new regressions. Full failure boot log attached. Bisected down to: cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 is the first bad commit commit cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 Author: Tero Kristo t-kri...@ti.com Date: Tue Oct 22 11:53:02 2013 +0300 ARM: OMAP2+: io: use new clock init API clk_init is now separated to a common function which gets called for all SoC:s, which initializes the DT clocks and calls the SoC specific clock init. Signed-off-by: Tero Kristo t-kri...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Mike Turquette mturque...@linaro.org Kevin Hi, I think this is because the tobi board is including wrong omap3-soc.dtsi file (omap34xx.dtsi) through omap3-overo.dtsi. The board should include omap36xx.dtsi at least based on the boot log: [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) The problem is that the Overo (processor card on the Tobi extension board) can have a variety of processor depending on the exact model: - OMAP 35xx (1st generation: Air, Earth, Fire, Sand, Tide, Water, FE) - OMAP 3730 - AM/DM 37xx omap3-overo.dtsi includes omap34xx.dtsi to be compatible with the first generation. omap34xx.dtsi | - omap3-overo.dtsi (processor card) | - omap3-tobi.dtsi (expansion board) What is the fundamental incompatibility here? If we have to specifically include omap36xx for newer Overo, it will become hard to maintain as it will double the number of Overo / expansion boards possibilities. Well, you get different board declaration inside mach-omap2/board-generic.c for omap34xx vs omap36xx. The clock data issues can be fixed by adding cpu_is_omap34xx() vs. cpu_is_omap3630() checks within the mach-omap2/io.c file, but this is probably for Tony/Kevin to comment whether we can/should do that. I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing the include to omap36xx.dtsi do not fix the issue. I still get the external abort on non-linefetch (full log here [1]). So the issue is clearly caused by the hwmod warning just before the panic I think: omap_hwmod: usb_tll_hs: enabled state can only be entered from initialized, idle, or disabled state usb_tll_hs is thus not enabled, and we get a panic when trying to read the revision register ver = usbtll_read(tll-base, OMAP_USBTLL_REVISION); at drivers/mfd/omap-usb-tll.c:237. I do not know enough about hwmod to efficiently debug why usb_tll_hs is not _HWMOD_STATE_INITIALIZED before trying to enable it. Are we missing some DT data? The problem is the point before this one, uart4_fck lookup fails. This causes the hwmod code to bail out early and not init anything after it. I guess you are still mapping wrong clock init as it fails with uart4. Give the attached patch a shot and see how it behaves. -Tero From b42055fb5c1712348a757d766dbd7c09140cfe66 Mon Sep 17 00:00:00 2001 From: Tero Kristo t-kri...@ti.com Date: Thu, 23 Jan 2014 14:24:57 +0200 Subject: [PATCH] ARM: OMAP3: change all omap3 boards to use common early_init early_init now checks the cpu type for the corresponding clock init function. Mainly needed by the overo board which can have almost any OMAP3 subtype installed on it. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-am3517crane.c|2 +- arch/arm/mach-omap2/board-am3517evm.c |2 +- arch/arm/mach-omap2/board-cm-t35.c |4 ++-- arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-generic.c|8 +++ arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-omap3logic.c |4 ++-- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3stalker.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- arch/arm/mach-omap2/io.c | 35 +++- 15 files changed, 27 insertions(+), 46 deletions(-) diff --git a/arch/arm/mach
Re: [PATCH 1/3] pwm: core: Rearrange pwm lock.
On Wed, Dec 18, 2013 at 05:06:53PM +0530, Sourav Poddar wrote:
When tiecap is used as a module, then while doing a rmmod I
get the following dump.
root@am437x-evm:/# rmmod pwm_tiecap
[ 219.539245]
[ 219.540771] ==
[ 219.546936] [ INFO: possible circular locking dependency detected ]
[ 219.553192] 3.12.4-01557-g9921cde-dirty #134 Not tainted
[ 219.558471] ---
[ 219.564727] rmmod/1517 is trying to acquire lock:
[ 219.569427] (s_active#35){.+}, at: [c017ab00]
sysfs_hash_and_remove+0x4c/0x8c
[ 219.577239]
[ 219.577239] but task is already holding lock:
[ 219.583068] (pwm_lock){+.+.+.}, at: [c0303598] pwmchip_remove+0x14/0xf8
[ 219.589996]
[ 219.589996] which lock already depends on the new lock.
[ 219.589996]
[ 219.598144]
[ 219.598144] the existing dependency chain (in reverse order) is:
[ 219.605590]
- #1 (pwm_lock){+.+.+.}:
[ 219.609497][c00a2d1c] lock_acquire+0x9c/0x128
[ 219.614746][c0639bc0] mutex_lock_nested+0x50/0x3dc
[ 219.620391][c0303974] pwm_request_from_chip+0x38/0x6c
[ 219.626312][c0303fe0] pwm_export_store+0x50/0x140
[ 219.631896][c039aba8] dev_attr_store+0x18/0x24
[ 219.637207][c017aff0] sysfs_write_file+0x16c/0x1a0
[ 219.642883][c0119084] vfs_write+0xb0/0x188
[ 219.647857][c0119478] SyS_write+0x3c/0x70
[ 219.652770][c0014100] ret_fast_syscall+0x0/0x48
[ 219.658172]
- #0 (s_active#35){.+}:
[ 219.662353][c00a2778] __lock_acquire+0x1b28/0x1b70
[ 219.667999][c00a2d1c] lock_acquire+0x9c/0x128
[ 219.673248][c017c780] sysfs_addrm_finish+0xe8/0x158
[ 219.678985][c017ab00] sysfs_hash_and_remove+0x4c/0x8c
[ 219.684906][c017e224] remove_files+0x38/0x74
[ 219.690063][c017e2a4] sysfs_remove_group+0x44/0x108
[ 219.695800][c017e38c] sysfs_remove_groups+0x24/0x34
[ 219.701538][c039bc2c] device_del+0xec/0x178
[ 219.706604][c039bcc4] device_unregister+0xc/0x18
[ 219.712097][c0303658] pwmchip_remove+0xd4/0xf8
[ 219.717407][c039fdc4] platform_drv_remove+0x18/0x1c
[ 219.723175][c039e6c4] __device_release_driver+0x70/0xc8
[ 219.729248][c039eec8] driver_detach+0xb4/0xb8
[ 219.734497][c039e4ec] bus_remove_driver+0x8c/0xd0
[ 219.740081][c00abd2c] SyS_delete_module+0x118/0x22c
[ 219.745819][c0014100] ret_fast_syscall+0x0/0x48
[ 219.751220]
[ 219.751220] other info that might help us debug this:
[ 219.751220]
[ 219.759216] Possible unsafe locking scenario:
[ 219.759216]
[ 219.765106]CPU0CPU1
[ 219.769622]
[ 219.774139] lock(pwm_lock);
[ 219.777130]lock(s_active#35);
[ 219.782897]lock(pwm_lock);
[ 219.788391] lock(s_active#35);
[ 219.791656]
[ 219.791656] *** DEADLOCK ***
[ 219.791656]
[ 219.797546] 3 locks held by rmmod/1517:
[ 219.801391] #0: (__lockdep_no_validate__){..}, at: [c039ee58]
driver_detach+0x44/0xb8
[ 219.810028] #1: (__lockdep_no_validate__){..}, at: [c039ee64]
driver_detach+0x50/0xb8
[ 219.818695] #2: (pwm_lock){+.+.+.}, at: [c0303598]
pwmchip_remove+0x14/0xf8
[ 219.826049]
[ 219.826049] stack backtrace:
[ 219.830413] CPU: 0 PID: 1517 Comm: rmmod Not tainted
3.12.4-01557-g9921cde-dirty #134
[ 219.838256] [c001cc98] (unwind_backtrace+0x0/0xf0) from [c0018124]
(show_stack+0x10/0x14)
[ 219.846771] [c0018124] (show_stack+0x10/0x14) from [c0636728]
(dump_stack+0x74/0xb4)
[ 219.854858] [c0636728] (dump_stack+0x74/0xb4) from [c06344e4]
(print_circular_bug+0x284/0x2d8)
[ 219.863830] [c06344e4] (print_circular_bug+0x284/0x2d8) from
[c00a2778] (__lock_acquire+0x1b28/0x1b70)
[ 219.873443] [c00a2778] (__lock_acquire+0x1b28/0x1b70) from [c00a2d1c]
(lock_acquire+0x9c/0x128)
[ 219.882476] [c00a2d1c] (lock_acquire+0x9c/0x128) from [c017c780]
(sysfs_addrm_finish+0xe8/0x158)
[ 219.891601] [c017c780] (sysfs_addrm_finish+0xe8/0x158) from [c017ab00]
(sysfs_hash_and_remove+0x4c/0x8c)
[ 219.901397] [c017ab00] (sysfs_hash_and_remove+0x4c/0x8c) from
[c017e224] (remove_files+0x38/0x74)
[ 219.910614] [c017e224] (remove_files+0x38/0x74) from [c017e2a4]
(sysfs_remove_group+0x44/0x108)
[ 219.919647] [c017e2a4] (sysfs_remove_group+0x44/0x108) from [c017e38c]
(sysfs_remove_groups+0x24/0x34)
[ 219.929260] [c017e38c] (sysfs_remove_groups+0x24/0x34) from [c039bc2c]
(device_del+0xec/0x178)
[ 219.938201] [c039bc2c] (device_del+0xec/0x178) from [c039bcc4]
(device_unregister+0xc/0x18)
[ 219.946899] [c039bcc4] (device_unregister+0xc/0x18) from [c0303658]
(pwmchip_remove+0xd4/0xf8)
[ 219.955841] [c0303658] (pwmchip_remove+0xd4/0xf8) from [c039fdc4]
(platform_drv_remove+0x18/0x1c)
[ 219.965057]
Re: [PATCH 3/3] driver: pwmss: Disable stop clk bit during enable clock call.
On Wed, Dec 18, 2013 at 05:06:55PM +0530, Sourav Poddar wrote:
Writing to ecap register on second insmod crashes with an external
abort. This happens becuase the STOP_CLK bit remains set(from rmmod)
during the second insmod thereby not allowing the clocks to get enabled.
So, we disable STOP clock bit while doing a clock enable.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
drivers/pwm/pwm-tipwmss.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/pwm/pwm-tipwmss.c b/drivers/pwm/pwm-tipwmss.c
index 3b119bc..4749866 100644
--- a/drivers/pwm/pwm-tipwmss.c
+++ b/drivers/pwm/pwm-tipwmss.c
@@ -40,6 +40,8 @@ u16 pwmss_submodule_state_change(struct device *dev, int
set)
mutex_lock(info-pwmss_lock);
val = readw(info-mmio_base + PWMSS_CLKCONFIG);
+ if (set == PWMSS_ECAPCLK_EN)
+ val = ~PWMSS_ECAPCLK_STOP_REQ;
Should this be done for set == PWMSS_EPWMCLK_EN as well? Also how does
this behave if somebody goes and passes:
PWMSS_ECAPCLK_EN | PWMSS_ECAPCLK_STOP_REQ
as the set parameter.
I think that perhaps the pwmss_submodule_state_change() API should be
rethought. Instead of taking a value that's directly written into the
register, perhaps it should abstract away what this does.
From my understanding this is used to enable (or disable) the clock for
a specific submodule (ECAP or EHRPWM). Perhaps an interface like the
following would be more intuitive:
bool pwmss_module_enable(struct device *dev, enum pwmss_module module)
{
struct pwmss_info *info = dev_get_drvdata(dev);
u16 value, mask, state, ack;
switch (module) {
case PWMSS_MODULE_ECAP:
mask = PWMSS_ECAPCLK_EN | PWMSS_ECAPCLK_STOP_REQ;
state = PWMSS_ECAPCLK_EN;
ack = PWMSS_ECAPCLK_EN_ACK;
break;
case PWMSS_MODULE_EPWM:
mask = PWMSS_EPWMCLK_EN | PWMSS_EPWMCLK_STOP_REQ;
state = PWMSS_EPWMCLK_EN;
ack = PWMSS_ECAPCLK_EN_ACK;
break;
default:
return false;
}
mutex_lock(info-pwmss_lock);
value = readw(info-mmio + PWMSS_CLKCONFIG);
value = ~mask;
value |= state;
writew(value, info-mmio + PWMSS_CLKCONFIG);
mutex_unlock(info-pwmss_lock);
value = readw(info-mmio + PWMSS_CLKSTATUS);
return (value ack) != 0;
}
void pwmss_module_disable(struct device *dev, enum pwmss_module module)
{
struct pwmss_info *info = dev_get_drvdata(dev);
u16 value, mask, state;
switch (module) {
case PWMSS_MODULE_ECAP:
mask = PWMSS_ECAPCLK_EN | PWMSS_ECAPCLK_STOP_REQ;
state = PWMSS_ECAPCLK_STOP_REQ;
break;
case PWMSS_MODULE_EPWM:
mask = PWMSS_EPWMCLK_EN | PWMSS_EPWMCLK_STOP_REQ;
state = PWMSS_EPWMCLK_STOP_REQ;
break;
default:
return false;
}
mutex_lock(info-pwmss_lock);
value = readw(info-mmio + PWMSS_CLKCONFIG);
value = ~mask;
value |= state;
writew(value, info-mmio + PWMSS_CLKCONFIG);
mutex_unlock(info-pwmss_lock);
}
One possible other interesting alternative would be to export this
functionality via the common clock framework, since you're essentially
exposing clk_enable() and clk_disable(). That's probably overkill,
though.
Thierry
pgpBsLMscUhj5.pgp
Description: PGP signature
Re: [PATCH 2/3] driver: pwm: ti-ecap: Remove duplicate put_sync call.
On Wed, Dec 18, 2013 at 05:06:54PM +0530, Sourav Poddar wrote: Remove duplicate 'pm_runtime_put_sync' in the remove path. Signed-off-by: Sourav Poddar sourav.pod...@ti.com --- drivers/pwm/pwm-tiecap.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) Applied, thanks. Thierry pgpSBPgNnxvs5.pgp Description: PGP signature
Re: [PATCH] ARM: OMAP4+: move errata initialization to omap4_pm_init_early
On 01/20/2014 10:06 PM, Nishanth Menon wrote:
Move all OMAP4 PM errata initializations to centralized location in
omap4_pm_init_early. This allows for users to utilize the erratas
in various submodules as needed.
Tested-by: Grygorii Strashko grygorii.stras...@ti.com
This patch fixes build failure caused by patch
https://patchwork.kernel.org/patch/3084521/
in case if SMP is not enabled.
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Reported by Tony here: https://patchwork.kernel.org/patch/3084521/
Reproduced with .config: http://slexy.org/view/s2EEdvTGXV on next-20140120
tag (based on omap2plus_defconfig)
Applies on v3.13 tag and on next-20140120
Tested to boot on next-20140120 along with
https://patchwork.kernel.org/patch/3084521/
on PandaBoard-ES with multi_v7_defconfig: http://slexy.org/view/s27n0BWrPf
arch/arm/mach-omap2/common.h |6 ++
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/omap-smp.c |6 +-
arch/arm/mach-omap2/pm44xx.c | 15 +++
4 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 3adaa1d..a6aae30 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -62,11 +62,17 @@ static inline int omap3_pm_init(void)
#if defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP4)
int omap4_pm_init(void);
+int omap4_pm_init_early(void);
#else
static inline int omap4_pm_init(void)
{
return 0;
}
+
+static inline int omap4_pm_init_early(void)
+{
+ return 0;
+}
#endif
#ifdef CONFIG_OMAP_MUX
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 47381fd..d408b15 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -641,6 +641,7 @@ void __init omap4430_init_early(void)
omap_cm_base_init();
omap4xxx_check_revision();
omap4xxx_check_features();
+ omap4_pm_init_early();
omap44xx_prm_init();
omap44xx_voltagedomains_init();
omap44xx_powerdomains_init();
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 75e95d4..17550aa 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -39,8 +39,6 @@
#define OMAP5_CORE_COUNT0x2
-u16 pm44xx_errata;
-
/* SCU base address */
static void __iomem *scu_base;
@@ -217,10 +215,8 @@ static void __init omap4_smp_prepare_cpus(unsigned int
max_cpus)
if (scu_base)
scu_enable(scu_base);
- if (cpu_is_omap446x()) {
+ if (cpu_is_omap446x())
startup_addr = omap4460_secondary_startup;
- pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
- }
/*
* Write the address of secondary startup routine into the
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 82f06989..eefb30c 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -24,6 +24,8 @@
#include powerdomain.h
#include pm.h
+u16 pm44xx_errata;
+
struct power_state {
struct powerdomain *pwrdm;
u32 next_state;
@@ -199,6 +201,19 @@ static inline int omap4_init_static_deps(void)
}
/**
+ * omap4_pm_init_early - Does early initialization necessary for OMAP4+
devices
+ *
+ * Initializes basic stuff for power management functionality.
+ */
+int __init omap4_pm_init_early(void)
+{
+ if (cpu_is_omap446x())
+ pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
+
+ return 0;
+}
+
+/**
* omap4_pm_init - Init routine for OMAP4+ devices
*
* Initializes all powerdomain and clockdomain target states
--
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: next boot: 34 pass, 5 fail (next-20140122)
On 01/23/2014 01:27 PM, Tero Kristo wrote: On 01/23/2014 11:41 AM, Florian Vaussard wrote: On 01/23/2014 10:15 AM, Florian Vaussard wrote: On 01/23/2014 10:00 AM, Tero Kristo wrote: On 01/23/2014 10:14 AM, Florian Vaussard wrote: Hello, On 01/23/2014 07:23 AM, Tero Kristo wrote: On 01/23/2014 03:35 AM, Kevin Hilman wrote: On Wed, Jan 22, 2014 at 4:46 PM, Kevin's boot bot khil...@linaro.org wrote: Automated DT boot report for various ARM defconfigs. Tree/Branch: next Git describe: next-20140122 Failed boot tests (console logs at the end) === omap3-tobi,3730storm: FAIL:omap2plus_defconfig [...] omap3-tobi,3730storm: FAIL:multi_v7_defconfig These OMAP3 failures are new regressions. Full failure boot log attached. Bisected down to: cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 is the first bad commit commit cfa9667d4ac9da8b3ba2269f934ecd69ae504d39 Author: Tero Kristo t-kri...@ti.com Date: Tue Oct 22 11:53:02 2013 +0300 ARM: OMAP2+: io: use new clock init API clk_init is now separated to a common function which gets called for all SoC:s, which initializes the DT clocks and calls the SoC specific clock init. Signed-off-by: Tero Kristo t-kri...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Mike Turquette mturque...@linaro.org Kevin Hi, I think this is because the tobi board is including wrong omap3-soc.dtsi file (omap34xx.dtsi) through omap3-overo.dtsi. The board should include omap36xx.dtsi at least based on the boot log: [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) The problem is that the Overo (processor card on the Tobi extension board) can have a variety of processor depending on the exact model: - OMAP 35xx (1st generation: Air, Earth, Fire, Sand, Tide, Water, FE) - OMAP 3730 - AM/DM 37xx omap3-overo.dtsi includes omap34xx.dtsi to be compatible with the first generation. omap34xx.dtsi | - omap3-overo.dtsi (processor card) | - omap3-tobi.dtsi (expansion board) What is the fundamental incompatibility here? If we have to specifically include omap36xx for newer Overo, it will become hard to maintain as it will double the number of Overo / expansion boards possibilities. Well, you get different board declaration inside mach-omap2/board-generic.c for omap34xx vs omap36xx. The clock data issues can be fixed by adding cpu_is_omap34xx() vs. cpu_is_omap3630() checks within the mach-omap2/io.c file, but this is probably for Tony/Kevin to comment whether we can/should do that. I just tested next-20140123 with an OMAP3630 ES1.2 Overo/Tobi. Changing the include to omap36xx.dtsi do not fix the issue. I still get the external abort on non-linefetch (full log here [1]). So the issue is clearly caused by the hwmod warning just before the panic I think: omap_hwmod: usb_tll_hs: enabled state can only be entered from initialized, idle, or disabled state usb_tll_hs is thus not enabled, and we get a panic when trying to read the revision register ver = usbtll_read(tll-base, OMAP_USBTLL_REVISION); at drivers/mfd/omap-usb-tll.c:237. I do not know enough about hwmod to efficiently debug why usb_tll_hs is not _HWMOD_STATE_INITIALIZED before trying to enable it. Are we missing some DT data? The problem is the point before this one, uart4_fck lookup fails. This causes the hwmod code to bail out early and not init anything after it. I guess you are still mapping wrong clock init as it fails with uart4. Give the attached patch a shot and see how it behaves. Ok, so with your patch and changing the include from omap34xx to omap36xx, it works. Now I have to come up with a way to manage all the versions without duplicating all the DT files :-( Regards, Florian -- 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: next boot: 34 pass, 5 fail (next-20140122)
On 01/23/2014 10:35 AM, Florian Vaussard wrote: [..] Ok, so with your patch and changing the include from omap34xx to omap36xx, it works. Now I have to come up with a way to manage all the versions without duplicating all the DT files :-( you'd also want to be careful about the omap3_pmx_core2 Vs omap3_pmx_core2 split for padconf. options that come to mind are: a) split omap3-overo.dtsi into omap3-overo-common.dtsi omap3-overo-34xx.dtsi,omap3-overo-36xx.dtsi, corresponding tobi board dts file include as needed b) only have common stuff in omap3-overo.dtsi, include omap34xx.dtsi or omap36xx.dtsi in corresponding tobi board dts. -- 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: next boot: 34 pass, 5 fail (next-20140122)
* Florian Vaussard florian.vauss...@epfl.ch [140123 08:37]: On 01/23/2014 01:27 PM, Tero Kristo wrote: The problem is that the Overo (processor card on the Tobi extension board) can have a variety of processor depending on the exact model: - OMAP 35xx (1st generation: Air, Earth, Fire, Sand, Tide, Water, FE) - OMAP 3730 - AM/DM 37xx With the legacy booting, the real problem is that board-overo.c is trying to boot all overos with just one machine ID. Tero's patch works around that issue for legacy booting, but maybe it's best to do the SoC detection in the board-*.c files in init_early as needed rather than patch all the board-*.c files. Sounds like we need to do the same for legacy booting for the original beagle as well? Ok, so with your patch and changing the include from omap34xx to omap36xx, it works. Now I have to come up with a way to manage all the versions without duplicating all the DT files :-( Yeah there's no quick fix here that's suitable in the long run. The proper fix is to have minimal SoC specific .dts files for the supported overo variants that include the common board specific .dtsi file(s). We did a similar thing recently for the compulab variants, see commit 0f0cfc69547e (ARM: dts: Add support for sbc-3xxx with cm-t3730) for example. Also take a look at the follo-up patches posted to the mailing list. With device tree based booting we don't want to build data into the kernel for all the SoC variants for things like clocks, pinctrl and hwmod. And we already need to define SoC specific things in the .dts files for pinctrl with clocks and hwmod heading that way too, so relying on the built-in kernel data won't work in the long run. If we really wanted to, we could set some devices to disabled state in the bootloader or in the kernel and rely on the SoC detection. But then we're back to building all the data into the kernel. And we won't be able to boot new SoC variants with just .dts changes in the long run like device tree is supposed to do. 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: [PATCH] ARM: OMAP4+: move errata initialization to omap4_pm_init_early
Grygorii Strashko grygorii.stras...@ti.com writes: On 01/20/2014 10:06 PM, Nishanth Menon wrote: Move all OMAP4 PM errata initializations to centralized location in omap4_pm_init_early. This allows for users to utilize the erratas in various submodules as needed. Tested-by: Grygorii Strashko grygorii.stras...@ti.com This patch fixes build failure caused by patch https://patchwork.kernel.org/patch/3084521/ in case if SMP is not enabled. So does that mean that that patch can now be applied as is? We could sure use that fix (or equivalent) for CPUidle breakage on 4460. 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: [PATCH] ARM: OMAP4+: move errata initialization to omap4_pm_init_early
* Kevin Hilman khil...@linaro.org [140123 09:55]: Grygorii Strashko grygorii.stras...@ti.com writes: On 01/20/2014 10:06 PM, Nishanth Menon wrote: Move all OMAP4 PM errata initializations to centralized location in omap4_pm_init_early. This allows for users to utilize the erratas in various submodules as needed. Tested-by: Grygorii Strashko grygorii.stras...@ti.com This patch fixes build failure caused by patch https://patchwork.kernel.org/patch/3084521/ in case if SMP is not enabled. So does that mean that that patch can now be applied as is? We could sure use that fix (or equivalent) for CPUidle breakage on 4460. Yeah, seems OK to me, feel free to apply it directly: Acked-by: Tony Lindgren t...@atomide.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: [net-next PATCH v2 1/1] drivers: net: cpsw: enable promiscuous mode support
From: Mugunthan V N mugunthan...@ti.com Date: Thu, 23 Jan 2014 00:03:12 +0530 Enable promiscuous mode support for CPSW. Signed-off-by: Mugunthan V N mugunthan...@ti.com Applied, thanks. -- 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
