[PATCH v2 0/4] omap hsmmc device tree support

2012-02-23 Thread Rajendra Nayak
This series adds device tree support for OMAP hsmmc driver. The series is dependent on a couple other series, to add TWL regulator DT support[1] and another to clean the pdev-id usage within the hsmmc driver[2] all patches including the dependent series can be found here

[PATCH v2 1/4] mmc: omap_hsmmc: Convert hsmmc driver to use device tree

2012-02-23 Thread Rajendra Nayak
Define dt bindings for the ti-omap-hsmmc, and adapt the driver to extract data (which was earlier passed as platform_data) from device tree. Signed-off-by: Rajendra Nayak rna...@ti.com --- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 31 + drivers/mmc/host/omap_hsmmc.c

[PATCH v2 2/4] mmc: omap_hsmmc: Avoid a regulator voltage change with dt

2012-02-23 Thread Rajendra Nayak
When booting with Device tree, the omap_hsmmc driver does not program the pbias cell (inside OMAP control module) during a regulator voltage change. In case of non-dt boot, this is handled using callbacks from within platform_data and implemented in machine code. To be able to do this with device

[PATCH v2 3/4] arm/dts: OMAP4: Add mmc controller nodes and board data

2012-02-23 Thread Rajendra Nayak
Add omap mmc related device tree data for OMAP4. Currenly limited to only omap4-panda and omap4-sdp boards. Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/boot/dts/omap4-panda.dts | 10 ++ arch/arm/boot/dts/omap4-sdp.dts | 16 arch/arm/boot/dts/omap4.dtsi

RE: [PATCH v2] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators

2012-02-23 Thread Hiremath, Vaibhav
On Wed, Feb 22, 2012 at 22:15:03, Porter, Matt wrote: This fixes smsc911x support on platforms using gpmc_smsc911x_init(). Commit c7e963f616 (net/smsc911x: Add regulator support) added the requirement that platforms provide vdd33a and vddvario supplies. Signed-off-by: Matt Porter

[PATCH 4/6] gpio/omap: get rid of retrigger variable in gpio_irq_handler

2012-02-23 Thread Tarun Kanti DebBarma
This local variable is just assigned zero and then OR'ed with isr. It does not appear to serve any purpose and so removing it. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- drivers/gpio/gpio-omap.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git

[PATCH 6/6] gpio/omap: fix _set_gpio_irqenable implementation

2012-02-23 Thread Tarun Kanti DebBarma
This function should be capable of both enabling and disabling interrupts based upon the *enable* parameter. Right now the function only enables the interrupt and *enable* is not used at all. So add the interrupt disable capability also using the parameter. Signed-off-by: Tarun Kanti DebBarma

[PATCH 3/6] gpio/omap: remove suspend_wakeup field from struct gpio_bank

2012-02-23 Thread Tarun Kanti DebBarma
Since we already have bank-context.wake_en to keep track of gpios which are wakeup enabled, there is no need to have this field any more. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- drivers/gpio/gpio-omap.c | 11 +-- 1 files changed, 5 insertions(+), 6 deletions(-) diff

[PATCH 1/6] gpio/omap: remove saved_fallingdetect, saved_risingdetect fields

2012-02-23 Thread Tarun Kanti DebBarma
Since we already have context.fallingdetect and context.risingdetect there is no more need to have these additional fields. Also, getting rid of extra reads associated with them. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- drivers/gpio/gpio-omap.c | 19 --- 1

[PATCH 2/6] gpio/omap: remove saved_wakeup field from struct gpio_bank

2012-02-23 Thread Tarun Kanti DebBarma
There is no more need to have saved_wakeup. Instead we can use context.wake_en which holds the current wakeup enable register context. This also means that the read from wakeup enable register is not needed. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- drivers/gpio/gpio-omap.c |

[PATCH 5/6] gpio/omap: fix trigger type to unsigned

2012-02-23 Thread Tarun Kanti DebBarma
The GPIO trigger parameter is of type unsigned. enum { IRQ_TYPE_NONE = 0x, IRQ_TYPE_EDGE_RISING= 0x0001, IRQ_TYPE_EDGE_FALLING = 0x0002, IRQ_TYPE_EDGE_BOTH = (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING),

[PATCH 0/6] gpio/omap: Some more driver cleanup and fixes

2012-02-23 Thread Tarun Kanti DebBarma
The cleanup is mostly getting rid of redundant fields in struct gpio_bank{} as we already have them as part of bank-context now. Also, remove un-used variable from gpio_irq_handler. The fix include correction of _set_gpio_irqenable() implementation and fix type mismatch of gpio trigger parameter.

Re: [PATCH v2 0/4] omap hsmmc device tree support

2012-02-23 Thread Rajendra Nayak
On Thursday 23 February 2012 05:31 PM, Rajendra Nayak wrote: This series adds device tree support for OMAP hsmmc driver. The series is dependent on a couple other series, to add TWL regulator DT support[1] and another to clean the pdev-id usage within the hsmmc driver[2] all patches including

Re: [PATCH 0/6] gpio/omap: Some more driver cleanup and fixes

2012-02-23 Thread Shilimkar, Santosh
On Thu, Feb 23, 2012 at 5:40 PM, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: The cleanup is mostly getting rid of redundant fields in struct gpio_bank{} as we already have them as part of bank-context now. Also, remove un-used variable from gpio_irq_handler. The fix include correction of

Re: [PATCH 1/6] gpio/omap: remove saved_fallingdetect, saved_risingdetect fields

2012-02-23 Thread Felipe Balbi
On Thu, Feb 23, 2012 at 05:40:26PM +0530, Tarun Kanti DebBarma wrote: Since we already have context.fallingdetect and context.risingdetect there is no more need to have these additional fields. Also, getting rid of extra reads associated with them. Signed-off-by: Tarun Kanti DebBarma

Re: [PATCH 2/6] gpio/omap: remove saved_wakeup field from struct gpio_bank

2012-02-23 Thread Felipe Balbi
On Thu, Feb 23, 2012 at 05:40:27PM +0530, Tarun Kanti DebBarma wrote: There is no more need to have saved_wakeup. Instead we can use context.wake_en which holds the current wakeup enable register context. This also means that the read from wakeup enable register is not needed.

Re: [PATCH 3/6] gpio/omap: remove suspend_wakeup field from struct gpio_bank

2012-02-23 Thread Felipe Balbi
On Thu, Feb 23, 2012 at 05:40:28PM +0530, Tarun Kanti DebBarma wrote: Since we already have bank-context.wake_en to keep track of gpios which are wakeup enabled, there is no need to have this field any more. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Likewise: Acked-by: Felipe

Re: [PATCH 4/6] gpio/omap: get rid of retrigger variable in gpio_irq_handler

2012-02-23 Thread Felipe Balbi
On Thu, Feb 23, 2012 at 05:40:29PM +0530, Tarun Kanti DebBarma wrote: This local variable is just assigned zero and then OR'ed with isr. It does not appear to serve any purpose and so removing it. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com hehe, makes a lot of sense :-)

Re: [PATCH 5/6] gpio/omap: fix trigger type to unsigned

2012-02-23 Thread Felipe Balbi
On Thu, Feb 23, 2012 at 05:40:30PM +0530, Tarun Kanti DebBarma wrote: The GPIO trigger parameter is of type unsigned. enum { IRQ_TYPE_NONE = 0x, IRQ_TYPE_EDGE_RISING= 0x0001, IRQ_TYPE_EDGE_FALLING = 0x0002, IRQ_TYPE_EDGE_BOTH

Re: [PATCH 6/6] gpio/omap: fix _set_gpio_irqenable implementation

2012-02-23 Thread Felipe Balbi
On Thu, Feb 23, 2012 at 05:40:31PM +0530, Tarun Kanti DebBarma wrote: This function should be capable of both enabling and disabling interrupts based upon the *enable* parameter. Right now the function only enables the interrupt and *enable* is not used at all. So add the interrupt disable

Re: [PATCH 5/6] gpio/omap: fix trigger type to unsigned

2012-02-23 Thread Shubhrajyoti
On Thursday 23 February 2012 05:40 PM, Tarun Kanti DebBarma wrote: The GPIO trigger parameter is of type unsigned. enum { IRQ_TYPE_NONE = 0x, IRQ_TYPE_EDGE_RISING= 0x0001, IRQ_TYPE_EDGE_FALLING = 0x0002, IRQ_TYPE_EDGE_BOTH

Re: [PATCH 5/6] gpio/omap: fix trigger type to unsigned

2012-02-23 Thread Russell King - ARM Linux
On Thu, Feb 23, 2012 at 06:09:16PM +0530, Shubhrajyoti wrote: On Thursday 23 February 2012 05:40 PM, Tarun Kanti DebBarma wrote: -static int _set_gpio_triggering(struct gpio_bank *bank, int gpio, int trigger) +static int _set_gpio_triggering(struct gpio_bank *bank, int gpio, +

Re: Questions about DSS device tree adaptation

2012-02-23 Thread Tomi Valkeinen
On Thu, 2012-02-23 at 12:43 +0100, Cousson, Benoit wrote: Hi Tomi, On 2/22/2012 1:07 PM, Tomi Valkeinen wrote: dsi1: dsi@1 { compatible = ti,omap4-dsi; ti,hwmods = dss_dsi1; id =0; Fixed id should be avoided. In theory you should not need

[PATCH 0/6] ARM: OMAP4: core retention support

2012-02-23 Thread Tero Kristo
Hi, This set adds core retention support on top of mainline. The set also adds IO CHAIN wakeup capability for OMAP4, which is a nice feature to have while trying suspend / resume with CSWR as it is quite difficult to wake up the device without this. Patch 6 might cause some stir, but this is

[PATCH 1/6] arm: omap4: suspend: Program all domains to RET

2012-02-23 Thread Tero Kristo
From: Rajendra Nayak rna...@ti.com Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/pm44xx.c |6 -- 1 files changed, 0

[PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

2012-02-23 Thread Tero Kristo
From: Rajendra Nayak rna...@ti.com patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430 Public TRM. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Vishwanath BS vishwanath...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/prm44xx.c |

[PATCH 3/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux

2012-02-23 Thread Tero Kristo
From: Vishwanath BS vishwanath...@ti.com IO Daisychain feature has to be triggered whenever there is a change in device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP). Now devices can idle independent of the powerdomain, there can be a window where device is idled and

[PATCH 5/6] ARM: OMAP4: suspend: Do not get dsp/tesla out of reset

2012-02-23 Thread Tero Kristo
From: Rajendra Nayak rna...@ti.com With no driver handling DSP/TESLA, if brought out of reset, it stays active and does not assert standby. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |1 + 1 files

[PATCH 4/6] arm: omap4: prm: fix interrupt register offsets

2012-02-23 Thread Tero Kristo
Previous code used wrong instance for the interrupt register access. Use the right one which is OCP_SOCKET. Signed-off-by: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/prm44xx.c | 21 +++-- 1 files changed, 11 insertions(+), 10

[PATCH 6/6] arm: omap3+: add prcm chain interrupts to the interrupt list

2012-02-23 Thread Tero Kristo
Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled from kernel config, however enabling this option breaks the OMAP kernel completely and it can't be used. Thus, OMAP_PRCM_IRQ_BASE was added to the end of the irq list, and the prm_common code was changed to use this instead

Re: [PATCH 1/6] arm: omap4: suspend: Program all domains to RET

2012-02-23 Thread Shilimkar, Santosh
On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo t-kri...@ti.com wrote: From: Rajendra Nayak rna...@ti.com Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com

Re: [PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

2012-02-23 Thread Shilimkar, Santosh
On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo t-kri...@ti.com wrote: From: Rajendra Nayak rna...@ti.com patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430 Public TRM. A brief about IO daisy in changelog would be good apart from TRM reference. Signed-off-by: Rajendra

Re: [PATCH 3/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux

2012-02-23 Thread Shilimkar, Santosh
On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo t-kri...@ti.com wrote: From: Vishwanath BS vishwanath...@ti.com IO Daisychain feature has to be triggered whenever there is a change in device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP). Now devices can idle independent of the

<    1   2