Re: [PATCH v2] omap: dma: Clear status registers on enable/disable irq.
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [120604 15:01]: On Tue, 15 May 2012 14:35:08 Oleg Matcovschi wrote: Use omap_disable_channel_irq() function instead of directly accessing CICR. The omap_disable_chanel_irq() function clears pending interrupts and disables interrupt on channel. Functions omap2_enable_irq_lch()/omap2_disable_irq_lch() clear interrupt status register. Signed-off-by: Oleg Matcovschi oleg.matcovs...@ti.com --- v1 initial revision v2 Review by Tony Lindgren My Tested-by: on OMAP1 still valid for v2 if you care. OK good to hear, will add that. 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: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
* Rajendra Nayak rna...@ti.com [120601 05:13]: The data is autogenerated using the OMAP autogeneration scripts (python scripts). Thanks to Mike Turquette for the initial efforts in updating the script which was later updated by me. All data is added into a new cclock44xx_data.c file, a later patch will get rid of clock44xx_data.c file. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/cclock44xx_data.c | 2602 +++ arch/arm/mach-omap2/clock.h | 17 + arch/arm/mach-omap2/clock_common_data.c | 14 + arch/arm/mach-omap2/scrm44xx.h |2 + 4 files changed, 2635 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c If you are adding new data anyways, why not add it to drivers/clock/omap to start with? 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
Please help! AM35xx mm/slab.c BUG
All, I'm **really** hoping someone out there can help us with this. My team has been working with the AM3517 for several months now, and we seem to be plagued every so often by what we have termed the slab bug. In short, it looks something like the pasted bootlog below. This has been an *incredibly* hard bug to figure out. We have a couple of different AM3517-based platforms at our disposal, but the one we see the issue on almost exclusively is a custom, prototype baseboard designed around the TechNexion TAM3157. Over the last several months, we have tried several versions of the Linux off the linux-omap tree, with loads of different configurations, and even different bootloader versions and combinations. We've spent most of our time with a linux-omap snapshot that was a 3.2-rc6, and more recently a 3.4-rc6 from late a week or two back. (Tomorrow I anticipate pulling the latest 3.5 now that I see it's out.) In all cases, since we switched to 3.0+, we've seen these errors. They are *very* inconsistent in when they occur, but they happen often enough to be very frustrating. Consequently, our team has had an incredibly difficult time tracking what's causing them. They seem to occur at random, perhaps on average once every handful of days. We've messed with everything we can think of from tweaking kernel options (like enabling/disabling preemption), to disabling various drivers and userspace components, to reviewing every single line in any of our board files. We have tried different versions and combinations of the OS and both bootloaders (x-loader u-boot), and even went so far as to do a full analysis of the RAM timings in the EMIF4. Unfortunately, nothing so far has worked. The error occurs when operating off both the SD/MMC and the NAND devices, with or without the Ethernets (LAN9221 EMAC) up and/or running, with or without PREEMPT, under heavy load and sometimes just idling, ... There is simply nothing consistent about it. After probably 2 weeks without seeing one, I saw 3 today. Though the error's occurence is inconistent, the error itself is. It always throws an internal OOPs at the following section of code in mm/slab.c: --- /* * The slab was either on partial or free list so * there must be at least one object available for * allocation. */ BUG_ON(slabp-inuse = cachep-num); --- (It appears this was patched in eons ago: https://lkml.org/lkml/2007/2/19/20. So it's nothing new.) Under our Linux 3.2-rc6, the error is listed as line 3109. Under our Linux 3.4-rc6, it is line 3175. I'm FAR from a Linux MM expert, and we've do NO customization there. So, I'm hoping someone on here will see something they recognize, or at least be able to help us get more debugging in there to try to get more information. Amazingly, Google has been little help on this one. It seems we're the only folks in the world having this issue. Can anyone *please* help us sort out what's happening here? Or even just suggest where to start looking? Below is a very recent snapshot of our full boot + the crash, this time on poweroff though it can happen any time. We have probably close to 15 of these crashes on file if anyone could use more information. I just chose not to spam them all on here. (*NOTE: These bootloaders kernel sources are highly customized now. So, you may notice that the processor detects as an AM3505 instead of a 3517 because we've removed features unnecessary to our project, such as the SGX, from our software. That being said, these errors have occurred on the very base builds before any customization. Please look around that unless you see something really unexplainable. Given taht we've seen these errors before any of the customizations, we do not believe they are the culprit. Similarly, those ECC ERRORS you see relate to us having to use Micron's on-die ECC for our 4-bit NAND. We've not gotten the bootloaders and Linux to play nicely with it yet without using the on-die support. The ERRORS are simply referencing the first block, which is managed with a 1-bit ECC instead of the 4-bit. So, other non-x-loader processes see that section as an error when reading it.) Thanks in advance for your help! Texas Instruments X-Loader 1.51-dirty (May 29 2012 - 14:05:44) Enable Micron on-die ECC engine Detected board: TEST_TAM3517+ Starting X-loader on MMC Reading boot sector 448240 Bytes Read from MMC Starting 'u-boot.bin' from MMC... Starting OS Bootloader... U-Boot 2012.04.01-00083-g0834508-dirty (Jun 04 2012 - 18:35:28) AM35XX-GP ES2.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 Mhz TEST_TAM3517+ Board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc (Micron NAND 512MiB 1,8V 16-bit) 512 MiB MMC: OMAP SD/MMC: 0 Scanning device for bad blocks ERROR: ON-DIE ECC READ FAILURE ERROR: ON-DIE ECC READ FAILURE ERROR: ON-DIE ECC READ FAILURE ERROR: ON-DIE ECC READ FAILURE ERROR: ON-DIE ECC
Re: [RFC 13/24] ARM: omap4: clk: Add 44xx data using common struct clk
* Tony Lindgren t...@atomide.com [120604 23:47]: * Rajendra Nayak rna...@ti.com [120601 05:13]: The data is autogenerated using the OMAP autogeneration scripts (python scripts). Thanks to Mike Turquette for the initial efforts in updating the script which was later updated by me. All data is added into a new cclock44xx_data.c file, a later patch will get rid of clock44xx_data.c file. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/cclock44xx_data.c | 2602 +++ arch/arm/mach-omap2/clock.h | 17 + arch/arm/mach-omap2/clock_common_data.c | 14 + arch/arm/mach-omap2/scrm44xx.h |2 + 4 files changed, 2635 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-omap2/cclock44xx_data.c If you are adding new data anyways, why not add it to drivers/clock/omap to start with? Sorry I mean drivers/clk/omap. 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: Please help! AM35xx mm/slab.c BUG
* CF Adad cfa...@rocketmail.com [120604 23:47]: All, I'm **really** hoping someone out there can help us with this. My team has been working with the AM3517 for several months now, and we seem to be plagued every so often by what we have termed the slab bug. In short, it looks something like the pasted bootlog below. This has been an *incredibly* hard bug to figure out. We have a couple of different AM3517-based platforms at our disposal, but the one we see the issue on almost exclusively is a custom, prototype baseboard designed around the TechNexion TAM3157. Over the last several months, we have tried several versions of the Linux off the linux-omap tree, with loads of different configurations, and even different bootloader versions and combinations. We've spent most of our time with a linux-omap snapshot that was a 3.2-rc6, and more recently a 3.4-rc6 from late a week or two back. (Tomorrow I anticipate pulling the latest 3.5 now that I see it's out.) In all cases, since we switched to 3.0+, we've seen these errors. They are *very* inconsistent in when they occur, but they happen often enough to be very frustrating. Consequently, our team has had an incredibly difficult time tracking what's causing them. They seem to occur at random, perhaps on average once every handful of days. We've messed with everything we can think of from tweaking kernel options (like enabling/disabling preemption), to disabling various drivers and userspace components, to reviewing every single line in any of our board files. We have tried different versions and combinations of the OS and both bootloaders (x-loader u-boot), and even went so far as to do a full analysis of the RAM timings in the EMIF4. Unfortunately, nothing so far has worked. The error occurs when operating off both the SD/MMC and the NAND devices, with or without the Ethernets (LAN9221 EMAC) up and/or running, with or without PREEMPT, under heavy load and sometimes just idling, ... There is simply nothing consistent about it. After probably 2 weeks without seeing one, I saw 3 today. Though the error's occurence is inconistent, the error itself is. It always throws an internal OOPs at the following section of code in mm/slab.c: --- /* * The slab was either on partial or free list so * there must be at least one object available for * allocation. */ BUG_ON(slabp-inuse = cachep-num); --- (It appears this was patched in eons ago: https://lkml.org/lkml/2007/2/19/20. So it's nothing new.) I can think of at least three issues causing errors like this: 1. Missing retention/off idle workarounds You can test this one by booting with nohlt cmdline option and seeing if that helps. 2. Broken memory I've seen at least one case of this where things would work fine if only half of the memory was in use and devices would oops at random point within a week. To test for this you can pass cmdline options to artifically partition the memory and leave out some chunks to see if that helps. Or boot with mem=xxxM set to half of the physical memory. And run your tests with SLAB_DEBUG set. 3. Software bugs My experience is that things are behaving very reliably regarding cache and highmem, so I would check #1 and #2 fist. 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 v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc
* Mohammed, Afzal af...@ti.com [120525 03:20]: Hi Tony, On Fri, May 25, 2012 at 12:56:59, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [120523 17:55]: On Tue, 22 May 2012, Tony Lindgren wrote: Unfortunately for many of the older boards these values will probably remain unknown. So the better approach here is to just disable frequency scaling for these cases. Otherwise we'll be breaking old boards with smsc911x where the timings for the FPGA controlling smsc911x are unknown. If we somehow manage to get those values without breaking support for these boards, then yes I agree we should deprecate hardcoded and bootloader values. I was thinking that if we log the register values supplied by the bootloader to the console, then someone can write a patch to the board file or DT data to set those register values explicitly in the kernel, once they're known. Or at least just report them to the l-o list. So then that should reduce the problem cases down to boards which no one reports the data to the mailing list within a few mainline kernel releases -- i.e., boards which are unmaintained. For those boards, I'd suggest that we just drop GPMC support until someone shows up who has a board and can test-boot it. Or just drop the board completely ;-) OK seems fair to me. It still allows us to boot the older boards with minimal changes (but without L3 frequency scaling). Sounds like those registers should be dumped only if no configuration is specified to avoid spamming the console. Shall I take it as go ahead to create a patch on Documentation/feature-removal-schedule.txt in the next version of gpmc series stating that implicit boot loader GPMC timings will be removed in three Kernel releases ? (i.e. as per Paul's suggestion, along with other points he has mentioned) Yes sure as long as we can see what needs to be set in the kernel. The GPMC timings should only come from the bootloader in the device tree case BTW, so that's also something to consider here. 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: [RESUBMIT PATCH] ARM: OMAP2+: am33xx: Add low level debugging support
* Hiremath, Vaibhav hvaib...@ti.com [120528 23:17]: On Thu, May 10, 2012 at 14:23:01, Hiremath, Vaibhav wrote: From: Afzal Mohammed af...@ti.com Add support for low level debugging on AM335X EVM (AM33XX family). Currently only support for UART1 console, which is used on AM335X EVM is added. Signed-off-by: Afzal Mohammed af...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Reviewed-by: Kevin Hilman khil...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com --- This patch had been Reviewed and accepted earlier, but got missed during last merge window. Resubmitting again, without code-change. arch/arm/mach-omap2/include/mach/debug-macro.S | 17 - arch/arm/plat-omap/include/plat/serial.h |4 arch/arm/plat-omap/include/plat/uncompress.h |6 ++ 3 files changed, 26 insertions(+), 1 deletions(-) Tony, Can this be merged now??? Yes applying into devel-am33xx branch. 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: OMAP2+: am33xx: Add AM335XEVM machine support
* Hiremath, Vaibhav hvaib...@ti.com [120528 23:17]: On Fri, May 11, 2012 at 00:38:49, Hiremath, Vaibhav wrote: From: Afzal Mohammed af...@ti.com This patch adds minimal support for AM335X machine init. During last merge window, two separate patches supporting am33xx machine init had been submitted, 1. Link to earlier Baseport patch submission (Legacy): http://www.mail-archive.com/linux-omap@vger.kernel.org/msg59325.html 2. Link to earlier DT based machine init support patch submission: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg61398.html And both had got accepted at that time, but got missed during merge window. But now, since we have taken decision to make am33xx as a separate class and not to follow omap3 family, these patches needs to changes accordingly (only changes), - Combine both the patches, since early init and timer init used in board-generic.c file requires them. - Remove dependency on AM3517EVM, and only use DT approach for machine init. - Change the config option (as changed recently) CONFIG_SOC_OMAPAM33XX -- CONFIG_SOC_AM33XX Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/board-generic.c | 18 ++ arch/arm/mach-omap2/common.h|2 ++ arch/arm/mach-omap2/io.c| 10 ++ arch/arm/mach-omap2/irq.c |2 +- arch/arm/mach-omap2/timer.c |5 + 5 files changed, 36 insertions(+), 1 deletions(-) Tony, Can this be merged now??? Adding this too to devel-am33xx branch. 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: OMAP2+: am33xx: Add AM335XEVM machine support
On Tue, Jun 05, 2012 at 13:23:44, Tony Lindgren wrote: * Hiremath, Vaibhav hvaib...@ti.com [120528 23:17]: On Fri, May 11, 2012 at 00:38:49, Hiremath, Vaibhav wrote: From: Afzal Mohammed af...@ti.com This patch adds minimal support for AM335X machine init. During last merge window, two separate patches supporting am33xx machine init had been submitted, 1. Link to earlier Baseport patch submission (Legacy): http://www.mail-archive.com/linux-omap@vger.kernel.org/msg59325.html 2. Link to earlier DT based machine init support patch submission: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg61398.html And both had got accepted at that time, but got missed during merge window. But now, since we have taken decision to make am33xx as a separate class and not to follow omap3 family, these patches needs to changes accordingly (only changes), - Combine both the patches, since early init and timer init used in board-generic.c file requires them. - Remove dependency on AM3517EVM, and only use DT approach for machine init. - Change the config option (as changed recently) CONFIG_SOC_OMAPAM33XX -- CONFIG_SOC_AM33XX Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/board-generic.c | 18 ++ arch/arm/mach-omap2/common.h|2 ++ arch/arm/mach-omap2/io.c| 10 ++ arch/arm/mach-omap2/irq.c |2 +- arch/arm/mach-omap2/timer.c |5 + 5 files changed, 36 insertions(+), 1 deletions(-) Tony, Can this be merged now??? Adding this too to devel-am33xx branch. Thanks Tony, Also, request you to add it as part of next pull request to the linux-next, at early rc cycle itself. Paul, Can you also send a pull request for AM33XX voltagedomain, cm, clockdomain, prm, powerdomain patches? Also request you to review clock-tree and hwmod changes, so that, they can also be merged within time. From clocktree perspective, I believe now I have to migrate to Rajendr's common-clock framework changes, so let me finish that and send new version. Thanks, Vaibhav -- 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-V2 0/4] ARM: OMAP2+: am33xx: Add clocktree and hwmod data
On Tue, Jun 05, 2012 at 13:29:52, Tony Lindgren wrote: * Vaibhav Hiremath hvaib...@ti.com [120529 03:01]: This patch adds complete clockctree and hwmod data for the AM33XX family of devices. This patch-series is cleaned up further from Paul's cleanup activity on AM33xx clocktree, where all leaf nodes have been removed and now modules enable/disable is controlled only using hwmod framework interface. There are certain modules, like clkdiv32k, debugss, etc..., for which we still doesn't have hwmod_data present, so in order to disable these modules during boot time, we still have to maintain clk node for them. Comment has been added to highlight this, and in the future we will cleanup this. As far as, CLKDIV32K module, in reality is not module but still we have MODULEMODE to control it, so we may have to keep this node alone in the clocktree. Considering that we have the RFC patches available for common clk fwk, we should probably avoid the extra churn and have this use the common clk fwk instead. Of course that is assuming the common clk fwk patches will be mergeable soonish. Tony, I am not quite sure how much time it will take to merge common clock changes from Rajendra, since it is still in RFC stage and may take couple merge windows. I would recommend to merge clock-tree and hwmod patches atleast to the linux-next, so that it gets validated for some time and we atleast would be able to boot the BeagleBone (community board) from linux-next/master. People can start further development using this on BeagleBone platform. Based on common-clock migration activity on OMAP, we can certainly make decision on pushing it to Mainline (Linus's) tree. And also I will start basing AM33XX clocktree on Rajendra's patches, so that it will get merged at the same time. Thanks, Vaibhav -- 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-V2 0/4] ARM: OMAP2+: am33xx: Add clocktree and hwmod data
* Hiremath, Vaibhav hvaib...@ti.com [120605 01:27]: On Tue, Jun 05, 2012 at 13:29:52, Tony Lindgren wrote: * Vaibhav Hiremath hvaib...@ti.com [120529 03:01]: This patch adds complete clockctree and hwmod data for the AM33XX family of devices. This patch-series is cleaned up further from Paul's cleanup activity on AM33xx clocktree, where all leaf nodes have been removed and now modules enable/disable is controlled only using hwmod framework interface. There are certain modules, like clkdiv32k, debugss, etc..., for which we still doesn't have hwmod_data present, so in order to disable these modules during boot time, we still have to maintain clk node for them. Comment has been added to highlight this, and in the future we will cleanup this. As far as, CLKDIV32K module, in reality is not module but still we have MODULEMODE to control it, so we may have to keep this node alone in the clocktree. Considering that we have the RFC patches available for common clk fwk, we should probably avoid the extra churn and have this use the common clk fwk instead. Of course that is assuming the common clk fwk patches will be mergeable soonish. Tony, I am not quite sure how much time it will take to merge common clock changes from Rajendra, since it is still in RFC stage and may take couple merge windows. I would recommend to merge clock-tree and hwmod patches atleast to the linux-next, so that it gets validated for some time and we atleast would be able to boot the BeagleBone (community board) from linux-next/master. People can start further development using this on BeagleBone platform. Based on common-clock migration activity on OMAP, we can certainly make decision on pushing it to Mainline (Linus's) tree. And also I will start basing AM33XX clocktree on Rajendra's patches, so that it will get merged at the same time. OK that sounds fair to me. Let's see what Paul and Rajendra say, it's really up to them to make the call. We need minimize the extra load for Paul and Rajendra here as it's already a big effort. 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-V2 0/4] ARM: OMAP2+: am33xx: Add clocktree and hwmod data
On Tue, Jun 05, 2012 at 13:29:52, Tony Lindgren wrote: * Vaibhav Hiremath hvaib...@ti.com [120529 03:01]: This patch adds complete clockctree and hwmod data for the AM33XX family of devices. This patch-series is cleaned up further from Paul's cleanup activity on AM33xx clocktree, where all leaf nodes have been removed and now modules enable/disable is controlled only using hwmod framework interface. There are certain modules, like clkdiv32k, debugss, etc..., for which we still doesn't have hwmod_data present, so in order to disable these modules during boot time, we still have to maintain clk node for them. Comment has been added to highlight this, and in the future we will cleanup this. As far as, CLKDIV32K module, in reality is not module but still we have MODULEMODE to control it, so we may have to keep this node alone in the clocktree. Considering that we have the RFC patches available for common clk fwk, we should probably avoid the extra churn and have this use the common clk fwk instead. Of course that is assuming the common clk fwk patches will be mergeable soonish. I will try to make sure that, their effort is only required for review (nothing else). Lets here from Paul and Rajendra on this. It would be really great if we decide to merge them to linux next, People really can start using linux-next/master for further development on BeagleBone. Thanks, Vaibhav -- 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/5] usb: musb: cleanup
Most part of this patch series was obtained by splitting [RFC PATCH 2/3] usb: musb: omap glue: use omap-usb2 as the phy driver. TO DO: * dt adaptation of musb omap glue, twl4030, twl6030. * Use control module driver API to write to control module registers (mailbox and power control of phy) * send usb2 phy driver * make musb omap glue make use of usb2 phy driver and make twl630 as a comparator driver. Patch series depends on [PATCH v4 0/3] usb: multi-phy support Performed device mode testing in omap4 panda and omap3 beagle Kishon Vijay Abraham I (5): usb: musb: move work_struct(otg_notifier_work) from core to omap glue usb: musb: twl: use mailbox API to send VBUS or ID events drivers: usb: musb: move otg specific initializations from twl to glue usb: musb: omap: use devres API to allocate resources drivers: usb: otg: twl: use devres API to allocate resources drivers/usb/musb/musb_core.h |2 - drivers/usb/musb/omap2430.c | 118 +--- drivers/usb/otg/twl4030-usb.c | 63 -- drivers/usb/otg/twl6030-usb.c | 69 include/linux/usb/musb-omap.h | 30 ++ 5 files changed, 150 insertions(+), 132 deletions(-) create mode 100644 include/linux/usb/musb-omap.h -- 1.7.5.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
[PATCH 1/5] usb: musb: move work_struct(otg_notifier_work) from core to omap glue
Commit 712d8e fixed pm_runtime calls while atomic by using a work queue.
While the issue and the work queue implementation is specific to omap
(omap2430.c), the work_struct is defined as a member of struct musb
(musb_core.h). Hence moved the work_struct from musb_core to omap
glue.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/musb_core.h |2 --
drivers/usb/musb/omap2430.c | 24 +++-
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index f4a40f0..dbcdeea 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -327,7 +327,6 @@ struct musb {
irqreturn_t (*isr)(int, void *);
struct work_struct irq_work;
- struct work_struct otg_notifier_work;
u16 hwvers;
/* this hub status bit is reserved by USB 2.0 and not seen by usbcore */
@@ -373,7 +372,6 @@ struct musb {
u16 int_tx;
struct usb_phy *xceiv;
- u8 xceiv_event;
int nIrq;
unsignedirq_wake:1;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index e279cf3..f40c805 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -41,6 +41,8 @@
struct omap2430_glue {
struct device *dev;
struct platform_device *musb;
+ u8 xceiv_event;
+ struct work_struct omap_musb_mailbox_work;
};
#define glue_to_musb(g)platform_get_drvdata(g-musb)
@@ -226,22 +228,26 @@ static inline void omap2430_low_level_init(struct musb
*musb)
static int musb_otg_notifications(struct notifier_block *nb,
unsigned long event, void *unused)
{
- struct musb *musb = container_of(nb, struct musb, nb);
+ struct musb *musb = container_of(nb, struct musb, nb);
+ struct device *dev = musb-controller;
+ struct omap2430_glue*glue = dev_get_drvdata(dev-parent);
- musb-xceiv_event = event;
- schedule_work(musb-otg_notifier_work);
+ glue-xceiv_event = event;
+ schedule_work(glue-omap_musb_mailbox_work);
return NOTIFY_OK;
}
-static void musb_otg_notifier_work(struct work_struct *data_notifier_work)
+static void omap_musb_mailbox_work(struct work_struct *data_notifier_work)
{
- struct musb *musb = container_of(data_notifier_work, struct musb,
otg_notifier_work);
+ struct omap2430_glue *glue = container_of(data_notifier_work,
+ struct omap2430_glue, omap_musb_mailbox_work);
+ struct musb *musb = glue_to_musb(glue);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
struct omap_musb_board_data *data = pdata-board_data;
- switch (musb-xceiv_event) {
+ switch (glue-xceiv_event) {
case USB_EVENT_ID:
dev_dbg(musb-controller, ID GND\n);
@@ -298,8 +304,6 @@ static int omap2430_musb_init(struct musb *musb)
return -ENODEV;
}
- INIT_WORK(musb-otg_notifier_work, musb_otg_notifier_work);
-
status = pm_runtime_get_sync(dev);
if (status 0) {
dev_err(dev, pm_runtime_get_sync FAILED %d\n, status);
@@ -388,7 +392,6 @@ static void omap2430_musb_disable(struct musb *musb)
static int omap2430_musb_exit(struct musb *musb)
{
del_timer_sync(musb_idle_timer);
- cancel_work_sync(musb-otg_notifier_work);
omap2430_low_level_exit(musb);
usb_put_phy(musb-xceiv);
@@ -441,6 +444,8 @@ static int __devinit omap2430_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, glue);
+ INIT_WORK(glue-omap_musb_mailbox_work, omap_musb_mailbox_work);
+
ret = platform_device_add_resources(musb, pdev-resource,
pdev-num_resources);
if (ret) {
@@ -478,6 +483,7 @@ static int __devexit omap2430_remove(struct platform_device
*pdev)
{
struct omap2430_glue*glue = platform_get_drvdata(pdev);
+ cancel_work_sync(glue-omap_musb_mailbox_work);
platform_device_del(glue-musb);
platform_device_put(glue-musb);
kfree(glue);
--
1.7.5.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
[PATCH 5/5] drivers: usb: otg: twl: use devres API to allocate resources
used devres API while allocating memory resource in twl4030 and twl6030
so that these resources are released automatically on driver detach.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/otg/twl4030-usb.c | 15 +++
drivers/usb/otg/twl6030-usb.c | 16 +++-
2 files changed, 6 insertions(+), 25 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 03368c3..49b127a 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -589,15 +589,13 @@ static int __devinit twl4030_usb_probe(struct
platform_device *pdev)
return -EINVAL;
}
- twl = kzalloc(sizeof *twl, GFP_KERNEL);
+ twl = devm_kzalloc(pdev-dev, sizeof *twl, GFP_KERNEL);
if (!twl)
return -ENOMEM;
- otg = kzalloc(sizeof *otg, GFP_KERNEL);
- if (!otg) {
- kfree(twl);
+ otg = devm_kzalloc(pdev-dev, sizeof *otg, GFP_KERNEL);
+ if (!otg)
return -ENOMEM;
- }
twl-dev= pdev-dev;
twl-irq= platform_get_irq(pdev, 0);
@@ -621,8 +619,6 @@ static int __devinit twl4030_usb_probe(struct
platform_device *pdev)
err = twl4030_usb_ldo_init(twl);
if (err) {
dev_err(pdev-dev, ldo init failed\n);
- kfree(otg);
- kfree(twl);
return err;
}
usb_add_phy(twl-phy, USB_PHY_TYPE_USB2);
@@ -646,8 +642,6 @@ static int __devinit twl4030_usb_probe(struct
platform_device *pdev)
if (status 0) {
dev_dbg(pdev-dev, can't get IRQ %d, err %d\n,
twl-irq, status);
- kfree(otg);
- kfree(twl);
return status;
}
@@ -691,9 +685,6 @@ static int __exit twl4030_usb_remove(struct platform_device
*pdev)
regulator_put(twl-usb1v8);
regulator_put(twl-usb3v1);
- kfree(twl-phy.otg);
- kfree(twl);
-
return 0;
}
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 66cfea7..600c27a 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -395,15 +395,13 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
struct device *dev = pdev-dev;
pdata = dev-platform_data;
- twl = kzalloc(sizeof *twl, GFP_KERNEL);
+ twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
return -ENOMEM;
- otg = kzalloc(sizeof *otg, GFP_KERNEL);
- if (!otg) {
- kfree(twl);
+ otg = devm_kzalloc(dev, sizeof *otg, GFP_KERNEL);
+ if (!otg)
return -ENOMEM;
- }
twl-dev= pdev-dev;
twl-irq1 = platform_get_irq(pdev, 0);
@@ -430,8 +428,6 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
err = twl6030_usb_ldo_init(twl);
if (err) {
dev_err(pdev-dev, ldo init failed\n);
- kfree(otg);
- kfree(twl);
return err;
}
usb_add_phy(twl-phy, USB_PHY_TYPE_USB2);
@@ -450,8 +446,6 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
dev_err(pdev-dev, can't get IRQ %d, err %d\n,
twl-irq1, status);
device_remove_file(twl-dev, dev_attr_vbus);
- kfree(otg);
- kfree(twl);
return status;
}
@@ -463,8 +457,6 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
twl-irq2, status);
free_irq(twl-irq1, twl);
device_remove_file(twl-dev, dev_attr_vbus);
- kfree(otg);
- kfree(twl);
return status;
}
@@ -495,8 +487,6 @@ static int __exit twl6030_usb_remove(struct platform_device
*pdev)
pdata-phy_exit(twl-dev);
device_remove_file(twl-dev, dev_attr_vbus);
cancel_work_sync(twl-set_vbus_work);
- kfree(twl-phy.otg);
- kfree(twl);
return 0;
}
--
1.7.5.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
[PATCH 4/5] usb: musb: omap: use devres API to allocate resources
used devres API while allocating memory resource and while getting
usb phy so that these resources are released automatically on driver
detach.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c | 19 +++
1 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 24d1cd5..f895d99 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -319,7 +319,7 @@ static int omap2430_musb_init(struct musb *musb)
* up through ULPI. TWL4030-family PMICs include one,
* which needs a driver, drivers aren't always needed.
*/
- musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
+ musb-xceiv = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
if (!musb-xceiv) {
pr_err(HS USB OTG: no transceiver configured\n);
return -ENODEV;
@@ -416,7 +416,6 @@ static int omap2430_musb_exit(struct musb *musb)
del_timer_sync(musb_idle_timer);
omap2430_low_level_exit(musb);
- usb_put_phy(musb-xceiv);
return 0;
}
@@ -443,7 +442,7 @@ static int __devinit omap2430_probe(struct platform_device
*pdev)
struct omap2430_glue*glue;
int ret = -ENOMEM;
- glue = kzalloc(sizeof(*glue), GFP_KERNEL);
+ glue = devm_kzalloc(pdev-dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
dev_err(pdev-dev, failed to allocate glue context\n);
goto err0;
@@ -452,7 +451,7 @@ static int __devinit omap2430_probe(struct platform_device
*pdev)
musb = platform_device_alloc(musb-hdrc, -1);
if (!musb) {
dev_err(pdev-dev, failed to allocate musb device\n);
- goto err1;
+ goto err0;
}
musb-dev.parent= pdev-dev;
@@ -479,13 +478,13 @@ static int __devinit omap2430_probe(struct
platform_device *pdev)
pdev-num_resources);
if (ret) {
dev_err(pdev-dev, failed to add resources\n);
- goto err2;
+ goto err1;
}
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(pdev-dev, failed to add platform_data\n);
- goto err2;
+ goto err1;
}
pm_runtime_enable(pdev-dev);
@@ -493,16 +492,13 @@ static int __devinit omap2430_probe(struct
platform_device *pdev)
ret = platform_device_add(musb);
if (ret) {
dev_err(pdev-dev, failed to register musb device\n);
- goto err2;
+ goto err1;
}
return 0;
-err2:
- platform_device_put(musb);
-
err1:
- kfree(glue);
+ platform_device_put(musb);
err0:
return ret;
@@ -515,7 +511,6 @@ static int __devexit omap2430_remove(struct platform_device
*pdev)
cancel_work_sync(glue-omap_musb_mailbox_work);
platform_device_del(glue-musb);
platform_device_put(glue-musb);
- kfree(glue);
return 0;
}
--
1.7.5.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
[PATCH 3/5] drivers: usb: musb: move otg specific initializations from twl to glue
Moved otg specific state(OTG_STATE_B_IDLE, OTG_STATE_A_IDLE) initializations
from twl to glue. These initializations are removed from twl4030 and
twl6030 and moved to the mailbox API defined in glue.
This is part of the cleanup in preparation to make use of usb2 phy
driver.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c |5 +
drivers/usb/otg/twl4030-usb.c |8
drivers/usb/otg/twl6030-usb.c |6 --
3 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 7139e57..24d1cd5 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -249,11 +249,14 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
struct omap_musb_board_data *data = pdata-board_data;
+ struct usb_otg *otg = musb-xceiv-otg;
switch (glue-status) {
case OMAP_MUSB_ID_GROUND:
dev_dbg(dev, ID GND\n);
+ otg-default_a = true;
+ musb-xceiv-state = OTG_STATE_A_IDLE;
musb-xceiv-last_event = USB_EVENT_ID;
if (!is_otg_enabled(musb) || musb-gadget_driver) {
pm_runtime_get_sync(dev);
@@ -265,6 +268,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
case OMAP_MUSB_VBUS_VALID:
dev_dbg(dev, VBUS Connect\n);
+ otg-default_a = false;
+ musb-xceiv-state = OTG_STATE_B_IDLE;
musb-xceiv-last_event = USB_EVENT_VBUS;
if (musb-gadget_driver)
pm_runtime_get_sync(dev);
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 05dc659..03368c3 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -251,7 +251,6 @@ static enum omap_musb_vbus_id_status
{
int status;
enum omap_musb_vbus_id_status linkstat = OMAP_MUSB_UNKNOWN;
- struct usb_otg *otg = twl-phy.otg;
twl-vbus_supplied = false;
@@ -289,13 +288,6 @@ static enum omap_musb_vbus_id_status
spin_lock_irq(twl-lock);
twl-linkstat = linkstat;
- if (linkstat == OMAP_MUSB_ID_GROUND) {
- otg-default_a = true;
- twl-phy.state = OTG_STATE_A_IDLE;
- } else {
- otg-default_a = false;
- twl-phy.state = OTG_STATE_B_IDLE;
- }
spin_unlock_irq(twl-lock);
return linkstat;
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6c75883..66cfea7 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -256,7 +256,6 @@ static DEVICE_ATTR(vbus, 0444, twl6030_usb_vbus_show, NULL);
static irqreturn_t twl6030_usb_irq(int irq, void *_twl)
{
struct twl6030_usb *twl = _twl;
- struct usb_otg *otg = twl-phy.otg;
enum omap_musb_vbus_id_status status = OMAP_MUSB_UNKNOWN;
u8 vbus_state, hw_state;
@@ -269,8 +268,6 @@ static irqreturn_t twl6030_usb_irq(int irq, void *_twl)
regulator_enable(twl-usb3v3);
twl-asleep = 1;
status = OMAP_MUSB_VBUS_VALID;
- otg-default_a = false;
- twl-phy.state = OTG_STATE_B_IDLE;
twl-linkstat = status;
omap_musb_mailbox(status);
} else {
@@ -293,7 +290,6 @@ static irqreturn_t twl6030_usb_irq(int irq, void *_twl)
static irqreturn_t twl6030_usbotg_irq(int irq, void *_twl)
{
struct twl6030_usb *twl = _twl;
- struct usb_otg *otg = twl-phy.otg;
enum omap_musb_vbus_id_status status = OMAP_MUSB_UNKNOWN;
u8 hw_state;
@@ -307,8 +303,6 @@ static irqreturn_t twl6030_usbotg_irq(int irq, void *_twl)
twl6030_writeb(twl, TWL_MODULE_USB, USB_ID_INT_EN_HI_SET,
0x10);
status = OMAP_MUSB_ID_GROUND;
- otg-default_a = true;
- twl-phy.state = OTG_STATE_A_IDLE;
twl-linkstat = status;
omap_musb_mailbox(status);
} else {
--
1.7.5.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
[PATCH 2/5] usb: musb: twl: use mailbox API to send VBUS or ID events
The atomic notifier from twl4030/twl6030 to notifiy VBUS and ID events,
is replaced by a direct call to omap musb blue.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c | 90 ++---
drivers/usb/otg/twl4030-usb.c | 42 +--
drivers/usb/otg/twl6030-usb.c | 47 +
include/linux/usb/musb-omap.h | 30 ++
4 files changed, 128 insertions(+), 81 deletions(-)
create mode 100644 include/linux/usb/musb-omap.h
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f40c805..7139e57 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -34,6 +34,7 @@
#include linux/dma-mapping.h
#include linux/pm_runtime.h
#include linux/err.h
+#include linux/usb/musb-omap.h
#include musb_core.h
#include omap2430.h
@@ -41,11 +42,13 @@
struct omap2430_glue {
struct device *dev;
struct platform_device *musb;
- u8 xceiv_event;
+ enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
};
#define glue_to_musb(g)platform_get_drvdata(g-musb)
+struct omap2430_glue *_glue;
+
static struct timer_list musb_idle_timer;
static void musb_do_idle(unsigned long _musb)
@@ -225,50 +228,54 @@ static inline void omap2430_low_level_init(struct musb
*musb)
musb_writel(musb-mregs, OTG_FORCESTDBY, l);
}
-static int musb_otg_notifications(struct notifier_block *nb,
- unsigned long event, void *unused)
+void omap_musb_mailbox(enum omap_musb_vbus_id_status status)
{
- struct musb *musb = container_of(nb, struct musb, nb);
- struct device *dev = musb-controller;
- struct omap2430_glue*glue = dev_get_drvdata(dev-parent);
+ struct omap2430_glue*glue = _glue;
+ struct musb *musb = glue_to_musb(glue);
- glue-xceiv_event = event;
- schedule_work(glue-omap_musb_mailbox_work);
+ glue-status = status;
+ if (!musb) {
+ dev_err(glue-dev, musb core is not yet ready\n);
+ return;
+ }
- return NOTIFY_OK;
+ schedule_work(glue-omap_musb_mailbox_work);
}
+EXPORT_SYMBOL_GPL(omap_musb_mailbox);
-static void omap_musb_mailbox_work(struct work_struct *data_notifier_work)
+static void omap_musb_set_mailbox(struct omap2430_glue *glue)
{
- struct omap2430_glue *glue = container_of(data_notifier_work,
- struct omap2430_glue, omap_musb_mailbox_work);
struct musb *musb = glue_to_musb(glue);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
struct omap_musb_board_data *data = pdata-board_data;
- switch (glue-xceiv_event) {
- case USB_EVENT_ID:
- dev_dbg(musb-controller, ID GND\n);
+ switch (glue-status) {
+ case OMAP_MUSB_ID_GROUND:
+ dev_dbg(dev, ID GND\n);
+ musb-xceiv-last_event = USB_EVENT_ID;
if (!is_otg_enabled(musb) || musb-gadget_driver) {
- pm_runtime_get_sync(musb-controller);
+ pm_runtime_get_sync(dev);
usb_phy_init(musb-xceiv);
omap2430_musb_set_vbus(musb, 1);
}
break;
- case USB_EVENT_VBUS:
- dev_dbg(musb-controller, VBUS Connect\n);
+ case OMAP_MUSB_VBUS_VALID:
+ dev_dbg(dev, VBUS Connect\n);
+ musb-xceiv-last_event = USB_EVENT_VBUS;
if (musb-gadget_driver)
- pm_runtime_get_sync(musb-controller);
+ pm_runtime_get_sync(dev);
usb_phy_init(musb-xceiv);
break;
- case USB_EVENT_NONE:
- dev_dbg(musb-controller, VBUS Disconnect\n);
+ case OMAP_MUSB_ID_FLOAT:
+ case OMAP_MUSB_VBUS_OFF:
+ dev_dbg(dev, VBUS Disconnect\n);
+ musb-xceiv-last_event = USB_EVENT_NONE;
if (is_otg_enabled(musb) || is_peripheral_enabled(musb))
if (musb-gadget_driver) {
pm_runtime_mark_last_busy(musb-controller);
@@ -282,15 +289,24 @@ static void omap_musb_mailbox_work(struct work_struct
*data_notifier_work)
usb_phy_shutdown(musb-xceiv);
break;
default:
- dev_dbg(musb-controller, ID float\n);
+ dev_dbg(dev, ID float\n);
}
}
+
+static void omap_musb_mailbox_work(struct work_struct *mailbox_work)
+{
+ struct omap2430_glue *glue = container_of(mailbox_work,
+ struct omap2430_glue, omap_musb_mailbox_work);
+ omap_musb_set_mailbox(glue);
+}
+
static int omap2430_musb_init(struct musb *musb)
{
u32 l;
int status =
Re: [PATCH 2/2] remoteproc: remove the now-redundant kref
On Tue, Jun 5, 2012 at 12:22 AM, Stephen Boyd sb...@codeaurora.org wrote: Option 1 is nicer and it also follows the model other subsystems have put forth such as the input subsystem. Sounds good, 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
Re: [PATCH] remoteproc: block premature rproc booting
On Tue, Jun 5, 2012 at 12:23 AM, Stephen Boyd sb...@codeaurora.org wrote: I thought we wanted to allow both calls to proceed in parallel? If we don't care about that Yeah, I don't think we do. then announcing it once the firmware is found the first time sounds correct. I agree. Though this patch may be moot very soon due to: The main reason we kept the get/put interface was to make it easier for you guys to adopt it, but I've been re-thinking lately whether we really want that interface. It's a problematic interface with non-negligible maintenance burden, and the code will be greatly simplified without it. If nobody in the kernel is using it why keep it? I was concerned that the non get/put interface might not suit everyone, and I planned to wait for another user or two to show up before I remove that interface. Since MSM's PIL is based on a get/put interface, I actually hoped to see if you guys can adopt the new interface before we ditch the get/put one. If MSM needs we can add it back when we move to rproc. Thanks - that's the kind of feedback I wanted to get. I think we'll need to have some way to describe the resources in the kernel when we register the rproc. We aren't going to be able to change our firmware to have the resource section. What about using a separate file for the resource table ? That should be very easy to support, and may make life easier for you in the long term. Resource tables tend to change in time, and hard coding it in the kernel doesn't sound ideal (both in terms of development overhead, and kernel-firmware backward and forward compatibility). Getting to that point would require changing smd code to be more linux device model friendly. We're exploring using virtio over smd (basically virtqueues would replace smd APIs while we replace the vrings with smd wire protocol). That sounds good. If that works out then we'll be able to attach the smd virtio device to the remote proc via some in kernel resource list. Please consider using an external file for the resource table. That should give you more flexibility and less overhead. One sticking point has been the desire to shut down processors when they're not in use and reclaim the memory. Also we would like to upgrade the firmware without rebooting the phone. Do you have any plans for that? It looks like the current design boots anything that is registered and has a matching rpmsg driver. I suppose one solution is to use modules but that looks like it disrupts other processors (I don't want to rmmod all of rpmsg). We probably need some sort of shutdown/boot mechanism that isn't driven entirely by the client drivers. Does the below work for you (sans the OMAP terminology ;) ? root@omap4430-panda:/sys/bus/platform/drivers/omap-rproc# echo omap-rproc.1 unbind [ 471.376556] remoteproc remoteproc0: releasing ipu_c0 root@omap4430-panda:/sys/bus/platform/drivers/omap-rproc# echo omap-rproc.1 bind [ 478.219177] remoteproc remoteproc0: ipu_c0 is available [ 478.224639] remoteproc remoteproc0: Note: remoteproc is still under development and considered experimental. [ 478.235015] remoteproc remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed. [ 478.325347] remoteproc remoteproc0: registered virtio0 (type 7) [ 478.331848] remoteproc remoteproc0: registered virtio1 (type 3) This way user space can unbind a specific remote processor (which will also trigger unbinding the entire device hierarchy below it, i.e. all rpmsg/virtio devices). Thanks, Ohad. -- 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 v3] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
* Kevin Hilman khil...@ti.com [120523 16:15]: Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of default uart pads) removed default uart pads that where getting populated and which was making rx pin wakeup capable. If uart pads were used in different mode by any other module then it would fail since the default pads took over all the uart pins forcefully. With removal of default pads the rx_pad wakeup for console uart while waking up from off mode is broken. Utilise the mux api available to probe the availability of mux pins in uart mode and probe for availability of uart pin in mux mode0 if uart is available as uart pin itself then configure rx pin as wakeup capable. This patch itself doesn't cater to all boards. Boards using uart rx wakeup mechanism should ensure the usage of omap_serial_init_port by configuring required uart ports and pass necessary mux data, till then this probing of uart pins can cater to enabling of rx pad wakeup to most of the boards. This patch can also throw some boot warning from _omap_mux_get_by_name if pin is requested for availability is not present while dynamically probing the uart pins availability such boot warnings can be addressed only when board files are patched with omap_serial_init_port calls passing the right pads needed for a given port. Discussion Threads for reference: http://www.spinics.net/lists/linux-omap/msg69859.html http://www.spinics.net/lists/linux-omap/msg68659.html Cc: Felipe Balbi ba...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Russ Dill russ.d...@gmail.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Ameya Palande ameya.pala...@ti.com Signed-off-by: Govindraj.R govindraj.r...@ti.com Tony, it's up to you if you're OK with this mux interface, but I can at least confirm that this gets runtime PM + UART wakeups working again on the boards I tried: 3530/Overo, 3430/n900, 3530/OMAP3EVM. OK good to hear. Patch looks good to me, applying into fixes branch. 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 v3] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
* Govindraj.R govindraj.r...@ti.com [120511 02:45]:
From: Govindraj.R govindraj.r...@ti.com
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
#else
-static void omap_serial_fill_default_pads(struct omap_board_data *bdata) {}
+static void __init omap_serial_check_wakeup(struct omap_board_data *bdata
+ struct omap_uart_state *uart) {}
#endif
There's a comma missing here that breaks CONFIG_OMAP_MUX is not set here ^^^.
I've updated the patch to add it.
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 1/5] usb: musb: move work_struct(otg_notifier_work) from core to omap glue
Hello. On 05-06-2012 13:38, Kishon Vijay Abraham I wrote: Commit 712d8e Please also specify that commit's summary in parens. fixed pm_runtime calls while atomic by using a work queue. While the issue and the work queue implementation is specific to omap (omap2430.c), the work_struct is defined as a member of struct musb (musb_core.h). Hence moved the work_struct from musb_core to omap glue. Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com WBR, Sergei -- 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: [GIT PULL] OMAP DSS for v3.5
Hi Tomi, On Tue, May 22, 2012 at 12:09 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi Florian, Here are the OMAP DSS changes for 3.5. I really tried this time to send the pull request early, but here I am again, sending it when the merge window has already opened... A few late-found bugs caused some unnecessary delays. I'm using github this time instead of gitorious, as gitorious seems to be down. This is my first pull request with a signed tag, I hope everything is correct. Note that there's a merge for small branch with omap board file changes (e4a9e94cc58ed6e4efb02b80be3a9bf57f448d07) that is also pulled by Tony for the linux-omap tree. This is meant to help avoid conflicts in the board files. Tomi The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c: Linux 3.4-rc4 (2012-04-21 14:47:52 -0700) are available in the git repository at: git://github.com/tomba/linux.git tags/omapdss-for-3.5 for you to fetch changes up to e92a5b28f71aea01b281f9c89d97a4bc5b24748f: OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request (2012-05-22 11:00:09 +0300) Omapdss driver changes for 3.5 merge window. Lots of normal development commits, but perhaps most notable changes are: * HDMI rework to properly decouple the HDMI audio part from the HDMI video part. * Restructure omapdss core driver so that it's possible to implement device tree support. This included changing how platform data is passed to the drivers, changing display device registration and improving the panel driver's ability to configure the underlying video output interface. * Basic support for DSI packet interleaving I am using a mainline kernel (3.5.0-rc1) with the patches below integrated. I have an issue with suspend/resume on OMAP3 Beagleboard, where the system hangs at resume time. Here below is a log with the option no_console_suspend set and a few added messages in case of null pointer in _od_resume_noirq. It looks like there is no omap_device associated to the omapdss_dpi pdev. What do you think? How to fix this? Sorry I know there have been some discussions on the lists but I am not aware of all the details in the devices creation for DSS. / # echo mem /sys/power/state [ 23.262298] PM: Syncing filesystems ... done. [ 23.295501] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 23.326507] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 23.502197] PM: suspend of devices complete after 163.766 msecs [ 23.511932] PM: late suspend of devices complete after 3.418 msecs [ 23.52] PM: noirq suspend of devices complete after 5.860 msecs [ 23.531249] Disabling non-boot CPUs ... [ 24.476562] Powerdomain (per_pwrdm) didn't enter target state 1 [ 24.482818] Powerdomain (core_pwrdm) didn't enter target state 1 [ 24.489166] Could not enter target state in pm_suspend [ 24.495147] *** _od_resume_noirq: od=NULL, dev=0xc78bcc08 [ 24.500915] *** _od_resume_noirq: od=NULL, pdev=0xc78bcc00 [ 24.506805] *** _od_resume_noirq: od=NULL, pdev-name:omapdss_dpi [ 24.513336] Unable to handle kernel NULL pointer dereference at virtual addre ss 0018 [ 24.521942] pgd = c62f [ 24.524841] [0018] *pgd=862c1831, *pte=, *ppte= [ 24.531524] Internal error: Oops: 17 [#1] SMP ARM [ 24.536529] Modules linked in: [ 24.539764] CPU: 0Not tainted (3.5.0-rc1-00010-g5041caa-dirty #131) [ 24.546844] PC is at _od_resume_noirq+0x1c/0xac [ 24.551635] LR is at _od_resume_noirq+0x94/0xac ... Regards, Jean Archit Taneja (19): OMAPDSS: DISPC/RFBI: Use dispc_mgr_set_lcd_timings() for setting lcd size OMAPDSS: DISPC: Use a common function to set manager timings OMAPDSS: DISPC: Clean up manager timing/size functions OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump OMAPDSS: HDMI: define and dump CORE registers in correct order OMAPDSS: Fix DSI_FCLK clock source selection OMAPDSS: DISPC: Remove Fake VSYNC support OMAPDSS: APPLY: Add manager timings as extra_info in private data OMAPDSS: Apply manager timings instead of direct DISPC writes OMAPDSS: MANAGER: Create a function to check manager timings OMAPDSS: APPLY: Don't check manager settings if it is disabled OMAPDSS: APPLY: Remove display dependency from overlay and manager checks OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate() OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device() OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC OMAPDSS:
Re: [GIT PULL] OMAP DSS for v3.5
Hi Jean,
On Tue, 2012-06-05 at 14:17 +0200, Jean Pihet wrote:
Hi Tomi,
I am using a mainline kernel (3.5.0-rc1) with the patches below integrated.
I have an issue with suspend/resume on OMAP3 Beagleboard, where the
system hangs at resume time.
Here below is a log with the option no_console_suspend set and a few
added messages in case of null pointer in _od_resume_noirq.
It looks like there is no omap_device associated to the omapdss_dpi pdev.
What do you think? How to fix this?
Sorry I know there have been some discussions on the lists but I am
not aware of all the details in the devices creation for DSS.
/ # echo mem /sys/power/state
[ 23.262298] PM: Syncing filesystems ... done.
[ 23.295501] Freezing user space processes ... (elapsed 0.02 seconds) done.
[ 23.326507] Freezing remaining freezable tasks ... (elapsed 0.02 seconds)
don
e.
[ 23.502197] PM: suspend of devices complete after 163.766 msecs
[ 23.511932] PM: late suspend of devices complete after 3.418 msecs
[ 23.52] PM: noirq suspend of devices complete after 5.860 msecs
[ 23.531249] Disabling non-boot CPUs ...
[ 24.476562] Powerdomain (per_pwrdm) didn't enter target state 1
[ 24.482818] Powerdomain (core_pwrdm) didn't enter target state 1
[ 24.489166] Could not enter target state in pm_suspend
[ 24.495147] *** _od_resume_noirq: od=NULL, dev=0xc78bcc08
[ 24.500915] *** _od_resume_noirq: od=NULL, pdev=0xc78bcc00
[ 24.506805] *** _od_resume_noirq: od=NULL, pdev-name:omapdss_dpi
[ 24.513336] Unable to handle kernel NULL pointer dereference at virtual
addre
ss 0018
[ 24.521942] pgd = c62f
[ 24.524841] [0018] *pgd=862c1831, *pte=, *ppte=
[ 24.531524] Internal error: Oops: 17 [#1] SMP ARM
[ 24.536529] Modules linked in:
[ 24.539764] CPU: 0Not tainted (3.5.0-rc1-00010-g5041caa-dirty #131)
[ 24.546844] PC is at _od_resume_noirq+0x1c/0xac
[ 24.551635] LR is at _od_resume_noirq+0x94/0xac
...
I'm on leave currently, so I can't test it right now. But can you try
the attached patch? Or even better, try merging the tag:
git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.5-rc2
which contains the included patch plus a couple other fixes.
Tomi
From 4ea30e9e0f2956b2ebcf1e81ac08d7c6691cf32d Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Tue, 5 Jun 2012 13:17:32 +0300
Subject: [PATCH] OMAPDSS: fix registration of DPI and SDI devices
The omapdss arch initialization code registers all the output devices as
omap_devices. However, DPI and SDI are not proper omap_devices, as they
do not have any corresponding HWMOD. This leads to crashes or problems
when the platform code tries to use omap_device functions for DPI and
SDI devices.
One such crash was reported by John Stultz johns...@us.ibm.com:
[ 18.756835] Unable to handle kernel NULL pointer dereference at
virtual addr8
[ 18.765319] pgd = ea6b8000
[ 18.768188] [0018] *pgd=aa942831, *pte=, *ppte=
[ 18.774749] Internal error: Oops: 17 [#1] SMP ARM
[ 18.779663] Modules linked in:
[ 18.782836] CPU: 0Not tainted (3.5.0-rc1-dirty #456)
[ 18.788482] PC is at _od_resume_noirq+0x1c/0x78
[ 18.793212] LR is at _od_resume_noirq+0x6c/0x78
[ 18.797943] pc : [c00307ec]lr : [c003083c]psr: 2113
[ 18.797943] sp : ec3abe80 ip : ec3abdb8 fp : 0006
[ 18.809936] r10: ec1148b8 r9 : c08a48f0 r8 : c00307d0
[ 18.815368] r7 : r6 : r5 : ec114800 r4 :
ec114808
[ 18.822174] r3 : r2 : r1 : ec154fe8 r0 :
0006
[ 18.829010] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM
Segment user
[ 18.836456] Control: 10c5387d Table: aa6b804a DAC: 0015
[ 18.842437] Process sh (pid: 1139, stack limit = 0xec3aa2f0)
[ 18.848358] Stack: (0xec3abe80 to 0xec3ac000)
DPI and SDI can be plain platform_devices. This patch changes the
registration from omap_device_register() to platform_device_add().
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Reported-by: John Stultz johns...@us.ibm.com
---
arch/arm/mach-omap2/display.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 54d49dd..5fb47a1 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -271,9 +271,9 @@ static struct platform_device *create_simple_dss_pdev(const char *pdev_name,
goto err;
}
- r = omap_device_register(pdev);
+ r = platform_device_add(pdev);
if (r) {
- pr_err(Could not register omap_device for %s\n, pdev_name);
+ pr_err(Could not register platform_device for %s\n, pdev_name);
goto err;
}
--
1.7.9.5
signature.asc
Description: This is a digitally signed message part
Re: [GIT PULL] OMAP DSS for v3.5
Hi Tomi, On Tue, Jun 5, 2012 at 2:33 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi Jean, On Tue, 2012-06-05 at 14:17 +0200, Jean Pihet wrote: Hi Tomi, I am using a mainline kernel (3.5.0-rc1) with the patches below integrated. I have an issue with suspend/resume on OMAP3 Beagleboard, where the system hangs at resume time. Here below is a log with the option no_console_suspend set and a few added messages in case of null pointer in _od_resume_noirq. It looks like there is no omap_device associated to the omapdss_dpi pdev. What do you think? How to fix this? Sorry I know there have been some discussions on the lists but I am not aware of all the details in the devices creation for DSS. / # echo mem /sys/power/state [ 23.262298] PM: Syncing filesystems ... done. [ 23.295501] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 23.326507] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 23.502197] PM: suspend of devices complete after 163.766 msecs [ 23.511932] PM: late suspend of devices complete after 3.418 msecs [ 23.52] PM: noirq suspend of devices complete after 5.860 msecs [ 23.531249] Disabling non-boot CPUs ... [ 24.476562] Powerdomain (per_pwrdm) didn't enter target state 1 [ 24.482818] Powerdomain (core_pwrdm) didn't enter target state 1 [ 24.489166] Could not enter target state in pm_suspend [ 24.495147] *** _od_resume_noirq: od=NULL, dev=0xc78bcc08 [ 24.500915] *** _od_resume_noirq: od=NULL, pdev=0xc78bcc00 [ 24.506805] *** _od_resume_noirq: od=NULL, pdev-name:omapdss_dpi [ 24.513336] Unable to handle kernel NULL pointer dereference at virtual addre ss 0018 [ 24.521942] pgd = c62f [ 24.524841] [0018] *pgd=862c1831, *pte=, *ppte= [ 24.531524] Internal error: Oops: 17 [#1] SMP ARM [ 24.536529] Modules linked in: [ 24.539764] CPU: 0 Not tainted (3.5.0-rc1-00010-g5041caa-dirty #131) [ 24.546844] PC is at _od_resume_noirq+0x1c/0xac [ 24.551635] LR is at _od_resume_noirq+0x94/0xac ... I'm on leave currently, so I can't test it right now. But can you try Oh sorry about that! the attached patch? Or even better, try merging the tag: That fixes it! I am able to suspend/resume correctly now. git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.5-rc2 which contains the included patch plus a couple other fixes. Thanks for the link, that is certainly useful! Have a nice time on leave ;-p Tomi Regards, Jean -- 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 05/24] ARM: omap: clk: Nuke plat clock.c clock.h if CONFIG_COMMON_CLK
Hi Rajendra,
On 06/04/2012 11:58 PM, Rajendra Nayak wrote:
Hi Jon,
On 06/04/2012 09:16 AM, Rajendra Nayak wrote:
+/* struct clksel_rate.flags possibilities */
+#define RATE_IN_242X(1 0)
+#define RATE_IN_243X(1 1)
+#define RATE_IN_3430ES1(1 2)/* 3430ES1 rates only */
+#define RATE_IN_3430ES2PLUS(1 3)/* 3430 ES= 2 rates
only */
+#define RATE_IN_36XX(1 4)
+#define RATE_IN_4430(1 5)
+#define RATE_IN_TI816X(1 6)
+#define RATE_IN_4460(1 7)
+#define RATE_IN_AM33XX(1 8)
+#define RATE_IN_TI814X(1 9)
+
+#define RATE_IN_24XX(RATE_IN_242X | RATE_IN_243X)
+#define RATE_IN_34XX(RATE_IN_3430ES1 | RATE_IN_3430ES2PLUS)
+#define RATE_IN_3XXX(RATE_IN_34XX | RATE_IN_36XX)
+#define RATE_IN_44XX(RATE_IN_4430 | RATE_IN_4460)
+
+/* RATE_IN_3430ES2PLUS_36XX includes 34xx/35xx with ES=2, and all
36xx/37xx */
+#define RATE_IN_3430ES2PLUS_36XX(RATE_IN_3430ES2PLUS |
RATE_IN_36XX)
+
+/* Platform flags for the clkdev-OMAP integration code */
+#define CK_242X(1 4)
+#define CK_243X(1 5)/* 243x, 253x */
+#define CK_3430ES1(1 6)/* 34xxES1 only */
+#define CK_3430ES2PLUS(1 7)/* 34xxES2, ES3,
non-Sitara 35xx only */
+#define CK_3505(1 8)
+#define CK_3517(1 9)
+#define CK_36XX(1 10) /* 36xx/37xx-specific
clocks */
+#define CK_443X(1 11)
+#define CK_TI816X(1 12)
+#define CK_446X(1 13)
+
+#define CK_34XX(CK_3430ES1 | CK_3430ES2PLUS)
+#define CK_AM35XX(CK_3505 | CK_3517) /* all Sitara AM35xx */
+#define CK_3XXX(CK_34XX | CK_AM35XX | CK_36XX)
I am not sure why we should duplicate these defines in an OMAP2
specific
header. What not just leave in plat clock.h where we have all the
RATE_IN_xxx and CK_xxx for all OMAP devices?
These get removed from the file which is used for OMAP1 in a later
patch. Like I said the idea was to separate out whats needed for OMAP1
(using legacy struct clk) and OMAP2+ (using common struct clk) with
both headers residing in respective mach-omap folders. (The RFC I posted
still had the OMAP1 file in plat-omap)
But these definitions are unrelated to whether you use common clock or
legacy. So why move them?
I am really fine either way, I don;t see a big issue in keeping these
in plat clock.h and some others with ifdefs around for COMMON_CLK.
The bigger issue is moving OMAP1 to common clk and I don't plan to do
it as part of this series.
Ok, thanks. I guess ultimately it is Paul's decision but you know my
preference ;-)
As for omap1, I was not expecting you/we convert this at this point.
That is not my goal either. However, just to make sure that if and when
we do it will not be such a massive churn.
+/**
+ * struct clksel_rate - register bitfield values corresponding to
clk divisors
+ * @val: register bitfield value (shifted to bit 0)
+ * @div: clock divisor corresponding to @val
+ * @flags: (see struct clksel_rate.flags possibilities above)
+ *
+ * @val should match the value of a read from struct clk.clksel_reg
+ * AND'ed with struct clk.clksel_mask, shifted right to bit 0.
+ *
+ * @div is the divisor that should be applied to the parent clock's
rate
+ * to produce the current clock's rate.
+ */
+struct clksel_rate {
+u32val;
+u8div;
+u8flags;
+};
+
+/**
+ * struct clksel - available parent clocks, and a pointer to their
divisors
+ * @parent: struct clk * to a possible parent clock
+ * @rates: available divisors for this parent clock
+ *
+ * A struct clksel is always associated with one or more struct clks
+ * and one or more struct clksel_rates.
+ */
+struct clksel {
+struct clk*parent;
+const struct clksel_rate*rates;
+};
These above clksel structures would be need for omap1 devices so
that we
could use the clock framework to set the parent clock. So why not keep
in plat clock.h?
We could, but that alone wouldn't be enough if we move OMAP2+ alone to
common clk, it would mean we duplicate the clksel handling code too,
and if we do that, maybe its not that bad to just duplicate a couple
more struct definitions.
So I have tested the legacy clksel code on omap1 and it works. So I
would hope that the common clock version of clksel would work too for
omap1 (if we move omap1 to the common clock framework).
Yes, *if we move omap1 to common clock* :-)
Agree :-)
Thanks
Jon
--
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/6] ARM: OMAP4: PMU: Add runtime PM support
Hi Will,
On 06/04/2012 04:44 PM, Jon Hunter wrote:
[...]
diff --git a/arch/arm/kernel/pmu.c b/arch/arm/kernel/pmu.c
index 2334bf8..8ffbb09 100644
--- a/arch/arm/kernel/pmu.c
+++ b/arch/arm/kernel/pmu.c
@@ -13,6 +13,8 @@
#include linux/err.h
#include linux/kernel.h
#include linux/module.h
+#include linux/pm_runtime.h
+#include linux/platform_device.h
#include asm/pmu.h
@@ -22,15 +24,17 @@
static unsigned long pmu_lock[BITS_TO_LONGS(ARM_NUM_PMU_DEVICES)];
int
-reserve_pmu(enum arm_pmu_type type)
+reserve_pmu(struct arm_pmu *armpmu)
{
- return test_and_set_bit_lock(type, pmu_lock) ? -EBUSY : 0;
+ pm_runtime_get_sync(armpmu-plat_device-dev);
+ return test_and_set_bit_lock(armpmu-type, pmu_lock) ? -EBUSY : 0;
}
EXPORT_SYMBOL_GPL(reserve_pmu);
void
-release_pmu(enum arm_pmu_type type)
+release_pmu(struct arm_pmu *armpmu)
{
- clear_bit_unlock(type, pmu_lock);
+ clear_bit_unlock(armpmu-type, pmu_lock);
+ pm_runtime_put_sync(armpmu-plat_device-dev);
}
EXPORT_SYMBOL_GPL(release_pmu);
I have realised that there is a slight bug in the above
pm_runtime_get/put. The calls to pm_runtime_get/put need to be
symmetrical otherwise the if we call _get more than _put the pmu will
stay on. So in the reserve_pmu, I should only call pm_runtime_get if we
acquire the lock.
Anyway, let me know what you think of this approach. An alternative is
to put the calls pm_runtime_get/put outside of the reserve/release_pmu,
which would be a simpler change, but I was thinking that the above maybe
more aligned with your thinking.
Cheers
Jon
--
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: Broken builds
Hi, On Tue, 2012-06-05 at 01:22 -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [120603 11:05]: Looks like the DSS stuff has broken OMAP builds again during this merge window: drivers/video/omap2/dss/core.c:197: error: static declaration of 'dss_debugfs_create_file' follows non-static declaration drivers/video/omap2/dss/dss.h:166: error: previous declaration of 'dss_debugfs_create_file' was here Both the OMAP3 and OMAP4 builds break with these two errors. Here's a patch for Tomi to fix this one. I have a patch for this in my for-rc branch. It just missed the main merge. I'll send this and a few other fixes today for the next rc. Btw, it compiles if you have debugfs and DSS_DEBUG_SUPPORT enabled. That's why I didn't notice it until too late. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH-V2 0/4] ARM: OMAP2+: am33xx: Add clocktree and hwmod data
Considering that we have the RFC patches available for common clk fwk, we should probably avoid the extra churn and have this use the common clk fwk instead. Of course that is assuming the common clk fwk patches will be mergeable soonish. Tony, I am not quite sure how much time it will take to merge common clock changes from Rajendra, since it is still in RFC stage and may take couple merge I am certainly hoping it does not take couple of merge windows and plan to get it in good shape for 3.6. windows. I would recommend to merge clock-tree and hwmod patches atleast to the linux-next, so that it gets validated for some time and we atleast would be able to boot the BeagleBone (community board) from linux-next/master. People can start further development using this on BeagleBone platform. Based on common-clock migration activity on OMAP, we can certainly make decision on pushing it to Mainline (Linus's) tree. And also I will start basing AM33XX clocktree on Rajendra's patches, so that it will get merged at the same time. OK that sounds fair to me. Let's see what Paul and Rajendra say, it's really up to them to make the call. We need minimize the extra load for Paul and Rajendra here as it's already a big effort. -- 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] OMAP DSS for v3.5-rc2
Hi Florian, Here are 5 small fixes for omapdss. The most important is the fix registration... patch, without which omapdss crashes when suspending/resuming. The compilation bug (fix build...) is also rather annoying for those users not interested in debug outputs. The rest are quite minor small fixes. It'd be great if these made it in for -rc2, as the crash bug is quite bad, but -rc3 is good also. Tomi The following changes since commit e92a5b28f71aea01b281f9c89d97a4bc5b24748f: OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request (2012-05-22 11:00:09 +0300) are available in the git repository at: git://gitorious.org/linux-omap-dss2/linux.git tags/omapdss-for-3.5-rc2 for you to fetch changes up to c3a21fc79b6bc097d8b0e47498903a649a27: OMAPDSS: fix registration of DPI and SDI devices (2012-06-05 17:15:24 +0300) Small fixes for omapdss driver. Most importantly, fixes a build problem when debugfs or omapdss debug support is turned off, and fixes a suspend related crash. Archit Taneja (1): OMAPDSS: DSI: Fix bug when calculating LP command interleaving parameters Tomi Valkeinen (4): OMAPDSS: fix build when DEBUG_FS or DSS_DEBUG_SUPPORT disabled OMAPDSS: Taal: fix compilation warning OMAPDSS: fix bogus WARN_ON in dss_runtime_put() OMAPDSS: fix registration of DPI and SDI devices arch/arm/mach-omap2/display.c |4 ++-- drivers/video/omap2/displays/panel-taal.c |2 +- drivers/video/omap2/dss/core.c|3 +-- drivers/video/omap2/dss/dsi.c |2 +- drivers/video/omap2/dss/dss.c |2 +- 5 files changed, 6 insertions(+), 7 deletions(-) signature.asc Description: This is a digitally signed message part
Re: Compile err when enable CONFIG_SND_OMAP_SOC_OMAP_HDMI
Hi Xiao, On 06/04/2012 11:15 PM, Xiao Jiang wrote: Ricardo Neri wrote: Hi Xiao, Tomi, Jarkko, On 05/30/2012 11:27 PM, Xiao Jiang wrote: Ricardo Neri wrote: +Tomi Hi Xiao, On 05/30/2012 02:14 AM, Xiao Jiang wrote: Hello, After enable SND_OMAP_SOC_OMAP_HDMI with omap2plus_defconfig, I got some err infos with latest Linus's tree, does somebody also has the same issue? sound/soc/omap/omap-hdmi.c:45:24: error: field 'dss_audio' has incomplete type sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_startup': sound/soc/omap/omap-hdmi.c:67:27: error: 'struct omap_dss_driver' has no member named 'audio_supported' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_prepare': sound/soc/omap/omap-hdmi.c:79:29: error: 'struct omap_dss_driver' has no member named 'audio_enable' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_hw_params': sound/soc/omap/omap-hdmi.c:208:28: error: 'struct omap_dss_driver' has no member named 'audio_config' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_trigger': sound/soc/omap/omap-hdmi.c:224:29: error: 'struct omap_dss_driver' has no member named 'audio_start' sound/soc/omap/omap-hdmi.c:229:23: error: 'struct omap_dss_driver' has no member named 'audio_stop' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_shutdown': sound/soc/omap/omap-hdmi.c:242:22: error: 'struct omap_dss_driver' has no member named 'audio_disable' sound/soc/omap/omap-hdmi.c: In function 'omap_hdmi_dai_prepare': sound/soc/omap/omap-hdmi.c:80:1: warning: control reaches end of non-void function Build breaks because there some patches [1] that are still missing in Linus' tree. ASoC HDMI audio driver for OMAP[2] now uses the new DSS audio functionality in [1], but ASoC patches were merged first. DSS patches have been accepted and they are part of Tomi's pull request for DSS for K3.5. Hopefully this will be fixed when v3.5-rc1 is out. Ricardo, thanks for your detail infos :). Just wanted to confirm to you that this build break is not present in 3.5-rc1 as both omapdss and asoc dependencies are present. Hi Ricardo, Good to know, but I can't get any voice with aplay, although penguins are appeared on the hdmi tv. Pls see below infos. root@panda:/root aplay -l List of PLAYBACK Hardware Devices card 0: OMAPHDMI [OMAPHDMI], device 0: HDMI omap-hdmi-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 root@panda:/root alsamixer ▒▒ AlsaMixer v1.0.21 ▒ ▒ Card: OMAPHDMI F1: Help ▒ ▒ Chip: F2: System information ▒ ▒ View: F3: Playback F4: Capture F5: All F6: Select sound card ▒ ▒ Item: Esc: Exit ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ This sound device does not have any controls. ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ ▒ root@panda:/root aplay audio48k16S.wav Playing WAVE 'audio48k16S.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo But hdmi audio of imx6q board is ok with the same hdmi tv. Did I miss something else? thanks. Do you see that the playback finishes (even though you don't hear anything)? Also, what version of Pandaboard are you using? Is it Pandaboard or PandaboardES? Have you tried on different TVs? BR, Ricardo Regards, Xiao Ricardo Regards, Xiao BR, Ricardo [1].http://www.spinics.net/lists/linux-omap/msg69466.html [2].http://www.spinics.net/lists/linux-omap/msg70561.html Regards, Xiao -- 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: Please help! AM35xx mm/slab.c BUG
Hi Tony, Thanks so much for the response! All good suggestions. #1.) Missing retention/off idle workarounds I'm highly suspect of this one. I've seen a lot of patches addressing things in this category come out recently for the Sitara series, and we've tried to incorporate everything we've seen. We also rebased our tree off the linux-omap masteras recently as May 17th. As I mentioned in the first post, I hope to do this again soon, perhaps today even, to pull in all the good work you folks have done bringing us up to the RCs of 3.5. Since we discovered the nohlt option, we've added it to our default kernel command line and have been using with it. For a while, I thought maybe that had fixed the glitch, but then yesterday came along... That crash from the first message occured with 'nohlt' enabled. #2.) Broken Memory We really hammered this one as well, as TechNexion delivered our boards with 256MB of NANYA NT5TU64M16GG–AC RAM. Since we were unfamiliar with that part, we rolled up our sleeves and evaluated every timing and configuration paramter in x-loader using the EMIF4 settings calculator spreadsheet provided by TI. We also have been running cycles of memtester 200M calls, and the board seems to hold up fine under that with both the default, very conservative timings and the more optimized ones we determinded with the TI sheet. I'll give your suggestion of limiting the memory a shot and see if that makes a difference. Several of our older captures were run with SLAB_DEBUG set, but it seemed at the time that we weren't getting any more info out of that so we disabled it. I'll re-enable. #3.) Software bugs We're certainly not opposed to the idea that we're doing something wrong. :) In fact, that would almost seem likely at this point. A few other things that may be helpful: * Could these issues be related to our GPMC? We're using the SMSC LAN9221 on our board, not the slower LAN9220 that it seems all the AM35xx dev. kits are using. Frankly, the fastest we could get with that chip was ~40Mbps with a ~1-2% packet loss. :-( So, we stepped up to the faster LAN9221 that's used by Gumstix and several others on the OMAP series. It's running super-well right now ( 80Mbps with 0% loss) with the faster GPMC timings and configuration provided with the Gumstix source. Is there perhaps a reason all the AM35xx boards were using the LAN9220 instead? We assumed the AM35xx GPMC was essentially as capable as the OMAP's. Was that a faulty assumption? Speaking of GPMC, our NAND that Technexion is delivering requires a 4-bit ECC. As support for that seems spotty at the moment in the various bootloader and kernel configurations, we finally punted and simply used Micron's on-die engine to do it. It appears stable, and we've done various filesystem burn-in tests to stress it. At little while back we also rigged a combination nandtest + iperf across the SMSC to really stress the GPMC. This too ran fine for several iterations. *DaVinci EMAC?: Perhaps it's just my latest thought-of-the-day, but since I saw so many of these things yesterday while focusing on Ethernet work, after seeing none for the past several days doing other work, I can't help but think it may be related to the networks somehow. Some of our TAM3517's do not have the SMSC hooked up to them. They are just using their EMAC adapters, but they have exhibited these SLAB crashes too. So, maybe it's the EMAC? We've noticed that when we run bandwdith tests between a pair of EMACs using iperf, we get a pretty reduced data rate, maybe 60Mbps. There is also the occasional dropped packet. When we connect and EMAC to another port, say a laptop or a Gumstix SMSC, we get blazing performance. That seems very odd. It's like the driver is more than capable of producing those high-class speeds, but when two of them get together they agree to dog it. Could this maybe be related??? Thanks again for you time and help! - Original Message - From: Tony Lindgren t...@atomide.com To: CF Adad cfa...@rocketmail.com Cc: linux-omap@vger.kernel.org linux-omap@vger.kernel.org Sent: Tuesday, June 5, 2012 3:08 AM Subject: Re: Please help! AM35xx mm/slab.c BUG * CF Adad cfa...@rocketmail.com [120604 23:47]: All, I'm **really** hoping someone out there can help us with this. My team has been working with the AM3517 for several months now, and we seem to be plagued every so often by what we have termed the slab bug. In short, it looks something like the pasted bootlog below. This has been an *incredibly* hard bug to figure out. We have a couple of different AM3517-based platforms at our disposal, but the one we see the issue on almost exclusively is a custom, prototype baseboard designed around the TechNexion TAM3157. Over the last several months, we have tried several versions of the Linux off the linux-omap tree, with loads of different configurations, and even
[PATCH V4 00/12] ARM: OMAP: DMTIMER clean-up and fixes in preparation for device-tree
In order to migrate the dmtimer driver to support device-tree I found that it
was first necessary to clean-up the timer platform data. The goal of this
series is to simplify the timer platform data structure from ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
int timer_ip_version;
u32 needs_manual_reset:1;
bool reserved;
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
};
to ...
struct dmtimer_platform_data {
/* set_timer_src - Only used for OMAP1 devices */
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 timer_capability;
};
... where timer_capability is a bit mask that indicates the timer features
supported and uses the HWMOD timer capabilities flags described in
plat/dmtimer.h. For OMAP2+ devices this allows us to read the timer
capabilities from the HWMOD data and for OMAP1 devices the flags are simply
populated by the timer initialisation code. Eventually, the aim is to read the
timer capabilities from the device tree blob.
This series includes some fixes as well as clean-up. For instance OMAP1 dmtimer
support is currently completely broken and so I have included a fix for this.
If it is preferred to split the series into fixes and clean-up I can do that.
This series is based upon the current linux-omap master branch (3.5-rc1).
Testing:
- I have built both omap1 and omap2plus configurations as well as booted the
respective kernels on the omap5912 OSK (omap1), OMAP3430 Beagle and OMAP4430
Blaze.
- On the above boards I have also verified that I can request a dmtimer and set
the parent clock.
V4:
- Well this is embarrassing! Somehow the removal of needs_manual_reset
variable got dropped during the rebase to 3.5-rc1.
- Re-ordered patches to avoid any compilation breaks.
V3:
- Unsquashed two patches (9 and 10) that I had previously managed to squash by
accident :-(
V2:
- Fix OMAP1 dmtimer support which currently broken. Requesting a timer
fails because clk_get() is called and this is not support for OMAP1
devices.
- Only use set_timer_src function pointer for OMAP1 devices.
Jon Hunter (12):
ARM: OMAP: Remove unnecessary clk structure
ARM: OMAP2+: Remove unused max number of timers definition
ARM: OMAP2+: Add dmtimer platform function to reserve systimers
ARM: OMAP: Add DMTIMER capability variable to represent timer
features
ARM: OMAP2+: HWMOD: Correct timer device attributes
ARM: OMAP2+: Fix external clock support for dmtimers
ARM: OMAP: Remove loses_context variable from timer platform data
ARM: OMAP: Remove timer function pointer for context loss counter
ARM: OMAP: Add flag to indicate if a timer needs a manual reset
ARM: OMAP1: Fix dmtimer support
ARM: OMAP2+: Move dmtimer clock set function to dmtimer driver
ARM: OMAP2+: Simplify dmtimer clock aliases
arch/arm/mach-omap1/timer.c|3 +-
arch/arm/mach-omap2/clock2420_data.c | 39 +--
arch/arm/mach-omap2/clock2430_data.c | 39 +--
arch/arm/mach-omap2/clock3xxx_data.c | 26 +
arch/arm/mach-omap2/clock44xx_data.c | 34 +++---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |8 --
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 10 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 --
arch/arm/mach-omap2/timer.c| 82 +--
arch/arm/plat-omap/dmtimer.c | 111 +++-
arch/arm/plat-omap/include/plat/dmtimer.h | 22 +---
11 files changed, 118 insertions(+), 262 deletions(-)
--
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 V4 09/12] ARM: OMAP: Add flag to indicate if a timer needs a manual reset
For OMAP1 devices, it is necessary to perform a manual reset of the timer.
Currently, this is indicating by setting the needs_manual_reset variable in
the platform data. Instead of using an extra variable to indicate this add a new
timer capabilities flag to indicate this and remove the needs_manual_reset
member from the platform data.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap1/timer.c |4 ++--
arch/arm/plat-omap/dmtimer.c |9 +++--
arch/arm/plat-omap/include/plat/dmtimer.h |2 +-
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index b4bf48c..aa81593 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -140,8 +140,8 @@ static int __init omap1_dm_timer_init(void)
}
pdata-set_timer_src = omap1_dm_timer_set_src;
- pdata-needs_manual_reset = 1;
- pdata-timer_capability = OMAP_TIMER_ALWON;
+ pdata-timer_capability = OMAP_TIMER_ALWON |
+ OMAP_TIMER_NEEDS_RESET;
ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
if (ret) {
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 7875eef..e3e22b3 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -135,7 +135,6 @@ static void omap_dm_timer_reset(struct omap_dm_timer *timer)
int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
- struct dmtimer_platform_data *pdata = timer-pdev-dev.platform_data;
int ret;
timer-fclk = clk_get(timer-pdev-dev, fck);
@@ -145,7 +144,7 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
return -EINVAL;
}
- if (pdata-needs_manual_reset)
+ if (timer-capability OMAP_TIMER_NEEDS_RESET)
omap_dm_timer_reset(timer);
ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
@@ -363,13 +362,11 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_start);
int omap_dm_timer_stop(struct omap_dm_timer *timer)
{
unsigned long rate = 0;
- struct dmtimer_platform_data *pdata;
if (unlikely(!timer))
return -EINVAL;
- pdata = timer-pdev-dev.platform_data;
- if (!pdata-needs_manual_reset)
+ if (!(timer-capability OMAP_TIMER_NEEDS_RESET))
rate = clk_get_rate(timer-fclk);
__omap_dm_timer_stop(timer, timer-posted, rate);
@@ -694,7 +691,7 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-capability = pdata-timer_capability;
/* Skip pm_runtime_enable for OMAP1 */
- if (!pdata-needs_manual_reset) {
+ if (!(timer-capability OMAP_TIMER_NEEDS_RESET)) {
pm_runtime_enable(pdev-dev);
pm_runtime_irq_safe(pdev-dev);
}
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index e11c9ea..c039e84 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -59,6 +59,7 @@
#define OMAP_TIMER_SECURE 0x8000
#define OMAP_TIMER_ALWON 0x4000
#define OMAP_TIMER_HAS_PWM 0x2000
+#define OMAP_TIMER_NEEDS_RESET 0x1000
struct omap_timer_capability_dev_attr {
u32 timer_capability;
@@ -90,7 +91,6 @@ struct timer_regs {
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
- u32 needs_manual_reset:1;
u32 timer_capability;
};
--
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 V4 10/12] ARM: OMAP1: Fix dmtimer support
OMAP1 dmtimer support is currently broken. When a dmtimer is requested by the
omap_dm_timer_request() function fails to allocate a dmtimer because the call
to clk_get() inside omap_dm_timer_prepare fails. The clk_get() fails simply
because the clock data for the OMAP1 dmtimers is not present.
Ideally this should be fixed by moving OMAP1 dmtimers to use the clock
framework. For now simply fix this by using the TIMER_NEEDS_RESET flag to
identify an OMAP1 device and avoid calling clk_get(). Although this is not
the ideal fix and should be corrected, this flag has already been use for the
same purpose in omap_dm_timer_stop().
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/dmtimer.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index e3e22b3..6510e5e 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -137,11 +137,17 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
int ret;
- timer-fclk = clk_get(timer-pdev-dev, fck);
- if (WARN_ON_ONCE(IS_ERR_OR_NULL(timer-fclk))) {
- timer-fclk = NULL;
- dev_err(timer-pdev-dev, : No fclk handle.\n);
- return -EINVAL;
+ /*
+* FIXME: OMAP1 devices do not use the clock framework for dmtimers so
+* do not call clk_get() for these devices.
+*/
+ if (!(timer-capability OMAP_TIMER_NEEDS_RESET)) {
+ timer-fclk = clk_get(timer-pdev-dev, fck);
+ if (WARN_ON_ONCE(IS_ERR_OR_NULL(timer-fclk))) {
+ timer-fclk = NULL;
+ dev_err(timer-pdev-dev, : No fclk handle.\n);
+ return -EINVAL;
+ }
}
if (timer-capability OMAP_TIMER_NEEDS_RESET)
--
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 V4 03/12] ARM: OMAP2+: Add dmtimer platform function to reserve systimers
During early boot, one or two dmtimers are reserved by the kernel as system
timers (for clocksource and clockevents). These timers are marked as reserved
and the dmtimer driver is notified which timers have been reserved via the
platform data information.
For OMAP2+ devices the timers reserved may vary depending on device and compile
flags. Therefore, it is not easy to assume which timers we be reserved for the
system timers. In order to migrate the dmtimer driver to support device-tree we
need a way to pass the timers reserved for system timers to the dmtimer driver.
Using the platform data structure will not work in the same way as it is
currently used because the platform data structure will be stored statically in
the dmtimer itself and the platform data will be selected via the device-tree
match device function (of_match_device).
There are a couple ways to workaround this. One option is to store the system
timers reserved for the kernel in the device-tree and query them on boot.
The downside of this approach is that it adds some delay to parse the DT blob
to search for the system timers. Secondly, for OMAP3 devices we have a
dependency on compile time flags and the device-tree would not be aware of that
kernel compile flags and so we would need to address that.
The second option is to add a function to the dmtimer code to reserved the
system timers during boot and so the dmtimer knows exactly which timers are
being used for system timers. This also allows us to remove the reserved
member from the timer platform data. This seemed like the simpler approach and
so was implemented here.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c |9 ++---
arch/arm/plat-omap/dmtimer.c | 18 +-
arch/arm/plat-omap/include/plat/dmtimer.h |3 +--
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 8350352..732bdcf 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -69,8 +69,6 @@
#define OMAP3_SECURE_TIMER 1
#endif
-static u32 sys_timer_reserved;
-
/* Clockevent code */
static struct omap_dm_timer clkev;
@@ -177,7 +175,8 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
omap_hwmod_enable(oh);
- sys_timer_reserved |= (1 (gptimer_id - 1));
+ if (omap_dm_timer_reserve_systimer(gptimer_id))
+ return -ENODEV;
if (gptimer_id != 12) {
struct clk *src;
@@ -506,10 +505,6 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
pdata-set_timer_src = omap2_dm_timer_set_src;
pdata-timer_ip_version = oh-class-rev;
- /* Mark clocksource and clockevent timers as reserved */
- if ((sys_timer_reserved (id - 1)) 0x1)
- pdata-reserved = 1;
-
pwrdm = omap_hwmod_get_pwrdm(oh);
pdata-loses_context = pwrdm_can_ever_lose_context(pwrdm);
#ifdef CONFIG_PM
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 3b0cfeb..f5b5c89 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -45,6 +45,7 @@
#include mach/hardware.h
+static u32 omap_reserved_systimers;
static LIST_HEAD(omap_timer_list);
static DEFINE_SPINLOCK(dm_timer_lock);
@@ -152,6 +153,21 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
return ret;
}
+static inline u32 omap_dm_timer_reserved_systimer(int id)
+{
+ return (omap_reserved_systimers (1 (id - 1))) ? 1 : 0;
+}
+
+int omap_dm_timer_reserve_systimer(int id)
+{
+ if (omap_dm_timer_reserved_systimer(id))
+ return -ENODEV;
+
+ omap_reserved_systimers |= (1 (id - 1));
+
+ return 0;
+}
+
struct omap_dm_timer *omap_dm_timer_request(void)
{
struct omap_dm_timer *timer = NULL, *t;
@@ -674,7 +690,7 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-id = pdev-id;
timer-irq = irq-start;
- timer-reserved = pdata-reserved;
+ timer-reserved = omap_dm_timer_reserved_systimer(timer-id);
timer-pdev = pdev;
timer-loses_context = pdata-loses_context;
timer-get_context_loss_count = pdata-get_context_loss_count;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 5fdfaa4..1e5ce5d 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -98,13 +98,12 @@ struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
int timer_ip_version;
u32 needs_manual_reset:1;
- bool reserved;
-
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
};
+int omap_dm_timer_reserve_systimer(int id);
struct omap_dm_timer *omap_dm_timer_request(void);
struct omap_dm_timer
[PATCH V4 07/12] ARM: OMAP: Remove loses_context variable from timer platform data
The platform data variable loses_context is used to determine if the timer may
lose its logic state during power transitions and so needs to be restored. This
information is also provided in the HWMOD device attributes for OMAP2+ devices
via the OMAP_TIMER_ALWON flag. When this flag is set the timer will not lose
context. So use the HWMOD device attributes to determine this.
For OMAP1 devices, loses_context is never set and so set the OMAP_TIMER_ALWON
flag for OMAP1 timers to ensure that code is equivalent.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap1/timer.c |1 +
arch/arm/mach-omap2/timer.c |3 ---
arch/arm/plat-omap/dmtimer.c |8
arch/arm/plat-omap/include/plat/dmtimer.h |3 ---
4 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap1/timer.c b/arch/arm/mach-omap1/timer.c
index 64c65bc..b4bf48c 100644
--- a/arch/arm/mach-omap1/timer.c
+++ b/arch/arm/mach-omap1/timer.c
@@ -141,6 +141,7 @@ static int __init omap1_dm_timer_init(void)
pdata-set_timer_src = omap1_dm_timer_set_src;
pdata-needs_manual_reset = 1;
+ pdata-timer_capability = OMAP_TIMER_ALWON;
ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
if (ret) {
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 62bc05e..b75bc6b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -467,7 +467,6 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
struct dmtimer_platform_data *pdata;
struct platform_device *pdev;
struct omap_timer_capability_dev_attr *timer_dev_attr;
- struct powerdomain *pwrdm;
pr_debug(%s: %s\n, __func__, oh-name);
@@ -500,8 +499,6 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
if (timer_dev_attr)
pdata-timer_capability = timer_dev_attr-timer_capability;
- pwrdm = omap_hwmod_get_pwrdm(oh);
- pdata-loses_context = pwrdm_can_ever_lose_context(pwrdm);
#ifdef CONFIG_PM
pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
#endif
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 30742d8e6..7aa1278 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -341,7 +341,7 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
omap_dm_timer_enable(timer);
- if (timer-loses_context) {
+ if (!(timer-capability OMAP_TIMER_ALWON)) {
u32 ctx_loss_cnt_after =
timer-get_context_loss_count(timer-pdev-dev);
if (ctx_loss_cnt_after != timer-ctx_loss_count)
@@ -374,7 +374,8 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
__omap_dm_timer_stop(timer, timer-posted, rate);
- if (timer-loses_context timer-get_context_loss_count)
+ if (!(timer-capability OMAP_TIMER_ALWON)
+ timer-get_context_loss_count)
timer-ctx_loss_count =
timer-get_context_loss_count(timer-pdev-dev);
@@ -447,7 +448,7 @@ int omap_dm_timer_set_load_start(struct omap_dm_timer
*timer, int autoreload,
omap_dm_timer_enable(timer);
- if (timer-loses_context) {
+ if (!(timer-capability OMAP_TIMER_ALWON)) {
u32 ctx_loss_cnt_after =
timer-get_context_loss_count(timer-pdev-dev);
if (ctx_loss_cnt_after != timer-ctx_loss_count)
@@ -692,7 +693,6 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-irq = irq-start;
timer-reserved = omap_dm_timer_reserved_systimer(timer-id);
timer-pdev = pdev;
- timer-loses_context = pdata-loses_context;
timer-get_context_loss_count = pdata-get_context_loss_count;
timer-capability = pdata-timer_capability;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 362cf97..0a7ed31 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -91,8 +91,6 @@ struct timer_regs {
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 needs_manual_reset:1;
- bool loses_context;
-
int (*get_context_loss_count)(struct device *dev);
u32 timer_capability;
};
@@ -264,7 +262,6 @@ struct omap_dm_timer {
unsigned reserved:1;
unsigned posted:1;
struct timer_regs context;
- bool loses_context;
int ctx_loss_count;
int revision;
u32 capability;
--
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 V4 06/12] ARM: OMAP2+: Fix external clock support for dmtimers
Currently, the dmtimer determines whether an timer can support an external
clock source (sys_altclk) for driving the timer by the IP version. Only
OMAP24xx devices can support an external clock source, but the IP version
between OMAP24xx and OMAP3xxx is common and so this incorrectly indicates
that OMAP3 devices can use an external clock source.
Rather than use the IP version, just let the clock framework handle this.
If the alt_ck does not exist for a timer then the clock framework will fail
to find the clock and hence will return an error. By doing this we can eliminate
the timer_ip_version variable passed as part of the platform data and simplify
the code.
We can also remove the timer IP version from the HWMOD data because the dmtimer
driver uses the TIDR register to determine the IP version.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |1 -
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 --
arch/arm/mach-omap2/timer.c| 12 ++--
arch/arm/plat-omap/include/plat/dmtimer.h |7 ---
4 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 7814e83..afad69c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -68,7 +68,6 @@ static struct omap_hwmod_class_sysconfig omap2xxx_timer_sysc
= {
struct omap_hwmod_class omap2xxx_timer_hwmod_class = {
.name = timer,
.sysc = omap2xxx_timer_sysc,
- .rev= OMAP_TIMER_IP_VERSION_1,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 7b33094..0ea53bc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -129,7 +129,6 @@ static struct omap_hwmod_class_sysconfig
omap3xxx_timer_1ms_sysc = {
static struct omap_hwmod_class omap3xxx_timer_1ms_hwmod_class = {
.name = timer,
.sysc = omap3xxx_timer_1ms_sysc,
- .rev = OMAP_TIMER_IP_VERSION_1,
};
static struct omap_hwmod_class_sysconfig omap3xxx_timer_sysc = {
@@ -145,7 +144,6 @@ static struct omap_hwmod_class_sysconfig
omap3xxx_timer_sysc = {
static struct omap_hwmod_class omap3xxx_timer_hwmod_class = {
.name = timer,
.sysc = omap3xxx_timer_sysc,
- .rev = OMAP_TIMER_IP_VERSION_1,
};
/* secure timers dev attribute */
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ddacb8f..62bc05e 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -402,7 +402,6 @@ OMAP_SYS_TIMER(4)
static int omap2_dm_timer_set_src(struct platform_device *pdev, int source)
{
int ret;
- struct dmtimer_platform_data *pdata = pdev-dev.platform_data;
struct clk *fclk, *parent;
char *parent_name = NULL;
@@ -423,14 +422,8 @@ static int omap2_dm_timer_set_src(struct platform_device
*pdev, int source)
break;
case OMAP_TIMER_SRC_EXT_CLK:
- if (pdata-timer_ip_version == OMAP_TIMER_IP_VERSION_1) {
- parent_name = alt_ck;
- break;
- }
- dev_err(pdev-dev, %s: %d: invalid clk src.\n,
- __func__, __LINE__);
- clk_put(fclk);
- return -EINVAL;
+ parent_name = alt_ck;
+ break;
}
parent = clk_get(pdev-dev, parent_name);
@@ -503,7 +496,6 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
sscanf(oh-name, timer%2d, id);
pdata-set_timer_src = omap2_dm_timer_set_src;
- pdata-timer_ip_version = oh-class-rev;
if (timer_dev_attr)
pdata-timer_capability = timer_dev_attr-timer_capability;
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 48e54ca..362cf97 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -55,12 +55,6 @@
#define OMAP_TIMER_TRIGGER_OVERFLOW0x01
#define OMAP_TIMER_TRIGGER_OVERFLOW_AND_COMPARE0x02
-/*
- * IP revision identifier so that Highlander IP
- * in OMAP4 can be distinguished.
- */
-#define OMAP_TIMER_IP_VERSION_10x1
-
/* timer capabilities used in hwmod database */
#define OMAP_TIMER_SECURE 0x8000
#define OMAP_TIMER_ALWON 0x4000
@@ -96,7 +90,6 @@ struct timer_regs {
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
- int timer_ip_version;
u32 needs_manual_reset:1;
bool loses_context;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
[PATCH V4 11/12] ARM: OMAP2+: Move dmtimer clock set function to dmtimer driver
OMAP1 uses an architecture specific function for setting the dmtimer clock
source, where as the OMAP2+ devices use the clock framework. Eventually OMAP1
device should also use the clock framework and hence we should not any
architecture specific functions.
For now move the OMAP2+ function for configuring the clock source into the
dmtimer driver. Therefore, we do no longer need to specify an architecture
specific function for setting the clock source for OMAP2+ devices. This will
simplify device tree migration of the dmtimers for OMAP2+ devices.
From now on, only OMAP1 devices should specify an architecture specific
function for setting the clock source via the platform data set_dmtimer_src()
function pointer.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c | 55 -
arch/arm/plat-omap/dmtimer.c | 46 +++-
arch/arm/plat-omap/include/plat/dmtimer.h |1 +
3 files changed, 46 insertions(+), 56 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 67a97cd..b5b5d92 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -395,59 +395,6 @@ OMAP_SYS_TIMER(4)
#endif
/**
- * omap2_dm_timer_set_src - change the timer input clock source
- * @pdev: timer platform device pointer
- * @source:array index of parent clock source
- */
-static int omap2_dm_timer_set_src(struct platform_device *pdev, int source)
-{
- int ret;
- struct clk *fclk, *parent;
- char *parent_name = NULL;
-
- fclk = clk_get(pdev-dev, fck);
- if (IS_ERR_OR_NULL(fclk)) {
- dev_err(pdev-dev, %s: %d: clk_get() FAILED\n,
- __func__, __LINE__);
- return -EINVAL;
- }
-
- switch (source) {
- case OMAP_TIMER_SRC_SYS_CLK:
- parent_name = sys_ck;
- break;
-
- case OMAP_TIMER_SRC_32_KHZ:
- parent_name = 32k_ck;
- break;
-
- case OMAP_TIMER_SRC_EXT_CLK:
- parent_name = alt_ck;
- break;
- }
-
- parent = clk_get(pdev-dev, parent_name);
- if (IS_ERR_OR_NULL(parent)) {
- dev_err(pdev-dev, %s: %d: clk_get() %s FAILED\n,
- __func__, __LINE__, parent_name);
- clk_put(fclk);
- return -EINVAL;
- }
-
- ret = clk_set_parent(fclk, parent);
- if (IS_ERR_VALUE(ret)) {
- dev_err(pdev-dev, %s: clk_set_parent() to %s FAILED\n,
- __func__, parent_name);
- ret = -EINVAL;
- }
-
- clk_put(parent);
- clk_put(fclk);
-
- return ret;
-}
-
-/**
* omap_timer_init - build and register timer device with an
* associated timer hwmod
* @oh:timer hwmod pointer to be used to build timer device
@@ -494,8 +441,6 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
*/
sscanf(oh-name, timer%2d, id);
- pdata-set_timer_src = omap2_dm_timer_set_src;
-
if (timer_dev_attr)
pdata-timer_capability = timer_dev_attr-timer_capability;
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 6510e5e..6a70889 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -397,6 +397,8 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_stop);
int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source)
{
int ret;
+ char *parent_name = NULL;
+ struct clk *fclk, *parent;
struct dmtimer_platform_data *pdata;
if (unlikely(!timer))
@@ -407,7 +409,49 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
if (source 0 || source = 3)
return -EINVAL;
- ret = pdata-set_timer_src(timer-pdev, source);
+ /*
+* FIXME: Used for OMAP1 devices only because they do not currently
+* use the clock framework to set the parent clock. To be removed
+* once OMAP1 migrated to using clock framework for dmtimers
+*/
+ if (pdata-set_timer_src)
+ return pdata-set_timer_src(timer-pdev, source);
+
+ fclk = clk_get(timer-pdev-dev, fck);
+ if (IS_ERR_OR_NULL(fclk)) {
+ pr_err(%s: fck not found\n, __func__);
+ return -EINVAL;
+ }
+
+ switch (source) {
+ case OMAP_TIMER_SRC_SYS_CLK:
+ parent_name = sys_ck;
+ break;
+
+ case OMAP_TIMER_SRC_32_KHZ:
+ parent_name = 32k_ck;
+ break;
+
+ case OMAP_TIMER_SRC_EXT_CLK:
+ parent_name = alt_ck;
+ break;
+ }
+
+ parent = clk_get(timer-pdev-dev, parent_name);
+ if (IS_ERR_OR_NULL(parent)) {
+ pr_err(%s: %s not found\n, __func__, parent_name);
+ ret = -EINVAL;
+ goto out;
+ }
+
+
[PATCH V4 08/12] ARM: OMAP: Remove timer function pointer for context loss counter
For OMAP2+ devices, a function pointer that returns the number of times a timer
power domain has lost context is passed to the dmtimer driver. This function
pointer is only populated for OMAP2+ devices and it is pointing to a platform
function. Given that this is a platform function, we can simplify the code by
removing the function pointer and referencing the function directly. We can use
the OMAP_TIMER_ALWON flag to determine if we need to call this function for
OMAP1 and OMAP2+ devices.
The benefit of this change is the we can remove the function pointer from the
platform data and simplifies the dmtimer migration to device-tree.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c |3 ---
arch/arm/plat-omap/dmtimer.c | 17 +++--
arch/arm/plat-omap/include/plat/dmtimer.h |3 ---
3 files changed, 7 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b75bc6b..67a97cd 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -499,9 +499,6 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
if (timer_dev_attr)
pdata-timer_capability = timer_dev_attr-timer_capability;
-#ifdef CONFIG_PM
- pdata-get_context_loss_count = omap_pm_get_dev_context_loss_count;
-#endif
pdev = omap_device_build(name, id, oh, pdata, sizeof(*pdata),
NULL, 0, 0);
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 7aa1278..7875eef 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -42,6 +42,7 @@
#include linux/pm_runtime.h
#include plat/dmtimer.h
+#include plat/omap-pm.h
#include mach/hardware.h
@@ -342,9 +343,8 @@ int omap_dm_timer_start(struct omap_dm_timer *timer)
omap_dm_timer_enable(timer);
if (!(timer-capability OMAP_TIMER_ALWON)) {
- u32 ctx_loss_cnt_after =
- timer-get_context_loss_count(timer-pdev-dev);
- if (ctx_loss_cnt_after != timer-ctx_loss_count)
+ if (omap_pm_get_dev_context_loss_count(timer-pdev-dev) !=
+ timer-ctx_loss_count)
omap_timer_restore_context(timer);
}
@@ -374,10 +374,9 @@ int omap_dm_timer_stop(struct omap_dm_timer *timer)
__omap_dm_timer_stop(timer, timer-posted, rate);
- if (!(timer-capability OMAP_TIMER_ALWON)
- timer-get_context_loss_count)
+ if (!(timer-capability OMAP_TIMER_ALWON))
timer-ctx_loss_count =
- timer-get_context_loss_count(timer-pdev-dev);
+ omap_pm_get_dev_context_loss_count(timer-pdev-dev);
/*
* Since the register values are computed and written within
@@ -449,9 +448,8 @@ int omap_dm_timer_set_load_start(struct omap_dm_timer
*timer, int autoreload,
omap_dm_timer_enable(timer);
if (!(timer-capability OMAP_TIMER_ALWON)) {
- u32 ctx_loss_cnt_after =
- timer-get_context_loss_count(timer-pdev-dev);
- if (ctx_loss_cnt_after != timer-ctx_loss_count)
+ if (omap_pm_get_dev_context_loss_count(timer-pdev-dev) !=
+ timer-ctx_loss_count)
omap_timer_restore_context(timer);
}
@@ -693,7 +691,6 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-irq = irq-start;
timer-reserved = omap_dm_timer_reserved_systimer(timer-id);
timer-pdev = pdev;
- timer-get_context_loss_count = pdata-get_context_loss_count;
timer-capability = pdata-timer_capability;
/* Skip pm_runtime_enable for OMAP1 */
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 0a7ed31..e11c9ea 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -91,7 +91,6 @@ struct timer_regs {
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 needs_manual_reset:1;
- int (*get_context_loss_count)(struct device *dev);
u32 timer_capability;
};
@@ -267,8 +266,6 @@ struct omap_dm_timer {
u32 capability;
struct platform_device *pdev;
struct list_head node;
-
- int (*get_context_loss_count)(struct device *dev);
};
int omap_dm_timer_prepare(struct omap_dm_timer *timer);
--
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 V4 12/12] ARM: OMAP2+: Simplify dmtimer clock aliases
The OMAP dmtimer driver allows you to dynamically configure the functional
clock that drives the timer logic. The dmtimer driver uses the device name and
a con-id string to search for the appropriate functional clock.
Currently, we define a clock alias for each functional clock source each timer
supports. Some functional clock sources are common to all of the timers on a
device and so for these clock sources we can use a single alias with a unique
con-id string.
The possible functional clock sources for an OMAP device are a 32kHz clock,
a system (MHz range) clock and (for OMAP2 only) an external clock. By defining
a unique con-id name for each of these (timer_32k_ck, timer_sys_ck and
timer_ext_ck) we can eliminate a lot of the clock aliases for timers. This
reduces code, speeds-up searches and clock initialisation time.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/clock2420_data.c | 39 +++---
arch/arm/mach-omap2/clock2430_data.c | 39 +++---
arch/arm/mach-omap2/clock3xxx_data.c | 26 ++-
arch/arm/mach-omap2/clock44xx_data.c | 34 +++--
arch/arm/plat-omap/dmtimer.c |6 +++---
5 files changed, 23 insertions(+), 121 deletions(-)
diff --git a/arch/arm/mach-omap2/clock2420_data.c
b/arch/arm/mach-omap2/clock2420_data.c
index bace930..861767e 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -1901,42 +1901,9 @@ static struct omap_clk omap2420_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_242X),
CLK(NULL, usb_fck, usb_fck, CK_242X),
CLK(musb-hdrc,fck, osc_ck,CK_242X),
- CLK(omap_timer.1, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.2, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.3, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.4, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.5, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.6, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.7, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.8, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.9, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.10,32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.11,32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.12,32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.1, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.2, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.3, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.4, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.5, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.6, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.7, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.8, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.9, sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.10,sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.11,sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.12,sys_ck, sys_ck,CK_243X),
- CLK(omap_timer.1, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.2, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.3, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.4, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.5, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.6, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.7, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.8, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.9, alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.10,alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.11,alt_ck, alt_ck,CK_243X),
- CLK(omap_timer.12,alt_ck, alt_ck,CK_243X),
+ CLK(NULL, timer_32k_ck, func_32k_ck, CK_243X),
+ CLK(NULL, timer_sys_ck, sys_ck,CK_243X),
+ CLK(NULL, timer_ext_ck, alt_ck,CK_243X),
};
/*
diff --git a/arch/arm/mach-omap2/clock2430_data.c
b/arch/arm/mach-omap2/clock2430_data.c
index 3b4d09a..5577810 100644
--- a/arch/arm/mach-omap2/clock2430_data.c
+++ b/arch/arm/mach-omap2/clock2430_data.c
@@ -2000,42 +2000,9 @@ static struct omap_clk omap2430_clks[] = {
CLK(NULL, mdm_intc_ick, mdm_intc_ick, CK_243X),
CLK(omap_hsmmc.0, mmchsdb_fck, mmchsdb1_fck, CK_243X),
CLK(omap_hsmmc.1, mmchsdb_fck, mmchsdb2_fck, CK_243X),
- CLK(omap_timer.1, 32k_ck, func_32k_ck, CK_243X),
- CLK(omap_timer.2,
[PATCH V4 02/12] ARM: OMAP2+: Remove unused max number of timers definition
The OMAP2+ timer code has a definition for the maximum number of timers that OMAP2+ devices have. This defintion is not used anywhere in the code and appears to be left over. Furthermore the definition is not accurate for OMAP4 devices that only have 11 timers available because the 12th timer is reserved as a secure timer and for OMAP3 devices the 12th timer is not available on secure devices. Therefore, remove this definition. Signed-off-by: Jon Hunter jon-hun...@ti.com --- arch/arm/mach-omap2/timer.c |3 --- 1 file changed, 3 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index ea6a0eb..8350352 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -69,9 +69,6 @@ #define OMAP3_SECURE_TIMER 1 #endif -/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */ -#define MAX_GPTIMER_ID 12 - static u32 sys_timer_reserved; /* Clockevent code */ -- 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 V4 01/12] ARM: OMAP: Remove unnecessary clk structure
In the plat/dmtimer.h there is a structure named clk declared. This structure
is not used and appears to be left over from previous code. Hence, remove this
unused structure.
Verified that both omap1 and omap2plus kernel configurations build with this
change.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/plat-omap/include/plat/dmtimer.h |1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 5da7356..5fdfaa4 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -71,7 +71,6 @@ struct omap_timer_capability_dev_attr {
};
struct omap_dm_timer;
-struct clk;
struct timer_regs {
u32 tidr;
--
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 V4 05/12] ARM: OMAP2+: HWMOD: Correct timer device attributes
Fix the following issues with the timer device attributes for OMAP2+ devices:
1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating
that these timers are in an ALWAYS-ON power domain. This is not the case
only timer1 is in an ALWAYS-ON power domain.
2. For OMAP3xxx devices, timers 2-7 have the ALWAYS-ON attribute indicating
that these timers are in an ALWAYS-ON power domain. This is not the case
only timer1 and timer12 are in an ALWAYS-ON power domain.
3. For OMAP3xxx devices, timer12 does not have the ALWAYS-ON attribute but
is in an always-on power domain.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |7 ---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8 +---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 --
3 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 83eafd9..7814e83 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -257,7 +257,6 @@ struct omap_hwmod omap2xxx_timer2_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT2_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -276,7 +275,6 @@ struct omap_hwmod omap2xxx_timer3_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT3_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -295,7 +293,6 @@ struct omap_hwmod omap2xxx_timer4_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT4_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -314,7 +311,6 @@ struct omap_hwmod omap2xxx_timer5_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT5_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -333,7 +329,6 @@ struct omap_hwmod omap2xxx_timer6_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT6_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -352,7 +347,6 @@ struct omap_hwmod omap2xxx_timer7_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT7_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
@@ -371,7 +365,6 @@ struct omap_hwmod omap2xxx_timer8_hwmod = {
.idlest_idle_bit = OMAP24XX_ST_GPT8_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap2xxx_timer_hwmod_class,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index b26d3c9..7b33094 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -150,7 +150,7 @@ static struct omap_hwmod_class omap3xxx_timer_hwmod_class =
{
/* secure timers dev attribute */
static struct omap_timer_capability_dev_attr capability_secure_dev_attr = {
- .timer_capability = OMAP_TIMER_SECURE,
+ .timer_capability = OMAP_TIMER_ALWON | OMAP_TIMER_SECURE,
};
/* always-on timers dev attribute */
@@ -195,7 +195,6 @@ static struct omap_hwmod omap3xxx_timer2_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT2_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap3xxx_timer_1ms_hwmod_class,
};
@@ -213,7 +212,6 @@ static struct omap_hwmod omap3xxx_timer3_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT3_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap3xxx_timer_hwmod_class,
};
@@ -231,7 +229,6 @@ static struct omap_hwmod omap3xxx_timer4_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT4_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap3xxx_timer_hwmod_class,
};
@@ -249,7 +246,6 @@ static struct omap_hwmod omap3xxx_timer5_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT5_SHIFT,
},
},
- .dev_attr = capability_alwon_dev_attr,
.class = omap3xxx_timer_hwmod_class,
};
@@ -267,7 +263,6 @@ static struct omap_hwmod omap3xxx_timer6_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT6_SHIFT,
},
},
- .dev_attr
[PATCH V4 04/12] ARM: OMAP: Add DMTIMER capability variable to represent timer features
Although the OMAP timers share a common hardware design, there are some
differences between the timer instances in a given device. For example, a timer
maybe in a power domain that can be powered-of, so can lose its logic state and
need restoring where as another may be in power domain that is always be on.
Another example, is a timer may support different clock sources to drive the
timer. This information is passed to the dmtimer via the following platform data
structure.
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
int timer_ip_version;
u32 needs_manual_reset:1;
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
};
The above structure uses multiple variables to represent the timer features.
HWMOD also stores the timer capabilities using a bit-mask that represents the
features supported. By using the same format for representing the timer
features in the platform data as used by HWMOD, we can ...
1. Use the flags defined in the plat/dmtimer.h to represent the features
supported.
2. For devices using HWMOD, we can retrieve the features supported from HWMOD.
3. Eventually, simplify the platform data structure to be ...
struct dmtimer_platform_data {
int (*set_timer_src)(struct platform_device *pdev, int source);
u32 timer_capability;
}
Another benefit from doing this, is that it will simplify the migration of the
dmtimer driver to device-tree. For example, in the current OMAP2+ timer code the
loses_context variable is configured at runtime by calling an architecture
specific function. For device tree this creates a problem, because we would need
to call the architecture specific function from within the dmtimer driver.
However, such attributes do not need to be queried at runtime and we can look up
the attributes via HWMOD or device-tree.
This changes a new capability variable to the platform data and timer
structure so we can start removing and simplifying the platform data structure.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/timer.c |3 +++
arch/arm/plat-omap/dmtimer.c |1 +
arch/arm/plat-omap/include/plat/dmtimer.h |2 ++
3 files changed, 6 insertions(+)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 732bdcf..ddacb8f 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -505,6 +505,9 @@ static int __init omap_timer_init(struct omap_hwmod *oh,
void *unused)
pdata-set_timer_src = omap2_dm_timer_set_src;
pdata-timer_ip_version = oh-class-rev;
+ if (timer_dev_attr)
+ pdata-timer_capability = timer_dev_attr-timer_capability;
+
pwrdm = omap_hwmod_get_pwrdm(oh);
pdata-loses_context = pwrdm_can_ever_lose_context(pwrdm);
#ifdef CONFIG_PM
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index f5b5c89..30742d8e6 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -694,6 +694,7 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
timer-pdev = pdev;
timer-loses_context = pdata-loses_context;
timer-get_context_loss_count = pdata-get_context_loss_count;
+ timer-capability = pdata-timer_capability;
/* Skip pm_runtime_enable for OMAP1 */
if (!pdata-needs_manual_reset) {
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 1e5ce5d..48e54ca 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -101,6 +101,7 @@ struct dmtimer_platform_data {
bool loses_context;
int (*get_context_loss_count)(struct device *dev);
+ u32 timer_capability;
};
int omap_dm_timer_reserve_systimer(int id);
@@ -273,6 +274,7 @@ struct omap_dm_timer {
bool loses_context;
int ctx_loss_count;
int revision;
+ u32 capability;
struct platform_device *pdev;
struct list_head node;
--
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: MFD USB host: prevents CORE retention in idle
Keshava, Felipe, ping. This problem is still preventing CORE retention in mainline. On 05/24/2012 03:13 PM, Kevin Hilman wrote: Kevin Hilmankhil...@ti.com writes: Munegowda, Keshavakeshava_mgo...@ti.com writes: On Thu, May 24, 2012 at 5:55 AM, Kevin Hilmankhil...@ti.com wrote: On 05/23/2012 05:01 PM, Kevin Hilman wrote: Hi Keshava, Using current l-o master, I noticed that CORE was not hitting retention in idle on my 3530/Overo. CORE hits retention on suspend just fine. Debugging this, I found that usbtll_fck was still enabled during idle, thus preventing CORE from hitting retention. To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and was then started seeing CORE hit retention in idle again. I have nothing plugged into the USB host port on this board, so I would've expected that runtime PM would've kicked in and shutdown this clock. Any ideas what's going on here? Is this expected behavior? If it helps, attached is a bootlog after enabling debug for mfd/omap-usb-host.c as well. Notice there's a couple of clock-related warnings from this driver as well. Not sure if they're relevant: usbhs_omap: alias fck already exists usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22 these clocks were specific to omap4 and it should not cause any problem to omap3 boards. OK, they seem unrelated to this CORE retention problem, but the warnings should still be understood and fixed. I will try to reproduce this on 3430 sdp to explore further. Thanks for looking. Note that I only saw this problem on my 3530 platforms (Overo, OMAP3EVM.) My 3430/n900 doesn't support USBHS host AFAICT, so didn't test there. After realizing that the same IP should exist on 3430/n900, I copied some board file support for USBHS host from overo into the n900 board file in order to test on 3430/n900. Problem exists on n900 too. 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 -- 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 v2] omap: dma: Clear status registers on enable/disable irq.
* Oleg Matcovschi oleg.matcovs...@ti.com [120515 14:40]: Use omap_disable_channel_irq() function instead of directly accessing CICR. The omap_disable_chanel_irq() function clears pending interrupts and disables interrupt on channel. Functions omap2_enable_irq_lch()/omap2_disable_irq_lch() clear interrupt status register. Looking at this again, I'll apply this into cleanup-dma instead of fixes. If it fixes something that I can't see, please reply with a description what it fixes and I'll move it into fixes. Regards, Tony Sure, cleanup-dma sounds ok. Code covers: - my test case for 4460: I could reproduce 2 interrupts @ omap-pcm driver after omap_stop_dma function call. 1st irq CSR: 0x42 (half drop) 2nd irq CSR: 0x02 (drop) Only 1 interrupt occurs after applying this patch(overnight test results) Test case was created to reproduce problem reported by customer(without clear description): contiguous playback of 0.5 wav file (frequent start/stop audio transitions) contiguous data transfers on 15 self-linked dma channels. - omap_request_dma could cause spurious interrupt (enable irq, clear irq status instead of clear irq status, enable irq) thanks, Oleg-- 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
New randconfig build failures in OMAP
I pulled Linus' tree at 7am UTC, and reran the builds after updating the build tree with that (plus my pending devel stuff). The resulting randconfig spat out this: arch/arm/mach-omap2/dsp.c: In function 'omap_dsp_reserve_sdram_memblock': arch/arm/mach-omap2/dsp.c:58: error: implicit declaration of function 'arm_memblock_steal' Looks to me like a missing include? arch/arm/mach-omap2/board-rx51-peripherals.c:147: error: implicit declaration of function 'OMAP_GPIO_IRQ' arch/arm/mach-omap2/board-rx51-peripherals.c:147: error: initializer element is not constant arch/arm/mach-omap2/board-rx51-peripherals.c:147: error: (near initialization for 'rx51_lis3lv02d_data.irq2') arch/arm/mach-omap2/board-rx51-peripherals.c:1033: error: initializer element is not constant arch/arm/mach-omap2/board-rx51-peripherals.c:1033: error: (near initialization for 'rx51_peripherals_i2c_board_info_3[0].irq') Again, a missing include? -- 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: OMAP2+: hwmod code/data: fix 32K sync timer
Hello Benoît
On Tue, 29 May 2012, Cousson, Benoit wrote:
On 5/25/2012 11:56 PM, Paul Walmsley wrote:
This patch is effectively a workaround for a hardware oversight. A
better hardware approach would have been to implement a smart-idle
target idle mode for this IP block. The smart-idle mode in this case
would behave identically to the force-idle mode.
I'm not sure to follow you here :-)
I should rewrite that paragraph. It is not as clear as it could be.
force-idle is almost equivalent to smart-idle, so it is the right
workaround when smart-idle is not implemented.
In force-idle idleack = idlereq. Whereas in smart-idle idleack = idlereq
if internal /OCP activity is completed.
It would be nice if the hardware people just implemented smart-idle on
all IP blocks. Section 3.1.1.1.2 Module-Level Clock Management of The
OMAP4430 TRM Rev. vAA states:
Smart-idle mode is the preferred mode of operation, while forced-idle and
no-idle modes are intended for debugging purposes.
Then no flags or software workarounds would be needed, except for
debugging.
So in fact, I'm wondering if a new flag is needed. We can potentially apply
that if
idlemodes == (SIDLE_FORCE | SIDLE_NO).
We need to check which IP will have that to ensure that does not add any
side-effects.
I guess that means me :-)
BTW, please note that the current idlemodes flags are wrong for the
counter 32k. I've just figured out that fixing the STANDBY flags for
some OMAP5 IPs. I'll add that fix in my WIP OMAP4 hwmod data cleanup for
3.6.
Something like that:
Okay will queue up a fix for 3.5-rc.
.context_offs = OMAP4_RM_WKUP_SYNCTIMER_CONTEXT_OFFSET,
},
},
+ .flags = HWMOD_ALWAYS_FORCE_SIDLE,
I'm confused by the location and the value, both linus/master and
lo/master branches does already have a flag for the counter_32k:
/* counter_32k */
static struct omap_hwmod omap44xx_counter_32k_hwmod = {
.name = counter_32k,
.class = omap44xx_counter_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
.flags = HWMOD_SWSUP_SIDLE,
.main_clk = sys_32k_ck,
.prcm = {
.omap4 = {
.clkctrl_offs =
OMAP4_CM_WKUP_SYNCTIMER_CLKCTRL_OFFSET,
.context_offs =
OMAP4_RM_WKUP_SYNCTIMER_CONTEXT_OFFSET,
},
},
};
So the patch should be slightly different, I guess ?
.class = omap44xx_counter_hwmod_class,
.clkdm_name = l4_wkup_clkdm,
- .flags = HWMOD_SWSUP_SIDLE,
+ .flags = HWMOD_ALWAYS_FORCE_SIDLE,
.main_clk = sys_32k_ck,
.prcm = {
This is the same issue for OMAP3 data.
What base branch are you using?
The wrong one, evidently. Will ensure this is fixed.
- Paul
Re: [PATCH] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Hello Benoît On Tue, 5 Jun 2012, Paul Walmsley wrote: On Tue, 29 May 2012, Cousson, Benoit wrote: So in fact, I'm wondering if a new flag is needed. We can potentially apply that if idlemodes == (SIDLE_FORCE | SIDLE_NO). We need to check which IP will have that to ensure that does not add any side-effects. I guess that means me :-) I looked at a few TRMs. Based on that incomplete survey, the above behavior would probably work for existing chips. But it seems perverse to assume that it is generally safe to set an IP block to force-idle while it's being used. That seems really dependent on the IP block's integration. So in terms of a general fix, the flag approach seems safest to me in the long run. The other advantage of using a flag is that it indicates that this is a hardware workaround; something that it would be nice to fix in future chips. - Paul
Re: New randconfig build failures in OMAP
On Tue, Jun 05, 2012 at 11:02:14PM +0100, Russell King - ARM Linux wrote: arch/arm/mach-omap2/board-rx51-peripherals.c:147: error: implicit declaration of function 'OMAP_GPIO_IRQ' arch/arm/mach-omap2/board-rx51-peripherals.c:147: error: initializer element is not constant arch/arm/mach-omap2/board-rx51-peripherals.c:147: error: (near initialization for 'rx51_lis3lv02d_data.irq2') arch/arm/mach-omap2/board-rx51-peripherals.c:1033: error: initializer element is not constant arch/arm/mach-omap2/board-rx51-peripherals.c:1033: error: (near initialization for 'rx51_peripherals_i2c_board_info_3[0].irq') Again, a missing include? patch: http://www.spinics.net/lists/linux-omap/msg71169.html -- Sebastian signature.asc Description: Digital signature
Re: Compile err when enable CONFIG_SND_OMAP_SOC_OMAP_HDMI
Hi Ricardo Do you see that the playback finishes (even though you don't hear anything)? Also, what version of Pandaboard are you using? Is it Pandaboard or PandaboardES? Have you tried on different TVs? Yes, it can finish normally, and board's version is OMAP4430 ES2.2. After changed to another tv (DELL 2410) I can hear the voice from hdmi audio, :), thanks. Regards, Xiao BR, Ricardo -- 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] remoteproc: block premature rproc booting
On 06/05/12 03:57, Ohad Ben-Cohen wrote: What about using a separate file for the resource table ? That should be very easy to support, and may make life easier for you in the long term. Resource tables tend to change in time, and hard coding it in the kernel doesn't sound ideal (both in terms of development overhead, and kernel-firmware backward and forward compatibility). Thanks. I'll look into that as that seems feasible. Does the below work for you (sans the OMAP terminology ;) ? root@omap4430-panda:/sys/bus/platform/drivers/omap-rproc# echo omap-rproc.1 unbind [ 471.376556] remoteproc remoteproc0: releasing ipu_c0 root@omap4430-panda:/sys/bus/platform/drivers/omap-rproc# echo omap-rproc.1 bind [ 478.219177] remoteproc remoteproc0: ipu_c0 is available [ 478.224639] remoteproc remoteproc0: Note: remoteproc is still under development and considered experimental. [ 478.235015] remoteproc remoteproc0: THE BINARY FORMAT IS NOT YET FINALIZED, and backward compatibility isn't yet guaranteed. [ 478.325347] remoteproc remoteproc0: registered virtio0 (type 7) [ 478.331848] remoteproc remoteproc0: registered virtio1 (type 3) This way user space can unbind a specific remote processor (which will also trigger unbinding the entire device hierarchy below it, i.e. all rpmsg/virtio devices). This is great! I finally see how bind/unbind is useful. What if I don't want to boot the device at kernel start-up? Do I have to make it a module then? -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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] remoteproc: block premature rproc booting
On Wed, Jun 6, 2012 at 6:25 AM, Stephen Boyd sb...@codeaurora.org wrote: What if I don't want to boot the device at kernel start-up? Do I have to make it a module then? Currently, yeah. But we can change stuff if needed. We took that design decision because it was simple and we didn't have any reason not to do it, but I'm thinking we can let the users decide about this using runtime pm (e.g. calling pm_runtime_get_sync with an rpmsg device, which will then be propagated all the way up to the remoteproc device and power it up). -- 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
