Re: [PATCH 0/3] Add OMAP hardware spinlock misc driver
On Wed, 2010-10-20 at 10:53 +0100, Russell King - ARM Linux wrote: To: Ohad Ben-Cohen o...@wizery.com Cc: Hari Kanigeri h-kanige...@ti.com, Benoit Cousson b-cous...@ti.com, Tony Lindgren t...@atomide.com, Greg KH g...@kroah.com, linux-ker...@vger.kernel.org, Grant Likely grant.lik...@secretlab.ca, ma...@codeaurora.org, a...@linux-foundation.org, Suman Anna s-a...@ti.com, ma...@codeaurora.orgmattw, linux-arm-ker...@lists.infradead.org which includes an invalid address ma...@codeaurora.orgmattw. Is there a reason why you're excluding the linux-omap list from your message and subsequent discussion? I was trying to add Matt to the CC, but I guess I accidentally deleted some CC's .. So it was purely an accident. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix HWCAP_TLS flag for ARM11MPCore/Cortex-A9
On Wed, 2010-10-06 at 17:00 -0700, Tony Lindgren wrote: - .long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP + .long HWCAP_SWP|HWCAP_HALF|HWCAP_THUMB|HWCAP_FAST_MULT|HWCAP_EDSP|HWCAP_TLS Thanks for catching this.. I have no idea how this happened, I must have somehow been using a pre July 5th kernel when I made the patch.. Maybe a forgotten bisect or something. Daniel -- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Thu, 2010-07-01 at 20:02 +0200, Andi Kleen wrote: What license (name/type) is this? IANAL, but AFAIK standard wisdom is that disclaimer in the documentation and/or other materials provided is generally not acceptable for Linux because it's an excessive burden for all distributors. It's the BSD license .. Also for me it's still quite unclear why we would want this code at all... It doesn't seem to do anything you couldn't do with the existing interfaces. I don't know all that much about what Zach's done here, but from what he's said so far it looks like this help to manage lots of IOMMUs on a single system.. On x86 it seems like there's not all that many IOMMUs in comparison .. Zach mentioned 10 to 100 IOMMUs .. Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Thu, 2010-07-01 at 21:38 +0200, Andi Kleen wrote: Also for me it's still quite unclear why we would want this code at all... It doesn't seem to do anything you couldn't do with the existing interfaces. I don't know all that much about what Zach's done here, but from what he's said so far it looks like this help to manage lots of IOMMUs on a single system.. On x86 it seems like there's not all that many IOMMUs in comparison .. Zach mentioned 10 to 100 IOMMUs .. The current code can manage multiple IOMMUs fine. He demonstrated the usage of his code in one of the emails he sent out initially. Did you go over that, and what (or how many) step would you use with the current code to do the same thing? Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager
On Thu, 2010-07-01 at 15:00 -0700, Zach Pfeffer wrote: Additionally, the current IOMMU interface does not allow users to associate one page table with multiple IOMMUs unless the user explicitly wrote a muxed device underneith the IOMMU interface. This also could be done, but would have to be done for every such use case. Since the particular topology is run-time configurable all of these use-cases and more can be expressed without pushing the topology into the low-level IOMMU driver. The VCMM takes the long view. Its designed for a future in which the number of IOMMUs will go up and the ways in which these IOMMUs are composed will vary from system to system, and may vary at runtime. Already, there are ~20 different IOMMU map implementations in the kernel. Had the Linux kernel had the VCMM, many of those implementations could have leveraged the mapping and topology management of a VCMM, while focusing on a few key hardware specific functions (map this physical address, program the page table base register). So if we include this code which map implementations could you collapse into this implementations ? Generally , what currently existing code can VCMM help to eliminate? Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
On Thu, 2010-05-13 at 14:46 -0700, Greg KH wrote: On Thu, May 13, 2010 at 02:33:29PM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote: Because someone would have to remove suspend blockers (or rather wakelocks) from the drivers, test that they work correctly without suspend blockers and submit the modified versions. Going forward, every party responsible for such a driver would have to maintain an out-of-tree version with suspend blockers (or wakelocks) anyway, so the incentive to do that is zero. They should work without wakelock since wakelock are optional .. I mean there's nothing in suspend blockers I've seen that indicates it's required for some drivers to work. So it's just a matter of patching out the wakelocks, with no need to re-test anything. You get the driver mainlined, then maintain a small patch to add wakelocks. Not hard at all , with lots of incentive to do so since you don't have to maintain such a large block of code out of tree. Sorry, but it doesn't seem to work that way. Look at the large number of out-of-tree android device drivers that remain sitting there because of the lack of this interface being in the kernel. I don't think that's due to this interface tho. During your CELF presentation you noted several bits of code that could go in right now but haven't (and still haven't as far as I've seen). I'm actively pushing code related to Android (with wakelocks removed).. Putting a wakelock contingency on everything to me doesn't make much sense. Also note that such a driver, without wakelocks, would never get tested, and so, things start quickly diverging. That's not totally true. For example the MMC driver had wakelocks (I think, or for sure mmc core does), and the MMC driver has been tested for G1 and works fine so far without them. I have code that is queued for my tree that will enable MMC on G1. I can merge Nexus one support through my tree also which would allow all the drivers for that device to eventually be used. With that device support in mainline then those drivers become nice things to have with or with out wakelocks. You don't need wakelocks to run Debian or anything else except Android. Daniel -- 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)
On Thu, 2010-05-13 at 13:17 +0100, Matthew Garrett wrote: On Wed, May 12, 2010 at 09:35:30PM -0600, Paul Walmsley wrote: Figuring out a different way to do this should not limit Android at all, since Google can do what other Linux distributions do and continue to patch opportunistic suspend/suspend-block calls into their kernels as needed to ship devices, while contributing towards a different solution to the problem. I basically agree, except that despite having a year to do so none of us have come up with a different way that would actually work. Google have done this work. Who's going to prove that there is actually a different way to do this? We all feel the pain of inelegance right? I think it's clear that this system will not last (but there's no other immediate option) .. That doesn't mean we should reject it, but we need to be clear that this system will get replaced. So we should format the patches appropriately. To me the userspace aspect is a permanent change .. If we could drop that (or put it into debugfs) then it would make this a lot easy to accept as a stepping stone. Daniel -- 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)
On Thu, 2010-05-13 at 11:17 -0700, Brian Swetland wrote: I'm not sure this necessitates using only debugfs for the userspace interface. A userspace interface is necessary to accomplish what we're trying to do here, otherwise we have only half a solution, and our hope is that it'd be a stable interface (as userspace interfaces are supposed to be) for as long as its needed. I could totally imagine the userspace interface eventually becoming a no-op or punching through to some other facility, depending on how this problem is solved long-term in the ideal post-suspend-block future. The problem is that once this userspace interface is exposed, it's nearly permanent and has to be support for a long long time .. It might seen trivial to just remove something your not using, but we never know who is using what once the kernel is released. Daniel -- 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)
On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote: On Thu, May 13, 2010 at 11:25:57AM -0700, Daniel Walker wrote: The problem is that once this userspace interface is exposed, it's nearly permanent and has to be support for a long long time .. It might seen trivial to just remove something your not using, but we never know who is using what once the kernel is released. Deprecating sysfs interfaces can be done within 6 months or so, especially if there's only one real consumer. I'll assume your right (can you give an example of this?), but why should we even add it if we know it's already going to get replaced. It's like it's pre-deprecated .. Daniel -- 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)
On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: On Thu, May 13, 2010 at 11:59:37AM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 19:36 +0100, Matthew Garrett wrote: Deprecating sysfs interfaces can be done within 6 months or so, especially if there's only one real consumer. I'll assume your right (can you give an example of this?), but why should we even add it if we know it's already going to get replaced. It's like it's pre-deprecated .. See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. Ok, feature-removal-schedule.txt applies to everything tho. What your saying is that if this interface only last a short time it might take 6 months, if it last for a long time it would take longer. There's no easy way to know that Google is the only user after some amount of time passes. Daniel -- 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)
On Thu, 2010-05-13 at 13:23 -0700, Tony Lindgren wrote: * Matthew Garrett m...@redhat.com [100513 13:03]: On Thu, May 13, 2010 at 01:00:04PM -0700, Tony Lindgren wrote: The system stays running because there's something to do. The system won't suspend until all the processors hit the kernel idle loop and the next_timer_interrupt_critical() returns nothing. At which point an application in a busy loop cripples you. Maybe you could deal with the misbehaving untrusted apps in the userspace by sending kill -STOP to them when the screen blanks? Then continue when some event wakes up the system again. Couldn't you just use priorities (nice), or cgroups to deal with that? I'm sure there is a way to limit an apps runtime, so the system does go idle sometimes. I think we could implement your suggestion more easily by just giving untrusted applications an effectively infinite amount of timer slack, but it still doesn't handle the case where an app behaves excrutiatingly badly. Hmm, if you use timer slack then you still need to search through the whole timer list instead of a smaller critical timer list. Both ways sound doable though. There are deferrable timers already in Linux.. It seems like it would just be an extension of that. Daniel -- 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)
On Thu, 2010-05-13 at 23:11 +0200, Rafael J. Wysocki wrote: On Thursday 13 May 2010, Matthew Garrett wrote: On Thu, May 13, 2010 at 12:36:34PM -0700, Daniel Walker wrote: On Thu, 2010-05-13 at 20:11 +0100, Matthew Garrett wrote: See feature-removal-schedule.txt. So far we have no indication that it's going to be replaced, because nobody has actually suggested a working way to do this better. If we had a concrete implementation proposal for that then we'd be in a pretty different position right now. Ok, feature-removal-schedule.txt applies to everything tho. What your saying is that if this interface only last a short time it might take 6 months, if it last for a long time it would take longer. There's no easy way to know that Google is the only user after some amount of time passes. If the interface is there for a long time, it's because we haven't come up with anything better. And if we haven't come up with anything better, the interface deserves to be there. Moreover, the interface is already in use out-of-tree and that usage is actually _growing_, so we have a growing number of out-of-tree drivers that aren't megrgeable for this very reason. Why can't we merge the drivers? Drivers are just drivers, they don't need this to get merged. (They need it to work with Android) Daniel -- 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)
On Thu, 2010-05-13 at 23:27 +0200, Rafael J. Wysocki wrote: Because someone would have to remove suspend blockers (or rather wakelocks) from the drivers, test that they work correctly without suspend blockers and submit the modified versions. Going forward, every party responsible for such a driver would have to maintain an out-of-tree version with suspend blockers (or wakelocks) anyway, so the incentive to do that is zero. They should work without wakelock since wakelock are optional .. I mean there's nothing in suspend blockers I've seen that indicates it's required for some drivers to work. So it's just a matter of patching out the wakelocks, with no need to re-test anything. You get the driver mainlined, then maintain a small patch to add wakelocks. Not hard at all , with lots of incentive to do so since you don't have to maintain such a large block of code out of tree. Practically, as long as the opportunistic suspend is out of tree, there will be a _growing_ number of out-of-tree drivers out there, which is not acceptable in the long run. I don't see why your saying that. These driver should work with out all of this, which means they can get mainlined right now. Daniel -- 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] arm: omap: iovmm: add missing mutex_unlock
I was using Coccinelle with the mutex_unlock semantic patch, and it unconvered this problem. It appears to be a valid missing unlock issue. This change should correct it by moving the unlock below the label. This patch is against the mainline kernel. Cc: Julia Lawall ju...@diku.dk Cc: Kevin Hilman khil...@deeprooted.net Cc: Tony Lindgren t...@atomide.com Signed-off-by: Daniel Walker dwal...@fifo99.com --- arch/arm/plat-omap/iovmm.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c index 57f7122..9b6cb90 100644 --- a/arch/arm/plat-omap/iovmm.c +++ b/arch/arm/plat-omap/iovmm.c @@ -363,8 +363,9 @@ void *da_to_va(struct iommu *obj, u32 da) goto out; } va = area-va; - mutex_unlock(obj-mmap_lock); out: + mutex_unlock(obj-mmap_lock); + return va; } EXPORT_SYMBOL_GPL(da_to_va); -- 1.6.0.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
