Re: [PATCH 270/493] arm: remove use of __devinit
On Mon, Nov 19, 2012 at 01:23:39PM -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu --- arch/arm/mach-msm/proc_comm.c| 2 +- arch/arm/mach-msm/smd.c | 2 +- Acked-by: David Brown dav...@codeaurora.org -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 V6 1/2] of: Add generic device tree DMA helpers
On Mon, Sep 17, 2012 at 08:42:11PM +, Arnd Bergmann wrote: On Saturday 15 September 2012, Russell King - ARM Linux wrote: On Fri, Sep 14, 2012 at 05:41:56PM -0500, Jon Hunter wrote: 3. Supporting legacy devices not using DMA Engine These devices present a problem, as there may not be a uniform way to easily support them with regard to device tree. Ideally, these should be migrated to DMA engine. However, if this is not possible, then they should still be able to use this binding, the only constaint imposed by this implementation is that when requesting a DMA channel via of_dma_request_slave_channel(), it will return a type of dma_chan. As far as devices not using DMA engine, the answer is we don't support their specification in the DT model. Note that the legacy OMAP DMA API is scheduled for removal next year, so it's not going to be around that much longer. There are a few platforms using the ISA DMA API (rpc, h720x, shark, footbridge), and I agree that they are unlikely to see OF support, although if they did, it wouldn't be unreasonable to encode their DMA channels using the same binding. The other ones that are currently around with their own DMA implementation are bcmring -- platform is going away samsung -- gradually getting moved to dmaengine, already has its own binding that needs to be replaced with this one, so best do it at the same time. tegra -- old dma code gone in 3.7 pxa/mmp -- dmaengine implementation being worked on, should wait for that. msm -- dma implementation only used by two drivers (serial and mmc). Outside of arch/arm, at least sh, cris, unicore32 and blackfin have their own dma APIs based on the ISA interfaces. I don't currently see any of them moving towards DT, but it's definitely possible. Among the above MSM seems to be the most likely candidate to use the binding before moving to DT. The msm_sdcc driver is (like much of the msm platform code) lagging far behind the internel version that qualcomm have, and the device tree binding they are using is incompatible with the common MMC binding (and of course the DMA binding here) as well. For getting MSM up to speed compared with the other platforms, they have to use proper DT bindings as well as proper DMA engine support. Between those two, I'd prefer fixing the DT binding first, in order to limit the amount of changes that have to be done to external device tree files. There is also a lot of similarity between the mmci hardware and the msm_sdcc hardware. Enough so, that it is probably better for us to make the mmci driver work with our hardware, rather than trying to keep msm_sdcc going. There is also an MSM nand device that appears to have not made it in. It is heavily dependent on the weird features of the DMA hardware. I don't have any current plans to support this device, since most boards using MSMs these days are using mmc/sd instead of bare NAND. Our DMA hardware is really weird, but should be a bit reasonable. It is also being gradually replaced in newer chips with a different DMA framework. As far as I'm concerned, I consider making our DMA driver(s) use the DMA engine API to be part of getting these platforms working with DT. It is planned, but there are quite a few things that need to be tackled first. David -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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: changing DMA slave configuration API
On Mon, Jun 11, 2012 at 10:20:49AM +0530, Vinod Koul wrote: I think it is a good idea. And I would like to extend it even a little bit. Do we have any users of peripheral to peripheral slave dma? IIRC that is not the case, or does anyone know of existence or plans for such a h/w? We have hardware that supports this, and I suspect it will become more common in our future chips. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/4] regulator: helper routine to extract regulator_init_data
On Fri, Nov 18, 2011 at 04:47:17PM +0530, Rajendra Nayak wrote:
+ xyzreg: regulator@0 {
+ regulator-min-microvolt = 100;
+ regulator-max-microvolt = 250;
+ regulator-always-on;
+ vin-supply = vin;
+ };
Just noticed this, but the '@0' shouldn't be on the name, since there
isn't a reg attribute on this node. Perhaps it should be
regulator-xyz?
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/17] ARM: mark const init data with __initconst instead of __initdata
On Thu, Mar 29, 2012 at 11:12:20PM +0200, Uwe Kleine-König wrote: arch/arm/mach-msm/board-msm8x60.c |2 +- arch/arm/mach-msm/board-qsd8x50.c |4 +- Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 2/5] ARM: SMP: Refactor Kconfig to be more maintainable
On Wed, Dec 14, 2011 at 11:39:38AM +, Dave Martin wrote: Making SMP depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms are SMP-capable to the individual machines. To enable this, a new HAVE_SMP config option is introduced to allow machines to indicate that they can run in a SMP configuration. There still seem to be several people and lists from the get_maintainer.pl output that are missing. Russell should be included, as well as the MSM maintainers and that list. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 REPOST 2/5] ARM: SMP: Refactor Kconfig to be more maintainable
On Wed, Dec 14, 2011 at 11:39:38AM +, Dave Martin wrote: Making SMP depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms are SMP-capable to the individual machines. To enable this, a new HAVE_SMP config option is introduced to allow machines to indicate that they can run in a SMP configuration. arch/arm/mach-msm/Kconfig |1 + Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mmc: Add mmc_host_level logging
On Tue, Nov 15, 2011 at 03:32:08PM -0800, Joe Perches wrote: Centralize the pr_level uses of mmc_hostname into specific mmc_host_level calls to allow a flexible presentation style and shorten the code a bit. drivers/mmc/host/msm_sdcc.c | 101 ++- The MSM ones at least are quite straightforward, so I'm fine with this part of the change. Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/6] iommu/msm: announce supported page sizes
On Fri, Sep 16, 2011 at 08:51:43PM +0300, Ohad Ben-Cohen wrote: Let the IOMMU core know we support 4KiB, 64KiB, 1MiB and 16MiB page sizes. This way the IOMMU core can split any arbitrary-sized physically contiguous regions (that it needs to map) as needed. Signed-off-by: Ohad Ben-Cohen o...@wizery.com Cc: David Brown dav...@codeaurora.org Cc: Stepan Moskovchenko step...@codeaurora.org --- drivers/iommu/msm_iommu.c |8 +++- Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 49/57] video: irq: Remove IRQF_DISABLED
On Wed, Sep 21, 2011 at 05:28:50PM +0800, Yong Zhang wrote: Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled], We run all interrupt handlers with interrupts disabled and we even check and yell when an interrupt handler returns with interrupts enabled (see commit [b738a50a: genirq: Warn when handler enables interrupts]). So now this flag is a NOOP and can be removed. Signed-off-by: Yong Zhang yong.zha...@gmail.com --- drivers/video/msm/mddi.c |2 +- drivers/video/msm/mdp.c |2 +- Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] iommu/msm: -unmap() should return order of unmapped page
On Fri, Sep 02, 2011 at 08:32:34PM +0300, Ohad Ben-Cohen wrote: Users of the IOMMU API (kvm specifically) assume that iommu_unmap() returns the order of the unmapped page (on success). Fix msm_iommu_unmap() accordingly. Signed-off-by: Ohad Ben-Cohen o...@wizery.com Cc: Stepan Moskovchenko step...@codeaurora.org Cc: David Brown dav...@codeaurora.org --- drivers/iommu/msm_iommu.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c index 1a584e0..d1733f6 100644 --- a/drivers/iommu/msm_iommu.c +++ b/drivers/iommu/msm_iommu.c @@ -543,6 +543,13 @@ static int msm_iommu_unmap(struct iommu_domain *domain, unsigned long va, } ret = __flush_iotlb(domain); + + /* + * the IOMMU API requires us to return the order of the unmapped + * page (on success). + */ + if (!ret) + ret = order; fail: spin_unlock_irqrestore(msm_iommu_lock, flags); return ret; Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/13] ARM: gpio: consolidate trivial gpiolib implementations
On Thu, Aug 11, 2011 at 04:08:07PM +0100, Russell King - ARM Linux wrote: As a note, there were duplicated e-mail address Grant and Nicolas in Cc ;) I just pushed 'reply all' :) That's not in the original email, and isn't in any one elses replies The original patches have a doubled CC line. I think most mailers eliminate the duplicates, though. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: Use pr_level, add and use mmc_level
On Thu, Aug 11, 2011 at 01:21:24PM -0700, Joe Perches wrote: Use current logging styles. Add an mmc_printk function to reduce overall size by centralizing the mmc_hostname use. Because pr_fmt(fmt) KBUILD_MODNAME is used, some logging prefixes are changed. For instance from SDIO: to mmc_core: Add macros for mmc_err, mmc_warn, and mmc_info. Convert printks with mmc_hostname to mmc_level. Whitespace neatening around pr_level. Convert printk(KERN_DEBUG to pr_debug( Convert direct uses of DBG macros to pr_debug. Convert direct uses of DBGF to DBG. Coalesce long format strings. Add a few missing newlines to logging messages. $ size drivers/mmc/built-in.o* text data bss dec hex filename 92530 1608 204 94342 17086 drivers/mmc/built-in.o.minimal.new 94229 1608 204 96041 17729 drivers/mmc/built-in.o.minimal.old 291831 5152 77344 374327 5b637 drivers/mmc/built-in.o.allyesconfig.new 293616 5152 78128 376896 5c040 drivers/mmc/built-in.o.allyesconfig.old Signed-off-by: Joe Perches j...@perches.com --- drivers/mmc/host/msm_sdcc.c | 103 +-- Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to handle named resources with DT?
On Wed, Aug 10, 2011 at 01:22:16PM -0600, Grant Likely wrote: Please, stick with the established convention and explicitly order 'reg' and 'interrupts' properties. If there is a specific use case where this doesn't work, then bring it up, but I haven't seen any yet. The current users of _byname that I've looked seem to only use it for convenience, not because a register range may be optional. ie. they all fail out if a reg resource isn't present. The msm_serial driver uses the presence of one of it's _byname reg regions to distinguish between two different types of the controller. Fortunately, it is the last register range that has this. It's probably best to make the DT code depend on compatible (or some attribute) to determine if this functionality is available, or in this case, even make it a separate memory region. I'm not sure what the cleanest way is to implement this, and still have the driver work with non-DT systems. Patches coming soon... David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/13] ARM: gpio: consolidate trivial gpiolib implementations
On Tue, Aug 09, 2011 at 09:08:01AM +0100, Russell King - ARM Linux wrote: Consolidate 24 trivial gpiolib implementions out of mach/gpio.h into asm/gpio.h. This is basically the include of asm-generic/gpio.h and the definition of gpio_get_value, gpio_set_value, and gpio_cansleep as described in Documentation/gpio.txt Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-msm/include/mach/gpio.h |5 + For msm (msm8660): Tested-by: David Brown dav...@codeaurora.org Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] msm: iommu: move to drivers/iommu/
On Fri, Jun 10 2011, Ohad Ben-Cohen wrote: This should ease finding similarities with different platforms, with the intention of solving problems once in a generic framework which everyone can use. Compile-tested for MSM8X60. Acked-by: David Brown dav...@codeaurora.org I believe that Stepan Moskovochenko has some extra tests for this code, but given that none of the code itself changes, I wouldn't expect any problems. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] drivers/iommu/ relocations
On Wed, Jun 08 2011, Roedel, Joerg wrote: Great, thanks. I'll apply the patches as soon as the relevant ACKs come in. Looking at the MAINTAINERS file David Brown needs to ACK the MSM patch and David Woodhouse the VT-d patch. David B., David W., is this direction ok for both of you? I think it is a good direction to move in. I'll reply to the patch directly to comment on it. My suggestion is that the ARM tree pulls in the necessary changes from the IOMMU tree and the IOMMU code goes upstream through Ingo or directly to Linus (with some time in linux-next, of course). Thoughts? This seems the cleanest to me. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] msm: iommu: move to drivers/iommu/
On Wed, Jun 08 2011, Ohad Ben-Cohen wrote: This should ease finding similarities with different platforms, with the intention of solving problems once in a generic framework which everyone can use. Compile-tested for MSM8X60. Signed-off-by: Ohad Ben-Cohen o...@wizery.com --- arch/arm/mach-msm/Kconfig | 12 arch/arm/mach-msm/Makefile |2 +- drivers/iommu/Kconfig | 11 +++ drivers/iommu/Makefile |1 + .../mach-msm/iommu.c = drivers/iommu/msm-iommu.c |0 5 files changed, 13 insertions(+), 13 deletions(-) rename arch/arm/mach-msm/iommu.c = drivers/iommu/msm-iommu.c (100%) Moving the driver is good. I'm wondering what we should do with iommu_dev.c, though. Wouldn't it make sense to move this file as well? I've added the author, Stepan Moskovchenko, in case he has any feedback. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wed, Mar 30 2011, Linus Torvalds wrote: And most GPIO drivers I've ever seen are actually basically turn this bit on or off in this register to turn it into an Input or Output along with read/write this other bit to actually see/set the value. Repeat that for 'nr' bits, where 'nr' is just some small value, usually in single digits. A few hundred is more typical. At least with the MSMs, it's even messier. The chip has a moderate number of pins, and a large number of peripherals, more than can actually be connected to these pins at a time. Multiple devices, and a general GPIO are frequently muxed. This has to be configured, in addition to input or output. Even for just GPIO, there may be multiple types of pullups, drive strengths. Different devices will need different configurations to handle low power, etc. Of the 145 files with 'gpio' in the name, 50 or so of them seem to actually be GPIO drivers. At least of the more common platforms, these are quite different, and seem to deal with fairly complex devices. Many at least use the gpiolib. The rest of the files seem to be more concerned with what the different GPIOs are connected to. This seems like the place to focus on generalizing. Maybe device tree. Now, not all of them are that, by all means, and the details are often slightly different. Sometimes the read register is the same as the write register, sometimes it isn't. Sometimes you have a clear register and a set register instead of a register you write the value to. And I haven't checked what those 145 files do, but I bet a _lot_ of them could be described by having a single generic gpio driver, and then just using devicetree to give that common driver a few values to describe where the IO ports are, which bits they are, and which type of gpio it is. If we can come up with a general way to describe the diverse things a GPIO can be used for. Even something like drive strength can have widely differing possibilities, and may need different settings for low power modes (which means it can't just be the boot loader setting it). And then when you have another ARM SoC, instead of writing yet another mindless board driver for the gpio's on it, just add the nr entries for the GPIO's to the device tree. NOT A SINGLE LINE OF CODE. Agree, at least in theory. Yes, yes, there are always exceptions. Many GPIO's are actually behind some i2c bus or something. Others can do pulsing or are just generally more complex than an array of single bits. So I'm sure we couldn't replace all those 145 gpio files under arch/arm with a single driver and some devicetree entries, but maybe half of them match the simple pattern. I bet the SoC case it's more than half, it would be silly to do i2c on an SoC. But I dunno. I really didn't look. At least one MSM has GPIOs behind i2c. Too many pins, otherwise. PowerPC does exactly the above, btw. So I'm not just talking about some magical theoretical thing. I seriously think every ARM person who has ever written any of those gpio files should look at powerpc. Now, I suspect that most powerpc SoC's tend to share more IP blocks than the crazy ARM situation, but even so, please just check it out. Check out the device tree files (*.dts) and do that same git ls-files arch/arm/ | grep gpio except do it on powerpc. See the difference? Yeah, powerpc doesn't seem to have as complex of a use of gpios. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, Mar 31 2011, Nicolas Pitre wrote: Leaf nodes on ARM are people coming from corporate background with the old school software development methodologies. They do it as a _job_ first and foremost. They only work on Linux because that's what their boss assigned them to. Don't get me wrong: that doesn't mean they are bad people. Simply that they are not into it for the public recognition (or flaming) from their peers. Once their code works they lose interest and move on. That mindset is extremely hard to change and take time, on a scale of years. Much more time than required to produce the code needed to support that new SOC out of the pipeline. There are notable exceptions obviously. But this is still a scalability problem in itself. So we need men-in-the-middle attacks. An additional mindset that is difficult to work with in this environment is that the corporate development methodology has a focus on schedules and deliverables. Even people who would otherwise like to contribute will have pressure to get something done. Many think of submit to mainline is kind of a last step in a development process, instead of even a goal to accomplish. When we push back, there is a good chance they just won't bother, not because they don't want to do it, but because it doesn't fit a schedule, and there is already something else for them to work on. So what's the right answer here. Practically, someone just sent out a fairly complete DMA driver for a new MSM device. Naturally, this hardware is nothing like anyone else's DMA, but the driver itself pretty much independent from other kernel APIs. It isn't even similar to the existing DMA driver in the MSM. With it are patches to ifdef-up various drivers to use the appropriate DMA. The DMA code, by itself, seems reasonably well written (with some cleanup and such needed), but it makes everything that uses it messy. In this particular case, DMA engine will probably need some work to either incorporate the unique capabilities of this hardware, or at least allow them to be used. The author probably won't be able to do this on their own. I could pull the driver into the tree, and now we have yet another driver with yet another API. If I push back, realistically, it will probably end up out-of-tree, along with everything that depends on it. Up until now, it seems that attitude has been that it is better to be in-tree than out of tree, but are we getting too much stuff to continue that? Today, most of the MSM code lives out of tree. The QuIC tree for MSM (currently based off of 2.6.35): git diff --stat v2.6.35..HEAD | tail -1 3432 files changed, 1144473 insertions(+), 17315 deletions(-) git diff --stat v2.6.35..HEAD arch/arm/mach-msm | tail -1 595 files changed, 286054 insertions(+), 1928 deletions(-) There's a large amount of work just to get the code up to kernel standards (the coding style has been fairly well enforced), and there is constant development for new hardware. Thanks, David Brown -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] ARM: smp: Select local timers vs dummy timer support runtime
On Sat, Feb 12 2011, Santosh Shilimkar wrote: The current code support of dummy timers in absence of local timer is compile time. This is an attempt to convert it to runtime so that on few SOC version if the local timers aren't supported kernel can switch to dummy timers. OMAP4430 ES1.0 does suffer from this limitation. This patch should not have any functional impact on affected files. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-msm/timer.c |3 ++- Acked-By: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] ARM: smp: Select local timers vs dummy timer support runtime
Let's try this again from the correct email address... On Sat, Feb 12 2011, Santosh Shilimkar wrote: The current code support of dummy timers in absence of local timer is compile time. This is an attempt to convert it to runtime so that on few SOC version if the local timers aren't supported kernel can switch to dummy timers. OMAP4430 ES1.0 does suffer from this limitation. This patch should not have any functional impact on affected files. arch/arm/mach-msm/timer.c |3 ++- Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ARM defconfig files
On Monday 12 July 2010 11:50:29 Uwe Kleine-König wrote: If it helps the powerpc people I can reduce their defconfigs, too. Do you have scripts or tools that you did this with, or is a manual process. We're about to add several new (ARM) targets, and it'd be nice to be able to make small defconfigs for those targets as well. Thanks, David -- 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: ARM defconfig files
On Monday 12 July 2010 16:18:01 Linus Torvalds wrote: 2010/7/12 David Brown dav...@codeaurora.org: Do you have scripts or tools that you did this with, or is a manual process. We're about to add several new (ARM) targets, and it'd be nice to be able to make small defconfigs for those targets as well. Uwe posted it earlier in this thread as an attachement, and I put the python script into the merge commit message too. And we should probably put it somewhere in scripts too, and/or make a 'make' target to create the small config files. I pushed it all out, and tagged it as -rc5. Got it, thanks. I just pulled a bit soon. It seems a bit brute force, probably not something I can make part of our regular build process, but I can definitely run it before sending patches out. I wonder if there's a more efficient way of doing it that doesn't involve invoking make for each line of the file. It at least shouldn't be necessary to actually build the kernel each time. David -- 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
