[PATCH resend] OMAP: DSS2: Replace strncmp() with sysfs_streq() in overlay_manager_store()

2010-07-28 Thread Archit Taneja
In the function overlay_manager_store, the length of the string
buf is used to comapre the 2 strings, there is a possibility of
false positive match if buf is a prefix string of another manager.

The use of sysfs_streq() fixes this.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/overlay.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap2/dss/overlay.c 
b/drivers/video/omap2/dss/overlay.c
index 8233658..244dca8
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -65,7 +65,7 @@ static ssize_t overlay_manager_store(struct omap_overlay 
*ovl, const char *buf,
for (i = 0; i  omap_dss_get_num_overlay_managers(); ++i) {
mgr = omap_dss_get_overlay_manager(i);
 
-   if (strncmp(buf, mgr-name, len) == 0)
+   if (sysfs_streq(buf, mgr-name))
break;
 
mgr = NULL;
-- 
1.5.4.7

--
To unsubscribe from this list: send the line unsubscribe 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] twl4030 reboot workaround

2010-07-28 Thread Mikko Rapeli
From: Mikko Rapeli ext-mikko.rap...@nokia.com

Original patch: http://marc.info/?l=linux-omapm=126522625032441w=2

Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is
necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting
in the sleep script being executed on TWL4030. This usually results in
VDD1  VDD2 voltage collapse while ROM code is executing, followed by an
MPU Watch Dog reset or worse, an irrecoverable hang.

Original patch resulted in a crash due to sleeping i2c calls late in the
reboot sequence. Here's how to trigger the crash:

# cat /dev/urandom  /foo 
sync();
reboot(LINUX_REBOOT_CMD_RESTART2);

Kernel trace from 2.6.32:

Unable to handle kernel NULL pointer dereference at virtual address 
pgd = c0004000
[] *pgd=
Internal error: Oops: 805 [#2] PREEMPT
...
[c00b3210] (exit_mmap+0x1d4/0x1f8) from [c006069c] (mmput+0x34/0x110)
[c006069c] (mmput+0x34/0x110) from [c0064a90] (exit_mm+0x140/0x180)
[c0064a90] (exit_mm+0x140/0x180) from [c00668ec] (do_exit+0x5d8/0x6ac)
[c00668ec] (do_exit+0x5d8/0x6ac) from [c0035858] (die+0x2d4/0x2e0)
[c0035858] (die+0x2d4/0x2e0) from [c0035904] (baddataabort+0x0/0x50)
[c0035904] (baddataabort+0x0/0x50) from [c0274ff4] (i2c_transfer+0xec/0x104)
[c0274ff4] (i2c_transfer+0xec/0x104) from [0001] (0x1)

Fix is to move reboot preparations into a reboot notifier.

Signed-off-by: Mikko Rapeli ext-mikko.rap...@nokia.com
---
 drivers/mfd/twl4030-power.c |   29 +
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 7efa878..5d46768 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -28,6 +28,7 @@
 #include linux/pm.h
 #include linux/i2c/twl.h
 #include linux/platform_device.h
+#include linux/reboot.h
 
 #include asm/mach-types.h
 
@@ -127,6 +128,29 @@ static u8 res_config_addrs[] = {
[RES_Main_Ref]  = 0x94,
 };
 
+/*
+ * PRCM on OMAP3 will drive SYS_OFFMODE low during DPLL3 warm reset.
+ * This causes Gaia sleep script to execute, usually killing VDD1 and
+ * VDD2 while code is running.  WA is to disable the sleep script
+ * before warm reset.
+ */
+static int twl4030_prepare_for_reboot(struct notifier_block *this,
+   unsigned long cmd, void *p)
+{
+   int err;
+   err = twl4030_remove_script(TWL4030_SLEEP_SCRIPT);
+   if (err)
+   pr_err(TWL4030: error trying to disable sleep script!\n);
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block twl4030_reboot_notifier = {
+   .notifier_call = twl4030_prepare_for_reboot,
+   .next = NULL,
+   .priority = 0
+};
+
 static int __init twl4030_write_script_byte(u8 address, u8 byte)
 {
int err;
@@ -549,6 +573,11 @@ void __init twl4030_power_init(struct twl4030_power_data 
*twl4030_scripts)
err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, R_PROTECT_KEY);
if (err)
pr_err(TWL4030 Unable to relock registers\n);
+
+   err = register_reboot_notifier(twl4030_reboot_notifier);
+   if (err)
+   pr_err(TWL4030 Failed to register reboot notifier\n);
+
return;
 
 unlock:
-- 
1.5.6.5

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


Re: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER

2010-07-28 Thread Laurent Pinchart
Hi,

On Tuesday 27 July 2010 21:05:11 Sin, David wrote:
 On Tuesday 27 July 2010 13:38:00 Hiremath, Vaibhav wrote:
  On Saturday 24 July 2010 04:52:00 Sin, David wrote:
   
   This patch adds support for DMM-PAT initialization and programming.
[snip]

   diff --git a/arch/arm/mach-omap2/include/mach/dmm.h b/arch/arm/mach-
   omap2/include/mach/dmm.h
   new file mode 100644
   index 000..68b798a
   --- /dev/null
   +++ b/arch/arm/mach-omap2/include/mach/dmm.h
   @@ -0,0 +1,128 @@

[snip]

   +#define DMM_PAT_STATUS__0 0x4C0
   +#define DMM_PAT_STATUS__1 0x4C4
   +#define DMM_PAT_STATUS__2 0x4C8
   +#define DMM_PAT_STATUS__3 0x4CC
   +#define DMM_PAT_DESCR__0  0x500
   +#define DMM_PAT_AREA__0   0x504
   +#define DMM_PAT_CTRL__0   0x508
   +#define DMM_PAT_DATA__0   0x50C
  
  [Hiremath, Vaibhav] Not sure whether somebody has given same comment or
  not, any specific reason behind double _ here?
 
 [dhs] Yes -- this comment has been made already.  I'm using the same names
 defined in the TRM.  However, it can be changed.

If the TRM uses two underscores I'm fine with it.

-- 
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 1/8] TILER-DMM: DMM-PAT driver for TI TILER

2010-07-28 Thread Laurent Pinchart

On Tuesday 27 July 2010 21:53:28 Hiremath, Vaibhav wrote:
 On Wednesday 28 July 2010 00:35:00 Sin, David wrote:
  On Tuesday 27 July 2010 01:38:00 Hiremath, Vaibhav wrote:
   On Saturday 24 July 2010 04:52:00 Sin, David wrote:

[snip]

   [Hiremath, Vaibhav] If I understand correctly, DMM stands for
   dynamic memory manager. Is it something which can only be
   used with Video devices? Any specific reason why this is part
   of drivers/media/video/ directory,
 
  [dhs] Any device can use TILER memory, but there is a big advantage,
  performance-wise, for 2-Dimensional macro block based buffers.  This HW
  is intended for image/video hardware accelerators (e.g. OMAP4 IVA-HD). 
  Plus there's the added advantage of doing zero-copy flips and rotations
  for the OMAP display and image sub-systems.
 
 [Hiremath, Vaibhav] When you mention Tiler memory, you meant Tiler Virtual
 memory which is independent of physical memory. Driver requesting/using
 Tiler is responsible for allocating physical memory. Is that understanding
 correct?
 
 If yes, then feature wise it is same as VRFB in OMAP3, where it provides
 virtual address space and driver requesting VRFB is responsible for
 physical memory allocation. There could be additional features,
 enhancement and stuff but zero-copy rotation for DSS, then its same as
 VRFB.
 
 Don't you think is would be very difficult to use for drivers with such
 proposals, I can comment from DSS point of view,
 
 In case of OMAP4 80% of code is being re-used from OMAP3 (located under
 drivers/video/omap2/), which is currently supported hardware
 rotation/mirroring and hardly tied to VRFB API's.
 
 Now with this driver we have to do something,
 
 cpu_is_omap34xx()
 VRFB
 else if cpu_is_omap44xx()
 Tiler
 
 I am not sure about further OMAP series of devices, where we might have
 something else with DSS IP reuse (along with software). And I believe
 Tiler is not part of DSS at all. Again if some other devices are using
 Tiler API's it would become more difficult to re-use the code when same IP
 is being used in multiple SoC's.
 
 Does it make sense to you to have registration based mechanism (function
 pointer) where you register your hardware capabilities/API's, driver don't
 have to dependent on underneath hardware block. Ofcource if driver intend
 to use some specific/custom feature supported by some hardware block then
 he has to call that API under cpu_is_

I think I agree with it. The tiler provides dynamic views on arbitrary 
physical memory. Ideally it shouldn't be tied to the media/video subsystem 
(obviously it should still provide an interface for V4L drivers).

It's getting a bit hard to comment on the proposal, as there's no public 
documentation I'm aware of beside the Documentation/arm/TILER file in the 
patch set, and that information is far too concise and vague.

-- 
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] twl4030 reboot workaround

2010-07-28 Thread Gopinath, Thara


-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Mikko
Rapeli
Sent: Wednesday, July 28, 2010 3:12 PM
To: linux-omap@vger.kernel.org
Cc: Turquette, Mike; sa...@linux.intel.com
Subject: [PATCH] twl4030 reboot workaround

From: Mikko Rapeli ext-mikko.rap...@nokia.com

Original patch: http://marc.info/?l=linux-omapm=126522625032441w=2

Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is
necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting
in the sleep script being executed on TWL4030. This usually results in
VDD1  VDD2 voltage collapse while ROM code is executing, followed by an
MPU Watch Dog reset or worse, an irrecoverable hang.

Original patch resulted in a crash due to sleeping i2c calls late in the
reboot sequence. Here's how to trigger the crash:

  # cat /dev/urandom  /foo 
  sync();
reboot(LINUX_REBOOT_CMD_RESTART2);

Kernel trace from 2.6.32:

Unable to handle kernel NULL pointer dereference at virtual address 
pgd = c0004000
[] *pgd=
Internal error: Oops: 805 [#2] PREEMPT
...
[c00b3210] (exit_mmap+0x1d4/0x1f8) from [c006069c] (mmput+0x34/0x110)
[c006069c] (mmput+0x34/0x110) from [c0064a90] (exit_mm+0x140/0x180)
[c0064a90] (exit_mm+0x140/0x180) from [c00668ec] (do_exit+0x5d8/0x6ac)
[c00668ec] (do_exit+0x5d8/0x6ac) from [c0035858] (die+0x2d4/0x2e0)
[c0035858] (die+0x2d4/0x2e0) from [c0035904] (baddataabort+0x0/0x50)
[c0035904] (baddataabort+0x0/0x50) from [c0274ff4] 
(i2c_transfer+0xec/0x104)
[c0274ff4] (i2c_transfer+0xec/0x104) from [0001] (0x1)

Fix is to move reboot preparations into a reboot notifier.

Signed-off-by: Mikko Rapeli ext-mikko.rap...@nokia.com
---
 drivers/mfd/twl4030-power.c |   29 +
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 7efa878..5d46768 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -28,6 +28,7 @@
 #include linux/pm.h
 #include linux/i2c/twl.h
 #include linux/platform_device.h
+#include linux/reboot.h

 #include asm/mach-types.h

@@ -127,6 +128,29 @@ static u8 res_config_addrs[] = {
  [RES_Main_Ref]  = 0x94,
 };

+/*
+ * PRCM on OMAP3 will drive SYS_OFFMODE low during DPLL3 warm reset.
+ * This causes Gaia sleep script to execute, usually killing VDD1 and
+ * VDD2 while code is running.  WA is to disable the sleep script
+ * before warm reset.
+ */
+static int twl4030_prepare_for_reboot(struct notifier_block *this,
+ unsigned long cmd, void *p)
+{
+ int err;

Minor nit. Insert a blank line.

Regards
Thara

+ err = twl4030_remove_script(TWL4030_SLEEP_SCRIPT);
+ if (err)
+ pr_err(TWL4030: error trying to disable sleep script!\n);
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block twl4030_reboot_notifier = {
+ .notifier_call = twl4030_prepare_for_reboot,
+ .next = NULL,
+ .priority = 0
+};
+
 static int __init twl4030_write_script_byte(u8 address, u8 byte)
 {
  int err;
@@ -549,6 +573,11 @@ void __init twl4030_power_init(struct twl4030_power_data 
*twl4030_scripts)
  err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, R_PROTECT_KEY);
  if (err)
  pr_err(TWL4030 Unable to relock registers\n);
+
+ err = register_reboot_notifier(twl4030_reboot_notifier);
+ if (err)
+ pr_err(TWL4030 Failed to register reboot notifier\n);
+
  return;

 unlock:
--
1.5.6.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe 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] twl4030 reboot workaround

2010-07-28 Thread Peter 'p2' De Schrijver
On Wed, Jul 28, 2010 at 11:41:32AM +0200, Rapeli Mikko (EXT-Ixonos/Oulu) wrote:
 From: Mikko Rapeli ext-mikko.rap...@nokia.com
 
 Original patch: http://marc.info/?l=linux-omapm=126522625032441w=2
 
 Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is
 necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting
 in the sleep script being executed on TWL4030. This usually results in
 VDD1  VDD2 voltage collapse while ROM code is executing, followed by an
 MPU Watch Dog reset or worse, an irrecoverable hang.
 
 Original patch resulted in a crash due to sleeping i2c calls late in the
 reboot sequence. Here's how to trigger the crash:
 
   # cat /dev/urandom  /foo 
   sync();
 reboot(LINUX_REBOOT_CMD_RESTART2);
 
 Kernel trace from 2.6.32:
 
 Unable to handle kernel NULL pointer dereference at virtual address 
 pgd = c0004000
 [] *pgd=
 Internal error: Oops: 805 [#2] PREEMPT
 ...
 [c00b3210] (exit_mmap+0x1d4/0x1f8) from [c006069c] (mmput+0x34/0x110)
 [c006069c] (mmput+0x34/0x110) from [c0064a90] (exit_mm+0x140/0x180)
 [c0064a90] (exit_mm+0x140/0x180) from [c00668ec] (do_exit+0x5d8/0x6ac)
 [c00668ec] (do_exit+0x5d8/0x6ac) from [c0035858] (die+0x2d4/0x2e0)
 [c0035858] (die+0x2d4/0x2e0) from [c0035904] (baddataabort+0x0/0x50)
 [c0035904] (baddataabort+0x0/0x50) from [c0274ff4] 
 (i2c_transfer+0xec/0x104)
 [c0274ff4] (i2c_transfer+0xec/0x104) from [0001] (0x1)
 
 Fix is to move reboot preparations into a reboot notifier.
 

And what if we get an OMAP3 watchdog reset ? In this case there is no
software to remove the script...

Cheers,

Peter.
--
To unsubscribe from this list: send the line unsubscribe 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: OMAP2 DSS Linux Driver

2010-07-28 Thread Tomi Valkeinen
On Wed, 2010-07-28 at 10:55 +0200, ext Nicholas Beck wrote:
 Hi Tomi,
 
 Firstly, I apologise if you would prefer this on a maillist rather than 
 a direct mail. Please let me know if you would prefer this on a maillist 
 I will post it there instead.

cc'ing linux-omap mailing list is always good (cc'd). More people can
answer, and more people will see the answer.

 I am working with the omap2 DSS driver implementation that you created. 
 The DSS linux docs say that MIPI DBI (RFBI) output is working and tested.
 
 Please could you let me know what platform you tried this on?

That information is a bit outdated. RFBI was working and tested, and the
platform was Nokia N800. However, the panel driver for N800 was just a
quickly ported hack, and currently there are no public boards that use
DSS2 and RFBI.

There has been quite big changes in the DSS2 code, and RFBI is most
likely broken. There has also been some discussions about RFBI in
linux-omap mailinglist, but I haven't looked at the RFBI code myself as
I don't have any board to test it on.

 I am working with some custom hardware, which is largely similar to the 
 OMAP3530EVM, but will use MIPI DBI (RFBI) through a custom FPGA instead 
 of MIPI DPI (RFBI bypass) as used by the EVM's LCD. We are trying to 
 reduce the integration risk by basing this work on a known working platform.

Most likely the problems with RFBI are quite small, as the driver did
work earlier. However, finding those small problems may be a big job =).
I suggest you search l-o mailing list archives, and try to work with the
guys there who are trying to use RFBI.

 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 2/2] omap:mailbox-provide multiple reader support

2010-07-28 Thread Ohad Ben-Cohen
Hi Hari,

On Wed, Jul 28, 2010 at 1:02 AM, Ohad Ben-Cohen o...@wizery.com wrote:
 On Wed, Jul 21, 2010 at 12:41 AM, Hari Kanigeri h-kanige...@ti.com wrote:
  This patch provides mutiple readers support for a mailbox
  instance.
 
  Signed-off-by: Hari Kanigeri h-kanige...@ti.com
  ---
   arch/arm/plat-omap/include/plat/mailbox.h |    6 ++-
   arch/arm/plat-omap/mailbox.c              |   63 
  
   2 files changed, 40 insertions(+), 29 deletions(-)
 
  diff --git a/arch/arm/plat-omap/include/plat/mailbox.h 
  b/arch/arm/plat-omap/include/plat/mailbox.h
  index 0486d64..c8e47d8 100644
  --- a/arch/arm/plat-omap/include/plat/mailbox.h
  +++ b/arch/arm/plat-omap/include/plat/mailbox.h
  @@ -68,13 +68,15 @@ struct omap_mbox {
         void                    *priv;
 
         void                    (*err_notify)(void);
  +       atomic_t                use_count;
  +       struct blocking_notifier_head   notifier;
   };
 
   int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
   void omap_mbox_init_seq(struct omap_mbox *);
 
  -struct omap_mbox *omap_mbox_get(const char *);
  -void omap_mbox_put(struct omap_mbox *);
  +struct omap_mbox *omap_mbox_get(const char *, struct notifier_block *nb);

 In this context, I'd like to change notifier to support adding a
 cookie which will be passed back to the handler function (unmodified,
 in a similar manner to request_irq's void *dev param).

This can be easily achieved with a simple container_of manipulation,
so please disregard my request : your patch is fine as-is. After it is
accepted, it'd be simple to add this context-get-back to dspbridge.

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: OMAP2 DSS Linux Driver

2010-07-28 Thread Nicholas Beck

On 28/07/10 11:32, Tomi Valkeinen wrote:

On Wed, 2010-07-28 at 10:55 +0200, ext Nicholas Beck wrote:
   

Hi Tomi,

Firstly, I apologise if you would prefer this on a maillist rather than
a direct mail. Please let me know if you would prefer this on a maillist
I will post it there instead.
 

cc'ing linux-omap mailing list is always good (cc'd). More people can
answer, and more people will see the answer.
   

Thanks and understood. I will make sure that future posts hit the mail list.
   

I am working with the omap2 DSS driver implementation that you created.
The DSS linux docs say that MIPI DBI (RFBI) output is working and tested.

Please could you let me know what platform you tried this on?
 

That information is a bit outdated. RFBI was working and tested, and the
platform was Nokia N800. However, the panel driver for N800 was just a
quickly ported hack, and currently there are no public boards that use
DSS2 and RFBI.

There has been quite big changes in the DSS2 code, and RFBI is most
likely broken. There has also been some discussions about RFBI in
linux-omap mailinglist, but I haven't looked at the RFBI code myself as
I don't have any board to test it on.

   

I am working with some custom hardware, which is largely similar to the
OMAP3530EVM, but will use MIPI DBI (RFBI) through a custom FPGA instead
of MIPI DPI (RFBI bypass) as used by the EVM's LCD. We are trying to
reduce the integration risk by basing this work on a known working platform.
 

Most likely the problems with RFBI are quite small, as the driver did
work earlier. However, finding those small problems may be a big job =).
I suggest you search l-o mailing list archives, and try to work with the
guys there who are trying to use RFBI.

   
Thanks for the info. I'll dig through the archive and see what the 
current state is.


Nick

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


RE: [PATCH resend] OMAP: DSS2: Replace strncmp() with sysfs_streq() in overlay_manager_store()

2010-07-28 Thread Premi, Sanjeev
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Taneja, Archit
 Sent: Wednesday, July 28, 2010 11:52 AM
 To: tomi.valkei...@nokia.com
 Cc: linux-omap@vger.kernel.org; Taneja, Archit
 Subject: [PATCH resend] OMAP: DSS2: Replace strncmp() with 
 sysfs_streq() in overlay_manager_store()
 
 In the function overlay_manager_store, the length of the string
 buf is used to comapre the 2 strings, there is a possibility of
 false positive match if buf is a prefix string of another manager.
 
 The use of sysfs_streq() fixes this.
 
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/video/omap2/dss/overlay.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/video/omap2/dss/overlay.c 
 b/drivers/video/omap2/dss/overlay.c
 index 8233658..244dca8
 --- a/drivers/video/omap2/dss/overlay.c
 +++ b/drivers/video/omap2/dss/overlay.c
 @@ -65,7 +65,7 @@ static ssize_t overlay_manager_store(struct 
 omap_overlay *ovl, const char *buf,
   for (i = 0; i  
 omap_dss_get_num_overlay_managers(); ++i) {
   mgr = omap_dss_get_overlay_manager(i);
  
 - if (strncmp(buf, mgr-name, len) == 0)
 + if (sysfs_streq(buf, mgr-name))

[sp] sysfs_streq() ignores trailing newlines during comparison. So,
 the possibility mentioned in the description still stays.

 I am not familiar with overall context; but wouldn't srtcmp()
 be the right choice? unless, of course, either of strings
 being compared are not null terminated.

   break;
  
   mgr = NULL;
 -- 
 1.5.4.7
 
 --
 To unsubscribe from this list: send the line unsubscribe 
 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 2/5] omap:hwspinlock-define HWSPINLOCK base address

2010-07-28 Thread Premi, Sanjeev
 

 -Original Message-
 From: Kanigeri, Hari 
 Sent: Tuesday, July 27, 2010 10:20 PM
 To: Premi, Sanjeev; Linux Omap; Tony Lindgren
 Cc: Shilimkar, Santosh; Cousson, Benoit; Que, Simon
 Subject: RE: [PATCH 2/5] omap:hwspinlock-define HWSPINLOCK 
 base address
 
 Sanjeev,
 
   @@ -49,5 +49,10 @@
#define OMAP44XX_MAILBOX_BASE(L4_44XX_BASE + 0xF4000)
#define OMAP44XX_HSUSB_OTG_BASE  (L4_44XX_BASE + 0xAB000)
  
   +#define OMAP4_MMU1_BASE  0x55082000
   +#define OMAP4_MMU2_BASE  0x4A066000
  
  [sp] Are these 2 base addresses related to this patch?
 
 Nope. Thanks for finding this. I will update the patch.

[sp] Then additional patch only to add the base address won't make much sense.
 You may want to combine it with appropriately with another one in this
 series.

 
  
  ~sanjeev
  
   +
   +#define OMAP44XX_SPINLOCK_BASE   (L4_44XX_BASE + 0xF6000)
   +
#endif /* __ASM_ARCH_OMAP44XX_H */
  
   --
   1.7.0
  
  
 
 Best regards,
 Hari
 --
To unsubscribe from this list: send the line unsubscribe 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] omap:hwspinlock-define HWSPINLOCK base address

2010-07-28 Thread Kanigeri, Hari
Sanjeev,


 -Original Message-
 From: Premi, Sanjeev
 Sent: Wednesday, July 28, 2010 9:12 AM
 To: Kanigeri, Hari; Linux Omap; Tony Lindgren
 Cc: Shilimkar, Santosh; Cousson, Benoit; Que, Simon
 Subject: RE: [PATCH 2/5] omap:hwspinlock-define HWSPINLOCK base address
 
 
 
  -Original Message-
  From: Kanigeri, Hari
  Sent: Tuesday, July 27, 2010 10:20 PM
  To: Premi, Sanjeev; Linux Omap; Tony Lindgren
  Cc: Shilimkar, Santosh; Cousson, Benoit; Que, Simon
  Subject: RE: [PATCH 2/5] omap:hwspinlock-define HWSPINLOCK
  base address
 
  Sanjeev,
 
@@ -49,5 +49,10 @@
 #define OMAP44XX_MAILBOX_BASE  (L4_44XX_BASE + 0xF4000)
 #define OMAP44XX_HSUSB_OTG_BASE(L4_44XX_BASE + 0xAB000)
   
+#define OMAP4_MMU1_BASE0x55082000
+#define OMAP4_MMU2_BASE0x4A066000
  
   [sp] Are these 2 base addresses related to this patch?
 
  Nope. Thanks for finding this. I will update the patch.
 
 [sp] Then additional patch only to add the base address won't make much
 sense.
  You may want to combine it with appropriately with another one in
 this
  series.

I think the define to add SPINLOCK base address is independent of adding 
spinlock driver functionality, and I don't see a reason why it shouldn't be a 
separate patch.
Example: The driver patches might take time to get upstreamed, but that 
shouldn't stop this patch that adds the missing Base address.

 
 
  
   ~sanjeev
  
+
+#define OMAP44XX_SPINLOCK_BASE (L4_44XX_BASE + 0xF6000)
+
 #endif /* __ASM_ARCH_OMAP44XX_H */
   
--
1.7.0
   
   
 
  Best regards,
  Hari
 
--
To unsubscribe from this list: send the line unsubscribe 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] omap:hwspinlock-define HWSPINLOCK base address

2010-07-28 Thread Premi, Sanjeev
 

 -Original Message-
 From: Kanigeri, Hari 
 Sent: Wednesday, July 28, 2010 7:53 PM
 To: Premi, Sanjeev; Linux Omap; Tony Lindgren
 Cc: Shilimkar, Santosh; Cousson, Benoit; Que, Simon
 Subject: RE: [PATCH 2/5] omap:hwspinlock-define HWSPINLOCK 
 base address
 
[snip]

   Sanjeev,
  
 @@ -49,5 +49,10 @@
  #define OMAP44XX_MAILBOX_BASE
 (L4_44XX_BASE + 0xF4000)
  #define OMAP44XX_HSUSB_OTG_BASE  
 (L4_44XX_BASE + 0xAB000)

 +#define OMAP4_MMU1_BASE  0x55082000
 +#define OMAP4_MMU2_BASE  0x4A066000
   
[sp] Are these 2 base addresses related to this patch?
  
   Nope. Thanks for finding this. I will update the patch.
  
  [sp] Then additional patch only to add the base address 
 won't make much
  sense.
   You may want to combine it with appropriately with 
 another one in
  this
   series.
 
 I think the define to add SPINLOCK base address is 
 independent of adding spinlock driver functionality, and I 
 don't see a reason why it shouldn't be a separate patch.
 Example: The driver patches might take time to get 
 upstreamed, but that shouldn't stop this patch that adds the 
 missing Base address.

[sp] Without driver would this base address be of any use?

 
  
  
   
~sanjeev
   
 +
 +#define OMAP44XX_SPINLOCK_BASE   
 (L4_44XX_BASE + 0xF6000)
 +
  #endif /* __ASM_ARCH_OMAP44XX_H */

 --
 1.7.0


  
   Best regards,
   Hari
  
 --
To unsubscribe from this list: send the line unsubscribe 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/5] staging:ti dspbridge: Checkpatch errors cleanup series

2010-07-28 Thread Ernesto Ramos
These patches are targetted to remove checkpatch errors within
dspbridge driver.

Ernesto Ramos (5):
  staging:ti dspbridge: remove unused typedef REG16
  staging:ti dspbridge: remove unnecessary check for NULL pointer in
cmm.c
  staging:ti dspbridge: remove function delete_strm_mgr
  staging:ti dspbridge: remove unnecessary volatile variables
  staging:ti dspbridge: replace simple_strtoul by strict_strtoul

 drivers/staging/tidspbridge/core/_tiomap.h|2 --
 drivers/staging/tidspbridge/core/tiomap3430.c |8 
 drivers/staging/tidspbridge/dynload/tramp.c   |4 ++--
 drivers/staging/tidspbridge/pmgr/cmm.c|   15 ++-
 drivers/staging/tidspbridge/rmgr/dbdcd.c  |6 +-
 drivers/staging/tidspbridge/rmgr/strm.c   |   16 ++--
 6 files changed, 19 insertions(+), 32 deletions(-)

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


[PATCH 1/5] staging:ti dspbridge: remove unused typedef REG16

2010-07-28 Thread Ernesto Ramos
Remove unused typedef REG16 in dspbridge.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/core/_tiomap.h |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/_tiomap.h 
b/drivers/staging/tidspbridge/core/_tiomap.h
index b754e49..1c1f157 100644
--- a/drivers/staging/tidspbridge/core/_tiomap.h
+++ b/drivers/staging/tidspbridge/core/_tiomap.h
@@ -295,8 +295,6 @@ static const struct bpwr_clk_t bpwr_clks[] = {
 #define LOW_LEVEL   false
 
 /* Macro's */
-#define REG16(A)(*(reg_uword16 *)(A))
-
 #define CLEAR_BIT(reg, mask) (reg = ~mask)
 #define SET_BIT(reg, mask)   (reg |= mask)
 
-- 
1.5.4.5

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


RE: [PATCH resend] OMAP: DSS2: Replace strncmp() with sysfs_streq() in overlay_manager_store()

2010-07-28 Thread Taneja, Archit
 

 -Original Message-
 From: Premi, Sanjeev 
 Sent: Wednesday, July 28, 2010 7:28 PM
 To: Taneja, Archit; tomi.valkei...@nokia.com
 Cc: linux-omap@vger.kernel.org
 Subject: RE: [PATCH resend] OMAP: DSS2: Replace strncmp() 
 with sysfs_streq() in overlay_manager_store()
 
  -Original Message-
  From: linux-omap-ow...@vger.kernel.org 
  [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
 Taneja, Archit
  Sent: Wednesday, July 28, 2010 11:52 AM
  To: tomi.valkei...@nokia.com
  Cc: linux-omap@vger.kernel.org; Taneja, Archit
  Subject: [PATCH resend] OMAP: DSS2: Replace strncmp() with
  sysfs_streq() in overlay_manager_store()
  
  In the function overlay_manager_store, the length of the 
 string buf is 
  used to comapre the 2 strings, there is a possibility of false 
  positive match if buf is a prefix string of another manager.
  
  The use of sysfs_streq() fixes this.
  
  Signed-off-by: Archit Taneja arc...@ti.com
  ---
   drivers/video/omap2/dss/overlay.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
  
  diff --git a/drivers/video/omap2/dss/overlay.c
  b/drivers/video/omap2/dss/overlay.c
  index 8233658..244dca8
  --- a/drivers/video/omap2/dss/overlay.c
  +++ b/drivers/video/omap2/dss/overlay.c
  @@ -65,7 +65,7 @@ static ssize_t overlay_manager_store(struct 
  omap_overlay *ovl, const char *buf,
  for (i = 0; i 
  omap_dss_get_num_overlay_managers(); ++i) {
  mgr = omap_dss_get_overlay_manager(i);
   
  -   if (strncmp(buf, mgr-name, len) == 0)
  +   if (sysfs_streq(buf, mgr-name))
 
 [sp] sysfs_streq() ignores trailing newlines during comparison. So,
  the possibility mentioned in the description still stays.

The aim is to compare one string which is a sysfs input and the other
which is in the kernel. 

 
  I am not familiar with overall context; but wouldn't srtcmp()
  be the right choice? unless, of course, either of strings
  being compared are not null terminated.

The sysfs input will have a newline and null at the end whereas the
other string will only have null, strcmp will fail when we want the two
strings to match.

Eg. Sysfs input lcd\n\0
Kernel string lcd\0

strcmp will fail here

 
  break;
   
  mgr = NULL;
  --
  1.5.4.7
  
  --
  To unsubscribe from this list: send the line unsubscribe 
 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


[PATCH 4/5] staging:ti dspbridge: remove unnecessary volatile variables

2010-07-28 Thread Ernesto Ramos
Remove unnecessary volatile variables; use accessor
functions __raw_readl/__raw_writel instead when applicable.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/core/tiomap3430.c |8 
 drivers/staging/tidspbridge/dynload/tramp.c   |4 ++--
 drivers/staging/tidspbridge/pmgr/cmm.c|7 ---
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c 
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 08a2f5f..ae1f394 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -404,7 +404,7 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
pr_err(%s: Illegal SM base\n, __func__);
status = -EPERM;
} else
-   *((volatile u32 *)dw_sync_addr) = 0x;
+   __raw_writel(0x, dw_sync_addr);
 
if (DSP_SUCCEEDED(status)) {
resources = dev_context-resources;
@@ -584,7 +584,7 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
dev_dbg(bridge, Waiting for Sync @ 0x%x\n, dw_sync_addr);
dev_dbg(bridge, DSP c_int00 Address =  0x%x\n, dsp_addr);
if (dsp_debug)
-   while (*((volatile u16 *)dw_sync_addr))
+   while (__raw_readw(dw_sync_addr))
;;
 
/* Wait for DSP to clear word in shared memory */
@@ -602,7 +602,7 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
/* Write the synchronization bit to indicate the
 * completion of OPP table update to DSP
 */
-   *((volatile u32 *)dw_sync_addr) = 0XCAFECAFE;
+   __raw_writel(0XCAFECAFE, dw_sync_addr);
 
/* update board state */
dev_context-dw_brd_state = BRD_RUNNING;
@@ -1852,7 +1852,7 @@ bool wait_for_start(struct bridge_dev_context 
*dev_context, u32 dw_sync_addr)
u16 timeout = TIHELEN_ACKTIMEOUT;
 
/*  Wait for response from board */
-   while (*((volatile u16 *)dw_sync_addr)  --timeout)
+   while (__raw_readw(dw_sync_addr)  --timeout)
udelay(10);
 
/*  If timed out: return false */
diff --git a/drivers/staging/tidspbridge/dynload/tramp.c 
b/drivers/staging/tidspbridge/dynload/tramp.c
index 81314d2..60d22ea 100644
--- a/drivers/staging/tidspbridge/dynload/tramp.c
+++ b/drivers/staging/tidspbridge/dynload/tramp.c
@@ -86,8 +86,8 @@ static u8 priv_h2a(u8 value)
 static void priv_tramp_sym_gen_name(u32 value, char *dst)
 {
u32 i;
-   volatile char *prefix = TRAMP_SYM_PREFIX;
-   volatile char *dst_local = dst;
+   char *prefix = TRAMP_SYM_PREFIX;
+   char *dst_local = dst;
u8 tmp;
 
/*  Clear out the destination, including the ending NULL */
diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c 
b/drivers/staging/tidspbridge/pmgr/cmm.c
index 874ed64..b7cba1b 100644
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -1008,6 +1008,7 @@ void *cmm_xlator_alloc_buf(struct cmm_xlatorobject 
*xlator, void *va_buf,
 {
struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
void *pbuf = NULL;
+   void *tmp_va_buff;
struct cmm_attrs attrs;
 
DBC_REQUIRE(refs  0);
@@ -1019,16 +1020,16 @@ void *cmm_xlator_alloc_buf(struct cmm_xlatorobject 
*xlator, void *va_buf,
 
if (xlator_obj) {
attrs.ul_seg_id = xlator_obj-ul_seg_id;
-   *(volatile u32 *)va_buf = 0;
+   __raw_writel(0, va_buf);
/* Alloc SM */
pbuf =
cmm_calloc_buf(xlator_obj-hcmm_mgr, pa_size, attrs, NULL);
if (pbuf) {
/* convert to translator(node/strm) process Virtual
 * address */
-   *(volatile u32 **)va_buf =
-   (u32 *) cmm_xlator_translate(xlator,
+tmp_va_buff = cmm_xlator_translate(xlator,
 pbuf, CMM_PA2VA);
+   __raw_writel((u32)tmp_va_buff, va_buf);
}
}
return pbuf;
-- 
1.5.4.5

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


[PATCH 2/5] staging:ti dspbridge: remove unnecessary check for NULL pointer in cmm.c

2010-07-28 Thread Ernesto Ramos
Remove unnecessary check for NULL pointer in cmm.c.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/pmgr/cmm.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c 
b/drivers/staging/tidspbridge/pmgr/cmm.c
index 8e808d9..874ed64 100644
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -992,16 +992,12 @@ int cmm_xlator_create(struct cmm_xlatorobject **xlator,
 int cmm_xlator_delete(struct cmm_xlatorobject *xlator, bool force)
 {
struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
-   int status = 0;
 
DBC_REQUIRE(refs  0);
 
-   if (xlator_obj)
-   kfree(xlator_obj);
-   else
-   status = -EFAULT;
+   kfree(xlator_obj);
 
-   return status;
+   return 0;
 }
 
 /*
-- 
1.5.4.5

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


[PATCH 3/5] staging:ti dspbridge: remove function delete_strm_mgr

2010-07-28 Thread Ernesto Ramos
Remove function delete_strm_mgr in strm.c and
use kfree instead.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/rmgr/strm.c |   16 ++--
 1 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/tidspbridge/rmgr/strm.c 
b/drivers/staging/tidspbridge/rmgr/strm.c
index 73888e3..6c184c6 100644
--- a/drivers/staging/tidspbridge/rmgr/strm.c
+++ b/drivers/staging/tidspbridge/rmgr/strm.c
@@ -90,7 +90,6 @@ static u32 refs;  /* module reference count */
 
 /*  --- Function Prototypes */
 static int delete_strm(struct strm_object *stream_obj);
-static void delete_strm_mgr(struct strm_mgr *strm_mgr_obj);
 
 /*
  *   strm_allocate_buffer 
@@ -232,7 +231,7 @@ int strm_create(struct strm_mgr **strm_man,
if (DSP_SUCCEEDED(status))
*strm_man = strm_mgr_obj;
else
-   delete_strm_mgr(strm_mgr_obj);
+   kfree(strm_mgr_obj);
 
DBC_ENSURE((DSP_SUCCEEDED(status)  *strm_man) ||
(DSP_FAILED(status)  *strm_man == NULL));
@@ -250,7 +249,7 @@ void strm_delete(struct strm_mgr *strm_mgr_obj)
DBC_REQUIRE(refs  0);
DBC_REQUIRE(strm_mgr_obj);
 
-   delete_strm_mgr(strm_mgr_obj);
+   kfree(strm_mgr_obj);
 }
 
 /*
@@ -859,14 +858,3 @@ static int delete_strm(struct strm_object *stream_obj)
}
return status;
 }
-
-/*
- *   delete_strm_mgr 
- *  Purpose:
- *  Frees stream manager.
- */
-static void delete_strm_mgr(struct strm_mgr *strm_mgr_obj)
-{
-   if (strm_mgr_obj)
-   kfree(strm_mgr_obj);
-}
-- 
1.5.4.5

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


[PATCH 5/5] staging:ti dspbridge: replace simple_strtoul by strict_strtoul

2010-07-28 Thread Ernesto Ramos
Replace simple_strtoul by strict_strtoul in atoi function.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/rmgr/dbdcd.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/tidspbridge/rmgr/dbdcd.c 
b/drivers/staging/tidspbridge/rmgr/dbdcd.c
index cceceb9..b96aea7 100644
--- a/drivers/staging/tidspbridge/rmgr/dbdcd.c
+++ b/drivers/staging/tidspbridge/rmgr/dbdcd.c
@@ -1012,6 +1012,8 @@ static s32 atoi(char *psz_buf)
 {
char *pch = psz_buf;
s32 base = 0;
+   unsigned long res;
+   int ret_val;
 
while (isspace(*pch))
pch++;
@@ -1023,7 +1025,9 @@ static s32 atoi(char *psz_buf)
base = 16;
}
 
-   return simple_strtoul(pch, NULL, base);
+   ret_val = strict_strtoul(pch, base, res);
+
+   return ret_val ? : res;
 }
 
 /*
-- 
1.5.4.5

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


RE: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER

2010-07-28 Thread Sin, David
 -Original Message-
 From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] 
 Sent: Wednesday, July 28, 2010 5:00 AM
 To: linux-arm-ker...@lists.infradead.org
 Cc: Hiremath, Vaibhav; Sin, David; 
 linux-omap@vger.kernel.org; Tony Lindgren; Russell King; Ohad 
 Ben-Cohen; Kanigeri, Hari; Shilimkar, Santosh; Molnar, Lajos
 Subject: Re: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER
 
 
 On Tuesday 27 July 2010 21:53:28 Hiremath, Vaibhav wrote:
  On Wednesday 28 July 2010 00:35:00 Sin, David wrote:
   On Tuesday 27 July 2010 01:38:00 Hiremath, Vaibhav wrote:
On Saturday 24 July 2010 04:52:00 Sin, David wrote:
 
 [snip]
 
[Hiremath, Vaibhav] If I understand correctly, DMM stands for
dynamic memory manager. Is it something which can only be
used with Video devices? Any specific reason why this is part
of drivers/media/video/ directory,
  
   [dhs] Any device can use TILER memory, but there is a big 
 advantage,
   performance-wise, for 2-Dimensional macro block based 
 buffers.  This HW
   is intended for image/video hardware accelerators (e.g. 
 OMAP4 IVA-HD). 
   Plus there's the added advantage of doing zero-copy flips 
 and rotations
   for the OMAP display and image sub-systems.
  
  [Hiremath, Vaibhav] When you mention Tiler memory, you 
 meant Tiler Virtual
  memory which is independent of physical memory. Driver 
 requesting/using
  Tiler is responsible for allocating physical memory. Is 
 that understanding
  correct?

[dhs] Yes this is correct.  I'm referring to the 33 bit 4 GB TILER virtual 
memory.

  
  If yes, then feature wise it is same as VRFB in OMAP3, 
 where it provides
  virtual address space and driver requesting VRFB is responsible for
  physical memory allocation. There could be additional features,
  enhancement and stuff but zero-copy rotation for DSS, then 
 its same as
  VRFB.
  
  Don't you think is would be very difficult to use for 
 drivers with such
  proposals, I can comment from DSS point of view,
  
  In case of OMAP4 80% of code is being re-used from OMAP3 
 (located under
  drivers/video/omap2/), which is currently supported hardware
  rotation/mirroring and hardly tied to VRFB API's.
  
  Now with this driver we have to do something,
  
  cpu_is_omap34xx()
  VRFB
  else if cpu_is_omap44xx()
  Tiler
  
  I am not sure about further OMAP series of devices, where 
 we might have
  something else with DSS IP reuse (along with software). And 
 I believe
  Tiler is not part of DSS at all. Again if some other 
 devices are using
  Tiler API's it would become more difficult to re-use the 
 code when same IP
  is being used in multiple SoC's.
  
  Does it make sense to you to have registration based 
 mechanism (function
  pointer) where you register your hardware 
 capabilities/API's, driver don't
  have to dependent on underneath hardware block. Ofcource if 
 driver intend
  to use some specific/custom feature supported by some 
 hardware block then
  he has to call that API under cpu_is_
 
 I think I agree with it. The tiler provides dynamic views on 
 arbitrary 
 physical memory. Ideally it shouldn't be tied to the 
 media/video subsystem 
 (obviously it should still provide an interface for V4L drivers).
 
 It's getting a bit hard to comment on the proposal, as 
 there's no public 
 documentation I'm aware of beside the Documentation/arm/TILER 
 file in the 
 patch set, and that information is far too concise and vague.
 
 -- 
 Regards,
 
 Laurent Pinchart
 

[dhs] I understand what you're stating here, conceptually, but I'm missing some 
details.  Do you mean that there needs to be a generic layer between a given 
video memory allocator and V4L? and that set of APIs should point to specific 
functions based on availability (e.g. VRFB, TILER, future TILER, other IP, etc)?

Laurent:  The TRM for DMM-TILER should be publicly available already, but for 
some reason, I'm not able to see the link.  I will work on this...  --
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 04/10] staging:ti dspbridge: remove DSP_SUCCEEDED macro from services

2010-07-28 Thread Ernesto Ramos
Since status succeeded is now 0 macro DSP_SUCCEEDED
is not necessary anymore.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/services/cfg.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/tidspbridge/services/cfg.c 
b/drivers/staging/tidspbridge/services/cfg.c
index 4ab3cd7..c3f33f6 100644
--- a/drivers/staging/tidspbridge/services/cfg.c
+++ b/drivers/staging/tidspbridge/services/cfg.c
@@ -62,7 +62,7 @@ int cfg_get_auto_start(struct cfg_devnode *dev_node_obj,
status = -EFAULT;
if (!auto_start || !drv_datap)
status = -EFAULT;
-   if (DSP_SUCCEEDED(status))
+   if (!status)
*auto_start = (drv_datap-base_img) ? 1 : 0;
 
DBC_ENSURE((status == 0 
@@ -93,7 +93,7 @@ int cfg_get_dev_object(struct cfg_devnode *dev_node_obj,
status = -EFAULT;
 
dw_buf_size = sizeof(value);
-   if (DSP_SUCCEEDED(status)) {
+   if (!status) {
 
/* check the device string and then store dev object */
if (!
@@ -127,7 +127,7 @@ int cfg_get_exec_file(struct cfg_devnode *dev_node_obj, u32 
buf_size,
if (strlen(drv_datap-base_img)  buf_size)
status = -EINVAL;
 
-   if (DSP_SUCCEEDED(status)  drv_datap-base_img)
+   if (!status  drv_datap-base_img)
strcpy(str_exec_file, drv_datap-base_img);
 
if (DSP_FAILED(status))
@@ -178,7 +178,7 @@ int cfg_get_object(u32 *value, u8 dw_type)
*value = 0;
pr_err(%s: Failed, status 0x%x\n, __func__, status);
}
-   DBC_ENSURE((DSP_SUCCEEDED(status)  *value != 0) ||
+   DBC_ENSURE((!status  *value != 0) ||
   (DSP_FAILED(status)  *value == 0));
return status;
 }
@@ -211,7 +211,7 @@ int cfg_set_dev_object(struct cfg_devnode *dev_node_obj, 
u32 value)
if (!dev_node_obj)
status = -EFAULT;
 
-   if (DSP_SUCCEEDED(status)) {
+   if (!status) {
/* Store the Bridge device object in the Registry */
 
if (!(strcmp((char *)dev_node_obj, TIOMAP1510)))
-- 
1.5.4.5

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


[PATCH 00/10] staging:ti dspbridge: Remove DSP_FAILED and DSP_SUCCEEDED macros

2010-07-28 Thread Ernesto Ramos
This series of patches is targetted to remove macros DSP_FAILED
and DSP_SUCCEEDED since bridge driver currently uses standard kernel
error codes.

Ernesto Ramos (10):
  staging:ti dspbridge: remove DSP_SUCCEEDED macro from core
  staging:ti dspbridge: remove DSP_SUCCEEDED macro from pmgr
  staging:ti dspbridge: remove DSP_SUCCEEDED macro from rmgr
  staging:ti dspbridge: remove DSP_SUCCEEDED macro from services
  staging:ti dspbridge: remove DSP_SUCCEEDED macro definition
  staging:ti dspbridge: remove DSP_FAILED macro from core
  staging:ti dspbridge: remove DSP_FAILED macro from pmgr
  staging:ti dspbridge: remove DSP_FAILED macro from rmgr
  staging:ti dspbridge: remove DSP_FAILED macro from services
  staging:ti dspbridge: remove DSP_FAILED macro definition

 drivers/staging/tidspbridge/core/chnl_sm.c |   42 ++--
 drivers/staging/tidspbridge/core/dsp-clock.c   |4 +-
 drivers/staging/tidspbridge/core/io_sm.c   |  111 +-
 drivers/staging/tidspbridge/core/msg_sm.c  |   26 ++--
 drivers/staging/tidspbridge/core/tiomap3430.c  |   61 +++---
 drivers/staging/tidspbridge/core/tiomap3430_pwr.c  |8 +-
 drivers/staging/tidspbridge/core/tiomap_io.c   |   41 ++--
 .../staging/tidspbridge/include/dspbridge/dbdefs.h |4 -
 drivers/staging/tidspbridge/pmgr/chnl.c|   10 +-
 drivers/staging/tidspbridge/pmgr/cmm.c |  137 ++---
 drivers/staging/tidspbridge/pmgr/cod.c |   18 +-
 drivers/staging/tidspbridge/pmgr/dbll.c|   32 ++--
 drivers/staging/tidspbridge/pmgr/dev.c |   79 +++
 drivers/staging/tidspbridge/pmgr/dmm.c |   12 +-
 drivers/staging/tidspbridge/pmgr/dspapi.c  |   82 
 drivers/staging/tidspbridge/pmgr/io.c  |4 +-
 drivers/staging/tidspbridge/pmgr/msg.c |2 +-
 drivers/staging/tidspbridge/rmgr/dbdcd.c   |   48 ++--
 drivers/staging/tidspbridge/rmgr/disp.c|   62 +++---
 drivers/staging/tidspbridge/rmgr/drv.c |   39 ++--
 drivers/staging/tidspbridge/rmgr/drv_interface.c   |   10 +-
 drivers/staging/tidspbridge/rmgr/dspdrv.c  |   16 +-
 drivers/staging/tidspbridge/rmgr/mgr.c |   32 ++--
 drivers/staging/tidspbridge/rmgr/nldr.c|  106 +-
 drivers/staging/tidspbridge/rmgr/node.c|  224 ++--
 drivers/staging/tidspbridge/rmgr/proc.c|  137 ++--
 drivers/staging/tidspbridge/rmgr/pwr.c |   26 +--
 drivers/staging/tidspbridge/rmgr/rmm.c |   12 +-
 drivers/staging/tidspbridge/rmgr/strm.c|   75 
 drivers/staging/tidspbridge/services/cfg.c |   21 +-
 30 files changed, 710 insertions(+), 771 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 09/10] staging:ti dspbridge: remove DSP_FAILED macro from services

2010-07-28 Thread Ernesto Ramos
Since status succeeded is 0, DSP_FAILED macro
is not necessary anymore.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/services/cfg.c |   13 ++---
 1 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/tidspbridge/services/cfg.c 
b/drivers/staging/tidspbridge/services/cfg.c
index c3f33f6..a7af74f 100644
--- a/drivers/staging/tidspbridge/services/cfg.c
+++ b/drivers/staging/tidspbridge/services/cfg.c
@@ -102,7 +102,7 @@ int cfg_get_dev_object(struct cfg_devnode *dev_node_obj,
  TIOMAP1510)))
*value = (u32)drv_datap-dev_object;
}
-   if (DSP_FAILED(status))
+   if (status)
pr_err(%s: Failed, status 0x%x\n, __func__, status);
return status;
 }
@@ -130,7 +130,7 @@ int cfg_get_exec_file(struct cfg_devnode *dev_node_obj, u32 
buf_size,
if (!status  drv_datap-base_img)
strcpy(str_exec_file, drv_datap-base_img);
 
-   if (DSP_FAILED(status))
+   if (status)
pr_err(%s: Failed, status 0x%x\n, __func__, status);
DBC_ENSURE(((status == 0) 
(strlen(str_exec_file) = buf_size))
@@ -174,12 +174,11 @@ int cfg_get_object(u32 *value, u8 dw_type)
default:
break;
}
-   if (DSP_FAILED(status)) {
+   if (status) {
*value = 0;
pr_err(%s: Failed, status 0x%x\n, __func__, status);
}
-   DBC_ENSURE((!status  *value != 0) ||
-  (DSP_FAILED(status)  *value == 0));
+   DBC_ENSURE((!status  *value != 0) || (status  *value == 0));
return status;
 }
 
@@ -217,7 +216,7 @@ int cfg_set_dev_object(struct cfg_devnode *dev_node_obj, 
u32 value)
if (!(strcmp((char *)dev_node_obj, TIOMAP1510)))
drv_datap-dev_object = (void *) value;
}
-   if (DSP_FAILED(status))
+   if (status)
pr_err(%s: Failed, status 0x%x\n, __func__, status);
 
return status;
@@ -248,7 +247,7 @@ int cfg_set_object(u32 value, u8 dw_type)
default:
break;
}
-   if (DSP_FAILED(status))
+   if (status)
pr_err(%s: Failed, status 0x%x\n, __func__, status);
return status;
 }
-- 
1.5.4.5

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


[PATCH 06/10] staging:ti dspbridge: remove DSP_FAILED macro from core

2010-07-28 Thread Ernesto Ramos
Since status succeeded is 0, DSP_FAILED macro
is not necessary anymore.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/core/chnl_sm.c|   20 +++---
 drivers/staging/tidspbridge/core/io_sm.c  |   64 ++--
 drivers/staging/tidspbridge/core/msg_sm.c |4 +-
 drivers/staging/tidspbridge/core/tiomap3430.c |4 +-
 drivers/staging/tidspbridge/core/tiomap3430_pwr.c |2 +-
 5 files changed, 47 insertions(+), 47 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/chnl_sm.c 
b/drivers/staging/tidspbridge/core/chnl_sm.c
index 1b23141..bee2b23 100644
--- a/drivers/staging/tidspbridge/core/chnl_sm.c
+++ b/drivers/staging/tidspbridge/core/chnl_sm.c
@@ -135,7 +135,7 @@ int bridge_chnl_add_io_req(struct chnl_object *chnl_obj, 
void *host_buf,
if (!dev_ctxt)
status = -EFAULT;
 
-   if (DSP_FAILED(status))
+   if (status)
goto func_end;
 
if (pchnl-chnl_type == CHNL_PCPY  pchnl-chnl_id  1  host_buf) {
@@ -266,7 +266,7 @@ int bridge_chnl_cancel_io(struct chnl_object *chnl_obj)
} else {
status = -EFAULT;
}
-   if (DSP_FAILED(status))
+   if (status)
goto func_end;
 
/*  Mark this channel as cancelled, to prevent further IORequests or
@@ -372,7 +372,7 @@ func_cont:
kfree(pchnl);
pchnl = NULL;
}
-   DBC_ENSURE(DSP_FAILED(status) || !pchnl);
+   DBC_ENSURE(status || !pchnl);
return status;
 }
 
@@ -428,7 +428,7 @@ int bridge_chnl_create(struct chnl_mgr **channel_mgr,
status = -ENOMEM;
}
 
-   if (DSP_FAILED(status)) {
+   if (status) {
bridge_chnl_destroy(chnl_mgr_obj);
*channel_mgr = NULL;
} else {
@@ -456,7 +456,7 @@ int bridge_chnl_destroy(struct chnl_mgr *hchnl_mgr)
status =
bridge_chnl_close(chnl_mgr_obj-ap_channel
  [chnl_id]);
-   if (DSP_FAILED(status))
+   if (status)
dev_dbg(bridge, %s: Error status 0x%x\n,
__func__, status);
}
@@ -509,7 +509,7 @@ int bridge_chnl_flush_io(struct chnl_object *chnl_obj, u32 
timeout)
while (!LST_IS_EMPTY(pchnl-pio_requests)  !status) {
status = bridge_chnl_get_ioc(chnl_obj,
timeout, chnl_ioc_obj);
-   if (DSP_FAILED(status))
+   if (status)
continue;
 
if (chnl_ioc_obj.status  CHNL_IOCSTATTIMEOUT)
@@ -522,7 +522,7 @@ int bridge_chnl_flush_io(struct chnl_object *chnl_obj, u32 
timeout)
pchnl-dw_state = ~CHNL_STATECANCEL;
}
}
-   DBC_ENSURE(DSP_FAILED(status) || LST_IS_EMPTY(pchnl-pio_requests));
+   DBC_ENSURE(status || LST_IS_EMPTY(pchnl-pio_requests));
return status;
 }
 
@@ -592,7 +592,7 @@ int bridge_chnl_get_ioc(struct chnl_object *chnl_obj, u32 
timeout,
if (!dev_ctxt)
status = -EFAULT;
 
-   if (DSP_FAILED(status))
+   if (status)
goto func_end;
 
ioc.status = CHNL_IOCSTATCOMPLETE;
@@ -806,7 +806,7 @@ int bridge_chnl_open(struct chnl_object **chnl,
}
}
}
-   if (DSP_FAILED(status))
+   if (status)
goto func_end;
 
DBC_ASSERT(ch_id  chnl_mgr_obj-max_channels);
@@ -860,7 +860,7 @@ int bridge_chnl_open(struct chnl_object **chnl,
}
}
 
-   if (DSP_FAILED(status)) {
+   if (status) {
/* Free memory */
if (pchnl-pio_completions) {
free_chirp_list(pchnl-pio_completions);
diff --git a/drivers/staging/tidspbridge/core/io_sm.c 
b/drivers/staging/tidspbridge/core/io_sm.c
index 1d433a9..02c660d 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -242,7 +242,7 @@ int bridge_io_create(struct io_mgr **io_man,
status = -EIO;
}
 func_end:
-   if (DSP_FAILED(status)) {
+   if (status) {
/* Cleanup */
bridge_io_destroy(pio_mgr);
if (io_man)
@@ -357,13 +357,13 @@ int bridge_io_on_loaded(struct io_mgr *hio_mgr)
/* Get start and length of channel part of shared memory */
status = cod_get_sym_value(cod_man, CHNL_SHARED_BUFFER_BASE_SYM,
   ul_shm_base);
-   if (DSP_FAILED(status)) {
+   if (status) {
status = -EFAULT;
goto func_end;
}
status = cod_get_sym_value(cod_man, CHNL_SHARED_BUFFER_LIMIT_SYM,
   

[PATCH 01/10] staging:ti dspbridge: remove DSP_SUCCEEDED macro from core

2010-07-28 Thread Ernesto Ramos
Since status succeeded is now 0 macro DSP_SUCCEEDED
is not necessary anymore.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/core/chnl_sm.c|   22 
 drivers/staging/tidspbridge/core/dsp-clock.c  |4 +-
 drivers/staging/tidspbridge/core/io_sm.c  |   47 -
 drivers/staging/tidspbridge/core/msg_sm.c |   22 
 drivers/staging/tidspbridge/core/tiomap3430.c |   57 +
 drivers/staging/tidspbridge/core/tiomap3430_pwr.c |6 +-
 drivers/staging/tidspbridge/core/tiomap_io.c  |   41 +++
 7 files changed, 91 insertions(+), 108 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/chnl_sm.c 
b/drivers/staging/tidspbridge/core/chnl_sm.c
index 69c4784..1b23141 100644
--- a/drivers/staging/tidspbridge/core/chnl_sm.c
+++ b/drivers/staging/tidspbridge/core/chnl_sm.c
@@ -170,7 +170,7 @@ func_cont:
omap_mbox_disable_irq(dev_ctxt-mbox, IRQ_RX);
if (pchnl-chnl_type == CHNL_PCPY) {
/* This is a processor-copy channel. */
-   if (DSP_SUCCEEDED(status)  CHNL_IS_OUTPUT(pchnl-chnl_mode)) {
+   if (!status  CHNL_IS_OUTPUT(pchnl-chnl_mode)) {
/* Check buffer size on output channels for fit. */
if (byte_size 
io_buf_size(pchnl-chnl_mgr_obj-hio_mgr))
@@ -178,7 +178,7 @@ func_cont:
 
}
}
-   if (DSP_SUCCEEDED(status)) {
+   if (!status) {
/* Get a free chirp: */
chnl_packet_obj =
(struct chnl_irp *)lst_get_head(pchnl-free_packets_list);
@@ -186,7 +186,7 @@ func_cont:
status = -EIO;
 
}
-   if (DSP_SUCCEEDED(status)) {
+   if (!status) {
/* Enqueue the chirp on the chnl's IORequest queue: */
chnl_packet_obj-host_user_buf = chnl_packet_obj-host_sys_buf =
host_buf;
@@ -330,7 +330,7 @@ int bridge_chnl_close(struct chnl_object *chnl_obj)
status = bridge_chnl_cancel_io(chnl_obj);
}
 func_cont:
-   if (DSP_SUCCEEDED(status)) {
+   if (!status) {
/* Assert I/O on this channel is now cancelled: Protects
 * from io_dpc. */
DBC_ASSERT((pchnl-dw_state  CHNL_STATECANCEL));
@@ -420,8 +420,7 @@ int bridge_chnl_create(struct chnl_mgr **channel_mgr,
chnl_mgr_obj-dw_output_mask = 0;
chnl_mgr_obj-dw_last_output = 0;
chnl_mgr_obj-hdev_obj = hdev_obj;
-   if (DSP_SUCCEEDED(status))
-   spin_lock_init(chnl_mgr_obj-chnl_mgr_lock);
+   spin_lock_init(chnl_mgr_obj-chnl_mgr_lock);
} else {
status = -ENOMEM;
}
@@ -499,7 +498,7 @@ int bridge_chnl_flush_io(struct chnl_object *chnl_obj, u32 
timeout)
} else {
status = -EFAULT;
}
-   if (DSP_SUCCEEDED(status)) {
+   if (!status) {
/* Note: Currently, if another thread continues to add IO
 * requests to this channel, this function will continue to
 * flush all such queued IO requests. */
@@ -507,8 +506,7 @@ int bridge_chnl_flush_io(struct chnl_object *chnl_obj, u32 
timeout)
 (pchnl-chnl_type == CHNL_PCPY)) {
/* Wait for IO completions, up to the specified
 * timeout: */
-   while (!LST_IS_EMPTY(pchnl-pio_requests) 
-  DSP_SUCCEEDED(status)) {
+   while (!LST_IS_EMPTY(pchnl-pio_requests)  !status) {
status = bridge_chnl_get_ioc(chnl_obj,
timeout, chnl_ioc_obj);
if (DSP_FAILED(status))
@@ -833,7 +831,7 @@ int bridge_chnl_open(struct chnl_object **chnl,
else
status = -ENOMEM;
 
-   if (DSP_SUCCEEDED(status)) {
+   if (!status) {
pchnl-ntfy_obj = kmalloc(sizeof(struct ntfy_object),
GFP_KERNEL);
if (pchnl-ntfy_obj)
@@ -842,7 +840,7 @@ int bridge_chnl_open(struct chnl_object **chnl,
status = -ENOMEM;
}
 
-   if (DSP_SUCCEEDED(status)) {
+   if (!status) {
if (pchnl-pio_completions  pchnl-pio_requests 
pchnl-free_packets_list) {
/* Initialize CHNL object fields: */
@@ -897,7 +895,7 @@ int bridge_chnl_open(struct chnl_object **chnl,
*chnl = pchnl;
}
 func_end:
-   DBC_ENSURE((DSP_SUCCEEDED(status)  pchnl) || (*chnl == NULL));
+   DBC_ENSURE((!status  pchnl) || (*chnl == NULL));
return status;
 }
 
diff --git 

[PATCH 08/10] staging:ti dspbridge: remove DSP_FAILED macro from rmgr

2010-07-28 Thread Ernesto Ramos
Since status succeeded is 0, DSP_FAILED macro
is not necessary anymore.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/rmgr/dbdcd.c |   24 
 drivers/staging/tidspbridge/rmgr/disp.c  |   28 
 drivers/staging/tidspbridge/rmgr/drv.c   |8 +-
 drivers/staging/tidspbridge/rmgr/drv_interface.c |8 +-
 drivers/staging/tidspbridge/rmgr/dspdrv.c|8 +-
 drivers/staging/tidspbridge/rmgr/mgr.c   |   12 ++--
 drivers/staging/tidspbridge/rmgr/nldr.c  |   15 ++--
 drivers/staging/tidspbridge/rmgr/node.c  |   75 +++---
 drivers/staging/tidspbridge/rmgr/proc.c  |   42 ++--
 drivers/staging/tidspbridge/rmgr/pwr.c   |8 +-
 drivers/staging/tidspbridge/rmgr/rmm.c   |4 +-
 drivers/staging/tidspbridge/rmgr/strm.c  |   29 
 12 files changed, 129 insertions(+), 132 deletions(-)

diff --git a/drivers/staging/tidspbridge/rmgr/dbdcd.c 
b/drivers/staging/tidspbridge/rmgr/dbdcd.c
index 12d2d41..f71e860 100644
--- a/drivers/staging/tidspbridge/rmgr/dbdcd.c
+++ b/drivers/staging/tidspbridge/rmgr/dbdcd.c
@@ -135,7 +135,7 @@ int dcd_create_manager(char *sz_zl_dll_name,
DBC_REQUIRE(dcd_mgr);
 
status = cod_create(cod_mgr, sz_zl_dll_name, NULL);
-   if (DSP_FAILED(status))
+   if (status)
goto func_end;
 
/* Create a DCD object. */
@@ -464,7 +464,7 @@ int dcd_get_object_def(struct dcd_manager *hdcd_mgr,
/* Open COFF file. */
status = cod_open(dcd_mgr_obj-cod_mgr, dcd_key-path,
COD_NOLOAD, lib);
-   if (DSP_FAILED(status)) {
+   if (status) {
status = -EACCES;
goto func_end;
}
@@ -480,7 +480,7 @@ int dcd_get_object_def(struct dcd_manager *hdcd_mgr,
 
/* Get section information. */
status = cod_get_section(lib, sz_sect_name, ul_addr, ul_len);
-   if (DSP_FAILED(status)) {
+   if (status) {
status = -EACCES;
goto func_end;
}
@@ -513,7 +513,7 @@ int dcd_get_object_def(struct dcd_manager *hdcd_mgr,
/* Parse the content of the COFF buffer. */
status =
get_attrs_from_buf(psz_coff_buf, ul_len, obj_type, obj_def);
-   if (DSP_FAILED(status))
+   if (status)
status = -EACCES;
} else {
status = -EACCES;
@@ -557,14 +557,14 @@ int dcd_get_objects(struct dcd_manager *hdcd_mgr,
 
/* Open DSP coff file, don't load symbols. */
status = cod_open(dcd_mgr_obj-cod_mgr, sz_coff_path, COD_NOLOAD, lib);
-   if (DSP_FAILED(status)) {
+   if (status) {
status = -EACCES;
goto func_cont;
}
 
/* Get DCD_RESIGER_SECTION section information. */
status = cod_get_section(lib, DCD_REGISTER_SECTION, ul_addr, ul_len);
-   if (DSP_FAILED(status) || !(ul_len  0)) {
+   if (status || !(ul_len  0)) {
status = -EACCES;
goto func_cont;
}
@@ -617,7 +617,7 @@ int dcd_get_objects(struct dcd_manager *hdcd_mgr,
 */
status =
register_fxn(dsp_uuid_obj, object_type, handle);
-   if (DSP_FAILED(status)) {
+   if (status) {
/* if error occurs, break from while loop. */
break;
}
@@ -729,7 +729,7 @@ int dcd_get_library_name(struct dcd_manager *hdcd_mgr,
status = -ENOKEY;
 
/* If can't find, phases might be registered as generic LIBRARYTYPE */
-   if (DSP_FAILED(status)  phase != NLDR_NOPHASE) {
+   if (status  phase != NLDR_NOPHASE) {
if (phase_split)
*phase_split = false;
 
@@ -872,7 +872,7 @@ int dcd_register_object(struct dsp_uuid *uuid_obj,
status = -EPERM;
}
 
-   if (DSP_FAILED(status))
+   if (status)
goto func_end;
 
/*
@@ -1449,14 +1449,14 @@ static int get_dep_lib_info(struct dcd_manager 
*hdcd_mgr,
/* Get dependent library section information. */
status = cod_get_section(lib, DEPLIBSECT, ul_addr, ul_len);
 
-   if (DSP_FAILED(status)) {
+   if (status) {
/* Ok, no dependent libraries */
ul_len = 0;
status = 0;
}
}
 
-   if (DSP_FAILED(status) || !(ul_len  0))
+   if (status || !(ul_len  0))
goto func_cont;
 
/* Allocate zeroed buffer. */
@@ -1466,7 +1466,7 @@ static int get_dep_lib_info(struct dcd_manager *hdcd_mgr,
 
/* Read section contents. */
status = cod_read_section(lib, DEPLIBSECT, 

[PATCH 05/10] staging:ti dspbridge: remove DSP_SUCCEEDED macro definition

2010-07-28 Thread Ernesto Ramos
Since status succeeded is now 0 macro DSP_SUCCEEDED
is not necessary anymore. This patch removes this
define.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 .../staging/tidspbridge/include/dspbridge/dbdefs.h |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h 
b/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h
index 397e2cb..2ccbfe1 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h
@@ -91,8 +91,7 @@
 #define DSPWORD   unsigned char
 #define DSPWORDSIZE sizeof(DSPWORD)
 
-/* Success  Failure macros */
-#define DSP_SUCCEEDED(status)  likely((s32)(status) = 0)
+/* Failure macro */
 #define DSP_FAILED(status) unlikely((s32)(status)  0)
 
 /* Power control enumerations */
-- 
1.5.4.5

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


[PATCH 07/10] staging:ti dspbridge: remove DSP_FAILED macro from pmgr

2010-07-28 Thread Ernesto Ramos
Since status succeeded is 0, DSP_FAILED macro
is not necessary anymore.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/pmgr/chnl.c   |2 +-
 drivers/staging/tidspbridge/pmgr/cmm.c|2 +-
 drivers/staging/tidspbridge/pmgr/cod.c|8 +++---
 drivers/staging/tidspbridge/pmgr/dbll.c   |   12 +-
 drivers/staging/tidspbridge/pmgr/dev.c|   24 ++
 drivers/staging/tidspbridge/pmgr/dmm.c|2 +-
 drivers/staging/tidspbridge/pmgr/dspapi.c |   30 ++--
 7 files changed, 39 insertions(+), 41 deletions(-)

diff --git a/drivers/staging/tidspbridge/pmgr/chnl.c 
b/drivers/staging/tidspbridge/pmgr/chnl.c
index 626a993..90317b5 100644
--- a/drivers/staging/tidspbridge/pmgr/chnl.c
+++ b/drivers/staging/tidspbridge/pmgr/chnl.c
@@ -100,7 +100,7 @@ int chnl_create(struct chnl_mgr **channel_mgr,
}
}
 
-   DBC_ENSURE(DSP_FAILED(status) || chnl_mgr_obj);
+   DBC_ENSURE(status || chnl_mgr_obj);
 
return status;
 }
diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c 
b/drivers/staging/tidspbridge/pmgr/cmm.c
index 2f974c5..ce3dc88 100644
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -1042,7 +1042,7 @@ int cmm_xlator_free_buf(struct cmm_xlatorobject *xlator, 
void *buf_va)
if (buf_pa) {
status = cmm_free_buf(xlator_obj-hcmm_mgr, buf_pa,
  xlator_obj-ul_seg_id);
-   if (DSP_FAILED(status)) {
+   if (status) {
/* Uh oh, this shouldn't happen. Descriptor
 * gone! */
DBC_ASSERT(false);  /* CMM is leaking mem */
diff --git a/drivers/staging/tidspbridge/pmgr/cod.c 
b/drivers/staging/tidspbridge/pmgr/cod.c
index 9f902de..52989ab 100644
--- a/drivers/staging/tidspbridge/pmgr/cod.c
+++ b/drivers/staging/tidspbridge/pmgr/cod.c
@@ -257,7 +257,7 @@ int cod_create(struct cod_manager **mgr, char *str_zl_file,
 
status = mgr_new-fxns.create_fxn(mgr_new-target, zl_attrs);
 
-   if (DSP_FAILED(status)) {
+   if (status) {
cod_delete(mgr_new);
return -ESPIPE;
}
@@ -529,7 +529,7 @@ int cod_load_base(struct cod_manager *cod_mgr_obj, u32 
num_argc, char *args[],
status = cod_mgr_obj-fxns.load_fxn(cod_mgr_obj-base_lib, flags,
new_attrs,
cod_mgr_obj-ul_entry);
-   if (DSP_FAILED(status))
+   if (status)
cod_mgr_obj-fxns.close_fxn(cod_mgr_obj-base_lib);
 
if (!status)
@@ -570,7 +570,7 @@ int cod_open(struct cod_manager *hmgr, char *sz_coff_path,
*lib_obj = lib;
}
 
-   if (DSP_FAILED(status))
+   if (status)
pr_err(%s: error status 0x%x, sz_coff_path: %s flags: 0x%x\n,
   __func__, status, sz_coff_path, flags);
return status;
@@ -608,7 +608,7 @@ int cod_open_base(struct cod_manager *hmgr, char 
*sz_coff_path,
hmgr-sz_zl_file[COD_MAXPATHLENGTH - 1] = '\0';
}
 
-   if (DSP_FAILED(status))
+   if (status)
pr_err(%s: error status 0x%x sz_coff_path: %s\n, __func__,
   status, sz_coff_path);
return status;
diff --git a/drivers/staging/tidspbridge/pmgr/dbll.c 
b/drivers/staging/tidspbridge/pmgr/dbll.c
index ea27824..2340638 100644
--- a/drivers/staging/tidspbridge/pmgr/dbll.c
+++ b/drivers/staging/tidspbridge/pmgr/dbll.c
@@ -256,7 +256,7 @@ int dbll_create(struct dbll_tar_obj **target_obj,
*target_obj = (struct dbll_tar_obj *)pzl_target;
}
DBC_ENSURE((!status  *target_obj) ||
-   (DSP_FAILED(status)  *target_obj == NULL));
+   (status  *target_obj == NULL));
}
 
return status;
@@ -559,7 +559,7 @@ int dbll_load(struct dbll_library_obj *lib, dbll_flags 
flags,
if (opened_doff)
dof_close(zl_lib);
 
-   DBC_ENSURE(DSP_FAILED(status) || zl_lib-load_ref  0);
+   DBC_ENSURE(status || zl_lib-load_ref  0);
 
dev_dbg(bridge, %s: lib: %p flags: 0x%x entry: %p, status 0x%x\n,
__func__, lib, flags, entry, status);
@@ -631,7 +631,7 @@ int dbll_open(struct dbll_tar_obj *target, char *file, 
dbll_flags flags,
/*
 *  Set up objects needed by the dynamic loader
 */
-   if (DSP_FAILED(status))
+   if (status)
goto func_cont;
 
/* Stream */
@@ -713,7 +713,7 @@ func_cont:
 
}
DBC_ENSURE((!status  (zl_lib-open_ref  0)  *lib_obj)
-   || (DSP_FAILED(status)  *lib_obj == NULL));
+   || (status  *lib_obj == NULL));
 

[PATCH 02/10] staging:ti dspbridge: remove DSP_SUCCEEDED macro from pmgr

2010-07-28 Thread Ernesto Ramos
Since status succeeded is now 0 macro DSP_SUCCEEDED
is not necessary anymore.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/pmgr/chnl.c   |8 +-
 drivers/staging/tidspbridge/pmgr/cmm.c|  135 +
 drivers/staging/tidspbridge/pmgr/cod.c|   10 +-
 drivers/staging/tidspbridge/pmgr/dbll.c   |   20 ++--
 drivers/staging/tidspbridge/pmgr/dev.c|   59 ++---
 drivers/staging/tidspbridge/pmgr/dmm.c|   10 +-
 drivers/staging/tidspbridge/pmgr/dspapi.c |   52 ++--
 drivers/staging/tidspbridge/pmgr/io.c |4 +-
 drivers/staging/tidspbridge/pmgr/msg.c|2 +-
 9 files changed, 139 insertions(+), 161 deletions(-)

diff --git a/drivers/staging/tidspbridge/pmgr/chnl.c 
b/drivers/staging/tidspbridge/pmgr/chnl.c
index d73c89c..626a993 100644
--- a/drivers/staging/tidspbridge/pmgr/chnl.c
+++ b/drivers/staging/tidspbridge/pmgr/chnl.c
@@ -77,20 +77,20 @@ int chnl_create(struct chnl_mgr **channel_mgr,
if (mgr_attrts-word_size == 0)
status = -EINVAL;
 
-   if (DSP_SUCCEEDED(status)) {
+   if (!status) {
status = dev_get_chnl_mgr(hdev_obj, hchnl_mgr);
-   if (DSP_SUCCEEDED(status)  hchnl_mgr != NULL)
+   if (!status  hchnl_mgr != NULL)
status = -EEXIST;
 
}
 
-   if (DSP_SUCCEEDED(status)) {
+   if (!status) {
struct bridge_drv_interface *intf_fxns;
dev_get_intf_fxns(hdev_obj, intf_fxns);
/* Let Bridge channel module finish the create: */
status = (*intf_fxns-pfn_chnl_create) (hchnl_mgr, hdev_obj,
mgr_attrts);
-   if (DSP_SUCCEEDED(status)) {
+   if (!status) {
/* Fill in DSP API channel module's fields of the
 * chnl_mgr structure */
chnl_mgr_obj = (struct chnl_mgr_ *)hchnl_mgr;
diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c 
b/drivers/staging/tidspbridge/pmgr/cmm.c
index b7cba1b..2f974c5 100644
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -266,33 +266,25 @@ int cmm_create(struct cmm_object **ph_cmm_mgr,
sys_info.dw_page_size = PAGE_SIZE;
sys_info.dw_allocation_granularity = PAGE_SIZE;
sys_info.dw_number_of_processors = 1;
-   if (DSP_SUCCEEDED(status)) {
-   cmm_obj-dw_page_size = sys_info.dw_page_size;
-   } else {
-   cmm_obj-dw_page_size = 0;
-   status = -EPERM;
-   }
+
+   cmm_obj-dw_page_size = sys_info.dw_page_size;
+
/* Note: DSP SM seg table(aDSPSMSegTab[]) zero'd by
 * MEM_ALLOC_OBJECT */
-   if (DSP_SUCCEEDED(status)) {
-   /* create node free list */
-   cmm_obj-node_free_list_head =
-   kzalloc(sizeof(struct lst_list),
-   GFP_KERNEL);
-   if (cmm_obj-node_free_list_head == NULL)
-   status = -ENOMEM;
-   else
-   INIT_LIST_HEAD(cmm_obj-
-  node_free_list_head-head);
-   }
-   if (DSP_SUCCEEDED(status))
-   mutex_init(cmm_obj-cmm_lock);
 
-   if (DSP_SUCCEEDED(status))
-   *ph_cmm_mgr = cmm_obj;
-   else
+   /* create node free list */
+   cmm_obj-node_free_list_head =
+   kzalloc(sizeof(struct lst_list),
+   GFP_KERNEL);
+   if (cmm_obj-node_free_list_head == NULL) {
+   status = -ENOMEM;
cmm_destroy(cmm_obj, true);
-
+   } else {
+   INIT_LIST_HEAD(cmm_obj-
+  node_free_list_head-head);
+   mutex_init(cmm_obj-cmm_lock);
+   *ph_cmm_mgr = cmm_obj;
+   }
} else {
status = -ENOMEM;
}
@@ -322,14 +314,14 @@ int cmm_destroy(struct cmm_object *hcmm_mgr, bool force)
if (!force) {
/* Check for outstanding memory allocations */
status = cmm_get_info(hcmm_mgr, temp_info);
-   if (DSP_SUCCEEDED(status)) {
+   if (!status) {
if (temp_info.ul_total_in_use_cnt  0) {
/* outstanding allocations */
status = -EPERM;
}
}
}
-   if (DSP_SUCCEEDED(status)) {
+   if (!status) {
/* UnRegister SM 

[PATCH 10/10] staging:ti dspbridge: remove DSP_FAILED macro definition

2010-07-28 Thread Ernesto Ramos
Since status succeeded is now 0 macro DSP_FAILED
is not necessary anymore. This patch removes this
define.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 .../staging/tidspbridge/include/dspbridge/dbdefs.h |3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h 
b/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h
index 2ccbfe1..5af075d 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/dbdefs.h
@@ -91,9 +91,6 @@
 #define DSPWORD   unsigned char
 #define DSPWORDSIZE sizeof(DSPWORD)
 
-/* Failure macro */
-#define DSP_FAILED(status) unlikely((s32)(status)  0)
-
 /* Power control enumerations */
 #define PROC_PWRCONTROL 0x8070
 
-- 
1.5.4.5

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


[PATCH 3/4] staging:ti dspbridge: make sure IVA2 is OFF when dev is created

2010-07-28 Thread Ernesto Ramos
Regardless the IVA2 power state before bridgedriver is
installed, the driver must ensure that IVA2 power
state is OFF when the device driver is created.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/core/tiomap3430.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c 
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 77527bd..e7584de 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -919,8 +919,10 @@ static int bridge_dev_create(struct bridge_dev_context
if (!status) {
dev_context-hdev_obj = hdev_obj;
/* Store current board state. */
-   dev_context-dw_brd_state = BRD_STOPPED;
+   dev_context-dw_brd_state = BRD_UNKNOWN;
dev_context-resources = resources;
+   dsp_clk_enable(DSP_CLK_IVA2);
+   bridge_brd_stop(dev_context);
/* Return ptr to our device state to the DSP API for storage */
*dev_cntxt = dev_context;
} else {
-- 
1.5.4.5

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


[PATCH 0/4] staging:ti dspbridge: Fix IVA2 power OFF series

2010-07-28 Thread Ernesto Ramos
This series of patches fixes issues that prevent IVA2 to turn OFF when
there are issues to load the base image and makes sure IVA2 switched OFF
when dsp bridge driver is installed.

Ernesto Ramos (4):
  staging:ti dspbridge: fix bridge_brd_stop so IVA2 is set OFF
  staging:ti dspbridge: proc_load/start should set IVA2 to OFF in case
of failure
  staging:ti dspbridge: make sure IVA2 is OFF when dev is created
  staging:ti dspbridge: remove bridge_brd_delete function

 drivers/staging/tidspbridge/core/tiomap3430.c |   65 ++--
 drivers/staging/tidspbridge/rmgr/proc.c   |6 ++-
 2 files changed, 10 insertions(+), 61 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 4/4] staging:ti dspbridge: remove bridge_brd_delete function

2010-07-28 Thread Ernesto Ramos
From: Ernesto Ramos erne...@ernesto-desktop.(none)

Remove bridge_brd_delete() function since it is
doing the same that bridge_brd_stop().

Signed-off-by: Ernesto Ramos erne...@ernesto-desktop.(none)
---
 drivers/staging/tidspbridge/core/tiomap3430.c |   57 +
 1 files changed, 1 insertions(+), 56 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c 
b/drivers/staging/tidspbridge/core/tiomap3430.c
index e7584de..f914829 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -686,61 +686,6 @@ static int bridge_brd_stop(struct bridge_dev_context 
*dev_ctxt)
 }
 
 /*
- *   bridge_brd_delete 
- *  purpose:
- *  Puts DSP in Low power mode
- *
- *  Preconditions :
- *  a) None
- */
-static int bridge_brd_delete(struct bridge_dev_context *dev_ctxt)
-{
-   int status = 0;
-   struct bridge_dev_context *dev_context = dev_ctxt;
-   struct pg_table_attrs *pt_attrs;
-   int clk_status;
-   struct dspbridge_platform_data *pdata =
-   omap_dspbridge_dev-dev.platform_data;
-
-   if (dev_context-dw_brd_state == BRD_STOPPED)
-   return status;
-
-   /* as per TRM, it is advised to first drive
-* the IVA2 to 'Standby' mode, before turning off the clocks.. This is
-* to ensure that there are no pending L3 or other transactons from
-* IVA2 */
-   status = sleep_dsp(dev_context, PWR_EMERGENCYDEEPSLEEP, NULL);
-   clk_status = dsp_clk_disable(DSP_CLK_IVA2);
-
-   /* Release the Ext Base virtual Address as the next DSP Program
-* may have a different load address */
-   if (dev_context-dw_dsp_ext_base_addr)
-   dev_context-dw_dsp_ext_base_addr = 0;
-
-   dev_context-dw_brd_state = BRD_STOPPED;/* update board state */
-
-   /* This is a good place to clear the MMU page tables as well */
-   if (dev_context-pt_attrs) {
-   pt_attrs = dev_context-pt_attrs;
-   memset((u8 *) pt_attrs-l1_base_va, 0x00, pt_attrs-l1_size);
-   memset((u8 *) pt_attrs-l2_base_va, 0x00, pt_attrs-l2_size);
-   memset((u8 *) pt_attrs-pg_info, 0x00,
-  (pt_attrs-l2_num_pages * sizeof(struct page_info)));
-   }
-   /* Disable the mail box interrupts */
-   if (dev_context-mbox) {
-   omap_mbox_disable_irq(dev_context-mbox, IRQ_RX);
-   omap_mbox_put(dev_context-mbox);
-   dev_context-mbox = NULL;
-   }
-   /* Reset IVA2 clocks*/
-   (*pdata-dsp_prm_write)(OMAP3430_RST1_IVA2_MASK | 
OMAP3430_RST2_IVA2_MASK |
-   OMAP3430_RST3_IVA2_MASK, OMAP3430_IVA2_MOD, 
OMAP2_RM_RSTCTRL);
-
-   return status;
-}
-
-/*
  *   bridge_brd_status 
  *  Returns the board status.
  */
@@ -1023,7 +968,7 @@ static int bridge_dev_destroy(struct bridge_dev_context 
*dev_ctxt)
return -EFAULT;
 
/* first put the device to stop state */
-   bridge_brd_delete(dev_context);
+   bridge_brd_stop(dev_context);
if (dev_context-pt_attrs) {
pt_attrs = dev_context-pt_attrs;
kfree(pt_attrs-pg_info);
-- 
1.5.4.5

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


[PATCH 1/4] staging:ti dspbridge: fix bridge_brd_stop so IVA2 is set OFF

2010-07-28 Thread Ernesto Ramos
right now, bridge_brd_stop is not changing the IVA2 power state
to OFF since PM_PWSTST_IVA2 is not 0 after calling this function.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/core/tiomap3430.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c 
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 9673acb..77527bd 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -639,11 +639,11 @@ static int bridge_brd_stop(struct bridge_dev_context 
*dev_ctxt)
dsp_pwr_state = (*pdata-dsp_prm_read)(OMAP3430_IVA2_MOD, 
OMAP2_PM_PWSTST) 
OMAP_POWERSTATEST_MASK;
if (dsp_pwr_state != PWRDM_POWER_OFF) {
+   (*pdata-dsp_prm_rmw_bits)(OMAP3430_RST2_IVA2_MASK, 0,
+   OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);
sm_interrupt_dsp(dev_context, MBX_PM_DSPIDLE);
mdelay(10);
 
-   clk_status = dsp_clk_disable(DSP_CLK_IVA2);
-
/* IVA2 is not in OFF state */
/* Set PM_PWSTCTRL_IVA2  to OFF */
(*pdata-dsp_prm_rmw_bits)(OMAP_POWERSTATEST_MASK,
@@ -651,8 +651,6 @@ static int bridge_brd_stop(struct bridge_dev_context 
*dev_ctxt)
/* Set the SW supervised state transition for Sleep */
(*pdata-dsp_cm_write)(OMAP34XX_CLKSTCTRL_FORCE_SLEEP,
OMAP3430_IVA2_MOD, OMAP2_CM_CLKSTCTRL);
-   } else {
-   clk_status = dsp_clk_disable(DSP_CLK_IVA2);
}
udelay(10);
/* Release the Ext Base virtual Address as the next DSP Program
@@ -682,6 +680,8 @@ static int bridge_brd_stop(struct bridge_dev_context 
*dev_ctxt)
(*pdata-dsp_prm_write)(OMAP3430_RST1_IVA2_MASK | 
OMAP3430_RST2_IVA2_MASK |
OMAP3430_RST3_IVA2_MASK, OMAP3430_IVA2_MOD, 
OMAP2_RM_RSTCTRL);
 
+   clk_status = dsp_clk_disable(DSP_CLK_IVA2);
+
return status;
 }
 
-- 
1.5.4.5

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


[PATCH 2/4] staging:ti dspbridge: proc_load/start should set IVA2 to OFF in case of failure

2010-07-28 Thread Ernesto Ramos
When a base image is being loaded or started and by some reason
the process fails, the IVA2 should be switched OFF.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/rmgr/proc.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/tidspbridge/rmgr/proc.c 
b/drivers/staging/tidspbridge/rmgr/proc.c
index 6258d8b..44c26e1 100644
--- a/drivers/staging/tidspbridge/rmgr/proc.c
+++ b/drivers/staging/tidspbridge/rmgr/proc.c
@@ -1302,9 +1302,10 @@ int proc_load(void *hprocessor, const s32 argc_index,
}
 
 func_end:
-   if (status)
+   if (status) {
pr_err(%s: Processor failed to load\n, __func__);
-
+   proc_stop(p_proc_object);
+   }
DBC_ENSURE((!status
 p_proc_object-proc_state == PROC_LOADED)
   || status);
@@ -1594,6 +1595,7 @@ func_cont:
}
} else {
pr_err(%s: Failed to start the dsp\n, __func__);
+   proc_stop(p_proc_object);
}
 
 func_end:
-- 
1.5.4.5

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


[PATCH] staging:ti dspbridge: remove find_gcf from nldr.c

2010-07-28 Thread Ernesto Ramos
Remove find_gcf from nldr.c and use kernel function
gcd().

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/rmgr/nldr.c |   20 ++--
 1 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/tidspbridge/rmgr/nldr.c 
b/drivers/staging/tidspbridge/rmgr/nldr.c
index 23b44cf..f01bddd 100644
--- a/drivers/staging/tidspbridge/rmgr/nldr.c
+++ b/drivers/staging/tidspbridge/rmgr/nldr.c
@@ -35,6 +35,7 @@
 #include dspbridge/uuidutil.h
 
 #include dspbridge/nldr.h
+#include linux/gcd.h
 
 /* Name of section containing dynamic load mem */
 #define DYNMEMSECT  .dspbridge_mem
@@ -304,7 +305,6 @@ static void unload_ovly(struct nldr_nodeobject 
*nldr_node_obj,
 static bool find_in_persistent_lib_array(struct nldr_nodeobject *nldr_node_obj,
 struct dbll_library_obj *lib);
 static u32 find_lcm(u32 a, u32 b);
-static u32 find_gcf(u32 a, u32 b);
 
 /*
  *   nldr_allocate 
@@ -1889,27 +1889,11 @@ static u32 find_lcm(u32 a, u32 b)
 {
u32 ret;
 
-   ret = a * b / find_gcf(a, b);
+   ret = a * b / gcd(a, b);
 
return ret;
 }
 
-/*
- *  Find GCF (Greatest Common Factor ) ===
- */
-static u32 find_gcf(u32 a, u32 b)
-{
-   u32 c;
-
-   /* Get the GCF (Greatest common factor between the numbers,
-* using Euclidian Algo */
-   while ((c = (a % b))) {
-   a = b;
-   b = c;
-   }
-   return b;
-}
-
 #ifdef CONFIG_TIDSPBRIDGE_BACKTRACE
 /**
  * nldr_find_addr() - Find the closest symbol to the given address based on
-- 
1.5.4.5

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


RE: [PATCH 2/5] omap:hwspinlock-define HWSPINLOCK base address

2010-07-28 Thread Kanigeri, Hari
 
Sanjeev,
   
  @@ -49,5 +49,10 @@
   #define OMAP44XX_MAILBOX_BASE
  (L4_44XX_BASE + 0xF4000)
   #define OMAP44XX_HSUSB_OTG_BASE
  (L4_44XX_BASE + 0xAB000)
 
  +#define OMAP4_MMU1_BASE0x55082000
  +#define OMAP4_MMU2_BASE0x4A066000

 [sp] Are these 2 base addresses related to this patch?
   
Nope. Thanks for finding this. I will update the patch.
  
   [sp] Then additional patch only to add the base address
  won't make much
   sense.
You may want to combine it with appropriately with
  another one in
   this
series.
 
  I think the define to add SPINLOCK base address is
  independent of adding spinlock driver functionality, and I
  don't see a reason why it shouldn't be a separate patch.
  Example: The driver patches might take time to get
  upstreamed, but that shouldn't stop this patch that adds the
  missing Base address.
 
 [sp] Without driver would this base address be of any use?
I could find you examples where there are definitions without being used.
But any case, it is a small change I will follow your suggestion.

 
 
  
   

 ~sanjeev

  +
  +#define OMAP44XX_SPINLOCK_BASE
  (L4_44XX_BASE + 0xF6000)
  +
   #endif /* __ASM_ARCH_OMAP44XX_H */
 
  --
  1.7.0
 
 
   
Best regards,
Hari
   
 
--
To unsubscribe from this list: send the line unsubscribe 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] staging:ti dspbridge: remove unnecessary volatile variables

2010-07-28 Thread Nishanth Menon

Ramos Falcon, Ernesto had written, on 07/28/2010 09:40 AM, the following:

Remove unnecessary volatile variables; use accessor
functions __raw_readl/__raw_writel instead when applicable.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/core/tiomap3430.c |8 
 drivers/staging/tidspbridge/dynload/tramp.c   |4 ++--
 drivers/staging/tidspbridge/pmgr/cmm.c|7 ---
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c 
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 08a2f5f..ae1f394 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -404,7 +404,7 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
pr_err(%s: Illegal SM base\n, __func__);
status = -EPERM;
} else
-   *((volatile u32 *)dw_sync_addr) = 0x;
+   __raw_writel(0x, dw_sync_addr);

curious question: any reason not to use writel instead of __raw_writel?

 
 	if (DSP_SUCCEEDED(status)) {

resources = dev_context-resources;
@@ -584,7 +584,7 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
dev_dbg(bridge, Waiting for Sync @ 0x%x\n, dw_sync_addr);
dev_dbg(bridge, DSP c_int00 Address =  0x%x\n, dsp_addr);
if (dsp_debug)
-   while (*((volatile u16 *)dw_sync_addr))
+   while (__raw_readw(dw_sync_addr))
;;


may be for a later on patch - we seem to have a potential infinite loop 
here..


 
 		/* Wait for DSP to clear word in shared memory */

@@ -602,7 +602,7 @@ static int bridge_brd_start(struct bridge_dev_context 
*dev_ctxt,
/* Write the synchronization bit to indicate the
 * completion of OPP table update to DSP
 */
-   *((volatile u32 *)dw_sync_addr) = 0XCAFECAFE;
+   __raw_writel(0XCAFECAFE, dw_sync_addr);
 
 			/* update board state */

dev_context-dw_brd_state = BRD_RUNNING;
@@ -1852,7 +1852,7 @@ bool wait_for_start(struct bridge_dev_context 
*dev_context, u32 dw_sync_addr)
u16 timeout = TIHELEN_ACKTIMEOUT;
 
 	/*  Wait for response from board */

-   while (*((volatile u16 *)dw_sync_addr)  --timeout)
+   while (__raw_readw(dw_sync_addr)  --timeout)
udelay(10);
 
 	/*  If timed out: return false */

diff --git a/drivers/staging/tidspbridge/dynload/tramp.c 
b/drivers/staging/tidspbridge/dynload/tramp.c
index 81314d2..60d22ea 100644
--- a/drivers/staging/tidspbridge/dynload/tramp.c
+++ b/drivers/staging/tidspbridge/dynload/tramp.c
@@ -86,8 +86,8 @@ static u8 priv_h2a(u8 value)
 static void priv_tramp_sym_gen_name(u32 value, char *dst)
 {
u32 i;
-   volatile char *prefix = TRAMP_SYM_PREFIX;
-   volatile char *dst_local = dst;
+   char *prefix = TRAMP_SYM_PREFIX;
+   char *dst_local = dst;
u8 tmp;
 
 	/*  Clear out the destination, including the ending NULL */

diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c 
b/drivers/staging/tidspbridge/pmgr/cmm.c
index 874ed64..b7cba1b 100644
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -1008,6 +1008,7 @@ void *cmm_xlator_alloc_buf(struct cmm_xlatorobject 
*xlator, void *va_buf,
 {
struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
void *pbuf = NULL;
+   void *tmp_va_buff;
struct cmm_attrs attrs;
 
 	DBC_REQUIRE(refs  0);

@@ -1019,16 +1020,16 @@ void *cmm_xlator_alloc_buf(struct cmm_xlatorobject 
*xlator, void *va_buf,
 
 	if (xlator_obj) {

attrs.ul_seg_id = xlator_obj-ul_seg_id;
-   *(volatile u32 *)va_buf = 0;
+   __raw_writel(0, va_buf);
/* Alloc SM */
pbuf =
cmm_calloc_buf(xlator_obj-hcmm_mgr, pa_size, attrs, NULL);
if (pbuf) {
/* convert to translator(node/strm) process Virtual
 * address */
-   *(volatile u32 **)va_buf =
-   (u32 *) cmm_xlator_translate(xlator,
+tmp_va_buff = cmm_xlator_translate(xlator,
 pbuf, CMM_PA2VA);
+   __raw_writel((u32)tmp_va_buff, va_buf);


a) is the u32 cast of tmp_va_buff really necessary?
b) tmp_va_buff is used only in this branch, why not reduce the scope of 
the variable to just to this if branch

or an optional way could be:
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -1022,18 +1022,17 @@ void *cmm_xlator_alloc_buf(struct 
cmm_xlatorobject *xlator, void *va_buf,

DBC_REQUIRE(xlator_obj-ul_seg_id  0);

if 

Re: [PATCH 2/5] staging:ti dspbridge: remove unnecessary check for NULL pointer in cmm.c

2010-07-28 Thread Nishanth Menon

Ramos Falcon, Ernesto had written, on 07/28/2010 09:40 AM, the following:

Remove unnecessary check for NULL pointer in cmm.c.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/pmgr/cmm.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c 
b/drivers/staging/tidspbridge/pmgr/cmm.c
index 8e808d9..874ed64 100644
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -992,16 +992,12 @@ int cmm_xlator_create(struct cmm_xlatorobject **xlator,
 int cmm_xlator_delete(struct cmm_xlatorobject *xlator, bool force)
 {
struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
-   int status = 0;
 
 	DBC_REQUIRE(refs  0);
 
-	if (xlator_obj)

-   kfree(xlator_obj);
-   else
-   status = -EFAULT;
+   kfree(xlator_obj);
 
-	return status;

+   return 0;
 }
 
 /*
which kind of begs the question - does this function need to any longer 
return int?


--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe 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/5] staging:ti dspbridge: replace simple_strtoul by strict_strtoul

2010-07-28 Thread Greg KH
On Wed, Jul 28, 2010 at 09:40:52AM -0500, Ernesto Ramos wrote:
 Replace simple_strtoul by strict_strtoul in atoi function.

Why not use the built-in kernel function instead of having your own atoi
function?

thanks,

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


RE: [RFC 0/8] TI TILER-DMM driver

2010-07-28 Thread Sin, David
 -Original Message-
 From: Hans Verkuil [mailto:hverk...@xs4all.nl] 
 Sent: Saturday, July 24, 2010 6:13 AM
 To: Sin, David
 Cc: linux-arm-ker...@lists.arm.linux.org.uk; 
 linux-omap@vger.kernel.org; Tony Lindgren; Russell King; 
 Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar, Santosh
 Subject: Re: [RFC 0/8] TI TILER-DMM driver
 
 Hi David,
 
 On Saturday 24 July 2010 01:22:20 David Sin wrote:
  TILER is a hardware block made by Texas Instruments.  Its 
 purpose is to 
  organize video/image memory in a 2-dimensional fashion to 
 limit memory 
  bandwidth and facilitate 0 effort rotation and mirroring.  
 The TILER 
  driver facilitates allocating, freeing, as well as mapping 
 2D blocks (areas) 
  in the TILER container(s).  It also facilitates rotating 
 and mirroring 
  the allocated blocks or its rectangular subsections.
 
 Since this driver is part of the media/video subsystem you 
 should cross-post
 it to the linux-media mailinglist as well.
 
 The main question that I have is how this driver is to be 
 used in practice.
 How does it fit into the bigger video4linux picture? Is this 
 something that
 is mainly used from other v4l or fb drivers? Or is it 
 controlled by userspace?

[dhs] I missed this one -- my apologies.  As I stated to Vaibhav, any device 
can use TILER memory, but there is a big advantage, performance-wise, for 
2-Dimensional macro block based buffers.  This HW is intended for image/video 
hardware accelerators (e.g. OMAP4 IVA-HD).  Plus there's the added advantage of 
doing zero-copy flips and rotations for the OMAP display and image sub-systems.

In this RFC, there are only kernel APIs to allocate TILER memory.  Eventually, 
we would like to provide a way to obtain TILER memory to the user space.

 
 Regards,
 
   Hans
 
  
  List of pending items in proposed order:
  
  * Add area packing support (multiple blocks can reside in 
 the same band/area)
to optimize area use
  * Add group-ID support (to specify which blocks can reside 
 together in the
same area)
  * Add multiple search directions to TCM-SiTA
  * Add 1D block support (including adding 1D search algo to TCM-SiTA)
  * Optimize mutex handling (don.t hold mutex during memory
allocation/mapping/cache flushing)
  * Add block reference counting, support for sharing blocks
  * Move all kernel-API-s to tiler-iface.c
  * Support orphaned block support (in preparation for 
 process cleanup support)
  * Change block identification from physical address to key-ID pair
(in preparation for user space support, and process security)
  * Add support for process security (blocks from separate 
 processes never
reside in the same band)
  * Support file interface (ioctl and mmap)
  * Support for buffers (ordered list of blocks that are 
 mapped to userspace
together, such as YUV420sp)
  * Support 1D user buffer mapping into TILER container
  * Support for block pre-reservation (to further optimize area use)
  
  David Sin (1):
TILER-DMM: DMM-PAT driver for TI TILER
  
  Lajos Molnar (6):
TILER-DMM: Container manager interface and utility definitons
TILER-DMM: TILER Memory Manager interface and implementation
TILER-DMM: TILER interface file and documentation
TILER-DMM: Geometry and view manipulation functions.
TILER-DMM: Main TILER driver implementation.
TILER-DMM: Linking TILER driver into the Linux kernel build
  
  Ravi Ramachandra (1):
TILER-DMM: Sample TCM implementation: Simple TILER Allocator
  
   Documentation/arm/TILER   |  144 +
   arch/arm/mach-omap2/include/mach/dmm.h|  128 
   arch/arm/mach-omap2/include/mach/tiler.h  |  201 +
   drivers/media/Kconfig |6 +
   drivers/media/Makefile|2 +
   drivers/media/video/tiler/Kconfig |   65 
   drivers/media/video/tiler/Makefile|7 +
   drivers/media/video/tiler/_tiler.h|   51 
   drivers/media/video/tiler/dmm.c   |  200 +
   drivers/media/video/tiler/tcm.h   |  209 +
   drivers/media/video/tiler/tcm/Makefile|1 +
   drivers/media/video/tiler/tcm/_tcm-sita.h |   64 
   drivers/media/video/tiler/tcm/tcm-sita.c  |  459 
 +
   drivers/media/video/tiler/tcm/tcm-sita.h  |   37 +++
   drivers/media/video/tiler/tcm/tcm-utils.h |   54 
   drivers/media/video/tiler/tiler-geom.c|  360 
 ++
   drivers/media/video/tiler/tiler-iface.c   |  106 +++
   drivers/media/video/tiler/tiler-main.c|  426 
 ++
   drivers/media/video/tiler/tmm-pat.c   |  274 +
   drivers/media/video/tiler/tmm.h   |  109 +++
   20 files changed, 2903 insertions(+), 0 deletions(-)
   create mode 100644 Documentation/arm/TILER
   create mode 100644 arch/arm/mach-omap2/include/mach/dmm.h
   create mode 100644 arch/arm/mach-omap2/include/mach/tiler.h
   

Re: [PATCH 2/5] staging:ti dspbridge: remove unnecessary check for NULL pointer in cmm.c

2010-07-28 Thread Nishanth Menon

Nishanth Menon had written, on 07/28/2010 10:04 AM, the following:

Ramos Falcon, Ernesto had written, on 07/28/2010 09:40 AM, the following:

Remove unnecessary check for NULL pointer in cmm.c.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/pmgr/cmm.c |8 ++--
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c 
b/drivers/staging/tidspbridge/pmgr/cmm.c
index 8e808d9..874ed64 100644
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -992,16 +992,12 @@ int cmm_xlator_create(struct cmm_xlatorobject **xlator,
 int cmm_xlator_delete(struct cmm_xlatorobject *xlator, bool force)
 {
struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
-   int status = 0;
 
 	DBC_REQUIRE(refs  0);
 
-	if (xlator_obj)

-   kfree(xlator_obj);
-   else
-   status = -EFAULT;
+   kfree(xlator_obj);
 
-	return status;

+   return 0;
 }
 
 /*
which kind of begs the question - does this function need to any longer 
return int?



here is a better approach:
remove cmm_xlator_delete altogether
diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c 
b/drivers/staging/tidspbridge/pmgr/cmm.c

index 8e808d9..1a4ebca 100644
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -984,27 +984,6 @@ int cmm_xlator_create(struct cmm_xlatorobject **xlator,
 }

 /*
- *   cmm_xlator_delete 
- *  Purpose:
- *  Free the Xlator resources.
- *  VM gets freed later.
- */
-int cmm_xlator_delete(struct cmm_xlatorobject *xlator, bool force)
-{
-   struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
-   int status = 0;
-
-   DBC_REQUIRE(refs  0);
-
-   if (xlator_obj)
-   kfree(xlator_obj);
-   else
-   status = -EFAULT;
-
-   return status;
-}
-
-/*
  *   cmm_xlator_alloc_buf 
  */
 void *cmm_xlator_alloc_buf(struct cmm_xlatorobject *xlator, void *va_buf,
diff --git a/drivers/staging/tidspbridge/rmgr/node.c 
b/drivers/staging/tidspbridge/rmgr/node.c

index 9f07c81..0c39288 100644
--- a/drivers/staging/tidspbridge/rmgr/node.c
+++ b/drivers/staging/tidspbridge/rmgr/node.c
@@ -2503,7 +2503,6 @@ static void delete_node(struct node_object *hnode,
struct process_context *pr_ctxt)
 {
struct node_mgr *hnode_mgr;
-   struct cmm_xlatorobject *xlator;
struct bridge_drv_interface *intf_fxns;
u32 i;
enum node_type node_type;
@@ -2521,7 +2520,6 @@ static void delete_node(struct node_object *hnode,
hnode_mgr = hnode-hnode_mgr;
if (!hnode_mgr)
goto func_end;
-   xlator = hnode-xlator;
node_type = node_get_type(hnode);
if (node_type != NODE_DEVICE) {
node_msg_args = hnode-create_args.asa.node_msg_args;
@@ -2617,10 +2615,7 @@ static void delete_node(struct node_object *hnode,
hnode-dcd_props.obj_data.node_obj.pstr_i_alg_name = NULL;

/* Free all SM address translator resources */
-   if (xlator) {
-   (void)cmm_xlator_delete(xlator, true);  /* force free */
-   xlator = NULL;
-   }
+   kfree(hnode-xlator);

kfree(hnode-nldr_node_obj);
hnode-nldr_node_obj = NULL;
diff --git a/drivers/staging/tidspbridge/rmgr/strm.c 
b/drivers/staging/tidspbridge/rmgr/strm.c

index 73888e3..05a8d13 100644
--- a/drivers/staging/tidspbridge/rmgr/strm.c
+++ b/drivers/staging/tidspbridge/rmgr/strm.c
@@ -844,14 +844,8 @@ static int delete_strm(struct strm_object *stream_obj)
status = (*intf_fxns-pfn_chnl_close)
(stream_obj-chnl_obj);
/* Free all SM address translator resources */
-   if (DSP_SUCCEEDED(status)) {
-   if (stream_obj-xlator) {
-   /* force free */
-   (void)cmm_xlator_delete(stream_obj-
-   xlator,
-   true);
-   }
-   }
+   if (DSP_SUCCEEDED(status))
+   kfree(stream_obj-xlator);
}
kfree(stream_obj);
} else {
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe 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 1/8] TILER-DMM: DMM-PAT driver for TI TILER

2010-07-28 Thread Hiremath, Vaibhav
 -Original Message-
 From: Sin, David
 Sent: Wednesday, July 28, 2010 8:09 PM
 To: Laurent Pinchart; linux-arm-ker...@lists.infradead.org
 Cc: Hiremath, Vaibhav; linux-omap@vger.kernel.org; Tony Lindgren; Russell
 King; Ohad Ben-Cohen; Kanigeri, Hari; Shilimkar, Santosh; Molnar, Lajos
 Subject: RE: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER
 
  -Original Message-
  From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
  Sent: Wednesday, July 28, 2010 5:00 AM
  To: linux-arm-ker...@lists.infradead.org
  Cc: Hiremath, Vaibhav; Sin, David;
  linux-omap@vger.kernel.org; Tony Lindgren; Russell King; Ohad
  Ben-Cohen; Kanigeri, Hari; Shilimkar, Santosh; Molnar, Lajos
  Subject: Re: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER
snip

  I think I agree with it. The tiler provides dynamic views on
  arbitrary
  physical memory. Ideally it shouldn't be tied to the
  media/video subsystem
  (obviously it should still provide an interface for V4L drivers).
 
  It's getting a bit hard to comment on the proposal, as
  there's no public
  documentation I'm aware of beside the Documentation/arm/TILER
  file in the
  patch set, and that information is far too concise and vague.
 
  --
  Regards,
 
  Laurent Pinchart
 
 
 [dhs] I understand what you're stating here, conceptually, but I'm missing
 some details.  Do you mean that there needs to be a generic layer between a
 given video memory allocator and V4L? 
 and that set of APIs should point to
 specific functions based on availability (e.g. VRFB, TILER, future TILER,
 other IP, etc)?
 
[Hiremath, Vaibhav] David,
As far as Memory allocator is concerned I think it is more generic term and 
should not really tie to underneath hardware/feature (Tiler, VRFB or could be 
anything). This is long time issue with every Embedded devices dealing with 
Video, due to their dynamic requirement of memory/buffers.

Have you looked at Samsung (CMA) and Qualcomm (IOMMU) patches for memory 
allocation/management? I think it is worth to look at their approach. 

Thanks,
Vaibhav

 Laurent:  The TRM for DMM-TILER should be publicly available already, but
 for some reason, I'm not able to see the link.  I will work on this...
--
To unsubscribe from this list: send the line unsubscribe 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] twl4030 reboot workaround

2010-07-28 Thread Mike Turquette

Mikko Rapeli wrote:

From: Mikko Rapeli ext-mikko.rap...@nokia.com

Original patch: http://marc.info/?l=linux-omapm=126522625032441w=2


I forgot about this one...


Removes TWL4030 sleep script prior to rebooting, only on OMAP3. This is
necessary since DPLL3 reset causes SYS_OFFMODE pin to go low, resulting
in the sleep script being executed on TWL4030. This usually results in
VDD1  VDD2 voltage collapse while ROM code is executing, followed by an
MPU Watch Dog reset or worse, an irrecoverable hang.

Original patch resulted in a crash due to sleeping i2c calls late in the
reboot sequence. Here's how to trigger the crash:

# cat /dev/urandom  /foo 
sync();
reboot(LINUX_REBOOT_CMD_RESTART2);

Kernel trace from 2.6.32:

Unable to handle kernel NULL pointer dereference at virtual address 
pgd = c0004000
[] *pgd=
Internal error: Oops: 805 [#2] PREEMPT
...
[c00b3210] (exit_mmap+0x1d4/0x1f8) from [c006069c] (mmput+0x34/0x110)
[c006069c] (mmput+0x34/0x110) from [c0064a90] (exit_mm+0x140/0x180)
[c0064a90] (exit_mm+0x140/0x180) from [c00668ec] (do_exit+0x5d8/0x6ac)
[c00668ec] (do_exit+0x5d8/0x6ac) from [c0035858] (die+0x2d4/0x2e0)
[c0035858] (die+0x2d4/0x2e0) from [c0035904] (baddataabort+0x0/0x50)
[c0035904] (baddataabort+0x0/0x50) from [c0274ff4] (i2c_transfer+0xec/0x104)
[c0274ff4] (i2c_transfer+0xec/0x104) from [0001] (0x1)

Fix is to move reboot preparations into a reboot notifier.

Signed-off-by: Mikko Rapeli ext-mikko.rap...@nokia.com
---
 drivers/mfd/twl4030-power.c |   29 +
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 7efa878..5d46768 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -28,6 +28,7 @@
 #include linux/pm.h
 #include linux/i2c/twl.h
 #include linux/platform_device.h
+#include linux/reboot.h
 
 #include asm/mach-types.h
 
@@ -127,6 +128,29 @@ static u8 res_config_addrs[] = {

[RES_Main_Ref]  = 0x94,
 };
 
+/*

+ * PRCM on OMAP3 will drive SYS_OFFMODE low during DPLL3 warm reset.
+ * This causes Gaia sleep script to execute, usually killing VDD1 and
+ * VDD2 while code is running.  WA is to disable the sleep script
+ * before warm reset.
+ */
+static int twl4030_prepare_for_reboot(struct notifier_block *this,
+   unsigned long cmd, void *p)
+{
+   int err;
+   err = twl4030_remove_script(TWL4030_SLEEP_SCRIPT);
+   if (err)
+   pr_err(TWL4030: error trying to disable sleep script!\n);
+
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block twl4030_reboot_notifier = {
+   .notifier_call = twl4030_prepare_for_reboot,
+   .next = NULL,
+   .priority = 0
+};
+
 static int __init twl4030_write_script_byte(u8 address, u8 byte)
 {
int err;
@@ -549,6 +573,11 @@ void __init twl4030_power_init(struct twl4030_power_data 
*twl4030_scripts)
err = twl_i2c_write_u8(TWL4030_MODULE_PM_MASTER, 0, R_PROTECT_KEY);
if (err)
pr_err(TWL4030 Unable to relock registers\n);
+
+   err = register_reboot_notifier(twl4030_reboot_notifier);


This method is much better than the method I proposed before.  Taking 
into account the comments from others, ACK.


Mike


+   if (err)
+   pr_err(TWL4030 Failed to register reboot notifier\n);
+
return;
 
 unlock:


--
To unsubscribe from this list: send the line unsubscribe 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] staging:ti dspbridge: avoid possible NULL dereference panic

2010-07-28 Thread Ernesto Ramos
When dsp_notifications array is received from user,
dspbridge verifies the array has valid pointers
and dsp_notification structures. However, these
structures contain pointers that need to be
checked for valid handles.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/pmgr/dspapi.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/tidspbridge/pmgr/dspapi.c 
b/drivers/staging/tidspbridge/pmgr/dspapi.c
index 1b0ab4a..da08dfc 100644
--- a/drivers/staging/tidspbridge/pmgr/dspapi.c
+++ b/drivers/staging/tidspbridge/pmgr/dspapi.c
@@ -539,7 +539,7 @@ func_end:
  */
 u32 mgrwrap_wait_for_bridge_events(union trapped_args *args, void *pr_ctxt)
 {
-   int status = 0, real_status = 0;
+   int status = 0;
struct dsp_notification *anotifications[MAX_EVENTS];
struct dsp_notification notifications[MAX_EVENTS];
u32 index, i;
@@ -554,19 +554,21 @@ u32 mgrwrap_wait_for_bridge_events(union trapped_args 
*args, void *pr_ctxt)
/* get the events */
for (i = 0; i  count; i++) {
CP_FM_USR(notifications[i], anotifications[i], status, 1);
-   if (!status) {
-   /* set the array of pointers to kernel structures */
-   anotifications[i] = notifications[i];
+   if (status || !notifications[i].handle) {
+   status = -EINVAL;
+   break;
}
+   /* set the array of pointers to kernel structures */
+   anotifications[i] = notifications[i];
}
if (!status) {
-   real_status = mgr_wait_for_bridge_events(anotifications, count,
+   status = mgr_wait_for_bridge_events(anotifications, count,
 index,
 args-args_mgr_wait.
 utimeout);
}
CP_TO_USR(args-args_mgr_wait.pu_index, index, status, 1);
-   return real_status;
+   return status;
 }
 
 /*
-- 
1.5.4.5

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


RE: [PATCH 2/5] staging:ti dspbridge: remove unnecessary check for NULL pointer in cmm.c

2010-07-28 Thread Ramos Falcon, Ernesto


-Original Message-
From: Menon, Nishanth
Sent: Wednesday, July 28, 2010 10:32 AM
To: Ramos Falcon, Ernesto
Cc: gre...@suse.de; Ramirez Luna, Omar; o...@wizery.com;
ameya.pala...@nokia.com; felipe.contre...@nokia.com; Guzman Lugo, Fernando;
linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-
o...@vger.kernel.org
Subject: Re: [PATCH 2/5] staging:ti dspbridge: remove unnecessary check for
NULL pointer in cmm.c

Nishanth Menon had written, on 07/28/2010 10:04 AM, the following:
 Ramos Falcon, Ernesto had written, on 07/28/2010 09:40 AM, the following:
 Remove unnecessary check for NULL pointer in cmm.c.

 Signed-off-by: Ernesto Ramos erne...@ti.com
 ---
  drivers/staging/tidspbridge/pmgr/cmm.c |8 ++--
  1 files changed, 2 insertions(+), 6 deletions(-)

 diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c
b/drivers/staging/tidspbridge/pmgr/cmm.c
 index 8e808d9..874ed64 100644
 --- a/drivers/staging/tidspbridge/pmgr/cmm.c
 +++ b/drivers/staging/tidspbridge/pmgr/cmm.c
 @@ -992,16 +992,12 @@ int cmm_xlator_create(struct cmm_xlatorobject
**xlator,
  int cmm_xlator_delete(struct cmm_xlatorobject *xlator, bool force)
  {
 struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
 -   int status = 0;

 DBC_REQUIRE(refs  0);

 -   if (xlator_obj)
 -   kfree(xlator_obj);
 -   else
 -   status = -EFAULT;
 +   kfree(xlator_obj);

 -   return status;
 +   return 0;
  }

  /*
 which kind of begs the question - does this function need to any longer
 return int?

here is a better approach:
remove cmm_xlator_delete altogether
diff --git a/drivers/staging/tidspbridge/pmgr/cmm.c
b/drivers/staging/tidspbridge/pmgr/cmm.c
index 8e808d9..1a4ebca 100644
--- a/drivers/staging/tidspbridge/pmgr/cmm.c
+++ b/drivers/staging/tidspbridge/pmgr/cmm.c
@@ -984,27 +984,6 @@ int cmm_xlator_create(struct cmm_xlatorobject
**xlator,
  }

  /*
- *   cmm_xlator_delete 
- *  Purpose:
- *  Free the Xlator resources.
- *  VM gets freed later.
- */
-int cmm_xlator_delete(struct cmm_xlatorobject *xlator, bool force)
-{
-  struct cmm_xlator *xlator_obj = (struct cmm_xlator *)xlator;
-  int status = 0;
-
-  DBC_REQUIRE(refs  0);
-
-  if (xlator_obj)
-  kfree(xlator_obj);
-  else
-  status = -EFAULT;
-
-  return status;
-}
-
-/*
   *   cmm_xlator_alloc_buf 
   */
  void *cmm_xlator_alloc_buf(struct cmm_xlatorobject *xlator, void *va_buf,
diff --git a/drivers/staging/tidspbridge/rmgr/node.c
b/drivers/staging/tidspbridge/rmgr/node.c
index 9f07c81..0c39288 100644
--- a/drivers/staging/tidspbridge/rmgr/node.c
+++ b/drivers/staging/tidspbridge/rmgr/node.c
@@ -2503,7 +2503,6 @@ static void delete_node(struct node_object *hnode,
   struct process_context *pr_ctxt)
  {
   struct node_mgr *hnode_mgr;
-  struct cmm_xlatorobject *xlator;
   struct bridge_drv_interface *intf_fxns;
   u32 i;
   enum node_type node_type;
@@ -2521,7 +2520,6 @@ static void delete_node(struct node_object *hnode,
   hnode_mgr = hnode-hnode_mgr;
   if (!hnode_mgr)
   goto func_end;
-  xlator = hnode-xlator;
   node_type = node_get_type(hnode);
   if (node_type != NODE_DEVICE) {
   node_msg_args = hnode-create_args.asa.node_msg_args;
@@ -2617,10 +2615,7 @@ static void delete_node(struct node_object *hnode,
   hnode-dcd_props.obj_data.node_obj.pstr_i_alg_name = NULL;

   /* Free all SM address translator resources */
-  if (xlator) {
-  (void)cmm_xlator_delete(xlator, true);  /* force free */
-  xlator = NULL;
-  }
+  kfree(hnode-xlator);

   kfree(hnode-nldr_node_obj);
   hnode-nldr_node_obj = NULL;
diff --git a/drivers/staging/tidspbridge/rmgr/strm.c
b/drivers/staging/tidspbridge/rmgr/strm.c
index 73888e3..05a8d13 100644
--- a/drivers/staging/tidspbridge/rmgr/strm.c
+++ b/drivers/staging/tidspbridge/rmgr/strm.c
@@ -844,14 +844,8 @@ static int delete_strm(struct strm_object *stream_obj)
   status = (*intf_fxns-pfn_chnl_close)
   (stream_obj-chnl_obj);
   /* Free all SM address translator resources */
-  if (DSP_SUCCEEDED(status)) {
-  if (stream_obj-xlator) {
-  /* force free */
-  (void)cmm_xlator_delete(stream_obj-
-  xlator,
-  true);
-  }
-  }
+  if (DSP_SUCCEEDED(status))
+  kfree(stream_obj-xlator);
   }
   kfree(stream_obj);
   } else {
--
Regards,
Nishanth Menon

Thanks Nishanth,

I considered this approach before but in terms of maintainability I thought it 
was easier to locate 

RE: [PATCH 3/5] omap:hwspinlock-added hwspinlock driver

2010-07-28 Thread Premi, Sanjeev
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kanigeri, Hari
 Sent: Monday, July 19, 2010 10:20 PM
 To: Linux Omap; Tony Lindgren
 Cc: Shilimkar, Santosh; Cousson, Benoit; Que, Simon; Kanigeri, Hari
 Subject: [PATCH 3/5] omap:hwspinlock-added hwspinlock driver

 From: Simon Que s...@ti.com

 Created driver for OMAP hardware spinlock.  This driver supports:
 - Reserved spinlocks for internal use
[sp] How do we reserver the spinlocks? I didn't see any API or parameter
 used to reserve them.
 If this refers to hwspinlock_request_specific(), then it isn't
 really reservation. Reservation is usually is blocks and I would
 expect range input.

 How is this reservation made known to other processors who would
 be attempting to use these spinlocks - in a multi processor scenario
 e.g. OMAP4. Both processors need to be aware of this reservation.

 - Dynamic allocation of unreserved locks
 - Lock, unlock, and trylock functions, with or without
 disabling irqs/preempt
 - Registered as a platform device driver

 The device initialization uses hwmod to configure the devices.
 One device will be created for each IP.  It will pass
 spinlock register offset
 info to the driver.  The device initialization file is:
   arch/arm/mach-omap2/hwspinlocks.c

 The driver takes in register offset info passed in device
 initialization.
 It uses hwmod to obtain the base address of the hardware
 spinlock module.
 Then it reads info from the registers.  The function
 hwspinlock_probe()
 initializes the array of spinlock structures, each containing
 a spinlock
 register address calculated from the base address and lock offsets.
 The device driver file is:
   arch/arm/plat-omap/hwspinlock.c

 Here's an API summary:
 int hwspinlock_lock(struct hwspinlock *);
   Attempt to lock a hardware spinlock.  If it is busy,
 the function will
   keep trying until it succeeds.  This is a blocking function.
 int hwspinlock_trylock(struct hwspinlock *);
   Attempt to lock a hardware spinlock.  If it is busy,
 the function will
   return BUSY.  If it succeeds in locking, the function
 will return
   ACQUIRED.  This is a non-blocking function.
 int hwspinlock_unlock(struct hwspinlock *);
   Unlock a hardware spinlock.

 struct hwspinlock *hwspinlock_request(void);
   Provides for dynamic allocation of a hardware
 spinlock.  It returns
   the handle to the next available (unallocated)
 spinlock.  If no more
   locks are available, it returns NULL.
 struct hwspinlock *hwspinlock_request_specific(unsigned int);
   Provides for static allocation of a specific hardware
 spinlock. This
   allows the system to use a specific spinlock,
 identified by an ID. If
   the ID is invalid or if the desired lock is already
 allocated, this
   will return NULL.  Otherwise it returns a spinlock handle.
 int hwspinlock_free(struct hwspinlock *);
   Frees an allocated hardware spinlock (either reserved
 or unreserved).

 Signed-off-by: Simon Que s...@ti.com
 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 ---
  arch/arm/mach-omap2/hwspinlocks.c|   70 ++
  arch/arm/plat-omap/hwspinlock.c  |  335
 ++
  arch/arm/plat-omap/include/plat/hwspinlock.h |   29 +++
  3 files changed, 434 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/mach-omap2/hwspinlocks.c
  create mode 100644 arch/arm/plat-omap/hwspinlock.c
  create mode 100644 arch/arm/plat-omap/include/plat/hwspinlock.h

 diff --git a/arch/arm/mach-omap2/hwspinlocks.c
 b/arch/arm/mach-omap2/hwspinlocks.c
 new file mode 100644
 index 000..f0f05e1
 --- /dev/null
 +++ b/arch/arm/mach-omap2/hwspinlocks.c
 @@ -0,0 +1,70 @@
 +/*
 + * OMAP hardware spinlock device initialization
 + *
 + * Copyright (C) 2010 Texas Instruments. All rights reserved.
 + *
 + * Contact: Simon Que s...@ti.com
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License
 + * version 2 as published by the Free Software Foundation.
 + *
 + * 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., 51 Franklin St, Fifth Floor, Boston, MA
 + * 02110-1301 USA
 + *
 + */
 +
 +#include linux/module.h
 +#include linux/interrupt.h
 +#include linux/device.h
 +#include linux/delay.h
 +#include linux/io.h
 +#include linux/slab.h
 +
 +#include plat/hwspinlock.h
 +#include plat/omap_device.h
 +#include plat/omap_hwmod.h
 +
 +/* Spinlock register offsets */
 +#define REVISION_OFFSET 

RE: [PATCH 5/5] omap:hwspinlocks-ensure the order of registration

2010-07-28 Thread Premi, Sanjeev
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kanigeri, Hari
 Sent: Monday, July 19, 2010 10:20 PM
 To: Linux Omap; Tony Lindgren
 Cc: Shilimkar, Santosh; Cousson, Benoit; Que, Simon; Kanigeri, Hari
 Subject: [PATCH 5/5] omap:hwspinlocks-ensure the order of registration
 
 Ensure that the hwspinlock driver is registered prior to
 I2C driver registration since I2C is dependent on hwspinlock.

[sp] Is there another patch where this dependency is introduced?

 
 Signed-off-by: Hari Kanigeri h-kanige...@ti.com
 ---
  arch/arm/mach-omap2/hwspinlocks.c |2 +-
  arch/arm/plat-omap/hwspinlock.c   |3 +--
  2 files changed, 2 insertions(+), 3 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/hwspinlocks.c 
 b/arch/arm/mach-omap2/hwspinlocks.c
 index f0f05e1..a9f85b9 100644
 --- a/arch/arm/mach-omap2/hwspinlocks.c
 +++ b/arch/arm/mach-omap2/hwspinlocks.c
 @@ -67,4 +67,4 @@ int __init hwspinlocks_init(void)
  
   return retval;
  }
 -module_init(hwspinlocks_init);
 +postcore_initcall(hwspinlocks_init);
 diff --git a/arch/arm/plat-omap/hwspinlock.c 
 b/arch/arm/plat-omap/hwspinlock.c
 index 1883add..3742b04 100644
 --- a/arch/arm/plat-omap/hwspinlock.c
 +++ b/arch/arm/plat-omap/hwspinlock.c
 @@ -309,6 +309,7 @@ static int __init hwspinlock_init(void)
  
   return retval;
  }
 +postcore_initcall(hwspinlock_init);
  
  /* Cleanup function */
  static void __exit hwspinlock_exit(void)
 @@ -325,8 +326,6 @@ static void __exit hwspinlock_exit(void)
   if (hwspinlock_module-is_init)
   kfree(hwspinlocks);
  }
 -
 -module_init(hwspinlock_init);
  module_exit(hwspinlock_exit);
  
  MODULE_LICENSE(GPL v2);
 -- 
 1.7.0
 
 --
 To unsubscribe from this list: send the line unsubscribe 
 linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 --
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH resend] OMAP: DSS2: Replace strncmp() with sysfs_streq() in overlay_manager_store()

2010-07-28 Thread Premi, Sanjeev
 

 -Original Message-
 From: Taneja, Archit 
 Sent: Wednesday, July 28, 2010 8:06 PM
 To: Premi, Sanjeev; tomi.valkei...@nokia.com
 Cc: linux-omap@vger.kernel.org
 Subject: RE: [PATCH resend] OMAP: DSS2: Replace strncmp() 
 with sysfs_streq() in overlay_manager_store()
 
  
 
  -Original Message-
  From: Premi, Sanjeev 
  Sent: Wednesday, July 28, 2010 7:28 PM
  To: Taneja, Archit; tomi.valkei...@nokia.com
  Cc: linux-omap@vger.kernel.org
  Subject: RE: [PATCH resend] OMAP: DSS2: Replace strncmp() 
  with sysfs_streq() in overlay_manager_store()
  
   -Original Message-
   From: linux-omap-ow...@vger.kernel.org 
   [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of 
  Taneja, Archit
   Sent: Wednesday, July 28, 2010 11:52 AM
   To: tomi.valkei...@nokia.com
   Cc: linux-omap@vger.kernel.org; Taneja, Archit
   Subject: [PATCH resend] OMAP: DSS2: Replace strncmp() with
   sysfs_streq() in overlay_manager_store()
   
   In the function overlay_manager_store, the length of the 
  string buf is 
   used to comapre the 2 strings, there is a possibility of false 
   positive match if buf is a prefix string of another manager.
   
   The use of sysfs_streq() fixes this.
   
   Signed-off-by: Archit Taneja arc...@ti.com
   ---
drivers/video/omap2/dss/overlay.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
   
   diff --git a/drivers/video/omap2/dss/overlay.c
   b/drivers/video/omap2/dss/overlay.c
   index 8233658..244dca8
   --- a/drivers/video/omap2/dss/overlay.c
   +++ b/drivers/video/omap2/dss/overlay.c
   @@ -65,7 +65,7 @@ static ssize_t overlay_manager_store(struct 
   omap_overlay *ovl, const char *buf,
 for (i = 0; i 
   omap_dss_get_num_overlay_managers(); ++i) {
 mgr = omap_dss_get_overlay_manager(i);

   - if (strncmp(buf, mgr-name, len) == 0)
   + if (sysfs_streq(buf, mgr-name))
  
  [sp] sysfs_streq() ignores trailing newlines during comparison. So,
   the possibility mentioned in the description still stays.
 
 The aim is to compare one string which is a sysfs input and the other
 which is in the kernel. 
 
  
   I am not familiar with overall context; but wouldn't srtcmp()
   be the right choice? unless, of course, either of strings
   being compared are not null terminated.
 
 The sysfs input will have a newline and null at the end whereas the
 other string will only have null, strcmp will fail when we 
 want the two
 strings to match.
 
 Eg. Sysfs input lcd\n\0
 Kernel string lcd\0
 
 strcmp will fail here

[sp] If the patch is intending to fix this condition, then it isn't
 evident from the description. You should consider updating the
 description.

 
  
 break;

 mgr = NULL;
   --
   1.5.4.7
   
   --
   To unsubscribe from this list: send the line unsubscribe 
  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 5/5] omap:hwspinlocks-ensure the order of registration

2010-07-28 Thread Kanigeri, Hari
Sanjeev,

Thanks for your comments.

 
  -Original Message-
  From: linux-omap-ow...@vger.kernel.org
  [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kanigeri, Hari
  Sent: Monday, July 19, 2010 10:20 PM
  To: Linux Omap; Tony Lindgren
  Cc: Shilimkar, Santosh; Cousson, Benoit; Que, Simon; Kanigeri, Hari
  Subject: [PATCH 5/5] omap:hwspinlocks-ensure the order of registration
 
  Ensure that the hwspinlock driver is registered prior to
  I2C driver registration since I2C is dependent on hwspinlock.
 
 [sp] Is there another patch where this dependency is introduced?

Basically, hwspinlock driver should be registered prior to any other modules 
that uses it. I2C driver is currently using hwspinlock and we noticed an issue 
if hwspinlock wasn't registered early on.

I don't know if the I2C patch was communicated on mailing list yet. Balaji, can 
you please share your patch.

 
 

Best regards,
Hari
--
To unsubscribe from this list: send the line unsubscribe 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] staging:ti dspbridge: remove unnecessary check for NULL pointer in cmm.c

2010-07-28 Thread Felipe Contreras
Hi Ernesto,

On Wed, Jul 28, 2010 at 7:53 PM, Ramos Falcon, Ernesto erne...@ti.com wrote:
here is a better approach:
remove cmm_xlator_delete altogether

[...]

 I considered this approach before but in terms of maintainability I thought 
 it was easier to locate where translator tables are destroy if we keep 
 cmm_xlator_delete function.

That's not maintainability, that's debugging convenience. AFAIU linux
is all about maintenance, because that provides real, tangible, and
proven gains. Debugging convenience gains are hypothetical; you don't
really know how useful it will be to have a separate free function.

And please avoid bottom-posting, instead use interleaved style,
otherwise people see a comment, and then have to scroll down to see
the answer.
http://en.wikipedia.org/wiki/Posting_style#Interleaved_style

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe 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] staging:ti dspbridge: remove unnecessary check for NULL pointer in cmm.c

2010-07-28 Thread Ramos Falcon, Ernesto
Agree! I'll send new version of this patch.

-Original Message-
From: Felipe Contreras [mailto:felipe.contre...@gmail.com]
Sent: Wednesday, July 28, 2010 12:12 PM
To: Ramos Falcon, Ernesto
Cc: Menon, Nishanth; gre...@suse.de; Ramirez Luna, Omar; o...@wizery.com;
ameya.pala...@nokia.com; felipe.contre...@nokia.com; Guzman Lugo, Fernando;
linux-ker...@vger.kernel.org; andy.shevche...@gmail.com; linux-
o...@vger.kernel.org
Subject: Re: [PATCH 2/5] staging:ti dspbridge: remove unnecessary check for
NULL pointer in cmm.c

Hi Ernesto,

On Wed, Jul 28, 2010 at 7:53 PM, Ramos Falcon, Ernesto erne...@ti.com
wrote:
here is a better approach:
remove cmm_xlator_delete altogether

[...]

 I considered this approach before but in terms of maintainability I
thought it was easier to locate where translator tables are destroy if we
keep cmm_xlator_delete function.

That's not maintainability, that's debugging convenience. AFAIU linux
is all about maintenance, because that provides real, tangible, and
proven gains. Debugging convenience gains are hypothetical; you don't
really know how useful it will be to have a separate free function.

And please avoid bottom-posting, instead use interleaved style,
otherwise people see a comment, and then have to scroll down to see
the answer.
http://en.wikipedia.org/wiki/Posting_style#Interleaved_style

--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe 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 0/8] TI TILER-DMM driver

2010-07-28 Thread Hiremath, Vaibhav
 -Original Message-
 From: Sin, David
 Sent: Wednesday, July 28, 2010 8:53 PM
 To: Hans Verkuil
 Cc: linux-omap@vger.kernel.org; Tony Lindgren; Russell King; Kanigeri, Hari;
 Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar, Santosh; linux-arm-
 ker...@lists.infradead.org
 Subject: RE: [RFC 0/8] TI TILER-DMM driver
 
  -Original Message-
  From: Hans Verkuil [mailto:hverk...@xs4all.nl]
  Sent: Saturday, July 24, 2010 6:13 AM
  To: Sin, David
  Cc: linux-arm-ker...@lists.arm.linux.org.uk;
  linux-omap@vger.kernel.org; Tony Lindgren; Russell King;
  Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar, Santosh
  Subject: Re: [RFC 0/8] TI TILER-DMM driver
 
  Hi David,
 
snip

  The main question that I have is how this driver is to be
  used in practice.
  How does it fit into the bigger video4linux picture? Is this
  something that
  is mainly used from other v4l or fb drivers? Or is it
  controlled by userspace?
 
 [dhs] I missed this one -- my apologies.  As I stated to Vaibhav, any device
 can use TILER memory, but there is a big advantage, performance-wise, for 2-
 Dimensional macro block based buffers.  This HW is intended for image/video
 hardware accelerators (e.g. OMAP4 IVA-HD).  Plus there's the added advantage
 of doing zero-copy flips and rotations for the OMAP display and image sub-
 systems.
 
 In this RFC, there are only kernel APIs to allocate TILER memory.
 Eventually, we would like to provide a way to obtain TILER memory to the
 user space.
 
[Hiremath, Vaibhav] Don't you think, user has to mmap memory (irrespective of 
whether it is tiles view or not) to userland in both the cases, Fbdev and V4L2 
(MMAP mode)?

Am I missing something here?

Thanks,
Vaibhav

 
  Regards,
 
  Hans
 
  
   List of pending items in proposed order:
  
   * Add area packing support (multiple blocks can reside in
  the same band/area)
 to optimize area use
   * Add group-ID support (to specify which blocks can reside
  together in the
 same area)
   * Add multiple search directions to TCM-SiTA
   * Add 1D block support (including adding 1D search algo to TCM-SiTA)
   * Optimize mutex handling (don.t hold mutex during memory
 allocation/mapping/cache flushing)
   * Add block reference counting, support for sharing blocks
   * Move all kernel-API-s to tiler-iface.c
   * Support orphaned block support (in preparation for
  process cleanup support)
   * Change block identification from physical address to key-ID pair
 (in preparation for user space support, and process security)
   * Add support for process security (blocks from separate
  processes never
 reside in the same band)
   * Support file interface (ioctl and mmap)
   * Support for buffers (ordered list of blocks that are
  mapped to userspace
 together, such as YUV420sp)
   * Support 1D user buffer mapping into TILER container
   * Support for block pre-reservation (to further optimize area use)
  
   David Sin (1):
 TILER-DMM: DMM-PAT driver for TI TILER
  
   Lajos Molnar (6):
 TILER-DMM: Container manager interface and utility definitons
 TILER-DMM: TILER Memory Manager interface and implementation
 TILER-DMM: TILER interface file and documentation
 TILER-DMM: Geometry and view manipulation functions.
 TILER-DMM: Main TILER driver implementation.
 TILER-DMM: Linking TILER driver into the Linux kernel build
  
   Ravi Ramachandra (1):
 TILER-DMM: Sample TCM implementation: Simple TILER Allocator
  
Documentation/arm/TILER   |  144 +
arch/arm/mach-omap2/include/mach/dmm.h|  128 
arch/arm/mach-omap2/include/mach/tiler.h  |  201 +
drivers/media/Kconfig |6 +
drivers/media/Makefile|2 +
drivers/media/video/tiler/Kconfig |   65 
drivers/media/video/tiler/Makefile|7 +
drivers/media/video/tiler/_tiler.h|   51 
drivers/media/video/tiler/dmm.c   |  200 +
drivers/media/video/tiler/tcm.h   |  209 +
drivers/media/video/tiler/tcm/Makefile|1 +
drivers/media/video/tiler/tcm/_tcm-sita.h |   64 
drivers/media/video/tiler/tcm/tcm-sita.c  |  459
  +
drivers/media/video/tiler/tcm/tcm-sita.h  |   37 +++
drivers/media/video/tiler/tcm/tcm-utils.h |   54 
drivers/media/video/tiler/tiler-geom.c|  360
  ++
drivers/media/video/tiler/tiler-iface.c   |  106 +++
drivers/media/video/tiler/tiler-main.c|  426
  ++
drivers/media/video/tiler/tmm-pat.c   |  274 +
drivers/media/video/tiler/tmm.h   |  109 +++
20 files changed, 2903 insertions(+), 0 deletions(-)
create mode 100644 Documentation/arm/TILER
create mode 100644 arch/arm/mach-omap2/include/mach/dmm.h
create mode 100644 arch/arm/mach-omap2/include/mach/tiler.h
   

Re: [PATCH 5/5] staging:ti dspbridge: replace simple_strtoul by strict_strtoul

2010-07-28 Thread Andy Shevchenko
On Wed, Jul 28, 2010 at 6:09 PM, Greg KH gre...@suse.de wrote:
 On Wed, Jul 28, 2010 at 09:40:52AM -0500, Ernesto Ramos wrote:
 Replace simple_strtoul by strict_strtoul in atoi function.

 Why not use the built-in kernel function instead of having your own atoi
 function?
The commit message left opened questions about
http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=commit;h=b8af1123b47741086ef5a307ad1ec8fec6fc7f0d

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line unsubscribe 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/5] staging:ti dspbridge: replace simple_strtoul by strict_strtoul

2010-07-28 Thread Andy Shevchenko
On Wed, Jul 28, 2010 at 5:40 PM, Ernesto Ramos erne...@ti.com wrote:
 Replace simple_strtoul by strict_strtoul in atoi function.
In general the question what is the purpose here to do the change?

 @@ -1023,7 +1025,9 @@ static s32 atoi(char *psz_buf)
                base = 16;
        }

 -       return simple_strtoul(pch, NULL, base);
 +       ret_val = strict_strtoul(pch, base, res);
 +
 +       return ret_val ? : res;
May be better to use explicit values in condition?

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line unsubscribe 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/5] staging:ti dspbridge: replace simple_strtoul by strict_strtoul

2010-07-28 Thread Greg KH
On Wed, Jul 28, 2010 at 09:40:19PM +0300, Andy Shevchenko wrote:
 On Wed, Jul 28, 2010 at 6:09 PM, Greg KH gre...@suse.de wrote:
  On Wed, Jul 28, 2010 at 09:40:52AM -0500, Ernesto Ramos wrote:
  Replace simple_strtoul by strict_strtoul in atoi function.
 
  Why not use the built-in kernel function instead of having your own atoi
  function?
 The commit message left opened questions about
 http://dev.omapzoom.org/?p=tidspbridge/kernel-dspbridge.git;a=commit;h=b8af1123b47741086ef5a307ad1ec8fec6fc7f0d

Ok, but you will have to fix this up eventually, you need to use the
in-kernel library functions, or fix the in-kernel ones to add the
support you need.

thanks,

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


RE: [RFC 0/8] TI TILER-DMM driver

2010-07-28 Thread Sin, David
 -Original Message-
 From: Hiremath, Vaibhav 
 Sent: Wednesday, July 28, 2010 12:31 PM
 To: Sin, David; Hans Verkuil
 Cc: linux-omap@vger.kernel.org; Tony Lindgren; Russell King; 
 Kanigeri, Hari; Ohad Ben-Cohen; Shilimkar, Santosh; 
 linux-arm-ker...@lists.infradead.org
 Subject: RE: [RFC 0/8] TI TILER-DMM driver
 
  -Original Message-
  From: Sin, David
  Sent: Wednesday, July 28, 2010 8:53 PM
  To: Hans Verkuil
  Cc: linux-omap@vger.kernel.org; Tony Lindgren; Russell 
 King; Kanigeri, Hari;
  Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar, Santosh; linux-arm-
  ker...@lists.infradead.org
  Subject: RE: [RFC 0/8] TI TILER-DMM driver
  
   -Original Message-
   From: Hans Verkuil [mailto:hverk...@xs4all.nl]
   Sent: Saturday, July 24, 2010 6:13 AM
   To: Sin, David
   Cc: linux-arm-ker...@lists.arm.linux.org.uk;
   linux-omap@vger.kernel.org; Tony Lindgren; Russell King;
   Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; 
 Shilimkar, Santosh
   Subject: Re: [RFC 0/8] TI TILER-DMM driver
  
   Hi David,
  
 snip
 
   The main question that I have is how this driver is to be
   used in practice.
   How does it fit into the bigger video4linux picture? Is this
   something that
   is mainly used from other v4l or fb drivers? Or is it
   controlled by userspace?
  
  [dhs] I missed this one -- my apologies.  As I stated to 
 Vaibhav, any device
  can use TILER memory, but there is a big advantage, 
 performance-wise, for 2-
  Dimensional macro block based buffers.  This HW is intended 
 for image/video
  hardware accelerators (e.g. OMAP4 IVA-HD).  Plus there's 
 the added advantage
  of doing zero-copy flips and rotations for the OMAP display 
 and image sub-
  systems.
  
  In this RFC, there are only kernel APIs to allocate TILER memory.
  Eventually, we would like to provide a way to obtain TILER 
 memory to the
  user space.
  
 [Hiremath, Vaibhav] Don't you think, user has to mmap memory 
 (irrespective of whether it is tiles view or not) to userland 
 in both the cases, Fbdev and V4L2 (MMAP mode)?
 
 Am I missing something here?
 
 Thanks,
 Vaibhav
 

[dhs] You're right; this is needed.  However, I first wanted to get some 
feedback for allocating 2-D memory just from kernel space.  

  
   Regards,
  
 Hans
  
   
List of pending items in proposed order:
   
* Add area packing support (multiple blocks can reside in
   the same band/area)
  to optimize area use
* Add group-ID support (to specify which blocks can reside
   together in the
  same area)
* Add multiple search directions to TCM-SiTA
* Add 1D block support (including adding 1D search algo 
 to TCM-SiTA)
* Optimize mutex handling (don.t hold mutex during memory
  allocation/mapping/cache flushing)
* Add block reference counting, support for sharing blocks
* Move all kernel-API-s to tiler-iface.c
* Support orphaned block support (in preparation for
   process cleanup support)
* Change block identification from physical address to 
 key-ID pair
  (in preparation for user space support, and process security)
* Add support for process security (blocks from separate
   processes never
  reside in the same band)
* Support file interface (ioctl and mmap)
* Support for buffers (ordered list of blocks that are
   mapped to userspace
  together, such as YUV420sp)
* Support 1D user buffer mapping into TILER container
* Support for block pre-reservation (to further 
 optimize area use)
   
David Sin (1):
  TILER-DMM: DMM-PAT driver for TI TILER
   
Lajos Molnar (6):
  TILER-DMM: Container manager interface and utility definitons
  TILER-DMM: TILER Memory Manager interface and implementation
  TILER-DMM: TILER interface file and documentation
  TILER-DMM: Geometry and view manipulation functions.
  TILER-DMM: Main TILER driver implementation.
  TILER-DMM: Linking TILER driver into the Linux kernel build
   
Ravi Ramachandra (1):
  TILER-DMM: Sample TCM implementation: Simple TILER Allocator
   
 Documentation/arm/TILER   |  144 +
 arch/arm/mach-omap2/include/mach/dmm.h|  128 
 arch/arm/mach-omap2/include/mach/tiler.h  |  201 +
 drivers/media/Kconfig |6 +
 drivers/media/Makefile|2 +
 drivers/media/video/tiler/Kconfig |   65 
 drivers/media/video/tiler/Makefile|7 +
 drivers/media/video/tiler/_tiler.h|   51 
 drivers/media/video/tiler/dmm.c   |  200 +
 drivers/media/video/tiler/tcm.h   |  209 +
 drivers/media/video/tiler/tcm/Makefile|1 +
 drivers/media/video/tiler/tcm/_tcm-sita.h |   64 
 drivers/media/video/tiler/tcm/tcm-sita.c  |  459
   +
 drivers/media/video/tiler/tcm/tcm-sita.h  |   37 +++
 drivers/media/video/tiler/tcm/tcm-utils.h | 

Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host

2010-07-28 Thread Vitaly Wool
Hi Ohad,

On Wed, Jul 21, 2010 at 7:33 PM, Ohad Ben-Cohen o...@wizery.com wrote:
 Add support to set/get mmc_host private embedded
 data.

 This is needed to allow software to dynamically
 create (and remove) SDIO functions which represents
 embedded SDIO devices.

snip
 @@ -209,6 +209,8 @@ struct mmc_host {
        struct led_trigger      *led;           /* activity led */
  #endif

 +       void                    *embedded_data;
 +

To my understanding, this data doesn't belong to mmc_host. It's not a
host data at all. E. g. imagine a GPIO IRQ for some SDIO chip -- it's
totally unrelated to host.

I think a cleaner way would be to introduce something similar to what
we have for SPI, e. g. struct sdio_board_info. This board info will
contain platform-specific stuff and vendor id/chip id for each onboard
SDIO device. Then the SDIO core will pick up the appropriate data
basing on vendor id/chip id.

~Vitaly
--
To unsubscribe from this list: send the line unsubscribe 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/5] use idr kernel library instead of handles

2010-07-28 Thread Ernesto Ramos
From: Rene Sapiens rene.sapi...@ti.com

Use idr kernel library to send/receive node and stream ids to the
user instead of kernel address.
This id will be use to access the node and stream handles at the
kernel side, if id does not match to any handle
error -EFAULT is returned.

For processor handle, dspbridge driver will make sure
the handle is valid by using the handle stored in process context.

Ernesto Ramos (5):
  staging:ti dspbridge: use node id instead of kernel address
  staging:ti dspbridge: avoid errors if node handle is zero
  staging:ti dspbridge: use processor handle from context instead of
user's
  staging:ti dspbridge: use stream id instead of kernel address
  staging:ti dspbridge: avoid errors if stream id is zero

 .../staging/tidspbridge/include/dspbridge/drv.h|   11 +-
 .../staging/tidspbridge/include/dspbridge/node.h   |   14 +-
 .../include/dspbridge/resourcecleanup.h|   12 -
 .../staging/tidspbridge/include/dspbridge/strm.h   |   22 +-
 drivers/staging/tidspbridge/pmgr/dspapi.c  |  329 
 drivers/staging/tidspbridge/rmgr/drv.c |  303 ++-
 drivers/staging/tidspbridge/rmgr/drv_interface.c   |   18 +-
 drivers/staging/tidspbridge/rmgr/node.c|  109 ---
 drivers/staging/tidspbridge/rmgr/strm.c|   54 ++--
 9 files changed, 485 insertions(+), 387 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] staging:ti dspbridge: use stream id instead of kernel address

2010-07-28 Thread Ernesto Ramos
Send stream ids to the user instead of handles, then when
the id is coming from user dspbridge can retrive the handle
using id and avoid using invalid handles.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 .../staging/tidspbridge/include/dspbridge/drv.h|5 +-
 .../include/dspbridge/resourcecleanup.h|6 -
 .../staging/tidspbridge/include/dspbridge/strm.h   |   22 ++--
 drivers/staging/tidspbridge/pmgr/dspapi.c  |  115 +---
 drivers/staging/tidspbridge/rmgr/drv.c |  148 +++-
 drivers/staging/tidspbridge/rmgr/drv_interface.c   |   13 ++-
 drivers/staging/tidspbridge/rmgr/strm.c|   54 +++
 7 files changed, 193 insertions(+), 170 deletions(-)

diff --git a/drivers/staging/tidspbridge/include/dspbridge/drv.h 
b/drivers/staging/tidspbridge/include/dspbridge/drv.h
index 0b36a11..f365015 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/drv.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/drv.h
@@ -131,7 +131,7 @@ struct strm_res_object {
void *hstream;
u32 num_bufs;
u32 dir;
-   struct strm_res_object *next;
+   int id;
 };
 
 /* Overall Bridge process resource usage state */
@@ -173,8 +173,7 @@ struct process_context {
struct dspheap_res_object *pdspheap_list;
 
/* Stream resources */
-   struct strm_res_object *pstrm_list;
-   struct mutex strm_mutex;
+   struct idr *stream_id;
 };
 
 /*
diff --git a/drivers/staging/tidspbridge/include/dspbridge/resourcecleanup.h 
b/drivers/staging/tidspbridge/include/dspbridge/resourcecleanup.h
index d17c7fb..dfaf0c6 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/resourcecleanup.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/resourcecleanup.h
@@ -47,12 +47,6 @@ extern int drv_proc_insert_strm_res_element(void *stream_obj,
   void *strm_res,
   void *process_ctxt);
 
-extern int drv_get_strm_res_element(void *stream_obj, void *strm_resources,
-  void *process_ctxt);
-
-extern int drv_proc_remove_strm_res_element(void *strm_res,
-  void *process_ctxt);
-
 extern int drv_remove_all_strm_res_elements(void *process_ctxt);
 
 extern enum node_state node_get_state(void *hnode);
diff --git a/drivers/staging/tidspbridge/include/dspbridge/strm.h 
b/drivers/staging/tidspbridge/include/dspbridge/strm.h
index 0ddc797..3e4671e 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/strm.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/strm.h
@@ -29,7 +29,7 @@
  *  Purpose:
  *  Allocate data buffer(s) for use with a stream.
  *  Parameter:
- *  stream_obj: Stream handle returned from strm_open().
+ *  strmres: Stream resource info handle returned from strm_open().
  *  usize:  Size (GPP bytes) of the buffer(s).
  *  num_bufs:   Number of buffers to allocate.
  *  ap_buffer:   Array to hold buffer addresses.
@@ -44,7 +44,7 @@
  *  ap_buffer != NULL.
  *  Ensures:
  */
-extern int strm_allocate_buffer(struct strm_object *stream_obj,
+extern int strm_allocate_buffer(struct strm_res_object *strmres,
   u32 usize,
   u8 **ap_buffer,
   u32 num_bufs,
@@ -55,7 +55,7 @@ extern int strm_allocate_buffer(struct strm_object 
*stream_obj,
  *  Purpose:
  *  Close a stream opened with strm_open().
  *  Parameter:
- *  stream_obj:  Stream handle returned from strm_open().
+ *  strmres:  Stream resource info handle returned from 
strm_open().
  *  Returns:
  *  0:Success.
  *  -EFAULT:Invalid stream_obj.
@@ -66,7 +66,7 @@ extern int strm_allocate_buffer(struct strm_object 
*stream_obj,
  *  strm_init(void) called.
  *  Ensures:
  */
-extern int strm_close(struct strm_object *stream_obj,
+extern int strm_close(struct strm_res_object *strmres,
 struct process_context *pr_ctxt);
 
 /*
@@ -125,7 +125,7 @@ extern void strm_exit(void);
  *  Purpose:
  *  Free buffer(s) allocated with strm_allocate_buffer.
  *  Parameter:
- *  stream_obj: Stream handle returned from strm_open().
+ *  strmres: Stream resource info handle returned from strm_open().
  *  ap_buffer:   Array containing buffer addresses.
  *  num_bufs:   Number of buffers to be freed.
  *  Returns:
@@ -137,7 +137,7 @@ extern void strm_exit(void);
  *  ap_buffer != NULL.
  *  Ensures:
  */
-extern int strm_free_buffer(struct strm_object *stream_obj,
+extern int strm_free_buffer(struct strm_res_object *strmres,
   u8 **ap_buffer, u32 num_bufs,
   struct process_context *pr_ctxt);
 
@@ -254,7 +254,7 @@ extern int strm_issue(struct strm_object 

[PATCH] staging:ti dspbridge: use node id instead of kernel address

2010-07-28 Thread Ernesto Ramos
Use idr kernel library to send/receive node ids to the
user instead of kernel address.
This id will be use to access the node handles at the
kernel side, if id does not match to any handle
error -EFAULT is returned.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 .../staging/tidspbridge/include/dspbridge/drv.h|6 +-
 .../staging/tidspbridge/include/dspbridge/node.h   |   14 +-
 .../include/dspbridge/resourcecleanup.h|6 -
 drivers/staging/tidspbridge/pmgr/dspapi.c  |  158 +---
 drivers/staging/tidspbridge/rmgr/drv.c |  151 ++-
 drivers/staging/tidspbridge/rmgr/drv_interface.c   |7 +-
 drivers/staging/tidspbridge/rmgr/node.c|  109 +++---
 7 files changed, 256 insertions(+), 195 deletions(-)

diff --git a/drivers/staging/tidspbridge/include/dspbridge/drv.h 
b/drivers/staging/tidspbridge/include/dspbridge/drv.h
index 28541f7..0b36a11 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/drv.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/drv.h
@@ -24,6 +24,7 @@
 #include dspbridge/devdefs.h
 
 #include dspbridge/drvdefs.h
+#include linux/idr.h
 
 #define DRV_ASSIGN 1
 #define DRV_RELEASE0
@@ -81,7 +82,7 @@ struct node_res_object {
s32 node_allocated; /* Node status */
s32 heap_allocated; /* Heap status */
s32 streams_allocated;  /* Streams status */
-   struct node_res_object *next;
+   int id;
 };
 
 /* used to cache dma mapping information */
@@ -158,8 +159,7 @@ struct process_context {
void *hprocessor;
 
/* DSP Node resources */
-   struct node_res_object *node_list;
-   struct mutex node_mutex;
+   struct idr *node_id;
 
/* DMM mapped memory resources */
struct list_head dmm_map_list;
diff --git a/drivers/staging/tidspbridge/include/dspbridge/node.h 
b/drivers/staging/tidspbridge/include/dspbridge/node.h
index 61d2d9b..49ed5c1 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/node.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/node.h
@@ -36,7 +36,7 @@
  *  pargs:  Optional arguments to be passed to the node.
  *  attr_in:Optional pointer to node attributes (priority,
  *  timeout...)
- *  ph_node: Location to store node handle on output.
+ *  noderes: Location to store node resource info.
  *  Returns:
  *  0:Success.
  *  -ENOMEM:Insufficient memory on GPP.
@@ -50,17 +50,17 @@
  *  node_init(void) called.
  *  hprocessor != NULL.
  *  node_uuid != NULL.
- *  ph_node != NULL.
+ *  noderes != NULL.
  *  Ensures:
  *  0:IsValidNode(*ph_node).
- *  error:  *ph_node == NULL.
+ *  error:  *noderes == NULL.
  */
 extern int node_allocate(struct proc_object *hprocessor,
const struct dsp_uuid *node_uuid,
const struct dsp_cbdata
*pargs, const struct dsp_nodeattrin
*attr_in,
-   struct node_object **ph_node,
+   struct node_res_object **noderes,
struct process_context *pr_ctxt);
 
 /*
@@ -242,7 +242,9 @@ extern int node_create_mgr(struct node_mgr **node_man,
  *  delete function. Loads the node's delete function if necessary.
  *  GPP side resources are freed after node's delete function returns.
  *  Parameters:
- *  hnode:  Node handle returned from node_allocate().
+ *  noderes:  Node resource info handle returned from
+ * node_allocate().
+ *  pr_ctxt:Poninter to process context data.
  *  Returns:
  *  0:Success.
  *  -EFAULT:Invalid hnode.
@@ -254,7 +256,7 @@ extern int node_create_mgr(struct node_mgr **node_man,
  *  Ensures:
  *  0:hnode is invalid.
  */
-extern int node_delete(struct node_object *hnode,
+extern int node_delete(struct node_res_object *noderes,
  struct process_context *pr_ctxt);
 
 /*
diff --git a/drivers/staging/tidspbridge/include/dspbridge/resourcecleanup.h 
b/drivers/staging/tidspbridge/include/dspbridge/resourcecleanup.h
index 4e1b8a2..d17c7fb 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/resourcecleanup.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/resourcecleanup.h
@@ -34,17 +34,11 @@ extern int drv_remove_all_resources(void *process_ctxt);
 extern int drv_remove_proc_context(struct drv_object *driver_obj,
  void *pr_ctxt);
 
-extern int drv_get_node_res_element(void *hnode, void *node_resource,
-  void *process_ctx);
-
 extern int drv_insert_node_res_element(void *hnode, void *node_resource,
   

[PATCH] staging:ti dspbridge: avoid errors if node handle is zero

2010-07-28 Thread Ernesto Ramos
As 'zero' can be a perfectly good id, it can be picked up as
a NULL from userspace, avoid issues in API and user apps if node
handle is zero.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/pmgr/dspapi.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/tidspbridge/pmgr/dspapi.c 
b/drivers/staging/tidspbridge/pmgr/dspapi.c
index 6eda7c5..f46aaf6 100644
--- a/drivers/staging/tidspbridge/pmgr/dspapi.c
+++ b/drivers/staging/tidspbridge/pmgr/dspapi.c
@@ -1059,7 +1059,7 @@ inline void find_node_handle(struct node_res_object 
**noderes,
 {
rcu_read_lock();
*noderes = idr_find(((struct process_context *)pr_ctxt)-node_id,
-   (int)hnode);
+   (int)hnode - 1);
rcu_read_unlock();
return;
 }
@@ -1077,6 +1077,7 @@ u32 nodewrap_allocate(union trapped_args *args, void 
*pr_ctxt)
u8 *pargs = NULL;
struct dsp_nodeattrin proc_attr_in, *attr_in = NULL;
struct node_res_object *node_res;
+   int nodeid;
 
/* Optional argument */
if (psize) {
@@ -1112,7 +1113,8 @@ u32 nodewrap_allocate(union trapped_args *args, void 
*pr_ctxt)
   attr_in, node_res, pr_ctxt);
}
if (!status) {
-   CP_TO_USR(args-args_node_allocate.ph_node, node_res-id,
+   nodeid = node_res-id + 1;
+   CP_TO_USR(args-args_node_allocate.ph_node, nodeid,
status, 1);
if (status) {
status = -EFAULT;
-- 
1.5.4.5

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


[PATCH] staging:ti dspbridge: avoid errors if stream id is zero

2010-07-28 Thread Ernesto Ramos
As 'zero' can be a perfectly good id, it can be picked up as
a NULL from userspace, avoid issues in API and user apps if stream
handle is zero.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/pmgr/dspapi.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/tidspbridge/pmgr/dspapi.c 
b/drivers/staging/tidspbridge/pmgr/dspapi.c
index 47892dd..7b42f72 100644
--- a/drivers/staging/tidspbridge/pmgr/dspapi.c
+++ b/drivers/staging/tidspbridge/pmgr/dspapi.c
@@ -1527,7 +1527,7 @@ inline void find_strm_handle(struct strm_res_object 
**strmres,
 {
rcu_read_lock();
*strmres = idr_find(((struct process_context *)pr_ctxt)-stream_id,
-   (int)hstream);
+   (int)hstream - 1);
rcu_read_unlock();
return;
 }
@@ -1724,6 +1724,7 @@ u32 strmwrap_open(union trapped_args *args, void *pr_ctxt)
struct strm_res_object *strm_res_obj;
struct dsp_streamattrin strm_attr_in;
struct node_res_object *node_res;
+   int strmid;
 
find_node_handle(node_res, pr_ctxt, args-args_strm_open.hnode);
 
@@ -1745,7 +1746,10 @@ u32 strmwrap_open(union trapped_args *args, void 
*pr_ctxt)
   args-args_strm_open.direction,
   args-args_strm_open.index, attr, strm_res_obj,
   pr_ctxt);
-   CP_TO_USR(args-args_strm_open.ph_stream, strm_res_obj-id, status, 1);
+   if (!status) {
+   strmid = strm_res_obj-id + 1;
+   CP_TO_USR(args-args_strm_open.ph_stream, strmid, status, 1);
+   }
return status;
 }
 
-- 
1.5.4.5

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


[PATCH] staging:ti dspbridge: use processor handle from context instead of user's

2010-07-28 Thread Ernesto Ramos
Make sure dspbridge driver uses a valid processor handle by
using the handle stored in process context.

Signed-off-by: Ernesto Ramos erne...@ti.com
---
 drivers/staging/tidspbridge/pmgr/dspapi.c |   50 +
 1 files changed, 29 insertions(+), 21 deletions(-)

diff --git a/drivers/staging/tidspbridge/pmgr/dspapi.c 
b/drivers/staging/tidspbridge/pmgr/dspapi.c
index f46aaf6..d7613eb 100644
--- a/drivers/staging/tidspbridge/pmgr/dspapi.c
+++ b/drivers/staging/tidspbridge/pmgr/dspapi.c
@@ -616,6 +616,7 @@ u32 procwrap_ctrl(union trapped_args *args, void *pr_ctxt)
args-args_proc_ctrl.pargs;
u8 *pargs = NULL;
int status = 0;
+   void *hprocessor = ((struct process_context *)pr_ctxt)-hprocessor;
 
if (psize) {
if (get_user(cb_data_size, psize)) {
@@ -633,7 +634,7 @@ u32 procwrap_ctrl(union trapped_args *args, void *pr_ctxt)
  cb_data_size);
}
if (!status) {
-   status = proc_ctrl(args-args_proc_ctrl.hprocessor,
+   status = proc_ctrl(hprocessor,
   args-args_proc_ctrl.dw_cmd,
   (struct dsp_cbdata *)pargs);
}
@@ -663,11 +664,12 @@ u32 procwrap_enum_node_info(union trapped_args *args, 
void *pr_ctxt)
void *node_tab[MAX_NODES];
u32 num_nodes;
u32 alloc_cnt;
+   void *hprocessor = ((struct process_context *)pr_ctxt)-hprocessor;
 
if (!args-args_proc_enumnode_info.node_tab_size)
return -EINVAL;
 
-   status = proc_enum_nodes(args-args_proc_enumnode_info.hprocessor,
+   status = proc_enum_nodes(hprocessor,
 node_tab,
 args-args_proc_enumnode_info.node_tab_size,
 num_nodes, alloc_cnt);
@@ -747,13 +749,14 @@ u32 procwrap_enum_resources(union trapped_args *args, 
void *pr_ctxt)
 {
int status = 0;
struct dsp_resourceinfo resource_info;
+   void *hprocessor = ((struct process_context *)pr_ctxt)-hprocessor;
 
if (args-args_proc_enumresources.resource_info_size 
sizeof(struct dsp_resourceinfo))
return -EINVAL;
 
status =
-   proc_get_resource_info(args-args_proc_enumresources.hprocessor,
+   proc_get_resource_info(hprocessor,
   args-args_proc_enumresources.resource_type,
   resource_info,
   args-args_proc_enumresources.
@@ -773,13 +776,13 @@ u32 procwrap_get_state(union trapped_args *args, void 
*pr_ctxt)
 {
int status;
struct dsp_processorstate proc_state;
+   void *hprocessor = ((struct process_context *)pr_ctxt)-hprocessor;
 
if (args-args_proc_getstate.state_info_size 
sizeof(struct dsp_processorstate))
return -EINVAL;
 
-   status =
-   proc_get_state(args-args_proc_getstate.hprocessor, proc_state,
+   status = proc_get_state(hprocessor, proc_state,
   args-args_proc_getstate.state_info_size);
CP_TO_USR(args-args_proc_getstate.proc_state_obj, proc_state, status,
  1);
@@ -794,14 +797,14 @@ u32 procwrap_get_trace(union trapped_args *args, void 
*pr_ctxt)
 {
int status;
u8 *pbuf;
+   void *hprocessor = ((struct process_context *)pr_ctxt)-hprocessor;
 
if (args-args_proc_gettrace.max_size  MAX_TRACEBUFLEN)
return -EINVAL;
 
pbuf = kzalloc(args-args_proc_gettrace.max_size, GFP_KERNEL);
if (pbuf != NULL) {
-   status = proc_get_trace(args-args_proc_gettrace.hprocessor,
-   pbuf,
+   status = proc_get_trace(hprocessor, pbuf,
args-args_proc_gettrace.max_size);
} else {
status = -ENOMEM;
@@ -823,6 +826,7 @@ u32 procwrap_load(union trapped_args *args, void *pr_ctxt)
char *temp;
s32 count = args-args_proc_load.argc_index;
u8 **argv = NULL, **envp = NULL;
+   void *hprocessor = ((struct process_context *)pr_ctxt)-hprocessor;
 
if (count = 0 || count  MAX_LOADARGS) {
status = -EINVAL;
@@ -905,7 +909,7 @@ u32 procwrap_load(union trapped_args *args, void *pr_ctxt)
}
 
if (!status) {
-   status = proc_load(args-args_proc_load.hprocessor,
+   status = proc_load(hprocessor,
   args-args_proc_load.argc_index,
   (const char **)argv, (const char **)envp);
}
@@ -936,6 +940,7 @@ u32 procwrap_map(union trapped_args *args, void *pr_ctxt)
 {
int status;
void *map_addr;
+   void *hprocessor = ((struct process_context *)pr_ctxt)-hprocessor;
 
if (!args-args_proc_mapmem.ul_size)
return -EINVAL;
@@ 

RE: [PATCH resend] OMAP: DSS2: Replace strncmp() with sysfs_streq() in overlay_manager_store()

2010-07-28 Thread Taneja, Archit

-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
   Taneja, Archit
Sent: Wednesday, July 28, 2010 11:52 AM
To: tomi.valkei...@nokia.com
Cc: linux-omap@vger.kernel.org; Taneja, Archit
Subject: [PATCH resend] OMAP: DSS2: Replace strncmp() with
sysfs_streq() in overlay_manager_store()

In the function overlay_manager_store, the length of the
   string buf is
used to comapre the 2 strings, there is a possibility of false 
positive match if buf is a prefix string of another manager.

The use of sysfs_streq() fixes this.

Signed-off-by: Archit Taneja arc...@ti.com
---
 drivers/video/omap2/dss/overlay.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/video/omap2/dss/overlay.c
b/drivers/video/omap2/dss/overlay.c
index 8233658..244dca8
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -65,7 +65,7 @@ static ssize_t overlay_manager_store(struct 
omap_overlay *ovl, const char *buf,
for (i = 0; i 
omap_dss_get_num_overlay_managers(); ++i) {
mgr = omap_dss_get_overlay_manager(i);
 
-   if (strncmp(buf, mgr-name, len) == 0)
+   if (sysfs_streq(buf, mgr-name))
   
   [sp] sysfs_streq() ignores trailing newlines during 
 comparison. So,
the possibility mentioned in the description still stays.
  
  The aim is to compare one string which is a sysfs input and 
 the other 
  which is in the kernel.
  
   
I am not familiar with overall context; but wouldn't srtcmp()
be the right choice? unless, of course, either of strings
being compared are not null terminated.
  
  The sysfs input will have a newline and null at the end whereas the 
  other string will only have null, strcmp will fail when we want the 
  two strings to match.
  
  Eg. Sysfs input lcd\n\0
  Kernel string lcd\0
  
  strcmp will fail here
 
 [sp] If the patch is intending to fix this condition, then it isn't
  evident from the description. You should consider updating the
  description.

The patch isn't intending to fix this condition, this condition doesn't
occur at all in the existing code. I explained this to tell you why strcmp
is a bad choice, the patch description tells why sysfs_streq is a better
choice over strncmp.

 
  
   
break;
 
mgr = NULL;
--
1.5.4.7

--
To unsubscribe from this list: send the line unsubscribe
   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 3/5] omap:hwspinlock-added hwspinlock driver

2010-07-28 Thread Marathe, Yogesh


 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Premi, Sanjeev
 Sent: Wednesday, July 28, 2010 10:28 PM
 To: Kanigeri, Hari; Linux Omap; Tony Lindgren
 Cc: Shilimkar, Santosh; Cousson, Benoit; Que, Simon
 Subject: RE: [PATCH 3/5] omap:hwspinlock-added hwspinlock driver

  -Original Message-
  From: linux-omap-ow...@vger.kernel.org
  [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kanigeri, Hari
  Sent: Monday, July 19, 2010 10:20 PM
  To: Linux Omap; Tony Lindgren
  Cc: Shilimkar, Santosh; Cousson, Benoit; Que, Simon; Kanigeri, Hari
  Subject: [PATCH 3/5] omap:hwspinlock-added hwspinlock driver
 
  From: Simon Que s...@ti.com
 
  Created driver for OMAP hardware spinlock.  This driver supports:
  - Reserved spinlocks for internal use
 [sp] How do we reserver the spinlocks? I didn't see any API or parameter
  used to reserve them.
  If this refers to hwspinlock_request_specific(), then it isn't
  really reservation. Reservation is usually is blocks and I would
  expect range input.

  How is this reservation made known to other processors who would
  be attempting to use these spinlocks - in a multi processor scenario
  e.g. OMAP4. Both processors need to be aware of this reservation.

  - Dynamic allocation of unreserved locks
  - Lock, unlock, and trylock functions, with or without
  disabling irqs/preempt
  - Registered as a platform device driver
 
  The device initialization uses hwmod to configure the devices.
  One device will be created for each IP.  It will pass
  spinlock register offset
  info to the driver.  The device initialization file is:
arch/arm/mach-omap2/hwspinlocks.c
 
  The driver takes in register offset info passed in device
  initialization.
  It uses hwmod to obtain the base address of the hardware
  spinlock module.
  Then it reads info from the registers.  The function
  hwspinlock_probe()
  initializes the array of spinlock structures, each containing
  a spinlock
  register address calculated from the base address and lock offsets.
  The device driver file is:
arch/arm/plat-omap/hwspinlock.c
 
  Here's an API summary:
  int hwspinlock_lock(struct hwspinlock *);
Attempt to lock a hardware spinlock.  If it is busy,
  the function will
keep trying until it succeeds.  This is a blocking function.
  int hwspinlock_trylock(struct hwspinlock *);
Attempt to lock a hardware spinlock.  If it is busy,
  the function will
return BUSY.  If it succeeds in locking, the function
  will return
ACQUIRED.  This is a non-blocking function.
  int hwspinlock_unlock(struct hwspinlock *);
Unlock a hardware spinlock.
 
  struct hwspinlock *hwspinlock_request(void);
Provides for dynamic allocation of a hardware
  spinlock.  It returns
the handle to the next available (unallocated)
  spinlock.  If no more
locks are available, it returns NULL.
  struct hwspinlock *hwspinlock_request_specific(unsigned int);
Provides for static allocation of a specific hardware
  spinlock. This
allows the system to use a specific spinlock,
  identified by an ID. If
the ID is invalid or if the desired lock is already
  allocated, this
will return NULL.  Otherwise it returns a spinlock handle.
  int hwspinlock_free(struct hwspinlock *);
Frees an allocated hardware spinlock (either reserved
  or unreserved).
 
  Signed-off-by: Simon Que s...@ti.com
  Signed-off-by: Hari Kanigeri h-kanige...@ti.com
  ---
   arch/arm/mach-omap2/hwspinlocks.c|   70 ++
   arch/arm/plat-omap/hwspinlock.c  |  335
  ++
   arch/arm/plat-omap/include/plat/hwspinlock.h |   29 +++
   3 files changed, 434 insertions(+), 0 deletions(-)
   create mode 100644 arch/arm/mach-omap2/hwspinlocks.c
   create mode 100644 arch/arm/plat-omap/hwspinlock.c
   create mode 100644 arch/arm/plat-omap/include/plat/hwspinlock.h
 
  diff --git a/arch/arm/mach-omap2/hwspinlocks.c
  b/arch/arm/mach-omap2/hwspinlocks.c
  new file mode 100644
  index 000..f0f05e1
  --- /dev/null
  +++ b/arch/arm/mach-omap2/hwspinlocks.c
  @@ -0,0 +1,70 @@
  +/*
  + * OMAP hardware spinlock device initialization
  + *
  + * Copyright (C) 2010 Texas Instruments. All rights reserved.
  + *
  + * Contact: Simon Que s...@ti.com
  + *
  + * This program is free software; you can redistribute it and/or
  + * modify it under the terms of the GNU General Public License
  + * version 2 as published by the Free Software Foundation.
  + *
  + * 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 

RE: [PATCH resend] OMAP: DSS2: Replace strncmp() with sysfs_streq() in overlay_manager_store()

2010-07-28 Thread Premi, Sanjeev
 -Original Message-
 From: Taneja, Archit 
 Sent: Thursday, July 29, 2010 9:16 AM
 To: Premi, Sanjeev; tomi.valkei...@nokia.com
 Cc: linux-omap@vger.kernel.org
 Subject: RE: [PATCH resend] OMAP: DSS2: Replace strncmp() 
 with sysfs_streq() in overlay_manager_store()
 
 
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
Taneja, Archit
 Sent: Wednesday, July 28, 2010 11:52 AM
 To: tomi.valkei...@nokia.com
 Cc: linux-omap@vger.kernel.org; Taneja, Archit
 Subject: [PATCH resend] OMAP: DSS2: Replace strncmp() with
 sysfs_streq() in overlay_manager_store()
 
 In the function overlay_manager_store, the length of the
string buf is
 used to comapre the 2 strings, there is a possibility 
 of false 
 positive match if buf is a prefix string of another manager.
 
 The use of sysfs_streq() fixes this.
 
 Signed-off-by: Archit Taneja arc...@ti.com
 ---
  drivers/video/omap2/dss/overlay.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/video/omap2/dss/overlay.c
 b/drivers/video/omap2/dss/overlay.c
 index 8233658..244dca8
 --- a/drivers/video/omap2/dss/overlay.c
 +++ b/drivers/video/omap2/dss/overlay.c
 @@ -65,7 +65,7 @@ static ssize_t overlay_manager_store(struct 
 omap_overlay *ovl, const char *buf,
   for (i = 0; i 
 omap_dss_get_num_overlay_managers(); ++i) {
   mgr = omap_dss_get_overlay_manager(i);
  
 - if (strncmp(buf, mgr-name, len) == 0)
 + if (sysfs_streq(buf, mgr-name))

[sp] sysfs_streq() ignores trailing newlines during 
  comparison. So,
 the possibility mentioned in the description still stays.
   
   The aim is to compare one string which is a sysfs input and 
  the other 
   which is in the kernel.
   

 I am not familiar with overall context; but 
 wouldn't srtcmp()
 be the right choice? unless, of course, either of strings
 being compared are not null terminated.
   
   The sysfs input will have a newline and null at the end 
 whereas the 
   other string will only have null, strcmp will fail when 
 we want the 
   two strings to match.
   
   Eg. Sysfs input lcd\n\0
   Kernel string lcd\0
   
   strcmp will fail here
  
  [sp] If the patch is intending to fix this condition, then it isn't
   evident from the description. You should consider updating the
   description.
 
 The patch isn't intending to fix this condition, this 
 condition doesn't
 occur at all in the existing code. I explained this to tell 
 you why strcmp
 is a bad choice, the patch description tells why sysfs_streq 
 is a better
 choice over strncmp.

[sp] Can you explain the real condition and how/why it can't be handled
 by strcmp()

 
  
   

   break;
  
   mgr = NULL;
 --
 1.5.4.7
 
 --
 To unsubscribe from this list: send the line unsubscribe
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 resend] OMAP: DSS2: Replace strncmp() with sysfs_streq() in overlay_manager_store()

2010-07-28 Thread Taneja, Archit
  
  -Original Message-
  From: linux-omap-ow...@vger.kernel.org 
  [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
 Taneja, Archit
  Sent: Wednesday, July 28, 2010 11:52 AM
  To: tomi.valkei...@nokia.com
  Cc: linux-omap@vger.kernel.org; Taneja, Archit
  Subject: [PATCH resend] OMAP: DSS2: Replace strncmp() with
  sysfs_streq() in overlay_manager_store()
  
  In the function overlay_manager_store, the length of the
 string buf is
  used to comapre the 2 strings, there is a possibility
  of false
  positive match if buf is a prefix string of another manager.
  
  The use of sysfs_streq() fixes this.
  
  Signed-off-by: Archit Taneja arc...@ti.com
  ---
   drivers/video/omap2/dss/overlay.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
  
  diff --git a/drivers/video/omap2/dss/overlay.c
  b/drivers/video/omap2/dss/overlay.c
  index 8233658..244dca8
  --- a/drivers/video/omap2/dss/overlay.c
  +++ b/drivers/video/omap2/dss/overlay.c
  @@ -65,7 +65,7 @@ static ssize_t 
 overlay_manager_store(struct 
  omap_overlay *ovl, const char *buf,
  for (i = 0; i 
  omap_dss_get_num_overlay_managers(); ++i) {
  mgr = omap_dss_get_overlay_manager(i);
   
  -   if (strncmp(buf, mgr-name, len) == 0)
  +   if (sysfs_streq(buf, mgr-name))
 
 [sp] sysfs_streq() ignores trailing newlines during
   comparison. So,
  the possibility mentioned in the description still stays.

The aim is to compare one string which is a sysfs input and
   the other
which is in the kernel.

 
  I am not familiar with overall context; but
  wouldn't srtcmp()
  be the right choice? unless, of course, either of strings
  being compared are not null terminated.

The sysfs input will have a newline and null at the end
  whereas the
other string will only have null, strcmp will fail when
  we want the
two strings to match.

Eg. Sysfs input lcd\n\0
Kernel string lcd\0

strcmp will fail here
   
   [sp] If the patch is intending to fix this condition, 
 then it isn't
evident from the description. You should consider 
 updating the
description.
  
  The patch isn't intending to fix this condition, this condition 
  doesn't occur at all in the existing code. I explained this to tell 
  you why strcmp is a bad choice, the patch description tells why 
  sysfs_streq is a better choice over strncmp.
 
 [sp] Can you explain the real condition and how/why it can't 
 be handled
  by strcmp()

Okay, the real condition (why this patch was sent) is this (please have a look
at the whole function body while reading the explanation):

The user enters lcd via sysfs input to change the overlay's manager to lcd,
this input will be converted to lcd\n\0, the function will try to
comapre this name with all the existing managers names. Consider the case where
buf (sysfs input) is lcd\n\0 and mgr-name is lcd2\0.

Now, len is calculated as 3 and is passed as the parameter to stncmp, in this
case, lcd and lcd2 will match because only the first 3 characters are 
compared.
This is what I meant by buf being a prefix string of mgr-name.

This above is the condition which the patch tries to resolve.

strcmp will work like a charm here and ignore false positives, but it will 
generate
a false negative which didn't occur previously at all, an example:

If buf is lcd\n\0 and mgr-name is lcd\0 the code should match this, but 
strcmp
won't.

Hence, to prevent both false positives and false negatives sysfs_streq is used.

If you want to use strcmp, you will have to manually strip off the newlines.

I have also shared the patch link below which intrioduces sysfs_streq in the 
kernel
and explains why it has been introduced in the first place:

http://kerneltrap.org/mailarchive/git-commits-head/2008/5/1/1688084

I hope this explanation elaborates things clearly.

Thanks,

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