Re: [PATCH] musb: move usb_add_hcd to the core init code from gadget code (v2)
With this patch, host mode works. What about OTG and gadget modes? The MUSB hardware is flakey with respect to those init issues. Re-ordering host vs gadget init has been a good way to waste a few months, for anyone who has a few to waste. (And a better way to waste them for folk who do NOT but just need to stay on schedule.) One learns quickly that the Mentor IP follows some other state machine than the USB-OTG says, but even their docs don't help uncover whatever init model they are trying to follow. -- 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/1] arm: omap: gpio: define .disable callback for gpio irq chip
o lazy-disable state This is an odd state, and confusion regularly comes up ... I've never been a fan of having the imperatively named disable_irq() act like a disable_irq_at a_random_later_time_ _but_nyet(). If one must have the latter function, clearer IMO to name it better and have disable_irq() do exactly that by the time it returns ... that is after all what folk expect given its name and conventional interpretation of disable. (ergo confusion when that's not what happens) lazy_disable_irq() would be accurate, butI'm not sure many folk would choose to use it. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/2] mfd: twl6030-irq: move to threaded_irq
--- On Tue, 12/28/10, Mark Brown broo...@opensource.wolfsonmicro.com wrote: F You shouldn't need this any more; the driver used to be faffing around with this because it wasn't using genirq for this in the past. Originally it couldn't, since genirq didn't support threaded IRQ handling... ... Simiarly here as far as I know; the original code predates genirq support for this so is doing some hairy stuff that is no longer required and may actually be harmful. What I'd expect to see from a conversion like this would be that most of the locking/IRQ management stuff would be dropped I'd expect that genirq solve all the issues and that its support be used. That's not the same as dropping anything except the initial code to handle what genirq didn't ... some locking/etc would still mostly need doing, but where genirq now handles it, that'd be preferable. and the bus_lock() and bus_sync_unlock() operations would be implemented. h ISTR maybe four or five genirq updates in the area of threaded IRQ management, added so that issues the twl4030 driver needed to be solved could be solved in generic ways. The first was just having threaded IRQ handlers, and another was I think removing the initial quick'n'dirty thread-per-irq restriction; there was no point in having a few dozen IRQ threads in e.g. a twl4030 driver, since two could never do constructive work concurrently. I'm glad to see this conversion finally start. Even if all the threaded IRQ hooks don't get used to best advantage, it'll be an improvement. -- 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: Issue : jffs2 and ecc layout
ISTR that while JFFS2 worked with NAND, it had to reserve a few bytes of OOB data that might more naturally be used for ECC data. I've not looked at your layout ... does it reserve those bytes for use by JFFS, or is it using them for ECC? Also, ISTR that Some People felt that using JFFS2 with NAND was sub-optimal. Which is why we have other NAND filesystem choices, like UBI/UBIFS, and (currently out-of-tree) YAFFS2. - Dave -- 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: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6
So to recapitulate ... you're agreeing with me on my key point -- that ARM1156, a V6T2 core with Thumb2 support (used in fact to introduce Thumb2), should work for some in-kernel Thumb2 usage, degree TBD, but obviously the v7 cores are more capable (with SIMD support in T2, etc). And no, *I* never said anything about a V7M Linux, that was your words. I'm used to the advantages of using MMUs with fork() and mprotect(), etc. But the updated reason you gave for not allowing V6T2 is that it's an uncommon architecture (one core, not widely manufactured today) ... not impossibility. In short, the basic premise of $PATCH is wrong, as I pointed out, but there may be other reasons to merge it, related to V6T2 chip availability not the actual architecture specs from ARM. A similar argument would be that making the ASM code cope with core variants would get ugly/messy. At least the GNU assembler is, as I recall, aware of which instructions which cores support, so it would provide clean errors if given instructions that are Thumb2 (some flavor) but not accepted by the target. But Linux code shouldn't trigger such errors in the first place, even if they're a good backstop (and that implies ugly core-driven conditional code. -- 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: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6
--- On Tue, 12/7/10, Dave Martin dave.mar...@linaro.org wrote: From: Dave Martin dave.mar...@linaro.org Subject: [PATCH] ARM: Thumb-2: Make CONFIG_THUMB2_KERNEL depend on !CPU_V6... This makes sense, because Thumb-2 code can't execute on anything prior to ARMv7. WRONG ... but you may be overlooking the fact that there are at least three flavors of Thumb-2 ... - Original, as on some ARMv6 chips ARM1156 was the introductory Thumb2 core). It's Thumb1 plus a very few 32-bit instructions. (And maybe the SIMD instructions too; I forget. Not suitable for OS work like IRQ handling, ISTR; or at least, not as suitable as the ARMv7 flavors. -Microcontroller ... ARMv7M chips, and likely not available on Linux-capable hardware ... Suitable for RTOS work like IRQ handling. - Applications ... ARMv7A chips ... like those V6 chips with THUMB2, but with SIMD multimedia instructions and maybe a bit more. Worth tossing THUMB-EE in this bag too. config THUMB2_KERNEL bool Compile the kernel in Thumb-2 mode - depends on CPU_V7 EXPERIMENTAL + depends on CPU_V7 !CPU_V6 EXPERIMENTAL select AEABI select ARM_ASM_UNIFIED help -- 1.7.1 -- 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 v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
Now force CS to be in inactive state only if it was inactive when it was suspended. Note that it's a bug if CS is active in any suspend state (including OFF). That strongly suggests $SUBJECT is an incomplete workaround for that other bug... When SPI wake up from OFF mode, CS is in the wrong state: force it to the inactive state. Best report the bug that the suspend/OFF state was mis-handled... That is, it didn't correctly ENTER that OFF mode... In fact ... I'd like to see that fixed more than the $SUBJECT issue, so the root cause gets resolved... CS should only be active while a SPI message is being processed, and such processing must have completed before suspend/OFF/... starts -- 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 1/4] drivers: hwspinlock: add generic framework
On Fri, 2010-11-26 at 09:34 +0200, Ohad Ben-Cohen wrote: On Thu, Nov 25, 2010 at 10:22 PM, David Brownell davi...@pacbell.net wrote: So there's no strong reason to think this is actually ggeneric. Function names no longer specify OMAP, but without other hardware under the interface, calling it generic reflects more optimism than reality. (That was the implication of my observations...) Well, it's not omap-specific anymore. You haven't (and evidently can't) show non-OMAP hardware under your calls, though ... so in a practical sense, it's still OMAP-specific code (since nothing else is working). (And for that matter, what non-OMAP code should try using these locks??) Your intent generic is fine, but you've not achieved it and thus I think you shouldn't imply that you have. Dropping the word generic should suffice; it _is_ a framework, and maybe the next person working with hardware spinlocks can finish generalizing (and add use cases). To find other hardware spinlocks, you might be able to look at fault tolerant multiprocessors. (For much the same reasons as the various ASMP chips care about HW spinlocks:... SMP can use pure software spinlocks, but when there are special hardware (or system) circumstances, they may not be sufficiently robust/ or reliable. (Consider just the impact of differeent memory and caching models, ARM vs DSP in the OMAP case. Non-Academic specs on fault tolerant computers may be hard to come by, unfortunately ... They're very specialized and often have lots of funky proprietary logic that vendors don't want reverse-engineered. Hardware voting is just the start. The software to make the fault tolerance robust/reliable gets to be very tricky ... and without it, why bother with expensive hardware mechanisms. The same issues come up with aerospace and some industrial systems, where reliability affects mission-readiness and, for industrial apps, safety. Ages ago I worked with one of those, where any spinlock failures integrated with CPU/OS fault detection; HW cwould yank (checkpointed) CPU boards off the bus so they could be recovered (some might continue later from checkpoints, etc.)... Is that HW supported by Linux today ? Not mainline, and unlikely any branch. Fault tolerant operating systems can't be as simple as Linux, and I think that trying to add fault tolerance to it would not only turn it into a very different animal, but would lose most developers. (The mantra I recall was No single Point Failures. Linux has lots of such failure modes, and removing them would be a multi-year effort, even just inside the kernel. (How would you recover from a bus failure? Fan failure? Power supply death? (All such hardware must be duplicated, with recovery supported by both hardware and software...) (Where recover includes keep running without losing data or other computations.) (Last I knew, Linux didn't even have much support for checkpoint and restore of kernel state ... hibernation is related, but seems to be constantly in flux. (Don't think it's aiming to tolerate CPU failures after a hibernation checkpoint either. (Heck ... on my Ubuntu, Network Manager isn't even competent to switch over cleanly from Ethernet to WLAN (and don't get me talking about other ways it's broken. LOTS of stupid fault handling, and that's arguably mission-critical for the whole system ... multiple single point failure modes. That's FAR from fault-tolerant. Any chance you can share a link or any other info about it ? I googled for sequoia systems fault tolerance and found some stuff that looked like it summarized some of the original hardware. I can't think, off the top of my head, of other kinds of system that need and use hardware spinlocks, but likely they do exist. (Mainframe tech might use them too, as part of the subset of fault-tolerant HW tech they build on. If you want to provide a generic framework you should find and support some (or Tom-Sawyer such support... :) I seem to recall some iterations of the real-time patches doing a lot of work to generalize spinlocks, since they needed multiple variants. It might be worth following in those footsteps. (Though I'm not sure they were thinking much about hardware support . Any chance you can point me at a specific discussion or patchset that you feel may be relevant ? Haven't looked at RT in a long time. Just look at the current RT patchset to see if it still has several spinlock variants. ISTR the raw spinlock stuff came from there not long ago. Much compile-time magic was involved in switching between variants. - Dave -- 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 1/4] drivers: hwspinlock: add generic framework
On Thu, 2010-11-25 at 08:40 +0200, Ohad Ben-Cohen wrote: On Thu, Nov 25, 2010 at 5:59 AM, David Brownell davi...@pacbell.net wrote: My rule of thumb is that nothing is generic until at least three whatever-it-is instances plug in to it. Sometimes this is called the Rule of Three. Other than OMAP, what's providing hardware spinlocks that plug into this framework? We are not aware of any. So there's no strong reason to think this is actually ggeneric. Function names no longer specify OMAP, but without other hardware under the interface, calling it generic reflects more optimism than reality. (That was the implication of my observations...) To find other hardware spinlocks, you might be able to look at fault tolerant multiprocessors. Ages ago I worked with one of those, where any spinlock failures integrated with CPU/OS fault detection; HW cwould yank (checkpointed) CPU boards off the bus so they could be recovered (some might continue later from checkpoints, etc.)... This way platforms [2] can easily plug into the framework anything they need to achieve multi-core synchronization. E.g., even in case a platform doesn't have dedicated silicon, but still need this functionality, it can still plug in an implementation which is based on Peterson's shared memory mutual exclusion algorithm And maybe also standard Linux spinlocks? I seem to recall some iterations of the real-time patches doing a lot of work to generalize spinlocks, since they needed multiple variants. It might be worth following in those footsteps. (Though I'm not sure they were thinking much about hardware support . - Dave -- 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 v5 1/1] OMAP2: Spi: Force CS to be in inactive state after off-mode transition
--- On Wed, 11/24/10, Kevin Hilman khil...@deeprootsystems.com wrote: I'm not SPI-aware enough to ack this patch or test it thoroughly. Heh, my excuse is usually not enough time or sometimes no test setup ... ;) In this case I can at least ack the fix in principle. CS active means an active trransfer, which must not happen during OFF or other suspend states. Acked-by: David Brownell dbrown...@users.sourceforge.net Also, in the last patch I suggested you do more of a save/restore of this value instead of a restore to a hard-coded value. IOW, save the value in the suspend method, restore it in resume. More correct to restart message queue processing after resume, if it's non-empty, and to have cleanly stopped it (between messages) before entering suspend states like OFF. -- 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 1/4] drivers: hwspinlock: add generic framework
My rule of thumb is that nothing is generic until at least three whatever-it-is instances plug in to it. Sometimes this is called the Rule of Three. Other than OMAP, what's providing hardware spinlocks that plug into this framework? - Dave -- 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] spi: omap2_mcspi: make use of dev_vdbg()
I know, the sourceforge list is a bit of a pain. As all sourceforge lists are. I don't even know who the admin of that list is. One of the Russian MontaVista crew created that list, and presumably maintains it. -- 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]OMAP:GPTIMER:1ms tick generation correction
--- On Wed, 7/7/10, Tony Lindgren t...@atomide.com wrote: Or can we somehow calculate this drift once during init? If it's set up in the gentime framework, yes; very standard. AT91 is one model (they all have 32K clocks used to generate the system tick). -- 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: On the APIs for Enabling and Disabling Wakeup capability.
I wanted to close on the introduction of two new OMAP device APIs omap_device_enable_wakeup () omap_device_disable_wakeup() in omap_device layer. What's the relationship between these and the sysfs attribute which manages the per-device wakeup enable? Should there be driver model calls, into which these OMAP errata-oriented calls would hook? -- 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:GPTIMER:1ms tick generation correction
Doesn't the generic clock code have logic to handle such rounding issues? I'm pretty sure I remember dealing with that issue for 32K timers on AT91 processors. If so that means the setup is done wrong, and is fixable. -- 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 8/8] usb: musb: Fix suspend interrupt issue in device mode
As a part of aligning the ISR code for MUSB with the specs,the ISR code was re-written. Best say re-aligning. When that code was merged, it was fully aligned with a version of the MUSB specification. Alternatively, specify which version of which spec was used this time around ... :) -- 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: SDHC card affected by preemption model in 2.6.35
When going from PREEMPT_VOLUNTARY to PREEMPT_NONE the problem goes away. Have you found whether this is a problem with the OMAP HSMMC driver versus the MMC/SD framework code -- 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: [linux-pm] suspend blockers Android integration
--- On Fri, 6/11/10, James Bottomley james.bottom...@suse.de wrote: Do we at least have a clean way that a driver can reject a system suspend? I've lost track of many issues, but maybe this could be phrased as a QOS constraint: the current config of driver X needs clock Y active to enter the target system suspend state, driver's suspend() method reports as much. Then the entry to that system state gets blocked if the clock isn't enabled. So in QoS modifications to android patches, the answer is yes ... except that the current android patch set didn't actually have this type of wakelock in it. Except, we're not talking wakelock ... :) So ... no, these cases still have no solution. (I think that's at least five years now.) The one thing that does look difficult is that these power constraints are device (and sometimes SoC) specific. Exactly why they make good examples for turning up framework limitations... like having overlooked constraints coming from various SoC peripherals. Expressing them in a generic way for the cpu govenors to make sense of might be hard. Requiring CPU governors to be involved in such stuff feels a bit off-course to me. At least, if the involvement is very deep. The constraints are from the integrated peripherals, not (usually) from the CPU There are plent of places to hang SoC or device specific data, once there's awareness that without such data, (which PCs hide behind ACPI bytecode) the PM framework is missing out on support for some desirable low power modes. (That QOS constraint should be removed when that driver no longer needs to issue wakeups; that's not quite the same as removed by driver.resume(). The USB one needs user input, doesn't it, I don't quite see that. The drivers get called in enough places, and they'll know if the system is going to be in a suspend state where they need to be partially aactive (with various QOS constraints, or they can't work. since user hotplug might (or might not) be one of the wakeup sources. If it wakes via hotplug, then the driver must already Do The Right Thing; what input would be needed (Beyond changing the cable config)? James -- -- 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: [linux-pm] suspend blockers Android integration
This is a bit off the topic of Android flamage, but I thought it would be worth highlighting an example where the current frameworks may still have a deficiency... one that likewise relates to needing to block entry ot a system suspend state, but in this case user-space isn't very involved (just drivers coping with hardware). The example I wanted to re-post (I've done so in the past) is one where drivers ouldn't really do the right thing, since driver.suspend() wasn't quite powerful enough as a programming interface. The example works with USB on many ARM SoCs, and similar non-USB examples aren't rare. - Want to enter a system suspend state, with some USB wakeup sources. USB peripheral waken up by the host, or vice versa. NOTE ASSUMPTION: there are multiple suspend states supported by the hardware, significantly different in hardware configuration Linux should be able to use more than one such state... (if only because their power savings differ.) This can mean driver-specific knowledge about those various states. - The wakeup requires a particular clock to be active, so the USB controller can detect that the wakeup should trigger, then issue the right signals triggering the non-USB parts of the system. Problem: how does the device driver suspend() method block entry to a suspend state when it can't ensure that clock is going to be active. Magic return code? There are other issues here too. (Is the target system suspend state one of the ones which doesn't allow that clock to be active? SoC-specific calls might suffice for this issue. A number of years ago, this problem was insoluble with the then-current Linux PM and clock frameworks. I've been away from this issue for quite a while now, but don't recall seeing its sub-problems get solved ... If they're now solved, I'll be glad. (I know Kevin's recent OMAP stuff addresses similar issues, but It's OMAP-specific...) After all these thousands and thousands of emails... I'm not sure how much forward motion has happened. Do we at least have a clean way that a driver can reject a system suspend? I've lost track of many issues, but maybe this could be phrased as a QOS constraint: the current config of driver X needs clock Y active to enter the target system suspend state, driver's suspend() method reports as much. Then the entry to that system state gets blocked if the clock isn't enabled. (That QOS constraint should be removed when that driver no longer needs to issue wakeups; that's not quite the same as removed by driver.resume(). -- 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: [linux-pm] suspend blockers Android integration
--- On Mon, 6/7/10, Peter Zijlstra pet...@infradead.org wrote: So what's up with this Binder stuff, from what I can see its just yet-another-CORBA. Why does it need a kernel part at all, can't you simply run with a user-space ORB instead? I really don't get why people keep re-inventing CORBA, That made me laugh. Do you realize that one of the earliest objections to CORBA was why do people keep re-inventing RPC ... :) (Simple answer: the existing stuff didn't solve enough of the right problems ... and it was easier (in a political sense) to come up with something new than to try fixing DCE or ONC (or whatever). Similar answers may still apply ... last I looked at CORBA, it didn't standardize desktop integration (or cell-phone equivalents), and the pure user-space versions suffered slowdowns when looking up object bindings. there's some really nice (free) ORBs out there, -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
If suspend is the thing we are used to via /sys/power/state then the race will persist forever except for the suspend blocker workaround, True, because device wakeups are enabled by device.driver.suspend() methods, which are invoked towards the end of the activities triggered by writing /sys/power/state. Now, there can be platforms (mostly embedded) where the drivers adopt a policy that not only do they keep their devices in as low a power state as practical at all times, but they also keep the hardware wakeup mechanisms enabled (they may be needed to kick the hardware out of those low power states) ... That is, suspend() might be superfluous (a NOP) in those platforms' drivers. Such platforms might also be (non-ACPI) ones where idle C-states and S3/STR have the same power consumption ... but that would be a platform-specific issue, not a generic thing which all Linux implementations could rely on. - Dave -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
--- On Tue, 6/1/10, James Bottomley james.bottom...@suse.de wrote: As long as you can set a wakeup timer, an S state is just a C state with side effects. I've seen similar statements on this endless thread before; they're not quite true... The significant one is that entering an S state stops the process scheduler and any in-kernel timers. There's a structural difference too, related to peripheral device activity and power states. Specifically, peripherals can be active in C states (erforming I/O, maybe with DMA etc) and will in general not be in lowest power states (PCI etc). Whereas entry to ACPI S-states involves calling the AML code to put those peripherals into lowest power modes ... ones they can't in general enter at run time. (An additional task of that bytecode is to activate any wakeup logic, which again is not generally functional in except in S-states). The point being perhaps more that ACPI doesn't map well to the more power-efficient architectures (often built on ARM) ... hardware vendors provide all kinds of PM hooks, and Linux can choose between them so it's more power-miserly than if it tried to emulate an ACPI based platform. I've seen some Linux systems which put DRAM into self-refresh during certain idle modes, for example, not just during suspend-to-RAM, if it's known that no DMA is active. (Why not save that power if it's safe?) Likewise, disable some oscillators and PLLs if they're not needed (the clock API allows that to be done regardless of C-states etc). The notion of suspend gets introduced on such systems primarily to match the ACPI-ish models that exist ... rather than because they necessarily make good matches for the hardware. Which has left a puzzle: how and why to use such suspend models? Maybe that's underlying some of the pushback for the notion of automagic entry to suspend states. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
--- On Mon, 5/31/10, Grazvydas Ignotas nota...@gmail.com wrote: Another issue is that OTG depends on PM, so if I build PM-less kernel (PM is still more or less in development on OMAPs), Kconfig will only allow host or peripheral for musb, which doesn't match OTG selection in the board file, and the driver fails. As Felipe partially explained: OTG implies HNP, and HNP requires suspending the USB link, which requires some PM support... -- 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/3 v3] AM35x: Add musb support
--- On Fri, 5/28/10, Sergei Shtylyov sshtyl...@mvista.com wrote: Ajay Kumar Gupta wrote: AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine. It has USB phy built inside the IP itself. So it's more like DaVinci (earlier CPPI as well as integrated PHY) than OMAP3... Also added ARCH_AM35x which is required to differentiate musb ips between OMAP3x and AM35x. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
--- On Fri, 5/28/10, Steve Sakoman sako...@gmail.com wrote: By the way ... the #ifdeffery should indeed vanish from all board configs except the Davinci DM6446 EVM. That board is kind of quirky in terms of USB support, and needs jumpering to get host or peripheral mode (and can't do OTG). For Overo this patch actually makes quite a bit of sense (and I have been using something similar for quite some time). The Overo COM itself has no USB connector -- the customer can choose or create a daughter card with the type of USB connector appropriate to their application, So that would be another exception ... because it doesn't have a fixed USB connector (and thus does not convey to users any specific details about what modes it supports). - Dave -- 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] touchscreen: ads7846: please don't touch free'd memory
--- On Tue, 5/25/10, Kevin Hilman khil...@deeprootsystems.com wrote:
This is a load of crap. If probe() fails that
means that driver does not
manage the device
And thus, dev-driver shouldn't be assigned ...
That probe() looks very odd, lately, yes. It seems
to have changed a lot over the past few years, and
grown a few fault paths that don't behave right (that
is, they don't clean up properly on failure, or don't
report their faults)...
and thus ads7846_suspend()
and ads7846_resume() should
not be called _at all_.
Those being called is an indication that
the probe() succeeded so the driver is
bound to that device...
If SPI core manages
to call random methods from
the drivers that failed to bind to a device
that should be fixed in SPI
core.
Not random methods. The appropriate ones ... for
the case where probe() succeeded and the device has
been properly set up.
I suspect a bug was added when the driver binding got rewritten, whereby
dev-driver was wrongly assigned
on fault paths (where it should have been cleared).
Of course that goes through slightly convoluted bits
of driver model code... maybe there's no such bug,
and everything is explained by probe() misbehaving.
Agreed, this is indeed a bug in the SPI driver
core.
That's not at all clear to me.
However, by fixing the SPI core to unregister the
driver on failure
(patch below),
... as you noted, not a good patch below.
The issue seems to be on probe() paths, NOT
as part of driver registration.
we prevent the suspend resume
methods from being
called, but the driver's -remove() method will
still be called due to
the driver_unregister(). So at least the
remove() method needs fixing
to prevent accessing free'd memory.
That doesn't seem right; if the issue is probe()
misbehavior, fixing that makes that access issue
go away. Don't change remove() etc.
I see two issues. One
is flakey ads7846 probe() behavior. Another is
the response of the current SPI core code to that
flakiness ... the report here seems to indicate that
the driver is bound to the device even though it's not
been properly set up ... unclear whether probe() is
reporting a clean failure, I suspect not. (If it
were reporting a clean failure, the device should
end up with no driver bound.)
It's very possible the probe() errors explain all
the problems.
Unless there are objections, I'll post the below
along with an updated
version of ads7846 patch.
Kevin
diff --git a/drivers/spi/spi.c
b/drivers/spi/spi.c
index b3a1f92..42d4d26 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -175,6 +175,8 @@ static void
spi_drv_shutdown(struct device *dev)
*/
int spi_register_driver(struct spi_driver
*sdrv)
{
+ int ret;
+
sdrv-driver.bus =
spi_bus_type;
if (sdrv-probe)
sdrv-driver.probe = spi_drv_probe;
@@ -182,7 +184,12 @@ int
spi_register_driver(struct spi_driver *sdrv)
sdrv-driver.remove = spi_drv_remove;
if (sdrv-shutdown)
sdrv-driver.shutdown = spi_drv_shutdown;
- return
driver_register(sdrv-driver);
+
+ ret =
driver_register(sdrv-driver);
+ if (!ret)
+
driver_unregister(sdrv-driver);
This is still wrong. driver_register() should properly
clean up after
itself and not require calls to driver_unregister()
(and I believe it
does).
Right ... driver registration should always be safe.
The tricky bit would be a side effect: probing any
devices which match that driver. Don't unregister
drivers on error; just make sure they don't get wrongly
bound to devices if probe() misbehaves.
Besides, I do not see how this patch changes anything
with regard to
binding devices and drivers. Even if driver_register()
succeeds, binding
may still fail and we should not be calling neither
-remove(), nor
-suspend()/-resume() for the devices that
failed to be bound.
Hmm, good point.
After digging into the driver core and realizing that it
seemed to
have sane error handling itself,
Sane but somewhat convoluted. It can be tricky
to figure out.
I took a closer look at
ads7846_probe() and discovered it doesn't actually return
an error
code for certain failure cases! That was the root
cause.
My conclusion too...
The patch below fixes the problem.
Did you do much of an audit, or just work to fix
this specific problem? I thought the code was
looking fairly goofy. Regulator additions were
pretty recent, but it wasn't clear to me that it'd
be the *only* source of such problems...
Thanks,
Kevin
From 3588494cf6e51754f7089bb8089b99abd765c493 Mon Sep 17
00:00:00 2001
From: Kevin Hilman khil...@deeprootsystems.com
Date: Tue, 25 May 2010 14:38:04 -0700
Subject: [PATCH] input: touchscreen: ads7846: return error
on probe failure
In probe(), if regulator_get() failed, an error code was
not being
returned causing the driver to be successfully bound, even
though
RE: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
--- On Fri, 5/21/10, Gupta, Ajay Kumar ajay.gu...@ti.com wrote: Then I think these #ifdefferys are required in all the board files. As I already explained: *NO*. Unless the board has been designed in a flakey manner (like the DM6446 EVM) it should have no #ifdeffery in the MUSB configuration. Then if I choose to compile the Kernel only for peripheral mode (Case-B above) then I would get below error from musb_core.c. incompatible Kconfig role setting That's a *correct* report that your config is broken. The hardware has an OTG connector, so the kernel should be supporting OTG mode. If it's not, that's an error; don't try to hide such errors. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
incompatible Kconfig role setting there's a patch making that a warning instead of an #error if I'm not wrong. It's not an #error, it's a dev_err(). But more to the point, it's reporting a real error. As the comment in the code explains: /* The driver might handle more features than * the board; OK. * Fail when the board needs a feature that's * not enabled. */ Ut;s simple: OTG connectors require OTG support. Host connectors require host support. Peripheral connectors require peripheral support. Why is anyone confused?? -- 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: Re: omap_musb_board_data -- trouble specifying 500mA supply
Actually in OMAP board files, power values have been provided With units of 1mA Everywhere (!!) in the Linux-USB stack, those units should be 2mA (just like in config descriptors) ... which gets divided to half in arch/arm/mach-omap2/usb-musb.c ... which is why there's a divide-by-two there. before sending it to musb driver. ... the divide-by-two should only be skipped when talking to power supplies or regulators, which don't have USB conventions to be concerned with. Looks like some board files need bugfixing. - Dave -- 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] gpiolib: introduce set_debounce method
--- On Fri, 5/21/10, Alan Cox a...@lxorguk.ukuu.org.uk wrote: GPIO is almost always fairly tightly platform bound Not entirely. SOC based ones, yes. But GPIOs on expanders and ancillary chips have more variable capabilities, and many SOC-based boards have a bunch of those. so features only existing on certain ports is fine. The platform vendor will have made sure they relevant ports have suitable debounce facilities. One of the earlier examples of why to want debouncing (in the original discussion, not this one) was for buttons (one signal per button press) and the hardware designers don't necessarily hook buttons up to only GPIOs with hardware debounce. So code to kick in debounce there needed to be sensitive to whether or not the capability was available ... and moreover, whether the debounce scale was adequate to compensate the contact chatter. When not, then software debounce was inescapable. -- 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] gpiolib: introduce set_debounce method
Not all GPIOs have hardware debounce though, so offering this capability sort of begs the question of where/how to provide a software debounce mechanism too... how about adding a flag for supported features and if that hardware doesn't support we simply return, Presense of a debounce method would suffice when gpiolib is in use (vs direct implementation of the API provided by gpiolib). or fallback to software emulation if chosen by the user. ISTR that if you look back to the original discussion about GPIO debouncing, you will find such a software implementation; and maybe such an integration ... -- 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: Re: omap_musb_board_data -- trouble specifying 500mA supply
We are designing a custom OMAP board that
will have a 500mA supply on
the OTG port. It looks like the power
is set with:
struct omap_musb_board_data {
u8
interface_type;
u8
mode;
u8
power;
};
However, with a u8, the max value is
255. Should power be changed to a
u16?
No. The units are 2mA not 1mA, matching the USB specs.
So to specify 500mA (the max), say 250 ...
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
I think better remove .mode parameter from board_data if its not needed anyways But it *IS* needed, as I explained before... if some board supports only some specific mode they can select those specifc config only. No they can't. Recall that kernels are expected to run on multiple boards. Which means that the same kernel should be able to work correctly on a board with a peripheral-only USB connector ... and on a board with an OTG connector. The way to pass that information to the MUSB driver is through the platform data. On the peripheral-only config the host code won't kick in. On the OTG-enabled config, it will kick in as needed (as will the peripheral mode). And so on. If you were to rely on Kconfig options, then at least one of those boards would work incorrectly. So that's not an option. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
Subject: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles. Fix board data to support device only, host only and OTG roles. The board data hardcodes the mode to OTG or Peripheral. Or host. That's correct... because the *BOARD* is hard-wired that way. Based on what connector is present, the driver uses that board-specific data to ensure it's exposing the right capabilities. (Example, a host-only board won't expose either OTG or peripheral capabilities, etc.) This fix will allow to use Peripheral, Host and OTG roles independently. The driver has had that capability almost forever... If you're saying that somebody broke the mode setup logic in the driver, which originally tested the board capabilities before it enabled the relevant driver capabilities, then the solution is to un-break that code ... not to further break it. ISTR it was pretty straightforward: boards with a host or peripheral connector could only enter that driver mode, but boards with an OTG connector could enter either driver mode. This affected initialization (one or both sides of the USB stack needed initialization before the driver could properly start) as well as role switching at runtime (either based on ID-sensing in the connector, or HNP). As of something like a year and a half ago, the cable based role switching worked pretty well (ID sensing) and HNP behaved at least partially, although there were some OTG conformance test failures (timing etc, but the roles did switch correctly via HNP, verified with both OMAP3 and DaVinci boards). Now the PITA was that the Mentor IP doesn't clearly document some of the key initialization or role switching steps. I recall losing over a month trying to make sense of what they wanted, since their state machine didn't match the OTG spec. I could easily believe that some patch broke that again. Which means someone might need to bisect things to fix a bug they inserted... Peripheral mode init was fragile to an extreme; changing the sequence was almost guaranteed to break something. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Fix board data to support device only, host only and OTG roles.
+#ifdef CONFIG_USB_MUSB_OTG + .mode = MUSB_OTG, +#elif defined(CONFIG_USB_MUSB_HDRC_HCD) + .mode = MUSB_HOST, +#elif defined(CONFIG_USB_GADGET_MUSB_HDRC) .mode = MUSB_PERIPHERAL, +#endif = MUSB_PERIPHERAL, +#endif By the way ... the #ifdeffery should indeed vanish from all board configs except the Davinci DM6446 EVM. That board is kind of quirky in terms of USB support, and needs jumpering to get host or peripheral mode (and can't do OTG). I suspect some of the other boards did a bad thing and tried emulating what that board did. But the description for such a patch would emphasize removing bogus ifdeffery, to match the board hardware (which is not conditional but is instead fixed). -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
during development on MeeGo devices we try to tackle down as much as possible the use_time offenders and start by filing bugs to those apps, instead of fixing their issues in kernel space. Some apps do abuse kernel mechanisms, and whether the bug is in the app or that kernel mechanism can be a judgement call. I'd expect to see some fixes be appropriately in-kernel; maybe not many though. When reading about this suspend block stuff, does anyone else hear eachoes of APM? It's been ages since that was used, but ISTR it also leveraged handshaking between kernel and userspace. Are there lessons to be applied from there to this discussion? On first principles, I don't see anything wrong with acknowledging that the kernel doesn't have a whole system PM view and thus its PM knowledge could usefully be augmented by information from userspace (applications), possibly on request. Just what that broad PM view consists of gets kind of system-specific. For OMAP hardware, with smart device-level power reduction active almost all the time, it may look different from an ACPI laptop where the BIOS is biased towards saving device power primarily in some suspend state(s) ... or some other hardware platform without much hardware or BIOS assist, where the main PM mechanisms involve software detection/instigation of hardware idleness (and potentially off-ness). And you will continue doing that once the Meego app store has 100k apps? I may have overlooked it, in one of the 100K messsages in my mailbox about versions of suspend block/etc patches ... But surely NOBODY is actually contending that broken aps NOT get fixed?? It's clear to me that tools are needed to identify power hogs; powertop can't be the extent of such tools. (ISTR it doesn't monitor display power usage, for one thing; maybe newer versions do so.) Once such hogs get identified they will need to get fixed. Any other proposal seems broken to me... -- 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] gpiolib: introduce set_debounce method
This would be generally useful for embedded systems, especially where the interrupt concerned is a wake source. It allows drivers to avoid spurious interrupts from noisy sources so if the hardware supports it the driver can avoid having to explicitly wait for the signal to become stable and software has to cope with fewer events. True. Not all GPIOs have hardware debounce though, so offering this capability sort of begs the question of where/how to provide a software debounce mechanism too... We've lived without it for quite some time, though. I looked at adding debounce support to the generic GPIO calls (and thus gpiolib) some time back, but decided against it. I forget why at this time (check list archives) but it wasn't because of lack of utility in certain contexts. One thing to watch out for is just how variable the hardware capabilities are. Atmel GPIOs have something like a fixed number of 32K clock cycles for debounce, twl4030 had something odd, OMAPs were more like the Atmel chips but with a different clock. In some cases debouncing had to be ganged, not per-GPIO. And so forth. - Dave -- 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: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
-0700, David Brownell wrote: Some apps do abuse kernel mechanisms, and whether the bug is in the app or that kernel mechanism can be a judgement call. I'd expect to hey come on, there's no judgement call for an app polling every second to check battery status or some other status that doesn't change that frequently. Or something as broken as a non-terminating CPU loop ... Of course not. But if there's a kernel mechanism exposed to userspace which really sucks down power ... either it's done correctly and the problem is userspace abusing it, or it's done wrong so that it's not possible to be used correctly. There are some things that just cost power, and that cost can't be escaped. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/4] twl4030 threaded_irq support
On Tuesday 26 January 2010, Felipe Balbi wrote: But nothing in drivers/mfd ... the entry to the whole stack? ... correct, that's still missing. I tried to play with it for a while, but had to give up due to other musb tasks. So if someone wants to step up and code that part, I'd be glad I'm quite sure I sent a patch doing that ... sometime early last summer, when the threaded IRQ stuff was being thrashed out! (To show what it'd look like, and see what problems remained.) That interface hasn't changed much since then, except for addition of a stuff like ONESHOT support, set_irq_nested_thread(), and the bus_lock stuff. It's surely in LKML archives. :) My point here was more like: these patches shouldn't merge without that top-level change. Just switch the whole current structure (one thread, nesting) over to the now-standard interfaces at the same time, not incrementally. Later, the bus_lock stuff can switch over too (for cleaner mask/unmask). That's clearly material for 2.6.34 though ... - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/5] usb: otg: add notifier support
On Friday 11 December 2009, Felipe Balbi wrote:
The notifier will be used to communicate usb events
to other drivers like the charger chip.
Good idea ... but not OTG-specific. It doesn't seem to me
that charging hookups belong in that header at all.
In fact, usb_gadget_vbus_draw() might better be implemented
as such a notifier call, removing that configuration mess
from the usb gadget drivers (how can I know what charger
to use??). That would be the most common situation: a
peripheral-only device.
And in fact, OTG can be treated as a trivial superset of
peripheral-only USB. (In terms of charger support, only!!)
I'd vote to convert all the USB-to-charger interfaces so
they use notifiers. After fixing the events ... see
comments below. :)
This can be used as source of information to kick
usb charger detection as described by the USB
Battery Charging Specification 1.1 and/or to
pass bMaxPower field of selected usb_configuration
to charger chip in order to use that information
as input current on the charging profile
setup.
Signed-off-by: Felipe Balbi felipe.ba...@nokia.com
---
include/linux/usb/otg.h | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 52bb917..6c0b676 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -9,6 +9,8 @@
#ifndef __LINUX_USB_OTG_H
#define __LINUX_USB_OTG_H
+#include linux/notifier.h
+
/* OTG defines lots of enumeration states before device reset */
enum usb_otg_state {
OTG_STATE_UNDEFINED = 0,
@@ -33,6 +35,14 @@ enum usb_otg_state {
OTG_STATE_A_VBUS_ERR,
};
+enum usb_xceiv_events {
Let's keep charger events separate from anything else,
like enter host mode or enter peripheral mode (or
even disconnect). The audiences for any other types
of event would be entirely different.
Right now there's a mess in terms of charger hookup,
so getting that straight is IMO a priority over any
other type of event. Using events will decouple a
bunch of drivers, and simplify driver configuration.
+ USB_EVENT_NONE, /* no events or cable disconnected */
+ USB_EVENT_VBUS, /* vbus valid event */
+ USB_EVENT_ID, /* id was grounded */
+ USB_EVENT_CHARGER, /* usb dedicated charger */
+ USB_EVENT_ENUMERATED, /* gadget driver enumerated */
Those seem like the wrong events. The right events for a charger
would be more along the lines of:
- For peripheral: you may use N milliAmperes now.
- General: Don't Charge (a.k.a. use 0 mA).
I don't see how N would be passed with those events ...
Haven't looked at the details of the charger spec, but
those two events are the *basics* from the USB 2.0 spec,
so official charger hardware wouldn't be less capable.
Thing like different levels of VBUS validity, ID grounding,
and so forth ... wouldn't be very relevant. An OTG driver
will do various things, internally, when ID grounds; but
anything else is a function of what role eventually gets
negotiated. And for the charger, they all add up to Don't
Charge (since ID grounded means A-role, sourcing power).
A host *might* want to be able to say things like supply
up to N milliAmperes now, e.g. to let a regulator choose
the most efficient mode.
+};
+
#define USB_OTG_PULLUP_ID(1 0)
#define USB_OTG_PULLDOWN_DP (1 1)
#define USB_OTG_PULLDOWN_DM (1 2)
@@ -70,6 +80,9 @@ struct otg_transceiver {
struct otg_io_access_ops*io_ops;
void __iomem*io_priv;
+ /* for notification of usb_xceiv_events */
+ struct blocking_notifier_head notifier;
Why blocking? That seems kind of unnatural; for example,
the main users -- like usb_gadget_vbus_draw() -- would be
called in IRQ context (blocking not allowed).
+
/* to pass extra port status to the root hub */
u16 port_status;
u16 port_change;
@@ -203,6 +216,18 @@ otg_start_srp(struct otg_transceiver *otg)
return otg-start_srp(otg);
}
+/* notifiers */
+static inline int
+otg_register_notifier(struct otg_transceiver *otg, struct notifier_block *nb)
+{
+ return blocking_notifier_chain_register(otg-notifier, nb);
+}
+
+static inline void
+otg_unregister_notifier(struct otg_transceiver *otg, struct notifier_block
*nb)
+{
+ blocking_notifier_chain_unregister(otg-notifier, nb);
+}
/* for OTG controller drivers (and maybe other stuff) */
extern int usb_bus_start_enum(struct usb_bus *bus, unsigned port_num);
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/5] usb: otg: add notifier support
On Tuesday 26 January 2010, Mark Brown wrote: On Tue, Jan 26, 2010 at 03:16:20AM -0800, David Brownell wrote: I'd vote to convert all the USB-to-charger interfaces so they use notifiers. After fixing the events ... see comments below. :) Yes please - it's not just chargers either, this can also be used by PMICs which do power path management that includes USB. Color me confused ... what do you mean by power path? Do you mean something like the board as a whole can take N mA of current from USB, rather than specifically addressing a charger? It's not uncommon to do things like use VBUS current to power the USB circuitry, too. That can leave less for other purposes. All of that being rather board-specific. Those seem like the wrong events. The right events for a charger would be more along the lines of: - For peripheral: you may use N milliAmperes now. - General: Don't Charge (a.k.a. use 0 mA). I don't see how N would be passed with those events ... These are good for the peripheral side. You do get to pass a void * along with the notifier value, that could be used to pass data like the current limit. I don't think I saw that being done ... either in code, comments, or documentation. Passing N is fundamental. A host *might* want to be able to say things like supply up to N milliAmperes now, e.g. to let a regulator choose the most efficient mode. Yes, they definitely want this - not just for efficiency but also to allow current limiting to protect the system from excessive current drain. There are load bursting issues too. All part of the USB spec; a load that's OK for 1 millisecond might not be OK for 1 second. ISTR the supply N mA refers to an average. And there are some limits to the capacitance that can practically be stuck on VBUS output lines (which includes the cable). Solvable problems, but not always pretty if software has to think it through. Thing is, supplying current is a bit more involved. If the board can't supply 300 mA, the USB configuration selection mechanism has to know that, so it never selects peripheral configurations which require that much current. Or maybe these two ports can serve 500 mA, but not those two; or their total can't exceed N (function of componentry and power budgeting). Ergo my desire to start with a straightforward problem whose solution has real value (how much VBUS current may be consumed?), and leave some of those other messes for later! - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/5] usb: otg: add notifier support
On Tuesday 26 January 2010, Felipe Balbi wrote:
+enum usb_xceiv_events {
Let's keep charger events separate from anything else,
like enter host mode or enter peripheral mode (or
even disconnect). The audiences for any other types
of event would be entirely different.
the idea was to notify USB events to interested drivers, not only usb
charger events.
There are thousands of events that could be issued.
I'd rather start with one specific problem, which
can really benefit from being solved.
If necessary, other events can be added later.
Right now there's a mess in terms of charger hookup,
so getting that straight is IMO a priority over any
other type of event. Using events will decouple a
bunch of drivers, and simplify driver configuration.
well, if you consider that this transceiver isn't really otg specific,
then this is already wrong.
It's the only transceiver interface we have; and it
works for OTG transceivers in peripheral-only mode,
as well as host-only and dual-role modes. So it's
not especially wrong.
However, you can consume N milliAmperes now doesn't
need to be coupled to a transceiver at all. In fact,
it works just fine with any pure peripheral interface.
The gadget stack uses such calls ... and doesn't need
to be coupled to any transceiver. (But obviously it
can hook up to an OTG transceiver.)
+USB_EVENT_NONE, /* no events or cable disconnected */
+USB_EVENT_VBUS, /* vbus valid event */
+USB_EVENT_ID, /* id was grounded */
+USB_EVENT_CHARGER, /* usb dedicated charger */
+USB_EVENT_ENUMERATED, /* gadget driver enumerated */
Those seem like the wrong events. The right events for a charger
would be more along the lines of:
- For peripheral: you may use N milliAmperes now.
- General: Don't Charge (a.k.a. use 0 mA).
I have to disagree, which information would you used to kick the usb
dedicated charger detection other than VBUS irq from transceiver ?
That's why I said what I did about the separate charger spec (and
you quoted it below): it's not going to be less than those two
ops, which your events don't really capture.
That's bonus functionality though ... among other reasons, it's
not all that common yet. The basic charge battery over USB
scenario needs to work without that stuff.
So we need at least that, and also need to notify when the charger
detection is finished, so we can enable data pullups on the link.
Remember we might be connected to a charging downstream port.
So you're presuming some separate component will do charger
detection by listening for events? If it's mucking with the
pullups, that seems very much like what an OTG transciever
needs to be managing. And thus, perhaps, transceiver code.
If there's such a separate component, I'd like to see some
detail about how it'd work. But ... at first glance, it'd
have thought it'd be simplest inside a transceiver driver.
I don't see how N would be passed with those events ...
there's a void * we can use to pass bMaxPower field of the selected
configuration.
Needs to be part of the event spec...
Haven't looked at the details of the charger spec, but
those two events are the *basics* from the USB 2.0 spec,
so official charger hardware wouldn't be less capable.
I believe the dedicated charger is also basic.
We could take a vote to see how many folk have even seen
one, much less own one. They're not very common, and not
part of the USB 2.0 spec. That's why I say not basic.
Thing like different levels of VBUS validity, ID grounding,
and so forth ... wouldn't be very relevant. An OTG driver
will do various things, internally, when ID grounds; but
anything else is a function of what role eventually gets
negotiated. And for the charger, they all add up to Don't
Charge (since ID grounded means A-role, sourcing power).
ID grounding event is necessary if you have an external charge pump.
At least the boards I've been working use an external chip as the USB
Charger and Charge pump, iow, the transceiver doesn't source VBUS on ID
ground, but the charger chip is put into boost mode for that role.
As you say: transceiver stuff. What I'm used to seeing is
what the OTG spec says: ID grounding is an event, which
triggers state machine transitions. One such transition
involves sourcing VBUS power and making sure it ramps up
properly. Activating that, and monitoring it, depend on
hardware details which are tightly coupled to transceiver
logic and implementation.
#define USB_OTG_PULLUP_ID (1 0)
#define USB_OTG_PULLDOWN_DP (1 1)
#define USB_OTG_PULLDOWN_DM (1 2)
@@ -70,6 +80,9 @@ struct otg_transceiver {
struct otg_io_access_ops*io_ops;
void __iomem*io_priv;
+/* for notification of usb_xceiv_events */
+struct blocking_notifier_head notifier;
Why blocking? That seems kind of
Re: [RFC/PATCH 1/5] usb: otg: add notifier support
On Tuesday 26 January 2010, Felipe Balbi wrote: but when suspended, we have to cut power ASAP. If not enumerated we can still draw power for a few miliseconds due to dead battery provision. When suspended, it's OK to draw a small amount of power. On the order of one milliamp, based on the config that's active ... instead of, often, hundreds. That limit is why for example a PXA 255 could never get certified as a bus-powered peripheral. It required much more than that when in suspend mode. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/5] usb: otg: add notifier support
On Tuesday 26 January 2010, Felipe Balbi wrote: Thing is, supplying current is a bit more involved. If the board can't supply 300 mA, the USB configuration selection mechanism has to know that, so it never selects peripheral configurations which require that much current. but that's done already by the usb core, no ? It rules out configuration based on the hub-power_budget (can't remember if the field is that exact name). Yes, it handles that ... but where does the power budget come from? That's what I meant by more involved. As in, the host/supplying side of the power equation can't be event driven like the peripheral/consuming side can. And that's another reason I think it's best to fully solve the common (peripheral, recharge-that-batter) case first. - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/5] usb: otg: add notifier support
On Tuesday 26 January 2010, Felipe Balbi wrote: just remember of another problem which I couldn't solve yet: if you boot the board with the usb cable already attached, then we miss the first notification because when the notifier is called, usb controller driver isn't probed yet. That's part of why the OTG transceiver driver has methods used by host and peripheral drivers to register themselves. Standard init sequence there is to do nothing until both drivers are fully initialized ... last step being to register the drivers with the transceiver. That way the transceiver can know when its peer drivers are ready. Example: VBUS present from a host. If the board runs in OTG mode, as soon as both drivers are registered then the B-Default state machine would start running ... and that involves (see the OTG state machine!) issuing a VBBUS event. Same thing can be done with the power events. As soon as an event listener is registered, it could be fed any events it missed. (Just one approach; one must sort out any other interdependencies too. In this case, it can make sense to consume 100mA current right away, and then adjust the draw later if needed.) - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/5] usb: otg: add notifier support
On Tuesday 26 January 2010, Mark Brown wrote: Yes please - it's not just chargers either, this can also be used by PMICs which do power path management that includes USB. Color me confused ... what do you mean by power path? In the sort of design I'm talking about there is generally a system power rail which is generated from the various power sources available to the system, which might include a combination of batteries, USB and wall adaptors. Just as an example: drivers/mfd/tps6510.c supports exactly that trio of power sources. More than one system rail though, which (as you know) is pretty common -- core != I/O. It's *way* simpler than e.g. the TWL6030. :) The power path management logic is the hardware which controls which of these are actually being used as supplies, and may also include battery charger management. Do you mean something like the board as a whole can take N mA of current from USB, rather than specifically addressing a charger? Pretty much, from this point of view. OK -- clear now. It's not uncommon to do things like use VBUS current to power the USB circuitry, too. That can leave less for other purposes. All of that being rather board-specific. In this sort of design either VBUS goes through the power path management logic before anything else gets to use it or the hardware will know about the headroom it needs to leave. The power path management will usually do things like try to suppliment VBUS with any battery that's available to generate the main system supply rail. This all needs to function without software since it tends to get used to decide things like if the system is able to begin power up at all, . Yep. That's part of the reason the USB specs have hard rules about having 100 mA available (for some period) even before software can come up. Bus powered devices can come up on that 100mA, running enough to enumerate ... and request more power, if they need it. Not all Linux systems can boot with that little power! - Dave -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/4] twl4030 threaded_irq support
On Monday 14 December 2009, Felipe Balbi wrote: move twl4030 children to threaded irq. Felipe Balbi (4): input: keyboard: twl4030: move to request_threaded_irq input: misc: twl4030: move to request_threaded_irq rtc: twl4030: move to request_threaded_irq usb: otg: twl4030: move to request_threaded_irq But nothing in drivers/mfd ... the entry to the whole stack? Did the threaded IRQ stuff ever get set up so that the top level IRQ thread didn't have to hand off to another thread each time? (That's how the current stuff works. One thread calling out to each handler.) If so, I'd like to see that be used here, rather than needlessly spend all those pages on mostly-unused stacks. drivers/input/keyboard/twl4030_keypad.c | 11 ++- drivers/input/misc/twl4030-pwrbutton.c | 12 +--- drivers/rtc/rtc-twl4030.c | 10 +- drivers/usb/otg/twl4030-usb.c | 10 +- 4 files changed, 5 insertions(+), 38 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/4] twl4030 threaded_irq support
On Monday 25 January 2010, David Brownell wrote: Did the threaded IRQ stuff ever get set up so that the top level IRQ thread didn't have to hand off to another thread each time? (That's how the current stuff works. One thread calling out to each handler.) Yes: set_irq_nested_thread(). Looks like the toplevel IRQ demux (in drivers/mfd/twl*irq*c) should use that, along with the ONESHOT flag and (eventually) bus_lock stuff. All the key parts that were missing a few years ago now seem to be present. But, not yet in use here. :) - Dave -- 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] rtc: make rtc-omap driver ioremap its register space
On Wednesday 16 September 2009, Mark A. Greer wrote:
From: Mark A. Greer mgr...@mvista.com
The rtc-omap driver currently assumes that the rtc's
registers are at a fixed address and already mapped
into virtual memory space. Remove those assumptions
so the same driver can be used for similar devices
that reside at different physical addresses (e.g.,
TI's DA8xx/OMAP-L13x SoC's).
Also allow the possibility for the timer and alarm
interrupts to use the same IRQ.
Signed-off-by: Mark A. Greer mgr...@mvista.com
CC: David Brownell davi...@pacbell.net
Acked-by: David Brownell dbrown...@users.sourceforge.net
... but not tested on OMAP1 (e.g. OSK5912, H2).
---
Sorry for the cross-posting but this is relevant to the different lists.
This patch was tested on a da830 and a da850. It was only compiled
for an omap1 platform (don't have the hardware) but it should be low
risk. Note that the platform_device data is already set up in
arch/arm/mach-omap1/devices.c so it those platforms should
Just Work(tm).
drivers/rtc/Kconfig|7 ---
drivers/rtc/rtc-omap.c | 47 ++-
2 files changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 81adbdb..f06e885 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -539,10 +539,11 @@ comment on-CPU RTC drivers
config RTC_DRV_OMAP
tristate TI OMAP1
- depends on ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730
+ depends on ARCH_OMAP15XX || ARCH_OMAP16XX || ARCH_OMAP730 ||
ARCH_DAVINCI_DA8XX
help
- Say yes here to support the real time clock on TI OMAP1 chips.
- This driver can also be built as a module called rtc-omap.
+ Say yes here to support the real time clock on TI OMAP1 and
+ DA8xx/OMAP-L13x chips. This driver can also be built as a
+ module called rtc-omap.
config RTC_DRV_S3C
tristate Samsung S3C series SoC RTC
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index bd1ce8e..aa418d5 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -87,9 +87,10 @@
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+static void __iomem *rtc_base;
-#define rtc_read(addr) omap_readb(OMAP_RTC_BASE + (addr))
-#define rtc_write(val, addr) omap_writeb(val, OMAP_RTC_BASE + (addr))
+#define rtc_read(addr) __raw_readb(rtc_base + (addr))
+#define rtc_write(val, addr) __raw_writeb(val, rtc_base + (addr))
/* we rely on the rtc framework to handle locking (rtc-ops_lock),
@@ -330,32 +331,31 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
return -ENOENT;
}
- /* NOTE: using static mapping for RTC registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res res-start != OMAP_RTC_BASE) {
- pr_debug(%s: RTC registers at %08x, expected %08x\n,
- pdev-name, (unsigned) res-start, OMAP_RTC_BASE);
+ if (!res) {
+ pr_debug(%s: RTC resource data missing\n, pdev-name);
return -ENOENT;
}
- if (res)
- mem = request_mem_region(res-start,
- res-end - res-start + 1,
- pdev-name);
- else
- mem = NULL;
+ mem = request_mem_region(res-start, resource_size(res), pdev-name);
if (!mem) {
pr_debug(%s: RTC registers at %08x are not free\n,
- pdev-name, OMAP_RTC_BASE);
+ pdev-name, res-start);
return -EBUSY;
}
+ rtc_base = ioremap(res-start, resource_size(res));
+ if (!rtc_base) {
+ pr_debug(%s: RTC registers can't be mapped\n, pdev-name);
+ goto fail;
+ }
+
rtc = rtc_device_register(pdev-name, pdev-dev,
omap_rtc_ops, THIS_MODULE);
if (IS_ERR(rtc)) {
pr_debug(%s: can't register RTC device, err %ld\n,
pdev-name, PTR_ERR(rtc));
- goto fail;
+ goto fail0;
}
platform_set_drvdata(pdev, rtc);
dev_set_drvdata(rtc-dev, mem);
@@ -380,13 +380,14 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
dev_name(rtc-dev), rtc)) {
pr_debug(%s: RTC timer interrupt IRQ%d already claimed\n,
pdev-name, omap_rtc_timer);
- goto fail0;
+ goto fail1;
}
- if (request_irq(omap_rtc_alarm, rtc_irq, IRQF_DISABLED,
- dev_name(rtc-dev), rtc)) {
+ if ((omap_rtc_timer != omap_rtc_alarm)
+ (request_irq(omap_rtc_alarm, rtc_irq, IRQF_DISABLED,
+ dev_name(rtc-dev), rtc))) {
pr_debug(%s: RTC alarm interrupt IRQ%d already claimed\n
Re: [spi-devel-general] [RESEND][PATCH 0/2] McSPI Slave and DMA , FIFO support
On Sunday 05 July 2009, Hemanth V wrote: Do you see any major changes required to support slave mode in the SPI core driver. There *is* no such thing as a SPI core driver... We are able to use the existing interface for slave mode also, but some APIs/ Structures could be made generic. Three things are obvious: - A spi_master is not a slave side driver! - Control model would need to be inverted * Chip select would be one input, not N outputs * No clock rate controls at all * latency issues ... driver can't necessarily respond quickly enough to guarantee no data loss (FIFOs help) * Can't re-use /dev/spidev* * Request queue would have a very different role - Some primitives are likely missing, for flow control (when hardware has a READY handshake) I think a few proposals for how to handle slave side have been circulated. -- 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: [spi-devel-general] [RESEND][PATCH 0/2] McSPI Slave and DMA , FIFO support
On Friday 28 August 2009, Hemanth V wrote: So would it be possible to merge the slave support also for now, and could be modified to support the new slave interface as and when available. Not really. You still haven't split the non-slave stuff into a patch, note .. -- 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] musb: fix CONFIGDATA register read issue
On Sunday 05 July 2009, Ajay Kumar Gupta wrote:
INDEX register has to be set to '0' before reading
CONFIGDATA register which is only present in TI musb
platforms.
Currently the default register access mode is set to
FLAT_MODE thus INDEX register is not getting set
properly with musb_ep_select() which is just a nop
operation in FLAT_MODE.This invalid register read is
causing module reinset failure.
Fixing the issue by moving INDEX register write part to
musb_read_configdata() function itself.
Signed-off-by: Vikram Pandita vikram.pandita at ti.com
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
This is the right fix, thanks. With these two important
operations *next to each other* it'll be harder to repeat
the goof that cause this breakage.
---
Based on a previous patch from Anand at,
http://marc.info/?l=linux-omapm=122051303604377w=2
Another version of this fix by Vikram is at,
http://linux.omap.com/pipermail/linux-omap-open-source/2007-November/012084.html
drivers/usb/musb/musb_core.c |1 -
drivers/usb/musb/musb_regs.h |1 +
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 554a414..3ec68a1 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1326,7 +1326,6 @@ static int __init musb_core_init(u16 musb_type, struct
musb *musb)
int i;
/* log core options (read using indexed model) */
- musb_ep_select(mbase, 0);
reg = musb_read_configdata(mbase);
strcpy(aInfo, (reg MUSB_CONFIGDATA_UTMIDW) ? UTMI-16 : UTMI-8);
diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h
index de3b2f1..fbfd3fd 100644
--- a/drivers/usb/musb/musb_regs.h
+++ b/drivers/usb/musb/musb_regs.h
@@ -323,6 +323,7 @@ static inline void musb_write_rxfifoadd(void __iomem
*mbase, u16 c_off)
static inline u8 musb_read_configdata(void __iomem *mbase)
{
+ musb_writeb(mbase, MUSB_INDEX, 0);
return musb_readb(mbase, 0x10 + MUSB_CONFIGDATA);
}
--
1.6.2.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
Re: [PATCH 1:2] [MTD][NAND]omap: Adding support for nand prefetch-read and post-write, in MPU mode.
On Friday 10 July 2009, vimal singh wrote:
+static void omap_read_buf8(struct mtd_info *mtd, u_char *buf, int len)
+{
+ struct nand_chip *nand = mtd-priv;
+ u_char *p = (u_char *)buf;
+
+ while (len--)
+ *p++ = __raw_readb(nand-IO_ADDR_R);
+}
Better as __raw_readsb() yes? Or maybe ioread8_rep().
... speaking of which, maybe the MTD layer can finally
default to using the accelerated block PIO calls, now
that ioreadX_rep() is supposed to work on all arches...
Last time I measured, that change alone was worth
something like a 10% speedup. Maybe more.
--
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] musb: cleanup the nop registration for OMAP3EVM
On Friday 03 July 2009, Ajay Kumar Gupta wrote:
OMAP3EVM uses ISP1504 phy which doesn't require any
programming and thus has to use NOP otg transceiver.
Cleanups being done:
- Remove unwanted code in usb-musb.c file
- Register nop in OMAP3EVM board file using
usb_nop_xceiv_register().
- Select NOP_USB_XCEIV for OMAP3EVM boards.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
... another for-2.6.31 bugfix.
---
This patch is refreshed based on David's recommendations at
[1] and [2].
[1] http://marc.info/?l=linux-omapm=123904265231360w=2
[2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg13891.html
arch/arm/mach-omap2/board-omap3evm.c |3 +++
arch/arm/mach-omap2/usb-musb.c | 21 -
drivers/usb/musb/Kconfig |1 +
3 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 595beac..ad3c78c 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -25,6 +25,7 @@
#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include linux/i2c/twl4030.h
+#include linux/usb/otg.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -307,6 +308,8 @@ static void __init omap3_evm_init(void)
ARRAY_SIZE(omap3evm_spi_board_info));
omap_serial_init();
+ /* OMAP3EVM uses ISP1504 phy and thus has to register nop transceiver */
+ usb_nop_xceiv_register();
usb_musb_init();
usb_ehci_init(EHCI_HCD_OMAP_MODE_PHY, true, true, 57, 61);
ads7846_dev_init();
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index d85296d..739e59e 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -155,20 +155,6 @@ static struct platform_device musb_device = {
.resource = musb_resources,
};
-#ifdef CONFIG_NOP_USB_XCEIV
-static u64 nop_xceiv_dmamask = DMA_BIT_MASK(32);
-
-static struct platform_device nop_xceiv_device = {
- .name = nop_usb_xceiv,
- .id = -1,
- .dev = {
- .dma_mask = nop_xceiv_dmamask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .platform_data = NULL,
- },
-};
-#endif
-
void __init usb_musb_init(void)
{
if (cpu_is_omap243x())
@@ -183,13 +169,6 @@ void __init usb_musb_init(void)
*/
musb_plat.clock = ick;
-#ifdef CONFIG_NOP_USB_XCEIV
- if (platform_device_register(nop_xceiv_device) 0) {
- printk(KERN_ERR Unable to register NOP-XCEIV device\n);
- return;
- }
-#endif
-
if (platform_device_register(musb_device) 0) {
printk(KERN_ERR Unable to register HS-USB (MUSB) device\n);
return;
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 70073b1..f822fd5 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -11,6 +11,7 @@ config USB_MUSB_HDRC
depends on (USB || USB_GADGET) HAVE_CLK
depends on !SUPERH
select NOP_USB_XCEIV if ARCH_DAVINCI
+ select NOP_USB_XCEIV if MACH_OMAP3EVM
select TWL4030_USB if MACH_OMAP_3430SDP
select USB_OTG_UTILS
tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)'
--
1.6.2.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
Re: [RESEND][PATCH 0/2] McSPI Slave and DMA ,FIFO support
On Tuesday 23 June 2009, Hemanth V wrote: This series of 2 patches adds support for McSPI slave and DMA,FIFO. It incorporates review comments from Kevin Hilman and Tony Lindgren PATCH[1/2]: Changes to arch specific files PATCH[2/2]: omap2_mcspi.c file changes Needs some changes yet: - Split out slave support as a separate patch. That's not really supported by the interface yet. - You sent the two patches with the same $SUBJECT; which indicates they are the *SAME* patch ... either make it be one patch, or change $SUBJECT (perhaps to match what you used above). The stuff in #1 should have Tony's ack. arch/arm/mach-omap2/devices.c |5 arch/arm/plat-omap/include/mach/mcspi.h | 16 + drivers/spi/omap2_mcspi.c | 353 -- -- 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: [RESEND][PATCH 2/2] McSPI Slave and DMA,FIFO support
On Tuesday 23 June 2009, Hemanth V wrote: This patch adds support for McSPI slave and FIFO. DMA and FIFO could be enabled together for better throughput. This has a dependency on patch [RESEND][PATCH 1/2] McSPI Slave and DMA,FIFO support ... in this case I'd think they would better be part of a single patch. However, anything related to SPI slave support should be separated entirely from FIFO support. Ditto anything adding more SPI_DEBUG support. Oh, and use the BIT(n) syntax not (1 n) in the new constants you define... the patch making this driver use that style finally went upstream. -- 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]OMAP4: McSPI Support for OMAP_4430
On Monday 29 June 2009, Syed Rafiuddin wrote: This patch adds McSPI support for OMAP4430 SDP platform. All the base addresses are changed between OMAP1/2/3 and OMAP4.The fields of the resource structures are filled at runtime to have McSPI support on OMAP4. Signed-off-by: Syed Rafiuddin rafiuddin.s...@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.com Acked-by: Tony Lindgren t...@atomide.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com I'd add my ack if this patch weren't mangled. :) --- arch/arm/mach-omap2/devices.c | 25 + Since *most* of this is arch/arm stuff, I think this patch should go to mainine through Tony. That's the best way to make sure it doesn't cause conflicts with other patches he sends. drivers/spi/omap2_mcspi.c | 10 ++ 2 files changed, 27 insertions(+), 8 deletions(-) None of this seemed particularly controversial. -- 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: musb otg changes break booting on omaps
On Tuesday 23 June 2009, Felipe Balbi wrote: Looks like commit 84e250ffa76dddc1bad84e04248a27f442c25986 musb: proper hookup to transceiver drivers breaks booting on omaps if no transceiver is configured. Got any patches for that? Tony, Is this on OMAP35x EVM? If so then the below patch should help. http://marc.info/?l=linux-omapm=123907915211910w=2 The problem with that patch is that the transceiver config is board-specific. So the omap2430.c change is wrong. Just register the NOP transceiver in the EVM setup code. and omap3x30-based hardware will most likely use twl4030-usb and in some cases (like evm) use the no-op trasceiver. I think I've got an SX51 patch somewhwere, I'll dig it up. - Dave -- 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] usb: disable OTG AUTOIDLE only with omap3430
On Monday 18 May 2009, Woodruff, Richard wrote: From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Niilo Minkkinen Sent: Monday, May 18, 2009 9:54 AM Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG register prevents the device from going into retention. This is a workaround (by Richard Woodruff/TI), as his comment : A new MUSB bug which is a match to data below was identified very recently (on hardware and in simulation). This bug is in 3430 and not 3630. As a priority test (and as new default) you should have engineers disable autoidle for MUSB block. This is the workaround which will show up in next errata. Signed-off-by: Niilo Minkkinen ext-niilo.1.minkki...@nokia.com Signed-off-by: Richard Woodruff r-woodru...@ti.com Yes this is needed for 34xx. Side note is this cost around 1mW of power during active mode of MUSB. When device is not active cost is not significant. System impact depends on duty cycle of MUSB in usecase. There's also some initialization goofiness in that code ... it's supposed to set initialize the transceiver with several distinct writes, of which setting AUTOIDLE (to auto-gate the L3 clock) is ISTR the last step. The goofiness shows up with OTG initialization, which is documented as needing a slightly different sequence ... my notes have it as being an extra write to set ENABLEFORCE. - Dave -- 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: MUSB ISSUE on OMAP3530 with USB-2-Ethernet converter
On Thursday 04 June 2009, Remith Ravi wrote: Hi, Anybody had a chance to attend this issue? Any hint to solve the problem? The ASIX AX88772A USB2.0 Fast Ethernet Network Adapter Linux driver available in Asix website supports only upto Linux 2.6.26. I integrated that driver into the git kernel and tested it on the OMAP35xx dev board (EHCI port). The driver detects the presence of USB-2-Ethernet converter and it is possible to assign ip address to the new Ethernet interface. But the ping test fails (ping statistics --- 40 packets transmitted, 0 packets received, 100% packet loss) and therefore I cant continue testing it on the latest git kernel. That worked OK for me the last time I hooked up one of those adapters to a 3430 (essentially the same as a 3530). Any help towards solving this issue will be highly appreciated. Regards, Remith On Fri, May 29, 2009 at 7:46 PM, umesh krishnan umeshde...@gmail.com wrote: Hi, Any help on the below-said musb-issue? -- Forwarded message -- From: Felipe Balbi felipe.ba...@nokia.com Date: Fri, May 29, 2009 at 3:10 PM Subject: Re: MUSB ISSUE on OMAP3530 with USB-2-Ethernet converter To: ext umesh krishnan umeshde...@gmail.com Cc: linux-omap@vger.kernel.org linux-omap@vger.kernel.org, linux-...@vger.kernel.org Hi, musb should be discussed in linux-usb, but keep linux-omap as Cc. unfortunately I don't have time to help community now due to internal tasks I gotta finish, but I'm sure there's more people in linux-usb that could help you with it. On Fri, May 29, 2009 at 11:24:37AM +0200, ext umesh krishnan wrote: Greetings, I am facing issues while using Asix's AX88772A USB-2-Ethernet converter on my OMAP3530 based product. It uses TI's 2.6.22.18 PSP release-1.0.2 as its OS. The driver for AX8877A was taken from Asix's website. This is one problem, community can only support you with the current version of the open source kernel. Meaning you should try with linux-omap-2.6.git or linux-2.6.git. I am facing kernel crashes when I use the converter on USB OTG port. I am able to get the device detected and also able to assign the ip to the device. But when i repeat the process after plugging-out and plugging-in again and then assigning the ip address , after repeating the process about 9 times, the kernel crashes(when i assign the ip). I tried testing by configuring the musb driver into both OTG and Host only mode. Kernel crashed in both cases. Crash log is attached. (keeping the crash below for reference) - eth1: unregister 'asix' usb-musb_hdrc.0-1, ASIX AX88772A USB 2.0 Ethernet musb_stage0_irq 699: CONNECT (a_host) devctl 5d usb 1-1: new high speed USB device using musb_hdrc and address 3 usb 1-1: Product: AX88x72A usb 1-1: Manufacturer: ASIX Elec. Corp. usb 1-1: SerialNumber: 01 usb 1-1: configuration #1 chosen from 1 choice eth1: register 'asix' at usb-musb_hdrc.0-1, ASIX AX88772A USB 2.0 Ethernet, 00:0e:c6:00:0f:97 [r...@omap3 /]# ping 192.168.13.1 [r...@omap3 /]# ifconfig eth1 192.168.13.254 Unable to handle kernel NULL pointer dereference at virtual address 001c pgd = c719 [001c] *pgd=8706b031, *pte=, *ppte= Internal error: Oops: 17 [#1] Modules linked in: CPU: 0 Not tainted (2.6.22.18-omap3 #1) PC is at musb_start_urb+0x74/0x9b0 LR is at __init_begin+0x3fff8000/0x30 pc : [c0219ac4] lr : [] psr: 6093 sp : c706fc18 ip : c059d1ec fp : c706fcb4 r10: 0020 r9 : r8 : c059d000 r7 : c713e120 r6 : c059d1ec r5 : c059d0d8 r4 : c7f9a9e0 r3 : r2 : r1 : c7f9a9e0 r0 : c059d1ec Flags: nZCv IRQs off FIQs on Mode SVC_32 Segment user Control: 00c5387f Table: 87190018 DAC: 0015 Process ifconfig (pid: 407, stack limit = 0xc706e2d8) Stack: (0xc706fc18 to 0xc707) fc00: 0020 0020 fc20: c706fc44 c706fc30 c02180b4 c02174ec c05c0a00 c706fc64 c03e4464 fc40: c7f9a9e0 c059d0d8 c713e128 c8808000 c059d1ec c706fc68 fc60: c0087f24 c00351dc 005c c03e4464 c706fc9c c706fc80 c002b04c c00688a4 fc80: d820 c059d000 c7f9a9e0 c059d0d8 c059d1ec c713e120 c059d000 fca0: 0020 c706fcf4 c706fcb8 c021a874 c0219a5c c059d000 c713e120 fcc0: a013 0020 0020 871cfa20 c05a1034 c059d000 c713e120 c713e128 fce0: 0020 0020 c706fdbc c706fcf8 c01f8e34 c021a520 c706fd1c c706fd08 fd00: c02180b4 c02174ec c05c0a00 c706fd3c c03e4464 005c fd20: c06753a0 0098 0020 c706fd54 c706fd40 c0087f24 c00351dc fd40: 005c c03e4464 c706fd74 c706fd58 c002b04c c00688a4
Re: [PATCH (V2)] TVP514x: Migration to sub-device framework
On Sunday 14 June 2009, Hans Verkuil wrote:
+#define dump_reg(sd, reg, val) \
do {\
- val = tvp514x_read_reg(client, reg);\
- v4l_info(client, Reg(0x%.2X): 0x%.2X\n, reg, val); \
+ val = tvp514x_read_reg(sd, reg);\
+ v4l2_info(sd, Reg(0x%.2X): 0x%.2X\n, reg, val); \
} while (0)
Why not turn this into a static inline function? Much better than a macro.
IMO, too big for either. Make it a real function.
--
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: Overo broken with current top of tree
On Thursday 30 April 2009, Grazvydas Ignotas wrote: I get the same on pandora, although it continues booting fine after that. Maybe regulator folks will comment about regulator errors. Does mainline 3e59091828ed5406c879b899b4257fcef7271e2c resolve it for you? -- 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: Overo broken with current top of tree
On Thursday 30 April 2009, Steve Sakoman wrote: The platform data messages still appear, Those platform_data patches are getting reverted. Ignore the messages for now. -- 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: Overo broken with current top of tree
On Thursday 30 April 2009, Steve Sakoman wrote: I've also noticed that I now get occasional mmcblk0: retrying using single block read messages on the serial console. I haven't seen these before. Anyone see anything similar on their setup? Yes. -- 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] OMAP OneNAND: add missing __devexit_p wrappers
On Wednesday 29 April 2009, Adrian Hunter wrote: + .shutdown = __devexit_p(omap2_onenand_shutdown), That looks wrong. Shutdown functions shouldn't get discarded like exit functions. I'd think the fix for that would be taking away any __devexit annotation on the shutdown function. -- 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] regulator core: fix double-free in regulator_register() error path
On Tuesday 28 April 2009, Mark Brown wrote: For the record, that incomplete constraints message is bogus. On that board, VAUX3 has a complete set of constraints: it may only emit 2.8V. It's not VAUX3 that it's saying has incomplete constraints, it's the board as a whole - if the constraints for the board were fully specified No; driver support != constraint. Only one of the issues is packaged as a constraint. (and the core had been told about it) then it would power off VAUX3 at that point. Mark and/or Liam ... you might want to fix that diagnostic, to avoid leading more developers astray! Probably shove a board has in there or something I guess. How about: VAUX3 board support is incomplete. That's accurate. A comment there might suggest constraints and driver support as two common issues ... I'd not be surprised to see a few more idioms pop up. - Dave -- 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: Card detect IRQ errors
On Monday 27 April 2009, Grazvydas Ignotas wrote: With current l-o head when I insert or remove SD card I'm getting this: [ 20.733489] [ cut here ] [ 20.738159] WARNING: at kernel/irq/handle.c:366 handle_IRQ_event+0x4c/0x14c() [ 20.745330] BUG: IRQ handler called from non-hardirq context!Modules linked in: ... [ 20.822753] ---[ end trace 2ca2d8ba630dd6b5 ]--- [ 20.869415] mmc0: card 8001 removed Has anyone else seen this? Regresssion caused by 044d408409cc4e1bc75c886e27ca85c270db104c. Notice the message is internally broken, too -- no newline. Try reverting that, things will still behave just fine. -- 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] OMAP: pandora: setup regulator framework for MMC
On Sunday 26 April 2009, Grazvydas Ignotas wrote:
Setup regulators for MMC1 and MMC2 to get those SD slots
working again.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
CC: David Brownell davi...@pacbell.net
---
arch/arm/mach-omap2/board-omap3pandora.c | 45
++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index c67f62f..c525b16 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -27,6 +27,7 @@
#include linux/spi/spi.h
#include linux/spi/ads7846.h
+#include linux/regulator/machine.h
#include linux/i2c/twl4030.h
#include linux/mtd/mtd.h
@@ -171,6 +172,14 @@ static struct omap_uart_config omap3pandora_uart_config
__initdata = {
.enabled_uarts = (1 2), /* UART3 */
};
+static struct regulator_consumer_supply pandora_vmmc1_supply = {
+ .supply = vmmc,
+};
+
+static struct regulator_consumer_supply pandora_vmmc2_supply = {
+ .supply = vmmc,
+};
+
static int omap3pandora_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -179,6 +188,10 @@ static int omap3pandora_twl_gpio_setup(struct device
*dev,
omap3pandora_mmc[1].gpio_cd = gpio + 1;
twl4030_mmc_init(omap3pandora_mmc);
+ /* link regulators to MMC adapters */
+ pandora_vmmc1_supply.dev = omap3pandora_mmc[0].dev;
+ pandora_vmmc2_supply.dev = omap3pandora_mmc[1].dev;
+
return 0;
}
@@ -189,6 +202,36 @@ static struct twl4030_gpio_platform_data
omap3pandora_gpio_data = {
.setup = omap3pandora_twl_gpio_setup,
};
+/* VMMC1 for MMC1 pins CMD, CLK, DAT0..DAT3 (20 mA, plus card == max 220 mA)
*/
+static struct regulator_init_data pandora_vmmc1 = {
+ .constraints = {
+ .min_uV = 185,
+ .max_uV = 315,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = pandora_vmmc1_supply,
+};
+
+/* VMMC2 for MMC2 pins CMD, CLK, DAT0..DAT3 (max 100 mA) */
+static struct regulator_init_data pandora_vmmc2 = {
+ .constraints = {
+ .min_uV = 185,
+ .max_uV = 315,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = pandora_vmmc2_supply,
+};
+
static struct twl4030_usb_data omap3pandora_usb_data = {
.usb_mode = T2_USB_MODE_ULPI,
};
@@ -198,6 +241,8 @@ static struct twl4030_platform_data omap3pandora_twldata
= {
.irq_end= TWL4030_IRQ_END,
.gpio = omap3pandora_gpio_data,
.usb= omap3pandora_usb_data,
+ .vmmc1 = pandora_vmmc1,
+ .vmmc2 = pandora_vmmc2,
};
static struct i2c_board_info __initdata omap3pandora_i2c_boardinfo[] = {
--
1.5.6.3
--
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] regulator core: fix double-free in regulator_register() error path
On Saturday 25 April 2009, Paul Walmsley wrote: device_unregister() calls regulator_dev_release() which frees rdev. The subsequent kfree corrupts memory and causes some OMAP3 systems to oops on boot in regulator_get(). For the 3430SDP users out there, this patch also fixes the boot hang after regulator_init_complete: incomplete constraints, leaving VAUX3 on on that device. For the record, that incomplete constraints message is bogus. On that board, VAUX3 has a complete set of constraints: it may only emit 2.8V. What it lacks is something entirely different: driver support for the LCD which uses the regulator framework, instead of just bypassing it and talking directly to the PMIC. By the time it gets there, the LCD has probably been turned on. Mark and/or Liam ... you might want to fix that diagnostic, to avoid leading more developers astray! -- 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] regulator core: fix double-free in regulator_register() error path
On Saturday 25 April 2009, Paul Walmsley wrote: During regulator registration, any error after device_register() will cause a double-free on the struct regulator_dev 'rdev'. The bug is in drivers/regulator/core.c:regulator_register(): ... scrub: device_unregister(rdev-dev); clean: kfree(rdev); --- rdev = ERR_PTR(ret); goto out; ... device_unregister() calls regulator_dev_release() which frees rdev. The subsequent kfree corrupts memory and causes some OMAP3 systems to oops on boot in regulator_get(). Applies against 2.6.30-rc3. Signed-off-by: Paul Walmsley p...@pwsan.com This looks like it would address the oopsing I mentioned a while back, since affects cleanup paths after errors during driver probe(). --- drivers/regulator/core.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 01f7702..fabd2e0 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -2080,6 +2080,10 @@ out: scrub: device_unregister(rdev-dev); + /* device core frees rdev */ + rdev = ERR_PTR(ret); + goto out; + clean: kfree(rdev); rdev = ERR_PTR(ret); -- 1.6.3.rc1.51.gea0b7 -- 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: Problems while designing TPS65023 regulator driver
On Thursday 23 April 2009, Trilok Soni wrote: Thanks but I was requesting tps 6 5 0 2 3 not tps 6 2 3 5 x :). Sorry ... maybe they'll help some other time. :) I was wondering what happened to the tps6235x drivers, which seemed to have gotten lost. I don't recall having seen tps65023 code. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 2.6.29-rc3-git] input: twl4030_keypad driver
On Thursday 23 April 2009, Dmitry Torokhov wrote:
Dave,
It waqs sitting in my local queue, I had some concerns over the keymap
change as it was implemented in the version you sent me. The problem is
that you mangle key codes in your keymap table (encoding row/col data in
Well, not really *me* I didn't write any of this. I just
cleaned it up and sent it along to help get this stuff out
of the OMAP tree, into mainline where it belongs.
them) but input core is not aware of that and when you try using
EVIOCSETKEYCODE it will do wierd things. I was wondering what you would
think about the following patch that should rectify this issue.
It invalidates all the existing keypad tables, which have been
waiting for this driver to merge before they go upstream ... it'd
be simpler just to prevent EVIOCSETKEYCODE calls. Or provide
update methods that understand the structure of those entries;
conceptually they're a struct { scancode; keycode; } though
it's not coded that way
Needing to take 512 bytes per keytable -- vs the keypad-specific
sizes, typically much less even if using a qwerty -- is also a
minor issue. Keypads with 256 keys are *really* unusual! Most
current ones are smaller ... the biggest I've seen is 44.
Also, I don't think we need the special handling for persistant keys.
Just let these keys generate KEY_RESERVED and input core will not
propagate their events.
I was never sure what to make of that, it seemed like a hack.
Only the Labrador boards (since renamed Zoom1) seem to
need that mechanism.
So I'm not sure whether that would be appropriate. If it is,
then the keytable construction macros could just change. But
is the input core aware that it shouldn't remap such things?
- Dave
p.s. a few comments are below.
Thanks!
--
Dmitry
Input: twl4030_kepad fixups
Signed-off-by: Dmitry Torokhov d...@mail.ru
---
drivers/input/keyboard/twl4030_keypad.c | 62
++-
include/linux/i2c/twl4030.h | 18 +++--
2 files changed, 32 insertions(+), 48 deletions(-)
diff --git a/drivers/input/keyboard/twl4030_keypad.c
b/drivers/input/keyboard/twl4030_keypad.c
index 987f13c..b761cac 100644
--- a/drivers/input/keyboard/twl4030_keypad.c
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -48,23 +48,18 @@
* See the TPS65950 documentation; that's the general availability
* version of the TWL5030 second generation part.
*/
-#define MAX_ROWS 8 /* TWL4030 hard limit */
struct twl4030_keypad {
- unsigned*keymap;
- unsigned intkeymapsize;
- u16 kp_state[MAX_ROWS];
- unsignedn_rows;
- unsignedn_cols;
+ unsigned short keymap[TWL4030_KEYMAP_SIZE];
The keypad size is board-specific; not all possible switch
settings are used.
+ u16 kp_state[TWL4030_MAX_ROWS];
TWL4030_MAX_ROWS makes sense, although the same keypad macros
are used in some other OMAP boards that don't use TWL4030 family
chips, so it's not really TWL-specific. (OMAP1 boards often use
the omap-keypad driver.)
+ u8 n_rows;
+ u8 n_cols;
Didn't really need to change those. This is one of the cases
where the code to read a byte then zero-extend it uses more
space than using a 32-bit unsigned value instead of 8-bit. :)
unsignedirq;
struct device *dbg_dev;
struct input_dev *input;
};
-#define ROWCOL_MASK KEY(0xf, 0xf, 0)
-#define KEYNUM_MASK ~PERSISTENT_KEY(0xf, 0xf)
This being a side-effect of changing the key table encoding...
-
/*--*/
/* arbitrary prescaler value 0..7 */
@@ -156,18 +151,6 @@ static int twl4030_kpwrite_u8(struct twl4030_keypad *kp,
u8 data, u32 reg)
return ret;
}
-static int twl4030_find_key(struct twl4030_keypad *kp, int col, int row)
-{
- int i, rc;
-
- rc = KEY(col, row, 0);
- for (i = 0; i kp-keymapsize; i++)
- if ((kp-keymap[i] ROWCOL_MASK) == rc)
- return kp-keymap[i] (KEYNUM_MASK | KEY_PERSISTENT);
-
- return -EINVAL;
-}
-
static inline u16 twl4030_col_xlate(struct twl4030_keypad *kp, u8 col)
{
/* If all bits in a row are active for all coloumns then
@@ -183,7 +166,7 @@ static inline u16 twl4030_col_xlate(struct twl4030_keypad
*kp, u8 col)
static int twl4030_read_kp_matrix_state(struct twl4030_keypad *kp, u16
*state)
{
- u8 new_state[MAX_ROWS];
+ u8 new_state[TWL4030_MAX_ROWS];
int row;
int ret = twl4030_kpread(kp,
new_state, KEYP_FULL_CODE_7_0, kp-n_rows);
@@ -213,7 +196,8 @@ static int twl4030_is_in_ghost_state(struct
twl4030_keypad *kp, u16 *key_state)
static void twl4030_kp_scan(struct twl4030_keypad *kp, int release_all)
{
- u16 new_state[MAX_ROWS];
+ struct input_dev *input =
Re: [PATCH] twl4030: Add some error checking to twl4030 init
On Monday 20 April 2009, Amit Kucheria wrote:
Whitespace-fixed version and passed through checkpatch.pl
Check for return values of i2c read/write operations and size of scripts being
uploaded to TWL4030
Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com
---
drivers/mfd/twl4030-core.c |2 +-
drivers/mfd/twl4030-power.c | 49 ++
The changes look OK ... but what this needs is to be
split into two patches. The -core one should go to
mainline; it's trivial, comment-only, unrelated to the
$SUBJECT patch. The -power one seems OK for merge to
the OMAP tree.
(Of course, the -power driver should probably go mainline
at some point. Once it stops breaking warm-reset!)
2 files changed, 36 insertions(+), 15 deletions(-)
diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
index 769b34b..067b02e 100644
--- a/drivers/mfd/twl4030-core.c
+++ b/drivers/mfd/twl4030-core.c
@@ -358,7 +358,7 @@ EXPORT_SYMBOL(twl4030_i2c_read);
int twl4030_i2c_write_u8(u8 mod_no, u8 value, u8 reg)
{
- /* 2 bytes offset 1 contains the data offset 0 is used by i2c_write */
+ /* 2 bytes: offset 1 contains the data, offset 0 is used by i2c_write */
u8 temp_buffer[2] = { 0 };
/* offset 1 contains the data */
temp_buffer[1] = value;
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 9dc493b..b4b636d 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -257,36 +257,38 @@ static int __init config_warmreset_sequence(u8 address)
return err;
}
-void twl4030_configure_resource(struct twl4030_resconfig *rconfig)
+static int __init twl4030_configure_resource(struct twl4030_resconfig
*rconfig)
{
int rconfig_addr;
+ int err;
u8 type;
if (rconfig-resource NUM_OF_RESOURCES) {
printk(KERN_ERR
TWL4030 Resource %d does not exist\n,
rconfig-resource);
- return;
+ return -EINVAL;
}
rconfig_addr = res_config_addrs[rconfig-resource];
/* Set resource group */
-
if (rconfig-devgroup = 0)
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
rconfig-devgroup 5,
rconfig_addr + DEVGROUP_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR TWL4030 failed to program devgroup);
+ return err;
+ }
/* Set resource types */
-
- if (twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER,
- type,
- rconfig_addr + TYPE_OFFSET) 0) {
- printk(KERN_ERR
- TWL4030 Resource %d type could not read\n,
+ err = twl4030_i2c_read_u8(TWL4030_MODULE_PM_RECEIVER, type,
+ rconfig_addr + TYPE_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR TWL4030 Resource %d type could not be read\n,
rconfig-resource);
- return;
+ return err;
}
if (rconfig-type = 0) {
@@ -299,8 +301,14 @@ void twl4030_configure_resource(struct twl4030_resconfig
*rconfig)
type |= rconfig-type2 3;
}
- twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
+ err = twl4030_i2c_write_u8(TWL4030_MODULE_PM_RECEIVER,
type, rconfig_addr + TYPE_OFFSET);
+ if (err 0) {
+ printk(KERN_ERR TWL4030 failed to program resource type);
+ return err;
+ }
+
+ return 0;
}
@@ -309,6 +317,12 @@ static int __init load_triton_script(struct
twl4030_script *tscript)
u8 address = triton_next_free_address;
int err;
+ /* Make sure the script isn't going beyond last valid address */
+ if ((address + tscript-size) (END_OF_SCRIPT-1)) {
+ printk(KERN_ERR TWL4030 script too big error\n);
+ return -EINVAL;
+ }
+
err = twl4030_write_script(address, tscript-script, tscript-size);
if (err)
return err;
@@ -346,15 +360,22 @@ void __init twl4030_power_init(struct
twl4030_power_data *triton2_scripts)
for (i = 0; i triton2_scripts-size; i++) {
err = load_triton_script(triton2_scripts-scripts[i]);
- if (err)
+ if (err 0) {
+ printk(KERN_ERR TWL4030 failed to load scripts);
break;
+ }
}
resconfig = triton2_scripts-resource_config;
if (resconfig) {
while (resconfig-resource) {
- twl4030_configure_resource(resconfig);
+ err = twl4030_configure_resource(resconfig);
resconfig++;
+ if
Re: usb-to-eth dongle on usb ehci host port
On Thursday 23 April 2009, twebb wrote: It does look like it recognizes it (REALTEK USB 10/100 LAN), but how to tell if it recognizes it specifically as a eth adaptor? drivers/net/usb/Kconfig has a USB_RTL8150 entry you might try. usb 1-2.2: New USB device found, idVendor=0bda, idProduct=8150 usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2.2: Product: USB 10/100 LAN usb 1-2.2: Manufacturer: REALTEK -- 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: Problems while designing TPS65023 regulator driver
On Thursday 23 April 2009, Trilok Soni wrote:
Any updates on tps65023 regulator driver? Could you please submit the
WIP patches to the list?
FWIW, here's the last version I saw ... it includes a
build hack for the regulator_register() call. I haven't
build-tested it since that API change went to mainline.
From: Manikandan Pillai mani.pil...@ti.com
Subject: regulator: add support for TPS6235x
The patch has been fixed for comments given by David Brownell
and Mark Brown for adding TPS6235x support on OMAP3 EVM.
Comments fixed include
moving Makefile changes to this patch
dev_err used
removed the extra configuration option from Kconfig
[ dbrown...@users.sourceforge.net: build hack ]
Signed-off-by: Manikandan Pillai mani.pil...@ti.com
---
drivers/regulator/Kconfig |8
drivers/regulator/Makefile |1
drivers/regulator/tps6235x-regulator.c | 350 +++
3 files changed, 359 insertions(+)
create mode 100644 drivers/regulator/tps6235x-regulator.c
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -98,4 +98,12 @@ config REGULATOR_PCF50633
Say Y here to support the voltage regulators and convertors
on PCF50633
+config REGULATOR_TPS6235X
+ tristate TI TPS6235x Power regulators
+ depends on I2C
+ help
+ This driver supports TPS6235x voltage regulator chips, for values
+ of x from 0 to 6. These are buck converters which support TI's
+ hardware based SmartReflex dynamic voltage scaling.
+
endif
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -13,5 +13,6 @@ obj-$(CONFIG_REGULATOR_WM8350) += wm8350
obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
obj-$(CONFIG_REGULATOR_DA903X) += da903x.o
obj-$(CONFIG_REGULATOR_PCF50633) += pcf50633-regulator.o
+obj-$(CONFIG_REGULATOR_TPS6235X)+= tps6235x-regulator.o
ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
--- /dev/null
+++ b/drivers/regulator/tps6235x-regulator.c
@@ -0,0 +1,350 @@
+/*
+ * tps6235x-regulator.c -- support regulators in tps6235x family chips
+ *
+ * Author : Manikandan Pillaimani.pil...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/regulator/driver.h
+#include linux/regulator/machine.h
+#include linux/i2c.h
+#include linux/delay.h
+
+/*
+ * These chips are often used in OMAP-based systems.
+ *
+ * This driver implements software-based resource control for various
+ * voltage regulators. This is usually augmented with state machine
+ * based control.
+ *
+ * For now, all regulator operations apply to VSEL1 (the ceiling),
+ * instead of VSEL0 (the floor) which is used for low power modes.
+ * Also, this *assumes* only software mode control is used...
+*/
+
+#defineTPS6235X_REG_VSEL0 0
+#defineTPS6235X_REG_VSEL1 1
+#defineTPS6235X_REG_CTRL1 2
+#defineTPS6235X_REG_CTRL2 3
+
+/* VSEL bitfields (EN_DCDC is shared) */
+#defineTPS6235X_EN_DCDCBIT(7)
+#defineTPS6235X_LIGHTPFM BIT(6)
+#defineTPS6235X_VSM_MSK(0x3F)
+
+/* CTRL1 bitfields */
+#define TPS6235X_EN_SYNC BIT(5)
+#define TPS6235X_HW_nSWBIT(4)
+
+/* CTRL2 bitfields */
+#define TPS6235X_PWR_OK_MSKBIT(5)
+#define TPS6235X_OUT_DIS_MSK BIT(6)
+#define TPS6235X_GO_MSKBIT(7)
+
+struct tps_info {
+ unsignedmin_uV;
+ unsignedmax_uV;
+ unsignedmult_uV;
+ boolfixed;
+};
+
+struct tps {
+ struct regulator_desc desc;
+ struct i2c_client *client;
+ struct regulator_dev*rdev;
+ const struct tps_info *info;
+};
+
+static inline int tps_6235x_read_reg(struct tps *tps, u8 reg, u8 *val)
+{
+ int status;
+
+ status = i2c_smbus_read_byte_data(tps-client, reg);
+ *val = status;
+ if (status 0)
+ return status;
+ return 0;
+}
+
+static inline int tps_6235x_write_reg(struct tps *tps, u8 reg, u8 val)
+{
+ return i2c_smbus_write_byte_data(tps-client, reg, val);
+}
+
+static int tps6235x_dcdc_is_enabled(struct regulator_dev *dev)
+{
+ unsigned char vsel1;
+ struct tps *tps = rdev_get_drvdata(dev);
+
+ tps_6235x_read_reg(tps, TPS6235X_REG_VSEL1, vsel1);
+
+ return !(vsel1 TPS6235X_EN_DCDC);
+}
+
+static int tps6235x_dcdc_enable(struct regulator_dev *dev)
+{
+ unsigned char vsel1;
+ int ret;
+ struct tps *tps = rdev_get_drvdata(dev);
+
+ ret = tps_6235x_read_reg(tps, TPS6235X_REG_VSEL1, vsel1
Re: [patch 2.6.29-rc3-git] input: twl4030_keypad driver
On Friday 06 February 2009, David Brownell wrote:
From: David Brownell dbrown...@users.sourceforge.net
Add a driver for the keypad controller on TWL4030 family chips.
PING? I was told this was in the input queue, but it's not in
http://git.kernel.org/?p=linux/kernel/git/dtor/input.git
Here's a current version of the patch.
- Dave
CUT HERE
From: David Brownell dbrown...@users.sourceforge.net
Add a driver for the keypad controller on TWL4030 family chips.
These support up to an 8x8 key matrix. The TWL4030 multifunction
chips are mostly used on OMAP3 (or OMAP 2430) based boards.
Reviewed-by: Trilok Soni soni.tri...@gmail.com
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
Sometime later we may get a more generic/reusable solution
than the KEY() macros used here, which basically came from
the OMAP keypad support.
drivers/input/keyboard/Kconfig | 11
drivers/input/keyboard/Makefile |1
drivers/input/keyboard/twl4030_keypad.c | 493 ++
include/linux/i2c/twl4030.h | 17 -
4 files changed, 517 insertions(+), 5 deletions(-)
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -259,6 +259,17 @@ config KEYBOARD_OMAP
To compile this driver as a module, choose M here: the
module will be called omap-keypad.
+config KEYBOARD_TWL4030
+ tristate TI TWL4030/TWL5030/TPS659x0 keypad support
+ depends on TWL4030_CORE
+ help
+ Say Y here if your board use the keypad controller on
+ TWL4030 family chips. It's safe to say enable this
+ even on boards that don't use the keypad controller.
+
+ To compile this driver as a module, choose M here: the
+ module will be called twl4030_keypad.
+
config KEYBOARD_PXA27x
tristate PXA27x/PXA3xx keypad support
depends on PXA27x || PXA3xx
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_KEYBOARD_TOSA) += tosakbd.
obj-$(CONFIG_KEYBOARD_HIL) += hil_kbd.o
obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
obj-$(CONFIG_KEYBOARD_OMAP)+= omap-keypad.o
+obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
obj-$(CONFIG_KEYBOARD_PXA27x) += pxa27x_keypad.o
obj-$(CONFIG_KEYBOARD_PXA930_ROTARY) += pxa930_rotary.o
obj-$(CONFIG_KEYBOARD_AAED2000)+= aaed2000_kbd.o
--- /dev/null
+++ b/drivers/input/keyboard/twl4030_keypad.c
@@ -0,0 +1,493 @@
+/*
+ * twl4030_keypad.c - driver for 8x8 keypad controller in twl4030 chips
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Copyright (C) 2008 Nokia Corporation
+ *
+ * Code re-written for 2430SDP by:
+ * Syed Mohammed Khasim x0kha...@ti.com
+ *
+ * Initial Code:
+ * Manjunatha G K manj...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/input.h
+#include linux/platform_device.h
+#include linux/i2c/twl4030.h
+
+
+/*
+ * The TWL4030 family chips include a keypad controller that supports
+ * up to an 8x8 switch matrix. The controller can issue system wakeup
+ * events, since it uses only the always-on 32KiHz oscillator, and has
+ * an internal state machine that decodes pressed keys, including
+ * multi-key combinations.
+ *
+ * This driver lets boards define what keycodes they wish to report for
+ * which scancodes, as part of the struct twl4030_keypad_data used in
+ * the probe() routine.
+ *
+ * See the TPS65950 documentation; that's the general availability
+ * version of the TWL5030 second generation part.
+ */
+#define MAX_ROWS 8 /* TWL4030 hard limit */
+
+struct twl4030_keypad {
+ unsigned*keymap;
+ unsigned intkeymapsize;
+ u16 kp_state[MAX_ROWS];
+ unsignedn_rows;
+ unsignedn_cols;
+ unsignedirq;
+
+ struct device *dbg_dev;
+ struct input_dev *input;
+};
+
+#define ROWCOL_MASKKEY(0xf, 0xf, 0)
+#define KEYNUM_MASK~PERSISTENT_KEY(0xf, 0xf)
+
+/*--*/
+
+/* arbitrary prescaler value 0..7 */
+#define PTV_PRESCALER
[patch omap-git] ehci-omap buildfix
device.bus_id doesn't exist any more Signed-off-by: David Brownell dbrown...@users.sourceforge.net --- drivers/usb/host/ehci-omap.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -432,7 +432,8 @@ static int ehci_hcd_omap_drv_probe(struc retval = -ENOMEM; } - hcd = usb_create_hcd(ehci_omap_hc_driver, dev-dev, dev-dev.bus_id); + hcd = usb_create_hcd(ehci_omap_hc_driver, dev-dev, + dev_name(dev-dev)); if (!hcd) return -ENOMEM; -- 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: Benchmarking: POP flash vs. MMC?
On Monday 06 April 2009, Russ Dill wrote: Also, it appears from looking an the openzoom git, there are some patches to add DMA support in, but I'm not sure what effect they have. We had asked for some benchmark data -- anything! -- to get a handle on that, and the prefetch/etc engine; nothing forthcoming, so far. -- 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: Preempt-RT on OMAP3?
On Sunday 05 April 2009, Hugo Vincent wrote: I'm trying to get the realtime patch set to work on OMAP3 (Gumstix Overo). Linux-omap 2.6.29 with the RT patches -rt1 or -rt2 work mostly as is (MUSB and the usb-gadget layer have quite a few problems, and Like what? Way back in 2.6.10 MUSB behaved relatively sanely. But that's a while back. ;) the realtime self-test stuff picks up a few problems to do with spinlock usage etc, but most things seem to mostly work correctly for my needs). Running cyclictest with various types of loads gives an average latency of ~30-50 usec and worst case up around 300 usec. -- 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: Benchmarking: POP flash vs. MMC?
On Monday 06 April 2009, Paul Walmsley wrote: Puzzle: get a dma_copypage() to work faster than copy_page(). Or a dma_clear_page() faster than clear_page(). Not easy... Doing it via the DMA engine may save power, since MPU can sleep. But the CPU overhead of calling the DMA engine can exceed that of the memcpy()/memset() ... ;) Another concern is cache impact. In some cases, having the dirty data in dcache is a big win. With DMA, the cache will have been purged. It'd be nice to see DMA versions of this stuff winning; all I'm saying is that such wins are hard to achieve. - Dave -- 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: Benchmarking: POP flash vs. MMC?
On Monday 06 April 2009, Paul Walmsley wrote:
Hi David
On Mon, 6 Apr 2009, David Brownell wrote:
On Monday 06 April 2009, Russ Dill wrote:
Also, it appears from looking an the openzoom git, there are some
patches to add DMA support in, but I'm not sure what effect they have.
We had asked for some benchmark data -- anything! -- to get a
handle on that, and the prefetch/etc engine; nothing forthcoming,
so far.
We'd also have to make sure that the comparison is between the linux-omap
kernel and the OMAPZoo kernel, rather than o-z PIO vs. o-z DMA. The
OMAPZoom kernel doesn't post any device register writes. That should
cause any driver using PIO to drag, compared to the l-o kernel.
I'd think the first thing to check is two linux-omap PIO flavors:
with vs without the prefetch/postwrite engine. Benchmarking DMA
would be a separate issue. Ditto comparing kernels with/without
write posting.
I've benchmarked small DMA transfers and it's rather hard to get
them faster than io{read,write}32_rep(). Overhead of DMA mapping
and just DMA setup/teardown/complete is annoyingly high. While
bus overheads aren't large.
Puzzle: get a dma_copypage() to work faster than copy_page().
Or a dma_clear_page() faster than clear_page(). Not easy...
- Dave
--
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] musb: refresh nop transceiver support for musb
On Monday 06 April 2009, Gupta, Ajay Kumar wrote: David, what's your comment on this? It was wrong to try registering the transceiver in the mach-map2/usb2.c file in any case. That's a board-specific issue for OMAP3; and TUSB60x0 chips have an integrated one. See http://marc.info/?l=linux-usbm=123852898920405w=2 So for example the RX51 board support (nyet in mainline) needs to register the NOP transceiver; and I think one more board, maybe the OMAP3 EVM, does too. - Dave p.s. This issue is *only* for the OMAP tree. -- 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] musb: refresh nop transceiver support for musb
On Monday 06 April 2009, Ajay Kumar Gupta wrote:
As the parent patch for NOP transceiver got modified which now does the
NOP device registration also so removing registration part from
usb-musb.c file.
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
---
Against latest linux-omap tree as on 6th April.
NAK -- see earlier comment
arch/arm/mach-omap2/usb-musb.c | 20 ++--
1 files changed, 2 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 927c2d9..e932b8c 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -25,6 +25,7 @@
#include linux/io.h
#include linux/usb/musb.h
+#include linux/usb/otg.h
#include mach/hardware.h
#include mach/irqs.h
@@ -145,20 +146,6 @@ static struct platform_device musb_device = {
.resource = musb_resources,
};
-#ifdef CONFIG_NOP_USB_XCEIV
-static u64 nop_xceiv_dmamask = DMA_32BIT_MASK;
-
-static struct platform_device nop_xceiv_device = {
- .name = nop_usb_xceiv,
- .id = -1,
- .dev = {
- .dma_mask = nop_xceiv_dmamask,
- .coherent_dma_mask = DMA_32BIT_MASK,
- .platform_data = NULL,
- },
-};
-#endif
-
void __init usb_musb_init(void)
{
if (cpu_is_omap243x()) {
@@ -172,10 +159,7 @@ void __init usb_musb_init(void)
musb_resources[0].end = musb_resources[0].start + SZ_8K - 1;
#ifdef CONFIG_NOP_USB_XCEIV
- if (platform_device_register(nop_xceiv_device) 0) {
- printk(KERN_ERR Unable to register NOP-XCEIV device\n);
- return;
- }
+ usb_nop_xceiv_register();
#endif
if (platform_device_register(musb_device) 0) {
--
1.6.0.3
--
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: Preempt-RT on OMAP3?
RX DMA is troublesome with the MUSB code, and there are some bugfixes pending which should affect it. (Posted to linux-usb over the last week or two.) Do these problems show up with DMA disabled? I guess you mean with CONFIG_MUSB_PIO_ONLY - yes, I've tried that. I don't observe the Rx DMA problems as described previously in that configuration, no Good... However I instead I see hard-lockups with no obvious cause and no messages printed to the console. (The only repeatable one I've found so far is exiting cyclictest with ^C. Not good). These lockups could well be and probably are unrelated, but none-the-less, it's very troubling! Given the bootlog excerpt you posted, I'm thinking there are still some basic goofy things with the RT patches you're using even outside the scope of MUSB. Basic as in timer tick and kernel thread setup; lots of things look goofy. I've uploaded my defconfig here: http://hugovincent.com/files/lkml-20090407/ along with a log of the bootup process. I've enabled a bunch of debug options and self-tests. You can see the rather verbose output of some spinlock tests (I think) failing early in the bootup process, somewhere in timer initialization (I think?). Those look like lockdep things. Get a more complete boot log and maybe someone will be able to sort out what's up. - Dave Regards, Hugo -- 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: Preempt-RT on OMAP3?
On Monday 06 April 2009, Hugo Vincent wrote: Here is a complete boot log + config: http://hugovincent.com/files/lkml-20090407/boot2.log Erm, not very complete actually. Enable DEBUG_LL to see more early messages ... like the ones starting right after the kernel decompression messages. Also, re those udev-induced messages: Remounting root file system... uncorrectable error : 3end_request: I/O error, dev mtdblock0, sector 0 Buffer I/O error on device mtdblock0, logical block 0 uncorrectable error : 3uncorrectable error : 3end_request: I/O error, dev mtdblock0, sector 8 Buffer I/O error on device mtdblock0, logical block 1 end_request: I/O error, dev mtdblock0, sector 16 Buffer I/O error on device mtdblock0, logical block 2 uncorrectable error : 3end_request: I/O error, dev mtdblock0, sector 24 Buffer I/O error on device mtdblock0, logical block 3 uncorrectable error : 3end_request: I/O error, dev mtdblock0, sector 0 Buffer I/O error on device mtdblock0, logical block 0 You shouldn't need mtdblock unless you run JFSS2, so that's the quick way to get rid of them: take that out of your kernel configuration. Else, add mtdblock* to the KERNEL==... ; goto persistent_storage_end check in /etc/udev/rules.d/60-persistent-storage.rules I understand the next version of udev will fix that. - Dave -- 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: Benchmarking: POP flash vs. MMC?
On Friday 03 April 2009, Russ Dill wrote: On Fri, Apr 3, 2009 at 7:52 PM, David Hagood david.hag...@gmail.com wrote: Well, that's not what I would have expected - I would have thought reads on POP would have been faster than that, and cheaper - the SD being the same speed but less CPU is surprising. The POP flash may not have a DMA ability. ISTR it does, but it's not used. There are other speedups possible; the NAND driver in the OMAP tree is pretty simplistic. It doesn't use the Prefetch and Write-Posting Engine (we don't know if that really helps though); or the more aggressive ECC support (4-bit and 8-bit modes both work). Of course using DMA in the MTD stack can be a bit problematic in general. It assumes that DMA is not used ... to the extent of not guaranteeing to provide DMA-mappable I/O buffers. That said, it's hard to achieve speedups through DMA for such small blocks of memory ... an issue which is not unique to NAND. Also, the POP flash contents are compressed and ECC corrected, so its a lot of extra work for the CPU. ECC is done in hardware for the native NAND stack on OMAP; but you're right about compression. Another point is that managed NAND (like MMC and eMMC, and various SSD flavors) is there to offload some complicated and error-prone tasks like wear-leveling. -- 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
twl4030-power scripts and wedge-on-reboot
I find that it's not just Beagle which refuses to reboot when the twl4030-power driver is configured ... 3430 SDP does so now, too. (Standard OMAP tree with no particular PM-related patches applied.) Does anyone know what the problem is? - Dave -- 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] OMAP: Don't warn user about expected behaviour in mmc-twl4030
On Tuesday 31 March 2009, Mark Brown wrote: On Mon, Mar 30, 2009 at 01:53:43PM -0700, David Brownell wrote: So when are you going to fix the regulator docs to report that: ALL regulator consumers must start by enabling and then disabling the regulator. The documention should not be changed to say that since only consumers that need the regulator to be off at startup should do this, and then probably only if they find that it is already enabled. Probably shows you still don't have a good answer... I see that mainline now has ca7255614e0861e36480103f4a402a115803d7b5 which is a variant of the first late-fixup patch I sent. The isssue with that approach is that it leaves a huge window between regulator init and its late fixup ... during which driver probe() calls suffer the bad effects of the current self-inconsistent initialization. So it doesn't really address the MMC cases. On Friday 03 April 2009, Tony Lindgren wrote: ... what if we have something in regulator_init_data that would tell the regulator to reset the regulator on init? That would address the MMC scenario, where the stack always wants to start with regulator off if it's possible. And in fact, that's exactly what I think folk should be doing with the recent additions to twl4030-power supporting explicit init of all the power resources ... as done with e.g. Beagle. The benefit of doing it that way is that it can cover the regulators which are not actually used on the board (like VAUX3 on Beagle, which u-boot enables but is not wired to anything) plus non-regulator resources like CLKREQ etc. So there's an OMAP-specific workaround now in place, albeit not yet headed towards mainline. - Dave -- 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] regulator: twl4030 VAUX3 supports 3.0V
On Wednesday 25 March 2009, Adrian Hunter wrote: http://community.ti.com/forums/p/3777/14574.aspx So how do we do it? I'd prefer seeing the reply from Ghandar to David's last question before accepting this patch again. It's still not 100% clear from TI, things seem a little bit muddled as to whether 3V will be guaranteed to work on *all* shipped devices. Ghandar has responded. What would you like to do? Update the patch to include a comment (by the table def) that TI says they're revising the twl5030/tps659x0 specs to support that 3.0V setting, then merge it. (Umm, though I'd be sure to find out specifically which selectors they're supporting that way, first...) I don't think they'll be revising specs on chips they've shipped already ... but this isn't likely to matter on those older systems, anyway; example, the 3430 SDP uses VAUX3, but at the always-supported 2.8V setting. -- 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: omap3evm mmc problem
On Wednesday 25 March 2009, Tony Lindgren wrote: * David Brownell davi...@pacbell.net [090321 02:34]: On Friday 20 March 2009, dfoley wrote: Does anyone else get these mmc errors or know why on the OMAP 3530 Development board ? Which dev board? LDP? EVM? mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock regulator: Unable to get requested regulator: vmmc Needs patches to setup whichever regulator is used with the MMC1 controller. Look at Beagle, Overo, or SDP for examples... mmci-omap-hs mmci-omap-hs.0: err -19 configuring card detect Is this again the CONFIG_REGULATOR missing in .config? Maybe. Do all the boards set up their regulators now? -- 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: omap3evm mmc problem
On Wednesday 25 March 2009, dfoley wrote: SD seems to work now with patch below and REGULATOR_TWL4030 [=y]. For the patch, I just copied from other boards in mach-omap2, so I really have no idea if it's correct. I think you don't need to set up VSIM, since that board only seems to support 4-wire SD cards (not 8-wire MMCplus). Else mmc[0].wires == 4 would be wrong... -- 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] OMAP: mmc_twl4030 nicely disable vmmc_aux
On Tuesday 24 March 2009, Adrian Hunter wrote:
From 1a3f939d95122d8e58a3750cf5bce09247357203 Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
The MMC driver turns the power off before it turns it
on. To avoid regulator warnings, vmmc_aux must only be
disabled if it has previously been enabled.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
Acked-by: David Brownell dbrown...@users.sourceforge.net
good catch.
---
arch/arm/mach-omap2/mmc-twl4030.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c
b/arch/arm/mach-omap2/mmc-twl4030.c
index 2ff50f0..cb56fe2 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -305,7 +305,7 @@ static int twl_mmc23_set_power(struct device *dev, int
slot, int power_on, int v
ret = mmc_regulator_set_ocr(c-vcc, 0);
}
} else {
- if (c-vcc_aux)
+ if (c-vcc_aux (ret = regulator_is_enabled(c-vcc_aux)) 0)
ret = regulator_disable(c-vcc_aux);
if (ret == 0)
ret = mmc_regulator_set_ocr(c-vcc, 0);
--
1.5.6.3
--
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] OMAP3: MMC needs CONFIG_REGULATOR{,_TWL4030} now in defconfigs
On Tuesday 24 March 2009, Paul Walmsley wrote: MMC doesn't work after 3fe326511c66ab842ef0a09a1f4c564b1a8beecf unless CONFIG_REGULATOR, CONFIG_REGULATOR_TWL4030 are present in the .config. Add those in for all OMAP3 defconfigs. Tested on BeagleBoard, but this is presumably needed for anything with MMC and TWL4030. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: David Brownell davi...@pacbell.net Acked-by: David Brownell dbrown...@users.sourceforge.net I seem to have given up on updating defconfigs, but that doesn't mean it's not a good thing to do! Same thing with twl4030 GPIO support, on most of those platforms. -- 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: omap3evm mmc problem
On Friday 20 March 2009, dfoley wrote: Does anyone else get these mmc errors or know why on the OMAP 3530 Development board ? Which dev board? LDP? EVM? mmci-omap-hs mmci-omap-hs.0: Failed to get debounce clock regulator: Unable to get requested regulator: vmmc Needs patches to setup whichever regulator is used with the MMC1 controller. Look at Beagle, Overo, or SDP for examples... mmci-omap-hs mmci-omap-hs.0: err -19 configuring card detect -- 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: PM branch rebased to 2.6.29
On Friday 20 March 2009, Tony Lindgren wrote: * David Brownell davi...@pacbell.net [090319 15:27]: * Least hassle ... I think all these should merge to the linux-omap tree in any case (and thence linux-pm): http://marc.info/?l=linux-omapm=123699264117846w=2 http://marc.info/?l=linux-omapm=123699340818395w=2 http://marc.info/?l=linux-omapm=123705919713239w=2 Pushed these. That way we'll end up with a working 2.6.29-omap1 :) I approve that message. ;) Dave, got a version of the third patch above against the mainline kernel? That could be added to the omap3-boards queue for the upcoming merge window. That patch was a bit messy ... combined the VPLL2 bits, and the twl4030-power bits. The former can go to mainline, but only after the regulator framework updates for VPLL2; I'll make such a patch. The latter needs twl4030-power to get to mainline ... The second fix -- in some flavor -- is IMO still needed, since the first fix is just avoiding regulator framework bugs. To me it sounds like the regulator framework should eventually handle the regulators left on by the bootloader. Just let me know if some other patches are needed to l-o tree meanwhile. I may just prepare an mmc-twl4030 patch with ugly workarounds, since I'm getting the strong feeling that it'll take forever to get the regulator framework fixed in that area. Meanwhile, I suggest merging the updated version of the Overo patch, as sent by Steve. - Dave -- 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.6.28-rc8-omap git] sdp regulator init updates
From: David Brownell dbrown...@users.sourceforge.net
Hook up VPLL2 regulator on 3430 SDP. Link that and VDAC to the
framebuffer device, supporting eventual conversion to use the
regulator framework.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
Try also to merge this into the mainline queue ...
arch/arm/mach-omap2/board-3430sdp.c | 30 ++
1 file changed, 30 insertions(+)
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -189,6 +189,8 @@ static int ads7846_vaux_control(int vaux
{
int ret = 0;
+ /* FIXME use regulator calls */
+
#ifdef CONFIG_TWL4030_CORE
/* check for return value of ldo_use: if success it returns 0 */
if (vaux_cntrl == VAUX_ENABLE) {
@@ -245,6 +247,16 @@ static struct platform_device sdp3430_lc
.id = -1,
};
+static struct regulator_consumer_supply sdp3430_vdac_supply = {
+ .supply = vdac,
+ .dev= sdp3430_lcd_device.dev,
+};
+
+static struct regulator_consumer_supply sdp3430_vdvi_supply = {
+ .supply = vdvi,
+ .dev= sdp3430_lcd_device.dev,
+};
+
static struct platform_device *sdp3430_devices[] __initdata = {
sdp3430_smc91x_device,
sdp3430_lcd_device,
@@ -587,6 +599,23 @@ static struct regulator_init_data sdp343
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = sdp3430_vdac_supply,
+};
+
+/* VPLL2 for digital video outputs */
+static struct regulator_init_data sdp3430_vpll2 = {
+ .constraints = {
+ .name = VDVI,
+ .min_uV = 180,
+ .max_uV = 180,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = sdp3430_vdvi_supply,
};
static struct twl4030_platform_data sdp3430_twldata = {
@@ -609,6 +638,7 @@ static struct twl4030_platform_data sdp3
.vmmc2 = sdp3430_vmmc2,
.vsim = sdp3430_vsim,
.vdac = sdp3430_vdac,
+ .vpll2 = sdp3430_vpll2,
};
static struct i2c_board_info __initdata sdp3430_i2c_boardinfo[] = {
--
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: [APPLIED] Overo broken after recent mainline merge
On Friday 20 March 2009, Tony Lindgren wrote:
This patch has been applied to the linux-omap
by youw fwiendly patch wobot.
Commit: f4223ec219313d631c3f620220ed23670c158a34
PatchWorks
http://patchwork.kernel.org/patch/12140/
To avoid needless divergence from mainline, the appended
patch would probably work better ... it doesn't actually
fix the bug in the regulator core, but it's a workaround
that could go to mainline until that core gets fixed.
(Oh, and it includes a real, albeit minor, bugfix.)
- Dave
=
From: David Brownell dbrown...@users.sourceforge.net
Updates to the mmc-twl4030 code:
- Partial workaround for the bug fixed more comprehensively
by f4223ec219313d631c3f620220ed23670c158a34 ... workaround
applies only to MMC devs using this code.
- Fix a cut'n'paste bug as noted by Adrian Hunter: the intent
was to disable not (re)enable.
The reason to want this workaround is lack of faith that any
sane fix for that regulator framework bug will ever merge,
while still wanting to see things work in mainline.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
I suggest reverting f4223ec219313d631c3f620220ed23670c158a34
after applying this ...
arch/arm/mach-omap2/mmc-twl4030.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -128,6 +128,27 @@ static int twl_mmc_late_init(struct devi
reg = regulator_get(dev, vmmc_aux);
hsmmc[i].vcc_aux = IS_ERR(reg) ? NULL : reg;
+ /* UGLY HACK: workaround regulator framework bugs.
+* When the bootloader leaves a supply active, it's
+* initialized with zero usecount ... and we can't
+* disable it without first disabling it. Until the
+* framework is fixed, we need a workaround like this
+* (which is safe for MMC, but not in general).
+*/
+ if (regulator_is_enabled(hsmmc[i].vcc) 0) {
+ dev_warn(dev, APPLY REGULATOR HACK for
vmmc\n);
+ regulator_enable(hsmmc[i].vcc);
+ regulator_disable(hsmmc[i].vcc);
+ }
+ if (hsmmc[i].vcc_aux) {
+ if (regulator_is_enabled(reg) 0) {
+ dev_warn(dev, APPLY REGULATOR HACK
+ for vmmc_aux\n);
+ regulator_enable(reg);
+ regulator_disable(reg);
+ }
+ }
+
break;
}
}
@@ -285,7 +306,7 @@ static int twl_mmc23_set_power(struct de
}
} else {
if (c-vcc_aux)
- ret = regulator_enable(c-vcc_aux);
+ ret = regulator_disable(c-vcc_aux);
if (ret == 0)
ret = mmc_regulator_set_ocr(c-vcc, 0);
}
--
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: PM branch rebased to 2.6.29
On Friday 20 March 2009, David Brownell wrote: I may just prepare an mmc-twl4030 patch with ugly workarounds, since I'm getting the strong feeling that it'll take forever to get the regulator framework fixed in that area. I just sent that ... -- 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: Things to do after 2.6.29 gets released
On Friday 20 March 2009, Felipe Balbi wrote: drivers/regulator/twl4030-regulator.c | 503 +++ Already queued for mainline... -- 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/1] Back-light class driver support for OMAP
On Wednesday 18 March 2009, hvaib...@ti.com wrote: + +#if defined(CONFIG_TWL4030_CORE) + twl4030_i2c_write_u8(TWL4030_MODULE_LED, 0x11, TWL4030_LED_EN); + twl4030_i2c_write_u8(TWL4030_MODULE_PWMA, c, TWL_PWMA_PWMAOFF); +#endif Hmm, I think I'm going to have to get off my butt and send in the PWM patches I have ... they work for the PWMs on the two LED outputs, but not yet for the two other PWM-equipped pins (GPIO-6, GPIO-7) - Dave -- 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
