date:20110405

Hi,

On Tue, Apr 05, 2011 at 02:10:53PM -0400, Alan Stern wrote:
> On Mon, 4 Apr 2011, Greg KH wrote:
> 
> > As I have seen this tangentally mentioned already a few times
> > publically, I figured it warranted it's own announcement now.
> > 
> > Linux has lost a great developer with the passing of David Brownell
> > recently and he will be greatly missed.
> 
> David made contributions to a large number of areas in the Linux
> kernel.  Even a quick look through MAINTAINERS will show that he worked
> on USB controllers (OHCI, EHCI, OMAP and others), USB gadgets, USB
> networking, and SPI.  He was influential in the core USB design (the
> HCD "glue" layer and the scatter-gather library) and the development of
> Power Management (system sleep and the USB PM implementation).  His
> designs were elegant and his code was always a pleasure to read.
> 
> He also was a big help to me personally, assisting in my initial entry
> to USB core development.  And he was the first person I met at the
> first Linux conference I attended.  I too will miss him.

I guess many of us have similar experience with Dave. He also helped me
a lot when I first started doing Linux development. I learned a lot from
him and will miss him a lot. His teachings, I will always carry with me.

Thanks Dave for all your help. Rest in Peace, my friend.

-- 
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 1/2 v2] OMAP2/3: hwmod: fix the i2c-reset timeout during bootup

2011-04-05 Thread Kevin Hilman

"Avinash.H.M"  writes:

> The i2c module has a special reset sequence. The sequence is
> - Disable the I2C.
> - Write to SOFTRESET bit.
> - Enable the I2C.
> - Poll on the RESETDONE bit.
> This sequence must be followed for i2c reset in omap2, omap3. The sequence is
> implemented as a function and the i2c_class is updated with the correct
> 'reset' pointer.
>
> Cc: Rajendra Nayak 
> Cc: Paul Walmsley 
> Cc: Benoit Cousson 
> Cc: Kevin Hilman 
> Signed-off-by: Avinash.H.M 

[...]

> +
> +/**
> + * omap_i2c_reset- reset the omap i2c module.
> + * @oh: struct omap_hwmod *
> + *
> + * The i2c moudle in omap2, omap3 had a special sequence to reset. The
> + * sequence is:
> + * - Disable the I2C.
> + * - Write to SOFTRESET bit.
> + * - Enable the I2C.
> + * - Poll on the RESETDONE bit.
> + * The sequence is implemented in below function. This is called for 2420,
> + * 2430 and omap3.
> + */
> +int omap_i2c_reset(struct omap_hwmod *oh)
> +{
> + u32 v;
> + int c = 0;
> +
> + /* Disable I2C */
> + v = omap_hwmod_read(oh, I2C_CON_OFFSET);
> + v = v & ~I2C_EN;
> + omap_hwmod_write(v, oh, I2C_CON_OFFSET);
> +
> + /* Write to the SOFTRESET bit */
> + v = oh->_sysc_cache;
> + v |= (0x1 << oh->class->sysc->sysc_fields->srst_shift);
> +
> + oh->_sysc_cache = v;
> + omap_hwmod_write(v, oh, oh->class->sysc->sysc_offs);

Direct SYSCONFIG access isn't right here.   This should go through
omap_hwmod.

What is probably needed is exposing _ocp_softreset to device code
via something like omap_hwmod_ocp_softreset() and calling that here.

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: mourning the loss of David Brownell

2011-04-05 Thread Bill Gatliff

Guys:


David Brownell unknowingly inspired me to get involved in Linux as a
profession.  I saw him as an individual working successfully on Free
and Open Software, and have made an effort to emulate his success for
over a decade now.

I deeply regret never taking the time to meet and thank him in person.


b.g.
-- 
Bill Gatliff
b...@billgatliff.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: [RFC][PATCH 1/3] OMAP PM: Seggregate Voltage layer parameters

2011-04-05 Thread Kevin Hilman

Vishwanath Sripathy  writes:

[...]

> Yes..I am planning to remove these parameters being exposed to board file
> and keep only minimal things (like oscillator ramp and ramp down time) in
> boaord file. We should be able calculate these parameters based on these
> generic parameters.

[...]

> Yes..I am coming up with a more generic way to provide set up latencies.

Great!  Thanks.

For now, please base on my pm-wip/voltdm_b branch.  If you're feeling
adventurous, I've started some VP cleanup/restructure in my
pm-wip/voltdm_c branch as well.

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: mourning the loss of David Brownell

2011-04-05 Thread Alan Stern

On Mon, 4 Apr 2011, Greg KH wrote:

> As I have seen this tangentally mentioned already a few times
> publically, I figured it warranted it's own announcement now.
> 
> Linux has lost a great developer with the passing of David Brownell
> recently and he will be greatly missed.

David made contributions to a large number of areas in the Linux
kernel.  Even a quick look through MAINTAINERS will show that he worked
on USB controllers (OHCI, EHCI, OMAP and others), USB gadgets, USB
networking, and SPI.  He was influential in the core USB design (the
HCD "glue" layer and the scatter-gather library) and the development of
Power Management (system sleep and the USB PM implementation).  His
designs were elegant and his code was always a pleasure to read.

He also was a big help to me personally, assisting in my initial entry
to USB core development.  And he was the first person I met at the
first Linux conference I attended.  I too will miss him.

Alan Stern

PS: A photo of David taken at the 2008 Linux Kernel Summit is available
here:

http://www.google.com/imgres?imgurl=http://farm4.static.flickr.com/3004/2949819475_98cbfc48b7.jpg&imgrefurl=http://www.flickr.com/photos/13825348%40N03/sets/72157608741347102/detail/&usg=__HjzUpixk_ITqzSnIhvUuWqdjQ_c=&h=500&w=333&sz=70&hl=en&start=0&zoom=1&tbnid=pixlWzZ4wUo1RM:&tbnh=132&tbnw=114&ei=w1mbTdXsCoO6sAOHp-j9Aw&prev=/search%3Fq%3Ddavid%2Bbrownell%26hl%3Den%26sa%3DX%26biw%3D1024%26bih%3D712%26tbm%3Disch%26prmd%3Divnso0%2C89&itbs=1&iact=hc&vpx=258&vpy=263&dur=7360&hovh=275&hovw=183&tx=85&ty=295&oei=w1mbTdXsCoO6sAOHp-j9Aw&page=1&ndsp=23&ved=1t:429,r:12,s:0&biw=1024&bih=712

--
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] usb: musb: omap2430: fix build failure

2011-04-05 Thread Johan Hovold

Fix build failure introduced by commit
7acc6197b76edd0b932a7cbcc6cfad0a8a87f026 (usb: musb: Idle path retention
and offmode support for OMAP3) when building without gadget
support.

  CC  drivers/usb/musb/omap2430.o
drivers/usb/musb/omap2430.c: In function ‘musb_otg_notifications’:
drivers/usb/musb/omap2430.c:262: error: ‘struct musb’ has no member named 
‘gadget_driver’

Signed-off-by: Johan Hovold 
---
 drivers/usb/musb/omap2430.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 25cb8b0..57a27fa 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -259,9 +259,10 @@ static int musb_otg_notifications(struct notifier_block 
*nb,
case USB_EVENT_VBUS:
DBG(4, "VBUS Connect\n");
 
+#ifdef CONFIG_USB_GADGET_MUSB_HDRC
if (musb->gadget_driver)
pm_runtime_get_sync(musb->controller);
-
+#endif
otg_init(musb->xceiv);
break;
 
-- 
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] arm: omap: introduce OMAP MCOP board file

2011-04-05 Thread Tony Lindgren

* Russell King - ARM Linux  [110405 02:48]:
> 
> I'd suggest holding fire on new stuff.
> 
> We *absolutely* *must* show that we're taking Linus' complaint seriously
> and make headway towards consolidating some of the code.  I don't see that
> activity as optional.

I agree.
 
> I've now made the decision (as I mentioned I may do in the thread) that
> for the next merge window I'm only taking consolidations and bug fixes
> through my tree, and I encourage everyone else to do the same.  At the
> moment, I'm planning for this up until the next merge window, but if
> sufficient progress hasn't been done, I'll extend it thereafter.

OK
 
> In other words, no new platform code and no new platform class code.
> 
> The longer it takes to get the consolidation effort producing results, the
> longer we will have to keep the restriction in place, and the more painful
> it'll be for people who want to have their platforms merged.
> 
> So I hope *no* one is thinking "this isn't my problem, someone else will
> solve it" - if you're thinking that then we're doomed.

Yes we need more people to pitch in to the consolidation process,
so everybody please help where possible.

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

[PATCH 2/2 v2] OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup.

2011-04-05 Thread Avinash.H.M

GPIO module expects the debounce clocks to be enabled during reset. It doesn't
reset properly and timeouts are seen, if this clock isn't enabled during
reset. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flags to the GPIO HWMODs, with
which the debounce clocks are enabled during reset.

Cc: Rajendra Nayak 
Cc: Paul Walmsley 
Cc: Benoit Cousson 
Cc: Kevin Hilman 
Signed-off-by: Avinash.H.M 
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |4 
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |5 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |6 ++
 3 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 82ff5f7..e0bda0a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1640,6 +1640,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio1_slaves[] 
= {
 
 static struct omap_hwmod omap2420_gpio1_hwmod = {
.name   = "gpio1",
+   .flags  = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs   = omap242x_gpio1_irqs,
.mpu_irqs_cnt   = ARRAY_SIZE(omap242x_gpio1_irqs),
.main_clk   = "gpios_fck",
@@ -1670,6 +1671,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio2_slaves[] 
= {
 
 static struct omap_hwmod omap2420_gpio2_hwmod = {
.name   = "gpio2",
+   .flags  = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs   = omap242x_gpio2_irqs,
.mpu_irqs_cnt   = ARRAY_SIZE(omap242x_gpio2_irqs),
.main_clk   = "gpios_fck",
@@ -1700,6 +1702,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio3_slaves[] 
= {
 
 static struct omap_hwmod omap2420_gpio3_hwmod = {
.name   = "gpio3",
+   .flags  = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs   = omap242x_gpio3_irqs,
.mpu_irqs_cnt   = ARRAY_SIZE(omap242x_gpio3_irqs),
.main_clk   = "gpios_fck",
@@ -1730,6 +1733,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio4_slaves[] 
= {
 
 static struct omap_hwmod omap2420_gpio4_hwmod = {
.name   = "gpio4",
+   .flags  = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs   = omap242x_gpio4_irqs,
.mpu_irqs_cnt   = ARRAY_SIZE(omap242x_gpio4_irqs),
.main_clk   = "gpios_fck",
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index ce292f0..99cd7bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1743,6 +1743,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio1_slaves[] 
= {
 
 static struct omap_hwmod omap2430_gpio1_hwmod = {
.name   = "gpio1",
+   .flags  = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs   = omap243x_gpio1_irqs,
.mpu_irqs_cnt   = ARRAY_SIZE(omap243x_gpio1_irqs),
.main_clk   = "gpios_fck",
@@ -1773,6 +1774,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio2_slaves[] 
= {
 
 static struct omap_hwmod omap2430_gpio2_hwmod = {
.name   = "gpio2",
+   .flags  = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs   = omap243x_gpio2_irqs,
.mpu_irqs_cnt   = ARRAY_SIZE(omap243x_gpio2_irqs),
.main_clk   = "gpios_fck",
@@ -1803,6 +1805,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio3_slaves[] 
= {
 
 static struct omap_hwmod omap2430_gpio3_hwmod = {
.name   = "gpio3",
+   .flags  = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs   = omap243x_gpio3_irqs,
.mpu_irqs_cnt   = ARRAY_SIZE(omap243x_gpio3_irqs),
.main_clk   = "gpios_fck",
@@ -1833,6 +1836,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio4_slaves[] 
= {
 
 static struct omap_hwmod omap2430_gpio4_hwmod = {
.name   = "gpio4",
+   .flags  = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs   = omap243x_gpio4_irqs,
.mpu_irqs_cnt   = ARRAY_SIZE(omap243x_gpio4_irqs),
.main_clk   = "gpios_fck",
@@ -1863,6 +1867,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio5_slaves[] 
= {
 
 static struct omap_hwmod omap2430_gpio5_hwmod = {
.name   = "gpio5",
+   .flags  = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs   = omap243x_gpio5_irqs,
.mpu_irqs_cnt   = ARRAY_SIZE(omap243x_gpio5_irqs),
.main_clk   = "gpio5_fck",
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index c74f972..7552b2f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -2142,6 +2142,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_gpio1_slaves[] 
= {
 
 static struct omap_hwmod omap3xxx_gpio1_hwmod = {
.name   = "gpio1",
+   .flags  = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs   = omap3xxx_gpio1_irqs,
.mpu_irqs_cnt   = ARRAY_

[PATCH 0/2 v2] OMAP2/3: fix the i2c,gpio reset timeouts during boot.

2011-04-05 Thread Avinash.H.M

Hi ,

The patches solve the reset timeouts seen in i2c and gpio modules while
booting omap2 and omap3.

version: v2
* For discussion on v1, please refer 
http://www.spinics.net/lists/linux-omap/msg49483.html
* changes from v1:
- moved i2c specific things from hwmod files to i2c files.
- fixed comments from Paul.

Baseline:
The patches are based on 
* git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
* master branch.
* v2.6.39-rc1 commit (0ce790e)

Testing:
* build tested omap2plus_defconfig for warnings and errors. none introduced.
* boot tested on 2430. 
* tested for 'core off' in suspend resume on 3430 sdp. core off counters
  increment after suspend resume. Core off works with below commands,

echo 1 > /debug/pm_debug/enable_off_mode
echo mem > /sys/power/state
cat /debug/pm_debug/count | grep ^core

Dependencies:
* need patch "OMAP2+: hwmod data: Set hwmod flags to only allow 16-bit
  accesses to i2c" from Andry Green for accessing i2c_sysc. Without this even
  with this patch, we will see i2c reset timeouts.

br ,
- Avinash

---

Avinash.H.M (2):
  OMAP2/3: hwmod: fix the i2c-reset timeout during bootup
  OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup.

 arch/arm/mach-omap2/i2c.c  |   58 
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |5 ++
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 +++
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |7 +++
 arch/arm/plat-omap/include/plat/i2c.h  |3 +
 5 files changed, 79 insertions(+), 0 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 1/2 v2] OMAP2/3: hwmod: fix the i2c-reset timeout during bootup

2011-04-05 Thread Avinash.H.M

The i2c module has a special reset sequence. The sequence is
- Disable the I2C.
- Write to SOFTRESET bit.
- Enable the I2C.
- Poll on the RESETDONE bit.
This sequence must be followed for i2c reset in omap2, omap3. The sequence is
implemented as a function and the i2c_class is updated with the correct
'reset' pointer.

Cc: Rajendra Nayak 
Cc: Paul Walmsley 
Cc: Benoit Cousson 
Cc: Kevin Hilman 
Signed-off-by: Avinash.H.M 
---
 arch/arm/mach-omap2/i2c.c  |   58 
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 +
 arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 +
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 +
 arch/arm/plat-omap/include/plat/i2c.h  |3 +
 5 files changed, 64 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/i2c.c b/arch/arm/mach-omap2/i2c.c
index 79c478c..67c7957 100644
--- a/arch/arm/mach-omap2/i2c.c
+++ b/arch/arm/mach-omap2/i2c.c
@@ -21,9 +21,16 @@
 
 #include 
 #include 
+#include 
 
 #include "mux.h"
 
+/* In register I2C_CON, Bit 15 is the I2C enable bit */
+#define I2C_EN BIT(15)
+#define I2C_CON_OFFSET 0x24
+/* Maximum microseconds to wait for OMAP module to softreset */
+#define MAX_MODULE_SOFTRESET_WAIT  1
+
 void __init omap2_i2c_mux_pins(int bus_id)
 {
char mux_name[sizeof("i2c2_scl.i2c2_scl")];
@@ -37,3 +44,54 @@ void __init omap2_i2c_mux_pins(int bus_id)
sprintf(mux_name, "i2c%i_sda.i2c%i_sda", bus_id, bus_id);
omap_mux_init_signal(mux_name, OMAP_PIN_INPUT);
 }
+
+/**
+ * omap_i2c_reset- reset the omap i2c module.
+ * @oh: struct omap_hwmod *
+ *
+ * The i2c moudle in omap2, omap3 had a special sequence to reset. The
+ * sequence is:
+ * - Disable the I2C.
+ * - Write to SOFTRESET bit.
+ * - Enable the I2C.
+ * - Poll on the RESETDONE bit.
+ * The sequence is implemented in below function. This is called for 2420,
+ * 2430 and omap3.
+ */
+int omap_i2c_reset(struct omap_hwmod *oh)
+{
+   u32 v;
+   int c = 0;
+
+   /* Disable I2C */
+   v = omap_hwmod_read(oh, I2C_CON_OFFSET);
+   v = v & ~I2C_EN;
+   omap_hwmod_write(v, oh, I2C_CON_OFFSET);
+
+   /* Write to the SOFTRESET bit */
+   v = oh->_sysc_cache;
+   v |= (0x1 << oh->class->sysc->sysc_fields->srst_shift);
+
+   oh->_sysc_cache = v;
+   omap_hwmod_write(v, oh, oh->class->sysc->sysc_offs);
+
+   /* Enable I2C */
+   v = omap_hwmod_read(oh, I2C_CON_OFFSET);
+   v |= I2C_EN;
+   omap_hwmod_write(v, oh, I2C_CON_OFFSET);
+
+   /* Poll on RESETDONE bit */
+   omap_test_timeout((omap_hwmod_read(oh,
+   oh->class->sysc->syss_offs)
+   & SYSS_RESETDONE_MASK),
+   MAX_MODULE_SOFTRESET_WAIT, c);
+
+   if (c == MAX_MODULE_SOFTRESET_WAIT)
+   pr_warning("%s: %s: softreset failed (waited %d usec)\n",
+   __func__, oh->name, MAX_MODULE_SOFTRESET_WAIT);
+   else
+   pr_debug("%s: %s: softreset in %d usec\n", __func__,
+   oh->name, c);
+
+   return 0;
+}
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 8eb3ce1..82ff5f7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1447,6 +1447,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {
 static struct omap_hwmod_class i2c_class = {
.name   = "i2c",
.sysc   = &i2c_sysc,
+   .reset  = &omap_i2c_reset,
 };
 
 static struct omap_i2c_dev_attr i2c_dev_attr;
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c 
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index a860fb5..ce292f0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1524,6 +1524,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {
 static struct omap_hwmod_class i2c_class = {
.name   = "i2c",
.sysc   = &i2c_sysc,
+   .reset  = &omap_i2c_reset,
 };
 
 static struct omap_i2c_dev_attr i2c_dev_attr = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index b98e2df..c74f972 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1460,6 +1460,7 @@ static struct omap_hwmod omap3xxx_uart4_hwmod = {
 static struct omap_hwmod_class i2c_class = {
.name = "i2c",
.sysc = &i2c_sysc,
+   .reset = &omap_i2c_reset,
 };
 
 /*
diff --git a/arch/arm/plat-omap/include/plat/i2c.h 
b/arch/arm/plat-omap/include/plat/i2c.h
index 878d632..749306f 100644
--- a/arch/arm/plat-omap/include/plat/i2c.h
+++ b/arch/arm/plat-omap/include/plat/i2c.h
@@ -22,6 +22,7 @@
 #define __ASM__ARCH_OMAP_I2C_H
 
 #include 
+#include 
 
 #if defined(CONFIG_I2C_OMAP) || defined(CONFIG_I2C_OMAP_MODULE)
 extern int omap_r

Re: [PATCH 0/4] iommu: Prevent oops in iommu_get() and while arch_iommu is in use

2011-04-05 Thread Sakari Ailus

Laurent Pinchart wrote:
> Hi Sakari,

Hi Laurent,

> On Tuesday 05 April 2011 11:03:21 Sakari Ailus wrote:
>> Laurent Pinchart wrote:
> 
> [snip]
> 
>>> Let me try to summarize the issue and the requirements.
>>>
>>> IOMMU support on OMAP platforms uses an OMAP-specific implementation,
>>> divided into 3 layers:
>>>
>>> - the IOVMM layer (arch/arm/plat-omap/iovmm.ko) deals with virtual
>>> address space management
>>> - the IOMMU layer (arch/arm/plat-omap/iommu.ko) controls the IOMMU
>>> hardware, and deals with TLB and page tables
>>> - the IOMMU platform-specific layers (arch/arm/mach-omap2/iommu2.ko)
>>> handles the IOMMU implementation variants between various OMAP platforms
>>>
>>> Drivers depend on iovmm and iommu. They must not depend on iommu2.ko.
>>>
>>> The only existing platform-specific IOMMU layer is iommu2.ko for OMAP2+.
>>> An OMAP1 implementation is being worked on, and other implementations
>>> might be needed for OMAP4 and/or OMAP5.
>>>
>>> Building a kernel image that will run on all OMAP platforms isn't
>>> possible at the moment but is being worked on. Such a kernel image will
>>> need to include all the platform-specific IOMMU layers, and the correct
>>> layer will need to be selected at runtime.
>>>
>>> If a driver tries to request and use an IOMMU before the
>>> platform-specific IOMMU layer is initialized, the request will fail. We
>>> thus need to ensure that the correct platform-specific IOMMU layer is
>>> initialized before IOMMU users are initialized.
>>
>> Thanks for the summary!
>>
>>> I can see several ways to fix the problem.
>>>
>>> - Turn the iommu and iommu2 options from tristate to bool. The downside
>>> is that the kernel image will get slightly bigger.
>>>
>>> - Merge the iommu and iommu2 modules together. This will temporarily fix
>>> the problem, but a proper solution will still be needed for the OMAP1
>>> (and maybe OMAP5) IOMMU layers.
>>>
>>> - Auto-load the correct platform-specific IOMMU module based on
>>> modaliases created from the platform name. The platform-specific modules
>>> will need to check at runtime whether they support the current platform
>>> to avoid conflicts when several of those modules will be compiled in.
>>
>> I'd like to add option to auto-load the module based on the type of the
>> IOMMU.
> 
> Could you elaborate on that ?

The module name could be specified somewhere, but the question is then
where. There needs to be iommu name -> module name mapping somewhere
(can be distributed) and it must not be the end user of the iommu framework.

>> This is more generic since there could be several types of IOMMUs in
>> the same system, although in the scope of OMAPs we are likely to have always
>> just one.
>>
>> Extending the scope of the OMAP IOMMU would be nice, or to add functionality
>> to the current generic layer which doesn't do much at the moment.
>>
>> This is probably a bigger task and something to consider in the future,
>> though.
>>
>> I'd go with the third option you suggested since this one
>>
>> 1) solves the problem,
>> 2) doesn't appear to create new ones,
>> 3) doesn't add anything that would be incompatible with probable future
>> developments and
>> 4) is easy to implement.
>>
>>
>> Btw. There should be no devices created by the board code on those platforms
>> either. Wrong iommu device drivers may be loaded in addition, but this does
>> no more harm than compiling those in to the kernel in the first option.
>>
>>> The second solution is the simplest, but it's a workaround. On the other
>>> hand, it's hard to design a proper solution before we know the
>>> requirements of the other OMAP platforms that have an IOMMU incompatible
>>> with iommu2.ko, so it might be better to postpone the decision until we
>>> have a real use case.
>>
>> There are two options that I can think of: either a SoC-wide IOMMU
>> implementation or
> 
> That's one option, unless you

I sent that too early. :-P

... a device which does have an IOMMU, connected to e.g. a bus that uses
the IOMMU framework. This way there could be different types of IOMMUs
in a system.

But we don't have that yet.

So either we have just one or multiple types or IOMMUs in the system.

>> The problem of loading that module exists right now so it should have
>> some kind of solution. If we go with the second option right now it does
>> push this to direction I don't like too much. The next implementer has
>> to solve the problem instead, and it might be easier to implement this
>> right now, as we are all up-to-date with the issue.
> 
> We only have iommu2.ko at the moment. I've heard about an iommu1.ko being 
> worked on, but I don't have more information. We don't know whether the OMAP5 
> will be able to use the same IOMMU implementation. Without more information, 
> I'm quite reluctant to design and implement a generic solution that will end 
> up being useless because we missed information in the design stage.

For the scope of OMAPs the first and third solutions would

Re: [GIT PULL] omap changes for v2.6.39 merge window

2011-04-05 Thread Catalin Marinas

On Tue, 2011-04-05 at 08:45 +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 05, 2011 at 12:10:24PM +0530, Santosh Shilimkar wrote:
> > The only issue I see is the clock-events implemented using
> > local timers capabilities in low power modes. The local timers
> > won't be able wakeup CPU from DORMANT or OFF state and hence
> > you will need an additional wakeup capable clock-event
> > working together with the local timers using clock-notifiers.
> 
> So yet again, we have something that almost works but doesn't, and
> we're going to have to have board-specific hacks to work around this.
> 
> This makes the architected timers totally *pointless*.

The point of architected timers is that you now get fast access to a
stable clock source with a fixed frequency that doesn't change with
cpufreq. You can also configure the clock source to be accessible from
user space (via another kuser helper) so that you have a fast
gettimeofday implementation (useful in the graphics world). Virtual
counters are another advantage.

The architecture doesn't say much about the power domains, so
implementations are allowed to vary here. Of course it would have been
better if it did but this doesn't make the architected timers totally
pointless (compare them with the A9 timers).

-- 
Catalin

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

Re: [PATCH] ARM: type casts update_sched_clock cyc_to_sched_clock cyc_to_fixed_sched_clock

On Tue, Apr 05, 2011 at 01:12:57PM +0200, Uwe Kleine-König wrote:
> ah, ok, makes sense and actually is consistent with my book.
> (After knowing what I search I found it. The rules are:
> 
>  - A signed type of rank less than int
>-> int
>  - An unsigned type of rank less than int,
>all of whose values can be represented in type int
>-> int
>  - An unsigned type of rank less than int,
>all of whose values cannot be represented in type int
>-> unsigned int
> ).
> 
> So the maximal correct variant is (u32)(int)~0U or alternatively
> (u32)(-1), right?

If you really want to be pedantic, (u32)~0UL, as we assume that longs
will always be equal or larger than 32-bit throughout the kernel.  The
u32 cast then becomes truncating in itself.

But... in the interests of avoiding churn, we know the current code
works, we know that its safe should we chose to change the function
argument to be a u64, so lets leave it as-is.  We know the only time
that it'd break is if an 'int' becomes less than 32-bit, which we
aren't going to see on ARM any time soon.
--
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] arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC

2011-04-05 Thread Alexander Holler

Without msecure beeing high it isn't possible to set (or start)
the RTC.

Tested with a BeagleBoard C4.

Signed-off-by: Alexander Holler 
---
 arch/arm/mach-omap2/board-omap3beagle.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index 46d814a..ebe3a7e 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -628,6 +628,9 @@ static void __init omap3_beagle_init(void)
usb_ehci_init(&ehci_pdata);
omap3beagle_flash_init();
 
+   /* Ensure msecure is mux'd to be able to set the RTC. */
+   omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
-- 
1.7.3.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 1/4] OMAP2+: clockdomain: Add an api to read idle mode

2011-04-05 Thread Santosh Shilimkar


On 4/5/2011 6:14 PM, Rajendra Nayak wrote:

Add a clockdomain api to check if hardware supervised
idle transitions are enabled on a clockdomain.

Signed-off-by: Rajendra Nayak
---
  arch/arm/mach-omap2/clockdomain.c |   21 +
  arch/arm/mach-omap2/clockdomain.h |3 +++
  2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index ab87854..1de6def 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -795,6 +795,27 @@ void clkdm_deny_idle(struct clockdomain *clkdm)
arch_clkdm->clkdm_deny_idle(clkdm);
  }

+/**
+ * clkdm_is_idle - Check if the clkdm hwsup/autoidle is enabled
+ * @clkdm: struct clockdomain *
+ *
+ * Returns true if the clockdomain is in hardware-supervised
+ * idle mode, or 0 otherwise.
+ *
+ */
+int clkdm_is_idle(struct clockdomain *clkdm)

>
Name of the API not seems to fit correctly.
Shoule it be something like "clkdm_is_in_hwsup"?
--
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: RX-51: Platform support for lp5523

Hi,

On Tue, Apr 05, 2011 at 03:59:32PM +0300, Ameya Palande wrote:
> On 04/05/2011 03:38 PM, ext Felipe Balbi wrote:
> >Hi,
> >
> >On Tue, Apr 05, 2011 at 03:34:08PM +0300, Ameya Palande wrote:
> >>>Exactly, adding a new feature. Let me put it this way: which bug or
> >>>regression are you fixing with this patch ?
> >>
> >>I never claimed that it is fixing a bug/regression ;)
> >
> >but you want this go into the RC cycle, which is strictly bug fixing and
> >regression fixing :-)
> 
> How about following commits since v2.6.39-rc1?
> 
> 54a93b6 ARM: pxa: PalmZ72: Add OV9640 camera support
> 54d5710 ARM: PXA: Z2: Add default triggers for LEDs
> 7780c80 arm: mach-kirkwood: add led in sheevaplug-setup.c
> 14fb20c ARM: mx53_loco: Add GPIO Keypad support
> 1b6f1e8 ARM: mxs/mx23evk: add mmc device
> 4b2a58a libceph: Create a new key type "ceph"
> 6090912 powerpc: Implement dma_mmap_coherent()
> 57bd35d microblaze: Wire up new syscalls
> beb4727 drm/radeon/kms: Add support for tv-out dongle on G5 9600
> 758f231 drm/radeon/kms: add some new ontario pci ids
> 41c5789 kernel/signal.c: add kernel-doc notation to syscalls
> 9a684e1 Documentation: consolidate leds files to leds/ subdir
> 
> I agree that rc cycle is mostly about bug/regression fixing but there
> are definitely exceptions for borderline cases and I am trying to
> check if this patch is such a case ;)

Like I said: Tony is the final judge here. :-)

But the fact that Russell has already stated the next merge window is
strictly for code consolidation already puts a stop sign in front of
this patch :-) Still, Tony is the final judge.

-- 
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: RX-51: Platform support for lp5523


Hi Felipe,

On 04/05/2011 03:38 PM, ext Felipe Balbi wrote:

Hi,

On Tue, Apr 05, 2011 at 03:34:08PM +0300, Ameya Palande wrote:

Exactly, adding a new feature. Let me put it this way: which bug or
regression are you fixing with this patch ?


I never claimed that it is fixing a bug/regression ;)


but you want this go into the RC cycle, which is strictly bug fixing and
regression fixing :-)


How about following commits since v2.6.39-rc1?

54a93b6 ARM: pxa: PalmZ72: Add OV9640 camera support
54d5710 ARM: PXA: Z2: Add default triggers for LEDs
7780c80 arm: mach-kirkwood: add led in sheevaplug-setup.c
14fb20c ARM: mx53_loco: Add GPIO Keypad support
1b6f1e8 ARM: mxs/mx23evk: add mmc device
4b2a58a libceph: Create a new key type "ceph"
6090912 powerpc: Implement dma_mmap_coherent()
57bd35d microblaze: Wire up new syscalls
beb4727 drm/radeon/kms: Add support for tv-out dongle on G5 9600
758f231 drm/radeon/kms: add some new ontario pci ids
41c5789 kernel/signal.c: add kernel-doc notation to syscalls
9a684e1 Documentation: consolidate leds files to leds/ subdir

I agree that rc cycle is mostly about bug/regression fixing but there 
are definitely exceptions for borderline cases and I am trying to check 
if this patch is such a case ;)


Cheers,
Ameya.
--
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: clockdomain: Follow recommended enable sequence


Hi Paul,

On 4/4/2011 12:17 PM, Paul Walmsley wrote:

On Fri, 1 Apr 2011, Rajendra Nayak wrote:


On 4/1/2011 8:21 PM, Rajendra Nayak wrote:

In omap_hwmod.c:_enable(), what do you think about:

1. saving the current idle mode of the clockdomain,

2. forcing the clockdomain to software-supervised wakeup.

3. enabling clocks and waiting for the module as we currently do, then

4. switching the clockdomain's idle mode back to its original state?

Seems like that would be a reasonable approach for the short term, at
least for drivers that have been converted to PM runtime.


Ok, I'll try and get some RFC patches in these lines soon.


I tried some of what you were suggesting here and it seems to
work well, like you said, for the drivers which are converted
to PM runtime.

Now the issue seems to be, how do we handle the ones which
are *still* using clock framework to enable main clocks and
are yet to be converted to PM runtime.

One such, MMC, is showing me issues on OMAP4 even at boot
and causes a crash.

Its a different thing that some of these drivers which use
direct clock calls are working by fluke on OMAP4 since the
clock framework does not even wait for the modules to become
accessible after the clock enable.

I know the right way seems to be to get all these drivers
converted to PM runtime, but that might take sometime.


One way I am able to get this working (atleast MMC)
is by preventing the clock domain belonging to MMC module
from being programmed into HW_SUP mode.


What programs the OMAP4 clockdomains into hwsup mode in the first place?


This is not yet in mainline, but being done by Santosh's series which
adds OMAP4 low power support in idle and suspend.
http://marc.info/?l=linux-omap&m=130130417927632&w=2


There's no clkdms_setup() as there is in mach-omap2/pm34xx.c.  I guess
maybe this code in mach-omap2/pm.c might do it as a side effect:

switch (sleep_switch) {
case FORCEWAKEUP_SWITCH:
if (pwrdm->pwrdm_clkdms[0]->flags&  CLKDM_CAN_ENABLE_AUTO)
clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
else
clkdm_sleep(pwrdm->pwrdm_clkdms[0]);
break;

If I'm reading this code correctly, it will always force clockdomains that
support hwsup mode into hwsup mode, even if they've been previously
programmed to swsup mode.  That's not right.  This function should leave
the clockdomain's autoidle setting where it was when the function was
entered.  So this needs to be fixed also.


You are right, the code is buggy, I just posted a short series which
should fix this.
http://marc.info/?l=linux-omap&m=130200752115352&w=2




Acceptable hack in the interim while we wait for the MMC driver to be
using PM runtime?


Ideally this should be overridden in the code, not the data, since this
hack is needed due to a software problem, not a hardware problem.  The
clockdomains data should just be a statement of what the hardware
supports.

But given the above bug and the lack of some clkdms_setup() function for
OMAP4, I guess the clockdomains data is the least bad choice for right
now, provided that the patch also:


With Santosh's series which adds the clkdms_setup and my series
to fix the above bug, I should be able to handle this in the code,
rather than hack the clockdomains data.
I will post some patches for that as well.

regards
Rajendra



1. puts a big comment in that data warning about the problem and
explaining why

2. puts a pr_warn() in mach-omap2/pm44xx.c:omap4_pm_init() saying:
"WARNING: OMAP4 power savings limited since MMC driver not converted to
PM runtime"


- Paul


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

[PATCH 4/4] OMAP2+: PM: idle clkdms only if already in idle

The omap_set_pwrdm_state function forces clockdomains
to idle, without checking the existing idle state
programmed, instead based solely on the HW capability
of the clockdomain to support idle.
This is wrong and the clockdomains should be idled
post a state_switch *only* if idle transitions on the
clockdomain were already enabled.

Signed-off-by: Rajendra Nayak 
---
 arch/arm/mach-omap2/pm.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 04b6da7..b1190c4 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -107,6 +107,7 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 
state)
u32 cur_state;
int sleep_switch = -1;
int ret = 0;
+   int hwsup = 0;
 
if (pwrdm == NULL || IS_ERR(pwrdm))
return -EINVAL;
@@ -126,6 +127,7 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 
state)
(pwrdm->flags & PWRDM_HAS_LOWPOWERSTATECHANGE)) {
sleep_switch = LOWPOWERSTATE_SWITCH;
} else {
+   hwsup = clkdm_is_idle(pwrdm->pwrdm_clkdms[0]);
clkdm_wakeup(pwrdm->pwrdm_clkdms[0]);
pwrdm_wait_transition(pwrdm);
sleep_switch = FORCEWAKEUP_SWITCH;
@@ -141,7 +143,7 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 
state)
 
switch (sleep_switch) {
case FORCEWAKEUP_SWITCH:
-   if (pwrdm->pwrdm_clkdms[0]->flags & CLKDM_CAN_ENABLE_AUTO)
+   if (hwsup)
clkdm_allow_idle(pwrdm->pwrdm_clkdms[0]);
else
clkdm_sleep(pwrdm->pwrdm_clkdms[0]);
-- 
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

[PATCH 3/4] OMAP2+: PM: Initialise sleep_switch to a non-valid value

sleep_switch which is initialised to 0 in omap_set_pwrdm_state
happens to be a valid sleep_switch type (FORCEWAKEUP_SWITCH)
which are defined as
#define FORCEWAKEUP_SWITCH  0
#define LOWPOWERSTATE_SWITCH1

This causes the function to wrongly program some clock domains
even when the Powerdomain is in ON state.

Signed-off-by: Rajendra Nayak 
---
 arch/arm/mach-omap2/pm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 30af335..04b6da7 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -105,7 +105,7 @@ static void omap2_init_processor_devices(void)
 int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state)
 {
u32 cur_state;
-   int sleep_switch = 0;
+   int sleep_switch = -1;
int ret = 0;
 
if (pwrdm == NULL || IS_ERR(pwrdm))
-- 
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

[PATCH 0/4] OMAP2+: Fix clockdomain state programming

This series fixes a few issues in the clockdomain
state programming done as part of the omap_set_pwrdm_state()
function.
More details on the issues can be found in the discussions
below
http://marc.info/?l=linux-arm-kernel&m=130189971726452&w=2

Doing this requires adding additional api's in the
clockdomain framework to identify what idle mode a
clockdomain is currently programmed in.
Hence a new api clkdm_is_idle() is also added as
part of this series.

The series is tested on OMAP3-beagle for all low
power states in idle and suspend and also boot
tested on a OMAP4430sdp. Applies on 2.6.39-rc1.

Rajendra Nayak (4):
  OMAP2+: clockdomain: Add an api to read idle mode
  OMAP2+: clockdomain: Add SoC support for clkdm_is_idle
  OMAP2+: PM: Initialise sleep_switch to a non-valid value
  OMAP2+: PM: idle clkdms only if already in idle

 arch/arm/mach-omap2/clockdomain.c  |   21 +
 arch/arm/mach-omap2/clockdomain.h  |3 +++
 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c |   12 
 arch/arm/mach-omap2/clockdomain44xx.c  |7 +++
 arch/arm/mach-omap2/pm.c   |6 --
 5 files changed, 47 insertions(+), 2 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 2/4] OMAP2+: clockdomain: Add SoC support for clkdm_is_idle

Add the SoC specific implemention for clkdm_is_idle
for OMAP2/3 and OMAP4.

Signed-off-by: Rajendra Nayak 
---
 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c |   12 
 arch/arm/mach-omap2/clockdomain44xx.c  |7 +++
 2 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c 
b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
index 48d0db7..3cdf95b 100644
--- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include 
 #include "prm.h"
 #include "prm2xxx_3xxx.h"
@@ -146,6 +147,15 @@ static void omap2_clkdm_deny_idle(struct clockdomain 
*clkdm)
_clkdm_del_autodeps(clkdm);
 }
 
+static int omap2_clkdm_is_idle(struct clockdomain *clkdm)
+{
+   if (!clkdm->clktrctrl_mask)
+   return -EINVAL;
+
+   return omap2_cm_is_clkdm_in_hwsup(clkdm->pwrdm.ptr->prcm_offs,
+   clkdm->clktrctrl_mask);
+}
+
 static void _enable_hwsup(struct clockdomain *clkdm)
 {
if (cpu_is_omap24xx())
@@ -252,6 +262,7 @@ struct clkdm_ops omap2_clkdm_operations = {
.clkdm_wakeup   = omap2_clkdm_wakeup,
.clkdm_allow_idle   = omap2_clkdm_allow_idle,
.clkdm_deny_idle= omap2_clkdm_deny_idle,
+   .clkdm_is_idle  = omap2_clkdm_is_idle,
.clkdm_clk_enable   = omap2_clkdm_clk_enable,
.clkdm_clk_disable  = omap2_clkdm_clk_disable,
 };
@@ -269,6 +280,7 @@ struct clkdm_ops omap3_clkdm_operations = {
.clkdm_wakeup   = omap3_clkdm_wakeup,
.clkdm_allow_idle   = omap3_clkdm_allow_idle,
.clkdm_deny_idle= omap3_clkdm_deny_idle,
+   .clkdm_is_idle  = omap2_clkdm_is_idle,
.clkdm_clk_enable   = omap2_clkdm_clk_enable,
.clkdm_clk_disable  = omap2_clkdm_clk_disable,
 };
diff --git a/arch/arm/mach-omap2/clockdomain44xx.c 
b/arch/arm/mach-omap2/clockdomain44xx.c
index a1a4ecd..4b10727 100644
--- a/arch/arm/mach-omap2/clockdomain44xx.c
+++ b/arch/arm/mach-omap2/clockdomain44xx.c
@@ -93,6 +93,12 @@ static void omap4_clkdm_deny_idle(struct clockdomain *clkdm)
clkdm->cm_inst, clkdm->clkdm_offs);
 }
 
+static int omap4_clkdm_is_idle(struct clockdomain *clkdm)
+{
+   return omap4_cminst_is_clkdm_in_hwsup(clkdm->prcm_partition,
+   clkdm->cm_inst, clkdm->clkdm_offs);
+}
+
 static int omap4_clkdm_clk_enable(struct clockdomain *clkdm)
 {
bool hwsup = false;
@@ -132,6 +138,7 @@ struct clkdm_ops omap4_clkdm_operations = {
.clkdm_wakeup   = omap4_clkdm_wakeup,
.clkdm_allow_idle   = omap4_clkdm_allow_idle,
.clkdm_deny_idle= omap4_clkdm_deny_idle,
+   .clkdm_is_idle  = omap4_clkdm_is_idle,
.clkdm_clk_enable   = omap4_clkdm_clk_enable,
.clkdm_clk_disable  = omap4_clkdm_clk_disable,
 };
-- 
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

[PATCH 1/4] OMAP2+: clockdomain: Add an api to read idle mode

Add a clockdomain api to check if hardware supervised
idle transitions are enabled on a clockdomain.

Signed-off-by: Rajendra Nayak 
---
 arch/arm/mach-omap2/clockdomain.c |   21 +
 arch/arm/mach-omap2/clockdomain.h |3 +++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index ab87854..1de6def 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -795,6 +795,27 @@ void clkdm_deny_idle(struct clockdomain *clkdm)
arch_clkdm->clkdm_deny_idle(clkdm);
 }
 
+/**
+ * clkdm_is_idle - Check if the clkdm hwsup/autoidle is enabled
+ * @clkdm: struct clockdomain *
+ *
+ * Returns true if the clockdomain is in hardware-supervised
+ * idle mode, or 0 otherwise.
+ *
+ */
+int clkdm_is_idle(struct clockdomain *clkdm)
+{
+   if (!clkdm)
+   return -EINVAL;
+
+   if (!arch_clkdm || !arch_clkdm->clkdm_is_idle)
+   return -EINVAL;
+
+   pr_debug("clockdomain: reading idle state for %s\n", clkdm->name);
+
+   return arch_clkdm->clkdm_is_idle(clkdm);
+}
+
 
 /* Clockdomain-to-clock framework interface code */
 
diff --git a/arch/arm/mach-omap2/clockdomain.h 
b/arch/arm/mach-omap2/clockdomain.h
index 85b3dce..2fe3412 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -138,6 +138,7 @@ struct clockdomain {
  * @clkdm_wakeup: Force a clockdomain to wakeup
  * @clkdm_allow_idle: Enable hw supervised idle transitions for clock domain
  * @clkdm_deny_idle: Disable hw supervised idle transitions for clock domain
+ * @clkdm_is_idle: Check if hw supervised idle transitions are enabled
  * @clkdm_clk_enable: Put the clkdm in right state for a clock enable
  * @clkdm_clk_disable: Put the clkdm in right state for a clock disable
  */
@@ -154,6 +155,7 @@ struct clkdm_ops {
int (*clkdm_wakeup)(struct clockdomain *clkdm);
void(*clkdm_allow_idle)(struct clockdomain *clkdm);
void(*clkdm_deny_idle)(struct clockdomain *clkdm);
+   int (*clkdm_is_idle)(struct clockdomain *clkdm);
int (*clkdm_clk_enable)(struct clockdomain *clkdm);
int (*clkdm_clk_disable)(struct clockdomain *clkdm);
 };
@@ -177,6 +179,7 @@ int clkdm_clear_all_sleepdeps(struct clockdomain *clkdm);
 
 void clkdm_allow_idle(struct clockdomain *clkdm);
 void clkdm_deny_idle(struct clockdomain *clkdm);
+int clkdm_is_idle(struct clockdomain *clkdm);
 
 int clkdm_wakeup(struct clockdomain *clkdm);
 int clkdm_sleep(struct clockdomain *clkdm);
-- 
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: RX-51: Platform support for lp5523

Hi,

On Tue, Apr 05, 2011 at 03:34:08PM +0300, Ameya Palande wrote:
> >Exactly, adding a new feature. Let me put it this way: which bug or
> >regression are you fixing with this patch ?
> 
> I never claimed that it is fixing a bug/regression ;)

but you want this go into the RC cycle, which is strictly bug fixing and
regression fixing :-)

> IMHO driver for lp5523 chip is a "new feature" which is already in
> mainline. This patch just enables use of this feature on N900.

enabling the use of that feature on N900 is a new feature for N900 ;-)

-- 
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: RX-51: Platform support for lp5523

On 04/05/2011 03:30 PM, ext Felipe Balbi wrote:

On Tue, Apr 05, 2011 at 03:23:12PM +0300, Ameya Palande wrote:

On 04/05/2011 03:19 PM, ext Felipe Balbi wrote:

On Tue, Apr 05, 2011 at 03:10:41PM +0300, Ameya Palande wrote:

Hi Tony,

On 03/29/2011 10:33 PM, ext Tony Lindgren wrote:

* Sebastian Reichel[110329 11:13]:

On Tue, Mar 29, 2011 at 10:36:47AM -0700, Tony Lindgren wrote:

* Sebastian Reichel[110329 10:26]:

Is there any reason, that the rx51 platform code does not support
the lp5523 chip? The chip driver itself is in the mainline kernel
since 2.6.37-rc2.

Got a patch for that? As always, patches related to blinking leds
have a special high priority here! :)

Ameya Palande has written one, which is available at [0]. I added
him to CC, so that he can comment on mainline inclusion.

OK. Ameya, can you please post it for review for this list with
linux-arm-kernel list Cc'd?

Regards,

Tony

[0]
http://gitorious.org/nokia-n900-kernel/nokia-n900-kernel/commit/54caed7bdc7e9f5aa84fe50f3bc321fc1ef600ad?format=patch

Can we get following patch in for 2.6.39-rc2?
http://marc.info/?l=linux-omap&m=130200500812156&w=2

Tony will say for sure, but I don't consider that a bugfix, so you need
to wait next merge window for that to reach mainline :-

It is not a new feature/driver for sure. We are just enabling support
for a driver (lp5523) on N900 which is already present in mainline.

Exactly, adding a new feature. Let me put it this way: which bug or
regression are you fixing with this patch ?

I never claimed that it is fixing a bug/regression ;)
IMHO driver for lp5523 chip is a "new feature" which is already in
mainline. This patch just enables use of this feature on N900.

Cheers,
Ameya.
--
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: RX-51: Platform support for lp5523

On Tue, Apr 05, 2011 at 03:23:12PM +0300, Ameya Palande wrote:
> On 04/05/2011 03:19 PM, ext Felipe Balbi wrote:
> >On Tue, Apr 05, 2011 at 03:10:41PM +0300, Ameya Palande wrote:
> >>Hi Tony,
> >>
> >>On 03/29/2011 10:33 PM, ext Tony Lindgren wrote:
> >>>* Sebastian Reichel   [110329 11:13]:
> On Tue, Mar 29, 2011 at 10:36:47AM -0700, Tony Lindgren wrote:
> >* Sebastian Reichel   [110329 10:26]:
> >>Is there any reason, that the rx51 platform code does not support
> >>the lp5523 chip? The chip driver itself is in the mainline kernel
> >>since 2.6.37-rc2.
> >
> >Got a patch for that? As always, patches related to blinking leds
> >have a special high priority here! :)
> 
> Ameya Palande has written one, which is available at [0]. I added
> him to CC, so that he can comment on mainline inclusion.
> >>>
> >>>OK. Ameya, can you please post it for review for this list with
> >>>linux-arm-kernel list Cc'd?
> >>>
> >>>Regards,
> >>>
> >>>Tony
> >>>
> [0] 
> http://gitorious.org/nokia-n900-kernel/nokia-n900-kernel/commit/54caed7bdc7e9f5aa84fe50f3bc321fc1ef600ad?format=patch
> >>
> >>Can we get following patch in for 2.6.39-rc2?
> >>http://marc.info/?l=linux-omap&m=130200500812156&w=2
> >
> >Tony will say for sure, but I don't consider that a bugfix, so you need
> >to wait next merge window for that to reach mainline :-
> 
> It is not a new feature/driver for sure. We are just enabling support
> for a driver (lp5523) on N900 which is already present in mainline.

Exactly, adding a new feature. Let me put it this way: which bug or
regression are you fixing with this patch ?

-- 
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: RX-51: Platform support for lp5523

On 04/05/2011 03:19 PM, ext Felipe Balbi wrote:

On Tue, Apr 05, 2011 at 03:10:41PM +0300, Ameya Palande wrote:

Hi Tony,

On 03/29/2011 10:33 PM, ext Tony Lindgren wrote:

* Sebastian Reichel [110329 11:13]:

On Tue, Mar 29, 2011 at 10:36:47AM -0700, Tony Lindgren wrote:

* Sebastian Reichel [110329 10:26]:

Is there any reason, that the rx51 platform code does not support
the lp5523 chip? The chip driver itself is in the mainline kernel
since 2.6.37-rc2.

Got a patch for that? As always, patches related to blinking leds
have a special high priority here! :)

Ameya Palande has written one, which is available at [0]. I added
him to CC, so that he can comment on mainline inclusion.

OK. Ameya, can you please post it for review for this list with
linux-arm-kernel list Cc'd?

Regards,

Tony

[0]
http://gitorious.org/nokia-n900-kernel/nokia-n900-kernel/commit/54caed7bdc7e9f5aa84fe50f3bc321fc1ef600ad?format=patch

Can we get following patch in for 2.6.39-rc2?
http://marc.info/?l=linux-omap&m=130200500812156&w=2

Tony will say for sure, but I don't consider that a bugfix, so you need
to wait next merge window for that to reach mainline :-

It is not a new feature/driver for sure. We are just enabling support
for a driver (lp5523) on N900 which is already present in mainline.

Re: RX-51: Platform support for lp5523

On Tue, Apr 05, 2011 at 03:10:41PM +0300, Ameya Palande wrote:
> Hi Tony,
> 
> On 03/29/2011 10:33 PM, ext Tony Lindgren wrote:
> >* Sebastian Reichel  [110329 11:13]:
> >>On Tue, Mar 29, 2011 at 10:36:47AM -0700, Tony Lindgren wrote:
> >>>* Sebastian Reichel  [110329 10:26]:
> Is there any reason, that the rx51 platform code does not support
> the lp5523 chip? The chip driver itself is in the mainline kernel
> since 2.6.37-rc2.
> >>>
> >>>Got a patch for that? As always, patches related to blinking leds
> >>>have a special high priority here! :)
> >>
> >>Ameya Palande has written one, which is available at [0]. I added
> >>him to CC, so that he can comment on mainline inclusion.
> >
> >OK. Ameya, can you please post it for review for this list with
> >linux-arm-kernel list Cc'd?
> >
> >Regards,
> >
> >Tony
> >
> >>[0] 
> >>http://gitorious.org/nokia-n900-kernel/nokia-n900-kernel/commit/54caed7bdc7e9f5aa84fe50f3bc321fc1ef600ad?format=patch
> 
> Can we get following patch in for 2.6.39-rc2?
> http://marc.info/?l=linux-omap&m=130200500812156&w=2

Tony will say for sure, but I don't consider that a bugfix, so you need
to wait next merge window for that to reach mainline :-

-- 
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: RX-51: Platform support for lp5523


Hi Tony,

On 03/29/2011 10:33 PM, ext Tony Lindgren wrote:

* Sebastian Reichel  [110329 11:13]:

On Tue, Mar 29, 2011 at 10:36:47AM -0700, Tony Lindgren wrote:

* Sebastian Reichel  [110329 10:26]:

Is there any reason, that the rx51 platform code does not support
the lp5523 chip? The chip driver itself is in the mainline kernel
since 2.6.37-rc2.


Got a patch for that? As always, patches related to blinking leds
have a special high priority here! :)


Ameya Palande has written one, which is available at [0]. I added
him to CC, so that he can comment on mainline inclusion.


OK. Ameya, can you please post it for review for this list with
linux-arm-kernel list Cc'd?

Regards,

Tony


[0] 
http://gitorious.org/nokia-n900-kernel/nokia-n900-kernel/commit/54caed7bdc7e9f5aa84fe50f3bc321fc1ef600ad?format=patch


Can we get following patch in for 2.6.39-rc2?
http://marc.info/?l=linux-omap&m=130200500812156&w=2

Cheers,
Ameya.
--
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] omap: rx51: Platform support for lp5523 led chip

On Tue, Apr 05, 2011 at 03:00:11PM +0300, Ameya Palande wrote:
> Hi Felipe,
> 
> On 03/31/2011 06:44 PM, ext Felipe Balbi wrote:
> >On Thu, Mar 31, 2011 at 06:30:32PM +0300, Ameya Palande wrote:
> >>Hi Felipe,
> >>
> >>On 03/31/2011 05:26 PM, ext Felipe Balbi wrote:
> >>>Hi,
> >>>
> >>>On Thu, Mar 31, 2011 at 04:38:12PM +0300, Ameya Palande wrote:
> +static int rx51_lp5523_setup(void)
> +{
> + int err;
> +
> + err = gpio_request_one(RX51_LP5523_CHIP_EN_GPIO, GPIOF_DIR_OUT,
> + "lp5523_enable");
> + if (err<   0) {
> + pr_err("Unable to get lp5523_enable GPIO\n");
> + return err;
> + }
> +
> + return err;
> >>>
> >>>isn't enough to return gpio_request_one(RX51_LP5523_CHIP_EN_GPIO,
> >>>GPIOF_DIR_OUT, "lp5523_enable"); ??
> >>
> >>But then we won't know the failure reason for lp5523_probe()
> >>I would prefer printing an error!
> >
> >see that both gpio_request() and gpio_direction_output() have debugging
> >prints for error cases ;-)
> 
> Any comments about the version 3 of this patch?

looks good to me. Replied with my Reviewed-by tag.

-- 
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: [PATCHv3] omap: rx51: Platform support for lp5523 led chip

On Fri, Apr 01, 2011 at 01:16:12PM +0300, Ameya Palande wrote:
> Signed-off-by: Ameya Palande 
> Signed-off-by: Mathias Nyman 

Reviewed-by: Felipe Balbi 

> ---
>  arch/arm/mach-omap2/board-rx51-peripherals.c |   66 
> ++
>  1 files changed, 66 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c 
> b/arch/arm/mach-omap2/board-rx51-peripherals.c
> index bbcb677..d8ec895 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include <../drivers/staging/iio/light/tsl2563.h>
>  
> @@ -51,6 +52,7 @@
>  #define RX51_WL1251_IRQ_GPIO 42
>  #define RX51_FMTX_RESET_GPIO 163
>  #define RX51_FMTX_IRQ53
> +#define RX51_LP5523_CHIP_EN_GPIO 41
>  
>  /* list all spi devices here */
>  enum {
> @@ -67,6 +69,64 @@ static struct tsl2563_platform_data 
> rx51_tsl2563_platform_data = {
>  };
>  #endif
>  
> +#if defined(CONFIG_LEDS_LP5523) || defined(CONFIG_LEDS_LP5523_MODULE)
> +static struct lp5523_led_config rx51_lp5523_led_config[] = {
> + {
> + .chan_nr= 0,
> + .led_current= 50,
> + }, {
> + .chan_nr= 1,
> + .led_current= 50,
> + }, {
> + .chan_nr= 2,
> + .led_current= 50,
> + }, {
> + .chan_nr= 3,
> + .led_current= 50,
> + }, {
> + .chan_nr= 4,
> + .led_current= 50,
> + }, {
> + .chan_nr= 5,
> + .led_current= 50,
> + }, {
> + .chan_nr= 6,
> + .led_current= 50,
> + }, {
> + .chan_nr= 7,
> + .led_current= 50,
> + }, {
> + .chan_nr= 8,
> + .led_current= 50,
> + }
> +};
> +
> +static int rx51_lp5523_setup(void)
> +{
> + return gpio_request_one(RX51_LP5523_CHIP_EN_GPIO, GPIOF_DIR_OUT,
> + "lp5523_enable");
> +}
> +
> +static void rx51_lp5523_release(void)
> +{
> + gpio_free(RX51_LP5523_CHIP_EN_GPIO);
> +}
> +
> +static void rx51_lp5523_enable(bool state)
> +{
> + gpio_set_value(RX51_LP5523_CHIP_EN_GPIO, !!state);
> +}
> +
> +static struct lp5523_platform_data rx51_lp5523_platform_data = {
> + .led_config = rx51_lp5523_led_config,
> + .num_channels   = ARRAY_SIZE(rx51_lp5523_led_config),
> + .clock_mode = LP5523_CLOCK_AUTO,
> + .setup_resources= rx51_lp5523_setup,
> + .release_resources  = rx51_lp5523_release,
> + .enable = rx51_lp5523_enable,
> +};
> +#endif
> +
>  static struct omap2_mcspi_device_config wl1251_mcspi_config = {
>   .turbo_mode = 0,
>   .single_channel = 1,
> @@ -816,6 +876,12 @@ static struct i2c_board_info __initdata 
> rx51_peripherals_i2c_board_info_2[] = {
>   .platform_data = &rx51_tsl2563_platform_data,
>   },
>  #endif
> +#if defined(CONFIG_LEDS_LP5523) || defined(CONFIG_LEDS_LP5523_MODULE)
> + {
> + I2C_BOARD_INFO("lp5523", 0x32),
> + .platform_data  = &rx51_lp5523_platform_data,
> + },
> +#endif
>   {
>   I2C_BOARD_INFO("tpa6130a2", 0x60),
>   .platform_data = &rx51_tpa6130a2_data,
> -- 
> 1.7.1
> 

-- 
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: [PATCHv2] omap: rx51: Platform support for lp5523 led chip


Hi Felipe,

On 03/31/2011 06:44 PM, ext Felipe Balbi wrote:

On Thu, Mar 31, 2011 at 06:30:32PM +0300, Ameya Palande wrote:

Hi Felipe,

On 03/31/2011 05:26 PM, ext Felipe Balbi wrote:

Hi,

On Thu, Mar 31, 2011 at 04:38:12PM +0300, Ameya Palande wrote:

+static int rx51_lp5523_setup(void)
+{
+   int err;
+
+   err = gpio_request_one(RX51_LP5523_CHIP_EN_GPIO, GPIOF_DIR_OUT,
+   "lp5523_enable");
+   if (err<   0) {
+   pr_err("Unable to get lp5523_enable GPIO\n");
+   return err;
+   }
+
+   return err;


isn't enough to return gpio_request_one(RX51_LP5523_CHIP_EN_GPIO,
GPIOF_DIR_OUT, "lp5523_enable"); ??


But then we won't know the failure reason for lp5523_probe()
I would prefer printing an error!


see that both gpio_request() and gpio_direction_output() have debugging
prints for error cases ;-)


Any comments about the version 3 of this patch?

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

Re: [PATCH 0/4] iommu: Prevent oops in iommu_get() and while arch_iommu is in use

2011-04-05 Thread David Cohen

On Tue, Apr 5, 2011 at 2:23 PM, Laurent Pinchart
 wrote:
> Hi Sakari,

Hi Laurent, Sakari,

>
> On Tuesday 05 April 2011 11:03:21 Sakari Ailus wrote:
>> Laurent Pinchart wrote:
>
> [snip]
>
>> > Let me try to summarize the issue and the requirements.
>> >
>> > IOMMU support on OMAP platforms uses an OMAP-specific implementation,
>> > divided into 3 layers:
>> >
>> > - the IOVMM layer (arch/arm/plat-omap/iovmm.ko) deals with virtual
>> > address space management
>> > - the IOMMU layer (arch/arm/plat-omap/iommu.ko) controls the IOMMU
>> > hardware, and deals with TLB and page tables
>> > - the IOMMU platform-specific layers (arch/arm/mach-omap2/iommu2.ko)
>> > handles the IOMMU implementation variants between various OMAP platforms
>> >
>> > Drivers depend on iovmm and iommu. They must not depend on iommu2.ko.
>> >
>> > The only existing platform-specific IOMMU layer is iommu2.ko for OMAP2+.
>> > An OMAP1 implementation is being worked on, and other implementations
>> > might be needed for OMAP4 and/or OMAP5.
>> >
>> > Building a kernel image that will run on all OMAP platforms isn't
>> > possible at the moment but is being worked on. Such a kernel image will
>> > need to include all the platform-specific IOMMU layers, and the correct
>> > layer will need to be selected at runtime.

That exists for all omap2+.

>> >
>> > If a driver tries to request and use an IOMMU before the
>> > platform-specific IOMMU layer is initialized, the request will fail. We
>> > thus need to ensure that the correct platform-specific IOMMU layer is
>> > initialized before IOMMU users are initialized.
>>
>> Thanks for the summary!

You've done it very well.

>>
>> > I can see several ways to fix the problem.
>> >
>> > - Turn the iommu and iommu2 options from tristate to bool. The downside
>> > is that the kernel image will get slightly bigger.
>> >
>> > - Merge the iommu and iommu2 modules together. This will temporarily fix
>> > the problem, but a proper solution will still be needed for the OMAP1
>> > (and maybe OMAP5) IOMMU layers.
>> >
>> > - Auto-load the correct platform-specific IOMMU module based on
>> > modaliases created from the platform name. The platform-specific modules
>> > will need to check at runtime whether they support the current platform
>> > to avoid conflicts when several of those modules will be compiled in.
>>
>> I'd like to add option to auto-load the module based on the type of the
>> IOMMU.
>
> Could you elaborate on that ?

I think it might be a good solution for near future in order to keep
the driver generic for OMAP. But we need to keep in mind nothing
related to specific implementation should be added to generic IOMMU
layer, so board code could be the right place. In this case I may
agree with the third option from Laurent.

>
>> This is more generic since there could be several types of IOMMUs in
>> the same system, although in the scope of OMAPs we are likely to have always
>> just one.
>>
>> Extending the scope of the OMAP IOMMU would be nice, or to add functionality
>> to the current generic layer which doesn't do much at the moment.
>>
>> This is probably a bigger task and something to consider in the future,
>> though.
>>
>> I'd go with the third option you suggested since this one
>>
>> 1) solves the problem,
>> 2) doesn't appear to create new ones,
>> 3) doesn't add anything that would be incompatible with probable future
>> developments and
>> 4) is easy to implement.
>>
>>
>> Btw. There should be no devices created by the board code on those platforms
>> either. Wrong iommu device drivers may be loaded in addition, but this does
>> no more harm than compiling those in to the kernel in the first option.
>>
>> > The second solution is the simplest, but it's a workaround. On the other
>> > hand, it's hard to design a proper solution before we know the
>> > requirements of the other OMAP platforms that have an IOMMU incompatible
>> > with iommu2.ko, so it might be better to postpone the decision until we
>> > have a real use case.
>>
>> There are two options that I can think of: either a SoC-wide IOMMU
>> implementation or
>
> That's one option, unless you
>
> :-)
>
>> The problem of loading that module exists right now so it should have
>> some kind of solution. If we go with the second option right now it does
>> push this to direction I don't like too much. The next implementer has
>> to solve the problem instead, and it might be easier to implement this
>> right now, as we are all up-to-date with the issue.
>
> We only have iommu2.ko at the moment. I've heard about an iommu1.ko being
> worked on, but I don't have more information. We don't know whether the OMAP5
> will be able to use the same IOMMU implementation. Without more information,
> I'm quite reluctant to design and implement a generic solution that will end
> up being useless because we missed information in the design stage.

One implementation belongs to mach-omap1 and other to mach-omap2. Not
sure if it's a good plan to get t

Re: [PATCH 0/4] iommu: Prevent oops in iommu_get() and while arch_iommu is in use

2011-04-05 Thread Laurent Pinchart

Hi Sakari,

On Tuesday 05 April 2011 11:03:21 Sakari Ailus wrote:
> Laurent Pinchart wrote:

[snip]

> > Let me try to summarize the issue and the requirements.
> > 
> > IOMMU support on OMAP platforms uses an OMAP-specific implementation,
> > divided into 3 layers:
> > 
> > - the IOVMM layer (arch/arm/plat-omap/iovmm.ko) deals with virtual
> > address space management
> > - the IOMMU layer (arch/arm/plat-omap/iommu.ko) controls the IOMMU
> > hardware, and deals with TLB and page tables
> > - the IOMMU platform-specific layers (arch/arm/mach-omap2/iommu2.ko)
> > handles the IOMMU implementation variants between various OMAP platforms
> > 
> > Drivers depend on iovmm and iommu. They must not depend on iommu2.ko.
> > 
> > The only existing platform-specific IOMMU layer is iommu2.ko for OMAP2+.
> > An OMAP1 implementation is being worked on, and other implementations
> > might be needed for OMAP4 and/or OMAP5.
> > 
> > Building a kernel image that will run on all OMAP platforms isn't
> > possible at the moment but is being worked on. Such a kernel image will
> > need to include all the platform-specific IOMMU layers, and the correct
> > layer will need to be selected at runtime.
> > 
> > If a driver tries to request and use an IOMMU before the
> > platform-specific IOMMU layer is initialized, the request will fail. We
> > thus need to ensure that the correct platform-specific IOMMU layer is
> > initialized before IOMMU users are initialized.
> 
> Thanks for the summary!
> 
> > I can see several ways to fix the problem.
> > 
> > - Turn the iommu and iommu2 options from tristate to bool. The downside
> > is that the kernel image will get slightly bigger.
> > 
> > - Merge the iommu and iommu2 modules together. This will temporarily fix
> > the problem, but a proper solution will still be needed for the OMAP1
> > (and maybe OMAP5) IOMMU layers.
> > 
> > - Auto-load the correct platform-specific IOMMU module based on
> > modaliases created from the platform name. The platform-specific modules
> > will need to check at runtime whether they support the current platform
> > to avoid conflicts when several of those modules will be compiled in.
> 
> I'd like to add option to auto-load the module based on the type of the
> IOMMU.

Could you elaborate on that ?

> This is more generic since there could be several types of IOMMUs in
> the same system, although in the scope of OMAPs we are likely to have always
> just one.
>
> Extending the scope of the OMAP IOMMU would be nice, or to add functionality
> to the current generic layer which doesn't do much at the moment.
> 
> This is probably a bigger task and something to consider in the future,
> though.
> 
> I'd go with the third option you suggested since this one
> 
> 1) solves the problem,
> 2) doesn't appear to create new ones,
> 3) doesn't add anything that would be incompatible with probable future
> developments and
> 4) is easy to implement.
> 
> 
> Btw. There should be no devices created by the board code on those platforms
> either. Wrong iommu device drivers may be loaded in addition, but this does
> no more harm than compiling those in to the kernel in the first option.
> 
> > The second solution is the simplest, but it's a workaround. On the other
> > hand, it's hard to design a proper solution before we know the
> > requirements of the other OMAP platforms that have an IOMMU incompatible
> > with iommu2.ko, so it might be better to postpone the decision until we
> > have a real use case.
> 
> There are two options that I can think of: either a SoC-wide IOMMU
> implementation or

That's one option, unless you

:-)

> The problem of loading that module exists right now so it should have
> some kind of solution. If we go with the second option right now it does
> push this to direction I don't like too much. The next implementer has
> to solve the problem instead, and it might be easier to implement this
> right now, as we are all up-to-date with the issue.

We only have iommu2.ko at the moment. I've heard about an iommu1.ko being 
worked on, but I don't have more information. We don't know whether the OMAP5 
will be able to use the same IOMMU implementation. Without more information, 
I'm quite reluctant to design and implement a generic solution that will end 
up being useless because we missed information in the design stage.

-- 
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: [PATCH] ARM: type casts update_sched_clock cyc_to_sched_clock cyc_to_fixed_sched_clock

2011-04-05 Thread Uwe Kleine-König

On Tue, Apr 05, 2011 at 10:01:00AM +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 05, 2011 at 10:31:44AM +0200, Uwe Kleine-König wrote:
> > On Tue, Apr 05, 2011 at 08:56:22AM +0100, Russell King - ARM Linux wrote:
> > > On Tue, Apr 05, 2011 at 09:43:21AM +0200, Jan Weitzel wrote:
> > > > parameter "u32 mask" type cast befor inversion
> > s/befor/before/
> > 
> > > Nak.  I want a 32-bit all ones quantity.
> > > 
> > > unsigned long long vali = (unsigned short)~0;
> > > unsigned long long vall = ~(unsigned short)0;
> > > 
> > BTW, the definiton of vall is equivalent to 
> > 
> > unsigned long long valu = ~(unsigned int)0;
> > 
> > because ~ converts the unsigned short to unsigned int.
> 
> No.  The value gets promoted to int not unsigned int.
> 
> > > compiles to:
> > > 
> > > vali:
> > > .word   65535
> > > .word   0
> > > 
> > > vall:
> > > .word   -1
> > > .word   -1
> > I really wonder about that. If I take a value of 0x (i.e. a 32
> > bit wide int == ~0U) and assign that to an 64-bit unsigned long long I'd
> > expect it to get the value 0xULL, not
> > 0xULL. What's wrong?
> 
> See above.  int not unsigned int.  And it makes a difference:
> 
> unsigned long long vals = ~(int)0;
> unsigned long long valu = ~(unsigned int)0;
> 
> vals:
> .word   -1
> .word   -1
> valu:
> .word   -1
> .word   0
> 
ah, ok, makes sense and actually is consistent with my book.
(After knowing what I search I found it. The rules are:

 - A signed type of rank less than int
   -> int
 - An unsigned type of rank less than int,
   all of whose values can be represented in type int
   -> int
 - An unsigned type of rank less than int,
   all of whose values cannot be represented in type int
   -> unsigned int
).

So the maximal correct variant is (u32)(int)~0U or alternatively
(u32)(-1), right?

Thanks for your answer, best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard

2011-04-05 Thread Avik Sil


On Tuesday 05 April 2011 07:33 AM, Ming Lei wrote:

Hi,

2011/4/5 Avik Sil:

#define OMAP4430_CM_L3INSTR_L3_3_CLKCTRL
OMAP44XX_CM2_REGADDR(OMAP4430_CM2_CORE_INST, 0x0720)
[...]

Should I use those identifier instead?


Yes, seems right, but you need to use the ioremap addresses of the identifiers.

Even after using ioremapped addresses in omap_writel() I'm getting the 
oops. Can you please point me to the location in mainline, where these 
l3 clocks are enabled?


Regards,
Avik

Are there other definitions for the identifiers you have used?


As I said  before, these are not needed for mainline, so I didn't try these.


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] ARM: type casts update_sched_clock cyc_to_sched_clock cyc_to_fixed_sched_clock

2011-04-05 Thread Jan Weitzel

linux-arm-kernel-boun...@lists.infradead.org schrieb am 05.04.2011 
10:31:44:

> Von: Uwe Kleine-König 
> An: Russell King - ARM Linux 
> Kopie: rub...@unipv.it, kgene@samsung.com, 
> eric.y.m...@gmail.com, ben-li...@fluff.org, t...@atomide.com, Jan 
> Weitzel , linux-te...@vger.kernel.org, linux-
> o...@vger.kernel.org, ker...@pengutronix.de, 
> stericsson_nomadik_li...@list.st.com, triv...@kernel.org, 
> ka...@openwrt.org, linux-arm-ker...@lists.infradead.org, k...@pm.waw.pl
> Datum: 05.04.2011 10:33
> Betreff: Re: [PATCH] ARM: type casts update_sched_clock 
> cyc_to_sched_clock cyc_to_fixed_sched_clock
> Gesendet von: linux-arm-kernel-boun...@lists.infradead.org
> 
> On Tue, Apr 05, 2011 at 08:56:22AM +0100, Russell King - ARM Linux 
wrote:
> > On Tue, Apr 05, 2011 at 09:43:21AM +0200, Jan Weitzel wrote:
> > > parameter "u32 mask" type cast befor inversion
> s/befor/before/
> 
> > Nak.  I want a 32-bit all ones quantity.
> > 
> > unsigned long long vali = (unsigned short)~0;
> > unsigned long long vall = ~(unsigned short)0;
> > 
> BTW, the definiton of vall is equivalent to 
> 
>unsigned long long valu = ~(unsigned int)0;
> 
> because ~ converts the unsigned short to unsigned int.
> 
> > compiles to:
> > 
> > vali:
> > .word   65535
> > .word   0
> > 
> > vall:
> > .word   -1
> > .word   -1
> I really wonder about that. If I take a value of 0x (i.e. a 32
> bit wide int == ~0U) and assign that to an 64-bit unsigned long long I'd
> expect it to get the value 0xULL, not
> 0xULL. What's wrong?
> 
> > So moving the ~ to be evaluated after the cast has the effect of 
making
> > the cast pointless, and produces wrong values.  (u32)~0 does the 
32-bit
> My C-Book tells that using ~ on a signed it produces implementation
> defined behaviour. That's what I pointed out to Jan and I guess that's
> the reason why he created the patch.

That's right. I tested it and got for both
static unsigned long long valuica = (unsigned int)~0;
static unsigned long long valuicb = ~(unsigned int)0;

the same:
.word   0x
.word   0x

With unsigned short I see the problem. Sorry for the noise.

Kind regards 
Jan

--
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: rtc-twl: catch22 in 2.6.37 and 2.6.38 when clock was never set

2011-04-05 Thread Alexander Holler


Hello,

Am 04.04.2011 16:29, schrieb Alexander Holler:


it just happened here that the rechargeable backup battery for the RTC
on a TPS65950 run out off power, because of some days while the device
wasn't powered.

Afterwards I couldn't read or set the clock with hwclock using a kernel
2.6.37.n or 2.6.38.n.

I don't have a fix, but I think I've analyzed the problem and can offer
a (bad) workaround.

What happens is the following:

When trying to read or set the clock with hwclock, the driver (rtc-twl)
starts an alarm, but the irq for the alarm will never get called. The
result is that a select in hwclock times out (for both operations, read
or set).

Because I had this clock running before, I've got the idea to try one of
those old OMAP-kernels (2.6.32-angstrom) using the same userland.
And with that kernel I could set the clock.
Using 2.6.37 or 2.6.38 afterwards, hwclock did function again, both read
an set are working.

So it looks like there is a catch22 in kernels >=2.6.37 (I haven't
tested .33-.36):

When the clock was never set, the alarm(-irq) doesn't work, so hwclock
doesn't work, so one can't set the clock.


It turns out that the missing/wrong initialization of the msecure line 
is the problem which disabled setting the clock. After doing that 
through a quick hack, I could set the clock.


I'm using a BeagleBoard C4, but I can't find any msecure initialization 
for other boards too.


What happened with those patches? E.g. those:

http://www.mail-archive.com/linux-omap@vger.kernel.org/msg16125.html

Regards,

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

Re: [PATCH] arm: omap: introduce OMAP MCOP board file

Hi,

On Tue, Apr 05, 2011 at 10:51:19AM +0100, Russell King - ARM Linux wrote:
> > I don't think Linus will like if we add yet another hwmod + clk data
> > file just for MCOP, so we need to re-use what's in tree.
> 
> I'd suggest holding fire on new stuff.
> 
> We *absolutely* *must* show that we're taking Linus' complaint seriously
> and make headway towards consolidating some of the code.  I don't see that
> activity as optional.
> 
> I've now made the decision (as I mentioned I may do in the thread) that
> for the next merge window I'm only taking consolidations and bug fixes
> through my tree, and I encourage everyone else to do the same.  At the
> moment, I'm planning for this up until the next merge window, but if
> sufficient progress hasn't been done, I'll extend it thereafter.
> 
> In other words, no new platform code and no new platform class code.
> 
> The longer it takes to get the consolidation effort producing results, the
> longer we will have to keep the restriction in place, and the more painful
> it'll be for people who want to have their platforms merged.
> 
> So I hope *no* one is thinking "this isn't my problem, someone else will
> solve it" - if you're thinking that then we're doomed.

Ok Russell, we will hold on to this patch and try to help as we can on
the code consolidation effort.

Let's hope to get this sorted out soon as it would be really great for
us to start pre-silicon validation with mainline kernel with little to
no effort needed :-D

-- 
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] arm: omap: introduce OMAP MCOP board file

On Tue, Apr 05, 2011 at 12:36:57PM +0300, Felipe Balbi wrote:
> On Tue, Apr 05, 2011 at 12:32:50PM +0300, Felipe Balbi wrote:
> > From: Michael Fillinger 
> > 
> > MCOP is an FPGA-based Silicon Validation platform
> > which is used to test particular IPs inside OMAP
> > before we have a real ASIC.
> > 
> > Signed-off-by: Michael Fillinger 
> > 
> > [ ba...@ti.com : few cleanups here an there and also
> > removal of some unnecessary code. ]
> > 
> > Signed-off-by: Felipe Balbi 
> 
> I should have RFCed this one, but bear with me for a minute.
> 
> This is just the bare minimum board-file for MCOP, there's still a bunch
> of changes needed to get it actually booting. The attached diff shows
> many of them.
> 
> Now, we don't want to send that patch upstream for obvious reasons and
> we also don't want to add ifdefs to clock data files as that would break
> multi-omap. What do you guys suggest ? How should we handle detection of
> MCOP so that we choose correct HWMODs and clock data files for it ?
> 
> I don't think Linus will like if we add yet another hwmod + clk data
> file just for MCOP, so we need to re-use what's in tree.

I'd suggest holding fire on new stuff.

We *absolutely* *must* show that we're taking Linus' complaint seriously
and make headway towards consolidating some of the code.  I don't see that
activity as optional.

I've now made the decision (as I mentioned I may do in the thread) that
for the next merge window I'm only taking consolidations and bug fixes
through my tree, and I encourage everyone else to do the same.  At the
moment, I'm planning for this up until the next merge window, but if
sufficient progress hasn't been done, I'll extend it thereafter.

In other words, no new platform code and no new platform class code.

The longer it takes to get the consolidation effort producing results, the
longer we will have to keep the restriction in place, and the more painful
it'll be for people who want to have their platforms merged.

So I hope *no* one is thinking "this isn't my problem, someone else will
solve it" - if you're thinking that then we're doomed.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] arm: omap: introduce OMAP MCOP board file

2011-04-05 Thread Fillinger, Michael



On Tue, Apr 05, 2011 at 11:37 AM +0300, Felipe Balbi wrote:
> On Tue, Apr 05, 2011 at 12:32:50PM +0300, Felipe Balbi wrote:
> > From: Michael Fillinger 
> >
> > MCOP is an FPGA-based Silicon Validation platform
> > which is used to test particular IPs inside OMAP
> > before we have a real ASIC.
> >
> > Signed-off-by: Michael Fillinger 
> >
> > [ ba...@ti.com : few cleanups here an there and also
> > removal of some unnecessary code. ]
> >
> > Signed-off-by: Felipe Balbi 
>
> I should have RFCed this one, but bear with me for a minute.
>
> This is just the bare minimum board-file for MCOP, there's still a bunch
> of changes needed to get it actually booting. The attached diff shows
> many of them.
>
> Now, we don't want to send that patch upstream for obvious reasons and
> we also don't want to add ifdefs to clock data files as that would break
> multi-omap. What do you guys suggest ? How should we handle detection of
> MCOP so that we choose correct HWMODs and clock data files for it ?
>
> I don't think Linus will like if we add yet another hwmod + clk data
> file just for MCOP, so we need to re-use what's in tree.
>
> --
> Balbi

What you need to know about the MCOP system, based on OMAP2420, is that there 
is no PRCM and no complex clock trees, or power management. There is just 1 
main driver clock. As such the "clock tree" can be extremely simplified.

Michael


Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 
036 420 040 R.C.S Antibes. Capital de EUR 753.920



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

Re: [PATCH] arm: omap: introduce OMAP MCOP board file

On Tue, Apr 05, 2011 at 12:32:50PM +0300, Felipe Balbi wrote:
> From: Michael Fillinger 
> 
> MCOP is an FPGA-based Silicon Validation platform
> which is used to test particular IPs inside OMAP
> before we have a real ASIC.
> 
> Signed-off-by: Michael Fillinger 
> 
> [ ba...@ti.com : few cleanups here an there and also
>   removal of some unnecessary code. ]
> 
> Signed-off-by: Felipe Balbi 

I should have RFCed this one, but bear with me for a minute.

This is just the bare minimum board-file for MCOP, there's still a bunch
of changes needed to get it actually booting. The attached diff shows
many of them.

Now, we don't want to send that patch upstream for obvious reasons and
we also don't want to add ifdefs to clock data files as that would break
multi-omap. What do you guys suggest ? How should we handle detection of
MCOP so that we choose correct HWMODs and clock data files for it ?

I don't think Linus will like if we add yet another hwmod + clk data
file just for MCOP, so we need to re-use what's in tree.

-- 
balbi
diff --git a/arch/arm/mach-omap2/clock2420_data.c b/arch/arm/mach-omap2/clock2420_data.c
index 0a992bc..32b98e4 100644
--- a/arch/arm/mach-omap2/clock2420_data.c
+++ b/arch/arm/mach-omap2/clock2420_data.c
@@ -77,10 +77,9 @@ static struct clk osc_ck = {		/* (*12, *13, 19.2, *26, 38.4)MHz */
 /* Without modem likely 12MHz, with modem likely 13MHz */
 static struct clk sys_ck = {		/* (*12, *13, 19.2, 26, 38.4)MHz */
 	.name		= "sys_ck",		/* ~ ref_clk also */
+	.rate		= 1920,
 	.ops		= &clkops_null,
-	.parent		= &osc_ck,
 	.clkdm_name	= "wkup_clkdm",
-	.recalc		= &omap2xxx_sys_clk_recalc,
 };
 
 static struct clk alt_ck = {		/* Typical 54M or 48M, may not exist */
@@ -192,7 +191,7 @@ static struct clk func_54m_ck = {
 static struct clk core_ck = {
 	.name		= "core_ck",
 	.ops		= &clkops_null,
-	.parent		= &dpll_ck,		/* can also be 32k */
+	.parent		= &sys_ck,
 	.clkdm_name	= "wkup_clkdm",
 	.recalc		= &followparent_recalc,
 };
@@ -407,13 +406,8 @@ static const struct clksel mpu_clksel[] = {
 static struct clk mpu_ck = {	/* Control cpu */
 	.name		= "mpu_ck",
 	.ops		= &clkops_null,
-	.parent		= &core_ck,
-	.clkdm_name	= "mpu_clkdm",
-	.init		= &omap2_init_clksel_parent,
-	.clksel_reg	= OMAP_CM_REGADDR(MPU_MOD, CM_CLKSEL),
-	.clksel_mask	= OMAP24XX_CLKSEL_MPU_MASK,
-	.clksel		= mpu_clksel,
-	.recalc		= &omap2_clksel_recalc,
+	.rate		= 1920,
+	.clkdm_name	= "wkup_clkdm",
 };
 
 /*
@@ -556,11 +550,8 @@ static struct clk core_l3_ck = {	/* Used for ick and fck, interconnect */
 	.name		= "core_l3_ck",
 	.ops		= &clkops_null,
 	.parent		= &core_ck,
-	.clkdm_name	= "core_l3_clkdm",
-	.clksel_reg	= OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
-	.clksel_mask	= OMAP24XX_CLKSEL_L3_MASK,
-	.clksel		= core_l3_clksel,
-	.recalc		= &omap2_clksel_recalc,
+	.recalc		= &followparent_recalc,
+	.clkdm_name	= "wkup_clkdm",
 };
 
 /* usb_l4_ick */
@@ -612,11 +603,8 @@ static struct clk l4_ck = {		/* used both as an ick and fck */
 	.name		= "l4_ck",
 	.ops		= &clkops_null,
 	.parent		= &core_l3_ck,
-	.clkdm_name	= "core_l4_clkdm",
-	.clksel_reg	= OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL1),
-	.clksel_mask	= OMAP24XX_CLKSEL_L4_MASK,
-	.clksel		= l4_clksel,
-	.recalc		= &omap2_clksel_recalc,
+	.recalc		= &followparent_recalc,
+	.clkdm_name	= "wkup_clkdm",
 };
 
 /*
@@ -845,76 +833,47 @@ static const struct clksel omap24xx_gpt_clksel[] = {
 
 static struct clk gpt1_ick = {
 	.name		= "gpt1_ick",
-	.ops		= &clkops_omap2_dflt_wait,
+	.ops		= &clkops_null,
 	.parent		= &l4_ck,
-	.clkdm_name	= "core_l4_clkdm",
-	.enable_reg	= OMAP_CM_REGADDR(WKUP_MOD, CM_ICLKEN),
-	.enable_bit	= OMAP24XX_EN_GPT1_SHIFT,
+	.clkdm_name	= "wkup_clkdm",
 	.recalc		= &followparent_recalc,
 };
 
 static struct clk gpt1_fck = {
 	.name		= "gpt1_fck",
-	.ops		= &clkops_omap2_dflt_wait,
-	.parent		= &func_32k_ck,
-	.clkdm_name	= "core_l4_clkdm",
-	.enable_reg	= OMAP_CM_REGADDR(WKUP_MOD, CM_FCLKEN),
-	.enable_bit	= OMAP24XX_EN_GPT1_SHIFT,
-	.init		= &omap2_init_clksel_parent,
-	.clksel_reg	= OMAP_CM_REGADDR(WKUP_MOD, CM_CLKSEL1),
-	.clksel_mask	= OMAP24XX_CLKSEL_GPT1_MASK,
-	.clksel		= omap24xx_gpt_clksel,
-	.recalc		= &omap2_clksel_recalc,
-	.round_rate	= &omap2_clksel_round_rate,
-	.set_rate	= &omap2_clksel_set_rate
+	.ops		= &clkops_null,
+	.rate		= 1200,
+	.clkdm_name	= "wkup_clkdm",
 };
 
 static struct clk gpt2_ick = {
 	.name		= "gpt2_ick",
-	.ops		= &clkops_omap2_dflt_wait,
+	.ops		= &clkops_null,
 	.parent		= &l4_ck,
-	.clkdm_name	= "core_l4_clkdm",
-	.enable_reg	= OMAP_CM_REGADDR(CORE_MOD, CM_ICLKEN1),
-	.enable_bit	= OMAP24XX_EN_GPT2_SHIFT,
+	.clkdm_name	= "wkup_clkdm",
 	.recalc		= &followparent_recalc,
 };
 
 static struct clk gpt2_fck = {
 	.name		= "gpt2_fck",
-	.ops		= &clkops_omap2_dflt_wait,
-	.parent		= &func_32k_ck,
-	.clkdm_name	= "core_l4_clkdm",
-	.enable_reg	= OMAP_CM_REGADDR(CORE_MOD, CM_FCLKEN1),
-	.enable_bit	= OMAP24XX_EN_GPT2_SHIFT,
-	.init		= &omap2_init_clksel_parent,
-	.clksel_reg	= OMAP_CM_REGADDR(CORE_MOD, CM

[PATCH] arm: omap: introduce OMAP MCOP board file

From: Michael Fillinger 

MCOP is an FPGA-based Silicon Validation platform
which is used to test particular IPs inside OMAP
before we have a real ASIC.

Signed-off-by: Michael Fillinger 

[ ba...@ti.com : few cleanups here an there and also
removal of some unnecessary code. ]

Signed-off-by: Felipe Balbi 
---
 arch/arm/mach-omap2/Kconfig  |7 +++
 arch/arm/mach-omap2/Makefile |1 +
 arch/arm/mach-omap2/board-mcop.c |   60 ++
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 4 files changed, 69 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-mcop.c

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 1a2cf62..6f5699f 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -116,6 +116,13 @@ config MACH_OMAP_H4
select OMAP_PACKAGE_ZAF
select OMAP_DEBUG_DEVICES
 
+config MACH_OMAP_MCOP
+   bool "OMAP MCOP Board"
+   depends on ARCH_OMAP2420
+   default y
+#  select OMAP_PACKAGE_ZAF
+#  select OMAP_DEBUG_DEVICES
+
 config MACH_OMAP_APOLLON
bool "OMAP 2420 Apollon board"
depends on ARCH_OMAP2420
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 1c0c2b0..6db99c4 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -153,6 +153,7 @@ endif
 # Specific board support
 obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
 obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
+obj-$(CONFIG_MACH_OMAP_MCOP)   += board-mcop.o
 obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o \
   hsmmc.o
 obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
diff --git a/arch/arm/mach-omap2/board-mcop.c b/arch/arm/mach-omap2/board-mcop.c
new file mode 100644
index 000..b9fe1a4
--- /dev/null
+++ b/arch/arm/mach-omap2/board-mcop.c
@@ -0,0 +1,60 @@
+/*
+ * board-mcop.c - OMAP pre-Silicon Validation Platform
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Michael Fillinger 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+static void __init omap_mcop_init_irq(void)
+{
+   omap2_init_common_infrastructure();
+   omap2_init_common_devices(NULL, NULL);
+   omap_init_irq();
+}
+
+static void __init omap_mcop_init(void)
+{
+   omap_serial_init();
+}
+
+static void __init omap_mcop_map_io(void)
+{
+   omap2_set_globals_242x();
+   omap242x_map_common_io();
+}
+
+MACHINE_START(OMAP_MCOP, "OMAP MCOP Board")
+   /* Maintainer: Michael Fillinger  */
+
+   /*
+* REVISIT What values to put here so that it works
+* on all versions of MCOP
+*
+* .phys_io = 0x4800,
+* .io_pg_offst = ((0xfa00) >> 18) & 0xfffc,
+*/
+
+   .boot_params= 0x8100,
+   .map_io = omap_mcop_map_io,
+   .reserve= omap_reserve,
+   .init_irq   = omap_mcop_init_irq,
+   .init_machine   = omap_mcop_init,
+   .timer  = &omap_timer,
+MACHINE_END
diff --git a/arch/arm/plat-omap/include/plat/uncompress.h 
b/arch/arm/plat-omap/include/plat/uncompress.h
index ad98b85..dbedd6e 100644
--- a/arch/arm/plat-omap/include/plat/uncompress.h
+++ b/arch/arm/plat-omap/include/plat/uncompress.h
@@ -129,6 +129,7 @@ static inline void __arch_decomp_setup(unsigned long 
arch_id)
DEBUG_LL_OMAP2(1, omap_2430sdp);
DEBUG_LL_OMAP2(1, omap_apollon);
DEBUG_LL_OMAP2(1, omap_h4);
+   DEBUG_LL_OMAP2(1, omapmcop);
 
/* omap2 based boards using UART3 */
DEBUG_LL_OMAP2(3, nokia_n800);
-- 
1.7.4.1.343.ga91df

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

Re: [PATCH 0/5] regulator: twl: make 6030 regulators useable

2011-04-05 Thread Liam Girdwood

On Fri, 2011-04-01 at 10:22 +0530, Nishanth Menon wrote:
> TWL6030 regulator dynamic operations such as those on vaux2 and vaux3
> were reported to be broken on platforms such as pandaboard(OMAP4).
> Digging deeper into the code, found that 6030 regulator support
> requires quiet a bit of fixes to make it useable. Major change w.r.t
> TWL4030 has been the introduction of CFG_STATE register in TWL6030
> which is needed to be used for regulator control compared to messages
> which were used in TWL4030.

All applied now.

Thanks

Liam

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

Re: [PATCH 0/4] iommu: Prevent oops in iommu_get() and while arch_iommu is in use

2011-04-05 Thread Sakari Ailus

Laurent Pinchart wrote:
> Hi David,

Hi Laurent, David, others,

> On Wednesday 30 March 2011 17:50:17 David Cohen wrote:
>> On Wed, Mar 30, 2011 at 4:56 PM, Laurent Pinchart wrote:
>>> On Wednesday 30 March 2011 15:50:37 Sakari Ailus wrote:
 Laurent Pinchart wrote:
> On Wednesday 30 March 2011 10:16:56 Sakari Ailus wrote:
>> Laurent Pinchart wrote:
>>> On Friday 25 March 2011 20:37:55 Ramirez Luna, Omar wrote:
 On Fri, Mar 25, 2011 at 10:13 AM, Sakari Ailus wrote:
> Hi,
>
> This patchset is aimed to fix a problem in arch_iommu
> implementation references. When an actual arch_iommu
> implementation is not loaded while iommu_get() is being called
> results to a kernel oops, as well as removing an arch_iommu
> implementation which is in use.

 How about fixing the dependency instead? Right now iommu2 depends
 on iommu because of the calls to
 install_iommu_arch/uninstall_iommu_arch... we should change that
 dependency to iommu depend on iommu2. Something like iommu (plat)
 querying iommu2 (mach) for devices to install.
>>>
>>> The reason why iommu depends on iommu2 and not the other way around
>>> is because several mach-specific iommu implementations should be
>>> able to coexist in the same kernel. The right one should be loaded
>>> at runtime.
>>>
>>> I think that Sakari's patches correcty fix the problems he noticed.
>>> However, they won't fix one basic issue, which is that the iommu2
>>> module won't be automatically pulled in when the omap3isp module is
>>> loaded. The omap3isp driver will then fail to probe the device.
>>> That's better than crashing though.
>>
>> One option would be to specify the name of the module in the platform
>> data and request_module() that in omap_iommu_probe(). This would
>> solve the issue, not sure how pretty is this though.
>
> Do we need that ? My understanding is that a machine will need a
> single mach- specific iommu implementation only. Drivers shouldn't
> need to care about that.

 Well, no more than that there would have to be a driver for the IOMMU
 for that very hardware.

> The iommu implementation should be automatically selected based on the
> machine time.

 Machine type?

 I agree, but where is the selection made?
>>>
>>> The selection can be made by board code, or by the iommu implementations
>>> themselves if they're compiled in.
>>
>> I prefer the first option. The second one will make the current
>> implementation be even more OMAP-only.
>> We have basically 3 layers:
>> IOVMM, IOMMU_GENERIC and IOMMU_SPECIFIC. The middle one should be
>> generic and don't care about machine types. The later one can be
>> handled by board code as it's machine specific and, for most of the
>> cases, I see no reason to let any other implementation besides the
>> machine type's to be loaded.
>>
>> But the generic layer should not depend on any specific one. If
>> somebody decides to load the specific layer after the generic one, it
>> cannot be a problem.
> 
> Let me try to summarize the issue and the requirements.
> 
> IOMMU support on OMAP platforms uses an OMAP-specific implementation, divided 
> into 3 layers:
> 
> - the IOVMM layer (arch/arm/plat-omap/iovmm.ko) deals with virtual address 
> space management
> - the IOMMU layer (arch/arm/plat-omap/iommu.ko) controls the IOMMU hardware, 
> and deals with TLB and page tables
> - the IOMMU platform-specific layers (arch/arm/mach-omap2/iommu2.ko) handles 
> the IOMMU implementation variants between various OMAP platforms
> 
> Drivers depend on iovmm and iommu. They must not depend on iommu2.ko.
> 
> The only existing platform-specific IOMMU layer is iommu2.ko for OMAP2+. An 
> OMAP1 implementation is being worked on, and other implementations might be 
> needed for OMAP4 and/or OMAP5.
> 
> Building a kernel image that will run on all OMAP platforms isn't possible at 
> the moment but is being worked on. Such a kernel image will need to include 
> all the platform-specific IOMMU layers, and the correct layer will need to be 
> selected at runtime.
> 
> If a driver tries to request and use an IOMMU before the platform-specific 
> IOMMU layer is initialized, the request will fail. We thus need to ensure 
> that 
> the correct platform-specific IOMMU layer is initialized before IOMMU users 
> are initialized.

Thanks for the summary!

> I can see several ways to fix the problem.
> 
> - Turn the iommu and iommu2 options from tristate to bool. The downside is 
> that the kernel image will get slightly bigger.
> 
> - Merge the iommu and iommu2 modules together. This will temporarily fix the 
> problem, but a proper solution will still be needed for the OMAP1 (and maybe 
> OMAP5) IOMMU layers.
> 
> - Auto-load the correct platform-specific IOMMU module based on modaliases 
> created from th

Re: [PATCH] ARM: type casts update_sched_clock cyc_to_sched_clock cyc_to_fixed_sched_clock

On Tue, Apr 05, 2011 at 10:31:44AM +0200, Uwe Kleine-König wrote:
> On Tue, Apr 05, 2011 at 08:56:22AM +0100, Russell King - ARM Linux wrote:
> > On Tue, Apr 05, 2011 at 09:43:21AM +0200, Jan Weitzel wrote:
> > > parameter "u32 mask" type cast befor inversion
> s/befor/before/
> 
> > Nak.  I want a 32-bit all ones quantity.
> > 
> > unsigned long long vali = (unsigned short)~0;
> > unsigned long long vall = ~(unsigned short)0;
> > 
> BTW, the definiton of vall is equivalent to 
> 
>   unsigned long long valu = ~(unsigned int)0;
> 
> because ~ converts the unsigned short to unsigned int.

No.  The value gets promoted to int not unsigned int.

> > compiles to:
> > 
> > vali:
> > .word   65535
> > .word   0
> > 
> > vall:
> > .word   -1
> > .word   -1
> I really wonder about that. If I take a value of 0x (i.e. a 32
> bit wide int == ~0U) and assign that to an 64-bit unsigned long long I'd
> expect it to get the value 0xULL, not
> 0xULL. What's wrong?

See above.  int not unsigned int.  And it makes a difference:

unsigned long long vals = ~(int)0;
unsigned long long valu = ~(unsigned int)0;

vals:
.word   -1
.word   -1
valu:
.word   -1
.word   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

Re: [PATCH] ARM: type casts update_sched_clock cyc_to_sched_clock cyc_to_fixed_sched_clock

2011-04-05 Thread Uwe Kleine-König

On Tue, Apr 05, 2011 at 08:56:22AM +0100, Russell King - ARM Linux wrote:
> On Tue, Apr 05, 2011 at 09:43:21AM +0200, Jan Weitzel wrote:
> > parameter "u32 mask" type cast befor inversion
s/befor/before/

> Nak.  I want a 32-bit all ones quantity.
> 
> unsigned long long vali = (unsigned short)~0;
> unsigned long long vall = ~(unsigned short)0;
> 
BTW, the definiton of vall is equivalent to 

unsigned long long valu = ~(unsigned int)0;

because ~ converts the unsigned short to unsigned int.

> compiles to:
> 
> vali:
> .word   65535
> .word   0
> 
> vall:
> .word   -1
> .word   -1
I really wonder about that. If I take a value of 0x (i.e. a 32
bit wide int == ~0U) and assign that to an 64-bit unsigned long long I'd
expect it to get the value 0xULL, not
0xULL. What's wrong?

> So moving the ~ to be evaluated after the cast has the effect of making
> the cast pointless, and produces wrong values.  (u32)~0 does the 32-bit
My C-Book tells that using ~ on a signed it produces implementation
defined behaviour. That's what I pointed out to Jan and I guess that's
the reason why he created the patch.

> cast _after_ the inversion which ensures that its always truncated to
> a 32-bit value.
> 
> As the function is declared as taking a u32, the cast isn't needed.  If
> the function gets changed to take a u64, the casts will need to be
> re-added.  So, (u32)~0 makes the fact that we want a 32-bit all-ones
> mask explicit.
Actually this only results in a 32-bit all-ones value if int is at least
32 bits long, so technically using ~(u32)0 is better. (Obviously this is
given on ARM and I guess even on all platforms that Linux runs on.)

Best regards
Uwe

PS: this mail is not about trolling.

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
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] ARM: type casts update_sched_clock cyc_to_sched_clock cyc_to_fixed_sched_clock

2011-04-05 Thread Jan Weitzel

parameter "u32 mask" type cast befor inversion

Signed-off-by: Jan Weitzel 
---
 arch/arm/mach-ixp4xx/common.c |4 ++--
 arch/arm/mach-mmp/time.c  |4 ++--
 arch/arm/mach-omap1/time.c|4 ++--
 arch/arm/mach-pxa/time.c  |4 ++--
 arch/arm/mach-sa1100/time.c   |4 ++--
 arch/arm/mach-tegra/timer.c   |4 ++--
 arch/arm/mach-u300/timer.c|4 ++--
 arch/arm/plat-iop/time.c  |4 ++--
 arch/arm/plat-mxc/time.c  |4 ++--
 arch/arm/plat-nomadik/timer.c |4 ++--
 arch/arm/plat-omap/counter_32k.c  |4 ++--
 arch/arm/plat-orion/time.c|4 ++--
 arch/arm/plat-s5p/s5p-time.c  |4 ++--
 arch/arm/plat-versatile/sched-clock.c |4 ++--
 14 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index ed19bc3..20338bc 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -407,13 +407,13 @@ static DEFINE_CLOCK_DATA(cd);
 unsigned long long notrace sched_clock(void)
 {
u32 cyc = *IXP4XX_OSTS;
-   return cyc_to_sched_clock(&cd, cyc, (u32)~0);
+   return cyc_to_sched_clock(&cd, cyc, ~(u32)0);
 }
 
 static void notrace ixp4xx_update_sched_clock(void)
 {
u32 cyc = *IXP4XX_OSTS;
-   update_sched_clock(&cd, cyc, (u32)~0);
+   update_sched_clock(&cd, cyc, ~(u32)0);
 }
 
 /*
diff --git a/arch/arm/mach-mmp/time.c b/arch/arm/mach-mmp/time.c
index aeb9ae2..78d178f 100644
--- a/arch/arm/mach-mmp/time.c
+++ b/arch/arm/mach-mmp/time.c
@@ -62,13 +62,13 @@ static inline uint32_t timer_read(void)
 unsigned long long notrace sched_clock(void)
 {
u32 cyc = timer_read();
-   return cyc_to_sched_clock(&cd, cyc, (u32)~0);
+   return cyc_to_sched_clock(&cd, cyc, ~(u32)0);
 }
 
 static void notrace mmp_update_sched_clock(void)
 {
u32 cyc = timer_read();
-   update_sched_clock(&cd, cyc, (u32)~0);
+   update_sched_clock(&cd, cyc, ~(u32)0);
 }
 
 static irqreturn_t timer_interrupt(int irq, void *dev_id)
diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index 6885d2f..830e4d8 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -221,7 +221,7 @@ static DEFINE_CLOCK_DATA(cd);
 static inline unsigned long long notrace _omap_mpu_sched_clock(void)
 {
u32 cyc = mpu_read(&clocksource_mpu);
-   return cyc_to_sched_clock(&cd, cyc, (u32)~0);
+   return cyc_to_sched_clock(&cd, cyc, ~(u32)0);
 }
 
 #ifndef CONFIG_OMAP_32K_TIMER
@@ -239,7 +239,7 @@ static unsigned long long notrace omap_mpu_sched_clock(void)
 static void notrace mpu_update_sched_clock(void)
 {
u32 cyc = mpu_read(&clocksource_mpu);
-   update_sched_clock(&cd, cyc, (u32)~0);
+   update_sched_clock(&cd, cyc, ~(u32)0);
 }
 
 static void __init omap_init_clocksource(unsigned long rate)
diff --git a/arch/arm/mach-pxa/time.c b/arch/arm/mach-pxa/time.c
index 428da3f..57e1432 100644
--- a/arch/arm/mach-pxa/time.c
+++ b/arch/arm/mach-pxa/time.c
@@ -37,13 +37,13 @@ static DEFINE_CLOCK_DATA(cd);
 unsigned long long notrace sched_clock(void)
 {
u32 cyc = OSCR;
-   return cyc_to_sched_clock(&cd, cyc, (u32)~0);
+   return cyc_to_sched_clock(&cd, cyc, ~(u32)0);
 }
 
 static void notrace pxa_update_sched_clock(void)
 {
u32 cyc = OSCR;
-   update_sched_clock(&cd, cyc, (u32)~0);
+   update_sched_clock(&cd, cyc, ~(u32)0);
 }
 
 
diff --git a/arch/arm/mach-sa1100/time.c b/arch/arm/mach-sa1100/time.c
index ae4f3d8..0251d67 100644
--- a/arch/arm/mach-sa1100/time.c
+++ b/arch/arm/mach-sa1100/time.c
@@ -36,13 +36,13 @@ static DEFINE_CLOCK_DATA(cd);
 unsigned long long notrace sched_clock(void)
 {
u32 cyc = OSCR;
-   return cyc_to_fixed_sched_clock(&cd, cyc, (u32)~0, SC_MULT, SC_SHIFT);
+   return cyc_to_fixed_sched_clock(&cd, cyc, ~(u32)0, SC_MULT, SC_SHIFT);
 }
 
 static void notrace sa1100_update_sched_clock(void)
 {
u32 cyc = OSCR;
-   update_sched_clock(&cd, cyc, (u32)~0);
+   update_sched_clock(&cd, cyc, ~(u32)0);
 }
 
 #define MIN_OSCR_DELTA 2
diff --git a/arch/arm/mach-tegra/timer.c b/arch/arm/mach-tegra/timer.c
index 0fcb1eb..6394dfc 100644
--- a/arch/arm/mach-tegra/timer.c
+++ b/arch/arm/mach-tegra/timer.c
@@ -131,13 +131,13 @@ static DEFINE_CLOCK_DATA(cd);
 unsigned long long notrace sched_clock(void)
 {
u32 cyc = timer_readl(TIMERUS_CNTR_1US);
-   return cyc_to_fixed_sched_clock(&cd, cyc, (u32)~0, SC_MULT, SC_SHIFT);
+   return cyc_to_fixed_sched_clock(&cd, cyc, ~(u32)0, SC_MULT, SC_SHIFT);
 }
 
 static void notrace tegra_update_sched_clock(void)
 {
u32 cyc = timer_readl(TIMERUS_CNTR_1US);
-   update_sched_clock(&cd, cyc, (u32)~0);
+   update_sched_clock(&cd, cyc, ~(u32)0);
 }
 
 /*
diff --git a/arch/arm/mach-u300/timer.c b/arch/arm/mach-u300/timer.c
index 3ec58bd..825b138 100644
--- a/arch/arm/mach-u300/timer.c
+++ b/arch/a

Re: [PATCH] ARM: type casts update_sched_clock cyc_to_sched_clock cyc_to_fixed_sched_clock

On Tue, Apr 05, 2011 at 09:43:21AM +0200, Jan Weitzel wrote:
> parameter "u32 mask" type cast befor inversion

Nak.  I want a 32-bit all ones quantity.

unsigned long long vali = (unsigned short)~0;
unsigned long long vall = ~(unsigned short)0;

compiles to:

vali:
.word   65535
.word   0

vall:
.word   -1
.word   -1

So moving the ~ to be evaluated after the cast has the effect of making
the cast pointless, and produces wrong values.  (u32)~0 does the 32-bit
cast _after_ the inversion which ensures that its always truncated to
a 32-bit value.

As the function is declared as taking a u32, the cast isn't needed.  If
the function gets changed to take a u64, the casts will need to be
re-added.  So, (u32)~0 makes the fact that we want a 32-bit all-ones
mask explicit.
--
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 changes for v2.6.39 merge window