date:20110927

On Mon, 2011-09-26 at 17:29 +0530, Archit Taneja wrote:
 Remove the code in omap_vout_probe() which calls display-driver-update() for
 all the displays. This isn't correct because:
 
 - An update in probe doesn't make sense, because we don't have any valid 
 content
   to show at this time.
 - Calling update for a panel which isn't enabled is not supported by DSS2. 
 This
   leads to a crash at probe.

Calling update() on a disabled panel should not crash... Where is the
crash coming from?

 Tomi


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

RE: [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe


 -Original Message-
 From: Taneja, Archit
 Sent: Monday, September 26, 2011 5:29 PM
 To: Hiremath, Vaibhav
 Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux-
 me...@vger.kernel.org; Taneja, Archit
 Subject: [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in
 omap_vout_probe
 
 Remove the code in omap_vout_probe() which calls display-driver-update()
 for
 all the displays. This isn't correct because:
 
 - An update in probe doesn't make sense, because we don't have any valid
 content
   to show at this time.
 - Calling update for a panel which isn't enabled is not supported by DSS2.
 This
   leads to a crash at probe.
 
It should not crash, do you have crash log here?

Thanks,
Vaibhav

 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/media/video/omap/omap_vout.c |8 
  1 files changed, 0 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/media/video/omap/omap_vout.c
 b/drivers/media/video/omap/omap_vout.c
 index 7b8e87a..3d9c83e 100644
 --- a/drivers/media/video/omap/omap_vout.c
 +++ b/drivers/media/video/omap/omap_vout.c
 @@ -2213,14 +2213,6 @@ static int __init omap_vout_probe(struct
 platform_device *pdev)
   if (ret)
   goto probe_err2;
 
 - for (i = 0; i  vid_dev-num_displays; i++) {
 - struct omap_dss_device *display = vid_dev-displays[i];
 -
 - if (display-driver-update)
 - display-driver-update(display, 0, 0,
 - display-panel.timings.x_res,
 - display-panel.timings.y_res);
 - }
   return 0;
 
  probe_err2:
 --
 1.7.1

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

RE: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr

 -Original Message-
 From: Semwal, Sumit
 Sent: Tuesday, September 27, 2011 11:12 AM
 To: Hiremath, Vaibhav
 Cc: Taneja, Archit; Valkeinen, Tomi; linux-omap@vger.kernel.org; linux-
 me...@vger.kernel.org
 Subject: Re: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in
 omap_vout_isr

 Hi Vaibhav,

  On Mon, Sep 26, 2011 at 3:49 PM, Hiremath, Vaibhav hvaib...@ti.com
 wrote:

   -Original Message-
   From: Taneja, Archit
   Sent: Thursday, September 22, 2011 11:46 AM
   To: Hiremath, Vaibhav
   Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit;
 linux-
   me...@vger.kernel.org
   Subject: Re: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling
 in
   omap_vout_isr

   Hi,

    snip

-          if (!(irqstatus  (DISPC_IRQ_VSYNC |
 DISPC_IRQ_VSYNC2)))
+          if (mgr_id == OMAP_DSS_CHANNEL_LCD)
+                  irq = DISPC_IRQ_VSYNC;
+          else if (mgr_id == OMAP_DSS_CHANNEL_LCD2)
+                  irq = DISPC_IRQ_VSYNC2;
+          else
+                  goto vout_isr_err;
+
+          if (!(irqstatus  irq))
                   goto vout_isr_err;
           break;
I understand what this patch meant for, but I am more curious to
 know
What is value addition of this patch?

if (!(irqstatus  (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))

Vs

if (mgr_id == OMAP_DSS_CHANNEL_LCD)
    irq = DISPC_IRQ_VSYNC;
else if (mgr_id == OMAP_DSS_CHANNEL_LCD2)
    irq = DISPC_IRQ_VSYNC2;

Isn't this same, because we are not doing anything separate and
 special
for VSYNC and VSYNC2?

   Consider a use case where the primary LCD panel(connected to LCD
   manager) is configured at a 60 Hz refresh rate, and the secondary
   panel(connected to LCD2) refreshes at 30 Hz. Let the overlay
   configuration be something like this:

   /dev/video1-overlay1-LCD manager-Primary panel(60 Hz)

   /dev/video2-overlay2-LCD2 manager-Secondary Panel(30
 Hz)

   Now if we are doing streaming on both video1 and video2, since we
 deque
   on either VSYNC or VSYNC2, video2 buffers will deque faster than the
   panels refresh, which is incorrect. So for video2, we should only
 deque
   when we get a VSYNC2 interrupt. Thats why there is a need to
 correlate
   the interrupt and the overlay manager.

  Archit,

  I think I am still not understood or convinced with your description
 above,

  The code snippet which we are referring here, does check whether the
  interrupt is either VSYNC or VSYNC2, else fall back to vout_isr_err.

 I am not quite sure I understand what is the confusing part here -
 below is my understanding; please correct me if you think otherwise.
 As I understand, this patch creates a (missing) correlation between a
 manager and the corresponding ISR. The earlier code would accept a
 VSYNC2 for LCD1 manager, which is not the correct thing to do.
 That is why the check of 'if ((mgr==LCD)  (IRQ==VSYNC))' kind of
 thing is needed; Which part of this do you think the above patch
 doesn't do? Or, do you think it is not needed / done correctly?
Sumit,

Please look at the patch carefully, it does exactly same thing. I understand 
the use-case what Archit explained in the last email but in this patch context, 
the use-case change anything here in this patch. 

Can you review it carefully again?

Thanks,
Vaibhav

  For me both are doing same thing, the original code is optimized way
 of implementation. Can you please review it again?

  Thanks,
  Vaibhav

 Thanks and best regards,
 ~Sumit.

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

RE: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr

On Tue, 2011-09-27 at 12:09 +0530, Hiremath, Vaibhav wrote:
 Please look at the patch carefully, it does exactly same thing. I
 understand the use-case what Archit explained in the last email but in
 this patch context, the use-case change anything here in this patch. 

With the current code, the ISR code will be ran for a panel connected to
LCD1 output when VSYNC for LCD2 happens.

After Archit's patch, this no longer happens.

I don't know what the ISR code does, so it may not cause any problems,
but it sure doesn't sound right running the code when a wrong interrupt
happens.

 Tomi


--
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 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr

2011-09-27 Thread Semwal, Sumit

Hi Vaibhav,

On Tue, Sep 27, 2011 at 12:09 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
 -Original Message-
 From: Semwal, Sumit
 Sent: Tuesday, September 27, 2011 11:12 AM
 To: Hiremath, Vaibhav
 Cc: Taneja, Archit; Valkeinen, Tomi; linux-omap@vger.kernel.org; linux-
 me...@vger.kernel.org
 Subject: Re: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in
 omap_vout_isr

 Hi Vaibhav,
snip
  Archit,

  I think I am still not understood or convinced with your description
 above,

  The code snippet which we are referring here, does check whether the
  interrupt is either VSYNC or VSYNC2, else fall back to vout_isr_err.

 I am not quite sure I understand what is the confusing part here -
 below is my understanding; please correct me if you think otherwise.
 As I understand, this patch creates a (missing) correlation between a
 manager and the corresponding ISR. The earlier code would accept a
 VSYNC2 for LCD1 manager, which is not the correct thing to do.
 That is why the check of 'if ((mgr==LCD)  (IRQ==VSYNC))' kind of
 thing is needed; Which part of this do you think the above patch
 doesn't do? Or, do you think it is not needed / done correctly?
 Sumit,

 Please look at the patch carefully, it does exactly same thing. I understand 
 the use-case what Archit explained in the last email but in this patch 
 context, the use-case change anything here in this patch.

 Can you review it carefully again?
Thanks - I did review it carefully (the first time, and again), and
maybe it is something that you're able to see which I can't.

Could you please explain why you think

(1)
if (!(irqstatus  (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2)))
goto vout_isr_err;

is *exactly* the same as

(2)
 if (!((mgr==LCD)  (irqstatus  DISPC_IRQ_VSYNC)) || (mgr==LCD2) 
(irqstatus  DISPC_IRQ_VSYNC2)) )
   goto vout_isr_err;
[which I understand is what Archit's patch does]

I am not able to see any correlation in (1) between mgr and irq,
whereas it is quite clear in (2).

Let me know if I missed something?

Best regards,
~Sumit.

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

RE: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr

 -Original Message-
 From: Valkeinen, Tomi
 Sent: Tuesday, September 27, 2011 12:19 PM
 To: Hiremath, Vaibhav
 Cc: Semwal, Sumit; Taneja, Archit; linux-omap@vger.kernel.org; linux-
 me...@vger.kernel.org
 Subject: RE: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in
 omap_vout_isr

 On Tue, 2011-09-27 at 12:09 +0530, Hiremath, Vaibhav wrote:
  Please look at the patch carefully, it does exactly same thing. I
  understand the use-case what Archit explained in the last email but in
  this patch context, the use-case change anything here in this patch.

 With the current code, the ISR code will be ran for a panel connected to
 LCD1 output when VSYNC for LCD2 happens.

 After Archit's patch, this no longer happens.

 I don't know what the ISR code does, so it may not cause any problems,
 but it sure doesn't sound right running the code when a wrong interrupt
 happens.

If you look at the patch, the patch barely checks for the condition and
makes sure that the interrupt is either of VSYNC or VSYNC2, else return. Rest 
everything is same.

The right fix is in streamon api, where you mask the interrupt before
registering it.

Thanks,
Vaibhav

  Tomi

--
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 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr

On Tuesday 27 September 2011 12:24 PM, Hiremath, Vaibhav wrote:

-Original Message-
From: Valkeinen, Tomi
Sent: Tuesday, September 27, 2011 12:19 PM
To: Hiremath, Vaibhav
Cc: Semwal, Sumit; Taneja, Archit; linux-omap@vger.kernel.org; linux-
me...@vger.kernel.org
Subject: RE: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in
omap_vout_isr

On Tue, 2011-09-27 at 12:09 +0530, Hiremath, Vaibhav wrote:

Please look at the patch carefully, it does exactly same thing. I
understand the use-case what Archit explained in the last email but in
this patch context, the use-case change anything here in this patch.

With the current code, the ISR code will be ran for a panel connected to
LCD1 output when VSYNC for LCD2 happens.

After Archit's patch, this no longer happens.

I don't know what the ISR code does, so it may not cause any problems,
but it sure doesn't sound right running the code when a wrong interrupt
happens.

If you look at the patch, the patch barely checks for the condition and
makes sure that the interrupt is either of VSYNC or VSYNC2, else return. Rest 
everything is same.

It doesn't only make sure that the interrupt it one of them, it uses it 
later too in the check:

if (!(irqstatus  irq))
goto vout_isr_err;
...
...

The right fix is in streamon api, where you mask the interrupt before
registering it.

If this is the right fix, we should have a purely selective method of 
selecting the interrupts. Even for OMAP3, we register interrupts for LCD 
and TV, and then check the interrupt in the handler using panel type. 
Now, since have 2 different interrupts for the same panel type, we have 
to further distinguish using the manager id.

Archit

Thanks,
Vaibhav

  Tomi

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

RE: [PATCH v3 3/3] OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility setting

Thanks,
Vaibhav

 -Original Message-
 From: Taneja, Archit
 Sent: Monday, September 26, 2011 12:04 PM
 To: Hiremath, Vaibhav
 Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; Taneja,
 Archit; linux-me...@vger.kernel.org; Molnar, Lajos
 Subject: [PATCH v3 3/3] OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha
 compatibility setting

 On OMAP3, in order to enable alpha blending for LCD and TV managers, we
 needed
 to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
 OMAP4, alpha blending is always enabled by default, if the above bits are
 set,
 we switch to an OMAP3 compatibility mode where the zorder values in the
 pipeline
 attribute registers are ignored and a fixed priority is configured.

 Rename the manager_info member alpha_enabled to partial_alpha_enabled
 for
 more clarity. Introduce two dss_features FEAT_ALPHA_FIXED_ZORDER and
 FEAT_ALPHA_FREE_ZORDER which represent OMAP3-alpha compatibility mode and
 OMAP4
 alpha mode respectively. Introduce an overlay cap for ZORDER. The DSS2
 user is
 expected to check for the ZORDER cap, if an overlay doesn't have this cap,
 the
 user is expected to set the parameter partial_alpha_enabled. If the
 overlay has
 ZORDER cap, the DSS2 user can assume that alpha blending is already
 enabled.

 Don't support OMAP3 compatibility mode for now. Trying to read/write to
 alpha_blending_enabled sysfs attribute issues a warning for OMAP4 and does
 not
 set the LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits.

 Change alpha_enabled to partial_alpha_enabled in the omap_vout driver. Use
 overlay cap OMAP_DSS_OVL_CAP_GLOBAL_ALPHA to check if overlay supports
 alpha
 blending or not. Replace this with checks for VIDEO1 pipeline.

 Cc: linux-me...@vger.kernel.org
 Cc: Lajos Molnar mol...@ti.com
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
 Changes in v3:
 - Fix some spelling mistakes in commit message.
 - Add comment about video1 limitation in omap_vout .

  drivers/media/video/omap/omap_vout.c   |   17 -
  drivers/video/omap2/dss/dispc.c|   24 
  drivers/video/omap2/dss/dss.h  |4 ++--
  drivers/video/omap2/dss/dss_features.c |   22 +++---
  drivers/video/omap2/dss/dss_features.h |3 ++-
  drivers/video/omap2/dss/manager.c  |   28 +++
 -
  include/video/omapdss.h|3 ++-
  7 files changed, 60 insertions(+), 41 deletions(-)

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

Thanks,
Vaibhav

 diff --git a/drivers/media/video/omap/omap_vout.c
 b/drivers/media/video/omap/omap_vout.c
 index b3a5ecd..d9e64f3 100644
 --- a/drivers/media/video/omap/omap_vout.c
 +++ b/drivers/media/video/omap/omap_vout.c
 @@ -1165,12 +1165,17 @@ static int vidioc_try_fmt_vid_overlay(struct file
 *file, void *fh,
  {
   int ret = 0;
   struct omap_vout_device *vout = fh;
 + struct omap_overlay *ovl;
 + struct omapvideo_info *ovid;
   struct v4l2_window *win = f-fmt.win;

 + ovid = vout-vid_info;
 + ovl = ovid-overlays[0];
 +
   ret = omap_vout_try_window(vout-fbuf, win);

   if (!ret) {
 - if (vout-vid == OMAP_VIDEO1)
 + if ((ovl-caps  OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
   win-global_alpha = 255;
   else
   win-global_alpha = f-fmt.win.global_alpha;
 @@ -1194,8 +1199,8 @@ static int vidioc_s_fmt_vid_overlay(struct file
 *file, void *fh,

   ret = omap_vout_new_window(vout-crop, vout-win, vout-fbuf,
 win);
   if (!ret) {
 - /* Video1 plane does not support global alpha */
 - if (ovl-id == OMAP_DSS_VIDEO1)
 + /* Video1 plane does not support global alpha on OMAP3 */
 + if ((ovl-caps  OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
   vout-win.global_alpha = 255;
   else
   vout-win.global_alpha = f-fmt.win.global_alpha;
 @@ -1788,7 +1793,9 @@ static int vidioc_s_fbuf(struct file *file, void *fh,
   if (ovl-manager  ovl-manager-get_manager_info 
   ovl-manager-set_manager_info) {
   ovl-manager-get_manager_info(ovl-manager, info);
 - info.alpha_enabled = enable;
 + /* enable this only if there is no zorder cap */
 + if ((ovl-caps  OMAP_DSS_OVL_CAP_ZORDER) == 0)
 + info.partial_alpha_enabled = enable;
   if (ovl-manager-set_manager_info(ovl-manager, info))
   return -EINVAL;
   }
 @@ -1820,7 +1827,7 @@ static int vidioc_g_fbuf(struct file *file, void *fh,
   }
   if (ovl-manager  ovl-manager-get_manager_info) {
   ovl-manager-get_manager_info(ovl-manager, info);
 - if (info.alpha_enabled)
 + if (info.partial_alpha_enabled)
   a-flags |= V4L2_FBUF_FLAG_LOCAL_ALPHA;
   }

 diff --git a/drivers/video/omap2/dss/dispc.c

Re: [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe


On Tuesday 27 September 2011 11:40 AM, Valkeinen, Tomi wrote:

On Mon, 2011-09-26 at 17:29 +0530, Archit Taneja wrote:

Remove the code in omap_vout_probe() which calls display-driver-update() for
all the displays. This isn't correct because:

- An update in probe doesn't make sense, because we don't have any valid content
   to show at this time.
- Calling update for a panel which isn't enabled is not supported by DSS2. This
   leads to a crash at probe.


Calling update() on a disabled panel should not crash... Where is the
crash coming from?


you are right, the crash isn't coming from the updates. I see the crash 
when we have 4 dss devices in our board file. The last display pointer 
is corrupted in that case. I'm trying to figure out why.


Archit



  Tomi




--
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 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr

On Tue, 2011-09-27 at 12:24 +0530, Hiremath, Vaibhav wrote:
 If you look at the patch, the patch barely checks for the condition
 and
 makes sure that the interrupt is either of VSYNC or VSYNC2, else
 return. Rest everything is same.

This is what the current code does, in clearer form and slightly pseudo
code:

if (irq == VSYNC || irq == VSYNC2) {
do isr stuff
}

This is what it does after Archit's patch:

if ((lcd == LCD1  irq == VSYNC) || (lcd == LCD2  irq == VSYNC2)) {
do isr stuff;
}

I see a clear difference there. Or am I missing something?

 The right fix is in streamon api, where you mask the interrupt before
 registering it.

I'm not familiar with v4l so I don't know what that means, but yes, it
would be better if it's possible to only register for the needed
interrupts.

But the ISR code is still needed. If you are using both LCDs, you will
get both interrupts and you need to check if the interrupt is for the
right output.

 Tomi


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

Re: [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe

On Tue, 2011-09-27 at 12:32 +0530, Archit Taneja wrote:
 On Tuesday 27 September 2011 11:40 AM, Valkeinen, Tomi wrote:
  On Mon, 2011-09-26 at 17:29 +0530, Archit Taneja wrote:
  Remove the code in omap_vout_probe() which calls display-driver-update() 
  for
  all the displays. This isn't correct because:
 
  - An update in probe doesn't make sense, because we don't have any valid 
  content
 to show at this time.
  - Calling update for a panel which isn't enabled is not supported by DSS2. 
  This
 leads to a crash at probe.
 
  Calling update() on a disabled panel should not crash... Where is the
  crash coming from?
 
 you are right, the crash isn't coming from the updates. I see the crash 
 when we have 4 dss devices in our board file. The last display pointer 
 is corrupted in that case. I'm trying to figure out why.

Could be totally unrelated, but does the V4L2 driver make sure that the
used dss devices have a driver loaded?

OMAPFB previously refused to start if all the devices do not have a
driver, but nowadays it starts fine by skipping the devices without a
driver.

 Tomi


--
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 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr

 -Original Message-
 From: Taneja, Archit
 Sent: Tuesday, September 27, 2011 12:32 PM
 To: Hiremath, Vaibhav
 Cc: Valkeinen, Tomi; Semwal, Sumit; linux-omap@vger.kernel.org; linux-
 me...@vger.kernel.org
 Subject: Re: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in
 omap_vout_isr

 On Tuesday 27 September 2011 12:24 PM, Hiremath, Vaibhav wrote:
  -Original Message-
  From: Valkeinen, Tomi
  Sent: Tuesday, September 27, 2011 12:19 PM
  To: Hiremath, Vaibhav
  Cc: Semwal, Sumit; Taneja, Archit; linux-omap@vger.kernel.org; linux-
  me...@vger.kernel.org
  Subject: RE: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in
  omap_vout_isr

  On Tue, 2011-09-27 at 12:09 +0530, Hiremath, Vaibhav wrote:
  Please look at the patch carefully, it does exactly same thing. I
  understand the use-case what Archit explained in the last email but in
  this patch context, the use-case change anything here in this patch.

  With the current code, the ISR code will be ran for a panel connected
 to
  LCD1 output when VSYNC for LCD2 happens.

  After Archit's patch, this no longer happens.

  I don't know what the ISR code does, so it may not cause any problems,
  but it sure doesn't sound right running the code when a wrong interrupt
  happens.

  If you look at the patch, the patch barely checks for the condition and
  makes sure that the interrupt is either of VSYNC or VSYNC2, else return.
 Rest everything is same.

 It doesn't only make sure that the interrupt it one of them, it uses it
 later too in the check:

 if (!(irqstatus  irq))
   goto vout_isr_err;
 ...
 ...

  The right fix is in streamon api, where you mask the interrupt before
  registering it.

 If this is the right fix, we should have a purely selective method of
 selecting the interrupts. Even for OMAP3, we register interrupts for LCD
 and TV, and then check the interrupt in the handler using panel type.
 Now, since have 2 different interrupts for the same panel type, we have
 to further distinguish using the manager id.

I have to agree here with you that we do not have this available now.

Also I had reviewed the patch again, and I think I now understand what usecase 
you are referring here. My bad, I concluded early on this

Thanks,
Vaibhav

 Archit

  Thanks,
  Vaibhav

Tomi

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

Re: [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe


On Tuesday 27 September 2011 12:37 PM, Valkeinen, Tomi wrote:

On Tue, 2011-09-27 at 12:32 +0530, Archit Taneja wrote:

On Tuesday 27 September 2011 11:40 AM, Valkeinen, Tomi wrote:

On Mon, 2011-09-26 at 17:29 +0530, Archit Taneja wrote:

Remove the code in omap_vout_probe() which calls display-driver-update() for
all the displays. This isn't correct because:

- An update in probe doesn't make sense, because we don't have any valid content
to show at this time.
- Calling update for a panel which isn't enabled is not supported by DSS2. This
leads to a crash at probe.


Calling update() on a disabled panel should not crash... Where is the
crash coming from?


you are right, the crash isn't coming from the updates. I see the crash
when we have 4 dss devices in our board file. The last display pointer
is corrupted in that case. I'm trying to figure out why.


Could be totally unrelated, but does the V4L2 driver make sure that the
used dss devices have a driver loaded?

OMAPFB previously refused to start if all the devices do not have a
driver, but nowadays it starts fine by skipping the devices without a
driver.


The drivers were loaded in. The issue was something else totally. I 
assumed it was something related to update call.


In drivers/media/video/omap/omap_voutdef.h:

struct omap2video_device {
...
...
struct omap_dss_device *displays[MAX_DISPLAYS];
...
...
};

MAX_DISPLAYS is 3, so the 4th display pointer was getting messed up 
wherever we used it.


I guess we don't need this patch. We may want to set MAX_DISPLAYS to a 
higher number i guess, because we could theoretically register as many 
panels as we want, and set/unset them.


Thanks,
Archit



  Tomi


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


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

RE: [PATCH v3 1/4] OMAP_VOUT: Fix check in reqbuf for buf_size allocation


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

I think we agreed in your last version patch patch-series that, the check in 
mmap should be against vout-buffer_size. Am I missing something here?

Thanks,
Vaibhav

   v4l2_err(vout-vid_dev-v4l2_dev,
   insufficient memory [%lu] [%u]\n,
   size, vout-buffer_size);
 --
 1.7.1

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

Re: [PATCH v3 1/4] OMAP_VOUT: Fix check in reqbuf for buf_size allocation


Hi,

On Tuesday 27 September 2011 12:49 PM, Hiremath, Vaibhav wrote:



-Original Message-
From: Taneja, Archit
Sent: Monday, September 26, 2011 5:29 PM
To: Hiremath, Vaibhav
Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux-
me...@vger.kernel.org; Taneja, Archit
Subject: [PATCH v3 1/4] OMAP_VOUT: Fix check in reqbuf for buf_size
allocation

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

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

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

Signed-off-by: Archit Tanejaarc...@ti.com
---
  drivers/media/video/omap/omap_vout.c |   10 --
  1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index d9e64f3..16ebff6 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct
videobuf_queue *q, unsigned int *count,
u32 phy_addr = 0, virt_addr = 0;
struct omap_vout_device *vout = q-priv_data;
struct omapvideo_info *ovid =vout-vid_info;
+   int vid_max_buf_size;

if (!vout)
return -EINVAL;

+   vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize :
+   video2_bufsize;
+
if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q-type)
return -EINVAL;

@@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct
videobuf_queue *q, unsigned int *count,
video1_numbuffers : video2_numbuffers;

/* Check the size of the buffer */
-   if (*size  vout-buffer_size) {
+   if (*size  vid_max_buf_size) {
v4l2_err(vout-vid_dev-v4l2_dev,
buffer allocation mismatch [%u] [%u]\n,
*size, vout-buffer_size);
@@ -865,6 +869,8 @@ static int omap_vout_mmap(struct file *file, struct
vm_area_struct *vma)
unsigned long size = (vma-vm_end - vma-vm_start);
struct omap_vout_device *vout = file-private_data;
struct videobuf_queue *q =vout-vbq;
+   int vid_max_buf_size = vout-vid == OMAP_VIDEO1 ? video1_bufsize :
+   video2_bufsize;

v4l2_dbg(1, debug,vout-vid_dev-v4l2_dev,
 %s pgoff=0x%lx, start=0x%lx, end=0x%lx\n, __func__,
@@ -887,7 +893,7 @@ static int omap_vout_mmap(struct file *file, struct
vm_area_struct *vma)
return -EINVAL;
}
/* Check the size of the buffer */
-   if (size  vout-buffer_size) {
+   if (size  vid_max_buf_size) {


I think we agreed in your last version patch patch-series that, the check in mmap 
should be against vout-buffer_size. Am I missing something here?


I totally missed this out for some reason. I'll correct this in the next 
set. Sorry about this.


Archit



Thanks,
Vaibhav


v4l2_err(vout-vid_dev-v4l2_dev,
insufficient memory [%lu] [%u]\n,
size, vout-buffer_size);
--
1.7.1





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

[PATCH] leds-class: change back LEDS_CLASS to tristate instead of bool

2011-09-27 Thread Bryan Wu

LEDS_CLASS is required by leds and trigger drivers, but we can build it as
module.  So change this option back as tristate and treak the help message
as well.

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

Change those ifdefs to take care of module configuration.

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

diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index b2572f7..fd28696 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -241,7 +241,7 @@ static struct i2c_board_info ams_delta_camera_board_info[] 
= {
},
 };
 
-#ifdef CONFIG_LEDS_TRIGGERS
+#if defined(CONFIG_LEDS_TRIGGERS) || defined(CONFIG_LEDS_TRIGGERS_MODULE)
 DEFINE_LED_TRIGGER(ams_delta_camera_led_trigger);
 
 static int ams_delta_camera_power(struct device *dev, int power)
@@ -320,7 +320,7 @@ static void __init ams_delta_init(void)
 
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
-#ifdef CONFIG_LEDS_TRIGGERS
+#if defined(CONFIG_LEDS_TRIGGERS) || defined(CONFIG_LEDS_TRIGGERS_MODULE)
led_trigger_register_simple(ams_delta_camera,
ams_delta_camera_led_trigger);
 #endif
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ff203a4..c30233e 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -17,10 +17,13 @@ menuconfig NEW_LEDS
 if NEW_LEDS
 
 config LEDS_CLASS
-   bool LED Class Support
+   tristate LED Class Support
help
  This option enables the led sysfs class in /sys/class/leds.  You'll
- need this to do anything useful with LEDs.  If unsure, say N.
+ need this to do anything useful with LEDs.  If unsure, say M.
+
+ Note: don't disable it as N, because plenty of led and trigger drivers
+ are using this option.
 
 comment LED drivers
 
@@ -388,7 +391,7 @@ config LEDS_RENESAS_TPU
  Brightness control is supported but hardware blinking is not.
 
 config LEDS_TRIGGERS
-   bool LED Trigger support
+   tristate LED Trigger support
depends on LEDS_CLASS
help
  This option enables trigger support for the leds class.
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index dc3d3d8..1f54cb0 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -75,7 +75,7 @@ static ssize_t led_max_brightness_show(struct device *dev,
 static struct device_attribute led_class_attrs[] = {
__ATTR(brightness, 0644, led_brightness_show, led_brightness_store),
__ATTR(max_brightness, 0444, led_max_brightness_show, NULL),
-#ifdef CONFIG_LEDS_TRIGGERS
+#if defined(CONFIG_LEDS_TRIGGERS) || defined(CONFIG_LEDS_TRIGGERS_MODULE)
__ATTR(trigger, 0644, led_trigger_show, led_trigger_store),
 #endif
__ATTR_NULL,
@@ -209,7 +209,7 @@ int led_classdev_register(struct device *parent, struct 
led_classdev *led_cdev)
if (IS_ERR(led_cdev-dev))
return PTR_ERR(led_cdev-dev);
 
-#ifdef CONFIG_LEDS_TRIGGERS
+#if defined(CONFIG_LEDS_TRIGGERS) || defined(CONFIG_LEDS_TRIGGERS_MODULE)
init_rwsem(led_cdev-trigger_lock);
 #endif
/* add to the list of leds */
@@ -226,7 +226,7 @@ int led_classdev_register(struct device *parent, struct 
led_classdev *led_cdev)
led_cdev-blink_timer.function = led_timer_function;
led_cdev-blink_timer.data = (unsigned long)led_cdev;
 
-#ifdef CONFIG_LEDS_TRIGGERS
+#if defined(CONFIG_LEDS_TRIGGERS) || defined(CONFIG_LEDS_TRIGGERS_MODULE)
led_trigger_set_default(led_cdev);
 #endif
 
@@ -245,7 +245,7 @@ EXPORT_SYMBOL_GPL(led_classdev_register);
  */
 void led_classdev_unregister(struct led_classdev *led_cdev)
 {
-#ifdef CONFIG_LEDS_TRIGGERS
+#if defined(CONFIG_LEDS_TRIGGERS) || defined(CONFIG_LEDS_TRIGGERS_MODULE)
down_write(led_cdev-trigger_lock);
if (led_cdev-trigger)
led_trigger_set(led_cdev, NULL);
diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
index e77c7f8..53b59b7 100644
--- a/drivers/leds/leds.h
+++ b/drivers/leds/leds.h
@@ -35,7 +35,7 @@ static inline int led_get_brightness(struct led_classdev 
*led_cdev)
 extern struct rw_semaphore leds_list_lock;
 extern struct list_head leds_list;
 
-#ifdef CONFIG_LEDS_TRIGGERS
+#if defined(CONFIG_LEDS_TRIGGERS) || defined(CONFIG_LEDS_TRIGGERS_MODULE)
 void

RE: [PATCH] ti816x: add support for nand on ti8168 evm

2011-09-27 Thread Saxena, Parth

If there are no review comments on this patch, can this be merged?

Thanks and Regards,
Parth

 -Original Message-
 From: Saxena, Parth
 Sent: Monday, September 19, 2011 6:54 PM
 To: linux-omap@vger.kernel.org
 Cc: linux-...@lists.infradead.org; t...@atomide.com; Saxena, Parth;
 Basheer, Mansoor Ahamed
 Subject: [PATCH] ti816x: add support for nand on ti8168 evm
 
 Add partition table for NAND device on TI8168 EVM
 and initialise the NAND module.
 
 Signed-off-by: Saxena, Parth parth.sax...@ti.com
 Signed-off-by: Basheer, Mansoor Ahamed mansoor.aha...@ti.com
 ---
 
 This patch is tested on top of linux-omap/master and
 Hemant's patches submitted recently.
 
 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53457.html
 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg54296.html
 
  arch/arm/mach-omap2/board-ti8168evm.c |   39
 +
  1 files changed, 39 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/board-ti8168evm.c b/arch/arm/mach-
 omap2/board-ti8168evm.c
 index e516a04..87953bb 100644
 --- a/arch/arm/mach-omap2/board-ti8168evm.c
 +++ b/arch/arm/mach-omap2/board-ti8168evm.c
 @@ -14,6 +14,7 @@
   */
  #include linux/kernel.h
  #include linux/init.h
 +#include linux/mtd/nand.h
 
  #include mach/hardware.h
  #include asm/mach-types.h
 @@ -23,6 +24,42 @@
  #include plat/irqs.h
  #include plat/board.h
  #include plat/common.h
 +#include plat/gpmc.h
 +#include plat/nand.h
 +
 +#include board-flash.h
 +
 +#define NAND_BLOCK_SIZE  SZ_128K
 +
 +static struct mtd_partition ti816x_nand_partitions[] = {
 +/* All the partition sizes are listed in terms of NAND block size */
 + {
 + .name   = U-Boot,
 + .offset = 0,/* Offset = 0x0 */
 + .size   = 18 * NAND_BLOCK_SIZE,
 + .mask_flags = MTD_WRITEABLE,/* force read-only */
 + },
 + {
 + .name   = U-Boot Env,
 + .offset = MTDPART_OFS_APPEND,   /* Offset = 0x24
 */
 + .size   = 2 * NAND_BLOCK_SIZE,
 + },
 + {
 + .name   = Kernel,
 + .offset = MTDPART_OFS_APPEND,   /* Offset = 0x28
 */
 + .size   = 34 * NAND_BLOCK_SIZE,
 + },
 + {
 + .name   = File System,
 + .offset = MTDPART_OFS_APPEND,   /* Offset = 0x6C
 */
 + .size   = 1601 * NAND_BLOCK_SIZE,
 + },
 + {
 + .name   = Reserved,
 + .offset = MTDPART_OFS_APPEND,   /* Offset =
 0xCEE */
 + .size   = MTDPART_SIZ_FULL,
 + },
 +};
 
  static struct omap_board_config_kernel ti8168_evm_config[] __initdata = {
  };
 @@ -35,6 +72,8 @@ static void __init ti8168_init_early(void)
 
  static void __init ti8168_evm_init(void)
  {
 + board_nand_init(ti816x_nand_partitions,
 + ARRAY_SIZE(ti816x_nand_partitions), 0, NAND_BUSWIDTH_16);
   omap_serial_init();
   omap_board_config = ti8168_evm_config;
   omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
 --
 1.6.2.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 v3 0/6] iommu: split mapping to page sizes as supported by the hardware

ping

On Fri, Sep 16, 2011 at 8:51 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 v2-v3:

 - s/KB/KiB/ (David W)

 v1-v2:

 - split to patches (by keeping the old code around until all drivers are 
 converted) (Joerg)


 Ohad Ben-Cohen (6):
  iommu/core: split mapping to page sizes as supported by the hardware
  iommu/omap: announce supported page sizes
  iommu/msm: announce supported page sizes
  iommu/amd: announce supported page sizes
  iommu/intel: announce supported page sizes
  iommu/core: remove the temporary register_iommu_pgsize API

  drivers/iommu/amd_iommu.c   |   20 ++-
  drivers/iommu/intel-iommu.c |   20 ++-
  drivers/iommu/iommu.c       |  130 
 +++
  drivers/iommu/msm_iommu.c   |    8 ++-
  drivers/iommu/omap-iommu.c  |    6 ++-
  drivers/iommu/omap-iovmm.c  |   12 +---
  include/linux/iommu.h       |    7 +-
  virt/kvm/iommu.c            |    4 +-
  8 files changed, 177 insertions(+), 30 deletions(-)

 --
 1.7.4.1


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

[PATCH V7 0/4] cpuidle: Global registration of idle states with per-cpu statistics

Version 6 of this patch series dated 22nd Sept 2011 was 
Acked-by: Arjan van de Ven ar...@linux.intel.com
Acked-by: Kevin Hilman khil...@ti.com for OMAP specific parts.
Reviewed-by: Kevin Hilman khil...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com

Hi Len, 
Can you please queue this series for the next mainline merge window by merging
it into your development tree and also linux-next for further testing.

I also tested it, by applying these patches on your ACPI tree hosted @github.

Thanks
-Deepthi


The following patch series implements global registration of cpuidle
states, and also has the necessary data structure changes to
accommodate the per-cpu writable members of the cpuidle_states
structure.

This patch series had been in discussion earlier and
following are the links to the previous discussions.

v1 -- https://lkml.org/lkml/2011/3/22/161
v2 -- https://lkml.org/lkml/2011/1/13/98
v3 -- https://lkml.org/lkml/2011/2/8/73
v4 -- https://lkml.org/lkml/2011/4/28/312
v5 -- https://lkml.org/lkml/2011/6/6/259
v6 -- https://lkml.org/lkml/2011/9/22/58

Changes from previous version (V6):

   Removed the RFC tag.

Tests done:

1. Compile tested for ARM using the following configs: 
da8xx_omapl_defconfig,
exynos4_defconfig, kirkwood_defconfig, omap2plus_defconfig, 
at91rm9200_defconfig
  
2. Boot tested on x86 nehalem with multiple C-states for both intel_idle
and acpi_idle drivers.

3. Boot tested on T60p thinkpad that has T2600 cpu with multiple C-states. 
Also tested the case when there is dynamic changes in C-states 
AC - Battery Power switch.

Brief description of the patches:

Core change in this series is to split the cpuidle_device structure 
into two parts, i.e  global and per-cpu basis. 

The per-cpu pieces are mostly generic statistics that can be independent 
of current running driver. As a result of these changes, there is single 
copy of cpuidle_states structure and single registration done by one 
cpu. The low level driver is free to set per-cpu driver data on
each cpu if needed using the cpuidle_set_statedata() as the case
today. Only in very rare cases asymmetric C-states exist which can be 
handled within the cpuidle driver. Most architectures do not have 
asymmetric C-states.

First two patches in the series facilitate splitting of cpuidle_states
and cpuidle_device structure and next two patches do the actual split,
change the API's and make existing code follow the changed API.

[1/4] - Move the idle residency accounting part from cpuidle.c to
the respective low level drivers, so that the accounting can
be accurately maintained if the driver decides to demote the
chosen (suggested) by the governor.

[2/4] - removes the cpuidle_device()-prepare API since is is not
widely used and the only use case was to allow software
demotion using CPUIDLE_FLAG_IGNORE flag.  Both these
functions can be absorbed within the cpuidle back-end
driver ad hence deprecating the prepare routine and the
CPUIDLE_FLAG_IGNORE flag.

- Ref: https://lkml.org/lkml/2011/3/25/52

[3/4] - Splits the usage statistics (read/write) part out of
cpuidle_state structure, so that the states can become read
only and hence made global.

[4/4] - Most APIs will now need to pass pointer to both global
cpuidle_driver and per-cpu cpuidle_device structure.

 arch/arm/mach-at91/cpuidle.c  |   41 +++--
 arch/arm/mach-davinci/cpuidle.c   |   51 ---
 arch/arm/mach-exynos4/cpuidle.c   |   30 ++--
 arch/arm/mach-kirkwood/cpuidle.c  |   42 +++---
 arch/arm/mach-omap2/cpuidle34xx.c |  133 +++--
 arch/sh/kernel/cpu/shmobile/cpuidle.c |   28 ++--
 drivers/acpi/processor_driver.c   |   20 ---
 drivers/acpi/processor_idle.c |  251 +++--
 drivers/cpuidle/cpuidle.c |   86 ---
 drivers/cpuidle/driver.c  |   25 +++
 drivers/cpuidle/governors/ladder.c|   41 -
 drivers/cpuidle/governors/menu.c  |   29 ++--
 drivers/cpuidle/sysfs.c   |   22 ++-
 drivers/idle/intel_idle.c |  130 +
 include/acpi/processor.h  |1 
 include/linux/cpuidle.h   |   52 ---
 16 files changed, 650 insertions(+), 332 deletions(-)


-- 

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

[PATCH V7 1/4] cpuidle: Move dev-last_residency update to driver enter routine; remove dev-last_state

Cpuidle governor only suggests the state to enter using the
governor-select() interface, but allows the low level driver to
override the recommended state. The actual entered state
may be different because of software or hardware demotion. Software
demotion is done by the back-end cpuidle driver and can be accounted
correctly. Current cpuidle code uses last_state field to capture the
actual state entered and based on that updates the statistics for the
state entered.

Ideally the driver enter routine should update the counters,
and it should return the state actually entered rather than the time
spent there. The generic cpuidle code should simply handle where
the counters live in the sysfs namespace, not updating the counters.

Reference:
https://lkml.org/lkml/2011/3/25/52

Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
Signed-off-by: Trinabh Gupta g.trin...@gmail.com
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Acked-by: Arjan van de Ven ar...@linux.intel.com
Acked-by: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-at91/cpuidle.c  |   10 +++-
 arch/arm/mach-davinci/cpuidle.c   |9 +++-
 arch/arm/mach-exynos4/cpuidle.c   |7 ++-
 arch/arm/mach-kirkwood/cpuidle.c  |   12 -
 arch/arm/mach-omap2/cpuidle34xx.c |   67 +
 arch/sh/kernel/cpu/shmobile/cpuidle.c |   12 +++--
 drivers/acpi/processor_idle.c |   75 ++---
 drivers/cpuidle/cpuidle.c |   32 +++---
 drivers/cpuidle/governors/ladder.c|   13 ++
 drivers/cpuidle/governors/menu.c  |7 ++-
 drivers/idle/intel_idle.c |   12 -
 include/linux/cpuidle.h   |7 +--
 12 files changed, 164 insertions(+), 99 deletions(-)

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 1cfeac1..4696a0d 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -33,7 +33,7 @@ static struct cpuidle_driver at91_idle_driver = {
 
 /* Actual code that puts the SoC in different idle states */
 static int at91_enter_idle(struct cpuidle_device *dev,
-  struct cpuidle_state *state)
+  int index)
 {
struct timeval before, after;
int idle_time;
@@ -41,10 +41,10 @@ static int at91_enter_idle(struct cpuidle_device *dev,
 
local_irq_disable();
do_gettimeofday(before);
-   if (state == dev-states[0])
+   if (index == 0)
/* Wait for interrupt state */
cpu_do_idle();
-   else if (state == dev-states[1]) {
+   else if (index == 1) {
asm(b 1f; .align 5; 1:);
asm(mcr p15, 0, r0, c7, c10, 4);  /* drain write buffer */
saved_lpr = sdram_selfrefresh_enable();
@@ -55,7 +55,9 @@ static int at91_enter_idle(struct cpuidle_device *dev,
local_irq_enable();
idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
(after.tv_usec - before.tv_usec);
-   return idle_time;
+
+   dev-last_residency = idle_time;
+   return index;
 }
 
 /* Initialize CPU idle by registering the idle states */
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index bd59f31..ca8582a 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -78,9 +78,9 @@ static struct davinci_ops 
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
 
 /* Actual code that puts the SoC in different idle states */
 static int davinci_enter_idle(struct cpuidle_device *dev,
-   struct cpuidle_state *state)
+   int index)
 {
-   struct davinci_ops *ops = cpuidle_get_statedata(state);
+   struct davinci_ops *ops = cpuidle_get_statedata(dev-states[index]);
struct timeval before, after;
int idle_time;
 
@@ -98,7 +98,10 @@ static int davinci_enter_idle(struct cpuidle_device *dev,
local_irq_enable();
idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
(after.tv_usec - before.tv_usec);
-   return idle_time;
+
+   dev-last_residency = idle_time;
+
+   return index;
 }
 
 static int __init davinci_cpuidle_probe(struct platform_device *pdev)
diff --git a/arch/arm/mach-exynos4/cpuidle.c b/arch/arm/mach-exynos4/cpuidle.c
index bf7e96f..ea026e7 100644
--- a/arch/arm/mach-exynos4/cpuidle.c
+++ b/arch/arm/mach-exynos4/cpuidle.c
@@ -16,7 +16,7 @@
 #include asm/proc-fns.h
 
 static int exynos4_enter_idle(struct cpuidle_device *dev,
- struct cpuidle_state *state);
+ int index);
 
 static struct cpuidle_state exynos4_cpuidle_set[] = {
[0] = {
@@ -37,7 +37,7 @@ static struct cpuidle_driver exynos4_idle_driver = {
 };
 
 static int exynos4_enter_idle(struct cpuidle_device *dev,
-

[PATCH V7 2/4] cpuidle: Remove CPUIDLE_FLAG_IGNORE and dev-prepare()

The cpuidle_device-prepare() mechanism causes updates to the
cpuidle_state[].flags, setting and clearing CPUIDLE_FLAG_IGNORE
to tell the governor not to chose a state on a per-cpu basis at
run-time. State demotion is now handled by the driver and it returns
the actual state entered. Hence, this mechanism is not required.
Also this removes per-cpu flags from cpuidle_state enabling
it to be made global.

Reference:
https://lkml.org/lkml/2011/3/25/52

Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm
Signed-off-by: Trinabh Gupta g.trin...@gmail.com
Signed-off-by: Jean Pihet j-pi...@ti.com
Acked-by: Arjan van de Ven ar...@linux.intel.com
Reviewed-by: Kevin Hilman khil...@ti.com
---
 drivers/cpuidle/cpuidle.c|   10 --
 drivers/cpuidle/governors/menu.c |2 --
 include/linux/cpuidle.h  |3 ---
 3 files changed, 0 insertions(+), 15 deletions(-)

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 88bd121..f66bcf9 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -83,16 +83,6 @@ int cpuidle_idle_call(void)
hrtimer_peek_ahead_timers();
 #endif
 
-   /*
-* Call the device's prepare function before calling the
-* governor's select function.  -prepare gives the device's
-* cpuidle driver a chance to update any dynamic information
-* of its cpuidle states for the current idle period, e.g.
-* state availability, latencies, residencies, etc.
-*/
-   if (dev-prepare)
-   dev-prepare(dev);
-
/* ask the governor for the next state */
next_state = cpuidle_curr_governor-select(dev);
if (need_resched()) {
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index e4b200c..af724e8 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -288,8 +288,6 @@ static int menu_select(struct cpuidle_device *dev)
for (i = CPUIDLE_DRIVER_STATE_START; i  dev-state_count; i++) {
struct cpuidle_state *s = dev-states[i];
 
-   if (s-flags  CPUIDLE_FLAG_IGNORE)
-   continue;
if (s-target_residency  data-predicted_us)
continue;
if (s-exit_latency  latency_req)
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 8da811b..c6d85cf 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -47,7 +47,6 @@ struct cpuidle_state {
 
 /* Idle State Flags */
 #define CPUIDLE_FLAG_TIME_VALID(0x01) /* is residency time measurable? 
*/
-#define CPUIDLE_FLAG_IGNORE(0x100) /* ignore during this idle period */
 
 #define CPUIDLE_DRIVER_FLAGS_MASK (0x)
 
@@ -93,8 +92,6 @@ struct cpuidle_device {
struct completion   kobj_unregister;
void*governor_data;
int safe_state_index;
-
-   int (*prepare)  (struct cpuidle_device *dev);
 };
 
 DECLARE_PER_CPU(struct cpuidle_device *, cpuidle_devices);

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

[PATCH V7 3/4] cpuidle: Split cpuidle_state structure and move per-cpu statistics fields

This is the first step towards global registration of cpuidle
states. The statistics used primarily by the governor are per-cpu
and have to be split from rest of the fields inside cpuidle_state,
which would be made global i.e. single copy. The driver_data field
is also per-cpu and moved.

Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
Signed-off-by: Trinabh Gupta g.trin...@gmail.com
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Acked-by: Arjan van de Ven ar...@linux.intel.com
Acked-by: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-davinci/cpuidle.c   |5 ++--
 arch/arm/mach-omap2/cpuidle34xx.c |   13 ++
 drivers/acpi/processor_idle.c |   25 ++--
 drivers/cpuidle/cpuidle.c |   11 +
 drivers/cpuidle/sysfs.c   |   19 ++-
 drivers/idle/intel_idle.c |   46 +++--
 include/linux/cpuidle.h   |   25 
 7 files changed, 90 insertions(+), 54 deletions(-)

diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index ca8582a..f2d2f34 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -80,7 +80,8 @@ static struct davinci_ops 
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
 static int davinci_enter_idle(struct cpuidle_device *dev,
int index)
 {
-   struct davinci_ops *ops = cpuidle_get_statedata(dev-states[index]);
+   struct cpuidle_state_usage *state_usage = dev-states_usage[index];
+   struct davinci_ops *ops = cpuidle_get_statedata(state_usage);
struct timeval before, after;
int idle_time;
 
@@ -142,7 +143,7 @@ static int __init davinci_cpuidle_probe(struct 
platform_device *pdev)
strcpy(device-states[1].desc, WFI and DDR Self Refresh);
if (pdata-ddr2_pdown)
davinci_states[1].flags |= DAVINCI_CPUIDLE_FLAGS_DDR2_PWDN;
-   cpuidle_set_statedata(device-states[1], davinci_states[1]);
+   cpuidle_set_statedata(device-states_usage[1], davinci_states[1]);
 
device-state_count = DAVINCI_CPUIDLE_MAX_STATES;
 
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 58425c7..d3fce7b 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -97,7 +97,7 @@ static int omap3_enter_idle(struct cpuidle_device *dev,
int index)
 {
struct omap3_idle_statedata *cx =
-   cpuidle_get_statedata(dev-states[index]);
+   cpuidle_get_statedata(dev-states_usage[index]);
struct timespec ts_preidle, ts_postidle, ts_idle;
u32 mpu_state = cx-mpu_state, core_state = cx-core_state;
int idle_time;
@@ -160,8 +160,9 @@ return_sleep_time:
 static int next_valid_state(struct cpuidle_device *dev,
int index)
 {
+   struct cpuidle_state_usage *curr_usage = dev-states_usage[index];
struct cpuidle_state *curr = dev-states[index];
-   struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr);
+   struct omap3_idle_statedata *cx = cpuidle_get_statedata(curr_usage);
u32 mpu_deepest_state = PWRDM_POWER_RET;
u32 core_deepest_state = PWRDM_POWER_RET;
int next_index = -1;
@@ -202,7 +203,7 @@ static int next_valid_state(struct cpuidle_device *dev,
 */
idx--;
for (; idx = 0; idx--) {
-   cx = cpuidle_get_statedata(dev-states[idx]);
+   cx = cpuidle_get_statedata(dev-states_usage[idx]);
if ((cx-valid) 
(cx-mpu_state = mpu_deepest_state) 
(cx-core_state = core_deepest_state)) {
@@ -231,7 +232,6 @@ static int next_valid_state(struct cpuidle_device *dev,
 static int omap3_enter_idle_bm(struct cpuidle_device *dev,
   int index)
 {
-   struct cpuidle_state *state = dev-states[index];
int new_state_idx;
u32 core_next_state, per_next_state = 0, per_saved_state = 0, cam_state;
struct omap3_idle_statedata *cx;
@@ -264,7 +264,7 @@ static int omap3_enter_idle_bm(struct cpuidle_device *dev,
 * Prevent PER off if CORE is not in retention or off as this
 * would disable PER wakeups completely.
 */
-   cx = cpuidle_get_statedata(state);
+   cx = cpuidle_get_statedata(dev-states_usage[index]);
core_next_state = cx-core_state;
per_next_state = per_saved_state = pwrdm_read_next_pwrst(per_pd);
if ((per_next_state == PWRDM_POWER_OFF) 
@@ -318,6 +318,7 @@ static inline struct omap3_idle_statedata *_fill_cstate(
 {
struct omap3_idle_statedata *cx = omap3_idle_data[idx];
struct cpuidle_state *state = dev-states[idx];
+   struct cpuidle_state_usage *state_usage = dev-states_usage[idx];

[PATCH V7 4/4] cpuidle: Single/Global registration of idle states

This patch makes the cpuidle_states structure global (single copy)
instead of per-cpu. The statistics needed on per-cpu basis
by the governor are kept per-cpu. This simplifies the cpuidle
subsystem as state registration is done by single cpu only.
Having single copy of cpuidle_states saves memory. Rare case
of asymmetric C-states can be handled within the cpuidle driver
and architectures such as POWER do not have asymmetric C-states.

Having single/global registration for all the idle states,
dynamic C-state transitions on x86 are handled by
the boot cpu. Here, the boot cpu  would disable all the devices,
re-populate the states and later enable all the devices,
irrespective of the cpu that would receive the notification first.

Reference:
https://lkml.org/lkml/2011/4/25/83

Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
Signed-off-by: Trinabh Gupta g.trin...@gmail.com
Signed-off-by: Jean Pihet j-pi...@ti.com
Reviewed-by: Kevin Hilman khil...@ti.com
Acked-by: Arjan van de Ven ar...@linux.intel.com
Acked-by: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-at91/cpuidle.c  |   31 +++--
 arch/arm/mach-davinci/cpuidle.c   |   39 ---
 arch/arm/mach-exynos4/cpuidle.c   |   23 ++--
 arch/arm/mach-kirkwood/cpuidle.c  |   30 +++--
 arch/arm/mach-omap2/cpuidle34xx.c |   73 -
 arch/sh/kernel/cpu/shmobile/cpuidle.c |   18 ++-
 drivers/acpi/processor_driver.c   |   20 +--
 drivers/acpi/processor_idle.c |  191 +
 drivers/cpuidle/cpuidle.c |   45 ++--
 drivers/cpuidle/driver.c  |   25 
 drivers/cpuidle/governors/ladder.c|   28 +++--
 drivers/cpuidle/governors/menu.c  |   20 ++-
 drivers/cpuidle/sysfs.c   |3 -
 drivers/idle/intel_idle.c |   80 +++---
 include/acpi/processor.h  |1 
 include/linux/cpuidle.h   |   19 ++-
 16 files changed, 439 insertions(+), 207 deletions(-)

diff --git a/arch/arm/mach-at91/cpuidle.c b/arch/arm/mach-at91/cpuidle.c
index 4696a0d..93178f6 100644
--- a/arch/arm/mach-at91/cpuidle.c
+++ b/arch/arm/mach-at91/cpuidle.c
@@ -33,6 +33,7 @@ static struct cpuidle_driver at91_idle_driver = {
 
 /* Actual code that puts the SoC in different idle states */
 static int at91_enter_idle(struct cpuidle_device *dev,
+   struct cpuidle_driver *drv,
   int index)
 {
struct timeval before, after;
@@ -64,27 +65,29 @@ static int at91_enter_idle(struct cpuidle_device *dev,
 static int at91_init_cpuidle(void)
 {
struct cpuidle_device *device;
-
-   cpuidle_register_driver(at91_idle_driver);
+   struct cpuidle_driver *driver = at91_idle_driver;
 
device = per_cpu(at91_cpuidle_device, smp_processor_id());
device-state_count = AT91_MAX_STATES;
+   driver-state_count = AT91_MAX_STATES;
 
/* Wait for interrupt state */
-   device-states[0].enter = at91_enter_idle;
-   device-states[0].exit_latency = 1;
-   device-states[0].target_residency = 1;
-   device-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
-   strcpy(device-states[0].name, WFI);
-   strcpy(device-states[0].desc, Wait for interrupt);
+   driver-states[0].enter = at91_enter_idle;
+   driver-states[0].exit_latency = 1;
+   driver-states[0].target_residency = 1;
+   driver-states[0].flags = CPUIDLE_FLAG_TIME_VALID;
+   strcpy(driver-states[0].name, WFI);
+   strcpy(driver-states[0].desc, Wait for interrupt);
 
/* Wait for interrupt and RAM self refresh state */
-   device-states[1].enter = at91_enter_idle;
-   device-states[1].exit_latency = 10;
-   device-states[1].target_residency = 1;
-   device-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
-   strcpy(device-states[1].name, RAM_SR);
-   strcpy(device-states[1].desc, WFI and RAM Self Refresh);
+   driver-states[1].enter = at91_enter_idle;
+   driver-states[1].exit_latency = 10;
+   driver-states[1].target_residency = 1;
+   driver-states[1].flags = CPUIDLE_FLAG_TIME_VALID;
+   strcpy(driver-states[1].name, RAM_SR);
+   strcpy(driver-states[1].desc, WFI and RAM Self Refresh);
+
+   cpuidle_register_driver(at91_idle_driver);
 
if (cpuidle_register_device(device)) {
printk(KERN_ERR at91_init_cpuidle: Failed registering\n);
diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
index f2d2f34..dbeeccd 100644
--- a/arch/arm/mach-davinci/cpuidle.c
+++ b/arch/arm/mach-davinci/cpuidle.c
@@ -78,6 +78,7 @@ static struct davinci_ops 
davinci_states[DAVINCI_CPUIDLE_MAX_STATES] = {
 
 /* Actual code that puts the SoC in different idle states */
 static int davinci_enter_idle(struct cpuidle_device *dev,
+   struct cpuidle_driver *drv,
int index)
 {
struct cpuidle_state_usage *state_usage =

Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware

2011-09-27 Thread Roedel, Joerg

On Fri, Sep 16, 2011 at 01:51:41PM -0400, Ohad Ben-Cohen wrote:
  drivers/iommu/iommu.c  |  158 
 +---
  drivers/iommu/omap-iovmm.c |   12 +---
  include/linux/iommu.h  |6 +-
  virt/kvm/iommu.c   |4 +-
  4 files changed, 157 insertions(+), 23 deletions(-)
 
 diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
 index c68ff29..7c01c8c 100644
 --- a/drivers/iommu/iommu.c
 +++ b/drivers/iommu/iommu.c
 @@ -16,6 +16,8 @@
   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
   */
 
 +#define pr_fmt(fmt)%s:  fmt, __func__
 +
  #include linux/kernel.h
  #include linux/bug.h
  #include linux/types.h
 @@ -23,15 +25,73 @@
  #include linux/slab.h
  #include linux/errno.h
  #include linux/iommu.h
 +#include linux/bitmap.h
 
  static struct iommu_ops *iommu_ops;
 
 +/* bitmap of supported page sizes */
 +static unsigned long *iommu_pgsize_bitmap;
 +
 +/* number of bits used to represent the supported pages */
 +static unsigned int iommu_nr_page_bits;
 +
 +/* size of the smallest supported page (in bytes) */
 +static unsigned int iommu_min_pagesz;
 +
 +/* bit number of the smallest supported page */
 +static unsigned int iommu_min_page_idx;
 +
 +/**
 + * register_iommu() - register an IOMMU hardware
 + * @ops: iommu handlers
 + * @pgsize_bitmap: bitmap of page sizes supported by the hardware
 + * @nr_page_bits: size of @pgsize_bitmap (in bits)
 + *
 + * Note: this is a temporary function, which will be removed once
 + * all IOMMU drivers are converted. The only reason it exists is to
 + * allow splitting the pgsizes changes to several patches in order to ease
 + * the review.
 + */
 +void register_iommu_pgsize(struct iommu_ops *ops, unsigned long 
 *pgsize_bitmap,
 +   unsigned int nr_page_bits)

I think a plain unsigned long value is sufficient to encode the
supported page-sizes. No need to use a full bitmap.

  int iommu_map(struct iommu_domain *domain, unsigned long iova,
 - phys_addr_t paddr, int gfp_order, int prot)
 + phys_addr_t paddr, size_t size, int prot)
  {
 -   size_t size;
 +   int ret = 0;
 +
 +   /*
 +* both the virtual address and the physical one, as well as
 +* the size of the mapping, must be aligned (at least) to the
 +* size of the smallest page supported by the hardware
 +*/
 +   if (!IS_ALIGNED(iova | paddr | size, iommu_min_pagesz)) {
 +   pr_err(unaligned: iova 0x%lx pa 0x%lx size 0x%lx min_pagesz 
 +   0x%x\n, iova, (unsigned long)paddr,
 +   (unsigned long)size, iommu_min_pagesz);
 +   return -EINVAL;
 +   }
 +
 +   pr_debug(map: iova 0x%lx pa 0x%lx size 0x%lx\n, iova,
 +   (unsigned long)paddr, (unsigned long)size);
 +
 +   while (size) {
 +   unsigned long pgsize = iommu_min_pagesz;
 +   unsigned long idx = iommu_min_page_idx;
 +   unsigned long addr_merge = iova | paddr;
 +   int order;
 +
 +   /* find the max page size with which iova, paddr are aligned 
 */
 +   for (;;) {
 +   unsigned long try_pgsize;
 +
 +   idx = find_next_bit(iommu_pgsize_bitmap,
 +   iommu_nr_page_bits, idx + 1);
 +
 +   /* no more pages to check ? */
 +   if (idx = iommu_nr_page_bits)
 +   break;
 +
 +   try_pgsize = 1  idx;
 
 -   size = 0x1000UL  gfp_order;
 +   /* page too big ? addresses not aligned ? */
 +   if (size  try_pgsize ||
 +   !IS_ALIGNED(addr_merge, try_pgsize))
 +   break;
 
 -   BUG_ON(!IS_ALIGNED(iova | paddr, size));
 +   pgsize = try_pgsize;
 +   }

With an unsigned long you can use plain and fast bit_ops instead of the
full bitmap functions. 

 
 -   return iommu_ops-map(domain, iova, paddr, gfp_order, prot);
 +   order = get_order(pgsize);
 +
 +   pr_debug(mapping: iova 0x%lx pa 0x%lx order %d\n, iova,
 +   (unsigned long)paddr, order);
 +
 +   ret = iommu_ops-map(domain, iova, paddr, order, prot);
 +   if (ret)
 +   break;
 +
 +   size -= pgsize;
 +   iova += pgsize;
 +   paddr += pgsize;
 +   }
 +
 +   return ret;
  }
  EXPORT_SYMBOL_GPL(iommu_map);
 

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

--
To unsubscribe from this list: send the line unsubscribe linux-omap in

[PATCH 1/9] regulator: twl: Remove hardcoded board constraints from driver

Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
each regulator from the twl driver and let the boards pass it.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 drivers/regulator/twl-regulator.c |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index ee8747f..f696287 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -1027,14 +1027,6 @@ static int __devinit twlreg_probe(struct platform_device 
*pdev)
/* copy the features into regulator data */
info-features = (unsigned long)initdata-driver_data;
 
-   /* Constrain board-specific capabilities according to what
-* this driver and the chip itself can actually do.
-*/
-   c = initdata-constraints;
-   c-valid_modes_mask = REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
-   c-valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
-   | REGULATOR_CHANGE_MODE
-   | REGULATOR_CHANGE_STATUS;
switch (pdev-id) {
case TWL4030_REG_VIO:
case TWL4030_REG_VDD1:
-- 
1.7.1

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

[PATCH 0/9] Device tree support for regulators

Hi Mark, Grant,

This is a respin of my RFC series I posted sometime back
and is now based on top of the latest omap i2c-twl support
series posted by Benoit
git://gitorious.org/omap-pm/linux.git for_3.2/4_omap_dt_i2c_twl

some changes done since the RFC:
1. twl driver fixed to remove hardcoded board params
2. regulator helpers moved from drivers/of to drivers/regulator
3. Better compatible definitions for specific device type
4. twl regulator driver doing internal table lookup based on
compatible rather then pdev-id
5. Seperate fixed voltage regulator bindings defined
6. Changed the way devices associate with regulators
i.e using name-supply = regulator-phandle;

regards,
Rajendra

Rajendra Nayak (9):
  regulator: twl: Remove hardcoded board constraints from driver
  regulator: helper routine to extract regulator_init_data
  omap4: sdp: Pass regulator data from dt
  regulator: twl: Make twl-regulator driver extract data from DT
  regulator: helper routine to extract fixed_voltage_config
  regulator: make fixed regulator driver extract data from dt
  omap4: panda: Pass regulator data from DT
  regulator: helper to extract regulator node based on supply name
  regulator: map consumer regulator based on device tree

 .../bindings/regulator/fixed-regulator.txt |   24 
 .../devicetree/bindings/regulator/regulator.txt|   42 +++
 .../bindings/regulator/twl-regulator.txt   |   60 +
 arch/arm/boot/dts/omap4-panda.dts  |   54 
 arch/arm/boot/dts/omap4-sdp.dts|   64 ++
 drivers/regulator/Kconfig  |7 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/core.c   |   14 ++
 drivers/regulator/fixed.c  |   54 -
 drivers/regulator/of_regulator.c   |  127 
 drivers/regulator/twl-regulator.c  |  125 
 include/linux/regulator/driver.h   |3 +
 include/linux/regulator/fixed.h|6 +-
 include/linux/regulator/machine.h  |   12 +-
 include/linux/regulator/of_regulator.h |   28 +
 15 files changed, 562 insertions(+), 59 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/fixed-regulator.txt
 create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/twl-regulator.txt
 create mode 100644 drivers/regulator/of_regulator.c
 create mode 100644 include/linux/regulator/of_regulator.h

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

[PATCH 6/9] regulator: make fixed regulator driver extract data from dt

Modify the fixed regulator driver to extract fixed_voltage_config from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 drivers/regulator/fixed.c |   18 +-
 1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index c09f791..0a9a10d 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -140,10 +140,15 @@ static struct regulator_ops fixed_voltage_ops = {
 
 static int __devinit reg_fixed_voltage_probe(struct platform_device *pdev)
 {
-   struct fixed_voltage_config *config = pdev-dev.platform_data;
+   struct fixed_voltage_config *config;
struct fixed_voltage_data *drvdata;
int ret;
 
+   if (pdev-dev.of_node)
+   config = of_get_fixed_voltage_config(pdev-dev);
+   else
+   config = pdev-dev.platform_data;
+
drvdata = kzalloc(sizeof(struct fixed_voltage_data), GFP_KERNEL);
if (drvdata == NULL) {
dev_err(pdev-dev, Failed to allocate device data\n);
@@ -252,12 +257,23 @@ static int __devexit reg_fixed_voltage_remove(struct 
platform_device *pdev)
return 0;
 }
 
+#if defined(CONFIG_OF)
+static const struct of_device_id fixed_of_match[] __devinitconst = {
+   { .compatible = regulator-fixed, },
+   {},
+};
+MODULE_DEVICE_TABLE(of, fixed_of_match);
+#else
+#define fixed_of_match NULL
+#endif
+
 static struct platform_driver regulator_fixed_voltage_driver = {
.probe  = reg_fixed_voltage_probe,
.remove = __devexit_p(reg_fixed_voltage_remove),
.driver = {
.name   = reg-fixed-voltage,
.owner  = THIS_MODULE,
+   .of_match_table = fixed_of_match,
},
 };
 
-- 
1.7.1

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

[PATCH 5/9] regulator: helper routine to extract fixed_voltage_config

The helper routine of_get_fixed_voltage_config() extracts
fixed_voltage_config structure contents from device tree.

Also add documenation for additional bindings for fixed
regulators that can be passed through dt.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 .../bindings/regulator/fixed-regulator.txt |   24 +
 drivers/regulator/fixed.c  |   36 
 include/linux/regulator/fixed.h|6 ++--
 3 files changed, 63 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/fixed-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.txt 
b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
new file mode 100644
index 000..a204cbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.txt
@@ -0,0 +1,24 @@
+Fixed Voltage regulators
+
+Required properties:
+- compatible: Must be regulator-fixed;
+
+Optional properties:
+- regulator-fixed-supply: Name of the regulator supply
+- regulator-fixed-microvolts: Output voltage of regulator
+- regulator-fixed-gpio: gpio to use for enable control
+- regulator-fixed-startup-delay: startup time in microseconds
+- regulator-fixed-enable-high: Polarity of enable GPIO, 1 = Active High, 0 = 
Active low
+- regulator-fixed-enabled-at-boot: 1 = yes, 0 = no
+
+Example:
+
+   abc: fixedregulator@0 {
+   compatible = regulator-fixed;
+   regulator-fixed-supply = fixed-supply;
+   regulator-fixed-microvolts = 180;
+   regulator-fixed-gpio = 43;
+   regulator-fixed-startup-delay = 7;
+   regulator-fixed-enable-high;
+   regulator-fixed-enabled-at-boot;
+   };
diff --git a/drivers/regulator/fixed.c b/drivers/regulator/fixed.c
index 2fe9d99..c09f791 100644
--- a/drivers/regulator/fixed.c
+++ b/drivers/regulator/fixed.c
@@ -26,6 +26,8 @@
 #include linux/gpio.h
 #include linux/delay.h
 #include linux/slab.h
+#include linux/of.h
+#include linux/regulator/of_regulator.h
 
 struct fixed_voltage_data {
struct regulator_desc desc;
@@ -37,6 +39,40 @@ struct fixed_voltage_data {
bool is_enabled;
 };
 
+
+/**
+ * of_get_fixed_voltage_config - extract fixed_voltage_config structure info
+ * @dev: device requesting for fixed_voltage_config
+ *
+ * Populates fixed_voltage_config structure by extracting data from device
+ * tree node, returns a pointer to the populated structure of NULL if memory
+ * alloc fails.
+ */
+struct fixed_voltage_config *of_get_fixed_voltage_config(struct device *dev)
+{
+   struct fixed_voltage_config *config;
+   struct device_node *np = dev-of_node;
+
+   config = devm_kzalloc(dev, sizeof(struct fixed_voltage_config), 
GFP_KERNEL);
+   if (!config)
+   return NULL;
+
+   config-supply_name = (char *)of_get_property(np,
+   regulator-fixed-supply, NULL);
+   of_property_read_u32(np, regulator-fixed-microvolts,
+   config-microvolts);
+   of_property_read_u32(np, regulator-fixed-gpio, config-gpio);
+   of_property_read_u32(np, regulator-fixed-startup-delay,
+   config-startup_delay);
+   if (of_find_property(np, regulator-fixed-enable-high, NULL))
+   config-enable_high = true;
+   if (of_find_property(np, regulator-fixed-enabled-at-boot, NULL))
+   config-enabled_at_boot = true;
+   config-init_data = of_get_regulator_init_data(dev);
+
+   return config;
+}
+
 static int fixed_voltage_is_enabled(struct regulator_dev *dev)
 {
struct fixed_voltage_data *data = rdev_get_drvdata(dev);
diff --git a/include/linux/regulator/fixed.h b/include/linux/regulator/fixed.h
index ffd7d50..bb762cf 100644
--- a/include/linux/regulator/fixed.h
+++ b/include/linux/regulator/fixed.h
@@ -40,9 +40,9 @@ struct regulator_init_data;
  */
 struct fixed_voltage_config {
const char *supply_name;
-   int microvolts;
-   int gpio;
-   unsigned startup_delay;
+   u32 microvolts;
+   u32 gpio;
+   u32 startup_delay;
unsigned enable_high:1;
unsigned enabled_at_boot:1;
struct regulator_init_data *init_data;
-- 
1.7.1

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

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

Device nodes in DT can associate themselves with one or more
regulators by providing a list of phandles (to regulator nodes)
and corresponding supply names.

For Example:
devicenode: node@0x0 {
...
...
vmmc-supply = regulator1;
vpll-supply = regulator1;
};

The driver would then do a regulator_get(dev, vmmc); to get
regulator1 and do a regulator_get(dev, vpll); to get
regulator2.

of_get_regulator() extracts the regulator node for a given
device, based on the supply name.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 drivers/regulator/of_regulator.c   |   39 
 include/linux/regulator/of_regulator.h |7 +
 2 files changed, 46 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 7fa63ff..49dd105 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -14,6 +14,45 @@
 #include linux/of.h
 #include linux/regulator/machine.h
 
+
+/**
+ * of_get_regulator - get a regulator device node based on supply name
+ * @dev: Device pointer for the consumer (of regulator) device
+ * @supply: regulator supply name
+ *
+ * Extract the regulator device node corresponding to the supply name.
+ * retruns the device node corresponding to the regulator if found, else
+ * returns NULL.
+ */
+struct device_node *of_get_regulator(struct device *dev, const char *supply)
+{
+   struct device_node *regnode = NULL;
+   u32 reghandle;
+   char prop_name[32]; /* 32 is max size of property name */
+   const void *prop;
+   int sz;
+
+   if (!dev)
+   return NULL;
+
+   dev_dbg(dev, Looking up %s-supply from device tree\n, supply);
+
+   snprintf(prop_name, 32, %s-supply, supply);
+
+   prop = of_get_property(dev-of_node, prop_name, sz);
+   if (!prop || sz  4)
+   return NULL;
+
+   reghandle = be32_to_cpup(prop);
+   regnode = of_find_node_by_phandle(reghandle);
+   if (!regnode) {
+   pr_warn(%s: %s property in node %s references invalid phandle,
+   __func__, prop_name, dev-of_node-full_name);
+   return NULL;
+   }
+   return regnode;
+}
+
 static void of_get_regulation_constraints(struct device_node *np,
struct regulator_init_data **init_data)
 {
diff --git a/include/linux/regulator/of_regulator.h 
b/include/linux/regulator/of_regulator.h
index 3f63be9..edaba1a 100644
--- a/include/linux/regulator/of_regulator.h
+++ b/include/linux/regulator/of_regulator.h
@@ -9,12 +9,19 @@
 #if defined(CONFIG_OF_REGULATOR)
 extern struct regulator_init_data
*of_get_regulator_init_data(struct device *dev);
+extern struct device_node *of_get_regulator(struct device *dev,
+   const char *supply);
 #else
 static inline struct regulator_init_data
*of_get_regulator_init_data(struct device_node *np)
 {
return NULL;
 }
+static inline struct device_node *of_get_regulator(struct device *dev,
+   const char *id)
+{
+   return NULL;
+}
 #endif /* CONFIG_OF_REGULATOR */
 
 #endif /* __LINUX_OF_REG_H */
-- 
1.7.1

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

[PATCH 7/9] omap4: panda: Pass regulator data from DT

Pass the fixed and adjustable voltage regulator information for
omap4panda board from device tree.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 arch/arm/boot/dts/omap4-panda.dts |   54 +
 1 files changed, 54 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda.dts 
b/arch/arm/boot/dts/omap4-panda.dts
index 2c6ce2b..045dbfc 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -48,6 +48,60 @@
compatible = ti,twl4030-rtc;
interrupts = 11;
};
+
+   vwl1271: fixedregulator@0 {
+   compatible = regulator-fixed;
+   regulator-fixed-supply = vwl1271;
+   regulator-fixed-microvolts = 180;
+   regulator-fixed-gpio = 43;
+   regulator-fixed-startup-delay = 7;
+   regulator-fixed-enable-high;
+   regulator-fixed-enabled-at-boot;
+   };
+
+   vaux2: regulator@0 {
+   compatible = ti,twl6030-vaux2,ti,twl6030;
+   regulator-min-uV = 120;
+   regulator-max-uV = 280;
+   regulator-mode-normal;
+   regulator-mode-standby;
+   regulator-change-mode;
+   regulator-change-status;
+   regulator-change-voltage;
+   };
+
+   vaux3: regulator@1 {
+   compatible = ti,twl6030-vaux3,ti,twl6030;
+   regulator-min-uV = 100;
+   regulator-max-uV = 300;
+   regulator-mode-normal;
+   regulator-mode-standby;
+   regulator-change-mode;
+   regulator-change-status;
+   regulator-change-voltage;
+   };
+
+   vmmc: regulator@2 {
+   compatible = ti,twl6030-vmmc,ti,twl6030;
+   regulator-min-uV = 120;
+   regulator-max-uV = 300;
+   regulator-mode-normal;
+   regulator-mode-standby;
+   regulator-change-mode;
+   regulator-change-status;
+   regulator-change-voltage;
+   };
+
+   vpp: regulator@3 {
+   compatible = ti,twl6030-vpp,ti,twl6030;
+   regulator-min-uV = 180;
+   regulator-max-uV = 250;
+   regulator-mode-normal;
+   regulator-mode-standby;
+   regulator-change-mode;
+   regulator-change-status;
+   regulator-change-voltage;
+   };
};
 };
 
-- 
1.7.1

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

[PATCH 9/9] regulator: map consumer regulator based on device tree

Look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.

Devices can associate with one or more regulators by providing a
list of phandles and supply names.

For Example:
devicenode: node@0x0 {
...
...
vmmc-supply = regulator1;
vpll-supply = regulator2;
};

When a device driver calls a regulator_get, specifying the
supply name, the phandle and eventually the regulator node
is extracted from the device node.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 drivers/regulator/core.c |   14 ++
 include/linux/regulator/driver.h |3 +++
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index d8e6a42..47b851c 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -25,9 +25,11 @@
 #include linux/mutex.h
 #include linux/suspend.h
 #include linux/delay.h
+#include linux/of.h
 #include linux/regulator/consumer.h
 #include linux/regulator/driver.h
 #include linux/regulator/machine.h
+#include linux/regulator/of_regulator.h
 
 #define CREATE_TRACE_POINTS
 #include trace/events/regulator.h
@@ -1155,6 +1157,7 @@ static struct regulator *_regulator_get(struct device 
*dev, const char *id,
struct regulator_map *map;
struct regulator *regulator = ERR_PTR(-ENODEV);
const char *devname = NULL;
+   struct device_node *node;
int ret;
 
if (id == NULL) {
@@ -1167,6 +1170,15 @@ static struct regulator *_regulator_get(struct device 
*dev, const char *id,
 
mutex_lock(regulator_list_mutex);
 
+   if (dev-of_node) {
+   node = of_get_regulator(dev, id);
+   if (!node)
+   goto retry; /* fallback and chk regulator_map_list */
+   list_for_each_entry(rdev, regulator_list, list)
+   if (node == rdev-node)
+   goto found;
+   }
+retry:
list_for_each_entry(map, regulator_map_list, list) {
/* If the mapping has a device set up it must match */
if (map-dev_name 
@@ -2619,6 +2631,8 @@ struct regulator_dev *regulator_register(struct 
regulator_desc *regulator_desc,
rdev-reg_data = driver_data;
rdev-owner = regulator_desc-owner;
rdev-desc = regulator_desc;
+   if (dev  dev-of_node)
+   rdev-node = dev-of_node;
INIT_LIST_HEAD(rdev-consumer_list);
INIT_LIST_HEAD(rdev-list);
BLOCKING_INIT_NOTIFIER_HEAD(rdev-notifier);
diff --git a/include/linux/regulator/driver.h b/include/linux/regulator/driver.h
index 1a80bc7..4aebbf5 100644
--- a/include/linux/regulator/driver.h
+++ b/include/linux/regulator/driver.h
@@ -196,6 +196,9 @@ struct regulator_dev {
struct mutex mutex; /* consumer lock */
struct module *owner;
struct device dev;
+#ifdef CONFIG_OF
+   struct device_node *node;
+#endif
struct regulation_constraints *constraints;
struct regulator *supply;   /* for tree */
 
-- 
1.7.1

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

[PATCH 3/9] omap4: sdp: Pass regulator data from dt

Pass adjustable regulator information for omap4sdp from device tree so the
regulator driver can then use the regulator helper
routine to extract and use them during the driver probe().

Also add documentation for TWL regulator specific bindings.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 .../bindings/regulator/twl-regulator.txt   |   60 ++
 arch/arm/boot/dts/omap4-sdp.dts|   64 
 2 files changed, 124 insertions(+), 0 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/twl-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt 
b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
new file mode 100644
index 000..7b809ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -0,0 +1,60 @@
+TWL family of regulators
+
+Required properties:
+- compatible:
+  - ti,twl4030 for twl4030 regulators
+  - ti,twl6025 for twl6025 regulators
+  - ti,twl6030 for twl6030 regulators
+
+Additionally compatible can be used to specify the
+exact regulator/ldo instance like
+For twl6030 regulators/LDO's
+- compatible:
+  - ti,twl6030-vaux1 for VAUX1 LDO
+  - ti,twl6030-vaux2 for VAUX2 LDO
+  - ti,twl6030-vaux3 for VAUX3 LDO
+  - ti,twl6030-vmmc for VMMC LDO
+  - ti,twl6030-vpp for VPP LDO
+  - ti,twl6030-vusim for VUSIM LDO
+For twl6025 regulators/LDO's
+- compatible:
+  - ti,twl6025-ldo1 for LDO1 LDO
+  - ti,twl6025-ldo2 for LDO2 LDO
+  - ti,twl6025-ldo3 for LDO3 LDO
+  - ti,twl6025-ldo4 for LDO4 LDO
+  - ti,twl6025-ldo5 for LDO5 LDO
+  - ti,twl6025-ldo6 for LDO6 LDO
+  - ti,twl6025-ldo7 for LDO7 LDO
+  - ti,twl6025-ldoln for LDOLN LDO
+  - ti,twl6025-ldousb for LDOUSB LDO
+For twl4030 regulators/LDO's
+- compatible:
+  - ti,twl4030-vaux1 for VAUX1 LDO
+  - ti,twl4030-vaux2 for VAUX2 LDO
+  - ti,twl5030-vaux2 for VAUX2 LDO
+  - ti,twl4030-vaux3 for VAUX3 LDO
+  - ti,twl4030-vaux4 for VAUX4 LDO
+  - ti,twl4030-vmmc1 for VMMC1 LDO
+  - ti,twl4030-vmmc2 for VMMC2 LDO
+  - ti,twl4030-vpll1 for VPLL1 LDO
+  - ti,twl4030-vpll2 for VPLL2 LDO
+  - ti,twl4030-vsim for VSIM LDO
+  - ti,twl4030-vdac for VDAC LDO
+  - ti,twl4030-vintana2 for VINTANA2 LDO
+  - ti,twl4030-vio for VIO LDO
+  - ti,twl4030-vdd1 for VDD1 LDO
+  - ti,twl4030-vdd2 for VDD2 LDO
+
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+
+Example:
+
+   xyz: regulator@0 {
+   compatible = ti,twl6030-vaux1,ti,twl6030;
+   regulator-min_uV  = 100;
+   regulator-max_uV  = 300;
+   regulator-more-normal;
+   regulator-mode-standby;
+   regulator-change-voltage;
+   };
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 2990841..edbf77e 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -48,6 +48,70 @@
compatible = ti,twl4030-rtc;
interrupts = 11;
};
+
+   vaux1: regulator@0 {
+   compatible = ti,twl6030-vaux1,ti,twl6030;
+   regulator-min-uV = 100;
+   regulator-max-uV = 300;
+   regulator-mode-normal;
+   regulator-mode-standby;
+   regulator-change-voltage;
+   regulator-change-mode;
+   };
+
+   vaux2: regulator@1 {
+   compatible = ti,twl6030-vaux2,ti,twl6030;
+   regulator-min-uV = 120;
+   regulator-max-uV = 280;
+   regulator-mode-normal;
+   regulator-mode-standby;
+   regulator-change-mode;
+   regulator-change-status;
+   regulator-change-voltage;
+   };
+
+   vaux3: regulator@2 {
+   compatible = ti,twl6030-vaux3,ti,twl6030;
+   regulator-min-uV = 100;
+   regulator-max-uV = 300;
+   regulator-mode-normal;
+   regulator-mode-standby;
+   regulator-change-mode;
+   regulator-change-status;
+   regulator-change-voltage;
+   };
+
+   vmmc: regulator@3 {
+   compatible = ti,twl6030-vmmc,ti,twl6030;
+   regulator-min-uV = 120;
+   regulator-max-uV = 300;
+   regulator-mode-normal;
+   regulator-mode-standby;
+   regulator-change-mode;
+   regulator-change-status;
+   regulator-change-voltage;
+   };
+
+   vpp: regulator@4 {
+   compatible = ti,twl6030-vpp,ti,twl6030;
+

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

The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure from the data
that is passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
implemented in subsequent patches.

Also add documentation for regulator bindings to be used to pass
regulator_init_data struct information from device tree.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 .../devicetree/bindings/regulator/regulator.txt|   42 +
 drivers/regulator/Kconfig  |7 ++
 drivers/regulator/Makefile |1 +
 drivers/regulator/of_regulator.c   |   88 
 include/linux/regulator/machine.h  |   12 ++--
 include/linux/regulator/of_regulator.h |   21 +
 6 files changed, 165 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/regulator/regulator.txt
 create mode 100644 drivers/regulator/of_regulator.c
 create mode 100644 include/linux/regulator/of_regulator.h

diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt 
b/Documentation/devicetree/bindings/regulator/regulator.txt
new file mode 100644
index 000..91b8d8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -0,0 +1,42 @@
+Voltage/Current Regulators
+
+Optional properties:
+- regulator-supplies: Names of the regulator supplies
+- regulator-min-uV: smallest voltage consumers may set
+- regulator-max-uV: largest voltage consumers may set
+- regulator-uV-offset: Offset applied to voltages to compensate for voltage 
drops
+- regulator-min-uA: smallest current consumers may set
+- regulator-max-uA: largest current consumers may set
+- regulator-change-voltage: boolean, Output voltage can be changed by software
+- regulator-change-current: boolean, Output current can be chnaged by software
+- regulator-change-mode: boolean, Operating mode can be changed by software
+- regulator-change-status: boolean, Enable/Disable control for regulator exists
+- regulator-change-drms: boolean, Dynamic regulator mode switching is enabled
+- regulator-mode-fast: boolean, allow/set fast mode for the regulator
+- regulator-mode-normal: boolean, allow/set normal mode for the regulator
+- regulator-mode-idle: boolean, allow/set idle mode for the regulator
+- regulator-mode-standby: boolean, allow/set standby mode for the regulator
+- regulator-input-uV: Input voltage for regulator when supplied by another 
regulator
+- regulator-always-on: boolean, regulator should never be disabled
+- regulator-boot-on: bootloader/firmware enabled regulator
+
+Example:
+
+   xyzreg: regulator@0 {
+   regulator-min-uV = 100;
+   regulator-max-uV = 250;
+   regulator-mode-fast;
+   regulator-change-voltage;
+   regulator-always-on;
+   };
+
+Example of a device node referencing a regulator node:
+
+   devicenode: node@0x0 {
+   ...
+   ...
+   name-supply = xyzreg;
+   };
+
+   where name is the supply name or regulator id passed
+   as part of regulator_get(dev, name);
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c7fd2c0..2b684aa 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -64,6 +64,13 @@ config REGULATOR_USERSPACE_CONSUMER
 
   If unsure, say no.
 
+config OF_REGULATOR
+   tristate OF regulator helpers
+   depends on OF
+   help
+ OpenFirmware regulator framework helper routines that can
+ used by regulator drivers to extract data from device tree.
+
 config REGULATOR_BQ24022
tristate TI bq24022 Dual Input 1-Cell Li-Ion Charger IC
help
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 040d5aa..e6bc009 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_REGULATOR) += core.o dummy.o
 obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o
 obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o
 obj-$(CONFIG_REGULATOR_USERSPACE_CONSUMER) += userspace-consumer.o
+obj-$(CONFIG_OF_REGULATOR) += of_regulator.o
 
 obj-$(CONFIG_REGULATOR_AD5398) += ad5398.o
 obj-$(CONFIG_REGULATOR_BQ24022) += bq24022.o
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
new file mode 100644
index 000..7fa63ff
--- /dev/null
+++ b/drivers/regulator/of_regulator.c
@@ -0,0 +1,88 @@
+/*
+ * OF helpers for regulator framework
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Rajendra Nayak rna...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+

[PATCH 4/9] regulator: twl: Make twl-regulator driver extract data from DT

Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 drivers/regulator/twl-regulator.c |  117 -
 1 files changed, 76 insertions(+), 41 deletions(-)

diff --git a/drivers/regulator/twl-regulator.c 
b/drivers/regulator/twl-regulator.c
index f696287..ddb5ad1 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -14,8 +14,10 @@
 #include linux/err.h
 #include linux/delay.h
 #include linux/platform_device.h
+#include linux/of.h
 #include linux/regulator/driver.h
 #include linux/regulator/machine.h
+#include linux/regulator/of_regulator.h
 #include linux/i2c/twl.h
 
 
@@ -58,6 +60,9 @@ struct twlreg_info {
 
/* chip specific features */
unsigned long   features;
+#ifdef CONFIG_OF
+   charcompatible[128];
+#endif
 };
 
 
@@ -839,13 +844,14 @@ static struct regulator_ops twlsmps_ops = {
TWL_FIXED_LDO(label, offset, mVolts, 0x0, turnon_delay, \
0x0, TWL6030, twl6030fixed_ops)
 
-#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf) { 
\
+#define TWL4030_ADJUSTABLE_LDO(label, offset, num, turnon_delay, remap_conf, 
comp) { \
.base = offset, \
.id = num, \
.table_len = ARRAY_SIZE(label##_VSEL_table), \
.table = label##_VSEL_table, \
.delay = turnon_delay, \
.remap = remap_conf, \
+   .compatible = comp, \
.desc = { \
.name = #label, \
.id = TWL4030_REG_##label, \
@@ -856,10 +862,11 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
 
-#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) { \
+#define TWL6030_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts, comp) { \
.base = offset, \
.min_mV = min_mVolts, \
.max_mV = max_mVolts, \
+   .compatible = comp, \
.desc = { \
.name = #label, \
.id = TWL6030_REG_##label, \
@@ -870,10 +877,11 @@ static struct regulator_ops twlsmps_ops = {
}, \
}
 
-#define TWL6025_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts) { \
+#define TWL6025_ADJUSTABLE_LDO(label, offset, min_mVolts, max_mVolts, comp) { \
.base = offset, \
.min_mV = min_mVolts, \
.max_mV = max_mVolts, \
+   .compatible = comp, \
.desc = { \
.name = #label, \
.id = TWL6025_REG_##label, \
@@ -932,23 +940,23 @@ static struct regulator_ops twlsmps_ops = {
  * software control over them after boot.
  */
 static struct twlreg_info twl_regs[] = {
-   TWL4030_ADJUSTABLE_LDO(VAUX1, 0x17, 1, 100, 0x08),
-   TWL4030_ADJUSTABLE_LDO(VAUX2_4030, 0x1b, 2, 100, 0x08),
-   TWL4030_ADJUSTABLE_LDO(VAUX2, 0x1b, 2, 100, 0x08),
-   TWL4030_ADJUSTABLE_LDO(VAUX3, 0x1f, 3, 100, 0x08),
-   TWL4030_ADJUSTABLE_LDO(VAUX4, 0x23, 4, 100, 0x08),
-   TWL4030_ADJUSTABLE_LDO(VMMC1, 0x27, 5, 100, 0x08),
-   TWL4030_ADJUSTABLE_LDO(VMMC2, 0x2b, 6, 100, 0x08),
-   TWL4030_ADJUSTABLE_LDO(VPLL1, 0x2f, 7, 100, 0x00),
-   TWL4030_ADJUSTABLE_LDO(VPLL2, 0x33, 8, 100, 0x08),
-   TWL4030_ADJUSTABLE_LDO(VSIM, 0x37, 9, 100, 0x00),
-   TWL4030_ADJUSTABLE_LDO(VDAC, 0x3b, 10, 100, 0x08),
+   TWL4030_ADJUSTABLE_LDO(VAUX1, 0x17, 1, 100, 0x08, ti,twl4030-vaux1),
+   TWL4030_ADJUSTABLE_LDO(VAUX2_4030, 0x1b, 2, 100, 0x08, 
ti,twl4030-vaux2),
+   TWL4030_ADJUSTABLE_LDO(VAUX2, 0x1b, 2, 100, 0x08, ti,twl5030-vaux2),
+   TWL4030_ADJUSTABLE_LDO(VAUX3, 0x1f, 3, 100, 0x08, ti,twl4030-vaux3),
+   TWL4030_ADJUSTABLE_LDO(VAUX4, 0x23, 4, 100, 0x08, ti,twl4030-vaux4),
+   TWL4030_ADJUSTABLE_LDO(VMMC1, 0x27, 5, 100, 0x08, ti,twl4030-vmmc1),
+   TWL4030_ADJUSTABLE_LDO(VMMC2, 0x2b, 6, 100, 0x08, ti,twl4030-vmmc2),
+   TWL4030_ADJUSTABLE_LDO(VPLL1, 0x2f, 7, 100, 0x00, ti,twl4030-vpll1),
+   TWL4030_ADJUSTABLE_LDO(VPLL2, 0x33, 8, 100, 0x08, ti,twl4030-vpll2),
+   TWL4030_ADJUSTABLE_LDO(VSIM, 0x37, 9, 100, 0x00, ti,twl4030-vsim),
+   TWL4030_ADJUSTABLE_LDO(VDAC, 0x3b, 10, 100, 0x08, ti,twl4030-vdac),
TWL4030_FIXED_LDO(VINTANA1, 0x3f, 1500, 11, 100, 0x08),
-   TWL4030_ADJUSTABLE_LDO(VINTANA2, 0x43, 12, 100, 0x08),
+   TWL4030_ADJUSTABLE_LDO(VINTANA2, 0x43, 12, 100, 0x08, 
ti,twl4030-vintana2),
TWL4030_FIXED_LDO(VINTDIG, 0x47, 1500, 13, 100, 0x08),
-   TWL4030_ADJUSTABLE_LDO(VIO, 0x4b, 14, 1000, 0x08),
-   TWL4030_ADJUSTABLE_LDO(VDD1, 0x55, 15, 1000, 0x08),
-   TWL4030_ADJUSTABLE_LDO(VDD2, 0x63, 16, 1000, 0x08),
+   TWL4030_ADJUSTABLE_LDO(VIO, 0x4b, 14, 1000, 0x08, ti,twl4030-vio),
+   TWL4030_ADJUSTABLE_LDO(VDD1, 0x55, 15, 1000, 0x08, ti,twl4030-vdd1),
+   TWL4030_ADJUSTABLE_LDO(VDD2, 0x63, 16, 1000, 0x08,

Re: [PATCH 1/9] regulator: twl: Remove hardcoded board constraints from driver

On Tue, Sep 27, 2011 at 03:42:44PM +0530, Rajendra Nayak wrote:
 Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
 each regulator from the twl driver and let the boards pass it.
 
 Signed-off-by: Rajendra Nayak rna...@ti.com


 - /* Constrain board-specific capabilities according to what
 -  * this driver and the chip itself can actually do.
 -  */
 - c = initdata-constraints;
 - c-valid_modes_mask = REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
 - c-valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
 - | REGULATOR_CHANGE_MODE
 - | REGULATOR_CHANGE_STATUS;

This isn't actually hard coding constraints, this is restricting the
constraints passed in further rather than adding new ones.

However should be fine:

Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 5/5] iommu/omap: eliminate the public omap_find_iommu_device() method

2011-09-27 Thread Laurent Pinchart

Hi Ohad,

Thanks for the patch.

On Sunday 25 September 2011 12:58:57 Ohad Ben-Cohen wrote:
 Eliminate the public omap_find_iommu_device() method, and don't
 expect clients to provide the omap_iommu handle anymore.
 
 Instead, OMAP's iommu driver should now utilize dev_archdata's private
 iommu extension to be able to access the required iommu information.
 
 Update omap3isp appropriately.
 
 Signed-off-by: Ohad Ben-Cohen o...@wizery.com
 Cc: Hiroshi DOYU hiroshi.d...@nokia.com
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Cc: Tony Lindgren t...@atomide.com

For the OMAP3 ISP driver,

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

-- 
Regards,

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

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

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

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

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

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

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

   /* voltage output range (inclusive) - for voltage control */
 - int min_uV;
 - int max_uV;
 + u32 min_uV;
 + u32 max_uV;
  
 - int uV_offset;
 + u32 uV_offset;
  
   /* current output range (inclusive) - for current control */
 - int min_uA;
 - int max_uA;
 + u32 min_uA;
 + u32 max_uA;

Hrm, I think loosing the signs here is bad karma - negative voltages do
exist after all.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/9] regulator: twl: Make twl-regulator driver extract data from DT

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

 +#ifdef CONFIG_OF
 + charcompatible[128];
 +#endif

Might it not be better to just make this a pointer to const char?
--
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 5/9] regulator: helper routine to extract fixed_voltage_config

On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
 The helper routine of_get_fixed_voltage_config() extracts
 fixed_voltage_config structure contents from device tree.
 
 Also add documenation for additional bindings for fixed
 regulators that can be passed through dt.

Why not just add device tree support into the driver directly?

 +Optional properties:
 +- regulator-fixed-supply: Name of the regulator supply

This is going to be confusing with respect to the generic regulator
supply property.

 +- regulator-fixed-enable-high: Polarity of enable GPIO, 1 = Active High, 0 = 
 Active low

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

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

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

 + if (!dev)
 + return NULL;

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

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

sz  4?  Magic!  :)

 +extern struct device_node *of_get_regulator(struct device *dev,
 + const char *supply);

This shouldn't be part of the public API, it should be transparently
handled within the core.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] ispccdc: Configure CCDC_SYN_MODE register for UYVY8_2X8 and YUYV8_2X8 formats

2011-09-27 Thread Laurent Pinchart

Hi Sakari,

On Sunday 25 September 2011 13:17:17 Sakari Ailus wrote:
 On Wed, Sep 21, 2011 at 11:06:41AM +0200, Laurent Pinchart wrote:
  On Wednesday 21 September 2011 07:32:44 Ravi, Deepthy wrote:
   On Wednesday, September 21, 2011 4:56 AM Laurent Pinchart wrote:
On Tuesday 20 September 2011 16:56:51 Deepthy Ravi wrote:
Configure INPMOD and PACK8 fileds of CCDC_SYN_MODE
register for UYVY8_2X8 and YUYV8_2X8 formats.

Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---

 drivers/media/video/omap3isp/ispccdc.c |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c index 418ba65..1dcf180
100644 --- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -985,8 +985,12 @@ static void ccdc_config_sync_if(struct
isp_ccdc_device
*ccdc,

  syn_mode = ~ISPCCDC_SYN_MODE_INPMOD_MASK;
  if (format-code == V4L2_MBUS_FMT_YUYV8_2X8 ||

- format-code == V4L2_MBUS_FMT_UYVY8_2X8)
- syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
+ format-code == V4L2_MBUS_FMT_UYVY8_2X8){
+ if (pdata  pdata-bt656)
+ syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
+ else
+ syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
+ }

  else if (format-code == V4L2_MBUS_FMT_YUYV8_1X16 ||
  
   format-code == V4L2_MBUS_FMT_UYVY8_1X16)
  
  syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;

@@ -1172,7 +1176,8 @@ static void ccdc_configure(struct
isp_ccdc_device *ccdc) syn_mode = ~ISPCCDC_SYN_MODE_SDR2RSZ;

  /* Use PACK8 mode for 1byte per pixel formats. */

- if (omap3isp_video_format_info(format-code)-width = 8)
+ if ((omap3isp_video_format_info(format-code)-width = 8) 
+ (omap3isp_video_format_info(format-code)-bpp
= 8))

I'm not sure to follow you. This will clear the PACK8 bit for the
YUYV8_2X8 formats. Those formats are 8 bits wide, shouldn't PACK8 be
set to store samples on 8 bits instead of 16 bits ?

Is this patch intended to support YUYV8_2X8 sensors in non BT.656
mode with the bridge enabled ? In that case, what would you think
about setting the CCDC input format to YUYV8_1X16 instead ? This
would better reflect the reality, as the bridge converts YUYV8_2X8
to YUYV8_1X16, and the CCDC is then fed with YUYV8_1X16.
   
   Yes this is intended for  YUYV8_2X8 sensors in non BT.656 with 8 to 16
   bit bridge enabled. So the data has to be stored as 16 bits per
   sample. Thats why PACK8 is cleared . I am not sure about using
   YUYV8_1X16.
  
  My original idea when I wrote the YV support patches was to implement
  this use case with YUYV8_2X8 at the sensor output and YUYV8_1X16 at the
  CCDC input. The ISP driver could then enable the bridge automatically.
  I'm not sure if that's the best solution though, it might be confusing
  for the users. What I would like to keep, however, is the idea of
  enabling the bridge automatically.
  
  Sakari, any opinion on this ?
 
 Are there any complications from the CCDC also listing the 2X8 formats as
 supported in its sink pad?

No, and the 2X8 formats need to be supported at the CCDC input, as BT.656 mode 
is not compatible with the bridge.

 I'd rather support them since doing it the other way might be somewhat
 confusing to the users.

It can be confusing indeed, but it reflects reality :-) It's also how we 
currently handle the lane shifter.

If we incorporate the bridge inside the CCDC, only YUV 2X8 formats will be 
supported at the CCDC input. Whether to enable the bridge will then be a 
platform decision and hardcoded in board code instead of being configurable by 
the user. Couldn't that be an issue ?

 This would also mean media-ctl users would have to set both sink and source
 formats rather than just the source format when configuring the format for
 the link.
 
  syn_mode |= ISPCCDC_SYN_MODE_PACK8;
  
  else
  
  syn_mode = ~ISPCCDC_SYN_MODE_PACK8;

-- 
Regards,

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

Re: [PATCH 9/9] regulator: map consumer regulator based on device tree

On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
 Look up the regulator for a given consumer from device tree, during
 a regulator_get(). If not found fallback and lookup through
 the regulator_map_list instead.

As with the fixed voltage regulator patch just use the code along with
adding it, no need to split it just makes it harder to review.

 + if (dev-of_node) {
 + node = of_get_regulator(dev, id);
 + if (!node)
 + goto retry; /* fallback and chk regulator_map_list */
 + list_for_each_entry(rdev, regulator_list, list)
 + if (node == rdev-node)
 + goto found;
 + }
 +retry:

retry is a confusing name for the target, we don't ever actually retry
using it.  Given the simplicity of the code I'd be inclined to just
intert the if (!node) check.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware

On Tue, Sep 27, 2011 at 1:05 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
 On Fri, Sep 16, 2011 at 01:51:41PM -0400, Ohad Ben-Cohen wrote:
  int iommu_map(struct iommu_domain *domain, unsigned long iova,
 -             phys_addr_t paddr, int gfp_order, int prot)
 +             phys_addr_t paddr, size_t size, int prot)
  {
 -       size_t size;
 +       int ret = 0;
 +
 +       /*
 +        * both the virtual address and the physical one, as well as
 +        * the size of the mapping, must be aligned (at least) to the
 +        * size of the smallest page supported by the hardware
 +        */
 +       if (!IS_ALIGNED(iova | paddr | size, iommu_min_pagesz)) {
 +               pr_err(unaligned: iova 0x%lx pa 0x%lx size 0x%lx min_pagesz 
 
 +                       0x%x\n, iova, (unsigned long)paddr,
 +                       (unsigned long)size, iommu_min_pagesz);
 +               return -EINVAL;
 +       }
 +
 +       pr_debug(map: iova 0x%lx pa 0x%lx size 0x%lx\n, iova,
 +                               (unsigned long)paddr, (unsigned long)size);
 +
 +       while (size) {
 +               unsigned long pgsize = iommu_min_pagesz;
 +               unsigned long idx = iommu_min_page_idx;
 +               unsigned long addr_merge = iova | paddr;
 +               int order;
 +
 +               /* find the max page size with which iova, paddr are aligned 
 */
 +               for (;;) {
 +                       unsigned long try_pgsize;
 +
 +                       idx = find_next_bit(iommu_pgsize_bitmap,
 +                                               iommu_nr_page_bits, idx + 1);
 +
 +                       /* no more pages to check ? */
 +                       if (idx = iommu_nr_page_bits)
 +                               break;
 +
 +                       try_pgsize = 1  idx;

 -       size         = 0x1000UL  gfp_order;
 +                       /* page too big ? addresses not aligned ? */
 +                       if (size  try_pgsize ||
 +                                       !IS_ALIGNED(addr_merge, try_pgsize))
 +                               break;

 -       BUG_ON(!IS_ALIGNED(iova | paddr, size));
 +                       pgsize = try_pgsize;
 +               }

 With an unsigned long you can use plain and fast bit_ops instead of the
 full bitmap functions.

Not sure I follow; the only bit operation I'm using while mapping is
find_next_bit() (which is a bitops.h method).

What other faster variant are you referring to ?

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

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

2011-09-27 Thread Tero Kristo

On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote:

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

-Original Message-

 From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
 Sent: Monday, September 26, 2011 7:49 PM
 To: Paul Walmsley; Tero Kristo; b-cous...@ti.com; ba...@ti.com;
 part...@india.ti.com
 Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
 ker...@vger.kernel.org; gadi...@ti.com; sa...@linux.intel.com;
 t...@atomide.com; khil...@ti.com; johns...@us.ibm.com;
 vishwanath...@ti.com
 Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod
 structures for omap3

 On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com wrote:
  On Fri, 23 Sep 2011, Munegowda, Keshava wrote:

  On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com
 wrote:

  But the question arises here , why do we need these ehci and ohci as
 two
  different hwmods containing only irq and base address? It is required
  for future - to implement remote wakeup feature for ehci and ohci
 ports
  depending on irq-chain handler patches by Tero. Separate hwmods for
 ehci
  and ohci are needed to enable prcm chain-handler to uniquely identify
  the wakeup source as ehci or ohci and call only the corresponding
  interrupt handler. We will be using omap_hwmod_mux_init for ehci and
  ohci hwmods to enable I/O wakeup capability for respective IO-pads.
  Depending on the particular wakeup source(ehci/ohci), the
 corresponding
  ehci or ohci irq handler will be called.

  If ehci and ohci are combined with usbhs hwmod as a single hwmod ,
 then
  for every wakeup (either ehci or ohci port wakeup) only the first
  interrupt handler will be called (please look at the function
  omap_hwmod_mux_handle_irq of

  /arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
  http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
  , so in this
  case, if ehci interrupt is the first interrupt , then even for ohci
 wakeup
  , only ehci interrupt will get called; which will break the
 functionality.

  Any reason why this couldn't be handled either by:

  1. adding an IRQ number field to struct omap_hwmod_mux_info, and
 changing
  _omap_hwmod_mux_handle_irq() to raise that IRQ number?

 yes, it is possible by changing the existing irq-chain handler by tero
 Kristo

 I am looping tero too.

 So here are new requirements for the irq-chain handler

 1. The hwmod should have have option to have multiple mux structures

 This is something like:

 The existing mux structure definition in omap_hwmod [file:
 /arch/arm/plat-omap/include/plat/omap_hwmod.h ] structure

  struct omap_hwmod_mux_info  *mux;

 it should changed to

  struct omap_hwmod_mux_info  **pmux;
  U32mux_cnt;

 pmux - pointers to mux ; array of mux structures.
 mux_cnt - number of mux per hwmod.

 2. The mux  omap_hwmod_mux_info  structure should have new member
 called irq, like as follows:

 struct omap_hwmod_mux_info {
  int nr_pads;
  ...

 u32   irq;

 };

 Upon wakeup of the I/O pad of the mux , the irq-chain handler should
 invoke the irq handler of the irq numbered map_hwmod_mux_info.irq

 3.  There should be SOME WAY to supply the irqs  from hwmod
 structure (omap_hwmod) to mux structure (omap_hwmod_mux_info)

 if you , tero and other opensource people are aligned on the proposed
 changes on the irq-handler ;
 then it is possible to have two hwmods ( usbhs and tll) for usbhost
 driver.
 please let me know you comments on the above approach.

 Hello Tero,

 I would like to draw your attention to the following thread:

 We need to support the following:
 1. Ability to associate multiple mux info to a hwmod.
 2. Able to associate a particular irq handler to a mux info.
 3. PRCM Chain handler should loop through all mux-info arrays
for a particular hwmod to identify the possible wakeup source(s)
and call the appropriate irq handler for that mux-info.
(It is possible that both mux-info are woken up in which case both
 handlers should be called).

 To give you a little more perspective, EHCI  OHCI are co-controllers
 under UHH/TLL.
 They do not get presented separately to the OCP bus, hence do not qualify
 as separate hwmods
 (Paul had objected to the design approach representing EHCI  OHCI as
 different hwmods).

 However, we need a mechanism to efficiently identify/distinguish
 remote-wakeup, connect/disconnect
 On to an EHCI port vs an OHCI port  call only the correct interrupt
 handler(EHCI or OHCI).

  To incorporate this, chain handler implementation would need some
 enhancements.
  We can look into the details in the next merge window cycle in
 conjunction with aggressive clock management support for EHCI/OHCI.
  But fundamentally, if you are aligned to the approach, we can

Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware

2011-09-27 Thread Roedel, Joerg

On Tue, Sep 27, 2011 at 08:26:29AM -0400, Ohad Ben-Cohen wrote:
  With an unsigned long you can use plain and fast bit_ops instead of the
  full bitmap functions.
 
 Not sure I follow; the only bit operation I'm using while mapping is
 find_next_bit() (which is a bitops.h method).
 
 What other faster variant are you referring to ?

You pass a pointer to an unsigned long for the page-size bitmap. This
allows to use an array of unsigned long. But a single unsigned long is
sufficient and you can use functions like ffs() and fls() together with
shifting. These functions often translate to a single intruction in the
binary. The find_next_bit function has much more overhead because it
needs to handle the array-of-ulong case.

Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

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

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

2011-09-27 Thread Munegowda, Keshava

On Tue, Sep 27, 2011 at 6:12 PM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2011-09-27 at 08:04 +0200, Basak, Partha wrote:

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

-Original Message-

From: Munegowda, Keshava [mailto:keshava_mgo...@ti.com]
Sent: Monday, September 26, 2011 7:49 PM
To: Paul Walmsley; Tero Kristo; b-cous...@ti.com; ba...@ti.com;
part...@india.ti.com
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org; gadi...@ti.com; sa...@linux.intel.com;
t...@atomide.com; khil...@ti.com; johns...@us.ibm.com;
vishwanath...@ti.com
Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod
structures for omap3

On Sat, Sep 24, 2011 at 12:00 PM, Paul Walmsley p...@pwsan.com wrote:
On Fri, 23 Sep 2011, Munegowda, Keshava wrote:

On Thu, Sep 22, 2011 at 11:31 PM, Paul Walmsley p...@pwsan.com
wrote:

But the question arises here , why do we need these ehci and ohci as
two
different hwmods containing only irq and base address? It is required
for future - to implement remote wakeup feature for ehci and ohci
ports
depending on irq-chain handler patches by Tero. Separate hwmods for
ehci
and ohci are needed to enable prcm chain-handler to uniquely identify
the wakeup source as ehci or ohci and call only the corresponding
interrupt handler. We will be using omap_hwmod_mux_init for ehci and
ohci hwmods to enable I/O wakeup capability for respective IO-pads.
Depending on the particular wakeup source(ehci/ohci), the
corresponding
ehci or ohci irq handler will be called.

If ehci and ohci are combined with usbhs hwmod as a single hwmod ,
then
for every wakeup (either ehci or ohci port wakeup) only the first
interrupt handler will be called (please look at the function
omap_hwmod_mux_handle_irq of

/arch/arm/mach-omap2/mux.c file ; in tero's latest patch:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53139.html)
, so in this
case, if ehci interrupt is the first interrupt , then even for ohci
wakeup
, only ehci interrupt will get called; which will break the
functionality.

Any reason why this couldn't be handled either by:

1. adding an IRQ number field to struct omap_hwmod_mux_info, and
changing
_omap_hwmod_mux_handle_irq() to raise that IRQ number?

yes, it is possible by changing the existing irq-chain handler by tero
Kristo

I am looping tero too.

So here are new requirements for the irq-chain handler

1. The hwmod should have have option to have multiple mux structures

This is something like:

The existing mux structure definition in omap_hwmod [file:
/arch/arm/plat-omap/include/plat/omap_hwmod.h ] structure

struct omap_hwmod_mux_info *mux;

it should changed to

struct omap_hwmod_mux_info **pmux;
U32 mux_cnt;

pmux - pointers to mux ; array of mux structures.
mux_cnt - number of mux per hwmod.

2. The mux omap_hwmod_mux_info structure should have new member
called irq, like as follows:

struct omap_hwmod_mux_info {
int nr_pads;
...
u32 irq;

};

Upon wakeup of the I/O pad of the mux , the irq-chain handler should
invoke the irq handler of the irq numbered map_hwmod_mux_info.irq

3. There should be SOME WAY to supply the irqs from hwmod
structure (omap_hwmod) to mux structure (omap_hwmod_mux_info)

if you , tero and other opensource people are aligned on the proposed
changes on the irq-handler ;
then it is possible to have two hwmods ( usbhs and tll) for usbhost
driver.
please let me know you comments on the above approach.

Hello Tero,

I would like to draw your attention to the following thread:

We need to support the following:
1. Ability to associate multiple mux info to a hwmod.
2. Able to associate a particular irq handler to a mux info.
3. PRCM Chain handler should loop through all mux-info arrays
for a particular hwmod to identify the possible wakeup source(s)
and call the appropriate irq handler for that mux-info.
(It is possible that both mux-info are woken up in which case both
handlers should be called).

To give you a little more perspective, EHCI OHCI are co-controllers
under UHH/TLL.
They do not get presented separately to the OCP bus, hence do not qualify
as separate hwmods
(Paul had objected to the design approach representing EHCI OHCI as
different hwmods).

However, we need a mechanism to efficiently identify/distinguish
remote-wakeup, connect/disconnect
On to an EHCI port vs an OHCI port call only the correct interrupt
handler(EHCI or OHCI).

To incorporate this, chain handler implementation would need some
enhancements.
We can look into the details in the next merge window cycle in
conjunction with aggressive clock management support for

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

2011-09-27 Thread Felipe Balbi

Hi,

On Tue, Sep 27, 2011 at 06:48:35PM +0530, Munegowda, Keshava wrote:
  So, you would need a mechanism to do something like this:
 
  pad a or b wakeup detected - irq0
  pad c or d wakeup detected - irq1?
 
 yes, if get something like this , its perfect.

can't you have different IRQs for each pad ? I mean, allocate one
irq_desc for each pad and let drivers request a pad/pin as an IRQ
source. Then, when you detect a pad wakeup, you can:

unsignedpad_irq = pad_number - pad-irq_base;

handle_nested_thread(pad_irq);

this will make use of threaded IRQ handlers even. Could it be something
like that ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware

On Tue, Sep 27, 2011 at 4:12 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
 You pass a pointer to an unsigned long for the page-size bitmap. This
 allows to use an array of unsigned long. But a single unsigned long is
 sufficient

This is fine; I can change that if you like it better (though without
doing the change below this is probably moot).

 and you can use functions like ffs() and fls() together with
 shifting. These functions often translate to a single intruction in the
 binary. The find_next_bit function has much more overhead because it
 needs to handle the array-of-ulong case.

So you're suggesting to re-implement find_next_bit() using ffs()/fls()
and shifting ?

What's the point ?

Sure, if we'll have a proven performance issue while using
find_next_bit() we can think of doing this, but at this stage, this
sounds to me like a premature optimization which isn't too elegant.

At this point I strongly prefer readable, maintainable and easier to
debug code over optimization which isn't proven to be necessary.

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

[PATCH v2 0/5] OMAP3EVM: Add support for MT9T111 sensor

This patchset
-adds support for MT9T111 sensor on omap3evm.
Currently the sensor driver supports only
VGA resolution.
-enables MT9T111 sensor in omap2plus_defconfig.

This is dependent on the following patchset
http://www.spinics.net/lists/linux-media/msg37270.html 
which adds YUYV input support for OMAP3ISP. And is 
applied on top of rc1-for-3.2 of gliakhovetski/v4l-dvb.git
---
Changes in v2:
As per the discussion here,
https://lkml.org/lkml/2011/9/20/280
the existing mt9t112 driver is reused for
adding support for mt9t111 sensor.
Deepthy Ravi (3):
  [media] v4l: Add support for mt9t111 sensor driver
  ispccdc: Configure CCDC_SYN_MODE register
  omap2plus_defconfig: Enable omap3isp and MT9T111 sensor drivers

Vaibhav Hiremath (2):
  omap3evm: Enable regulators for camera interface
  omap3evm: Add Camera board init/hookup file

 arch/arm/configs/omap2plus_defconfig|9 +
 arch/arm/mach-omap2/Makefile|5 +
 arch/arm/mach-omap2/board-omap3evm-camera.c |  185 
 arch/arm/mach-omap2/board-omap3evm.c|   26 +
 drivers/media/video/Kconfig |7 +
 drivers/media/video/Makefile|1 +
 drivers/media/video/mt9t111_reg.h   | 1367 +++
 drivers/media/video/mt9t112.c   |  320 ++-
 drivers/media/video/omap3isp/ispccdc.c  |   11 +-
 include/media/mt9t111.h |   45 +
 10 files changed, 1937 insertions(+), 39 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
 create mode 100644 drivers/media/video/mt9t111_reg.h
 create mode 100644 include/media/mt9t111.h

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

[PATCH v2 5/5] omap2plus_defconfig: Enable omap3isp and MT9T111 sensor drivers

Enables multimedia driver, media controller api,
v4l2-subdev-api, omap3isp and mt9t111 sensor
drivers in omap2plus_defconfig. Also enables
soc-camera and mt9t112 support since mt9t111
sensor is using mt9t112 driver which is based
on soc-camera subsystem.
Loading soc_camera.ko fails. Hence built into
the kernel.

Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
 arch/arm/configs/omap2plus_defconfig |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/arch/arm/configs/omap2plus_defconfig 
b/arch/arm/configs/omap2plus_defconfig
index d5f00d7..48032b6 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -133,6 +133,15 @@ CONFIG_TWL4030_WATCHDOG=y
 CONFIG_REGULATOR_TWL4030=y
 CONFIG_REGULATOR_TPS65023=y
 CONFIG_REGULATOR_TPS6507X=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_CONTROLLER=y
+CONFIG_VIDEO_DEV=y
+CONFIG_VIDEO_V4L2_SUBDEV_API=y
+CONFIG_VIDEO_MEDIA=y
+CONFIG_VIDEO_MT9T111=m
+CONFIG_VIDEO_OMAP3=m
+CONFIG_SOC_CAMERA=y
+CONFIG_SOC_CAMERA_MT9T112=m
 CONFIG_FB=y
 CONFIG_FIRMWARE_EDID=y
 CONFIG_FB_MODE_HELPERS=y
-- 
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 v2 3/5] omap3evm: Add Camera board init/hookup file

From: Vaibhav Hiremath hvaib...@ti.com

Adds board support for MT9T111 sensor.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
 arch/arm/mach-omap2/Makefile|5 +
 arch/arm/mach-omap2/board-omap3evm-camera.c |  185 +++
 arch/arm/mach-omap2/board-omap3evm.c|4 +
 3 files changed, 194 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index f343365..a19753c 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -280,3 +280,8 @@ disp-$(CONFIG_OMAP2_DSS):= display.o
 obj-y  += $(disp-m) $(disp-y)
 
 obj-y  += common-board-devices.o twl-common.o
+
+ifeq ($(CONFIG_MACH_OMAP3EVM),y)
+evm-camera-$(CONFIG_VIDEO_OMAP3)   := board-omap3evm-camera.o
+obj-y  += $(evm-camera-m) $(evm-camera-y)
+endif
diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c 
b/arch/arm/mach-omap2/board-omap3evm-camera.c
new file mode 100644
index 000..e762f61
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
@@ -0,0 +1,185 @@
+/*
+ * arch/arm/mach-omap2/board-omap3evm-camera.c
+ *
+ * OMAP3EVM: Driver for Leopard Module Board
+ *
+ * Copyright (C) 2011 Texas Instruments Inc
+ * Author: Vaibhav Hiremath hvaib...@ti.com
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/io.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/err.h
+#include linux/platform_device.h
+#include mach/gpio.h
+#include media/mt9t111.h
+#include media/omap3isp.h
+#include ../drivers/media/video/omap3isp/isp.h
+#include devices.h
+
+#define CAM_USE_XCLKA  0
+
+#define T2_GPIO_2  194
+#define nCAM_VD_SEL157
+#define nCAM_VD_EN 200
+
+/* mux id to enable/disable signal routing to different peripherals */
+enum omap3evm_cam_mux {
+   MUX_EN_TVP5146 = 0,
+   MUX_EN_CAMERA_SENSOR,
+   MUX_EN_EXP_CAMERA_SENSOR,
+   MUX_INVALID,
+};
+
+/**
+ * @brief omap3evm_set_mux - Sets mux to enable/disable signal routing to
+ * different peripherals present on new EVM board
+ *
+ * @param mux_id - enum, mux id to enable/disable
+ * @param value - enum, ENABLE_MUX for enabling and DISABLE_MUX for disabling
+ *
+ */
+static void omap3evm_set_mux(enum omap3evm_cam_mux mux_id)
+{
+   switch (mux_id) {
+   /*
+   * JP1 jumper need to configure to choose between on-board
+   * camera sensor conn and on-board LI-3MC02 camera sensor.
+   */
+   case MUX_EN_CAMERA_SENSOR:
+   /* Set nCAM_VD_EN (T2_GPIO8) = 0 */
+   gpio_set_value_cansleep(nCAM_VD_EN, 0);
+   /* Set nCAM_VD_SEL (GPIO157) = 0 */
+   gpio_set_value(nCAM_VD_SEL, 0);
+   break;
+   case MUX_EN_EXP_CAMERA_SENSOR:
+   /* Set nCAM_VD_EN (T2_GPIO8) = 1 */
+   gpio_set_value_cansleep(nCAM_VD_EN, 1);
+   break;
+   case MUX_EN_TVP5146:
+   default:
+   /* Set nCAM_VD_EN (T2_GPIO8) = 0 */
+   gpio_set_value_cansleep(nCAM_VD_EN, 0);
+   /* Set nCAM_VD_SEL (GPIO157) = 1 */
+   gpio_set_value(nCAM_VD_SEL, 1);
+   break;
+   }
+}
+
+/* MT9T111: 3M sensor */
+static int omap3evm_mt9t111_s_power(struct v4l2_subdev *subdev, u32 on)
+{
+   struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+
+   omap3evm_set_mux(MUX_EN_CAMERA_SENSOR);
+
+   if (on) {
+   /* Enable EXTCLK */
+   if (isp-platform_cb.set_xclk)
+   isp-platform_cb.set_xclk(isp, 2400, CAM_USE_XCLKA);
+   udelay(5);
+   } else {
+   if (isp-platform_cb.set_xclk)
+   isp-platform_cb.set_xclk(isp, 0, CAM_USE_XCLKA);
+   }
+
+   return 0;
+}
+
+static struct mt9t111_platform_data omap3evm_mt9t111_platform_data = {
+   .s_power= omap3evm_mt9t111_s_power,
+};
+
+
+#define MT9T111_I2C_BUS_NUM2
+
+static struct i2c_board_info omap3evm_camera_i2c_devices[] = {
+   {
+

[PATCH v2 4/5] ispccdc: Configure CCDC_SYN_MODE register

Configure INPMOD and PACK8 fileds for UYVY8_2X8
and YUYV8_2X8 formats.

Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
 drivers/media/video/omap3isp/ispccdc.c |   11 ---
 1 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/omap3isp/ispccdc.c 
b/drivers/media/video/omap3isp/ispccdc.c
index 3bc9b7d..7791acb 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -985,8 +985,12 @@ static void ccdc_config_sync_if(struct isp_ccdc_device 
*ccdc,
 
syn_mode = ~ISPCCDC_SYN_MODE_INPMOD_MASK;
if (format-code == V4L2_MBUS_FMT_YUYV8_2X8 ||
-   format-code == V4L2_MBUS_FMT_UYVY8_2X8)
-   syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
+   format-code == V4L2_MBUS_FMT_UYVY8_2X8){
+   if (pdata  pdata-bt656)
+   syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
+   else
+   syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
+   }
else if (format-code == V4L2_MBUS_FMT_YUYV8_1X16 ||
 format-code == V4L2_MBUS_FMT_UYVY8_1X16)
syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
@@ -1172,7 +1176,8 @@ static void ccdc_configure(struct isp_ccdc_device *ccdc)
syn_mode = ~ISPCCDC_SYN_MODE_SDR2RSZ;
 
/* Use PACK8 mode for 1byte per pixel formats. */
-   if (omap3isp_video_format_info(format-code)-width = 8)
+   if ((omap3isp_video_format_info(format-code)-width = 8) 
+   (omap3isp_video_format_info(format-code)-bpp = 8))
syn_mode |= ISPCCDC_SYN_MODE_PACK8;
else
syn_mode = ~ISPCCDC_SYN_MODE_PACK8;
-- 
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 v2 2/5] [media] v4l: Add support for mt9t111 sensor driver

Added support for mt9t111 sensor in the existing
mt9t112 driver. Also added support for media controller
framework. The sensor driver currently supports only
VGA resolution.

Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
 drivers/media/video/Kconfig   |7 +
 drivers/media/video/Makefile  |1 +
 drivers/media/video/mt9t111_reg.h | 1367 +
 drivers/media/video/mt9t112.c |  320 -
 include/media/mt9t111.h   |   45 ++
 5 files changed, 1704 insertions(+), 36 deletions(-)
 create mode 100644 drivers/media/video/mt9t111_reg.h
 create mode 100644 include/media/mt9t111.h

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 14326d7..b5806e8 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -482,6 +482,13 @@ config VIDEO_MT9V032
  This is a Video4Linux2 sensor-level driver for the Micron
  MT9V032 752x480 CMOS sensor.
 
+config VIDEO_MT9T111
+   tristate Aptina MT9T111 VGA CMOS IMAGE SENSOR
+   depends on VIDEO_V4L2  I2C  VIDEO_V4L2_SUBDEV_API
+   ---help---
+This is a Video4Linux2 sensor-level driver for the Aptina MT9T111
+image sensor.
+
 config VIDEO_TCM825X
tristate TCM825x camera sensor support
depends on I2C  VIDEO_V4L2
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index c06f515..02a8b70 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
 obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o
 obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o
 obj-$(CONFIG_VIDEO_SR030PC30)  += sr030pc30.o
+obj-$(CONFIG_VIDEO_MT9T111) += mt9t112.o
 obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o
 obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/
 obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o
diff --git a/drivers/media/video/mt9t111_reg.h 
b/drivers/media/video/mt9t111_reg.h
new file mode 100644
index 000..2f610d4
--- /dev/null
+++ b/drivers/media/video/mt9t111_reg.h
@@ -0,0 +1,1367 @@
+/*
+ * drivers/media/video/mt9t111_reg.h
+ *
+ * mt9t111 sensor driver header file
+ *
+ * Copyright (C) 2009 Leopard Imaging
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifndef MT9T111_REG_H
+#define MT9T111_REG_H
+
+/* register addr */
+#define MT9T111_CHIP_ID(0x)
+
+/* register value */
+#define MT9T111_CHIP_ID_VALUE  (0x2680)
+
+#define MT9T111_IMAGE_WIDTH(640)
+#define MT9T111_IMAGE_HEIGHT   (480)
+
+typedef struct {
+   u16 delay_time;
+   u16 addr;
+   u16 data;
+} mt9t111_regs;
+
+mt9t111_regs patch_rev6[] = {
+   {0, 0x0982, 0x0},
+   {0, 0x098A, 0xCE7},
+   {0, 0x0990, 0x3C3C},
+   {0, 0x0992, 0x3C3C},
+   {0, 0x0994, 0x3C5F},
+   {0, 0x0996, 0x4F30},
+   {0, 0x0998, 0xED08},
+   {0, 0x099a, 0xBD61},
+   {0, 0x099c, 0xD5CE},
+   {0, 0x099e, 0x4CD},
+   {0, 0x098A, 0xCF7},
+   {0, 0x0990, 0x1F17},
+   {0, 0x0992, 0x211},
+   {0, 0x0994, 0xCC33},
+   {0, 0x0996, 0x2E30},
+   {0, 0x0998, 0xED02},
+   {0, 0x099a, 0xCCFF},
+   {0, 0x099c, 0xFDED},
+   {0, 0x099e, 0xCC},
+   {0, 0x098A, 0xD07},
+   {0, 0x0990, 0x2},
+   {0, 0x0992, 0xBD70},
+   {0, 0x0994, 0x6D18},
+   {0, 0x0996, 0xDE1F},
+   {0, 0x0998, 0x181F},
+   {0, 0x099a, 0x8E01},
+   {0, 0x099c, 0x10CC},
+   {0, 0x099e, 0x3C52},
+   {0, 0x098A, 0xD17},
+   {0, 0x0990, 0x30ED},
+   {0, 0x0992, 0x18},
+   {0, 0x0994, 0xECA0},
+   {0, 0x0996, 0xC4FD},
+   {0, 0x0998, 0xBD70},
+   {0, 0x099a, 0x2120},
+   {0, 0x099c, 0x1ECC},
+   {0, 0x099e, 0x3C52},
+   {0, 0x098A, 0xD27},
+   {0, 0x0990, 0x30ED},
+   {0, 0x0992, 0xDE},
+   {0, 0x0994, 0x1FEC},
+   {0, 0x0996, 0xA0BD},
+   {0, 0x0998, 0x7021},
+   {0, 0x099a, 0xCC3C},
+   {0, 0x099c, 0x5230},
+   {0, 0x099e, 0xED02},
+   {0, 0x098A, 0xD37},
+   {0, 0x0990, 0xCCFF},
+   {0, 0x0992, 0xFCED},
+   {0, 0x0994, 0xCC},
+   {0, 0x0996, 0x2},
+   {0, 0x0998, 0xBD70},
+   {0, 0x099a, 0x6DFC},
+   {0, 0x099c, 0x4E1},
+   {0, 0x099e, 0x1A83},
+   {0, 0x098A, 0xD47},
+   {0, 0x0990, 0x1},
+   {0, 0x0992, 0x2720},
+   {0, 0x0994, 0x1A83},
+   {0, 0x0996, 0x4},
+   {0, 0x0998, 0x271E},
+   {0, 0x099a, 0x1A83},
+   {0, 0x099c, 0x8},
+   {0, 0x099e, 0x271C},
+   {0, 0x098A, 0xD57},
+   {0, 0x0990, 0x1A83},
+   {0, 0x0992, 0x10},
+   {0, 0x0994, 0x271A},
+   {0, 0x0996, 0x1A83},
+   {0, 0x0998, 0x20},
+   {0, 0x099a, 0x2718},
+   {0, 0x099c, 0x1A83},
+   {0, 0x099e, 0x40},
+   {0, 0x098A, 0xD67},
+   {0, 0x0990, 0x2716},
+   {0, 0x0992, 0x2019},
+   {0, 0x0994, 0xC61E},
+

[PATCH v2 1/5] omap3evm: Enable regulators for camera interface

From: Vaibhav Hiremath hvaib...@ti.com

Enabled 1v8 and 2v8 regulator output, which is being used by
camera module.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
 arch/arm/mach-omap2/board-omap3evm.c |   22 ++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index c452b3f..f63a8fa 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -273,6 +273,25 @@ static struct omap_dss_board_info omap3_evm_dss_data = {
.default_device = omap3_evm_lcd_device,
 };
 
+static struct regulator_consumer_supply omap3evm_vaux3_supply[] = {
+   REGULATOR_SUPPLY(cam_2v8, NULL),
+};
+
+/* VAUX3 for CAM_2V8 */
+static struct regulator_init_data omap3evm_vaux3 = {
+   .constraints = {
+   .min_uV = 280,
+   .max_uV = 280,
+   .apply_uV   = true,
+   .valid_modes_mask   = REGULATOR_MODE_NORMAL
+   | REGULATOR_MODE_STANDBY,
+   .valid_ops_mask = REGULATOR_CHANGE_MODE
+   | REGULATOR_CHANGE_STATUS,
+   },
+   .num_consumer_supplies  = ARRAY_SIZE(omap3evm_vaux3_supply),
+   .consumer_supplies  = omap3evm_vaux3_supply,
+};
+
 static struct regulator_consumer_supply omap3evm_vmmc1_supply[] = {
REGULATOR_SUPPLY(vmmc, omap_hsmmc.0),
 };
@@ -433,6 +452,7 @@ static struct twl4030_keypad_data omap3evm_kp_data = {
 /* ads7846 on SPI */
 static struct regulator_consumer_supply omap3evm_vio_supply[] = {
REGULATOR_SUPPLY(vcc, spi1.0),
+   REGULATOR_SUPPLY(vio_1v8, NULL),
 };
 
 /* VIO for ads7846 */
@@ -499,6 +519,7 @@ static struct twl4030_platform_data omap3evm_twldata = {
.vio= omap3evm_vio,
.vmmc1  = omap3evm_vmmc1,
.vsim   = omap3evm_vsim,
+   .vaux3  = omap3evm_vaux3,
 };
 
 static int __init omap3_evm_i2c_init(void)
@@ -512,6 +533,7 @@ static int __init omap3_evm_i2c_init(void)
omap3evm_twldata.vpll2-constraints.apply_uV = true;
 
omap3_pmic_init(twl4030, omap3evm_twldata);
+   /* Bus 2 is used for Camera/Sensor interface */
omap_register_i2c_bus(2, 400, NULL, 0);
omap_register_i2c_bus(3, 400, NULL, 0);
return 0;
-- 
1.7.0.4

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

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

2011-09-27 Thread Partha Basak

-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Tuesday, September 27, 2011 6:55 PM
To: Munegowda, Keshava
Cc: t-kri...@ti.com; Paul Walmsley; Cousson, Benoit; Basak, Partha;
Balbi, Felipe; part...@india.ti.com; linux-...@vger.kernel.org; linux-
o...@vger.kernel.org; linux-ker...@vger.kernel.org; Gadiyar, Anand;
sa...@linux.intel.com; t...@atomide.com; Hilman, Kevin;
johns...@us.ibm.com; Sripathy, Vishwanath
Subject: Re: [PATCH 2/5 v11] arm: omap: usb: ehci and ohci hwmod
structures for omap3

Hi,

On Tue, Sep 27, 2011 at 06:48:35PM +0530, Munegowda, Keshava wrote:
  So, you would need a mechanism to do something like this:

  pad a or b wakeup detected - irq0
  pad c or d wakeup detected - irq1?

 yes, if get something like this , its perfect.

can't you have different IRQs for each pad ? I mean, allocate one
irq_desc for each pad and let drivers request a pad/pin as an IRQ
source. Then, when you detect a pad wakeup, you can:

unsigned   pad_irq = pad_number - pad-irq_base;

handle_nested_thread(pad_irq);

this will make use of threaded IRQ handlers even. Could it be something
like that ?

Felipe, your suggestion would mean more design change from the existing
implementation of Tero.

I would propose something like what Tero said initially:
For each mux-info have an associated irq handler.
So, say pads a..d form mux info1. This gets associated to irq_handler1.
Similarly, say pads e..h form mux info2. This gets associated to
irq_handler2.
Both get associated to the same uhh_hwmod. Now, when chain handler scans
for wakeup sources,
it scans both mux-info1  mux-info2.
If at-least one pad in mux-info1 is woken up, irqhandler1 is called  same
for irqhandler2.
This mechanism would need multiple mux-infos to be attached to the same
hwmod.

So, fundamentally, if we are in alignment, can we go ahead now to collapse
the ehci  ohci hwmods into one?

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

Re: [PATCH v2 0/5] OMAP3EVM: Add support for MT9T111 sensor

2011-09-27 Thread Gary Thomas


On 2011-09-27 07:40, Deepthy Ravi wrote:

This patchset
-adds support for MT9T111 sensor on omap3evm.
Currently the sensor driver supports only
VGA resolution.
-enables MT9T111 sensor in omap2plus_defconfig.

This is dependent on the following patchset
http://www.spinics.net/lists/linux-media/msg37270.html
which adds YUYV input support for OMAP3ISP. And is
applied on top of rc1-for-3.2 of gliakhovetski/v4l-dvb.git


Why not use the same base as Lennart?
  The set is based on
  
http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-omap3isp-next


---
Changes in v2:
As per the discussion here,
https://lkml.org/lkml/2011/9/20/280
the existing mt9t112 driver is reused for
adding support for mt9t111 sensor.
Deepthy Ravi (3):
   [media] v4l: Add support for mt9t111 sensor driver
   ispccdc: Configure CCDC_SYN_MODE register
   omap2plus_defconfig: Enable omap3isp and MT9T111 sensor drivers

Vaibhav Hiremath (2):
   omap3evm: Enable regulators for camera interface
   omap3evm: Add Camera board init/hookup file

  arch/arm/configs/omap2plus_defconfig|9 +
  arch/arm/mach-omap2/Makefile|5 +
  arch/arm/mach-omap2/board-omap3evm-camera.c |  185 
  arch/arm/mach-omap2/board-omap3evm.c|   26 +
  drivers/media/video/Kconfig |7 +
  drivers/media/video/Makefile|1 +
  drivers/media/video/mt9t111_reg.h   | 1367 +++
  drivers/media/video/mt9t112.c   |  320 ++-
  drivers/media/video/omap3isp/ispccdc.c  |   11 +-
  include/media/mt9t111.h |   45 +
  10 files changed, 1937 insertions(+), 39 deletions(-)
  create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
  create mode 100644 drivers/media/video/mt9t111_reg.h
  create mode 100644 include/media/mt9t111.h


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

RE: [PATCH 2/5] [media] v4l: Add mt9t111 sensor driver

2011-09-27 Thread Ravi, Deepthy

Hi,
 
 From: Gary Thomas [g...@mlbassoc.com]
 Sent: Tuesday, September 27, 2011 7:21 PM
 To: Ravi, Deepthy
 Cc: laurent.pinch...@ideasonboard.com; mche...@infradead.org; 
 t...@atomide.com; Hiremath, Vaibhav; linux-me...@vger.kernel.org; 
 li...@arm.linux.org.uk; linux-arm-ker...@lists.infradead.org; 
 kyungmin.p...@samsung.com; hverk...@xs4all.nl; m.szyprow...@samsung.com; 
 g.liakhovet...@gmx.de; Shilimkar, Santosh; khil...@deeprootsystems.com; 
 linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org
 Subject: Re: [PATCH v2 0/5] OMAP3EVM: Add support for MT9T111 sensor

 On 2011-09-27 07:40, Deepthy Ravi wrote:
 This patchset
   -adds support for MT9T111 sensor on omap3evm.
   Currently the sensor driver supports only
   VGA resolution.
   -enables MT9T111 sensor in omap2plus_defconfig.

 This is dependent on the following patchset
 http://www.spinics.net/lists/linux-media/msg37270.html
 which adds YUYV input support for OMAP3ISP. And is
 applied on top of rc1-for-3.2 of gliakhovetski/v4l-dvb.git

 Why not use the same base as Lennart?
   The set is based on
   
 http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-omap3isp-next

[Deepthy Ravi] Because the patches for making mt9t112 driver usable outside the 
soc-camera subsystem are present in that base only . Its not there in Laurent's.
 ---
 Changes in v2:
   As per the discussion here,
   https://lkml.org/lkml/2011/9/20/280
   the existing mt9t112 driver is reused for
   adding support for mt9t111 sensor.
 Deepthy Ravi (3):
[media] v4l: Add support for mt9t111 sensor driver
ispccdc: Configure CCDC_SYN_MODE register
omap2plus_defconfig: Enable omap3isp and MT9T111 sensor drivers

 Vaibhav Hiremath (2):
omap3evm: Enable regulators for camera interface
omap3evm: Add Camera board init/hookup file

   arch/arm/configs/omap2plus_defconfig|9 +
   arch/arm/mach-omap2/Makefile|5 +
   arch/arm/mach-omap2/board-omap3evm-camera.c |  185 
   arch/arm/mach-omap2/board-omap3evm.c|   26 +
   drivers/media/video/Kconfig |7 +
   drivers/media/video/Makefile|1 +
   drivers/media/video/mt9t111_reg.h   | 1367 
 +++
   drivers/media/video/mt9t112.c   |  320 ++-
   drivers/media/video/omap3isp/ispccdc.c  |   11 +-
   include/media/mt9t111.h |   45 +
   10 files changed, 1937 insertions(+), 39 deletions(-)
   create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
   create mode 100644 drivers/media/video/mt9t111_reg.h
   create mode 100644 include/media/mt9t111.h

 --
 
 Gary Thomas |  Consulting for the
 MLB Associates  |Embedded world
 


--
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 v7 REPOST 00/24] gpio/omap: driver cleanup and fixes

Tarun Kanti DebBarma tarun.ka...@ti.com writes:

 This series is continuation of cleanup of OMAP GPIO driver and fixes.
 The cleanup include getting rid of cpu_is_* checks wherever possible,
 use of gpio_bank list instead of static array, use of unique platform
 specific value associated data member to OMAP platforms to avoid
 cpu_is_* checks. The series also include PM runtime support.*

 Baseline: git://gitorious.org/khilman/linux-omap-pm.git
 Branch: for_3.2/gpio-cleanup
 Commit: 8323374

Is this functionally different than the branch you posted yesterday?

I replied to that saying it does not fix the PER retention problems on
n900, and giving a suggestion of how to test it.

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 v7 00/26] gpio/omap: driver cleanup and fixes

2011-09-27 Thread DebBarma, Tarun Kanti

On Tue, Sep 27, 2011 at 4:40 AM, Kevin Hilman khil...@ti.com wrote:
 DebBarma, Tarun Kanti tarun.ka...@ti.com writes:

 [...]

 As pointed out by Kevin, debounce clock was not getting disabled.
 In my testing I was somehow grepping CORE power domain instead
 of PER power domain and hence missed it. The fix for the debounce
 clock issue is at the end of the email.

 - Have re-based the for_3.2/gpio-cleanup branch against 3.1-rc6.
 - Dropped [PATCH 26/26] gpio/omap: add dbclk aliases for all gpio modules
 as suggested by Kevin since it's already taken care by hwmod.
 - Added the debounce clock fix in the end.

 That debounce fix definitely makes things look better, but it's not
 solving the problem...

 With above, PER is hitting low power state in Suspend and Idle path.

 Have pushed a branch at below URL with mentioned changes.
 git://gitorious.org/omap-sw-develoment/linux-omap-dev.git
 for_3.2/kevin/gpio-cleanup

 I tested your branch on my 3430/n900 and PER is still not hitting
 retention.  Setting all debounce values in the board file to zero using
 the patch below[1] makes PER hit retention again.

 Assuming you don't have an n900 to test with, I suggest you just copy
 the GPIO keys init from board-rx51-peripherals.c (or some of it) into
 the board file you are testing with.

 The problem is most likely be related to having more than one GPIO in a
 bank with debounce enabled, or more than one bank with GPIOs enabled and
 your current test is not be catching it.

As per commit c8c9fda506945 {OMAP: PM: disable idle on suspend for GPIO
and UART}, the gpio code needs to be fixed once GPIO driver is run-time adapted.
So I did below change as per the commit and now suspend is working fine even
with board files change for debounce functionality. So the last series
+ below one
line change is whats needed for suspend to work. Can you please see if this does
help on your board ?

I am not finished my idle testing yet but just reporting the suspend results.

diff --git a/arch/arm/mach-omap2/gpio.c b/arch/arm/mach-omap2/gpio.c
index d865033..1957663 100644
--- a/arch/arm/mach-omap2/gpio.c
+++ b/arch/arm/mach-omap2/gpio.c
@@ -148,8 +148,6 @@ static int omap2_gpio_dev_init(struct omap_hwmod
*oh, void *unused)
return PTR_ERR(od);
}

-   omap_device_disable_idle_on_suspend(od);
-
return 0;
 }

--

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

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

2011-09-27 Thread Tero Kristo

On Tue, 2011-09-27 at 15:24 +0200, Balbi, Felipe wrote:
 Hi,
 
 On Tue, Sep 27, 2011 at 06:48:35PM +0530, Munegowda, Keshava wrote:
   So, you would need a mechanism to do something like this:
  
   pad a or b wakeup detected - irq0
   pad c or d wakeup detected - irq1?
  
  yes, if get something like this , its perfect.
 
 can't you have different IRQs for each pad ? I mean, allocate one
 irq_desc for each pad and let drivers request a pad/pin as an IRQ
 source. Then, when you detect a pad wakeup, you can:

Direct pad to irq mapping was turned down on some previous version of
the prcm chain handler set, but yes, it is a potential approach. However
the irq_desc allocation mechanism should be dynamic... there are some
200 programmable pads anyway.


 unsigned  pad_irq = pad_number - pad-irq_base;
 
 handle_nested_thread(pad_irq);
 
 this will make use of threaded IRQ handlers even. Could it be something
 like that ?
 



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

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

Re: [PATCH 1/9] regulator: twl: Remove hardcoded board constraints from driver


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

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

Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
each regulator from the twl driver and let the boards pass it.

Signed-off-by: Rajendra Nayakrna...@ti.com




-   /* Constrain board-specific capabilities according to what
-* this driver and the chip itself can actually do.
-*/
-   c =initdata-constraints;
-   c-valid_modes_mask= REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
-   c-valid_ops_mask= REGULATOR_CHANGE_VOLTAGE
-   | REGULATOR_CHANGE_MODE
-   | REGULATOR_CHANGE_STATUS;


This isn't actually hard coding constraints, this is restricting the
constraints passed in further rather than adding new ones.

However should be fine:

Acked-by: Mark Brownbroo...@opensource.wolfsonmicro.com


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

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


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

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


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


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


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




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


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


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




/* voltage output range (inclusive) - for voltage control */
-   int min_uV;
-   int max_uV;
+   u32 min_uV;
+   u32 max_uV;

-   int uV_offset;
+   u32 uV_offset;

/* current output range (inclusive) - for current control */
-   int min_uA;
-   int max_uA;
+   u32 min_uA;
+   u32 max_uA;


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


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

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

Re: [PATCH 4/9] regulator: twl: Make twl-regulator driver extract data from DT


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

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


+#ifdef CONFIG_OF
+   charcompatible[128];
+#endif


Might it not be better to just make this a pointer to const char?


Yes, my bad.
--
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 5/9] regulator: helper routine to extract fixed_voltage_config


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

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

The helper routine of_get_fixed_voltage_config() extracts
fixed_voltage_config structure contents from device tree.

Also add documenation for additional bindings for fixed
regulators that can be passed through dt.


Why not just add device tree support into the driver directly?


Ok, will do.




+Optional properties:
+- regulator-fixed-supply: Name of the regulator supply


This is going to be confusing with respect to the generic regulator
supply property.


Yes, I guess. Any suggestions on how to make it less
confusing? :-)




+- regulator-fixed-enable-high: Polarity of enable GPIO, 1 = Active High, 0 = 
Active low


Word wrap for legibility please.


Ok.

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

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


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

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


+   if (!dev)
+   return NULL;


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


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




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


sz  4?  Magic!  :)


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




+extern struct device_node *of_get_regulator(struct device *dev,
+   const char *supply);


This shouldn't be part of the public API, it should be transparently
handled within the core.


agreed.

--
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 9/9] regulator: map consumer regulator based on device tree


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

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

Look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.


As with the fixed voltage regulator patch just use the code along with
adding it, no need to split it just makes it harder to review.


Ok.




+   if (dev-of_node) {
+   node = of_get_regulator(dev, id);
+   if (!node)
+   goto retry; /* fallback and chk regulator_map_list */
+   list_for_each_entry(rdev,regulator_list, list)
+   if (node == rdev-node)
+   goto found;
+   }
+retry:


retry is a confusing name for the target, we don't ever actually retry
using it.  Given the simplicity of the code I'd be inclined to just
intert the if (!node) check.


Ok.

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

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

On Tue, Sep 27, 2011 at 08:18:04PM +0530, Rajendra Nayak wrote:
 On Tuesday 27 September 2011 05:40 PM, Mark Brown wrote:
 On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:

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

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

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

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

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

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

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

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

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

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

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

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

2011-09-27 Thread Cousson, Benoit

On 9/27/2011 3:46 AM, Grant Likely wrote:
 On Thu, Sep 22, 2011 at 10:52:25PM +0200, Benoit Cousson wrote:

[...]

 +Required properties:
 +- compatible: Every devices present in OMAP SoC should be in the
 +  form: ti,XXX
 +- ti,hwmods: list of hwmods attached to a device. Must contain at least
 +  one hwmod.
 
 Nit: This should specify that ti,hwmods is a list of hwmod names
 (ascii strings), and that the hwmod names come from the OMAP
 documentation.  Don't respin the patch over this though, just do a
 follow-up patch.

OK, but since you asked later to remove the DT helpers, I will have to resend 
it anyway:-)

[...]

 +/*
 + * XXX: DT helper functions that should be replaced by more generic
 + * API introduced by Stephen Warren once they'll be in mainline.
 + */
 +static int _dt_count_property_string(const char *prop, int len)
 +{
 +int i = 0;
 +size_t l = 0, total = 0;
 +
 +if (!prop || !len)
 +return -EINVAL;
 +
 +for (i = 0; len= total; total += l, prop += l) {
 +l = strlen(prop) + 1;
 +if (*prop != 0)
 +i++;
 +}
 +return i;
 +}
 +
 +static int _dt_get_property(const char *prop, int len, int index, char 
 *output,
 +int size)
 +{
 +int i = 0;
 +size_t l = 0, total = 0;
 +
 +if (!prop || !len)
 +return -EINVAL;
 +
 +for (i = 0; len= total; total += l, prop += l) {
 +l = strlcpy(output, prop, size) + 1;
 +if (*prop != 0) {
 +if (i++ == index)
 +return 0;
 +}
 +}
 +return -ENODEV;
 +}
 
 Don't merge this.  Kevin or I could put Stephen's patch into a separate
 branch that both Kevin and I pull.  There's no need to merge temporary
 code.
 
 That said, I just looked at Stephen's iterator, and even without it
 this particular hunk shouldn't be merged here.  A
 of_property_count_strings() function is useful in and of itself, and
 of_property_read_string() could be extended with an
 of_property_read_string_index() version.  Both changes should be in
 the common drivers/of code, and you can easily do them.

I'm fine with that, but in that case, and in order to be consistent with the 
existing of_property_read_string, I should include the find_property in these 
functions. Whereas in my case, it was supposed to be done before.

Please find below a first version of this patch.

Regards,
Benoit

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

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

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

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 3ff22e3..d97d53e 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -662,6 +662,91 @@ int of_property_read_string(struct device_node *np, const 
char *propname,
 EXPORT_SYMBOL_GPL(of_property_read_string);
 
 /**
+ * of_property_read_string_index - Find and read a string from a multiple
+ * strings property.
+ * @np:device node from which the property value is to be read.
+ * @propname:  name of the property to be searched.
+ * @index: index of the string in the list of strings
+ * @out_string:pointer to null terminated return string, modified only 
if
+ * return value is 0.
+ *
+ * Search for a property in a device tree node and retrieve a null
+ * terminated string value (pointer to data, not a copy) in the list of strings
+ * contained in that property.
+ * Returns 0 on
+ * success, -EINVAL if the property does not exist, -ENODATA if property
+ * does not have a value, and -EILSEQ if the string is not null-terminated
+ * within the length of the property data.
+ *
+ * The out_string pointer is modified only if a valid string can be decoded.
+ */
+int of_property_read_string_index(struct device_node *np, const char *propname,
+ int index, const char **output)
+{
+   struct property *prop = of_find_property(np, propname, NULL);
+   int i = 0;
+   size_t l = 0, total = 0;
+   const char *p;
+
+   if (!prop)
+   return -EINVAL;
+   if (!prop-value)
+   return -ENODATA;
+   if (strnlen(prop-value, prop-length) = prop-length)
+   return -EILSEQ;
+
+   p = prop-value;
+
+   for (i = 0; total  prop-length; total += l, p += l) {
+   l = strlen(p) + 1;
+   if ((*p != 0)  (i++ == index)) {
+   *output = p;
+   return 0;
+   }
+   }
+

Re: [PATCH 5/9] regulator: helper routine to extract fixed_voltage_config

On Tue, Sep 27, 2011 at 08:19:00PM +0530, Rajendra Nayak wrote:
 On Tuesday 27 September 2011 05:46 PM, Mark Brown wrote:
 On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:

 +Optional properties:
 +- regulator-fixed-supply: Name of the regulator supply

 This is going to be confusing with respect to the generic regulator
 supply property.

 Yes, I guess. Any suggestions on how to make it less
 confusing? :-)

Call it display-name or something?
--
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 v7 00/26] gpio/omap: driver cleanup and fixes

DebBarma, Tarun Kanti tarun.ka...@ti.com writes:

 On Tue, Sep 27, 2011 at 4:40 AM, Kevin Hilman khil...@ti.com wrote:
 DebBarma, Tarun Kanti tarun.ka...@ti.com writes:

 [...]

 As pointed out by Kevin, debounce clock was not getting disabled.
 In my testing I was somehow grepping CORE power domain instead
 of PER power domain and hence missed it. The fix for the debounce
 clock issue is at the end of the email.

 - Have re-based the for_3.2/gpio-cleanup branch against 3.1-rc6.
 - Dropped [PATCH 26/26] gpio/omap: add dbclk aliases for all gpio modules
 as suggested by Kevin since it's already taken care by hwmod.
 - Added the debounce clock fix in the end.

 That debounce fix definitely makes things look better, but it's not
 solving the problem...

 With above, PER is hitting low power state in Suspend and Idle path.

 Have pushed a branch at below URL with mentioned changes.
 git://gitorious.org/omap-sw-develoment/linux-omap-dev.git
 for_3.2/kevin/gpio-cleanup

 I tested your branch on my 3430/n900 and PER is still not hitting
 retention.  Setting all debounce values in the board file to zero using
 the patch below[1] makes PER hit retention again.

 Assuming you don't have an n900 to test with, I suggest you just copy
 the GPIO keys init from board-rx51-peripherals.c (or some of it) into
 the board file you are testing with.

 The problem is most likely be related to having more than one GPIO in a
 bank with debounce enabled, or more than one bank with GPIOs enabled and
 your current test is not be catching it.

 As per commit c8c9fda506945 {OMAP: PM: disable idle on suspend for
 GPIO and UART}, the gpio code needs to be fixed once GPIO driver is
 run-time adapted.  

Great, good catch.

 So I did below change as per the commit and now suspend is working
 fine even with board files change for debounce functionality. So the
 last series + below one line change is whats needed for suspend to
 work. Can you please see if this does help on your board ?

Yeah, with your patch, PER is hitting retention in suspend on my
3430/n900.

 I am not finished my idle testing yet but just reporting the suspend
 results.

For me, PER is not hitting retention on idle.

Also, your repost of v7 doesn't included any of the comments I made on
it yesterday.

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 V7 0/4] cpuidle: Global registration of idle states with per-cpu statistics

Deepthi Dharwar deep...@linux.vnet.ibm.com writes:

 Version 6 of this patch series dated 22nd Sept 2011 was 
 Acked-by: Arjan van de Ven ar...@linux.intel.com
 Acked-by: Kevin Hilman khil...@ti.com for OMAP specific parts.
 Reviewed-by: Kevin Hilman khil...@ti.com
 Signed-off-by: Jean Pihet j-pi...@ti.com

minor: I think this should be a Tested-by from Jean.  Since he was not on
the delivery path, it should not be a sign-off.

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

[PATCH v3 0/6] OMAP: omap_device cleanup before device-tree integration

Hi Kevin,

Here are a couple of cleanups on top of your for_3.2/omap_device branch.

patches are available here:
git://gitorious.org/omap-pm/linux.git for_3.2/1_omap_device_cleanup

Regards,
Benoit


Changes since v1: http://www.spinics.net/lists/linux-omap/msg55801.html
 - Update the 2 patches from Nishanth based on Kevin's comment and merge
   them into one patch.
 - Fix the omap_device_pm_latency issue reported by Paul.

Changes since v2: http://www.spinics.net/lists/arm-kernel/msg138993.html
 - Change the API name from omap_hwmod_name_get_dev to 
   omap_device_get_by_hwmod_name per Kevin's suggestion.
 

Benoit Cousson (5):
  OMAP3: beagle-board: Use the omap_hwmod_name_get_dev API
  OMAP2+: pm: Use hwmod name instead of dev pointer
  OMAP2+: pm: Remove static devices variable for mpu, dsp, iva and l3 PM
  OMAP: omap_device: Create a default omap_device_pm_latency
  OMAP2+: devices: Remove all omap_device_pm_latency structures

Nishanth Menon (1):
  OMAP: omap_device: Add omap_device_get_by_hwmod_name

 arch/arm/mach-omap2/board-omap3beagle.c   |4 +-
 arch/arm/mach-omap2/devices.c |   46 ++---
 arch/arm/mach-omap2/display.c |   11 +
 arch/arm/mach-omap2/dma.c |   11 +
 arch/arm/mach-omap2/gpio.c|   12 +
 arch/arm/mach-omap2/hsmmc.c   |   18 +--
 arch/arm/mach-omap2/hwspinlock.c  |   12 +
 arch/arm/mach-omap2/mcbsp.c   |   11 +
 arch/arm/mach-omap2/pm.c  |   69 -
 arch/arm/mach-omap2/serial.c  |   25 +-
 arch/arm/mach-omap2/sr_device.c   |   11 +
 arch/arm/mach-omap2/usb-musb.c|   11 +
 arch/arm/plat-omap/i2c.c  |   10 +---
 arch/arm/plat-omap/include/plat/omap_device.h |1 +
 arch/arm/plat-omap/omap_device.c  |   55 +++-
 15 files changed, 93 insertions(+), 214 deletions(-)

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

[PATCH v3 1/6] OMAP: omap_device: Add omap_device_get_by_hwmod_name

From: Nishanth Menon n...@ti.com

An API which translates a standard hwmod name to corresponding
platform_device is useful for drivers when they need to look up the
device associated with a hwmod name to map back into the device
structure pointers. These ideally should be used by drivers in
mach directory. Using a generic hwmod name like gpu instead of
the actual device name which could change in the future, allows
us to:
a) Could in effect help replace apis such as omap2_get_mpuss_device,
omap2_get_iva_device, omap2_get_l3_device, omap4_get_dsp_device,
etc..
b) Scale to more devices rather than be restricted to named functions
c) Simplify driver's platform_data from passing additional fields
all doing the same thing with different function pointer names
just for accessing a different device name.

Signed-off-by: Nishanth Menon n...@ti.com
[b-cous...@ti.com: Adapt it to the new pdev pointer inside od,
remove the unneeded helpers, and fold the next patch here]
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
 arch/arm/plat-omap/include/plat/omap_device.h |1 +
 arch/arm/plat-omap/omap_device.c  |   36 +
 2 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/omap_device.h 
b/arch/arm/plat-omap/include/plat/omap_device.h
index d4d9b96..12c5b0c 100644
--- a/arch/arm/plat-omap/include/plat/omap_device.h
+++ b/arch/arm/plat-omap/include/plat/omap_device.h
@@ -101,6 +101,7 @@ struct platform_device *omap_device_build_ss(const char 
*pdev_name, int pdev_id,
 int pm_lats_cnt, int is_early_device);
 
 void __iomem *omap_device_get_rt_va(struct omap_device *od);
+struct device *omap_device_get_by_hwmod_name(const char *oh_name);
 
 /* OMAP PM interface */
 int omap_device_align_pm_lat(struct platform_device *pdev,
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 26aee5c..f832f92 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -844,6 +844,42 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od)
return omap_hwmod_get_mpu_rt_va(od-hwmods[0]);
 }
 
+/**
+ * omap_device_get_by_hwmod_name() - convert a hwmod name to
+ * device pointer.
+ * @oh_name: name of the hwmod device
+ *
+ * Returns back a struct device * pointer associated with a hwmod
+ * device represented by a hwmod_name
+ */
+struct device *omap_device_get_by_hwmod_name(const char *oh_name)
+{
+   struct omap_hwmod *oh;
+
+   if (!oh_name) {
+   WARN(1, %s: no hwmod name!\n, __func__);
+   return ERR_PTR(-EINVAL);
+   }
+
+   oh = omap_hwmod_lookup(oh_name);
+   if (IS_ERR_OR_NULL(oh)) {
+   WARN(1, %s: no hwmod for %s\n, __func__,
+   oh_name);
+   return ERR_PTR(oh ? PTR_ERR(oh) : -ENODEV);
+   }
+   if (IS_ERR_OR_NULL(oh-od)) {
+   WARN(1, %s: no omap_device for %s\n, __func__,
+   oh_name);
+   return ERR_PTR(oh-od ? PTR_ERR(oh-od) : -ENODEV);
+   }
+
+   if (IS_ERR_OR_NULL(oh-od-pdev))
+   return ERR_PTR(oh-od-pdev ? PTR_ERR(oh-od-pdev) : -ENODEV);
+
+   return oh-od-pdev-dev;
+}
+EXPORT_SYMBOL(omap_device_get_by_hwmod_name);
+
 /*
  * Public functions intended for use in omap_device_pm_latency
  * .activate_func and .deactivate_func function pointers
-- 
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 v3 2/6] OMAP3: beagle-board: Use the omap_hwmod_name_get_dev API

Replace the multiple omap2_get_XXX_device APIs with the new
omap_hwmod_name_get_dev that uses the hwmod name to get the proper
device.

Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Nishanth Menon n...@ti.com
---
 arch/arm/mach-omap2/board-omap3beagle.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index 3ae16b4..9815b2b 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -493,8 +493,8 @@ static void __init beagle_opp_init(void)
if (cpu_is_omap3630()) {
struct device *mpu_dev, *iva_dev;
 
-   mpu_dev = omap2_get_mpuss_device();
-   iva_dev = omap2_get_iva_device();
+   mpu_dev = omap_device_get_by_hwmod_name(mpu);
+   iva_dev = omap_device_get_by_hwmod_name(iva);
 
if (!mpu_dev || !iva_dev) {
pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
-- 
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 v3 4/6] OMAP2+: pm: Remove static devices variable for mpu, dsp, iva and l3 PM

Since the device pointer is now retrieved using the hwmod name, remove
the static variables used to store the device pointers for DSP, MPU, IVA
and L3 devices for PM/DVFS usage.

Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-omap2/pm.c |   47 ++---
 1 files changed, 7 insertions(+), 40 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index f852e4f..d2ef1c2 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -26,38 +26,7 @@
 
 static struct omap_device_pm_latency *pm_lats;
 
-static struct device *mpu_dev;
-static struct device *iva_dev;
-static struct device *l3_dev;
-static struct device *dsp_dev;
-
-struct device *omap2_get_mpuss_device(void)
-{
-   WARN_ON_ONCE(!mpu_dev);
-   return mpu_dev;
-}
-
-struct device *omap2_get_iva_device(void)
-{
-   WARN_ON_ONCE(!iva_dev);
-   return iva_dev;
-}
-
-struct device *omap2_get_l3_device(void)
-{
-   WARN_ON_ONCE(!l3_dev);
-   return l3_dev;
-}
-
-struct device *omap4_get_dsp_device(void)
-{
-   WARN_ON_ONCE(!dsp_dev);
-   return dsp_dev;
-}
-EXPORT_SYMBOL(omap4_get_dsp_device);
-
-/* static int _init_omap_device(struct omap_hwmod *oh, void *user) */
-static int _init_omap_device(char *name, struct device **new_dev)
+static int _init_omap_device(char *name)
 {
struct omap_hwmod *oh;
struct platform_device *pdev;
@@ -72,8 +41,6 @@ static int _init_omap_device(char *name, struct device 
**new_dev)
 __func__, name))
return -ENODEV;
 
-   *new_dev = pdev-dev;
-
return 0;
 }
 
@@ -82,16 +49,16 @@ static int _init_omap_device(char *name, struct device 
**new_dev)
  */
 static void omap2_init_processor_devices(void)
 {
-   _init_omap_device(mpu, mpu_dev);
+   _init_omap_device(mpu);
if (omap3_has_iva())
-   _init_omap_device(iva, iva_dev);
+   _init_omap_device(iva);
 
if (cpu_is_omap44xx()) {
-   _init_omap_device(l3_main_1, l3_dev);
-   _init_omap_device(dsp, dsp_dev);
-   _init_omap_device(iva, iva_dev);
+   _init_omap_device(l3_main_1);
+   _init_omap_device(dsp);
+   _init_omap_device(iva);
} else {
-   _init_omap_device(l3_main, l3_dev);
+   _init_omap_device(l3_main);
}
 }
 
-- 
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 v3 5/6] OMAP: omap_device: Create a default omap_device_pm_latency

Most devices are using the same default omap_device_pm_latency structure
during device built. In order to avoid the duplication of the same
structure everywhere, add a default structure that will be used if
the device does not have an explicit one.

Next patches will clean the duplicated structures.

Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
 arch/arm/plat-omap/omap_device.c |   19 ++-
 1 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index f832f92..cd8d977 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -97,6 +97,14 @@
 static int omap_device_register(struct platform_device *pdev);
 static int omap_early_device_register(struct platform_device *pdev);
 
+static struct omap_device_pm_latency omap_default_latency[] = {
+   {
+   .deactivate_func = omap_device_idle_hwmods,
+   .activate_func   = omap_device_enable_hwmods,
+   .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
+   }
+};
+
 /* Private functions */
 
 /**
@@ -510,8 +518,17 @@ struct platform_device *omap_device_build_ss(const char 
*pdev_name, int pdev_id,
if (ret)
goto odbs_exit3;
 
-   od-pm_lats = pm_lats;
+   if (!pm_lats) {
+   pm_lats = omap_default_latency;
+   pm_lats_cnt = ARRAY_SIZE(omap_default_latency);
+   }
+
od-pm_lats_cnt = pm_lats_cnt;
+   od-pm_lats = kmemdup(pm_lats,
+   sizeof(struct omap_device_pm_latency) * pm_lats_cnt,
+   GFP_KERNEL);
+   if (!od-pm_lats)
+   goto odbs_exit3;
 
for (i = 0; i  oh_cnt; i++) {
hwmods[i]-od = od;
-- 
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 v3 3/6] OMAP2+: pm: Use hwmod name instead of dev pointer

Replace the struct device parameter of omap2_set_init_voltage
by the hwmod name. It will avoid having to store explicitely
the device pointer into a static variable.
Moreover, it will be a little bit more scalable if we introduce
new DVFS devices.

Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-omap2/pm.c |   22 +++---
 1 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index e7cd794..f852e4f 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -169,18 +169,26 @@ err:
  * in the opp entry
  */
 static int __init omap2_set_init_voltage(char *vdd_name, char *clk_name,
-   struct device *dev)
+const char *oh_name)
 {
struct voltagedomain *voltdm;
struct clk *clk;
struct opp *opp;
unsigned long freq, bootup_volt;
+   struct device *dev;
 
-   if (!vdd_name || !clk_name || !dev) {
+   if (!vdd_name || !clk_name || !oh_name) {
printk(KERN_ERR %s: Invalid parameters!\n, __func__);
goto exit;
}
 
+   dev = omap_device_get_by_hwmod_name(oh_name);
+   if (IS_ERR(dev)) {
+   pr_err(%s: Unable to get dev pointer for hwmod %s\n,
+   __func__, oh_name);
+   goto exit;
+   }
+
voltdm = omap_voltage_domain_lookup(vdd_name);
if (IS_ERR(voltdm)) {
printk(KERN_ERR %s: Unable to get vdd pointer for vdd_%s\n,
@@ -226,8 +234,8 @@ static void __init omap3_init_voltages(void)
if (!cpu_is_omap34xx())
return;
 
-   omap2_set_init_voltage(mpu, dpll1_ck, mpu_dev);
-   omap2_set_init_voltage(core, l3_ick, l3_dev);
+   omap2_set_init_voltage(mpu, dpll1_ck, mpu);
+   omap2_set_init_voltage(core, l3_ick, l3_main);
 }
 
 static void __init omap4_init_voltages(void)
@@ -235,9 +243,9 @@ static void __init omap4_init_voltages(void)
if (!cpu_is_omap44xx())
return;
 
-   omap2_set_init_voltage(mpu, dpll_mpu_ck, mpu_dev);
-   omap2_set_init_voltage(core, l3_div_ck, l3_dev);
-   omap2_set_init_voltage(iva, dpll_iva_m5x2_ck, iva_dev);
+   omap2_set_init_voltage(mpu, dpll_mpu_ck, mpu);
+   omap2_set_init_voltage(core, l3_div_ck, l3_main_1);
+   omap2_set_init_voltage(iva, dpll_iva_m5x2_ck, iva);
 }
 
 static int __init omap2_common_pm_init(void)
-- 
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 v3 6/6] OMAP2+: devices: Remove all omap_device_pm_latency structures

Remove all these duplicated structures since a default one is now
available.

Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
 arch/arm/mach-omap2/devices.c|   46 +++--
 arch/arm/mach-omap2/display.c|   11 +
 arch/arm/mach-omap2/dma.c|   11 +
 arch/arm/mach-omap2/gpio.c   |   12 +-
 arch/arm/mach-omap2/hsmmc.c  |   18 +--
 arch/arm/mach-omap2/hwspinlock.c |   12 +-
 arch/arm/mach-omap2/mcbsp.c  |   11 +
 arch/arm/mach-omap2/serial.c |   25 +---
 arch/arm/mach-omap2/sr_device.c  |   11 +
 arch/arm/mach-omap2/usb-musb.c   |   11 +
 arch/arm/plat-omap/i2c.c |   10 +---
 11 files changed, 14 insertions(+), 164 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 10adf66..2d4a199 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -221,14 +221,6 @@ static inline void omap_init_camera(void)
 #endif
 }
 
-struct omap_device_pm_latency omap_keyboard_latency[] = {
-   {
-   .deactivate_func = omap_device_idle_hwmods,
-   .activate_func   = omap_device_enable_hwmods,
-   .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
-   },
-};
-
 int __init omap4_keyboard_init(struct omap4_keypad_platform_data
*sdp4430_keypad_data, struct omap_board_data *bdata)
 {
@@ -248,9 +240,7 @@ int __init omap4_keyboard_init(struct 
omap4_keypad_platform_data
keypad_data = sdp4430_keypad_data;
 
pdev = omap_device_build(name, id, oh, keypad_data,
-   sizeof(struct omap4_keypad_platform_data),
-   omap_keyboard_latency,
-   ARRAY_SIZE(omap_keyboard_latency), 0);
+   sizeof(struct omap4_keypad_platform_data), NULL, 0, 0);
 
if (IS_ERR(pdev)) {
WARN(1, Can't build omap_device for %s:%s.\n,
@@ -263,14 +253,6 @@ int __init omap4_keyboard_init(struct 
omap4_keypad_platform_data
 }
 
 #if defined(CONFIG_OMAP_MBOX_FWK) || defined(CONFIG_OMAP_MBOX_FWK_MODULE)
-static struct omap_device_pm_latency mbox_latencies[] = {
-   [0] = {
-   .activate_func = omap_device_enable_hwmods,
-   .deactivate_func = omap_device_idle_hwmods,
-   .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
-   },
-};
-
 static inline void omap_init_mbox(void)
 {
struct omap_hwmod *oh;
@@ -282,8 +264,7 @@ static inline void omap_init_mbox(void)
return;
}
 
-   pdev = omap_device_build(omap-mailbox, -1, oh, NULL, 0,
-   mbox_latencies, ARRAY_SIZE(mbox_latencies), 0);
+   pdev = omap_device_build(omap-mailbox, -1, oh, NULL, 0, NULL, 0, 0);
WARN(IS_ERR(pdev), %s: could not build device, err %ld\n,
__func__, PTR_ERR(pdev));
 }
@@ -334,14 +315,6 @@ static inline void omap_init_audio(void) {}
 
 #include plat/mcspi.h
 
-struct omap_device_pm_latency omap_mcspi_latency[] = {
-   [0] = {
-   .deactivate_func = omap_device_idle_hwmods,
-   .activate_func   = omap_device_enable_hwmods,
-   .flags   = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
-   },
-};
-
 static int omap_mcspi_init(struct omap_hwmod *oh, void *unused)
 {
struct platform_device *pdev;
@@ -372,8 +345,7 @@ static int omap_mcspi_init(struct omap_hwmod *oh, void 
*unused)
 
spi_num++;
pdev = omap_device_build(name, spi_num, oh, pdata,
-   sizeof(*pdata), omap_mcspi_latency,
-   ARRAY_SIZE(omap_mcspi_latency), 0);
+   sizeof(*pdata), NULL, 0, 0);
WARN(IS_ERR(pdev), Can't build omap_device for %s:%s\n,
name, oh-name);
kfree(pdata);
@@ -698,14 +670,6 @@ static int __init omap2_init_devices(void)
 arch_initcall(omap2_init_devices);
 
 #if defined(CONFIG_OMAP_WATCHDOG) || defined(CONFIG_OMAP_WATCHDOG_MODULE)
-static struct omap_device_pm_latency omap_wdt_latency[] = {
-   [0] = {
-   .deactivate_func = omap_device_idle_hwmods,
-   .activate_func   = omap_device_enable_hwmods,
-   .flags   = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
-   },
-};
-
 static int __init omap_init_wdt(void)
 {
int id = -1;
@@ -723,9 +687,7 @@ static int __init omap_init_wdt(void)
return -EINVAL;
}
 
-   pdev = omap_device_build(dev_name, id, oh, NULL, 0,
-   omap_wdt_latency,
-   ARRAY_SIZE(omap_wdt_latency), 0);
+   pdev = omap_device_build(dev_name, id, oh, NULL, 0, NULL, 0, 0);
WARN(IS_ERR(pdev), Can't build omap_device for %s:%s.\n,
dev_name, oh-name);
return 0;
diff --git

Re: [PATCH v3 5/6] OMAP: omap_device: Create a default omap_device_pm_latency

2011-09-27 Thread Tony Lindgren

* Benoit Cousson b-cous...@ti.com [110927 09:45]:
 Most devices are using the same default omap_device_pm_latency structure
 during device built. In order to avoid the duplication of the same
 structure everywhere, add a default structure that will be used if
 the device does not have an explicit one.
 
 Next patches will clean the duplicated structures.
 
 Signed-off-by: Benoit Cousson b-cous...@ti.com
 Cc: Kevin Hilman khil...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 ---
  arch/arm/plat-omap/omap_device.c |   19 ++-
  1 files changed, 18 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/plat-omap/omap_device.c 
 b/arch/arm/plat-omap/omap_device.c
 index f832f92..cd8d977 100644
 --- a/arch/arm/plat-omap/omap_device.c
 +++ b/arch/arm/plat-omap/omap_device.c
 @@ -97,6 +97,14 @@
  static int omap_device_register(struct platform_device *pdev);
  static int omap_early_device_register(struct platform_device *pdev);
  
 +static struct omap_device_pm_latency omap_default_latency[] = {
 + {
 + .deactivate_func = omap_device_idle_hwmods,
 + .activate_func   = omap_device_enable_hwmods,
 + .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
 + }
 +};
 +
  /* Private functions */

Isn't this racey between devices if the latency values get adjusted
automatically for each device?

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

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

2011-09-27 Thread Laurent Pinchart

Hi Vaibhav,

On Monday 19 September 2011 17:31:02 Hiremath, Vaibhav wrote:
 On Friday, September 16, 2011 6:36 PM Laurent Pinchart wrote:
  On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote:
   On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote:
On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote:
From: Vaibhav Hiremath hvaib...@ti.com

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

Why so ? Shouldn't it be queried on the subdev output pad directly ?
   
   Because standard v4l2 application for analog devices will call these
   std ioctls on the streaming device node. So it's done on /dev/video to
   make the existing apllication work.
  
  Existing applications can't work with the OMAP3 ISP (and similar complex
  embedded devices) without userspace support anyway, either in the form of
  a GStreamer element or a libv4l plugin. I still believe that analog video
  standard operations should be added to the subdev pad operations and
  exposed through subdev device nodes, exactly as done with formats.
 
 I completely agree with your point that, existing application will not work
 without setting links properly. But I believe the assumption here is,
 media-controller should set the links (along with pad formants) and all
 existing application should work as is. Isn't it?

The media controller is an API used (among other things) to set the links. You 
still need to call it from userspace. That won't happen magically. The 
userspace component that sets up the links and configures the formats, be it a 
GStreamer element, a libv4l plugin, or something else, can as well setup the 
standard on the TVP5146 subdev.

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

At then end of the OMAP3 ISP pipeline video data has long lost its analog 
roots. I don't think standards make sense there.

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

-- 
Regards,

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

Re: [RFC 2/5] ARM: OMAP: omap_device: add a method to set iommu private archdata

Hi Kevin,

On Tue, Sep 27, 2011 at 1:53 AM, Kevin Hilman khil...@ti.com wrote:
 Benoit did just this in preparation for DT.

       http://marc.info/?l=linux-omapm=131672480111927w=2

 Will that meet your needs?

It's almost there, but not entirely.

Benoit's alloc/delete functions focus on the omap_device part, leaving
the handling of the platform device (allocation and pdata setting) to
omap_device_build_ss(), which at the same time registers the pdev.

I'd need to split omap_device_build_ss() into two: an alloc() part
which does everything but registering the pdev, and a register() part.
Users will first call alloc(), manually set archdata members, and then
call the register() part.

Something like this (compile-tested only, based on Benoit's
for_3.2/4_omap4_dt_early_devices branch):

diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 0ae9e7f..9b8008c 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -671,7 +671,7 @@ struct platform_device *omap_device_build(const
char *pdev_name, int pdev_id,
 }

 /**
- * omap_device_build_ss - build and register an omap_device with
multiple hwmods
+ * omap_device_alloc_ss - build an omap_device with multiple hwmods
  * @pdev_name: name of the platform_device driver to use
  * @pdev_id: this platform_device's connection ID
  * @oh: ptr to the single omap_hwmod that backs this omap_device
@@ -679,19 +679,19 @@ struct platform_device *omap_device_build(const
char *pdev_name, int pdev_id,
  * @pdata_len: amount of memory pointed to by @pdata
  * @pm_lats: pointer to a omap_device_pm_latency array for this device
  * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
- * @is_early_device: should the device be registered as an early device or not
  *
- * Convenience function for building and registering an omap_device
+ * Convenience function for building (only) an omap_device
  * subsystem record.  Subsystem records consist of multiple
- * omap_hwmods.  This function in turn builds and registers a
- * platform_device record.  Returns an ERR_PTR() on error, or passes
- * along the return value of omap_device_register().
+ * omap_hwmods.  This function in turn builds (but doesn't register) a
+ * platform_device record, so callers can manipulate it (typically by
+ * setting one or more archdata members) before it's registered.
+ * Returns an ERR_PTR() on error, or the allocated pdev on success.
  */
-struct platform_device *omap_device_build_ss(const char *pdev_name,
int pdev_id,
+struct platform_device *omap_device_alloc_ss(const char *pdev_name,
int pdev_id,
 struct omap_hwmod **ohs, int oh_cnt,
 void *pdata, int pdata_len,
 struct omap_device_pm_latency *pm_lats,
-int pm_lats_cnt, int is_early_device)
+int pm_lats_cnt)
 {
int ret = -ENOMEM;
struct platform_device *pdev;
@@ -723,13 +723,6 @@ struct platform_device
*omap_device_build_ss(const char *pdev_name, int pdev_id,
if (ret)
goto odbs_exit2;

-   if (is_early_device)
-   ret = omap_early_device_register(pdev);
-   else
-   ret = omap_device_register(pdev);
-   if (ret)
-   goto odbs_exit2;
-
return pdev;

 odbs_exit2:
@@ -744,6 +737,93 @@ odbs_exit:
 }

 /**
+ * omap_device_delete_ss - free an omap_device-based platform device
+ * @pdev: platform_device that represents this omap_device
+ *
+ * Convenience function for freeing a platform_device record, which
+ * is based on an omap_device subsystem record.
+ *
+ * Use this function only if @pdev was created using omap_device_alloc_ss(),
+ * most commonly because a subsequent call to omap_device_register_ss() failed.
+ */
+void omap_device_delete_ss(struct platform_device *pdev)
+{
+   struct omap_device *od = to_omap_device(pdev);
+
+   omap_device_delete(od);
+   platform_device_put(pdev);
+}
+
+/**
+ * omap_device_register_ss - register an omap_device-based platform device
+ * @pdev: platform_device that represents this omap_device
+ * @is_early_device: should the device be registered as an early device or not
+ *
+ * Convenience function for registering a platform_device record, which
+ * is based on an omap_device subsystem record, which was created using
+ * omap_device_alloc_ss().
+ *
+ * Returns 0 on success, or an appropriate error value otherwise (essentially
+ * by returning the value of platform_device_register())
+ */
+int omap_device_register_ss(struct platform_device *pdev, int is_early_device)
+{
+   int ret;
+
+   if (is_early_device)
+   ret = omap_early_device_register(pdev);
+   else
+   ret = omap_device_register(pdev);
+
+   return ret;
+}
+
+/**
+ * omap_device_build_ss - build and register an omap_device with
multiple hwmods
+ * @pdev_name:

Re: [PATCH v3 1/6] iommu/core: split mapping to page sizes as supported by the hardware

2011-09-27 Thread Roedel, Joerg

On Tue, Sep 27, 2011 at 09:28:37AM -0400, Ohad Ben-Cohen wrote:
 So you're suggesting to re-implement find_next_bit() using ffs()/fls()
 and shifting ?

No. I suggest a simpler and shorter algorithm using the bit helpers.
Something like that:

min_idx = __ffs(iommu_page_sizes);

while (size) {
/* Max alignment allowed by current physical address */
phys_idx = __ffs(phys);

/* Max alignment allowed by current size */
size_idx = __fls(size);

/* special case: iova == 0 */
if (likely(phys))
idx = min(phys_idx, size_idx);
else
idx = size_idx;

BUG_ON(idx  min_idx);

psize = 1UL  idx;

/* search next smaller page-size supported */
while (psize  !(iommu_page_sizes  psize))
psize = 1;

BUG_ON(psize == 0);

iommu_ops-map(domain, iova, phys, get_order(psize), prot);

iova += psize;
phys += psize;
size -= psize;
}

It is only C-style pseudo-code, of course. These __ffs and __fls lines
all translate to a single instruction later. The find_next_bit()
function has a lot more overhead because it needs to take account of
real bitmaps (arrays of ulong). But this complexity is not required
here.

And yes, overhead is important when we implement the generic dma-ops
on-top of the iommu-api because this will make the iommu_map function a
fast-path. So we really care about overhead here.

Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

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

Re: [PATCH v3 5/6] OMAP: omap_device: Create a default omap_device_pm_latency

Tony Lindgren t...@atomide.com writes:

 * Benoit Cousson b-cous...@ti.com [110927 09:45]:
 Most devices are using the same default omap_device_pm_latency structure
 during device built. In order to avoid the duplication of the same
 structure everywhere, add a default structure that will be used if
 the device does not have an explicit one.
 
 Next patches will clean the duplicated structures.
 
 Signed-off-by: Benoit Cousson b-cous...@ti.com
 Cc: Kevin Hilman khil...@ti.com
 Cc: Paul Walmsley p...@pwsan.com
 ---
  arch/arm/plat-omap/omap_device.c |   19 ++-
  1 files changed, 18 insertions(+), 1 deletions(-)
 
 diff --git a/arch/arm/plat-omap/omap_device.c 
 b/arch/arm/plat-omap/omap_device.c
 index f832f92..cd8d977 100644
 --- a/arch/arm/plat-omap/omap_device.c
 +++ b/arch/arm/plat-omap/omap_device.c
 @@ -97,6 +97,14 @@
  static int omap_device_register(struct platform_device *pdev);
  static int omap_early_device_register(struct platform_device *pdev);
  
 +static struct omap_device_pm_latency omap_default_latency[] = {
 +{
 +.deactivate_func = omap_device_idle_hwmods,
 +.activate_func   = omap_device_enable_hwmods,
 +.flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
 +}
 +};
 +
  /* Private functions */

 Isn't this racey between devices if the latency values get adjusted
 automatically for each device?

A copy of this is made for each device (uses kmemdup later in the patch.)

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 v3 5/6] OMAP: omap_device: Create a default omap_device_pm_latency

2011-09-27 Thread Tony Lindgren

* Kevin Hilman khil...@ti.com [110927 10:56]:
 Tony Lindgren t...@atomide.com writes:
 
  Isn't this racey between devices if the latency values get adjusted
  automatically for each device?
 
 A copy of this is made for each device (uses kmemdup later in the patch.)

Oh ok, sorry for the noise.

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

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

On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:
 On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
 On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:

 +   if (!dev)
 +   return NULL;

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

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

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

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

 sz  4?  Magic!  :)

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

I think we need an of_get_phandle(), it'd be clearer what the check is,
more type safe and would avoid needing to replicate the check.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv5 1/4] regulator: omap smps regulator driver

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

 OMAP SMPS regulator driver provides access to OMAP voltage processor
 controlled regulators. These include VDD_MPU and VDD_CORE for OMAP3 and
 additionally VDD_IVA for OMAP4. SMPS regulators use the OMAP voltage
 layer for the actual voltage regulation operations.

 Signed-off-by: Tero Kristo t-kri...@ti.com
 Cc: Kevin Hilman khil...@ti.com
 Cc: Tony Lindgren t...@atomide.com
 Cc: Todd Poynor toddpoy...@google.com
 Cc: Mark Brown broo...@opensource.wolfsonmicro.com
 Cc: Liam Girdwood l...@ti.com
 Cc: Graeme Gregory g...@slimlogic.co.uk

I believe this was already ack'd by Mark.  Have there been any
significan changes since then?

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 2/5 v11] arm: omap: usb: ehci and ohci hwmod structures for omap3

2011-09-27 Thread Felipe Balbi

hi,

On Tue, Sep 27, 2011 at 05:38:51PM +0300, Tero Kristo wrote:
  On Tue, Sep 27, 2011 at 06:48:35PM +0530, Munegowda, Keshava wrote:
So, you would need a mechanism to do something like this:
   
pad a or b wakeup detected - irq0
pad c or d wakeup detected - irq1?
   
   yes, if get something like this , its perfect.
  
  can't you have different IRQs for each pad ? I mean, allocate one
  irq_desc for each pad and let drivers request a pad/pin as an IRQ
  source. Then, when you detect a pad wakeup, you can:
 
 Direct pad to irq mapping was turned down on some previous version of
 the prcm chain handler set, but yes, it is a potential approach. However

do you remember what was the reason for that being turned down ? Maybe I
can search the archives...

 the irq_desc allocation mechanism should be dynamic... there are some
 200 programmable pads anyway.

I wouldn't worry too much about that. If you try to allocate irq_desc
dynamically, you would have to keep track of an irq_base for each
irq_desc you allocate, otherwise it's difficult to map it back to mux
number.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v3 0/6] OMAP: omap_device cleanup before device-tree integration