Re: [GIT PULL] OMAP4 coupled CPUidle support for v3.6

[Shilimkar, Santosh]

On Fri, Jul 27, 2012 at 2:19 AM, Olof Johansson o...@lixom.net wrote:
 Kevin,

 On Thu, Jul 26, 2012 at 2:37 PM, Kevin Hilman khil...@ti.com wrote:
 Hi Arnd, Olof,

 I know it is late, but I'm really hoping this can still make it for
 v3.6, so consider this a [GIT PLEA].  ;)

 New features submitted halfway through the merge window? Yeah, that's late.

 I'll pull it in as late2/pm once the below is fixed, but I won't
 promise we'll send it up.


 Kevin Hilman (1):
   ARM: OMAP4: CPUidle: add synchronization for coupled idle states

 Santosh Shilimkar (3):
   ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
   ARM: OMAP4: CPUidle: Use coupled cpuidle states to implement SMP 
 cpuidle.
   ARM: OMAP4: CPUidle: Open broadcast clock-event device.

 This looks odd, Colin was author to the first of the commits
 attributed to Santosh.

Not sure what you mean. These patches are written by me. Kevin, Collin helped
in review. If you are referring to the {ARM: OMAP: timer: allow gp
timer clock-event to be
used on both cpus} which does have SOB from me and Colin. The very first version
of this version I picked was from product tree in which it was
commited on Coiln's name.
Later I updated that forf the multi-omap and the new timer code and
hence the update
in Author.

Hope this clear.

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

Re: [GIT PULL] OMAP4 coupled CPUidle support for v3.6

[Colin Cross]

On Thu, Jul 26, 2012 at 11:34 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
 On Fri, Jul 27, 2012 at 2:19 AM, Olof Johansson o...@lixom.net wrote:
 Kevin,

 On Thu, Jul 26, 2012 at 2:37 PM, Kevin Hilman khil...@ti.com wrote:
 Hi Arnd, Olof,

 I know it is late, but I'm really hoping this can still make it for
 v3.6, so consider this a [GIT PLEA].  ;)

 New features submitted halfway through the merge window? Yeah, that's late.

 I'll pull it in as late2/pm once the below is fixed, but I won't
 promise we'll send it up.


 Kevin Hilman (1):
   ARM: OMAP4: CPUidle: add synchronization for coupled idle states

 Santosh Shilimkar (3):
   ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
   ARM: OMAP4: CPUidle: Use coupled cpuidle states to implement SMP 
 cpuidle.
   ARM: OMAP4: CPUidle: Open broadcast clock-event device.

 This looks odd, Colin was author to the first of the commits
 attributed to Santosh.

 Not sure what you mean. These patches are written by me. Kevin, Collin helped
 in review. If you are referring to the {ARM: OMAP: timer: allow gp
 timer clock-event to be
 used on both cpus} which does have SOB from me and Colin. The very first 
 version
 of this version I picked was from product tree in which it was
 commited on Coiln's name.
 Later I updated that forf the multi-omap and the new timer code and
 hence the update
 in Author.

I have no problem with the authorship on these two patches.
--
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 2/4] ARM: OMAP: PM: Get rid of Powerdomain book-keeping from cpuidle

[Rajendra Nayak]

Hi Tero,

On Thursday 26 July 2012 11:57 PM, Tero Kristo wrote:

Yeah, this is definitely a problem.

  As long as we have autodeps, everything is centralized around CPU
  transitions anyways, so it makes sense to keep the accounting
  centralized too.


I think as long as we have autodeps, the only way on OMAP3 to accurately
do this is to do it for all dependent domains in CPUIdle:(


  Or, to get rid of autodeps.;)

Whats the reason for having them anyway? Some of the wakedeps make sense
(per domain due to hw bugs) but sleepdeps...?



FWIK, the main problem is with modules with clocks under hardware
control. Once a slave module isn't functional and there are no
outstanding OCP accesses pending, the module when sent an IDLEREQ
by PRCM responds with an IDLEACK causing the clkdm to transition
to INACTIVE. A driver which is active can still in the meantime
cause a register access to the module, but the register access
does not act as an event which makes PRCM de-assert IDLEREQ causing
the module to unidle. This causes problems. So as long as there is
a possibility of some code doing a register access on the module
we need to keep it from idling. IIRC the issues we saw on OMAP3
were mostly around PER domain and I think with GPIO in particular.

The problem might be limited to modules with _only_ hardware controlled
clocks (iclks) like GPIO. For others which have an iclk and fclk, we can
always keep the autodeps while fclks are requested and get rid of them
when fclks are disabled. This is exactly what clkdm_clk_enable/disable
functions do, but given in the current mainline even iclks account
for usecounting, a clkdms usecount would never hit 0 causing 
clkdm_clk_disable never to be called. (On clkdms which have atleast one

iclk under hardware control).
hwmod keeps all iclks always enabled and under hardware control unless
the OCP interface has a 'OCPIF_SWSUP_IDLE' flag set.

But now with your series, which does not account iclks for usecounting,
I would expect this to be fixed. I was expecting for modules with both
fclk and iclk, as long as the driver has done a pm_runtime_get_sync()
or equivalent the autodeps would be set, and once the driver does a
pm_runtime_put_sync() the autodeps would be removed. This would also
be the same time we clear the Powerdomains previous power state register
and the Powerdomain should ideally immediately transition on not go in
and out with every MPU transition.
So this kind of rules out the problems that my theory above was
suggesting we would have with the $subject patch.
We still have to deal with the iclk only modules like GPIO though.

However a quick test with just your latest usecounting series (without
any of my RFC patches) seems to make me think I am still missing
something.

If you see the counts below for usbhost and dss, they both seem to
go in and out of RET with every MPU transition. Which means the
dependencies are still set.

# cat /debug/pm_debug/count
usbhost_pwrdm 
(ON),OFF:0,RET:138,INA:0,ON:139,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0

sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm 
(ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0

per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm (ON),OFF:0,RET:138,INA:0,ON:139,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:0,RET:132,INA:6,ON:139,RET-LOGIC-OFF:0
mpu_pwrdm (ON),OFF:0,RET:132,INA:6,ON:139,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm 
(RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0


However if I look at the dss registers, I don;t see any fclks are
enabled.

# ./readmem 0x48004E00
0x - All FCLK disabled.

# ./readmem 0x48004E10
0x0001 - ICLK enabled

# ./readmem 0x48004E44
0x0006 - dependencies are set with MPU and IVA

# ./readmem 0x48004E48
0x0003 - clkdm is under HWSUP.

Any idea why this could be happening?

regards,
Rajendra




--
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] OMAP3 clock: remove obsolete comment

[Michael Jones]

Hi Paul,

On 07/26/2012 09:55 PM, Paul Walmsley wrote:
 
 Hello Michael,
 
 thanks for the patch.  I've queued it for 3.7 after writing a changelog.
 Two minor comments for future patches: we don't accept patches with a
 non-null changelog - usually just something brief works fine.  Also Tony
 wants all OMAP patches to be cc'ed to the linux-arm-kernel mailing list.
 
 regards,
 
 - Paul

Thanks for the comments, I'll adhere to them in the future.  I assume you
meant you _only_ accept patches with a non-null changelog.  I referred to
http://omappedia.org/wiki/Releasing_to_Linux_kernel_using_patches_and_emails
before my submission, and didn't see these two points.  A few Q's:

Can I add these two points to that Wiki page?  Or is there a more
authoritative checklist somewhere?

Why is it queued for 3.7?  I thought 3.6 was in the works?

Where is it queued?

thanks,
Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
--
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/6] w1: omap-hdq: add section annotation to remove

[Felipe Balbi]

Hi,

On Thu, Jul 26, 2012 at 06:45:26PM +0400, Evgeniy Polyakov wrote:
 Hi all
 
 On Wed, Jul 25, 2012 at 03:05:27PM +0300, Felipe Balbi (ba...@ti.com) wrote:
  trivial patch, no functional changes.
  
  Signed-off-by: Felipe Balbi ba...@ti.com
 
 Looks good to me
 Who should pick it up?
 
 Feel free to add my acked-by: Evgeniy Polyakov z...@ioremap.net

I thought you would :-p Then I guess Tony, maybe ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] OMAP3 clock: remove obsolete comment

[Paul Walmsley]

Hello Michael,

On Fri, 27 Jul 2012, Michael Jones wrote:

 Thanks for the comments, I'll adhere to them in the future.  I assume you
 meant you _only_ accept patches with a non-null changelog.

Indeed, that's right, I misstated it.

 I referred to 
 http://omappedia.org/wiki/Releasing_to_Linux_kernel_using_patches_and_emails 
 before my submission, and didn't see these two points.  A few Q's:
 
 Can I add these two points to that Wiki page?

Sounds reasonable, but I don't know who maintains that page.

 Or is there a more authoritative checklist somewhere?

There is; it's Documentation/SubmittingPatches which can be viewed here:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/SubmittingPatches

 Why is it queued for 3.7?

It is a low-priority fix (but valuable nonetheless, of course).

 I thought 3.6 was in the works?

Most of the significant new patches for 3.6 were tested and queued several 
weeks ago.  Now we are queuing bugfix and regression patches for 3.6-rc 
and new features and low-priority fixes for 3.7.

 Where is it queued?

It is currently queued in a git branch on my local drive.


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

Re: [PATCH] OMAP3 clock: remove obsolete comment

[Michael Jones]

Hi Paul,

Thanks for the explanations.

On 07/27/2012 09:14 AM, Paul Walmsley wrote:

Hello Michael,



[snip]


There is; it's Documentation/SubmittingPatches which can be viewed here:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/SubmittingPatches


I looked at that, too, but it wasn't clear to me that even such a 
trivial patch should have an explanation body, as the description

there assumes a functional change is being introduced.  Now I know!

[snip]


- Paul



-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
--
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

arm interrupt handling

[Qipeng Zha]

Hi
When I study the interrupt handling code in 2.6.39 for omap soc, found don't 
clear CPSR.I to enable irq till each ISR finished.
Is this true? Or I miss something, since this will be wired that the core will 
not service any other irq before complete before irq handling.


Best wishes
Qipeng


-Original Message-
From: linux-arm-kernel-boun...@lists.infradead.org 
[mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf Of Andy Green 
(林安廸)
Sent: 2012年7月10日 20:59
To: Florian Fainelli
Cc: s-...@ti.com; a...@arndb.de; patc...@linaro.org; t...@atomide.com; 
net...@vger.kernel.org; linux-ker...@vger.kernel.org; rost...@goodmis.org; 
linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC 
addresses to deterministic computed locally administered values

On 10/07/12 20:37, the mail apparently from Florian Fainelli included:

Hi -

 Le jeudi 05 juillet 2012 04:44:33, Andy Green a écrit :
 The following series adds some code to generate legal, locally administered
 MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
 net/ethernet taking care of accepting device path / MAC mapping
 registrations and running a notifier to enforce the requested MAC when the
 matching network device turns up.

 This looks like something you can solve by user-space entirely. Expose the

That might seem so from a openwrt perspective, where you custom cook the 
whole userland thing per-device, but it ain't so from a generic rootfs 
perspective.

Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific 
workarounds?  And Panda is not the only device with this issue.

-Andy

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
N�r��yb�X��ǧv�^�)޺{.n�+{��f��{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj��!�i

Re: [RFC 2/4] ARM: OMAP: PM: Get rid of Powerdomain book-keeping from cpuidle

[Rajendra Nayak]

Hi Tero,

On Friday 27 July 2012 12:16 PM, Rajendra Nayak wrote:

However a quick test with just your latest usecounting series (without
any of my RFC patches) seems to make me think I am still missing
something.

If you see the counts below for usbhost and dss, they both seem to
go in and out of RET with every MPU transition. Which means the
dependencies are still set.

# cat /debug/pm_debug/count
usbhost_pwrdm
(ON),OFF:0,RET:138,INA:0,ON:139,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
core_pwrdm
(ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0

per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
dss_pwrdm
(ON),OFF:0,RET:138,INA:0,ON:139,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
cam_pwrdm (RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
neon_pwrdm (ON),OFF:0,RET:132,INA:6,ON:139,RET-LOGIC-OFF:0
mpu_pwrdm
(ON),OFF:0,RET:132,INA:6,ON:139,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
iva2_pwrdm
(RET),OFF:0,RET:1,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0


However if I look at the dss registers, I don;t see any fclks are
enabled.

# ./readmem 0x48004E00
0x - All FCLK disabled.

# ./readmem 0x48004E10
0x0001 - ICLK enabled

# ./readmem 0x48004E44
0x0006 - dependencies are set with MPU and IVA

# ./readmem 0x48004E48
0x0003 - clkdm is under HWSUP.

Any idea why this could be happening?


I think I know what the problem is now.

omap3_pm_init calls clkdm_allow_idle for all clkdms, while autoidle on
all iclks is still disabled. This causes autodeps to be set as the iclks
are accounted for in the usecount.
(hwmod would have done a clk_enable() on the iclks and left them enabled
as OCPIF_SWSUP_IDLE isn't set)

static void omap3_clkdm_allow_idle(struct clockdomain *clkdm)
{
if (atomic_read(clkdm-usecount)  0)
_clkdm_add_autodeps(clkdm);

omap3xxx_cm_clkdm_enable_hwsup(clkdm-pwrdm.ptr-prcm_offs,
clkdm-clktrctrl_mask);
}

A little later after omap3_pm_init, we enable autoidle for all iclks.
omap2_clkt_iclk_allow_idle decrements the usecount, but leaves the
autodeps still set.

This seems to be causing the dss and usb to also transition along with
MPU.

We will need some way to also clear and set autodeps in
omap2_clkt_iclk_allow_idle/deny_idle.

regards,
Rajendra




--
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: OMAP3xxx: clockdomain: fix software supervised wakeup/sleep

[Nayak, Rajendra]

Paul,

On Fri, Jul 27, 2012 at 2:34 AM, Paul Walmsley p...@pwsan.com wrote:

 Commit 4da71ae6 (OMAP: clockdomain: Arch specific funcs for
 clkdm_clk_enable/disable) called the OMAP2xxx-specific functions for
 clockdomain wakeup and sleep.  This would probably have broken
 software-supervised clockdomain wakeup and sleep on OMAP3.

Would something like this be better than duplicating most of
omap2_clkdm_clk_enable/disable?

---
 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c |   25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

Index: linux-2.6/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
2012-07-27 13:15:49.238134472 +0530
+++ linux-2.6/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
2012-07-27 13:22:01.607380032 +0530
@@ -162,6 +162,27 @@
clkdm-clktrctrl_mask);
 }

+static void _clkdm_sleep(struct clockdomain *clkdm)
+{
+   if (cpu_is_omap24xx())
+   omap2_cm_set_mod_reg_bits(OMAP24XX_FORCESTATE_MASK,
+   clkdm-pwrdm.ptr-prcm_offs,
+   OMAP2_PM_PWSTCTRL);
+   else if (cpu_is_omap34xx())
+   omap3xxx_cm_clkdm_force_sleep(clkdm-pwrdm.ptr-prcm_offs,
+   clkdm-clktrctrl_mask);
+}
+
+static void _clkdm_wakeup(struct clockdomain *clkdm)
+{
+   if (cpu_is_omap24xx())
+   omap2_cm_clear_mod_reg_bits(OMAP24XX_FORCESTATE_MASK,
+   clkdm-pwrdm.ptr-prcm_offs,
+   OMAP2_PM_PWSTCTRL);
+   else if (cpu_is_omap34xx())
+   omap3xxx_cm_clkdm_force_wakeup(clkdm-pwrdm.ptr-prcm_offs,
+   clkdm-clktrctrl_mask);
+}

 static int omap2_clkdm_clk_enable(struct clockdomain *clkdm)
 {
@@ -180,7 +201,7 @@
_enable_hwsup(clkdm);
} else {
if (clkdm-flags  CLKDM_CAN_FORCE_WAKEUP)
-   omap2_clkdm_wakeup(clkdm);
+   _clkdm_wakeup(clkdm);
}

return 0;
@@ -203,7 +224,7 @@
_enable_hwsup(clkdm);
} else {
if (clkdm-flags  CLKDM_CAN_FORCE_SLEEP)
-   omap2_clkdm_sleep(clkdm);
+   _clkdm_sleep(clkdm);
}


 Signed-off-by: Paul Walmsley p...@pwsan.com
 Cc: Rajendra Nayak rna...@ti.com
 Cc: Jon Hunter jon-hun...@ti.com
 ---
  arch/arm/mach-omap2/clockdomain2xxx_3xxx.c |   50 
 ++--
  1 file changed, 48 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c 
 b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 index a0d68db..f99e65c 100644
 --- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 +++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 @@ -241,6 +241,52 @@ static void omap3_clkdm_deny_idle(struct clockdomain 
 *clkdm)
 _clkdm_del_autodeps(clkdm);
  }

 +static int omap3xxx_clkdm_clk_enable(struct clockdomain *clkdm)
 +{
 +   bool hwsup = false;
 +
 +   if (!clkdm-clktrctrl_mask)
 +   return 0;
 +
 +   hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm-pwrdm.ptr-prcm_offs,
 +   clkdm-clktrctrl_mask);
 +
 +   if (hwsup) {
 +   /* Disable HW transitions when we are changing deps */
 +   _disable_hwsup(clkdm);
 +   _clkdm_add_autodeps(clkdm);
 +   _enable_hwsup(clkdm);
 +   } else {
 +   if (clkdm-flags  CLKDM_CAN_FORCE_WAKEUP)
 +   omap3_clkdm_wakeup(clkdm);
 +   }
 +
 +   return 0;
 +}
 +
 +static int omap3xxx_clkdm_clk_disable(struct clockdomain *clkdm)
 +{
 +   bool hwsup = false;
 +
 +   if (!clkdm-clktrctrl_mask)
 +   return 0;
 +
 +   hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm-pwrdm.ptr-prcm_offs,
 +   clkdm-clktrctrl_mask);
 +
 +   if (hwsup) {
 +   /* Disable HW transitions when we are changing deps */
 +   _disable_hwsup(clkdm);
 +   _clkdm_del_autodeps(clkdm);
 +   _enable_hwsup(clkdm);
 +   } else {
 +   if (clkdm-flags  CLKDM_CAN_FORCE_SLEEP)
 +   omap3_clkdm_sleep(clkdm);
 +   }
 +
 +   return 0;
 +}
 +
  struct clkdm_ops omap2_clkdm_operations = {
 .clkdm_add_wkdep= omap2_clkdm_add_wkdep,
 .clkdm_del_wkdep= omap2_clkdm_del_wkdep,
 @@ -267,6 +313,6 @@ 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_clk_enable   = omap2_clkdm_clk_enable,
 -   .clkdm_clk_disable  = omap2_clkdm_clk_disable,
 +   .clkdm_clk_enable   = 

[PATCH v6 07/11] usb: otg: nop: add dt support

[Ravi B]

From: Ajay Kumar Gupta ajay.gu...@ti.com

Added device tree support for nop transceiver driver and updated the
Documentation with device tree binding information for am33xx platform.

Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi B ravib...@ti.com
---
 .../devicetree/bindings/usb/am33xx-usb.txt |3 +++
 drivers/usb/otg/nop-usb-xceiv.c|   10 ++
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt 
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ca8fa56..9782585 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,3 +12,6 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
  - power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+NOP USB PHY
+ - compatible : Should be nop-xceiv-usb
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index fc899e4..90889d9 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -27,6 +27,7 @@
  */
 
 #include linux/module.h
+#include linux/of.h
 #include linux/platform_device.h
 #include linux/dma-mapping.h
 #include linux/usb/otg.h
@@ -188,12 +189,21 @@ static int __devexit nop_usb_xceiv_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id nop_xceiv_id_table[] = {
+   { .compatible = nop-xceiv-usb },
+   {}
+};
+MODULE_DEVICE_TABLE(of, nop_xceiv_id_table);
+#endif
+
 static struct platform_driver nop_usb_xceiv_driver = {
.probe  = nop_usb_xceiv_probe,
.remove = __devexit_p(nop_usb_xceiv_remove),
.driver = {
.name   = nop_usb_xceiv,
.owner  = THIS_MODULE,
+   .of_match_table = of_match_ptr(nop_xceiv_id_table),
},
 };
 
-- 
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 v6 05/11] usb: musb: dsps: add dt support

[Ravi B]

From: Ajay Kumar Gupta ajay.gu...@ti.com

Added device tree support for dsps musb glue driver and updated the
Documentation with device tree binding information.

Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi B ravib...@ti.com
---
 .../devicetree/bindings/usb/am33xx-usb.txt |   14 +
 drivers/usb/musb/musb_dsps.c   |   60 +---
 2 files changed, 65 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/am33xx-usb.txt

diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt 
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
new file mode 100644
index 000..ca8fa56
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -0,0 +1,14 @@
+AM33XX MUSB GLUE
+ - compatible : Should be ti,musb-am33xx
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+   multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+   MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - port0_mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+   represents PERIPHERAL.
+ - port1_mode : Should be 1 to represent HOST. 3 signifies OTG and 2
+   represents PERIPHERAL.
+ - power : Should be 250. This signifies the controller can supply upto
+   500mA when operating in host mode.
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 4fcfa1a..67d1f00 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -31,6 +31,7 @@
 
 #include linux/init.h
 #include linux/io.h
+#include linux/of.h
 #include linux/err.h
 #include linux/platform_device.h
 #include linux/dma-mapping.h
@@ -45,6 +46,10 @@
 
 #include musb_core.h
 
+#ifdef CONFIG_OF
+static const struct of_device_id musb_dsps_of_match[];
+#endif
+
 /**
  * avoid using musb_readx()/musb_writex() as glue layer should not be
  * dependent on musb core layer symbols.
@@ -501,6 +506,8 @@ static int __devinit dsps_create_musb_pdev(struct dsps_glue 
*glue, u8 id)
struct device *dev = glue-dev;
struct platform_device *pdev = to_platform_device(dev);
struct musb_hdrc_platform_data  *pdata = dev-platform_data;
+   struct device_node *np = pdev-dev.of_node;
+   struct musb_hdrc_config *config;
struct platform_device  *musb;
struct resource *res;
struct resource resources[2];
@@ -567,14 +574,40 @@ static int __devinit dsps_create_musb_pdev(struct 
dsps_glue *glue, u8 id)
 
glue-musb[id]  = musb;
 
-   pdata-platform_ops = dsps_ops;
-
ret = platform_device_add_resources(musb, resources, 2);
if (ret) {
dev_err(dev, failed to add resources\n);
goto err2;
}
 
+   if (np) {
+   pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata) {
+   dev_err(pdev-dev,
+   failed to allocate musb platfrom data\n);
+   ret = -ENOMEM;
+   goto err2;
+   }
+
+   config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+   if (!config) {
+   dev_err(pdev-dev,
+   failed to allocate musb hdrc config\n);
+   goto err2;
+   }
+
+   of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+   of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+   sprintf(res_name, port%d_mode, id);
+   of_property_read_u32(np, res_name, (u32 *)pdata-mode);
+   of_property_read_u32(np, power, (u32 *)pdata-power);
+   config-multipoint = of_property_read_bool(np, multipoint);
+
+   pdata-config   = config;
+   }
+
+   pdata-platform_ops = dsps_ops;
+
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(dev, failed to add platform_data\n);
@@ -606,14 +639,22 @@ static void __devexit dsps_delete_musb_pdev(struct 
dsps_glue *glue, u8 id)
 
 static int __devinit dsps_probe(struct platform_device *pdev)
 {
-   const struct platform_device_id *id = platform_get_device_id(pdev);
-   const struct dsps_musb_wrapper *wrp =
-   (struct dsps_musb_wrapper *)id-driver_data;
+   struct device_node *np = pdev-dev.of_node;
+   const struct of_device_id *match;
+   const struct dsps_musb_wrapper *wrp;
struct dsps_glue *glue;
struct resource *iomem;
u32 __iomem *usbss;
int ret, i;
 
+   match = of_match_node(musb_dsps_of_match, np);
+   if (!match) {
+   dev_err(pdev-dev, fail to get matching of_match 

[PATCH v6 04/11] usb: otg: nop: add support for multiple tranceiver

[Ravi B]

From: Ajay Kumar Gupta ajay.gu...@ti.com

Currently we have one single nop transceiver support as same is
defined as a global variable in drivers/usb/otg/nop-usb-xceiv.c.
This need to be changed to support multiple otg controller each
using nop transceiver on a platform such as am335x.

Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi B ravib...@ti.com
---
 drivers/usb/musb/am35x.c|2 +-
 drivers/usb/musb/blackfin.c |2 +-
 drivers/usb/musb/da8xx.c|2 +-
 drivers/usb/musb/davinci.c  |4 +-
 drivers/usb/musb/musb_dsps.c|8 +++---
 drivers/usb/musb/tusb6010.c |4 +-
 drivers/usb/otg/nop-usb-xceiv.c |   54 +-
 include/linux/usb/otg.h |4 +-
 8 files changed, 60 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 01203eb..984e439 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -408,7 +408,7 @@ static int am35x_musb_exit(struct musb *musb)
data-set_phy_power(0);
 
usb_put_phy(musb-xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb-xceiv);
 
return 0;
 }
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index c848b82..f1fe728 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -442,7 +442,7 @@ static int bfin_musb_exit(struct musb *musb)
gpio_free(musb-config-gpio_vrsel);
 
usb_put_phy(musb-xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb-xceiv);
return 0;
 }
 
diff --git a/drivers/usb/musb/da8xx.c b/drivers/usb/musb/da8xx.c
index cebd9d7..a5260b6 100644
--- a/drivers/usb/musb/da8xx.c
+++ b/drivers/usb/musb/da8xx.c
@@ -460,7 +460,7 @@ static int da8xx_musb_exit(struct musb *musb)
phy_off();
 
usb_put_phy(musb-xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb-xceiv);
 
return 0;
 }
diff --git a/drivers/usb/musb/davinci.c b/drivers/usb/musb/davinci.c
index 3f094f2..c7ef654 100644
--- a/drivers/usb/musb/davinci.c
+++ b/drivers/usb/musb/davinci.c
@@ -447,7 +447,7 @@ static int davinci_musb_init(struct musb *musb)
 fail:
usb_put_phy(musb-xceiv);
 unregister:
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb-xceiv);
return -ENODEV;
 }
 
@@ -496,7 +496,7 @@ static int davinci_musb_exit(struct musb *musb)
phy_off();
 
usb_put_phy(musb-xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb-xceiv);
 
return 0;
 }
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 2fd5dc8..4fcfa1a 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -424,7 +424,7 @@ static int dsps_musb_init(struct musb *musb)
/* mentor core register starts at offset of 0x400 from musb base */
musb-mregs += wrp-musb_core_offset;
 
-   /* NOP driver needs change if supporting dual instance */
+   /* Register NOP driver */
usb_nop_xceiv_register();
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
@@ -460,7 +460,7 @@ static int dsps_musb_init(struct musb *musb)
return 0;
 err0:
usb_put_phy(musb-xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb-xceiv);
return status;
 }
 
@@ -477,9 +477,9 @@ static int dsps_musb_exit(struct musb *musb)
/* Shutdown the on-chip PHY and its PLL. */
musb_dsps_phy_control(glue, pdev-id, 0);
 
-   /* NOP driver needs change if supporting dual instance */
+   /* Unregister NOP driver */
usb_put_phy(musb-xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb-xceiv);
 
return 0;
 }
diff --git a/drivers/usb/musb/tusb6010.c b/drivers/usb/musb/tusb6010.c
index 64a0e95..3a12330 100644
--- a/drivers/usb/musb/tusb6010.c
+++ b/drivers/usb/musb/tusb6010.c
@@ -1132,7 +1132,7 @@ done:
iounmap(sync);
 
usb_put_phy(musb-xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb-xceiv);
}
return ret;
 }
@@ -1148,7 +1148,7 @@ static int tusb_musb_exit(struct musb *musb)
iounmap(musb-sync_va);
 
usb_put_phy(musb-xceiv);
-   usb_nop_xceiv_unregister();
+   usb_nop_xceiv_unregister(musb-xceiv);
return 0;
 }
 
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 803f958..fc899e4 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -31,30 +31,69 @@
 #include linux/dma-mapping.h
 #include linux/usb/otg.h
 #include linux/slab.h
+#include linux/idr.h
 
 struct nop_usb_xceiv {
struct usb_phy  phy;
struct device   *dev;
+   struct platform_device  *pd;
 };
 
-static struct platform_device 

[PATCH v6 09/11] usb: musb: dsps: remove explicit NOP device creation

[Ravi B]

From: Ajay Kumar Gupta ajay.gu...@ti.com

As NOP device node is now added in am33xx tree so remove the call
which creates the NOP platform_device.

Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi B ravib...@ti.com
---
 drivers/usb/musb/musb_dsps.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 67d1f00..24b2e4a 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -429,8 +429,7 @@ static int dsps_musb_init(struct musb *musb)
/* mentor core register starts at offset of 0x400 from musb base */
musb-mregs += wrp-musb_core_offset;
 
-   /* Register NOP driver */
-   usb_nop_xceiv_register();
+   /* Get the NOP PHY */
musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb-xceiv))
return -ENODEV;
-- 
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 v6 03/11] usb: musb: am335x: add support for dual instance

[Ravi B]

From: Ajay Kumar Gupta ajay.gu...@ti.com

AM335x and TI81xx platform has dual musb controller so updating the
musb_dspc.c to support the same.

Changes:
- Moved otg_workaround timer to glue structure
- Moved static local variable last_timer to glue structure
- PHY on/off related cleanups

Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi B ravib...@ti.com
---
 drivers/usb/musb/musb_dsps.c |  118 +
 1 files changed, 72 insertions(+), 46 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 2174699..2fd5dc8 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -105,6 +105,8 @@ struct dsps_musb_wrapper {
/* miscellaneous stuff */
u32 musb_core_offset;
u8  poll_seconds;
+   /* number of musb instances */
+   u8  instances;
 };
 
 /**
@@ -112,16 +114,18 @@ struct dsps_musb_wrapper {
  */
 struct dsps_glue {
struct device *dev;
-   struct platform_device *musb;   /* child musb pdev */
+   struct platform_device *musb[2];/* child musb pdev */
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
-   struct timer_list timer;/* otg_workaround timer */
-   u32 __iomem *usb_ctrl;
+   struct timer_list timer[2]; /* otg_workaround timer */
+   unsigned long last_timer[2];/* last timer data for each instance */
+   u32 __iomem *usb_ctrl[2];
u8  usbss_rev;
 };
 
 /**
  * musb_dsps_phy_control - phy on/off
  * @glue: struct dsps_glue *
+ * @id: musb instance
  * @on: flag for phy to be switched on or off
  *
  * This is to enable the PHY using usb_ctrl register in system control
@@ -130,11 +134,11 @@ struct dsps_glue {
  * XXX: This function will be removed once we have a seperate driver for
  * control module
  */
-static void musb_dsps_phy_control(struct dsps_glue *glue, u8 on)
+static void musb_dsps_phy_control(struct dsps_glue *glue, u8 id, u8 on)
 {
u32 usbphycfg;
 
-   usbphycfg = __raw_readl(glue-usb_ctrl);
+   usbphycfg = __raw_readl(glue-usb_ctrl[id]);
 
if (on) {
if (glue-usbss_rev == MUSB_USBSS_REV_816X) {
@@ -157,7 +161,7 @@ static void musb_dsps_phy_control(struct dsps_glue *glue, 
u8 on)
glue-usbss_rev == MUSB_USBSS_REV_33XX)
usbphycfg |= USBPHY_CM_PWRDN | USBPHY_OTG_PWRDN;
}
-   __raw_writel(usbphycfg, glue-usb_ctrl);
+   __raw_writel(usbphycfg, glue-usb_ctrl[id]);
 }
 /**
  * dsps_musb_enable - enable interrupts
@@ -207,8 +211,9 @@ static void otg_timer(unsigned long _musb)
struct musb *musb = (void *)_musb;
void __iomem *mregs = musb-mregs;
struct device *dev = musb-controller;
-   struct platform_device *pdev = to_platform_device(dev-parent);
-   struct dsps_glue *glue = platform_get_drvdata(pdev);
+   struct platform_device *pdev = to_platform_device(dev);
+   struct platform_device *parent_pdev = to_platform_device(dev-parent);
+   struct dsps_glue *glue = platform_get_drvdata(parent_pdev);
const struct dsps_musb_wrapper *wrp = glue-wrp;
u8 devctl;
unsigned long flags;
@@ -247,7 +252,7 @@ static void otg_timer(unsigned long _musb)
 
devctl = dsps_readb(mregs, MUSB_DEVCTL);
if (devctl  MUSB_DEVCTL_BDEVICE)
-   mod_timer(glue-timer,
+   mod_timer(glue-timer[pdev-id],
jiffies + wrp-poll_seconds * HZ);
else
musb-xceiv-state = OTG_STATE_A_IDLE;
@@ -261,9 +266,9 @@ static void otg_timer(unsigned long _musb)
 static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
 {
struct device *dev = musb-controller;
-   struct platform_device *pdev = to_platform_device(dev-parent);
-   struct dsps_glue *glue = platform_get_drvdata(pdev);
-   static unsigned long last_timer;
+   struct platform_device *pdev = to_platform_device(dev);
+   struct platform_device *parent_pdev = to_platform_device(dev-parent);
+   struct dsps_glue *glue = platform_get_drvdata(parent_pdev);
 
if (!is_otg_enabled(musb))
return;
@@ -276,22 +281,23 @@ static void dsps_musb_try_idle(struct musb *musb, 
unsigned long timeout)
musb-xceiv-state == OTG_STATE_A_WAIT_BCON)) {
dev_dbg(musb-controller, %s active, deleting timer\n,
otg_state_string(musb-xceiv-state));
-   del_timer(glue-timer);
-   last_timer = jiffies;
+   del_timer(glue-timer[pdev-id]);
+   glue-last_timer[pdev-id] = jiffies;
return;
}
 
-   if (time_after(last_timer, timeout)  timer_pending(glue-timer)) {
+   if 

[PATCH v6 11/11] arm/dts: am33xx: add phy phandle to usbss

[Ravi B]

From: Ajay Kumar Gupta ajay.gu...@ti.com

Added NOP PHY phandle to usbss device node as same will be used
to get the phy from otg framework.

Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi B ravib...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index b03a9b5..d3ab69a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -172,6 +172,8 @@
port0_mode = 3;
port1_mode = 1;
power = 250;
+   usb0-phy = usb0_phy;
+   usb1-phy = usb1_phy;
};
};
 };
-- 
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 v6 01/11] usb: musb: add musb_ida for multi instance support

[Ravi B]

From: Ajay Kumar Gupta ajay.gu...@ti.com

Added musb_ida in musb_core.c to manage the multi core ids.

Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi B ravib...@ti.com
---
 drivers/usb/musb/am35x.c |   42 --
 drivers/usb/musb/blackfin.c  |   26 --
 drivers/usb/musb/da8xx.c |   34 --
 drivers/usb/musb/davinci.c   |   34 --
 drivers/usb/musb/musb_core.c |   31 +++
 drivers/usb/musb/musb_core.h |2 ++
 drivers/usb/musb/musb_dsps.c |   25 ++---
 drivers/usb/musb/omap2430.c  |   26 --
 drivers/usb/musb/tusb6010.c  |   26 --
 drivers/usb/musb/ux500.c |   33 +++--
 10 files changed, 210 insertions(+), 69 deletions(-)

diff --git a/drivers/usb/musb/am35x.c b/drivers/usb/musb/am35x.c
index 7a95ab8..01203eb 100644
--- a/drivers/usb/musb/am35x.c
+++ b/drivers/usb/musb/am35x.c
@@ -468,6 +468,7 @@ static int __devinit am35x_probe(struct platform_device 
*pdev)
struct clk  *clk;
 
int ret = -ENOMEM;
+   int musbid;
 
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -475,38 +476,47 @@ static int __devinit am35x_probe(struct platform_device 
*pdev)
goto err0;
}
 
-   musb = platform_device_alloc(musb-hdrc, -1);
+   /* get the musb id */
+   musbid = musb_get_id(pdev-dev, GFP_KERNEL);
+   if (musbid  0) {
+   dev_err(pdev-dev, failed to allocate musb id\n);
+   ret = -ENOMEM;
+   goto err1;
+   }
+
+   musb = platform_device_alloc(musb-hdrc, musbid);
if (!musb) {
dev_err(pdev-dev, failed to allocate musb device\n);
-   goto err1;
+   goto err2;
}
 
phy_clk = clk_get(pdev-dev, fck);
if (IS_ERR(phy_clk)) {
dev_err(pdev-dev, failed to get PHY clock\n);
ret = PTR_ERR(phy_clk);
-   goto err2;
+   goto err3;
}
 
clk = clk_get(pdev-dev, ick);
if (IS_ERR(clk)) {
dev_err(pdev-dev, failed to get clock\n);
ret = PTR_ERR(clk);
-   goto err3;
+   goto err4;
}
 
ret = clk_enable(phy_clk);
if (ret) {
dev_err(pdev-dev, failed to enable PHY clock\n);
-   goto err4;
+   goto err5;
}
 
ret = clk_enable(clk);
if (ret) {
dev_err(pdev-dev, failed to enable clock\n);
-   goto err5;
+   goto err6;
}
 
+   musb-id= musbid;
musb-dev.parent= pdev-dev;
musb-dev.dma_mask  = am35x_dmamask;
musb-dev.coherent_dma_mask = am35x_dmamask;
@@ -524,38 +534,41 @@ static int __devinit am35x_probe(struct platform_device 
*pdev)
pdev-num_resources);
if (ret) {
dev_err(pdev-dev, failed to add resources\n);
-   goto err6;
+   goto err7;
}
 
ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
if (ret) {
dev_err(pdev-dev, failed to add platform_data\n);
-   goto err6;
+   goto err7;
}
 
ret = platform_device_add(musb);
if (ret) {
dev_err(pdev-dev, failed to register musb device\n);
-   goto err6;
+   goto err7;
}
 
return 0;
 
-err6:
+err7:
clk_disable(clk);
 
-err5:
+err6:
clk_disable(phy_clk);
 
-err4:
+err5:
clk_put(clk);
 
-err3:
+err4:
clk_put(phy_clk);
 
-err2:
+err3:
platform_device_put(musb);
 
+err2:
+   musb_put_id(pdev-dev, musbid);
+
 err1:
kfree(glue);
 
@@ -567,6 +580,7 @@ static int __devexit am35x_remove(struct platform_device 
*pdev)
 {
struct am35x_glue   *glue = platform_get_drvdata(pdev);
 
+   musb_put_id(pdev-dev, glue-musb-id);
platform_device_del(glue-musb);
platform_device_put(glue-musb);
clk_disable(glue-clk);
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 428e6aa..c848b82 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -471,6 +471,7 @@ static int __devinit bfin_probe(struct platform_device 
*pdev)
struct bfin_glue*glue;
 
int ret = -ENOMEM;
+   int musbid;
 
glue = kzalloc(sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -478,12 +479,21 @@ static int __devinit bfin_probe(struct platform_device 
*pdev)
goto err0;
}
 
-   musb = 

[PATCH v6 02/11] usb: musb: kill global and static for multi instance

[Ravi B]

From: Ajay Kumar Gupta ajay.gu...@ti.com

Moved global variable musb_debugfs_root and static variable
old_state to 'struct musb' to help support multi instance of
musb controller as present on AM335x platform.

Also removed the global variable orig_dma_mask and filled the
dev-dma_mask with parent device's dma_mask.

Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi B ravib...@ti.com
---
 drivers/usb/musb/musb_core.c|   22 +++---
 drivers/usb/musb/musb_core.h|4 
 drivers/usb/musb/musb_debugfs.c |8 +++-
 3 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index a565fc2..e781800 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -100,6 +100,7 @@
 #include linux/platform_device.h
 #include linux/io.h
 #include linux/idr.h
+#include linux/dma-mapping.h
 
 #include musb_core.h
 
@@ -1804,10 +1805,9 @@ static const struct attribute_group musb_attr_group = {
 static void musb_irq_work(struct work_struct *data)
 {
struct musb *musb = container_of(data, struct musb, irq_work);
-   static int old_state;
 
-   if (musb-xceiv-state != old_state) {
-   old_state = musb-xceiv-state;
+   if (musb-xceiv-state != musb-xceiv_old_state) {
+   musb-xceiv_old_state = musb-xceiv-state;
sysfs_notify(musb-controller-kobj, NULL, mode);
}
 }
@@ -2115,11 +2115,6 @@ fail0:
 /* all implementations (PCI bridge to FPGA, VLYNQ, etc) should just
  * bridge to a platform device; this driver then suffices.
  */
-
-#ifndef CONFIG_MUSB_PIO_ONLY
-static u64 *orig_dma_mask;
-#endif
-
 static int __devinit musb_probe(struct platform_device *pdev)
 {
struct device   *dev = pdev-dev;
@@ -2138,10 +2133,6 @@ static int __devinit musb_probe(struct platform_device 
*pdev)
return -ENOMEM;
}
 
-#ifndef CONFIG_MUSB_PIO_ONLY
-   /* clobbered by use_dma=n */
-   orig_dma_mask = dev-dma_mask;
-#endif
status = musb_init_controller(dev, irq, base);
if (status  0)
iounmap(base);
@@ -2151,7 +2142,8 @@ static int __devinit musb_probe(struct platform_device 
*pdev)
 
 static int __devexit musb_remove(struct platform_device *pdev)
 {
-   struct musb *musb = dev_to_musb(pdev-dev);
+   struct device   *dev = pdev-dev;
+   struct musb *musb = dev_to_musb(dev);
void __iomem*ctrl_base = musb-ctrl_base;
 
/* this gets called on rmmod.
@@ -2164,9 +2156,9 @@ static int __devexit musb_remove(struct platform_device 
*pdev)
 
musb_free(musb);
iounmap(ctrl_base);
-   device_init_wakeup(pdev-dev, 0);
+   device_init_wakeup(dev, 0);
 #ifndef CONFIG_MUSB_PIO_ONLY
-   pdev-dev.dma_mask = orig_dma_mask;
+   dma_set_mask(dev, *dev-parent-dma_mask);
 #endif
return 0;
 }
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 84436f7..5ec32b9 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -450,6 +450,10 @@ struct musb {
 #ifdef MUSB_CONFIG_PROC_FS
struct proc_dir_entry *proc_entry;
 #endif
+   int xceiv_old_state;
+#ifdef CONFIG_DEBUG_FS
+   struct dentry   *debugfs_root;
+#endif
 };
 
 static inline struct musb *gadget_to_musb(struct usb_gadget *g)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 40a37c9..1d6e8af 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -103,8 +103,6 @@ static const struct musb_register_map musb_regmap[] = {
{  }/* Terminating Entry */
 };
 
-static struct dentry *musb_debugfs_root;
-
 static int musb_regdump_show(struct seq_file *s, void *unused)
 {
struct musb *musb = s-private;
@@ -241,7 +239,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
struct dentry   *file;
int ret;
 
-   root = debugfs_create_dir(musb, NULL);
+   root = debugfs_create_dir(dev_name(musb-controller), NULL);
if (!root) {
ret = -ENOMEM;
goto err0;
@@ -261,7 +259,7 @@ int __devinit musb_init_debugfs(struct musb *musb)
goto err1;
}
 
-   musb_debugfs_root = root;
+   musb-debugfs_root = root;
 
return 0;
 
@@ -274,5 +272,5 @@ err0:
 
 void /* __init_or_exit */ musb_exit_debugfs(struct musb *musb)
 {
-   debugfs_remove_recursive(musb_debugfs_root);
+   debugfs_remove_recursive(musb-debugfs_root);
 }
-- 
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 v6 10/11] usb: musb: dsps: get the PHY using phandle api

[Ravi B]

From: Ajay Kumar Gupta ajay.gu...@ti.com

AM33xx has two PHY of same type used by each musb controller so
use phandle of phy nodes to get the phy pointer.

Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi B ravib...@ti.com
---
 .../devicetree/bindings/usb/am33xx-usb.txt |2 ++
 drivers/usb/musb/musb_dsps.c   |4 +++-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt 
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index 9782585..e2702df 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,6 +12,8 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
  - power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+ - usb0-phy : phandle for usb0 NOP PHY
+ - usb1-phy : phandle for usb1 NOP PHY
 
 NOP USB PHY
  - compatible : Should be nop-xceiv-usb
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 24b2e4a..c2d053b 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -423,6 +423,7 @@ static int dsps_musb_init(struct musb *musb)
struct dsps_glue *glue = platform_get_drvdata(parent_pdev);
const struct dsps_musb_wrapper *wrp = glue-wrp;
void __iomem *reg_base = musb-ctrl_base;
+   char name[10];
u32 rev, val;
int status;
 
@@ -430,7 +431,8 @@ static int dsps_musb_init(struct musb *musb)
musb-mregs += wrp-musb_core_offset;
 
/* Get the NOP PHY */
-   musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
+   sprintf(name, usb%d-phy, pdev-id);
+   musb-xceiv = devm_usb_get_phy_by_phandle(parent_pdev-dev, name);
if (IS_ERR_OR_NULL(musb-xceiv))
return -ENODEV;
 
-- 
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 v6 06/11] arm/dts: am33xx: Add dt data for usbss

[Ravi B]

From: Ajay Kumar Gupta ajay.gu...@ti.com

Added device tree data for usbss on am33xx. There are two musb controllers
on am33xx platform so have port0_mode and port1_mode additional data.

Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Ravi B ravib...@ti.com
---
 arch/arm/boot/dts/am33xx.dtsi |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..08e9a40 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -154,5 +154,16 @@
#size-cells = 0;
ti,hwmods = i2c3;
};
+
+   usb_otg_hs: usb_otg_hs {
+   compatible = ti,musb-am33xx;
+   ti,hwmods = usb_otg_hs;
+   multipoint = 1;
+   num_eps = 16;
+   ram_bits = 12;
+   port0_mode = 3;
+   port1_mode = 1;
+   power = 250;
+   };
};
 };
-- 
1.7.0.4

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

Re: [PATCH RESEND v2 1/2] arm/dts: Add AM33XX basic pinctrl support

[Peter Ujfalusi]

Hi,

On 07/24/2012 06:45 PM, AnilKumar Ch wrote:
 Adds basic pinctrl support for AM33XX family of devices. This patch
 is based on the pinctrl-simple driver submitted by Tony Lindgren's
 here: http://lwn.net/Articles/496075/
 
 Signed-off-by: AnilKumar Ch anilku...@ti.com
 ---
  arch/arm/boot/dts/am33xx.dtsi |9 +
  1 file changed, 9 insertions(+)
 
 diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
 index 59509c4..9b974dc 100644
 --- a/arch/arm/boot/dts/am33xx.dtsi
 +++ b/arch/arm/boot/dts/am33xx.dtsi
 @@ -40,6 +40,15 @@
   };
   };
  
 + am3358_pinmux: pinmux@44E10800 {
 + compatible = pinctrl-single;
 + reg = 0x44E10800 0x0338;

I'm just curious about the size here: how it ended up as 0x0338?
While looking at the TRM of AM335x I can come up with 0x0238 (0x44e10800 -
0x44e10a38), but I don't see any sings of the remaining 0x0100 to be
documented at least.

 + #address-cells = 1;
 + #size-cells = 0;
 + pinctrl-single,register-width = 32;
 + pinctrl-single,function-mask = 0x7F;
 + };
 +
   /*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex.Since
 
-- 
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

OMAP: Configuring CONTROL_DEVCONF0 register via DT with pinctrl

[Peter Ujfalusi]

Hello,

I need to find a solution to control 2 bits in CONTROL_DEVCONF0 on OMAP2/3 for
McBSP1 CLKR/FSR signal routing.
In boards using McBSP1 we might need to change bit 3 and 4 based on the audio
setup (how the board has been wired).

So far I have come up with the following idea to handle to but not really sure
if it is the correct way (I have taken the idea from the arm/dts: Add AM33XX
basic pinctrl support series).

In .dtsi file of the SoC:

control_devconf0: pinmux@48002274 {
compatible = pinctrl-single;
reg = 0x48002274 4;   /* Single register */
#address-cells = 1;
#size-cells = 0;
pinctrl-single,register-width = 32;
pinctrl-single,function-mask = 0x5F;
};

In the .dts file of the board which needs to change the CLKR/FSR configuration:

control_devconf0 {
pinctrl-names = default;
pinctrl-0 = mcbsp1_pins;

mcbsp1_pins: pinmux_mcbsp1_pins {
pinctrl-single,pins = 0x00 0x18; /* CLKR/FSR from CLKX/FSX
* pin */
};

};

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

Re: [PATCH V4 0/5] ARM: OMAP: HOST: TLL driver implementation

[Munegowda, Keshava]

On Mon, Jul 23, 2012 at 8:04 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
 On Mon, Jul 23, 2012 at 7:38 PM, Felipe Balbi ba...@ti.com wrote:
 Hi,

 On Mon, Jul 23, 2012 at 07:31:10PM +0530, Munegowda, Keshava wrote:
 On Thu, Jul 19, 2012 at 3:48 PM, Munegowda, Keshava
 keshava_mgo...@ti.com wrote:
  On Mon, Jul 16, 2012 at 7:01 PM, Keshava Munegowda
  keshava_mgo...@ti.com wrote:
  The TLL (Transceiver Less Link) is an separate IP block, independent of
  the host controller. Basically this TLL operates like USB PHY which 
  allows
  the user to connect two USB transceiver interfaces together directly
  without the use of differential transceivers in omap3 and later chips.
  The TLL configuration is removed from the UHH driver and implemented as
  a seperate platform driver. Now, the UHH driver configures the TLL
  through API's exported by the TLL platform driver.
 
  Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
 
  In v4:
  - rebased on top of linux kernel version 3.5.rc7
  - reworked as per the comments given by Paul Walmsley 
  p...@pwsan.com
 
  In v3:
- rebased on top V3 of Russ dill's patch
 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue'
 fixes an issue where the ULPI PHYs were not held in reset
 while initializing the EHCI controller
  http://permalink.gmane.org/gmane.linux.usb.general/65988
 
- rebased on top of patch
  OMAP: USB : Fix the EHCI enumeration and core retention issue
   http://permalink.gmane.org/gmane.linux.usb.general/66239
 
  In V2:
  - covered review comments from linux omap and usb community
  - rebased on top Russ dill's patch
 'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue'
 fixes an issue where the ULPI PHYs were not held in reset
 while initializing the EHCI controller
 
  Keshava Munegowda (5):
ARM: OMAP: Add the USB TLL clocks device name
ARM: OMAP: USB: HOST TLL platform driver
ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver
ARM: OMAP: USB: Remove TLL specific code from USB HS core driver
ARM: OMAP: Remove older device name of the USB TLL clocks
 
   arch/arm/mach-omap2/clock3xxx_data.c  |8 +-
   arch/arm/mach-omap2/clock44xx_data.c  |4 +-
   arch/arm/mach-omap2/usb-host.c|   31 ++-
   arch/arm/plat-omap/include/plat/usb.h |7 +
   drivers/mfd/Kconfig   |2 +-
   drivers/mfd/Makefile  |2 +-
   drivers/mfd/omap-usb-host.c   |  238 ++---
   drivers/mfd/omap-usb-tll.c|  471 
  +
   8 files changed, 523 insertions(+), 240 deletions(-)
   create mode 100644 drivers/mfd/omap-usb-tll.c
 
  --
  1.7.9.5
 
 
  Felipe/ Paul
please let me know if you have any review comments on this v4 
  series.
 
  regards
  keshava

 Hi Felipe
   please let me know if you have any review comments on this series 
 now.

 looks ok... pretty much just moving code around.

 --
 balbi


 Thanks Felipe

 then I request please give your Ack by for this series.

 regards
 keshava

Hi Paul
do you have any review comments on this series?
Felipe is OK with this series.  if there are no review comments on this series
I request your ack by for the same.
Once this series gets in to mainline. i will start the Device tree
conversion for usb2 host.

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

Re: [PATCH] mfd/regulator: tps65217: Move regulator plat data handling to regulator

[Samuel Ortiz]

Hi Anilkumar,

On Fri, Jul 20, 2012 at 03:00:01PM +0530, AnilKumar Ch wrote:
 Regulator platform data handling was mistakenly added to MFD
 driver. So we will see build errors if we compile MFD drivers
 without CONFIG_REGULATOR. This patch moves regulator platform
 data handling from TPS65217 MFD driver to regulator driver.
 
 This makes MFD driver independent of REGULATOR framework so
 build error is fixed if CONFIG_REGULATOR is not set.
 
 drivers/built-in.o: In function `tps65217_probe':
 tps65217.c:(.devinit.text+0x13e37): undefined reference
 to `of_regulator_match'
 
 This patch is based on linux-next (20120720) tree
 
 Signed-off-by: AnilKumar Ch anilku...@ti.com
 ---
  drivers/mfd/tps65217.c |  130 
 +++-
  drivers/regulator/tps65217-regulator.c |  124 ++
  include/linux/mfd/tps65217.h   |   12 ++-
  3 files changed, 161 insertions(+), 105 deletions(-)
It doesn't apply to my for-next branch. Could you please re-send this one
after the merge window is closed ? I'll push that as part of the MFD fixes for
3.6.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP3xxx: clockdomain: fix software supervised wakeup/sleep

[Kevin Hilman]

Nayak, Rajendra rna...@ti.com writes:

 Paul,

 On Fri, Jul 27, 2012 at 2:34 AM, Paul Walmsley p...@pwsan.com wrote:

 Commit 4da71ae6 (OMAP: clockdomain: Arch specific funcs for
 clkdm_clk_enable/disable) called the OMAP2xxx-specific functions for
 clockdomain wakeup and sleep.  This would probably have broken
 software-supervised clockdomain wakeup and sleep on OMAP3.

 Would something like this be better than duplicating most of
 omap2_clkdm_clk_enable/disable?

Not when using cpu_is* checks at runtime.  Maybe if you setup function
pointers at init time?

Kevin

 ---
  arch/arm/mach-omap2/clockdomain2xxx_3xxx.c |   25 +++--
  1 file changed, 23 insertions(+), 2 deletions(-)

 Index: linux-2.6/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 ===
 --- linux-2.6.orig/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 2012-07-27 13:15:49.238134472 +0530
 +++ linux-2.6/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 2012-07-27 13:22:01.607380032 +0530
 @@ -162,6 +162,27 @@
 clkdm-clktrctrl_mask);
  }

 +static void _clkdm_sleep(struct clockdomain *clkdm)
 +{
 +   if (cpu_is_omap24xx())
 +   omap2_cm_set_mod_reg_bits(OMAP24XX_FORCESTATE_MASK,
 +   clkdm-pwrdm.ptr-prcm_offs,
 +   OMAP2_PM_PWSTCTRL);
 +   else if (cpu_is_omap34xx())
 +   omap3xxx_cm_clkdm_force_sleep(clkdm-pwrdm.ptr-prcm_offs,
 +   clkdm-clktrctrl_mask);
 +}
 +
 +static void _clkdm_wakeup(struct clockdomain *clkdm)
 +{
 +   if (cpu_is_omap24xx())
 +   omap2_cm_clear_mod_reg_bits(OMAP24XX_FORCESTATE_MASK,
 +   clkdm-pwrdm.ptr-prcm_offs,
 +   OMAP2_PM_PWSTCTRL);
 +   else if (cpu_is_omap34xx())
 +   omap3xxx_cm_clkdm_force_wakeup(clkdm-pwrdm.ptr-prcm_offs,
 +   clkdm-clktrctrl_mask);
 +}

  static int omap2_clkdm_clk_enable(struct clockdomain *clkdm)
  {
 @@ -180,7 +201,7 @@
 _enable_hwsup(clkdm);
 } else {
 if (clkdm-flags  CLKDM_CAN_FORCE_WAKEUP)
 -   omap2_clkdm_wakeup(clkdm);
 +   _clkdm_wakeup(clkdm);
 }

 return 0;
 @@ -203,7 +224,7 @@
 _enable_hwsup(clkdm);
 } else {
 if (clkdm-flags  CLKDM_CAN_FORCE_SLEEP)
 -   omap2_clkdm_sleep(clkdm);
 +   _clkdm_sleep(clkdm);
 }


 Signed-off-by: Paul Walmsley p...@pwsan.com
 Cc: Rajendra Nayak rna...@ti.com
 Cc: Jon Hunter jon-hun...@ti.com
 ---
  arch/arm/mach-omap2/clockdomain2xxx_3xxx.c |   50 
 ++--
  1 file changed, 48 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c 
 b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 index a0d68db..f99e65c 100644
 --- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 +++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 @@ -241,6 +241,52 @@ static void omap3_clkdm_deny_idle(struct clockdomain 
 *clkdm)
 _clkdm_del_autodeps(clkdm);
  }

 +static int omap3xxx_clkdm_clk_enable(struct clockdomain *clkdm)
 +{
 +   bool hwsup = false;
 +
 +   if (!clkdm-clktrctrl_mask)
 +   return 0;
 +
 +   hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm-pwrdm.ptr-prcm_offs,
 +   clkdm-clktrctrl_mask);
 +
 +   if (hwsup) {
 +   /* Disable HW transitions when we are changing deps */
 +   _disable_hwsup(clkdm);
 +   _clkdm_add_autodeps(clkdm);
 +   _enable_hwsup(clkdm);
 +   } else {
 +   if (clkdm-flags  CLKDM_CAN_FORCE_WAKEUP)
 +   omap3_clkdm_wakeup(clkdm);
 +   }
 +
 +   return 0;
 +}
 +
 +static int omap3xxx_clkdm_clk_disable(struct clockdomain *clkdm)
 +{
 +   bool hwsup = false;
 +
 +   if (!clkdm-clktrctrl_mask)
 +   return 0;
 +
 +   hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm-pwrdm.ptr-prcm_offs,
 +   clkdm-clktrctrl_mask);
 +
 +   if (hwsup) {
 +   /* Disable HW transitions when we are changing deps */
 +   _disable_hwsup(clkdm);
 +   _clkdm_del_autodeps(clkdm);
 +   _enable_hwsup(clkdm);
 +   } else {
 +   if (clkdm-flags  CLKDM_CAN_FORCE_SLEEP)
 +   omap3_clkdm_sleep(clkdm);
 +   }
 +
 +   return 0;
 +}
 +
  struct clkdm_ops omap2_clkdm_operations = {
 .clkdm_add_wkdep= omap2_clkdm_add_wkdep,
 .clkdm_del_wkdep= omap2_clkdm_del_wkdep,
 @@ -267,6 +313,6 @@ struct clkdm_ops omap3_clkdm_operations = {
 .clkdm_wakeup   = omap3_clkdm_wakeup,
 .clkdm_allow_idle   = omap3_clkdm_allow_idle,
 

rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Russell King - ARM Linux]

On Wed, Jul 25, 2012 at 03:12:22PM +0100, Russell King - ARM Linux wrote:
 Just a quick reminder that I'm still on holiday, and at this point there
 are over 2500 messages from the mailing lists which are sitting unread
 since I left the UK.  As I mentioned before I left the UK, it is my
 intention *not* to go back and read all those outstanding messages -
 there's too many of them to do that.
 
 So, if you want me to react to any email message you've sent, you'd
 *better* send it again next week unless I've already responded.
 
 Meanwhile, I see v3.5 has been released; I have a couple of things I
 need to do with my tree before I can push the changes, and I'll
 probably see about sorting those out over the weekend.  I also see
 that 14 new patches have landed in the patch system.
 
 However, the timing of my holiday vs the merge window means that I
 can't take anything new, unless they're fixes, so don't be surprised
 if some stuff gets missed this merge window.

Right.  I'm not fully recovered from the jet lag (I'm still rather tired
- I hate travelling back from the North American continent because it
takes days to recover.)

I have now archived off *all* email sent to me during July - which means
that I will *NOT* be responding to anything sent during the last 17 days.
If anyone has sent me anything important, it *MUST* be resent now.

I am aware of an issue concerning the OMAP DMA patches.  I'm not sure
exactly what is required there, so I've dropped them from my planned pull
request in the interests of getting everything else I have to Linus.  I
may plan to send a pull request this evening.

I've not yet looked at merging *anything* which is in the patch system,
that's for when I feel more awake.
--
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: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Jon Hunter]

Hi Russell,

On 07/27/2012 08:42 AM, Russell King - ARM Linux wrote:
 On Wed, Jul 25, 2012 at 03:12:22PM +0100, Russell King - ARM Linux wrote:
 Just a quick reminder that I'm still on holiday, and at this point there
 are over 2500 messages from the mailing lists which are sitting unread
 since I left the UK.  As I mentioned before I left the UK, it is my
 intention *not* to go back and read all those outstanding messages -
 there's too many of them to do that.

 So, if you want me to react to any email message you've sent, you'd
 *better* send it again next week unless I've already responded.

 Meanwhile, I see v3.5 has been released; I have a couple of things I
 need to do with my tree before I can push the changes, and I'll
 probably see about sorting those out over the weekend.  I also see
 that 14 new patches have landed in the patch system.

 However, the timing of my holiday vs the merge window means that I
 can't take anything new, unless they're fixes, so don't be surprised
 if some stuff gets missed this merge window.
 
 Right.  I'm not fully recovered from the jet lag (I'm still rather tired
 - I hate travelling back from the North American continent because it
 takes days to recover.)

Welcome back!

 I have now archived off *all* email sent to me during July - which means
 that I will *NOT* be responding to anything sent during the last 17 days.
 If anyone has sent me anything important, it *MUST* be resent now.

I took a look at your git tree and I am not sure if I have missed it,
but wanted to check if have [1] queued?

Thanks
Jon

[1] http://marc.info/?l=linux-omapm=134053393317444w=2
--
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: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Russell King - ARM Linux]

On Fri, Jul 27, 2012 at 10:20:32AM -0500, Jon Hunter wrote:
 Hi Russell,
 
 On 07/27/2012 08:42 AM, Russell King - ARM Linux wrote:
  On Wed, Jul 25, 2012 at 03:12:22PM +0100, Russell King - ARM Linux wrote:
  Just a quick reminder that I'm still on holiday, and at this point there
  are over 2500 messages from the mailing lists which are sitting unread
  since I left the UK.  As I mentioned before I left the UK, it is my
  intention *not* to go back and read all those outstanding messages -
  there's too many of them to do that.
 
  So, if you want me to react to any email message you've sent, you'd
  *better* send it again next week unless I've already responded.
 
  Meanwhile, I see v3.5 has been released; I have a couple of things I
  need to do with my tree before I can push the changes, and I'll
  probably see about sorting those out over the weekend.  I also see
  that 14 new patches have landed in the patch system.
 
  However, the timing of my holiday vs the merge window means that I
  can't take anything new, unless they're fixes, so don't be surprised
  if some stuff gets missed this merge window.
  
  Right.  I'm not fully recovered from the jet lag (I'm still rather tired
  - I hate travelling back from the North American continent because it
  takes days to recover.)
 
 Welcome back!
 
  I have now archived off *all* email sent to me during July - which means
  that I will *NOT* be responding to anything sent during the last 17 days.
  If anyone has sent me anything important, it *MUST* be resent now.
 
 I took a look at your git tree and I am not sure if I have missed it,
 but wanted to check if have [1] queued?

Well, it isn't in the patch system, so I guess it never got applied.
--
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: OMAP2+: ads7846 init: fix fault caused by freeing pen-down GPIO

[Igor Grinberg]

On 07/26/12 22:30, Kevin Hilman wrote:
 + Zumeng Chen
 
 Igor Grinberg grinb...@compulab.co.il writes:
 
 Hi Kevin,

 I've just noticed that the patch has been modified by Arnd in a way
 that of course will trigger GPIO use without being requested.
 I'm sorry, I was not available by that time Arnd changed the patch.
 
 Your right, your original patch isn't the problem.  I found the root
 cause.
 
 The real problem is actually introduced by the merge of your patch from
 the arm-soc/cleanup branch, and this one from Zumeng Chen: commit
 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce time for
 ads7846) from the arm-soc/boards branch.
 
 However, looking closer at the one from Zumeng, that one is clearly not
 right.  It unconditionally adds a *board-specific* -get_pendown_state
 function to the pdata that is common to *all* boards.  That's just wrong
 and has the side-effect of making -get_pendown_state() wrong on every
 board except the OMAP3EVM.  Oops.

Argh... that should not be applied in first place...
I double sorry, I was not available when that conflict was resolved...
The right resolution would be just to revert the 16aced80f6
(ARM: OMAP3530evm: set pendown_state and debounce time for ads7846),
but who cares now...

 
 So, IMO, in addition to $SUBJECT patch, in order to get the touchscreen
 GPIO working on non OMAP3EVM boards, we also need something like this as
 well.
 
 Igor, Zumeng, could you try this out on your boards anc confirm if it's
 working?  I currently don't have a board setup with a touchscreen in my
 board farm.

Since you have already dig into this, which branch would be good for testing?

 
 Kevin
 
From 85516c6a3354967caf4cff434d28c3001cd411eb Mon Sep 17 00:00:00 2001
 From: Kevin Hilman khil...@ti.com
 Date: Thu, 26 Jul 2012 12:15:38 -0700
 Subject: [PATCH 2/2] ARM: OMAP2+: ads7846: fix -get_pendown_state() to work
  on all boards
 
 commit 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce
 time for ads7846) introduced a common -get_pendown_state() function
 into the generic code, but that function was board-specific for the
 OMAP3EVM.
 
 Fix this up to work for all boards that pass in a pendown GPIO.
 
 Cc: Zumeng Chen zumeng.c...@windriver.com
 Cc: Igor Grinberg grinb...@compulab.co.il
 Signed-off-by: Kevin Hilman khil...@ti.com
 ---
  arch/arm/mach-omap2/board-omap3evm.c   |1 +
  arch/arm/mach-omap2/common-board-devices.c |4 +++-
  arch/arm/mach-omap2/common-board-devices.h |1 -
  3 files changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
 b/arch/arm/mach-omap2/board-omap3evm.c
 index ef230a0..0d362e9 100644
 --- a/arch/arm/mach-omap2/board-omap3evm.c
 +++ b/arch/arm/mach-omap2/board-omap3evm.c
 @@ -58,6 +58,7 @@
  #include hsmmc.h
  #include common-board-devices.h
  
 +#define OMAP3_EVM_TS_GPIO175
  #define OMAP3_EVM_EHCI_VBUS  22
  #define OMAP3_EVM_EHCI_SELECT61
  
 diff --git a/arch/arm/mach-omap2/common-board-devices.c 
 b/arch/arm/mach-omap2/common-board-devices.c
 index 0fee95f..06f176f 100644
 --- a/arch/arm/mach-omap2/common-board-devices.c
 +++ b/arch/arm/mach-omap2/common-board-devices.c
 @@ -40,9 +40,10 @@ static struct omap2_mcspi_device_config 
 ads7846_mcspi_config = {
   * of pdata-get_pendown_state, but we have done this. So set
   * get_pendown_state to avoid twice gpio requesting.
   */
 +static int omap3_gpio_pendown;
  static int omap3_get_pendown_state(void)
  {
 - return !gpio_get_value(OMAP3_EVM_TS_GPIO);
 + return !gpio_get_value(omap3_gpio_pendown);
  }
  
  static struct ads7846_platform_data ads7846_config = {
 @@ -74,6 +75,7 @@ void __init omap_ads7846_init(int bus_num, int 
 gpio_pendown, int gpio_debounce,
   struct spi_board_info *spi_bi = ads7846_spi_board_info;
   int err;
  
 + omap3_gpio_pendown = gpio_pendown;
   err = gpio_request_one(gpio_pendown, GPIOF_IN, TSPenDown);
   if (err) {
   pr_err(Couldn't obtain gpio for TSPenDown: %d\n, err);
 diff --git a/arch/arm/mach-omap2/common-board-devices.h 
 b/arch/arm/mach-omap2/common-board-devices.h
 index 4c4ef6a..a0b4a428 100644
 --- a/arch/arm/mach-omap2/common-board-devices.h
 +++ b/arch/arm/mach-omap2/common-board-devices.h
 @@ -4,7 +4,6 @@
  #include twl-common.h
  
  #define NAND_BLOCK_SIZE  SZ_128K
 -#define OMAP3_EVM_TS_GPIO175
  
  struct mtd_partition;
  struct ads7846_platform_data;

-- 
Regards,
Igor.
--
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: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Shilimkar, Santosh]

On Fri, Jul 27, 2012 at 3:42 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Wed, Jul 25, 2012 at 03:12:22PM +0100, Russell King - ARM Linux wrote:
 Just a quick reminder that I'm still on holiday, and at this point there
 are over 2500 messages from the mailing lists which are sitting unread
 since I left the UK.  As I mentioned before I left the UK, it is my
 intention *not* to go back and read all those outstanding messages -
 there's too many of them to do that.

 So, if you want me to react to any email message you've sent, you'd
 *better* send it again next week unless I've already responded.

 Meanwhile, I see v3.5 has been released; I have a couple of things I
 need to do with my tree before I can push the changes, and I'll
 probably see about sorting those out over the weekend.  I also see
 that 14 new patches have landed in the patch system.

 However, the timing of my holiday vs the merge window means that I
 can't take anything new, unless they're fixes, so don't be surprised
 if some stuff gets missed this merge window.

 Right.  I'm not fully recovered from the jet lag (I'm still rather tired
 - I hate travelling back from the North American continent because it
 takes days to recover.)

 I have now archived off *all* email sent to me during July - which means
 that I will *NOT* be responding to anything sent during the last 17 days.
 If anyone has sent me anything important, it *MUST* be resent now.

 I am aware of an issue concerning the OMAP DMA patches.  I'm not sure
 exactly what is required there, so I've dropped them from my planned pull
 request in the interests of getting everything else I have to Linus.  I
 may plan to send a pull request this evening.

Well the only pending discussion was enabling the CONFIG option for
DMA at driver level SOC config level. Not sure if there was anything else
on this really.

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

Re: rmk back but still recovering (was Re: Reminder - rmk still on vacation)

[Russell King - ARM Linux]

On Fri, Jul 27, 2012 at 06:08:13PM +0200, Shilimkar, Santosh wrote:
 On Fri, Jul 27, 2012 at 3:42 PM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
  On Wed, Jul 25, 2012 at 03:12:22PM +0100, Russell King - ARM Linux wrote:
  Just a quick reminder that I'm still on holiday, and at this point there
  are over 2500 messages from the mailing lists which are sitting unread
  since I left the UK.  As I mentioned before I left the UK, it is my
  intention *not* to go back and read all those outstanding messages -
  there's too many of them to do that.
 
  So, if you want me to react to any email message you've sent, you'd
  *better* send it again next week unless I've already responded.
 
  Meanwhile, I see v3.5 has been released; I have a couple of things I
  need to do with my tree before I can push the changes, and I'll
  probably see about sorting those out over the weekend.  I also see
  that 14 new patches have landed in the patch system.
 
  However, the timing of my holiday vs the merge window means that I
  can't take anything new, unless they're fixes, so don't be surprised
  if some stuff gets missed this merge window.
 
  Right.  I'm not fully recovered from the jet lag (I'm still rather tired
  - I hate travelling back from the North American continent because it
  takes days to recover.)
 
  I have now archived off *all* email sent to me during July - which means
  that I will *NOT* be responding to anything sent during the last 17 days.
  If anyone has sent me anything important, it *MUST* be resent now.
 
  I am aware of an issue concerning the OMAP DMA patches.  I'm not sure
  exactly what is required there, so I've dropped them from my planned pull
  request in the interests of getting everything else I have to Linus.  I
  may plan to send a pull request this evening.
 
 Well the only pending discussion was enabling the CONFIG option for
 DMA at driver level SOC config level. Not sure if there was anything else
 on this really.

Why?  The DMA driver itself is optional.
--
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/1 v2] ARM: only call smp_send_stop() on SMP

[Jon Hunter]

Hi Javier,

On 06/25/2012 05:31 AM, Javier Martinez Canillas wrote:
 On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
 On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
 It seems the same patch has been there for a while.

 http://thread.gmane.org/gmane.linux.kernel/1303115

 Bah, why doesn't stuff like this get resent if nothing has happened for
 a while?
 
 Indeed. At least other people that face the same issue (like me) sends
 similar patches to remind you :-)

I checked with Russell but this one is not in his patch tracking system
[1] and so still not queued. Can you submit this? Would be great to get
this one in.

Cheers
Jon

[1] http://www.arm.linux.org.uk/developer/patches/
--
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: OMAP2+: ads7846 init: fix fault caused by freeing pen-down GPIO

[Kevin Hilman]

Igor Grinberg grinb...@compulab.co.il writes:

 On 07/26/12 22:30, Kevin Hilman wrote:
 + Zumeng Chen
 
 Igor Grinberg grinb...@compulab.co.il writes:
 
 Hi Kevin,

 I've just noticed that the patch has been modified by Arnd in a way
 that of course will trigger GPIO use without being requested.
 I'm sorry, I was not available by that time Arnd changed the patch.
 
 Your right, your original patch isn't the problem.  I found the root
 cause.
 
 The real problem is actually introduced by the merge of your patch from
 the arm-soc/cleanup branch, and this one from Zumeng Chen: commit
 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce time for
 ads7846) from the arm-soc/boards branch.
 
 However, looking closer at the one from Zumeng, that one is clearly not
 right.  It unconditionally adds a *board-specific* -get_pendown_state
 function to the pdata that is common to *all* boards.  That's just wrong
 and has the side-effect of making -get_pendown_state() wrong on every
 board except the OMAP3EVM.  Oops.

 Argh... that should not be applied in first place...

Agreed, but it's already in mainline.

 I double sorry, I was not available when that conflict was resolved...
 The right resolution would be just to revert the 16aced80f6
 (ARM: OMAP3530evm: set pendown_state and debounce time for ads7846),
 but who cares now...



 
 So, IMO, in addition to $SUBJECT patch, in order to get the touchscreen
 GPIO working on non OMAP3EVM boards, we also need something like this as
 well.
 
 Igor, Zumeng, could you try this out on your boards anc confirm if it's
 working?  I currently don't have a board setup with a touchscreen in my
 board farm.

 Since you have already dig into this, which branch would be good for testing?


git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
for_3.6/fixes/ads7846

I just pushed this out, so it might take a bit to propagate to all the
mirrors.

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

Re: [PATCH] ARM: OMAP2+: ads7846 init: fix fault caused by freeing pen-down GPIO

[Igor Grinberg]

On 07/26/12 22:30, Kevin Hilman wrote:
 + Zumeng Chen
 
 Igor Grinberg grinb...@compulab.co.il writes:
 
 Hi Kevin,

 I've just noticed that the patch has been modified by Arnd in a way
 that of course will trigger GPIO use without being requested.
 I'm sorry, I was not available by that time Arnd changed the patch.
 
 Your right, your original patch isn't the problem.  I found the root
 cause.
 
 The real problem is actually introduced by the merge of your patch from
 the arm-soc/cleanup branch, and this one from Zumeng Chen: commit
 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce time for
 ads7846) from the arm-soc/boards branch.
 
 However, looking closer at the one from Zumeng, that one is clearly not
 right.  It unconditionally adds a *board-specific* -get_pendown_state
 function to the pdata that is common to *all* boards.  That's just wrong
 and has the side-effect of making -get_pendown_state() wrong on every
 board except the OMAP3EVM.  Oops.
 
 So, IMO, in addition to $SUBJECT patch, in order to get the touchscreen
 GPIO working on non OMAP3EVM boards, we also need something like this as
 well.
 
 Igor, Zumeng, could you try this out on your boards anc confirm if it's
 working?  I currently don't have a board setup with a touchscreen in my
 board farm.
 
 Kevin
 
From 85516c6a3354967caf4cff434d28c3001cd411eb Mon Sep 17 00:00:00 2001
 From: Kevin Hilman khil...@ti.com
 Date: Thu, 26 Jul 2012 12:15:38 -0700
 Subject: [PATCH 2/2] ARM: OMAP2+: ads7846: fix -get_pendown_state() to work
  on all boards
 
 commit 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce
 time for ads7846) introduced a common -get_pendown_state() function
 into the generic code, but that function was board-specific for the
 OMAP3EVM.
 
 Fix this up to work for all boards that pass in a pendown GPIO.
 
 Cc: Zumeng Chen zumeng.c...@windriver.com
 Cc: Igor Grinberg grinb...@compulab.co.il
 Signed-off-by: Kevin Hilman khil...@ti.com

Tested-by: Igor Grinberg grinb...@compulab.co.il

 ---
  arch/arm/mach-omap2/board-omap3evm.c   |1 +
  arch/arm/mach-omap2/common-board-devices.c |4 +++-
  arch/arm/mach-omap2/common-board-devices.h |1 -
  3 files changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
 b/arch/arm/mach-omap2/board-omap3evm.c
 index ef230a0..0d362e9 100644
 --- a/arch/arm/mach-omap2/board-omap3evm.c
 +++ b/arch/arm/mach-omap2/board-omap3evm.c
 @@ -58,6 +58,7 @@
  #include hsmmc.h
  #include common-board-devices.h
  
 +#define OMAP3_EVM_TS_GPIO175
  #define OMAP3_EVM_EHCI_VBUS  22
  #define OMAP3_EVM_EHCI_SELECT61
  
 diff --git a/arch/arm/mach-omap2/common-board-devices.c 
 b/arch/arm/mach-omap2/common-board-devices.c
 index 0fee95f..06f176f 100644
 --- a/arch/arm/mach-omap2/common-board-devices.c
 +++ b/arch/arm/mach-omap2/common-board-devices.c
 @@ -40,9 +40,10 @@ static struct omap2_mcspi_device_config 
 ads7846_mcspi_config = {
   * of pdata-get_pendown_state, but we have done this. So set
   * get_pendown_state to avoid twice gpio requesting.
   */
 +static int omap3_gpio_pendown;
  static int omap3_get_pendown_state(void)
  {
 - return !gpio_get_value(OMAP3_EVM_TS_GPIO);
 + return !gpio_get_value(omap3_gpio_pendown);
  }
  
  static struct ads7846_platform_data ads7846_config = {
 @@ -74,6 +75,7 @@ void __init omap_ads7846_init(int bus_num, int 
 gpio_pendown, int gpio_debounce,
   struct spi_board_info *spi_bi = ads7846_spi_board_info;
   int err;
  
 + omap3_gpio_pendown = gpio_pendown;
   err = gpio_request_one(gpio_pendown, GPIOF_IN, TSPenDown);
   if (err) {
   pr_err(Couldn't obtain gpio for TSPenDown: %d\n, err);
 diff --git a/arch/arm/mach-omap2/common-board-devices.h 
 b/arch/arm/mach-omap2/common-board-devices.h
 index 4c4ef6a..a0b4a428 100644
 --- a/arch/arm/mach-omap2/common-board-devices.h
 +++ b/arch/arm/mach-omap2/common-board-devices.h
 @@ -4,7 +4,6 @@
  #include twl-common.h
  
  #define NAND_BLOCK_SIZE  SZ_128K
 -#define OMAP3_EVM_TS_GPIO175
  
  struct mtd_partition;
  struct ads7846_platform_data;

-- 
Regards,
Igor.
--
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: OMAP2+: ads7846 init: fix fault caused by freeing pen-down GPIO

[Igor Grinberg]

On 07/27/12 20:46, Kevin Hilman wrote:
 Igor Grinberg grinb...@compulab.co.il writes:
 
 On 07/26/12 22:30, Kevin Hilman wrote:
 + Zumeng Chen

 Igor Grinberg grinb...@compulab.co.il writes:

 Hi Kevin,

 I've just noticed that the patch has been modified by Arnd in a way
 that of course will trigger GPIO use without being requested.
 I'm sorry, I was not available by that time Arnd changed the patch.

 Your right, your original patch isn't the problem.  I found the root
 cause.

 The real problem is actually introduced by the merge of your patch from
 the arm-soc/cleanup branch, and this one from Zumeng Chen: commit
 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce time for
 ads7846) from the arm-soc/boards branch.

 However, looking closer at the one from Zumeng, that one is clearly not
 right.  It unconditionally adds a *board-specific* -get_pendown_state
 function to the pdata that is common to *all* boards.  That's just wrong
 and has the side-effect of making -get_pendown_state() wrong on every
 board except the OMAP3EVM.  Oops.

 Argh... that should not be applied in first place...
 
 Agreed, but it's already in mainline.
 
 I double sorry, I was not available when that conflict was resolved...
 The right resolution would be just to revert the 16aced80f6
 (ARM: OMAP3530evm: set pendown_state and debounce time for ads7846),
 but who cares now...
 
 


 So, IMO, in addition to $SUBJECT patch, in order to get the touchscreen
 GPIO working on non OMAP3EVM boards, we also need something like this as
 well.

 Igor, Zumeng, could you try this out on your boards anc confirm if it's
 working?  I currently don't have a board setup with a touchscreen in my
 board farm.

 Since you have already dig into this, which branch would be good for testing?
 
 
 git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
 for_3.6/fixes/ads7846
 
 I just pushed this out, so it might take a bit to propagate to all the
 mirrors.

Thanks, Kevin, I've just sent the tested-by.
I would also like to see only one patch instead of current two patches,
can you please, amend them into one, write a correct message and resend?



-- 
Regards,
Igor.
--
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: OMAP2+: ads7846 init: fix fault caused by freeing pen-down GPIO

[Kevin Hilman]

Igor Grinberg grinb...@compulab.co.il writes:

 On 07/26/12 22:30, Kevin Hilman wrote:
 + Zumeng Chen
 
 Igor Grinberg grinb...@compulab.co.il writes:
 
 Hi Kevin,

 I've just noticed that the patch has been modified by Arnd in a way
 that of course will trigger GPIO use without being requested.
 I'm sorry, I was not available by that time Arnd changed the patch.
 
 Your right, your original patch isn't the problem.  I found the root
 cause.
 
 The real problem is actually introduced by the merge of your patch from
 the arm-soc/cleanup branch, and this one from Zumeng Chen: commit
 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce time for
 ads7846) from the arm-soc/boards branch.
 
 However, looking closer at the one from Zumeng, that one is clearly not
 right.  It unconditionally adds a *board-specific* -get_pendown_state
 function to the pdata that is common to *all* boards.  That's just wrong
 and has the side-effect of making -get_pendown_state() wrong on every
 board except the OMAP3EVM.  Oops.
 
 So, IMO, in addition to $SUBJECT patch, in order to get the touchscreen
 GPIO working on non OMAP3EVM boards, we also need something like this as
 well.
 
 Igor, Zumeng, could you try this out on your boards anc confirm if it's
 working?  I currently don't have a board setup with a touchscreen in my
 board farm.
 
 Kevin
 
From 85516c6a3354967caf4cff434d28c3001cd411eb Mon Sep 17 00:00:00 2001
 From: Kevin Hilman khil...@ti.com
 Date: Thu, 26 Jul 2012 12:15:38 -0700
 Subject: [PATCH 2/2] ARM: OMAP2+: ads7846: fix -get_pendown_state() to work
  on all boards
 
 commit 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce
 time for ads7846) introduced a common -get_pendown_state() function
 into the generic code, but that function was board-specific for the
 OMAP3EVM.
 
 Fix this up to work for all boards that pass in a pendown GPIO.
 
 Cc: Zumeng Chen zumeng.c...@windriver.com
 Cc: Igor Grinberg grinb...@compulab.co.il
 Signed-off-by: Kevin Hilman khil...@ti.com

 Tested-by: Igor Grinberg grinb...@compulab.co.il

Thanks to both of you for testing, I've updated the branch to include
the tags, and will submit during the v3.6-rc cycle.

Thanks,

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: [PATCHv4 2/8] ARM: OMAP3+: voltage/pwrdm/clkdm/clock add recursive usecount tracking

[Kevin Hilman]

Tero Kristo t-kri...@ti.com writes:

 This patch fixes the usecount tracking for omap3+, previously the
 usecount numbers were rather bogus and were not really useful for
 any purpose. Now usecount numbers track the number of really active
 clients on each domain. This patch also adds support for usecount
 tracking on powerdomain level and autoidle flag for clocks that
 are hardware controlled and should be skipped in usecount
 calculations.

 Signed-off-by: Tero Kristo t-kri...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Kevin Hilman khil...@ti.com

Minor nit: please avoid using BUG_ON() which will panic the whole
kernel.  Proper error detection is preferred, but your usage, a
WARN_ON() should suffice.

Otherwise,

Reviewed-by: Kevin Hilman khil...@ti.com

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: [PATCHv4 4/8] ARM: OMAP3: add manual control for mpu / core pwrdm usecounting

[Kevin Hilman]

Tero Kristo t-kri...@ti.com writes:

 mpu / core powerdomain usecounts are now statically increased
 by 1 during MPU activity. This allows the domains to reflect
 actual usage, and will allow the usecount to reach 0 just before
 all CPUs are ready to idle. Proper powerdomain usecounts are
 propageted to voltagedomain level also, and will allow vc
 callbacks to be triggered at right point of time.

 Signed-off-by: Tero Kristo t-kri...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Kevin Hilman khil...@ti.com

IMO, the idea is fine, but I'm not crazy about the implementation in
powerdomain.c, which is meant for pwrdm generic code.   In particular,
I'm not crazy about the pwrdm lookups in powerdomain.c.

Since pmsoc.c already has references to mpu_pwrdm and core_pwrdm, why
not just add the pwrdm_clkdm_enable/disable calls directly in pmsoc.c

Also, the changelog should be a bit more specific about why CORE
powerdomain is also handled here when most of the code only talks about
the CPU.

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: [PATCHv4 6/8] ARM: OMAP: pm-debug: enhanced usecount debug support

[Kevin Hilman]

Tero Kristo t-kri...@ti.com writes:

 Voltdm, pwrdm, clkdm, hwmod and clk usecounts are now separeted to
 their own file, 'usecount'. This file shows the usecounts for every
 active domain and their children recursively. 'count' file now only
 shows power state counts for powerdomains.

 This patch also provices a way to do printk dumps from kernel code,
 by calling the pm_dbg_dump_X functions. The plan is to call these
 functions once an error condition is detected, e.g. failed suspend.

 Signed-off-by: Tero Kristo t-kri...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 Cc: Kevin Hilman khil...@ti.com

I think we should separate out the debug stuff as a separate patch set.

Where I want to go with PM debug is away from in-kernel debug prints and
towards using tracepoints.  We have tracepoints in the clock code that
correspond to usecounts, but we need them in the clkdm, pwrdm and voltdm
code as well.  With that, you can use userspace tools (perf, ftrace) to
trace a problem (e.g. failed suspend) and see voltdm/pwrdm/clkdm/clks
are on when they shouldn't be.

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: [PATCHv4 7/8] ARM: OMAP: clockdomain: add support for preventing autodep delete

[Kevin Hilman]

Rajendra Nayak rna...@ti.com writes:

 On Wednesday 18 July 2012 01:35 PM, Tero Kristo wrote:
 On Wed, 2012-07-18 at 12:45 +0530, Rajendra Nayak wrote:
 On Tuesday 17 July 2012 08:26 PM, Tero Kristo wrote:
 Anyway, it also looks like this fix is no longer needed with the latest
 kernel, something has changed with the gpio code / or latencies and it
 doesn't crash anymore. Thus, it looks like patches 7   8 can be dropped
 from this set for now. This is the behavior with beagleboard at least,
 if someone can verify this with some other omap3 hw that would be nice.

 I can test it on a omap3 SDP. What do you want me to test?

 Just try suspend + cpuidle with and without off-mode enabled and see if
 there are any problems. I've usually seen problems with off-mode myself.

 So I just knocked off the last 2 patches from 'mainline-3.5-rc6-pwrdm-
 changes-v4' and tested on my 3430 SDP.

 I was able to hit RET and OFF in both suspend and cpuidle. Did not see
 any issues.


FYI...

I tested this series without the last 2 patches on top of v3.5 and
suspend/resume hangs on 3430/n900, 3530/Overo, 3730/OveroSTORM, but
suspend/resume and cpuidle tests for retention and idle seem to work
fine on 3730/Beagle-xM.

It works fine on all the platforms with the last 2 applied (note 6/8
needs a minor update to apply cleanly to mainline v3.5.)

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: [GIT PULL] OMAP4 coupled CPUidle support for v3.6

[Olof Johansson]

On Thu, Jul 26, 2012 at 11:44 PM, Colin Cross ccr...@android.com wrote:
 On Thu, Jul 26, 2012 at 11:34 PM, Shilimkar, Santosh
 santosh.shilim...@ti.com wrote:
 On Fri, Jul 27, 2012 at 2:19 AM, Olof Johansson o...@lixom.net wrote:
 Kevin,

 On Thu, Jul 26, 2012 at 2:37 PM, Kevin Hilman khil...@ti.com wrote:
 Hi Arnd, Olof,

 I know it is late, but I'm really hoping this can still make it for
 v3.6, so consider this a [GIT PLEA].  ;)

 New features submitted halfway through the merge window? Yeah, that's late.

 I'll pull it in as late2/pm once the below is fixed, but I won't
 promise we'll send it up.


 Kevin Hilman (1):
   ARM: OMAP4: CPUidle: add synchronization for coupled idle states

 Santosh Shilimkar (3):
   ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
   ARM: OMAP4: CPUidle: Use coupled cpuidle states to implement SMP 
 cpuidle.
   ARM: OMAP4: CPUidle: Open broadcast clock-event device.

 This looks odd, Colin was author to the first of the commits
 attributed to Santosh.

 Not sure what you mean. These patches are written by me. Kevin, Collin helped
 in review. If you are referring to the {ARM: OMAP: timer: allow gp
 timer clock-event to be
 used on both cpus} which does have SOB from me and Colin. The very first 
 version
 of this version I picked was from product tree in which it was
 commited on Coiln's name.
 Later I updated that forf the multi-omap and the new timer code and
 hence the update
 in Author.

 I have no problem with the authorship on these two patches.

Santosh, Colin,

Ok, fair enough -- I just want to make sure attribution happens
appropriately, and it's a red flag when there's a S-o-b by someone not
at your company before yours without explanation.



-Olof
--
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/1 v2] ARM: only call smp_send_stop() on SMP

[Will Deacon]

On Fri, Jul 27, 2012 at 06:15:04PM +0100, Jon Hunter wrote:
 Hi Javier,
 
 On 06/25/2012 05:31 AM, Javier Martinez Canillas wrote:
  On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux
  li...@arm.linux.org.uk wrote:
  On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
  It seems the same patch has been there for a while.
 
  http://thread.gmane.org/gmane.linux.kernel/1303115
 
  Bah, why doesn't stuff like this get resent if nothing has happened for
  a while?
  
  Indeed. At least other people that face the same issue (like me) sends
  similar patches to remind you :-)
 
 I checked with Russell but this one is not in his patch tracking system
 [1] and so still not queued. Can you submit this? Would be great to get
 this one in.

I did comment on this one:

  http://thread.gmane.org/gmane.linux.kernel/1303115

and I really think we should fix the cause of the problem, rather than
point patching this instance of it.

Will
--
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/1 v2] ARM: only call smp_send_stop() on SMP

[Russell King - ARM Linux]

On Fri, Jul 27, 2012 at 09:44:47PM +0100, Will Deacon wrote:
 On Fri, Jul 27, 2012 at 06:15:04PM +0100, Jon Hunter wrote:
  Hi Javier,
  
  On 06/25/2012 05:31 AM, Javier Martinez Canillas wrote:
   On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux
   li...@arm.linux.org.uk wrote:
   On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
   It seems the same patch has been there for a while.
  
   http://thread.gmane.org/gmane.linux.kernel/1303115
  
   Bah, why doesn't stuff like this get resent if nothing has happened for
   a while?
   
   Indeed. At least other people that face the same issue (like me) sends
   similar patches to remind you :-)
  
  I checked with Russell but this one is not in his patch tracking system
  [1] and so still not queued. Can you submit this? Would be great to get
  this one in.
 
 I did comment on this one:
 
   http://thread.gmane.org/gmane.linux.kernel/1303115
 
 and I really think we should fix the cause of the problem, rather than
 point patching this instance of it.

What do you think needs fixing there?

We support booting a kernel on systems with or without SMP support, even
with a SMP kernel.  When the kernel is booted on such a system, it is
undefined whether smp_cross_call() is a valid function pointer.

In any case, when we have only one CPU online in the system, it is
pointless even calling smp_cross_call().

That is why I explicitly suggested this solution.  This is the solution
_I_ want, because it is the most sane solution all round.
--
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] OMAP4 coupled CPUidle support for v3.6

[Shilimkar, Santosh]

On Fri, Jul 27, 2012 at 10:22 PM, Olof Johansson o...@lixom.net wrote:
 On Thu, Jul 26, 2012 at 11:44 PM, Colin Cross ccr...@android.com wrote:
 On Thu, Jul 26, 2012 at 11:34 PM, Shilimkar, Santosh
 santosh.shilim...@ti.com wrote:
 On Fri, Jul 27, 2012 at 2:19 AM, Olof Johansson o...@lixom.net wrote:
 Kevin,

 On Thu, Jul 26, 2012 at 2:37 PM, Kevin Hilman khil...@ti.com wrote:
 Hi Arnd, Olof,

 I know it is late, but I'm really hoping this can still make it for
 v3.6, so consider this a [GIT PLEA].  ;)

 New features submitted halfway through the merge window? Yeah, that's late.

 I'll pull it in as late2/pm once the below is fixed, but I won't
 promise we'll send it up.


 Kevin Hilman (1):
   ARM: OMAP4: CPUidle: add synchronization for coupled idle states

 Santosh Shilimkar (3):
   ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
   ARM: OMAP4: CPUidle: Use coupled cpuidle states to implement SMP 
 cpuidle.
   ARM: OMAP4: CPUidle: Open broadcast clock-event device.

 This looks odd, Colin was author to the first of the commits
 attributed to Santosh.

 Not sure what you mean. These patches are written by me. Kevin, Collin 
 helped
 in review. If you are referring to the {ARM: OMAP: timer: allow gp
 timer clock-event to be
 used on both cpus} which does have SOB from me and Colin. The very first 
 version
 of this version I picked was from product tree in which it was
 commited on Coiln's name.
 Later I updated that forf the multi-omap and the new timer code and
 hence the update
 in Author.

 I have no problem with the authorship on these two patches.

 Santosh, Colin,

 Ok, fair enough -- I just want to make sure attribution happens
 appropriately, and it's a red flag when there's a S-o-b by someone not
 at your company before yours without explanation.

Sure. No problem with that.

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

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Will Deacon]

Hi Russell,

On Fri, Jul 27, 2012 at 10:06:37PM +0100, Russell King - ARM Linux wrote:
 On Fri, Jul 27, 2012 at 09:44:47PM +0100, Will Deacon wrote:
  I did comment on this one:
  
http://thread.gmane.org/gmane.linux.kernel/1303115
  
  and I really think we should fix the cause of the problem, rather than
  point patching this instance of it.
 
 What do you think needs fixing there?

Well, we certainly need to fix the NULL dereference and the original patch
does do that. I just think it might be nicer to remove the possibility of a
NULL dereference instead.

 We support booting a kernel on systems with or without SMP support, even
 with a SMP kernel.  When the kernel is booted on such a system, it is
 undefined whether smp_cross_call() is a valid function pointer.

So let's define it to point at a dummy function which explodes with a BUG if
the cpumask passed in isn't empty. That allows SMP kernels to do things like
`cross call to all other cores' without having to worry about whether there
are any other cores or not.

 In any case, when we have only one CPU online in the system, it is
 pointless even calling smp_cross_call().

Pointless, but also error-prone and requiring explicit cpumask checks at
each call-site.

 That is why I explicitly suggested this solution.  This is the solution
 _I_ want, because it is the most sane solution all round.

Adding a dummy implementation is straightforward [ok, this is untested]:


diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 2c7217d..ffa411f 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -329,7 +329,13 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
}
 }
 
-static void (*smp_cross_call)(const struct cpumask *, unsigned int);
+static void dummy_smp_cross_call(const struct cpumask *mask, unsigned int irq)
+{
+   BUG_ON(!cpumask_empty(mask));
+}
+
+static void (*smp_cross_call)(const struct cpumask *, unsigned int) =
+   dummy_smp_cross_call;
 
 void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned 
int))
 {


If you still prefer checking at the call-site then the original patch will
certainly work. Otherwise, I'm happy to submit the above after some testing.

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

[PATCH 0/2] OMAPDSS: DISPC: Improvements to DIGIT sync signal selection

[Ricardo Neri]

Hello,

DSS code wrongly assumes that VENC is always available as source for the 
external
sync signal for the display controller DIGIT channel. One cannot blindly
rely only on the value of DSS_CONTROL register as certain processors may not
have VENC (e.g., OMAP5).

These patches add logic to correctly set/get the sync signal based on the
available displays in the DIGIT channel.

For the HDMI driver, handle the error in the selection of the source.

BR,

Ricardo


Ricardo Neri (2):
  OMAPDSS: DISPC: Improve logic of selection of external sync signal
  OMAPDSS:HDMI: Improve error handling at power on

 drivers/video/omap2/dss/dss.c  |   19 +--
 drivers/video/omap2/dss/dss.h  |2 +-
 drivers/video/omap2/dss/hdmi.c |   10 --
 3 files changed, 26 insertions(+), 5 deletions(-)

-- 
1.7.5.4

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

[PATCH 1/2] OMAPDSS: DISPC: Improve logic of selection of external sync signal

[Ricardo Neri]

The DIGIT channel of the display controller can take the external sync
signal from VENC or HDMI. The code was wrongly assuming that VENC was always
available, which is not necessarily true (e.g., OMAP5). Now, first verify if
the requested external source sync signal is available before getting/setting
the source.

Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
 drivers/video/omap2/dss/dss.c |   19 +--
 drivers/video/omap2/dss/dss.h |2 +-
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 04b4586..e399b4f 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -648,9 +648,21 @@ void dss_set_dac_pwrdn_bgz(bool enable)
REG_FLD_MOD(DSS_CONTROL, enable, 5, 5); /* DAC Power-Down Control */
 }
 
-void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select hdmi)
+int dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select src)
 {
-   REG_FLD_MOD(DSS_CONTROL, hdmi, 15, 15); /* VENC_HDMI_SWITCH */
+   enum omap_display_type displays;
+
+   displays = dss_feat_get_supported_displays(OMAP_DSS_CHANNEL_DIGIT);
+
+   /* discard invalid cases */
+   if (src == DSS_VENC_TV_CLK  !(displays  OMAP_DISPLAY_TYPE_VENC))
+   return -EINVAL;
+
+   if (src == DSS_HDMI_M_PCLK  !(displays  OMAP_DISPLAY_TYPE_HDMI))
+   return -EINVAL;
+
+   REG_FLD_MOD(DSS_CONTROL, src, 15, 15);  /* VENC_HDMI_SWITCH */
+   return 0;
 }
 
 enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void)
@@ -661,6 +673,9 @@ enum dss_hdmi_venc_clk_source_select 
dss_get_hdmi_venc_clk_source(void)
if ((displays  OMAP_DISPLAY_TYPE_HDMI) == 0)
return DSS_VENC_TV_CLK;
 
+   if ((displays  OMAP_DISPLAY_TYPE_VENC) == 0)
+   return DSS_HDMI_M_PCLK;
+
return REG_GET(DSS_CONTROL, 15, 15);
 }
 
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index f67afe7..7ae763c 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -270,7 +270,7 @@ bool dss_ovl_use_replication(struct dss_lcd_mgr_config 
config,
 int dss_init_platform_driver(void) __init;
 void dss_uninit_platform_driver(void);
 
-void dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select);
+int dss_select_hdmi_venc_clk_source(enum dss_hdmi_venc_clk_source_select);
 enum dss_hdmi_venc_clk_source_select dss_get_hdmi_venc_clk_source(void);
 const char *dss_get_generic_clk_source_name(enum omap_dss_clk_source clk_src);
 void dss_dump_clocks(struct seq_file *s);
-- 
1.7.5.4

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

[PATCH 2/2] OMAPDSS:HDMI: Improve error handling at power on

[Ricardo Neri]

Handle the errors that may occur when selecting the source of the
sync signal for the DIGIT channel of the display controller and
when enabling the PHY.

Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
 drivers/video/omap2/dss/hdmi.c |   10 --
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 060216f..3caac2a 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -501,13 +501,17 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
r = hdmi.ip_data.ops-phy_enable(hdmi.ip_data);
if (r) {
DSSDBG(Failed to start PHY\n);
-   goto err;
+   goto err_phy_enable;
}
 
hdmi.ip_data.ops-video_configure(hdmi.ip_data);
 
/* Make selection of HDMI in DSS */
-   dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
+   r = dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
+   if (r) {
+   DSSDBG(Failed to start PHY\n);
+   goto err_src_hdmi_venc;
+   }
 
/* Select the dispc clock source as PRCM clock, to ensure that it is not
 * DSI PLL source as the clock selected by DSI PLL might not be
@@ -536,7 +540,9 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
 err_mgr_enable:
hdmi.ip_data.ops-video_disable(hdmi.ip_data);
 err_vid_enable:
+err_src_hdmi_venc:
hdmi.ip_data.ops-phy_disable(hdmi.ip_data);
+err_phy_enable:
hdmi.ip_data.ops-pll_disable(hdmi.ip_data);
 err:
hdmi_runtime_put();
-- 
1.7.5.4

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

Re: [PATCH] ARM: OMAP2+: ads7846 init: fix fault caused by freeing pen-down GPIO

[Kevin Hilman]

Igor Grinberg grinb...@compulab.co.il writes:

 On 07/27/12 20:46, Kevin Hilman wrote:
 Igor Grinberg grinb...@compulab.co.il writes:
 
 On 07/26/12 22:30, Kevin Hilman wrote:
 + Zumeng Chen

 Igor Grinberg grinb...@compulab.co.il writes:

 Hi Kevin,

 I've just noticed that the patch has been modified by Arnd in a way
 that of course will trigger GPIO use without being requested.
 I'm sorry, I was not available by that time Arnd changed the patch.

 Your right, your original patch isn't the problem.  I found the root
 cause.

 The real problem is actually introduced by the merge of your patch from
 the arm-soc/cleanup branch, and this one from Zumeng Chen: commit
 16aced80f6 (ARM: OMAP3530evm: set pendown_state and debounce time for
 ads7846) from the arm-soc/boards branch.

 However, looking closer at the one from Zumeng, that one is clearly not
 right.  It unconditionally adds a *board-specific* -get_pendown_state
 function to the pdata that is common to *all* boards.  That's just wrong
 and has the side-effect of making -get_pendown_state() wrong on every
 board except the OMAP3EVM.  Oops.

 Argh... that should not be applied in first place...
 
 Agreed, but it's already in mainline.
 
 I double sorry, I was not available when that conflict was resolved...
 The right resolution would be just to revert the 16aced80f6
 (ARM: OMAP3530evm: set pendown_state and debounce time for ads7846),
 but who cares now...
 
 


 So, IMO, in addition to $SUBJECT patch, in order to get the touchscreen
 GPIO working on non OMAP3EVM boards, we also need something like this as
 well.

 Igor, Zumeng, could you try this out on your boards anc confirm if it's
 working?  I currently don't have a board setup with a touchscreen in my
 board farm.

 Since you have already dig into this, which branch would be good for 
 testing?
 
 
 git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
 for_3.6/fixes/ads7846
 
 I just pushed this out, so it might take a bit to propagate to all the
 mirrors.

 Thanks, Kevin, I've just sent the tested-by.
 I would also like to see only one patch instead of current two patches,
 can you please, amend them into one, write a correct message and resend?

Yeah, the changelog in my first patch isn't quite right anymore since
your patch isn't the one that caused the problems.

You're more familiar with this code than me, so feel free to recombine
them if you like, and I'll queue it up for v3.6-rc.

Thanks,

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: [GIT PULL] OMAP4 coupled CPUidle support for v3.6

[Kevin Hilman]

Olof Johansson o...@lixom.net writes:

 On Thu, Jul 26, 2012 at 11:44 PM, Colin Cross ccr...@android.com wrote:
 On Thu, Jul 26, 2012 at 11:34 PM, Shilimkar, Santosh
 santosh.shilim...@ti.com wrote:
 On Fri, Jul 27, 2012 at 2:19 AM, Olof Johansson o...@lixom.net wrote:
 Kevin,

 On Thu, Jul 26, 2012 at 2:37 PM, Kevin Hilman khil...@ti.com wrote:
 Hi Arnd, Olof,

 I know it is late, but I'm really hoping this can still make it for
 v3.6, so consider this a [GIT PLEA].  ;)

 New features submitted halfway through the merge window? Yeah, that's late.

 I'll pull it in as late2/pm once the below is fixed, but I won't
 promise we'll send it up.


 Kevin Hilman (1):
   ARM: OMAP4: CPUidle: add synchronization for coupled idle states

 Santosh Shilimkar (3):
   ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
   ARM: OMAP4: CPUidle: Use coupled cpuidle states to implement SMP 
 cpuidle.
   ARM: OMAP4: CPUidle: Open broadcast clock-event device.

 This looks odd, Colin was author to the first of the commits
 attributed to Santosh.

 Not sure what you mean. These patches are written by me. Kevin, Collin 
 helped
 in review. If you are referring to the {ARM: OMAP: timer: allow gp
 timer clock-event to be
 used on both cpus} which does have SOB from me and Colin. The very first 
 version
 of this version I picked was from product tree in which it was
 commited on Coiln's name.
 Later I updated that forf the multi-omap and the new timer code and
 hence the update
 in Author.

 I have no problem with the authorship on these two patches.

 Santosh, Colin,

 Ok, fair enough -- I just want to make sure attribution happens
 appropriately, and it's a red flag when there's a S-o-b by someone not
 at your company before yours without explanation.

Thanks Olof for considering this very late branch.

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

[RFC 0/3] solving omapdrm/omapdss layering issues

[Rob Clark]

From: Rob Clark r...@ti.com

I've been working for the better part of the week on solving some of
the omapdss vs kms mismatches, which is one of the bigger remaining
issues in the TODO before moving omapdrm out of staging.

The biggest place that this shows up is in GO bit handling.  Basically,
some of the scanout related registers in DSS hw block are only shadow
registers, and if the GO bit is set during the vblank the hw copies
into the actual registers (not accessible to CPU) and clears the GO
bit.  When the GO bit is set, there is no safe way to update these
registers without undefined results.  So omapdss tries to be friendly
and abstract this, by buffering up the updated state, and applying it
on the next vblank once the GO bit is cleared.  But this causes all
sorts of mayhem at the omapdrm layer, which would like to unpin the
previous scanout buffer(s) on the next vblank (or endwin) irq.  Due
to the buffering in omapdss, we have no way to know on a vblank if we
have switched to the scanout buffer or not.  Basically it works ok as
long as userspace is only ever updating on layer (either crtc or drm
plane) at a time.  But throw together hw mouse cursor (drm plane)
plus a window manager like compiz which does page flips, or wayland
(weston drm compositor) with hw composition (drm plane), and things
start to fail in a big way.

I've tried a few approaches to preserve the omapdss more or less as it
is, by adding callbacks for when GO bit is cleared, etc.  But the
sequencing of setting up connector/encoder/crtc is not really what
omapdss expects, and would generally end up confusing the apply
layer in omapdss (it would end up not programming various registers
because various dirty flags would get cleared, for example mgr updated
before overlay connected, etc).

Finally, in frustration, this afternoon I hit upon an idea.  Why not
just use the dispc code in omapdss, which is basically a stateless
layer of helper functions, and bypass the stateful layer of omapdss.
Since KMS helper functions already give us the correct sequence for
setting up the hardware, this turned out to be rather easy.  And fit
it quite nicely with my mechanism to queue up updates when the GO bit
is not clear.  And, unlike my previous attempts, it actually worked..
not only that, but it worked on the first boot!

So I am pretty happy about how this is shaping up.  Not only is it
simpler that my previous attepmts, and solves a few tricky buffer
unpin related issues.  But it also makes it very easy to wire in the
missing userspace vblank event handling without resorting to duct-
tape.

Obviously there is stuff still missing, and some hacks.  This is
really just a proof of concept at this stage.  But I wanted to send an
RFC so we could start discussing how to move forward.  Ie. could we
reasonably add support to build dispc as a library of stateless helper
functions, sharing it and the panel drivers between omapdrm and the
legacy omapdss based drivers.  Or is there no clean way to do that, in
which case we should just copy the code we need into omapdrm, and
leave the deprecated omapdss as it is for legacy drivers.

Rob Clark (3):
  OMAPDSS: expose dispc for use from omapdrm
  omap2+: use dss_dispc hwmod for omapdrm
  drm/omap: use dispc directly

 arch/arm/mach-omap2/drm.c|   24 +-
 drivers/staging/omapdrm/Makefile |1 +
 drivers/staging/omapdrm/omap_connector.c |   20 +-
 drivers/staging/omapdrm/omap_crtc.c  |   42 ++--
 drivers/staging/omapdrm/omap_drv.c   |   70 +-
 drivers/staging/omapdrm/omap_drv.h   |   64 -
 drivers/staging/omapdrm/omap_encoder.c   |  213 ++---
 drivers/staging/omapdrm/omap_irq.c   |  133 +++
 drivers/staging/omapdrm/omap_plane.c |  382 +-
 drivers/video/omap2/dss/apply.c  |4 +-
 drivers/video/omap2/dss/dispc.c  |   76 --
 drivers/video/omap2/dss/dss.h|2 +
 drivers/video/omap2/dss/hdmi.c   |   18 +-
 13 files changed, 628 insertions(+), 421 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_irq.c

-- 
1.7.9.5

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

[RFC 1/3] OMAPDSS: expose dispc for use from omapdrm

[Rob Clark]

From: Rob Clark r...@ti.com

Not very clean, just for proof of concept.

Signed-off-by: Rob Clark r...@ti.com
---
 drivers/video/omap2/dss/apply.c |4 ++-
 drivers/video/omap2/dss/dispc.c |   76 ++-
 drivers/video/omap2/dss/dss.h   |2 ++
 drivers/video/omap2/dss/hdmi.c  |   18 +-
 4 files changed, 73 insertions(+), 27 deletions(-)

diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index ab22cc2..c9a9b80 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -699,6 +699,8 @@ static void dss_write_regs(void)
 
 static void dss_set_go_bits(void)
 {
+   dump_stack();
+#if 0
const int num_mgrs = omap_dss_get_num_overlay_managers();
int i;
 
@@ -722,7 +724,7 @@ static void dss_set_go_bits(void)
 
dispc_mgr_go(mgr-id);
}
-
+#endif
 }
 
 static void mgr_clear_shadow_dirty(struct omap_overlay_manager *mgr)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e6ea47e..bdb0bde 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -352,7 +352,7 @@ static void dispc_restore_context(void)
if (dss_has_feature(FEAT_MGR_LCD2))
RR(CONTROL2);
/* clear spurious SYNC_LOST_DIGIT interrupts */
-   dispc_write_reg(DISPC_IRQSTATUS, DISPC_IRQ_SYNC_LOST_DIGIT);
+   dispc_clear_irqs(DISPC_IRQ_SYNC_LOST_DIGIT);
 
/*
 * enable last so IRQs won't trigger before
@@ -376,6 +376,7 @@ int dispc_runtime_get(void)
WARN_ON(r  0);
return r  0 ? r : 0;
 }
+EXPORT_SYMBOL_GPL(dispc_runtime_get);
 
 void dispc_runtime_put(void)
 {
@@ -386,6 +387,7 @@ void dispc_runtime_put(void)
r = pm_runtime_put_sync(dispc.pdev-dev);
WARN_ON(r  0  r != -ENOSYS);
 }
+EXPORT_SYMBOL_GPL(dispc_runtime_put);
 
 static inline bool dispc_mgr_is_lcd(enum omap_channel channel)
 {
@@ -410,6 +412,7 @@ u32 dispc_mgr_get_vsync_irq(enum omap_channel channel)
return 0;
}
 }
+EXPORT_SYMBOL_GPL(dispc_mgr_get_vsync_irq);
 
 u32 dispc_mgr_get_framedone_irq(enum omap_channel channel)
 {
@@ -440,6 +443,7 @@ bool dispc_mgr_go_busy(enum omap_channel channel)
else
return REG_GET(DISPC_CONTROL, bit, bit) == 1;
 }
+EXPORT_SYMBOL_GPL(dispc_mgr_go_busy);
 
 void dispc_mgr_go(enum omap_channel channel)
 {
@@ -483,6 +487,7 @@ void dispc_mgr_go(enum omap_channel channel)
else
REG_FLD_MOD(DISPC_CONTROL, 1, bit, bit);
 }
+EXPORT_SYMBOL_GPL(dispc_mgr_go);
 
 static void dispc_ovl_write_firh_reg(enum omap_plane plane, int reg, u32 value)
 {
@@ -844,6 +849,7 @@ void dispc_ovl_set_channel_out(enum omap_plane plane, enum 
omap_channel channel)
}
dispc_write_reg(DISPC_OVL_ATTRIBUTES(plane), val);
 }
+EXPORT_SYMBOL_GPL(dispc_ovl_set_channel_out);
 
 static enum omap_channel dispc_ovl_get_channel_out(enum omap_plane plane)
 {
@@ -2236,6 +2242,7 @@ int dispc_ovl_setup(enum omap_plane plane, struct 
omap_overlay_info *oi,
 
return 0;
 }
+EXPORT_SYMBOL_GPL(dispc_ovl_setup);
 
 int dispc_ovl_enable(enum omap_plane plane, bool enable)
 {
@@ -2256,6 +2263,7 @@ static void dispc_disable_isr(void *data, u32 mask)
struct completion *compl = data;
complete(compl);
 }
+EXPORT_SYMBOL_GPL(dispc_ovl_enable);
 
 static void _enable_lcd_out(enum omap_channel channel, bool enable)
 {
@@ -2318,6 +2326,10 @@ static void _enable_digit_out(bool enable)
dispc_read_reg(DISPC_CONTROL);
 }
 
+/* TODO revisit how this and dispc_mgr_enable_lcd_out() should
+ * work w/ omapdrm handling the irqs..  ideally we'd just have
+ * a dispc helper fxn to call from the omapdrm irq handling.
+ */
 static void dispc_mgr_enable_digit_out(bool enable)
 {
struct completion frame_done_completion;
@@ -2381,7 +2393,7 @@ static void dispc_mgr_enable_digit_out(bool enable)
unsigned long flags;
spin_lock_irqsave(dispc.irq_lock, flags);
dispc.irq_error_mask |= DISPC_IRQ_SYNC_LOST_DIGIT;
-   dispc_write_reg(DISPC_IRQSTATUS, DISPC_IRQ_SYNC_LOST_DIGIT);
+   dispc_clear_irqs(DISPC_IRQ_SYNC_LOST_DIGIT);
_omap_dispc_set_irqs();
spin_unlock_irqrestore(dispc.irq_lock, flags);
}
@@ -2410,6 +2422,7 @@ void dispc_mgr_enable(enum omap_channel channel, bool 
enable)
else
BUG();
 }
+EXPORT_SYMBOL_GPL(dispc_mgr_enable);
 
 void dispc_lcd_enable_signal_polarity(bool act_high)
 {
@@ -2529,6 +2542,7 @@ void dispc_mgr_setup(enum omap_channel channel,
dispc_mgr_set_cpr_coef(channel, info-cpr_coefs);
}
 }
+EXPORT_SYMBOL_GPL(dispc_mgr_setup);
 
 void dispc_mgr_set_tft_data_lines(enum omap_channel channel, u8 data_lines)
 {
@@ -2705,6 +2719,7 @@ void dispc_mgr_set_timings(enum omap_channel channel,
 
dispc_mgr_set_size(channel, t.x_res, t.y_res);
 }

[RFC 2/3] omap2+: use dss_dispc hwmod for omapdrm

[Rob Clark]

From: Rob Clark r...@ti.com

We need this so that platform_get_irq() works when drm core sets up the
irq handling.

Signed-off-by: Rob Clark r...@ti.com
---
 arch/arm/mach-omap2/drm.c |   24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
index 4ab7b6a..f7a2444 100644
--- a/arch/arm/mach-omap2/drm.c
+++ b/arch/arm/mach-omap2/drm.c
@@ -33,18 +33,6 @@
 #include plat/drm.h
 
 #if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
-
-static struct omap_drm_platform_data omapdrm_platdata;
-
-static struct platform_device omap_drm_device = {
-   .dev = {
-   .coherent_dma_mask = DMA_BIT_MASK(32),
-   .platform_data = omapdrm_platdata,
-   },
-   .name = omapdrm,
-   .id = 0,
-};
-
 static int __init omap_init_drm(void)
 {
struct omap_hwmod *oh = NULL;
@@ -60,8 +48,16 @@ static int __init omap_init_drm(void)
oh-name);
}
 
-   return platform_device_register(omap_drm_device);
+   /* lookup and populate DSS information: */
+   oh = omap_hwmod_lookup(dss_dispc);
+   pdev = omap_device_build(omapdrm, -1, oh, NULL, 0, NULL, 0,
+   false);
+   WARN(IS_ERR(pdev), Could not build omap_device for omapdrm\n);
 
+   if (!pdev)
+   return -EINVAL;
+
+   return 0;
 }
 
 arch_initcall(omap_init_drm);
@@ -69,12 +65,14 @@ arch_initcall(omap_init_drm);
 void __init omapdrm_reserve_vram(void)
 {
 #ifdef CONFIG_CMA
+#if 0 /* TODO add this back for omap3 */
/*
 * Create private 32MiB contiguous memory area for omapdrm.0 device
 * TODO revisit size.. if uc/wc buffers are allocated from CMA pages
 * then the amount of memory we need goes up..
 */
dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
+#endif
 #else
 #  warning CMA is not enabled, there may be limitations about scanout buffer 
allocations on OMAP3 and earlier
 #endif
-- 
1.7.9.5

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

[RFC 3/3] drm/omap: use dispc directly

[Rob Clark]

From: Rob Clark r...@ti.com

This is still work in progress, but it nicely solves the omapdss vs drm
impedence mismatches, and properly fixes unpin confusion vs GO bit status.
As an added bonus, we also no longer leave the last overlay buffer pinned.
Adding the previously missing vblank event handling for userspace should
be pretty trivial now too.

Signed-off-by: Rob Clark r...@ti.com
---
 drivers/staging/omapdrm/Makefile |1 +
 drivers/staging/omapdrm/omap_connector.c |   20 +-
 drivers/staging/omapdrm/omap_crtc.c  |   42 ++--
 drivers/staging/omapdrm/omap_drv.c   |   70 +-
 drivers/staging/omapdrm/omap_drv.h   |   64 -
 drivers/staging/omapdrm/omap_encoder.c   |  213 ++---
 drivers/staging/omapdrm/omap_irq.c   |  133 +++
 drivers/staging/omapdrm/omap_plane.c |  382 +-
 8 files changed, 544 insertions(+), 381 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_irq.c

diff --git a/drivers/staging/omapdrm/Makefile b/drivers/staging/omapdrm/Makefile
index 1ca0e00..d85e058 100644
--- a/drivers/staging/omapdrm/Makefile
+++ b/drivers/staging/omapdrm/Makefile
@@ -5,6 +5,7 @@
 
 ccflags-y := -Iinclude/drm -Werror
 omapdrm-y := omap_drv.o \
+   omap_irq.o \
omap_debugfs.o \
omap_crtc.o \
omap_plane.o \
diff --git a/drivers/staging/omapdrm/omap_connector.c 
b/drivers/staging/omapdrm/omap_connector.c
index 5e2856c..577ae32 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -284,16 +284,17 @@ static const struct drm_connector_helper_funcs 
omap_connector_helper_funcs = {
 };
 
 /* called from encoder when mode is set, to propagate settings to the dssdev */
-void omap_connector_mode_set(struct drm_connector *connector,
-   struct drm_display_mode *mode)
+int omap_connector_mode_set(struct drm_connector *connector,
+   struct drm_display_mode *mode,
+   struct omap_video_timings *timings)
 {
struct drm_device *dev = connector-dev;
struct omap_connector *omap_connector = to_omap_connector(connector);
struct omap_dss_device *dssdev = omap_connector-dssdev;
struct omap_dss_driver *dssdrv = dssdev-driver;
-   struct omap_video_timings timings;
+   int ret;
 
-   copy_timings_drm_to_omap(timings, mode);
+   copy_timings_drm_to_omap(timings, mode);
 
DBG(%s: set mode: %d:\%s\ %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x,
omap_connector-dssdev-name,
@@ -303,12 +304,15 @@ void omap_connector_mode_set(struct drm_connector 
*connector,
mode-vdisplay, mode-vsync_start,
mode-vsync_end, mode-vtotal, mode-type, mode-flags);
 
-   if (dssdrv-check_timings(dssdev, timings)) {
-   dev_err(dev-dev, could not set timings\n);
-   return;
+   ret = dssdrv-check_timings(dssdev, timings);
+   if (ret) {
+   dev_err(dev-dev, could not set timings: %d\n, ret);
+   return ret;
}
 
-   dssdrv-set_timings(dssdev, timings);
+   dssdrv-set_timings(dssdev, timings);
+
+   return 0;
 }
 
 /* flush an area of the framebuffer (in case of manual update display that
diff --git a/drivers/staging/omapdrm/omap_crtc.c 
b/drivers/staging/omapdrm/omap_crtc.c
index 7479dcb..3024dcd 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -33,7 +33,6 @@ struct omap_crtc {
 
/* if there is a pending flip, these will be non-null: */
struct drm_pending_vblank_event *event;
-   struct drm_framebuffer *old_fb;
 };
 
 static void omap_crtc_destroy(struct drm_crtc *crtc)
@@ -78,7 +77,8 @@ static int omap_crtc_mode_set(struct drm_crtc *crtc,
return omap_plane_mode_set(plane, crtc, crtc-fb,
0, 0, mode-hdisplay, mode-vdisplay,
x  16, y  16,
-   mode-hdisplay  16, mode-vdisplay  16);
+   mode-hdisplay  16, mode-vdisplay  16,
+   NULL, NULL);
 }
 
 static void omap_crtc_prepare(struct drm_crtc *crtc)
@@ -102,10 +102,11 @@ static int omap_crtc_mode_set_base(struct drm_crtc *crtc, 
int x, int y,
struct drm_plane *plane = omap_crtc-plane;
struct drm_display_mode *mode = crtc-mode;
 
-   return plane-funcs-update_plane(plane, crtc, crtc-fb,
+   return omap_plane_mode_set(plane, crtc, crtc-fb,
0, 0, mode-hdisplay, mode-vdisplay,
x  16, y  16,
-   mode-hdisplay  16, mode-vdisplay  16);
+   mode-hdisplay  16, mode-vdisplay  16,
+   NULL, NULL);
 }
 
 static void omap_crtc_load_lut(struct drm_crtc *crtc)
@@ -154,17 +155,17 @@ static void page_flip_cb(void *arg)
 {
struct drm_crtc *crtc = arg;
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   struct