RE: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl

[Hiremath, Vaibhav]

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Tuesday, September 27, 2011 11:36 PM
 To: Hiremath, Vaibhav
 Cc: Ravi, Deepthy; linux-me...@vger.kernel.org; t...@atomide.com;
 li...@arm.linux.org.uk; linux-omap@vger.kernel.org; linux-arm-
 ker...@lists.infradead.org; linux-ker...@vger.kernel.org;
 mche...@infradead.org; g.liakhovet...@gmx.de
 Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
 
 Hi Vaibhav,
 
 On Monday 19 September 2011 17:31:02 Hiremath, Vaibhav wrote:
  On Friday, September 16, 2011 6:36 PM Laurent Pinchart wrote:
   On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote:
On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote:
 On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
 From: Vaibhav Hiremath hvaib...@ti.com

 In order to support TVP5146 (for that matter any video decoder),
 it is important to support G/S/ENUM_STD ioctl on /dev/videoX
 device node.

 Why so ? Shouldn't it be queried on the subdev output pad
 directly ?
   
Because standard v4l2 application for analog devices will call these
std ioctls on the streaming device node. So it's done on /dev/video
 to
make the existing apllication work.
  
   Existing applications can't work with the OMAP3 ISP (and similar
 complex
   embedded devices) without userspace support anyway, either in the form
 of
   a GStreamer element or a libv4l plugin. I still believe that analog
 video
   standard operations should be added to the subdev pad operations and
   exposed through subdev device nodes, exactly as done with formats.
 
  I completely agree with your point that, existing application will not
 work
  without setting links properly. But I believe the assumption here is,
  media-controller should set the links (along with pad formants) and all
  existing application should work as is. Isn't it?
 
 The media controller is an API used (among other things) to set the links.
 You
 still need to call it from userspace. That won't happen magically. The
 userspace component that sets up the links and configures the formats, be
 it a
 GStreamer element, a libv4l plugin, or something else, can as well setup
 the
 standard on the TVP5146 subdev.
 
Please look at from analog device point of view which is interfaced to ISP.

OMAP3 ISP = TVP5146 (video decoder)

As a user I would want to expect the standard to be supported on streaming 
device node, since all standard streaming applications (for analog 
devices/interfaces) does this.

Setting up the links and format is still something got added with MC framework, 
and I would consider it as a separate plug-in along with existing applications.

Why do I need to write/use two different streaming application one for MC 
compatible device and another for non-MC?

  The way it is being done currently is, set the format at the pad level
  which is same as analog standard resolution and use existing application
  for streaming...
 
 At then end of the OMAP3 ISP pipeline video data has long lost its analog
 roots. I don't think standards make sense there.
 
I don't agree with you here, I think we made it clear when we started with MC 
development activity, we will not break existing standard applications. 
Media-controller will play a roll to setup the links, connecting the pads and 
stuff.


Thanks,
Vaibhav

  I am ok, if we add s/g/enum_std api support at sub-dev level but this
  should also be supported on streaming device node.
 
 --
 Regards,
 
 Laurent Pinchart
--
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: [PATCHv5 1/4] regulator: omap smps regulator driver

[Tero Kristo]

On Tue, 2011-09-27 at 22:06 +0200, Hilman, Kevin wrote:
 Tero Kristo t-kri...@ti.com writes:
 
  OMAP SMPS regulator driver provides access to OMAP voltage processor
  controlled regulators. These include VDD_MPU and VDD_CORE for OMAP3 and
  additionally VDD_IVA for OMAP4. SMPS regulators use the OMAP voltage
  layer for the actual voltage regulation operations.
 
  Signed-off-by: Tero Kristo t-kri...@ti.com
  Cc: Kevin Hilman khil...@ti.com
  Cc: Tony Lindgren t...@atomide.com
  Cc: Todd Poynor toddpoy...@google.com
  Cc: Mark Brown broo...@opensource.wolfsonmicro.com
  Cc: Liam Girdwood l...@ti.com
  Cc: Graeme Gregory g...@slimlogic.co.uk
 
 I believe this was already ack'd by Mark.  Have there been any
 significan changes since then?

Just the consumer supply naming was changed for this.

-Tero


Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6. 
Kotipaikka: Helsinki
 

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

Re: [PATCH v2 2/6] OMAP4: Clock: round_rate and recalc functions for DPLL_ABE

[Paul Walmsley]

Hi Jon and Mike,

On Fri, 16 Sep 2011, Jon Hunter wrote:

 From: Mike Turquette mturque...@ti.com
 
 OMAP4 DPLL_ABE can enable a 4X multipler on top of the normal MN multipler
 and divider. This is achieved by setting CM_CLKMODE_DPLL_ABE.DPLL_REGM4XEN
 bit in CKGEN module of CM1. From the OMAP4 TRM:
 
 Fdpll = Fref x 2 x (4 x M/(N+1)) in case REGM4XEN bit field is set (only
 applicable to DPLL_ABE).
 
 Add new round_rate() and recalc() functions for OMAP4, that check the
 setting of REGM4XEN bit and handle this appropriately. The new functions
 are a simple wrapper on top of the existing omap2_dpll_round_rate() and
 omap2_dpll_get_rate() functions to handle the REGM4XEN bit.
 
 The REGM4XEN bit is only implemented for the ABE DPLL on OMAP4 and so
 only dpll_abe_ck uses omap4_dpll_regm4xen_round_rate() and
 omap4_dpll_regm4xen_recalc() functions.
 
 Signed-off-by: Mike Turquette mturque...@ti.com
 Tested-by: Jon Hunter jon-hun...@ti.com

Some changes have been made to this patch here, to fix a few minor bugs in 
error paths and to add documentation and Jon's Signed-off-by: (since he's 
in the submittal chain).

Care to review and send any comments?  Otherwise, I plan to queue this 
revised version for 3.2.

Thanks for the great changelogs on this, and the other patches in this 
series.

regards


- Paul

From: Mike Turquette mturque...@ti.com
Date: Wed, 28 Sep 2011 00:00:31 -0600
Subject: [PATCH] ARM: OMAP4: clock: round_rate and recalc functions for
 DPLL_ABE

OMAP4 DPLL_ABE can enable a 4X multipler on top of the normal MN multipler
and divider. This is achieved by setting CM_CLKMODE_DPLL_ABE.DPLL_REGM4XEN
bit in CKGEN module of CM1. From the OMAP4 TRM:

Fdpll = Fref x 2 x (4 x M/(N+1)) in case REGM4XEN bit field is set (only
applicable to DPLL_ABE).

Add new round_rate() and recalc() functions for OMAP4, that check the
setting of REGM4XEN bit and handle this appropriately. The new functions
are a simple wrapper on top of the existing omap2_dpll_round_rate() and
omap2_dpll_get_rate() functions to handle the REGM4XEN bit.

The REGM4XEN bit is only implemented for the ABE DPLL on OMAP4 and so
only dpll_abe_ck uses omap4_dpll_regm4xen_round_rate() and
omap4_dpll_regm4xen_recalc() functions.

Signed-off-by: Mike Turquette mturque...@ti.com
Tested-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
[p...@pwsan.com: fixed attempt to return a negative from a fn returning
 unsigned; pass along errors from omap2_dpll_round_rate();
 added documentation; added Jon's S-o-b]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
 arch/arm/mach-omap2/clock.h  |2 +
 arch/arm/mach-omap2/clock44xx.h  |7 +++
 arch/arm/mach-omap2/clock44xx_data.c |4 +-
 arch/arm/mach-omap2/dpll44xx.c   |   69 ++
 4 files changed, 80 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 48ac568..2311bc2 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -66,6 +66,8 @@ void omap3_noncore_dpll_disable(struct clk *clk);
 int omap4_dpllmx_gatectrl_read(struct clk *clk);
 void omap4_dpllmx_allow_gatectrl(struct clk *clk);
 void omap4_dpllmx_deny_gatectrl(struct clk *clk);
+long omap4_dpll_regm4xen_round_rate(struct clk *clk, unsigned long 
target_rate);
+unsigned long omap4_dpll_regm4xen_recalc(struct clk *clk);
 
 #ifdef CONFIG_OMAP_RESET_CLOCKS
 void omap2_clk_disable_unused(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock44xx.h b/arch/arm/mach-omap2/clock44xx.h
index 7ceb870..287a46f 100644
--- a/arch/arm/mach-omap2/clock44xx.h
+++ b/arch/arm/mach-omap2/clock44xx.h
@@ -8,6 +8,13 @@
 #ifndef __ARCH_ARM_MACH_OMAP2_CLOCK44XX_H
 #define __ARCH_ARM_MACH_OMAP2_CLOCK44XX_H
 
+/*
+ * OMAP4430_REGM4XEN_MULT: If the CM_CLKMODE_DPLL_ABE.DPLL_REGM4XEN bit is
+ *set, then the DPLL's lock frequency is multiplied by 4 (OMAP4430 TRM
+ *vV Section 3.6.3.3.1 DPLLs Output Clocks Parameters)
+ */
+#define OMAP4430_REGM4XEN_MULT 4
+
 int omap4xxx_clk_init(void);
 
 #endif
diff --git a/arch/arm/mach-omap2/clock44xx_data.c 
b/arch/arm/mach-omap2/clock44xx_data.c
index c0b6fbd..c98c0a2 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -270,8 +270,8 @@ static struct clk dpll_abe_ck = {
.dpll_data  = dpll_abe_dd,
.init   = omap2_init_dpll_parent,
.ops= clkops_omap3_noncore_dpll_ops,
-   .recalc = omap3_dpll_recalc,
-   .round_rate = omap2_dpll_round_rate,
+   .recalc = omap4_dpll_regm4xen_recalc,
+   .round_rate = omap4_dpll_regm4xen_round_rate,
.set_rate   = omap3_noncore_dpll_set_rate,
 };
 
diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
index 4e4da61..9c6a296 100644
--- a/arch/arm/mach-omap2/dpll44xx.c
+++ b/arch/arm/mach-omap2/dpll44xx.c
@@ -19,6 +19,7 @@
 #include plat/clock.h
 
 

Re: [PATCH v3 3/6] OMAP3+: use DPLL's round_rate when setting rate

[Paul Walmsley]

Hi,

On Fri, 16 Sep 2011, Jon Hunter wrote:

 From: Mike Turquette mturque...@ti.com
 
 omap3_noncore_dpll_set_rate uses omap2_dpll_round_rate explicitly.  Instead
 use the struct clk pointer's round_rate function to allow for DPLL's with
 special needs.
 
 Also the rounded rate can differ from target rate, so to better reflect
 reality set clk-rate equal to the rounded rate when setting DPLL frequency.
 This avoids issues where the DPLL frequency is slightly different than what
 debugfs clock tree reports using the old target rate.
 
 An example of both of these needs is DPLL_ABE on OMAP4 which can have a 4x
 multiplier on top of the usual MN dividers depending on register settings.
 This requires a special round_rate function that might yield a rate
 different from the initial target.
 
 Signed-off-by: Mike Turquette mturque...@ti.com
 Signed-off-by: Jon Hunter jon-hun...@ti.com

The two separate changes in this patch have been separated out into two 
patches - both included below.  Please let me know if you have any 
comments; otherwise, I'll queue for 3.2.


- Paul

From: Mike Turquette mturque...@ti.com
Date: Wed, 28 Sep 2011 00:00:32 -0600
Subject: [PATCH] ARM: OMAP3+: dpll: use DPLL's round_rate when setting rate

omap3_noncore_dpll_set_rate uses omap2_dpll_round_rate explicitly.  Instead
use the struct clk pointer's round_rate function to allow for DPLL's with
special needs.

An example of a clock that requires this is DPLL_ABE on OMAP4 which
can have a 4x multiplier on top of the usual MN dividers depending on
register settings.  This requires a special round_rate function that
might yield a rate different from the initial target.

Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
[p...@pwsan.com: split rate assignment portion into a separate patch]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
 arch/arm/mach-omap2/dpll3xxx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index f77022b..6b0fa37 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -455,7 +455,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned 
long rate)
new_parent = dd-clk_bypass;
} else {
if (dd-last_rounded_rate != rate)
-   omap2_dpll_round_rate(clk, rate);
+   clk-round_rate(clk, rate);
 
if (dd-last_rounded_rate == 0)
return -EINVAL;
-- 
1.7.6.3




From: Mike Turquette mturque...@ti.com
Date: Wed, 28 Sep 2011 00:00:32 -0600
Subject: [PATCH] ARM: OMAP3+: dpll: assign clk rate from rounded rate during
 rate set

The rounded rate can differ from target rate, so to better reflect
reality set clk-rate equal to the rounded rate when setting DPLL frequency.
This avoids issues where the DPLL frequency is slightly different than what
debugfs clock tree reports using the old target rate.

An example of a clock that requires this is DPLL_ABE on OMAP4 which
can have a 4x multiplier on top of the usual MN dividers depending on
register settings.  This requires a special round_rate function that
might yield a rate different from the initial target.

Signed-off-by: Mike Turquette mturque...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
---
 arch/arm/mach-omap2/dpll3xxx.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 6b0fa37..73a1595 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -455,7 +455,7 @@ int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned 
long rate)
new_parent = dd-clk_bypass;
} else {
if (dd-last_rounded_rate != rate)
-   clk-round_rate(clk, rate);
+   rate = clk-round_rate(clk, rate);
 
if (dd-last_rounded_rate == 0)
return -EINVAL;
-- 
1.7.6.3

--
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 4/6] OMAP3+: use DPLLs recalc function instead of omap2_get_dpll_rate

[Paul Walmsley]

On Fri, 16 Sep 2011, Jon Hunter wrote:

 From: Jon Hunter jon-hun...@ti.com
 
 This is a continuation of Mike Turquette's patch OMAP3+: use
 DPLL's round_rate when setting rate.
 
 omap3_noncore_dpll_set_rate() and omap3_noncore_dpll_enable() call
 omap2_get_dpll_rate() explicitly. It may be necessary for some
 DPLLs to use a different function and so use the DPLLs recalc()
 function pointer instead.
 
 An example is the DPLL_ABE on OMAP4 which can have a 4X multiplier
 in addition to the usual MN multipler and dividers and therefore
 uses a different round_rate and recalc function.
 
 Signed-off-by: Jon Hunter jon-hun...@ti.com

Thanks, queued for 3.2.


- 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

Re: [PATCH 2/9] regulator: helper routine to extract regulator_init_data

[Cousson, Benoit]

On 9/27/2011 5:05 PM, Mark Brown wrote:

On Tue, Sep 27, 2011 at 08:18:04PM +0530, Rajendra Nayak wrote:

On Tuesday 27 September 2011 05:40 PM, Mark Brown wrote:

On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:



+   init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
+GFP_KERNEL);
+   if (!init_data)
+   return NULL; /* Out of memory? */



This means that the init data will be kept around for the entire
lifetime of the device rather than being discarded.



Wasn't it the same while this was passed around as platform_data?


It was in the past but I remember fixing it at some point.  Perhaps I'm
imagining things.


+   init_data-supply_regulator = (char *)of_get_property(dev-of_node,
+   regulator-supplies, NULL);



I'd expect that in the device tree world the supply regulator would
reference the node for that regulator.



You mean using phandles? Thats what Grant proposed too but
I thought you instead had an inclination towards names? Or maybe
I misunderstood.


They need both.  We need to reference the device that provides the
supply and use a name to say which of the potentially multiple supplies
on the consumer device is which.


Hrm, I think loosing the signs here is bad karma - negative voltages do
exist after all.



Oops.. they do? didn't know about that.


Yup, ground is just a reference point.


Yep, we do have a negative charge pump to generate -1.9v from 3.8v to 
supply the audio power amplifier part in twl6040 for example.


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 8/9] regulator: helper to extract regulator node based on supply name

[Cousson, Benoit]

On 9/27/2011 8:59 PM, Mark Brown wrote:

On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:

On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:

On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:



+   if (!dev)
+   return NULL;



So how do we handle CPUs?  cpufreq is one of the most active users of
regulators...



Hmm, never thought of it :(
Maybe I should associate a supply name with all
regulators and then lookup from the global registered
list.


I'm not sure how this should work in a device tree world, I'd *hope*
we'd get a device tree node for the CPU and could then just make this a
regular consumer thing but then the cpufreq drivers would need to be
updated to make use of it.  The only reason we allow null devices right
now is the fact that cpufreq doesn't have a struct device it can use.


That's why we do have a MPU node in OMAP dts, in order to build an 
omap_device that will be mainly used for the DVFS on the MPU.


And even before DT migration, we used to build statically some 
omap_device to represent the various processors in the system (MPU, DSP, 
CortexM3...).


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 02/13] gpio/omap: Adapt GPIO driver to DT

[Cousson, Benoit]

Hi Rajendra,

On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:

On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:

Adapt the GPIO driver to retrieve information from a DT file.
Note that since the driver is currently under cleanup, some hacks
will have to be removed after.

Add documentation for GPIO properties specific to OMAP.

Remove an un-needed whitespace.

Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Grant Likelygrant.lik...@secretlab.ca
Cc: Charulatha Vch...@ti.com
Cc: Tarun Kanti DebBarmatarun.ka...@ti.com
---
   .../devicetree/bindings/gpio/gpio-omap.txt |   33 ++
   drivers/gpio/gpio-omap.c   |  108 
++--
   2 files changed, 132 insertions(+), 9 deletions(-)
   create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt

diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt 
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
new file mode 100644
index 000..bdd63de
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -0,0 +1,33 @@
+OMAP GPIO controller
+
+Required properties:
+- compatible:
+  - ti,omap2-gpio for OMAP2 and OMAP3 controllers


Would it be more readable to have
ti,omap2-gpio for OMAP2 controllers and
ti,omap3-gpio for OMAP3 controllers?


+  - ti,omap4-gpio for OMAP4 controller
+- #gpio-cells : Should be two.
+  - first cell is the pin number
+  - second cell is used to specify optional parameters (unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the GPIO
+- id: 32 bits to identify the id (1 based index)
+- bank-width: number of pin supported by the controller (16 or 32)
+- debounce: set if the controller support the debouce funtionnality
+- bank-count: number of controller support by the SoC. This is a temporary
+  hack until the bank_count is removed from the driver.


Is there a general rule to be followed as to when to use
ti,prop-name and when to use justprop-name.
Since all these are OMAP specific properties, shouldn't all
of them be ti,prop-name?


To be honest, I was wondering as well about this rule.
I think that a property that is not purely OMAP specific and that 
represents some standard HW information does not have to be prefixed by 
ti,XXX.
So hwmods must be ti,hwmods, but bank-witdh and bank-count seems to me 
quite generic.



+Example:
+
+gpio4: gpio4 {
+compatible = ti,omap4-gpio, ti,omap-gpio;
+ti,hwmods = gpio4;
+id =4;
+bank-width =32;
+debounce;
+no_idle_on_suspend;
+#gpio-cells =2;
+gpio-controller;
+};
+
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 0599854..f878fa4 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -21,6 +21,8 @@
   #includelinux/io.h
   #includelinux/slab.h
   #includelinux/pm_runtime.h
+#includelinux/of.h
+#includelinux/of_device.h

   #includemach/hardware.h
   #includeasm/irq.h
@@ -521,7 +523,7 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int 
gpio, int enable)
unsigned long flags;

if (bank-non_wakeup_gpios   gpio_bit) {
-   dev_err(bank-dev,
+   dev_err(bank-dev,


Stray change?


Not anymore, it is part of the changelog :-)




Unable to modify wakeup on non-wakeup GPIO%d\n, gpio);
return -EINVAL;
}
@@ -1150,6 +1152,8 @@ static void __devinit omap_gpio_chip_init(struct 
gpio_bank *bank)
irq_set_handler_data(bank-irq, bank);
   }

+static const struct of_device_id omap_gpio_match[];
+
   static int __devinit omap_gpio_probe(struct platform_device *pdev)
   {
static int gpio_init_done;
@@ -1157,11 +1161,31 @@ static int __devinit omap_gpio_probe(struct 
platform_device *pdev)
struct resource *res;
int id;
struct gpio_bank *bank;
+   struct device_node *node = pdev-dev.of_node;
+   const struct of_device_id *match;
+
+   match = of_match_device(omap_gpio_match,pdev-dev);
+   if (match) {
+   pdata = match-data;
+   /* XXX: big hack until the bank_count is removed */
+   of_property_read_u32(node, bank-count,gpio_bank_count);
+   if (of_property_read_u32(node, id,id))


id should be u32.


Oops, good point.




+   return -EINVAL;
+   /*
+* In an ideal world, the id should not be needed, but since
+* the OMAP TRM consider the multiple GPIO controllers as
+* multiple banks, the GPIO number is based on the whole set
+* of banks. Hence the need to provide an id in order to
+* respect the order and the correct GPIO number.
+*/
+   id -= 1;
+   } else {
+   if (!pdev-dev.platform_data)
+   return -EINVAL;

-   if (!pdev-dev.platform_data)
-   return -EINVAL;
-
- 

Re: [PATCH 8/9] regulator: helper to extract regulator node based on supply name

[Rajendra Nayak]

On Wednesday 28 September 2011 01:39 PM, Cousson, Benoit wrote:

On 9/27/2011 8:59 PM, Mark Brown wrote:

On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:

On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:

On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:



+ if (!dev)
+ return NULL;



So how do we handle CPUs? cpufreq is one of the most active users of
regulators...



Hmm, never thought of it :(
Maybe I should associate a supply name with all
regulators and then lookup from the global registered
list.


I'm not sure how this should work in a device tree world, I'd *hope*
we'd get a device tree node for the CPU and could then just make this a
regular consumer thing but then the cpufreq drivers would need to be
updated to make use of it. The only reason we allow null devices right
now is the fact that cpufreq doesn't have a struct device it can use.


That's why we do have a MPU node in OMAP dts, in order to build an
omap_device that will be mainly used for the DVFS on the MPU.

And even before DT migration, we used to build statically some
omap_device to represent the various processors in the system (MPU, DSP,
CortexM3...).


yes, but clearly not everyone seems to do this. and then there are
also these instances of board files requesting regulators without
associating them with any device :(



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 02/13] gpio/omap: Adapt GPIO driver to DT

[Cousson, Benoit]

I missed one comment...

On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:

On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:


[...]


+Required properties:
+- compatible:
+  - ti,omap2-gpio for OMAP2 and OMAP3 controllers


Would it be more readable to have
ti,omap2-gpio for OMAP2 controllers and
ti,omap3-gpio for OMAP3 controllers?


The point here is to identify the IP version used in various OMAPs. 
Since OMAP3 and OMAP2 are using the same IP version, there is no point 
to differentiate the OMAP3 version.
What is doable is to put both ti,omap3-gpio, ti,omap2-gpio to avoid 
modifying the driver for no reason and still being able to identify the 
OMAP3 version.

But I'm not sure we should do that if there is not real difference.

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 06/13] mfd: twl-core: Add initial DT support for twl4030/twl6030

[Cousson, Benoit]

On 9/27/2011 7:42 AM, Nayak, Rajendra wrote:

On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:

Add initial device-tree support for twl familly chips.


s/familly/family


Oops.


The current version is missing the regulator entries due
to the lack of DT regulator bindings for the moment.
Only the simple sub-modules that do not depend on
platform_data information can be initialized properly.

Add documentation for the Texas Instruments TWL Integrated Chip.

Signed-off-by: Benoit Coussonb-cous...@ti.com
Cc: Balaji T Kbalaj...@ti.com
Cc: Graeme Gregoryg...@slimlogic.co.uk
Cc: Samuel Ortizsa...@linux.intel.com
---
   .../devicetree/bindings/mfd/twl-familly.txt|   47 +
   drivers/mfd/twl-core.c |   53 
++--
   2 files changed, 96 insertions(+), 4 deletions(-)
   create mode 100644 Documentation/devicetree/bindings/mfd/twl-familly.txt


s/familly.txt/family.txt


At least I am consistent in my typos ;-)


diff --git a/Documentation/devicetree/bindings/mfd/twl-familly.txt 
b/Documentation/devicetree/bindings/mfd/twl-familly.txt
new file mode 100644
index 000..ff4cacd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/twl-familly.txt
@@ -0,0 +1,47 @@
+Texas Instruments TWL family
+
+The TWLs are Integrated Power Management Chips.
+Some version might contain much more analog function like
+USB transceiver or Audio amplifier.
+These chips are connected to an i2c bus.
+
+
+Required properties:
+- compatible : Must be ti,twl4030;
+  For Integrated power-management/audio CODEC device used in OMAP3
+  based boards
+- compatible : Must be ti,twl6030;
+  For Integrated power-management used in OMAP4 based boards
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the twl support several interrupts internally,
+  it is considered as an interrupt controller cascaded to the SoC one.
+- #interrupt-cells =1;
+- interrupt-parent : The parent interrupt controller.
+
+Optional node:
+- Child nodes contain in the twl. The twl family is made of severals variants
+  that support a different number of features.
+  The children nodes will thus depend of the capabilty of the variant.
+
+
+Example:
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/twl6030.pdf
+ */
+twl@48 {
+compatible = ti,twl6030;
+reg =0x48;


What does the 'reg' property signify here for twl?


The i2c slave address.


+interrupts =39; /* IRQ_SYS_1N cascaded to gic */
+interrupt-controller;
+#interrupt-cells =1;
+interrupt-parent =gic;
+#address-cells =1;
+#size-cells =0;
+
+twl_rtc {
+compatible = ti,twl_rtc;
+interrupts =11;
+reg =0;


Does the 'reg' property need to be faked for
every twl child node, even if it does not have
any?


No, it was even removed from the DTS. But I forgot to update the 
documentation:-(



+};
+};
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 01ecfee..3ef0b43 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -33,6 +33,10 @@
   #includelinux/platform_device.h
   #includelinux/clk.h
   #includelinux/err.h
+#includelinux/slab.h
+#includelinux/of_irq.h
+#includelinux/of_platform.h
+#includelinux/irqdomain.h

   #includelinux/regulator/machine.h

@@ -1182,22 +1186,53 @@ twl_probe(struct i2c_client *client, const struct 
i2c_device_id *id)
int status;
unsignedi;
struct twl4030_platform_data*pdata = client-dev.platform_data;
+   struct device_node  *node = client-dev.of_node;
u8 temp;
int ret = 0;

+   if (node   !pdata) {
+   /*
+* XXX: Temporary fake pdata until the information
+* is correctly retrieved by every TWL modules from DT.
+*/
+   pdata = kzalloc(sizeof(struct twl4030_platform_data),
+   GFP_KERNEL);


devm_kzalloc instead?


Good point.


+   if (!pdata) {
+   status = -ENOMEM;
+   goto exit;
+   }
+
+   /*
+* XXX: For the moment the IRQs for TWL seems to be encoded in
+* the global OMAP space. That should be cleaned to allow
+* dynamically adding a new IRQ controller.
+*/
+   if ((id-driver_data)   TWL6030_CLASS) {
+   pdata-irq_base = TWL6030_IRQ_BASE;
+   pdata-irq_end = pdata-irq_base + TWL6030_BASE_NR_IRQS;
+   } else {
+   pdata-irq_base = TWL4030_IRQ_BASE;
+   pdata-irq_end = pdata-irq_base + TWL4030_BASE_NR_IRQS;
+   }
+   irq_domain_add_simple(node, pdata-irq_base);
+   }
+
if (!pdata) {
dev_dbg(client-dev, no platform data?\n);
-   

Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl

[Sakari Ailus]

Hi Hiremath,

Hiremath, Vaibhav wrote:
 -Original Message- From: Laurent Pinchart
 [mailto:laurent.pinch...@ideasonboard.com] Sent: Tuesday, September
 27, 2011 11:36 PM To: Hiremath, Vaibhav Cc: Ravi, Deepthy;
 linux-me...@vger.kernel.org; t...@atomide.com; 
 li...@arm.linux.org.uk; linux-omap@vger.kernel.org; linux-arm- 
 ker...@lists.infradead.org; linux-ker...@vger.kernel.org; 
 mche...@infradead.org; g.liakhovet...@gmx.de Subject: Re: [PATCH
 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl
 
 Hi Vaibhav,
 
 On Monday 19 September 2011 17:31:02 Hiremath, Vaibhav wrote:
 On Friday, September 16, 2011 6:36 PM Laurent Pinchart wrote:
 On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote:
 On Thursday, September 08, 2011 10:51 PM Laurent Pinchart
 wrote:
 On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
 From: Vaibhav Hiremath hvaib...@ti.com
 
 In order to support TVP5146 (for that matter any video
 decoder), it is important to support G/S/ENUM_STD ioctl
 on /dev/videoX device node.
 
 Why so ? Shouldn't it be queried on the subdev output pad
 directly ?
 
 Because standard v4l2 application for analog devices will
 call these std ioctls on the streaming device node. So it's
 done on /dev/video
 to
 make the existing apllication work.
 
 Existing applications can't work with the OMAP3 ISP (and
 similar
 complex
 embedded devices) without userspace support anyway, either in
 the form
 of
 a GStreamer element or a libv4l plugin. I still believe that
 analog
 video
 standard operations should be added to the subdev pad
 operations and exposed through subdev device nodes, exactly as
 done with formats.
 
 I completely agree with your point that, existing application
 will not
 work
 without setting links properly. But I believe the assumption here
 is, media-controller should set the links (along with pad
 formants) and all existing application should work as is. Isn't
 it?
 
 The media controller is an API used (among other things) to set the
 links. You still need to call it from userspace. That won't happen
 magically. The userspace component that sets up the links and
 configures the formats, be it a GStreamer element, a libv4l plugin,
 or something else, can as well setup the standard on the TVP5146
 subdev.
 
 Please look at from analog device point of view which is interfaced
 to ISP.
 
 OMAP3 ISP = TVP5146 (video decoder)
 
 As a user I would want to expect the standard to be supported on
 streaming device node, since all standard streaming applications (for
 analog devices/interfaces) does this.
 
 Setting up the links and format is still something got added with MC
 framework, and I would consider it as a separate plug-in along with
 existing applications.
 
 Why do I need to write/use two different streaming application one
 for MC compatible device and another for non-MC?

You musn't need to.

This is something that will have to be handled by the libv4l plugin, as
the rest of controlling the device. Controls related ioctls will be
passed from the source to downstream once they apply, and I don't see
why the same shouldn't be done to the {G,S,ENUM}_STD.

Regards,

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

Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl

[Mauro Carvalho Chehab]

Em 27-09-2011 19:49, Gary Thomas escreveu:
 On 2011-09-27 16:31, Mauro Carvalho Chehab wrote:
 Em 19-09-2011 12:31, Hiremath, Vaibhav escreveu:

 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
 Sent: Friday, September 16, 2011 6:36 PM
 To: Ravi, Deepthy
 Cc: linux-me...@vger.kernel.org; t...@atomide.com; li...@arm.linux.org.uk;
 linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
 ker...@vger.kernel.org; mche...@infradead.org; g.liakhovet...@gmx.de;
 Hiremath, Vaibhav
 Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl

 Hi Deepthy,

 On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote:
 On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote:
 On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
 From: Vaibhav Hiremathhvaib...@ti.com

 In order to support TVP5146 (for that matter any video decoder),
 it is important to support G/S/ENUM_STD ioctl on /dev/videoX
 device node.

 Why so ? Shouldn't it be queried on the subdev output pad directly ?

 Because standard v4l2 application for analog devices will call these std
 ioctls on the streaming device node. So it's done on /dev/video to make
 the
 existing apllication work.

 Existing applications can't work with the OMAP3 ISP (and similar complex
 embedded devices) without userspace support anyway, either in the form of
 a
 GStreamer element or a libv4l plugin. I still believe that analog video
 standard operations should be added to the subdev pad operations and
 exposed
 through subdev device nodes, exactly as done with formats.

 [Hiremath, Vaibhav] Laurent,

 I completely agree with your point that, existing application will not work 
 without setting links properly.
 But I believe the assumption here is, media-controller should set the links 
 (along with pad formants) and
 all existing application should work as is. Isn't it?

 Yes.

 The way it is being done currently is, set the format at the pad level 
 which is same as analog standard resolution and use existing application 
 for streaming...

 Yes.

 I am ok, if we add s/g/enum_std api support at sub-dev level but this 
 should also be supported on streaming device node.

 Agreed. Standards selection should be done at device node, just like any 
 other
 device.
 
 So how do you handle a part like the TVP5150 that is standard agnostic?
 That device can sense the standard from the input signal and sets the
 result appropriately.
 
See the em28xx driver. It uses tvp5150 at the device node, and works properly.

It should be noticed, however, that the implementation at tvp5150 doesn't
implement standards detection properly, due to hardware limitation.

A proper implementation of standards detection is to get the standards mask from
userspace and let the driver detect between the standards that the userspace is
expecting.

So, userspace could, for example, do things like:

v4l2_std_id std = V4L2_STD_PAL_M | V4L2_STD_NTSC_M | V4L2_STD_PAL_DK;

ioctl (fd, VIDIOC_S_STD, std);
msleep (100);
ioctl (fd, VIDIOC_G_STD, std);
if (std  V4L2_STD_625_50)
height = 576;
else
height = 480;

The above code won't work with the current tvp5150 driver, due to two reasons:

1) The tvp5150 register 0x28 doesn't allow an arbitrary standards mask like the 
above.
The driver does support standards detection, if V4L2_STD_ALL is passed into it.

2) even if V4L2_STD_ALL is used, the driver currently doesn't implement a
vidioc_g_std callback. So, the driver cannot return back to userspace and to
the bridge driver what standard were detected. Without this information, 
userspace
might use the wrong number of lines when allocating the buffer, and this won't
work.

Of course, patches for fixing this are welcome.

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

Re: [PATCH 1/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap4

[Ming Lei]

Hi Paul,

On Fri, Sep 23, 2011 at 7:31 AM, Paul Walmsley p...@pwsan.com wrote:

 The idea of the main_clk was not intended to be PRCM or OCP or even
 OMAP-specific.  It's just intended to represent a clock that is used to
 drive the register logic inside the IP block.  Therefore it must be
 enabled before any register access may occur.  Even if clock gating is
 handled by some higher-level interface (e.g., at the IP block level), the
 main_clk has a rate, so it also implies an upper limit on how quickly
 register operations can occur.  I suppose that all of the IP block's
 clocks could be optional clocks, but we know that every IP block with
 registers requires at least one clock to work, and that should be the
 main_clk.

I am a bit confused about you comment on main_clk.

From hwmod related source code, main_clk is the function clock
of one module(hwmod), such as: on omap4, for uart3, main_clk is
uart3_fck.

But from[1] and [2] of omap4 PRM, we can find that interface clock
is required to provide register access instead of function clock.

This is a bit conflictive with what you description, so could you
give a further comments about main_clk, function clock and interface
clock?


[1], 23.3.4.2 Clock Configuration
Each UART uses a 48-MHz functional clock for its logic
and to generate external interface signals. Each UART
uses an interface clock for register accesses.

[2], 3.1.1.1.1 Module Interface and Functional Clocks
The interface clocks have the following characteristics:
• They ensure proper communication between any module/subsystem
and the interconnect.
• In most cases, they supply the system interconnect interface
and registers of the module.

thanks,
-- 
Ming Lei
--
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 8/9] regulator: helper to extract regulator node based on supply name

[Rajendra Nayak]

On Wednesday 28 September 2011 12:29 AM, Mark Brown wrote:

On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:

On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:

On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:



+   if (!dev)
+   return NULL;



So how do we handle CPUs?  cpufreq is one of the most active users of
regulators...



Hmm, never thought of it :(
Maybe I should associate a supply name with all
regulators and then lookup from the global registered
list.


I'm not sure how this should work in a device tree world, I'd *hope*
we'd get a device tree node for the CPU and could then just make this a
regular consumer thing but then the cpufreq drivers would need to be
updated to make use of it.  The only reason we allow null devices right
now is the fact that cpufreq doesn't have a struct device it can use.


+   snprintf(prop_name, 32, %s-supply, supply);
+
+   prop = of_get_property(dev-of_node, prop_name,sz);
+   if (!prop || sz   4)
+   return NULL;



sz   4?  Magic!  :)



Its the valid phandle size.
I guess I need a sz != 4


I think we need an of_get_phandle(), it'd be clearer what the check is,
more type safe and would avoid needing to replicate the check.


Yes, there already seems to be one, of_parse_phandle() which I should
have used. thanks.

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

Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3

[Munegowda, Keshava]

On Mon, Sep 26, 2011 at 8:15 PM, Paul Walmsley p...@pwsan.com wrote:
 On Mon, 26 Sep 2011, Munegowda, Keshava wrote:

 On Sat, Sep 24, 2011 at 12:45 PM, Paul Walmsley p...@pwsan.com wrote:
  On Fri, 23 Sep 2011, Munegowda, Keshava wrote:
 
  On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com wrote:
  
   On Thu, 22 Sep 2011, Keshava Munegowda wrote:
   4. usb_tll_hs hwmod of usbhs with the TLL base address and irq.
  
   Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
   Reviewed-by: Partha Basak part...@india.ti.com
   ---
    arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |  271 
   
    1 files changed, 271 insertions(+), 0 deletions(-)
  
   diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
   b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
   index 59fdb9f..d79f728 100644
   --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
   +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
 
   +static struct omap_hwmod_ocp_if omap34xx_f128m_cfg__usb_host_hs = {
   +     .clk            = usbhost_120m_fck,
  
   This doesn't look right.  This is an interface structure record, so it
   should be associated with an interface clock.  Is the hardware really
   using the functional clock as the interface clock?  Or, as seems more
   likely...
 
 
  Agreed, how about:
 
  main clock: usbhost_120m_fck
  optional f clock: usbhost_48m_fck
 
  Assuming the interface clock is enabled, which one of these clocks is
  needed for UHH register accesses to complete successfully?

 it is usbhost_48m_fck ;
 so,
 main clock: usbhost_48m_fck
 optional clock : usbhost_120m_fck

 do you agree?

 Yes.

Thanks paul,

But In USB Host case, there is a challenge!

I need both usbhost_48m_fck and usbhost_120m_fck to be turned on when
I invoke pm_runtime_get_sync ; so there are couple of options to do this

1. use clk_get with hard coded  usbhost_120m_fck name in  usbhs driver
   enable this clock after invoking pm_runtime_get_sync

2. add an additional flag in hwmod ; so that pm_runtime_get_sync will enable
   main clock as well as optional clocks

please comment on these two approaches..


regards
keshava
--
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] mmc: omap_hsmmc: use runtime put sync in probe error path

[Balaji T K]

pm_runtime_put_sync instead of autosuspend pm runtime API
because iounmap(host-base) follows immediately.

Reported-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
---
 drivers/mmc/host/omap_hsmmc.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21e4a79..f59bea8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2091,8 +2091,7 @@ err_reg:
 err_irq_cd_init:
free_irq(host-irq, host);
 err_irq:
-   pm_runtime_mark_last_busy(host-dev);
-   pm_runtime_put_autosuspend(host-dev);
+   pm_runtime_put_sync(host-dev);
clk_put(host-fclk);
if (host-got_dbclk) {
clk_disable(host-dbclk);
-- 
1.7.0.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 8/9] regulator: helper to extract regulator node based on supply name

[Mark Brown]

On Wed, Sep 28, 2011 at 10:09:30AM +0200, Cousson, Benoit wrote:
 On 9/27/2011 8:59 PM, Mark Brown wrote:

 I'm not sure how this should work in a device tree world, I'd *hope*
 we'd get a device tree node for the CPU and could then just make this a
 regular consumer thing but then the cpufreq drivers would need to be
 updated to make use of it.  The only reason we allow null devices right
 now is the fact that cpufreq doesn't have a struct device it can use.

 That's why we do have a MPU node in OMAP dts, in order to build an
 omap_device that will be mainly used for the DVFS on the MPU.

 And even before DT migration, we used to build statically some
 omap_device to represent the various processors in the system (MPU,
 DSP, CortexM3...).

Yeah, but that's very OMAP specific - we don't have that in general (in
fact it's the only Linux platform I'm aware of that has a device for the
CPU).
--
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] OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1

[T Krishnamoorthy, Balaji]

Hi Tony,

Can you queue this patch ?

On Fri, Sep 9, 2011 at 7:34 PM, T Krishnamoorthy, Balaji
balaj...@ti.com wrote:
 On Fri, Aug 12, 2011 at 8:43 PM, Buckley, Bryan bryan.buck...@ti.com wrote:
 On Fri, Jul 22, 2011 at 7:30 AM, Kishore Kadiyala
 kishorek.kadiy...@gmail.com wrote:

 On Fri, Jul 22, 2011 at 12:59 AM, Bryan Buckley bryan.buck...@ti.com 
 wrote:
  Remove OMAP4_USBC1_ICUSB_PWRDNZ_MASK during enable/disable PWRDNZ mode for
  MMC1_PBIAS and associated extended-drain MMC1 I/O cell. This is in 
  accordance
  with the control module programming guide. This fixes a bug where if 
  trying to
  use gpio_98 or gpio_99 and MMC1 at the same time the GPIO signal will be
  affected by a changing SDMMC1_VDDS.
 
  Software must keep MMC1_PBIAS cell and MMC1_IO cell PWRDNZ signals low 
  whenever
  SDMMC1_VDDS ramps up/down or changes for cell protection purposes.
 
  MMC1 is based on SDMMC1_VDDS whereas USBC1 is based on SIM_VDDS therefore
  they can operate independently.
 
  Signed-off-by: Bryan Buckley bryan.buck...@ti.com

 Good catch,

 Acked-by:  Kishore Kadiyala kishore.kadiy...@ti.com


 Any other comments from anyone else?  Noticed that this commit isn't
 in any upstream branches. This patch will fix issues with people who
 want to use GPIO 98/99 AND MMC1 at the same time.  Would be good to
 have this fix upstream.

 FWIW: Tested on OMAP4 Blaze
 Tested-by: Balaji T K balaj...@ti.com

--
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 v4 0/5] OMAP_VOUT: Misc fixes and cleanup patches for 3.2

[Archit Taneja]

This set includes patches which do the following:
- Fix crash if number of displays registered by DSS2 is more than 4.
- Fix the issue of not being able to request for a buffer which is larger than
  what we did the last time.
- Fix a small bug in omap_vout_isr()
- Remove some redundant code in omap_vout_isr()
- Add basic support for DSI panels

Changes in v4:
- Fix issue in OMAP_VOUT: Fix check in reqbuf for buf_size allocation, improve
  commit message
- Remove patch OMAP_VOUT: Don't trigger updates in omap_vout_probe, replace
  with OMAP_VOUT: Increase MAX_DISPLAYS to a larger value

Archit Taneja (5):
  OMAP_VOUT: Fix check in reqbuf for buf_size allocation
  OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
  OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
  OMAP_VOUT: Add support for DSI panels
  OMAP_VOUT: Increase MAX_DISPLAYS to a larger value

 drivers/media/video/omap/omap_vout.c|  187 ---
 drivers/media/video/omap/omap_voutdef.h |2 +-
 2 files changed, 97 insertions(+), 92 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 v4 1/5] OMAP_VOUT: Fix check in reqbuf for buf_size allocation

[Archit Taneja]

The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf prevent
requesting a larger size buffer than what is allocated at kernel boot during
omap_vout_probe.

In omap_vout_buffer_setup callback API, the requested size is compared with
vout-buffer_size, this isn't correct as vout-buffer_size is later set to the
size requested in reqbuf. When the video device is opened the next time, this
check will prevent us to allocate a buffer which is larger than what we 
requested
the last time.

Don't use vout-buffer_size, always check with the parameters video1_bufsize
or video2_bufsize.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/video/omap/omap_vout.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index d9e64f3..e64a83c 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct videobuf_queue 
*q, unsigned int *count,
u32 phy_addr = 0, virt_addr = 0;
struct omap_vout_device *vout = q-priv_data;
struct omapvideo_info *ovid = vout-vid_info;
+   int vid_max_buf_size;
 
if (!vout)
return -EINVAL;
 
+   vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize :
+   video2_bufsize;
+
if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
return -EINVAL;
 
@@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q, 
unsigned int *count,
video1_numbuffers : video2_numbuffers;
 
/* Check the size of the buffer */
-   if (*size  vout-buffer_size) {
+   if (*size  vid_max_buf_size) {
v4l2_err(vout-vid_dev-v4l2_dev,
buffer allocation mismatch [%u] [%u]\n,
*size, vout-buffer_size);
-- 
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 v4 3/5] OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr

[Archit Taneja]

Currently, in omap_vout_isr(), if the panel type is DPI, and if we
get either VSYNC or VSYNC2 interrupts, we proceed ahead to set the
current buffers state to VIDEOBUF_DONE and prepare to display the
next frame in the queue.

On OMAP4, because we have 2 LCD managers, the panel type itself is not
sufficient to tell if we have received the correct irq, i.e, we shouldn't
proceed ahead if we get a VSYNC interrupt for LCD2 manager, or a VSYNC2
interrupt for LCD manager.

Fix this by correlating LCD manager to VSYNC interrupt and LCD2 manager
to VSYNC2 interrupt.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/video/omap/omap_vout.c |   14 +++---
 1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index 247ea31..6bc2620 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -566,8 +566,8 @@ err:
 
 static void omap_vout_isr(void *arg, unsigned int irqstatus)
 {
-   int ret, fid;
-   u32 addr;
+   int ret, fid, mgr_id;
+   u32 addr, irq;
struct omap_overlay *ovl;
struct timeval timevalue;
struct omapvideo_info *ovid;
@@ -583,6 +583,7 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus)
if (!ovl-manager || !ovl-manager-device)
return;
 
+   mgr_id = ovl-manager-id;
cur_display = ovl-manager-device;
 
spin_lock(vout-vbq_lock);
@@ -590,7 +591,14 @@ static void omap_vout_isr(void *arg, unsigned int 
irqstatus)
 
switch (cur_display-type) {
case OMAP_DISPLAY_TYPE_DPI:
-   if (!(irqstatus  (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
+   if (mgr_id == OMAP_DSS_CHANNEL_LCD)
+   irq = DISPC_IRQ_VSYNC;
+   else if (mgr_id == OMAP_DSS_CHANNEL_LCD2)
+   irq = DISPC_IRQ_VSYNC2;
+   else
+   goto vout_isr_err;
+
+   if (!(irqstatus  irq))
goto vout_isr_err;
break;
case OMAP_DISPLAY_TYPE_VENC:
-- 
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 v4 2/5] OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr

[Archit Taneja]

Currently, there is a lot of redundant code is between DPI and VENC panels, this
can be made common by moving out field/interlace specific code to a separate
function called omapvid_handle_interlace_display(). There is no functional
change made.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/video/omap/omap_vout.c |  172 --
 1 files changed, 82 insertions(+), 90 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index e64a83c..247ea31 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -524,10 +524,50 @@ static int omapvid_apply_changes(struct omap_vout_device 
*vout)
return 0;
 }
 
+static int omapvid_handle_interlace_display(struct omap_vout_device *vout,
+   unsigned int irqstatus, struct timeval timevalue)
+{
+   u32 fid;
+
+   if (vout-first_int) {
+   vout-first_int = 0;
+   goto err;
+   }
+
+   if (irqstatus  DISPC_IRQ_EVSYNC_ODD)
+   fid = 1;
+   else if (irqstatus  DISPC_IRQ_EVSYNC_EVEN)
+   fid = 0;
+   else
+   goto err;
+
+   vout-field_id ^= 1;
+   if (fid != vout-field_id) {
+   if (fid == 0)
+   vout-field_id = fid;
+   } else if (0 == fid) {
+   if (vout-cur_frm == vout-next_frm)
+   goto err;
+
+   vout-cur_frm-ts = timevalue;
+   vout-cur_frm-state = VIDEOBUF_DONE;
+   wake_up_interruptible(vout-cur_frm-done);
+   vout-cur_frm = vout-next_frm;
+   } else {
+   if (list_empty(vout-dma_queue) ||
+   (vout-cur_frm != vout-next_frm))
+   goto err;
+   }
+
+   return vout-field_id;
+err:
+   return 0;
+}
+
 static void omap_vout_isr(void *arg, unsigned int irqstatus)
 {
-   int ret;
-   u32 addr, fid;
+   int ret, fid;
+   u32 addr;
struct omap_overlay *ovl;
struct timeval timevalue;
struct omapvideo_info *ovid;
@@ -548,107 +588,59 @@ static void omap_vout_isr(void *arg, unsigned int 
irqstatus)
spin_lock(vout-vbq_lock);
do_gettimeofday(timevalue);
 
-   if (cur_display-type != OMAP_DISPLAY_TYPE_VENC) {
-   switch (cur_display-type) {
-   case OMAP_DISPLAY_TYPE_DPI:
-   if (!(irqstatus  (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
-   goto vout_isr_err;
-   break;
-   case OMAP_DISPLAY_TYPE_HDMI:
-   if (!(irqstatus  DISPC_IRQ_EVSYNC_EVEN))
-   goto vout_isr_err;
-   break;
-   default:
+   switch (cur_display-type) {
+   case OMAP_DISPLAY_TYPE_DPI:
+   if (!(irqstatus  (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
goto vout_isr_err;
-   }
-   if (!vout-first_int  (vout-cur_frm != vout-next_frm)) {
-   vout-cur_frm-ts = timevalue;
-   vout-cur_frm-state = VIDEOBUF_DONE;
-   wake_up_interruptible(vout-cur_frm-done);
-   vout-cur_frm = vout-next_frm;
-   }
-   vout-first_int = 0;
-   if (list_empty(vout-dma_queue))
+   break;
+   case OMAP_DISPLAY_TYPE_VENC:
+   fid = omapvid_handle_interlace_display(vout, irqstatus,
+   timevalue);
+   if (!fid)
goto vout_isr_err;
+   break;
+   case OMAP_DISPLAY_TYPE_HDMI:
+   if (!(irqstatus  DISPC_IRQ_EVSYNC_EVEN))
+   goto vout_isr_err;
+   break;
+   default:
+   goto vout_isr_err;
+   }
 
-   vout-next_frm = list_entry(vout-dma_queue.next,
-   struct videobuf_buffer, queue);
-   list_del(vout-next_frm-queue);
-
-   vout-next_frm-state = VIDEOBUF_ACTIVE;
-
-   addr = (unsigned long) vout-queued_buf_addr[vout-next_frm-i]
-   + vout-cropped_offset;
+   if (!vout-first_int  (vout-cur_frm != vout-next_frm)) {
+   vout-cur_frm-ts = timevalue;
+   vout-cur_frm-state = VIDEOBUF_DONE;
+   wake_up_interruptible(vout-cur_frm-done);
+   vout-cur_frm = vout-next_frm;
+   }
 
-   /* First save the configuration in ovelray structure */
-   ret = omapvid_init(vout, addr);
-   if (ret)
-   printk(KERN_ERR VOUT_NAME
-   failed to set overlay info\n);
-   /* Enable the pipeline and set the Go bit */
-   ret = omapvid_apply_changes(vout);
-   if (ret)
-   printk(KERN_ERR 

[PATCH v4 4/5] OMAP_VOUT: Add support for DSI panels

[Archit Taneja]

Add support for DSI panels. DSI video mode panels will work directly. For
command mode panels, we will need to trigger updates regularly. This isn't done
by the omap_vout driver currently. It can still be supported if we connect a
framebuffer device to the panel and configure it in auto update mode.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/video/omap/omap_vout.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c 
b/drivers/media/video/omap/omap_vout.c
index 6bc2620..65374b5 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -590,6 +590,7 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus)
do_gettimeofday(timevalue);
 
switch (cur_display-type) {
+   case OMAP_DISPLAY_TYPE_DSI:
case OMAP_DISPLAY_TYPE_DPI:
if (mgr_id == OMAP_DSS_CHANNEL_LCD)
irq = DISPC_IRQ_VSYNC;
-- 
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 v4 5/5] OMAP_VOUT: Increase MAX_DISPLAYS to a larger value

[Archit Taneja]

There is no limit to the number of displays that can registered with DSS2. The
current value of MAX_DISPLAYS is 3, set this to 10 so that the 'displays'
member of omap2video_device struct can store more omap_dss_device pointers.

This fixes a crash seen in omap_vout_probe when DSS2 registers for more than 3
displays.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/media/video/omap/omap_voutdef.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/omap/omap_voutdef.h 
b/drivers/media/video/omap/omap_voutdef.h
index d793501..27a95d2 100644
--- a/drivers/media/video/omap/omap_voutdef.h
+++ b/drivers/media/video/omap/omap_voutdef.h
@@ -25,7 +25,7 @@
 #define MAC_VRFB_CTXS  4
 #define MAX_VOUT_DEV   2
 #define MAX_OVLS   3
-#define MAX_DISPLAYS   3
+#define MAX_DISPLAYS   10
 #define MAX_MANAGERS   3
 
 #define QQVGA_WIDTH160
-- 
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

Re: [PATCH v2 2/6] OMAP4: Clock: round_rate and recalc functions for DPLL_ABE

[Jon Hunter]

Hi Paul,

On 9/28/2011 1:59, Paul Walmsley wrote:

Hi Jon and Mike,

On Fri, 16 Sep 2011, Jon Hunter wrote:


From: Mike Turquettemturque...@ti.com

OMAP4 DPLL_ABE can enable a 4X multipler on top of the normal MN multipler
and divider. This is achieved by setting CM_CLKMODE_DPLL_ABE.DPLL_REGM4XEN
bit in CKGEN module of CM1. From the OMAP4 TRM:

Fdpll = Fref x 2 x (4 x M/(N+1)) in case REGM4XEN bit field is set (only
applicable to DPLL_ABE).

Add new round_rate() and recalc() functions for OMAP4, that check the
setting of REGM4XEN bit and handle this appropriately. The new functions
are a simple wrapper on top of the existing omap2_dpll_round_rate() and
omap2_dpll_get_rate() functions to handle the REGM4XEN bit.

The REGM4XEN bit is only implemented for the ABE DPLL on OMAP4 and so
only dpll_abe_ck uses omap4_dpll_regm4xen_round_rate() and
omap4_dpll_regm4xen_recalc() functions.

Signed-off-by: Mike Turquettemturque...@ti.com
Tested-by: Jon Hunterjon-hun...@ti.com


Some changes have been made to this patch here, to fix a few minor bugs in
error paths and to add documentation and Jon's Signed-off-by: (since he's
in the submittal chain).

Care to review and send any comments?  Otherwise, I plan to queue this
revised version for 3.2.


Looks good to me. Thanks for fixes and documentation.

Cheers
Jon

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

Re: [PATCH v3 3/6] OMAP3+: use DPLL's round_rate when setting rate

[Jon Hunter]

Hi Paul,

On 9/28/2011 2:02, Paul Walmsley wrote:

Hi,

On Fri, 16 Sep 2011, Jon Hunter wrote:


From: Mike Turquettemturque...@ti.com

omap3_noncore_dpll_set_rate uses omap2_dpll_round_rate explicitly.  Instead
use the struct clk pointer's round_rate function to allow for DPLL's with
special needs.

Also the rounded rate can differ from target rate, so to better reflect
reality set clk-rate equal to the rounded rate when setting DPLL frequency.
This avoids issues where the DPLL frequency is slightly different than what
debugfs clock tree reports using the old target rate.

An example of both of these needs is DPLL_ABE on OMAP4 which can have a 4x
multiplier on top of the usual MN dividers depending on register settings.
This requires a special round_rate function that might yield a rate
different from the initial target.

Signed-off-by: Mike Turquettemturque...@ti.com
Signed-off-by: Jon Hunterjon-hun...@ti.com


The two separate changes in this patch have been separated out into two
patches - both included below.  Please let me know if you have any
comments; otherwise, I'll queue for 3.2.


Yes, looks good to me. Thanks. Jon
--
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 2/2] OMAP: omap_device: Add a method to build an omap_device from a DT node

[Cousson, Benoit]

Hi Grant, Kevin,

Should I go ahead with this version and repost the series with that 
third patch?


Thanks,
Benoit


On 9/27/2011 6:04 PM, Cousson, Benoit wrote:

[...]


From 4403f8a00090e5ea1814a5242947b81c348947a1 Mon Sep 17 00:00:00 2001
From: Benoit Coussonb-cous...@ti.com
Date: Tue, 27 Sep 2011 17:45:43 +0200
Subject: [PATCH] of: Add helpers to get one string in multiple strings property

Add of_property_read_string_index and of_property_count_strings
to retrieve one string inside a property that will contains
severals strings.

Signed-off-by: Benoit Coussonb-cous...@ti.com
---
  drivers/of/base.c  |   85 
  include/linux/of.h |   18 +++
  2 files changed, 103 insertions(+), 0 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 3ff22e3..d97d53e 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -662,6 +662,91 @@ int of_property_read_string(struct device_node *np, const 
char *propname,
  EXPORT_SYMBOL_GPL(of_property_read_string);

  /**
+ * of_property_read_string_index - Find and read a string from a multiple
+ * strings property.
+ * @np:device node from which the property value is to be read.
+ * @propname:  name of the property to be searched.
+ * @index: index of the string in the list of strings
+ * @out_string:pointer to null terminated return string, modified only 
if
+ * return value is 0.
+ *
+ * Search for a property in a device tree node and retrieve a null
+ * terminated string value (pointer to data, not a copy) in the list of strings
+ * contained in that property.
+ * Returns 0 on
+ * success, -EINVAL if the property does not exist, -ENODATA if property
+ * does not have a value, and -EILSEQ if the string is not null-terminated
+ * within the length of the property data.
+ *
+ * The out_string pointer is modified only if a valid string can be decoded.
+ */
+int of_property_read_string_index(struct device_node *np, const char *propname,
+ int index, const char **output)
+{
+   struct property *prop = of_find_property(np, propname, NULL);
+   int i = 0;
+   size_t l = 0, total = 0;
+   const char *p;
+
+   if (!prop)
+   return -EINVAL;
+   if (!prop-value)
+   return -ENODATA;
+   if (strnlen(prop-value, prop-length)= prop-length)
+   return -EILSEQ;
+
+   p = prop-value;
+
+   for (i = 0; total  prop-length; total += l, p += l) {
+   l = strlen(p) + 1;
+   if ((*p != 0)  (i++ == index)) {
+   *output = p;
+   return 0;
+   }
+   }
+   return -ENODATA;
+}
+EXPORT_SYMBOL_GPL(of_property_read_string_index);
+
+
+/**
+ * of_property_count_strings - Find and return the number of strings from a
+ * multiple strings property.
+ * @np:device node from which the property value is to be read.
+ * @propname:  name of the property to be searched.
+ *
+ * Search for a property in a device tree node and retrieve the number of null
+ * terminated string contain in it. Returns the number of strings on
+ * success, -EINVAL if the property does not exist, -ENODATA if property
+ * does not have a value, and -EILSEQ if the string is not null-terminated
+ * within the length of the property data.
+ */
+int of_property_count_strings(struct device_node *np, const char *propname)
+{
+   struct property *prop = of_find_property(np, propname, NULL);
+   int i = 0;
+   size_t l = 0, total = 0;
+   const char *p;
+
+   if (!prop)
+   return -EINVAL;
+   if (!prop-value)
+   return -ENODATA;
+   if (strnlen(prop-value, prop-length)= prop-length)
+   return -EILSEQ;
+
+   p = prop-value;
+
+   for (i = 0; total  prop-length; total += l, p += l) {
+   l = strlen(p) + 1;
+   if (*p != 0)
+   i++;
+   }
+   return i;
+}
+EXPORT_SYMBOL_GPL(of_property_count_strings);
+
+/**
   * of_parse_phandle - Resolve a phandle property to a device_node pointer
   * @np: Pointer to device node holding phandle property
   * @phandle_name: Name of property holding a phandle value
diff --git a/include/linux/of.h b/include/linux/of.h
index 9180dc5..9eadc4e 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -203,6 +203,11 @@ extern int of_property_read_u32_array(const struct 
device_node *np,
  extern int of_property_read_string(struct device_node *np,
   const char *propname,
   const char **out_string);
+extern int of_property_read_string_index(struct device_node *np,
+const char *propname,
+int index, const char **output);
+extern int of_property_count_strings(struct device_node *np,
+const char 

Re: [PATCH v3 2/2] OMAP: omap_device: Add a method to build an omap_device from a DT node

[Kevin Hilman]

Cousson, Benoit b-cous...@ti.com writes:

 Hi Grant, Kevin,

 Should I go ahead with this version and repost the series with that
 third patch?

Fine with me.

Grant let me know if you prefer if I merge it (with your ack) with the
rest of the series or if you want to take it to avoid conflicts.

Kevin
--
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] OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1

[Tony Lindgren]

* T Krishnamoorthy, Balaji balaj...@ti.com [110928 05:00]:
 Hi Tony,
 
 Can you queue this patch ?

Thanks, adding into fixes.

Tony
 
 On Fri, Sep 9, 2011 at 7:34 PM, T Krishnamoorthy, Balaji
 balaj...@ti.com wrote:
  On Fri, Aug 12, 2011 at 8:43 PM, Buckley, Bryan bryan.buck...@ti.com 
  wrote:
  On Fri, Jul 22, 2011 at 7:30 AM, Kishore Kadiyala
  kishorek.kadiy...@gmail.com wrote:
 
  On Fri, Jul 22, 2011 at 12:59 AM, Bryan Buckley bryan.buck...@ti.com 
  wrote:
   Remove OMAP4_USBC1_ICUSB_PWRDNZ_MASK during enable/disable PWRDNZ mode 
   for
   MMC1_PBIAS and associated extended-drain MMC1 I/O cell. This is in 
   accordance
   with the control module programming guide. This fixes a bug where if 
   trying to
   use gpio_98 or gpio_99 and MMC1 at the same time the GPIO signal will be
   affected by a changing SDMMC1_VDDS.
  
   Software must keep MMC1_PBIAS cell and MMC1_IO cell PWRDNZ signals low 
   whenever
   SDMMC1_VDDS ramps up/down or changes for cell protection purposes.
  
   MMC1 is based on SDMMC1_VDDS whereas USBC1 is based on SIM_VDDS 
   therefore
   they can operate independently.
  
   Signed-off-by: Bryan Buckley bryan.buck...@ti.com
 
  Good catch,
 
  Acked-by:  Kishore Kadiyala kishore.kadiy...@ti.com
 
 
  Any other comments from anyone else?  Noticed that this commit isn't
  in any upstream branches. This patch will fix issues with people who
  want to use GPIO 98/99 AND MMC1 at the same time.  Would be good to
  have this fix upstream.
 
  FWIW: Tested on OMAP4 Blaze
  Tested-by: Balaji T K balaj...@ti.com
 
--
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] OMAP: irq: loop counter fix in omap_init_irq()

[Tony Lindgren]

* Tapani Utriainen tap...@technexion.com [110721 20:58]:
 From: Tapani Utriainen tap...@technexion.com
 
 Fixes bug where variable i was redundantly used for counting two nested loops.

Thanks  sorry for the delay. Adding this into fixes.

Tony
 
 Signed-off-by: Tapani Utriainen tap...@technexion.com
 --- 
  irq.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 --- a/arch/arm/mach-omap2/irq.c
 +++ b/arch/arm/mach-omap2/irq.c
 @@ -165,8 +165,8 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
  
   omap_irq_bank_init_one(bank);
  
 - for (i = 0, j = 0; i  bank-nr_irqs; i += 32, j += 0x20)
 - omap_alloc_gc(bank-base_reg + j, i, 32);
 + for (j = 0; j  bank-nr_irqs; j += 32)
 + omap_alloc_gc(bank-base_reg + j, j, 32);
  
   nr_of_irqs += bank-nr_irqs;
   nr_banks++;
 --
 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
--
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 02/13] gpio/omap: Adapt GPIO driver to DT

[Scott Wood]

On 09/28/2011 03:15 AM, Cousson, Benoit wrote:
 On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:
 On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:
 +Required properties:
 +- compatible:
 +  - ti,omap2-gpio for OMAP2 and OMAP3 controllers

 Would it be more readable to have
 ti,omap2-gpio for OMAP2 controllers and
 ti,omap3-gpio for OMAP3 controllers?

Or have OMAP3 say this if it's fully backwards compatible:

compatible = ti,omap3-gpio, ti,omap2-gpio;

 +  - ti,omap4-gpio for OMAP4 controller
 +- #gpio-cells : Should be two.
 +  - first cell is the pin number
 +  - second cell is used to specify optional parameters (unused)
 +- gpio-controller : Marks the device node as a GPIO controller.
 +
 +OMAP specific properties:
 +- ti,hwmods: Name of the hwmod associated to the GPIO
 +- id: 32 bits to identify the id (1 based index)

What does the id mean, in relation to the actual hardware?

Some existing bindings have such a thing (often called cell-index),
but it should be well-defined what it refers to.  Often aliases would be
a better approach, if it just refers to what the manual calls the device.

 +- bank-width: number of pin supported by the controller (16 or 32)
 +- debounce: set if the controller support the debouce funtionnality
 +- bank-count: number of controller support by the SoC. This is a
 temporary
 +  hack until the bank_count is removed from the driver.

 Is there a general rule to be followed as to when to use
 ti,prop-name and when to use justprop-name.
 Since all these are OMAP specific properties, shouldn't all
 of them be ti,prop-name?
 
 To be honest, I was wondering as well about this rule.
 I think that a property that is not purely OMAP specific and that
 represents some standard HW information does not have to be prefixed by
 ti,XXX.
 So hwmods must be ti,hwmods, but bank-witdh and bank-count seems to me
 quite generic.

It's about where the property is documented.  Suppose you use an
un-prefixed bank-width but define it in the TI-specific binding to mean
width in bits.  Later, someone wants something similar for another
driver, doesn't look at the TI binding, but says, This is generic, I'll
define something in the main gpio binding, but defines it as width in
bytes (ignore the (de)merits of defining it that way in this case).  If
you had a namespace prefix, it would be clear which binding a node is
referring to.

As for bank-count, the description this is a temporary hack until the
bank_count is removed from the driver suggests it shouldn't be there at
all, much less be part of the generic binding.

-Scott

--
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] OMAP4: Keyboard: Fix section mismatch in the board file

[Tony Lindgren]

* Bjarne Steinsbo bstein...@gmail.com [110913 23:39]:
 I can't see this one queued up anywhere.  Did it just slip through the
 cracks, or are there any problems with it?

Just slipped through the cracks.. Adding into fixes thanks.

Tony
 
 BR,
 
 Bjarne Steinsbo
 
 On Tue, Aug 16, 2011 at 8:53 AM, Felipe Balbi ba...@ti.com wrote:
  On Fri, Aug 12, 2011 at 05:27:52PM +0200, Bjarne Steinsbo wrote:
  `keypad_pads' is referred to by `keypad_data' which is
  not __initdata, so `keypad_pads' should not be __initdata either.
 
  Signed-off-by: Bjarne Steinsbo bstein...@gmail.com
 
  Reviewed-by: Felipe Balbi ba...@ti.com
 
  --
  balbi
 
--
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] OMAP: Fix linking error in twl-common.c for OMAP2/3/4 only builds

[Tony Lindgren]

Hi,

Sorry for the delay in replying..

* Michael Jones michael.jo...@matrix-vision.de [110811 07:34]:
 
 I still stumbled upon these linker errors when building for my OMAP3
 board, using the current linux-omap master branch. I inadvertently had
 CONFIG_ARCH_OMAP4=y (leftover from my starting point,
 omap2plus_defconfig), but didn't have any of the boards with
 omap_phy_internal.o selected (OMAP_4430SDP, OMAP4_PANDA, PCM049, PCM049,
 OMAP3517EVM). Maybe this isn't a concern anyway, since anybody building
 with CONFIG_ARCH_OMAP4 will presumably also be building one of those
 boards? I don't know if it is our goal to build successfully with every
 wacky CONFIG_ combination, but I thought I would report it here just in
 case.

Probably the best way is to get omap specific randconfigs going based
on something what Arnd posted few days ago. Even with the old defconfig
files we'll still be missing many corner cases.

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: [PATCH v2 4/4] arm: BeagleBoard: add support for the twl4030-madc

[Tony Lindgren]

* Kyle Manna k...@kylemanna.com [110811 20:01]:
 Signed-off-by: Kyle Manna k...@kylemanna.com

Missing description, but with that corrected:

Acked-by: Tony Lindgren t...@atomide.com

 ---
  arch/arm/mach-omap2/board-omap3beagle.c |9 -
  1 files changed, 8 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
 b/arch/arm/mach-omap2/board-omap3beagle.c
 index 3ae16b4..9cc9fa9 100644
 --- a/arch/arm/mach-omap2/board-omap3beagle.c
 +++ b/arch/arm/mach-omap2/board-omap3beagle.c
 @@ -378,7 +378,8 @@ static struct i2c_board_info __initdata 
 beagle_i2c_eeprom[] = {
  static int __init omap3_beagle_i2c_init(void)
  {
   omap3_pmic_get_config(beagle_twldata,
 - TWL_COMMON_PDATA_USB | TWL_COMMON_PDATA_AUDIO,
 + TWL_COMMON_PDATA_USB | TWL_COMMON_PDATA_MADC |
 + TWL_COMMON_PDATA_AUDIO,
   TWL_COMMON_REGULATOR_VDAC | TWL_COMMON_REGULATOR_VPLL2);
  
   beagle_twldata.vpll2-constraints.name = VDVI;
 @@ -456,9 +457,15 @@ static void __init omap3_beagle_init_irq(void)
   omap3_init_irq();
  }
  
 +static struct platform_device madc_hwmon = {
 + .name   = twl4030_madc_hwmon,
 + .id = -1,
 +};
 +
  static struct platform_device *omap3_beagle_devices[] __initdata = {
   leds_gpio,
   keys_gpio,
 + madc_hwmon,
  };
  
  static const struct usbhs_omap_board_data usbhs_bdata __initconst = {
 -- 
 1.7.4.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

Re: [PATCH v2 0/4] Fixes to twl4030-madc and add BeagleBoard support

[Tony Lindgren]

* Samuel Ortiz sa...@linux.intel.com [110822 06:20]:
 Hi Kyle,
 
 On Thu, Aug 11, 2011 at 10:33:11PM -0500, Kyle Manna wrote:
  These patches add basic functionality to the twl4030-madc driver to make
  it work on the BeagleBoard xM.
  
  Version 2 adds fixes per Grazvydas Ignotas and the check for NULL pointer 
  patch.
  
  Kyle Manna (4):
mfd: twl4030-madc: copy the device pointer
mfd: twl4030-madc: turn on the MADC clock
mfd: twl4030-madc: check for NULL pointer
arm: BeagleBoard: add support for the twl4030-madc
 Tony, are you ok with the BeagleBoard changes ?
 The MFD ones look fine to me, I'd like to apply them.

Yes sorry for the delay in replying. I acked it, maybe
you can just copy the subject to have a proper description
for the patch.

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: [PATCH 02/13] gpio/omap: Adapt GPIO driver to DT

[Cousson, Benoit]

On 9/28/2011 8:23 PM, Scott Wood wrote:

On 09/28/2011 03:15 AM, Cousson, Benoit wrote:

On 9/27/2011 7:40 AM, Nayak, Rajendra wrote:

On Monday 26 September 2011 10:20 PM, Benoit Cousson wrote:

+Required properties:
+- compatible:
+  - ti,omap2-gpio for OMAP2 and OMAP3 controllers


Would it be more readable to have
ti,omap2-gpio for OMAP2 controllers and
ti,omap3-gpio for OMAP3 controllers?


Or have OMAP3 say this if it's fully backwards compatible:

compatible = ti,omap3-gpio, ti,omap2-gpio;


I saw that several time for other platform, but was wondering if this 
was a strong rule or not. In that case, the IP is the same, so should we 
still identify it with a different compatible value?



+  - ti,omap4-gpio for OMAP4 controller
+- #gpio-cells : Should be two.
+  - first cell is the pin number
+  - second cell is used to specify optional parameters (unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the GPIO
+- id: 32 bits to identify the id (1 based index)


What does the id mean, in relation to the actual hardware?


It's true that the description is not super meaningful...
This is the HW instance number. We have 6 gpios, named gpio1 to gpio6, 
but the pin numbering is global, meaning from 1 to 192, sine only the 
global number is referenced in the pinmuxing control, we have to 
maintain the order to ensure the right number.


I still do not know how to use that with the way gpio binding is 
working. Because in theory each gpio controller should be referenced 
with the local number, not the global one. And converting that global 
number from HW spec to a gpio instance + local number seems to me very 
error prone.



Some existing bindings have such a thing (often called cell-index),
but it should be well-defined what it refers to.  Often aliases would be
a better approach, if it just refers to what the manual calls the device.


The issue is that the manual refer to a global gpio controller.


+- bank-width: number of pin supported by the controller (16 or 32)
+- debounce: set if the controller support the debouce funtionnality
+- bank-count: number of controller support by the SoC. This is a
temporary
+  hack until the bank_count is removed from the driver.


Is there a general rule to be followed as to when to use
ti,prop-name and when to use justprop-name.
Since all these are OMAP specific properties, shouldn't all
of them be ti,prop-name?


To be honest, I was wondering as well about this rule.
I think that a property that is not purely OMAP specific and that
represents some standard HW information does not have to be prefixed by
ti,XXX.
So hwmods must be ti,hwmods, but bank-witdh and bank-count seems to me
quite generic.


It's about where the property is documented.  Suppose you use an
un-prefixed bank-width but define it in the TI-specific binding to mean
width in bits.  Later, someone wants something similar for another
driver, doesn't look at the TI binding, but says, This is generic, I'll
define something in the main gpio binding, but defines it as width in
bytes (ignore the (de)merits of defining it that way in this case).  If
you had a namespace prefix, it would be clear which binding a node is
referring to.


Good to know, and that makes sense. So the recommendation is to add that 
into the generic gpio as much as possible if this can be reused by 
someone else.



As for bank-count, the description this is a temporary hack until the
bank_count is removed from the driver suggests it shouldn't be there at
all, much less be part of the generic binding.


That one sucks and will be removed soon since the driver cleanup was 
posted and waiting for upstream acceptance.


Thanks for the detailed explanations.
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 02/13] gpio/omap: Adapt GPIO driver to DT

[Scott Wood]

On 09/28/2011 03:57 PM, Cousson, Benoit wrote:
 On 9/28/2011 8:23 PM, Scott Wood wrote:
 What does the id mean, in relation to the actual hardware?
 
 It's true that the description is not super meaningful...
 This is the HW instance number. We have 6 gpios, named gpio1 to gpio6,
 but the pin numbering is global, meaning from 1 to 192, sine only the
 global number is referenced in the pinmuxing control, we have to
 maintain the order to ensure the right number.

I'd either have one node that handles all the banks (with multiple reg
resources in the order that they should be mapped to the numberspace),
or avoid using that global numberspace and reference things by
bank/offset (with the bank identified by alias or phandle).

 I still do not know how to use that with the way gpio binding is
 working. Because in theory each gpio controller should be referenced
 with the local number, not the global one. And converting that global
 number from HW spec to a gpio instance + local number seems to me very
 error prone.

You could say the same thing about a chip whose manual is written
assuming a global IRQ numberspace with a certain encoding scheme.

Or in the other direction, Freescale's manuals split up MPIC interrupts
into external/internal/MSI, while they really just map to different
regions of the openpic (hardware standard that Freescale's MPIC is an
instance of) interrupt space.  The device trees use the raw openpic
interrupt numbers.

There's certainly potential for confusion, but at least the device tree
representation is internally consistent and doesn't make assumptions
about the overall system.

-Scott

--
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/4] Few omap fixes for review

[Tony Lindgren]

Hi all,

Here are some omap fixes for review. Only the first two would
be nice to get into v3.1 during the -rc cycle.

Regards,

Tony

---

Bjarne Steinsbo (1):
  ARM: OMAP4: Keyboard: Fix section mismatch in the board file

Bryan Buckley (1):
  ARM: OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1

Tapani Utriainen (1):
  ARM: OMAP: irq: loop counter fix in omap_init_irq()

Tony Lindgren (1):
  ARM: OMAP: Fix i2c init for twl4030


 arch/arm/mach-omap2/board-2430sdp.c |3 ++-
 arch/arm/mach-omap2/board-4430sdp.c |2 +-
 arch/arm/mach-omap2/hsmmc.c |   12 
 arch/arm/mach-omap2/irq.c   |4 ++--
 4 files changed, 9 insertions(+), 12 deletions(-)

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

[PATCH 1/4] ARM: OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1

[Tony Lindgren]

From: Bryan Buckley bryan.buck...@ti.com

Remove OMAP4_USBC1_ICUSB_PWRDNZ_MASK during enable/disable PWRDNZ mode for
MMC1_PBIAS and associated extended-drain MMC1 I/O cell. This is in accordance
with the control module programming guide. This fixes a bug where if trying to
use gpio_98 or gpio_99 and MMC1 at the same time the GPIO signal will be
affected by a changing SDMMC1_VDDS.

Software must keep MMC1_PBIAS cell and MMC1_IO cell PWRDNZ signals low whenever
SDMMC1_VDDS ramps up/down or changes for cell protection purposes.

MMC1 is based on SDMMC1_VDDS whereas USBC1 is based on SIM_VDDS therefore
they can operate independently.

Signed-off-by: Bryan Buckley bryan.buck...@ti.com
Acked-by:  Kishore Kadiyala kishore.kadiy...@ti.com
Tested-by: Balaji T K balaj...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/hsmmc.c |   12 
 1 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index a9b45c7..097a42d 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -137,8 +137,7 @@ static void omap4_hsmmc1_before_set_reg(struct device *dev, 
int slot,
 */
reg = omap4_ctrl_pad_readl(control_pbias_offset);
reg = ~(OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
-   OMAP4_MMC1_PWRDNZ_MASK |
-   OMAP4_USBC1_ICUSB_PWRDNZ_MASK);
+   OMAP4_MMC1_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
 }
 
@@ -156,8 +155,7 @@ static void omap4_hsmmc1_after_set_reg(struct device *dev, 
int slot,
else
reg |= OMAP4_MMC1_PBIASLITE_VMODE_MASK;
reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
-   OMAP4_MMC1_PWRDNZ_MASK |
-   OMAP4_USBC1_ICUSB_PWRDNZ_MASK);
+   OMAP4_MMC1_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
 
timeout = jiffies + msecs_to_jiffies(5);
@@ -171,16 +169,14 @@ static void omap4_hsmmc1_after_set_reg(struct device 
*dev, int slot,
if (reg  OMAP4_MMC1_PBIASLITE_VMODE_ERROR_MASK) {
pr_err(Pbias Voltage is not same as LDO\n);
/* Caution : On VMODE_ERROR Power Down MMC IO */
-   reg = ~(OMAP4_MMC1_PWRDNZ_MASK |
-   OMAP4_USBC1_ICUSB_PWRDNZ_MASK);
+   reg = ~(OMAP4_MMC1_PWRDNZ_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
} else {
reg = omap4_ctrl_pad_readl(control_pbias_offset);
reg |= (OMAP4_MMC1_PBIASLITE_PWRDNZ_MASK |
OMAP4_MMC1_PWRDNZ_MASK |
-   OMAP4_MMC1_PBIASLITE_VMODE_MASK |
-   OMAP4_USBC1_ICUSB_PWRDNZ_MASK);
+   OMAP4_MMC1_PBIASLITE_VMODE_MASK);
omap4_ctrl_pad_writel(reg, control_pbias_offset);
}
 }

--
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/4] ARM: OMAP: Fix i2c init for twl4030

[Tony Lindgren]

Looks like 2600 kHz rate does not work reliably on 2430,
so just use the 100 kHz rate.

Otherwise the system often fails to boot properly with:

omap_i2c omap_i2c.2: timeout waiting for bus ready
omap_i2c omap_i2c.2: timeout waiting for bus ready
twl: i2c_write failed to transfer all messages
omap_i2c omap_i2c.2: timeout waiting for bus ready
twl: i2c_write failed to transfer all messages
omap_i2c omap_i2c.2: timeout waiting for bus ready
twl: i2c_write failed to transfer all messages
twl: clock init err [-110]
omap_i2c omap_i2c.2: timeout waiting for bus ready
twl: i2c_write failed to transfer all messages
TWL4030 Unable to unlock IDCODE registers --110

Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-2430sdp.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index 2028464..f79b7d2 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -193,7 +193,8 @@ static int __init omap2430_i2c_init(void)
 {
omap_register_i2c_bus(1, 100, sdp2430_i2c1_boardinfo,
ARRAY_SIZE(sdp2430_i2c1_boardinfo));
-   omap2_pmic_init(twl4030, sdp2430_twldata);
+   omap_pmic_init(2, 100, twl4030, INT_24XX_SYS_NIRQ,
+   sdp2430_twldata);
return 0;
 }
 

--
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 3/4] ARM: OMAP4: Keyboard: Fix section mismatch in the board file

[Tony Lindgren]

From: Bjarne Steinsbo bstein...@gmail.com

`keypad_pads' is referred to by `keypad_data' which is
not __initdata, so `keypad_pads' should not be __initdata either.

Signed-off-by: Bjarne Steinsbo bstein...@gmail.com
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/board-4430sdp.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index c7cef44..9e423ac 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -129,7 +129,7 @@ static const int sdp4430_keymap[] = {
KEY(7, 6, KEY_OK),
KEY(7, 7, KEY_DOWN),
 };
-static struct omap_device_pad keypad_pads[] __initdata = {
+static struct omap_device_pad keypad_pads[] = {
{   .name   = kpd_col1.kpd_col1,
.enable = OMAP_WAKEUP_EN | OMAP_MUX_MODE1,
},

--
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 4/4] ARM: OMAP: irq: loop counter fix in omap_init_irq()

[Tony Lindgren]

From: Tapani Utriainen tap...@technexion.com

Fixes bug where variable i was redundantly used for counting two nested loops.

Signed-off-by: Tapani Utriainen tap...@technexion.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
 arch/arm/mach-omap2/irq.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/irq.c b/arch/arm/mach-omap2/irq.c
index 3a12f75..65f1be6 100644
--- a/arch/arm/mach-omap2/irq.c
+++ b/arch/arm/mach-omap2/irq.c
@@ -165,8 +165,8 @@ static void __init omap_init_irq(u32 base, int nr_irqs)
 
omap_irq_bank_init_one(bank);
 
-   for (i = 0, j = 0; i  bank-nr_irqs; i += 32, j += 0x20)
-   omap_alloc_gc(bank-base_reg + j, i, 32);
+   for (j = 0; j  bank-nr_irqs; j += 32)
+   omap_alloc_gc(bank-base_reg + j, j, 32);
 
nr_of_irqs += bank-nr_irqs;
nr_banks++;

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

[GIT PULL] dmtimer changes for v3.2 merge window

[Tony Lindgren]

Hi Arnd,

Please pull omap dmtimer changes from:

git://github.com/tmlind/linux.git dmtimer

This series completes the system timer separation from the
driver like features. It also adds support for v2 ip that is
available for some timers starting with omap4.

After this series arch/arm/plat-omap/dmtimer.c could be
moved to live under drivers somewhere, but there is still
discussion going on which features should be supported in
a generic way.

This series depends on the cleanup you pulled earlier.
As this series adds some new features like runtime PM suppport,
I've kept it separate from cleanup.

Regards,

Tony


The following changes since commit ceb1c532ba6220900e61ec7073a9234661efa450:
  Tony Lindgren (1):
Merge branch 'omap_chip_remove_cleanup_3.2' of 
git://git.pwsan.com/linux-2.6 into cleanup

are available in the git repository at:

  git://github.com/tmlind/linux.git dmtimer

Tarun Kanti DebBarma (8):
  ARM: OMAP2+: dmtimer: add device names to flck nodes
  ARM: OMAP1: dmtimer: conversion to platform devices
  ARM: OMAP2+: dmtimer: convert to platform devices
  ARM: OMAP: dmtimer: platform driver
  ARM: OMAP: dmtimer: switch-over to platform device driver
  ARM: OMAP: dmtimer: pm_runtime support
  ARM: OMAP: dmtimer: low-power mode support
  ARM: OMAP: dmtimer: add error handling to export APIs

Tony Lindgren (2):
  ARM: OMAP: Add support for dmtimer v2 ip
  ARM: OMAP: dmtimer: skip reserved timers

 arch/arm/mach-omap1/Makefile   |2 +-
 arch/arm/mach-omap1/timer.c|  173 +++
 arch/arm/mach-omap2/clock2420_data.c   |   48 ++
 arch/arm/mach-omap2/clock2430_data.c   |   48 ++
 arch/arm/mach-omap2/clock3xxx_data.c   |   36 ++
 arch/arm/mach-omap2/clock44xx_data.c   |   33 ++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |   22 +
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |   22 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   27 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |   22 +
 arch/arm/mach-omap2/timer.c|  194 +++-
 arch/arm/plat-omap/dmtimer.c   |  713 
 arch/arm/plat-omap/include/plat/dmtimer.h  |  233 +++---
 13 files changed, 1185 insertions(+), 388 deletions(-)
 create mode 100644 arch/arm/mach-omap1/timer.c
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] OMAP: Few sparse/bug fixes and clean-up for 3.2

[Tony Lindgren]

* Santosh Shilimkar santosh.shilim...@ti.com [110924 00:48]:
 Tony,
 
 Please pull few OMAP sparse/bug fixes and clean-up for 3.2 

Thanks I'll pull these into l3 branch for v3.2 merge window and
merge them into l-o master.

Tony

 
 Thnaks,
 Santosh
 
 The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb:
 
   Linux 3.1-rc6 (2011-09-12 14:02:02 -0700)
 
 are available in the git repository at:
   git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3_2/omap_misc
 
 Santosh Shilimkar (1):
   OMAP4: Fix the emif and dmm virtual mapping
 
 Todd Poynor (2):
   OMAP: Improve register access in L3 Error handler.
   OMAP: Fix a BUG in l3 error handler.
 
 sricharan (3):
   OMAP: Fix indentation issues in l3 error handler.
   OMAP: Fix sparse warnings in l3 error handler.
   OMAP: Print Initiator name for l3 custom error.
 
  arch/arm/mach-omap2/omap_l3_noc.c|  130 ++--
  arch/arm/mach-omap2/omap_l3_noc.h|  224 
 +++---
  arch/arm/mach-omap2/omap_l3_smx.c|   91 +++---
  arch/arm/mach-omap2/omap_l3_smx.h|  164 
  arch/arm/plat-omap/include/plat/io.h |4 +-
  5 files changed, 322 insertions(+), 291 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

Re: [PATCH v2 2/6] OMAP4: Clock: round_rate and recalc functions for DPLL_ABE

[Turquette, Mike]

On Tue, Sep 27, 2011 at 11:59 PM, Paul Walmsley p...@pwsan.com wrote:
 Hi Jon and Mike,

 On Fri, 16 Sep 2011, Jon Hunter wrote:

 From: Mike Turquette mturque...@ti.com

 OMAP4 DPLL_ABE can enable a 4X multipler on top of the normal MN multipler
 and divider. This is achieved by setting CM_CLKMODE_DPLL_ABE.DPLL_REGM4XEN
 bit in CKGEN module of CM1. From the OMAP4 TRM:

 Fdpll = Fref x 2 x (4 x M/(N+1)) in case REGM4XEN bit field is set (only
 applicable to DPLL_ABE).

 Add new round_rate() and recalc() functions for OMAP4, that check the
 setting of REGM4XEN bit and handle this appropriately. The new functions
 are a simple wrapper on top of the existing omap2_dpll_round_rate() and
 omap2_dpll_get_rate() functions to handle the REGM4XEN bit.

 The REGM4XEN bit is only implemented for the ABE DPLL on OMAP4 and so
 only dpll_abe_ck uses omap4_dpll_regm4xen_round_rate() and
 omap4_dpll_regm4xen_recalc() functions.

 Signed-off-by: Mike Turquette mturque...@ti.com
 Tested-by: Jon Hunter jon-hun...@ti.com

 Some changes have been made to this patch here, to fix a few minor bugs in
 error paths and to add documentation and Jon's Signed-off-by: (since he's
 in the submittal chain).

 Care to review and send any comments?  Otherwise, I plan to queue this
 revised version for 3.2.

Your changes to the patch look good.

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

Re: [PATCH v3 3/6] OMAP3+: use DPLL's round_rate when setting rate

[Turquette, Mike]

On Wed, Sep 28, 2011 at 12:02 AM, Paul Walmsley p...@pwsan.com wrote:
 Hi,

 On Fri, 16 Sep 2011, Jon Hunter wrote:

 From: Mike Turquette mturque...@ti.com

 omap3_noncore_dpll_set_rate uses omap2_dpll_round_rate explicitly.  Instead
 use the struct clk pointer's round_rate function to allow for DPLL's with
 special needs.

 Also the rounded rate can differ from target rate, so to better reflect
 reality set clk-rate equal to the rounded rate when setting DPLL frequency.
 This avoids issues where the DPLL frequency is slightly different than what
 debugfs clock tree reports using the old target rate.

 An example of both of these needs is DPLL_ABE on OMAP4 which can have a 4x
 multiplier on top of the usual MN dividers depending on register settings.
 This requires a special round_rate function that might yield a rate
 different from the initial target.

 Signed-off-by: Mike Turquette mturque...@ti.com
 Signed-off-by: Jon Hunter jon-hun...@ti.com

 The two separate changes in this patch have been separated out into two
 patches - both included below.  Please let me know if you have any
 comments; otherwise, I'll queue for 3.2.

The split patches look good to me.  I have another patch which does a
similar thing (converts omap2_get_dpll_rate use to clk-recalc) which
fixes yet more bugs that plague DPLL_ABE.  Will send across shortly;
hopefully can make it into 3.2?

Regards,
Mike
--
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 0/3] Add support for TI814X processor series

[Hemant Pedanekar]

This patch set adds support for DM814x/AM387x device series having Cortex-A8
MPU.

The technical documents are available from following link:

http://focus.ti.com/docs/prod/folders/print/tms320dm8148.html

This series is referred in code as TI814X.

Since these devices share similar architecture as TI816X devices, existing
TI816X code is updated to accomodate TI814X support. The code shared across
TI816X and TI814X devices is updated with TI81XX/ti81xx prefix as applicable,
while maintaining cpu_is_ti816x() and cpu_is_ti814x() to distinguish specific
execution differences.

Changes since v2:
1) Incorporate Tony's suggestion about moving ti8168_evm_map_io() to
   arch/arm/mach-omap2/common.c to keep common across TI81XX.
2) Keeping single board file (board-ti81xxevm.c) for TI816X and TI814X EVMs

Changes since v1:
1) Rebased and updated after Paul's CHIP_IS removal changes
2) Removed call to omap2_init_common_devices() as per Kevin's comment

Hemant Pedanekar (3):
  ARM: OMAP: TI81XX: Prepare for addition of TI814X support
  ARM: OMAP: TI814X: Add cpu type macros and detection support
  ARM: OMAP: TI814X: Create board support and enable build for TI8148
EVM

 arch/arm/mach-omap2/Kconfig|   11 +--
 arch/arm/mach-omap2/Makefile   |3 +-
 .../{board-ti8168evm.c = board-ti81xxevm.c}   |   34 +++-
 arch/arm/mach-omap2/clock.c|2 +-
 arch/arm/mach-omap2/clock.h|2 +-
 arch/arm/mach-omap2/clock3xxx_data.c   |5 ++-
 arch/arm/mach-omap2/common.c   |   28 ++--
 arch/arm/mach-omap2/control.h  |8 ++--
 arch/arm/mach-omap2/id.c   |   30 +++--
 arch/arm/mach-omap2/include/mach/debug-macro.S |   12 +++---
 arch/arm/mach-omap2/include/mach/entry-macro.S |4 +-
 arch/arm/mach-omap2/io.c   |   12 +++---
 arch/arm/mach-omap2/irq.c  |2 +-
 arch/arm/mach-omap2/opp2xxx.h  |2 +-
 arch/arm/mach-omap2/serial.c   |6 ++--
 arch/arm/plat-omap/include/plat/clkdev_omap.h  |1 +
 arch/arm/plat-omap/include/plat/clock.h|3 +-
 arch/arm/plat-omap/include/plat/common.h   |5 ++-
 arch/arm/plat-omap/include/plat/cpu.h  |   22 +
 arch/arm/plat-omap/include/plat/hardware.h |2 +-
 arch/arm/plat-omap/include/plat/io.h   |6 ++--
 arch/arm/plat-omap/include/plat/irqs.h |2 +-
 arch/arm/plat-omap/include/plat/serial.h   |   14 
 .../plat-omap/include/plat/{ti816x.h = ti81xx.h}  |   18 +-
 arch/arm/plat-omap/include/plat/uncompress.h   |   11 --
 arch/arm/plat-omap/io.c|2 +-
 26 files changed, 158 insertions(+), 89 deletions(-)
 rename arch/arm/mach-omap2/{board-ti8168evm.c = board-ti81xxevm.c} (60%)
 rename arch/arm/plat-omap/include/plat/{ti816x.h = ti81xx.h} (60%)

-- 
1.7.3.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 v3 1/3] ARM: OMAP: TI81XX: Prepare for addition of TI814X support

[Hemant Pedanekar]

This patch updates existing macros, functions used for TI816X, to enable
addition of other SoCs belonging to TI81XX family (e.g., TI814X).

The approach taken is to use TI81XX/ti81xx for code/data going to be common
across all TI81XX devices.

cpu_is_ti81xx() is introduced to handle code common across TI81XX devices.

In addition, ti8168_evm_map_io() is now replaced with ti81xx_map_io() and moved
in mach-omap2/common.c as same will be used for TI814X and is not board
specific.

Signed-off-by: Hemant Pedanekar hema...@ti.com
---
 arch/arm/mach-omap2/Kconfig|6 ++--
 arch/arm/mach-omap2/board-ti8168evm.c  |   12 ++--
 arch/arm/mach-omap2/clock3xxx_data.c   |2 +-
 arch/arm/mach-omap2/common.c   |   28 
 arch/arm/mach-omap2/control.h  |8 +++---
 arch/arm/mach-omap2/id.c   |8 +++---
 arch/arm/mach-omap2/include/mach/debug-macro.S |   12 
 arch/arm/mach-omap2/include/mach/entry-macro.S |4 +-
 arch/arm/mach-omap2/io.c   |   12 
 arch/arm/mach-omap2/irq.c  |2 +-
 arch/arm/mach-omap2/serial.c   |6 ++--
 arch/arm/plat-omap/include/plat/common.h   |5 ++-
 arch/arm/plat-omap/include/plat/cpu.h  |   13 +
 arch/arm/plat-omap/include/plat/hardware.h |2 +-
 arch/arm/plat-omap/include/plat/io.h   |6 ++--
 arch/arm/plat-omap/include/plat/irqs.h |2 +-
 arch/arm/plat-omap/include/plat/serial.h   |   14 +-
 .../plat-omap/include/plat/{ti816x.h = ti81xx.h}  |   18 ++--
 arch/arm/plat-omap/include/plat/uncompress.h   |8 +++---
 arch/arm/plat-omap/io.c|2 +-
 20 files changed, 92 insertions(+), 78 deletions(-)
 rename arch/arm/plat-omap/include/plat/{ti816x.h = ti81xx.h} (60%)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 7edf802..a3b9227 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -73,8 +73,8 @@ config SOC_OMAP3430
default y
select ARCH_OMAP_OTG
 
-config SOC_OMAPTI816X
-   bool TI816X support
+config SOC_OMAPTI81XX
+   bool TI81XX support
depends on ARCH_OMAP3
default y
 
@@ -313,7 +313,7 @@ config MACH_OMAP_3630SDP
 
 config MACH_TI8168EVM
bool TI8168 Evaluation Module
-   depends on SOC_OMAPTI816X
+   depends on SOC_OMAPTI81XX
default y
 
 config MACH_OMAP_4430SDP
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c 
b/arch/arm/mach-omap2/board-ti8168evm.c
index e26c79c..7935fc9 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -35,18 +35,12 @@ static void __init ti8168_evm_init(void)
omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
 }
 
-static void __init ti8168_evm_map_io(void)
-{
-   omap2_set_globals_ti816x();
-   omapti816x_map_common_io();
-}
-
 MACHINE_START(TI8168EVM, ti8168evm)
/* Maintainer: Texas Instruments */
.atag_offset= 0x100,
-   .map_io = ti8168_evm_map_io,
-   .init_early = ti816x_init_early,
-   .init_irq   = ti816x_init_irq,
+   .map_io = ti81xx_map_io,
+   .init_early = ti81xx_init_early,
+   .init_irq   = ti81xx_init_irq,
.timer  = omap3_timer,
.init_machine   = ti8168_evm_init,
 MACHINE_END
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index 65dd363..74cc7ce 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3612,7 +3612,7 @@ int __init omap3xxx_clk_init(void)
 * Lock DPLL5 -- here only until other device init code can
 * handle this
 */
-   if (!cpu_is_ti816x()  (omap_rev() = OMAP3430_REV_ES2_0))
+   if (!cpu_is_ti81xx()  (omap_rev() = OMAP3430_REV_ES2_0))
omap3_clk_lock_dpll5();
 
/* Avoid sleeping during omap3_core_dpll_m2_set_rate() */
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 3f20cbb..2ce8e2b 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -101,23 +101,29 @@ void __init omap3_map_io(void)
 
 /*
  * Adjust TAP register base such that omap3_check_revision accesses the correct
- * TI816X register for checking device ID (it adds 0x204 to tap base while
- * TI816X DEVICE ID register is at offset 0x600 from control base).
+ * TI81XX register for checking device ID (it adds 0x204 to tap base while
+ * TI81XX DEVICE ID register is at offset 0x600 from control base).
  */
-#define TI816X_TAP_BASE(TI816X_CTRL_BASE + \
-   TI816X_CONTROL_DEVICE_ID - 0x204)
+#define TI81XX_TAP_BASE(TI81XX_CTRL_BASE + \
+   TI81XX_CONTROL_DEVICE_ID 

[PATCH v3 2/3] ARM: OMAP: TI814X: Add cpu type macros and detection support

[Hemant Pedanekar]

This patch adds cpu type, macros for identification of TI814X device.

Note that following update to common OMAP data structures is made:

cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence struct
clksel_rate.flags, struct prcm_config.flags and cpu_mask are changed to u16 from
u8.

Signed-off-by: Hemant Pedanekar hema...@ti.com
---
 arch/arm/mach-omap2/clock.c   |2 +-
 arch/arm/mach-omap2/clock.h   |2 +-
 arch/arm/mach-omap2/clock3xxx_data.c  |3 +++
 arch/arm/mach-omap2/id.c  |   22 ++
 arch/arm/mach-omap2/opp2xxx.h |2 +-
 arch/arm/plat-omap/include/plat/clkdev_omap.h |1 +
 arch/arm/plat-omap/include/plat/clock.h   |3 ++-
 arch/arm/plat-omap/include/plat/cpu.h |9 +
 8 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 1f3481f..f57ed5b 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -35,7 +35,7 @@
 #include cm-regbits-24xx.h
 #include cm-regbits-34xx.h
 
-u8 cpu_mask;
+u16 cpu_mask;
 
 /*
  * clkdm_control: if true, then when a clock is enabled in the
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 48ac568..687d3d3 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -130,7 +130,7 @@ void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
   const char *core_ck_name,
   const char *mpu_ck_name);
 
-extern u8 cpu_mask;
+extern u16 cpu_mask;
 
 extern const struct clkops clkops_omap2_dflt_wait;
 extern const struct clkops clkops_dummy;
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c 
b/arch/arm/mach-omap2/clock3xxx_data.c
index 74cc7ce..230ff88 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3529,6 +3529,9 @@ int __init omap3xxx_clk_init(void)
} else if (cpu_is_ti816x()) {
cpu_mask = RATE_IN_TI816X;
cpu_clkflg = CK_TI816X;
+   } else if (cpu_is_ti814x()) {
+   cpu_mask = RATE_IN_TI814X;
+   cpu_clkflg = CK_TI814X;
} else if (cpu_is_omap34xx()) {
if (omap_rev() == OMAP3430_REV_ES1_0) {
cpu_mask = RATE_IN_3430ES1;
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index ab2f417..f07faa9 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -337,6 +337,26 @@ static void __init omap3_check_revision(const char 
**cpu_rev)
break;
}
break;
+   case 0xb8f2:
+   switch (rev) {
+   case 0:
+   /* FALLTHROUGH */
+   case 1:
+   omap_revision = TI8148_REV_ES1_0;
+   *cpu_rev = 1.0;
+   break;
+   case 2:
+   omap_revision = TI8148_REV_ES2_0;
+   *cpu_rev = 2.0;
+   break;
+   case 3:
+   /* FALLTHROUGH */
+   default:
+   omap_revision = TI8148_REV_ES2_1;
+   *cpu_rev = 2.1;
+   break;
+   }
+   break;
default:
/* Unknown default to latest silicon rev as default */
omap_revision = OMAP3630_REV_ES1_2;
@@ -429,6 +449,8 @@ static void __init omap3_cpuinfo(const char *cpu_rev)
cpu_name = (omap3_has_sgx()) ? AM3517 : AM3505;
} else if (cpu_is_ti816x()) {
cpu_name = TI816X;
+   } else if (cpu_is_ti814x()) {
+   cpu_name = TI814X;
} else if (omap3_has_iva()  omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
cpu_name = OMAP3430/3530;
diff --git a/arch/arm/mach-omap2/opp2xxx.h b/arch/arm/mach-omap2/opp2xxx.h
index 8affc66..8fae534 100644
--- a/arch/arm/mach-omap2/opp2xxx.h
+++ b/arch/arm/mach-omap2/opp2xxx.h
@@ -51,7 +51,7 @@ struct prcm_config {
unsigned long cm_clksel2_pll;   /* dpllx1 or x2 out */
unsigned long cm_clksel_mdm;/* modem dividers 2430 only */
unsigned long base_sdrc_rfr;/* base refresh timing for a set */
-   unsigned char flags;
+   unsigned short flags;
 };
 
 
diff --git a/arch/arm/plat-omap/include/plat/clkdev_omap.h 
b/arch/arm/plat-omap/include/plat/clkdev_omap.h
index 387a963..3c50ec8 100644
--- a/arch/arm/plat-omap/include/plat/clkdev_omap.h
+++ b/arch/arm/plat-omap/include/plat/clkdev_omap.h
@@ -40,6 +40,7 @@ struct omap_clk {
 #define CK_443X(1  11)
 #define CK_TI816X  (1  12)
 #define CK_446X(1  13)
+#define CK_TI814X  (1  14)
 
 
 #define CK_34XX(CK_3430ES1 | CK_3430ES2PLUS)
diff --git a/arch/arm/plat-omap/include/plat/clock.h 

[PATCH v3 3/3] ARM: OMAP: TI814X: Create board support and enable build for TI8148 EVM

[Hemant Pedanekar]

This patch adds minimal support and build configuration for TI8148 EVM. Also
adds support for low level debugging on UART1 console on the EVM.

Note that existing TI8168 EVM file (board-ti8168evm.c) is updated with machine
info for TI8148 EVM and renamed as board-ti81xxevm.c.

Signed-off-by: Hemant Pedanekar hema...@ti.com
---
 arch/arm/mach-omap2/Kconfig|5 
 arch/arm/mach-omap2/Makefile   |3 +-
 .../{board-ti8168evm.c = board-ti81xxevm.c}   |   22 ++-
 arch/arm/plat-omap/include/plat/uncompress.h   |3 ++
 4 files changed, 26 insertions(+), 7 deletions(-)
 rename arch/arm/mach-omap2/{board-ti8168evm.c = board-ti81xxevm.c} (66%)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index a3b9227..cc4f213 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -316,6 +316,11 @@ config MACH_TI8168EVM
depends on SOC_OMAPTI81XX
default y
 
+config MACH_TI8148EVM
+   bool TI8148 Evaluation Module
+   depends on SOC_OMAPTI81XX
+   default y
+
 config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5ee4cd6..1dc2c6b 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -239,7 +239,8 @@ obj-$(CONFIG_MACH_OMAP3517EVM)  += 
board-am3517evm.o \
 obj-$(CONFIG_MACH_CRANEBOARD)  += board-am3517crane.o
 
 obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
-obj-$(CONFIG_MACH_TI8168EVM)   += board-ti8168evm.o
+obj-$(CONFIG_MACH_TI8168EVM)   += board-ti81xxevm.o
+obj-$(CONFIG_MACH_TI8148EVM)   += board-ti81xxevm.o
 
 # Platform specific device init code
 
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c 
b/arch/arm/mach-omap2/board-ti81xxevm.c
similarity index 66%
rename from arch/arm/mach-omap2/board-ti8168evm.c
rename to arch/arm/mach-omap2/board-ti81xxevm.c
index 7935fc9..b858921 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti81xxevm.c
@@ -1,5 +1,5 @@
 /*
- * Code for TI8168 EVM.
+ * Code for TI8168/TI8148 EVM.
  *
  * Copyright (C) 2010 Texas Instruments, Inc. - http://www.ti.com/
  *
@@ -24,15 +24,15 @@
 #include plat/board.h
 #include plat/common.h
 
-static struct omap_board_config_kernel ti8168_evm_config[] __initdata = {
+static struct omap_board_config_kernel ti81xx_evm_config[] __initdata = {
 };
 
-static void __init ti8168_evm_init(void)
+static void __init ti81xx_evm_init(void)
 {
omap_serial_init();
omap_sdrc_init(NULL, NULL);
-   omap_board_config = ti8168_evm_config;
-   omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
+   omap_board_config = ti81xx_evm_config;
+   omap_board_config_size = ARRAY_SIZE(ti81xx_evm_config);
 }
 
 MACHINE_START(TI8168EVM, ti8168evm)
@@ -42,5 +42,15 @@ MACHINE_START(TI8168EVM, ti8168evm)
.init_early = ti81xx_init_early,
.init_irq   = ti81xx_init_irq,
.timer  = omap3_timer,
-   .init_machine   = ti8168_evm_init,
+   .init_machine   = ti81xx_evm_init,
+MACHINE_END
+
+MACHINE_START(TI8148EVM, ti8148evm)
+   /* Maintainer: Texas Instruments */
+   .atag_offset= 0x100,
+   .map_io = ti81xx_map_io,
+   .init_early = ti81xx_init_early,
+   .init_irq   = ti81xx_init_irq,
+   .timer  = omap3_timer,
+   .init_machine   = ti81xx_evm_init,
 MACHINE_END
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index 40336ad..8d052e7 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -175,6 +175,9 @@ static inline void __arch_decomp_setup(unsigned long 
arch_id)
/* TI8168 base boards using UART3 */
DEBUG_LL_TI81XX(3, ti8168evm);
 
+   /* TI8148 base boards using UART1 */
+   DEBUG_LL_TI81XX(1, ti8148evm);
+
} while (0);
 }
 
-- 
1.7.3.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] leds-class: change back LEDS_CLASS to tristate instead of bool

[Bryan Wu]

Hiya,

Any comments and need I do anything to improve this patch?

Thanks,
-Bryan

On Tue, Sep 27, 2011 at 4:50 PM, Bryan Wu bryan...@canonical.com wrote:
 LEDS_CLASS is required by leds and trigger drivers, but we can build it as
 module.  So change this option back as tristate and treak the help message
 as well.

 LEDS_TRIGGERS depends on LEDS_CLASSS, which should be tristate.  So set it
 as tristate too and update header files as well.

 Change those ifdefs to take care of module configuration.

 Signed-off-by: Bryan Wu bryan...@canonical.com
 ---
  arch/arm/mach-omap1/board-ams-delta.c |    4 ++--
  drivers/leds/Kconfig                  |    9 ++---
  drivers/leds/led-class.c              |    8 
  drivers/leds/leds.h                   |    2 +-
  drivers/mmc/host/au1xmmc.c            |    6 +++---
  drivers/power/power_supply.h          |    2 +-
  include/linux/leds.h                  |    7 ---
  include/linux/mmc/host.h              |    2 +-
  include/linux/power_supply.h          |    2 +-
  9 files changed, 23 insertions(+), 19 deletions(-)

 diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
 b/arch/arm/mach-omap1/board-ams-delta.c
 index b2572f7..fd28696 100644
 --- a/arch/arm/mach-omap1/board-ams-delta.c
 +++ b/arch/arm/mach-omap1/board-ams-delta.c
 @@ -241,7 +241,7 @@ static struct i2c_board_info 
 ams_delta_camera_board_info[] = {
        },
  };

 -#ifdef CONFIG_LEDS_TRIGGERS
 +#if defined(CONFIG_LEDS_TRIGGERS) || defined(CONFIG_LEDS_TRIGGERS_MODULE)
  DEFINE_LED_TRIGGER(ams_delta_camera_led_trigger);

  static int ams_delta_camera_power(struct device *dev, int power)
 @@ -320,7 +320,7 @@ static void __init ams_delta_init(void)

        omap1_usb_init(ams_delta_usb_config);
        omap1_set_camera_info(ams_delta_camera_platform_data);
 -#ifdef CONFIG_LEDS_TRIGGERS
 +#if defined(CONFIG_LEDS_TRIGGERS) || defined(CONFIG_LEDS_TRIGGERS_MODULE)
        led_trigger_register_simple(ams_delta_camera,
                        ams_delta_camera_led_trigger);
  #endif
 diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
 index ff203a4..c30233e 100644
 --- a/drivers/leds/Kconfig
 +++ b/drivers/leds/Kconfig
 @@ -17,10 +17,13 @@ menuconfig NEW_LEDS
  if NEW_LEDS

  config LEDS_CLASS
 -       bool LED Class Support
 +       tristate LED Class Support
        help
          This option enables the led sysfs class in /sys/class/leds.  You'll
 -         need this to do anything useful with LEDs.  If unsure, say N.
 +         need this to do anything useful with LEDs.  If unsure, say M.
 +
 +         Note: don't disable it as N, because plenty of led and trigger 
 drivers
 +         are using this option.

  comment LED drivers

 @@ -388,7 +391,7 @@ config LEDS_RENESAS_TPU
          Brightness control is supported but hardware blinking is not.

  config LEDS_TRIGGERS
 -       bool LED Trigger support
 +       tristate LED Trigger support
        depends on LEDS_CLASS
        help
          This option enables trigger support for the leds class.
 diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
 index dc3d3d8..1f54cb0 100644
 --- a/drivers/leds/led-class.c
 +++ b/drivers/leds/led-class.c
 @@ -75,7 +75,7 @@ static ssize_t led_max_brightness_show(struct device *dev,
  static struct device_attribute led_class_attrs[] = {
        __ATTR(brightness, 0644, led_brightness_show, led_brightness_store),
        __ATTR(max_brightness, 0444, led_max_brightness_show, NULL),
 -#ifdef CONFIG_LEDS_TRIGGERS
 +#if defined(CONFIG_LEDS_TRIGGERS) || defined(CONFIG_LEDS_TRIGGERS_MODULE)
        __ATTR(trigger, 0644, led_trigger_show, led_trigger_store),
  #endif
        __ATTR_NULL,
 @@ -209,7 +209,7 @@ int led_classdev_register(struct device *parent, struct 
 led_classdev *led_cdev)
        if (IS_ERR(led_cdev-dev))
                return PTR_ERR(led_cdev-dev);

 -#ifdef CONFIG_LEDS_TRIGGERS
 +#if defined(CONFIG_LEDS_TRIGGERS) || defined(CONFIG_LEDS_TRIGGERS_MODULE)
        init_rwsem(led_cdev-trigger_lock);
  #endif
        /* add to the list of leds */
 @@ -226,7 +226,7 @@ int led_classdev_register(struct device *parent, struct 
 led_classdev *led_cdev)
        led_cdev-blink_timer.function = led_timer_function;
        led_cdev-blink_timer.data = (unsigned long)led_cdev;

 -#ifdef CONFIG_LEDS_TRIGGERS
 +#if defined(CONFIG_LEDS_TRIGGERS) || defined(CONFIG_LEDS_TRIGGERS_MODULE)
        led_trigger_set_default(led_cdev);
  #endif

 @@ -245,7 +245,7 @@ EXPORT_SYMBOL_GPL(led_classdev_register);
  */
  void led_classdev_unregister(struct led_classdev *led_cdev)
  {
 -#ifdef CONFIG_LEDS_TRIGGERS
 +#if defined(CONFIG_LEDS_TRIGGERS) || defined(CONFIG_LEDS_TRIGGERS_MODULE)
        down_write(led_cdev-trigger_lock);
        if (led_cdev-trigger)
                led_trigger_set(led_cdev, NULL);
 diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
 index e77c7f8..53b59b7 100644
 --- a/drivers/leds/leds.h
 +++ b/drivers/leds/leds.h
 @@ -35,7 +35,7 @@ static inline int led_get_brightness(struct 

Re: [PATCH v2 1/6] OMAP4: Add missing clock divider for OCP_ABE_ICLK

[Paul Walmsley]

On Fri, 16 Sep 2011, Jon Hunter wrote:

 From: Jon Hunter jon-hun...@ti.com
 
 The parent clock of the OCP_ABE_ICLK is the AESS_FCLK and the
 parent clock of the AESS_FCLK is the ABE_FCLK...
 
 ABE_FCLK -- AESS_FCLK -- OCP_ABE_ICLK
 
 The AESS_FCLK and OCP_ABE_ICLK clocks both have dividers which
 determine their operational frequency. However, the dividers for
 the AESS_FCLK and OCP_ABE_ICLK are controlled via a single bit,
 which is the CM1_ABE_AESS_CLKCTRL[24] bit. When this bit is set to
 0, the AESS_FCLK divider is 1 and the OCP_ABE_ICLK divider is 2.
 Similarly, when this bit is set to 1, the AESS_FCLK divider is 2
 and the OCP_ABE_ICLK is 1.
 
 The above relationship between the AESS_FCLK and OCP_ABE_ICLK
 dividers ensure that the OCP_ABE_ICLK clock is always half the
 frequency of the ABE_CLK...
 
 OCP_ABE_ICLK = ABE_FCLK/2
 
 The divider for the OCP_ABE_ICLK is currently missing so add a
 divider that will ensure the OCP_ABE_ICLK frequency is always half
 the ABE_FCLK frequency.
 
 Signed-off-by: Jon Hunter jon-hun...@ti.com

Thanks, queued for 3.2.


- 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

RE: [PATCH v4 1/5] OMAP_VOUT: Fix check in reqbuf for buf_size allocation

[Hiremath, Vaibhav]

 -Original Message-
 From: Taneja, Archit
 Sent: Wednesday, September 28, 2011 8:19 PM
 To: Hiremath, Vaibhav
 Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux-
 me...@vger.kernel.org; Taneja, Archit
 Subject: [PATCH v4 1/5] OMAP_VOUT: Fix check in reqbuf for buf_size
 allocation
 
 The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf prevent
 requesting a larger size buffer than what is allocated at kernel boot
 during
 omap_vout_probe.
 
 In omap_vout_buffer_setup callback API, the requested size is compared
 with
 vout-buffer_size, this isn't correct as vout-buffer_size is later set to
 the
 size requested in reqbuf. When the video device is opened the next time,
 this
 check will prevent us to allocate a buffer which is larger than what we
 requested
 the last time.
 
 Don't use vout-buffer_size, always check with the parameters
 video1_bufsize
 or video2_bufsize.
 
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/media/video/omap/omap_vout.c |6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/media/video/omap/omap_vout.c
 b/drivers/media/video/omap/omap_vout.c
 index d9e64f3..e64a83c 100644
 --- a/drivers/media/video/omap/omap_vout.c
 +++ b/drivers/media/video/omap/omap_vout.c
 @@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct
 videobuf_queue *q, unsigned int *count,
   u32 phy_addr = 0, virt_addr = 0;
   struct omap_vout_device *vout = q-priv_data;
   struct omapvideo_info *ovid = vout-vid_info;
 + int vid_max_buf_size;
 
   if (!vout)
   return -EINVAL;
 
 + vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize :
 + video2_bufsize;
 +
   if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
   return -EINVAL;
 
 @@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct
 videobuf_queue *q, unsigned int *count,
   video1_numbuffers : video2_numbuffers;
 
   /* Check the size of the buffer */
 - if (*size  vout-buffer_size) {
 + if (*size  vid_max_buf_size) {
   v4l2_err(vout-vid_dev-v4l2_dev,
   buffer allocation mismatch [%u] [%u]\n,
   *size, vout-buffer_size);

Acked-by: Vaibhav Hiremath hvaib...@ti.com

Thanks,
Vaibhav


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

Re: [PATCH v4 3/5] OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr

[Semwal, Sumit]

On Wed, Sep 28, 2011 at 8:19 PM, Archit Taneja arc...@ti.com wrote:
 Currently, in omap_vout_isr(), if the panel type is DPI, and if we
 get either VSYNC or VSYNC2 interrupts, we proceed ahead to set the
 current buffers state to VIDEOBUF_DONE and prepare to display the
 next frame in the queue.

 On OMAP4, because we have 2 LCD managers, the panel type itself is not
 sufficient to tell if we have received the correct irq, i.e, we shouldn't
 proceed ahead if we get a VSYNC interrupt for LCD2 manager, or a VSYNC2
 interrupt for LCD manager.

 Fix this by correlating LCD manager to VSYNC interrupt and LCD2 manager
 to VSYNC2 interrupt.

 Signed-off-by: Archit Taneja arc...@ti.com
Reviewed-by: Sumit Semwal sumit.sem...@ti.com
snip
--
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