Re: [PATCH v2] clk: ti: fix dual-registration of uart4_ick

2015-10-02 Thread Tero Kristo 

On 10/02/2015 03:15 AM, Stephen Boyd wrote:

On 09/29, Ben Dooks wrote:

On the OMAP AM3517 platform the uart4_ick gets registered
twice, causing any power managment to /dev/ttyO3 to fail
when trying to wake the device up.

This solves the following oops:

[] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008
[] PC is at serial_omap_pm+0x48/0x15c
[] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c

Cc: sta...@vger.kernel.org
Cc: mturque...@baylibre.com
Cc: sb...@codeaurora.org
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: t-kri...@ti.com
Cc: linux-ker...@lists.codethink.co.uk
Signed-off-by: Ben Dooks 


Which patch broke this? Adding a Fixes: line will help us figure
out where to backport this.



The issue has been around since the legacy clock data code already, I am 
not quite sure which initially broke it though. As such, we can use the 
initial clock conversion commit as a fixes by for this:


commit aafd900cab87d339dc3004c241eebc854005124b
Author: Tero Kristo 
Date:   Fri Aug 2 14:04:19 2013 +0300

CLK: TI: add omap3 clock init file

I'll add a fixes tag to this and queue it for 4.3-rc-fixes.

-Tero
--
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] clk: ti: dflt: fix enable_reg validity check

2015-10-02 Thread Tero Kristo 

On 09/30/2015 01:37 AM, Suman Anna wrote:

The default clock enabling functions for TI clocks -
omap2_dflt_clk_enable() and omap2_dflt_clk_disable() perform a
NULL check for the enable_reg field of the clk_hw_omap structure.
This enable_reg field however is merely a combination of the index
of the master IP module, and the offset from the master IP module's
base address. A value of 0 is perfectly valid, and the current error
checking will fail in these cases. The issue was found when trying
to enable the iva2_ck clock on OMAP3 platforms.

So, switch the check to use IS_ERR. This correction is similar to the
logic used in commit c807dbedb5e5 ("clk: ti: fix ti_clk_get_reg_addr
error handling").

Signed-off-by: Suman Anna 
---
Hi Tero,

Patch done against 4.3-rc3. There are couple of similar checks in
drivers/clk/ti/clockdomain.c, but those seem to be ok. This is
a non-urgent fix, as there are currently no active users of
iva2_ck in the kernel (the MMU node is disabled in DT atm).

Boot tested on OMAP3 Beagle-XM, AM437x GP EVM, AM335x BeagleBone
Black, OMAP4 Panda, OMAP5 uEVM and DRA7 Beagle-X15 boards.

regards
Suman

Following is the error log from a unit test of the IVA MMU on OMAP3 using
some additional patch to enable the DTS node,

[   86.626342] omap_iommu_test_init: iommu_test_init entered
[   86.632080] omap_iommu_test iommu_test: Enabling IOMMU...
[   86.647460] omap_iommu_test iommu_test: testing IOMMU 5d00.mmu
[   86.654815] omap2_dflt_clk_enable: iva2_ck missing enable_reg
[   86.680938] [ cut here ]
[   86.685821] WARNING: CPU: 0 PID: 910 at drivers/clk/clk.c:675 
clk_disable+0x28/0x34()
[   86.694091] Modules linked in: iommu_dt_test(O+)
[   86.698974] CPU: 0 PID: 910 Comm: insmod Tainted: G   O
4.3.0-rc3-8-g61458979cbbe #40
[   86.708618] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[   86.715240] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   86.723419] [] (show_stack) from [] 
(dump_stack+0x84/0x9c)
[   86.731048] [] (dump_stack) from [] 
(warn_slowpath_common+0x78/0xb4)
[   86.739593] [] (warn_slowpath_common) from [] 
(warn_slowpath_null+0x1c/0x24)
[   86.748870] [] (warn_slowpath_null) from [] 
(clk_disable+0x28/0x34)
[   86.757324] [] (clk_disable) from [] 
(_disable_clocks+0x18/0x68)
[   86.765502] [] (_disable_clocks) from [] 
(omap_hwmod_deassert_hardreset+0xc8/0x180)
[   86.775421] [] (omap_hwmod_deassert_hardreset) from [] 
(omap_device_deassert_hardreset+0x34/
0x54)
[   86.786621] [] (omap_device_deassert_hardreset) from [] 
(omap_iommu_attach_dev+0xbc/0x1fc)
[   86.797180] [] (omap_iommu_attach_dev) from [] 
(__iommu_attach_device+0x1c/0x80)
[   86.806854] [] (__iommu_attach_device) from [] 
(omap_iommu_test_probe+0xd0/0x21c [iommu_dt_t
est])
[   86.818054] [] (omap_iommu_test_probe [iommu_dt_test]) from 
[] (platform_drv_probe+0x44/0xa4
)
[   86.828857] [] (platform_drv_probe) from [] 
(driver_probe_device+0x1f4/0x2f0)
[   86.838195] [] (driver_probe_device) from [] 
(__driver_attach+0x94/0x98)
[   86.847045] [] (__driver_attach) from [] 
(bus_for_each_dev+0x6c/0xa0)
[   86.855651] [] (bus_for_each_dev) from [] 
(bus_add_driver+0x18c/0x214)
[   86.864349] [] (bus_add_driver) from [] 
(driver_register+0x78/0xf8)
[   86.872772] [] (driver_register) from [] 
(do_one_initcall+0x80/0x1dc)
[   86.881378] [] (do_one_initcall) from [] 
(do_init_module+0x5c/0x1d0)
[   86.889892] [] (do_init_module) from [] 
(load_module+0x1818/0x1f70)
[   86.898315] [] (load_module) from [] 
(SyS_init_module+0xdc/0x14c)
[   86.906555] [] (SyS_init_module) from [] 
(ret_fast_syscall+0x0/0x1c)
[   86.915039] ---[ end trace 49b229a4289ab8b2 ]---
[   86.919891] omap_hwmod: mmu_iva: failed to hardreset
[   86.925384] omap-iommu 5d00.mmu: deassert_reset failed: -16
[   86.931640] omap_iommu_test iommu_test: can't get omap iommu: -16
[   86.938140] omap_iommu_test iommu_test: can't attach iommu device: -16
[   86.945068] omap_iommu_test_init failed, ret = -16

  drivers/clk/ti/clkt_dflt.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)


Queued for 4.3-rc-fixes thanks, as I have other patches to push for that.

-Tero



diff --git a/drivers/clk/ti/clkt_dflt.c b/drivers/clk/ti/clkt_dflt.c
index 90d7d8a21c49..1ddc288fce4e 100644
--- a/drivers/clk/ti/clkt_dflt.c
+++ b/drivers/clk/ti/clkt_dflt.c
@@ -222,7 +222,7 @@ int omap2_dflt_clk_enable(struct clk_hw *hw)
}
}

-   if (unlikely(!clk->enable_reg)) {
+   if (unlikely(IS_ERR(clk->enable_reg))) {
pr_err("%s: %s missing enable_reg\n", __func__,
   clk_hw_get_name(hw));
ret = -EINVAL;
@@ -264,7 +264,7 @@ void omap2_dflt_clk_disable(struct clk_hw *hw)
u32 v;

clk = to_clk_hw_omap(hw);
-   if (!clk->enable_reg) {
+   if (IS_ERR(clk->enable_reg)) {
/*
 * 'independent' here refers to a clock which is not
 * controlled by

[GIT PULL] clock: ti: fixes for 4.3-rc

2015-10-02 Thread Tero Kristo 

Hi Stephen, Mike,

A few TI clock driver fixes to pull against 4.3-rc.

-Tero



The following changes since commit 9ffecb10283508260936b96022d4ee43a7798b4c:

  Linux 4.3-rc3 (2015-09-27 07:50:08 -0400)

are available in the git repository at:

  https://github.com/t-kristo/linux-pm.git for-4.3-rc/ti-clk-fixes

for you to fetch changes up to 7aba4f5201d1b7b3ddb0b03883d9edf69851ddad:

  clk: ti: dflt: fix enable_reg validity check (2015-10-02 09:24:28 +0300)


Ben Dooks (1):
  clk: ti: fix dual-registration of uart4_ick

Peter Ujfalusi (1):
  clk: ti: clk-7xx: Remove hardwired ABE clock configuration

Suman Anna (1):
  clk: ti: dflt: fix enable_reg validity check

 drivers/clk/ti/clk-3xxx.c  |2 +-
 drivers/clk/ti/clk-7xx.c   |   18 +-
 drivers/clk/ti/clkt_dflt.c |4 ++--
 3 files changed, 4 insertions(+), 20 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

Re: [PATCH 01/11 RESEND] ARM: OMAP: DRA7: hwmod: Add data for McASP3

2015-10-02 Thread Peter Ujfalusi 
On 10/02/2015 02:55 PM, Peter Ujfalusi wrote:
> On 10/02/2015 02:22 PM, Peter Ujfalusi wrote:
>> Paul,
>>
>> On 10/02/2015 12:07 PM, Paul Walmsley wrote:
>>> Hello Péter,
>>>
>>> On Wed, 30 Sep 2015, Peter Ujfalusi wrote:
>>>
 On 09/27/2015 10:02 AM, Paul Walmsley wrote:
>>  /*
>> + * 'mcasp' class
>> + *
>> + */
>> +static struct omap_hwmod_class_sysconfig dra7xx_mcasp_sysc = {
>> +.sysc_offs  = 0x0004,
>> +.sysc_flags = SYSC_HAS_SIDLEMODE,
>> +.idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
>> +.sysc_fields= _hwmod_sysc_type3,
>> +};
>> +
>> +static struct omap_hwmod_class dra7xx_mcasp_hwmod_class = {
>> +.name   = "mcasp",
>> +.sysc   = _mcasp_sysc,
>> +};
>> +
>> +/* mcasp3 */
>> +static struct omap_hwmod dra7xx_mcasp3_hwmod = {
>> +.name   = "mcasp3",
>> +.class  = _mcasp_hwmod_class,
>> +.clkdm_name = "l4per2_clkdm",
>> +.main_clk   = "mcasp3_ahclkx_mux",
>
> I'd expect this clock to be something derived from mcasp3_aux_gfclk, 
> according to Table 24-408 "Clocks and Resets" of SPRUHZ6.  Could you 
> please doublecheck this?

 I can not explain this. If I change the main_clk to "mcasp3_aux_gfclk_mux"
 then I can not access to McASP3 register at all.
 I don't see anything popping out in the clock data, nor in other places.
>>>
>>> OK thank you for testing that.  Maybe just add a brief comment along those 
>>> lines in the hwmod data, above the structure record declaration?
>>
>> Now I more or less figured out the root of the issue. According to the
>> documentations the McASP in dra7xx family has following clocks:
>> ICLK - interface clock
>> GFCLK - functional clock
>> AHCLKX - Transmit high-frequency master clock
>> AHCLKR - Receive high-frequency master clock (on selected instances)
>>
>> In order to access registers all of these clock lines must have valid clock
>> signal. No other SoC with McASP has this setup.
>> As for why things seams to work when mcasp3_ahclkx_mux is set as main_clk and
>> mcasp3_aux_gfclk_mux is not handled at all?
>> The mcasp3_aux_gfclk_mux by default is from PER_ABE_X1GFCLK we never change
>> this. On dra7/72 evm the AHCLKX is reparented to ATL2 clock.
>> When with pm_runtime we enable the device, the mcasp3_ahclkx_mux will be
>> enabled by the SW (and ATL as well) _and_ the mcasp3_aux_gfclk_mux path will
>> be enabled by HW w/o SW.
>> The reason why I have had crash when I switched the main_clk to
>> mcasp3_aux_gfclk_mux is that even the path for the mcasp3_ahclkx_mux is
>> enabled by the HW, the ATL itself was not enabled, so it was not generating
>> the needed clocks. Same goes backwards for the gfclk: if I reparent it to
>> let's say HDMI clock - which is not present, and handle the ahclkx clock I
>> have similar crash.
>> All in all: the McASP3 needs ICLK and both FCLK and AHCLKX to be running in
>> order to be able to access registers.
>>
>> This current setup works fine, the only issue I see is that the refcounts for
>> the mcasp3_aux_gfclk_mux path is not reflecting the reality.
>>
>> With Tero we looked at different angles of this and how to solve it w/o
>> considering it as a hack.
>> Either we go with the hwmod data with main_clk set to mcasp3_ahclkx_mux and
>> document it in a comment, or:
>> Add new flag HWMOD_OPT_CLKS_NEEDED to hwmods to use to tell that the optional
>> clocks are not really optional as they are needed to be enabled in order to
>> access to the IP. In omap_hwmod.c's _enable_clocks() and _disable_clocks() we
>> call _enable_optional_clocks()/_disable_optional_clocks() if the flag is set
>> for the hwmod and add the ahclkx_mux as optional clock for McASP3.
> 
> This might be awkward to say that the optional clocks are not optional,
> probably would be better to add:
> struct omap_hwmod {
>   ...
>   struct omap_hwmod_opt_clk   *needed_clks;
>   ...
>   u8  needed_clks_cnt;
>   ...
> };
> 
> and use the needed_clks in 
> _init_main_clk()/_enable_clocks()/_disable_clocks() ?

Arrgh, but how to deal with this via DT bindings? It will be better to mark
the optional clocks as needed.

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

Re: [PATCH 1/2] gpio: omap: move pm runtime in irq_chip.irq_bus_lock/sync_unlock

2015-10-02 Thread Linus Walleij 
On Fri, Sep 25, 2015 at 12:28 PM, Grygorii Strashko
 wrote:

> The PM runtime API can't be used in atomic contex on -RT even if
> it's configured as irqsafe. As result, below error report can
> be seen when PM runtime API called from IRQ chip's callbacks
> irq_startup/irq_shutdown/irq_set_type, because they are
> protected by RAW spinlock:
>
> BUG: sleeping function called from invalid context at 
> kernel/locking/rtmutex.c:917
> in_atomic(): 1, irqs_disabled(): 128, pid: 96, name: insmod
> 3 locks held by insmod/96:
>  #0:  (>mutex){..}, at: [] __driver_attach+0x54/0xa0
>  #1:  (>mutex){..}, at: [] __driver_attach+0x60/0xa0
>  #2:  (class){..}, at: [] __irq_get_desc_lock+0x60/0xa4
> irq event stamp: 1834
> hardirqs last  enabled at (1833): [] 
> _raw_spin_unlock_irqrestore+0x88/0x90
> hardirqs last disabled at (1834): [] 
> _raw_spin_lock_irqsave+0x2c/0x64
> softirqs last  enabled at (0): [] copy_process.part.52+0x410/0x19d8
> softirqs last disabled at (0): [<  (null)>]   (null)
> Preemption disabled at:[<  (null)>]   (null)
>
> CPU: 1 PID: 96 Comm: insmod Tainted: GW  O
> 4.1.3-rt3-00618-g57e2387-dirty #184
> Hardware name: Generic DRA74X (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x20/0x24)
> [] (show_stack) from [] (dump_stack+0x88/0xdc)
> [] (dump_stack) from [] (___might_sleep+0x198/0x2a8)
> [] (___might_sleep) from [] (rt_spin_lock+0x30/0x70)
> [] (rt_spin_lock) from [] (__pm_runtime_resume+0x68/0xa4)
> [] (__pm_runtime_resume) from [] 
> (omap_gpio_irq_type+0x188/0x1d8)
> [] (omap_gpio_irq_type) from [] 
> (__irq_set_trigger+0x68/0x130)
> [] (__irq_set_trigger) from [] 
> (irq_set_irq_type+0x44/0x6c)
> [] (irq_set_irq_type) from [] 
> (irq_create_of_mapping+0x120/0x174)
> [] (irq_create_of_mapping) from [] (of_irq_get+0x48/0x58)
> [] (of_irq_get) from [] (i2c_device_probe+0x54/0x15c)
> [] (i2c_device_probe) from [] 
> (driver_probe_device+0x184/0x2c8)
> [] (driver_probe_device) from [] 
> (__driver_attach+0x9c/0xa0)
> [] (__driver_attach) from [] (bus_for_each_dev+0x7c/0xb0)
> [] (bus_for_each_dev) from [] (driver_attach+0x28/0x30)
> [] (driver_attach) from [] (bus_add_driver+0x154/0x200)
> [] (bus_add_driver) from [] (driver_register+0x88/0x108)
> [] (driver_register) from [] 
> (i2c_register_driver+0x3c/0x90)
> [] (i2c_register_driver) from [] (pcf857x_init+0x18/0x24 
> [gpio_pcf857x])
> [] (pcf857x_init [gpio_pcf857x]) from [] 
> (do_one_initcall+0x128/0x1e8)
> [] (do_one_initcall) from [] (do_init_module+0x6c/0x1bc)
> [] (do_init_module) from [] (load_module+0x18e8/0x21c4)
> [] (load_module) from [] (SyS_init_module+0xfc/0x158)
> [] (SyS_init_module) from [] (ret_fast_syscall+0x0/0x54)
>
> The IRQ chip interface defines only two callbacks which are executed in
> non-atomic contex - irq_bus_lock/irq_bus_sync_unlock, so lets move
> PM runtime calls there.
>
> Tested-by: Tony Lindgren 
> Tested-by: Austin Schuh 
> Signed-off-by: Grygorii Strashko 

Patch applied with Santosh's ACK.

Yours,
Linus Walleij
--
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: Remove __ref on hotplug cpu die path

2015-10-02 Thread Linus Walleij 
On Mon, Sep 14, 2015 at 5:23 PM, Stephen Boyd  wrote:

> Now that __cpuinit has been removed, the __ref markings on these
> functions are useless. Remove them. This also reduces the size of
> the multi_v7_defconfig image:
>
> $ size before after
>textdata bss dec hex filename
>126835781470996  348904 14503478 dd4e36 before
>126832741470996  348904 14503174 dd4d06 after
>
> presumably because now we don't have to jump to code in the
> .ref.text section and/or the noinline marking is removed.
>
> Cc: Tony Lindgren 
> Cc: Barry Song 
> Cc: Andy Gross 
> Cc: Viresh Kumar 
> Cc: Shiraz Hashim 
> Cc: Stephen Warren 
> Cc: Thierry Reding 
> Cc: Alexandre Courbot 
> Cc: Linus Walleij 
> Cc: Sudeep Holla 
> Cc: Lorenzo Pieralisi 
> Cc: Will Deacon 
> Cc: Mark Rutland 
> Cc: 
> Cc: 
> Cc: 
> Cc: 
> Signed-off-by: Stephen Boyd 

Acked-by: Linus Walleij 

Yours,
Linus Walleij
--
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 01/11 RESEND] ARM: OMAP: DRA7: hwmod: Add data for McASP3

2015-10-02 Thread Peter Ujfalusi 
On 10/02/2015 02:22 PM, Peter Ujfalusi wrote:
> Paul,
> 
> On 10/02/2015 12:07 PM, Paul Walmsley wrote:
>> Hello Péter,
>>
>> On Wed, 30 Sep 2015, Peter Ujfalusi wrote:
>>
>>> On 09/27/2015 10:02 AM, Paul Walmsley wrote:
>  /*
> + * 'mcasp' class
> + *
> + */
> +static struct omap_hwmod_class_sysconfig dra7xx_mcasp_sysc = {
> + .sysc_offs  = 0x0004,
> + .sysc_flags = SYSC_HAS_SIDLEMODE,
> + .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> + .sysc_fields= _hwmod_sysc_type3,
> +};
> +
> +static struct omap_hwmod_class dra7xx_mcasp_hwmod_class = {
> + .name   = "mcasp",
> + .sysc   = _mcasp_sysc,
> +};
> +
> +/* mcasp3 */
> +static struct omap_hwmod dra7xx_mcasp3_hwmod = {
> + .name   = "mcasp3",
> + .class  = _mcasp_hwmod_class,
> + .clkdm_name = "l4per2_clkdm",
> + .main_clk   = "mcasp3_ahclkx_mux",

 I'd expect this clock to be something derived from mcasp3_aux_gfclk, 
 according to Table 24-408 "Clocks and Resets" of SPRUHZ6.  Could you 
 please doublecheck this?
>>>
>>> I can not explain this. If I change the main_clk to "mcasp3_aux_gfclk_mux"
>>> then I can not access to McASP3 register at all.
>>> I don't see anything popping out in the clock data, nor in other places.
>>
>> OK thank you for testing that.  Maybe just add a brief comment along those 
>> lines in the hwmod data, above the structure record declaration?
> 
> Now I more or less figured out the root of the issue. According to the
> documentations the McASP in dra7xx family has following clocks:
> ICLK - interface clock
> GFCLK - functional clock
> AHCLKX - Transmit high-frequency master clock
> AHCLKR - Receive high-frequency master clock (on selected instances)
> 
> In order to access registers all of these clock lines must have valid clock
> signal. No other SoC with McASP has this setup.
> As for why things seams to work when mcasp3_ahclkx_mux is set as main_clk and
> mcasp3_aux_gfclk_mux is not handled at all?
> The mcasp3_aux_gfclk_mux by default is from PER_ABE_X1GFCLK we never change
> this. On dra7/72 evm the AHCLKX is reparented to ATL2 clock.
> When with pm_runtime we enable the device, the mcasp3_ahclkx_mux will be
> enabled by the SW (and ATL as well) _and_ the mcasp3_aux_gfclk_mux path will
> be enabled by HW w/o SW.
> The reason why I have had crash when I switched the main_clk to
> mcasp3_aux_gfclk_mux is that even the path for the mcasp3_ahclkx_mux is
> enabled by the HW, the ATL itself was not enabled, so it was not generating
> the needed clocks. Same goes backwards for the gfclk: if I reparent it to
> let's say HDMI clock - which is not present, and handle the ahclkx clock I
> have similar crash.
> All in all: the McASP3 needs ICLK and both FCLK and AHCLKX to be running in
> order to be able to access registers.
> 
> This current setup works fine, the only issue I see is that the refcounts for
> the mcasp3_aux_gfclk_mux path is not reflecting the reality.
> 
> With Tero we looked at different angles of this and how to solve it w/o
> considering it as a hack.
> Either we go with the hwmod data with main_clk set to mcasp3_ahclkx_mux and
> document it in a comment, or:
> Add new flag HWMOD_OPT_CLKS_NEEDED to hwmods to use to tell that the optional
> clocks are not really optional as they are needed to be enabled in order to
> access to the IP. In omap_hwmod.c's _enable_clocks() and _disable_clocks() we
> call _enable_optional_clocks()/_disable_optional_clocks() if the flag is set
> for the hwmod and add the ahclkx_mux as optional clock for McASP3.

This might be awkward to say that the optional clocks are not optional,
probably would be better to add:
struct omap_hwmod {
...
struct omap_hwmod_opt_clk   *needed_clks;
...
u8  needed_clks_cnt;
...
};

and use the needed_clks in _init_main_clk()/_enable_clocks()/_disable_clocks() ?

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

Re: [PATCH 01/11 RESEND] ARM: OMAP: DRA7: hwmod: Add data for McASP3

2015-10-02 Thread Peter Ujfalusi 
Paul,

On 10/02/2015 12:07 PM, Paul Walmsley wrote:
> Hello Péter,
> 
> On Wed, 30 Sep 2015, Peter Ujfalusi wrote:
> 
>> On 09/27/2015 10:02 AM, Paul Walmsley wrote:
  /*
 + * 'mcasp' class
 + *
 + */
 +static struct omap_hwmod_class_sysconfig dra7xx_mcasp_sysc = {
 +  .sysc_offs  = 0x0004,
 +  .sysc_flags = SYSC_HAS_SIDLEMODE,
 +  .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
 +  .sysc_fields= _hwmod_sysc_type3,
 +};
 +
 +static struct omap_hwmod_class dra7xx_mcasp_hwmod_class = {
 +  .name   = "mcasp",
 +  .sysc   = _mcasp_sysc,
 +};
 +
 +/* mcasp3 */
 +static struct omap_hwmod dra7xx_mcasp3_hwmod = {
 +  .name   = "mcasp3",
 +  .class  = _mcasp_hwmod_class,
 +  .clkdm_name = "l4per2_clkdm",
 +  .main_clk   = "mcasp3_ahclkx_mux",
>>>
>>> I'd expect this clock to be something derived from mcasp3_aux_gfclk, 
>>> according to Table 24-408 "Clocks and Resets" of SPRUHZ6.  Could you 
>>> please doublecheck this?
>>
>> I can not explain this. If I change the main_clk to "mcasp3_aux_gfclk_mux"
>> then I can not access to McASP3 register at all.
>> I don't see anything popping out in the clock data, nor in other places.
> 
> OK thank you for testing that.  Maybe just add a brief comment along those 
> lines in the hwmod data, above the structure record declaration?

Now I more or less figured out the root of the issue. According to the
documentations the McASP in dra7xx family has following clocks:
ICLK - interface clock
GFCLK - functional clock
AHCLKX - Transmit high-frequency master clock
AHCLKR - Receive high-frequency master clock (on selected instances)

In order to access registers all of these clock lines must have valid clock
signal. No other SoC with McASP has this setup.
As for why things seams to work when mcasp3_ahclkx_mux is set as main_clk and
mcasp3_aux_gfclk_mux is not handled at all?
The mcasp3_aux_gfclk_mux by default is from PER_ABE_X1GFCLK we never change
this. On dra7/72 evm the AHCLKX is reparented to ATL2 clock.
When with pm_runtime we enable the device, the mcasp3_ahclkx_mux will be
enabled by the SW (and ATL as well) _and_ the mcasp3_aux_gfclk_mux path will
be enabled by HW w/o SW.
The reason why I have had crash when I switched the main_clk to
mcasp3_aux_gfclk_mux is that even the path for the mcasp3_ahclkx_mux is
enabled by the HW, the ATL itself was not enabled, so it was not generating
the needed clocks. Same goes backwards for the gfclk: if I reparent it to
let's say HDMI clock - which is not present, and handle the ahclkx clock I
have similar crash.
All in all: the McASP3 needs ICLK and both FCLK and AHCLKX to be running in
order to be able to access registers.

This current setup works fine, the only issue I see is that the refcounts for
the mcasp3_aux_gfclk_mux path is not reflecting the reality.

With Tero we looked at different angles of this and how to solve it w/o
considering it as a hack.
Either we go with the hwmod data with main_clk set to mcasp3_ahclkx_mux and
document it in a comment, or:
Add new flag HWMOD_OPT_CLKS_NEEDED to hwmods to use to tell that the optional
clocks are not really optional as they are needed to be enabled in order to
access to the IP. In omap_hwmod.c's _enable_clocks() and _disable_clocks() we
call _enable_optional_clocks()/_disable_optional_clocks() if the flag is set
for the hwmod and add the ahclkx_mux as optional clock for McASP3.

 +  .user   = OCP_USER_MPU | OCP_USER_SDMA,
 +};
>>>
>>> There's another struct omap_hwmod_ocp_if record missing: the high-speed 
>>> bus-master port that the McASP3 uses to DMA audio data.  This port should 
>>> most likely be clocked with "l3_iclk_div" per Table 24-408 "Clocks and 
>>> Resets".  This port is also where the registers described in Table 24-555 
>>> "MCASP_DAT Register Summary 3" L3_MAIN column are exposed.  You've got 
>>> that address map range blocked out in your DT data reg property, and 
>>> associated with this device, right? 0x4600?
>>
>> Yes, the McASP3-dat port is not used ATM. This is over the L3 interconnect 
>> and
>> due to a feature we can not use it with sDMA (constant addressing is not
>> supported through L3 interconnect for DMAs).
>> We could use eDMA, but there are complications regarding to that.
>> At the moment we are using the sDMA through the L4 interconnect address 
>> space.
> 
> OK thanks for the explanation.  The hwmod code prevents links from being 
> registered if no initiator 'users' are listed, so sounds like we should 
> leave it out for now.  Could you add a brief comment, similar to your 
> paragraph above, in the data, in case others wonder about the L3 link?

Sure, I'll do that.

> 
> After those changes are made, feel free to add my ack.

I'll wait for your comment regarding to the multiple main_clk need for the
McASP3 before I'll send the next version.

> Köszönöm,

:D

> 
> - Paul
> 

-- 
Péter
--
To

Re: [PATCH 01/11 RESEND] ARM: OMAP: DRA7: hwmod: Add data for McASP3

2015-10-02 Thread Paul Walmsley 
Hello Péter,

On Wed, 30 Sep 2015, Peter Ujfalusi wrote:

> On 09/27/2015 10:02 AM, Paul Walmsley wrote:
> >>  /*
> >> + * 'mcasp' class
> >> + *
> >> + */
> >> +static struct omap_hwmod_class_sysconfig dra7xx_mcasp_sysc = {
> >> +  .sysc_offs  = 0x0004,
> >> +  .sysc_flags = SYSC_HAS_SIDLEMODE,
> >> +  .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
> >> +  .sysc_fields= _hwmod_sysc_type3,
> >> +};
> >> +
> >> +static struct omap_hwmod_class dra7xx_mcasp_hwmod_class = {
> >> +  .name   = "mcasp",
> >> +  .sysc   = _mcasp_sysc,
> >> +};
> >> +
> >> +/* mcasp3 */
> >> +static struct omap_hwmod dra7xx_mcasp3_hwmod = {
> >> +  .name   = "mcasp3",
> >> +  .class  = _mcasp_hwmod_class,
> >> +  .clkdm_name = "l4per2_clkdm",
> >> +  .main_clk   = "mcasp3_ahclkx_mux",
> > 
> > I'd expect this clock to be something derived from mcasp3_aux_gfclk, 
> > according to Table 24-408 "Clocks and Resets" of SPRUHZ6.  Could you 
> > please doublecheck this?
> 
> I can not explain this. If I change the main_clk to "mcasp3_aux_gfclk_mux"
> then I can not access to McASP3 register at all.
> I don't see anything popping out in the clock data, nor in other places.

OK thank you for testing that.  Maybe just add a brief comment along those 
lines in the hwmod data, above the structure record declaration?

> >> +  .flags  = HWMOD_SWSUP_SIDLE,
> 
> Not sure why this has been added, I can not find any pointers regarding to
> this and everything is working w/o this flag. Will remove it in v2.

OK thanks.  

> >> @@ -2566,6 +2598,14 @@ static struct omap_hwmod_ocp_if 
> >> dra7xx_l3_main_1__hdmi = {
> >>.user   = OCP_USER_MPU | OCP_USER_SDMA,
> >>  };
> >>  
> >> +/* l4_per2 -> mcasp3 */
> >> +static struct omap_hwmod_ocp_if dra7xx_l4_per2__mcasp3 = {
> >> +  .master = _l4_per2_hwmod,
> >> +  .slave  = _mcasp3_hwmod,
> > 
> > So this is the low-speed control/register access port, where the MPU 
> > writes to the McASP3 config registers...
> > 
> >> +  .clk= "l3_iclk_div",
> > 
> > ... and thus this interface clock doesn't look right for this port, since 
> > it's most likely generated from the L4PER2, where this port is connected.  
> > So it should probably be "l4_iclk_div".
> 
> There is no "l4_iclk_div" for dra7xx. Looking around the file all other script
> generated data uses "l3_iclk_div" for IPs under dra7xx_l4_per2_hwmod.
> 
> Tero: do you know the reason for this?

Sounds like from your followup E-mail that the clock name to use in the 
kernel is "l4_root_clk_div", which sounds fine to me.  (Haven't looked 
closely at the clock data, though.)

> >> +  .user   = OCP_USER_MPU | OCP_USER_SDMA,
> >> +};
> > 
> > There's another struct omap_hwmod_ocp_if record missing: the high-speed 
> > bus-master port that the McASP3 uses to DMA audio data.  This port should 
> > most likely be clocked with "l3_iclk_div" per Table 24-408 "Clocks and 
> > Resets".  This port is also where the registers described in Table 24-555 
> > "MCASP_DAT Register Summary 3" L3_MAIN column are exposed.  You've got 
> > that address map range blocked out in your DT data reg property, and 
> > associated with this device, right? 0x4600?
> 
> Yes, the McASP3-dat port is not used ATM. This is over the L3 interconnect and
> due to a feature we can not use it with sDMA (constant addressing is not
> supported through L3 interconnect for DMAs).
> We could use eDMA, but there are complications regarding to that.
> At the moment we are using the sDMA through the L4 interconnect address space.

OK thanks for the explanation.  The hwmod code prevents links from being 
registered if no initiator 'users' are listed, so sounds like we should 
leave it out for now.  Could you add a brief comment, similar to your 
paragraph above, in the data, in case others wonder about the L3 link?

After those changes are made, feel free to add my ack.


Köszönöm,

- Paul

Re: Queueing b0a688ddcc50 "usb: musb: cppi41: allow it to work again" for -stable

2015-10-02 Thread Felipe Balbi 
On Fri, Oct 02, 2015 at 02:23:45AM -0300, Ezequiel Garcia wrote:
> Hello,
> 
> Commit b0a688ddcc50 "usb: musb: cppi41: allow it to work again" seems
> to fix a regression. It applies cleanly on v4.1 and removes the
> "musb-hdrc musb-hdrc.1.auto: Need DT for the DMA engine." error.
> 
> Any chance you can queue it for -stable?

Have a look at Documentation/stable_kernel_rules.txt, you can do a proper
request for Greg and he will make sure it gets there.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v2] clk: ti: fix dual-registration of uart4_ick

2015-10-02 Thread Ben Dooks 
On 02/10/15 07:07, Tero Kristo wrote:
> On 10/02/2015 03:15 AM, Stephen Boyd wrote:
>> On 09/29, Ben Dooks wrote:
>>> On the OMAP AM3517 platform the uart4_ick gets registered
>>> twice, causing any power managment to /dev/ttyO3 to fail
>>> when trying to wake the device up.
>>>
>>> This solves the following oops:
>>>
>>> [] Unhandled fault: external abort on non-linefetch (0x1028) at
>>> 0xfa09e008
>>> [] PC is at serial_omap_pm+0x48/0x15c
>>> [] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c
>>>
>>> Cc: sta...@vger.kernel.org
>>> Cc: mturque...@baylibre.com
>>> Cc: sb...@codeaurora.org
>>> Cc: linux-...@vger.kernel.org
>>> Cc: linux-omap@vger.kernel.org
>>> Cc: t-kri...@ti.com
>>> Cc: linux-ker...@lists.codethink.co.uk
>>> Signed-off-by: Ben Dooks 
>>
>> Which patch broke this? Adding a Fixes: line will help us figure
>> out where to backport this.
>>
> 
> The issue has been around since the legacy clock data code already, I am
> not quite sure which initially broke it though. As such, we can use the

Thanks, i've been off ill for the last two days so catching up on this.

-- 
Ben Dooks   http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] clock: ti: fixes for 4.3-rc

2015-10-02 Thread Stephen Boyd 
On 10/02, Tero Kristo wrote:
> Hi Stephen, Mike,
> 
> A few TI clock driver fixes to pull against 4.3-rc.
> 
> -Tero
> 
> 
> 
> The following changes since commit 9ffecb10283508260936b96022d4ee43a7798b4c:
> 
>   Linux 4.3-rc3 (2015-09-27 07:50:08 -0400)
> 
> are available in the git repository at:
> 
>   https://github.com/t-kristo/linux-pm.git for-4.3-rc/ti-clk-fixes
> 

Thanks, pulled. I guess we'll wait until Monday next week to send
off to Linus so this can go through a couple -next cycles.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] clk: ti: dflt: fix enable_reg validity check

2015-10-02 Thread Stephen Boyd 
On 09/29, Suman Anna wrote:
> diff --git a/drivers/clk/ti/clkt_dflt.c b/drivers/clk/ti/clkt_dflt.c
> index 90d7d8a21c49..1ddc288fce4e 100644
> --- a/drivers/clk/ti/clkt_dflt.c
> +++ b/drivers/clk/ti/clkt_dflt.c
> @@ -222,7 +222,7 @@ int omap2_dflt_clk_enable(struct clk_hw *hw)
>   }
>   }
>  
> - if (unlikely(!clk->enable_reg)) {
> + if (unlikely(IS_ERR(clk->enable_reg))) {

IS_ERR() already has an unlikely inside it, so the unlikely is
redundant here.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: Queueing b0a688ddcc50 "usb: musb: cppi41: allow it to work again" for -stable

2015-10-02 Thread Ezequiel Garcia 
On 2 October 2015 at 13:09, Felipe Balbi  wrote:
> On Fri, Oct 02, 2015 at 02:23:45AM -0300, Ezequiel Garcia wrote:
>> Hello,
>>
>> Commit b0a688ddcc50 "usb: musb: cppi41: allow it to work again" seems
>> to fix a regression. It applies cleanly on v4.1 and removes the
>> "musb-hdrc musb-hdrc.1.auto: Need DT for the DMA engine." error.
>>
>> Any chance you can queue it for -stable?
>
> Have a look at Documentation/stable_kernel_rules.txt, you can do a proper
> request for Greg and he will make sure it gets there.
>

Sure, I will.

Maybe next time you could add a Cc: stable to these kinds of fixes, along with
a proper Fixes tag, so the -stable folks can pick them automatically.

Thanks!
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
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: Queueing b0a688ddcc50 "usb: musb: cppi41: allow it to work again" for -stable

2015-10-02 Thread Felipe Balbi 
On Fri, Oct 02, 2015 at 02:16:50PM -0300, Ezequiel Garcia wrote:
> On 2 October 2015 at 13:09, Felipe Balbi  wrote:
> > On Fri, Oct 02, 2015 at 02:23:45AM -0300, Ezequiel Garcia wrote:
> >> Hello,
> >>
> >> Commit b0a688ddcc50 "usb: musb: cppi41: allow it to work again" seems
> >> to fix a regression. It applies cleanly on v4.1 and removes the
> >> "musb-hdrc musb-hdrc.1.auto: Need DT for the DMA engine." error.
> >>
> >> Any chance you can queue it for -stable?
> >
> > Have a look at Documentation/stable_kernel_rules.txt, you can do a proper
> > request for Greg and he will make sure it gets there.
> >
> 
> Sure, I will.
> 
> Maybe next time you could add a Cc: stable to these kinds of fixes, along with
> a proper Fixes tag, so the -stable folks can pick them automatically.

I usually do, in this case, nobody had complained about this board in any stable
kernel so I just didn't.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] clk: ti: dflt: fix enable_reg validity check

2015-10-02 Thread Suman Anna 
On 10/02/2015 01:21 PM, Stephen Boyd wrote:
> On 09/29, Suman Anna wrote:
>> diff --git a/drivers/clk/ti/clkt_dflt.c b/drivers/clk/ti/clkt_dflt.c
>> index 90d7d8a21c49..1ddc288fce4e 100644
>> --- a/drivers/clk/ti/clkt_dflt.c
>> +++ b/drivers/clk/ti/clkt_dflt.c
>> @@ -222,7 +222,7 @@ int omap2_dflt_clk_enable(struct clk_hw *hw)
>>  }
>>  }
>>  
>> -if (unlikely(!clk->enable_reg)) {
>> +if (unlikely(IS_ERR(clk->enable_reg))) {
> 
> IS_ERR() already has an unlikely inside it, so the unlikely is
> redundant here.

Thanks Stephen, didn't realize that. I will fix this up in a subsequent
patch, Tero has already staged it and sent a PULL request.

regards
Suman


--
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] gpio: omap: convert to use generic irq handler

2015-10-02 Thread Linus Walleij 
On Fri, Sep 25, 2015 at 12:28 PM, Grygorii Strashko
 wrote:

> This patch converts TI OMAP GPIO driver to use generic irq handler
> instead of chained IRQ handler. This way OMAP GPIO driver will be
> compatible with RT kernel where it will be forced thread IRQ handler
> while in non-RT kernel it still will be executed in HW IRQ context.
> As part of this change the IRQ wakeup configuration is applied to
> GPIO Bank IRQ as it now will be under control of IRQ PM Core during
> suspend.
>
> There are also additional benefits:
>  - on-RT kernel there will be no complains any more about PM runtime usage
>in atomic context  "BUG: sleeping function called from invalid context";
>  - GPIO bank IRQs will appear in /proc/interrupts and its usage statistic
> will be  visible;
>  - GPIO bank IRQs could be configured through IRQ proc_fs interface and,
>as result, could be a part of IRQ balancing process if needed;
>  - GPIO bank IRQs will be under control of IRQ PM Core during
>suspend to RAM.
>
> Disadvantage:
>  - additional runtime overhed as call chain till
>omap_gpio_irq_handler() will be longer now
>  - necessity to use wa_lock in omap_gpio_irq_handler() to W/A warning
>in handle_irq_event_percpu()
>WARNING: CPU: 1 PID: 35 at kernel/irq/handle.c:149 
> handle_irq_event_percpu+0x51c/0x638()
>
> This patch doesn't fully follows recommendations provided by Sebastian
> Andrzej Siewior [1], because It's required to go through and check all
> GPIO IRQ pin states as fast as possible and pass control to handle_level_irq
> or handle_edge_irq. handle_level_irq or handle_edge_irq will perform actions
> specific for IRQ triggering type and wakeup corresponding registered
> threaded IRQ handler (at least it's expected to be threaded).
> IRQs can be lost if handle_nested_irq() will be used, because excecution
> time of some pin specific GPIO IRQ handler can be very significant and
> require accessing ext. devices (I2C).
>
> Idea of such kind reworking was also discussed in [2].
>
> [1] http://www.spinics.net/lists/linux-omap/msg120665.html
> [2] http://www.spinics.net/lists/linux-omap/msg119516.html
>
> Tested-by: Tony Lindgren 
> Tested-by: Austin Schuh 
> Signed-off-by: Grygorii Strashko 

Patch applied.

I'm thinking that we need some recommendations on how to write
IRQ handlers in order to be RT-compatible. Can you help me lining
up the requirements in Documentation/gpio/driver.txt?

I will write an RFC patch and let you write some additional text
to it in response then we can iterate it a bit.

Yours,
Linus Walleij
--
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] gpio: omap: convert to use generic irq handler

2015-10-02 Thread Grygorii Strashko 

On 10/02/2015 03:17 PM, Linus Walleij wrote:

On Fri, Sep 25, 2015 at 12:28 PM, Grygorii Strashko
 wrote:


This patch converts TI OMAP GPIO driver to use generic irq handler
instead of chained IRQ handler. This way OMAP GPIO driver will be
compatible with RT kernel where it will be forced thread IRQ handler
while in non-RT kernel it still will be executed in HW IRQ context.
As part of this change the IRQ wakeup configuration is applied to
GPIO Bank IRQ as it now will be under control of IRQ PM Core during
suspend.

There are also additional benefits:
  - on-RT kernel there will be no complains any more about PM runtime usage
in atomic context  "BUG: sleeping function called from invalid context";
  - GPIO bank IRQs will appear in /proc/interrupts and its usage statistic
 will be  visible;
  - GPIO bank IRQs could be configured through IRQ proc_fs interface and,
as result, could be a part of IRQ balancing process if needed;
  - GPIO bank IRQs will be under control of IRQ PM Core during
suspend to RAM.

Disadvantage:
  - additional runtime overhed as call chain till
omap_gpio_irq_handler() will be longer now
  - necessity to use wa_lock in omap_gpio_irq_handler() to W/A warning
in handle_irq_event_percpu()
WARNING: CPU: 1 PID: 35 at kernel/irq/handle.c:149 
handle_irq_event_percpu+0x51c/0x638()

This patch doesn't fully follows recommendations provided by Sebastian
Andrzej Siewior [1], because It's required to go through and check all
GPIO IRQ pin states as fast as possible and pass control to handle_level_irq
or handle_edge_irq. handle_level_irq or handle_edge_irq will perform actions
specific for IRQ triggering type and wakeup corresponding registered
threaded IRQ handler (at least it's expected to be threaded).
IRQs can be lost if handle_nested_irq() will be used, because excecution
time of some pin specific GPIO IRQ handler can be very significant and
require accessing ext. devices (I2C).

Idea of such kind reworking was also discussed in [2].

[1] http://www.spinics.net/lists/linux-omap/msg120665.html
[2] http://www.spinics.net/lists/linux-omap/msg119516.html

Tested-by: Tony Lindgren 
Tested-by: Austin Schuh 
Signed-off-by: Grygorii Strashko 


Patch applied.



Thanks.


I'm thinking that we need some recommendations on how to write
IRQ handlers in order to be RT-compatible. Can you help me lining
up the requirements in Documentation/gpio/driver.txt?

I will write an RFC patch and let you write some additional text
to it in response then we can iterate it a bit.


Sure. I'll try to help.


--
regards,
-grygorii
--
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

[REPOST PATCH 1/4] ARM: dts: DRA7: Add dsp1_system syscon node

2015-10-02 Thread Suman Anna 
The DSP_SYSTEM sub-module is a dedicated system control logic
module present within a DRA7 DSP processor sub-system. This
module is responsible for power management, clock generation
and connection to the device PRCM module.

Add a syscon node for this module for the DSP1 processor
sub-system. This is added as a syscon node as it is a common
configuration module that can be used by the different IOMMU
instances and the corresponding remoteproc device.

The node is added to the common dra7.dtsi file, as the DSP1
processor sub-system is mostly common across all the variants
of the DRA7 SoC family.

Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/dra7.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index e289c706d27d..62055094e8d5 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -292,6 +292,11 @@
#thermal-sensor-cells = <1>;
};
 
+   dsp1_system: dsp_system@40d0 {
+   compatible = "syscon";
+   reg = <0x40d0 0x100>;
+   };
+
sdma: dma-controller@4a056000 {
compatible = "ti,omap4430-sdma";
reg = <0x4a056000 0x1000>;
-- 
2.6.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

[REPOST PATCH 3/4] ARM: dts: DRA7: Add common IOMMU nodes

2015-10-02 Thread Suman Anna 
The DRA7xx family of SOCs have two IPUs and one DSP processor
subsystems in common. The IOMMU DT nodes have been added for
these processor subsystems, and have been disabled by default.

These MMUs are very similar to those on OMAP4 and OMAP5, with
the only difference being the presence of a second MMU within
the DSP subsystem for the EDMA port. The DSP IOMMUs also need
an additional 'ti,syscon-mmuconfig' property compared to the
IPU IOMMUs.

NOTE: The enabling of these nodes is left to the respective
board dts files.

Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/dra7.dtsi | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 62055094e8d5..9f6bafcad385 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -916,6 +916,46 @@
status = "disabled";
};
 
+   mmu0_dsp1: mmu@40d01000 {
+   compatible = "ti,dra7-dsp-iommu";
+   reg = <0x40d01000 0x100>;
+   interrupts = ;
+   ti,hwmods = "mmu0_dsp1";
+   #iommu-cells = <0>;
+   ti,syscon-mmuconfig = <_system 0x0>;
+   status = "disabled";
+   };
+
+   mmu1_dsp1: mmu@40d02000 {
+   compatible = "ti,dra7-dsp-iommu";
+   reg = <0x40d02000 0x100>;
+   interrupts = ;
+   ti,hwmods = "mmu1_dsp1";
+   #iommu-cells = <0>;
+   ti,syscon-mmuconfig = <_system 0x1>;
+   status = "disabled";
+   };
+
+   mmu_ipu1: mmu@58882000 {
+   compatible = "ti,dra7-iommu";
+   reg = <0x58882000 0x100>;
+   interrupts = ;
+   ti,hwmods = "mmu_ipu1";
+   #iommu-cells = <0>;
+   ti,iommu-bus-err-back;
+   status = "disabled";
+   };
+
+   mmu_ipu2: mmu@55082000 {
+   compatible = "ti,dra7-iommu";
+   reg = <0x55082000 0x100>;
+   interrupts = ;
+   ti,hwmods = "mmu_ipu2";
+   #iommu-cells = <0>;
+   ti,iommu-bus-err-back;
+   status = "disabled";
+   };
+
abb_mpu: regulator-abb-mpu {
compatible = "ti,abb-v3";
regulator-name = "abb_mpu";
-- 
2.6.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

[REPOST PATCH 4/4] ARM: dts: DRA74x: Add IOMMU nodes for DSP2

2015-10-02 Thread Suman Anna 
The DRA74x family of SoCs have a second DSP, that also has
two MMUs just like the DSP1 subsystem. Add the IOMMU nodes
for this DSP2 subsystem in disabled state to the DRA74x
specific DTS file, the nodes would need to be enabled
appropriately in the respective board DTS files.

Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/dra74x.dtsi | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index dfa29b7ba86a..2f7d313e91a0 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -81,6 +81,26 @@
dr_mode = "otg";
};
};
+
+   mmu0_dsp2: mmu@41501000 {
+   compatible = "ti,dra7-dsp-iommu";
+   reg = <0x41501000 0x100>;
+   interrupts = ;
+   ti,hwmods = "mmu0_dsp2";
+   #iommu-cells = <0>;
+   ti,syscon-mmuconfig = <_system 0x0>;
+   status = "disabled";
+   };
+
+   mmu1_dsp2: mmu@41502000 {
+   compatible = "ti,dra7-dsp-iommu";
+   reg = <0x41502000 0x100>;
+   interrupts = ;
+   ti,hwmods = "mmu1_dsp2";
+   #iommu-cells = <0>;
+   ti,syscon-mmuconfig = <_system 0x1>;
+   status = "disabled";
+   };
};
 };
 
-- 
2.6.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

[REPOST PATCH 2/4] ARM: dts: DRA74x: Add dsp2_system syscon node

2015-10-02 Thread Suman Anna 
The DSP_SYSTEM sub-module is a dedicated system control logic
module present within a DRA7 DSP processor sub-system. This
module is responsible for power management, clock generation
and connection to the device PRCM module.

Add a syscon node for this module for the DSP2 processor
sub-system. This is added as a syscon node as it is a common
configuration module that can be used by the different IOMMU
instances and the corresponding remoteproc device.

The node is added to the dra74x.dtsi file, as the DSP2 processor
subsystem is usually present only on the DRA74x variants of the
DRA7 SoC family.

Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/dra74x.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index feea98e0a4b5..dfa29b7ba86a 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -52,6 +52,11 @@
};
 
ocp {
+   dsp2_system: dsp_system@4150 {
+   compatible = "syscon";
+   reg = <0x4150 0x100>;
+   };
+
omap_dwc3_4: omap_dwc3_4@4894 {
compatible = "ti,dwc3";
ti,hwmods = "usb_otg_ss4";
-- 
2.6.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

[REPOST PATCH 0/4] Add DRA7 IOMMU DT nodes

2015-10-02 Thread Suman Anna 
Hi Tony,

The following series is a repost of the previous seried that
added the basic DT nodes for the DSP and IPU IOMMU devices for
the DRA7xx SoC family [1]. There are no code changes, but the
patches have to be rebased to resolve slight merge conflicts
as the dra7_ctrl_core and dra7_ctrl_general nodes have been
removed since the last submission.

This patch series is pending based on the equivalent bindings
update series [2] which has also been reposted without any changes.

Patches are based on 4.3-rc3.

regards
Suman

[1] http://marc.info/?l=linux-omap=143752332808524=2
[2] http://marc.info/?l=linux-omap=144382697928741=2

Suman Anna (4):
  ARM: dts: DRA7: Add dsp1_system syscon node
  ARM: dts: DRA74x: Add dsp2_system syscon node
  ARM: dts: DRA7: Add common IOMMU nodes
  ARM: dts: DRA74x: Add IOMMU nodes for DSP2

 arch/arm/boot/dts/dra7.dtsi   | 45 +++
 arch/arm/boot/dts/dra74x.dtsi | 25 
 2 files changed, 70 insertions(+)

-- 
2.6.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

[REPOST PATCH 1/2] Documentation: dt: Update OMAP iommu bindings for DRA7 DSPs

2015-10-02 Thread Suman Anna 
The DSP processor sub-systems on DRA7xx have two MMU instances
each, one for the processor core and the other for an internal
EDMA block. These MMUs need an additional shared register to be
programmed in the DSP_SYSTEM sub-module to be enabled properly.

The OMAP IOMMU bindings is updated to account for this additional
syscon property required for these DSP IOMMU instances on DRA7xx
SoCs. A new compatible "ti,dra7-dsp-iommu" is also defined to
distinguish these devices specifically from other DRA7 IOMMU
devices.

An example of the DRA7 DSP IOMMU nodes is also added to the
document for clarity.

Signed-off-by: Suman Anna 
---
 .../devicetree/bindings/iommu/ti,omap-iommu.txt| 27 ++
 1 file changed, 27 insertions(+)

diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt 
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
index 869699925fd5..4bd10dd881b8 100644
--- a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -4,6 +4,7 @@ Required properties:
 - compatible : Should be one of,
"ti,omap2-iommu" for OMAP2/OMAP3 IOMMU instances
"ti,omap4-iommu" for OMAP4/OMAP5 IOMMU instances
+   "ti,dra7-dsp-iommu" for DRA7xx DSP IOMMU instances
"ti,dra7-iommu" for DRA7xx IOMMU instances
 - ti,hwmods  : Name of the hwmod associated with the IOMMU instance
 - reg: Address space for the configuration registers
@@ -19,6 +20,13 @@ Optional properties:
 Should be either 8 or 32 (default: 32)
 - ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing
  back a bus error response on MMU faults.
+- ti,syscon-mmuconfig : Should be a pair of the phandle to the DSP_SYSTEM
+syscon node that contains the additional control
+register for enabling the MMU, and the MMU instance
+number (0-indexed) within the sub-system. This property
+is required for DSP IOMMU instances on DRA7xx SoCs. The
+instance number should be 0 for DSP MDMA MMUs and 1 for
+DSP EDMA MMUs.
 
 Example:
/* OMAP3 ISP MMU */
@@ -30,3 +38,22 @@ Example:
ti,hwmods = "mmu_isp";
ti,#tlb-entries = <8>;
};
+
+   /* DRA74x DSP2 MMUs */
+   mmu0_dsp2: mmu@41501000 {
+   compatible = "ti,dra7-dsp-iommu";
+   reg = <0x41501000 0x100>;
+   interrupts = ;
+   ti,hwmods = "mmu0_dsp2";
+   #iommu-cells = <0>;
+   ti,syscon-mmuconfig = <_system 0x0>;
+   };
+
+   mmu1_dsp2: mmu@41502000 {
+   compatible = "ti,dra7-dsp-iommu";
+   reg = <0x41502000 0x100>;
+   interrupts = ;
+   ti,hwmods = "mmu1_dsp2";
+   #iommu-cells = <0>;
+   ti,syscon-mmuconfig = <_system 0x1>;
+   };
-- 
2.6.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

[REPOST PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

2015-10-02 Thread Suman Anna 
The DSP MMUs on DRA7xx SoC requires configuring an additional
MMU_CONFIG register present in the DSP_SYSTEM sub module. This
setting dictates whether the DSP Core's MDMA and EDMA traffic
is routed through the respective MMU or not. Add the support
to the OMAP iommu driver so that the traffic is not bypassed
when enabling the MMUs.

The MMU_CONFIG register has two different bits for enabling
each of these two MMUs present in the DSP processor sub-system
on DRA7xx. An id field is added to the OMAP iommu object to
identify and enable each IOMMU. The id information and the
DSP_SYSTEM.MMU_CONFIG register programming is achieved through
the processing of the optional "ti,syscon-mmuconfig" property.
A proper value is assigned to the id field only when this
property is present.

Signed-off-by: Suman Anna 
---
 drivers/iommu/omap-iommu.c | 58 ++
 drivers/iommu/omap-iommu.h |  9 +++
 2 files changed, 67 insertions(+)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 36d0033c2ccb..3dc5b65f3990 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -112,6 +114,18 @@ void omap_iommu_restore_ctx(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(omap_iommu_restore_ctx);
 
+static void dra7_cfg_dspsys_mmu(struct omap_iommu *obj, bool enable)
+{
+   u32 val, mask;
+
+   if (!obj->syscfg)
+   return;
+
+   mask = (1 << (obj->id * DSP_SYS_MMU_CONFIG_EN_SHIFT));
+   val = enable ? mask : 0;
+   regmap_update_bits(obj->syscfg, DSP_SYS_MMU_CONFIG, mask, val);
+}
+
 static void __iommu_set_twl(struct omap_iommu *obj, bool on)
 {
u32 l = iommu_read_reg(obj, MMU_CNTL);
@@ -147,6 +161,8 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
 
iommu_write_reg(obj, pa, MMU_TTB);
 
+   dra7_cfg_dspsys_mmu(obj, true);
+
if (obj->has_bus_err_back)
iommu_write_reg(obj, MMU_GP_REG_BUS_ERR_BACK_EN, MMU_GP_REG);
 
@@ -161,6 +177,7 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
 
l &= ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
+   dra7_cfg_dspsys_mmu(obj, false);
 
dev_dbg(obj->dev, "%s is shutting down\n", obj->name);
 }
@@ -864,6 +881,42 @@ static void omap_iommu_detach(struct omap_iommu *obj)
dev_dbg(obj->dev, "%s: %s\n", __func__, obj->name);
 }
 
+static int omap_iommu_dra7_get_dsp_system_cfg(struct platform_device *pdev,
+ struct omap_iommu *obj)
+{
+   struct device_node *np = pdev->dev.of_node;
+   int ret;
+
+   if (!of_device_is_compatible(np, "ti,dra7-dsp-iommu"))
+   return 0;
+
+   if (!of_property_read_bool(np, "ti,syscon-mmuconfig")) {
+   dev_err(>dev, "ti,syscon-mmuconfig property is 
missing\n");
+   return -EINVAL;
+   }
+
+   obj->syscfg =
+   syscon_regmap_lookup_by_phandle(np, "ti,syscon-mmuconfig");
+   if (IS_ERR(obj->syscfg)) {
+   /* can fail with -EPROBE_DEFER */
+   ret = PTR_ERR(obj->syscfg);
+   return ret;
+   }
+
+   if (of_property_read_u32_index(np, "ti,syscon-mmuconfig", 1,
+  >id)) {
+   dev_err(>dev, "couldn't get the IOMMU instance id within 
subsystem\n");
+   return -EINVAL;
+   }
+
+   if (obj->id != 0 && obj->id != 1) {
+   dev_err(>dev, "invalid IOMMU instance id\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 /*
  * OMAP Device MMU(IOMMU) detection
  */
@@ -907,6 +960,10 @@ static int omap_iommu_probe(struct platform_device *pdev)
if (IS_ERR(obj->regbase))
return PTR_ERR(obj->regbase);
 
+   err = omap_iommu_dra7_get_dsp_system_cfg(pdev, obj);
+   if (err)
+   return err;
+
irq = platform_get_irq(pdev, 0);
if (irq < 0)
return -ENODEV;
@@ -943,6 +1000,7 @@ static const struct of_device_id omap_iommu_of_match[] = {
{ .compatible = "ti,omap2-iommu" },
{ .compatible = "ti,omap4-iommu" },
{ .compatible = "ti,dra7-iommu" },
+   { .compatible = "ti,dra7-dsp-iommu" },
{},
 };
 
diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h
index a656df2f9e03..59628e5017b4 100644
--- a/drivers/iommu/omap-iommu.h
+++ b/drivers/iommu/omap-iommu.h
@@ -30,6 +30,7 @@ struct iotlb_entry {
 struct omap_iommu {
const char  *name;
void __iomem*regbase;
+   struct regmap   *syscfg;
struct device   *dev;
struct iommu_domain *domain;
struct dentry   *debug_dir;
@@ -48,6 +49,7 @@ struct omap_iommu {
void *ctx; /* iommu context: registres saved area */
 
int has_bus_err_back;
+   u32 id;
 };
 
 struct cr_regs {
@@ -159,6 +161,13 @@ static inline

[REPOST PATCH 0/2] DRA7 DSP MMU config support

2015-10-02 Thread Suman Anna 
Hi Joerg,

This is a repost of the DRA7 DSP MMU config support patch series,
baselined on the latest rc (4.3-rc3). Details of the MMUs are summarized
in the previous series [1], and the discussion with Tony did not require
any changes to the code from that series. As per your request, I have
also summarized the testing details below.

I have tested the patches on OMAP3 Beagle-XM, OMAP4 Panda Board,
OMAP5 uEVM and DRA7 Beagle-X15 boards using a OMAP IOMMU unit test
module [2]. The unit test basically requires a test node to be added
to the respective nodes with it using the IOMMU under test. The test
is done during the probe of the test platform driver, with it mainly
attaching to the IOMMU and programming the MMU pagetable. The entire
test branch is hosted [3] for your reference and the corresponding
logs are at [4].

A few additional notes regarding testing:
- OMAP3 IVA MMU node was disabled at the moment in kernel, so it
  had to be enabled in the test branch along with the test node. A
  fix [5] was required in the TI CLK driver for it to pass the
  test, and this fix will be incorporated into the current -rc cycle.
- One MMU device is tested per boot, depending on the IOMMU used by
  the test node.
- This is only a preparatory series in adding the IOMMU support
  for the DRA7 SoCs. Full enablement of DRA7 IOMMUs requires
  DTS nodes, hwmod data and pdata quirks needed for reset management.
  The DRA7 logs therefore do not list any MMUs and the OMAP IOMMU driver
  is not registered even due to the absence of any compatible DT nodes.

This series also had a supplementary DTS patch series previously [6], and
I will be reposting those as well after rebasing for Tony to pick them up
through the linux-omap tree.

regards
Suman

[1] http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013704.html
[2] https://github.com/sumananna/omap-test-iommu/blob/master/main_dt.c
[3] 
https://github.com/sumananna/omap-kernel/commits/iommu/test/4.3-rc3-dra7-dsp-support
[4] 
https://github.com/sumananna/kernel-test-logs/tree/master/4.3-rc3-dra7-dsp-support
[5] http://marc.info/?l=linux-omap=144356627831318=2
[6] http://marc.info/?l=linux-omap=143752332808524=2

Suman Anna (2):
  Documentation: dt: Update OMAP iommu bindings for DRA7 DSPs
  iommu/omap: Add support for configuring dsp iommus on DRA7xx

 .../devicetree/bindings/iommu/ti,omap-iommu.txt| 27 ++
 drivers/iommu/omap-iommu.c | 58 ++
 drivers/iommu/omap-iommu.h |  9 
 3 files changed, 94 insertions(+)

-- 
2.6.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

[PATCH v8 2/4] PM / Domains: add setter for dev.pm_domain

2015-10-02 Thread Tomeu Vizoso 
Adds a function that sets the pointer to dev_pm_domain in struct device
and that warns if the device has already finished probing. The reason
why we want to enforce that is because in the general case that can
cause problems and also that we can simplify code quite a bit if we can
always assume that.

This patch also changes all current code that directly sets the
dev.pm_domain pointer.

Signed-off-by: Tomeu Vizoso 
---

Changes in v8:
- Add dev_pm_domain_set() and update code to use it

 arch/arm/mach-omap2/omap_device.c |  7 ---
 drivers/acpi/acpi_lpss.c  |  5 +++--
 drivers/acpi/device_pm.c  |  5 +++--
 drivers/base/power/clock_ops.c|  5 +++--
 drivers/base/power/common.c   |  8 
 drivers/base/power/domain.c   |  4 ++--
 drivers/gpu/vga/vga_switcheroo.c  | 10 +-
 drivers/misc/mei/pci-me.c |  5 +++--
 drivers/misc/mei/pci-txe.c|  5 +++--
 include/linux/pm_domain.h |  3 +++
 10 files changed, 37 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_device.c 
b/arch/arm/mach-omap2/omap_device.c
index 4cb8fd9f741f..204101d11632 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -168,7 +169,7 @@ static int omap_device_build_from_dt(struct platform_device 
*pdev)
r->name = dev_name(>dev);
}
 
-   pdev->dev.pm_domain = _device_pm_domain;
+   dev_pm_domain_set(>dev, _device_pm_domain);
 
if (device_active) {
omap_device_enable(pdev);
@@ -180,7 +181,7 @@ odbfd_exit1:
 odbfd_exit:
/* if data/we are at fault.. load up a fail handler */
if (ret)
-   pdev->dev.pm_domain = _device_fail_pm_domain;
+   dev_pm_domain_set(>dev, _device_fail_pm_domain);
 
return ret;
 }
@@ -701,7 +702,7 @@ int omap_device_register(struct platform_device *pdev)
 {
pr_debug("omap_device: %s: registering\n", pdev->name);
 
-   pdev->dev.pm_domain = _device_pm_domain;
+   dev_pm_domain_set(>dev, _device_pm_domain);
return platform_device_add(pdev);
 }
 
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index f51bd0d0bc17..cc6e1abc69b3 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -706,7 +707,7 @@ static int acpi_lpss_platform_notify(struct notifier_block 
*nb,
 
switch (action) {
case BUS_NOTIFY_ADD_DEVICE:
-   pdev->dev.pm_domain = _lpss_pm_domain;
+   dev_pm_domain_set(>dev, _lpss_pm_domain);
if (pdata->dev_desc->flags & LPSS_LTR)
return sysfs_create_group(>dev.kobj,
  _attr_group);
@@ -714,7 +715,7 @@ static int acpi_lpss_platform_notify(struct notifier_block 
*nb,
case BUS_NOTIFY_DEL_DEVICE:
if (pdata->dev_desc->flags & LPSS_LTR)
sysfs_remove_group(>dev.kobj, _attr_group);
-   pdev->dev.pm_domain = NULL;
+   dev_pm_domain_set(>dev, NULL);
break;
default:
break;
diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index 4806b7f856c4..8c5955bf9bbf 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "internal.h"
@@ -1076,7 +1077,7 @@ static void acpi_dev_pm_detach(struct device *dev, bool 
power_off)
struct acpi_device *adev = ACPI_COMPANION(dev);
 
if (adev && dev->pm_domain == _general_pm_domain) {
-   dev->pm_domain = NULL;
+   dev_pm_domain_set(dev, NULL);
acpi_remove_pm_notifier(adev);
if (power_off) {
/*
@@ -1128,7 +1129,7 @@ int acpi_dev_pm_attach(struct device *dev, bool power_on)
return -EBUSY;
 
acpi_add_pm_notifier(adev, dev, acpi_pm_notify_work_func);
-   dev->pm_domain = _general_pm_domain;
+   dev_pm_domain_set(dev, _general_pm_domain);
if (power_on) {
acpi_dev_pm_full_power(adev);
acpi_device_wakeup(adev, ACPI_STATE_S0, false);
diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
index 652b5a367c1f..e80fda6c03a9 100644
--- a/drivers/base/power/clock_ops.c
+++ b/drivers/base/power/clock_ops.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef CONFIG_PM
@@ -346,7 +347,7 @@ static int pm_clk_notify(struct notifier_block *nb,
if (error)
break;
 
-   dev->pm_domain = clknb->pm_domain;
+   dev_pm_domain_set(dev, clknb->pm_domain);
if (clknb->con_ids[0]) {
for

[PATCH v8 0/4] Allow USB devices to remain runtime-suspended when sleeping

2015-10-02 Thread Tomeu Vizoso 
Hi,

this is v8 of an attempt to make it easier for devices to remain in
runtime PM when the system goes to sleep, mainly to reduce the time
spent resuming devices.

For this, we interpret the absence of all PM callback implementations as
it being safe to do direct_complete, so their ancestors aren't prevented
from remaining runtime-suspended.

Additionally, the prepare() callback of USB devices will return 1 if
runtime PM is enabled and the current wakeup settings are correct.

With these changes, a uvcvideo device (for example) stays in runtime
suspend when the system goes to sleep and is left in that state when the
system resumes, not delaying it unnecessarily.

Thanks,

Tomeu

Changes in v8:
- Add device_is_bound()
- Add dev_pm_domain_set() and update code to use it
- Move no_pm_callbacks field into CONFIG_PM_SLEEP
- Call device_check_pm_callbacks only after a device is bound or unbound

Changes in v7:
- Reduce indentation by adding a label in device_prepare()

Changes in v6:
- Add stub for !CONFIG_PM.
- Move implementation of device_check_pm_callbacks to power/main.c as it
  doesn't belong to CONFIG_PM_SLEEP.
- Take dev->power.lock before modifying flag.

Changes in v5:
- Check for all dev_pm_ops instances associated to a device, updating a
  no_pm_callbacks flag at the times when that could change.

Tomeu Vizoso (4):
  device core: add device_is_bound()
  PM / Domains: add setter for dev.pm_domain
  PM / sleep: Go direct_complete if driver has no callbacks
  USB / PM: Allow USB devices to remain runtime-suspended when sleeping

 arch/arm/mach-omap2/omap_device.c |  7 ---
 drivers/acpi/acpi_lpss.c  |  5 +++--
 drivers/acpi/device_pm.c  |  5 +++--
 drivers/base/dd.c | 12 ++--
 drivers/base/power/clock_ops.c|  5 +++--
 drivers/base/power/common.c   |  8 
 drivers/base/power/domain.c   |  6 --
 drivers/base/power/main.c | 33 +
 drivers/base/power/power.h|  6 ++
 drivers/gpu/vga/vga_switcheroo.c  | 10 +-
 drivers/misc/mei/pci-me.c |  5 +++--
 drivers/misc/mei/pci-txe.c|  5 +++--
 drivers/usb/core/port.c   |  6 ++
 drivers/usb/core/usb.c| 11 ++-
 include/linux/device.h|  2 ++
 include/linux/pm.h|  1 +
 include/linux/pm_domain.h |  3 +++
 17 files changed, 107 insertions(+), 23 deletions(-)

-- 
2.4.3

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