Re: [PATCH v2 0/9] unshare and simplify omap_hsmmc platform struct

2014-10-06 Thread Ulf Hansson 
On 3 October 2014 15:00, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 29 September 2014 11:32, Andreas Fenkart afenk...@gmail.com wrote:
 v2:
 - replace erroneous mmci by omap1/2
 - add description to all patches
 - full compile check with:
 CONFIG_MACH_OMAP3_BEAGLE=y
 CONFIG_MACH_DEVKIT8000=y
 CONFIG_MACH_OMAP_LDP=y
 CONFIG_MACH_OMAP3530_LV_SOM=y
 CONFIG_MACH_OMAP3_TORPEDO=y
 CONFIG_MACH_OVERO=y
 CONFIG_MACH_OMAP3517EVM=y
 CONFIG_MACH_CRANEBOARD=y
 CONFIG_MACH_OMAP3_PANDORA=y
 CONFIG_MACH_TOUCHBOOK=y
 CONFIG_MACH_OMAP_3430SDP=y
 CONFIG_MACH_NOKIA_RX51=y
 CONFIG_MACH_CM_T35=y
 CONFIG_MACH_CM_T3517=y
 CONFIG_MACH_CM_T3730=y
 CONFIG_MACH_SBC3530=y
 - reorganized and added more patches, hence no blank ack added


 Andreas Fenkart (9):
   omap_hsmmc: use separate platform data for ompa3 and omap 1/2 driver
   omap_hsmmc: remove unused fields in platform_data
   omap_hsmmc: remove un-initialized callbacks from platform data
   omap_hsmmc: remove un-ready power_saving field in omap2_hsmmc_info
   omap_hsmmc: remove unused get_context_loss_count callback
   omap_hsmmc: remove unnecessary omap_hsmmc_slot_data indirection
   omap_hsmmc: pass mmc_priv struct to gpio init / free
   omap_hsmmc: Remove unnecessary callbacks from platform data
   omap_hsmmc: remove unused slot_id parameter

  arch/arm/mach-omap2/board-rx51-peripherals.c   |   4 +-
  arch/arm/mach-omap2/hsmmc.c| 155 +--
  arch/arm/mach-omap2/hsmmc.h|   9 +-
  arch/arm/mach-omap2/mmc.h  |   6 +-
  .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |   6 +-
  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |   6 +-
  drivers/mmc/host/omap_hsmmc.c  | 282 
 ++---
  include/linux/platform_data/hsmmc-omap.h   |  88 +++
  8 files changed, 299 insertions(+), 257 deletions(-)
  create mode 100644 include/linux/platform_data/hsmmc-omap.h

 --
 2.1.0


 Thanks! Applied for next!

As you know, these had some issues for omap2. I have dropped them from
next branch, they will have to be considered for 3.19 instead.

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

Re: [PATCHv4 4/7] hwspinlock/core: add common OF helpers

2014-10-06 Thread Ohad Ben-Cohen 
On Fri, Sep 26, 2014 at 7:25 PM, Suman Anna s-a...@ti.com wrote:
 I am yet to receive any comments on v6, but that series should address
 both your need for a probe deferral and Ohad's request to not change any
 return types. Please give it a try and let me know if you have any comments.

Guys,

Just to let you know we have several holidays around here these days,
and I intend to review all pending patches immediately soon after.

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: CPSW bug with AM437x SK

2014-10-06 Thread Mugunthan V N 
On Friday 03 October 2014 06:34 AM, Felipe Balbi wrote:
 [  261.177168] [c0648d48] (skb_panic) from [c0565edc] (skb_put+0x5c/0x60)
 [  261.184415] [c0565edc] (skb_put) from [c0605aac] 
 (unix_stream_sendmsg+0x164/0x390)
 [  261.192712] [c0605aac] (unix_stream_sendmsg) from [c055b364] 
 (sock_aio_write+0xdc/0xfc)
 [  261.201475] [c055b364] (sock_aio_write) from [c014c42c] 
 (do_sync_write+0x8c/0xb4)
 [  261.209697] [c014c42c] (do_sync_write) from [c014cf70] 
 (vfs_write+0x118/0x1c0)
 [  261.217652] [c014cf70] (vfs_write) from [c014d564] 
 (SyS_write+0x4c/0xa0)
 [  261.225054] [c014d564] (SyS_write) from [c000ed40] 
 (ret_fast_syscall+0x0/0x48)
 [  261.232988] Code: e58d4008 e58de00c e59f0008 ebfff48e (e7f001f2) 
 [  261.239378] ---[ end trace d64258d586f40104 ]---

The BT shows that the warn came from a unix socket interface, so this
cannot be a CPSW bug, its a bug in unix socket.

Are you not seeing this issue with file system in any other media?

I will try to reproduce this locally with my AM437x EVMsk.

Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe 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: CPSW bug with AM437x SK

2014-10-06 Thread Felipe Balbi 
Hi,

On Mon, Oct 06, 2014 at 03:24:59PM +0530, Mugunthan V N wrote:
 On Friday 03 October 2014 06:34 AM, Felipe Balbi wrote:
  [  261.177168] [c0648d48] (skb_panic) from [c0565edc] 
  (skb_put+0x5c/0x60)
  [  261.184415] [c0565edc] (skb_put) from [c0605aac] 
  (unix_stream_sendmsg+0x164/0x390)
  [  261.192712] [c0605aac] (unix_stream_sendmsg) from [c055b364] 
  (sock_aio_write+0xdc/0xfc)
  [  261.201475] [c055b364] (sock_aio_write) from [c014c42c] 
  (do_sync_write+0x8c/0xb4)
  [  261.209697] [c014c42c] (do_sync_write) from [c014cf70] 
  (vfs_write+0x118/0x1c0)
  [  261.217652] [c014cf70] (vfs_write) from [c014d564] 
  (SyS_write+0x4c/0xa0)
  [  261.225054] [c014d564] (SyS_write) from [c000ed40] 
  (ret_fast_syscall+0x0/0x48)
  [  261.232988] Code: e58d4008 e58de00c e59f0008 ebfff48e (e7f001f2) 
  [  261.239378] ---[ end trace d64258d586f40104 ]---
 
 The BT shows that the warn came from a unix socket interface, so this
 cannot be a CPSW bug, its a bug in unix socket.
 
 Are you not seeing this issue with file system in any other media?

Have not tried with other media, but since it comes from vfs_write() and
my rootfs sits in NFS I figured that might be the cause. Could not
reproduce this with BeagleBone Black, btw.

 I will try to reproduce this locally with my AM437x EVMsk.

alright.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] ARM: OMAP2: Remove unnecessary KERN_* in omap_phy_internal.c

2014-10-06 Thread Masanari Iida 
This patch remove unnecessary KERN_INFO and KERN_ERR from omap_phy_internal.c.

Signed-off-by: Masanari Iida standby2...@gmail.com
---
 arch/arm/mach-omap2/omap_phy_internal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_phy_internal.c 
b/arch/arm/mach-omap2/omap_phy_internal.c
index 50640b3..f4d942a 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -97,13 +97,13 @@ void am35x_musb_phy_power(u8 on)
 
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
 
-   pr_info(KERN_INFO Waiting for PHY clock good...\n);
+   pr_info(Waiting for PHY clock good...\n);
while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
 CONF2_PHYCLKGD)) {
cpu_relax();
 
if (time_after(jiffies, timeout)) {
-   pr_err(KERN_ERR musb PHY clock good timed 
out\n);
+   pr_err(musb PHY clock good timed out\n);
break;
}
}
@@ -145,7 +145,7 @@ void am35x_set_mode(u8 musb_mode)
devconf2 |= CONF2_NO_OVERRIDE;
break;
default:
-   pr_info(KERN_INFO Unsupported mode %u\n, musb_mode);
+   pr_info(Unsupported mode %u\n, musb_mode);
}
 
omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
-- 
2.1.1.273.g97b8860

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

Re: [PATCH] ARM: OMAP2: Remove unnecessary KERN_* in omap_phy_internal.c

2014-10-06 Thread Nishanth Menon 
On 01:16-20141007, Masanari Iida wrote:
 This patch remove unnecessary KERN_INFO and KERN_ERR from omap_phy_internal.c.
 
 Signed-off-by: Masanari Iida standby2...@gmail.com
 ---
  arch/arm/mach-omap2/omap_phy_internal.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/omap_phy_internal.c 
 b/arch/arm/mach-omap2/omap_phy_internal.c
 index 50640b3..f4d942a 100644
 --- a/arch/arm/mach-omap2/omap_phy_internal.c
 +++ b/arch/arm/mach-omap2/omap_phy_internal.c

With the cleanups, maybe add a
#define pr_fmt(fmt) %s:  fmt, __func__
at the start to make the log info a little more relevant?

 @@ -97,13 +97,13 @@ void am35x_musb_phy_power(u8 on)
  
   omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
  
 - pr_info(KERN_INFO Waiting for PHY clock good...\n);
 + pr_info(Waiting for PHY clock good...\n);
   while (!(omap_ctrl_readl(AM35XX_CONTROL_DEVCONF2)
CONF2_PHYCLKGD)) {
   cpu_relax();
  
   if (time_after(jiffies, timeout)) {
 - pr_err(KERN_ERR musb PHY clock good timed 
 out\n);
 + pr_err(musb PHY clock good timed out\n);
   break;
   }
   }
 @@ -145,7 +145,7 @@ void am35x_set_mode(u8 musb_mode)
   devconf2 |= CONF2_NO_OVERRIDE;
   break;
   default:
 - pr_info(KERN_INFO Unsupported mode %u\n, musb_mode);
 + pr_info(Unsupported mode %u\n, musb_mode);
   }
  
   omap_ctrl_writel(devconf2, AM35XX_CONTROL_DEVCONF2);
 -- 
 2.1.1.273.g97b8860
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
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 1/2] clk: Make clk API return per-user struct clk instances

2014-10-06 Thread Tomeu Vizoso 
On 4 October 2014 01:15, Stephen Boyd sb...@codeaurora.org wrote:
 On 10/02, Tomeu Vizoso wrote:
 Moves clock state to struct clk_core, but takes care to change as little API 
 as
 possible.

 struct clk_hw still has a pointer to a struct clk, which is the
 implementation's per-user clk instance, for backwards compatibility.

 The struct clk that clk_get_parent() returns isn't owned by the caller, but 
 by
 the clock implementation, so the former shouldn't call clk_put() on it.

 Because some boards in mach-omap2 still register clocks statically, their 
 clock
 registration had to be updated to take into account that the clock 
 information
 is stored in struct clk_core now.

 Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
 ---


 We should s/provider/core/ when we're dealing with clk_core
 structures in the function signature. The providers are hardware
 drivers and the core structures are for the framework, not the
 same. Furthermore, the provider drivers should only be dealing
 with clk_hw structures. The only place that clk_core should be in
 clk-provider.h is in struct clk_hw because there's no way to get
 around it.

 This way, provider drivers should only be including
 clk-provider.h because they only care about dealing with struct
 clk_hw. Consumers should only be including linux/clk.h where they
 only know about struct clk as an opaque pointer. Once we get OMAP
 to stop using clk-private.h we can kill off that header entirely
 (I see there are some other bogus users of that header outside of
 OMAP that we should nuke). Then the framework can include
 clk-provider.h and clk.h to map between the hw cookie and the
 consumer cookie.

Agreed.

 This is the end goal. I understand that the provider API is sort
 of a mess with us allowing drivers to use the underscore and
 non-underscore functions and the mixture of struct clk and struct
 ckl_hw throughout.

  struct clk_hw -- struct clk_core  struct clk
\- struct clk
|- struct clk

Agree this is how it should look like at some point, but for now I
need a reference to struct clk from struct clk_hw, so providers can
keep using the existing API. This reference would be removed once they
move to the new clk_hw-based API.

  providers
  -
  struct clk_hw {
 struct clk_core *
 ...
  };

  consumers
  -

  struct clk;

  hidden in core framework
  
  struct clk {
 struct clk_core *;
 ...
  }

  struct clk_core {
 struct clk_hw *;
 ...
  }



 diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
 index 4eeb8de..b216b13 100644
 --- a/drivers/clk/clk.c
 +++ b/drivers/clk/clk.c
 @@ -37,6 +37,13 @@ static HLIST_HEAD(clk_root_list);
  static HLIST_HEAD(clk_orphan_list);
  static LIST_HEAD(clk_notifier_list);

 +static void clk_provider_put(struct clk_core *clk);

 Does this need to be forward declared?

No, removed.

 +static long clk_provider_get_accuracy(struct clk_core *clk);
 +static bool clk_provider_is_prepared(struct clk_core *clk);
 +static bool clk_provider_is_enabled(struct clk_core *clk);
 +static long clk_provider_round_rate(struct clk_core *clk, unsigned long 
 rate);
 @@ -356,7 +363,7 @@ out:
   *
   * Caller must hold prepare_lock.
   */
 -static void clk_debug_unregister(struct clk *clk)
 +static void clk_debug_unregister(struct clk_core *clk)
  {
   debugfs_remove_recursive(clk-dentry);
  }
 @@ -366,8 +373,8 @@ struct dentry *clk_debugfs_add_file(struct clk *clk, 
 char *name, umode_t mode,

 We should pass struct clk_hw here instead of struct clk. Let's do
 it soon before we get any users.

Sounds good to me.

  {
   struct dentry *d = NULL;

 - if (clk-dentry)
 - d = debugfs_create_file(name, mode, clk-dentry, data, fops);
 + if (clk-core-dentry)
 + d = debugfs_create_file(name, mode, clk-core-dentry, data, 
 fops);

   return d;
  }
 @@ -545,53 +553,67 @@ late_initcall_sync(clk_disable_unused);

  const char *__clk_get_name(struct clk *clk)
  {
 - return !clk ? NULL : clk-name;
 + return !clk ? NULL : clk-core-name;
  }
  EXPORT_SYMBOL_GPL(__clk_get_name);

  struct clk_hw *__clk_get_hw(struct clk *clk)
  {
 - return !clk ? NULL : clk-hw;
 + return !clk ? NULL : clk-core-hw;
  }
  EXPORT_SYMBOL_GPL(__clk_get_hw);

  u8 __clk_get_num_parents(struct clk *clk)
  {
 - return !clk ? 0 : clk-num_parents;
 + return !clk ? 0 : clk-core-num_parents;
  }
  EXPORT_SYMBOL_GPL(__clk_get_num_parents);

  struct clk *__clk_get_parent(struct clk *clk)
  {
 - return !clk ? NULL : clk-parent;
 + /* TODO: Create a per-user clk and change callers to call clk_put */

 More like replace all callers with a function that returns their
 parent's hw pointer.

Sounds good, but I thought about it and have chosen to just remove the comment.

 struct clk_hw *clk_provider_get_parent(struct clk_hw *hw)


 + return

Re: [PATCH 1/2] clk: Make clk API return per-user struct clk instances

2014-10-06 Thread Stephen Boyd 

On 10/06/2014 10:14 AM, Tomeu Vizoso wrote:

This is the end goal. I understand that the provider API is sort
of a mess with us allowing drivers to use the underscore and
non-underscore functions and the mixture of struct clk and struct
ckl_hw throughout.

  struct clk_hw -- struct clk_core  struct clk
\- struct clk
|- struct clk

Agree this is how it should look like at some point, but for now I
need a reference to struct clk from struct clk_hw, so providers can
keep using the existing API. This reference would be removed once they
move to the new clk_hw-based API.


Ok sounds like we're on the same page.


+struct clk *__clk_create_clk(struct clk_core *clk_core, const char *dev_id,
+  const char *con_id);
+#endif
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index da4bda8..fe3712f 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -168,14 +172,27 @@ static struct clk_lookup *clk_find(const char *dev_id, 
const char *con_id)
  struct clk *clk_get_sys(const char *dev_id, const char *con_id)
  {
   struct clk_lookup *cl;
+ struct clk *clk = NULL;

   mutex_lock(clocks_mutex);
   cl = clk_find(dev_id, con_id);
- if (cl  !__clk_get(cl-clk))
- cl = NULL;
+ if (cl) {
+#if defined(CONFIG_COMMON_CLK)
+ clk = __clk_create_clk(cl-clk-core, dev_id, con_id);
+ if (clk  !__clk_get(clk)) {
+ kfree(clk);

This looks weird. It makes me suspect we've failed to reference
count something properly. Can we avoid this?

Can you extend on this? But I see how the behaviour doesn't match the
previous one because cl should be NULLed when __clk_get fails. I have
fixed this.


It triggers my that's not symmetric filter because it requires the 
caller to free something allocated by the callee. Do we still need 
__clk_get() to be called in the common clock path? Why not just do the 
stuff we do in __clk_get() in __clk_create_clk()? Then if that fails we 
can return an error pointer indicating some sort of failure (-ENOENT?) 
and we don't need to do any sort of cleanup otherwise.


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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