RE: [PATCH v2 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC

2012-09-05 Thread Hiremath, Vaibhav
On Tue, Sep 04, 2012 at 15:47:59, Cousson, Benoit wrote:
 Hi Vaibhav,
 
 On 09/04/2012 05:42 AM, Vaibhav Hiremath wrote:
  On 9/3/2012 8:16 PM, Benoit Cousson wrote:
  Hi Peter,
 
  The overall series looks good to me, but I do have a couple of comments.
 
  On 08/29/2012 03:31 PM, Peter Ujfalusi wrote:
  The McBSP IP within OMAP2420 and 2430 is different we need to create 
  separate
  dtsi files for them.
 
  Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
  ---
   arch/arm/boot/dts/omap2420.dtsi |   39 ++
   arch/arm/boot/dts/omap2430.dtsi |   83 
  +++
   2 files changed, 122 insertions(+), 0 deletions(-)
   create mode 100644 arch/arm/boot/dts/omap2420.dtsi
   create mode 100644 arch/arm/boot/dts/omap2430.dtsi
 
  diff --git a/arch/arm/boot/dts/omap2420.dtsi 
  b/arch/arm/boot/dts/omap2420.dtsi
  new file mode 100644
  index 000..f375c68
  --- /dev/null
  +++ b/arch/arm/boot/dts/omap2420.dtsi
  @@ -0,0 +1,39 @@
  +/*
  + * Device Tree Source for OMAP2420 SoC
  + *
  + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
 
  Nit: 2012
 
  + *
  + * This file is licensed under the terms of the GNU General Public 
  License
  + * version 2.  This program is licensed as is without any warranty of 
  any
  + * kind, whether express or implied.
  + */
  +
  +/include/ omap2.dtsi
  +
  +/ {
  + compatible = ti,omap2420, ti,omap2;
  +
  + ocp {
  + mcbsp1: mcbsp@48074000 {
  + compatible = ti,omap2420-mcbsp;
  + reg = 0x48074000 0xff;
  + reg-names = mpu;
  + interrupts = 0 59 0x4, /* TX interrupt */
  +  0 60 0x4; /* RX interrupt */
 
  That one is not correct because it does comply with the interrupt
  controller specifier that require only one cell:
 
 intc: interrupt-controller@4820 {
 compatible = ti,omap2-intc;
 interrupt-controller;
 #interrupt-cells = 1;
  ...
 
  The one you are using is for GIC IRQ controller.
  It works probably because we are using hwmod so far :-)
 
  
  I think now we should kill the resource overwrite path, and should
  respect and use resources passed from DT.
  
  Benoit,
  Did you get a chance to validate patch submitted towards this??
 
 Not yet, but we discussed that with Peter and since he does have these
 patches for DT, he'll be able to test your series with the McBSP changes.
 

Great.

 I still want to update a couple of DTS to test that on some other IPs.
 

Ohh ok. Please let me know if I can help you here by any means.
I am equipped with AM37xEVM, BeagleBoard and Panda.

Thanks,
Vaibhav

--
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/3] gpio-twl4030: get platform data from device tree

2012-09-05 Thread Florian Vaussard





On 9/3/2012 7:24 PM, Florian Vaussard wrote:

Adds a number of missing properties to the device tree of
twl4030/gpio:
- ti,use-leds  - .use_leds
- ti,debounce  - .debounce
- ti,mmc-cd- .mmc_cd
- ti,pullups   - .pullups
- ti,pulldowns - .pulldowns

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
  drivers/gpio/gpio-twl4030.c |   86 +-
  1 files changed, 59 insertions(+), 27 deletions(-)

diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 94256fe..dabe76b 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -395,6 +395,33 @@ static int __devinit gpio_twl4030_debounce(u32 debounce, 
u8 mmc_cd)
  
  static int gpio_twl4030_remove(struct platform_device *pdev);
  
+static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev)

+{
+   struct twl4030_gpio_platform_data *omap_twl_info;
+   const char *of_use_leds;
+
+   omap_twl_info = devm_kzalloc(dev, sizeof(*omap_twl_info), GFP_KERNEL);
+   if (!omap_twl_info)
+   return NULL;
+
+   omap_twl_info-gpio_base = -1;
+
+   of_property_read_string(dev-of_node, ti,use-leds, of_use_leds);
+   if (!strcmp(of_use_leds, true))
+   omap_twl_info-use_leds = true;
+

You can replace this with

omap_twl_info-use_leds = of_property_read_bool(dev-of_node,
ti,use-leds);

Otherwise looks OK to me, also I have tested it on OMAP3EVM.

Tested--Acked-By: Vaibhav Hiremath hvaib...@ti.com


Thank you Vaibhav for your review. I will send a v2 today.

Regards,
Florian
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v2 0/2] gpio-twl4030: add new device tree properties

2012-09-05 Thread Florian Vaussard
Hello,

A number of platform data are missing when using twl4030/gpio from a
device tree. This patchset adds the missing properties, updates the 
documentation with the new bindings, and updates existing device trees.
It mainly enables LEDA and LEDB outputs, as well as pullups /
pulldowns on GPIOs.

The 1st patch changes the device driver and updates the documentation.
The 2nd patch updates the device trees for BeagleBoard and omap3-evm.

Changes since v1: 
- Patches on driver and documentation merged into the same patch
- Put device trees' values in hexadecimal
- Handle bool property using of_property_read_bool()
- Prefix the patches with the correct convention

Tested on Gumstix Overo. V1 was tested on omap3-evm by Vaibhav Hiremath.

BTW: who will merge this?

Regards,
Florian


Florian Vaussard (2):
  gpio/twl4030: get platform data from device tree
  ARM: dts: omap3: Add gpio-twl4030 properties for BeagleBoard and
omap3-EVM

 .../devicetree/bindings/gpio/gpio-twl4030.txt  |6 ++
 arch/arm/boot/dts/omap3-beagle.dts |   20 +
 arch/arm/boot/dts/omap3-evm.dts|   13 +++
 drivers/gpio/gpio-twl4030.c|   84 +--
 4 files changed, 96 insertions(+), 27 deletions(-)

-- 
1.7.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 1/2] gpio/twl4030: get platform data from device tree

2012-09-05 Thread Florian Vaussard
Adds a number of missing device tree properties for
twl4030/gpio, and update bindings:
- ti,use-leds  - .use_leds
- ti,debounce  - .debounce
- ti,mmc-cd- .mmc_cd
- ti,pullups   - .pullups
- ti,pulldowns - .pulldowns

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Acked-by: Linus Walleij linus.wall...@linaro.org
Acked-by: Vaibhav Hiremath hvaib...@ti.com
---
 .../devicetree/bindings/gpio/gpio-twl4030.txt  |6 ++
 drivers/gpio/gpio-twl4030.c|   84 +--
 2 files changed, 63 insertions(+), 27 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-twl4030.txt 
b/Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
index 16695d9..66788fd 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-twl4030.txt
@@ -11,6 +11,11 @@ Required properties:
 - interrupt-controller: Mark the device node as an interrupt controller
   The first cell is the GPIO number.
   The second cell is not used.
+- ti,use-leds : Enables LEDA and LEDB outputs if set
+- ti,debounce : if n-th bit is set, debounces GPIO-n
+- ti,mmc-cd : if n-th bit is set, GPIO-n controls VMMC(n+1)
+- ti,pullups : if n-th bit is set, set a pullup on GPIO-n
+- ti,pulldowns : if n-th bit is set, set a pulldown on GPIO-n
 
 Example:
 
@@ -20,4 +25,5 @@ twl_gpio: gpio {
 gpio-controller;
 #interrupt-cells = 2;
 interrupt-controller;
+ti,use-leds;
 };
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index 94256fe..477c1d9 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -395,6 +395,31 @@ static int __devinit gpio_twl4030_debounce(u32 debounce, 
u8 mmc_cd)
 
 static int gpio_twl4030_remove(struct platform_device *pdev);
 
+static struct twl4030_gpio_platform_data *of_gpio_twl4030(struct device *dev)
+{
+   struct twl4030_gpio_platform_data *omap_twl_info;
+
+   omap_twl_info = devm_kzalloc(dev, sizeof(*omap_twl_info), GFP_KERNEL);
+   if (!omap_twl_info)
+   return NULL;
+
+   omap_twl_info-gpio_base = -1;
+
+   omap_twl_info-use_leds = of_property_read_bool(dev-of_node,
+   ti,use-leds);
+
+   of_property_read_u32(dev-of_node, ti,debounce,
+   omap_twl_info-debounce);
+   of_property_read_u32(dev-of_node, ti,mmc-cd,
+   (u32 *)omap_twl_info-mmc_cd);
+   of_property_read_u32(dev-of_node, ti,pullups,
+   omap_twl_info-pullups);
+   of_property_read_u32(dev-of_node, ti,pulldowns,
+   omap_twl_info-pulldowns);
+
+   return omap_twl_info;
+}
+
 static int __devinit gpio_twl4030_probe(struct platform_device *pdev)
 {
struct twl4030_gpio_platform_data *pdata = pdev-dev.platform_data;
@@ -423,39 +448,44 @@ static int __devinit gpio_twl4030_probe(struct 
platform_device *pdev)
twl4030_gpio_irq_base = irq_base;
 
 no_irqs:
-   twl_gpiochip.base = -1;
twl_gpiochip.ngpio = TWL4030_GPIO_MAX;
twl_gpiochip.dev = pdev-dev;
 
-   if (pdata) {
-   twl_gpiochip.base = pdata-gpio_base;
+   if (node)
+   pdata = of_gpio_twl4030(pdev-dev);
 
-   /*
-* NOTE:  boards may waste power if they don't set pullups
-* and pulldowns correctly ... default for non-ULPI pins is
-* pulldown, and some other pins may have external pullups
-* or pulldowns.  Careful!
-*/
-   ret = gpio_twl4030_pulls(pdata-pullups, pdata-pulldowns);
-   if (ret)
-   dev_dbg(pdev-dev, pullups %.05x %.05x -- %d\n,
-   pdata-pullups, pdata-pulldowns,
-   ret);
-
-   ret = gpio_twl4030_debounce(pdata-debounce, pdata-mmc_cd);
-   if (ret)
-   dev_dbg(pdev-dev, debounce %.03x %.01x -- %d\n,
-   pdata-debounce, pdata-mmc_cd,
-   ret);
-
-   /*
-* NOTE: we assume VIBRA_CTL.VIBRA_EN, in MODULE_AUDIO_VOICE,
-* is (still) clear if use_leds is set.
-*/
-   if (pdata-use_leds)
-   twl_gpiochip.ngpio += 2;
+   if (pdata == NULL) {
+   dev_err(pdev-dev, Platform data is missing\n);
+   return -ENXIO;
}
 
+   twl_gpiochip.base = pdata-gpio_base;
+
+   /*
+* NOTE:  boards may waste power if they don't set pullups
+* and pulldowns correctly ... default for non-ULPI pins is
+* pulldown, and some other pins may have external pullups
+* or pulldowns.  Careful!
+*/
+   ret = gpio_twl4030_pulls(pdata-pullups, pdata-pulldowns);
+   if (ret)
+   dev_dbg(pdev-dev, pullups %.05x %.05x 

[PATCH 2/2] ARM: dts: omap3: Add gpio-twl4030 properties for BeagleBoard and omap3-EVM

2012-09-05 Thread Florian Vaussard
Add device tree properties for twl4030/gpio, according to the
platform data of corresponding boards. This enables the led
connected to LEDB output for both boards, as well as
pullups/pulldowns on GPIO for the BeagleBoard.

Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Acked-by: Linus Walleij linus.wall...@linaro.org
Acked-by: Vaibhav Hiremath hvaib...@ti.com
---
 arch/arm/boot/dts/omap3-beagle.dts |   20 
 arch/arm/boot/dts/omap3-evm.dts|   13 +
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index cdcb98c..c7256d5 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -17,6 +17,14 @@
device_type = memory;
reg = 0x8000 0x2000; /* 512 MB */
};
+
+   leds {
+   compatible = gpio-leds;
+   pmu_stat {
+   label = beagleboard::pmu_stat;
+   gpios = twl_gpio 19 0; /* LEDB */
+   };
+   };
 };
 
 i2c1 {
@@ -67,3 +75,15 @@
 mmc3 {
status = disabled;
 };
+
+twl_gpio {
+   ti,use-leds;
+   /* pullups: BIT(1) */
+   ti,pullups = 0x02;
+   /*
+* pulldowns:
+* BIT(2), BIT(6), BIT(7), BIT(8), BIT(13)
+* BIT(15), BIT(16), BIT(17)
+*/
+   ti,pulldowns = 0x03a1c4;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index f349ee9..e8ba1c2 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -17,6 +17,15 @@
device_type = memory;
reg = 0x8000 0x1000; /* 256 MB */
};
+
+   leds {
+   compatible = gpio-leds;
+   ledb {
+   label = omap3evm::ledb;
+   gpios = twl_gpio 19 0; /* LEDB */
+   linux,default-trigger = default-on;
+   };
+   };
 };
 
 i2c1 {
@@ -46,3 +55,7 @@
reg = 0x5c;
};
 };
+
+twl_gpio {
+   ti,use-leds;
+};
-- 
1.7.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC

2012-09-05 Thread Peter Ujfalusi
Hi,

On 09/05/2012 09:11 AM, Hiremath, Vaibhav wrote:
 Not yet, but we discussed that with Peter and since he does have these
 patches for DT, he'll be able to test your series with the McBSP changes.

 
 Great.

With his series and your patch for omap-hwmod audio was probing and working on
OMAP3/4/5 without issues.

 
 I still want to update a couple of DTS to test that on some other IPs.

 
 Ohh ok. Please let me know if I can help you here by any means.
 I am equipped with AM37xEVM, BeagleBoard and Panda.

You can try this series and your patch on top of linux-next on Panda. Not all
patches are in which needed for BeagleBoard at the moment.

-- 
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 00/17] Misc OMAP DSS patches part 2

2012-09-05 Thread Tomi Valkeinen
This series contains miscellaneous patches for omapdss. These are based on the
previous misc patches series
(http://www.mail-archive.com/linux-omap@vger.kernel.org/msg74279.html).

Some cleanups, but three a bit more important things:

* vram.c no longer uses OMAP's sDMA to clear the memory
* fifomerge has been reverted
* Swap GFX and WB fifos to avoid underflows

 Tomi

Tomi Valkeinen (17):
  OMAPDSS: Taal: use devm_* functions
  OMAPFB1: remove unnecessary includes
  OMAPFB1: remove a non-used table
  OMAPDSS: remove unnecessary includes
  OMAPFB: clear framebuffers with CPU
  OMAPDSS: VRAM: Remove clearing with sDMA
  OMAPDSS: Taal: Reogranize for device tree
  OMAPDSS: TFP410: use devm_gpio_request_one
  OMAPDSS: split overlay sysfs code
  OMAPDSS: split manager sysfs code
  OMAPDSS: clean up dss_mgr_set_lcd_config
  OMAPDSS: clean up dss_mgr_set_timings
  Revert OMAPDSS: APPLY: add fifo-merge support
  Revert OMAPDSS: APPLY: add fifo merge support funcs
  OMAPDSS: remove extra_info completion code
  OMAPDSS: Improve fifo management code
  OMAPDSS: Use WB fifo for GFX overlay

 drivers/video/omap/hwa742.c |1 -
 drivers/video/omap/lcd_ams_delta.c  |1 -
 drivers/video/omap/lcd_palmte.c |1 -
 drivers/video/omap/omapfb_main.c|9 -
 drivers/video/omap2/displays/panel-taal.c   |  215 ++--
 drivers/video/omap2/displays/panel-tfp410.c |   14 +-
 drivers/video/omap2/dss/Makefile|2 +-
 drivers/video/omap2/dss/apply.c |  298 +---
 drivers/video/omap2/dss/dispc.c |   68 +++-
 drivers/video/omap2/dss/dispc.h |4 +
 drivers/video/omap2/dss/dpi.c   |1 -
 drivers/video/omap2/dss/dsi.c   |1 -
 drivers/video/omap2/dss/dss.c   |1 -
 drivers/video/omap2/dss/dss.h   |7 +
 drivers/video/omap2/dss/manager-sysfs.c |  499 +++
 drivers/video/omap2/dss/manager.c   |  462 +
 drivers/video/omap2/dss/overlay-sysfs.c |  456 
 drivers/video/omap2/dss/overlay.c   |  421 +-
 drivers/video/omap2/dss/venc.c  |1 -
 drivers/video/omap2/omapfb/omapfb-main.c|   26 ++
 drivers/video/omap2/vram.c  |   56 ---
 include/video/omapdss.h |1 +
 22 files changed, 1180 insertions(+), 1365 deletions(-)
 create mode 100644 drivers/video/omap2/dss/manager-sysfs.c
 create mode 100644 drivers/video/omap2/dss/overlay-sysfs.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 01/17] OMAPDSS: Taal: use devm_* functions

2012-09-05 Thread Tomi Valkeinen
Use devm_ functions in panel-taal.c's probe when possible. Also reorder
the initialization sequence so that devm_ allocations are done before
things that require explicit freeing. This simplifies the probe and
remove functions.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/displays/panel-taal.c |  118 +++--
 1 file changed, 44 insertions(+), 74 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index 7b2d7bb..1255864 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -865,10 +865,8 @@ static int taal_probe(struct omap_dss_device *dssdev)
 
dev_dbg(dssdev-dev, probe\n);
 
-   if (!panel_data || !panel_data-name) {
-   r = -EINVAL;
-   goto err;
-   }
+   if (!panel_data || !panel_data-name)
+   return -EINVAL;
 
for (i = 0; i  ARRAY_SIZE(panel_configs); i++) {
if (strcmp(panel_data-name, panel_configs[i].name) == 0) {
@@ -877,21 +875,17 @@ static int taal_probe(struct omap_dss_device *dssdev)
}
}
 
-   if (!panel_config) {
-   r = -EINVAL;
-   goto err;
-   }
+   if (!panel_config)
+   return -EINVAL;
 
dssdev-panel.timings = panel_config-timings;
dssdev-panel.dsi_pix_fmt = OMAP_DSS_DSI_FMT_RGB888;
dssdev-caps = OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE |
OMAP_DSS_DISPLAY_CAP_TEAR_ELIM;
 
-   td = kzalloc(sizeof(*td), GFP_KERNEL);
-   if (!td) {
-   r = -ENOMEM;
-   goto err;
-   }
+   td = devm_kzalloc(dssdev-dev, sizeof(*td), GFP_KERNEL);
+   if (!td)
+   return -ENOMEM;
td-dssdev = dssdev;
td-panel_config = panel_config;
td-esd_interval = panel_data-esd_interval;
@@ -902,26 +896,51 @@ static int taal_probe(struct omap_dss_device *dssdev)
 
atomic_set(td-do_update, 0);
 
-   td-workqueue = create_singlethread_workqueue(taal_esd);
-   if (td-workqueue == NULL) {
-   dev_err(dssdev-dev, can't create ESD workqueue\n);
-   r = -ENOMEM;
-   goto err_wq;
-   }
-   INIT_DELAYED_WORK_DEFERRABLE(td-esd_work, taal_esd_work);
-   INIT_DELAYED_WORK(td-ulps_work, taal_ulps_work);
-
dev_set_drvdata(dssdev-dev, td);
 
if (gpio_is_valid(panel_data-reset_gpio)) {
-   r = gpio_request_one(panel_data-reset_gpio, GPIOF_OUT_INIT_LOW,
-   taal rst);
+   r = devm_gpio_request_one(dssdev-dev, panel_data-reset_gpio,
+   GPIOF_OUT_INIT_LOW, taal rst);
if (r) {
dev_err(dssdev-dev, failed to request reset gpio\n);
-   goto err_rst_gpio;
+   return r;
}
}
 
+   if (panel_data-use_ext_te) {
+   int gpio = panel_data-ext_te_gpio;
+
+   r = devm_gpio_request_one(dssdev-dev, gpio, GPIOF_IN,
+   taal irq);
+   if (r) {
+   dev_err(dssdev-dev, GPIO request failed\n);
+   return r;
+   }
+
+   r = devm_request_irq(dssdev-dev, gpio_to_irq(gpio),
+   taal_te_isr,
+   IRQF_TRIGGER_RISING,
+   taal vsync, dssdev);
+
+   if (r) {
+   dev_err(dssdev-dev, IRQ request failed\n);
+   return r;
+   }
+
+   INIT_DELAYED_WORK_DEFERRABLE(td-te_timeout_work,
+   taal_te_timeout_work_callback);
+
+   dev_dbg(dssdev-dev, Using GPIO TE\n);
+   }
+
+   td-workqueue = create_singlethread_workqueue(taal_esd);
+   if (td-workqueue == NULL) {
+   dev_err(dssdev-dev, can't create ESD workqueue\n);
+   return -ENOMEM;
+   }
+   INIT_DELAYED_WORK_DEFERRABLE(td-esd_work, taal_esd_work);
+   INIT_DELAYED_WORK(td-ulps_work, taal_ulps_work);
+
taal_hw_reset(dssdev);
 
if (panel_data-use_dsi_backlight) {
@@ -945,31 +964,6 @@ static int taal_probe(struct omap_dss_device *dssdev)
taal_bl_update_status(bldev);
}
 
-   if (panel_data-use_ext_te) {
-   int gpio = panel_data-ext_te_gpio;
-
-   r = gpio_request_one(gpio, GPIOF_IN, taal irq);
-   if (r) {
-   dev_err(dssdev-dev, GPIO request failed\n);
-   goto err_gpio;
-   }
-
-   r = request_irq(gpio_to_irq(gpio), taal_te_isr,
-   IRQF_TRIGGER_RISING,
-   taal vsync, dssdev);
-
-   if (r) {
-   dev_err(dssdev-dev, IRQ request 

[PATCH 04/17] OMAPDSS: remove unnecessary includes

2012-09-05 Thread Tomi Valkeinen
Remove unnecessary includes from omapdss.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/dispc.c   |2 --
 drivers/video/omap2/dss/dpi.c |1 -
 drivers/video/omap2/dss/dsi.c |1 -
 drivers/video/omap2/dss/dss.c |1 -
 drivers/video/omap2/dss/overlay.c |1 -
 drivers/video/omap2/dss/venc.c|1 -
 6 files changed, 7 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 0de9a7e..e934abb 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -37,8 +37,6 @@
 #include linux/platform_device.h
 #include linux/pm_runtime.h
 
-#include plat/clock.h
-
 #include video/omapdss.h
 
 #include dss.h
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 25fb895..99b9851 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -31,7 +31,6 @@
 #include linux/regulator/consumer.h
 
 #include video/omapdss.h
-#include plat/cpu.h
 
 #include dss.h
 #include dss_features.h
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 254666f..8d815e3 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -41,7 +41,6 @@
 
 #include video/omapdss.h
 #include video/mipi_display.h
-#include plat/clock.h
 
 #include dss.h
 #include dss_features.h
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 31a553a..759dbee 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -36,7 +36,6 @@
 #include video/omapdss.h
 
 #include plat/cpu.h
-#include plat/clock.h
 
 #include dss.h
 #include dss_features.h
diff --git a/drivers/video/omap2/dss/overlay.c 
b/drivers/video/omap2/dss/overlay.c
index 952c6fa..94e74be 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -32,7 +32,6 @@
 #include linux/slab.h
 
 #include video/omapdss.h
-#include plat/cpu.h
 
 #include dss.h
 #include dss_features.h
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 4a6caf9..45252cf 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -36,7 +36,6 @@
 #include linux/pm_runtime.h
 
 #include video/omapdss.h
-#include plat/cpu.h
 
 #include dss.h
 #include dss_features.h
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 03/17] OMAPFB1: remove a non-used table

2012-09-05 Thread Tomi Valkeinen
The old omapfb driver contains a table for DMA element types, which is
not used. Remove it.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap/omapfb_main.c |9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index f54b463..4351c43 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -131,15 +131,6 @@ static void omapfb_rqueue_unlock(struct omapfb_device 
*fbdev)
  * LCD controller and LCD DMA
  * ---
  */
-/* Lookup table to map elem size to elem type. */
-static const int dma_elem_type[] = {
-   0,
-   OMAP_DMA_DATA_TYPE_S8,
-   OMAP_DMA_DATA_TYPE_S16,
-   0,
-   OMAP_DMA_DATA_TYPE_S32,
-};
-
 /*
  * Allocate resources needed for LCD controller and LCD DMA operations. Video
  * memory is allocated from system memory according to the virtual display
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 06/17] OMAPDSS: VRAM: Remove clearing with sDMA

2012-09-05 Thread Tomi Valkeinen
Currently vram.c clears the allocated memory automatically using OMAP
system DMA. In an effort to reduce OMAP dependencies, we'll do the
memory clear with CPU from now on.

The previous patch implemented memory clear in the omapfb driver, and
this patch removes the now obsolete clear functionality from vram.c.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
---
 drivers/video/omap2/vram.c |   56 
 1 file changed, 56 deletions(-)

diff --git a/drivers/video/omap2/vram.c b/drivers/video/omap2/vram.c
index 87e421e..f2b15c4 100644
--- a/drivers/video/omap2/vram.c
+++ b/drivers/video/omap2/vram.c
@@ -34,7 +34,6 @@
 #include asm/setup.h
 
 #include plat/vram.h
-#include plat/dma.h
 
 #ifdef DEBUG
 #define DBG(format, ...) pr_debug(VRAM:  format, ## __VA_ARGS__)
@@ -250,59 +249,6 @@ int omap_vram_reserve(unsigned long paddr, size_t size)
 }
 EXPORT_SYMBOL(omap_vram_reserve);
 
-static void _omap_vram_dma_cb(int lch, u16 ch_status, void *data)
-{
-   struct completion *compl = data;
-   complete(compl);
-}
-
-static int _omap_vram_clear(u32 paddr, unsigned pages)
-{
-   struct completion compl;
-   unsigned elem_count;
-   unsigned frame_count;
-   int r;
-   int lch;
-
-   init_completion(compl);
-
-   r = omap_request_dma(OMAP_DMA_NO_DEVICE, VRAM DMA,
-   _omap_vram_dma_cb,
-   compl, lch);
-   if (r) {
-   pr_err(VRAM: request_dma failed for memory clear\n);
-   return -EBUSY;
-   }
-
-   elem_count = pages * PAGE_SIZE / 4;
-   frame_count = 1;
-
-   omap_set_dma_transfer_params(lch, OMAP_DMA_DATA_TYPE_S32,
-   elem_count, frame_count,
-   OMAP_DMA_SYNC_ELEMENT,
-   0, 0);
-
-   omap_set_dma_dest_params(lch, 0, OMAP_DMA_AMODE_POST_INC,
-   paddr, 0, 0);
-
-   omap_set_dma_color_mode(lch, OMAP_DMA_CONSTANT_FILL, 0x00);
-
-   omap_start_dma(lch);
-
-   if (wait_for_completion_timeout(compl, msecs_to_jiffies(1000)) == 0) {
-   omap_stop_dma(lch);
-   pr_err(VRAM: dma timeout while clearing memory\n);
-   r = -EIO;
-   goto err;
-   }
-
-   r = 0;
-err:
-   omap_free_dma(lch);
-
-   return r;
-}
-
 static int _omap_vram_alloc(unsigned pages, unsigned long *paddr)
 {
struct vram_region *rm;
@@ -337,8 +283,6 @@ found:
 
*paddr = start;
 
-   _omap_vram_clear(start, pages);
-
return 0;
}
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 08/17] OMAPDSS: TFP410: use devm_gpio_request_one

2012-09-05 Thread Tomi Valkeinen
Use devm_ version instead of the regular gpio_request_one to simplify
the error handling.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/displays/panel-tfp410.c |   14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-tfp410.c 
b/drivers/video/omap2/displays/panel-tfp410.c
index 4be9a59..383811c 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -119,8 +119,8 @@ static int tfp410_probe(struct omap_dss_device *dssdev)
}
 
if (gpio_is_valid(ddata-pd_gpio)) {
-   r = gpio_request_one(ddata-pd_gpio, GPIOF_OUT_INIT_LOW,
-   tfp410 pd);
+   r = devm_gpio_request_one(dssdev-dev, ddata-pd_gpio,
+   GPIOF_OUT_INIT_LOW, tfp410 pd);
if (r) {
dev_err(dssdev-dev, Failed to request PD GPIO %d\n,
ddata-pd_gpio);
@@ -135,8 +135,7 @@ static int tfp410_probe(struct omap_dss_device *dssdev)
if (!adapter) {
dev_err(dssdev-dev, Failed to get I2C adapter, bus 
%d\n,
i2c_bus_num);
-   r = -EINVAL;
-   goto err_i2c;
+   return -EINVAL;
}
 
ddata-i2c_adapter = adapter;
@@ -145,10 +144,6 @@ static int tfp410_probe(struct omap_dss_device *dssdev)
dev_set_drvdata(dssdev-dev, ddata);
 
return 0;
-err_i2c:
-   if (gpio_is_valid(ddata-pd_gpio))
-   gpio_free(ddata-pd_gpio);
-   return r;
 }
 
 static void __exit tfp410_remove(struct omap_dss_device *dssdev)
@@ -160,9 +155,6 @@ static void __exit tfp410_remove(struct omap_dss_device 
*dssdev)
if (ddata-i2c_adapter)
i2c_put_adapter(ddata-i2c_adapter);
 
-   if (gpio_is_valid(ddata-pd_gpio))
-   gpio_free(ddata-pd_gpio);
-
dev_set_drvdata(dssdev-dev, NULL);
 
mutex_unlock(ddata-lock);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 07/17] OMAPDSS: Taal: Reogranize for device tree

2012-09-05 Thread Tomi Valkeinen
Reorganize taal driver to make it easier to integrate device tree code.
Instead of storing the panel's platform data, we'll parse the platform
data and store the required information in driver's own data. This way
adding device tree data parsing is simple.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/displays/panel-taal.c |  127 +
 1 file changed, 74 insertions(+), 53 deletions(-)

diff --git a/drivers/video/omap2/displays/panel-taal.c 
b/drivers/video/omap2/displays/panel-taal.c
index 1255864..4cf9416 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -121,6 +121,18 @@ struct taal_data {
 
struct omap_dss_device *dssdev;
 
+   /* panel specific HW info */
+   struct panel_config *panel_config;
+
+   /* panel HW configuration from DT or platform data */
+   int reset_gpio;
+   int ext_te_gpio;
+
+   bool use_dsi_backlight;
+
+   struct omap_dsi_pin_config pin_config;
+
+   /* runtime variables */
bool enabled;
u8 rotate;
bool mirror;
@@ -145,16 +157,8 @@ struct taal_data {
bool ulps_enabled;
unsigned ulps_timeout;
struct delayed_work ulps_work;
-
-   struct panel_config *panel_config;
 };
 
-static inline struct nokia_dsi_panel_data
-*get_panel_data(const struct omap_dss_device *dssdev)
-{
-   return (struct nokia_dsi_panel_data *) dssdev-data;
-}
-
 static void taal_esd_work(struct work_struct *work);
 static void taal_ulps_work(struct work_struct *work);
 
@@ -371,7 +375,6 @@ static void taal_cancel_ulps_work(struct omap_dss_device 
*dssdev)
 static int taal_enter_ulps(struct omap_dss_device *dssdev)
 {
struct taal_data *td = dev_get_drvdata(dssdev-dev);
-   struct nokia_dsi_panel_data *panel_data = get_panel_data(dssdev);
int r;
 
if (td-ulps_enabled)
@@ -383,7 +386,8 @@ static int taal_enter_ulps(struct omap_dss_device *dssdev)
if (r)
goto err;
 
-   disable_irq(gpio_to_irq(panel_data-ext_te_gpio));
+   if (gpio_is_valid(td-ext_te_gpio))
+   disable_irq(gpio_to_irq(td-ext_te_gpio));
 
omapdss_dsi_display_disable(dssdev, false, true);
 
@@ -405,7 +409,6 @@ err:
 static int taal_exit_ulps(struct omap_dss_device *dssdev)
 {
struct taal_data *td = dev_get_drvdata(dssdev-dev);
-   struct nokia_dsi_panel_data *panel_data = get_panel_data(dssdev);
int r;
 
if (!td-ulps_enabled)
@@ -425,7 +428,8 @@ static int taal_exit_ulps(struct omap_dss_device *dssdev)
goto err2;
}
 
-   enable_irq(gpio_to_irq(panel_data-ext_te_gpio));
+   if (gpio_is_valid(td-ext_te_gpio))
+   enable_irq(gpio_to_irq(td-ext_te_gpio));
 
taal_queue_ulps_work(dssdev);
 
@@ -438,7 +442,8 @@ err2:
 
r = taal_panel_reset(dssdev);
if (!r) {
-   enable_irq(gpio_to_irq(panel_data-ext_te_gpio));
+   if (gpio_is_valid(td-ext_te_gpio))
+   enable_irq(gpio_to_irq(td-ext_te_gpio));
td-ulps_enabled = false;
}
 err1:
@@ -835,71 +840,93 @@ static struct attribute_group taal_attr_group = {
 static void taal_hw_reset(struct omap_dss_device *dssdev)
 {
struct taal_data *td = dev_get_drvdata(dssdev-dev);
-   struct nokia_dsi_panel_data *panel_data = get_panel_data(dssdev);
 
-   if (panel_data-reset_gpio == -1)
+   if (!gpio_is_valid(td-reset_gpio))
return;
 
-   gpio_set_value(panel_data-reset_gpio, 1);
+   gpio_set_value(td-reset_gpio, 1);
if (td-panel_config-reset_sequence.high)
udelay(td-panel_config-reset_sequence.high);
/* reset the panel */
-   gpio_set_value(panel_data-reset_gpio, 0);
+   gpio_set_value(td-reset_gpio, 0);
/* assert reset */
if (td-panel_config-reset_sequence.low)
udelay(td-panel_config-reset_sequence.low);
-   gpio_set_value(panel_data-reset_gpio, 1);
+   gpio_set_value(td-reset_gpio, 1);
/* wait after releasing reset */
if (td-panel_config-sleep.hw_reset)
msleep(td-panel_config-sleep.hw_reset);
 }
 
+static void taal_probe_pdata(struct taal_data *td,
+   const struct nokia_dsi_panel_data *pdata)
+{
+   td-reset_gpio = pdata-reset_gpio;
+
+   if (pdata-use_ext_te)
+   td-ext_te_gpio = pdata-ext_te_gpio;
+   else
+   td-ext_te_gpio = -1;
+
+   td-esd_interval = pdata-esd_interval;
+   td-ulps_timeout = pdata-ulps_timeout;
+
+   td-use_dsi_backlight = pdata-use_dsi_backlight;
+
+   td-pin_config = pdata-pin_config;
+}
+
 static int taal_probe(struct omap_dss_device *dssdev)
 {
struct backlight_properties props;
struct taal_data *td;
struct backlight_device *bldev = NULL;
-   struct nokia_dsi_panel_data *panel_data = get_panel_data(dssdev);
-  

[PATCH 05/17] OMAPFB: clear framebuffers with CPU

2012-09-05 Thread Tomi Valkeinen
Currently vram.c clears the allocated memory automatically using OMAP
system DMA. In an effort to reduce OMAP dependencies, we'll do the
memory clear with CPU from now on.

This patch implements clearing of the framebuffer in omapfb, using
cfb_fillrect() to do the actual clear.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/omapfb/omapfb-main.c |   26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c 
b/drivers/video/omap2/omapfb/omapfb-main.c
index fc671d3..7afdfcf 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1592,6 +1592,20 @@ static int omapfb_allocate_all_fbs(struct omapfb2_device 
*fbdev)
return 0;
 }
 
+static void omapfb_clear_fb(struct fb_info *fbi)
+{
+   const struct fb_fillrect rect = {
+   .dx = 0,
+   .dy = 0,
+   .width = fbi-var.xres_virtual,
+   .height = fbi-var.yres_virtual,
+   .color = 0,
+   .rop = ROP_COPY,
+   };
+
+   cfb_fillrect(fbi, rect);
+}
+
 int omapfb_realloc_fbmem(struct fb_info *fbi, unsigned long size, int type)
 {
struct omapfb_info *ofbi = FB2OFB(fbi);
@@ -1661,6 +1675,8 @@ int omapfb_realloc_fbmem(struct fb_info *fbi, unsigned 
long size, int type)
goto err;
}
 
+   omapfb_clear_fb(fbi);
+
return 0;
 err:
omapfb_free_fbmem(fbi);
@@ -1972,6 +1988,16 @@ static int omapfb_create_framebuffers(struct 
omapfb2_device *fbdev)
}
}
 
+   for (i = 0; i  fbdev-num_fbs; i++) {
+   struct fb_info *fbi = fbdev-fbs[i];
+   struct omapfb_info *ofbi = FB2OFB(fbi);
+
+   if (ofbi-region-size == 0)
+   continue;
+
+   omapfb_clear_fb(fbi);
+   }
+
/* Enable fb0 */
if (fbdev-num_fbs  0) {
struct omapfb_info *ofbi = FB2OFB(fbdev-fbs[0]);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 15/17] OMAPDSS: remove extra_info completion code

2012-09-05 Thread Tomi Valkeinen
Now that fifo merge has been removed, nobody uses the extra_info related
completion code, which can be removed.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/apply.c |   69 ---
 1 file changed, 69 deletions(-)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 32b5379..2579d15 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -118,7 +118,6 @@ static struct {
 static spinlock_t data_lock;
 /* lock for blocking functions */
 static DEFINE_MUTEX(apply_lock);
-static DECLARE_COMPLETION(extra_updated_completion);
 
 static void dss_register_vsync_isr(void);
 
@@ -355,69 +354,6 @@ static bool need_go(struct omap_overlay_manager *mgr)
return false;
 }
 
-/* returns true if an extra_info field is currently being updated */
-static bool extra_info_update_ongoing(void)
-{
-   const int num_mgrs = dss_feat_get_num_mgrs();
-   int i;
-
-   for (i = 0; i  num_mgrs; ++i) {
-   struct omap_overlay_manager *mgr;
-   struct omap_overlay *ovl;
-   struct mgr_priv_data *mp;
-
-   mgr = omap_dss_get_overlay_manager(i);
-   mp = get_mgr_priv(mgr);
-
-   if (!mp-enabled)
-   continue;
-
-   if (!mp-updating)
-   continue;
-
-   if (mp-extra_info_dirty || mp-shadow_extra_info_dirty)
-   return true;
-
-   list_for_each_entry(ovl, mgr-overlays, list) {
-   struct ovl_priv_data *op = get_ovl_priv(ovl);
-
-   if (op-extra_info_dirty || op-shadow_extra_info_dirty)
-   return true;
-   }
-   }
-
-   return false;
-}
-
-/* wait until no extra_info updates are pending */
-static void wait_pending_extra_info_updates(void)
-{
-   bool updating;
-   unsigned long flags;
-   unsigned long t;
-   int r;
-
-   spin_lock_irqsave(data_lock, flags);
-
-   updating = extra_info_update_ongoing();
-
-   if (!updating) {
-   spin_unlock_irqrestore(data_lock, flags);
-   return;
-   }
-
-   init_completion(extra_updated_completion);
-
-   spin_unlock_irqrestore(data_lock, flags);
-
-   t = msecs_to_jiffies(500);
-   r = wait_for_completion_timeout(extra_updated_completion, t);
-   if (r == 0)
-   DSSWARN(timeout in wait_pending_extra_info_updates\n);
-   else if (r  0)
-   DSSERR(wait_pending_extra_info_updates failed: %d\n, r);
-}
-
 int dss_mgr_wait_for_go(struct omap_overlay_manager *mgr)
 {
unsigned long timeout = msecs_to_jiffies(500);
@@ -823,7 +759,6 @@ static void dss_apply_irq_handler(void *data, u32 mask)
 {
const int num_mgrs = dss_feat_get_num_mgrs();
int i;
-   bool extra_updating;
 
spin_lock(data_lock);
 
@@ -854,10 +789,6 @@ static void dss_apply_irq_handler(void *data, u32 mask)
dss_write_regs();
dss_set_go_bits();
 
-   extra_updating = extra_info_update_ongoing();
-   if (!extra_updating)
-   complete_all(extra_updated_completion);
-
if (!need_isr())
dss_unregister_vsync_isr();
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 16/17] OMAPDSS: Improve fifo management code

2012-09-05 Thread Tomi Valkeinen
OMAP4+ allows assigning the overlay FIFOs freely, but that is not
supported by omapdss yet. This patch takes a step forward by improving
the fifo management to be more flexible.

dispc.c is changed to keep track of the sizes of each fifo, and also the
overlay using each fifo.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   39 +++
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e934abb..dc0f372 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -94,8 +94,11 @@ struct dispc_features {
u16 pos_x, unsigned long *core_clk);
unsigned long (*calc_core_clk) (enum omap_channel channel,
u16 width, u16 height, u16 out_width, u16 out_height);
+   u8 num_fifos;
 };
 
+#define DISPC_MAX_NR_FIFOS 5
+
 static struct {
struct platform_device *pdev;
void __iomem*base;
@@ -105,7 +108,9 @@ static struct {
int irq;
struct clk *dss_clk;
 
-   u32 fifo_size[MAX_DSS_OVERLAYS];
+   u32 fifo_size[DISPC_MAX_NR_FIFOS];
+   /* maps which plane is using a fifo. fifo-id - plane-id */
+   int fifo_assignment[DISPC_MAX_NR_FIFOS];
 
spinlock_t irq_lock;
u32 irq_error_mask;
@@ -1061,10 +1066,10 @@ static void dispc_mgr_set_size(enum omap_channel 
channel, u16 width,
dispc_write_reg(DISPC_SIZE_MGR(channel), val);
 }
 
-static void dispc_read_plane_fifo_sizes(void)
+static void dispc_init_fifos(void)
 {
u32 size;
-   int plane;
+   int fifo;
u8 start, end;
u32 unit;
 
@@ -1072,16 +1077,30 @@ static void dispc_read_plane_fifo_sizes(void)
 
dss_feat_get_reg_field(FEAT_REG_FIFOSIZE, start, end);
 
-   for (plane = 0; plane  dss_feat_get_num_ovls(); ++plane) {
-   size = REG_GET(DISPC_OVL_FIFO_SIZE_STATUS(plane), start, end);
+   for (fifo = 0; fifo  dispc.feat-num_fifos; ++fifo) {
+   size = REG_GET(DISPC_OVL_FIFO_SIZE_STATUS(fifo), start, end);
size *= unit;
-   dispc.fifo_size[plane] = size;
+   dispc.fifo_size[fifo] = size;
+
+   /*
+* By default fifos are mapped directly to overlays, fifo 0 to
+* ovl 0, fifo 1 to ovl 1, etc.
+*/
+   dispc.fifo_assignment[fifo] = fifo;
}
 }
 
 static u32 dispc_ovl_get_fifo_size(enum omap_plane plane)
 {
-   return dispc.fifo_size[plane];
+   int fifo;
+   u32 size = 0;
+
+   for (fifo = 0; fifo  dispc.feat-num_fifos; ++fifo) {
+   if (dispc.fifo_assignment[fifo] == plane)
+   size += dispc.fifo_size[fifo];
+   }
+
+   return size;
 }
 
 void dispc_ovl_set_fifo_threshold(enum omap_plane plane, u32 low, u32 high)
@@ -3708,7 +3727,7 @@ static void _omap_dispc_initial_config(void)
 
dispc_set_loadmode(OMAP_DSS_LOAD_FRAME_ONLY);
 
-   dispc_read_plane_fifo_sizes();
+   dispc_init_fifos();
 
dispc_configure_burst_sizes();
 
@@ -3724,6 +3743,7 @@ static const struct dispc_features omap24xx_dispc_feats 
__initconst = {
.hp_max =   256,
.calc_scaling   =   dispc_ovl_calc_scaling_24xx,
.calc_core_clk  =   calc_core_clk_24xx,
+   .num_fifos  =   3,
 };
 
 static const struct dispc_features omap34xx_rev1_0_dispc_feats __initconst = {
@@ -3735,6 +3755,7 @@ static const struct dispc_features 
omap34xx_rev1_0_dispc_feats __initconst = {
.hp_max =   256,
.calc_scaling   =   dispc_ovl_calc_scaling_34xx,
.calc_core_clk  =   calc_core_clk_34xx,
+   .num_fifos  =   3,
 };
 
 static const struct dispc_features omap34xx_rev3_0_dispc_feats __initconst = {
@@ -3746,6 +3767,7 @@ static const struct dispc_features 
omap34xx_rev3_0_dispc_feats __initconst = {
.hp_max =   4096,
.calc_scaling   =   dispc_ovl_calc_scaling_34xx,
.calc_core_clk  =   calc_core_clk_34xx,
+   .num_fifos  =   3,
 };
 
 static const struct dispc_features omap44xx_dispc_feats __initconst = {
@@ -3757,6 +3779,7 @@ static const struct dispc_features omap44xx_dispc_feats 
__initconst = {
.hp_max =   4096,
.calc_scaling   =   dispc_ovl_calc_scaling_44xx,
.calc_core_clk  =   calc_core_clk_44xx,
+   .num_fifos  =   5,
 };
 
 static int __init dispc_init_features(struct device *dev)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 14/17] Revert OMAPDSS: APPLY: add fifo merge support funcs

2012-09-05 Thread Tomi Valkeinen
This reverts commit fb0119742291b6f30cd97026ee137b2d3d1f4de8.

Adding fifo merge feature as an omapdss internal configuration was a
mistake. We cannot hide from the users of omapdss the complexities of
fifo merge.

The previous commit removed fifo merge itself, and this removes the
remaining fifo merge support functions.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/apply.c |   43 ---
 1 file changed, 43 deletions(-)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 02943a5..32b5379 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -111,9 +111,6 @@ static struct {
struct ovl_priv_data ovl_priv_data_array[MAX_DSS_OVERLAYS];
struct mgr_priv_data mgr_priv_data_array[MAX_DSS_MANAGERS];
 
-   bool fifo_merge_dirty;
-   bool fifo_merge;
-
bool irq_enabled;
 } dss_data;
 
@@ -677,40 +674,11 @@ static void dss_mgr_write_regs_extra(struct 
omap_overlay_manager *mgr)
mp-shadow_extra_info_dirty = true;
 }
 
-static void dss_write_regs_common(void)
-{
-   const int num_mgrs = omap_dss_get_num_overlay_managers();
-   int i;
-
-   if (!dss_data.fifo_merge_dirty)
-   return;
-
-   for (i = 0; i  num_mgrs; ++i) {
-   struct omap_overlay_manager *mgr;
-   struct mgr_priv_data *mp;
-
-   mgr = omap_dss_get_overlay_manager(i);
-   mp = get_mgr_priv(mgr);
-
-   if (mp-enabled) {
-   if (dss_data.fifo_merge_dirty) {
-   dispc_enable_fifomerge(dss_data.fifo_merge);
-   dss_data.fifo_merge_dirty = false;
-   }
-
-   if (mp-updating)
-   mp-shadow_info_dirty = true;
-   }
-   }
-}
-
 static void dss_write_regs(void)
 {
const int num_mgrs = omap_dss_get_num_overlay_managers();
int i;
 
-   dss_write_regs_common();
-
for (i = 0; i  num_mgrs; ++i) {
struct omap_overlay_manager *mgr;
struct mgr_priv_data *mp;
@@ -799,8 +767,6 @@ void dss_mgr_start_update(struct omap_overlay_manager *mgr)
dss_mgr_write_regs(mgr);
dss_mgr_write_regs_extra(mgr);
 
-   dss_write_regs_common();
-
mp-updating = true;
 
if (!dss_data.irq_enabled  need_isr())
@@ -984,15 +950,6 @@ static void dss_apply_ovl_fifo_thresholds(struct 
omap_overlay *ovl,
op-extra_info_dirty = true;
 }
 
-static void dss_apply_fifo_merge(bool use_fifo_merge)
-{
-   if (dss_data.fifo_merge == use_fifo_merge)
-   return;
-
-   dss_data.fifo_merge = use_fifo_merge;
-   dss_data.fifo_merge_dirty = true;
-}
-
 static void dss_ovl_setup_fifo(struct omap_overlay *ovl)
 {
struct ovl_priv_data *op = get_ovl_priv(ovl);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 17/17] OMAPDSS: Use WB fifo for GFX overlay

2012-09-05 Thread Tomi Valkeinen
OMAP4's GFX overlay has smaller fifo than the rest of the overlays
(including writeback overlay). This seems to be the reason for
underflows in some more demanding scenarios.

We can avoid the problems by using the WB fifo for GFX overlay, and vice
versa. WB usage is not supported yet, but when it will, it should
perform just fine with smaller fifo as there are no hard realtime
constraints with WB.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/dispc.c |   27 +++
 drivers/video/omap2/dss/dispc.h |4 
 include/video/omapdss.h |1 +
 3 files changed, 32 insertions(+)

diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index dc0f372..d512c38 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -95,6 +95,9 @@ struct dispc_features {
unsigned long (*calc_core_clk) (enum omap_channel channel,
u16 width, u16 height, u16 out_width, u16 out_height);
u8 num_fifos;
+
+   /* swap GFX  WB fifos */
+   bool gfx_fifo_workaround:1;
 };
 
 #define DISPC_MAX_NR_FIFOS 5
@@ -1088,6 +1091,29 @@ static void dispc_init_fifos(void)
 */
dispc.fifo_assignment[fifo] = fifo;
}
+
+   /*
+* The GFX fifo on OMAP4 is smaller than the other fifos. The small fifo
+* causes problems with certain use cases, like using the tiler in 2D
+* mode. The below hack swaps the fifos of GFX and WB planes, thus
+* giving GFX plane a larger fifo. WB but should work fine with a
+* smaller fifo.
+*/
+   if (dispc.feat-gfx_fifo_workaround) {
+   u32 v;
+
+   v = dispc_read_reg(DISPC_GLOBAL_BUFFER);
+
+   v = FLD_MOD(v, 4, 2, 0); /* GFX BUF top to WB */
+   v = FLD_MOD(v, 4, 5, 3); /* GFX BUF bottom to WB */
+   v = FLD_MOD(v, 0, 26, 24); /* WB BUF top to GFX */
+   v = FLD_MOD(v, 0, 29, 27); /* WB BUF bottom to GFX */
+
+   dispc_write_reg(DISPC_GLOBAL_BUFFER, v);
+
+   dispc.fifo_assignment[OMAP_DSS_GFX] = OMAP_DSS_WB;
+   dispc.fifo_assignment[OMAP_DSS_WB] = OMAP_DSS_GFX;
+   }
 }
 
 static u32 dispc_ovl_get_fifo_size(enum omap_plane plane)
@@ -3780,6 +3806,7 @@ static const struct dispc_features omap44xx_dispc_feats 
__initconst = {
.calc_scaling   =   dispc_ovl_calc_scaling_44xx,
.calc_core_clk  =   calc_core_clk_44xx,
.num_fifos  =   5,
+   .gfx_fifo_workaround=   true,
 };
 
 static int __init dispc_init_features(struct device *dev)
diff --git a/drivers/video/omap2/dss/dispc.h b/drivers/video/omap2/dss/dispc.h
index 92d8a9b..42e56cc 100644
--- a/drivers/video/omap2/dss/dispc.h
+++ b/drivers/video/omap2/dss/dispc.h
@@ -36,6 +36,7 @@
 #define DISPC_CONTROL2 0x0238
 #define DISPC_CONFIG2  0x0620
 #define DISPC_DIVISOR  0x0804
+#define DISPC_GLOBAL_BUFFER0x0800
 #define DISPC_CONTROL3  0x0848
 #define DISPC_CONFIG3   0x084C
 
@@ -355,6 +356,8 @@ static inline u16 DISPC_OVL_BASE(enum omap_plane plane)
return 0x014C;
case OMAP_DSS_VIDEO3:
return 0x0300;
+   case OMAP_DSS_WB:
+   return 0x0500;
default:
BUG();
return 0;
@@ -517,6 +520,7 @@ static inline u16 DISPC_FIFO_SIZE_STATUS_OFFSET(enum 
omap_plane plane)
case OMAP_DSS_VIDEO2:
return 0x0018;
case OMAP_DSS_VIDEO3:
+   case OMAP_DSS_WB:
return 0x0088;
default:
BUG();
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 24a7fa1..ac2e4cc 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -73,6 +73,7 @@ enum omap_plane {
OMAP_DSS_VIDEO1 = 1,
OMAP_DSS_VIDEO2 = 2,
OMAP_DSS_VIDEO3 = 3,
+   OMAP_DSS_WB = 4,
 };
 
 enum omap_channel {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 12/17] OMAPDSS: clean up dss_mgr_set_timings

2012-09-05 Thread Tomi Valkeinen
dss_mgr_set_timings() can only be called when the output is not active.
This means that most of the code in the function is extra, as there's no
need to write the values to registers, etc, because that will be handled
when the output will be enabled.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/apply.c |   18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 53629dd..1b49019 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -1314,21 +1314,19 @@ void dss_mgr_set_timings(struct omap_overlay_manager 
*mgr,
const struct omap_video_timings *timings)
 {
unsigned long flags;
-
-   mutex_lock(apply_lock);
+   struct mgr_priv_data *mp = get_mgr_priv(mgr);
 
spin_lock_irqsave(data_lock, flags);
 
-   dss_apply_mgr_timings(mgr, timings);
-
-   dss_write_regs();
-   dss_set_go_bits();
+   if (mp-enabled) {
+   DSSERR(cannot set timings for %s: manager needs to be 
disabled\n,
+   mgr-name);
+   goto out;
+   }
 
+   dss_apply_mgr_timings(mgr, timings);
+out:
spin_unlock_irqrestore(data_lock, flags);
-
-   wait_pending_extra_info_updates();
-
-   mutex_unlock(apply_lock);
 }
 
 static void dss_apply_mgr_lcd_config(struct omap_overlay_manager *mgr,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 11/17] OMAPDSS: clean up dss_mgr_set_lcd_config

2012-09-05 Thread Tomi Valkeinen
dss_mgr_set_lcd_config() can only be called when the output is not
active. This means that most of the code in the function is extra, as
there's no need to write the values to registers, etc, because that will
be handled when the output will be enabled.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/apply.c |   14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 52a5940..53629dd 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -1346,7 +1346,7 @@ void dss_mgr_set_lcd_config(struct omap_overlay_manager 
*mgr,
unsigned long flags;
struct mgr_priv_data *mp = get_mgr_priv(mgr);
 
-   mutex_lock(apply_lock);
+   spin_lock_irqsave(data_lock, flags);
 
if (mp-enabled) {
DSSERR(cannot apply lcd config for %s: manager needs to be 
disabled\n,
@@ -1354,19 +1354,9 @@ void dss_mgr_set_lcd_config(struct omap_overlay_manager 
*mgr,
goto out;
}
 
-   spin_lock_irqsave(data_lock, flags);
-
dss_apply_mgr_lcd_config(mgr, config);
-
-   dss_write_regs();
-   dss_set_go_bits();
-
-   spin_unlock_irqrestore(data_lock, flags);
-
-   wait_pending_extra_info_updates();
-
 out:
-   mutex_unlock(apply_lock);
+   spin_unlock_irqrestore(data_lock, flags);
 }
 
 int dss_ovl_set_info(struct omap_overlay *ovl,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 02/17] OMAPFB1: remove unnecessary includes

2012-09-05 Thread Tomi Valkeinen
Remove unnecessary includes from the old omapfb driver.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap/hwa742.c|1 -
 drivers/video/omap/lcd_ams_delta.c |1 -
 drivers/video/omap/lcd_palmte.c|1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/video/omap/hwa742.c b/drivers/video/omap/hwa742.c
index 9f1d23c..f349ee6 100644
--- a/drivers/video/omap/hwa742.c
+++ b/drivers/video/omap/hwa742.c
@@ -27,7 +27,6 @@
 #include linux/clk.h
 #include linux/interrupt.h
 
-#include plat/dma.h
 #include omapfb.h
 
 #define HWA742_REV_CODE_REG   0x0
diff --git a/drivers/video/omap/lcd_ams_delta.c 
b/drivers/video/omap/lcd_ams_delta.c
index d3a3113..5cca6b3 100644
--- a/drivers/video/omap/lcd_ams_delta.c
+++ b/drivers/video/omap/lcd_ams_delta.c
@@ -28,7 +28,6 @@
 #include linux/gpio.h
 
 #include plat/board-ams-delta.h
-#include mach/hardware.h
 
 #include omapfb.h
 
diff --git a/drivers/video/omap/lcd_palmte.c b/drivers/video/omap/lcd_palmte.c
index 88c31eb..ff4fb62 100644
--- a/drivers/video/omap/lcd_palmte.c
+++ b/drivers/video/omap/lcd_palmte.c
@@ -23,7 +23,6 @@
 #include linux/platform_device.h
 #include linux/io.h
 
-#include plat/fpga.h
 #include omapfb.h
 
 static int palmte_panel_init(struct lcd_panel *panel,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 09/17] OMAPDSS: split overlay sysfs code

2012-09-05 Thread Tomi Valkeinen
Separate sysfs code for overlays to a separate file. This is a bit
cleaner, and will allow us later to easily switch off the sysfs support
via Kconfig option.

Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
 drivers/video/omap2/dss/Makefile|2 +-
 drivers/video/omap2/dss/dss.h   |3 +
 drivers/video/omap2/dss/overlay-sysfs.c |  456 +++
 drivers/video/omap2/dss/overlay.c   |  420 +---
 4 files changed, 462 insertions(+), 419 deletions(-)
 create mode 100644 drivers/video/omap2/dss/overlay-sysfs.c

diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index 30a48fb..927d5ce 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -1,6 +1,6 @@
 obj-$(CONFIG_OMAP2_DSS) += omapdss.o
 omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
-   manager.o overlay.o apply.o
+   manager.o overlay.o overlay-sysfs.o apply.o
 omapdss-$(CONFIG_OMAP2_DSS_DPI) += dpi.o
 omapdss-$(CONFIG_OMAP2_DSS_RFBI) += rfbi.o
 omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o venc_panel.o
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index d6cca82..11b053e 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -265,6 +265,9 @@ int dss_ovl_check(struct omap_overlay *ovl, struct 
omap_overlay_info *info,
const struct omap_video_timings *mgr_timings);
 bool dss_ovl_use_replication(struct dss_lcd_mgr_config config,
enum omap_color_mode mode);
+int dss_overlay_kobj_init(struct omap_overlay *ovl,
+   struct platform_device *pdev);
+void dss_overlay_kobj_uninit(struct omap_overlay *ovl);
 
 /* DSS */
 int dss_init_platform_driver(void) __init;
diff --git a/drivers/video/omap2/dss/overlay-sysfs.c 
b/drivers/video/omap2/dss/overlay-sysfs.c
new file mode 100644
index 000..4cc5dde
--- /dev/null
+++ b/drivers/video/omap2/dss/overlay-sysfs.c
@@ -0,0 +1,456 @@
+/*
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * Some code and ideas taken from drivers/video/omap/ driver
+ * by Imre Deak.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#define DSS_SUBSYS_NAME OVERLAY
+
+#include linux/module.h
+#include linux/err.h
+#include linux/sysfs.h
+#include linux/kobject.h
+#include linux/platform_device.h
+
+#include video/omapdss.h
+
+#include dss.h
+#include dss_features.h
+
+static ssize_t overlay_name_show(struct omap_overlay *ovl, char *buf)
+{
+   return snprintf(buf, PAGE_SIZE, %s\n, ovl-name);
+}
+
+static ssize_t overlay_manager_show(struct omap_overlay *ovl, char *buf)
+{
+   return snprintf(buf, PAGE_SIZE, %s\n,
+   ovl-manager ? ovl-manager-name : none);
+}
+
+static ssize_t overlay_manager_store(struct omap_overlay *ovl, const char *buf,
+   size_t size)
+{
+   int i, r;
+   struct omap_overlay_manager *mgr = NULL;
+   struct omap_overlay_manager *old_mgr;
+   int len = size;
+
+   if (buf[size-1] == '\n')
+   --len;
+
+   if (len  0) {
+   for (i = 0; i  omap_dss_get_num_overlay_managers(); ++i) {
+   mgr = omap_dss_get_overlay_manager(i);
+
+   if (sysfs_streq(buf, mgr-name))
+   break;
+
+   mgr = NULL;
+   }
+   }
+
+   if (len  0  mgr == NULL)
+   return -EINVAL;
+
+   if (mgr)
+   DSSDBG(manager %s found\n, mgr-name);
+
+   if (mgr == ovl-manager)
+   return size;
+
+   old_mgr = ovl-manager;
+
+   r = dispc_runtime_get();
+   if (r)
+   return r;
+
+   /* detach old manager */
+   if (old_mgr) {
+   r = ovl-unset_manager(ovl);
+   if (r) {
+   DSSERR(detach failed\n);
+   goto err;
+   }
+
+   r = old_mgr-apply(old_mgr);
+   if (r)
+   goto err;
+   }
+
+   if (mgr) {
+   r = ovl-set_manager(ovl, mgr);
+   if (r) {
+   DSSERR(Failed to attach overlay\n);
+   goto err;
+   }
+
+   r = mgr-apply(mgr);
+   if (r)
+   goto err;
+   }
+
+   dispc_runtime_put();
+
+

[PATCH v7 0/3] GPMC driver conversion

2012-09-05 Thread Afzal Mohammed
Hi,

Basic gpmc driver conversion series. Driver that is now created out of
gpmc code is a simple one, it handles tasks that were earlier executed
by gpmc_init. Now instead of relying on cpu_is_* checks, it obtains
resources and clk handle in the standard Linux way. The existing gpmc
interface works as was without this series.

HWMOD patch also has been brought into this series back.

As this creates only a basic driver, further gpmc driver work can be
based over this, while having a driver first in place.

This series is based on l-o/testing-cleanup as on 5-Sep-12,
i.e. over commit,

e3a5c14 ARM: OMAP1: Move SoC specific headers from plat to mach for omap1

per Tony's suggestion.

It is available
@git://gitorious.org/x0148406-public/linux-kernel.git gpmc-drv-v7

This series has been tested on omap3evm (rev G).


GPMC (General Purpose Memory Controller) in brief:
GPMC is an unified memory controller dedicated to interfacing external
memory devices like
 Asynchronous SRAM like memories and application specific integrated circuit 
devices.
 Asynchronous, synchronous, and page mode burst NOR flash devices NAND flash
 Pseudo-SRAM devices

GPMC details can be referred in AM335X Technical Reference Manual
@ http://www.ti.com/lit/pdf/spruh73

Regards
Afzal

v7:
Create a simple driver that gets resources  clk the standard Linux way
Pull in HMWOD patch back into this series

v6: Capability flag added that stores features based on revision
Macros used for finding revision
Return value from memory setup function corrected
Comments added to clarify handling of device type, size
Bool type time setting patch removed as has been taken care in [2]
Handle variable number of waitpin
Warn if driver is unable to configure interrupt
Enhance some of commit messages
Handle shared writeprotect case
Fix a bug in gpmc_create_device
Get clk from hwmod
Remove unwanted code
v5: Make this a purely driver conversion series, i.e. gpmc-mtd
interactions has been made as a separate series, so is adding
hwmod entry for OMAP2/3.
And modifying gpmc peripheral platform initialization has been
separated out of this series, so is migrating boards to use new
driver interface. GPMC driver conversion which was done in a few
patches in v4 has been tranformed to series of small patches.
Also care has been taken care that old interface will not break
with any of these patches, so both interfaces can coexist.
This helps in converting boards one-by-one gradually. Acquiring
CS has been thrown out. And conclusive comments on v4 has been
addressed.
v4: Handle wait pin (except for interrupts), enhance configuration
 timing interface of GPMC to take care of all boards. Dynamic
allocation of interrupt instead of static. Convert remaining
peripherals to work with GPMC driver. Handle acquiring NAND CS#,
adapt to HWMOD, update HWMOD OMAP2/3 entries, other minor
commenst on v3.
v3: Single device structure passed from platform for peripherals using
multiple CS instead of using multiple device structure having a few
redundant data, handle interrupts, GPMC NAND handling by GPMC NAND
driver instead of GPMC driver
v2: Avoid code movement that kept similar code together (for easy review)

Afzal Mohammed (3):
  ARM: OMAP2/3: hwmod data: add gpmc
  ARM: OMAP2+: gpmc: Adapt to HWMOD
  ARM: OMAP2+: gpmc: minimal driver support

 arch/arm/mach-omap2/gpmc.c |  193 +++-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   18 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   18 ++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |   44 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   54 ++
 arch/arm/mach-omap2/omap_hwmod_common_data.h   |1 +
 arch/arm/mach-omap2/prcm-common.h  |2 +
 7 files changed, 282 insertions(+), 48 deletions(-)

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v7 1/3] ARM: OMAP2/3: hwmod data: add gpmc

2012-09-05 Thread Afzal Mohammed
Add gpmc hwmod and associated interconnect data

Signed-off-by: Afzal Mohammed af...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   18 +++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   18 +++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |   44 -
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   54 
 arch/arm/mach-omap2/omap_hwmod_common_data.h   |1 +
 arch/arm/mach-omap2/prcm-common.h  |2 +
 6 files changed, 136 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index e7b90a0..b22c35b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -537,6 +537,15 @@ static struct omap_hwmod_addr_space 
omap2420_counter_32k_addrs[] = {
{ }
 };
 
+static struct omap_hwmod_addr_space omap2420_gpmc_addrs[] = {
+   {
+   .pa_start   = 0x6800A000,
+   .pa_end = 0x6800AFFF,
+   .flags  = ADDR_TYPE_RT
+   },
+   { }
+};
+
 static struct omap_hwmod_ocp_if omap2420_l4_wkup__counter_32k = {
.master = omap2xxx_l4_wkup_hwmod,
.slave  = omap2xxx_counter_32k_hwmod,
@@ -545,6 +554,14 @@ static struct omap_hwmod_ocp_if 
omap2420_l4_wkup__counter_32k = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+static struct omap_hwmod_ocp_if omap2420_l3__gpmc = {
+   .master = omap2xxx_l3_main_hwmod,
+   .slave  = omap2xxx_gpmc_hwmod,
+   .clk= core_l3_ck,
+   .addr   = omap2420_gpmc_addrs,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] __initdata = {
omap2xxx_l3_main__l4_core,
omap2xxx_mpu__l3_main,
@@ -588,6 +605,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] 
__initdata = {
omap2420_l4_core__msdi1,
omap2420_l4_core__hdq1w,
omap2420_l4_wkup__counter_32k,
+   omap2420_l3__gpmc,
NULL,
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 5fe65ae..8340516 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -888,6 +888,15 @@ static struct omap_hwmod_addr_space 
omap2430_counter_32k_addrs[] = {
{ }
 };
 
+static struct omap_hwmod_addr_space omap2430_gpmc_addrs[] = {
+   {
+   .pa_start   = 0x6E00,
+   .pa_end = 0x6E000FFF,
+   .flags  = ADDR_TYPE_RT
+   },
+   { }
+};
+
 static struct omap_hwmod_ocp_if omap2430_l4_wkup__counter_32k = {
.master = omap2xxx_l4_wkup_hwmod,
.slave  = omap2xxx_counter_32k_hwmod,
@@ -896,6 +905,14 @@ static struct omap_hwmod_ocp_if 
omap2430_l4_wkup__counter_32k = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+static struct omap_hwmod_ocp_if omap2430_l3__gpmc = {
+   .master = omap2xxx_l3_main_hwmod,
+   .slave  = omap2xxx_gpmc_hwmod,
+   .clk= core_l3_ck,
+   .addr   = omap2430_gpmc_addrs,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] __initdata = {
omap2xxx_l3_main__l4_core,
omap2xxx_mpu__l3_main,
@@ -946,6 +963,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] 
__initdata = {
omap2430_l4_core__mcbsp5,
omap2430_l4_core__hdq1w,
omap2430_l4_wkup__counter_32k,
+   omap2430_l3__gpmc,
NULL,
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 055f735..dcdcbcc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -173,6 +173,26 @@ struct omap_hwmod_class omap2xxx_mcspi_class = {
 };
 
 /*
+ * 'gpmc' class
+ * general purpose memory controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2xxx_gpmc_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+  SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2xxx_gpmc_hwmod_class = {
+   .name   = gpmc,
+   .sysc   = omap2xxx_gpmc_sysc,
+};
+
+/*
  * IP blocks
  */
 
@@ -724,7 +744,6 @@ struct omap_hwmod omap2xxx_mcspi2_hwmod = {
.dev_attr   = omap_mcspi2_dev_attr,
 };
 
-
 static struct omap_hwmod_class omap2xxx_counter_hwmod_class = {
.name   = counter,
 };
@@ -743,3 +762,26 @@ struct omap_hwmod 

[PATCH v7 3/3] ARM: OMAP2+: gpmc: minimal driver support

2012-09-05 Thread Afzal Mohammed
Create a minimal driver out of gpmc code.
Responsibilities handled by earlier gpmc
initialization is now achieved in probe.

Signed-off-by: Afzal Mohammed af...@ti.com
---
 arch/arm/mach-omap2/gpmc.c |  167 +++
 1 files changed, 120 insertions(+), 47 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index c45f185..f633b0d 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -24,6 +24,7 @@
 #include linux/io.h
 #include linux/module.h
 #include linux/interrupt.h
+#include linux/platform_device.h
 
 #include asm/mach-types.h
 
@@ -85,6 +86,12 @@
 #define ENABLE_PREFETCH(0x1  7)
 #define DMA_MPU_MODE   2
 
+#defineGPMC_REVISION_MAJOR(l)  ((l  4)  0xf)
+#defineGPMC_REVISION_MINOR(l)  (l  0xf)
+
+#defineGPMC_HAS_WR_ACCESS  0x1
+#defineGPMC_HAS_WR_DATA_MUX_BUS0x2
+
 /* XXX: Only NAND irq has been considered,currently these are the only ones 
used
  */
 #defineGPMC_NR_IRQ 2
@@ -130,7 +137,10 @@ static struct resource gpmc_cs_mem[GPMC_CS_NUM];
 static DEFINE_SPINLOCK(gpmc_mem_lock);
 static unsigned int gpmc_cs_map;   /* flag for cs which are initialized */
 static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
-
+static struct device *gpmc_dev;
+static int gpmc_irq;
+static resource_size_t phys_base, mem_size;
+static unsigned gpmc_capability;
 static void __iomem *gpmc_base;
 
 static struct clk *gpmc_l3_clk;
@@ -433,6 +443,19 @@ static int gpmc_cs_insert_mem(int cs, unsigned long base, 
unsigned long size)
return r;
 }
 
+static int gpmc_cs_delete_mem(int cs)
+{
+   struct resource *res = gpmc_cs_mem[cs];
+   int r;
+
+   spin_lock(gpmc_mem_lock);
+   r = release_resource(gpmc_cs_mem[cs]);
+   res-start = res-end = 0;
+   spin_unlock(gpmc_mem_lock);
+
+   return r;
+}
+
 int gpmc_cs_request(int cs, unsigned long size, unsigned long *base)
 {
struct resource *res = gpmc_cs_mem[cs];
@@ -769,7 +792,7 @@ static void gpmc_irq_noop(struct irq_data *data) { }
 
 static unsigned int gpmc_irq_noop_ret(struct irq_data *data) { return 0; }
 
-static int gpmc_setup_irq(int gpmc_irq)
+static int gpmc_setup_irq(void)
 {
int i;
u32 regval;
@@ -813,7 +836,37 @@ static int gpmc_setup_irq(int gpmc_irq)
return request_irq(gpmc_irq, gpmc_handle_irq, 0, gpmc, NULL);
 }
 
-static void __init gpmc_mem_init(void)
+static __exit int gpmc_free_irq(void)
+{
+   int i;
+
+   if (gpmc_irq)
+   free_irq(gpmc_irq, NULL);
+
+   for (i = 0; i  GPMC_NR_IRQ; i++) {
+   irq_set_handler(gpmc_client_irq[i].irq, NULL);
+   irq_set_chip(gpmc_client_irq[i].irq, no_irq_chip);
+   irq_modify_status(gpmc_client_irq[i].irq, 0, 0);
+   }
+
+   irq_free_descs(gpmc_irq_start, GPMC_NR_IRQ);
+
+   return 0;
+}
+
+static void __devexit gpmc_mem_exit(void)
+{
+   int cs;
+
+   for (cs = 0; cs  GPMC_CS_NUM; cs++) {
+   if (!gpmc_cs_mem_enabled(cs))
+   continue;
+   gpmc_cs_delete_mem(cs);
+   }
+
+}
+
+static void __devinit gpmc_mem_init(void)
 {
int cs;
unsigned long boot_rom_space = 0;
@@ -840,65 +893,85 @@ static void __init gpmc_mem_init(void)
}
 }
 
-static int __init gpmc_init(void)
+static __devinit int gpmc_probe(struct platform_device *pdev)
 {
u32 l;
-   int ret = -EINVAL;
-   int gpmc_irq;
-   char *ck = NULL;
-
-   if (cpu_is_omap24xx()) {
-   ck = core_l3_ck;
-   if (cpu_is_omap2420())
-   l = OMAP2420_GPMC_BASE;
-   else
-   l = OMAP34XX_GPMC_BASE;
-   gpmc_irq = 20 + OMAP_INTC_START;
-   } else if (cpu_is_omap34xx()) {
-   ck = gpmc_fck;
-   l = OMAP34XX_GPMC_BASE;
-   gpmc_irq = 20 + OMAP_INTC_START;
-   } else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
-   /* Base address and irq number are same for OMAP4/5 */
-   ck = gpmc_ck;
-   l = OMAP44XX_GPMC_BASE;
-   gpmc_irq = 20 + OMAP44XX_IRQ_GIC_START;
-   }
+   struct resource *res;
 
-   if (WARN_ON(!ck))
-   return ret;
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (res == NULL)
+   return -ENOENT;
 
-   gpmc_l3_clk = clk_get(NULL, ck);
-   if (IS_ERR(gpmc_l3_clk)) {
-   printk(KERN_ERR Could not get GPMC clock %s\n, ck);
-   BUG();
-   }
+   phys_base = res-start;
+   mem_size = resource_size(res);
 
-   gpmc_base = ioremap(l, SZ_4K);
+   gpmc_base = devm_request_and_ioremap(pdev-dev, res);
if (!gpmc_base) {
-   clk_put(gpmc_l3_clk);
-   printk(KERN_ERR Could not get GPMC register memory\n);
-   

[PATCH 1/2] pinctrl: pinctrl-single: Make sure we do not change bits outside of mask

2012-09-05 Thread Peter Ujfalusi
Use the pcs-fmask to make sure that the value is not changing (setting)
bits in areas where it should not.
To avoid situations like this:

pmx_dummy: pinmux@4a100040 {
compatible = pinctrl-single;
reg = 0x4a100040 0x0196;
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0x00ff;
};

pmx_dummy {
pinctrl-names = default;
pinctrl-0 = board_pins;

board_pins: pinmux_board_pins {
pinctrl-single,pins = 
0x6c 0xf0f
0x6e 0x10f
0x70 0x23f
0x72 0xa5f
;
};
};

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/pinctrl/pinctrl-single.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 76a4260..3508631 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -337,7 +337,7 @@ static int pcs_enable(struct pinctrl_dev *pctldev, unsigned 
fselector,
vals = func-vals[i];
val = pcs-read(vals-reg);
val = ~pcs-fmask;
-   val |= vals-val;
+   val |= (vals-val  pcs-fmask);
pcs-write(val, vals-reg);
}
 
-- 
1.7.12

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/2] pinctrl: pinctrl-single: new type: pinctrl-single,bits

2012-09-05 Thread Peter Ujfalusi
Hello,

When configuring pinmux with pinctrl-single there could be a case when one
register is used to configure mux for more than one pin.
In this case the use of pinctrl-single,pins is a bit problematic since we can
only update the whole register (restricted by the mask).
In such a situations the pinctrl-single,bits could provide a safe way to handle
the mux.

pinctrl-single,bits takes three parameters: reg offset, value, sub-mask
The sub mask is used to mask part of the register to make sure we do not change
bits outside of the scope of this pin.

The first patch in this series is to fix the previous pinctrl-since,pins
implementation because it was not using the mask on the value which could result
changed bits outside of the mask.

Regards,
Peter
---
Peter Ujfalusi (2):
  pinctrl: pinctrl-single: Make sure we do not change bits outside of
mask
  pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux

 .../devicetree/bindings/pinctrl/pinctrl-single.txt |  9 +
 drivers/pinctrl/pinctrl-single.c   | 42 --
 2 files changed, 41 insertions(+), 10 deletions(-)

-- 
1.7.12

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 2/2] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux

2012-09-05 Thread Peter Ujfalusi
With pinctrl-single,bits it is possible to update just part of the register
within the pinctrl-single,function-mask area.
This is useful when one register configures mmore than one pin's mux.

pinctrl-single,bits takes three parameters:
reg offset, value, sub-mask

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 .../devicetree/bindings/pinctrl/pinctrl-single.txt |  9 +
 drivers/pinctrl/pinctrl-single.c   | 42 --
 2 files changed, 41 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt 
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 5187f0d..287801d 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -31,6 +31,15 @@ device pinctrl register, and 0x118 contains the desired 
value of the
 pinctrl register. See the device example and static board pins example
 below for more information.
 
+In case when one register changes more than one pin's mux the
+pinctrl-single,bits can be used which takes three parameters:
+
+   pinctrl-single,bits = 0xdc 0x18, 0xff;
+
+Where 0xdc is the offset from the pinctrl register base address for the
+device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
+be used when applying this change to the register.
+
 Example:
 
 /* SoC common file */
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 3508631..aec338e 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -26,7 +26,8 @@
 #include core.h
 
 #define DRIVER_NAMEpinctrl-single
-#define PCS_MUX_NAME   pinctrl-single,pins
+#define PCS_MUX_PINS_NAME  pinctrl-single,pins
+#define PCS_MUX_BITS_NAME  pinctrl-single,bits
 #define PCS_REG_NAME_LEN   ((sizeof(unsigned long) * 2) + 1)
 #define PCS_OFF_DISABLED   ~0U
 
@@ -54,6 +55,7 @@ struct pcs_pingroup {
 struct pcs_func_vals {
void __iomem *reg;
unsigned val;
+   unsigned mask;
 };
 
 /**
@@ -332,12 +334,17 @@ static int pcs_enable(struct pinctrl_dev *pctldev, 
unsigned fselector,
 
for (i = 0; i  func-nvals; i++) {
struct pcs_func_vals *vals;
-   unsigned val;
+   unsigned val, mask;
 
vals = func-vals[i];
val = pcs-read(vals-reg);
-   val = ~pcs-fmask;
-   val |= (vals-val  pcs-fmask);
+   if (!vals-mask)
+   mask = pcs-fmask;
+   else
+   mask = pcs-fmask  vals-mask;
+
+   val = ~mask;
+   val |= (vals-val  mask);
pcs-write(val, vals-reg);
}
 
@@ -657,18 +664,29 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device 
*pcs,
 {
struct pcs_func_vals *vals;
const __be32 *mux;
-   int size, rows, *pins, index = 0, found = 0, res = -ENOMEM;
+   int size, params, rows, *pins, index = 0, found = 0, res = -ENOMEM;
struct pcs_function *function;
 
-   mux = of_get_property(np, PCS_MUX_NAME, size);
-   if ((!mux) || (size  sizeof(*mux) * 2)) {
-   dev_err(pcs-dev, bad data for mux %s\n,
-   np-name);
+   mux = of_get_property(np, PCS_MUX_PINS_NAME, size);
+   if (mux) {
+   params = 2;
+   } else {
+   mux = of_get_property(np, PCS_MUX_BITS_NAME, size);
+   if (!mux) {
+   dev_err(pcs-dev, no valid property for %s\n,
+   np-name);
+   return -EINVAL;
+   }
+   params = 3;
+   }
+
+   if (size  (sizeof(*mux) * params)) {
+   dev_err(pcs-dev, bad data for %s\n, np-name);
return -EINVAL;
}
 
size /= sizeof(*mux);   /* Number of elements in array */
-   rows = size / 2;/* Each row is a key value pair */
+   rows = size / params;   /* Each row is a key value pair */
 
vals = devm_kzalloc(pcs-dev, sizeof(*vals) * rows, GFP_KERNEL);
if (!vals)
@@ -686,6 +704,10 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device 
*pcs,
val = be32_to_cpup(mux + index++);
vals[found].reg = pcs-base + offset;
vals[found].val = val;
+   if (params == 3) {
+   val = be32_to_cpup(mux + index++);
+   vals[found].mask = val;
+   }
 
pin = pcs_get_pin_by_offset(pcs, offset);
if (pin  0) {
-- 
1.7.12

--
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 7/9] ARM: OMAP2+: Prepare for irqs.h removal

2012-09-05 Thread Mohammed, Afzal
Hi Tony,

On Wed, Sep 05, 2012 at 06:39:22, Tony Lindgren wrote:
 * Mohammed, Afzal af...@ti.com [120904 01:47]:

  *I am not sending the patches now to avoid confusion by way of having
  too many patch series*
  
  In case you like this, let me know, I will post.
 
 Yes please post the patches rebased on testing-cleanup branch that I
 just pushed. That branch is not immutable yet though as we're waiting
 to hear from Arnd regrading the first patch in the branch.

The patches rebased on testing-cleanup branch has been posted [1].

Regards
Afzal

[1] http://marc.info/?l=linux-omapm=134683495407871w=2



Re: [PATCH 12/17] OMAPDSS: clean up dss_mgr_set_timings

2012-09-05 Thread Archit Taneja

On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote:

dss_mgr_set_timings() can only be called when the output is not active.
This means that most of the code in the function is extra, as there's no
need to write the values to registers, etc, because that will be handled
when the output will be enabled.


We need to fix dpi_set_timings() before we can make this change. DPI 
still tries to change timings on the fly, i.e, with manager enabled. We 
need to disable and enable the DPI output like we do for other outputs.


Archit



Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
  drivers/video/omap2/dss/apply.c |   18 --
  1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 53629dd..1b49019 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -1314,21 +1314,19 @@ void dss_mgr_set_timings(struct omap_overlay_manager 
*mgr,
const struct omap_video_timings *timings)
  {
unsigned long flags;
-
-   mutex_lock(apply_lock);
+   struct mgr_priv_data *mp = get_mgr_priv(mgr);

spin_lock_irqsave(data_lock, flags);

-   dss_apply_mgr_timings(mgr, timings);
-
-   dss_write_regs();
-   dss_set_go_bits();
+   if (mp-enabled) {
+   DSSERR(cannot set timings for %s: manager needs to be 
disabled\n,
+   mgr-name);
+   goto out;
+   }

+   dss_apply_mgr_timings(mgr, timings);
+out:
spin_unlock_irqrestore(data_lock, flags);
-
-   wait_pending_extra_info_updates();
-
-   mutex_unlock(apply_lock);
  }

  static void dss_apply_mgr_lcd_config(struct omap_overlay_manager *mgr,



--
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 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC

2012-09-05 Thread Hiremath, Vaibhav
On Wed, Sep 05, 2012 at 13:53:58, Ujfalusi, Peter wrote:
 Hi,
 
 On 09/05/2012 09:11 AM, Hiremath, Vaibhav wrote:
  Not yet, but we discussed that with Peter and since he does have these
  patches for DT, he'll be able to test your series with the McBSP changes.
 
  
  Great.
 
 With his series and your patch for omap-hwmod audio was probing and working on
 OMAP3/4/5 without issues.
 
Peter,
Care to provide your Tested-By??

Benoit,
Can we merge this patch now?


Thanks,
Vaibhav

--
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 PATCH] ARM: OMAP2+: omap-device: Do not overwrite resources allocated by OF layer

2012-09-05 Thread Peter Ujfalusi
On 08/29/2012 12:48 PM, Vaibhav Hiremath wrote:
 With the new devices (like, AM33XX and OMAP5) we now only support
 DT boot mode of operation and now it is the time to start killing
 slowly the dependency on hwmod, so with this patch, we are starting
 with device resources.
 The idea here is implemented considering to both boot modes -
   - DT boot mode
 OF framework will construct the resource structure (currently
 does for MEM  IRQ resource) and we should respect/use these
 resources, killing hwmod dependency.
 If pdev-num_resources  0, we assume that MEM  IRQ resources
 have been allocated by OF layer already (through DTB).
 
 Once DMA resource is available from OF layer, we should
 kill filling any resources from hwmod.
 
   - Non-DT boot mode
 Here, pdev-num_resources = 0, and we should get all the
 resources from hwmod (following existing steps)
 
 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
 Cc: Benoit Cousson b-cous...@ti.com
 Cc: Tony Lindgren t...@atomide.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Kevin Hilman khil...@ti.com
 ---
 This patch is tested on BeagleBone and AM37xEVM.

I tried this on OMAP3 (with McBSP/twl4030-audio/omap-twl4030 DT boot), OMAP4
(McPDM, DMIC DT), and on OMAP5 (McPDM, DMIC DT).
I have sent the patches needed for the dtsi files to probe the audio related
IPs with this patch.

Tested-by: Peter Ujfalusi peter.ujfal...@ti.com

 
 Why RFC?
 Still we have function duplication omap_device_fill_resources() and
 omap_device_fill_dma_resources(), we can actually split the function
 into 3 resources and avoid duplication -
   - omap_device_fill_dma_resources()
   - omap_device_fill_mem_resources()
   - omap_device_fill_irq_resources()
 
 Actually I wanted to clean it further but thought of getting
 feedback first and then proceed further.
 
  arch/arm/mach-omap2/omap_hwmod.c |   27 ++
  arch/arm/plat-omap/include/plat/omap_hwmod.h |1 +
  arch/arm/plat-omap/omap_device.c |   72 +
  3 files changed, 88 insertions(+), 12 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/omap_hwmod.c 
 b/arch/arm/mach-omap2/omap_hwmod.c
 index 31ec283..edabfb3 100644
 --- a/arch/arm/mach-omap2/omap_hwmod.c
 +++ b/arch/arm/mach-omap2/omap_hwmod.c
 @@ -3330,6 +3330,33 @@ int omap_hwmod_fill_resources(struct omap_hwmod *oh, 
 struct resource *res)
  }
 
  /**
 + * omap_hwmod_fill_dma_resources - fill struct resource array with dma data
 + * @oh: struct omap_hwmod *
 + * @res: pointer to the array of struct resource to fill
 + *
 + * Fill the struct resource array @res with dma resource data from the
 + * omap_hwmod @oh.  Intended to be called by code that registers
 + * omap_devices.  See also omap_hwmod_count_resources().  Returns the
 + * number of array elements filled.
 + */
 +int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource 
 *res)
 +{
 + int i, sdma_reqs_cnt;
 + int r = 0;
 +
 + sdma_reqs_cnt = _count_sdma_reqs(oh);
 + for (i = 0; i  sdma_reqs_cnt; i++) {
 + (res + r)-name = (oh-sdma_reqs + i)-name;
 + (res + r)-start = (oh-sdma_reqs + i)-dma_req;
 + (res + r)-end = (oh-sdma_reqs + i)-dma_req;
 + (res + r)-flags = IORESOURCE_DMA;
 + r++;
 + }
 +
 + return r;
 +}
 +
 +/**
   * omap_hwmod_get_resource_byname - fetch IP block integration data by name
   * @oh: struct omap_hwmod * to operate on
   * @type: one of the IORESOURCE_* constants from include/linux/ioport.h
 diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h 
 b/arch/arm/plat-omap/include/plat/omap_hwmod.h
 index 9b9646c..0533073 100644
 --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
 +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
 @@ -615,6 +615,7 @@ int omap_hwmod_softreset(struct omap_hwmod *oh);
 
  int omap_hwmod_count_resources(struct omap_hwmod *oh);
  int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
 +int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource 
 *res);
  int omap_hwmod_get_resource_byname(struct omap_hwmod *oh, unsigned int type,
  const char *name, struct resource *res);
 
 diff --git a/arch/arm/plat-omap/omap_device.c 
 b/arch/arm/plat-omap/omap_device.c
 index c490240..fd15a3a 100644
 --- a/arch/arm/plat-omap/omap_device.c
 +++ b/arch/arm/plat-omap/omap_device.c
 @@ -486,6 +486,33 @@ static int omap_device_fill_resources(struct omap_device 
 *od,
  }
 
  /**
 + * omap_device_fill_dma_resources - fill in array of struct resource with 
 dma resources
 + * @od: struct omap_device *
 + * @res: pointer to an array of struct resource to be filled in
 + *
 + * Populate one or more empty struct resource pointed to by @res with
 + * the dma resource data for this omap_device @od.  Used by
 + * omap_device_alloc() after calling omap_device_count_resources().
 + *
 + * Ideally this function would not be needed at all.  If we have
 + * 

Converting OMAP's custom vram allocator

2012-09-05 Thread Tomi Valkeinen
Hi,

OMAP has a custom video ram allocator, which I'd like to remove and use
the standard dma allocation functions.

There are two problems for which I'd like to hear suggestions or
comments:

First one is that the dma_alloc_* functions map the allocated memory for
cpu use. In many cases with OMAP DSS (display subsystem) this is not
needed: the memory may be written only by the SGX or the DSP, and it's
only read by the DSS, so it's never touched by the CPU.

This is even more true when using VRFB on omap3 (and probably TILER on
omap4) for rotation, as VRFB hides the actual memory and offers rotated
views. In this case the backend memory is never accessed by anyone else
than VRFB.

Is there a way to allocate the memory without creating a mapping? While
it won't break anything as such, the allocated areas can be quite large
thus causing large areas of the kernel's memory space to be needlessly
reserved.

The second case is passing a framebuffer address from the bootloader to
the kernel. Often with mobile devices the bootloader will initialize the
display hardware, showing a company logo or such. To keep the image on
the screen when kernel starts we need to reserve the same physical
memory area early at boot, and use that for the framebuffer.

I'm not sure if there's any actual problem with this one, presuming
there is a solution for the first case. Somehow the memory is reserved
at early boot time, and this is passed to the fb driver. But can the
memory be managed the same way as in normal case (for example freeing
it), or does it need to be handled as a special case?

 Tomi



signature.asc
Description: This is a digitally signed message part


Re: [PATCH 12/17] OMAPDSS: clean up dss_mgr_set_timings

2012-09-05 Thread Tomi Valkeinen
On Wed, 2012-09-05 at 14:45 +0530, Archit Taneja wrote:
 On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote:
  dss_mgr_set_timings() can only be called when the output is not active.
  This means that most of the code in the function is extra, as there's no
  need to write the values to registers, etc, because that will be handled
  when the output will be enabled.
 
 We need to fix dpi_set_timings() before we can make this change. DPI 
 still tries to change timings on the fly, i.e, with manager enabled. We 
 need to disable and enable the DPI output like we do for other outputs.

Yep, and for HDMI also (I didn't check the others yet).

I think the simplest way to handle this is to only write the dpi.timings
in omapdss_dpi_set_timings, and remove the call to dss_mgr_set_timings.
This is not perfect, as a call to omapdss_dpi_set_timings when the
display is enabled would result in changing the dpi.timings, but the
changes wouldn't be actually in use.

However, there are only a few places where set_timings is called, and we
can make sure in those places to first disable the output and then
enable it again.

 Tomi



signature.asc
Description: This is a digitally signed message part


[PATCH v2 0/4] can: c_can: Add suspend/resume and pinctrl support

2012-09-05 Thread AnilKumar Ch
Adds suspend/resume functionality of d_can driver along with d_can
raminit support which is required to initialize RAM while data
transmission.

This patch series also adds pinctrl support to c_can driver. These
patches were tested on AM335x-EVM.

This patch-series is based ontop of runtimePM patch submitted
earlier - https://patchwork.kernel.org/patch/1348081/

Changes from v1:
- Incorporated Marc's comments on v1
  * Changed marco name with units in it
  * Used ndev-flags for link status instead of new member
  * Added BUG_ON inside *_power_down and *_power_up APIs
  * Added new member type in c_can_priv struct for keeping
dev id details/name.

AnilKumar Ch (4):
  can: c_can: Adopt pinctrl support
  can: c_can: Add d_can raminit support
  ARM: AM33XX: board-generic: Add of_dev_auxdata to pass d_can raminit
  can: c_can: Add d_can suspend resume support

 arch/arm/mach-omap2/board-generic.c|   40 +-
 arch/arm/mach-omap2/control.h  |4 ++
 drivers/net/can/c_can/c_can.c  |   95 
 drivers/net/can/c_can/c_can.h  |   10 
 drivers/net/can/c_can/c_can_platform.c |   79 ++
 include/linux/can/platform/c_can.h |   36 
 6 files changed, 263 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/can/platform/c_can.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH RESEND 1/4] can: c_can: Adopt pinctrl support

2012-09-05 Thread AnilKumar Ch
Adopt pinctrl support to c_can driver based on c_can device
pointer, pinctrl driver configure SoC pins to d_can mode
according to definitions provided in .dts file.

In device specific device tree file 'pinctrl-names = default;'
and 'pinctrl-0 = d_can1_pins;' needs to add to configure pins
from c_can driver. d_can1_pins node contains the pinmux/config
details of d_can L/H pins.

Signed-off-by: AnilKumar Ch anilku...@ti.com
---
 drivers/net/can/c_can/c_can_platform.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/can/c_can/c_can_platform.c 
b/drivers/net/can/c_can/c_can_platform.c
index 90801c4..c351975 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -33,6 +33,7 @@
 #include linux/of.h
 #include linux/of_device.h
 #include linux/pm_runtime.h
+#include linux/pinctrl/consumer.h
 
 #include linux/can/dev.h
 
@@ -98,6 +99,7 @@ static int __devinit c_can_plat_probe(struct platform_device 
*pdev)
struct c_can_priv *priv;
const struct of_device_id *match;
const struct platform_device_id *id;
+   struct pinctrl *pinctrl;
struct resource *mem;
int irq;
struct clk *clk;
@@ -114,6 +116,11 @@ static int __devinit c_can_plat_probe(struct 
platform_device *pdev)
id = platform_get_device_id(pdev);
}
 
+   pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+   if (IS_ERR(pinctrl))
+   dev_warn(pdev-dev,
+   failed to configure pins from driver\n);
+
/* get the appropriate clk */
clk = clk_get(pdev-dev, NULL);
if (IS_ERR(clk)) {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH RESEND 2/4] can: c_can: Add d_can raminit support

2012-09-05 Thread AnilKumar Ch
Add D_CAN raminit support to C_CAN driver to enable D_CAN RAM,
which holds all the message objects during transmission or
receiving of data. This initialization/de-initialization should
be done in synchronous with D_CAN clock.

Signed-off-by: AnilKumar Ch anilku...@ti.com
---
 drivers/net/can/c_can/c_can.c  |   13 
 drivers/net/can/c_can/c_can.h  |2 ++
 drivers/net/can/c_can/c_can_platform.c |   10 +
 include/linux/can/platform/c_can.h |   36 
 4 files changed, 61 insertions(+)
 create mode 100644 include/linux/can/platform/c_can.h

diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index aa6c5eb..c175410 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -214,6 +214,12 @@ static inline void c_can_pm_runtime_put_sync(const struct 
c_can_priv *priv)
pm_runtime_put_sync(priv-device);
 }
 
+static inline void c_can_reset_ram(const struct c_can_priv *priv, bool enable)
+{
+   if (priv-ram_init)
+   priv-ram_init(priv-instance, enable);
+}
+
 static inline int get_tx_next_msg_obj(const struct c_can_priv *priv)
 {
return (priv-tx_next  C_CAN_NEXT_MSG_OBJ_MASK) +
@@ -1071,6 +1077,8 @@ static int c_can_open(struct net_device *dev)
struct c_can_priv *priv = netdev_priv(dev);
 
c_can_pm_runtime_get_sync(priv);
+   /* Initialize DCAN RAM */
+   c_can_reset_ram(priv, true);
 
/* open the can device */
err = open_candev(dev);
@@ -1099,6 +1107,8 @@ static int c_can_open(struct net_device *dev)
 exit_irq_fail:
close_candev(dev);
 exit_open_fail:
+   /* De-Initialize DCAN RAM */
+   c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
return err;
 }
@@ -1112,6 +1122,9 @@ static int c_can_close(struct net_device *dev)
c_can_stop(dev);
free_irq(dev-irq, dev);
close_candev(dev);
+
+   /* De-Initialize DCAN RAM */
+   c_can_reset_ram(priv, false);
c_can_pm_runtime_put_sync(priv);
 
return 0;
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 1437a6d..5f6339c 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -166,6 +166,8 @@ struct c_can_priv {
unsigned int tx_echo;
void *priv; /* for board-specific data */
u16 irqstatus;
+   unsigned int instance;
+   void (*ram_init) (unsigned int instance, bool enable);
 };
 
 struct net_device *alloc_c_can_dev(void);
diff --git a/drivers/net/can/c_can/c_can_platform.c 
b/drivers/net/can/c_can/c_can_platform.c
index c351975..c6963b2 100644
--- a/drivers/net/can/c_can/c_can_platform.c
+++ b/drivers/net/can/c_can/c_can_platform.c
@@ -34,6 +34,7 @@
 #include linux/of_device.h
 #include linux/pm_runtime.h
 #include linux/pinctrl/consumer.h
+#include linux/can/platform/c_can.h
 
 #include linux/can/dev.h
 
@@ -98,6 +99,7 @@ static int __devinit c_can_plat_probe(struct platform_device 
*pdev)
struct net_device *dev;
struct c_can_priv *priv;
const struct of_device_id *match;
+   struct c_can_platform_data *pdata = NULL;
const struct platform_device_id *id;
struct pinctrl *pinctrl;
struct resource *mem;
@@ -179,6 +181,14 @@ static int __devinit c_can_plat_probe(struct 
platform_device *pdev)
priv-can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES;
priv-read_reg = c_can_plat_read_reg_aligned_to_16bit;
priv-write_reg = c_can_plat_write_reg_aligned_to_16bit;
+   pdata = pdev-dev.platform_data;
+   if (!pdata) {
+   dev_err(pdev-dev, d_can platform data missing\n);
+   ret = -EINVAL;
+   goto exit_free_device;
+   }
+   priv-ram_init = pdata-ram_init;
+   priv-instance = pdata-instance;
break;
default:
ret = -EINVAL;
diff --git a/include/linux/can/platform/c_can.h 
b/include/linux/can/platform/c_can.h
new file mode 100644
index 000..84b27d2
--- /dev/null
+++ b/include/linux/can/platform/c_can.h
@@ -0,0 +1,36 @@
+/*
+ * C_CAN controller driver platform header
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Bosch C_CAN/D_CAN controller is compliant to CAN protocol version 2.0
+ * part A and B.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __CAN_PLATFORM_C_CAN_H__
+#define 

[PATCH v2 4/4] can: c_can: Add d_can suspend resume support

2012-09-05 Thread AnilKumar Ch
Adds suspend resume support to DCAN driver which enables
DCAN power down mode bit (PDR). Then DCAN will ack the local
power-down mode by setting PDA bit in STATUS register.

Signed-off-by: AnilKumar Ch anilku...@ti.com
---
 drivers/net/can/c_can/c_can.c  |   82 
 drivers/net/can/c_can/c_can.h  |8 
 drivers/net/can/c_can/c_can_platform.c |   62 
 3 files changed, 152 insertions(+)

diff --git a/drivers/net/can/c_can/c_can.c b/drivers/net/can/c_can/c_can.c
index c175410..c601136 100644
--- a/drivers/net/can/c_can/c_can.c
+++ b/drivers/net/can/c_can/c_can.c
@@ -46,6 +46,9 @@
 #define IF_ENUM_REG_LEN11
 #define C_CAN_IFACE(reg, iface)(C_CAN_IF1_##reg + (iface) * 
IF_ENUM_REG_LEN)
 
+/* control extension register D_CAN specific */
+#define CONTROL_EX_PDR BIT(8)
+
 /* control register */
 #define CONTROL_TEST   BIT(7)
 #define CONTROL_CCEBIT(6)
@@ -65,6 +68,7 @@
 #define TEST_BASIC BIT(2)
 
 /* status register */
+#define STATUS_PDA BIT(10)
 #define STATUS_BOFFBIT(7)
 #define STATUS_EWARN   BIT(6)
 #define STATUS_EPASS   BIT(5)
@@ -164,6 +168,9 @@
 /* minimum timeout for checking BUSY status */
 #define MIN_TIMEOUT_VALUE  6
 
+/* Wait for ~1 sec for INIT bit */
+#define INIT_WAIT_MS   1000
+
 /* napi related */
 #define C_CAN_NAPI_WEIGHT  C_CAN_MSG_OBJ_RX_NUM
 
@@ -1154,6 +1161,81 @@ struct net_device *alloc_c_can_dev(void)
 }
 EXPORT_SYMBOL_GPL(alloc_c_can_dev);
 
+#ifdef CONFIG_PM
+int c_can_power_down(struct net_device *dev)
+{
+   u32 val;
+   unsigned long time_out;
+   struct c_can_priv *priv = netdev_priv(dev);
+
+   if (!(dev-flags  IFF_UP))
+   return 0;
+
+   BUG_ON(priv-type != BOSCH_D_CAN);
+
+   /* set PDR value so the device goes to power down mode */
+   val = priv-read_reg(priv, C_CAN_CTRL_EX_REG);
+   val |= CONTROL_EX_PDR;
+   priv-write_reg(priv, C_CAN_CTRL_EX_REG, val);
+
+   /* Wait for the PDA bit to get set */
+   time_out = jiffies + msecs_to_jiffies(INIT_WAIT_MS);
+   while (!(priv-read_reg(priv, C_CAN_STS_REG)  STATUS_PDA) 
+   time_after(time_out, jiffies))
+   cpu_relax();
+
+   if (time_after(jiffies, time_out))
+   return -ETIMEDOUT;
+
+   c_can_stop(dev);
+
+   /* De-initialize DCAN RAM */
+   c_can_reset_ram(priv, false);
+   c_can_pm_runtime_put_sync(priv);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(c_can_power_down);
+
+int c_can_power_up(struct net_device *dev)
+{
+   u32 val;
+   unsigned long time_out;
+   struct c_can_priv *priv = netdev_priv(dev);
+
+   if (!(dev-flags  IFF_UP))
+   return 0;
+
+   BUG_ON(priv-type != BOSCH_D_CAN);
+
+   c_can_pm_runtime_get_sync(priv);
+   /* Initialize DCAN RAM */
+   c_can_reset_ram(priv, true);
+
+   /* Clear PDR and INIT bits */
+   val = priv-read_reg(priv, C_CAN_CTRL_EX_REG);
+   val = ~CONTROL_EX_PDR;
+   priv-write_reg(priv, C_CAN_CTRL_EX_REG, val);
+   val = priv-read_reg(priv, C_CAN_CTRL_REG);
+   val = ~CONTROL_INIT;
+   priv-write_reg(priv, C_CAN_CTRL_REG, val);
+
+   /* Wait for the PDA bit to get clear */
+   time_out = jiffies + msecs_to_jiffies(INIT_WAIT_MS);
+   while ((priv-read_reg(priv, C_CAN_STS_REG)  STATUS_PDA) 
+   time_after(time_out, jiffies))
+   cpu_relax();
+
+   if (time_after(jiffies, time_out))
+   return -ETIMEDOUT;
+
+   c_can_start(dev);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(c_can_power_up);
+#endif
+
 void free_c_can_dev(struct net_device *dev)
 {
free_candev(dev);
diff --git a/drivers/net/can/c_can/c_can.h b/drivers/net/can/c_can/c_can.h
index 5f6339c..ca149eb 100644
--- a/drivers/net/can/c_can/c_can.h
+++ b/drivers/net/can/c_can/c_can.h
@@ -24,6 +24,7 @@
 
 enum reg {
C_CAN_CTRL_REG = 0,
+   C_CAN_CTRL_EX_REG,
C_CAN_STS_REG,
C_CAN_ERR_CNT_REG,
C_CAN_BTR_REG,
@@ -104,6 +105,7 @@ static const u16 reg_map_c_can[] = {
 
 static const u16 reg_map_d_can[] = {
[C_CAN_CTRL_REG]= 0x00,
+   [C_CAN_CTRL_EX_REG] = 0x02,
[C_CAN_STS_REG] = 0x04,
[C_CAN_ERR_CNT_REG] = 0x08,
[C_CAN_BTR_REG] = 0x0C,
@@ -166,6 +168,7 @@ struct c_can_priv {
unsigned int tx_echo;
void *priv; /* for board-specific data */
u16 irqstatus;
+   enum c_can_dev_id type;
unsigned int instance;
void (*ram_init) (unsigned int instance, bool enable);
 };
@@ -175,4 +178,9 @@ void free_c_can_dev(struct net_device *dev);
 int register_c_can_dev(struct net_device *dev);
 void unregister_c_can_dev(struct net_device *dev);
 
+#ifdef CONFIG_PM
+int c_can_power_up(struct net_device *dev);
+int c_can_power_down(struct 

[PATCH RESEND 3/4] ARM: AM33XX: board-generic: Add of_dev_auxdata to pass d_can raminit

2012-09-05 Thread AnilKumar Ch
Add of_dev_auxdata to pass d_can raminit callback APIs to initialize
d_can RAM. D_CAN RAM initialization bits are present in CONTROL module
address space, which can be accessed by platform specific code. So
callback functions are added to serve this purpose, this can done by
using of_dev_auxdata.

Two callback APIs are added to of_dev_auxdata used by two instances of
D_CAN IP. These callback functions are used to enable/disable D_CAN RAM
from CAN driver.

Signed-off-by: AnilKumar Ch anilku...@ti.com
---
 arch/arm/mach-omap2/board-generic.c |   40 ++-
 arch/arm/mach-omap2/control.h   |4 
 2 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 6f93a20..b68e642 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,7 @@
 #include linux/of_irq.h
 #include linux/of_platform.h
 #include linux/irqdomain.h
+#include linux/can/platform/c_can.h
 
 #include mach/hardware.h
 #include asm/hardware/gic.h
@@ -22,6 +23,8 @@
 
 #include plat/board.h
 #include common.h
+#include control.h
+#include iomap.h
 #include common-board-devices.h
 
 #if !(defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3))
@@ -37,11 +40,46 @@ static struct of_device_id omap_dt_match_table[] __initdata 
= {
{ }
 };
 
+void d_can_hw_raminit(unsigned int instance, bool enable)
+{
+   u32 val;
+
+   val = readl(AM33XX_CTRL_REGADDR(AM33XX_CONTROL_DCAN_RAMINIT));
+   if (enable) {
+   val = ~AM33XX_DCAN_RAMINIT_START_MASK(instance);
+   val |= AM33XX_DCAN_RAMINIT_START_MASK(instance);
+   writel(val, AM33XX_CTRL_REGADDR(AM33XX_CONTROL_DCAN_RAMINIT));
+   } else {
+   val = ~AM33XX_DCAN_RAMINIT_START_MASK(instance);
+   writel(val, AM33XX_CTRL_REGADDR(AM33XX_CONTROL_DCAN_RAMINIT));
+   }
+}
+
+static struct c_can_platform_data d_can0_pdata = {
+   .ram_init   = d_can_hw_raminit,
+   .instance   = 0,
+};
+
+static struct c_can_platform_data d_can1_pdata = {
+   .ram_init   = d_can_hw_raminit,
+   .instance   = 1,
+};
+
+static const struct of_dev_auxdata am33xx_auxdata_lookup[] __initconst = {
+   OF_DEV_AUXDATA(bosch,d_can, 0x481cc000, NULL, d_can0_pdata),
+   OF_DEV_AUXDATA(bosch,d_can, 0x481d, NULL, d_can1_pdata),
+   { },
+};
+
 static void __init omap_generic_init(void)
 {
omap_sdrc_init(NULL, NULL);
 
-   of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+   if (of_machine_is_compatible(ti,am33xx))
+   of_platform_populate(NULL, omap_dt_match_table,
+   am33xx_auxdata_lookup, NULL);
+   else
+   of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
 }
 
 #ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b8cdc85..afd189b 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -356,6 +356,10 @@
 #define AM33XX_CONTROL_STATUS_SYSBOOT1_SHIFT   22
 #define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK(0x3  22)
 
+/* AM33XX DCAN bitfields */
+#define AM33XX_CONTROL_DCAN_RAMINIT0x644
+#define AM33XX_DCAN_RAMINIT_START_MASK(i)  (1  (i))
+
 /* CONTROL OMAP STATUS register to identify OMAP3 features */
 #define OMAP3_CONTROL_OMAP_STATUS  0x044c
 
-- 
1.7.9.5

--
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 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC

2012-09-05 Thread Peter Ujfalusi
Hi Benoit,

On 09/03/2012 05:46 PM, Benoit Cousson wrote:
 + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
 
 Nit: 2012

Oh, I missed that (copy-paste of the header...)

 + *
 + * This file is licensed under the terms of the GNU General Public License
 + * version 2.  This program is licensed as is without any warranty of any
 + * kind, whether express or implied.
 + */
 +
 +/include/ omap2.dtsi
 +
 +/ {
 +compatible = ti,omap2420, ti,omap2;
 +
 +ocp {
 +mcbsp1: mcbsp@48074000 {
 +compatible = ti,omap2420-mcbsp;
 +reg = 0x48074000 0xff;
 +reg-names = mpu;
 +interrupts = 0 59 0x4, /* TX interrupt */
 + 0 60 0x4; /* RX interrupt */
 
 That one is not correct because it does comply with the interrupt
 controller specifier that require only one cell:
 
   intc: interrupt-controller@4820 {
   compatible = ti,omap2-intc;
   interrupt-controller;
   #interrupt-cells = 1;
 ...
 
 The one you are using is for GIC IRQ controller.
 It works probably because we are using hwmod so far :-)
 
 Didn't you get some warning?

dtb compiles fine. I'll fix OMAP2 and OMAP3 as well.

Will send the updated series shortly.

-- 
Péter
--
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 12/17] OMAPDSS: clean up dss_mgr_set_timings

2012-09-05 Thread Archit Taneja

On Wednesday 05 September 2012 04:11 PM, Tomi Valkeinen wrote:

On Wed, 2012-09-05 at 14:45 +0530, Archit Taneja wrote:

On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote:

dss_mgr_set_timings() can only be called when the output is not active.
This means that most of the code in the function is extra, as there's no
need to write the values to registers, etc, because that will be handled
when the output will be enabled.


We need to fix dpi_set_timings() before we can make this change. DPI
still tries to change timings on the fly, i.e, with manager enabled. We
need to disable and enable the DPI output like we do for other outputs.


Yep, and for HDMI also (I didn't check the others yet).


I don't think HDMI is impacted, we do the full power off and power on 
for HDMI, so the manager would be disabled when we set the timings.




I think the simplest way to handle this is to only write the dpi.timings
in omapdss_dpi_set_timings, and remove the call to dss_mgr_set_timings.
This is not perfect, as a call to omapdss_dpi_set_timings when the
display is enabled would result in changing the dpi.timings, but the
changes wouldn't be actually in use.


The simplest way would be to do what other outputs do, disable the 
output and re-enable the output with the new timings value, if the panel 
is enabled.


Archit

--
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


[PATCHv2 0/4] Add mfd driver for smsc-ece1099 chip

2012-09-05 Thread Sourav Poddar

Add a smsc-ece1099 mfd driver which will work as
keypad scan device or a gpio expander device.

Patch 1 creates the parent mfd driver.
Patch 2 add keypad support. Patch 3 adds dts
support for keypad in omap5 dts file.
Patch 4 add gpio expansion driver for chip (RFC).

Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com

G, Manjunath Kondaiah (1):
  Input: keypad: Add smsc ece1099 keypad driver

Sourav Poddar (3):
  mfd: smsc: Add support for smsc gpio io/keypad driver
  arm/dts: omap5-evm: Add keypad support
  gpio: smscece: Add support for gpio IO expander feature

 Documentation/smsc_ece1099.txt   |   56 
 arch/arm/boot/dts/omap5-evm.dts  |   95 +++
 drivers/gpio/Kconfig |7 +
 drivers/gpio/Makefile|1 +
 drivers/gpio/gpio-smscece.c  |  380 ++
 drivers/input/keyboard/Kconfig   |   11 +
 drivers/input/keyboard/Makefile  |1 +
 drivers/input/keyboard/smsc-ece1099-keypad.c |  306 +
 drivers/mfd/Kconfig  |   12 +
 drivers/mfd/Makefile |1 +
 drivers/mfd/smsc-ece1099.c   |  110 
 include/linux/mfd/smsc.h |  111 
 12 files changed, 1091 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/smsc_ece1099.txt
 create mode 100644 drivers/gpio/gpio-smscece.c
 create mode 100644 drivers/input/keyboard/smsc-ece1099-keypad.c
 create mode 100644 drivers/mfd/smsc-ece1099.c
 create mode 100644 include/linux/mfd/smsc.h

--
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


[PATCHv2 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver

2012-09-05 Thread Sourav Poddar
smsc ece1099 is a keyboard scan or gpio expansion device.
The patch create keypad and gpio expander child for this
multi function smsc driver.

Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Changes since v1:
 - Use Kconfig option correctly
 - Add regmap_config paramters
 - Modify formatting of logs for devid
 - Move read/write function to headed file as an inline
   function.
 Documentation/smsc_ece1099.txt |   56 
 drivers/mfd/Kconfig|   12 
 drivers/mfd/Makefile   |1 +
 drivers/mfd/smsc-ece1099.c |  110 +++
 include/linux/mfd/smsc.h   |  111 
 5 files changed, 290 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/smsc_ece1099.txt
 create mode 100644 drivers/mfd/smsc-ece1099.c
 create mode 100644 include/linux/mfd/smsc.h

diff --git a/Documentation/smsc_ece1099.txt b/Documentation/smsc_ece1099.txt
new file mode 100644
index 000..6b492e8
--- /dev/null
+++ b/Documentation/smsc_ece1099.txt
@@ -0,0 +1,56 @@
+What is smsc-ece1099?
+--
+
+The ECE1099 is a 40-Pin 3.3V Keyboard Scan Expansion
+or GPIO Expansion device. The device supports a keyboard
+scan matrix of 23x8. The device is connected to a Master
+via the SMSC BC-Link interface or via the SMBus.
+Keypad scan Input(KSI) and Keypad Scan Output(KSO) signals
+are multiplexed with GPIOs.
+
+Interrupt generation
+
+
+Interrupts can be generated by an edge detection on a GPIO
+pin or an edge detection on one of the bus interface pins.
+Interrupts can also be detected on the keyboard scan interface.
+The bus interrupt pin (BC_INT# or SMBUS_INT#) is asserted if
+any bit in one of the Interrupt Status registers is 1 and
+the corresponding Interrupt Mask bit is also 1.
+
+In order for software to determine which device is the source
+of an interrupt, it should first read the Group Interrupt Status Register
+to determine which Status register group is a source for the interrupt.
+Software should read both the Status register and the associated Mask register,
+then AND the two values together. Bits that are 1 in the result of the AND
+are active interrupts. Software clears an interrupt by writing a 1 to the
+corresponding bit in the Status register.
+
+Communication Protocol
+--
+
+- SMbus slave Interface
+   The host processor communicates with the ECE1099 device
+   through a series of read/write registers via the SMBus
+   interface. SMBus is a serial communication protocol between
+   a computer host and its peripheral devices. The SMBus data
+   rate is 10KHz minimum to 400 KHz maximum
+
+- Slave Bus Interface
+   The ECE1099 device SMBus implementation is a subset of the
+   SMBus interface to the host. The device is a slave-only SMBus device.
+   The implementation in the device is a subset of SMBus since it
+   only supports four protocols.
+
+   The Write Byte, Read Byte, Send Byte, and Receive Byte protocols are the
+   only valid SMBus protocols for the device.
+
+- BC-LinkTM Interface
+   The BC-Link is a proprietary bus that allows communication
+   between a Master device and a Companion device. The Master
+   device uses this serial bus to read and write registers
+   located on the Companion device. The bus comprises three signals,
+   BC_CLK, BC_DAT and BC_INT#. The Master device always provides the
+   clock, BC_CLK, and the Companion device is the source for an
+   independent asynchronous interrupt signal, BC_INT#. The ECE1099
+   supports BC-Link speeds up to 24MHz.
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d1facef..991ef15 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -385,6 +385,18 @@ config MFD_T7L66XB
help
  Support for Toshiba Mobile IO Controller T7L66XB
 
+config MFD_SMSC
+   bool Support for the SMSC ECE1099 series chips
+   depends on I2C=y
+   select MFD_CORE
+   select REGMAP_I2C
+   help
+If you say yes here you get support for the
+ece1099 chips from SMSC.
+
+To compile this driver as a module, choose M here: the
+module will be called smsc.
+
 config MFD_TC6387XB
bool Support Toshiba TC6387XB
depends on ARM  HAVE_CLK
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 79dd22d..f587d91 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_EZX_PCAP)+= ezx-pcap.o
 obj-$(CONFIG_MCP)  += mcp-core.o
 obj-$(CONFIG_MCP_SA11X0)   += mcp-sa11x0.o
 obj-$(CONFIG_MCP_UCB1200)  += ucb1x00-core.o
+obj-$(CONFIG_MFD_SMSC)+= smsc.o
 obj-$(CONFIG_MCP_UCB1200_TS)   += ucb1x00-ts.o
 
 ifeq 

[PATCHv2 3/4] arm/dts: omap5-evm: Add keypad support

2012-09-05 Thread Sourav Poddar
Add keypad data node in omap5-evm.

Based on I2C support patch for omap5, which has been
already posted as a different series.

Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Tested on omap5430 sdp with 3.66 custom kernel.

Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Changes since v1:
- use spaces around key comments
 arch/arm/boot/dts/omap5-evm.dts |   95 +++
 1 files changed, 95 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 200c39a..b782e67 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -18,3 +18,98 @@
reg = 0x8000 0x4000; /* 1 GB */
};
 };
+
+i2c5 {
+   clock-frequency = 40;
+
+   smsc@38 {
+   compatible = smsc;
+   reg = 0x38;
+   clock = 0x13;
+   keypad {
+   compatible = smsc,keypad;
+   interrupt-parent = gpio5;
+   interrupts = 23; /* gpio line 151 */
+   keypad,num-rows = 8;
+   keypad,num-columns = 16;
+   linux,keymap =  0x20041 /* KEY_F7 */
+   0x30001 /* KEY_ESC */
+   0x4003e /* KEY_F4 */
+   0x50022 /* KEY_G */
+   0x70023 /* KEY_H */
+   0x9009a /* KEY_CYCLEWINDOWS */
+   0xc000e /* KEY_BACKSPACE */
+   0xd0057 /* KEY_F11 */
+   0xe009f /* KEY_FORWARD */
+   0xf006e /* KEY_INSERT */
+   0x1020036 /* KEY_RIGHTSHIFT */
+   0x1030011 /* KEY_W */
+   0x1040010 /* KEY_Q */
+   0x1050012 /* KEY_E */
+   0x1070013 /* KEY_R */
+   0x1080016 /* KEY_U */
+   0x10c0017 /* KEY_I */
+   0x10d0067 /* KEY_UP */
+   0x10e0018 /* KEY_O */
+   0x10f0019 /* KEY_LEFT */
+   0x2020003 /* KEY_2 */
+   0x2040004 /* KEY_1 */
+   0x2050005 /* KEY_3 */
+   0x2070008 /* KEY_4 */
+   0x2080009 /* KEY_7 */
+   0x20b0064 /* KEY_8 */
+   0x20c006c /* KEY_RIGHTALT */
+   0x20d000a /* KEY_DOWN */
+   0x20e0001 /* KEY_0 */
+   0x20f006a /* KEY_RIGHT */
+   0x3010061 /* KEY_RIGHTCTRL */
+   0x302001f /* KEY_S */
+   0x303001e /* KEY_A */
+   0x3040020 /* KEY_D */
+   0x3050021 /* KEY_F */
+   0x3070024 /* KEY_J */
+   0x3080025 /* KEY_K */
+   0x30c001c /* KEY_ENTER */
+   0x30d0026 /* KEY_L */
+   0x30e0027 /* KEY_SEMICOLON */
+   0x42a /* KEY_LEFTSHIFT */
+   0x402002d /* KEY_X */
+   0x403002c /* KEY_Z */
+   0x404002e /* KEY_C */
+   0x405002f /* KEY_V */
+   0x4070032 /* KEY_M */
+   0x4080033 /* KEY_COMMA */
+   0x40c0039 /* KEY_SPACE */
+   0x40d0033 /* KEY_DOT */
+   0x40e0035 /* KEY_SLASH */
+   0x40f006b /* KEY_END */
+   0x501001d /* KEY_LEFTCTRL */
+   0x5020040 /* KEY_F6 */
+   0x503000f /* KEY_TAB */
+   0x504003d /* KEY_F3 */
+   0x5050014 /* KEY_T */
+   0x5070015 /* KEY_Y */
+   0x508001a /* KEY_LEFTBRACE */
+   0x50d0044 /* 

[PATCHv2 4/4] gpio: smscece: Add support for gpio IO expander feature

2012-09-05 Thread Sourav Poddar
smsc can be used as an gpio io expander device also. So adding
support for configuring smsc pins as a gpio.

Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Changes since v1: 
 - Use edge triggering instead of level
 - Use devm_reuest_threaded_irq
 - In remove part, use irq_free_desc and
 irq_remove_domain api.
 drivers/gpio/Kconfig|7 +
 drivers/gpio/Makefile   |1 +
 drivers/gpio/gpio-smscece.c |  380 +++
 3 files changed, 388 insertions(+), 0 deletions(-)
 create mode 100644 drivers/gpio/gpio-smscece.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b16c8a7..e883929 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -444,6 +444,13 @@ config GPIO_ADP5588_IRQ
  Say yes here to enable the adp5588 to be used as an interrupt
  controller. It requires the driver to be built in the kernel.
 
+config GPIO_SMSCECE
+   tristate SMSCECE 1099 I2C GPIO expander
+   depends on I2C
+   help
+ This option enables support for 18 GPIOs found
+ on SMSC ECE 1099 GPIO Expanders.
+
 comment PCI GPIO expanders:
 
 config GPIO_CS5535
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 153cace..7c803c5 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_GPIO_74X164) += gpio-74x164.o
 obj-$(CONFIG_GPIO_AB8500)  += gpio-ab8500.o
 obj-$(CONFIG_GPIO_ADP5520) += gpio-adp5520.o
 obj-$(CONFIG_GPIO_ADP5588) += gpio-adp5588.o
+obj-$(CONFIG_GPIO_SMSCECE)  += gpio-smscece.o
 obj-$(CONFIG_GPIO_AMD8111) += gpio-amd8111.o
 obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
 obj-$(CONFIG_GPIO_BT8XX)   += gpio-bt8xx.o
diff --git a/drivers/gpio/gpio-smscece.c b/drivers/gpio/gpio-smscece.c
new file mode 100644
index 000..68a17fa
--- /dev/null
+++ b/drivers/gpio/gpio-smscece.c
@@ -0,0 +1,380 @@
+/*
+ * GPIO Chip driver for smsc
+ * SMSC I/O Expander and QWERTY Keypad Controller
+ *
+ * Copyright 2012 Texas Instruments Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/init.h
+#include linux/i2c.h
+#include linux/gpio.h
+#include linux/interrupt.h
+#include linux/irqdomain.h
+#include linux/irq.h
+#include linux/mfd/smsc.h
+#include linux/err.h
+
+struct smsc_gpio {
+   struct device *dev;
+   struct smsc *smsc;
+   struct gpio_chip gpio_chip;
+   struct mutex lock;  /* protect cached dir, dat_out */
+   /* protect serialized access to the interrupt controller bus */
+   struct mutex irq_lock;
+   struct irq_domain   *irq_domain;
+   unsigned gpio_start;
+   int type;
+   int flags;
+   int irq;
+   int irq_base;
+   unsigned int gpio_base;
+   unsigned int dat_out[5];
+   unsigned int dir[5];
+   unsigned int irq_trig_fall[5];
+   unsigned int irq_trig_raise[5];
+   unsigned int int_en[5];
+   unsigned int irq_mask[5];
+   unsigned int irq_stat[5];
+};
+
+static int smsc_gpio_get_value(struct gpio_chip *chip, unsigned off)
+{
+   struct smsc_gpio *sg =
+   container_of(chip, struct smsc_gpio, gpio_chip);
+   unsigned int get;
+   return !!(smsc_read(sg-dev,
+   (SMSC_GPIO_DATA_IN_START + SMSC_BANK(off))  SMSC_BIT(off),
+   get));
+}
+
+static void smsc_gpio_set_value(struct gpio_chip *chip,
+   unsigned off, int val)
+{
+   unsigned bank, bit;
+   struct smsc_gpio *sg =
+   container_of(chip, struct smsc_gpio, gpio_chip);
+
+   bank = SMSC_BANK(off);
+   bit = SMSC_BIT(off);
+
+   mutex_lock(sg-lock);
+   if (val)
+   sg-dat_out[bank] |= bit;
+   else
+   sg-dat_out[bank] = ~bit;
+
+   smsc_write(sg-dev, SMSC_GPIO_DATA_OUT_START + bank,
+  sg-dat_out[bank]);
+   mutex_unlock(sg-lock);
+}
+
+static int smsc_gpio_direction_input(struct gpio_chip *chip, unsigned off)
+{
+   unsigned int reg;
+   struct smsc_gpio *sg =
+   container_of(chip, struct smsc_gpio, gpio_chip);
+   int reg_dir;
+
+   mutex_lock(sg-lock);
+   reg_dir = SMSC_CFG_START + off;
+   smsc_read(sg-dev, reg_dir, reg);
+   reg |= SMSC_GPIO_INPUT_LOW;
+   mutex_unlock(sg-lock);
+
+   return smsc_write(sg-dev, reg_dir, reg);
+}
+
+static int smsc_gpio_direction_output(struct gpio_chip *chip,
+unsigned off, int val)
+{
+   unsigned int reg;
+   struct smsc_gpio *sg =
+   container_of(chip, struct smsc_gpio, gpio_chip);
+   int reg_dir;
+
+   mutex_lock(sg-lock);
+   reg_dir = SMSC_CFG_START + off;
+   smsc_read(sg-dev, reg_dir, reg);
+   reg |= SMSC_GPIO_OUTPUT_PP;
+   

Re: [PATCH 12/17] OMAPDSS: clean up dss_mgr_set_timings

2012-09-05 Thread Tomi Valkeinen
On Wed, 2012-09-05 at 17:04 +0530, Archit Taneja wrote:
 On Wednesday 05 September 2012 04:11 PM, Tomi Valkeinen wrote:
  On Wed, 2012-09-05 at 14:45 +0530, Archit Taneja wrote:
  On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote:
  dss_mgr_set_timings() can only be called when the output is not active.
  This means that most of the code in the function is extra, as there's no
  need to write the values to registers, etc, because that will be handled
  when the output will be enabled.
 
  We need to fix dpi_set_timings() before we can make this change. DPI
  still tries to change timings on the fly, i.e, with manager enabled. We
  need to disable and enable the DPI output like we do for other outputs.
 
  Yep, and for HDMI also (I didn't check the others yet).
 
 I don't think HDMI is impacted, we do the full power off and power on 
 for HDMI, so the manager would be disabled when we set the timings.

Ah right.

  I think the simplest way to handle this is to only write the dpi.timings
  in omapdss_dpi_set_timings, and remove the call to dss_mgr_set_timings.
  This is not perfect, as a call to omapdss_dpi_set_timings when the
  display is enabled would result in changing the dpi.timings, but the
  changes wouldn't be actually in use.
 
 The simplest way would be to do what other outputs do, disable the 
 output and re-enable the output with the new timings value, if the panel 
 is enabled.

Not quite, as there's the mutex in dpi so we can't call enable/disable
from set_timings. I could create separate non-locked internal functions
for enable and disable, but that feels more complex than just removing
the enable  disable from set_timings.

In the end we'll anyway only allow changing timings when the output is
disabled.

The only change I had to do, in addition to removing code from
set_timings functions, was to add display disable  enable calls to the
timings sysfs write. omapfb already only calls set_timings when the
output is disabled, and omapdrm does the same.

 Tomi



signature.asc
Description: This is a digitally signed message part


Re: [PATCH] ARM: OMAP4: Fix array size for irq_target_cpu

2012-09-05 Thread Benoit Cousson
Hi Tony,

On 09/05/2012 02:03 AM, Tony Lindgren wrote:
 If NR_IRQS is less than MAX_IRQS, we end up writing past the
 irq_target_cpu array in omap_wakeupgen_init():
 
 /* Associate all the IRQs to boot CPU like GIC init does. */
 for (i = 0; i  max_irqs; i++)
   irq_target_cpu[i] = boot_cpu;
 
 This can happen if SPARSE_IRQ is enabled as by default NR_IRQS is
 set to 16. Without this patch we're overwriting other data during
 the boot.

In fact I already sent a patch to fix that when I started my SPARSE_IRQ 
cleanup, but it looks like it was never merged :-(
I guess I forgot a little bit that series.

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086076.html


Author: Benoit Cousson b-cous...@ti.com
Date:   Thu Feb 23 18:44:27 2012 +0100

ARM: OMAP2+: wakeupgen: Fix wrong array size for irq_target_cpu

The wakeupgen was wrongly allocating an array based on the
NR_IRQS value (410 on OMAP4) whereas it is just capable of handling 128
entries.
Moreover with SPARSE_IRQ, the NR_IRQS number might be 16, and thus
cannot handle the proper number of entries. It will generate an oops as
soon a driver will request an IRQ  16.

Allocate the array using the fixed MAX_IRQS value (128).

Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com

diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wak
index d3d8971..bec55e1 100644
--- a/arch/arm/mach-omap2/omap-wakeupgen.c
+++ b/arch/arm/mach-omap2/omap-wakeupgen.c
@@ -45,7 +45,7 @@ static void __iomem *wakeupgen_base;
 static void __iomem *sar_base;
 static DEFINE_PER_CPU(u32 [NR_REG_BANKS], irqmasks);
 static DEFINE_SPINLOCK(wakeupgen_lock);
-static unsigned int irq_target_cpu[NR_IRQS];
+static unsigned int irq_target_cpu[MAX_IRQS];
 
 /*
  * Static helper functions.
@@ -379,7 +379,7 @@ int __init omap_wakeupgen_init(void)
 */
 
/* Associate all the IRQs to boot CPU like GIC init does. */
-   for (i = 0; i  NR_IRQS; i++)
+   for (i = 0; i  MAX_IRQS; i++)
irq_target_cpu[i] = boot_cpu;
 
irq_hotplug_init();


My original series was doing a little bit more:

0cc3fdc ARM: OMAP: irqs: Set NR_IRQS to NR_IRQS_LEGACY for CONFIG_SPARSE_IRQ
116263d ARM: OMAP2+: gpmc: Use irq_alloc_descs instead of static IRQ range
47b6c8c ARM: OMAP2+: wakeupgen: Fix wrong array size for irq_target_cpu
9017329 ARM: OMAP: irqs: Delete irqs-44xx.h file
b9bb0df ARM: OMAP2+: l3_noc: Remove references to static IRQ defines

But I guess that all of that is now gone with your latest series.

Regards,
Benoit

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH RESEND v5 1/3] arm/dts: AM33XX: Add basic pinctrl device tree data

2012-09-05 Thread AnilKumar Ch
Adds basic pinctrl device tree data for AM33XX family of devices.
This patch is based on the pinctrl-single driver.

Signed-off-by: AnilKumar Ch anilku...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi |9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index be43511..bf5f713 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
};
};
 
+   am3358_pinmux: pinmux@44e10800 {
+   compatible = pinctrl-single;
+   reg = 0x44e10800 0x0238;
+   #address-cells = 1;
+   #size-cells = 0;
+   pinctrl-single,register-width = 32;
+   pinctrl-single,function-mask = 0x7f;
+   };
+
/*
 * XXX: Use a flat representation of the AM33XX interconnect.
 * The real AM33XX interconnect network is quite complex.Since
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH RESEND v5 3/3] arm/dts: AM33XX: Add D_CAN device tree data

2012-09-05 Thread AnilKumar Ch
Add Bosch D_CAN controller device tree data to AM33XX dtsi
file by adding d_can device nodes with all the necessary
parameters.

Signed-off-by: AnilKumar Ch anilku...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi |   18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bf5f713..ab744d6 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -177,5 +177,23 @@
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
};
+
+   dcan0: d_can@481cc000 {
+   compatible = bosch,d_can;
+   ti,hwmods = d_can0;
+   reg = 0x481cc000 0x2000;
+   interrupts = 52;
+   interrupt-parent = intc;
+   status = disabled;
+   };
+
+   dcan1: d_can@481d {
+   compatible = bosch,d_can;
+   ti,hwmods = d_can1;
+   reg = 0x481d 0x2000;
+   interrupts = 55;
+   interrupt-parent = intc;
+   status = disabled;
+   };
};
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v6 2/3] arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone

2012-09-05 Thread AnilKumar Ch
Adds GPIO pinctrl nodes to am3358_pinmux master node to control
user leds (USR0, USR1, USR2 and USR3) present on BeagleBone.

[k...@dominion.thruhere.net: led0, led1 suggested by koen]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
 arch/arm/boot/dts/am335x-bone.dts |   43 +
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-bone.dts 
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..822efe6 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,11 +18,54 @@
reg = 0x8000 0x1000; /* 256 MB */
};
 
+   am3358_pinmux: pinmux@44e10800 {
+   userled_pins: pinmux_userled_pins {
+   pinctrl-single,pins = 
+   0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT | 
MODE7 */
+   0x58 0x17   /* gpmc_a6.gpio1_22, 
OUTPUT_PULLUP | MODE7 */
+   0x5c 0x7/* gpmc_a7.gpio1_23, OUTPUT | 
MODE7 */
+   0x60 0x17   /* gpmc_a8.gpio1_24, 
OUTPUT_PULLUP | MODE7 */
+   ;
+   };
+   };
+
ocp {
uart1: serial@44e09000 {
status = okay;
};
 
+   leds {
+   compatible = gpio-leds;
+   pinctrl-names = default;
+   pinctrl-0 = userled_pins;
+
+   heartbeat {
+   label = beaglebone:green:usr0;
+   gpios = gpio2 21 0;
+   linux,default-trigger = heartbeat;
+   default-state = off;
+   };
+
+   mmc {
+   label = beaglebone:green:usr1;
+   gpios = gpio2 22 0;
+   linux,default-trigger = mmc0;
+   default-state = off;
+   };
+
+   led2 {
+   label = beaglebone:green:usr2;
+   gpios = gpio2 23 0;
+   default-state = off;
+   };
+
+   led3 {
+   label = beaglebone:green:usr3;
+   gpios = gpio2 24 0;
+   default-state = off;
+   };
+   };
+
i2c1: i2c@44e0b000 {
status = okay;
clock-frequency = 40;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v6 0/3] arm/dts: Add device tree data for AM33XX devices

2012-09-05 Thread AnilKumar Ch
Add pinctrl and d_can device tree data to AM33XX family of devices.
First two patches add support for pinctrl DT data and third one
adds dcan DT data.

Reason behind combining these patches is to apply cleanly on
linux-omap tree, because these are sequential patches.

These patches were tested on AM335x-Bone, AM335x-EVM and based
on linux-omap:master with this patch
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg74393.html

Changes from v5:
- Incorporated Koen's comments on v5 series, user leds
  trigger modifications.
- Dropped 4th and 5th patches, submitted v2 versions of
  those in their corresponding mailing lists.

d_can:
  Changes from v4:
- Incorporated Tony's comments on v4
  * Converted all hex numbers to lower-case.
- Updated C_CAN bindings documentation according to recent
  changes.

  Changes from v3:
- Removed d_can1 node from am335x-evm.dts file. Instance
  one of CAN (d_can1) is available on AM335x-EVM only under
  a specific CPLD mode selection. am335x-evm.dts does not
  support this mode so remove the d_can1 node.
- Dropped d_can pinmux settings patch, above comment
  applies here as well.

  Changes from v2:
- Incorporated Vaibhav H's comments on v2
  * Added dcan0 instances to am33xx.dtsi file

  Changes from v1:
- These two patches separated from c_can DT support
  patch series.

pinctrl:
  Changes from v4:
- Incorporated Tony's comments on v4
  * Converted all hex numbers to lower-case.
- Added pinctrl api to leds-gpio driver to configure led
  pins to GPIO mode.

  Changes from v3:
- Updated the reg length based on latest AM335x TRM.

  Changes from v2:
- user led pinmux comments updated according to Tony's
  comment.

  Changes from v1:
- Rebased the patches based on latest pinctrl-single driver

AnilKumar Ch (3):
  arm/dts: AM33XX: Add basic pinctrl device tree data
  arm/dts: AM33XX: Configure pinmuxs for user leds control on Bone
  arm/dts: AM33XX: Add D_CAN device tree data

 arch/arm/boot/dts/am335x-bone.dts |   43 +
 arch/arm/boot/dts/am33xx.dtsi |   27 +++
 2 files changed, 70 insertions(+)

-- 
1.7.9.5

--
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 12/17] OMAPDSS: clean up dss_mgr_set_timings

2012-09-05 Thread Archit Taneja

On Wednesday 05 September 2012 05:11 PM, Tomi Valkeinen wrote:

On Wed, 2012-09-05 at 17:04 +0530, Archit Taneja wrote:

On Wednesday 05 September 2012 04:11 PM, Tomi Valkeinen wrote:

On Wed, 2012-09-05 at 14:45 +0530, Archit Taneja wrote:

On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote:

dss_mgr_set_timings() can only be called when the output is not active.
This means that most of the code in the function is extra, as there's no
need to write the values to registers, etc, because that will be handled
when the output will be enabled.


We need to fix dpi_set_timings() before we can make this change. DPI
still tries to change timings on the fly, i.e, with manager enabled. We
need to disable and enable the DPI output like we do for other outputs.


Yep, and for HDMI also (I didn't check the others yet).


I don't think HDMI is impacted, we do the full power off and power on
for HDMI, so the manager would be disabled when we set the timings.


Ah right.


I think the simplest way to handle this is to only write the dpi.timings
in omapdss_dpi_set_timings, and remove the call to dss_mgr_set_timings.
This is not perfect, as a call to omapdss_dpi_set_timings when the
display is enabled would result in changing the dpi.timings, but the
changes wouldn't be actually in use.


The simplest way would be to do what other outputs do, disable the
output and re-enable the output with the new timings value, if the panel
is enabled.


Not quite, as there's the mutex in dpi so we can't call enable/disable
from set_timings. I could create separate non-locked internal functions
for enable and disable, but that feels more complex than just removing
the enable  disable from set_timings.


Okay, right.



In the end we'll anyway only allow changing timings when the output is
disabled.

The only change I had to do, in addition to removing code from
set_timings functions, was to add display disable  enable calls to the
timings sysfs write. omapfb already only calls set_timings when the
output is disabled, and omapdrm does the same.


Okay, that sounds good then.

Archit

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 1/8] ARM/dts: omap2: Add McBSP entries for OMAP2420 and OMAP2430 SoC

2012-09-05 Thread Peter Ujfalusi
The McBSP IP within OMAP2420 and 2430 is different we need to create separate
dtsi files for them.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/omap2420.dtsi | 39 +++
 arch/arm/boot/dts/omap2430.dtsi | 83 +
 2 files changed, 122 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap2420.dtsi
 create mode 100644 arch/arm/boot/dts/omap2430.dtsi

diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
new file mode 100644
index 000..6174d3d
--- /dev/null
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -0,0 +1,39 @@
+/*
+ * Device Tree Source for OMAP2420 SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ omap2.dtsi
+
+/ {
+   compatible = ti,omap2420, ti,omap2;
+
+   ocp {
+   mcbsp1: mcbsp@48074000 {
+   compatible = ti,omap2420-mcbsp;
+   reg = 0x48074000 0xff;
+   reg-names = mpu;
+   interrupts = 59, /* TX interrupt */
+60; /* RX interrupt */
+   interrupt-names = tx, rx;
+   interrupt-parent = intc;
+   ti,hwmods = mcbsp1;
+   };
+
+   mcbsp2: mcbsp@48076000 {
+   compatible = ti,omap2420-mcbsp;
+   reg = 0x48076000 0xff;
+   reg-names = mpu;
+   interrupts = 62, /* TX interrupt */
+63; /* RX interrupt */
+   interrupt-names = tx, rx;
+   interrupt-parent = intc;
+   ti,hwmods = mcbsp2;
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
new file mode 100644
index 000..59a639a
--- /dev/null
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -0,0 +1,83 @@
+/*
+ * Device Tree Source for OMAP243x SoC
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ omap2.dtsi
+
+/ {
+   compatible = ti,omap2430, ti,omap2;
+
+   ocp {
+   mcbsp1: mcbsp@48074000 {
+   compatible = ti,omap2430-mcbsp;
+   reg = 0x48074000 0xff;
+   reg-names = mpu;
+   interrupts = 64, /* OCP compliant interrupt */
+59, /* TX interrupt */
+60, /* RX interrupt */
+61; /* RX overflow interrupt */
+   interrupt-names = common, tx, rx, rx_overflow;
+   interrupt-parent = intc;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp1;
+   };
+
+   mcbsp2: mcbsp@48076000 {
+   compatible = ti,omap2430-mcbsp;
+   reg = 0x48076000 0xff;
+   reg-names = mpu;
+   interrupts = 16, /* OCP compliant interrupt */
+62, /* TX interrupt */
+63; /* RX interrupt */
+   interrupt-names = common, tx, rx;
+   interrupt-parent = intc;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp2;
+   };
+
+   mcbsp3: mcbsp@4808c000 {
+   compatible = ti,omap2430-mcbsp;
+   reg = 0x4808c000 0xff;
+   reg-names = mpu;
+   interrupts = 17, /* OCP compliant interrupt */
+89, /* TX interrupt */
+90; /* RX interrupt */
+   interrupt-names = common, tx, rx;
+   interrupt-parent = intc;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp3;
+   };
+
+   mcbsp4: mcbsp@4808e000 {
+   compatible = ti,omap2430-mcbsp;
+   reg = 0x4808e000 0xff;
+   reg-names = mpu;
+   interrupts = 18, /* OCP compliant interrupt */
+54, /* TX interrupt */
+55; /* RX interrupt */
+   interrupt-names = common, tx, rx;
+   interrupt-parent = intc;
+   ti,buffer-size = 128;
+   

[PATCH v3 2/8] ARM/dts: omap2420-h4: Include omap2420.dtsi file instead the common omap2

2012-09-05 Thread Peter Ujfalusi
Since the board is based on OMAP2420 we should include the dedicated dtsi
file (which includes the common omap2 dtsi).

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/omap2420-h4.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap2420-h4.dts 
b/arch/arm/boot/dts/omap2420-h4.dts
index 25b50b7..77b84e1 100644
--- a/arch/arm/boot/dts/omap2420-h4.dts
+++ b/arch/arm/boot/dts/omap2420-h4.dts
@@ -7,7 +7,7 @@
  */
 /dts-v1/;
 
-/include/ omap2.dtsi
+/include/ omap2420.dtsi
 
 / {
model = TI OMAP2420 H4 board;
-- 
1.7.12

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 4/8] ARM/dts: omap4: Add McBSP entries

2012-09-05 Thread Peter Ujfalusi
Create the sections describing the McBSP ports to be able to use them via
DT.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/omap4.dtsi | 47 
 1 file changed, 47 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 1853dc7..5ed3b94 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -287,6 +287,53 @@
ti,hwmods = dmic;
};
 
+   mcbsp1: mcbsp@40122000 {
+   compatible = ti,omap4-mcbsp;
+   reg = 0x40122000 0xff, /* MPU private access */
+ 0x49022000 0xff; /* L3 Interconnect */
+   reg-names = mpu, dma;
+   interrupts = 0 17 0x4;
+   interrupt-names = common;
+   interrupt-parent = gic;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp1;
+   };
+
+   mcbsp2: mcbsp@40124000 {
+   compatible = ti,omap4-mcbsp;
+   reg = 0x40124000 0xff, /* MPU private access */
+ 0x49024000 0xff; /* L3 Interconnect */
+   reg-names = mpu, dma;
+   interrupts = 0 22 0x4;
+   interrupt-names = common;
+   interrupt-parent = gic;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp2;
+   };
+
+   mcbsp3: mcbsp@40126000 {
+   compatible = ti,omap4-mcbsp;
+   reg = 0x40126000 0xff, /* MPU private access */
+ 0x49026000 0xff; /* L3 Interconnect */
+   reg-names = mpu, dma;
+   interrupts = 0 23 0x4;
+   interrupt-names = common;
+   interrupt-parent = gic;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp3;
+   };
+
+   mcbsp4: mcbsp@48096000 {
+   compatible = ti,omap4-mcbsp;
+   reg = 0x48096000 0xff; /* L4 Interconnect */
+   reg-names = mpu;
+   interrupts = 0 16 0x4;
+   interrupt-names = common;
+   interrupt-parent = gic;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp4;
+   };
+
keypad: keypad@4a31c000 {
compatible = ti,omap4-keypad;
ti,hwmods = kbd;
-- 
1.7.12

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 3/8] ARM/dts: omap3: Add McBSP entries

2012-09-05 Thread Peter Ujfalusi
Create the needed sections to be able to probe McBSP ports via DT.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/omap3.dtsi | 69 
 1 file changed, 69 insertions(+)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 8109471..f024bb3 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -220,5 +220,74 @@
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
};
+
+   mcbsp1: mcbsp@48074000 {
+   compatible = ti,omap3-mcbsp;
+   reg = 0x48074000 0xff;
+   reg-names = mpu;
+   interrupts = 16, /* OCP compliant interrupt */
+59, /* TX interrupt */
+60; /* RX interrupt */
+   interrupt-names = common, tx, rx;
+   interrupt-parent = intc;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp1;
+   };
+
+   mcbsp2: mcbsp@49022000 {
+   compatible = ti,omap3-mcbsp;
+   reg = 0x49022000 0xff,
+ 0x49028000 0xff;
+   reg-names = mpu, sidetone;
+   interrupts = 17, /* OCP compliant interrupt */
+62, /* TX interrupt */
+63, /* RX interrupt */
+4;  /* Sidetone */
+   interrupt-names = common, tx, rx, sidetone;
+   interrupt-parent = intc;
+   ti,buffer-size = 1280;
+   ti,hwmods = mcbsp2;
+   };
+
+   mcbsp3: mcbsp@49024000 {
+   compatible = ti,omap3-mcbsp;
+   reg = 0x49024000 0xff,
+ 0x4902a000 0xff;
+   reg-names = mpu, sidetone;
+   interrupts = 22, /* OCP compliant interrupt */
+89, /* TX interrupt */
+90, /* RX interrupt */
+5;  /* Sidetone */
+   interrupt-names = common, tx, rx, sidetone;
+   interrupt-parent = intc;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp3;
+   };
+
+   mcbsp4: mcbsp@49026000 {
+   compatible = ti,omap3-mcbsp;
+   reg = 0x49026000 0xff;
+   reg-names = mpu;
+   interrupts = 23, /* OCP compliant interrupt */
+54, /* TX interrupt */
+55; /* RX interrupt */
+   interrupt-names = common, tx, rx;
+   interrupt-parent = intc;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp4;
+   };
+
+   mcbsp5: mcbsp@48096000 {
+   compatible = ti,omap3-mcbsp;
+   reg = 0x48096000 0xff;
+   reg-names = mpu;
+   interrupts = 27, /* OCP compliant interrupt */
+81, /* TX interrupt */
+82; /* RX interrupt */
+   interrupt-names = common, tx, rx;
+   interrupt-parent = intc;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp5;
+   };
};
 };
-- 
1.7.12

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 6/8] ARM/dts: omap5: Add McBSP entries

2012-09-05 Thread Peter Ujfalusi
Create the sections describing the McBSP ports to be able to use them via
DT.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi | 36 
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 4c11ae1..aa97e93 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -251,5 +251,41 @@
compatible = ti,omap4-keypad;
ti,hwmods = kbd;
};
+
+   mcbsp1: mcbsp@40122000 {
+   compatible = ti,omap4-mcbsp;
+   reg = 0x40122000 0xff, /* MPU private access */
+ 0x49022000 0xff; /* L3 Interconnect */
+   reg-names = mpu, dma;
+   interrupts = 0 17 0x4;
+   interrupt-names = common;
+   interrupt-parent = gic;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp1;
+   };
+
+   mcbsp2: mcbsp@40124000 {
+   compatible = ti,omap4-mcbsp;
+   reg = 0x40124000 0xff, /* MPU private access */
+ 0x49024000 0xff; /* L3 Interconnect */
+   reg-names = mpu, dma;
+   interrupts = 0 22 0x4;
+   interrupt-names = common;
+   interrupt-parent = gic;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp2;
+   };
+
+   mcbsp3: mcbsp@40126000 {
+   compatible = ti,omap4-mcbsp;
+   reg = 0x40126000 0xff, /* MPU private access */
+ 0x49026000 0xff; /* L3 Interconnect */
+   reg-names = mpu, dma;
+   interrupts = 0 23 0x4;
+   interrupt-names = common;
+   interrupt-parent = gic;
+   ti,buffer-size = 128;
+   ti,hwmods = mcbsp3;
+   };
};
 };
-- 
1.7.12

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 8/8] ARM/dts: omap3-beagle: Enable audio support

2012-09-05 Thread Peter Ujfalusi
Add the needed sections to enable audio support on BeagleBoard when booted
with DT blob.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/omap3-beagle.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 16bff8b..10d87a2 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -25,6 +25,14 @@
gpios = twl_gpio 19 0; /* LEDB */
};
};
+
+   sound {
+   compatible = ti,omap-twl4030;
+   ti,model = omap3beagle;
+
+   ti,mcbsp = mcbsp2;
+   ti,codec = twl_audio;
+   };
 };
 
 i2c1 {
@@ -40,6 +48,12 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 300;
};
+
+   twl_audio: audio {
+   compatible = ti,twl4030-audio;
+   codec {
+   };
+   };
};
 };
 
-- 
1.7.12

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 5/8] ARM/dts: omap4: Add reg-names for McPDM and DMIC

2012-09-05 Thread Peter Ujfalusi
In order to get the memory areas by name when booted with DT.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/omap4.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 5ed3b94..9f851df 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -273,6 +273,7 @@
compatible = ti,omap4-mcpdm;
reg = 0x40132000 0x7f, /* MPU private access */
  0x49032000 0x7f; /* L3 Interconnect */
+   reg-names = mpu, dma;
interrupts = 0 112 0x4;
interrupt-parent = gic;
ti,hwmods = mcpdm;
@@ -282,6 +283,7 @@
compatible = ti,omap4-dmic;
reg = 0x4012e000 0x7f, /* MPU private access */
  0x4902e000 0x7f; /* L3 Interconnect */
+   reg-names = mpu, dma;
interrupts = 0 114 0x4;
interrupt-parent = gic;
ti,hwmods = dmic;
-- 
1.7.12

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v3 7/8] ARM/dts: omap5: Add McPDM and DMIC section to the dtsi file

2012-09-05 Thread Peter Ujfalusi
To be able to load the McPDM and DMIC driver when booted with device tree.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index aa97e93..9ac75b3 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -252,6 +252,26 @@
ti,hwmods = kbd;
};
 
+   mcpdm: mcpdm@40132000 {
+   compatible = ti,omap4-mcpdm;
+   reg = 0x40132000 0x7f, /* MPU private access */
+ 0x49032000 0x7f; /* L3 Interconnect */
+   reg-names = mpu, dma;
+   interrupts = 0 112 0x4;
+   interrupt-parent = gic;
+   ti,hwmods = mcpdm;
+   };
+
+   dmic: dmic@4012e000 {
+   compatible = ti,omap4-dmic;
+   reg = 0x4012e000 0x7f, /* MPU private access */
+ 0x4902e000 0x7f; /* L3 Interconnect */
+   reg-names = mpu, dma;
+   interrupts = 0 114 0x4;
+   interrupt-parent = gic;
+   ti,hwmods = dmic;
+   };
+
mcbsp1: mcbsp@40122000 {
compatible = ti,omap4-mcbsp;
reg = 0x40122000 0xff, /* MPU private access */
-- 
1.7.12

--
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/2] pinctrl: pinctrl-single: new type: pinctrl-single,bits

2012-09-05 Thread Linus Walleij
On Wed, Sep 5, 2012 at 11:01 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:

 When configuring pinmux with pinctrl-single there could be a case when one
 register is used to configure mux for more than one pin.
 In this case the use of pinctrl-single,pins is a bit problematic since we can
 only update the whole register (restricted by the mask).
 In such a situations the pinctrl-single,bits could provide a safe way to 
 handle
 the mux.

 pinctrl-single,bits takes three parameters: reg offset, value, sub-mask
 The sub mask is used to mask part of the register to make sure we do not 
 change
 bits outside of the scope of this pin.

 The first patch in this series is to fix the previous pinctrl-since,pins
 implementation because it was not using the mask on the value which could 
 result
 changed bits outside of the mask.

This looks sane to me, but I'd like Tony to ACK before I apply it.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v8 0/3] GPMC driver conversion

2012-09-05 Thread Afzal Mohammed
Hi,

Basic gpmc driver conversion series. Driver that is now created out of
gpmc code is a simple one, it handles tasks that were earlier executed
by gpmc_init. Now instead of relying on cpu_is_* checks, it obtains
resources and clk handle in the standard Linux way. The existing gpmc
interface works as was without this series.

HWMOD patch also has been brought into this series back with v7 series

As this creates only a basic driver, further gpmc driver work can be
based over this, while having a driver first in place.

This series is based on l-o/testing-cleanup as on 5-Sep-12,
i.e. over commit,

e3a5c14 ARM: OMAP1: Move SoC specific headers from plat to mach for omap1

per Tony's suggestion.

It is available
@git://gitorious.org/x0148406-public/linux-kernel.git gpmc-drv-v8

This series has been tested on omap3evm (rev G).


GPMC (General Purpose Memory Controller) in brief:
GPMC is an unified memory controller dedicated to interfacing external
memory devices like
 Asynchronous SRAM like memories and application specific integrated circuit 
devices.
 Asynchronous, synchronous, and page mode burst NOR flash devices NAND flash
 Pseudo-SRAM devices

GPMC details can be referred in AM335X Technical Reference Manual
@ http://www.ti.com/lit/pdf/spruh73

Regards
Afzal

v8:
Use feature flag to decide whether wr_access and wr_data_mux_bus
timings has to be configured (PATCH 3/3)

v7:
Create a simple driver that gets resources  clk the standard Linux way
Pull in HMWOD patch back into this series
v6: Capability flag added that stores features based on revision
Macros used for finding revision
Return value from memory setup function corrected
Comments added to clarify handling of device type, size
Bool type time setting patch removed as has been taken care in [2]
Handle variable number of waitpin
Warn if driver is unable to configure interrupt
Enhance some of commit messages
Handle shared writeprotect case
Fix a bug in gpmc_create_device
Get clk from hwmod
Remove unwanted code
v5: Make this a purely driver conversion series, i.e. gpmc-mtd
interactions has been made as a separate series, so is adding
hwmod entry for OMAP2/3.
And modifying gpmc peripheral platform initialization has been
separated out of this series, so is migrating boards to use new
driver interface. GPMC driver conversion which was done in a few
patches in v4 has been tranformed to series of small patches.
Also care has been taken care that old interface will not break
with any of these patches, so both interfaces can coexist.
This helps in converting boards one-by-one gradually. Acquiring
CS has been thrown out. And conclusive comments on v4 has been
addressed.
v4: Handle wait pin (except for interrupts), enhance configuration
 timing interface of GPMC to take care of all boards. Dynamic
allocation of interrupt instead of static. Convert remaining
peripherals to work with GPMC driver. Handle acquiring NAND CS#,
adapt to HWMOD, update HWMOD OMAP2/3 entries, other minor
commenst on v3.
v3: Single device structure passed from platform for peripherals using
multiple CS instead of using multiple device structure having a few
redundant data, handle interrupts, GPMC NAND handling by GPMC NAND
driver instead of GPMC driver
v2: Avoid code movement that kept similar code together (for easy review)


Afzal Mohammed (3):
  ARM: OMAP2/3: hwmod data: add gpmc
  ARM: OMAP2+: gpmc: Adapt to HWMOD
  ARM: OMAP2+: gpmc: minimal driver support

 arch/arm/mach-omap2/gpmc.c |  197 +++-
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   18 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   18 ++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |   44 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   54 ++
 arch/arm/mach-omap2/omap_hwmod_common_data.h   |1 +
 arch/arm/mach-omap2/prcm-common.h  |2 +
 7 files changed, 284 insertions(+), 50 deletions(-)

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v8 1/3] ARM: OMAP2/3: hwmod data: add gpmc

2012-09-05 Thread Afzal Mohammed
Add gpmc hwmod and associated interconnect data

Signed-off-by: Afzal Mohammed af...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   18 +++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   18 +++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |   44 -
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   54 
 arch/arm/mach-omap2/omap_hwmod_common_data.h   |1 +
 arch/arm/mach-omap2/prcm-common.h  |2 +
 6 files changed, 136 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index e7b90a0..b22c35b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -537,6 +537,15 @@ static struct omap_hwmod_addr_space 
omap2420_counter_32k_addrs[] = {
{ }
 };
 
+static struct omap_hwmod_addr_space omap2420_gpmc_addrs[] = {
+   {
+   .pa_start   = 0x6800A000,
+   .pa_end = 0x6800AFFF,
+   .flags  = ADDR_TYPE_RT
+   },
+   { }
+};
+
 static struct omap_hwmod_ocp_if omap2420_l4_wkup__counter_32k = {
.master = omap2xxx_l4_wkup_hwmod,
.slave  = omap2xxx_counter_32k_hwmod,
@@ -545,6 +554,14 @@ static struct omap_hwmod_ocp_if 
omap2420_l4_wkup__counter_32k = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+static struct omap_hwmod_ocp_if omap2420_l3__gpmc = {
+   .master = omap2xxx_l3_main_hwmod,
+   .slave  = omap2xxx_gpmc_hwmod,
+   .clk= core_l3_ck,
+   .addr   = omap2420_gpmc_addrs,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] __initdata = {
omap2xxx_l3_main__l4_core,
omap2xxx_mpu__l3_main,
@@ -588,6 +605,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] 
__initdata = {
omap2420_l4_core__msdi1,
omap2420_l4_core__hdq1w,
omap2420_l4_wkup__counter_32k,
+   omap2420_l3__gpmc,
NULL,
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 5fe65ae..8340516 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -888,6 +888,15 @@ static struct omap_hwmod_addr_space 
omap2430_counter_32k_addrs[] = {
{ }
 };
 
+static struct omap_hwmod_addr_space omap2430_gpmc_addrs[] = {
+   {
+   .pa_start   = 0x6E00,
+   .pa_end = 0x6E000FFF,
+   .flags  = ADDR_TYPE_RT
+   },
+   { }
+};
+
 static struct omap_hwmod_ocp_if omap2430_l4_wkup__counter_32k = {
.master = omap2xxx_l4_wkup_hwmod,
.slave  = omap2xxx_counter_32k_hwmod,
@@ -896,6 +905,14 @@ static struct omap_hwmod_ocp_if 
omap2430_l4_wkup__counter_32k = {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+static struct omap_hwmod_ocp_if omap2430_l3__gpmc = {
+   .master = omap2xxx_l3_main_hwmod,
+   .slave  = omap2xxx_gpmc_hwmod,
+   .clk= core_l3_ck,
+   .addr   = omap2430_gpmc_addrs,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] __initdata = {
omap2xxx_l3_main__l4_core,
omap2xxx_mpu__l3_main,
@@ -946,6 +963,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] 
__initdata = {
omap2430_l4_core__mcbsp5,
omap2430_l4_core__hdq1w,
omap2430_l4_wkup__counter_32k,
+   omap2430_l3__gpmc,
NULL,
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 055f735..dcdcbcc 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -173,6 +173,26 @@ struct omap_hwmod_class omap2xxx_mcspi_class = {
 };
 
 /*
+ * 'gpmc' class
+ * general purpose memory controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap2xxx_gpmc_sysc = {
+   .rev_offs   = 0x,
+   .sysc_offs  = 0x0010,
+   .syss_offs  = 0x0014,
+   .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_SIDLEMODE |
+  SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+   .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2xxx_gpmc_hwmod_class = {
+   .name   = gpmc,
+   .sysc   = omap2xxx_gpmc_sysc,
+};
+
+/*
  * IP blocks
  */
 
@@ -724,7 +744,6 @@ struct omap_hwmod omap2xxx_mcspi2_hwmod = {
.dev_attr   = omap_mcspi2_dev_attr,
 };
 
-
 static struct omap_hwmod_class omap2xxx_counter_hwmod_class = {
.name   = counter,
 };
@@ -743,3 +762,26 @@ struct omap_hwmod 

[PATCH v8 2/3] ARM: OMAP2+: gpmc: Adapt to HWMOD

2012-09-05 Thread Afzal Mohammed
Create API for platforms to adapt GPMC to HWMOD

Signed-off-by: Afzal Mohammed af...@ti.com
---
 arch/arm/mach-omap2/gpmc.c |   26 ++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index dbc1ebc..c45f185 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -29,11 +29,14 @@
 
 #include plat/gpmc.h
 #include plat/sdrc.h
+#include plat/omap_device.h
 
 #include soc.h
 
 #include common.h
 
+#defineDEVICE_NAME omap-gpmc
+
 /* GPMC register offsets */
 #define GPMC_REVISION  0x00
 #define GPMC_SYSCONFIG 0x10
@@ -897,6 +900,29 @@ static int __init gpmc_init(void)
 }
 postcore_initcall(gpmc_init);
 
+static int __init omap_gpmc_init(void)
+{
+   struct omap_hwmod *oh;
+   struct platform_device *pdev;
+   char *oh_name = gpmc;
+
+   oh = omap_hwmod_lookup(oh_name);
+   if (!oh) {
+   pr_err(Could not look up %s\n, oh_name);
+   return -ENODEV;
+   }
+
+   pdev = omap_device_build(DEVICE_NAME, -1, oh, NULL, 0, NULL, 0, 0);
+   if (IS_ERR(pdev)) {
+   WARN(1, Can't build omap_device for %s:%s.\n,
+   DEVICE_NAME, oh-name);
+   return PTR_ERR(pdev);
+   }
+
+   return 0;
+}
+postcore_initcall(omap_gpmc_init);
+
 static irqreturn_t gpmc_handle_irq(int irq, void *dev)
 {
int i;
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v8 3/3] ARM: OMAP2+: gpmc: minimal driver support

2012-09-05 Thread Afzal Mohammed
Create a minimal driver out of gpmc code.
Responsibilities handled by earlier gpmc
initialization is now achieved in probe.

Signed-off-by: Afzal Mohammed af...@ti.com
---
 arch/arm/mach-omap2/gpmc.c |  171 +++-
 1 files changed, 122 insertions(+), 49 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index c45f185..4ae2bb8 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -24,6 +24,7 @@
 #include linux/io.h
 #include linux/module.h
 #include linux/interrupt.h
+#include linux/platform_device.h
 
 #include asm/mach-types.h
 
@@ -85,6 +86,12 @@
 #define ENABLE_PREFETCH(0x1  7)
 #define DMA_MPU_MODE   2
 
+#defineGPMC_REVISION_MAJOR(l)  ((l  4)  0xf)
+#defineGPMC_REVISION_MINOR(l)  (l  0xf)
+
+#defineGPMC_HAS_WR_ACCESS  0x1
+#defineGPMC_HAS_WR_DATA_MUX_BUS0x2
+
 /* XXX: Only NAND irq has been considered,currently these are the only ones 
used
  */
 #defineGPMC_NR_IRQ 2
@@ -130,7 +137,10 @@ static struct resource gpmc_cs_mem[GPMC_CS_NUM];
 static DEFINE_SPINLOCK(gpmc_mem_lock);
 static unsigned int gpmc_cs_map;   /* flag for cs which are initialized */
 static int gpmc_ecc_used = -EINVAL;/* cs using ecc engine */
-
+static struct device *gpmc_dev;
+static int gpmc_irq;
+static resource_size_t phys_base, mem_size;
+static unsigned gpmc_capability;
 static void __iomem *gpmc_base;
 
 static struct clk *gpmc_l3_clk;
@@ -320,10 +330,10 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings 
*t)
 
GPMC_SET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
 
-   if (cpu_is_omap34xx()) {
+   if (gpmc_capability  GPMC_HAS_WR_DATA_MUX_BUS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
+   if (gpmc_capability  GPMC_HAS_WR_ACCESS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
-   }
 
/* caller is expected to have initialized CONFIG1 to cover
 * at least sync vs async
@@ -433,6 +443,19 @@ static int gpmc_cs_insert_mem(int cs, unsigned long base, 
unsigned long size)
return r;
 }
 
+static int gpmc_cs_delete_mem(int cs)
+{
+   struct resource *res = gpmc_cs_mem[cs];
+   int r;
+
+   spin_lock(gpmc_mem_lock);
+   r = release_resource(gpmc_cs_mem[cs]);
+   res-start = res-end = 0;
+   spin_unlock(gpmc_mem_lock);
+
+   return r;
+}
+
 int gpmc_cs_request(int cs, unsigned long size, unsigned long *base)
 {
struct resource *res = gpmc_cs_mem[cs];
@@ -769,7 +792,7 @@ static void gpmc_irq_noop(struct irq_data *data) { }
 
 static unsigned int gpmc_irq_noop_ret(struct irq_data *data) { return 0; }
 
-static int gpmc_setup_irq(int gpmc_irq)
+static int gpmc_setup_irq(void)
 {
int i;
u32 regval;
@@ -813,7 +836,37 @@ static int gpmc_setup_irq(int gpmc_irq)
return request_irq(gpmc_irq, gpmc_handle_irq, 0, gpmc, NULL);
 }
 
-static void __init gpmc_mem_init(void)
+static __exit int gpmc_free_irq(void)
+{
+   int i;
+
+   if (gpmc_irq)
+   free_irq(gpmc_irq, NULL);
+
+   for (i = 0; i  GPMC_NR_IRQ; i++) {
+   irq_set_handler(gpmc_client_irq[i].irq, NULL);
+   irq_set_chip(gpmc_client_irq[i].irq, no_irq_chip);
+   irq_modify_status(gpmc_client_irq[i].irq, 0, 0);
+   }
+
+   irq_free_descs(gpmc_irq_start, GPMC_NR_IRQ);
+
+   return 0;
+}
+
+static void __devexit gpmc_mem_exit(void)
+{
+   int cs;
+
+   for (cs = 0; cs  GPMC_CS_NUM; cs++) {
+   if (!gpmc_cs_mem_enabled(cs))
+   continue;
+   gpmc_cs_delete_mem(cs);
+   }
+
+}
+
+static void __devinit gpmc_mem_init(void)
 {
int cs;
unsigned long boot_rom_space = 0;
@@ -840,65 +893,85 @@ static void __init gpmc_mem_init(void)
}
 }
 
-static int __init gpmc_init(void)
+static __devinit int gpmc_probe(struct platform_device *pdev)
 {
u32 l;
-   int ret = -EINVAL;
-   int gpmc_irq;
-   char *ck = NULL;
-
-   if (cpu_is_omap24xx()) {
-   ck = core_l3_ck;
-   if (cpu_is_omap2420())
-   l = OMAP2420_GPMC_BASE;
-   else
-   l = OMAP34XX_GPMC_BASE;
-   gpmc_irq = 20 + OMAP_INTC_START;
-   } else if (cpu_is_omap34xx()) {
-   ck = gpmc_fck;
-   l = OMAP34XX_GPMC_BASE;
-   gpmc_irq = 20 + OMAP_INTC_START;
-   } else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
-   /* Base address and irq number are same for OMAP4/5 */
-   ck = gpmc_ck;
-   l = OMAP44XX_GPMC_BASE;
-   gpmc_irq = 20 + OMAP44XX_IRQ_GIC_START;
-   }
+   struct resource *res;
 
-   if (WARN_ON(!ck))
-   return ret;
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (res 

RE: [PATCH v7 3/3] ARM: OMAP2+: gpmc: minimal driver support

2012-09-05 Thread Mohammed, Afzal
Hi,

On Wed, Sep 05, 2012 at 14:20:09, Mohammed, Afzal wrote:
 Create a minimal driver out of gpmc code.
 Responsibilities handled by earlier gpmc
 initialization is now achieved in probe.

 + if (GPMC_REVISION_MAJOR(l)  0x4)
 + gpmc_capability = GPMC_HAS_WR_ACCESS | GPMC_HAS_WR_DATA_MUX_BUS;

v8 of this series has been submitted leveraging gpmc capability
flag to determine whether wr_access and wr_data_mux_bus timing
fields has to be configured.

Regards
Afzal
N�r��yb�X��ǧv�^�)޺{.n�+{��f��{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

RE: [PATCH 7/9] ARM: OMAP2+: Prepare for irqs.h removal

2012-09-05 Thread Mohammed, Afzal
Hi Tony,

On Wed, Sep 05, 2012 at 14:33:58, Mohammed, Afzal wrote:
 On Wed, Sep 05, 2012 at 06:39:22, Tony Lindgren wrote:
  * Mohammed, Afzal af...@ti.com [120904 01:47]:
 
   *I am not sending the patches now to avoid confusion by way of having
   too many patch series*
   
   In case you like this, let me know, I will post.
  
  Yes please post the patches rebased on testing-cleanup branch that I
  just pushed. That branch is not immutable yet though as we're waiting
  to hear from Arnd regrading the first patch in the branch.
 
 The patches rebased on testing-cleanup branch has been posted [1].

Latest version (v8) of patch series has been posted [A] with an
enhancement, please ignore v7.

Regards
Afzal

[A] http://marc.info/?l=linux-omapm=134684859913232w=2


N�r��yb�X��ǧv�^�)޺{.n�+{��f��{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

Re: [PATCH 5/9] ARM: OMAP2+: Remove hardcoded twl4030 gpio_base, irq_base and irq_end

2012-09-05 Thread Peter Ujfalusi
Hi Tony,

On 09/01/2012 02:52 AM, Tony Lindgren wrote:
 * Tony Lindgren t...@atomide.com [120830 17:53]:
 We can't use hardcoded interrupts for SPARSE_IRQ, and can replace
 the hardcoded gpio_base with twl_gpiochip.base after it's been
 allocated.
 ...
 
 --- a/include/linux/mfd/twl6040.h
 +++ b/include/linux/mfd/twl6040.h
 @@ -194,7 +194,6 @@ struct twl6040_vibra_data {
  
  struct twl6040_platform_data {
  int audpwron_gpio;  /* audio power-on gpio */
 -unsigned int irq_base;
  
  struct twl6040_codec_data *codec;
  struct twl6040_vibra_data *vibra;
 
 The platform_data irq_base is not being used it seems..

Yes, this is not in use.

 
 @@ -222,7 +221,6 @@ struct twl6040 {
  unsigned int mclk;
  
  unsigned int irq;
 -unsigned int irq_base;
  u8 irq_masks_cur;
  u8 irq_masks_cache;
  };
 
 ..but irq_base here is still in use as that's where the value from
 irq_alloc_descs() is being stored to. So I'll drop the changes to
 struct twl6040 from this patch as otherwise twl6040 code won't compile.
 
 Turns out I did not have twl6040 selected in any of the testconfigs
 that I ran.

I store the irq_base in a private data for the MFD driver so child drivers can
request the correct IRQ.

You can safely remove the irq_base from twl6040_platform_data struct

-- 
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: OMAP4: Fix array size for irq_target_cpu

2012-09-05 Thread Shilimkar, Santosh
On Wed, Sep 5, 2012 at 5:11 PM, Benoit Cousson b-cous...@ti.com wrote:

 Hi Tony,

 On 09/05/2012 02:03 AM, Tony Lindgren wrote:
  If NR_IRQS is less than MAX_IRQS, we end up writing past the
  irq_target_cpu array in omap_wakeupgen_init():
 
  /* Associate all the IRQs to boot CPU like GIC init does. */
  for (i = 0; i  max_irqs; i++)
irq_target_cpu[i] = boot_cpu;
 
  This can happen if SPARSE_IRQ is enabled as by default NR_IRQS is
  set to 16. Without this patch we're overwriting other data during
  the boot.

 In fact I already sent a patch to fix that when I started my SPARSE_IRQ
 cleanup, but it looks like it was never merged :-(
 I guess I forgot a little bit that series.

Indeed. I remember acking few patches in that series.
Infact this patch set was the basis on which I was talking to Arnd
that SPARSE_IRQ
should work on OMAP. Didn't think that it has not made it yet in mainline.

Regards
Santosh
--
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 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts

2012-09-05 Thread Koen Kooi

Op 28 aug. 2012, om 07:34 heeft AnilKumar, Chimata anilku...@ti.com het 
volgende geschreven:

 Hi Koen,
 
 On Fri, Aug 24, 2012 at 13:32:17, Koen Kooi wrote:
 
 Op 24 aug. 2012, om 09:56 heeft Koen Kooi k...@dominion.thruhere.net het 
 volgende geschreven:
 
 
 Op 24 aug. 2012, om 09:26 heeft AnilKumar, Chimata anilku...@ti.com het 
 volgende geschreven:
 
 Hi Koen,
 
 On Fri, Aug 24, 2012 at 11:58:34, Koen Kooi wrote:
 
 Op 24 aug. 2012, om 07:50 heeft AnilKumar, Chimata anilku...@ti.com 
 het volgende geschreven:
 
 Hi Koen,
 
 On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote:
 
 Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het 
 volgende geschreven:
 
 Add tps65217 regulator device tree data to AM335x-Bone by adding
 regulator consumers with tightened constraints and regulator-name.
 TPS65217 regulator handle can be obtained by using this regulator
 name.
 
 This patch also add I2C node with I2C frequency and tps65217 PMIC
 I2C slave address.
 
 Signed-off-by: AnilKumar Ch anilku...@ti.com
 
 I tried this and the kernel immediately crashes on my beaglebone. Could 
 you upload the complete git tree and .config you used to test this to 
 somewhere public please?
 
 Use this repo to test on beaglebone
 https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl
 
 This wiki talks about how to build and use?
 https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree
 
 Note: Enable tps65217 regulator in kernel config.
 
 I used that repo and as a seperate test I rebased that to latest 
 mainline, same thing: as soon as I turn on the TPS in the .config it 
 crashes on boot. Is the pinctrl repo the *exact* repo you used to test 
 the patches on beaglebone?
 
 I tested on latest mainline after merging to
 am335x-upstream-staging-pinctrl (voltage also changing)
 
 Can you share your .config and uImage?
 
 Config: 
 https://github.com/beagleboard/kernel/blob/beaglebone-3.6/patches/configs/beaglebone
 
 My config details:- (After merge)
 1. omap2plus_defconfig
 2. Enable tps65217 MFD driver
 3. Enable tps65217 regulator driver
 
 
 I rebased onto latest mainline and refreshed the base patches from Vaibhav 
 and I now get: 
 
 [0.246796] tps65217 0-0024: TPS65217 ID 0xf version 1.1
 
 So it boots! I don't know what made it break before, but it's working now :)
 
 *sigh* I'm an idiot:
 
 root@beaglebone:~# uname -a
 Linux beaglebone 3.6.0-rc3-00103-gfd02083 #86 SMP Fri Aug 24 09:45:54 CEST 
 2012 armv7l GNU/Linux
 root@beaglebone:~# zcat /proc/config.gz | grep 217
 CONFIG_MFD_TPS65217=y
 # CONFIG_REGULATOR_TPS65217 is not set
 
 Will retry with regulator driver actually turned on in a bit.
 
 Is it working after enabling the regulator?

It took me a while to get back to this problem, but it still isn't working for 
me. I did manage to get more info on the error:

root@bone-mainline:~# insmod tps65217-regulator.ko
[   32.754419] Unable to handle kernel NULL pointer dereference at virtual 
address 00c8
[   32.763087] pgd = cea6
[   32.765969] [00c8] *pgd=8fbed831, *pte=, *ppte=
[   32.772617] Internal error: Oops: 17 [#1] SMP THUMB2
[   32.777827] Modules linked in: tps65217_regulator(+) ip_tables x_tables 
snd_soc_omap snd_soc_core regmap_spi snd_pcm snd_timer snd soundcore 
snd_page_alloc ipv6
[   32.792976] CPU: 0Not tainted  (3.6.0-rc4 #109)
[   32.798106] PC is at regmap_read+0x8/0x38
[   32.802315] LR is at regulator_get_voltage_sel_regmap+0x15/0x38
[   32.808525] pc : [c0233c8c]lr : [c0208619]psr: 6033
[   32.808525] sp : ceb2fd20  ip :   fp : c0ba6168
[   32.820565] r10: c0619fac  r9 : cf926840  r8 : cf0278b0
[   32.826045] r7 : cf92c008  r6 : cf115d40  r5 : 000e  r4 : 
[   32.832892] r3 : bf946440  r2 : ceb2fd34  r1 : 000e  r0 : 000e
[   32.839740] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment 
user
[   32.847406] Control: 50c5387d  Table: 8ea60019  DAC: 0015
[   32.853431] Process insmod (pid: 176, stack limit = 0xceb2e2f8)
[   32.859638] Stack: (0xceb2fd20 to 0xceb3)
[   32.864214] fd20: cf027800 bf946440 cf115d40 c0208619 0001 c00a59b1 
cf027800 c0206cc3
[   32.872796] fd40: cf027800 c0209d65 c00fefcb  c0626ef0 ceb2fd7c 
cf027810 
[   32.881379] fd60:  c00fefcb c0379721 ceb28b40 0001 c061bf74 
6013 
[   32.889961] fd80:       
 
[   32.898542] fda0:       
 
[   32.907128] fdc0:     cf072950 0044 
cf92c008 c0db8fd0
[   32.915712] fde0: bf946440 bf948001 0028 0030 03fb bf946397 
cf92c008 cf926840
[   32.924296] fe00: cf92c410 c0db8fd0     
bf946768 cf92c008
[   32.932878] fe20: c0baa0b0 c0baa0c0 bf946768 c022af2b c022af19 c022a30d 
 cf92c008
[   32.941460] fe40: bf946768 cf92c03c  bf948001 

Re: [PATCH 15/17] OMAPDSS: remove extra_info completion code

2012-09-05 Thread Archit Taneja

On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote:

Now that fifo merge has been removed, nobody uses the extra_info related
completion code, which can be removed.


I think this might come into use when we fix the usage of channel out 
field. That is, since channel out is an immediate write field, when we 
set a new manager for an overlay, we may need to wait till the overlay 
disable kicks in, only then we should change channel out.


For this, we would need some wait for extra_info, right?

Archit



Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
  drivers/video/omap2/dss/apply.c |   69 ---
  1 file changed, 69 deletions(-)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 32b5379..2579d15 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -118,7 +118,6 @@ static struct {
  static spinlock_t data_lock;
  /* lock for blocking functions */
  static DEFINE_MUTEX(apply_lock);
-static DECLARE_COMPLETION(extra_updated_completion);

  static void dss_register_vsync_isr(void);

@@ -355,69 +354,6 @@ static bool need_go(struct omap_overlay_manager *mgr)
return false;
  }

-/* returns true if an extra_info field is currently being updated */
-static bool extra_info_update_ongoing(void)
-{
-   const int num_mgrs = dss_feat_get_num_mgrs();
-   int i;
-
-   for (i = 0; i  num_mgrs; ++i) {
-   struct omap_overlay_manager *mgr;
-   struct omap_overlay *ovl;
-   struct mgr_priv_data *mp;
-
-   mgr = omap_dss_get_overlay_manager(i);
-   mp = get_mgr_priv(mgr);
-
-   if (!mp-enabled)
-   continue;
-
-   if (!mp-updating)
-   continue;
-
-   if (mp-extra_info_dirty || mp-shadow_extra_info_dirty)
-   return true;
-
-   list_for_each_entry(ovl, mgr-overlays, list) {
-   struct ovl_priv_data *op = get_ovl_priv(ovl);
-
-   if (op-extra_info_dirty || op-shadow_extra_info_dirty)
-   return true;
-   }
-   }
-
-   return false;
-}
-
-/* wait until no extra_info updates are pending */
-static void wait_pending_extra_info_updates(void)
-{
-   bool updating;
-   unsigned long flags;
-   unsigned long t;
-   int r;
-
-   spin_lock_irqsave(data_lock, flags);
-
-   updating = extra_info_update_ongoing();
-
-   if (!updating) {
-   spin_unlock_irqrestore(data_lock, flags);
-   return;
-   }
-
-   init_completion(extra_updated_completion);
-
-   spin_unlock_irqrestore(data_lock, flags);
-
-   t = msecs_to_jiffies(500);
-   r = wait_for_completion_timeout(extra_updated_completion, t);
-   if (r == 0)
-   DSSWARN(timeout in wait_pending_extra_info_updates\n);
-   else if (r  0)
-   DSSERR(wait_pending_extra_info_updates failed: %d\n, r);
-}
-
  int dss_mgr_wait_for_go(struct omap_overlay_manager *mgr)
  {
unsigned long timeout = msecs_to_jiffies(500);
@@ -823,7 +759,6 @@ static void dss_apply_irq_handler(void *data, u32 mask)
  {
const int num_mgrs = dss_feat_get_num_mgrs();
int i;
-   bool extra_updating;

spin_lock(data_lock);

@@ -854,10 +789,6 @@ static void dss_apply_irq_handler(void *data, u32 mask)
dss_write_regs();
dss_set_go_bits();

-   extra_updating = extra_info_update_ongoing();
-   if (!extra_updating)
-   complete_all(extra_updated_completion);
-
if (!need_isr())
dss_unregister_vsync_isr();




--
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 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC

2012-09-05 Thread Benoit Cousson
Hi Vaibhav,

On 09/05/2012 11:15 AM, Hiremath, Vaibhav wrote:
 On Wed, Sep 05, 2012 at 13:53:58, Ujfalusi, Peter wrote:
 Hi,

 On 09/05/2012 09:11 AM, Hiremath, Vaibhav wrote:
 Not yet, but we discussed that with Peter and since he does have these
 patches for DT, he'll be able to test your series with the McBSP changes.


 Great.

 With his series and your patch for omap-hwmod audio was probing and working 
 on
 OMAP3/4/5 without issues.

 Peter,
 Care to provide your Tested-By??
 
 Benoit,
 Can we merge this patch now?

Yes, I'll include it in the pull request along with DTS patches.

I've just tested it as well on OMAP4 by hacking the DTS for GPIO.
I'll try to update at least all the OMAP4 IPs as well with the proper
DTS resources for 3.7.

Regards,
Benoit

--
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 13/17] Revert OMAPDSS: APPLY: add fifo-merge support

2012-09-05 Thread Archit Taneja

On Wednesday 05 September 2012 01:55 PM, Tomi Valkeinen wrote:

This reverts commit 1d71f42b35ed66d90a9a39bc515bb16cfe2d4a46.

Adding fifo merge feature as an omapdss internal configuration was a
mistake. We cannot hide from the users of omapdss the complexities of
fifo merge.

This commit removes the fifo merge support, which luckily is easily done
as it was handled totally inside apply.c.

The plan is to try fifo merge again later when it is more clear how the
hardware acts in various situations, and how the omapdrm wants to use
fifo merge.


Nitpick: This isn't an exact revert right? Maybe we should mention that, 
so that if someone tries to apply the old patch, it doesn't fail.




Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
  drivers/video/omap2/dss/apply.c |  154 ++-
  1 file changed, 8 insertions(+), 146 deletions(-)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 1b49019..02943a5 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -993,11 +993,11 @@ static void dss_apply_fifo_merge(bool use_fifo_merge)
dss_data.fifo_merge_dirty = true;
  }

-static void dss_ovl_setup_fifo(struct omap_overlay *ovl,
-   bool use_fifo_merge)
+static void dss_ovl_setup_fifo(struct omap_overlay *ovl)
  {
struct ovl_priv_data *op = get_ovl_priv(ovl);
u32 fifo_low, fifo_high;
+   bool use_fifo_merge = false;


This looks like the line which wasn't removed in the original commit.

Archit

--
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 RESEND v5 3/3] arm/dts: AM33XX: Add D_CAN device tree data

2012-09-05 Thread Marc Kleine-Budde
On 09/05/2012 01:41 PM, AnilKumar Ch wrote:
 Add Bosch D_CAN controller device tree data to AM33XX dtsi
 file by adding d_can device nodes with all the necessary
 parameters.
 
 Signed-off-by: AnilKumar Ch anilku...@ti.com
 ---
  arch/arm/boot/dts/am33xx.dtsi |   18 ++
  1 file changed, 18 insertions(+)
 
 diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
 index bf5f713..ab744d6 100644
 --- a/arch/arm/boot/dts/am33xx.dtsi
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -177,5 +177,23 @@
   compatible = ti,omap3-wdt;
   ti,hwmods = wd_timer2;
   };
 +
 + dcan0: d_can@481cc000 {
 + compatible = bosch,d_can;

On imx/mxs we also add a compatible for the current hardware, this may
look like this:

compatible = ti,am33xx-can, bosch,d_can;

But I don't know if this is a generic policy or just an imx/mxs thing :)

Marc

 + ti,hwmods = d_can0;
 + reg = 0x481cc000 0x2000;
 + interrupts = 52;
 + interrupt-parent = intc;
 + status = disabled;
 + };
 +
 + dcan1: d_can@481d {
 + compatible = bosch,d_can;
 + ti,hwmods = d_can1;
 + reg = 0x481d 0x2000;
 + interrupts = 55;
 + interrupt-parent = intc;
 + status = disabled;
 + };
   };
  };
 


-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature


Re: [PATCH v2 0/4] can: c_can: Add suspend/resume and pinctrl support

2012-09-05 Thread Marc Kleine-Budde
On 09/05/2012 01:54 PM, Marc Kleine-Budde wrote:
 On 09/05/2012 01:12 PM, AnilKumar Ch wrote:
 Adds suspend/resume functionality of d_can driver along with d_can
 raminit support which is required to initialize RAM while data
 transmission.

 This patch series also adds pinctrl support to c_can driver. These
 patches were tested on AM335x-EVM.

 This patch-series is based ontop of runtimePM patch submitted
 earlier - https://patchwork.kernel.org/patch/1348081/
 
 Looks good, I'll apply the series after Tony acks the patch 3
 ([PATCH RESEND 3/4] ARM: AM33XX: board-generic: Add of_dev_auxdata to
 pass d_can raminit).

I've pushed all patches to can-next/master [1]. When Tony gives his Ack,
I'll send David a pull request (of a tree including that Ack).

Marc

[1] https://gitorious.org/linux-can/linux-can-next

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature


Re: [PATCH v3 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts

2012-09-05 Thread Matt Porter
On Wed, Sep 05, 2012 at 03:29:30PM +0200, Koen Kooi wrote:
 
 Op 28 aug. 2012, om 07:34 heeft AnilKumar, Chimata anilku...@ti.com het 
 volgende geschreven:
 
  Hi Koen,
  
  On Fri, Aug 24, 2012 at 13:32:17, Koen Kooi wrote:
  
  Op 24 aug. 2012, om 09:56 heeft Koen Kooi k...@dominion.thruhere.net het 
  volgende geschreven:
  
  
  Op 24 aug. 2012, om 09:26 heeft AnilKumar, Chimata anilku...@ti.com 
  het volgende geschreven:
  
  Hi Koen,
  
  On Fri, Aug 24, 2012 at 11:58:34, Koen Kooi wrote:
  
  Op 24 aug. 2012, om 07:50 heeft AnilKumar, Chimata anilku...@ti.com 
  het volgende geschreven:
  
  Hi Koen,
  
  On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote:
  
  Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het 
  volgende geschreven:
  
  Add tps65217 regulator device tree data to AM335x-Bone by adding
  regulator consumers with tightened constraints and regulator-name.
  TPS65217 regulator handle can be obtained by using this regulator
  name.
  
  This patch also add I2C node with I2C frequency and tps65217 PMIC
  I2C slave address.
  
  Signed-off-by: AnilKumar Ch anilku...@ti.com
  
  I tried this and the kernel immediately crashes on my beaglebone. 
  Could you upload the complete git tree and .config you used to test 
  this to somewhere public please?
  
  Use this repo to test on beaglebone
  https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl
  
  This wiki talks about how to build and use?
  https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree
  
  Note: Enable tps65217 regulator in kernel config.
  
  I used that repo and as a seperate test I rebased that to latest 
  mainline, same thing: as soon as I turn on the TPS in the .config it 
  crashes on boot. Is the pinctrl repo the *exact* repo you used to test 
  the patches on beaglebone?
  
  I tested on latest mainline after merging to
  am335x-upstream-staging-pinctrl (voltage also changing)
  
  Can you share your .config and uImage?
  
  Config: 
  https://github.com/beagleboard/kernel/blob/beaglebone-3.6/patches/configs/beaglebone
  
  My config details:- (After merge)
  1. omap2plus_defconfig
  2. Enable tps65217 MFD driver
  3. Enable tps65217 regulator driver
  
  
  I rebased onto latest mainline and refreshed the base patches from 
  Vaibhav and I now get: 
  
  [0.246796] tps65217 0-0024: TPS65217 ID 0xf version 1.1
  
  So it boots! I don't know what made it break before, but it's working now 
  :)
  
  *sigh* I'm an idiot:
  
  root@beaglebone:~# uname -a
  Linux beaglebone 3.6.0-rc3-00103-gfd02083 #86 SMP Fri Aug 24 09:45:54 CEST 
  2012 armv7l GNU/Linux
  root@beaglebone:~# zcat /proc/config.gz | grep 217
  CONFIG_MFD_TPS65217=y
  # CONFIG_REGULATOR_TPS65217 is not set
  
  Will retry with regulator driver actually turned on in a bit.
  
  Is it working after enabling the regulator?
 
 It took me a while to get back to this problem, but it still isn't working 
 for me. I did manage to get more info on the error:
 
 root@bone-mainline:~# insmod tps65217-regulator.ko
 [   32.754419] Unable to handle kernel NULL pointer dereference at virtual 
 address 00c8
 [   32.763087] pgd = cea6
 [   32.765969] [00c8] *pgd=8fbed831, *pte=, *ppte=
 [   32.772617] Internal error: Oops: 17 [#1] SMP THUMB2
 [   32.777827] Modules linked in: tps65217_regulator(+) ip_tables x_tables 
 snd_soc_omap snd_soc_core regmap_spi snd_pcm snd_timer snd soundcore 
 snd_page_alloc ipv6
 [   32.792976] CPU: 0Not tainted  (3.6.0-rc4 #109)
 [   32.798106] PC is at regmap_read+0x8/0x38
 [   32.802315] LR is at regulator_get_voltage_sel_regmap+0x15/0x38

I just got to this same point last night as I needed this working to
test omap_hsmmc with edma dmaengine...

The problem is that the tps65217-regulator driver is handing the wrong
device to regulator_register() and it contains a null regmap. This patch
passes in the the parent dev to fix it. Maybe I missed another patch
that addresses this in a different way, such as the regulator devices
being stuffed with the regmap devres?

-Matt

From 40d118bebc5eaf2a8df4f8b5e113b892a3210f96 Mon Sep 17 00:00:00 2001
From: Matt Porter mpor...@ti.com
Date: Wed, 5 Sep 2012 10:09:50 -0400
Subject: [PATCH] regulator: tps65217: fix crash during registration

The struct device for each platform device bound to this
driver is a child to the parent mfd device. The parent device
is the one that actually contains the regmap devres so fix the
null pointer dereference during the first regmap access in
registration by passing in the parent device.

Signed-off-by: Matt Porter mpor...@ti.com
---
 drivers/regulator/tps65217-regulator.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/tps65217-regulator.c 
b/drivers/regulator/tps65217-regulator.c
index 6caa222..af4916c 100644
--- a/drivers/regulator/tps65217-regulator.c
+++ b/drivers/regulator/tps65217-regulator.c
@@ -292,7 +292,7 @@ static int 

Re: [PATCH] ARM: omap_hwmod: Fix up resource names when booted with devicetree

2012-09-05 Thread Benoit Cousson
Hi Paul,

On 08/24/2012 06:20 PM, Peter Ujfalusi wrote:
 Hi Paul,
 
 On 08/24/2012 06:38 PM, Paul Walmsley wrote:
 Do we need both this one and your '[PATCH] driver core: Check if r-name 
 is valid in platform_get_resource_byname()' ?  Or would that second patch 
 be enough?  Is the crash happening in the platform_get_resource_byname() 
 iterator?
 
 The crash happens in platform_get_resource_byname(). What I see as a problem
 that when we boot without DT the r-name is configured for the hwmods. If we
 boot with DT we discard the resources created by the OF (which also have the
 r-name configured). We replace the resources from hwmods but we do not fix up
 the resource names (which is done in other cases).
 I have sent the patch for the drivers core as well since I think it is a good
 practice anyway to check for NULL pointer before strcmp().
 
 Either is good, but IMHO we should fix this in omap_hwmod (at least).

Yes, clearly we do have a corner case today due to the mix of hwmod /
DTS resource management.
- Legacy boot + hwmod resources is OK
- DTS boot with DTS resources will be OK
- DTS boot with hwmod resources is not OK since the resource name will
  not be populated in the case resources are not named :-(

If you are OK, I'll take that patch along with Vaibhav one to handle
properly the resources from DTS long with the DTS patches I'm queuing
for 3.7.

Thanks,
Benoit
--
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 4/4] arm/dts: Add tps65217 regulator DT data to am335x-bone.dts

2012-09-05 Thread Koen Kooi

Op 5 sep. 2012, om 16:24 heeft Matt Porter mpor...@ti.com het volgende 
geschreven:

 On Wed, Sep 05, 2012 at 03:29:30PM +0200, Koen Kooi wrote:
 
 Op 28 aug. 2012, om 07:34 heeft AnilKumar, Chimata anilku...@ti.com het 
 volgende geschreven:
 
 Hi Koen,
 
 On Fri, Aug 24, 2012 at 13:32:17, Koen Kooi wrote:
 
 Op 24 aug. 2012, om 09:56 heeft Koen Kooi k...@dominion.thruhere.net het 
 volgende geschreven:
 
 
 Op 24 aug. 2012, om 09:26 heeft AnilKumar, Chimata anilku...@ti.com 
 het volgende geschreven:
 
 Hi Koen,
 
 On Fri, Aug 24, 2012 at 11:58:34, Koen Kooi wrote:
 
 Op 24 aug. 2012, om 07:50 heeft AnilKumar, Chimata anilku...@ti.com 
 het volgende geschreven:
 
 Hi Koen,
 
 On Thu, Aug 23, 2012 at 19:43:48, Koen Kooi wrote:
 
 Op 21 aug. 2012, om 13:17 heeft AnilKumar Ch anilku...@ti.com het 
 volgende geschreven:
 
 Add tps65217 regulator device tree data to AM335x-Bone by adding
 regulator consumers with tightened constraints and regulator-name.
 TPS65217 regulator handle can be obtained by using this regulator
 name.
 
 This patch also add I2C node with I2C frequency and tps65217 PMIC
 I2C slave address.
 
 Signed-off-by: AnilKumar Ch anilku...@ti.com
 
 I tried this and the kernel immediately crashes on my beaglebone. 
 Could you upload the complete git tree and .config you used to test 
 this to somewhere public please?
 
 Use this repo to test on beaglebone
 https://github.com/hvaibhav/am335x-linux/commits/am335x-upstream-staging-pinctrl
 
 This wiki talks about how to build and use?
 https://github.com/hvaibhav/am335x-linux/wiki/How-To-Use-Upstream-Tree
 
 Note: Enable tps65217 regulator in kernel config.
 
 I used that repo and as a seperate test I rebased that to latest 
 mainline, same thing: as soon as I turn on the TPS in the .config it 
 crashes on boot. Is the pinctrl repo the *exact* repo you used to test 
 the patches on beaglebone?
 
 I tested on latest mainline after merging to
 am335x-upstream-staging-pinctrl (voltage also changing)
 
 Can you share your .config and uImage?
 
 Config: 
 https://github.com/beagleboard/kernel/blob/beaglebone-3.6/patches/configs/beaglebone
 
 My config details:- (After merge)
 1. omap2plus_defconfig
 2. Enable tps65217 MFD driver
 3. Enable tps65217 regulator driver
 
 
 I rebased onto latest mainline and refreshed the base patches from 
 Vaibhav and I now get: 
 
 [0.246796] tps65217 0-0024: TPS65217 ID 0xf version 1.1
 
 So it boots! I don't know what made it break before, but it's working now 
 :)
 
 *sigh* I'm an idiot:
 
 root@beaglebone:~# uname -a
 Linux beaglebone 3.6.0-rc3-00103-gfd02083 #86 SMP Fri Aug 24 09:45:54 CEST 
 2012 armv7l GNU/Linux
 root@beaglebone:~# zcat /proc/config.gz | grep 217
 CONFIG_MFD_TPS65217=y
 # CONFIG_REGULATOR_TPS65217 is not set
 
 Will retry with regulator driver actually turned on in a bit.
 
 Is it working after enabling the regulator?
 
 It took me a while to get back to this problem, but it still isn't working 
 for me. I did manage to get more info on the error:
 
 root@bone-mainline:~# insmod tps65217-regulator.ko
 [   32.754419] Unable to handle kernel NULL pointer dereference at virtual 
 address 00c8
 [   32.763087] pgd = cea6
 [   32.765969] [00c8] *pgd=8fbed831, *pte=, *ppte=
 [   32.772617] Internal error: Oops: 17 [#1] SMP THUMB2
 [   32.777827] Modules linked in: tps65217_regulator(+) ip_tables x_tables 
 snd_soc_omap snd_soc_core regmap_spi snd_pcm snd_timer snd soundcore 
 snd_page_alloc ipv6
 [   32.792976] CPU: 0Not tainted  (3.6.0-rc4 #109)
 [   32.798106] PC is at regmap_read+0x8/0x38
 [   32.802315] LR is at regulator_get_voltage_sel_regmap+0x15/0x38
 
 I just got to this same point last night as I needed this working to
 test omap_hsmmc with edma dmaengine...
 
 The problem is that the tps65217-regulator driver is handing the wrong
 device to regulator_register() and it contains a null regmap. This patch
 passes in the the parent dev to fix it. Maybe I missed another patch
 that addresses this in a different way, such as the regulator devices
 being stuffed with the regmap devres?
 
 -Matt
 
 From 40d118bebc5eaf2a8df4f8b5e113b892a3210f96 Mon Sep 17 00:00:00 2001
 From: Matt Porter mpor...@ti.com
 Date: Wed, 5 Sep 2012 10:09:50 -0400
 Subject: [PATCH] regulator: tps65217: fix crash during registration
 
 The struct device for each platform device bound to this
 driver is a child to the parent mfd device. The parent device
 is the one that actually contains the regmap devres so fix the
 null pointer dereference during the first regmap access in
 registration by passing in the parent device.
 
 Signed-off-by: Matt Porter mpor...@ti.com
 ---
 drivers/regulator/tps65217-regulator.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/regulator/tps65217-regulator.c 
 b/drivers/regulator/tps65217-regulator.c
 index 6caa222..af4916c 100644
 --- a/drivers/regulator/tps65217-regulator.c
 +++ b/drivers/regulator/tps65217-regulator.c
 @@ 

Re: linux 3.6-rc2, undefined reference to omap_musb_mailbox

2012-09-05 Thread Pantelis Antoniou
Felipe,

That seems like what this patch of mine fixes (was about to send it when
I saw this on my mailbox).

It is not enough to just do a dependency; the patch fixes it by having
a helper that's always resident, and also making sure we don't drop
events.

Regards

-- Pantelis

On Aug 24, 2012, at 10:27 AM, Felipe Balbi wrote:

 On Thu, Aug 23, 2012 at 10:38:59PM +0200, Peter Meerwald wrote:
 On Mon, 20 Aug 2012, Felipe Balbi wrote:
 
 On Mon, Aug 20, 2012 at 04:37:28PM +0530, ABRAHAM, KISHON VIJAY wrote:
 Hi,
 
 On Mon, Aug 20, 2012 at 3:56 PM, Felipe Balbi ba...@ti.com wrote:
 On Mon, Aug 20, 2012 at 03:46:07PM +0530, ABRAHAM, KISHON VIJAY wrote:
 Hi,
 
 On Mon, Aug 20, 2012 at 3:24 PM, Felipe Balbi ba...@ti.com wrote:
 On Mon, Aug 20, 2012 at 11:06:34AM +0530, ABRAHAM, KISHON VIJAY wrote:
 Hi,
 
 On Sat, Aug 18, 2012 at 9:34 PM, Peter Meerwald pme...@pmeerw.net 
 wrote:
 
 3.6-rc2 fails to compile with
 CONFIG_USB_MUSB_HDRC=m
 CONFIG_USB_MUSB_OMAP2PLUS=m
 
  LD  init/built-in.o
 drivers/built-in.o: In function `twl4030_usb_irq':
 /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:518: 
 undefined reference to `omap_musb_mailbox'
 drivers/built-in.o: In function `twl4030_usb_phy_init':
 /home/pmeerw/linux-3.6-rc2/drivers/usb/otg/twl4030-usb.c:540: 
 undefined reference to `omap_musb_mailbox'
 
 Having TWL4030_USB as a module will get rid of this.
 I'll see how this can be resolved when some modules are *built-in* and
 some are made as *modules*.
 
 EXPORT_SYMBOL_GPL() should sort that out, right ?
 
 No :-( I already have EXPORT_SYMBOL_GPL() in omap2430.c.
 
 I see you're missing an extern on the function prototype (on the
 header). Not sure how modules.dep is generated, but maybe it needs the
 extern there. Can you check it out ?
 
 That isn't helping either.
 
 oh, ok... twl4030-usb is built-in... now that makes sense. Since
 twl4030-usb uses a symbol from omap2430, then it should depend on it,
 otherwise this will always happen.
 
 so add USB_MUSB_OMAP2PLUS to the depends of TWL4030_USB in 
 drivers/usb/otg/Kconfig?
 
 correct ;-)
 
 -- 
 balbi

commit e191e7226099d90ba077719313d4964cf42834ca
Author: Pantelis Antoniou pa...@antoniou-consulting.com
Date:   Fri Aug 10 13:07:43 2012 +

musb: Introduce mailbox helper

When MUSB_OMAP2 is compiled as a module while the musb mailbox callers are
not build fails. Introduce a helper to get around the problem.

diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index f5ed3d7..6a868bc 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_USB_ATM) += atm/
 obj-$(CONFIG_USB_SPEEDTOUCH)   += atm/
 
 obj-$(CONFIG_USB_MUSB_HDRC)+= musb/
+obj-$(CONFIG_USB_MUSB_OMAP2PLUS_MBOX_HELPER)   += musb/
 obj-$(CONFIG_USB_CHIPIDEA) += chipidea/
 obj-$(CONFIG_USB_RENESAS_USBHS)+= renesas_usbhs/
 obj-$(CONFIG_USB_GADGET)   += gadget/
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 6259f0d..9201c3e 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -50,6 +50,7 @@ config USB_MUSB_TUSB6010
 config USB_MUSB_OMAP2PLUS
tristate OMAP2430 and onwards
depends on ARCH_OMAP2PLUS
+   select USB_MUSB_OMAP2PLUS_MBOX_HELPER
 
 config USB_MUSB_AM35X
tristate AM35x
@@ -69,6 +70,9 @@ config USB_MUSB_UX500
 
 endchoice
 
+config USB_MUSB_OMAP2PLUS_MBOX_HELPER
+   bool
+
 choice
prompt 'MUSB DMA mode'
default USB_UX500_DMA if USB_MUSB_UX500
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index 3b85871..9126fa2 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -12,6 +12,7 @@ musb_hdrc-$(CONFIG_DEBUG_FS)  += 
musb_debugfs.o
 
 # Hardware Glue Layer
 obj-$(CONFIG_USB_MUSB_OMAP2PLUS)   += omap2430.o
+obj-$(CONFIG_USB_MUSB_OMAP2PLUS_MBOX_HELPER)   += omap2430_mboxhelper.o
 obj-$(CONFIG_USB_MUSB_AM35X)   += am35x.o
 obj-$(CONFIG_USB_MUSB_DSPS)+= musb_dsps.o
 obj-$(CONFIG_USB_MUSB_TUSB6010)+= tusb6010.o
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index d8c6aeb..920db04 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -228,7 +228,7 @@ static inline void omap2430_low_level_init(struct musb 
*musb)
musb_writel(musb-mregs, OTG_FORCESTDBY, l);
 }
 
-void omap_musb_mailbox(enum omap_musb_vbus_id_status status)
+static void omap_musb_mailbox_actual(enum omap_musb_vbus_id_status status)
 {
struct omap2430_glue*glue = _glue;
struct musb *musb = glue_to_musb(glue);
@@ -241,7 +241,6 @@ void omap_musb_mailbox(enum omap_musb_vbus_id_status status)
 
schedule_work(glue-omap_musb_mailbox_work);
 }
-EXPORT_SYMBOL_GPL(omap_musb_mailbox);
 
 static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 {
@@ -441,6 +440,7 @@ static int omap2430_probe(struct platform_device *pdev)
struct 

RE: [PATCH v2 1/8] ARM/dts: OMAP2: Add McBSP entries for OMAP2420 and OMAP2430 SoC

2012-09-05 Thread Hiremath, Vaibhav
On Wed, Sep 05, 2012 at 19:01:55, Cousson, Benoit wrote:
 Hi Vaibhav,
 
 On 09/05/2012 11:15 AM, Hiremath, Vaibhav wrote:
  On Wed, Sep 05, 2012 at 13:53:58, Ujfalusi, Peter wrote:
  Hi,
 
  On 09/05/2012 09:11 AM, Hiremath, Vaibhav wrote:
  Not yet, but we discussed that with Peter and since he does have these
  patches for DT, he'll be able to test your series with the McBSP changes.
 
 
  Great.
 
  With his series and your patch for omap-hwmod audio was probing and 
  working on
  OMAP3/4/5 without issues.
 
  Peter,
  Care to provide your Tested-By??
  
  Benoit,
  Can we merge this patch now?
 
 Yes, I'll include it in the pull request along with DTS patches.
 
 I've just tested it as well on OMAP4 by hacking the DTS for GPIO.
 I'll try to update at least all the OMAP4 IPs as well with the proper
 DTS resources for 3.7.
 

Thanks Benoit,

There are other patches which are pending,

arm/dts: AM33XX: Convert all hex numbers to lower-case
https://patchwork.kernel.org/patch/1377351/
arm/dts: AM33XX: Specify reg and interrupt property for all nodes
https://patchwork.kernel.org/patch/1377361/


Probably your Ack is required for,

ARM: AM33XX: clock: Add dcan clock aliases for device-tree
https://patchwork.kernel.org/patch/1377061/



RTC:
I am not sure how to deal with RTC DT support, as I understand the list is very 
unresponsive there.
http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg23253.html



Thanks,
Vaibhav

--
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 0/2] gpio-twl4030: add new device tree properties

2012-09-05 Thread Benoit Cousson
Hi Florian,

On 09/05/2012 09:46 AM, Florian Vaussard wrote:
 Hello,
 
 A number of platform data are missing when using twl4030/gpio from a
 device tree. This patchset adds the missing properties, updates the 
 documentation with the new bindings, and updates existing device trees.
 It mainly enables LEDA and LEDB outputs, as well as pullups /
 pulldowns on GPIOs.
 
 The 1st patch changes the device driver and updates the documentation.
 The 2nd patch updates the device trees for BeagleBoard and omap3-evm.
 
 Changes since v1: 
 - Patches on driver and documentation merged into the same patch
 - Put device trees' values in hexadecimal
 - Handle bool property using of_property_read_bool()
 - Prefix the patches with the correct convention

Thanks for the update.

 Tested on Gumstix Overo. V1 was tested on omap3-evm by Vaibhav Hiremath.

I've just tested it on beagle xM. I can play with D12 led using:

echo 255  /sys/class/leds/beagleboard\:\:pmu_stat/brightness

Tested-by: Benoit Cousson b-cous...@ti.com


 BTW: who will merge this?

Since Linus already acked it, Tony can merge it.


Tony,

I can add that series in my DTS series for 3.7 if you want.

Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: omap_hwmod: Fix up resource names when booted with devicetree

2012-09-05 Thread Benoit Cousson
Peter,

I will just slighty change the subject since it is a omap_device.c patch and 
not an omap_hwmod.c one.

ARM: OMAP: omap_device: Fix up resource names when booted with devicetree

Regards,
Benoit

On 09/05/2012 04:27 PM, Benoit Cousson wrote:
 Hi Paul,
 
 On 08/24/2012 06:20 PM, Peter Ujfalusi wrote:
 Hi Paul,

 On 08/24/2012 06:38 PM, Paul Walmsley wrote:
 Do we need both this one and your '[PATCH] driver core: Check if r-name 
 is valid in platform_get_resource_byname()' ?  Or would that second patch 
 be enough?  Is the crash happening in the platform_get_resource_byname() 
 iterator?

 The crash happens in platform_get_resource_byname(). What I see as a problem
 that when we boot without DT the r-name is configured for the hwmods. If we
 boot with DT we discard the resources created by the OF (which also have the
 r-name configured). We replace the resources from hwmods but we do not fix 
 up
 the resource names (which is done in other cases).
 I have sent the patch for the drivers core as well since I think it is a good
 practice anyway to check for NULL pointer before strcmp().

 Either is good, but IMHO we should fix this in omap_hwmod (at least).
 
 Yes, clearly we do have a corner case today due to the mix of hwmod /
 DTS resource management.
 - Legacy boot + hwmod resources is OK
 - DTS boot with DTS resources will be OK
 - DTS boot with hwmod resources is not OK since the resource name will
   not be populated in the case resources are not named :-(
 
 If you are OK, I'll take that patch along with Vaibhav one to handle
 properly the resources from DTS long with the DTS patches I'm queuing
 for 3.7.
 
 Thanks,
 Benoit
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: omap_hwmod: Fix up resource names when booted with devicetree

2012-09-05 Thread Benoit Cousson
Peter,

I will just slighty change the subject since it is an omap_device.c patch and 
not an omap_hwmod.c one.

ARM: OMAP: omap_device: Fix up resource names when booted with devicetree

Regards,
Benoit

On 09/05/2012 04:27 PM, Benoit Cousson wrote:
 Hi Paul,
 
 On 08/24/2012 06:20 PM, Peter Ujfalusi wrote:
 Hi Paul,

 On 08/24/2012 06:38 PM, Paul Walmsley wrote:
 Do we need both this one and your '[PATCH] driver core: Check if r-name 
 is valid in platform_get_resource_byname()' ?  Or would that second patch 
 be enough?  Is the crash happening in the platform_get_resource_byname() 
 iterator?

 The crash happens in platform_get_resource_byname(). What I see as a problem
 that when we boot without DT the r-name is configured for the hwmods. If we
 boot with DT we discard the resources created by the OF (which also have the
 r-name configured). We replace the resources from hwmods but we do not fix 
 up
 the resource names (which is done in other cases).
 I have sent the patch for the drivers core as well since I think it is a good
 practice anyway to check for NULL pointer before strcmp().

 Either is good, but IMHO we should fix this in omap_hwmod (at least).
 
 Yes, clearly we do have a corner case today due to the mix of hwmod /
 DTS resource management.
 - Legacy boot + hwmod resources is OK
 - DTS boot with DTS resources will be OK
 - DTS boot with hwmod resources is not OK since the resource name will
   not be populated in the case resources are not named :-(
 
 If you are OK, I'll take that patch along with Vaibhav one to handle
 properly the resources from DTS long with the DTS patches I'm queuing
 for 3.7.
 
 Thanks,
 Benoit
 

--
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


OMAP baseline test results for v3.6-rc4

2012-09-05 Thread Paul Walmsley

Here are some basic boot and power management test results for v3.6-rc4:

http://www.pwsan.com/omap/testlogs/test_v3.6-rc4/20120904122415/

Some observations:

* N800: panics during kernel init
  - This is caused by an MMC driver bug; fixed by [PATCH] MMC: OMAP MSDI: 
fix broken PIO mode, available from here:
http://www.spinics.net/lists/arm-kernel/msg190879.html

* CM-T3517: L3 in-band error with USB OTG during boot
  - Cause unknown; longstanding issue; does not occur on the 3517EVM

* 37xx EVM: CORE not entering dynamic off-idle
  - Cause unknown; dynamic retention-idle seems to work; system suspend to 
off works

* 4430ES2 Panda: CORE, L4PER, L3INIT, TESLA, IVAHD not going idle
  - Cause unknown; may be partially due to McPDM reset problem

(The objective in posting these is to determine what is and isn't working 
in the mainline releases, as well as to make it easier to determine what 
is fixed or is broken by subsequent series that use this as a base.)


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] musb: Kill __init from function that are called at other times as well.

2012-09-05 Thread Pantelis Antoniou
Marking functions as __init or __devinit and calling them at other times
leads to predictable crashes (if you're lucky).

Remove them for now.

Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
 drivers/usb/musb/musb_core.c| 16 
 drivers/usb/musb/musb_debugfs.c |  2 +-
 drivers/usb/musb/musb_dma.h |  2 +-
 drivers/usb/musb/musb_gadget.c  |  6 +++---
 drivers/usb/musb/musbhsdma.c|  2 +-
 drivers/usb/musb/omap2430.c |  2 +-
 6 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 26f1bef..215d2d5 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1160,7 +1160,7 @@ static struct musb_fifo_cfg __devinitdata mode_5_cfg[] = {
  *
  * returns negative errno or offset for next fifo.
  */
-static int __devinit
+static int
 fifo_setup(struct musb *musb, struct musb_hw_ep  *hw_ep,
const struct musb_fifo_cfg *cfg, u16 offset)
 {
@@ -1235,7 +1235,7 @@ static struct musb_fifo_cfg __devinitdata ep0_cfg = {
.style = FIFO_RXTX, .maxpacket = 64,
 };
 
-static int __devinit ep_config_from_table(struct musb *musb)
+static int ep_config_from_table(struct musb *musb)
 {
const struct musb_fifo_cfg  *cfg;
unsignedi, n;
@@ -1326,7 +1326,7 @@ done:
  * ep_config_from_hw - when MUSB_C_DYNFIFO_DEF is false
  * @param musb the controller
  */
-static int __devinit ep_config_from_hw(struct musb *musb)
+static int ep_config_from_hw(struct musb *musb)
 {
u8 epnum = 0;
struct musb_hw_ep *hw_ep;
@@ -1373,7 +1373,7 @@ enum { MUSB_CONTROLLER_MHDRC, MUSB_CONTROLLER_HDRC, };
 /* Initialize MUSB (M)HDRC part of the USB hardware subsystem;
  * configure endpoints, or take their config from silicon
  */
-static int __devinit musb_core_init(u16 musb_type, struct musb *musb)
+static int musb_core_init(u16 musb_type, struct musb *musb)
 {
u8 reg;
char *type;
@@ -1797,7 +1797,7 @@ static void musb_irq_work(struct work_struct *data)
  * Init support
  */
 
-static struct musb *__devinit
+static struct musb *
 allocate_instance(struct device *dev,
struct musb_hdrc_config *config, void __iomem *mbase)
 {
@@ -1873,7 +1873,7 @@ static void musb_free(struct musb *musb)
  * @mregs: virtual address of controller registers,
  * not yet corrected for platform-specific offsets
  */
-static int __devinit
+static int
 musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
 {
int status;
@@ -2101,7 +2101,7 @@ fail0:
 static u64 *orig_dma_mask;
 #endif
 
-static int __devinit musb_probe(struct platform_device *pdev)
+static int musb_probe(struct platform_device *pdev)
 {
struct device   *dev = pdev-dev;
int irq = platform_get_irq_byname(pdev, mc);
@@ -2397,7 +2397,7 @@ static struct platform_driver musb_driver = {
 
 /*-*/
 
-static int __init musb_init(void)
+static int /* __init */ musb_init(void)
 {
if (usb_disabled())
return 0;
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..8f8597d 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -235,7 +235,7 @@ static const struct file_operations musb_test_mode_fops = {
.release= single_release,
 };
 
-int __devinit musb_init_debugfs(struct musb *musb)
+int musb_init_debugfs(struct musb *musb)
 {
struct dentry   *root;
struct dentry   *file;
diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 3a97c4e..69254c8 100644
--- a/drivers/usb/musb/musb_dma.h
+++ b/drivers/usb/musb/musb_dma.h
@@ -178,7 +178,7 @@ struct dma_controller {
 extern void musb_dma_completion(struct musb *musb, u8 epnum, u8 transmit);
 
 
-extern struct dma_controller *__init
+extern struct dma_controller * /* __init */
 dma_controller_create(struct musb *, void __iomem *);
 
 extern void dma_controller_destroy(struct dma_controller *);
diff --git a/drivers/usb/musb/musb_gadget.c b/drivers/usb/musb/musb_gadget.c
index f7194cf..f3d9f4e 100644
--- a/drivers/usb/musb/musb_gadget.c
+++ b/drivers/usb/musb/musb_gadget.c
@@ -1795,7 +1795,7 @@ static void musb_gadget_release(struct device *dev)
 }
 
 
-static void __devinit
+static void
 init_peripheral_ep(struct musb *musb, struct musb_ep *ep, u8 epnum, int is_in)
 {
struct musb_hw_ep   *hw_ep = musb-endpoints + epnum;
@@ -1832,7 +1832,7 @@ init_peripheral_ep(struct musb *musb, struct musb_ep *ep, 
u8 epnum, int is_in)
  * Initialize the endpoints exposed to peripheral drivers, with backlinks
  * to the rest of the driver state.
  */
-static inline void __devinit musb_g_init_endpoints(struct musb *musb)
+static inline void musb_g_init_endpoints(struct musb *musb)
 {
u8  epnum;

[GIT PULL] ARM: OMAP2+: PRCM/hwmod: some fixes for 3.6-rc

2012-09-05 Thread Paul Walmsley
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tony,

The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d:

  Linux 3.6-rc4 (2012-09-01 10:39:58 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
tags/omap-fixes-a-for-3.6rc

for you to fetch changes up to 8a94febc21743fe121bdaf1d1470d98b1135acc2:

  Merge branches 'clkdev_fixes_3.6rc', 'clkdm_fixes_3.6rc' and 
'hwmod_data_fixes_a_3.6rc' into omap_fixes_a_3.6rc (2012-09-03 11:52:02 -0600)

- 

Some hwmod, clockdomain, am335x fixes against v3.6-rc4.

Test logs can be found here:

   http://www.pwsan.com/omap/testlogs/omap_fixes_a_3.6rc/20120904110254/

- 
Misael Lopez Cruz (1):
  ARM: OMAP: hwmod code: Disable module when hwmod enable fails

Paul Walmsley (2):
  ARM: OMAP3xxx: clockdomain: fix software supervised wakeup/sleep
  Merge branches 'clkdev_fixes_3.6rc', 'clkdm_fixes_3.6rc' and 
'hwmod_data_fixes_a_3.6rc' into omap_fixes_a_3.6rc

Tero Kristo (2):
  ARM: OMAP3: hwmod data: fix iva2 reset info
  ARM: OMAP4: hwmod data: temporarily comment out data for the sl2if IP 
block

Vaibhav Hiremath (1):
  ARM: OMAP2+: am33xx: Fix the timer fck clock naming convention

 arch/arm/mach-omap2/clock33xx_data.c   |   14 
 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c |   50 ++--
 arch/arm/mach-omap2/cm-regbits-34xx.h  |1 +
 arch/arm/mach-omap2/omap_hwmod.c   |1 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   15 +++--
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   12 +++
 6 files changed, 75 insertions(+), 18 deletions(-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQR3ooAAoJEMePsQ0LvSpLQ94P/1DzifcEU/R0YFLZF+20XPd5
hOrUk2EWn7SlPAxZJMG1K+In7EZ3K4r7IYaROIbwUWJTO/hQdx6zwyAOec/qnutV
WYRnQ+KN+x7gd8EYZPnS1voiqeH0SnP/wI2ri9UcMTV+tpAtO6ibD10iAUmBxSfX
x9HaYb65cYA+ulMsQXX2g1oejV2+4eR+fWWI0+bGfOxIHPGQcEhSGSvNkDs9W/bE
QfBKmTWeizx2jlRlXBG8pxV8MtEIDtwRZitcgTnyStw8LMqR/YnCOLIRoU2OHVcP
UtQwIxtNqGaoqm3i6IXGM1BLI4ZT/EN0kr+1LZVl1WoFqL1tDrn39dSvSVfxfGje
CjhkTk9XVzbV4GV+1yTt6JlfD3AimLwYqihKDs21a2OleAsQAu8a+gftsJtSp8Xu
fscJcjr1c5JKyjE5CzbH7mbDgX+LTveZV3b6pT1m599UidP/NZ4yzUYrmkTmoSkk
JdqQlTgahLxjBoBBDfNhavuCzA4cYNh6q0Pt6GhmWc1ZC7aR3+7xU4wUNXAvbKoe
mUksJmjROwk4MlswLqpIkgt8iiEGa2LzHcyL7eVD2+oCun0FFlolqa1R3gTF9x8y
Hr8iNv4b0OeX55oSZ53ijIDY4WwgmBVvnVjiWEiAkBuwqsghRLii5eemX572szGU
lTSzo95e8x7kAaO6moNI
=wc/t
-END PGP SIGNATURE-
--
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] Don't clobber access methods when !regmap

2012-09-05 Thread Lars-Peter Clausen
On 09/06/2012 03:45 PM, Pantelis Antoniou wrote:
 A snd-soc driver that doesn't support regmap blow up horribly
 when you assume that regmap is available. Fix it by marking
 the driver as not supporting regmap  not clobbering the codec
 access methods.
 
 This is immediately noticeable on the beagleboard where we crash,
 since we might have REGMAP enabled, but it doesn't mean that the
 omap driver uses it.
 
 Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com

But calling snd_soc_codec_set_cache_io sort of implies that you are using
regmap. If you are not using regmap your codec should not call
snd_soc_codec_set_cache_io.

- Lars

 
 ---
  sound/soc/soc-io.c | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)
 
 diff --git a/sound/soc/soc-io.c b/sound/soc/soc-io.c
 index 29183ef..4e5b4ae 100644
 --- a/sound/soc/soc-io.c
 +++ b/sound/soc/soc-io.c
 @@ -117,9 +117,6 @@ int snd_soc_codec_set_cache_io(struct snd_soc_codec 
 *codec,
   int ret;
  
   memset(config, 0, sizeof(config));
 - codec-write = hw_write;
 - codec-read = hw_read;
 - codec-bulk_write_raw = snd_soc_hw_bulk_write_raw;
  
   config.reg_bits = addr_bits;
   config.val_bits = data_bits;
 @@ -151,7 +148,9 @@ int snd_soc_codec_set_cache_io(struct snd_soc_codec 
 *codec,
* multiples */
   if (ret  0)
   codec-val_bytes = ret;
 - }
 + } else
 + codec-using_regmap = false;
 +
   break;
  
   default:
 @@ -161,6 +160,13 @@ int snd_soc_codec_set_cache_io(struct snd_soc_codec 
 *codec,
   if (IS_ERR(codec-control_data))
   return PTR_ERR(codec-control_data);
  
 + /* only when using regmap; don't modify unconditionally */
 + if (codec-using_regmap) {
 + codec-write = hw_write;
 + codec-read = hw_read;
 + codec-bulk_write_raw = snd_soc_hw_bulk_write_raw;
 + }
 +
   return 0;
  }
  EXPORT_SYMBOL_GPL(snd_soc_codec_set_cache_io);

--
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] Don't clobber access methods when !regmap

2012-09-05 Thread Pantelis Antoniou
Hi Lars,

On Sep 5, 2012, at 7:36 PM, Lars-Peter Clausen wrote:

 On 09/06/2012 03:45 PM, Pantelis Antoniou wrote:
 A snd-soc driver that doesn't support regmap blow up horribly
 when you assume that regmap is available. Fix it by marking
 the driver as not supporting regmap  not clobbering the codec
 access methods.
 
 This is immediately noticeable on the beagleboard where we crash,
 since we might have REGMAP enabled, but it doesn't mean that the
 omap driver uses it.
 
 Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
 
 But calling snd_soc_codec_set_cache_io sort of implies that you are using
 regmap. If you are not using regmap your codec should not call
 snd_soc_codec_set_cache_io.
 
 - Lars
 

The driver in question (twl4030.c) does not call snd_soc_codec_set_cache_io().
However the snd-soc core does call it in sound/soc/soc-core.c in 
soc_probe_codec.

I do see that there's a commit 98d3088e534a2a61f6690b5426909b0c3b57a785 that is
fixing it in a different manner.

 diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
 index f219b2f..f81c597 100644
 --- a/sound/soc/soc-core.c
 +++ b/sound/soc/soc-core.c
 @@ -1096,7 +1096,7 @@ static int soc_probe_codec(struct snd_soc_card *card,
 }
  
 /* If the driver didn't set I/O up try regmap */
 -   if (!codec-control_data)
 +   if (!codec-write  dev_get_regmap(codec-dev, NULL))
 snd_soc_codec_set_cache_io(codec, 0, 0, SND_SOC_REGMAP);
  
 if (driver-controls)
 
 

Originally it was call unconditionally, but now it should work. Let me check 
this
and I'll report back.

Regards

-- Pantelis


 
 ---
 sound/soc/soc-io.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)
 
 diff --git a/sound/soc/soc-io.c b/sound/soc/soc-io.c
 index 29183ef..4e5b4ae 100644
 --- a/sound/soc/soc-io.c
 +++ b/sound/soc/soc-io.c
 @@ -117,9 +117,6 @@ int snd_soc_codec_set_cache_io(struct snd_soc_codec 
 *codec,
  int ret;
 
  memset(config, 0, sizeof(config));
 -codec-write = hw_write;
 -codec-read = hw_read;
 -codec-bulk_write_raw = snd_soc_hw_bulk_write_raw;
 
  config.reg_bits = addr_bits;
  config.val_bits = data_bits;
 @@ -151,7 +148,9 @@ int snd_soc_codec_set_cache_io(struct snd_soc_codec 
 *codec,
   * multiples */
  if (ret  0)
  codec-val_bytes = ret;
 -}
 +} else
 +codec-using_regmap = false;
 +
  break;
 
  default:
 @@ -161,6 +160,13 @@ int snd_soc_codec_set_cache_io(struct snd_soc_codec 
 *codec,
  if (IS_ERR(codec-control_data))
  return PTR_ERR(codec-control_data);
 
 +/* only when using regmap; don't modify unconditionally */
 +if (codec-using_regmap) {
 +codec-write = hw_write;
 +codec-read = hw_read;
 +codec-bulk_write_raw = snd_soc_hw_bulk_write_raw;
 +}
 +
  return 0;
 }
 EXPORT_SYMBOL_GPL(snd_soc_codec_set_cache_io);
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: OMAP4: Fix array size for irq_target_cpu

2012-09-05 Thread Tony Lindgren
* Shilimkar, Santosh santosh.shilim...@ti.com [120905 06:17]:
 On Wed, Sep 5, 2012 at 5:11 PM, Benoit Cousson b-cous...@ti.com wrote:
 
  Hi Tony,
 
  On 09/05/2012 02:03 AM, Tony Lindgren wrote:
   If NR_IRQS is less than MAX_IRQS, we end up writing past the
   irq_target_cpu array in omap_wakeupgen_init():
  
   /* Associate all the IRQs to boot CPU like GIC init does. */
   for (i = 0; i  max_irqs; i++)
 irq_target_cpu[i] = boot_cpu;
  
   This can happen if SPARSE_IRQ is enabled as by default NR_IRQS is
   set to 16. Without this patch we're overwriting other data during
   the boot.
 
  In fact I already sent a patch to fix that when I started my SPARSE_IRQ
  cleanup, but it looks like it was never merged :-(
  I guess I forgot a little bit that series.
 
 Indeed. I remember acking few patches in that series.
 Infact this patch set was the basis on which I was talking to Arnd
 that SPARSE_IRQ
 should work on OMAP. Didn't think that it has not made it yet in mainline.

Bummer. That means duplicate wasted effort was done :(

Looks like the original patch no longer applies because of commit
247c445c0 (ARM: OMAP5: Add the WakeupGen IP updates). So I'll just
update the comments to mention Benoit's original patch.

I guess the lesson here is that everybody must follow up on their own
patches to make sure they get merged. Especially on fixes.

Benoit, can you please check if some parts of your earlier series are
still needed in the testing-cleanup branch?

BTW, there was also Felipe's TWL removal patch that was done in a slightly
different way [PATCH] arm: omap: drop unused IRQ defines:

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/103274.html# 

Regards,

Tony
--
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] ARM: OMAP2+: PRCM/hwmod: some fixes for 3.6-rc

2012-09-05 Thread Tony Lindgren
* Paul Walmsley p...@pwsan.com [120905 09:16]:
 Hi Tony,
 
 The following changes since commit 4cbe5a555fa58a79b6ecbb6c531b8bab0650778d:
 
   Linux 3.6-rc4 (2012-09-01 10:39:58 -0700)
 
 are available in the git repository at:
 
   git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git 
 tags/omap-fixes-a-for-3.6rc
 
 for you to fetch changes up to 8a94febc21743fe121bdaf1d1470d98b1135acc2:
 
   Merge branches 'clkdev_fixes_3.6rc', 'clkdm_fixes_3.6rc' and 
 'hwmod_data_fixes_a_3.6rc' into omap_fixes_a_3.6rc (2012-09-03 11:52:02 -0600)
 
 
 
 Some hwmod, clockdomain, am335x fixes against v3.6-rc4.
 
 Test logs can be found here:
 
http://www.pwsan.com/omap/testlogs/omap_fixes_a_3.6rc/20120904110254/
 

Thanks pulled into fixes.

Tony
--
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: [PATCHv2 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver

2012-09-05 Thread Vaibhav Hiremath


On 9/5/2012 5:06 PM, Sourav Poddar wrote:
 smsc ece1099 is a keyboard scan or gpio expansion device.
 The patch create keypad and gpio expander child for this
 multi function smsc driver.
 
 Cc: Samuel Ortiz sa...@linux.intel.com
 Cc: Benoit Cousson b-cous...@ti.com
 Cc: Felipe Balbi ba...@ti.com
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Signed-off-by: Sourav Poddar sourav.pod...@ti.com
 ---
 Changes since v1:
  - Use Kconfig option correctly
  - Add regmap_config paramters
  - Modify formatting of logs for devid
  - Move read/write function to headed file as an inline
function.
  Documentation/smsc_ece1099.txt |   56 
  drivers/mfd/Kconfig|   12 
  drivers/mfd/Makefile   |1 +
  drivers/mfd/smsc-ece1099.c |  110 +++
  include/linux/mfd/smsc.h   |  111 
 
  5 files changed, 290 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/smsc_ece1099.txt
  create mode 100644 drivers/mfd/smsc-ece1099.c
  create mode 100644 include/linux/mfd/smsc.h
 
 diff --git a/Documentation/smsc_ece1099.txt b/Documentation/smsc_ece1099.txt
 new file mode 100644
 index 000..6b492e8
 --- /dev/null
 +++ b/Documentation/smsc_ece1099.txt
 @@ -0,0 +1,56 @@
 +What is smsc-ece1099?
 +--
 +
 +The ECE1099 is a 40-Pin 3.3V Keyboard Scan Expansion
 +or GPIO Expansion device. The device supports a keyboard
 +scan matrix of 23x8. The device is connected to a Master
 +via the SMSC BC-Link interface or via the SMBus.
 +Keypad scan Input(KSI) and Keypad Scan Output(KSO) signals
 +are multiplexed with GPIOs.
 +
 +Interrupt generation
 +
 +
 +Interrupts can be generated by an edge detection on a GPIO
 +pin or an edge detection on one of the bus interface pins.
 +Interrupts can also be detected on the keyboard scan interface.
 +The bus interrupt pin (BC_INT# or SMBUS_INT#) is asserted if
 +any bit in one of the Interrupt Status registers is 1 and
 +the corresponding Interrupt Mask bit is also 1.
 +
 +In order for software to determine which device is the source
 +of an interrupt, it should first read the Group Interrupt Status Register
 +to determine which Status register group is a source for the interrupt.
 +Software should read both the Status register and the associated Mask 
 register,
 +then AND the two values together. Bits that are 1 in the result of the AND
 +are active interrupts. Software clears an interrupt by writing a 1 to the
 +corresponding bit in the Status register.
 +
 +Communication Protocol
 +--
 +
 +- SMbus slave Interface
 + The host processor communicates with the ECE1099 device
 + through a series of read/write registers via the SMBus
 + interface. SMBus is a serial communication protocol between
 + a computer host and its peripheral devices. The SMBus data
 + rate is 10KHz minimum to 400 KHz maximum
 +
 +- Slave Bus Interface
 + The ECE1099 device SMBus implementation is a subset of the
 + SMBus interface to the host. The device is a slave-only SMBus device.
 + The implementation in the device is a subset of SMBus since it
 + only supports four protocols.
 +
 + The Write Byte, Read Byte, Send Byte, and Receive Byte protocols are the
 + only valid SMBus protocols for the device.
 +
 +- BC-LinkTM Interface
 + The BC-Link is a proprietary bus that allows communication
 + between a Master device and a Companion device. The Master
 + device uses this serial bus to read and write registers
 + located on the Companion device. The bus comprises three signals,
 + BC_CLK, BC_DAT and BC_INT#. The Master device always provides the
 + clock, BC_CLK, and the Companion device is the source for an
 + independent asynchronous interrupt signal, BC_INT#. The ECE1099
 + supports BC-Link speeds up to 24MHz.
 diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
 index d1facef..991ef15 100644
 --- a/drivers/mfd/Kconfig
 +++ b/drivers/mfd/Kconfig
 @@ -385,6 +385,18 @@ config MFD_T7L66XB
   help
 Support for Toshiba Mobile IO Controller T7L66XB
  
 +config MFD_SMSC
 +   bool Support for the SMSC ECE1099 series chips
 +   depends on I2C=y
 +   select MFD_CORE
 +   select REGMAP_I2C
 +   help
 +If you say yes here you get support for the
 +ece1099 chips from SMSC.
 +
 +To compile this driver as a module, choose M here: the
 +module will be called smsc.
 +
  config MFD_TC6387XB
   bool Support Toshiba TC6387XB
   depends on ARM  HAVE_CLK
 diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
 index 79dd22d..f587d91 100644
 --- a/drivers/mfd/Makefile
 +++ b/drivers/mfd/Makefile
 @@ -77,6 +77,7 @@ obj-$(CONFIG_EZX_PCAP)  += ezx-pcap.o
  obj-$(CONFIG_MCP)+= mcp-core.o
  obj-$(CONFIG_MCP_SA11X0) += mcp-sa11x0.o
  obj-$(CONFIG_MCP_UCB1200)+= ucb1x00-core.o
 

Re: [PATCH 0/2] pinctrl: pinctrl-single: new type: pinctrl-single,bits

2012-09-05 Thread Tony Lindgren
* Linus Walleij linus.wall...@linaro.org [120905 05:11]:
 On Wed, Sep 5, 2012 at 11:01 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 
  When configuring pinmux with pinctrl-single there could be a case when one
  register is used to configure mux for more than one pin.
  In this case the use of pinctrl-single,pins is a bit problematic since we 
  can
  only update the whole register (restricted by the mask).
  In such a situations the pinctrl-single,bits could provide a safe way to 
  handle
  the mux.
 
  pinctrl-single,bits takes three parameters: reg offset, value, sub-mask
  The sub mask is used to mask part of the register to make sure we do not 
  change
  bits outside of the scope of this pin.
 
  The first patch in this series is to fix the previous pinctrl-since,pins
  implementation because it was not using the mask on the value which could 
  result
  changed bits outside of the mask.
 
 This looks sane to me, but I'd like Tony to ACK before I apply it.

Cool, this should allow handling cases where some pinctrl devices can have
extra aux registers for signal strength etc for some of the pins.

Will take a look.

Tony
--
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: [PATCHv2 2/4] Input: keypad: Add smsc ece1099 keypad driver

2012-09-05 Thread Vaibhav Hiremath


On 9/5/2012 5:06 PM, Sourav Poddar wrote:
 From: G, Manjunath Kondaiah manj...@ti.com
 
 SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
 supports a keypad scan matrix of 23*8.This driver uses this
 device as a keypad driver.
 
 Cc: Dmitry Torokhov dmitry.torok...@gmail.com
 Cc: Benoit Cousson b-cous...@ti.com
 Cc: Felipe Balbi ba...@ti.com
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
 Signed-off-by: Sourav Poddar sourav.pod...@ti.com
 Acked-by: Felipe Balbi ba...@ti.com
 ---
 Changes since v1:
  - Prevent the use of kfree since devm_kzalloc was used.
  - Use devexit around remove api
  drivers/input/keyboard/Kconfig   |   11 +
  drivers/input/keyboard/Makefile  |1 +
  drivers/input/keyboard/smsc-ece1099-keypad.c |  306 
 ++
  3 files changed, 318 insertions(+), 0 deletions(-)
  create mode 100644 drivers/input/keyboard/smsc-ece1099-keypad.c
 
 diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
 index c50fa75..2a2d374 100644
 --- a/drivers/input/keyboard/Kconfig
 +++ b/drivers/input/keyboard/Kconfig
 @@ -593,6 +593,17 @@ config KEYBOARD_TWL4030
 To compile this driver as a module, choose M here: the
 module will be called twl4030_keypad.
  
 +config KEYBOARD_SMSC
 +   tristate SMSC ECE1099 keypad support
 +   depends on I2C=y

Any specific reason behind =y

 +   help
 + Say Y here if your board use the smsc keypad controller
 + for omap5 defconfig. It's safe to say enable this
 + even on boards that don't use the keypad controller.
 +
 + To compile this driver as a module, choose M here: the
 + module will be called smsc-ece1099-keypad.
 +
  config KEYBOARD_XTKBD
   tristate XT keyboard
   select SERIO
 diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
 index 44e7600..0f2aa26 100644
 --- a/drivers/input/keyboard/Makefile
 +++ b/drivers/input/keyboard/Makefile
 @@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X)  += 
 tc3589x-keypad.o
  obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
  obj-$(CONFIG_KEYBOARD_TNETV107X) += tnetv107x-keypad.o
  obj-$(CONFIG_KEYBOARD_TWL4030)   += twl4030_keypad.o
 +obj-$(CONFIG_KEYBOARD_SMSC)+= smsc-ece1099-keypad.o
  obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
  obj-$(CONFIG_KEYBOARD_W90P910)   += w90p910_keypad.o
 diff --git a/drivers/input/keyboard/smsc-ece1099-keypad.c 
 b/drivers/input/keyboard/smsc-ece1099-keypad.c
 new file mode 100644
 index 000..71cd7d6
 --- /dev/null
 +++ b/drivers/input/keyboard/smsc-ece1099-keypad.c
 @@ -0,0 +1,306 @@
 +/*
 + * SMSC_ECE1099 Keypad driver
 + *
 + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include linux/i2c.h
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/init.h
 +#include linux/interrupt.h
 +#include linux/input.h
 +#include linux/gpio.h
 +#include linux/slab.h
 +#include linux/jiffies.h
 +#include linux/input/matrix_keypad.h
 +#include linux/delay.h
 +#include linux/mfd/core.h
 +#include linux/mfd/smsc.h
 +#include linux/of_gpio.h
 +#include linux/of.h
 +
 +#define KEYPRESS_TIME  200
 +
 +struct smsc_keypad {
 + struct smsc *smsc;
 + struct matrix_keymap_data *keymap_data;
 + unsigned int last_key_state[16];
 + unsigned int last_col;
 + unsigned int last_key_ms[16];
 + unsigned short *keymap;
 + struct i2c_client *client;
 + struct input_dev *input;
 + int rows, cols;
 + int row_shift;
 + bool no_autorepeat;
 + unsignedirq;
 + struct device *dev;
 +};
 +
 +static void smsc_kp_scan(struct smsc_keypad *kp)
 +{
 + struct input_dev *input = kp-input;
 + int i, j;
 + int row, col;
 + int temp, code;
 + unsigned int new_state[16];
 + unsigned int bits_changed;
 + int this_ms;
 +
 + smsc_write(kp-dev, SMSC_KP_INT_MASK, 0x00);
 + smsc_write(kp-dev, SMSC_KP_INT_STAT, 0xFF);
 +
 + /* Scan for row and column */
 + for (i = 0; i  kp-cols; i++) {
 + smsc_write(kp-dev, SMSC_KP_OUT, SMSC_KSO_EVAL + i);
 + /* Read Row Status */
 + smsc_read(kp-dev, SMSC_KP_IN, temp);
 + if (temp == 0xFF)
 + continue;
 +
 + col = i;
 + for (j = 0; j  kp-rows; j++) {
 + if ((temp  0x01) != 0x00) {
 + temp = temp  1;
 + continue;
 + }
 +
 + row = j;
 + new_state[col] =  (1  row);
 + bits_changed = kp-last_key_state[col] ^ new_state[col];
 + 

Re: [PATCHv2 4/4] gpio: smscece: Add support for gpio IO expander feature

2012-09-05 Thread Vaibhav Hiremath


On 9/5/2012 5:07 PM, Sourav Poddar wrote:
 smsc can be used as an gpio io expander device also. So adding
 support for configuring smsc pins as a gpio.
 
 Cc: Benoit Cousson b-cous...@ti.com
 Cc: Felipe Balbi ba...@ti.com
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 Signed-off-by: Sourav Poddar sourav.pod...@ti.com
 ---
 Changes since v1: 
  - Use edge triggering instead of level
  - Use devm_reuest_threaded_irq
  - In remove part, use irq_free_desc and
  irq_remove_domain api.
  drivers/gpio/Kconfig|7 +
  drivers/gpio/Makefile   |1 +
  drivers/gpio/gpio-smscece.c |  380 
 +++
  3 files changed, 388 insertions(+), 0 deletions(-)
  create mode 100644 drivers/gpio/gpio-smscece.c
 
 diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
 index b16c8a7..e883929 100644
 --- a/drivers/gpio/Kconfig
 +++ b/drivers/gpio/Kconfig
 @@ -444,6 +444,13 @@ config GPIO_ADP5588_IRQ
 Say yes here to enable the adp5588 to be used as an interrupt
 controller. It requires the driver to be built in the kernel.
  
 +config GPIO_SMSCECE
 + tristate SMSCECE 1099 I2C GPIO expander
 + depends on I2C
 + help
 +   This option enables support for 18 GPIOs found
 +   on SMSC ECE 1099 GPIO Expanders.
 +
  comment PCI GPIO expanders:
  
  config GPIO_CS5535
 diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
 index 153cace..7c803c5 100644
 --- a/drivers/gpio/Makefile
 +++ b/drivers/gpio/Makefile
 @@ -12,6 +12,7 @@ obj-$(CONFIG_GPIO_74X164)   += gpio-74x164.o
  obj-$(CONFIG_GPIO_AB8500)+= gpio-ab8500.o
  obj-$(CONFIG_GPIO_ADP5520)   += gpio-adp5520.o
  obj-$(CONFIG_GPIO_ADP5588)   += gpio-adp5588.o
 +obj-$(CONFIG_GPIO_SMSCECE)  += gpio-smscece.o
  obj-$(CONFIG_GPIO_AMD8111)   += gpio-amd8111.o
  obj-$(CONFIG_GPIO_ARIZONA)   += gpio-arizona.o
  obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
 diff --git a/drivers/gpio/gpio-smscece.c b/drivers/gpio/gpio-smscece.c
 new file mode 100644
 index 000..68a17fa
 --- /dev/null
 +++ b/drivers/gpio/gpio-smscece.c
 @@ -0,0 +1,380 @@
 +/*
 + * GPIO Chip driver for smsc
 + * SMSC I/O Expander and QWERTY Keypad Controller
 + *
 + * Copyright 2012 Texas Instruments Inc.
 + *
 + * Licensed under the GPL-2 or later.

Can you put proper license here?

 + */
 +
 +#include linux/module.h
 +#include linux/kernel.h
 +#include linux/slab.h
 +#include linux/init.h
 +#include linux/i2c.h
 +#include linux/gpio.h
 +#include linux/interrupt.h
 +#include linux/irqdomain.h
 +#include linux/irq.h
 +#include linux/mfd/smsc.h
 +#include linux/err.h
 +
 +struct smsc_gpio {
 + struct device *dev;
 + struct smsc *smsc;
 + struct gpio_chip gpio_chip;
 + struct mutex lock;  /* protect cached dir, dat_out */
 + /* protect serialized access to the interrupt controller bus */
 + struct mutex irq_lock;
 + struct irq_domain   *irq_domain;
 + unsigned gpio_start;
 + int type;
 + int flags;
 + int irq;
 + int irq_base;
 + unsigned int gpio_base;
 + unsigned int dat_out[5];
 + unsigned int dir[5];
 + unsigned int irq_trig_fall[5];
 + unsigned int irq_trig_raise[5];
 + unsigned int int_en[5];
 + unsigned int irq_mask[5];
 + unsigned int irq_stat[5];
 +};
 +
 +static int smsc_gpio_get_value(struct gpio_chip *chip, unsigned off)
 +{
 + struct smsc_gpio *sg =
 + container_of(chip, struct smsc_gpio, gpio_chip);
 + unsigned int get;
 + return !!(smsc_read(sg-dev,
 + (SMSC_GPIO_DATA_IN_START + SMSC_BANK(off))  SMSC_BIT(off),
 + get));
 +}
 +
 +static void smsc_gpio_set_value(struct gpio_chip *chip,
 + unsigned off, int val)
 +{
 + unsigned bank, bit;
 + struct smsc_gpio *sg =
 + container_of(chip, struct smsc_gpio, gpio_chip);
 +
 + bank = SMSC_BANK(off);
 + bit = SMSC_BIT(off);
 +
 + mutex_lock(sg-lock);
 + if (val)
 + sg-dat_out[bank] |= bit;
 + else
 + sg-dat_out[bank] = ~bit;
 +
 + smsc_write(sg-dev, SMSC_GPIO_DATA_OUT_START + bank,
 +sg-dat_out[bank]);
 + mutex_unlock(sg-lock);
 +}
 +
 +static int smsc_gpio_direction_input(struct gpio_chip *chip, unsigned off)
 +{
 + unsigned int reg;
 + struct smsc_gpio *sg =
 + container_of(chip, struct smsc_gpio, gpio_chip);
 + int reg_dir;
 +
 + mutex_lock(sg-lock);
 + reg_dir = SMSC_CFG_START + off;
 + smsc_read(sg-dev, reg_dir, reg);
 + reg |= SMSC_GPIO_INPUT_LOW;
 + mutex_unlock(sg-lock);
 +
 + return smsc_write(sg-dev, reg_dir, reg);
 +}
 +
 +static int smsc_gpio_direction_output(struct gpio_chip *chip,
 +  unsigned off, int val)
 +{
 + unsigned int reg;
 + struct smsc_gpio *sg =
 + container_of(chip, struct smsc_gpio, gpio_chip);
 + int reg_dir;
 +
 + mutex_lock(sg-lock);
 + reg_dir = 

[PATCH 02/10] ARM: OMAP: Fix timer posted mode support

2012-09-05 Thread Jon Hunter
Currently the dmtimer posted mode is being enabled when the function
__omap_dm_timer_reset() is called. This function is only being called for
OMAP1 timers and OMAP2+ timers that are being used as system timers. Hence,
for OMAP2+ timers that are NOT being used as a system timer, posted mode is
not enabled but the timer-posted variable is still set (incorrectly) in
the omap_dm_timer_prepare() function.

This is a regression introduced by commit 3392cdd3 (ARM: OMAP: dmtimer:
switch-over to platform device driver) which changed the code to only call
omap_dm_timer_reset() for OMAP1 devices. Although this is a regression from
the original code it only impacts performance and so is not needed for stable.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/timer.c   |3 +--
 arch/arm/plat-omap/dmtimer.c  |   14 +-
 arch/arm/plat-omap/include/plat/dmtimer.h |9 -
 3 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 5471706..e24ee0f 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -194,10 +194,9 @@ static int __init omap_dm_timer_init_one(struct 
omap_dm_timer *timer,
}
__omap_dm_timer_init_regs(timer);
__omap_dm_timer_reset(timer, 1, 1);
-   timer-posted = 1;
+   __omap_dm_timer_enable_posted(timer);
 
timer-rate = clk_get_rate(timer-fclk);
-
timer-reserved = 1;
 
return res;
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index c34f55b..22790ea 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -122,21 +122,15 @@ static void omap_dm_timer_wait_for_reset(struct 
omap_dm_timer *timer)
 
 static void omap_dm_timer_reset(struct omap_dm_timer *timer)
 {
-   omap_dm_timer_enable(timer);
if (timer-pdev-id != 1) {
omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
omap_dm_timer_wait_for_reset(timer);
}
-
__omap_dm_timer_reset(timer, 0, 0);
-   omap_dm_timer_disable(timer);
-   timer-posted = 1;
 }
 
 int omap_dm_timer_prepare(struct omap_dm_timer *timer)
 {
-   int ret;
-
/*
 * FIXME: OMAP1 devices do not use the clock framework for dmtimers so
 * do not call clk_get() for these devices.
@@ -150,13 +144,15 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
}
}
 
+   omap_dm_timer_enable(timer);
+
if (timer-capability  OMAP_TIMER_NEEDS_RESET)
omap_dm_timer_reset(timer);
 
-   ret = omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
+   __omap_dm_timer_enable_posted(timer);
+   omap_dm_timer_disable(timer);
 
-   timer-posted = 1;
-   return ret;
+   return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
 }
 
 static inline u32 omap_dm_timer_reserved_systimer(int id)
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h 
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 5ce2f00..fa9d04b 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -348,13 +348,20 @@ static inline void __omap_dm_timer_reset(struct 
omap_dm_timer *timer,
l |= 1  2;
 
__raw_writel(l, timer-io_base + OMAP_TIMER_OCP_CFG_OFFSET);
+}
+
+static inline void __omap_dm_timer_enable_posted(struct omap_dm_timer *timer)
+{
+   if (timer-posted)
+   return;
 
if (timer-errata  OMAP_TIMER_ERRATA_I103_I767)
return;
 
-   /* Match hardware reset default of posted mode */
__omap_dm_timer_write(timer, OMAP_TIMER_IF_CTRL_REG,
OMAP_TIMER_CTRL_POSTED, 0);
+   timer-context.tsicr = OMAP_TIMER_CTRL_POSTED;
+   timer-posted = 1;
 }
 
 /**
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 00/10] ARM: OMAP: DMTIMER fixes and clean-up

2012-09-05 Thread Jon Hunter
This series includes several fixes for the OMAP DMTIMER driver and a few
clean-ups to simplify some of the code. This series is based upon 3.6-rc4.

Tested on OMAP5912 OSK, OMAP2420 H4, OMAP3430 Beagle and OMAP4430 Panda.
Testing includes ...
1. Booting kernel on above boards
2. Set date and ensuring time of day is correct after 24 hours
3. Checking the timer counter is incrementing when configuring and starting
   a timer
4. Checking the timer overflow interrupt when timer expires.
5. Using different clock sources to operate the timer with.
6. Running a loop test overnight that continually runs test #3 and #4 for
   each available timer

Jon Hunter (10):
  ARM: OMAP3+: Implement timer workaround for errata i103 and i767
  ARM: OMAP: Fix timer posted mode support
  ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations
  ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs
  ARM: OMAP2+: Don't use __omap_dm_timer_reset()
  ARM: OMAP: Fix dmtimer reset for timer1
  ARM: OMAP: Clean-up dmtimer reset code
  ARM: OMAP: Clean-up timer posted mode support
  ARM: OMAP: Add dmtimer interrupt disable function
  ARM: OMAP: Remove unnecessary call to clk_get()

 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |   15 ++-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   41 
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |4 +
 arch/arm/mach-omap2/timer.c|   27 +++--
 arch/arm/plat-omap/dmtimer.c   |  109 +---
 arch/arm/plat-omap/include/plat/dmtimer.h  |   95 ++---
 6 files changed, 184 insertions(+), 107 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 01/10] ARM: OMAP3+: Implement timer workaround for errata i103 and i767

2012-09-05 Thread Jon Hunter
Errata Titles:
i103: Delay needed to read some GP timer, WD timer and sync timer registers
  after wakeup (OMAP3/4)
i767: Delay needed to read some GP timer registers after wakeup (OMAP5)

Description (i103/i767):
If a General Purpose Timer (GPTimer) is in posted mode (TSICR [2].POSTED=1),
due to internal resynchronizations, values read in TCRR, TCAR1 and TCAR2
registers right after the timer interface clock (L4) goes from stopped to
active may not return the expected values. The most common event leading to
this situation occurs upon wake up from idle.

GPTimer non-posted synchronization mode is not impacted by this limitation.

Workarounds:
1). Disable posted mode
2). Use static dependency between timer clock domain and MPUSS clock domain
3). Use no-idle mode when the timer is active

Workarounds #2 and #3 are not pratical from a power standpoint and so
workaround #1 has been implemented. Disabling posted mode adds some CPU overhead
for configuring the timers as the CPU has to wait for the write to complete.
However, disabling posted mode guarantees correct operation.

Please note that it is safe to use posted mode for timers if the counter (TCRR)
and capture (TCARx) registers will never be read. An example of this is the
clock-event system timer. This is used by the kernel to schedule events however,
the timers counter is never read and capture registers are not used. Given that
the kernel configures this timer often yet never reads the counter register it
is safe to enable posted mode in this case. Hence, for the timer used for kernel
clock-events, posted mode is enabled by overriding the errata for devices that
are impacted by this defect.

Although both dmtimers and watchdogs are impacted by this defect this patch only
implements the workaround for the dmtimer. Currently the watchdog driver does
not read the counter register and so no workaround is necessary.

Confirmed with Vaibhav Hiremath that this bug also impacts AM33xx devices.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/timer.c   |9 +++
 arch/arm/plat-omap/dmtimer.c  |2 ++
 arch/arm/plat-omap/include/plat/dmtimer.h |   39 +
 3 files changed, 50 insertions(+)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2ff6d41..5471706 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -208,6 +208,13 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
 {
int res;
 
+   /*
+* For clock-event timers we never read the timer counter and
+* so we are not impacted by errata i103 and i767. Therefore,
+* we can safely ignore this errata for clock-event timers.
+*/
+   __omap_dm_timer_populate_errata(clkev, OMAP_TIMER_ERRATA_I103_I767);
+
res = omap_dm_timer_init_one(clkev, gptimer_id, fck_source);
BUG_ON(res);
 
@@ -305,6 +312,8 @@ static void __init omap2_gptimer_clocksource_init(int 
gptimer_id,
 {
int res;
 
+   __omap_dm_timer_populate_errata(clksrc, 0);
+
res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source);
BUG_ON(res);
 
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 938b50a..c34f55b 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -730,6 +730,8 @@ static int __devinit omap_dm_timer_probe(struct 
platform_device *pdev)
timer-pdev = pdev;
timer-capability = pdata-timer_capability;
 
+   __omap_dm_timer_populate_errata(timer, 0);
+
/* Skip pm_runtime_enable for OMAP1 */
if (!(timer-capability  OMAP_TIMER_NEEDS_RESET)) {
pm_runtime_enable(dev);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h 
b/arch/arm/plat-omap/include/plat/dmtimer.h
index 19e7fa5..5ce2f00 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -36,6 +36,7 @@
 #include linux/delay.h
 #include linux/io.h
 #include linux/platform_device.h
+#include plat/cpu.h
 
 #ifndef __ASM_ARCH_DMTIMER_H
 #define __ASM_ARCH_DMTIMER_H
@@ -61,6 +62,16 @@
 #define OMAP_TIMER_HAS_PWM 0x2000
 #define OMAP_TIMER_NEEDS_RESET 0x1000
 
+/*
+ * timer errata flags
+ *
+ * Errata i103/i767 impacts all OMAP3/4/5 devices including AM33xx. This
+ * errata prevents us from using posted mode on these devices, unless the
+ * timer counter register is never read. For more details please refer to
+ * the OMAP3/4/5 errata documents.
+ */
+#define OMAP_TIMER_ERRATA_I103_I7670x8000
+
 struct omap_timer_capability_dev_attr {
u32 timer_capability;
 };
@@ -265,6 +276,7 @@ struct omap_dm_timer {
int ctx_loss_count;
int revision;
u32 capability;
+   u32 errata;
struct platform_device *pdev;
struct list_head node;
 };
@@ -337,11 +349,38 @@ static inline void 

[PATCH 03/10] ARM: OMAP3: Correct HWMOD DMTIMER SYSC register declarations

2012-09-05 Thread Jon Hunter
Currently, the OMAP3 HWMOD data defines two TIOCP_CFG register structures
(referred to as the SYSC register in the HWMOD data) where timers 1, 2 and 10
use one of the defintions and the other timers use the other definition. For
OMAP3 devices the structure of the DMTIMER TIOCP_CFG register is the same for
all 12 instances of the DMTIMER. Please note that this is a difference between
OMAP3 and OMAP4 and could be the source of the confusion.

For OMAP3 devices, the DMTIMER TIOCP_CFG register has the fields,
clock-activity, emufree, idlemode, enwakeup, softreset and autoidle for all
12 timers. Therefore, remove one of the SYSC register definitions for the
DMTIMERs and ensure the appropriate register fields are defined for all
DMTIMERs.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   27 ++-
 1 file changed, 6 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index c9e3820..659f7c4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -115,28 +115,13 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
 };
 
 /* timer class */
-static struct omap_hwmod_class_sysconfig omap3xxx_timer_1ms_sysc = {
-   .rev_offs   = 0x,
-   .sysc_offs  = 0x0010,
-   .syss_offs  = 0x0014,
-   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
-   SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
-   SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
-   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
-   .sysc_fields= omap_hwmod_sysc_type1,
-};
-
-static struct omap_hwmod_class omap3xxx_timer_1ms_hwmod_class = {
-   .name = timer,
-   .sysc = omap3xxx_timer_1ms_sysc,
-};
-
 static struct omap_hwmod_class_sysconfig omap3xxx_timer_sysc = {
.rev_offs   = 0x,
.sysc_offs  = 0x0010,
.syss_offs  = 0x0014,
-   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_ENAWAKEUP |
-  SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+  SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
.idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
 };
@@ -176,7 +161,7 @@ static struct omap_hwmod omap3xxx_timer1_hwmod = {
},
},
.dev_attr   = capability_alwon_dev_attr,
-   .class  = omap3xxx_timer_1ms_hwmod_class,
+   .class  = omap3xxx_timer_hwmod_class,
 };
 
 /* timer2 */
@@ -193,7 +178,7 @@ static struct omap_hwmod omap3xxx_timer2_hwmod = {
.idlest_idle_bit = OMAP3430_ST_GPT2_SHIFT,
},
},
-   .class  = omap3xxx_timer_1ms_hwmod_class,
+   .class  = omap3xxx_timer_hwmod_class,
 };
 
 /* timer3 */
@@ -332,7 +317,7 @@ static struct omap_hwmod omap3xxx_timer10_hwmod = {
},
},
.dev_attr   = capability_pwm_dev_attr,
-   .class  = omap3xxx_timer_1ms_hwmod_class,
+   .class  = omap3xxx_timer_hwmod_class,
 };
 
 /* timer11 */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 04/10] ARM: OMAP2/3: Define HWMOD software reset status for DMTIMERs

2012-09-05 Thread Jon Hunter
For OMAP2/3 devices, the HWMOD data does not define a software reset status
field for the DMTIMERs. Therefore, when HWMOD performs a soft-reset of the
DMTIMER we don't check and wait for the reset to complete. For OMAP2/3 devices,
the software reset status for a DMTIMER can be read from bit 0 of the DMTIMER
TISTAT register (referred to as the SYSS register in HWMOD). Add the
appropriate HWMOD definitions so that HWMOD will check the software reset
status when performing a software reset of the DMTIMER.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index afad69c..d094285 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -60,7 +60,7 @@ static struct omap_hwmod_class_sysconfig omap2xxx_timer_sysc 
= {
.syss_offs  = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
   SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
-  SYSC_HAS_AUTOIDLE),
+  SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
.idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
 };
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 659f7c4..5f0b2ee 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -121,7 +121,8 @@ static struct omap_hwmod_class_sysconfig 
omap3xxx_timer_sysc = {
.syss_offs  = 0x0014,
.sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
   SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
-  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+  SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE |
+  SYSS_HAS_RESET_STATUS),
.idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= omap_hwmod_sysc_type1,
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 07/10] ARM: OMAP: Clean-up dmtimer reset code

2012-09-05 Thread Jon Hunter
Only OMAP1 devices use the omap_dm_timer_reset() and so require the
omap_dm_timer_wait_for_reset() and __omap_dm_timer_reset() functions.
Therefore combine these into a single function called omap_dm_timer_reset()
and simplify the code.

Please note that for OMAP1 devices, the TIOCP_CFG register does not have the
clock-activity field and so when we reset the timer for an OMAP1 device we
only need to configure the idle-mode field in the TIOCP_CFG register.

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/plat-omap/dmtimer.c  |   40 +
 arch/arm/plat-omap/include/plat/dmtimer.h |   19 --
 2 files changed, 24 insertions(+), 35 deletions(-)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 623c1f3..1eb7353 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -43,6 +43,7 @@
 
 #include plat/dmtimer.h
 #include plat/omap-pm.h
+#include plat/omap_hwmod.h
 
 #include mach/hardware.h
 
@@ -103,32 +104,34 @@ static void omap_timer_restore_context(struct 
omap_dm_timer *timer)
timer-context.tclr);
 }
 
-static void omap_dm_timer_wait_for_reset(struct omap_dm_timer *timer)
+static int omap_dm_timer_reset(struct omap_dm_timer *timer)
 {
-   int c;
+   u32 l, timeout = 0;
 
if (!timer-sys_stat)
-   return;
+   return -EINVAL;
+
+   omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
 
-   c = 0;
while (!(__raw_readl(timer-sys_stat)  1)) {
-   c++;
-   if (c  10) {
-   printk(KERN_ERR Timer failed to reset\n);
-   return;
+   if (timeout++  10) {
+   dev_err(timer-pdev-dev, Timer failed to reset\n);
+   return -ETIMEDOUT;
}
}
-}
 
-static void omap_dm_timer_reset(struct omap_dm_timer *timer)
-{
-   omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
-   omap_dm_timer_wait_for_reset(timer);
-   __omap_dm_timer_reset(timer, 0, 0);
+   /* Configure timer for smart-idle mode */
+   l = __raw_readl(timer-io_base + OMAP_TIMER_OCP_CFG_OFFSET);
+   l |= __ffs(HWMOD_IDLEMODE_SMART)  SYSC_TYPE1_SIDLEMODE_SHIFT;
+   __raw_writel(l, timer-io_base + OMAP_TIMER_OCP_CFG_OFFSET);
+
+   return 0;
 }
 
 int omap_dm_timer_prepare(struct omap_dm_timer *timer)
 {
+   int rc;
+
/*
 * FIXME: OMAP1 devices do not use the clock framework for dmtimers so
 * do not call clk_get() for these devices.
@@ -144,8 +147,13 @@ int omap_dm_timer_prepare(struct omap_dm_timer *timer)
 
omap_dm_timer_enable(timer);
 
-   if (timer-capability  OMAP_TIMER_NEEDS_RESET)
-   omap_dm_timer_reset(timer);
+   if (timer-capability  OMAP_TIMER_NEEDS_RESET) {
+   rc = omap_dm_timer_reset(timer);
+   if (rc) {
+   omap_dm_timer_disable(timer);
+   return rc;
+   }
+   }
 
__omap_dm_timer_enable_posted(timer);
omap_dm_timer_disable(timer);
diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h 
b/arch/arm/plat-omap/include/plat/dmtimer.h
index fa9d04b..6488a19 100644
--- a/arch/arm/plat-omap/include/plat/dmtimer.h
+++ b/arch/arm/plat-omap/include/plat/dmtimer.h
@@ -331,25 +331,6 @@ static inline void __omap_dm_timer_init_regs(struct 
omap_dm_timer *timer)
}
 }
 
-/* Assumes the source clock has been set by caller */
-static inline void __omap_dm_timer_reset(struct omap_dm_timer *timer,
-   int autoidle, int wakeup)
-{
-   u32 l;
-
-   l = __raw_readl(timer-io_base + OMAP_TIMER_OCP_CFG_OFFSET);
-   l |= 0x02  3;  /* Set to smart-idle mode */
-   l |= 0x2  8;   /* Set clock activity to perserve f-clock on idle */
-
-   if (autoidle)
-   l |= 0x1  0;
-
-   if (wakeup)
-   l |= 1  2;
-
-   __raw_writel(l, timer-io_base + OMAP_TIMER_OCP_CFG_OFFSET);
-}
-
 static inline void __omap_dm_timer_enable_posted(struct omap_dm_timer *timer)
 {
if (timer-posted)
-- 
1.7.9.5

--
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


  1   2   >