[PATCH resend 2/3] musb: add musb support for AM35x

2010-07-01 Thread Ajay Kumar Gupta
AM35x has musb interface and uses CPPI4.1 DMA engine. Current patch supports only PIO mode. DMA support can be added later once basic CPPI4.1 DMA patch is accepted. Signed-off-by: Ajay Kumar Gupta --- drivers/usb/musb/Kconfig |4 +- drivers/usb/musb/Makefile |4 + drivers/usb/musb/am35x

[PATCH resend 3/3] musb: AM35x: Workaround for fifo read issue

2010-07-01 Thread Ajay Kumar Gupta
AM35x supports only 32bit read operations so we need to have workaround for 8bit and 16bit read operations. Signed-off-by: Ajay Kumar Gupta --- drivers/usb/musb/am35x.c | 30 ++ drivers/usb/musb/musb_core.c |2 ++ 2 files changed, 32 insertions(+), 0 deletio

[PATCH resend 1/3] AM35x: Add musb support

2010-07-01 Thread Ajay Kumar Gupta
AM35x has musb interface (version 1.8) and uses CPPI41 DMA engine. It has USB phy built inside the IP itself. Also added ARCH_AM35x which is required to differentiate musb ips between OMAP3x and AM35x. This config would be used for below purposes, - Select am35x.c instead of omap2430.c for

Re: [PATCH 0/2] pandora updates for .36

2010-07-01 Thread Tony Lindgren
* Gadiyar, Anand [100701 23:25]: > Grazvydas Ignotas wrote: > > > > Hi Tony, > > > > here are some updates for Pandora, which we have now around 700 units > > shipped (finally!) after years of developemt hell. More are being > > made at the moment. > > > > Neat! Hope you sell a zillion. I'll t

Re: [GIT PULL] omap iommu: for-next for 2.6.35-rc1

2010-07-01 Thread Hiroshi DOYU
From: Hiroshi DOYU Subject: Re: [GIT PULL] omap iommu: for-next for 2.6.35-rc1 Date: Tue, 29 Jun 2010 07:57:44 +0300 (EEST) > Hi Tony, > > From: Hiroshi DOYU > Subject: [GIT PULL] omap iommu: for-next for 2.6.35-rc1 > Date: Wed, 02 Jun 2010 10:50:54 +0300 (EEST) > >> Hi Tony, >> >> Patches fo

Re: [PATCH 1/9] dspbridge: replace iommu custom for opensource implementation

2010-07-01 Thread Hiroshi DOYU
Hi Fernando, From: ext Fernando Guzman Lugo Subject: [PATCH 1/9] dspbridge: replace iommu custom for opensource implementation Date: Thu, 1 Jul 2010 02:20:52 +0200 > This patch replace the call to custom dsp mmu implemenation > for the once on iommu module. > > Signed-off-by: Fernando Guzman L

Re: [PATCH 5/9] dspbridge: add mmufault support

2010-07-01 Thread Hiroshi DOYU
Hi Fernando, From: ext Fernando Guzman Lugo Subject: [PATCH 5/9] dspbridge: add mmufault support Date: Thu, 1 Jul 2010 02:20:56 +0200 > With changes for iommu migration mmu fault report and dsp track > dump is broken, this patch fixes that. > > Signed-off-by: Fernando Guzman Lugo > --- > driv

Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

2010-07-01 Thread Zach Pfeffer
Andi Kleen wrote: >> The VCMM provides a more abstract, global view with finer-grained >> control of each mapping a user wants to create. For instance, the >> semantics of iommu_map preclude its use in setting up just the IOMMU >> side of a mapping. With a one-sided map, two IOMMU devices can be >

Re: [RFC 1/6] omap: add iva2 hwmod support to omap3

2010-07-01 Thread Cousson, Benoit
On 7/2/2010 12:23 AM, Ohad Ben-Cohen wrote: From: Ohad Ben-Cohen Add preliminary iva2 hwmod support to omap3. We do not include iva2_clk; that will be part of a separate hwmod, which will be controlled by iommu. I think Kevin already sent a hwmod for IVA2... one week ago: [PATCH 13/13] OMAP3:

RE: [RFC][PATCH 3/8] OMAP: DSS2: Modify dss_recheck_connections

2010-07-01 Thread Taneja, Archit
Hi, > On Thu, 2010-07-01 at 14:28 +0200, ext Taneja, Archit wrote: > > > On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote: > > > > From: Sumit Semwal > > > > > > > > The addition of the new 2lcd manager requires > modifications in the > > > > dss_recheck_connections patch, this funct

Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6

2010-07-01 Thread Nicolas Pitre
On Thu, 1 Jul 2010, Jamie Lokier wrote: > Tony Lindgren wrote: > > +static void __init kuser_get_tls_init(unsigned long vectors) > > +{ > > + /* > > +* vectors + 0xfe0 = __kuser_get_tls > > +* vectors + 0xfe8 = hardware TLS instruction at 0x0fe8 > > +*/ > > + if (tls_emu || has

RE: [PATCH 8/9] dspbridge: add map support for big buffers

2010-07-01 Thread Kanigeri, Hari
Fernando, > - for_each_sg(sgt->sgl, sg, sgt->nents, i) > - sg_set_page(sg, usr_pgs[i], PAGE_SIZE, 0); > + da = iommu_vmap(mmu, da, sgt, IOVMF_ENDIAN_LITTLE | > + IOVMF_ELSZ_32); -- iommu_vmap does the Kernel mapping t

Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

2010-07-01 Thread Andi Kleen
> The VCMM provides a more abstract, global view with finer-grained > control of each mapping a user wants to create. For instance, the > symantics of iommu_map preclude its use in setting up just the IOMMU > side of a mapping. With a one-sided map, two IOMMU devices can be Hmm? dma_map_* does not

Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

2010-07-01 Thread Hari Kanigeri
> 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 Linu

[RFC 6/6] omap: enable remoteproc building

2010-07-01 Thread Ohad Ben-Cohen
From: Ohad Ben-Cohen Make it possible to build omap's remoteproc module Signed-off-by: Ohad Ben-Cohen Signed-off-by: Hari Kanigeri --- arch/arm/mach-omap2/Makefile |6 ++ arch/arm/plat-omap/Kconfig |7 +++ arch/arm/plat-omap/Makefile |1 + 3 files changed, 14 insertions

[RFC 5/6] omap: add remoteproc device(s)

2010-07-01 Thread Ohad Ben-Cohen
From: Ohad Ben-Cohen Add an omap_device for each remote processor on the system Signed-off-by: Ohad Ben-Cohen Signed-off-by: Hari Kanigeri --- arch/arm/mach-omap2/devices.c | 86 + 1 files changed, 86 insertions(+), 0 deletions(-) diff --git a/arch/a

[RFC 4/6] omap: introduce common remoteproc module

2010-07-01 Thread Ohad Ben-Cohen
From: Ohad Ben-Cohen The OMAP remote processor module decouples machine-specific code from TI's IPC drivers (e.g. dspbridge and syslink). While dspbridge calls the remoteproc handlers from the kernel, syslink calls them from user space. Hence remoteproc supports both interfaces. Signed-off-by:

[RFC 3/6] omap: introduce OMAP4 remoteproc module

2010-07-01 Thread Ohad Ben-Cohen
From: Hari Kanigeri Introduce OMAP4 machine-dependent module required for starting and stopping the OMAP3 remote processors. Signed-off-by: Hari Kanigeri Signed-off-by: Ohad Ben-Cohen --- arch/arm/mach-omap2/remoteproc44xx.c | 196 ++ 1 files changed, 196 inse

[RFC 2/6] omap: introduce OMAP3 remoteproc module

2010-07-01 Thread Ohad Ben-Cohen
From: Ohad Ben-Cohen Introduce OMAP3 remoteproc module which takes care of machine-specific code required to start and stop the DSP remote processor. Signed-off-by: Ohad Ben-Cohen Signed-off-by: Hari Kanigeri --- arch/arm/mach-omap2/remoteproc3xxx.c | 226 ++

[RFC 1/6] omap: add iva2 hwmod support to omap3

2010-07-01 Thread Ohad Ben-Cohen
From: Ohad Ben-Cohen Add preliminary iva2 hwmod support to omap3. We do not include iva2_clk; that will be part of a separate hwmod, which will be controlled by iommu. Signed-off-by: Ohad Ben-Cohen Signed-off-by: Hari Kanigeri --- arch/arm/mach-omap2/omap_hwmod_34xx.h| 23 ++

[RFC 0/6] Introducing OMAP Remote Processor module

2010-07-01 Thread Ohad Ben-Cohen
From: Ohad Ben-Cohen This is a preliminary version of OMAP's remoteproc module, submitted for RFC purposes. The purpose of the remoteproc module is to decouple hw-specific code from generic IPC drivers (such as dspbridge and syslink), in order to eventually make those IPC drivers platform-indepe

Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

2010-07-01 Thread Hari Kanigeri
> > 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? -- So is this patch set adding layers and abstractions to help the User ? If the idea is to share s

Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

2010-07-01 Thread Daniel Walker
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

Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

2010-07-01 Thread Zach Pfeffer
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

Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

2010-07-01 Thread Randy Dunlap
On 07/01/10 13:59, Paul Walmsley wrote: > Randy, > > On Thu, 1 Jul 2010, Randy Dunlap wrote: > >>> + * @start_addr The starting address of the VCM region. >>> + * @lenThe len of the VCM region. This must be at least >>> + * vcm_min() bytes. >> >> and missing lots of struct members

Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

2010-07-01 Thread Paul Walmsley
Randy, On Thu, 1 Jul 2010, Randy Dunlap wrote: > > + * @start_addr The starting address of the VCM region. > > + * @lenThe len of the VCM region. This must be at least > > + * vcm_min() bytes. > > and missing lots of struct members here. > If some of them are private, you can use

RE: [PATCH 0/2] pandora updates for .36

2010-07-01 Thread Gadiyar, Anand
Grazvydas Ignotas wrote: > > Hi Tony, > > here are some updates for Pandora, which we have now around 700 units > shipped (finally!) after years of developemt hell. More are being > made at the moment. > Neat! Hope you sell a zillion. I'll try and buy one someday. - Anand -- To unsubscribe fro

Re: [PATCH 0/2] pandora updates for .36

2010-07-01 Thread Paul Walmsley
On Thu, 1 Jul 2010, Grazvydas Ignotas wrote: > here are some updates for Pandora, which we have now around 700 units > shipped (finally!) after years of developemt hell. More are being > made at the moment. Woohoo! Congratulations to you and the rest of the team :-) - Paul -- To unsubscribe fr

[PATCH 2/2] omap3: pandora: add NAND and wifi support

2010-07-01 Thread Grazvydas Ignotas
Add platform data for NAND and wifi, also setup all GPIOs needed to use the wifi chip. Signed-off-by: Grazvydas Ignotas --- arch/arm/mach-omap2/board-omap3pandora.c | 121 ++ 1 files changed, 121 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-o

[PATCH 1/2] omap3: pandora: update gpio-keys data

2010-07-01 Thread Grazvydas Ignotas
Update gpio-keys setup so it matches what is on default firmware. Also make use of debounce feature in gpio-keys instead of setting it explicitly, as gpio-keys is now capable of using hardware debounce on OMAPs thanks to recent gpiolib changes. Also fix a sparce warning along the way. Signed-off-b

[PATCH 0/2] pandora updates for .36

2010-07-01 Thread Grazvydas Ignotas
Hi Tony, here are some updates for Pandora, which we have now around 700 units shipped (finally!) after years of developemt hell. More are being made at the moment. Patch 2/2 has incorporated my last patch that missed the last merge window, and depends on "pass wl1251 information to SDIO core" [1

Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

2010-07-01 Thread Daniel Walker
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 f

Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

2010-07-01 Thread Andi Kleen
On Thu, Jul 01, 2010 at 12:28:23PM -0700, Daniel Walker wrote: > 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 acce

Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

2010-07-01 Thread Daniel Walker
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.

RE: [PATCH V4 0/2] OMAP3: Dynamic Calculation of SDRC stall latency during DVFS

2010-07-01 Thread Paul Walmsley
Pramod, Teerth, On Mon, 7 Jun 2010, Gurav , Pramod wrote: > Can you please push these patches if you don't you are OK with them? As we discussed in Bangalore, these patches need some changes: 1. The delay needs to be precisely characterized in terms of what the hardware actually needs. It sho

RE: [PATCHv3 5/9] dspbridge: add mmufault support

2010-07-01 Thread Guzman Lugo, Fernando
> -Original Message- > From: Kanigeri, Hari > Sent: Thursday, July 01, 2010 1:04 PM > To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc: o...@wizery.com; Hiroshi DOYU; ameya.pala...@nokia.com; > felipe.contre...@nokia.com > Subject: RE: [PATCHv3 5

RE: [PATCHv3 5/9] dspbridge: add mmufault support

2010-07-01 Thread Kanigeri, Hari
> > > + da = iommu_read_reg(mmu, MMU_FAULT_AD); > > > + iommu_write_reg(mmu, 0, MMU_IRQENABLE); > > > > -- Isn't the MMU already enabled at this point when the function > callback > > is called by iommu ? > > This line is actually disabling the interrupts. I am writing "0x0" in the > MMU_IRQENABLE

Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

2010-07-01 Thread Andi Kleen
> 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. Also for me it's still quite unclear why we would want this c

RE: [PATCHv3 5/9] dspbridge: add mmufault support

2010-07-01 Thread Guzman Lugo, Fernando
Hi Hari, > -Original Message- > From: Kanigeri, Hari > Sent: Thursday, July 01, 2010 12:17 PM > To: Guzman Lugo, Fernando; linux-omap@vger.kernel.org; linux- > ker...@vger.kernel.org > Cc: o...@wizery.com; hiroshi.d...@nokia.com; ameya.pala...@nokia.com; > felipe.contre...@nokia.com; Guz

Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6

2010-07-01 Thread Jamie Lokier
Tony Lindgren wrote: > +static void __init kuser_get_tls_init(unsigned long vectors) > +{ > + /* > + * vectors + 0xfe0 = __kuser_get_tls > + * vectors + 0xfe8 = hardware TLS instruction at 0x0fe8 > + */ > + if (tls_emu || has_tls) > + memcpy((void *)vectors +

Re: [RFC 3/3] mm: iommu: The Virtual Contiguous Memory Manager

2010-07-01 Thread Randy Dunlap
On Tue, 29 Jun 2010 22:55:50 -0700 Zach Pfeffer wrote: > arch/arm/mm/vcm.c | 1901 > + > include/linux/vcm.h | 701 + > include/linux/vcm_types.h | 318 > 3 files changed, 2920 insertions(+), 0 deletions(-) > c

RE: [PATCHv3 5/9] dspbridge: add mmufault support

2010-07-01 Thread Kanigeri, Hari
Hi Fernando, > +int mmu_fault_isr(struct iommu *mmu) > > -/* > - * mmu_check_if_fault === > - * Check to see if MMU Fault is valid TLB miss from DSP > - * Note: This function is called from an ISR > - */ > -static bool mmu_check_if_fault(struct bridge_dev_context *dev_context)

Re: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk

2010-07-01 Thread Paul Walmsley
On Thu, 1 Jul 2010, Tony Lindgren wrote: > * Paul Walmsley [100624 09:22]: > > Hi Tony, > > > > what do you think on this one? -rc or .36? > > If we want to try to get it into the -rc cycle, the description > should mention what it fixes and show the error. Otherwise it might > be hard to argu

Re: [RFC][PATCH 4/8] OMAP: DSS2: OMAP4 Secondary LCD Channel DISPC Registers

2010-07-01 Thread Paul Walmsley
On Thu, 1 Jul 2010, Archit Taneja wrote: > From: Semwal, Sumit > > Introduce OMAP4 DISPC base address and Secondary LCD Channel registers, use > them > in register dumps. > > Signed-off-by: Sumit Semwal > Signed-off-by: Senthilvadivu Guruswamy > Signed-off-by: Mukund Mittal > Signed-off-by:

Re: [PATCH 03/33] Removing dead OMAP_MUX_ERRORS

2010-07-01 Thread Kirill A. Shutemov
On Thu, Jul 01, 2010 at 03:22:55PM +0200, Christoph Egger wrote: > On Wed, Jun 30, 2010 at 10:54:09PM +0300, Kirill A. Shutemov wrote: > > On Wed, Jun 30, 2010 at 05:54:42PM +0200, Christoph Egger wrote: > > > OMAP_MUX_ERRORS doesn't exist in Kconfig, therefore removing all > > > references for it

Re: [PATCH] OMAP:DSS2:OMAPFB: Fix probe error path

2010-07-01 Thread Tomi Valkeinen
On Thu, 2010-07-01 at 15:40 +0200, ext Afzal Mohammed wrote: > Move sysfs entry creation to omapfb_probe() from omapfb_create_framebuffers(). > This will make sure that sysfs entry is not left behind in case of > unsuccessful > probe due to failure in enabling fb0 of omapfb_create_framebuffers().

[PATCH] OMAP:DSS2:OMAPFB: Fix probe error path

2010-07-01 Thread Afzal Mohammed
Hi Tomi, Is this change ok instead of having sysfs entry removal in omapfb_free_resources() ? Hope this change makes probe look more of a remove mirror. Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org Mo

[PATCH] OMAP:DSS2:OMAPFB: Fix probe error path

2010-07-01 Thread Afzal Mohammed
Move sysfs entry creation to omapfb_probe() from omapfb_create_framebuffers(). This will make sure that sysfs entry is not left behind in case of unsuccessful probe due to failure in enabling fb0 of omapfb_create_framebuffers(). Signed-off-by: Afzal Mohammed --- drivers/video/omap2/omapfb/omapfb

Re: [PATCH 03/33] Removing dead OMAP_MUX_ERRORS

2010-07-01 Thread Christoph Egger
On Wed, Jun 30, 2010 at 10:54:09PM +0300, Kirill A. Shutemov wrote: > On Wed, Jun 30, 2010 at 05:54:42PM +0200, Christoph Egger wrote: > > OMAP_MUX_ERRORS doesn't exist in Kconfig, therefore removing all > > references for it from the source code. > > IIUC, CONFIG_OMAP_MUX_WARNINGS should be used

RE: [RFC][PATCH 3/8] OMAP: DSS2: Modify dss_recheck_connections

2010-07-01 Thread Tomi Valkeinen
On Thu, 2010-07-01 at 14:28 +0200, ext Taneja, Archit wrote: > > On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote: > > > From: Sumit Semwal > > > > > > The addition of the new 2lcd manager requires modifications in the > > > dss_recheck_connections patch, this function behaves the > >

[RFC] [PATCH] Board changes for tmp105 temperature sensor

2010-07-01 Thread Datta, Shubhrajyoti
Adding board configuration for the tmp105 temperature sensor. The interface to the sensor is I2C. -Removing unwanted file mode change Signed-off-by: Shubhrajyoti D --- arch/arm/mach-omap2/board-4430sdp.c |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/arch/arm/mac

Re: [PATCH 2/2] arm: Make VFPv3 usable on ARMv6

2010-07-01 Thread Tony Lindgren
* Catalin Marinas [100625 16:44]: > On Wed, 2010-06-23 at 08:57 +0100, Tony Lindgren wrote: > > MVFR0 and MVFR1 are only available starting with ARM1136 r1p0 release > > according to "B.5 VFP changes" in DDI0211F_arm1136_r1p0_trm.pdf. This is > > also when TLS register got added, so we can use HAS

Re: [PATCH v5 2/2] OMAP4 HSMMC: Adding card detect support for MMC1 Controller

2010-07-01 Thread Tony Lindgren
* Andrew Morton [100617 23:09]: > On Thu, 17 Jun 2010 20:57:19 +0530 (IST) > "kishore kadiyala" wrote: > > > Adding card detect callback function which gives the status of > > the card .For MMC1 Controller, Card detect interrupt source is > > twl6030 and card present/absent status is provided by

RE: [RFC] [PATCH] Board changes for tmp105 temperature sensor

2010-07-01 Thread Datta, Shubhrajyoti
Hi Tony, > -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Thursday, July 01, 2010 5:47 PM > To: Datta, Shubhrajyoti > Cc: linux-omap@vger.kernel.org; LM Sensors > Subject: Re: [RFC] [PATCH] Board changes for tmp105 temperature sensor > > * Datta, Shubhrajyoti

Re: [PATCH v5 1/2] OMAP HSMMC: Adding a Flag to determine the type of Card detect

2010-07-01 Thread Tony Lindgren
* kishore kadiyala [100621 09:49]: > On Fri, Jun 18, 2010 at 1:49 AM, Andrew Morton > wrote: > > On Thu, 17 Jun 2010 20:56:58 +0530 (IST) > > "kishore kadiyala" wrote: > > > >> --- a/arch/arm/plat-omap/include/plat/mmc.h > >> +++ b/arch/arm/plat-omap/include/plat/mmc.h > >> @@ -43,6 +43,9 @@ > >

RE: [RFC][PATCH 3/8] OMAP: DSS2: Modify dss_recheck_connections

2010-07-01 Thread Taneja, Archit
> On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote: > > From: Sumit Semwal > > > > The addition of the new 2lcd manager requires modifications in the > > dss_recheck_connections patch, this function behaves the > same if the > > 2lcd manager doesn't exist > > Here (and also in the

Re: [PATCH] Enable lm75 and hwmon in OMAP4

2010-07-01 Thread Tony Lindgren
* Datta, Shubhrajyoti [100617 09:14]: > Enabling hwmon and lm75 in the omap4 defconfig > > Signed-off-by: Shubhrajyoti D > --- > arch/arm/configs/omap_4430sdp_defconfig |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > mode change 100644 => 100755 arch/arm/configs/omap_4430sdp_d

Re: [PATCH 2/2] OMAP4: Add support for PWM LED

2010-07-01 Thread Tony Lindgren
* Hemanth V [100701 15:11]: > - Original Message - From: "Tony Lindgren" > > To: "Hemanth V" > Cc: > Sent: Thursday, July 01, 2010 4:07 PM > Subject: Re: [PATCH 2/2] OMAP4: Add support for PWM LED > > > >* Hemanth V [100630 17:12]: > >>From 713727188b99465341767eedaa42004862261211 Mo

Re: [PATCH 2/2] OMAP4: Add support for PWM LED

2010-07-01 Thread Hemanth V
- Original Message - From: "Tony Lindgren" To: "Hemanth V" Cc: Sent: Thursday, July 01, 2010 4:07 PM Subject: Re: [PATCH 2/2] OMAP4: Add support for PWM LED * Hemanth V [100630 17:12]: From 713727188b99465341767eedaa42004862261211 Mon Sep 17 00:00:00 2001 From: Hemanth V Date: We

Re: [RFC] [PATCH] Board changes for tmp105 temperature sensor

2010-07-01 Thread Tony Lindgren
* Datta, Shubhrajyoti [100615 17:40]: > Adding board configuration for the tmp105 > temperature sensor. The interface to the sensor > is I2C. > > Signed-off-by: Shubhrajyoti D > --- > arch/arm/mach-omap2/board-4430sdp.c |8 +++- > 1 files changed, 7 insertions(+), 1 deletions(-) > mode

Re: [PATCH] omap: mux: Add api to retrieve padconf offset based on muxname

2010-07-01 Thread Tony Lindgren
* Govindraj.R [100614 17:07]: > Adds a padconf offset retrieval api which will > get us the padconf offset based on muxname provided > which can be later used with omap_ctrl_writew, > omap_ctrl_readw calls for remuxing signals. > > Cc: Tony Lindgren > Signed-off-by: Govindraj.R > --- > Patch is

FW: [RFC][PATCH 4/8] OMAP: DSS2: OMAP4 Secondary LCD Channel DISPC Registers

2010-07-01 Thread Taneja, Archit
Hi, > On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote: > > From: Semwal, Sumit > > > > Introduce OMAP4 DISPC base address and Secondary LCD Channel > > registers, use them in register dumps. > > #define DISPC_DIVISOR DISPC_REG(0x0070) > > +#define DISPC_DIVI

RE: [PATCH] [RFC][PATCH 2/8] OMAP: DSS2: Add new Overlay Manager

2010-07-01 Thread Taneja, Archit
> On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote: > > From: Sumit Semwal > > > > Add new Overlay Manager in manager.c, make secondary > channel changes > > and update supported displays for the managers in OMAP4 > > > > @@ -1471,15 +1471,25 @@ int > dss_init_overlay_managers(

Re: [PATCH] [RFC][PATCH 2/8] OMAP: DSS2: Add new Overlay Manager

2010-07-01 Thread Tomi Valkeinen
On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote: > From: Sumit Semwal > > Add new Overlay Manager in manager.c, make secondary channel changes > and update supported displays for the managers in OMAP4 > > Signed-off-by: Sumit Semwal > Signed-off-by: Senthilvadivu Guruswamy > Signed-

Re: [RFC][PATCH 3/8] OMAP: DSS2: Modify dss_recheck_connections

2010-07-01 Thread Tomi Valkeinen
On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote: > From: Sumit Semwal > > The addition of the new 2lcd manager requires modifications in the > dss_recheck_connections patch, this function behaves the same if > the 2lcd manager doesn't exist Here (and also in the previous patch) you ta

Re: [RFC][PATCH 4/8] OMAP: DSS2: OMAP4 Secondary LCD Channel DISPC Registers

2010-07-01 Thread Tomi Valkeinen
On Thu, 2010-07-01 at 12:31 +0200, ext Archit Taneja wrote: > From: Semwal, Sumit > > Introduce OMAP4 DISPC base address and Secondary LCD Channel registers, use > them > in register dumps. > > Signed-off-by: Sumit Semwal > Signed-off-by: Senthilvadivu Guruswamy > Signed-off-by: Mukund Mittal

Re: [PATCH] OMAP3: wait on IDLEST after enabling USBTLL fclk

2010-07-01 Thread Tony Lindgren
* Paul Walmsley [100624 09:22]: > Hi Tony, > > what do you think on this one? -rc or .36? If we want to try to get it into the -rc cycle, the description should mention what it fixes and show the error. Otherwise it might be hard to argue this is a real fix or a regression. Regards, Tony >

[PATCH v2 4/4] omap: nand: making ecc layout as compatible with romcode ecc

2010-07-01 Thread Sukumar Ghorai
This patch overrides nand ecc layout and bad block descriptor (for 8-bit device) to support hw ecc in romcode layout. So as to have in sync with ecc layout throughout; i.e. x-laod, u-boot and kernel. This patch also enables to use romcode ecc for spd and zoom, by default. This

[PATCH v2 1/4] omap3: nand: prefetch in irq mode support

2010-07-01 Thread Sukumar Ghorai
This patch enable prefetch-irq mode for NAND. Signed-off-by: Vimal Singh Signed-off-by: Sukumar Ghorai --- arch/arm/mach-omap2/board-flash.c |1 + arch/arm/mach-omap2/gpmc.c |7 + arch/arm/mach-omap2/include/mach/board-flash.h |3 + arch/arm/plat-oma

[PATCH v2 2/4] omap3: nand: configurable fifo threshold to gain the throughput

2010-07-01 Thread Sukumar Ghorai
Configure the FIFO THREASHOLD value different for read and write to keep busy both filling and to drain out of FIFO at reading and writing. Signed-off-by: Sukumar Ghorai Signed-off-by: Vimal Singh --- arch/arm/mach-omap2/gpmc.c | 11 +++ arch/arm/plat-omap/include/pla

[PATCH v2 3/4] omap: nand: ecc layout select from board file

2010-07-01 Thread Sukumar Ghorai
This patch makes it possible to select sw or hw (different layout options) ecc scheme supported by omap nand driver. And hw ecc layout selected for sdp and zoom boards, by default. Signed-off-by: Sukumar Ghorai Signed-off-by: Vimal Singh --- arch/arm/mach-omap2/board-flash.c |

[PATCH v2 0/4] nand prefetch-irq support and ecc layout chanage

2010-07-01 Thread Sukumar Ghorai
The following set of patches applies on top of for-next branch. And is dependent on the following patches not yet applied onto this branch. 1. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg30305.html 2. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg3073

Re: [PATCH 13/16] omap: mux: Mux Apollon LCD power in board-apollon.c

2010-07-01 Thread Kyungmin Park
On Thu, Jul 1, 2010 at 7:33 PM, Tony Lindgren wrote: > * Kyungmin Park [100701 11:12]: >> Hi, >> >> This value is set from bootloader, and kernel side only change the mode. >> Right it runs by luck. > > So should we just drop the omap_cfg_reg for now, then add it back > later with proper gpio_req

Re: [PATCH 2/2] OMAP4: Add support for PWM LED

2010-07-01 Thread Tony Lindgren
* Hemanth V [100630 17:12]: > From 713727188b99465341767eedaa42004862261211 Mon Sep 17 00:00:00 2001 > From: Hemanth V > Date: Wed, 30 Jun 2010 18:16:33 +0530 > Subject: [PATCH] OMAP4: Add support for PWM LED > > TWL6030 supports PWM (Pulse Width Modulator) which is used > to control charging LE

RE: [PATCH 6/6] omap2/3/4: Add Kconfig option to compile in typical omap features

2010-07-01 Thread Shilimkar, Santosh
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Wednesday, June 30, 2010 12:55 PM > To: Shilimkar, Santosh > Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org > Subject: Re: [PATCH 6/6] omap2/3/4: Add Kconfig option to compile in > typical om

Re: [PATCH 13/16] omap: mux: Mux Apollon LCD power in board-apollon.c

2010-07-01 Thread Tony Lindgren
* Kyungmin Park [100701 11:12]: > Hi, > > This value is set from bootloader, and kernel side only change the mode. > Right it runs by luck. So should we just drop the omap_cfg_reg for now, then add it back later with proper gpio_request etc? Tony -- To unsubscribe from this list: send the line

[PATCH] [PATCH] [RFC][PATCH 8/8] OMAP: DSS2: Interface driver changes for Secondary LCD Channel

2010-07-01 Thread Archit Taneja
From: Sumit Semwal Make necessary changes in the interface drivers for the dispc functions which have the new enum channel added to them Signed-off-by: Sumit Semwal Signed-off-by: Senthilvadivu Guruswamy Signed-off-by: Mukund Mittal Signed-off-by: Archit Taneja Signed-off-by: Samreen --- d

[RFC][PATCH 7/8] OMAP: DSS2: Context Save and Restore of DISPC registers for Secondary LCD

2010-07-01 Thread Archit Taneja
From: Mayuresh Janorkar Context Save and Restore of DISPC registers for Secondary LCD Signed-off-by: Sumit Semwal Signed-off-by: Senthilvadivu Guruswamy Signed-off-by: Mukund Mittal Signed-off-by: Archit Taneja Signed-off-by: Samreen --- drivers/video/omap2/dss/dispc.c | 48 +

[PATCH] [RFC][PATCH 6/8] OMAP: DSS2: Secondary LCD Channel DISPC IRQs

2010-07-01 Thread Archit Taneja
From: Sumit Semwal Introduce Secondary Channel IRQS for dumps and error handling Signed-off-by: Sumit Semwal Signed-off-by: Senthilvadivu Guruswamy Signed-off-by: Mukund Mittal Signed-off-by: Archit Taneja Signed-off-by: Samreen --- arch/arm/plat-omap/include/plat/display.h |4 ++ driv

[RFC][PATCH 5/8] OMAP: DSS2: Secondary LCD Channel in DISPC functions

2010-07-01 Thread Archit Taneja
From: Sumit Semwal Introduce the new enum channel as a parameter in all dispc functions used by interface drivers(dsi, sdi etc) in order to differentiate between the 2 channels Signed-off-by: Sumit Semwal Signed-off-by: Senthilvadivu Guruswamy Signed-off-by: Mukund Mittal Signed-off-by: Archi

[RFC][PATCH 4/8] OMAP: DSS2: OMAP4 Secondary LCD Channel DISPC Registers

2010-07-01 Thread Archit Taneja
From: Semwal, Sumit Introduce OMAP4 DISPC base address and Secondary LCD Channel registers, use them in register dumps. Signed-off-by: Sumit Semwal Signed-off-by: Senthilvadivu Guruswamy Signed-off-by: Mukund Mittal Signed-off-by: Archit Taneja Signed-off-by: Samreen --- drivers/video/omap

[RFC][PATCH 3/8] OMAP: DSS2: Modify dss_recheck_connections

2010-07-01 Thread Archit Taneja
From: Sumit Semwal The addition of the new 2lcd manager requires modifications in the dss_recheck_connections patch, this function behaves the same if the 2lcd manager doesn't exist Signed-off-by: Sumit Semwal Signed-off-by: Senthilvadivu Guruswamy Signed-off-by: Mukund Mittal Signed-off-by:

[PATCH] [RFC][PATCH 2/8] OMAP: DSS2: Add new Overlay Manager

2010-07-01 Thread Archit Taneja
From: Sumit Semwal Add new Overlay Manager in manager.c, make secondary channel changes and update supported displays for the managers in OMAP4 Signed-off-by: Sumit Semwal Signed-off-by: Senthilvadivu Guruswamy Signed-off-by: Mukund Mittal Signed-off-by: Archit Taneja Signed-off-by: Samreen

[RFC][PATCH 1/8] OMAP: DSS2: Overlay Manager LCD2 changes in dispay.h

2010-07-01 Thread Archit Taneja
From: Sumit Semwal Overlay Manager LCD2 changes in dispay.h Signed-off-by: Sumit Semwal Signed-off-by: Senthilvadivu Guruswamy Signed-off-by: Mukund Mittal Signed-off-by: Archit Taneja Signed-off-by: Samreen --- arch/arm/plat-omap/include/plat/display.h |3 +++ 1 files changed, 3 inser

[RFC][PATCH 0/8] OMAP: DSS2: Overlay Manager LCD2 support in DISPC

2010-07-01 Thread Archit Taneja
From: Semwal, Sumit This patch series incorporates changes in DSS2 to enable omap_dss_device instances to use the new Overlay Manager LCD2 in DISPC. On OMAP4, we have a new DISPC channel for Overlay Manager LCD2. This channel's video port is a source port for RFBI, DSI2 and DPI. The Primary chan

[PATCH v7 7/8] omap3: pm: Use generic TRITON power scripts for 3430SDP board

2010-07-01 Thread Lesly A M
This patch has the changes to remove the sleep/wakeup/warm_rest sequence & resource configuration from the 3430SDP board file and use the generic script. Updating the sleep/wakeup/warm_rest sequence & resource configuration in the board file from generic script file. Signed-off-by: Lesly A M Cc:

[PATCH v7 8/8] omap3: pm: Use generic TRITON power scripts for ZOOM[2,3], 3630SDP board

2010-07-01 Thread Lesly A M
Adding the power script data for zoom board to TWL4030 platform data. Updating the sleep/wakeup/warm_reset sequence & resource configuration from generic script file. Signed-off-by: Lesly A M Cc: Nishanth Menon Cc: David Derrick Cc: Samuel Ortiz --- arch/arm/mach-omap2/Makefile

[PATCH v7 6/8] omap3: pm: Generic TRITON power scripts for OMAP3 based boards

2010-07-01 Thread Lesly A M
This patch will create the generic TRITON power scripts which can be used by different OMAP3 boards with the same power companion chip (TWL4030 series). Added the api(twl4030_get_scripts/twl4030_get_vc_timings) to update the sleep/wakeup/warm_reset sequence, resource configuration & voltsetup_time

[PATCH v7 4/8] omap3: pm: re-programing the setup time based on CORE_DOMAIN target state

2010-07-01 Thread Lesly A M
This patch will add a new function omap_voltage_vc_update() to re-program the VC parameters while entering low power mode, based on CORE_DOMAIN target state. The voltsetup2 is used only when the device exits sys_off mode (with PRM_VOLTCTRL[3]SEL_OFF set to 1). Also removed the clearing of PRM_VOL

[PATCH v7 5/8] omap3: pm: changing vdd0_/vdd1_ to vdd1_/vdd2_ in VC param structure

2010-07-01 Thread Lesly A M
Renaming vdd0_/vdd1_ to vdd1_/vdd2_ in VC param structure, since there is no VDD0. It's VDD1 voltage domain with processor voltage & VDD2 voltage domain with CORE voltage. VDD1 voltage specific values are stored in PRM_VC_CMD_VAL_0 register & VDD2 voltage specific values are stored in PRM_VC_CMD_V

[PATCH v7 3/8] omap3: pm: Using separate clk/volt setup_time for RET and OFF states

2010-07-01 Thread Lesly A M
This patch has the changes to use separate clk/volt setup_time for RET and OFF state. Because the clocksetup voltsetup time1 used for RET & OFF is different. Create separate copies of VC parameters for each Si in voltage.c. Since the voltage vales for each state is different in different OMAP Si.

[PATCH v7 2/8] omap3: pm: correct the warning print during script loading

2010-07-01 Thread Lesly A M
Correcting the if condition check for printing the warning, if wakeup script is not updated before updating the sleep script. Since the flag 'order' is set to '1' while updating the wakeup script for P1P2, the condition checking for printing the warning should be if(!order) (ie: print the warning

[PATCH v7 1/8] omap3: pm: fix for twl4030 script load

2010-07-01 Thread Lesly A M
This patch will fix the TRITON sleep/wakeup sequence. Since the function to populate the sleep script is getting called always irrespective of the flag "TWL4030_SLEEP_SCRIPT", other scripts data is getting over written by the sleep script. Signed-off-by: Lesly A M Cc: Nishanth Menon Cc: David D

[PATCH v7 0/8] omap3: pm: Update TRITON power scripts and making it generic

2010-07-01 Thread Lesly A M
T2 script changes rebased on top of Thara's SmartReflex patches. This series of patch implements a updated TRITON power scripts. Also moving the sleep, wakeup & warm_reset sequence to a generic script file, which can be used by different OMAP3 board with the power companion chip TWL4030. This pa

Re: [PATCH] OMAP:DSS2:OMAPFB: Fix probe error path

2010-07-01 Thread Tomi Valkeinen
Hi, On Wed, 2010-06-30 at 16:15 +0200, ext Afzal Mohammed wrote: > If enabling fb0 fails in omapfb_create_framebuffers(), remove > sysfs file before returning to probe. This is required to complete > the cleanup in the above mentioned error case. omapfb frees the resources in omapfb_free_resource

Re: [PATCH 1/2] arm: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for it on V6

2010-07-01 Thread Tony Lindgren
* Nicolas Pitre [100630 17:36]: > On Wed, 30 Jun 2010, Tony Lindgren wrote: > > > * Tony Lindgren [100630 14:02]: > > > * Nicolas Pitre [100629 22:14]: > > > > > > Updated patch below. > > > > And a bug crept in.. > > > > > + .macro set_tls_v6, tp, tmp1, tmp2 > > > + ldr \tmp1, =elf_hwca

RE: [PATCH 13/16] omap: mux: Mux Apollon LCD power in board-apollon.c

2010-07-01 Thread Kyungmin Park
Hi, This value is set from bootloader, and kernel side only change the mode. Right it runs by luck. Thank you, Kyungmin Park > -Original Message- > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > Sent: Thursday, July 01, 2010 4:06 PM > To: ext Tony Lindgren > Cc: linux-arm-ker..

[RFC 1v2/3] mm: iommu: An API to unify IOMMU, CPU and device memory management

2010-07-01 Thread Zach Pfeffer
This patch contains the documentation for the API, termed the Virtual Contiguous Memory Manager. Its use would allow all of the IOMMU to VM, VM to device and device to IOMMU interoperation code to be refactored into platform independent code. Comments, suggestions and criticisms are welcome and wa

Re: [PATCH 20/33] Removing dead MACH_OMAP2_H4_USB1

2010-07-01 Thread Felipe Balbi
On Wed, Jun 30, 2010 at 06:00:23PM +0200, ext Christoph Egger wrote: MACH_OMAP2_H4_USB1 doesn't exist in Kconfig, therefore removing all references for it from the source code. Signed-off-by: Christoph Egger Does this apply on top of Tony's recent patches ?? -- balbi DefectiveByDesign.org -

Re: [RFC 1/3] mm: iommu: An API to unify IOMMU, CPU and device memory management

2010-07-01 Thread Zach Pfeffer
Thank you for the corrections. I'm correcting them now. Some responses: Randy Dunlap wrote: >> +struct vcm *vcm_create(size_t start_addr, size_t len); > > Seems odd to use size_t for start_addr. I used size_t because I wanted to allow the start_addr the same range as len. Is there a better t

  1   2   >