[RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
This patch sets gpio #interrupt-cells from a falsely acquired '1' to '2'
referring to Documentation/devicetree/bindings/gpio/gpio-omap.txt:
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
But using this trigger cell in a board specific devicetree leads to a
non-starting kernel. This is due to not yet enabled gpio-clocks while
kernel/irq/irqdomain.c tries to set this trigger-flag (from the second
interrupt-cell) to gpio-irq-controller.
Any ideas?
---
arch/arm/boot/dts/omap3.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1997b41..e8e6b8f 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -99,7 +99,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio2: gpio@4905 {
@@ -108,7 +108,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio3: gpio@49052000 {
@@ -117,7 +117,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio4: gpio@49054000 {
@@ -126,7 +126,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio5: gpio@49056000 {
@@ -135,7 +135,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio6: gpio@49058000 {
@@ -144,7 +144,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
uart1: serial@4806a000 {
--
1.7.10.4
--
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
AM3517 USB and OTG issues 3.9-rc1 kernel.
Hello All, I have a question about the updates/changes that have been made to the USB OTG support in the latest 3.9-rc1 kernel My platform is using an AM3517 processor and I am in the progress of moving from 3.6 to 3.9 kernel because I need some of the iio support in the latest 3.9 kernel. The last hurdle I have is in trying to get the USB OTG support working in HOST mode, as I am using it to connect a storage device to. If I configure the kernel in the same way as I do for 3.6 it doesn't bring the interface up. The log output is ; [0.897552] usbcore: registered new interface driver carl9170 [0.903900] usbcore: registered new interface driver cdc_ether [0.910400] usbcore: registered new interface driver cdc_ncm [0.917327] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [0.924499] ehci-omap.0 supply hsusb0 not found, using dummy regulator [0.931549] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller [0.937927] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 [1.949218] ehci-omap ehci-omap.0: irq 93, io mem 0x48064800 [1.968811] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 [1.975067] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [1.982269] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.989929] usb usb1: Product: OMAP-EHCI Host Controller [1.995544] usb usb1: Manufacturer: Linux 3.9.0-rc1 ehci_hcd [2.001556] usb usb1: SerialNumber: ehci-omap.0 [2.007507] hub 1-0:1.0: USB hub found [2.011596] hub 1-0:1.0: 3 ports detected [2.016967] usbcore: registered new interface driver cdc_wdm [2.023010] Initializing USB Mass Storage driver... [2.028472] usbcore: registered new interface driver usb-storage [2.034851] USB Mass Storage support registered. [2.040283] usbcore: registered new interface driver usbserial [2.046447] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host) [2.054107] 6Waiting for PHY clock good... [2.070343] mousedev: PS/2 mouse device common for all mice The output from 3.6 shows usb2 being initialised and recognising the connected device. [1.369934] usbcore: registered new interface driver cdc_ether [1.376373] usbcore: registered new interface driver cdc_ncm [1.383361] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.390380] ehci-omap.0 supply hsusb0 not found, using dummy regulator [1.397399] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller [1.403717] ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1 [2.443176] ehci-omap ehci-omap.0: irq 77, io mem 0x48064800 [2.458770] ehci-omap ehci-omap.0: USB 2.0 started, EHCI 1.00 [2.464935] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [2.472106] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [2.479675] usb usb1: Product: OMAP-EHCI Host Controller [2.485290] usb usb1: Manufacturer: Linux 3.6.0-rc6 ehci_hcd [2.491241] usb usb1: SerialNumber: ehci-omap.0 [2.497039] hub 1-0:1.0: USB hub found [2.501098] hub 1-0:1.0: 3 ports detected [2.506134] usbcore: registered new interface driver cdc_wdm [2.512329] usbcore: registered new interface driver uas [2.517913] Initializing USB Mass Storage driver... [2.523345] usbcore: registered new interface driver usb-storage [2.529663] USB Mass Storage support registered. [2.534484] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host) [2.541778] 6Waiting for PHY clock good... [2.560424] musb-hdrc musb-hdrc: MUSB HDRC host driver [2.566223] musb-hdrc musb-hdrc: new USB bus registered, assigned bus number 2 [2.574035] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [2.581176] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [2.588775] usb usb2: Product: MUSB HDRC host driver [2.593994] usb usb2: Manufacturer: Linux 3.6.0-rc6 musb-hcd [2.599945] usb usb2: SerialNumber: musb-hdrc [2.605651] hub 2-0:1.0: USB hub found [2.609680] hub 2-0:1.0: 1 port detected [2.614166] musb-hdrc musb-hdrc: USB Host mode controller at d080e000 using PIO, IRQ 71 [2.623504] mousedev: PS/2 mouse device common for all mice Is there a known issue with the HOST support for OTG ? Or could there be something missing from the config ? I have looked but can't see anything obvious. Any help greatly appreciated. Thanks 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: [RFC][BUG] arm/dts: OMAP3: set #interrupt-cells to two
On Sat, Mar 30, 2013 at 9:21 AM, Christoph Fritz
chf.fr...@googlemail.com wrote:
This patch sets gpio #interrupt-cells from a falsely acquired '1' to '2'
referring to Documentation/devicetree/bindings/gpio/gpio-omap.txt:
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
But using this trigger cell in a board specific devicetree leads to a
non-starting kernel. This is due to not yet enabled gpio-clocks while
kernel/irq/irqdomain.c tries to set this trigger-flag (from the second
interrupt-cell) to gpio-irq-controller.
Any ideas?
Hi Christoph,
A call to gpio_request() to enable the GPIO bank is needed before
using a GPIO as an IRQ source, otherwise accesses to the GPIO bank
registers fails making the kernel to hang. Jon's (added as cc)
gpio/omap: warn if bank is not enabled on setting irq type patch [1]
fixes the issue by warning and returning -EINVAL.
This patch will make the kernel to boot but the call to request_irq()
will fail of course. For now, the only solution is to call
gpio_request() before request_irq() in your platform code or device
driver. There is an on going discussion about what's the better way to
address this but we still haven't found a good solution to this
problem, you can see the last email for this discussion here [2]
Also, even when calling gpio_request() before request_irq() this won't
work. When specifying the trigger/level flags on the second cell for
an GPIO-IRQ, this is not set on the IORESOURCE_IRQ struct resource.
The IRQ flag is set on of_irq_to_resource() but it just does:
r-flags = IORESOURCE_IRQ;
and then the call stack is irq_to_parse_and_map() -
irq_set_irq_type() - __irq_set_trigger() - chip-irq_set_type() -
(drivers/gpio/gpio-omap.c) gpio_irq_type().
So, even when gpio_irq_type() receive the correct flags, this are not
returned neither stored on the flags member of the IORESOURCE_IRQ
struct resource that passed to the drivers in their struct
platform_device.
I have on my TODO to better investigate if this behavior is
intentional or is a bug in the interrupt core but didn't have time to
work on this yet. A relevant discussion about this is here [3].
---
arch/arm/boot/dts/omap3.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1997b41..e8e6b8f 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -99,7 +99,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio2: gpio@4905 {
@@ -108,7 +108,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio3: gpio@49052000 {
@@ -117,7 +117,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio4: gpio@49054000 {
@@ -126,7 +126,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio5: gpio@49056000 {
@@ -135,7 +135,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
gpio6: gpio@49058000 {
@@ -144,7 +144,7 @@
gpio-controller;
#gpio-cells = 2;
interrupt-controller;
- #interrupt-cells = 1;
+ #interrupt-cells = 2;
};
uart1: serial@4806a000 {
--
1.7.10.4
By the way, Jon has already sent a ARM: dts: OMAP3+: Correct gpio
#interrupts-cells property patch [4] that changes #interrupt-cells to
2 for all OMAP platforms.
Best regards,
Javier
[1]: https://patchwork.kernel.org/patch/2202511/
[2]: http://www.spinics.net/lists/linux-omap/msg89247.html
[3]: https://patchwork.kernel.org/patch/2194911/
[4]: https://patchwork.kernel.org/patch/2278081/
--
To unsubscribe from this list: send the line
Re: [PATCH] RX-51: Add leds lp5523 names from Maemo 5 2.6.28 kernel
On Sun 2013-01-20 03:50:44, Pali Rohár wrote: Signed-off-by: Pali Rohár pali.ro...@gmail.com Reviewed-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCH] RX-51: Register twl4030-madc device
On Sun 2013-01-20 03:54:26, Pali Rohár wrote: Signed-off-by: Pali Rohár pali.ro...@gmail.com Reviewed-by: Pavel Machek pa...@ucw.cz -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCH] ADP1653 board code for Nokia RX-51
Hi!
+static int __init rx51_camera_hw_init(void)
+{
+ int rval;
+
+ rval = rx51_adp1653_init();
+ if (rval)
+ return rval;
+
+ return 0;
+}
return rx51_adp1653_init(). Or better yet, rename rx51_adp1653_init
to rx51_camera_hw_init.
Thanks for all the n900 work, btw :-).
+static struct adp1653_platform_data rx51_adp1653_platform_data = {
+ .power = rx51_adp1653_power,
+ /* Must be limited to 500 ms in RX-51 */
+ .max_flash_timeout = 50, /* us */
+ /* Must be limited to 320 mA in RX-51 B3 and newer hardware */
+ .max_flash_intensity = ADP1653_FLASH_INTENSITY_REG_TO_mA(19),
+ /* Must be limited to 50 mA in RX-51 */
+ .max_torch_intensity = ADP1653_FLASH_INTENSITY_REG_TO_mA(1),
So we do 1mA to be safe?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround
Hi!
+u32 rx51_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32 arg2,
+u32 arg3, u32 arg4)
+{
+ u32 ret;
+ u32 param[5];
+
+ param[0] = nargs+1;
+ param[1] = arg1;
+ param[2] = arg2;
+ param[3] = arg3;
+ param[4] = arg4;
+
+ /*
+ * Secure API needs physical address
+ * pointer for the parameters
+ */
+ flush_cache_all();
+ outer_clean_range(__pa(param), __pa(param + 5));
+ ret = rx51_ppa_smc(idx, flag, __pa(param));
+
+ return ret;
+}
You can do without ret variable... Also more detailed changelog would
be nice... like what exact problem this works around.
google
So... some CPU errata where code sharing virtual addresses could be
executed improperly?
@@ -103,6 +104,12 @@ static void __init rx51_init(void)
rx51_peripherals_init();
rx51_camera_init();
+#ifdef CONFIG_ARM_ERRATA_430973
+ printk(KERN_INFO Enabling ARM errata 430973 workaround.\n);
+ /* set IBE to 1 */
+ rx51_secure_update_aux_cr(1 6, 0);
+#endif
+
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround
Hi,
Оригинално писмо
От: Pavel Machek
Относно: Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround
До: Pali Rohár
Изпратено на: Събота, 2013, Март 30 20:36:54 EET
Hi!
+u32 rx51_secure_dispatcher(u32 idx, u32 flag, u32 nargs, u32 arg1, u32
arg2,
+ u32 arg3, u32 arg4)
+{
+ u32 ret;
+ u32 param[5];
+
+ param[0] = nargs+1;
+ param[1] = arg1;
+ param[2] = arg2;
+ param[3] = arg3;
+ param[4] = arg4;
+
+ /*
+* Secure API needs physical address
+* pointer for the parameters
+*/
+ flush_cache_all();
+ outer_clean_range(__pa(param), __pa(param + 5));
+ ret = rx51_ppa_smc(idx, flag, __pa(param));
+
+ return ret;
+}
You can do without ret variable... Also more detailed changelog would
be nice... like what exact problem this works around.
Sure i can, but I don't see a reason to ignore SM's return value. Changelog of
what?
So... some CPU errata where code sharing virtual addresses could be
executed improperly?
@@ -103,6 +104,12 @@ static void __init rx51_init(void)
rx51_peripherals_init();
rx51_camera_init();
+#ifdef CONFIG_ARM_ERRATA_430973
+ printk(KERN_INFO quot;Enabling ARM errata 430973
workaround.#92;nquot;);
+ /* set IBE to 1 */
+ rx51_secure_update_aux_cr(1 6, 0);
+#endif
+
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
I guess if you read the thread over the ML you'll have your questions already
answered.
Or google for ARM errata 430973 workaround :).
Regards,
Ivo
--
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
[GIT PULL] ARM: OMAP2+: standardize integration for AES SHA/MD5 IP blocks for 3.10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, The following changes since commit 78e52e026d288aad88b46bff0d94b05e145c4583: ARM: OMAP2+: clock data: Remove CK_* flags (2013-03-18 09:57:39 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-a-for-3.10 for you to fetch changes up to 1cb804b93f506dfba5fd684a8ea63706aaa8e709: ARM: AM33XX: hwmod: Update and uncomment AES0 module data (2013-03-30 15:52:17 -0600) - For OMAP2+ SoCs, convert the SHA/MD5 and AES accelerator integration code and data to use hwmod and omap_device. This is a prerequisite for moving the hwmod code out of arch/arm. Basic test logs are available at: http://www.pwsan.com/omap/testlogs/sham_aes_integration_devel_3.10/20130330155313/ - vmlinux object size (delta in bytes from jk_clock_flags_cleanup_3.10 (78e52e026d288aad88b46bff0d94b05e145c4583)): text data bsstotal kernel +152 +6400 +792 n800_multi_omap2xxx +152 +5760 +728 n800_only_a 0000 omap1_defconfig 0000 omap1_defconfig_1510innovator_only +4264+22320+6496 omap2plus_defconfig +168+22320+2400 omap2plus_defconfig_cpupm +168+22320+2400 omap2plus_defconfig_no_pm +160 +6720 +832 omap2plus_defconfig_omap2_4_only +168+15600+1728 omap2plus_defconfig_omap3_4_only +316+2056 -136+2236 rmk_omap3430_ldp_allnoconfig +152+15760+1728 rmk_omap3430_ldp_oldconfig +316+2056 -136+2236 rmk_omap4430_sdp_allnoconfig +144 +8480 +992 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from jk_clock_flags_cleanup_3.10 (78e52e026d288aad88b46bff0d94b05e145c4583)) avail rsrvd high freed board kconfig -4k 4k . . 2430sdpomap2plus_defconfig -4k 4k . . 3517evmomap2plus_defconfig -4k 4k . . 3530es3beagle omap2plus_defconfig -4k 4k . . 3730beaglexm omap2plus_defconfig -4k 4k . . 37xxevmomap2plus_defconfig -4k 4k . . 4430es2panda omap2plus_defconfig -4k 4k . . 4460pandaesomap2plus_defconfig Mark A. Greer (13): ARM: OMAP2xxx: hwmod: Convert SHAM crypto device data to hwmod ARM: OMAP2xxx: hwmod: Add DMA support for SHAM module ARM: OMAP3xxx: hwmod: Convert SHAM crypto device data to hwmod ARM: OMAP2+: Remove unnecessary message when no SHA IP is present ARM: OMAP2+: Only manually add hwmod data when DT not used. ARM: AM33XX: Add sha0 crypto clock data ARM: AM33XX: hwmod: Update and uncomment SHA0 module data ARM: OMAP2xxx: hwmod: Convert AES crypto devcie data to hwmod ARM: OMAP3xxx: hwmod: Convert AES crypto device data to hwmod ARM: OMAP2+: Remove unnecessary message when no AES IP is present ARM: OMAP2+: Only manually add hwmod data when DT not used. ARM: AM33XX: Add aes0 crypto clock data ARM: AM33XX: hwmod: Update and uncomment AES0 module data arch/arm/mach-omap2/cclock2430_data.c |4 +- arch/arm/mach-omap2/cclock33xx_data.c | 10 ++ arch/arm/mach-omap2/cclock3xxx_data.c |2 + arch/arm/mach-omap2/devices.c | 149 +++-- arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 + arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 + .../mach-omap2/omap_hwmod_2xxx_interconnect_data.c | 36 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 81 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 92 +-- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 172 +++- arch/arm/mach-omap2/omap_hwmod_common_data.h |4 + 11 files changed, 401 insertions(+), 153 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJRV2q6AAoJEMePsQ0LvSpLye8P/0L3LTVp4sN2G+mQjVI7Zrkd t3GIwVJmnquh1zXlkRUjO4zFUeFN6zjnZFeCWO3kfsgppbzNJo2Z5o/CyvdehB4D mJpactIkYIOteZNW/tGJ91nXUow784552qXZaIiv9Ydxi3yMkEFU2UuusB6eHeWq 22V8gVR3r7pFu0dOcAubcaebjJiBkcX5TMqMlhO0TCQCyKRChQbeZUyCw5/1hJDA +KqdlUpw21VJhcXAhL+4AuDPXA1GSFKl4KYtdeO9ajBGAopQk7XRPyqPDlZjInXR 034BLk2WnzN3XmCq3d5b4fbrLY/Mh+G6N8f1iM++Z4vgj5h4QwsGa1UvsSRcVTFR RaQbzIFmBiwPidjXWYe2Em1JcAUTf9QM6vUalxl7mFMdXc4y+DjkSGiMdMkW6o1d YKUKodjVLbwu8ZUDcsFn6ki1pWpx+M5lKl4DHR737fpTcJggTNMGi/fiOputvsXd fbIhj4+T/+9/wzh7HXt0SgGHPswJ5QA3s5UMvZRVcHFHftkoEkyhLTp41It6a0VI gtbtHDODK7zW8V8xTz34Hj9Vra+IsJZZj6Z9F6bcv2EDNlZkTMBvQUsrSdDIqFGr Z2GSYcae5FKeib2hcee+Fv7qURGkqP329nXKmNKHFcqHV3atkxTJHnquRWNehqxy 8aQ0aNKw9K6bTmTKl3Ct =DiqN -END PGP
Re: [GIT PULL] ARM: OMAP2+: standardize integration for AES SHA/MD5 IP blocks for 3.9
Hi Tony, On Mon, 4 Mar 2013, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [130208 09:57]: For OMAP2+ SoCs, convert the SHA/MD5 and AES accelerator integration code and data to use hwmod and omap_device. This is a prerequisite for moving the hwmod code out of arch/arm. Basic test logs are available at: http://www.pwsan.com/omap/testlogs/sham_aes_integration_devel_3.9/20130208093215/ Sorry looks like I totally missed this one somehow as discussed last week. Anyways, let's get it queued early at -rc2 or so, let me know if you want to update the branch or if I should just use this pull request. Well, I missed -rc2, but here it is: http://marc.info/?l=linux-arm-kernelm=136468366425369w=2 It's got a dependency on omap-cleanup-a-for-3.10 (the clock flags removal). - Paul -- 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] Revert lockdep: check that no locks held at freeze time
This reverts commit 6aa9707099c4b25700940eb3d016f16c4434360d.
Commit 6aa970 causes problems with NFS root filesystems. The failures
were noticed on OMAP2 and 3 boards during kernel init:
[5.508148] [ BUG: swapper/0/1 still has locks held! ]
[5.513610] 3.9.0-rc3-00344-ga937536 #1 Not tainted
[5.518798] -
[5.523773] 1 lock held by swapper/0/1:
[5.527893] #0: (type-s_umount_key#13/1){+.+.+.}, at: [c011e84c]
sget+0x248/0x574
[5.536437]
[5.536437] stack backtrace:
[5.541107] [c001bba8] (unwind_backtrace+0x0/0xf0) from [c05304bc]
(rpc_wait_bit_killable+0x98/0xcc)
[5.551208] [c05304bc] (rpc_wait_bit_killable+0x98/0xcc) from [c0551600]
(__wait_on_bit+0x74/0xb8)
[5.561096] [c0551600] (__wait_on_bit+0x74/0xb8) from [c05516b0]
(out_of_line_wait_on_bit+0x6c/0x78)
[5.571166] [c05516b0] (out_of_line_wait_on_bit+0x6c/0x78) from
[c0530a0c] (__rpc_execute+0xf0/0x360)
[5.581329] [c0530a0c] (__rpc_execute+0xf0/0x360) from [c052a254]
(rpc_run_task+0x98/0xa4)
[5.590515] [c052a254] (rpc_run_task+0x98/0xa4) from [c052a374]
(rpc_call_sync+0x48/0xb4)
[5.599578] [c052a374] (rpc_call_sync+0x48/0xb4) from [c0234964]
(nfs_proc_get_root+0x48/0x124)
[5.609191] [c0234964] (nfs_proc_get_root+0x48/0x124) from [c0227300]
(nfs_get_root+0x58/0x190)
[5.618804] [c0227300] (nfs_get_root+0x58/0x190) from [c022abbc]
(nfs_fs_mount_common+0x98/0x158)
[5.628601] [c022abbc] (nfs_fs_mount_common+0x98/0x158) from [c022b440]
(nfs_try_mount+0x144/0x214)
[5.638580] [c022b440] (nfs_try_mount+0x144/0x214) from [c022c4e0]
(nfs_fs_mount+0x178/0x850)
[5.648010] [c022c4e0] (nfs_fs_mount+0x178/0x850) from [c011f6e8]
(mount_fs+0x44/0x184)
[5.656860] [c011f6e8] (mount_fs+0x44/0x184) from [c01384c4]
(vfs_kern_mount+0x4c/0xc0)
[5.665740] [c01384c4] (vfs_kern_mount+0x4c/0xc0) from [c013a6d4]
(do_mount+0x6d0/0x858)
[5.674682] [c013a6d4] (do_mount+0x6d0/0x858) from [c013a8e0]
(sys_mount+0x84/0xb8)
[5.683197] [c013a8e0] (sys_mount+0x84/0xb8) from [c075faf0]
(do_mount_root+0x24/0xb0)
[5.691986] [c075faf0] (do_mount_root+0x24/0xb0) from [c075fee4]
(mount_root+0x50/0xf8)
[5.700866] [c075fee4] (mount_root+0x50/0xf8) from [c07600ec]
(prepare_namespace+0x160/0x1c4)
[5.710296] [c07600ec] (prepare_namespace+0x160/0x1c4) from [c075f978]
(kernel_init_freeable+0x17c/0x1c4)
[5.720825] [c075f978] (kernel_init_freeable+0x17c/0x1c4) from
[c054b6c4] (kernel_init+0x8/0xe4)
[5.730529] [c054b6c4] (kernel_init+0x8/0xe4) from [c0013d90]
(ret_from_fork+0x14/0x24)
Although the rootfs mounts, the system is unstable. Here's a transcript from
a PM test:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc3/20130317194234/pm/37xxevm/37xxevm_log.txt
Here's what the test log should look like:
http://www.pwsan.com/omap/testlogs/test_v3.8/20130218214403/pm/37xxevm/37xxevm_log.txt
Mailing list discussion is here:
http://lkml.org/lkml/2013/3/4/221
Deal with this for v3.9 by reverting the problem commit, until folks can
figure out the right long-term course of action.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Mandeep Singh Baines m...@chromium.org
Cc: Jeff Layton jlay...@redhat.com
Cc: Shawn Guo shawn@linaro.org
Cc: maciej.rute...@gmail.com
Cc: Fengguang Wu fengguang...@intel.com
Cc: Trond Myklebust trond.mykleb...@netapp.com
Cc: Ingo Molnar mi...@redhat.com
Cc: Ben Chan benc...@chromium.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Tejun Heo t...@kernel.org
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Andrew Morton a...@linux-foundation.org
Cc: Linus Torvalds torva...@linux-foundation.org
---
include/linux/debug_locks.h |4 ++--
include/linux/freezer.h |3 ---
kernel/exit.c |2 +-
kernel/lockdep.c| 17 +
4 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/include/linux/debug_locks.h b/include/linux/debug_locks.h
index a975de1..3bd46f7 100644
--- a/include/linux/debug_locks.h
+++ b/include/linux/debug_locks.h
@@ -51,7 +51,7 @@ struct task_struct;
extern void debug_show_all_locks(void);
extern void debug_show_held_locks(struct task_struct *task);
extern void debug_check_no_locks_freed(const void *from, unsigned long len);
-extern void debug_check_no_locks_held(void);
+extern void debug_check_no_locks_held(struct task_struct *task);
#else
static inline void debug_show_all_locks(void)
{
@@ -67,7 +67,7 @@ debug_check_no_locks_freed(const void *from, unsigned long
len)
}
static inline void
-debug_check_no_locks_held(void)
+debug_check_no_locks_held(struct task_struct *task)
{
}
#endif
diff --git a/include/linux/freezer.h b/include/linux/freezer.h
index 043a5cf..e70df40 100644
--- a/include/linux/freezer.h
+++ b/include/linux/freezer.h
@@ -3,7 +3,6 @@
#ifndef FREEZER_H_INCLUDED
#define FREEZER_H_INCLUDED
-#include linux/debug_locks.h
#include linux/sched.h
#include linux/wait.h
#include linux/atomic.h
@@ -49,8 +48,6 @@ extern void
Re: LOCKDEP: 3.9-rc1: mount.nfs/4272 still has locks held!
On Wed, 13 Mar 2013, Jeff Layton wrote: Of course, this is all a lot of work, and not something we can shove into the kernel for 3.9 at this point. In the meantime, while Mandeep's warning is correctly pointing out a problem, I think we ought to back it out until we can fix this properly. Revert posted at: http://marc.info/?l=linux-kernelm=136468829626184w=2 Andrew or Linus, care to pick this up before for 3.9-rc? - Paul -- 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: AM3517 USB and OTG issues 3.9-rc1 kernel.
Hi, On Sat, 30 Mar 2013, Marc Murphy wrote: Hello All, I have a question about the updates/changes that have been made to the USB OTG support in the latest 3.9-rc1 kernel My platform is using an AM3517 processor and I am in the progress of moving from 3.6 to 3.9 kernel because I need some of the iio support in the latest 3.9 kernel. The last hurdle I have is in trying to get the USB OTG support working in HOST mode, as I am using it to connect a storage device to. If I configure the kernel in the same way as I do for 3.6 it doesn't bring the interface up. Maybe try resending this and cc Felipe Balbi ba...@ti.com and linux-...@vger.kernel.org? - Paul -- 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 2/8] ARM: OMAP2+: hwmod: Cleanup sidle/mstandby programming
Hi On Wed, 20 Feb 2013, Santosh Shilimkar wrote: From: Rajendra Nayak rna...@ti.com _enable_wakeup() and _disable_wakeup() are expected to program the OCP_SYSCONFIG.ENAWAKEUP bit. These functions were originally intended to take care of everything needed for the IP block to wake up the chip, including the PRCM WKEN programming. ENAWAKEUP is simply one part of that. Get rid of the additional sidle/mstandby programming in them, as its confusing (this is expected to be handled elsewhere as part of _enable_sysc()/__idle_sysc()) Sorry, why does the expectation exist for the code to enable and disable device wakeup to be part of _enable_sysc()/_idle_sysc(), rather than in functions called by _enable_sysc()/_idle_sysc()? and unnecessary. So here's part of the reason why the module wakeup control functions should remain separate. When the kernel boots, all the PM features should be disabled. Then mach-omap2/pm*.c should enables PM features where they're needed. Right now, mach-omap2/pm34xx.c sets module WKEN bits. (These direct register accesses need to be moved as part of the cleanup work, of moving the PM/PRM/CM code into drivers.) But the list of IP blocks that should be allowed to wake the system is board-dependent. So really, what mach-omap2/pm34xx.c should do is to call into the hwmod enable-wakeups code to enable MPU wakeups for all the IP blocks that have some DT property set, something like 'enable-wakeups'. Then the hwmod code should ensure that the PRM wakeup-enable and GRPSEL bits are programmed (by calling into the PRM driver code) and should then either set the ENAWAKEUP bits or put the module into smart_wkup MSTANDBY/MIDLE. Similarly, when the PM driver is unloaded, it should set no-idle on all the IP blocks that were marked as wakeup-capable and disable the PRCM wakeup control bits, by calling some hwmod disable-wakeups code. Well, the _enable_sysc()/_idle_sysc() handled only the mstandby modes correctly. So fix them so they also handle the midle modes correctly If there's a fix here, please split that out into a separate patch. - Paul -- 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 3/8] ARM: OMAP2+: hwmod: Always have OCP_SYSCONFIG.ENAWAKEUP enabled
On Wed, 20 Feb 2013, Santosh Shilimkar wrote: From: Rajendra Nayak rna...@ti.com Get rid of all complexities around when to enable OCP_SYSCONFIG.ENAWAKEUP. It should be safe to have this set *always* for all IP blocks which have this control. It should be a *dont care* when the IP is in NO/FORCE modes of sidle/mstandby. As for the SMART/SMART_WKUP modes of sidle/mstandby the framework anyway sets this always. Tested-by: Vaibhav Bedia vaibhav.be...@ti.com Tested-by: Sourav Poddar sourav.pod...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Some of the comments here: http://marc.info/?l=linux-omapm=136469345727226w=2 apply to this patch as well. - Paul -- 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 6/8] SERIAL: OMAP: Remove the slave idle handling from the driver
Hi On Wed, 20 Feb 2013, Santosh Shilimkar wrote: UART IP slave idle handling now taken care by runtime pm backend(hwmod layer) so remove the hackery from the driver. Tested-by: Vaibhav Bedia vaibhav.be...@ti.com Tested-by: Sourav Poddar sourav.pod...@ti.com Signed-off-by: Rajendra nayak rna...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com I'm fine with the basic idea. But based on rmk's and your subsequent comments, please add some comments to the driver in this patch that encapsulates what needs to be done to get DMA working again properly, including the idle mode switching, in the unlikely event that someone will try to get that working again. - Paul -- 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/8] ARM: OMAP2+: hwmod: Remove unused _HWMOD_WAKEUP_ENABLED flag
On Wed, 20 Feb 2013, Santosh Shilimkar wrote: From: Rajendra Nayak rna...@ti.com _HWMOD_WAKEUP_ENABLED is currently unused across the hwmod framework. Just get rid of it, so we have one less flag to worry about. Tested-by: Vaibhav Bedia vaibhav.be...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks, queued for 3.9. - Paul -- 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/2] ARM: OMAP2+: AM33xx: hwmod: Add missing sysc definition to wdt1 entry
On Fri, 29 Mar 2013, Vaibhav Hiremath wrote: This patch adds sysc definitions to the wdt1 hwmod entry, which in-turn makes sure that sysc idle bit-fields are configured to valid state on enable/disable callbacks. With the recent submitted patch from Santosh Shilimkar, ARM: OMAP2+: hwmod: Don't call _init_mpu_rt_base if no sysc (commit: 4a98c2d89), it is required to add sysconf information to each valid hwmod entry, else device will not be come out from idle state properly and leads to below kernel crash - [2.190237] Unhandled fault: external abort on non-linefetch (0x1028) at 0xf9e35034 [2.198325] Internal error: : 1028 [#1] SMP ARM [2.203101] Modules linked in: [2.206334] CPU: 0Not tainted (3.9.0-rc3-00059-gd114294#1) [2.212679] PC is at omap_wdt_disable.clone.5+0xc/0x60 [2.218090] LR is at omap_wdt_probe+0x184/0x1fc Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson benoit.cous...@linaro.org Cc: Paul Walmsley p...@pwsan.com Thanks, queued for 3.10. - Paul -- 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 2/2] ARM: OMAP2+: am335x: Change the wdt1 func clk src to per_32k clk
On Fri, 29 Mar 2013, Vaibhav Hiremath wrote: WDT1 module can take one of the below clocks as input functional clock - - On-Chip 32K RC Osc [default/reset] - 32K from PRCM The On-Chip 32K RC Osc clock is not an accurate clock-source as per the design/spec, so as a result, for example, timer which supposed to get expired @60Sec, but will expire somewhere ~@40Sec, which is not expected by any use-case. The solution here is to switch the input clock-source to PRCM generated 32K clock-source during boot-time itself. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson benoit.cous...@linaro.org Cc: Paul Walmsley p...@pwsan.com Thanks, queued for 3.10. - Paul -- 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/8] ARM: OMAP2+: hwmod: Remove unused _HWMOD_WAKEUP_ENABLED flag
On Sun, 31 Mar 2013, Paul Walmsley wrote: On Wed, 20 Feb 2013, Santosh Shilimkar wrote: From: Rajendra Nayak rna...@ti.com _HWMOD_WAKEUP_ENABLED is currently unused across the hwmod framework. Just get rid of it, so we have one less flag to worry about. Tested-by: Vaibhav Bedia vaibhav.be...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks, queued for 3.9. Err, 3.10, rather. - Paul -- 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: [RFC][PATCH 0/5] Introduce .get_voltage callback into voltdm
Hi Mike, Kevin, On Wed, 3 Oct 2012, Mike Turquette wrote: From: Mike Turquette mturque...@linaro.org This series creates a new callback for struct voltagedomain, .get_voltage. This fetches the voltage from hardware, if possible, and returns it to the caller. We use this call to populate voltdm-nominal_volt at boot time. Just checking on the status of this series. Is this superseded by Andrii's driver? Does it need to be reposted for merging? etc. - Paul -- 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
