Re: [PATCH] Fix IGEPv2 second MMC channel power supply

On Mon, 15 Nov 2010 09:32:22 +0100 Enric Balletbò i Serra eballe...@gmail.com wrote: Hi Enric, So the DUMMY_REGULATOR is only a workaround when a regulator is not defined and shouldn't be used ? Sorry if this is a stupid question but regulator interface is not too clear for me. My

[PATCHv2]OMAP PM:MPU/DMA Latency constraints

The previous implementation of OMAP interrupt/DMA latency constraints were implemented using SRF which is obsolete now. This patch has implemented the same using PM QOS infeastructure. As part of this, API signature has been changed to take pm qos handle instead of dev pointer since PM QOS

[PATCH 0/8] OMAP2+: hwmod core upgrades for 2.6.38: first set

This patch series contains upgrades for the OMAP2+ hwmod core code, intended for 2.6.38. Most of these patches were developed in response to use-cases discovered while converting device drivers to use the hwmod code. Tested on an OMAP34xx BeagleBoard with omap2plus_defconfig. - Paul ---

[PATCH 1/8] OMAP2+: io: split omap2_init_common_hw()

Split omap2_init_common_hw() into two functions. The first, omap2_init_common_infrastructure(), initializes the hwmod code and data, the OMAP PM code, and the clock code and data. The second, omap2_init_common_devices(), handles any other early device initialization that, for whatever reason,

[PATCH 3/8] OMAP2+: hwmod: add postsetup state

Allow board files and OMAP core code to control the state that some or all of the hwmods end up in at the end of _setup() (called by omap_hwmod_late_init() ). Reimplement the old skip_setup_idle code in terms of this new postsetup state code. There are two use-cases for this patch: the

[PATCH 8/8] OMAP2+: hwmod: Update the sysc_cache in case module context is lost

From: Rajendra Nayak rna...@ti.com Do not skip the sysc programming in the hmwod framework based on the cached value alone, since at times the module might have lost context (due to the Powerdomain in which the module belongs transitions to either Open Switch RET or OFF). Identifying if a module

[PATCH 6/8] OMAP2+: hwmod: upgrade per-hwmod mutex to a spinlock

Change the per-hwmod mutex to a spinlock. (The per-hwmod lock serializes most post-initialization hwmod operations such as enable, idle, and shutdown.) Spinlocks are needed, because in some cases, hwmods must be enabled from timer interrupt disabled-context, such as an ISR. The current use-case

[PATCH 4/8] OMAP2+: hwmod: add support for per-class custom device reset functions

The standard omap_hwmod.c _reset() code relies on an IP block's OCP_SYSCONFIG.SOFTRESET register bit to reset the IP block. This works for most IP blocks on the chip, but unfortunately not all. For example, initiator-only IP blocks often don't have any MPU-accessible OCP-header registers, and

[PATCH 7/8] OMAP2+: hwmod: fix a warning, add some docs, remove unused fields

Trivial cleanup and documentation changes on the hwmod code and data: - resolve the OMAP2430 hwmod data i2c_dev_attr warning - add some hwmod documentation to indicate flags that should be moved outside the static hwmod data in a future patch - remove some unused fields in the struct

[PATCH 5/8] OMAP2+: hwmod: rename omap_hwmod_mutex to _hwmod_list_mutex

This trivial patch renames omap_hwmod_mutex to _hwmod_list_mutex to indicate clearly that it is only used for hwmod list manipulation operations. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Benoît Cousson b-cous...@ti.com --- arch/arm/mach-omap2/omap_hwmod.c | 27

[PATCH 0/3] OMAP: wd_timer: update integration code to use new hwmod changes

Update the OMAP watchdog timer integration code to take advantage of the new hwmod upgrades added by the OMAP2+: hwmod core upgrades for 2.6.38: first set series, posted previously. So that series needs to be applied before these patches. Charu, it would be great if you could take a look at

[PATCH 1/3] OMAP2+: wd_timer: separate watchdog disable code from the rest of mach-omap2/devices.c

Split the wd_timer disable code out into its own file, mach-omap2/wd_timer.c; it belongs in its own file rather than cluttering up devices.c. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Charulatha Varadarajan ch...@ti.com --- arch/arm/mach-omap2/Makefile |2 +

[PATCH 3/3] OMAP: wd_timer: remove old, dead probing code

After commit f2ce62312650211f6cf665cd6dc519c334c4071e, watchdog probing is handled by files in mach-omap1/ and mach-omap2/, and the plat-omap/devices.c probing code is no longer used. Remove the dead code in plat-omap/devices.c. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Charulatha

[PATCH 2/3] OMAP2+: wd_timer: disable on boot via hwmod postsetup mechanism

The OMAP watchdog timer IP blocks require a specific set of register writes to occur before they will be disabled[1], even if the device clocks appear to be disabled in the CM_*CLKEN registers. In the MPU watchdog case, failure to execute this reset sequence will eventually cause the watchdog to

Re: [PATCH 0/3] OMAP: wd_timer: update integration code to use new hwmod changes

Paul, Thanks for the series. On Tue, Nov 16, 2010 at 15:55, Paul Walmsley p...@pwsan.com wrote: Update the OMAP watchdog timer integration code to take advantage of the new hwmod upgrades added by the OMAP2+: hwmod core upgrades for 2.6.38: first set series, posted previously.  So that series

Re: [PATCH v4 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter

Hi, On Mon, 2010-11-08 at 13:24 +0100, ext Archit Taneja wrote: From: Sumit Semwal sumit.sem...@ti.com A new member 'channel' is introduced in omap_dss_device structure to determine which channel the panel uses. The dispc functions used by interface drivers (dsi, sdi etc) will use this

Re: [PATCH] i2c-omap: Set latency requirements only once for several messages

On Tue, 16 Nov 2010, Samu Onkalo wrote: Ordinary I2C read consist of two messages. First a write operation to tell register address and then read operation to get data. CPU wake up latency is set and removed twice in read case. Set latency requirement before the message processing loop and

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Hello, On Mon, 15 Nov 2010 13:27:39 -0600 Nishanth Menon n...@ti.com wrote: + /* + * Allow multiple calls, but initialize only if not already initalized Minor: s/initalized/initialized/. + * even if the previous call failed, coz, no reason we'd succeed again + */ +

RE: [PATCH v4 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter

Hi, Tomi Valkeinen wrote: Hi, [snip] diff --git a/arch/arm/plat-omap/include/plat/display.h b/arch/arm/plat-omap/include/plat/display.h index 586944d..3e6eec1 100644 --- a/arch/arm/plat-omap/include/plat/display.h +++ b/arch/arm/plat-omap/include/plat/display.h @@ -434,6 +434,7 @@

[RFC] OMAP: Serial: Define register access modes in LCR

From: Andrei Emeltchenko andrei.emeltche...@nokia.com Access to some registers depends on register access mode Three different modes are available for OMAP (at least) * Operational mode LCR_REG[7] = 0x0 * Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF * Configuration mode B

[RFC] OMAP: Serial: Define register access modes in LCR

From: Andrei Emeltchenko andrei.emeltche...@nokia.com Access to some registers depends on register access mode Three different modes are available for OMAP (at least) * Operational mode LCR_REG[7] = 0x0 * Configuration mode A LCR_REG[7] = 0x1 and LCR_REG[7:0]! = 0xBF * Configuration mode B

[PATCH v2] OMAP: DSS2: OMAPFB: Add null pointer check

A null pointer check added. And using kstrdup() instead of kmalloc() strcpy() Signed-off-by: Samreen samr...@ti.com --- Version2: - Using kstrdup() instead of kmalloc() strcpy() - Using ENOMEM as error code instead of EINVAL - Subject changed appropriately The link to v1 of patch is:

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Thomas Petazzoni wrote, on 11/16/2010 05:21 AM: Hello, On Mon, 15 Nov 2010 13:27:39 -0600 Nishanth Menonn...@ti.com wrote: + /* +* Allow multiple calls, but initialize only if not already initalized Minor: s/initalized/initialized/. aah thanks :) +* even if the

Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

- Original Message - From: Grant Erickson maratho...@gmail.com To: linux-omap@vger.kernel.org Cc: Tony Lindgren t...@atomide.com Sent: Monday, November 15, 2010 12:58 AM Subject: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers This patch adds support to

Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

On Sun, Nov 14, 2010 at 01:28:49PM -0600, Grant Erickson wrote: +MODULE_LICENSE(GPLv2); module license should be GPL v2 just read the comment above MODULE_LICENSE definition: /* * The following license idents are currently accepted as indicating free * software modules * * GPL

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Hello, On Tue, 16 Nov 2010 05:54:50 -0600 Nishanth Menon n...@ti.com wrote: Do we really need this ? I personaly don't really like this quite of Hey, I'm already initialized, let's do nothing silently then. Unless there are strong reasons for which this function could be called twice,

Re: [PATCH 3/3] OMAP: wd_timer: remove old, dead probing code

Hello. On 16-11-2010 13:25, Paul Walmsley wrote: After commit f2ce62312650211f6cf665cd6dc519c334c4071e, watchdog Linus has asked to also specify the commit summary in parens... probing is handled by files in mach-omap1/ and mach-omap2/, and the plat-omap/devices.c probing code is no

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Thomas Petazzoni wrote, on 11/16/2010 06:42 AM: Hello, On Tue, 16 Nov 2010 05:54:50 -0600 Nishanth Menonn...@ti.com wrote: Do we really need this ? I personaly don't really like this quite of Hey, I'm already initialized, let's do nothing silently then. Unless there are strong reasons for

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Hello, On Tue, 16 Nov 2010 07:10:36 -0600 Nishanth Menon n...@ti.com wrote: I feel you may have misunderstood the code, we DONOT oblige all boards to *have* to call omapX_init_opp. It is a device_initcall - so for the boards that dont call it, device_initcall will trigger and initialzie

RE: [PATCH v4 3/7] OMAP: DSS2: Introduce omap_channel as a omap_dss_device parameter

On Tue, 2010-11-16 at 12:22 +0100, ext Taneja, Archit wrote: Hi, Tomi Valkeinen wrote: Hi, [snip] diff --git a/arch/arm/plat-omap/include/plat/display.h b/arch/arm/plat-omap/include/plat/display.h index 586944d..3e6eec1 100644 --- a/arch/arm/plat-omap/include/plat/display.h

RE: [PATCH v5 1/5] omap gpmc: enable irq mode in gpmc

-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Saturday, November 06, 2010 2:43 AM To: Ghorai, Sukumar Cc: linux-omap@vger.kernel.org; linux-...@lists.infradead.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH v5 1/5] omap gpmc: enable irq

Re: [PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver

Hi, On Tue, 2010-11-16 at 05:17 +0100, ext Bryan Wu wrote: Generic DPI panel driver includes the driver and 4 similar panel configurations. It will match the panel name which is passed from platform data and setup the right configurations. With generic DPI panel driver, we can remove

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Thomas Petazzoni had written, on 11/16/2010 06:42 AM, the following: But, sorry, I find this even uglier than I thought it was :) What about adding the obligation to boards file to call the omapX_init_opp() function and then do their customization (if needed), then no call to I knew I had

[PATCH 1/6] OMAP: powerdomain: Move powerdomain.c from mach-omap2 to plat-omap

This is in preparation of splitting the powerdomain framework into platform-independent part (for all omaps) and platform-specific parts. The platform-independent code would reside in plat-omap/powerdomain.c and the platform-specific code will resides in mach-omap2/powerdomain-.c files. Some

[PATCH 6/6] OMAP4: powerdomain: Add pwrdm_clear_all_prev_pwrst

From: Santosh Shilimkar santosh.shilim...@ti.com OMAP4430 ES2 has additional bitfields in PWRSTST register which help identify the previous power state entered by the powerdomain. Add pwrdm_clear_all_prev_pwrst api to support this. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com

[PATCH 4/6] OMAP: powerdomain: Arch specific funcs for logic control

Define the following architecture specific funtions for omap2/3/4 .pwrdm_set_logic_retst .pwrdm_read_logic_pwrst .pwrdm_read_prev_logic_pwrst .pwrdm_read_logic_retst Convert the platform-independent framework to call these functions. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley

[PATCH 5/6] OMAP: powerdomain: Arch specific funcs for mem control

Define the following architecture specific funtions for omap2/3/4 .pwrdm_set_mem_onst .pwrdm_set_mem_retst .pwrdm_read_mem_pwrst .pwrdm_read_prev_mem_pwrst .pwrdm_read_mem_retst .pwrdm_clear_all_prev_pwrst .pwrdm_enable_hdwr_sar .pwrdm_disable_hdwr_sar .pwrdm_wait_transition Convert the

[PATCH 0/6] Split powerdomain framework into plat specific/independent

OMAP4 powerdomains have some inherent differences as compared to OMAP2/3 powerdomains, starting with register offsets being different to clubbing of multiple controls into one register and in some cases splitting of control into multiple registers. There are also new features like

[PATCH 2/6] OMAP: powerdomain: Infrastructure to put arch specific code

Put infrastructure in place, so arch specific func pointers can be hooked up to the platform-independent part of the framework. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com ---

[PATCH 3/6] OMAP: powerdomain: Arch specific funcs for state control

Define the following architecture specific funtions for omap2/3/4 .pwrdm_set_next_pwrst .pwrdm_read_next_pwrst .pwrdm_read_pwrst .pwrdm_read_prev_pwrst Convert the platform-independent framework to call these functions. Signed-off-by: Rajendra Nayak rna...@ti.com Cc: Paul Walmsley p...@pwsan.com

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

On Tue, 16 Nov 2010 09:23:06 -0600 Nishanth Menon n...@ti.com wrote: my initial implementation had forced board files to call the opp_init_table, then changed that here: http://marc.info/?l=linux-omapm=127431810922704w=2 Kevin seemed happy with the change here:

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Thomas Petazzoni had written, on 11/16/2010 09:50 AM, the following: On Tue, 16 Nov 2010 09:23:06 -0600 Nishanth Menon n...@ti.com wrote: my initial implementation had forced board files to call the opp_init_table, then changed that here: http://marc.info/?l=linux-omapm=127431810922704w=2

Re: [PATCH 5/6] OMAP: powerdomain: Arch specific funcs for mem control

Hello, On Tue, 16 Nov 2010 21:08:05 +0530 Rajendra Nayak rna...@ti.com wrote: Define the following architecture specific funtions for omap2/3/4 funtions - functions. +/* Common Internal functions used across OMAP rev's*/ +int _get_mem_bank_onstate_mask(u8 bank) +{ + switch (bank) { +

Re: [PATCH 2/6] OMAP: powerdomain: Infrastructure to put arch specific code

On Tue, 16 Nov 2010 21:08:02 +0530 Rajendra Nayak rna...@ti.com wrote: +struct pwrdm_functions { + int (*pwrdm_set_next_pwrst)(struct powerdomain *pwrdm, u8 pwrst); + int (*pwrdm_read_next_pwrst)(struct powerdomain *pwrdm); + int (*pwrdm_read_pwrst)(struct powerdomain

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Thomas Petazzoni thomas.petazz...@free-electrons.com writes: On Tue, 16 Nov 2010 09:23:06 -0600 Nishanth Menon n...@ti.com wrote: my initial implementation had forced board files to call the opp_init_table, then changed that here: http://marc.info/?l=linux-omapm=127431810922704w=2 Kevin

Re: [PATCH] i2c-omap: Set latency requirements only once for several messages

Samu Onkalo samu.p.onk...@nokia.com writes: Ordinary I2C read consist of two messages. First a write operation to tell register address and then read operation to get data. CPU wake up latency is set and removed twice in read case. Set latency requirement before the message processing loop

Re: [PATCH 3/3] OMAP: wd_timer: remove old, dead probing code

On Tue, 16 Nov 2010, Sergei Shtylyov wrote: On 16-11-2010 13:25, Paul Walmsley wrote: After commit f2ce62312650211f6cf665cd6dc519c334c4071e, watchdog Linus has asked to also specify the commit summary in parens... Thanks, will do. - Paul -- To unsubscribe from this list: send the

Re: [PATCH 2/7] OMAP: mux: Add support for control module split in several partitions

* Cousson, Benoit b-cous...@ti.com [101115 13:36]: Hi Tony, On 11/15/2010 9:03 PM, Tony Lindgren wrote: * Benoit Coussonb-cous...@ti.com [10 13:26]: Starting on OMAP4, the pin mux configuration is located in two different partitions of the control module (CODE_PAD and WKUP_PAD). The

Re: [PATCH 0/8] OMAP2+: hwmod core upgrades for 2.6.38: first set

On Tue, 16 Nov 2010, Paul Walmsley wrote: This patch series contains upgrades for the OMAP2+ hwmod core code, intended for 2.6.38. Most of these patches were developed in response to use-cases discovered while converting device drivers to use the hwmod code. Tested on an OMAP34xx

Re: [PATCH 0/3] OMAP: wd_timer: update integration code to use new hwmod changes

On Tue, 16 Nov 2010, Paul Walmsley wrote: Update the OMAP watchdog timer integration code to take advantage of the new hwmod upgrades added by the OMAP2+: hwmod core upgrades for 2.6.38: first set series, posted previously. So that series needs to be applied before these patches. Charu,

Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

Grant Erickson maratho...@gmail.com writes: This patch adds support to request and use one or more of the OMAP dual-mode timers as a generic PWM device compatible with other generic PWM drivers such as the PWM backlight or PWM beeper driver. How will this co-exist with the PWM on the twl6030

Re: [PATCH 2/7] OMAP: mux: Add support for control module split in several partitions

Hi Tony, On 11/16/2010 5:41 PM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [101115 13:36]: Hi Tony, On 11/15/2010 9:03 PM, Tony Lindgren wrote: * Benoit Coussonb-cous...@ti.com [10 13:26]: Starting on OMAP4, the pin mux configuration is located in two different partitions

Re: [PATCH 1/5] crypto: omap-aes: change in prevention of OCP bus error

Hi, * Dmitry Kasatkin dmitry.kasat...@nokia.com [101110 09:18]: Suggested to use udelay() instead of nop as on the higher core frequencies it might not be enough time. Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com --- drivers/crypto/omap-aes.c | 10 ++ 1 files

Re: [PATCH 1/7] crypto: updates omap sham device related platform code

* Dmitry Kasatkin dmitry.kasat...@nokia.com [101110 09:20]: - registration with multi OMAP kernels support - clocks Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com --- arch/arm/mach-omap2/clock2420_data.c |2 +- arch/arm/mach-omap2/clock2430_data.c |2 +-

Re: [PATCH 3/7] omap-sham: OMAP macros corrected

* Dmitry Kasatkin dmitry.kasat...@nokia.com [101110 09:20]: Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com --- arch/arm/mach-omap2/devices.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c

Re: [PATCH 5/8] OMAP2+: hwmod: rename omap_hwmod_mutex to _hwmod_list_mutex

Hi Paul, Funny, I was about to send you a RFC to get rid of that mutex :-) Today that mutex is preventing us to be re-entrant during hwmod lookup and for_each_by_class iteration, and we'd like to in order to manage link between 2 hwmods. The context is the link between mcbsp and sidetone on

Re: [PATCH 2/7] OMAP: mux: Add support for control module split in several partitions

* Cousson, Benoit b-cous...@ti.com [101116 08:53]: Hi Tony, On 11/16/2010 5:41 PM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [101115 13:36]: Hi Tony, On 11/15/2010 9:03 PM, Tony Lindgren wrote: * Benoit Coussonb-cous...@ti.com [10 13:26]: Starting on OMAP4, the pin

Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

On 11/16/10 4:37 AM, Hemanth V wrote: - Original Message - From: Grant Erickson maratho...@gmail.com Sent: Monday, November 15, 2010 12:58 AM This patch adds support to request and use one or more of the OMAP dual-mode timers as a generic PWM device compatible with other generic

Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

On 11/16/10 4:42 AM, Felipe Balbi wrote: On Sun, Nov 14, 2010 at 01:28:49PM -0600, Grant Erickson wrote: +MODULE_LICENSE(GPLv2); module license should be GPL v2 Thanks for the feedback. I'll make that adjustment. Best, Grant -- To unsubscribe from this list: send the line unsubscribe

Re: omap4: hsmmc: Fix improper card detection while booting

* kishore kadiyala kishore.kadiy...@ti.com [101115 00:59]: While booting OMAP4 ES2.0 boards, cards on MMC1 and MMC2 controllers are not getting detected some times. During reset of command/data line, wrong pointer to base address was passed while read operation to SYSCTL register, thus

Re: [PATCH] omap4: enable L2 prefetching

* Måns Rullgård m...@mansr.com [101115 09:01]: Nishanth Menon n...@ti.com writes: From: Mans Rullgard m...@mansr.com Enabling L2 prefetching improves performance as shown on Panda ES2.1 board with mem test, and it has measurable impact on performances. I think we should consider it,

Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

On 11/16/10 9:01 AM, Kevin Hilman wrote: Grant Erickson maratho...@gmail.com writes: This patch adds support to request and use one or more of the OMAP dual-mode timers as a generic PWM device compatible with other generic PWM drivers such as the PWM backlight or PWM beeper driver. How will

Re: [PATCH 2/7] OMAP: mux: Add support for control module split in several partitions

On 11/16/2010 6:37 PM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [101116 08:53]: Hi Tony, On 11/16/2010 5:41 PM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [101115 13:36]: Hi Tony, On 11/15/2010 9:03 PM, Tony Lindgren wrote: * Benoit Coussonb-cous...@ti.com

Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

Grant Erickson maratho...@gmail.com writes: On 11/16/10 9:01 AM, Kevin Hilman wrote: Grant Erickson maratho...@gmail.com writes: This patch adds support to request and use one or more of the OMAP dual-mode timers as a generic PWM device compatible with other generic PWM drivers such as the

Re: [PATCH] omap4: enable L2 prefetching

Nishanth Menon n...@ti.com writes: From: Mans Rullgard m...@mansr.com Enabling L2 prefetching improves performance as shown on Panda ES2.1 board with mem test, and it has measurable impact on performances. I think we should consider it, even though it damages writes a bit. (rebased to

[PATCH v4 2/3] omap4: opp: add OPP table data

This patch adds OPP tables for OMAP4. New file has been added to keep the OMAP4 opp tables and the registration of these tables with the generic opp framework by OMAP SoC OPP interface. Based on:

[PATCH v3 3/3] OMAP3: remove OPP interfaces from OMAP PM layer

From: Kevin Hilman khil...@deeprootsystems.com With new OPP layer, OPP users will access OPP API directly instead of using OMAP PM layer, so remove all notions of OPPs from the OMAP PM layer. Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Kevin Hilman khil...@deeprootsystems.com ---

[PATCH v4 1/3] omap: opp: add OMAP3 OPP table data and common init

Add OPP data for OMAP34xx and OMAP36xx and initialization functions to populate OPP tables based on current SoC. introduce an OMAP generic opp initialization routine which OMAP3 and OMAP4+ SoCs can use to register their OPP definitions. Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com

[PATCH v4 0/3] OMAP: Add opp data

Major changes in V4: Rename of oppxxx_data.h to data.c, move device_init there omap_init_opp_table now will return -EEXIST if it was called previously. V3: http://marc.info/?l=linux-omapm=128984926812800w=2 V2: http://marc.info/?t=12875366533r=1w=2 Kevin Hilman (1):

RE: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Grant Erickson Sent: Monday, November 15, 2010 12:59 AM To: linux-omap@vger.kernel.org Cc: Tony Lindgren Subject: [PATCH] Add OMAP Support for Generic PWM Devices

Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

On 11/16/10 10:54 AM, Premi, Sanjeev wrote: [sp] pr_info(), dev_info() are already macros - conditional to DEBUG. We should use them instead of defining another layer. The macros pr_devel, pr_dbg, and dev_dbg are so conditionalized; however, *_info are straight pass-throughs to printk and

Re: [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3

* Tomi Valkeinen tomi.valkei...@nokia.com [101116 05:41]: On Tue, 2010-11-16 at 07:09 +0100, ext Nilofer, Samreen wrote: Hi, Any more comments on this patch? I'm not sure if enabling kernel options by default is a good thing. Somehow I remember that enabling things by default is not

Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

On 11/16/10 10:43 AM, Kevin Hilman wrote: Grant Erickson maratho...@gmail.com writes: On 11/16/10 9:01 AM, Kevin Hilman wrote: Grant Erickson maratho...@gmail.com writes: This patch adds support to request and use one or more of the OMAP dual-mode timers as a generic PWM device compatible

Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

Grant Erickson maratho...@gmail.com writes: [...] Before something like this can merge, I would rather see 1) generic PWM framework pushed along and merged 2) the dmtimer hwmod conversion finished Yes, I know it's a lot more work to fix the core/framework code before having a feature

Re: [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3

Tony Lindgren t...@atomide.com writes: * Tomi Valkeinen tomi.valkei...@nokia.com [101116 05:41]: On Tue, 2010-11-16 at 07:09 +0100, ext Nilofer, Samreen wrote: Hi, Any more comments on this patch? I'm not sure if enabling kernel options by default is a good thing. Somehow I remember

Re: [PATCH v4] OMAP3: DSS: Kconfig changes to enable display options on OMAP3

* Kevin Hilman khil...@deeprootsystems.com [101116 11:45]: Tony Lindgren t...@atomide.com writes: * Tomi Valkeinen tomi.valkei...@nokia.com [101116 05:41]: On Tue, 2010-11-16 at 07:09 +0100, ext Nilofer, Samreen wrote: Hi, Any more comments on this patch? I'm not sure if

Re: [PATCH] Add OMAP Support for Generic PWM Devices using Dual-mode Timers

* Kevin Hilman khil...@deeprootsystems.com [101116 11:43]: Grant Erickson maratho...@gmail.com writes: [...] Before something like this can merge, I would rather see 1) generic PWM framework pushed along and merged 2) the dmtimer hwmod conversion finished Yes, I know it's a lot

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

* Nishanth Menon n...@ti.com [101115 16:43]: Thomas Petazzoni had written, on 11/15/2010 04:51 PM, the following: Hello, On Mon, 15 Nov 2010 13:27:39 -0600 Nishanth Menon n...@ti.com wrote: +++ b/arch/arm/mach-omap2/opp3xxx_data.h + +static struct omap_opp_def __initdata

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

* Kevin Hilman khil...@deeprootsystems.com [101116 08:06]: Thomas Petazzoni thomas.petazz...@free-electrons.com writes: On Tue, 16 Nov 2010 09:23:06 -0600 Nishanth Menon n...@ti.com wrote: my initial implementation had forced board files to call the opp_init_table, then changed that

Re: [PATCH 2/3] OMAP: use generic DPI panel driver in board files

* Bryan Wu bryan...@canonical.com [101115 20:08]: Still keep sharp_ls_panel, since the sharp_ls_panel driver contains blacklight control driver code which will be moved out later. Then we can use generic DPI driver for sharp_ls_panel. Signed-off-by: Bryan Wu bryan...@canonical.com ---

[PATCH v2 0/8] OMAP4: mux: Add the OMAP4430 ES1.0 ES2.x support

Hi Tony, Here is the version updated with your latest fixes and improvements after a small clean to fix a checkpatch issue. I added as well a patch from Dan to add __func__ in every pr__xxx calls. The series is based on mainline (2.6.37-rc1) and is available here:

[PATCH v2 1/8] OMAP: mux: Replace printk with pr_xxx macros

Replace all the printk(KERN_XXX... with pr_xxx macros. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/mach-omap2/mux.c | 38 +++--- 1

[PATCH v2 2/8] OMAP: mux: Add support for control module split in several partitions

Starting on OMAP4, the pin mux configuration is located in two different partitions of the control module (CODE_PAD and WKUP_PAD). The first one is inside the core power domain whereas the second one is inside the wakeup. - Add the capability to add any number of partition during board init time

[PATCH v2 4/8] OMAP4: sdp4430: Select CBL package for ES1 and initialize mux

Select the CBL package if SDP4430 is enabled during config. Initialize the mux framework during the board init. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com ---

[PATCH v2 8/8] OMAP: mux: Add __func__ macro to pr_xxx macros

From: Dan Murphy dmur...@ti.com Removed mux: and added the __func__ macro to make debugging easier. Signed-off-by: Dan Murphy dmur...@ti.com Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/mux.c | 30 +++---

[PATCH v2 6/8] OMAP4: sdp4430: Select CBS package for ES2

Select the CBS package if SDP4430 is enabled during config. Use the proper package (CBL or CBS) based on chip revision. Signed-off-by: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Anand

[PATCH v2 5/8] OMAP4: mux: Add CBS package data for OMAP4430 ES2

Please note that the full muxmodes are re-defined for ES2 instead of using the subset. There are 81 differences among 204 pins. The subset fixup will have to iterate over the whole list for each subset entry, which can lead to an important number of iteration. On the other hand, it will take much

[PATCH v2 7/8] OMAP4: pandaboard: Select CBL CBS package and initialize mux

From: sricharan r.sricha...@ti.com The mux framework allows the change of pad configuration by drivers when needed. Prior to this the mux framework has to be initialised with all the mux parameters specific to the board. The mux init is already present in the board file for SDP. Adding the mux

Re: [PATCH v3 1/3] omap: opp: add OMAP3 OPP table data and common init

Tony Lindgren had written, on 11/16/2010 02:35 PM, the following: * Nishanth Menon n...@ti.com [101115 16:43]: Thomas Petazzoni had written, on 11/15/2010 04:51 PM, the following: Hello, On Mon, 15 Nov 2010 13:27:39 -0600 Nishanth Menon n...@ti.com wrote: +++

Re: [PATCH v2] OMAP1: drop AMS_DELTA_FIQ config option

* Janusz Krzysztofik jkrzy...@tis.icnet.pl [101105 18:48]: This patches removes a config option that was used to select a FIQ handler to be build for Amstrad Delta, as required by the on-board serio interface driver. Not having any problem reports received since it was introduced in 2.6.35,

Re: [Patch v5] OMAP: AM3517/05: Add craneboard support

* srin...@mistralsolutions.com srin...@mistralsolutions.com [101109 06:23]: From: Srinath srin...@mistralsolutions.com Craneboard is a hardware development platform based on the Sitara AM3517 ARM Cortex - A8 microprocessor device. This is a low cost reference design. This patch adds basic

Re: [PATCH] omap3: feature: fix OMAP3_IVA_MASK

* Nishanth Menon n...@ti.com [101105 17:29]: From: Arno Steffen arno.stef...@googlemail.com OMAP3_IVA_MASK should use OMAP3_IVA_SHIFT instead of OMAP3_SGX_SHIFT Signed-off-by: Arno Steffen arno.stef...@googlemail.com --- Sending on behalf of Arno - he pointed at the change and everything

Re: [PATCH 2.6.38] omap: McBSP: Fix potential memory leak in omap_mcbsp_remove

* Jarkko Nikula jhnik...@gmail.com [101103 02:15]: Function omap_mcbsp_probe allocates struct omap_mcbsp *mcbsp but it is not freed in omap_mcbsp_remove. Fix this, remove unneeded structure cleanups and clk_disable calls since they are not needed here. This is not problem currently but

Re: [PATCH ] McBSP:Make the free variable update more readable

* Jarkko Nikula jhnik...@gmail.com [101103 03:09]: On Wed, 3 Nov 2010 15:28:57 +0530 shubhrajy...@ti.com wrote: From: Shubhrajyoti D shubhrajy...@ti.com Using true/false instead of 1/0 to update the free variable. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com ---

Re: [PATCHv3 1/1] omap: Ptr isr_reg tracked as NULL was dereferenced

* Evgeny Kuznetsov ext-eugeny.kuznet...@nokia.com [101108 00:35]: From: Evgeny Kuznetsov ext-eugeny.kuznet...@nokia.com Value of isr_reg pointer is depend on configuration and GPIO method. Potentially it may have NULL value and it is dereferenced later in code. Warning and exit from function

Re: BeagleBoard not resuming from uart with latest pm-core ?

Thomas Petazzoni thomas.petazz...@free-electrons.com writes: Hello Govindraj, On Mon, 15 Nov 2010 19:24:05 +0530 Govindraj govindraj...@gmail.com wrote: Can you check if you have below two patches in the kernel you have? http://www.spinics.net/lists/linux-serial/msg02684.html

[PATCH 0/3] OMAP: DSS2: introduce generic panel display driver (try #7)

There are 4 duplicated DPI panel drivers in DSS2 display driver. They are similar and a generic DPI panel driver can support all them with specific panel configuration. And new DPI panel driver can be easily supported by adding panel configurations into generic panel DPI driver. This patchset

[PATCH 1/3] OMAP: DSS2: Add generic DPI panel display driver

Generic DPI panel driver includes the driver and 4 similar panel configurations. It will match the panel name which is passed from platform data and setup the right configurations. With generic DPI panel driver, we can remove those 4 duplicated panel display drivers. In the future, it is simple

[PATCH 2/3] OMAP: use generic DPI panel driver in board files

Still keep sharp_ls_panel, since the sharp_ls_panel driver contains blacklight control driver code which will be moved out later. Then we can use generic DPI driver for sharp_ls_panel. Signed-off-by: Bryan Wu bryan...@canonical.com --- arch/arm/mach-omap2/board-3430sdp.c | 12 +---

[PATCH 3/3] OMAP: DSS2: remove generic DPI panel driver duplicated panel drivers

Still keep sharp_ls_panel driver, because it contains blacklight control driver. Signed-off-by: Bryan Wu bryan...@canonical.com --- drivers/video/omap2/displays/Kconfig | 18 -- drivers/video/omap2/displays/Makefile |3 -

  1   2   >