Re: [PATCH v2 0/9] unshare and simplify omap_hsmmc platform struct
On 3 October 2014 15:00, Ulf Hansson wrote: > On 29 September 2014 11:32, Andreas Fenkart 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
On Fri, Sep 26, 2014 at 7:25 PM, Suman Anna 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
On Friday 03 October 2014 06:34 AM, Felipe Balbi wrote: > [ 261.177168] [] (skb_panic) from [] (skb_put+0x5c/0x60) > [ 261.184415] [] (skb_put) from [] > (unix_stream_sendmsg+0x164/0x390) > [ 261.192712] [] (unix_stream_sendmsg) from [] > (sock_aio_write+0xdc/0xfc) > [ 261.201475] [] (sock_aio_write) from [] > (do_sync_write+0x8c/0xb4) > [ 261.209697] [] (do_sync_write) from [] > (vfs_write+0x118/0x1c0) > [ 261.217652] [] (vfs_write) from [] > (SyS_write+0x4c/0xa0) > [ 261.225054] [] (SyS_write) from [] > (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
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] [] (skb_panic) from [] > > (skb_put+0x5c/0x60) > > [ 261.184415] [] (skb_put) from [] > > (unix_stream_sendmsg+0x164/0x390) > > [ 261.192712] [] (unix_stream_sendmsg) from [] > > (sock_aio_write+0xdc/0xfc) > > [ 261.201475] [] (sock_aio_write) from [] > > (do_sync_write+0x8c/0xb4) > > [ 261.209697] [] (do_sync_write) from [] > > (vfs_write+0x118/0x1c0) > > [ 261.217652] [] (vfs_write) from [] > > (SyS_write+0x4c/0xa0) > > [ 261.225054] [] (SyS_write) from [] > > (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
This patch remove unnecessary KERN_INFO and KERN_ERR from omap_phy_internal.c.
Signed-off-by: Masanari Iida
---
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
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
> ---
> 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
On 4 October 2014 01:15, Stephen Boyd 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
>> ---
>
>
> 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 r
Re: [PATCH 1/2] clk: Make clk API return per-user struct clk instances
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
Re: [PATCH 0/2] mtd: nand: omap: Fix build with CONFIG_MTD_NAND_OMAP_BCH=m
On Wed, Oct 01, 2014 at 02:33:28PM +0300, Roger Quadros wrote: > Hi, > > Patch 1 fixes build with OMAP nand driver as built-in and the BCH driver as a > module. > Ezequiel, I took the liberty to address an issue with your original patch so > this is v2. > > Patch 2 fixes the help message for CONFIG_MTD_NAND_OMAP_BCH to avoid user > confusion. > CONFIG_MTD_NAND_OMAP_BCH is optional but doesn't harm on legacy OMAP > platforms not having > the ELM/BCH hardware. Thanks for finishing these off properly. Pushed to l2-mtd.git. Briarn -- 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
