Re: [PATCH v9] ARM: omap: edma: add suspend resume hook

2014-11-14 Thread Daniel Mack
Hi Sekhar,

On 11/14/2014 06:03 PM, Sekhar Nori wrote:
 I think I have asked this before, and I am still not sure why this call 
 to pm_runtime_get_sync() is needed here. From my testing today, this 
 does seem to be a a no-op and this call returns from rpm_resume() 
 because of this check:
 
   else if (dev-power.disable_depth == 1  dev-power.is_suspended
dev-power.runtime_status == RPM_ACTIVE)
   retval = 1;

Yes. IIRC, it was in fact not needed.

 So, AFAICS, the net effect is an increment of dev-power.usage_count
 (which is already greater than 0) and its subsequent decrement at the
 end of the function.
 
 After removing this call I did not see any EDMA malfunction as well 
 (can access MMC/SD just fine after suspend/resume cycle).
 
 So, any objections to merging this patch with the attached hunk 
 applied?

Looks good to me, we can still add it back later if it turns out to be
needed.


Thanks,
Daniel


 Thanks,
 Sekhar
 
 ---8---
 diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
 index 1f492d5be9c0..79de6a23047b 100644
 --- a/arch/arm/common/edma.c
 +++ b/arch/arm/common/edma.c
 @@ -1803,13 +1803,7 @@ static int edma_probe(struct platform_device *pdev)
  
  static int edma_pm_resume(struct device *dev)
  {
 -   int i, j, r;
 -
 -   r = pm_runtime_get_sync(dev);
 -   if (r  0) {
 -   dev_err(dev, %s: get_sync returned %d\n, __func__, r);
 -   return r;
 -   }
 +   int i, j;
  
 for (j = 0; j  arch_num_cc; j++) {
 struct edma *cc = edma_cc[j];
 @@ -1844,8 +1838,6 @@ static int edma_pm_resume(struct device *dev)
 }
 }
  
 -   pm_runtime_put_sync(dev);
 -
 return 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


Re: [PATCH v7 RESEND] ARM: omap: edma: add suspend suspend/resume hooks

2014-08-26 Thread Daniel Mack
Hi,

On 08/26/2014 08:36 AM, Sekhar Nori wrote:
 On Friday 22 August 2014 01:16 PM, Dave Gerlach wrote:

Thanks for pushing that forward!

 +static int edma_pm_suspend(struct device *dev)
 +{
 +int j, r;
 +
 +r = pm_runtime_get_sync(dev);
 +if (r  0) {
 +dev_err(dev, %s: get_sync returned %d\n, __func__, r);
 +return r;
 +}
 
 The driver currently does a pm_runtime_get_sync() once during probe. And
 does not do a put(). So this should actually be not required. In fact
 looks like this additional get() call will prevent the clock from
 getting disabled which is probably not what you intend.

Well, the pm runtime is put again ...

 +
 +for (j = 0; j  arch_num_cc; j++) {
 +struct edma *ecc = edma_cc[j];
 +
 +disable_irq(ecc-irq_res_start);
 +disable_irq(ecc-irq_res_end);
 
 Do we really need to disable these irqs?
 
 +}
 +
 +pm_runtime_put_sync(dev);

... here, so it's in sync and should be fine.

I was also sure than when I wrote the code, disabling the interrupts
during suspend was necessary, and even the only thing that has to be
done at suspend time. Now that I address this again, my tests show that
in can in fact be omitted.

So I'll send a v9 now that has no edma_pm_suspend() at all anymore.

 +static const struct dev_pm_ops edma_pm_ops = {
 +.suspend_late   = edma_pm_suspend,
 +.resume_early   = edma_pm_resume,
 +};
 
 You can use SET_LATE_SYSTEM_SLEEP_PM_OPS() as some other DMA drivers are
 doing too.

Sure, why not.


Thanks,
Daniel

--
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 v9] ARM: omap: edma: add suspend resume hook

2014-08-26 Thread Daniel Mack
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams and omap_hsmmc.

All information can be reconstructed by already known runtime
information.

As we now use some functions that were previously only used from __init
context, annotations had to be dropped.

[n...@ti.com: added error handling for runtime + suspend_late/early_resume]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Daniel Mack zon...@gmail.com
Tested-by: Joel Fernandes jo...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
Changes from v8:

* Drop the edma_suspend hook altogether. Even though back then
  when I wrote the code I was sure disabling the interrupts
  during suspend is necessary, tests now show it in fact isn't.
  My test setup still works if that code is omitted.
* Use SET_LATE_SYSTEM_SLEEP_PM_OPS in the dev_pm_ops
  declaration.

Thanks to Sekhar for pointing out the above.

 arch/arm/common/edma.c | 60 --
 1 file changed, 58 insertions(+), 2 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 485be42..c623dd0 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -244,6 +244,8 @@ struct edma {
/* list of channels with no even trigger; terminated by -1 */
const s8*noevent;
 
+   struct edma_soc_info *info;
+
/* The edma_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
 */
@@ -295,7 +297,7 @@ static void map_dmach_queue(unsigned ctlr, unsigned ch_no,
~(0x7  bit), queue_no  bit);
 }
 
-static void __init assign_priority_to_queue(unsigned ctlr, int queue_no,
+static void assign_priority_to_queue(unsigned ctlr, int queue_no,
int priority)
 {
int bit = queue_no * 4;
@@ -314,7 +316,7 @@ static void __init assign_priority_to_queue(unsigned ctlr, 
int queue_no,
  * included in that particular EDMA variant (Eg : dm646x)
  *
  */
-static void __init map_dmach_param(unsigned ctlr)
+static void map_dmach_param(unsigned ctlr)
 {
int i;
for (i = 0; i  EDMA_MAX_DMACH; i++)
@@ -1762,15 +1764,69 @@ static int edma_probe(struct platform_device *pdev)
edma_write_array2(j, EDMA_DRAE, i, 1, 0x0);
edma_write_array(j, EDMA_QRAE, i, 0x0);
}
+   edma_cc[j]-info = info[j];
arch_num_cc++;
}
 
return 0;
 }
 
+static int edma_pm_resume(struct device *dev)
+{
+   int i, j, r;
+
+   r = pm_runtime_get_sync(dev);
+   if (r  0) {
+   dev_err(dev, %s: get_sync returned %d\n, __func__, r);
+   return r;
+   }
+
+   for (j = 0; j  arch_num_cc; j++) {
+   struct edma *cc = edma_cc[j];
+
+   s8 (*queue_priority_mapping)[2];
+
+   queue_priority_mapping = cc-info-queue_priority_mapping;
+
+   /* Event queue priority mapping */
+   for (i = 0; queue_priority_mapping[i][0] != -1; i++)
+   assign_priority_to_queue(j,
+queue_priority_mapping[i][0],
+queue_priority_mapping[i][1]);
+
+   /*
+* Map the channel to param entry if channel mapping logic
+* exist
+*/
+   if (edma_read(j, EDMA_CCCFG)  CHMAP_EXIST)
+   map_dmach_param(j);
+
+   for (i = 0; i  cc-num_channels; i++) {
+   if (test_bit(i, cc-edma_inuse)) {
+   /* ensure access through shadow region 0 */
+   edma_or_array2(j, EDMA_DRAE, 0, i  5,
+  BIT(i  0x1f));
+
+   setup_dma_interrupt(i,
+   cc-intr_data[i].callback,
+   cc-intr_data[i].data);
+   }
+   }
+   }
+
+   pm_runtime_put_sync(dev);
+
+   return 0;
+}
+
+static const struct dev_pm_ops edma_pm_ops = {
+   SET_LATE_SYSTEM_SLEEP_PM_OPS(NULL, edma_pm_resume)
+};
+
 static struct platform_driver edma_driver = {
.driver = {
.name   = edma,
+   .pm = edma_pm_ops,
.of_match_table = edma_of_ids,
},
.probe = edma_probe,
-- 
2.1.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


Re: [PATCH] ARM: OMAP: generic: add call to of_clk_init()

2014-07-23 Thread Daniel Mack
Hi Tony,

On 07/23/2014 10:54 AM, Tony Lindgren wrote:
 * Daniel Mack zon...@gmail.com [140712 03:57]:
 This is needed to instanciate fixed clocks in the DT.
 
 Makes sense to me. Does this fix some regression or hang
 that's needed for the -rc series?

No, it's a feature addition. No need to hurry :)

 Also would like to get an ack from Tero on this as the other
 clocks are initialized elsewhere.

Ok, thanks. I'm open to alternative ways of course.


Thanks,
Daniel

--
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] ARM: OMAP: generic: add call to of_clk_init()

2014-07-12 Thread Daniel Mack
This is needed to instanciate fixed clocks in the DT.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 arch/arm/mach-omap2/board-generic.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index 5606fa2..39f154a 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,6 +15,7 @@
 #include linux/of_irq.h
 #include linux/of_platform.h
 #include linux/irqdomain.h
+#include linux/clk-provider.h
 
 #include asm/mach/arch.h
 
@@ -33,6 +34,11 @@ static struct of_device_id omap_dt_match_table[] __initdata 
= {
{ }
 };
 
+static struct of_device_id clk_match[] __initdata = {
+   { .compatible = fixed-clock, .data = of_fixed_clk_setup, },
+   { }
+};
+
 static void __init omap_generic_init(void)
 {
omapdss_early_init_of();
@@ -40,6 +46,8 @@ static void __init omap_generic_init(void)
pdata_quirks_init(omap_dt_match_table);
 
omapdss_init_of();
+
+   of_clk_init(clk_match);
 }
 
 #ifdef CONFIG_SOC_OMAP2420
-- 
1.9.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


Re: [PATCH v4 00/11] ARM: OMAP2+: AM33XX: Add suspend-resume support

2014-07-11 Thread Daniel Mack
On 07/11/2014 04:55 AM, Dave Gerlach wrote:
 This series adds suspend/resume support for am335x. Version 3 of this
 series can be found at [1]. I apologize for the large delay between this
 and the previous revision. This code has been heavily refined
 since the last version based on the various comments received for v3. The
 major change from previous version is moving all wkup_m3 code into a
 remoteproc based driver. The new driver handles all IPC and fw loading
 and exposes a small API to be used by PM code to achieve low power states.

Thanks a lot for this new series, Dave!

I've given it a quick test on a custom AM335x board and can confirm
success. Tested with both DDR2 and DDR3 versions, both work fine, and
power consumption drops to a reasonable level.

I'd be very happy if these patches made it in for 3.17, but I haven't
followed the discussion on the patches this set depends on.


Best regards,
Daniel

--
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: Gadget regression with enabling of MUSB babble interrupt handling

2014-06-19 Thread Daniel Mack
(+ George)

On 06/19/2014 11:56 AM, Tony Lindgren wrote:
 Looks like commit ca88fc2ef0d7 (usb: musb: add a work_struct
 to recover from babble errors) causes MUSB gadgets to stop
 enumerating at least on omap3. Reverting the the commit fixes
 the issue.

Hmm, so do you see babble errors occuring?

Also, there are some more patches for musb and babble error recovery on
the usb list, namely the ones starting here in v6:

  http://marc.info/?l=linux-usbm=140109627505065w=4

Care to give them a try?


Thanks,
Daniel


--
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: Gadget regression with enabling of MUSB babble interrupt handling

2014-06-19 Thread Daniel Mack
Hi Tony,

On 06/19/2014 12:31 PM, Tony Lindgren wrote:
 * Daniel Mack dan...@zonque.org [140619 03:10]:
 On 06/19/2014 11:56 AM, Tony Lindgren wrote:
 Looks like commit ca88fc2ef0d7 (usb: musb: add a work_struct
 to recover from babble errors) causes MUSB gadgets to stop
 enumerating at least on omap3. Reverting the the commit fixes
 the issue.

 Hmm, so do you see babble errors occuring?
 
 Not that I noticed of.
  
 Also, there are some more patches for musb and babble error recovery on
 the usb list, namely the ones starting here in v6:

   http://marc.info/?l=linux-usbm=140109627505065w=4

 Care to give them a try?
 
 I can confirm that [PATCH v6 1/5] usb: musb: core: Handle Babble
 condition only in HOST mode fixes the issue for me. Also the
 explanation in the patch description explains why it breaks, and
 probably for all gadgets too because BABBLE and RESET share the
 same interrupt so it's RESET in peripheral mode.

Ok, thanks for testing. I was told Felipe was out for some weeks, so I
don't know when these patches will be reviewed and merged.

 But that also raises a question: Were these patches merged for
 v3.16 ever even tested in peripheral mode?

At the time, I had no such hardware to test this on, so I was hoping for
more testers to give them a try in different environments, which
apparently didn't happen. It fixed a dead USB port condition on
host-mode enabled hardware, though.

We should make sure at least patch 1/5 from the series mentioned above
makes it to 3.16.


Thanks,
Daniel
--
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: Gadget regression with enabling of MUSB babble interrupt handling

2014-06-19 Thread Daniel Mack
On 06/19/2014 12:43 PM, Tony Lindgren wrote:
 * Daniel Mack dan...@zonque.org [140619 03:38]:
 On 06/19/2014 12:31 PM, Tony Lindgren wrote:
 * Daniel Mack dan...@zonque.org [140619 03:10]:
 On 06/19/2014 11:56 AM, Tony Lindgren wrote:

 But that also raises a question: Were these patches merged for
 v3.16 ever even tested in peripheral mode?

 At the time, I had no such hardware to test this on, so I was hoping for
 more testers to give them a try in different environments, which
 apparently didn't happen. It fixed a dead USB port condition on
 host-mode enabled hardware, though.
 
 Well we probably should not merge patches without proper acks and
 tested-by:s in general as things just seem to keep breaking
 constantly otherwise. And things not working will keep people from
 using linux next which will lead into even less testing..

I'm fairly sure the patch causing your trouble has been in linux-next
for a while before they hit the merge window, so people with gadget
enabled musb could have noticed the breakage early enough. The feedback
rate for patches to this driver posted to linux-usb is also usually low,
unfortunately.

Anyway, breaking things is certainly not good, and I'm sorry for that.
I'm just uncertain what detail in the procedure should be tweaked in
order to prevent that from happening in the future.


Thanks,
Daniel

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


Re: [PATCH v3 0/5] Add support for SW babble Control

2014-05-13 Thread Daniel Mack
Hi George,

On 05/13/2014 10:31 AM, George Cherian wrote:
 Series add support for SW babble control logic found in 
 new silicon versions of AM335x. Runtime differentiation of
 silicon version is done by checking the BABBLE_CTL register.
 For newer silicon the register default value read is 0x4 and
 for older versions its 0x0.

I tested this on a AM33xx platform and don't see any regression at
least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE.
Anything particular you want me to test as well?


Thanks,
Daniel

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


Re: [PATCH v3 0/5] Add support for SW babble Control

2014-05-13 Thread Daniel Mack
On 05/13/2014 01:57 PM, George Cherian wrote:
 On 5/13/2014 3:16 PM, Daniel Mack wrote:
 On 05/13/2014 10:31 AM, George Cherian wrote:
 Series add support for SW babble control logic found in
 new silicon versions of AM335x. Runtime differentiation of
 silicon version is done by checking the BABBLE_CTL register.
 For newer silicon the register default value read is 0x4 and
 for older versions its 0x0.
 I tested this on a AM33xx platform and don't see any regression at
 least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE.
 Anything particular you want me to test as well?
 Are you seeing a wrapper restart done always or does it continue with a 
 restart
 after the babble condition?

MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE, so sw_babble_control() is
called from dsps_musb_reset(). However, MUSB_BABBLE_CTL still returns
0x04 (MUSB_BABBLE_RCV_DISABLE) inside that function, which means
(babble_ctl  MUSB_BABBLE_STUCK_J) is false, and hence
sw_babble_control() returns 1. Consequently, the glue is fully reset in
this case. Does this help?

FWIW, this is the output of dsps_musb_reset() with dev_dbg() enabled:

[   54.066124] CAUTION: musb: Babble Interrupt Occurred
[   54.071856] usb 1-1: USB disconnect, device number 8
[   54.159495] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 4
[   54.166446] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset


I only have one exact USB device to reproduce the babble condition, so I
guess this is all I can do for now.


Thanks,
Daniel

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


Re: [PATCH v3 0/5] Add support for SW babble Control

2014-05-13 Thread Daniel Mack
Hi George,

On 05/13/2014 02:57 PM, George Cherian wrote:
 I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL reg.
 can you try with the following patch.
 
 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index 1ae6681..1160cd1 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
   val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
 - if (val == MUSB_BABBLE_RCV_DISABLE)
 + if (val == MUSB_BABBLE_RCV_DISABLE) {
   glue-sw_babble_enabled = true;
 + val |= MUSB_BABBLE_SW_SESSION_CTRL;
 + dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
 + }
   
   ret = dsps_musb_dbg_init(musb, glue);
   if (ret)

MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?


[   19.672373] CAUTION: musb: Babble Interrupt Occurred
[   19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[   19.685815] usb 1-1: USB disconnect, device number 3
[   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 44
[   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset


I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?

Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?


Daniel

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


Re: [PATCH v3 0/5] Add support for SW babble Control

2014-05-13 Thread Daniel Mack
On 05/13/2014 03:24 PM, George Cherian wrote:
 Basically, there are 2 types of babble conditions.
 1) Transient babble condition - which could be recovered from without an 
 IP reset .
 2) Babble condition - which could be recovered from only by doing an IP 
 reset.

Ok, thanks for the explanation.

 Looks like you are always hitting case 2 (Most times am also hitting the 
 same).

Seems like, yes.

 There is no 100% reliable method to force it to happen. Following is
 my setup ,
 I have a HUB with 4 devices connected , which gives me a Babble interrupt
 on both connects and disconnects ( Not always though).

I also get them at disconnects, but only with one specific USB device.

But as I don't ever see case 1) above, I can't say if your approach
works. What I can say, though, is that your patches don't break the
recovery from babble conditions that I experienced :)


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


Re: [PATCH v2 3/5] usb: musb: core: Convert the musb_platform_reset to have a return value.

2014-05-08 Thread Daniel Mack
Hi Geroge,

On 05/08/2014 11:35 AM, George Cherian wrote:
 -static inline void musb_platform_reset(struct musb *musb)
 +static inline int  musb_platform_reset(struct musb *musb)
  {
 - if (musb-ops-reset)
 - musb-ops-reset(musb);
 + if (!musb-ops-reset)
 + return -EINVAL;
 +
 + return musb-ops-reset(musb);
  }
  
  static inline int musb_platform_get_vbus_status(struct musb *musb)
 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index 74c4193..8438200 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -536,7 +536,7 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
   return 0;
  }
  
 -static void dsps_musb_reset(struct musb *musb)
 +static int dsps_musb_reset(struct musb *musb)
  {
   struct device *dev = musb-controller;
   struct dsps_glue *glue = dev_get_drvdata(dev-parent);
 @@ -548,6 +548,7 @@ static void dsps_musb_reset(struct musb *musb)
   usleep_range(100, 200);
   usb_phy_init(musb-xceiv);
  
 + return 1;

Could we follow the general kernel rule here and return 0 for success,
and  0 on failure?



Thanks,
Daniel

--
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 RESEND] mmc: omap_hsmmc: support more DT properties

2014-03-03 Thread Daniel Mack
This should probably be done implicitly through mmc_of_parse(), but that
doesn't play well along with the multi-slot model the hsmmc driver
features. Hence, for now, do it manually. The properties are already
documented in Documentation/devicetree/bindings/mmc/mmc.txt.

Signed-off-by: Daniel Mack zon...@gmail.com
Acked-by: Balaji T K balaj...@ti.com
---
This is a resend of a patch that was already acked by Balaji T K:

  http://www.spinics.net/lists/linux-mmc/msg25029.html


 drivers/mmc/host/omap_hsmmc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2815de6..a5a38cc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1765,6 +1765,12 @@ static struct omap_mmc_platform_data 
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, ti,needs-special-hs-handling, NULL))
pdata-slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;
 
+   if (of_find_property(np, keep-power-in-suspend, NULL))
+   pdata-slots[0].pm_caps |= MMC_PM_KEEP_POWER;
+
+   if (of_find_property(np, enable-sdio-wakeup, NULL))
+   pdata-slots[0].pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
+
return pdata;
 }
 #else
-- 
1.8.5.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


Re: [PATCH] mmc: omap_hsmmc: support more DT properties

2014-02-24 Thread Daniel Mack
On 02/18/2014 03:36 PM, Balaji T K wrote:
 On Monday 17 February 2014 05:06 PM, Daniel Mack wrote:
 This should probably be done implicitly through mmc_of_parse(), but that
 doesn't play well along with the multi-slot model the hsmmc driver
 features. Hence, for now, do it manually. The properties are already
 documented in Documentation/devicetree/bindings/mmc/mmc.txt.

 Signed-off-by: Daniel Mack zon...@gmail.com
 
 looks good to me
 Acked-by: Balaji T K balaj...@ti.com

Thanks for the review! Did it land in any tree yet?


Best regards,
Daniel

 ---
   drivers/mmc/host/omap_hsmmc.c | 6 ++
   1 file changed, 6 insertions(+)

 diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
 index 2815de6..a5a38cc 100644
 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -1765,6 +1765,12 @@ static struct omap_mmc_platform_data 
 *of_get_hsmmc_pdata(struct device *dev)
  if (of_find_property(np, ti,needs-special-hs-handling, NULL))
  pdata-slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;

 +if (of_find_property(np, keep-power-in-suspend, NULL))
 +pdata-slots[0].pm_caps |= MMC_PM_KEEP_POWER;
 +
 +if (of_find_property(np, enable-sdio-wakeup, NULL))
 +pdata-slots[0].pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
 +
  return pdata;
   }
   #else

 

--
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] mmc: omap_hsmmc: support more DT properties

2014-02-17 Thread Daniel Mack
This should probably be done implicitly through mmc_of_parse(), but that
doesn't play well along with the multi-slot model the hsmmc driver
features. Hence, for now, do it manually. The properties are already
documented in Documentation/devicetree/bindings/mmc/mmc.txt.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/mmc/host/omap_hsmmc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 2815de6..a5a38cc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1765,6 +1765,12 @@ static struct omap_mmc_platform_data 
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, ti,needs-special-hs-handling, NULL))
pdata-slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;
 
+   if (of_find_property(np, keep-power-in-suspend, NULL))
+   pdata-slots[0].pm_caps |= MMC_PM_KEEP_POWER;
+
+   if (of_find_property(np, enable-sdio-wakeup, NULL))
+   pdata-slots[0].pm_caps |= MMC_PM_WAKE_SDIO_IRQ;
+
return pdata;
 }
 #else
-- 
1.8.5.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


Re: AM335x USB DMA seems broken on ISOC URBs

2014-01-20 Thread Daniel Mack
On 01/18/2014 04:12 PM, Daniel Mack wrote:
 On 01/17/2014 05:27 PM, Ezequiel Garcia wrote:
 On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote:

 While doing some experiments with the stk1160 driver (for Easycap TV video
 capture devices), ran into problems using v3.13-rc4. The problem is that the
 stk1160 IRQ handler receives no URBs at all.

[...]

 Let me know if you find anything - I hope to find some time to do
 similar tests on AM33xx based hardware.

I tried using an USB headset connected to a AM33xx based board, using
kernel v3.13.

The good news is that aplay gives me sound, so there's nothing generally
wrong with isochronous streams on musb_dsps/cppi41.

I can also do some simple 'arecord | aplay' loopback, and I can hear the
microphone signal, but the stream breaks down after a couple of seconds,
showing the following error:

[  433.671757] ALSA sound/core/pcm_lib.c:1945 capture write error (DMA
or IRQ trouble?)

Also, when tearing down the aplay stream, the cppi41 driver spits a
number of the warnings below.

Sebastian, do you have any pending patches that might be worth testing?



Thanks,
Daniel



[  340.255651] [ cut here ]
[  340.262828] WARNING: CPU: 0 PID: 112 at drivers/dma/cppi41.c:605
cppi41_dma_control+0x2a8/0x2d4()
[  340.272086] Modules linked in:
[  340.287140] CPU: 0 PID: 112 Comm: aplay Tainted: GW
3.13.0-00051-gff62d1c #1661
[  340.295798] [c00137b8] (unwind_backtrace+0x0/0xf4) from
[c001158c] (show_stack+0x10/0x14)
[  340.304712] [c001158c] (show_stack+0x10/0x14) from [c0037154]
(warn_slowpath_common+0x6c/0x84)
[  340.314070] [c0037154] (warn_slowpath_common+0x6c/0x84) from
[c0037208] (warn_slowpath_null+0x1c/0x24)
[  340.324153] [c0037208] (warn_slowpath_null+0x1c/0x24) from
[c02b50d8] (cppi41_dma_control+0x2a8/0x2d4)
[  340.334255] [c02b50d8] (cppi41_dma_control+0x2a8/0x2d4) from
[c0375f0c] (cppi41_dma_channel_abort+0xcc/0)
[  340.344976] [c0375f0c] (cppi41_dma_channel_abort+0xcc/0x140) from
[c037187c] (musb_cleanup_urb.isra.16+0)
[  340.356147] [c037187c] (musb_cleanup_urb.isra.16+0x58/0x11c) from
[c0371b80] (musb_urb_dequeue+0xe8/0x12)
[  340.366595] [c0371b80] (musb_urb_dequeue+0xe8/0x128) from
[c035aa74] (unlink1+0x2c/0x110)
[  340.375497] [c035aa74] (unlink1+0x2c/0x110) from [c035b2e0]
(usb_hcd_unlink_urb+0x50/0xc4)
[  340.384496] [c035b2e0] (usb_hcd_unlink_urb+0x50/0xc4) from
[c03db53c] (deactivate_urbs+0xd8/0xf4)
[  340.394126] [c03db53c] (deactivate_urbs+0xd8/0xf4) from
[c03dc614] (snd_usb_endpoint_stop+0x30/0x70)
[  340.404032] [c03dc614] (snd_usb_endpoint_stop+0x30/0x70) from
[c03e3d40] (stop_endpoints+0x70/0x88)
[  340.413843] [c03e3d40] (stop_endpoints+0x70/0x88) from [c03e3ea0]
(snd_usb_substream_playback_trigger+0x)
[  340.424836] [c03e3ea0]
(snd_usb_substream_playback_trigger+0x9c/0xb8) from [c03cdb40]
(snd_pcm_do_stop+0)
[  340.435917] [c03cdb40] (snd_pcm_do_stop+0x54/0x58) from
[c03cd768] (snd_pcm_action_single+0x38/0x78)
[  340.445816] [c03cd768] (snd_pcm_action_single+0x38/0x78) from
[c03cd970] (snd_pcm_drop+0x6c/0xc4)
[  340.455443] [c03cd970] (snd_pcm_drop+0x6c/0xc4) from [c03cf22c]
(snd_pcm_common_ioctl1+0xc90/0x109c)
[  340.465344] [c03cf22c] (snd_pcm_common_ioctl1+0xc90/0x109c) from
[c03cf7f0] (snd_pcm_playback_ioctl1+0x1)
[  340.476434] [c03cf7f0] (snd_pcm_playback_ioctl1+0x1b8/0x4b0) from
[c00e7a60] (do_vfs_ioctl+0x3fc/0x5f0)
[  340.486607] [c00e7a60] (do_vfs_ioctl+0x3fc/0x5f0) from [c00e7cc4]
(SyS_ioctl+0x70/0x80)
[  340.495331] [c00e7cc4] (SyS_ioctl+0x70/0x80) from [c000e340]
(ret_fast_syscall+0x0/0x48)
[  340.504136] ---[ end trace 521a83c0d2567bbb ]---


--
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: AM335x USB DMA seems broken on ISOC URBs

2014-01-18 Thread Daniel Mack
Hi Ezequiel,

On 01/17/2014 05:27 PM, Ezequiel Garcia wrote:
 On Sun, Dec 22, 2013 at 02:59:45AM -0300, Ezequiel Garcia wrote:
 Hello,

 While doing some experiments with the stk1160 driver (for Easycap TV video
 capture devices), ran into problems using v3.13-rc4. The problem is that the
 stk1160 IRQ handler receives no URBs at all.

 When configuring with CONFIG_MUSB_PIO_ONLY this looks solved, but the
 bandwidth requirements are too large for PIO (it's a raw video device) and 
 the
 video can't get captured.

 Interesting enough, using an old backported for v3.2 stk1160 driver, this 
 same
 setup works with TI PSP v3.2 kernel. So, I guess it's some software bug in
 either the cppi41 dmaengine or the musb.

 I tried to compare the PSP to the mainline drivers but they seems *very*
 different and really beyond my understanding.

 Any ideas on how can I help debugging this?

 
 Ping? It would be good to hunt thig bug down. The TI PSP provided USB driver
 works fine so at least that's a starting point...
 

Did you try this with a different type of peripheral hardware, a USB
audio device for example? You could also check whether the packets are
actually received by the DMA driver but dropped before the USB subsys
gets to see them for whatever reason.

Let me know if you find anything - I hope to find some time to do
similar tests on AM33xx based hardware.


Daniel

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


Re: [PATCH v7] ARM: omap: edma: add suspend suspend/resume hooks

2013-11-29 Thread Daniel Mack
On 11/29/2013 09:08 AM, Brian Murphy wrote:
 On 11/27/2013 02:56 PM, Daniel Mack wrote:
 This patch makes the edma driver resume correctly after suspend. Tested
 on an AM33xx platform with cyclic audio streams and omap_hsmmc.
 
 Can I ask which git this patch is relative to? There is no
 suspend/resume support for AM33xx in Linus Torvalds kernel as far as I 
 can see.

I am based on 3.13-rc1 with some patches from Suman Anna, Vaibhav Bedia
and Dave Gerlach that have been posted on arm-linux some month ago.

This patch can be merged independently as it has no dependency on those.

We already did the same for cppi41, musb, mcasp and some other drivers,
which gradually learn support for suspend in mainline now. Only the core
bits are missing, but I'm sure someone from TI is pushing them forward :)


Daniel

--
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 v6] ARM: omap: edma: add suspend suspend/resume hooks

2013-11-27 Thread Daniel Mack
On 11/27/2013 02:22 PM, Sekhar Nori wrote:
 + Kevin
 
 On Monday 25 November 2013 11:04 PM, Joel Fernandes wrote:
 On 11/17/2013 04:19 PM, Daniel Mack wrote:
 This patch makes the edma driver resume correctly after suspend. Tested
 on an AM33xx platform with cyclic audio streams and omap_hsmmc.

 All information can be reconstructed by already known runtime
 information.

 As we now use some functions that were previously only used from __init
 context, annotations had to be dropped.

 [n...@ti.com: added error handling for runtime + suspend_late/early_resume]
 Signed-off-by: Nishanth Menon n...@ti.com
 Signed-off-by: Daniel Mack zon...@gmail.com
 Tested-by: Joel Fernandes jo...@ti.com
 Acked-by: Joel Fernandes jo...@ti.com

 Hi Sekhar,

 Can you consider pulling this patch? It has been tested and Acked. Thanks.
 
 Kevin had some inputs on previous version of this patch. Were you able
 to make sure he is okay with this version being merged?

I had concerns about the feedback I got, and haven't got answers yet.

In particular, I'm not convinced that using runtime PM to suspend
channels would actually save any power during runtime, or have any other
benefit. But I might be wrong - maybe someone at TI could comment on that?


Thanks,
Daniel

--
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 v6] ARM: omap: edma: add suspend suspend/resume hooks

2013-11-27 Thread Daniel Mack
Hi Sekhar,

On 11/27/2013 02:35 PM, Sekhar Nori wrote:
 On Monday 18 November 2013 03:49 AM, Daniel Mack wrote:

 +static int edma_pm_suspend(struct device *dev)
 +{
 +int j, r;
 +
 +r = pm_runtime_get_sync(dev);
 +if (IS_ERR_VALUE(r)) {
 
 So IS_ERR_VALUE() is only for functions which may return a negative
 number outside of MAX_ERRNO as a success indication.
 pm_runtime_get_sync() does not appear to be one of them so just use

 if (r  0) { .. }

That's true. Thanks for catching this, I'll fix it. However, grepping
through the tree, there are quite a lot places where the same mistake is
made.

 +/* Map the channel to param entry if channel mapping logic
 + * exist
 + */
 
 Please follow the multi-line commenting style.

Can do. However, these lines in fact follow the style that is used
throughout the entire file ;)

 There are some checkpatch checks that result from lines like this.
 Please fix these as well.
 
 CHECK: Alignment should match open parenthesis
 #179: FILE: arch/arm/common/edma.c:1841:
 + map_queue_tc(j, queue_tc_mapping[i][0],
 + queue_tc_mapping[i][1]);

If you say so, even though I disagree with checkpatch.pl here. The above
is actually more readable, right? :)


Thanks,
Daniel

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


[PATCH v7] ARM: omap: edma: add suspend suspend/resume hooks

2013-11-27 Thread Daniel Mack
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams and omap_hsmmc.

All information can be reconstructed by already known runtime
information.

As we now use some functions that were previously only used from __init
context, annotations had to be dropped.

[n...@ti.com: added error handling for runtime + suspend_late/early_resume]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Daniel Mack zon...@gmail.com
Tested-by: Joel Fernandes jo...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
v6 - v7:

 * Addressed comments from Sekhar Nori:

   * pm_runtime_get_sync() returns negative errors, so do not use
 IS_ERR_VALUE()
   * Several style fixes


 arch/arm/common/edma.c | 95 --
 1 file changed, 92 insertions(+), 3 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 41bca32..dece66d 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -239,6 +239,8 @@ struct edma {
/* list of channels with no even trigger; terminated by -1 */
const s8*noevent;
 
+   struct edma_soc_info *info;
+
/* The edma_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
 */
@@ -290,13 +292,13 @@ static void map_dmach_queue(unsigned ctlr, unsigned ch_no,
~(0x7  bit), queue_no  bit);
 }
 
-static void __init map_queue_tc(unsigned ctlr, int queue_no, int tc_no)
+static void map_queue_tc(unsigned ctlr, int queue_no, int tc_no)
 {
int bit = queue_no * 4;
edma_modify(ctlr, EDMA_QUETCMAP, ~(0x7  bit), ((tc_no  0x7)  bit));
 }
 
-static void __init assign_priority_to_queue(unsigned ctlr, int queue_no,
+static void assign_priority_to_queue(unsigned ctlr, int queue_no,
int priority)
 {
int bit = queue_no * 4;
@@ -315,7 +317,7 @@ static void __init assign_priority_to_queue(unsigned ctlr, 
int queue_no,
  * included in that particular EDMA variant (Eg : dm646x)
  *
  */
-static void __init map_dmach_param(unsigned ctlr)
+static void map_dmach_param(unsigned ctlr)
 {
int i;
for (i = 0; i  EDMA_MAX_DMACH; i++)
@@ -1785,15 +1787,102 @@ static int edma_probe(struct platform_device *pdev)
edma_write_array2(j, EDMA_DRAE, i, 1, 0x0);
edma_write_array(j, EDMA_QRAE, i, 0x0);
}
+   edma_cc[j]-info = info[j];
arch_num_cc++;
}
 
return 0;
 }
 
+static int edma_pm_suspend(struct device *dev)
+{
+   int j, r;
+
+   r = pm_runtime_get_sync(dev);
+   if (r  0) {
+   dev_err(dev, %s: get_sync returned %d\n, __func__, r);
+   return r;
+   }
+
+   for (j = 0; j  arch_num_cc; j++) {
+   struct edma *ecc = edma_cc[j];
+
+   disable_irq(ecc-irq_res_start);
+   disable_irq(ecc-irq_res_end);
+   }
+
+   pm_runtime_put_sync(dev);
+
+   return 0;
+}
+
+static int edma_pm_resume(struct device *dev)
+{
+   int i, j, r;
+
+   r = pm_runtime_get_sync(dev);
+   if (r  0) {
+   dev_err(dev, %s: get_sync returned %d\n, __func__, r);
+   return r;
+   }
+
+   for (j = 0; j  arch_num_cc; j++) {
+   struct edma *cc = edma_cc[j];
+
+   s8 (*queue_priority_mapping)[2];
+   s8 (*queue_tc_mapping)[2];
+
+   queue_tc_mapping = cc-info-queue_tc_mapping;
+   queue_priority_mapping = cc-info-queue_priority_mapping;
+
+   /* Event queue to TC mapping */
+   for (i = 0; queue_tc_mapping[i][0] != -1; i++)
+   map_queue_tc(j, queue_tc_mapping[i][0],
+queue_tc_mapping[i][1]);
+
+   /* Event queue priority mapping */
+   for (i = 0; queue_priority_mapping[i][0] != -1; i++)
+   assign_priority_to_queue(j,
+queue_priority_mapping[i][0],
+queue_priority_mapping[i][1]);
+
+   /*
+* Map the channel to param entry if channel mapping logic
+* exist
+*/
+   if (edma_read(j, EDMA_CCCFG)  CHMAP_EXIST)
+   map_dmach_param(j);
+
+   for (i = 0; i  cc-num_channels; i++) {
+   if (test_bit(i, cc-edma_inuse)) {
+   /* ensure access through shadow region 0 */
+   edma_or_array2(j, EDMA_DRAE, 0, i  5,
+  BIT(i  0x1f));
+
+   setup_dma_interrupt(i,
+   cc-intr_data[i].callback,
+   cc-intr_data[i

Re: [PATCH 1/5] usb: musb: conditionally save and restore the context on suspend

2013-11-26 Thread Daniel Mack
On 11/26/2013 11:50 AM, Sergei Shtylyov wrote:
 On 25-11-2013 23:39, Daniel Mack wrote:
 
 It appears not all platforms featuring a musb core need to save the musb
 core registers at suspend time and restore them on resume.
 
 The dsps platform does, however. So add a bit in struct
 musb_hdrc_platform_data to let platforms specify their need of such
 action being taken.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 [...]
 
 diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
 index eb50525..e5a581c 100644
 --- a/include/linux/usb/musb.h
 +++ b/include/linux/usb/musb.h
 @@ -99,6 +99,9 @@ struct musb_hdrc_platform_data {
  /* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
  u8  mode;

 +/* should the musb core restore registers after suspend? */
 +u8  restore_after_suspend:1;
 +
 
 Better placement seems to be with 'extvbus' field which is also 1-bit -- 
 that would save space in the structure.

That patch is deprecated, as things are now done unconditionally,
without consulting this flag.


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


Re: [PATCH v2 4/4] usb: musb: dsps: add support for suspend and resume

2013-11-26 Thread Daniel Mack
On 11/25/2013 10:32 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 10:30:37PM +0100, Daniel Mack wrote:
 On 11/25/2013 10:29 PM, Felipe Balbi wrote:
 Hi,

 On Mon, Nov 25, 2013 at 10:26:43PM +0100, Daniel Mack wrote:
 +static int dsps_resume(struct device *dev)
 +{
 +  struct dsps_glue *glue = dev_get_drvdata(dev);
 +  const struct dsps_musb_wrapper *wrp = glue-wrp;
 +  struct musb *musb = platform_get_drvdata(glue-musb);
 +  void __iomem *mbase = musb-ctrl_base;
 +
 +  dsps_writel(mbase, wrp-control, glue-context.control);
 +  dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
 +  dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
 +  dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
 +  dsps_writel(mbase, wrp-mode, glue-context.mode);
 +  dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
 +  dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
 +
 +  //musb_port_reset(musb, false);

 


 Urgs. Development left-over. Sorry. You want me to resend the whole
 series or just this last patch?
 
 just the last patch is fine :-)

Sorry, there was one more hunk that shouldn't be there. I'll resend a v4
with all the patches included again, for reference.

--
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 v4 0/4] musb/dsps: suspend related patches for 3.14 (rebased)

2013-11-26 Thread Daniel Mack
v2 - v3:
 * removed a development left-over

v3 - v4:
 * one hunk removed that sneaked in during rebasing


Daniel Mack (4):
  usb: musb: unconditionally save and restore the context on suspend
  usb: musb: call musb_port_suspend from musb_bus_suspend
  usb: musb: dsps: add {tx,rx}_mode to wrapper
  usb: musb: dsps: add support for suspend and resume

 drivers/usb/musb/musb_core.c| 14 +-
 drivers/usb/musb/musb_dsps.c| 61 +
 drivers/usb/musb/musb_host.c|  9 +-
 drivers/usb/musb/musb_host.h|  4 +++
 drivers/usb/musb/musb_virthub.c |  4 +--
 include/linux/usb/musb.h|  3 ++
 6 files changed, 91 insertions(+), 4 deletions(-)

-- 
1.8.4.2

--
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 v4 4/4] usb: musb: dsps: add support for suspend and resume

2013-11-26 Thread Daniel Mack
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.

We also have to explicitly de-assert the port reset upon resume on this
platform, but musb_port_reset() should not be called from glue layers.

Hence, introduce a flag in struct musb_hdrc_config for this.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c| 57 +
 drivers/usb/musb/musb_host.c|  7 -
 drivers/usb/musb/musb_host.h|  2 ++
 drivers/usb/musb/musb_virthub.c |  2 +-
 include/linux/usb/musb.h|  3 +++
 5 files changed, 69 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index e57d712..3600af0 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
u8  poll_seconds;
 };
 
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+   u32 control;
+   u32 epintr;
+   u32 coreintr;
+   u32 phy_utmi;
+   u32 mode;
+   u32 tx_mode;
+   u32 rx_mode;
+};
+
 /**
  * DSPS glue structure.
  */
@@ -121,6 +134,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+   struct dsps_context context;
 };
 
 static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -509,6 +524,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
 
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
+   config-host_port_deassert_reset_at_resume = 1;
pdata.mode = get_musb_port_mode(dev);
/* DT keeps this entry in mA, musb expects it as per USB spec */
pdata.power = get_int_prop(dn, mentor,power) / 2;
@@ -632,11 +648,52 @@ static const struct of_device_id musb_dsps_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
 
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   glue-context.control = dsps_readl(mbase, wrp-control);
+   glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+   glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+   glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+   glue-context.mode = dsps_readl(mbase, wrp-mode);
+   glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
+   glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
+
+   return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   dsps_writel(mbase, wrp-control, glue-context.control);
+   dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+   dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+   dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+   dsps_writel(mbase, wrp-mode, glue-context.mode);
+   dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+   dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
.remove = dsps_remove,
.driver = {
.name   = musb-dsps,
+   .pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
 };
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 81caf9f..8224138 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2464,7 +2464,12 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
 
 static int musb_bus_resume(struct usb_hcd *hcd)
 {
-   /* resuming child port does the work */
+   struct musb *musb = hcd_to_musb(hcd);
+
+   if (musb-config 
+   musb-config-host_port_deassert_reset_at_resume)
+   musb_port_reset(musb, false);
+
return 0;
 }
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index e660af9..7436c24 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void

[PATCH v4 2/4] usb: musb: call musb_port_suspend from musb_bus_suspend

2013-11-26 Thread Daniel Mack
Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_host.c| 2 ++
 drivers/usb/musb/musb_host.h| 2 ++
 drivers/usb/musb/musb_virthub.c | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 6582a20..81caf9f 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8  devctl;
 
+   musb_port_suspend(musb, true);
+
if (!is_host_active(musb))
return 0;
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 960d735..e660af9 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -92,6 +92,7 @@ extern void musb_host_rx(struct musb *, u8);
 extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
+extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -121,6 +122,7 @@ static inline void musb_root_disconnect(struct musb *musb)  
{}
 static inline void musb_host_resume_root_hub(struct musb *musb){}
 static inline void musb_host_poll_rh_status(struct musb *musb) {}
 static inline void musb_host_poke_root_hub(struct musb *musb)  {}
+static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
 #endif
 
 struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 9af6bba..e977441 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -44,7 +44,7 @@
 
 #include musb_core.h
 
-static void musb_port_suspend(struct musb *musb, bool do_suspend)
+void musb_port_suspend(struct musb *musb, bool do_suspend)
 {
struct usb_otg  *otg = musb-xceiv-otg;
u8  power;
-- 
1.8.4.2

--
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 v4 1/4] usb: musb: unconditionally save and restore the context on suspend

2013-11-26 Thread Daniel Mack
It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.

The dsps platform does, however, and because it should cause any trouble
on other platforms, do it unconditionally.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0a43329..797709d 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2215,16 +2215,28 @@ static int musb_suspend(struct device *dev)
 */
}
 
+   musb_save_context(musb);
+
spin_unlock_irqrestore(musb-lock, flags);
return 0;
 }
 
 static int musb_resume_noirq(struct device *dev)
 {
-   /* for static cmos like DaVinci, register values were preserved
+   struct musb *musb = dev_to_musb(dev);
+
+   /*
+* For static cmos like DaVinci, register values were preserved
 * unless for some reason the whole soc powered down or the USB
 * module got reset through the PSC (vs just being disabled).
+*
+* For the DSPS glue layer though, a full register restore has to
+* be done. As it shouldn't harm other platforms, we do it
+* unconditionally.
 */
+
+   musb_restore_context(musb);
+
return 0;
 }
 
-- 
1.8.4.2

--
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 v4 3/4] usb: musb: dsps: add {tx,rx}_mode to wrapper

2013-11-26 Thread Daniel Mack
rx_mode and tx_mode need to be read at suspend time and restored on
resume for dsps platforms. So add it to the wrapper struct first, and
initialize the values.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1901f6f..e57d712 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -83,6 +83,8 @@ struct dsps_musb_wrapper {
u16 coreintr_status;
u16 phy_utmi;
u16 mode;
+   u16 tx_mode;
+   u16 rx_mode;
 
/* bit positions for control */
unsignedreset:5;
@@ -605,6 +607,8 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
.coreintr_status= 0x34,
.phy_utmi   = 0xe0,
.mode   = 0xe8,
+   .tx_mode= 0x70,
+   .rx_mode= 0x74,
.reset  = 0,
.otg_disable= 21,
.iddig  = 8,
-- 
1.8.4.2

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


[PATCH 1/5] usb: musb: conditionally save and restore the context on suspend

2013-11-25 Thread Daniel Mack
It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.

The dsps platform does, however. So add a bit in struct
musb_hdrc_platform_data to let platforms specify their need of such
action being taken.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.c | 17 -
 include/linux/usb/musb.h |  3 +++
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0a43329..a8ded57 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2202,6 +2202,7 @@ static int musb_suspend(struct device *dev)
 {
struct musb *musb = dev_to_musb(dev);
unsigned long   flags;
+   struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
 
spin_lock_irqsave(musb-lock, flags);
 
@@ -2215,16 +2216,30 @@ static int musb_suspend(struct device *dev)
 */
}
 
+   if (plat-restore_after_suspend)
+   musb_save_context(musb);
+
spin_unlock_irqrestore(musb-lock, flags);
return 0;
 }
 
 static int musb_resume_noirq(struct device *dev)
 {
-   /* for static cmos like DaVinci, register values were preserved
+   struct musb *musb = dev_to_musb(dev);
+   struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
+
+   /*
+* For static cmos like DaVinci, register values were preserved
 * unless for some reason the whole soc powered down or the USB
 * module got reset through the PSC (vs just being disabled).
+*
+* The plaform data tells us about the necessity of saving and
+* restoring the context across a suspend cycle.
 */
+
+   if (plat-restore_after_suspend)
+   musb_restore_context(musb);
+
return 0;
 }
 
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index eb50525..e5a581c 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,6 +99,9 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8  mode;
 
+   /* should the musb core restore registers after suspend? */
+   u8  restore_after_suspend:1;
+
/* for clk_get() */
const char  *clock;
 
-- 
1.8.4.2

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


[PATCH 0/5] musb/dsps: suspend related patches for 3.14 (rebased)

2013-11-25 Thread Daniel Mack
Hi Felipe,

These five patches for musb/dsps didn't make it into 3.13, which is no
big deal, at least as far as I'm concerned :)

I rebased the missing bits on top of 3.13-rc1. There are no functional
changes in comparison to what was posted earlier on this list.

Successfully tested on a AM33xx board.


Thanks,
Daniel


Daniel Mack (5):
  usb: musb: conditionally save and restore the context on suspend
  usb: musb: call musb_port_suspend from musb_bus_suspend
  usb: musb: dsps: add {tx,rx}_mode to wrapper
  usb: musb: dsps: add support for suspend and resume
  usb: musb: dsps: indentation and whitespace fixes

 drivers/usb/musb/musb_core.c| 17 +++-
 drivers/usb/musb/musb_core.h|  1 +
 drivers/usb/musb/musb_dsps.c| 86 +++--
 drivers/usb/musb/musb_host.c|  2 +
 drivers/usb/musb/musb_host.h|  4 ++
 drivers/usb/musb/musb_virthub.c |  4 +-
 include/linux/usb/musb.h|  3 ++
 7 files changed, 102 insertions(+), 15 deletions(-)

-- 
1.8.4.2

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


[PATCH 4/5] usb: musb: dsps: add support for suspend and resume

2013-11-25 Thread Daniel Mack
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.

We also have to call musb_port_reset() for this platform upon resume, so
this function has to be made non-static.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.h|  1 +
 drivers/usb/musb/musb_dsps.c| 59 +
 drivers/usb/musb/musb_host.h|  2 ++
 drivers/usb/musb/musb_virthub.c |  2 +-
 4 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 29f7cd7..a423037 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -295,6 +295,7 @@ struct musb {
 
irqreturn_t (*isr)(int, void *);
struct work_struct  irq_work;
+
u16 hwvers;
 
u16 intrrxe;
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index e57d712..361ddf8 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
u8  poll_seconds;
 };
 
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+   u32 control;
+   u32 epintr;
+   u32 coreintr;
+   u32 phy_utmi;
+   u32 mode;
+   u32 tx_mode;
+   u32 rx_mode;
+};
+
 /**
  * DSPS glue structure.
  */
@@ -121,6 +134,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+   struct dsps_context context;
 };
 
 static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -506,6 +521,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
}
pdata.config = config;
pdata.platform_ops = dsps_ops;
+   pdata.restore_after_suspend = 1;
 
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
@@ -632,11 +648,54 @@ static const struct of_device_id musb_dsps_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
 
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   glue-context.control = dsps_readl(mbase, wrp-control);
+   glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+   glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+   glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+   glue-context.mode = dsps_readl(mbase, wrp-mode);
+   glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
+   glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
+
+   return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   dsps_writel(mbase, wrp-control, glue-context.control);
+   dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+   dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+   dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+   dsps_writel(mbase, wrp-mode, glue-context.mode);
+   dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+   dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+   musb_port_reset(musb, false);
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
.remove = dsps_remove,
.driver = {
.name   = musb-dsps,
+   .pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
 };
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index e660af9..7436c24 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
 extern void musb_port_suspend(struct musb *musb, bool do_suspend);
+extern void musb_port_reset(struct musb *musb, bool do_reset);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -123,6 +124,7 @@ static inline void musb_host_resume_root_hub(struct musb 
*musb) {}
 static inline void musb_host_poll_rh_status(struct

[PATCH 3/5] usb: musb: dsps: add {tx,rx}_mode to wrapper

2013-11-25 Thread Daniel Mack
rx_mode and tx_mode need to be read at suspend time and restored on
resume for dsps platforms. So add it to the wrapper struct first, and
initialize the values.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1901f6f..e57d712 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -83,6 +83,8 @@ struct dsps_musb_wrapper {
u16 coreintr_status;
u16 phy_utmi;
u16 mode;
+   u16 tx_mode;
+   u16 rx_mode;
 
/* bit positions for control */
unsignedreset:5;
@@ -605,6 +607,8 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
.coreintr_status= 0x34,
.phy_utmi   = 0xe0,
.mode   = 0xe8,
+   .tx_mode= 0x70,
+   .rx_mode= 0x74,
.reset  = 0,
.otg_disable= 21,
.iddig  = 8,
-- 
1.8.4.2

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


[PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

2013-11-25 Thread Daniel Mack
Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_host.c| 2 ++
 drivers/usb/musb/musb_host.h| 2 ++
 drivers/usb/musb/musb_virthub.c | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 6582a20..81caf9f 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8  devctl;
 
+   musb_port_suspend(musb, true);
+
if (!is_host_active(musb))
return 0;
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 960d735..e660af9 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -92,6 +92,7 @@ extern void musb_host_rx(struct musb *, u8);
 extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
+extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -121,6 +122,7 @@ static inline void musb_root_disconnect(struct musb *musb)  
{}
 static inline void musb_host_resume_root_hub(struct musb *musb){}
 static inline void musb_host_poll_rh_status(struct musb *musb) {}
 static inline void musb_host_poke_root_hub(struct musb *musb)  {}
+static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
 #endif
 
 struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 9af6bba..e977441 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -44,7 +44,7 @@
 
 #include musb_core.h
 
-static void musb_port_suspend(struct musb *musb, bool do_suspend)
+void musb_port_suspend(struct musb *musb, bool do_suspend)
 {
struct usb_otg  *otg = musb-xceiv-otg;
u8  power;
-- 
1.8.4.2

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


[PATCH 5/5] usb: musb: dsps: indentation and whitespace fixes

2013-11-25 Thread Daniel Mack
Just a cosmetic thing, no functional change.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 361ddf8..b27c072 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -131,9 +131,9 @@ struct dsps_context {
 struct dsps_glue {
struct device *dev;
struct platform_device *musb;   /* child musb pdev */
-   const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
+   const struct dsps_musb_wrapper *wrp;/* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
-   unsigned long last_timer;/* last timer data for each instance */
+   unsigned long last_timer;   /* last timer data for each instance */
 
struct dsps_context context;
 };
@@ -213,7 +213,7 @@ static void dsps_musb_disable(struct musb *musb)
 
dsps_writel(reg_base, wrp-coreintr_clear, wrp-usb_bitmap);
dsps_writel(reg_base, wrp-epintr_clear,
-wrp-txep_bitmap | wrp-rxep_bitmap);
+   wrp-txep_bitmap | wrp-rxep_bitmap);
dsps_writeb(musb-mregs, MUSB_DEVCTL, 0);
 }
 
@@ -234,7 +234,7 @@ static void otg_timer(unsigned long _musb)
 */
devctl = dsps_readb(mregs, MUSB_DEVCTL);
dev_dbg(musb-controller, Poll devctl %02x (%s)\n, devctl,
-   usb_otg_state_string(musb-xceiv-state));
+   usb_otg_state_string(musb-xceiv-state));
 
spin_lock_irqsave(musb-lock, flags);
switch (musb-xceiv-state) {
@@ -298,7 +298,7 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
dsps_writel(reg_base, wrp-coreintr_status, usbintr);
 
dev_dbg(musb-controller, usbintr (%x) epintr(%x)\n,
-   usbintr, epintr);
+   usbintr, epintr);
/*
 * DRVVBUS IRQs are the only proxy we have (a very poor one!) for
 * DSPS IP's missing ID change IRQ.  We need an ID change IRQ to
@@ -348,10 +348,9 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
 
/* NOTE: this must complete power-on within 100 ms. */
dev_dbg(musb-controller, VBUS %s (%s)%s, devctl %02x\n,
-   drvvbus ? on : off,
-   usb_otg_state_string(musb-xceiv-state),
-   err ?  ERROR : ,
-   devctl);
+   drvvbus ? on : off,
+   usb_otg_state_string(musb-xceiv-state),
+   err ?  ERROR : , devctl);
ret = IRQ_HANDLED;
}
 
@@ -692,9 +691,9 @@ static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, 
dsps_resume);
 
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
-   .remove = dsps_remove,
-   .driver = {
-   .name   = musb-dsps,
+   .remove = dsps_remove,
+   .driver = {
+   .name   = musb-dsps,
.pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
-- 
1.8.4.2

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


Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

2013-11-25 Thread Daniel Mack
On 11/25/2013 08:46 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:39:50PM +0100, Daniel Mack wrote:
 Make musb_port_suspend() externally available, and call it when to host
 goes into suspend. This allows the core to go into suspend while a
 device is connected.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_host.c| 2 ++
  drivers/usb/musb/musb_host.h| 2 ++
  drivers/usb/musb/musb_virthub.c | 2 +-
  3 files changed, 5 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
 index 6582a20..81caf9f 100644
 --- a/drivers/usb/musb/musb_host.c
 +++ b/drivers/usb/musb/musb_host.c
 @@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
  struct musb *musb = hcd_to_musb(hcd);
  u8  devctl;
  
 +musb_port_suspend(musb, true);
 
 have you considered the fact that when musb looses context it'll cause a
 disconnect on the bus because soft_connect bit is lost ?

 What if you have a mounted file system on a pendrive ? Should we allow
 suspend in that case ?

Well, I would have expected that, but in fact, the opposite is true.
With 3.12, mounting a filesystem on a USB media and accessing it after
resume was exactly my test case, and it worked just fine with that patch.

In 3.13, something about the parition table reading seems to be broken
currently, I'll have a closer look.


Thanks,
Daniel

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


Re: [PATCH 5/5] usb: musb: dsps: indentation and whitespace fixes

2013-11-25 Thread Daniel Mack
On 11/25/2013 08:49 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:39:53PM +0100, Daniel Mack wrote:
 Just a cosmetic thing, no functional change.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_dsps.c | 23 +++
  1 file changed, 11 insertions(+), 12 deletions(-)

 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index 361ddf8..b27c072 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -131,9 +131,9 @@ struct dsps_context {
  struct dsps_glue {
  struct device *dev;
  struct platform_device *musb;   /* child musb pdev */
 -const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
 +const struct dsps_musb_wrapper *wrp;/* wrapper register offsets */
  struct timer_list timer;/* otg_workaround timer */
 -unsigned long last_timer;/* last timer data for each instance */
 +unsigned long last_timer;   /* last timer data for each instance */
  
  struct dsps_context context;
  };
 @@ -213,7 +213,7 @@ static void dsps_musb_disable(struct musb *musb)
  
  dsps_writel(reg_base, wrp-coreintr_clear, wrp-usb_bitmap);
  dsps_writel(reg_base, wrp-epintr_clear,
 - wrp-txep_bitmap | wrp-rxep_bitmap);
 +wrp-txep_bitmap | wrp-rxep_bitmap);
 
 quite frankly, I don't what checkpatch.pl is trying to force here. I
 much prefer a tab-only indentation, matching with ( characters forces us
 to add some spaces. I would rather not take this patch.
 

Alright, I really don't care much. I'll drop the patch when resending.

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


Re: [PATCH 4/5] usb: musb: dsps: add support for suspend and resume

2013-11-25 Thread Daniel Mack
On 11/25/2013 08:48 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:39:52PM +0100, Daniel Mack wrote:
 The dsps platform needs to save save some registers at suspend time and
 restore them after resume. This patch adds a struct for these registers,
 and also lets the musb core know that the core registers need to be
 saved as well.

 We also have to call musb_port_reset() for this platform upon resume, so
 this function has to be made non-static.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_core.h|  1 +
  drivers/usb/musb/musb_dsps.c| 59 
 +
  drivers/usb/musb/musb_host.h|  2 ++
  drivers/usb/musb/musb_virthub.c |  2 +-
  4 files changed, 63 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
 index 29f7cd7..a423037 100644
 --- a/drivers/usb/musb/musb_core.h
 +++ b/drivers/usb/musb/musb_core.h
 @@ -295,6 +295,7 @@ struct musb {
  
  irqreturn_t (*isr)(int, void *);
  struct work_struct  irq_work;
 +
  u16 hwvers;
  
  u16 intrrxe;
 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index e57d712..361ddf8 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
  u8  poll_seconds;
  };
  
 +/*
 + * register shadow for suspend
 + */
 +struct dsps_context {
 +u32 control;
 +u32 epintr;
 +u32 coreintr;
 +u32 phy_utmi;
 +u32 mode;
 +u32 tx_mode;
 +u32 rx_mode;
 +};
 +
  /**
   * DSPS glue structure.
   */
 @@ -121,6 +134,8 @@ struct dsps_glue {
  const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
  struct timer_list timer;/* otg_workaround timer */
  unsigned long last_timer;/* last timer data for each instance */
 +
 +struct dsps_context context;
  };
  
  static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
 @@ -506,6 +521,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
  }
  pdata.config = config;
  pdata.platform_ops = dsps_ops;
 +pdata.restore_after_suspend = 1;
  
  config-num_eps = get_int_prop(dn, mentor,num-eps);
  config-ram_bits = get_int_prop(dn, mentor,ram-bits);
 @@ -632,11 +648,54 @@ static const struct of_device_id musb_dsps_of_match[] 
 = {
  };
  MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
  
 +#ifdef CONFIG_PM
 +static int dsps_suspend(struct device *dev)
 +{
 +struct dsps_glue *glue = dev_get_drvdata(dev);
 +const struct dsps_musb_wrapper *wrp = glue-wrp;
 +struct musb *musb = platform_get_drvdata(glue-musb);
 +void __iomem *mbase = musb-ctrl_base;
 +
 +glue-context.control = dsps_readl(mbase, wrp-control);
 +glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
 +glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
 +glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
 +glue-context.mode = dsps_readl(mbase, wrp-mode);
 +glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
 +glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
 +
 +return 0;
 +}
 +
 +static int dsps_resume(struct device *dev)
 +{
 +struct dsps_glue *glue = dev_get_drvdata(dev);
 +const struct dsps_musb_wrapper *wrp = glue-wrp;
 +struct musb *musb = platform_get_drvdata(glue-musb);
 +void __iomem *mbase = musb-ctrl_base;
 +
 +dsps_writel(mbase, wrp-control, glue-context.control);
 +dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
 +dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
 +dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
 +dsps_writel(mbase, wrp-mode, glue-context.mode);
 +dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
 +dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
 +
 +musb_port_reset(musb, false);
 +
 +return 0;
 +}
 +#endif
 +
 +static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
 +
  static struct platform_driver dsps_usbss_driver = {
  .probe  = dsps_probe,
  .remove = dsps_remove,
  .driver = {
  .name   = musb-dsps,
 +.pm = dsps_pm_ops,
  .of_match_table = musb_dsps_of_match,
  },
  };
 diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
 index e660af9..7436c24 100644
 --- a/drivers/usb/musb/musb_host.h
 +++ b/drivers/usb/musb/musb_host.h
 @@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
  extern void musb_host_resume_root_hub(struct musb *musb);
  extern void musb_host_poke_root_hub(struct musb *musb);
  extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 +extern void musb_port_reset(struct musb *musb, bool do_reset);
  #else
  static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
  {
 @@ -123,6 +124,7 @@ static inline void

Re: [PATCH 1/5] usb: musb: conditionally save and restore the context on suspend

2013-11-25 Thread Daniel Mack
On 11/25/2013 08:44 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 08:39:49PM +0100, Daniel Mack wrote:
 It appears not all platforms featuring a musb core need to save the musb
 core registers at suspend time and restore them on resume.

 The dsps platform does, however. So add a bit in struct
 musb_hdrc_platform_data to let platforms specify their need of such
 action being taken.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_core.c | 17 -
  include/linux/usb/musb.h |  3 +++
  2 files changed, 19 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
 index 0a43329..a8ded57 100644
 --- a/drivers/usb/musb/musb_core.c
 +++ b/drivers/usb/musb/musb_core.c
 @@ -2202,6 +2202,7 @@ static int musb_suspend(struct device *dev)
  {
  struct musb *musb = dev_to_musb(dev);
  unsigned long   flags;
 +struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
 
 we don't want to have platform_data on DT-based boot. It's best to just
 save those registers unconditionally as it doesn't hurt.
 

My concern about doing it unconditionally from the core is simply that I
fear regressions for other platforms. I can of course drop it if you're
certain that that's correct.

I can only test this on a dsps glue layer, and I have no documentation
for the musb core. All I'm left with here is fishing in muddy waters :/


Daniel

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


Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

2013-11-25 Thread Daniel Mack
On 11/25/2013 09:01 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 08:58:22PM +0100, Daniel Mack wrote:
 On 11/25/2013 08:46 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:39:50PM +0100, Daniel Mack wrote:
 Make musb_port_suspend() externally available, and call it when to host
 goes into suspend. This allows the core to go into suspend while a
 device is connected.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_host.c| 2 ++
  drivers/usb/musb/musb_host.h| 2 ++
  drivers/usb/musb/musb_virthub.c | 2 +-
  3 files changed, 5 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
 index 6582a20..81caf9f 100644
 --- a/drivers/usb/musb/musb_host.c
 +++ b/drivers/usb/musb/musb_host.c
 @@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8  devctl;
  
 +  musb_port_suspend(musb, true);

 have you considered the fact that when musb looses context it'll cause a
 disconnect on the bus because soft_connect bit is lost ?

 What if you have a mounted file system on a pendrive ? Should we allow
 suspend in that case ?

 Well, I would have expected that, but in fact, the opposite is true.
 With 3.12, mounting a filesystem on a USB media and accessing it after
 resume was exactly my test case, and it worked just fine with that patch.
 
 so you had a mounted file system, suspend, resume, it was still mounted?

Yes, exactly.

 or did it reenumerate and you remounted it ?

No, it did not reenumerate, but the core did a reset on it. See the
following log.

# mount /dev/sda /mnt
# md5sum /mnt/sine_left.wav
bcd90548c1ebf293289072f1a6161f0f  /mnt/sine_left.wav
#
#
# echo mem  /sys/power/state
[   31.553425] PM: Syncing filesystems ... done.
[   31.575462] Freezing user space processes ... (elapsed 0.002 seconds)
done.
[   31.585275] Freezing remaining freezable tasks ... (elapsed 0.002
seconds) done.
[   31.595953] PM: Sending message for entering DeepSleep mode
[   31.628887] PM: suspend of devices complete after 21.097 msecs
[   31.641082] PM: late suspend of devices complete after 5.906 msecs
[   31.653834] PM: noirq suspend of devices complete after 6.135 msecs
[   31.660558] PM: GFX domain entered low power state
[   31.660558] PM: Successfully put all powerdomains to target state
[   31.660558] PM: Wakeup source GPIO0
[   31.679130] PM: noirq resume of devices complete after 17.941 msecs
[   31.693371] PM: early resume of devices complete after 4.388 msecs
[   31.702750] net eth0: initializing cpsw version 1.12 (0)
[   31.712084] net eth0: phy found : id is : 0x4dd076
[   31.717317] libphy: PHY  not found
[   31.722448] net eth0: phy  not found on slave 1
[   32.030792] usb 1-1: reset high-speed USB device number 2 using
musb-hdrc  !
[   32.395192] PM: resume of devices complete after 695.279 msecs
[   32.407816] PM: Sending message for resetting M3 state machine
[   32.414683] Restarting tasks ... done.
[   36.701568] libphy: 4a101000.mdio:04 - Link is Up - 100/Full
#
#
# md5sum /mnt/sine_left.wav
bcd90548c1ebf293289072f1a6161f0f  /mnt/sine_left.wav

 Try to do the same with transfers in flight, it's likely to corrupt your
 file system.

I did that as well, and it appeared stable to me. After all, the USB
device was properly put into suspend before VBUS went away, and the usb
storage driver caught up after the core's reset.

In my tests, this was the only approach that would work after resume.



Daniel

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


Re: [PATCH 4/5] usb: musb: dsps: add support for suspend and resume

2013-11-25 Thread Daniel Mack
On 11/25/2013 09:08 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 09:04:16PM +0100, Daniel Mack wrote:
 diff --git a/drivers/usb/musb/musb_virthub.c 
 b/drivers/usb/musb/musb_virthub.c
 index e977441..24e46c0 100644
 --- a/drivers/usb/musb/musb_virthub.c
 +++ b/drivers/usb/musb/musb_virthub.c
 @@ -109,7 +109,7 @@ void musb_port_suspend(struct musb *musb, bool 
 do_suspend)
}
  }
  
 -static void musb_port_reset(struct musb *musb, bool do_reset)
 +void musb_port_reset(struct musb *musb, bool do_reset)

 NAK, this should not be called from the glue layers at all. If anything
 call from musb_core's resume callback. That will only be called after
 parent's resume has been called anyway.

 Given that this driver is successfully used with suspend/resume on other
 platforms without that reset, but it's clearly needed for dsps, I'm
 fairly sure this should be a glue-layer specific thing. Hence the change.

 I think it'll break things on other platforms if we unconditionally
 reset the port after resume, but I can't test it. Anyone?
 
 your original commit log only says we need to issue port reset but it
 never explains why. It could very well be you just found a device which
 needs to be reset when coming out of suspend and it misses a quirk flag ?

I think I can really rule that out, as I tested with multiple USB sticks
and also tested the same sticks on other embedded platforms.

 In any case, those functions should never be called by the glue, if
 reset needs to be called, it must be called by musb-hdrc.ko, if you need
 a flag, pass a flag but I need a really good explanation in your commit
 log of why that's necessary.

Well, if I'd only knew exactly why. All these patches are really the
result of many days of trial and error, with multiple drivers (musb,
cppi41, ...) involved. And as I said - I have no documentation of the
musb core itself.

So yes, I can do it the other way around and pass a flag, but what I
can't provide is a good explanantion why the dsps glue behaves
differently here than others. I'm curious myself, and all I know is that
with this reset in place, things work as expected on AM33xx.


Thanks for your feedback,
Daniel

--
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/5] usb: musb: conditionally save and restore the context on suspend

2013-11-25 Thread Daniel Mack
On 11/25/2013 09:13 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 09:08:51PM +0100, Daniel Mack wrote:
 On 11/25/2013 08:44 PM, Felipe Balbi wrote:
 Hi,

 On Mon, Nov 25, 2013 at 08:39:49PM +0100, Daniel Mack wrote:
 It appears not all platforms featuring a musb core need to save the musb
 core registers at suspend time and restore them on resume.

 The dsps platform does, however. So add a bit in struct
 musb_hdrc_platform_data to let platforms specify their need of such
 action being taken.

 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/usb/musb/musb_core.c | 17 -
  include/linux/usb/musb.h |  3 +++
  2 files changed, 19 insertions(+), 1 deletion(-)

 diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
 index 0a43329..a8ded57 100644
 --- a/drivers/usb/musb/musb_core.c
 +++ b/drivers/usb/musb/musb_core.c
 @@ -2202,6 +2202,7 @@ static int musb_suspend(struct device *dev)
  {
struct musb *musb = dev_to_musb(dev);
unsigned long   flags;
 +  struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);

 we don't want to have platform_data on DT-based boot. It's best to just
 save those registers unconditionally as it doesn't hurt.


 My concern about doing it unconditionally from the core is simply that I
 fear regressions for other platforms. I can of course drop it if you're
 certain that that's correct.

 I can only test this on a dsps glue layer, and I have no documentation
 for the musb core. All I'm left with here is fishing in muddy waters :/
 
 I really don't think it should cause any issues with any other platform.
 
 We can make to leave this soaking in linux-next for a long time and hope
 people test it.
 

Ok, sounds good. I'll do it and repost, along with the other changes.


Many thanks,
Daniel


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


Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

2013-11-25 Thread Daniel Mack
On 11/25/2013 09:41 PM, Alan Stern wrote:
 On Mon, 25 Nov 2013, Daniel Mack wrote:
 
 What if you have a mounted file system on a pendrive ? Should we allow
 suspend in that case ?

 Well, I would have expected that, but in fact, the opposite is true.
 With 3.12, mounting a filesystem on a USB media and accessing it after
 resume was exactly my test case, and it worked just fine with that patch.

 so you had a mounted file system, suspend, resume, it was still mounted?

 Yes, exactly.

 or did it reenumerate and you remounted it ?

 No, it did not reenumerate, but the core did a reset on it. See the
 following log.
 
 ...
 [   32.030792] usb 1-1: reset high-speed USB device number 2 using
 musb-hdrc  !
 
 Like I said, you get a reset-resume.

Yup. We can't avoid losing VBUS on this platform, and even if we could,
we wouldn't want that, in order to save as much power as possible.

 Try to do the same with transfers in flight, it's likely to corrupt your
 file system.
 
 It's not so easy to suspend a system with USB mass-storage transfers in 
 flight.  For one thing, userspace gets frozen before the suspend 
 starts, so there's nothing to initiate new I/O requests (except perhaps 
 for dirty-block writebacks).
 
 Also, the child SCSI device gets suspended before the USB device, so
 its I/O queue stops running.  In addition, the usb-storage suspend
 routine and the main I/O thread are mutually exclusive (they both grab
 the private mutex), so a suspend can't occur while a SCSI command is
 underway.

Thanks Alan for the explanation. That was my understanding as well.


Best regards,
Daniel

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


Re: [PATCH 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

2013-11-25 Thread Daniel Mack
On 11/25/2013 09:01 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 08:58:22PM +0100, Daniel Mack wrote:

 In 3.13, something about the parition table reading seems to be broken
 currently, I'll have a closer look.
 
 cool

Ah, and forget about this one. I didn't look close enough. There's no
such issue in 3.13. Sorry for the noise.




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


Re: [PATCH 4/5] usb: musb: dsps: add support for suspend and resume

2013-11-25 Thread Daniel Mack
On 11/25/2013 09:46 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 09:26:55PM +0100, Daniel Mack wrote:
 On 11/25/2013 09:08 PM, Felipe Balbi wrote:
 On Mon, Nov 25, 2013 at 09:04:16PM +0100, Daniel Mack wrote:
 diff --git a/drivers/usb/musb/musb_virthub.c 
 b/drivers/usb/musb/musb_virthub.c
 index e977441..24e46c0 100644
 --- a/drivers/usb/musb/musb_virthub.c
 +++ b/drivers/usb/musb/musb_virthub.c
 @@ -109,7 +109,7 @@ void musb_port_suspend(struct musb *musb, bool 
 do_suspend)
  }
  }
  
 -static void musb_port_reset(struct musb *musb, bool do_reset)
 +void musb_port_reset(struct musb *musb, bool do_reset)

 NAK, this should not be called from the glue layers at all. If anything
 call from musb_core's resume callback. That will only be called after
 parent's resume has been called anyway.

 Given that this driver is successfully used with suspend/resume on other
 platforms without that reset, but it's clearly needed for dsps, I'm
 fairly sure this should be a glue-layer specific thing. Hence the change.

 I think it'll break things on other platforms if we unconditionally
 reset the port after resume, but I can't test it. Anyone?

 your original commit log only says we need to issue port reset but it
 never explains why. It could very well be you just found a device which
 needs to be reset when coming out of suspend and it misses a quirk flag ?

 I think I can really rule that out, as I tested with multiple USB sticks
 and also tested the same sticks on other embedded platforms.

 In any case, those functions should never be called by the glue, if
 reset needs to be called, it must be called by musb-hdrc.ko, if you need
 a flag, pass a flag but I need a really good explanation in your commit
 log of why that's necessary.

 Well, if I'd only knew exactly why. All these patches are really the
 result of many days of trial and error, with multiple drivers (musb,
 cppi41, ...) involved. And as I said - I have no documentation of the
 musb core itself.

 So yes, I can do it the other way around and pass a flag, but what I
 can't provide is a good explanantion why the dsps glue behaves
 differently here than others. I'm curious myself, and all I know is that
 with this reset in place, things work as expected on AM33xx.
 
 ok, then let's pass a flag. Meanwhile I'll try to figure out internally
 why we need that reset.

Well, we don't need a reset, I wasn't quite precise here. What we need
is to manually *de*assert the reset when we resume. Note the 'false'
flag that is passed to musb_port_reset().

 As Alan said, usb-persist should already for a
 bus-reset when resuming, right ?

The explicit un-reset is really needed, otherwise the port will
reenumerate the device, and a previously mounted filesystem will become
invalid of course. The log looks like this in that case:

[   17.045641] PM: resume of devices complete after 166.084 msecs
[   17.056461] PM: Sending message for resetting M3 state machine
[   17.063451] Restarting tasks ... [   17.071767] usb 1-1: USB
disconnect, device number 2
done.
[   17.403402] usb 1-1: new high-speed USB device number 3 using musb-hdrc
[   17.766959] usb 1-1: New USB device found, idVendor=058f, idProduct=6387
[   17.774849] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3



Thanks,
Daniel

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


[PATCH v2 2/4] usb: musb: call musb_port_suspend from musb_bus_suspend

2013-11-25 Thread Daniel Mack
Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_host.c| 2 ++
 drivers/usb/musb/musb_host.h| 2 ++
 drivers/usb/musb/musb_virthub.c | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 6582a20..81caf9f 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8  devctl;
 
+   musb_port_suspend(musb, true);
+
if (!is_host_active(musb))
return 0;
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 960d735..e660af9 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -92,6 +92,7 @@ extern void musb_host_rx(struct musb *, u8);
 extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
+extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -121,6 +122,7 @@ static inline void musb_root_disconnect(struct musb *musb)  
{}
 static inline void musb_host_resume_root_hub(struct musb *musb){}
 static inline void musb_host_poll_rh_status(struct musb *musb) {}
 static inline void musb_host_poke_root_hub(struct musb *musb)  {}
+static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
 #endif
 
 struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 9af6bba..e977441 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -44,7 +44,7 @@
 
 #include musb_core.h
 
-static void musb_port_suspend(struct musb *musb, bool do_suspend)
+void musb_port_suspend(struct musb *musb, bool do_suspend)
 {
struct usb_otg  *otg = musb-xceiv-otg;
u8  power;
-- 
1.8.4.2

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


[PATCH v2 1/4] usb: musb: unconditionally save and restore the context on suspend

2013-11-25 Thread Daniel Mack
It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.

The dsps platform does, however, and because it shouldn't cause any
trouble on other platforms, do it unconditionally for all of them.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0a43329..797709d 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2215,16 +2215,28 @@ static int musb_suspend(struct device *dev)
 */
}
 
+   musb_save_context(musb);
+
spin_unlock_irqrestore(musb-lock, flags);
return 0;
 }
 
 static int musb_resume_noirq(struct device *dev)
 {
-   /* for static cmos like DaVinci, register values were preserved
+   struct musb *musb = dev_to_musb(dev);
+
+   /*
+* For static cmos like DaVinci, register values were preserved
 * unless for some reason the whole soc powered down or the USB
 * module got reset through the PSC (vs just being disabled).
+*
+* For the DSPS glue layer though, a full register restore has to
+* be done. As it shouldn't harm other platforms, we do it
+* unconditionally.
 */
+
+   musb_restore_context(musb);
+
return 0;
 }
 
-- 
1.8.4.2

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


[PATCH v2 3/4] usb: musb: dsps: add {tx,rx}_mode to wrapper

2013-11-25 Thread Daniel Mack
rx_mode and tx_mode need to be read at suspend time and restored on
resume for dsps platforms. So add it to the wrapper struct first, and
initialize the values.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1901f6f..e57d712 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -83,6 +83,8 @@ struct dsps_musb_wrapper {
u16 coreintr_status;
u16 phy_utmi;
u16 mode;
+   u16 tx_mode;
+   u16 rx_mode;
 
/* bit positions for control */
unsignedreset:5;
@@ -605,6 +607,8 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
.coreintr_status= 0x34,
.phy_utmi   = 0xe0,
.mode   = 0xe8,
+   .tx_mode= 0x70,
+   .rx_mode= 0x74,
.reset  = 0,
.otg_disable= 21,
.iddig  = 8,
-- 
1.8.4.2

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


[PATCH v2 4/4] usb: musb: dsps: add support for suspend and resume

2013-11-25 Thread Daniel Mack
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.

We also have to explicitly de-assert the port reset upon resume on this
platform, but musb_port_reset() should not be called from glue layers.

Hence, introduce a flag in struct musb_hdrc_config for this.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c| 60 +
 drivers/usb/musb/musb_host.c|  7 -
 drivers/usb/musb/musb_host.h|  2 ++
 drivers/usb/musb/musb_virthub.c |  2 +-
 include/linux/usb/musb.h|  3 +++
 5 files changed, 72 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index e57d712..4a6ab1a 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
u8  poll_seconds;
 };
 
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+   u32 control;
+   u32 epintr;
+   u32 coreintr;
+   u32 phy_utmi;
+   u32 mode;
+   u32 tx_mode;
+   u32 rx_mode;
+};
+
 /**
  * DSPS glue structure.
  */
@@ -121,6 +134,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+   struct dsps_context context;
 };
 
 static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -506,9 +521,11 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
}
pdata.config = config;
pdata.platform_ops = dsps_ops;
+   pdata.restore_after_suspend = 1;
 
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
+   config-host_port_deassert_reset_at_resume = 1;
pdata.mode = get_musb_port_mode(dev);
/* DT keeps this entry in mA, musb expects it as per USB spec */
pdata.power = get_int_prop(dn, mentor,power) / 2;
@@ -632,11 +649,54 @@ static const struct of_device_id musb_dsps_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
 
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   glue-context.control = dsps_readl(mbase, wrp-control);
+   glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+   glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+   glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+   glue-context.mode = dsps_readl(mbase, wrp-mode);
+   glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
+   glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
+
+   return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   dsps_writel(mbase, wrp-control, glue-context.control);
+   dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+   dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+   dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+   dsps_writel(mbase, wrp-mode, glue-context.mode);
+   dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+   dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+   //musb_port_reset(musb, false);
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
.remove = dsps_remove,
.driver = {
.name   = musb-dsps,
+   .pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
 };
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 81caf9f..8224138 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2464,7 +2464,12 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
 
 static int musb_bus_resume(struct usb_hcd *hcd)
 {
-   /* resuming child port does the work */
+   struct musb *musb = hcd_to_musb(hcd);
+
+   if (musb-config 
+   musb-config-host_port_deassert_reset_at_resume)
+   musb_port_reset(musb, false);
+
return 0;
 }
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index e660af9..7436c24 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb

[PATCH v2 0/4] musb/dsps: suspend related patches for 3.14 (rebased)

2013-11-25 Thread Daniel Mack
v1 - v2:

 * *un*conditionally save and restore registers upon suspend/resume
   rather than only doing it for the DSPS glue.
 * do not call musb_port_reset() from glue, but rather introduce a
   flag and let musb-hdrc.ko do it.
 * dropped 'usb: musb: dsps: indentation and whitespace fixes'

Daniel Mack (4):
  usb: musb: unconditionally save and restore the context on suspend
  usb: musb: call musb_port_suspend from musb_bus_suspend
  usb: musb: dsps: add {tx,rx}_mode to wrapper
  usb: musb: dsps: add support for suspend and resume

 drivers/usb/musb/musb_core.c| 14 -
 drivers/usb/musb/musb_dsps.c| 64 +
 drivers/usb/musb/musb_host.c|  9 +-
 drivers/usb/musb/musb_host.h|  4 +++
 drivers/usb/musb/musb_virthub.c |  4 +--
 include/linux/usb/musb.h|  3 ++
 6 files changed, 94 insertions(+), 4 deletions(-)

-- 
1.8.4.2

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


Re: [PATCH v2 4/4] usb: musb: dsps: add support for suspend and resume

2013-11-25 Thread Daniel Mack
On 11/25/2013 10:29 PM, Felipe Balbi wrote:
 Hi,
 
 On Mon, Nov 25, 2013 at 10:26:43PM +0100, Daniel Mack wrote:
 +static int dsps_resume(struct device *dev)
 +{
 +struct dsps_glue *glue = dev_get_drvdata(dev);
 +const struct dsps_musb_wrapper *wrp = glue-wrp;
 +struct musb *musb = platform_get_drvdata(glue-musb);
 +void __iomem *mbase = musb-ctrl_base;
 +
 +dsps_writel(mbase, wrp-control, glue-context.control);
 +dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
 +dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
 +dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
 +dsps_writel(mbase, wrp-mode, glue-context.mode);
 +dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
 +dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
 +
 +//musb_port_reset(musb, false);
 
 
 

Urgs. Development left-over. Sorry. You want me to resend the whole
series or just this last patch?


Daniel

--
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 v4] ARM: omap: edma: add suspend suspend/resume hooks

2013-11-17 Thread Daniel Mack
Hi Nishanth,

On 11/15/2013 03:39 PM, Nishanth Menon wrote:
 To trigger the fail, I created a custom Test case on TI vendor kernel
 based on v3.12 tag:
 On beagleBone-Black
 test scenario (BBB):
 
 Boot from SD card
 ensure firmware is loaded (rev 0x182)
 run LTP fsstress [1] in background on EMMC
 mkdir -p /tmp/testing
 mke2fs /dev/mmcblk1p1
 mount /dev/mmcblk1p1 /tmp/testing
 fsstress -d /tmp/testing p 4 -n 1000 -l0 -v /dev/null 
 run ping in the background (to add yet another interface)
 run memtester[2] (70% of free memory)
 memtester 343M /dev/null 
 sleep 10 (to allow memtester to start up properly)
 start=`date`;i=0; while [ 1 ]; do rtcwake -d /dev/rtc0 -m mem -s
 2; i=$((i + 1)); echo $i: start =$start, now=`date`; sleep 2; done
 
 Eventual hang log (using the regular suspend-resume): [3] - took close
 to two days of testing to trigger this.
 
 Moving to a suspend_late and resume_early such as in [4], it passed
 the test for over 4 days now.

Wow, that's an intense test that you have there :)

 Daniel,
 will be good if you could post [4] for comments if you think that is
 the right thing to do and helps solve the issue you saw as  well.

Alright, will do!


Thanks a lot,
Daniel

--
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 v6] ARM: omap: edma: add suspend suspend/resume hooks

2013-11-17 Thread Daniel Mack
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams and omap_hsmmc.

All information can be reconstructed by already known runtime
information.

As we now use some functions that were previously only used from __init
context, annotations had to be dropped.

[n...@ti.com: added error handling for runtime + suspend_late/early_resume]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Daniel Mack zon...@gmail.com
Tested-by: Joel Fernandes jo...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---

v6:
  amended version from Nishanth Menon, adding error handling for runtime,
  and using suspend_late/early_resume.


 arch/arm/common/edma.c | 94 --
 1 file changed, 91 insertions(+), 3 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 8e1a024..e2b9638 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -239,6 +239,8 @@ struct edma {
/* list of channels with no even trigger; terminated by -1 */
const s8*noevent;
 
+   struct edma_soc_info *info;
+
/* The edma_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
 */
@@ -290,13 +292,13 @@ static void map_dmach_queue(unsigned ctlr, unsigned ch_no,
~(0x7  bit), queue_no  bit);
 }
 
-static void __init map_queue_tc(unsigned ctlr, int queue_no, int tc_no)
+static void map_queue_tc(unsigned ctlr, int queue_no, int tc_no)
 {
int bit = queue_no * 4;
edma_modify(ctlr, EDMA_QUETCMAP, ~(0x7  bit), ((tc_no  0x7)  bit));
 }
 
-static void __init assign_priority_to_queue(unsigned ctlr, int queue_no,
+static void assign_priority_to_queue(unsigned ctlr, int queue_no,
int priority)
 {
int bit = queue_no * 4;
@@ -315,7 +317,7 @@ static void __init assign_priority_to_queue(unsigned ctlr, 
int queue_no,
  * included in that particular EDMA variant (Eg : dm646x)
  *
  */
-static void __init map_dmach_param(unsigned ctlr)
+static void map_dmach_param(unsigned ctlr)
 {
int i;
for (i = 0; i  EDMA_MAX_DMACH; i++)
@@ -1785,15 +1787,101 @@ static int edma_probe(struct platform_device *pdev)
edma_write_array2(j, EDMA_DRAE, i, 1, 0x0);
edma_write_array(j, EDMA_QRAE, i, 0x0);
}
+   edma_cc[j]-info = info[j];
arch_num_cc++;
}
 
return 0;
 }
 
+static int edma_pm_suspend(struct device *dev)
+{
+   int j, r;
+
+   r = pm_runtime_get_sync(dev);
+   if (IS_ERR_VALUE(r)) {
+   dev_err(dev, %s: get_sync returned %d\n, __func__, r);
+   return r;
+   }
+
+   for (j = 0; j  arch_num_cc; j++) {
+   struct edma *ecc = edma_cc[j];
+
+   disable_irq(ecc-irq_res_start);
+   disable_irq(ecc-irq_res_end);
+   }
+
+   pm_runtime_put_sync(dev);
+
+   return 0;
+}
+
+static int edma_pm_resume(struct device *dev)
+{
+   int i, j, r;
+
+   r = pm_runtime_get_sync(dev);
+   if (IS_ERR_VALUE(r)) {
+   dev_err(dev, %s: get_sync returned %d\n, __func__, r);
+   return r;
+   }
+
+   for (j = 0; j  arch_num_cc; j++) {
+   struct edma *cc = edma_cc[j];
+
+   s8 (*queue_priority_mapping)[2];
+   s8 (*queue_tc_mapping)[2];
+
+   queue_tc_mapping = cc-info-queue_tc_mapping;
+   queue_priority_mapping = cc-info-queue_priority_mapping;
+
+   /* Event queue to TC mapping */
+   for (i = 0; queue_tc_mapping[i][0] != -1; i++)
+   map_queue_tc(j, queue_tc_mapping[i][0],
+   queue_tc_mapping[i][1]);
+
+   /* Event queue priority mapping */
+   for (i = 0; queue_priority_mapping[i][0] != -1; i++)
+   assign_priority_to_queue(j,
+   queue_priority_mapping[i][0],
+   queue_priority_mapping[i][1]);
+
+   /* Map the channel to param entry if channel mapping logic
+* exist
+*/
+   if (edma_read(j, EDMA_CCCFG)  CHMAP_EXIST)
+   map_dmach_param(j);
+
+   for (i = 0; i  cc-num_channels; i++) {
+   if (test_bit(i, cc-edma_inuse)) {
+   /* ensure access through shadow region 0 */
+   edma_or_array2(j, EDMA_DRAE, 0, i  5,
+   BIT(i  0x1f));
+
+   setup_dma_interrupt(i,
+   cc-intr_data[i].callback,
+   cc-intr_data[i].data

Re: [PATCH v5] ARM: omap: edma: add suspend suspend/resume hooks

2013-11-08 Thread Daniel Mack
On 11/08/2013 01:02 AM, Kevin Hilman wrote:
 Daniel Mack zon...@gmail.com writes:

 +.resume_noirq   = edma_pm_resume,
 +};
 
 Also, I believe it was already suggested by Nishanth, but the late/early
 callbacks are probably more appropriate here than the noirq callbacks.
 Unless there's a *really* good reason to use the noirq callbacks, they
 should be avoided.

Ok, no problem to change that. Regarding the function ordering,
late/early didn't show any lockup in my tests yet.

 That being said, I wonder if the whole approach here is the right one.
 I know you're basing your stuff on some TI tree, but that doesn't make
 it the right way (usually, it's the opposite, but I digress...)  ;)

:)

Well, I was primarily looking for a solution to bring the edma back to
life after suspend. As I wrote in the first version of this patch that I
sent, I didn't even intent that patch to go mainline at all, given that
arch/arm/common/edma.c woill go away soon.

 IMO, EDMA should be done like we currently do I2C and not implement
 suspend/resume at all.  Instead, the driver should do runtime PM done on
 a per xfer basis.  Then when suspend comes along, all that needs to be
 done is ensure all in-flight xfers are done, then runtime PM will kick
 in.

I see your point in general, but isn't runtime PM there to actually save
power at runtime? Does disabling unused channels in the EDMA really
reduce the consumption of that IP block?


Daniel

--
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 v4] ARM: omap: edma: add suspend suspend/resume hooks

2013-11-07 Thread Daniel Mack
On 11/07/2013 02:30 PM, Gururaja Hebbar wrote:
 On Wednesday 06 November 2013 11:06 PM, Joel Fernandes wrote:
 Hi Vaibhav,

 On 10/31/2013 05:25 PM, Vaibhav Bedia wrote:
 Hi Daniel,

 On Wed, Oct 30, 2013 at 4:21 PM, Daniel Mack zon...@gmail.com wrote:
 [...]
 +
 +static SIMPLE_DEV_PM_OPS(edma_pm_ops, edma_pm_suspend, edma_pm_resume);
 +
  static struct platform_driver edma_driver = {
 .driver = {
 .name   = edma,
 +   .pm = edma_pm_ops,
 .of_match_table = edma_of_ids,
 },

 A while back we discovered a nasty race condition here that had us move the 
 EDMA
 PM callbacks to the noirq phase. IIRC the MMC driver was resuming
 before the EDMA
 driver had a chance to run and that was leading to a deadlock. I am
 not sure how to force
 this scenario but i do remember spending time debugging this on a
 random codebase.
 Maybe some else has some better ideas on how to force this race condition...

 I think you're talking about the patch at [1] which is not upstream. A quick
 question with my limited knowledge of suspend/resume- How can there be 
 pending
 I/O operations between suspend/resume cycles? 
 
 AFAIK, MMC framework started talking to cards immediately after resume.
 Due to race condition, EDMA resume callback had not yet completed and
 HSMMC driver had initiated a DMA operation. This resulted in Deadlock.

Hmm. At least in my case, that doesn't happen. And my debug logs also
show that the calls are in expected order. Which tree were you on when
you saw this?


Thanks,
Daniel

--
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 v4] ARM: omap: edma: add suspend suspend/resume hooks

2013-11-07 Thread Daniel Mack
On 11/07/2013 04:18 PM, Nishanth Menon wrote:
 Tested this on a vendor V3.12 tag based kernel:
 
 Test patch: http://pastebin.com/AmnktQ7B
 test: echo -n 1/sys/power/pm_print_times; rtcwake -d /dev/rtc0 -m
 mem -s 5
 
 
 with the current patch: http://pastebin.com/RujarRLV
 suspend_late and resume_early: http://pastebin.com/RujarRLV

These two are identical.

 suspend_noirq and resume_noirq: http://pastebin.com/nKfbm7Mj

And I can't see any difference between this one and the first one,
except for slightly different timings. Am I missing anything?

 one needs to be careful of the sequence - donot forget that
 omap_device also does stuff in the background to every SoC device in
 noirq - sequence is paramount. you would want to ensure edma is saving
 after every single dependent device is done with it's stuff and
 guarenteed to never request any further transaction, and resume is
 done before any of the dependent devices need edma. but edma is also a
 peripheral that omap_device and generic runtime pm framework deals
 with - so ensure sequences consider that as well.

So, what would you say which sequence is correct then? :)


Thanks,
Daniel



--
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 v4] ARM: omap: edma: add suspend suspend/resume hooks

2013-11-07 Thread Daniel Mack
Hi Joel,

On 11/07/2013 05:34 PM, Joel Fernandes wrote:
 Thanks for your followup patch on this. It looks much better now using 
 existing
 functions to save/restore the state.

Yes, thanks for the suggesting it in the first place.

 On 10/30/2013 03:21 PM, Daniel Mack wrote:
 diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
 [..]
 +static int edma_pm_resume(struct device *dev)
 +{
 +int i, j;
 +
 +pm_runtime_get_sync(dev);
 +
 +for (j = 0; j  arch_num_cc; j++) {
 +struct edma *cc = edma_cc[j];
 +
 +s8 (*queue_priority_mapping)[2];
 +s8 (*queue_tc_mapping)[2];
 +
 +queue_tc_mapping = cc-info-queue_tc_mapping;
 +queue_priority_mapping = cc-info-queue_priority_mapping;
 +
 +/* Event queue to TC mapping */
 +for (i = 0; queue_tc_mapping[i][0] != -1; i++)
 +map_queue_tc(j, queue_tc_mapping[i][0],
 +queue_tc_mapping[i][1]);
 +
 +/* Event queue priority mapping */
 +for (i = 0; queue_priority_mapping[i][0] != -1; i++)
 +assign_priority_to_queue(j,
 +queue_priority_mapping[i][0],
 +queue_priority_mapping[i][1]);
 
 I know ti,edma-regions property is not currently being used, but we should
 future proof this by setting up DRAE for like done in probe:
 
 for (i = 0; i  info[j]-n_region; i++) {
 edma_write_array2(j, EDMA_DRAE, i, 0, 0x0);
 edma_write_array2(j, EDMA_DRAE, i, 1, 0x0);
 edma_write_array(j, EDMA_QRAE, i, 0x0);
 }

That doesn't work for me. I'm running long-time tests here on a device
which has a mwifiex connected to omap_hsmmc. The test procedure includes:

a) a script on the device that puts the device to sleep some seconds
after it has been woken up

b) a script on a host that wakes up the device with wake-on-lan every 10
seconds

c) a flood ping that checks whether the device is responding


That precedure is running since a couple of hourse here, and it works
well with both by v3 and v4 patches. Moving the functions to
.suspend/resume _noirq doesn't seem to break anything.

Setting QRAE to 0 as you mentioned above, however, makes the device fail
at resume.

 +static SIMPLE_DEV_PM_OPS(edma_pm_ops, edma_pm_suspend, edma_pm_resume);
 
 I agree with Nishanth here, it is better to do this in .suspend/resume _noirq
 stage to rule out any ordering bugs that may show up in the future, since such
 an issue already showed up in earlier testing.

Alright, I already did that.

 I would appreciate it if you can make these 2 changes and post a v5. Thanks 
 for
 a lot for all the hardwork.

No problem at all :)

 Acked-by: Joel Fernandes jo...@ti.com

Still sure about that? What about your follow-up to your own reply?


Many thanks for all the feedback!

Daniel




--
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 v5] ARM: omap: edma: add suspend suspend/resume hooks

2013-11-07 Thread Daniel Mack
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams and omap_hsmmc.

All information can be reconstructed by already known runtime
information.

As we now use some functions that were previously only used from __init
context, annotations had to be dropped.

Signed-off-by: Daniel Mack zon...@gmail.com
---
Ok, here is v5.

v4 - v5:

* dropped pm_runtime_* function calls entirely
* moved the function pointers to .suspend/resume _noirq

Again, thanks for the reviews. I'm still uncertain which function order
is most appropriate though.


Thanks,
Daniel



 arch/arm/common/edma.c | 78 --
 1 file changed, 75 insertions(+), 3 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 8e1a024..7deacde 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -239,6 +239,8 @@ struct edma {
/* list of channels with no even trigger; terminated by -1 */
const s8*noevent;
 
+   struct edma_soc_info *info;
+
/* The edma_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
 */
@@ -290,13 +292,13 @@ static void map_dmach_queue(unsigned ctlr, unsigned ch_no,
~(0x7  bit), queue_no  bit);
 }
 
-static void __init map_queue_tc(unsigned ctlr, int queue_no, int tc_no)
+static void map_queue_tc(unsigned ctlr, int queue_no, int tc_no)
 {
int bit = queue_no * 4;
edma_modify(ctlr, EDMA_QUETCMAP, ~(0x7  bit), ((tc_no  0x7)  bit));
 }
 
-static void __init assign_priority_to_queue(unsigned ctlr, int queue_no,
+static void assign_priority_to_queue(unsigned ctlr, int queue_no,
int priority)
 {
int bit = queue_no * 4;
@@ -315,7 +317,7 @@ static void __init assign_priority_to_queue(unsigned ctlr, 
int queue_no,
  * included in that particular EDMA variant (Eg : dm646x)
  *
  */
-static void __init map_dmach_param(unsigned ctlr)
+static void map_dmach_param(unsigned ctlr)
 {
int i;
for (i = 0; i  EDMA_MAX_DMACH; i++)
@@ -1785,15 +1787,85 @@ static int edma_probe(struct platform_device *pdev)
edma_write_array2(j, EDMA_DRAE, i, 1, 0x0);
edma_write_array(j, EDMA_QRAE, i, 0x0);
}
+   edma_cc[j]-info = info[j];
arch_num_cc++;
}
 
return 0;
 }
 
+static int edma_pm_suspend(struct device *dev)
+{
+   int j;
+
+   for (j = 0; j  arch_num_cc; j++) {
+   struct edma *ecc = edma_cc[j];
+
+   disable_irq(ecc-irq_res_start);
+   disable_irq(ecc-irq_res_end);
+   }
+
+   return 0;
+}
+
+static int edma_pm_resume(struct device *dev)
+{
+   int i, j;
+
+   for (j = 0; j  arch_num_cc; j++) {
+   struct edma *cc = edma_cc[j];
+
+   s8 (*queue_priority_mapping)[2];
+   s8 (*queue_tc_mapping)[2];
+
+   queue_tc_mapping = cc-info-queue_tc_mapping;
+   queue_priority_mapping = cc-info-queue_priority_mapping;
+
+   /* Event queue to TC mapping */
+   for (i = 0; queue_tc_mapping[i][0] != -1; i++)
+   map_queue_tc(j, queue_tc_mapping[i][0],
+   queue_tc_mapping[i][1]);
+
+   /* Event queue priority mapping */
+   for (i = 0; queue_priority_mapping[i][0] != -1; i++)
+   assign_priority_to_queue(j,
+   queue_priority_mapping[i][0],
+   queue_priority_mapping[i][1]);
+
+   /* Map the channel to param entry if channel mapping logic
+* exist
+*/
+   if (edma_read(j, EDMA_CCCFG)  CHMAP_EXIST)
+   map_dmach_param(j);
+
+   for (i = 0; i  cc-num_channels; i++) {
+   if (test_bit(i, cc-edma_inuse)) {
+   /* ensure access through shadow region 0 */
+   edma_or_array2(j, EDMA_DRAE, 0, i  5,
+   BIT(i  0x1f));
+
+   setup_dma_interrupt(i,
+   cc-intr_data[i].callback,
+   cc-intr_data[i].data);
+   }
+   }
+
+   enable_irq(cc-irq_res_start);
+   enable_irq(cc-irq_res_end);
+   }
+
+   return 0;
+}
+
+static const struct dev_pm_ops edma_pm_ops = {
+   .suspend= edma_pm_suspend,
+   .resume_noirq   = edma_pm_resume,
+};
+
 static struct platform_driver edma_driver = {
.driver = {
.name   = edma,
+   .pm = edma_pm_ops,
.of_match_table

Re: [PATCH v4] ARM: omap: edma: add suspend suspend/resume hooks

2013-11-07 Thread Daniel Mack
On 11/08/2013 05:07 AM, Gururaja Hebbar wrote:
 On Thursday 07 November 2013 11:07 PM, Daniel Mack wrote:

 I'm running long-time tests here on a device
 which has a mwifiex connected to omap_hsmmc. The test procedure includes:

 a) a script on the device that puts the device to sleep some seconds
 after it has been woken up
 
 b) a script on a host that wakes up the device with wake-on-lan every 10
 seconds

 c) a flood ping that checks whether the device is responding
 
 can you share above 2 (b  C) test scripts? (pastebin or inline if small)

Of course. It's very hand-baked and simple:

a)

# wpa_supplicant is started and and the ip address ist set

while [ true ]; do
ethtool -s eth0 wol g
echo mem /sys/power/state
ethtool -s eth0 wol d
sleep 7
done

b)

while [ true ]; do
sudo etherwake -i em1 BC:6A:29:84:0A:62
sleep 5
done

c)

ping -s 32768 -i 0.1 192.168.178.222



Daniel

--
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 v4] ARM: omap: edma: add suspend suspend/resume hooks

2013-10-30 Thread Daniel Mack
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams and omap_hsmmc.

All information can be reconstructed by already known runtime
information.

As we now use some functions that were previously only used from __init
context, annotations had to be dropped.

Signed-off-by: Daniel Mack zon...@gmail.com
---
There was actually only a v3 ever, I made a mistake when formating the
first version of this patch. To prevent confusion though, I named this
one v4.

v3 - v4:
* dropped extra allocations, and reconstruct register values
  from already known driver states.



Hi Joel, Gururaja, Balaji,

thanks a lot for your feedback. I successfully tested this version with
davinci mcasp as well as omap_hsmmc. I'd appreciate another round of
reviews :)


Thanks,
Daniel

 arch/arm/common/edma.c | 82 --
 1 file changed, 79 insertions(+), 3 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 8e1a024..f15cdb9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -239,6 +239,8 @@ struct edma {
/* list of channels with no even trigger; terminated by -1 */
const s8*noevent;
 
+   struct edma_soc_info *info;
+
/* The edma_inuse bit for each PaRAM slot is clear unless the
 * channel is in use ... by ARM or DSP, for QDMA, or whatever.
 */
@@ -290,13 +292,13 @@ static void map_dmach_queue(unsigned ctlr, unsigned ch_no,
~(0x7  bit), queue_no  bit);
 }
 
-static void __init map_queue_tc(unsigned ctlr, int queue_no, int tc_no)
+static void map_queue_tc(unsigned ctlr, int queue_no, int tc_no)
 {
int bit = queue_no * 4;
edma_modify(ctlr, EDMA_QUETCMAP, ~(0x7  bit), ((tc_no  0x7)  bit));
 }
 
-static void __init assign_priority_to_queue(unsigned ctlr, int queue_no,
+static void assign_priority_to_queue(unsigned ctlr, int queue_no,
int priority)
 {
int bit = queue_no * 4;
@@ -315,7 +317,7 @@ static void __init assign_priority_to_queue(unsigned ctlr, 
int queue_no,
  * included in that particular EDMA variant (Eg : dm646x)
  *
  */
-static void __init map_dmach_param(unsigned ctlr)
+static void map_dmach_param(unsigned ctlr)
 {
int i;
for (i = 0; i  EDMA_MAX_DMACH; i++)
@@ -1785,15 +1787,89 @@ static int edma_probe(struct platform_device *pdev)
edma_write_array2(j, EDMA_DRAE, i, 1, 0x0);
edma_write_array(j, EDMA_QRAE, i, 0x0);
}
+   edma_cc[j]-info = info[j];
arch_num_cc++;
}
 
return 0;
 }
 
+static int edma_pm_suspend(struct device *dev)
+{
+   int j;
+
+   pm_runtime_get_sync(dev);
+
+   for (j = 0; j  arch_num_cc; j++) {
+   struct edma *ecc = edma_cc[j];
+
+   disable_irq(ecc-irq_res_start);
+   disable_irq(ecc-irq_res_end);
+   }
+
+   pm_runtime_put_sync(dev);
+
+   return 0;
+}
+
+static int edma_pm_resume(struct device *dev)
+{
+   int i, j;
+
+   pm_runtime_get_sync(dev);
+
+   for (j = 0; j  arch_num_cc; j++) {
+   struct edma *cc = edma_cc[j];
+
+   s8 (*queue_priority_mapping)[2];
+   s8 (*queue_tc_mapping)[2];
+
+   queue_tc_mapping = cc-info-queue_tc_mapping;
+   queue_priority_mapping = cc-info-queue_priority_mapping;
+
+   /* Event queue to TC mapping */
+   for (i = 0; queue_tc_mapping[i][0] != -1; i++)
+   map_queue_tc(j, queue_tc_mapping[i][0],
+   queue_tc_mapping[i][1]);
+
+   /* Event queue priority mapping */
+   for (i = 0; queue_priority_mapping[i][0] != -1; i++)
+   assign_priority_to_queue(j,
+   queue_priority_mapping[i][0],
+   queue_priority_mapping[i][1]);
+
+   /* Map the channel to param entry if channel mapping logic
+* exist
+*/
+   if (edma_read(j, EDMA_CCCFG)  CHMAP_EXIST)
+   map_dmach_param(j);
+
+   for (i = 0; i  cc-num_channels; i++)
+   if (test_bit(i, cc-edma_inuse)) {
+   /* ensure access through shadow region 0 */
+   edma_or_array2(j, EDMA_DRAE, 0, i  5,
+   BIT(i  0x1f));
+
+   setup_dma_interrupt(i,
+   cc-intr_data[i].callback,
+   cc-intr_data[i].data);
+   }
+
+   enable_irq(cc-irq_res_start);
+   enable_irq(cc-irq_res_end);
+   }
+
+   pm_runtime_put_sync(dev

Re: [PATCH v3 0/5] usb: musb_dsps: support for suspend and resume

2013-10-28 Thread Daniel Mack
On 10/18/2013 11:59 AM, Sebastian Andrzej Siewior wrote:
 On 10/18/2013 11:39 AM, Daniel Mack wrote:
 v3 of my musb_dsps suspend patches.

 With these patches applied, I can successfully bring an AM335x board
 to suspend with a USB media connected, and access it again after
 resume.

 This works for both PIO mode and CPPI41 enabled configurations,
 together with Sebasitian's and my cppi41 patches recently posted.

 Felipe, this work was rebased and now applies cleanly on top of
 your current 'next' branch. IOW, on top of usb: musb: cppi41: allow
 to defer probing if DMA isn't yet available.
 
 Sounds good.

Felipe, do you think that series is good to be taken for 3.13?


Thanks,
Daniel

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


[PATCH v3 0/5] usb: musb_dsps: support for suspend and resume

2013-10-18 Thread Daniel Mack
v3 of my musb_dsps suspend patches.

With these patches applied, I can successfully bring an AM335x board
to suspend with a USB media connected, and access it again after
resume.

This works for both PIO mode and CPPI41 enabled configurations,
together with Sebasitian's and my cppi41 patches recently posted.

Felipe, this work was rebased and now applies cleanly on top of
your current 'next' branch. IOW, on top of usb: musb: cppi41: allow
to defer probing if DMA isn't yet available.


Thanks,
Daniel

v2 - v3
* dropped usb: musb: move port reset to worker which is
  not crucial for this series.
* added another cosmetic cleanup patch (#5)

Daniel Mack (5):
  usb: musb: call musb_port_suspend from musb_bus_suspend
  usb: musb: conditionally save and restore the context on suspend
  usb: musb: dsps: add {tx,rx}_mode to wrapper
  usb: musb: dsps: add support for suspend and resume
  usb: musb: dsps: indentation and whitespace fixes

 drivers/usb/musb/musb_core.c| 17 +++-
 drivers/usb/musb/musb_core.h|  1 +
 drivers/usb/musb/musb_dsps.c| 86 +++--
 drivers/usb/musb/musb_host.c|  2 +
 drivers/usb/musb/musb_host.h|  4 ++
 drivers/usb/musb/musb_virthub.c |  4 +-
 include/linux/usb/musb.h|  1 +
 7 files changed, 100 insertions(+), 15 deletions(-)

-- 
1.8.3.1

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


[PATCH v3 1/5] usb: musb: call musb_port_suspend from musb_bus_suspend

2013-10-18 Thread Daniel Mack
Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_host.c| 2 ++
 drivers/usb/musb/musb_host.h| 2 ++
 drivers/usb/musb/musb_virthub.c | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 9a2b8c8..2b60596 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8  devctl;
 
+   musb_port_suspend(musb, true);
+
if (!is_host_active(musb))
return 0;
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 960d735..e660af9 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -92,6 +92,7 @@ extern void musb_host_rx(struct musb *, u8);
 extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
+extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -121,6 +122,7 @@ static inline void musb_root_disconnect(struct musb *musb)  
{}
 static inline void musb_host_resume_root_hub(struct musb *musb){}
 static inline void musb_host_poll_rh_status(struct musb *musb) {}
 static inline void musb_host_poke_root_hub(struct musb *musb)  {}
+static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
 #endif
 
 struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 9af6bba..e977441 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -44,7 +44,7 @@
 
 #include musb_core.h
 
-static void musb_port_suspend(struct musb *musb, bool do_suspend)
+void musb_port_suspend(struct musb *musb, bool do_suspend)
 {
struct usb_otg  *otg = musb-xceiv-otg;
u8  power;
-- 
1.8.3.1

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


[PATCH v3 2/5] usb: musb: conditionally save and restore the context on suspend

2013-10-18 Thread Daniel Mack
It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.

The dsps platform does, however. So add a bit in struct
musb_hdrc_platform_data to let platforms specify their need of such
action being taken.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.c | 17 -
 include/linux/usb/musb.h |  1 +
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index e5ad77d..fea6ecd 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2200,6 +2200,7 @@ static int musb_suspend(struct device *dev)
 {
struct musb *musb = dev_to_musb(dev);
unsigned long   flags;
+   struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
 
spin_lock_irqsave(musb-lock, flags);
 
@@ -2213,16 +2214,30 @@ static int musb_suspend(struct device *dev)
 */
}
 
+   if (plat-restore_after_suspend)
+   musb_save_context(musb);
+
spin_unlock_irqrestore(musb-lock, flags);
return 0;
 }
 
 static int musb_resume_noirq(struct device *dev)
 {
-   /* for static cmos like DaVinci, register values were preserved
+   struct musb *musb = dev_to_musb(dev);
+   struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
+
+   /*
+* For static cmos like DaVinci, register values were preserved
 * unless for some reason the whole soc powered down or the USB
 * module got reset through the PSC (vs just being disabled).
+*
+* The plaform data tells us about the necessity of saving and
+* restoring the context across a suspend cycle.
 */
+
+   if (plat-restore_after_suspend)
+   musb_restore_context(musb);
+
return 0;
 }
 
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..296be6c 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -100,6 +100,7 @@ struct musb_hdrc_platform_data {
u8  mode;
 
u8  has_mailbox:1;
+   u8  restore_after_suspend:1;
 
/* for clk_get() */
const char  *clock;
-- 
1.8.3.1

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


[PATCH v3 4/5] usb: musb: dsps: add support for suspend and resume

2013-10-18 Thread Daniel Mack
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.

We also have to call musb_port_reset() for this platform upon resume, so
this function has to be made non-static.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.h|  1 +
 drivers/usb/musb/musb_dsps.c| 59 +
 drivers/usb/musb/musb_host.h|  2 ++
 drivers/usb/musb/musb_virthub.c |  2 +-
 4 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 1c5bf75..ebb9058 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -294,6 +294,7 @@ struct musb {
 
irqreturn_t (*isr)(int, void *);
struct work_struct  irq_work;
+
u16 hwvers;
 
u16 intrrxe;
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index da21a4e..ce5bbc6 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
u8  poll_seconds;
 };
 
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+   u32 control;
+   u32 epintr;
+   u32 coreintr;
+   u32 phy_utmi;
+   u32 mode;
+   u32 tx_mode;
+   u32 rx_mode;
+};
+
 /**
  * DSPS glue structure.
  */
@@ -121,6 +134,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+   struct dsps_context context;
 };
 
 static void dsps_musb_try_idle(struct musb *musb, unsigned long timeout)
@@ -506,6 +521,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
}
pdata.config = config;
pdata.platform_ops = dsps_ops;
+   pdata.restore_after_suspend = 1;
 
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
@@ -632,11 +648,54 @@ static const struct of_device_id musb_dsps_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
 
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   glue-context.control = dsps_readl(mbase, wrp-control);
+   glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+   glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+   glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+   glue-context.mode = dsps_readl(mbase, wrp-mode);
+   glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
+   glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
+
+   return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   dsps_writel(mbase, wrp-control, glue-context.control);
+   dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+   dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+   dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+   dsps_writel(mbase, wrp-mode, glue-context.mode);
+   dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+   dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+   musb_port_reset(musb, false);
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
.remove = dsps_remove,
.driver = {
.name   = musb-dsps,
+   .pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
 };
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index e660af9..7436c24 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
 extern void musb_port_suspend(struct musb *musb, bool do_suspend);
+extern void musb_port_reset(struct musb *musb, bool do_reset);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -123,6 +124,7 @@ static inline void musb_host_resume_root_hub(struct musb 
*musb) {}
 static inline void musb_host_poll_rh_status(struct

[PATCH v3 3/5] usb: musb: dsps: add {tx,rx}_mode to wrapper

2013-10-18 Thread Daniel Mack
rx_mode and tx_mode need to be read at suspend time and restored on
resume for dsps platforms. So add it to the wrapper struct first, and
initialize the values.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 3cda7ad..da21a4e 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -83,6 +83,8 @@ struct dsps_musb_wrapper {
u16 coreintr_status;
u16 phy_utmi;
u16 mode;
+   u16 tx_mode;
+   u16 rx_mode;
 
/* bit positions for control */
unsignedreset:5;
@@ -605,6 +607,8 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
.coreintr_status= 0x34,
.phy_utmi   = 0xe0,
.mode   = 0xe8,
+   .tx_mode= 0x70,
+   .rx_mode= 0x74,
.reset  = 0,
.otg_disable= 21,
.iddig  = 8,
-- 
1.8.3.1

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


[PATCH v3 5/5] usb: musb: dsps: indentation and whitespace fixes

2013-10-18 Thread Daniel Mack
Just a cosmetic thing, no functional change.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index ce5bbc6..0fa3468 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -131,9 +131,9 @@ struct dsps_context {
 struct dsps_glue {
struct device *dev;
struct platform_device *musb;   /* child musb pdev */
-   const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
+   const struct dsps_musb_wrapper *wrp;/* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
-   unsigned long last_timer;/* last timer data for each instance */
+   unsigned long last_timer;   /* last timer data for each instance */
 
struct dsps_context context;
 };
@@ -213,7 +213,7 @@ static void dsps_musb_disable(struct musb *musb)
 
dsps_writel(reg_base, wrp-coreintr_clear, wrp-usb_bitmap);
dsps_writel(reg_base, wrp-epintr_clear,
-wrp-txep_bitmap | wrp-rxep_bitmap);
+   wrp-txep_bitmap | wrp-rxep_bitmap);
dsps_writeb(musb-mregs, MUSB_DEVCTL, 0);
 }
 
@@ -234,7 +234,7 @@ static void otg_timer(unsigned long _musb)
 */
devctl = dsps_readb(mregs, MUSB_DEVCTL);
dev_dbg(musb-controller, Poll devctl %02x (%s)\n, devctl,
-   usb_otg_state_string(musb-xceiv-state));
+   usb_otg_state_string(musb-xceiv-state));
 
spin_lock_irqsave(musb-lock, flags);
switch (musb-xceiv-state) {
@@ -298,7 +298,7 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
dsps_writel(reg_base, wrp-coreintr_status, usbintr);
 
dev_dbg(musb-controller, usbintr (%x) epintr(%x)\n,
-   usbintr, epintr);
+   usbintr, epintr);
/*
 * DRVVBUS IRQs are the only proxy we have (a very poor one!) for
 * DSPS IP's missing ID change IRQ.  We need an ID change IRQ to
@@ -348,10 +348,9 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
 
/* NOTE: this must complete power-on within 100 ms. */
dev_dbg(musb-controller, VBUS %s (%s)%s, devctl %02x\n,
-   drvvbus ? on : off,
-   usb_otg_state_string(musb-xceiv-state),
-   err ?  ERROR : ,
-   devctl);
+   drvvbus ? on : off,
+   usb_otg_state_string(musb-xceiv-state),
+   err ?  ERROR : , devctl);
ret = IRQ_HANDLED;
}
 
@@ -692,9 +691,9 @@ static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, 
dsps_resume);
 
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
-   .remove = dsps_remove,
-   .driver = {
-   .name   = musb-dsps,
+   .remove = dsps_remove,
+   .driver = {
+   .name   = musb-dsps,
.pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
-- 
1.8.3.1

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


Re: [PATCH v3 4/5] usb: musb: dsps: add support for suspend and resume

2013-10-18 Thread Daniel Mack
On 10/18/2013 11:58 AM, Sebastian Andrzej Siewior wrote:
 On 10/18/2013 11:39 AM, Daniel Mack wrote:
 
 diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
 index da21a4e..ce5bbc6 100644
 --- a/drivers/usb/musb/musb_dsps.c
 +++ b/drivers/usb/musb/musb_dsps.c
 @@ -632,11 +648,54 @@ static const struct of_device_id musb_dsps_of_match[] 
 = {
  };
  MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
  
 +#ifdef CONFIG_PM
 +static int dsps_suspend(struct device *dev)
 +{
 +struct dsps_glue *glue = dev_get_drvdata(dev);
 +const struct dsps_musb_wrapper *wrp = glue-wrp;
 +struct musb *musb = platform_get_drvdata(glue-musb);
 +void __iomem *mbase = musb-ctrl_base;
 +
 +glue-context.control = dsps_readl(mbase, wrp-control);
 +glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
 +glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
 +glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
 +glue-context.mode = dsps_readl(mbase, wrp-mode);
 +glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
 +glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
 
 Looking at this made me wonder, what about
 
drivers/usb/phy/phy-am335x-control.c
 
 Since it seems to work for you, maybe we don't need this after all :P

Yes, I thought that needs fixing as well, but at least on my system, it
doesn't. So I skipped that for now.


Daniel

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


Re: [PATCH v3 0/5] usb: musb_dsps: support for suspend and resume

2013-10-18 Thread Daniel Mack
On 10/18/2013 11:59 AM, Sebastian Andrzej Siewior wrote:
 On 10/18/2013 11:39 AM, Daniel Mack wrote:
 v3 of my musb_dsps suspend patches.

 With these patches applied, I can successfully bring an AM335x board
 to suspend with a USB media connected, and access it again after
 resume.

 This works for both PIO mode and CPPI41 enabled configurations,
 together with Sebasitian's and my cppi41 patches recently posted.

 Felipe, this work was rebased and now applies cleanly on top of
 your current 'next' branch. IOW, on top of usb: musb: cppi41: allow
 to defer probing if DMA isn't yet available.
 
 Sounds good. What happend to the patch series where you used a
 workqueue do defer some sleeping code that caused sleeping while
 atomic warnings?

As mentioned, that doesn't hit me anymore with the current patch stack.

That doesn't mean we should ignore that issue, of course, we're still
sleeping while atomic. But I removed the patch from the series for now,
so we can address that separately.


Thanks,
Daniel

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


Re: [PATCH v3] ARM: omap: edma: add suspend suspend/resume hooks

2013-10-18 Thread Daniel Mack
On 10/09/2013 10:14 PM, Joel Fernandes wrote:
 On 10/09/2013 09:12 AM, Joel Fernandes wrote:
 On 10/09/2013 02:38 AM, Daniel Mack wrote:
 [..]
 (And the 'v3' in the subject is really my bad, sorry - I only sent one
 version of this patch ever).

 I can respin the patch on top of the proper driver once all the edma
 bits have eventually been moved to drivers/dma. Is anyone continuing
 Matt Porter's work on this?

 The work is waiting on conversion of the davinci-pcm ASoC driver to DMA 
 Engine,
 which once done can make exposing the private EDMA API in 
 arch/arm/common/edma.c
 obsolete and we can take it to drivers/dma. Some more work to be done in 
 edma in
 unifying the probe etc.
 
 Forgot to mention, since ASoC DMAengine conversion is not going to happen any
 time soon considering the amount of work involved, I suggest you respin this
 patch on the common/edma code itself. That way we can keep suspend/resume
 working on these platforms that use EDMA till the actual conversion takes 
 place.

Ok, I also figured that the current patch does not really suffice. There
seems to be an issue with omap_hsmmc DMA channels being disfunct after
resume, so I'll respin it.

 I suggest though to recreate the state based on existing datastructures 
 instead
 of allocating/saving additional memory.
 
 Hope you're also in agreement with my comments on your original patch on what
 needs to / need not be saved.

I'm still not sure whether the parameters block has to be preserved
manually. Let see what we're left with eventually :)


Thanks,
Daniel

--
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/3] dma: cppi41: more suspend/resume patches

2013-10-09 Thread Daniel Mack
On 09.10.2013 08:41, Sebastian Andrzej Siewior wrote:
 * Daniel Mack | 2013-10-01 15:31:08 [+0200]:
 
 Patch #1 restores more registers on resume time.

 Patch #2 is a cosmetic cleanup that emerged while digging through the
 driver and gaining a basic idea of how it's implemented. Nothing fancy.
 
 I'm fine with those two.
 

 Patch #3, however, gives me headaches. I can't fully explain what's
 going on, but I can tell for sure that if fixes a problem that I stared
 on for many hours.
 
 I'm still trying to verify if it breaks something or not. So I haven't
 forgotten about this.

Ok, thank you very much for the update :) I can of course test
alternative patches if you have any.

Could you actually reproduce the issue I described by sending your board
to suspend?


Daniel
--
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/3] dma: cppi41: more suspend/resume patches

2013-10-09 Thread Daniel Mack
On 09.10.2013 09:28, Sebastian Andrzej Siewior wrote:
 On 10/09/2013 09:23 AM, Daniel Mack wrote:
 Ok, thank you very much for the update :) I can of course test
 alternative patches if you have any.

 Could you actually reproduce the issue I described by sending your board
 to suspend?
 
 No, I don't have mem, just freeze.

Sounds like you need to update your cm3 firmware. I built mine from this
tree:

  git://arago-project.org/git/projects/am33x-cm3.git
  Branch next3
  AM335xPSP_04.06.00.08-141-g1628306

I can also send you my binary in PM if you want me to.

 I try to test if this is a
 regression compared to my earlier testing. If not then it looks good I
 would say.

Ok.


Thanks,
Daniel

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


Re: [PATCH v3] ARM: omap: edma: add suspend suspend/resume hooks

2013-10-09 Thread Daniel Mack
Hi everyone,

On 09.10.2013 08:18, Gururaja Hebbar wrote:
 On Wednesday 09 October 2013 11:33 AM, Fernandes, Joel wrote:
 Some temporary issues with my mua so forgive any artifacts in this
 email.
 
 On Oct 9, 2013, at 12:14 AM, Hebbar, Gururaja
 gururaja.heb...@ti.com wrote:
 
 On Wednesday 09 October 2013 09:58 AM, Joel Fernandes wrote:
 On 10/01/2013 10:04 AM, Daniel Mack wrote:

 AFAIK, Suspend/resume should be quick. Allocating and
 deallocating on every iterating would be useless and time
 consuming.
 
 Nobody said allocate and deallocate on every iteration. Allocate
 once during the first suspend call and then don't have to allocate
 on subsequent calls.
 
 I couldn't find any code which allocates parameters inside suspend. 

Me neighter :)

But on a general note, I wonder whether it's really worth discussing and
merging this patch. As I wrote in the cover letter, it's just a quick
and dirty solution that I copied from a very old BSP tree, and I know
that the file I'm patching here is going to be removed soon anyway.
Actually, the sooner the better.

(And the 'v3' in the subject is really my bad, sorry - I only sent one
version of this patch ever).

I can respin the patch on top of the proper driver once all the edma
bits have eventually been moved to drivers/dma. Is anyone continuing
Matt Porter's work on this?


Thanks,
Daniel
--
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/4] usb: musb: am35x: use SIMPLE_DEV_PM_OPS

2013-10-02 Thread Daniel Mack
On 30.09.2013 18:25, Felipe Balbi wrote:
On Fri, Sep 27, 2013 at 08:47:10PM +0200, Daniel Mack wrote:

 So are you happy with this v2?
  It's just a cosmetic cleanup after all ...
 I can't see v2 anywhere... The only version I have is the one with
 DEV_PM_OPS still in it.

Seen them this time?

  http://marc.info/?l=linux-usbm=138056774812520w=2
  http://marc.info/?l=linux-usbm=138056774612517w=2
  http://marc.info/?l=linux-usbm=138056775012522w=2

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


Re: [PATCH 3/3] dma: cppi41: move -EAGAIN in tear_down

2013-10-02 Thread Daniel Mack
Hi Sebastian,

On 02.10.2013 10:29, Sebastian Andrzej Siewior wrote:
 * Daniel Mack | 2013-10-01 15:31:11 [+0200]:

 diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
 index 7747bf7..6decf34 100644
 --- a/drivers/dma/cppi41.c
 +++ b/drivers/dma/cppi41.c
 @@ -586,6 +586,9 @@ static int cppi41_tear_down_chan(struct cppi41_channel 
 *c)
  }
  c-td_seen = 1;
  }
 +
 +if (c-td_retry)
 +return -EAGAIN;
 
 So you return right away since the retry counter should be  0 here. And
 then you want to get the TDDOWN bit set and retry. Hmmm.
 Let me answer to you 0/3 on this.

Thanks a lot for having a look! As I'm going to be off for a couple of
days now, and only be able to read my mails sporadically, maybe you can
also try the musb suspend functions on your hardware. I'll give you a
quick wrap-up of how my test setup looks like.

On an AM33xx board, I have a host-only (type A) connector with a USB
memory stick plugged in. The relevant config settings are:

CONFIG_USB_MUSB_HDRC=m
# CONFIG_USB_MUSB_HOST is not set
# CONFIG_USB_MUSB_GADGET is not set
CONFIG_USB_MUSB_DUAL_ROLE=y
# CONFIG_USB_MUSB_TUSB6010 is not set
# CONFIG_USB_MUSB_OMAP2PLUS is not set
# CONFIG_USB_MUSB_AM35X is not set
CONFIG_USB_MUSB_DSPS=m
# CONFIG_USB_MUSB_UX500 is not set
CONFIG_USB_MUSB_AM335X_CHILD=m
# CONFIG_MUSB_PIO_ONLY is not set
CONFIG_USB_TI_CPPI41_DMA=y
CONFIG_TI_CPPI41=y

Once the system is booted up and the USB media is detected, I send the
system to sleep mode with cat mem /sys/power/state. After wakeup, I
access the media by mounting and unmounting it once, then send the
system back to sleep.

Repeating the above cycle multiple times will sooner or later make the
warning kick in without the discussed patch. Sometimes it happened on
first try, sometimes it took me up to ~20 cycles to make it happen.

I'd be curious whether you see the same behavior on your board as well,
and whether the fix work for you, too.

For reference, I just pushed my current working tree here:

  https://github.com/zonque/linux/tree/am33xx-3.12


Thanks,
Daniel

--
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/3] dma: cppi41: more suspend/resume patches

2013-10-02 Thread Daniel Mack
On 02.10.2013 12:20, Sebastian Andrzej Siewior wrote:
 * Daniel Mack | 2013-10-01 15:31:08 [+0200]:
 
 Patch #3, however, gives me headaches. I can't fully explain what's
 going on, but I can tell for sure that if fixes a problem that I stared
 on for many hours.

 The problem is that on resume, the musb core will detect that some of
 the suspended USB devices' endpoints are stalled. Which is something
 that is unrelated to the dma driver, it just seems to be an expected
 condition. That, however, makes the musb core call
 cppi41_dma_channel_abort() - cppi41_tear_down_chan(), which is
 an otherwise untravelled code path. When that function is called for
 a channel which has all of td_queued, td_seen and td_desc_seen set
 to FALSE, I'm always getting a warning like this:

 [   17.105981] [ cut here ]
 [   17.110861] WARNING: CPU: 0 PID: 122 at drivers/dma/cppi41.c:644 
 cppi41_dma_control+0x378/0x3f8 [cppi41]()
 
 This is 
 WARN_ON(!cdd-chan_busy[desc_num]);
 
 at the end of cppi41_stop_chan() right?

No, as stated, the line numbers in the kernel message are somewhat off
due to added debugging code. What kicks in here is this one:

if (!c-td_desc_seen) {
desc_phys = cppi41_pop_desc(cdd, c-q_comp_num);
if (desc_phys) {
__iormb();
WARN_ON(c-desc_phys != desc_phys);
c-td_desc_seen = 1;
}
}

 So you get the warning because
 you tried to stop a channel which was not busy. But then you should not
 be called at all because cppi41_dma_channel_abort() shouldn't call dma
 driver on idle channels.

However, I see nothing that forbids you from calling
dmaengine_terminate_all() on idle channels. If that's not handled
properly by the cppi driver, I'd say it needs fixing.

 How does your suspend  resume thingy work? Is it completly shutdown
 i.e. powered off? According to you earlier patches I would assume so. In
 that case the request is not enqueued and there is nothing to be removed
 from the engine, right?

No, my debugging showed that the channel has actually been prepared and
submitted before. It's just being torn down shortly after that. That's
what makes be believe in a race condition here.

 With the change you somehow get an interrupt that cleans up that slot.

Timing, I presume.

 The whole thing has been tested by manipulating the USB storage driver
 to enqueue more / less data then required by the protocol leading to a
 stall followed by an abort of the transfer. Let me re-do your suspend
 with the patches you made so far to check what is going on and if the
 normal transfer cancel is still working.

Ok, that sounds good.


Thanks,
Daniel

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


Re: [PATCH v2 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

2013-10-02 Thread Daniel Mack
On 02.10.2013 12:49, Sebastian Andrzej Siewior wrote:
 * Daniel Mack | 2013-10-01 15:39:54 [+0200]:
 
 Make musb_port_suspend() externally available, and call it when to host
 goes into suspend. This allows the core to go into suspend while a
 device is connected.
 
 Sorry for asking this stupid question but what is usally happening when
 the host goes to suspend and a device is connected? I think it is
 disconnected  re-enumerated and resume and this not what you want,
 right?

It is usually put into USB suspend and the host preserves its state.
After resume, the usb storage driver, for example, will not register new
partitions but expect things to be as they were before. That is, your
previously mounted devices remain functional.

However, the enumeration process has to be done again, because when the
device looses power, it can't memorize its address.

 What happens if the device is unplugged while the host is suspended and
 not there on resume?

That condition is detected and a full teardown of the connected drivers
is conducted. Try what happens on your notebook when you do that.
Embedded systems should behave just the same.


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


Re: [PATCH v2 1/5] usb: musb: move port reset to worker

2013-10-02 Thread Daniel Mack
On 02.10.2013 12:46, Sebastian Andrzej Siewior wrote:
 * Daniel Mack | 2013-10-01 15:39:53 [+0200]:
 
 musb_port_reset() sleeps, so we can't call it from atomic context. It
 is, however, called from places inside musb_hub_control() while
 musb-lock is held, which leads to a scheduling while atomic warning.
 
 I guess you are hit by the msleep(1) here.

Yes.

 Fix this by moving the logic into a worker, and call it where the
 function was previously called directly.
 
 I *think* the better approach here would be to replace the msleep(1) by
 a busy loop. The thing is that you do now want to continue the operation
 and having the reset in progress. It should complete _right_ _now_ i.e.
 SET_PORT_FEATURE RESET is completed before the the next SET/GET request
 arrives and with a workqueue you can not guarantee this.

Hmm, ok. I'm just not sure what time periods we're really sleeping for
here. After all, we're blocking all interrupts from occuring while the
lock is held.

So my question is rather whether it's sensible at all to hold the lock
while waiting. We might change some of the execution pathes to mutexes
and waitqueues as well. Felipe?



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


Re: [PATCH 3/3] dma: cppi41: move -EAGAIN in tear_down

2013-10-02 Thread Daniel Mack
On 02.10.2013 12:25, Sebastian Andrzej Siewior wrote:
 On 10/02/2013 11:19 AM, Daniel Mack wrote:

 Once the system is booted up and the USB media is detected, I send the
 system to sleep mode with cat mem /sys/power/state. After wakeup, I
 access the media by mounting and unmounting it once, then send the
 system back to sleep.
 
 Okay. Going to sleep is probably easy, I need to figure out how to
 wakeup…

Unless you pass no_console_suspend in your cmdline, you can just wake up
the system via UART0. IOW, just press enter on the serial console.


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


Re: [PATCH v2 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

2013-10-02 Thread Daniel Mack
On 02.10.2013 14:01, Sebastian Andrzej Siewior wrote:
 On 10/02/2013 01:14 PM, Daniel Mack wrote:
 On 02.10.2013 12:49, Sebastian Andrzej Siewior wrote:

 What happens if the device is unplugged while the host is suspended and
 not there on resume?

 That condition is detected and a full teardown of the connected drivers
 is conducted. Try what happens on your notebook when you do that.
 Embedded systems should behave just the same.
 
 I had the feeling that the USB device gets disconnected and
 re-enumerated on resume.

Yes. The device looses its +5V power supply, so it has to be reset and
re-enumerated on resume of course. It's just that USB drivers know about
the state the device has to be put back into after resume, and don't
assume the device was disconnected and reconnected. The latter would
(for usb-storage) also cause paritions to be removed and added.

 But if you say that the ehci-hcd saves the
 state and keeps the device connected if it wasn't disconnected during
 suspend then there is no reason for musb to behave differently.

Which it doesn't with my patches applied. I can mount a USB volume, put
the system into suspend and access the contents after resume. Just the
way it should be :)


Daniel

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


Re: [PATCH v3 4/5] dma: cppi41: only allocate descriptor memory once

2013-10-01 Thread Daniel Mack
Hi Sebastian,

sorry for the long delay, I got distracted by other things.


On 26.09.2013 10:26, Sebastian Andrzej Siewior wrote:
 * Daniel Mack | 2013-09-22 16:50:03 [+0200]:
 
 cdd-cd and cdd-descs_phys are allocated DESCS_AREAS times from
 init_descs() and freed as often from purge_descs(). This leads to both
 memory leaks and double-frees.

 Fix this by pulling the calls to dma_{alloc,free}_coherent() out of the
 loops.

 While at it, remove the intermediate variable mem_decs (I guess it was
 only there to make the code comply to the 80-chars CodingSytle rule).

 Signed-off-by: Daniel Mack zon...@gmail.com
 
 Please don't merge the memory descriptors. The idea was initially to
 allocate multiple small descriptors instead one big. The descrriptor
 turned out to be enough so it looks like the way it looks.
 If you want to clean this up, please either remove the for loop and
 allocate only one memory area or please prepare for multiple descripors
 (I think two is the upper limit).

Well, I didn't merge the descriptors. Look again at my changes please.

A simplified version of the code as it stands is:

  for (i = 0; i  DESCS_AREAS; i++)
cdd-cd = dma_alloc_coherent(dev, ..., cdd-descs_phys, GFP_KERNEL);

  for (i = 0; i  DESCS_AREAS; i++)
dma_free_coherent(dev, mem_decs, cdd-cd, cdd-descs_phys);

So you're effectively allocating and freeing the same pointer
DESCS_AREAS times, which is certainly not what you wanted.

And this just doesn't hit you because DESCS_AREAS is always 1:

  BUILD_BUG_ON(DESCS_AREAS != 1);


So, after all, my patch doesn't really change any of the runtime
behaviour. Consider it a cosmetic cleanup if you wish :)


Thanks,
Daniel

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


[PATCH 1/3] dma: cppi41: restore more registers

2013-10-01 Thread Daniel Mack
With active users over suspend/resume cycles, it turns out that
more registers, in particular DMA_TDFDQ and RXHPCRA0, have to be
restored on resume.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/dma/cppi41.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 89decc9..9a298b1 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -141,6 +141,9 @@ struct cppi41_dd {
const struct chan_queues *queues_rx;
const struct chan_queues *queues_tx;
struct chan_queues td_queue;
+
+   /* context for suspend/resume */
+   unsigned int dma_tdfdq;
 };
 
 #define FIST_COMPLETION_QUEUE  93
@@ -1045,6 +1048,7 @@ static int cppi41_suspend(struct device *dev)
 {
struct cppi41_dd *cdd = dev_get_drvdata(dev);
 
+   cdd-dma_tdfdq = cppi_readl(cdd-ctrl_mem + DMA_TDFDQ);
cppi_writel(0, cdd-usbss_mem + USBSS_IRQ_CLEARR);
disable_sched(cdd);
 
@@ -1054,12 +1058,23 @@ static int cppi41_suspend(struct device *dev)
 static int cppi41_resume(struct device *dev)
 {
struct cppi41_dd *cdd = dev_get_drvdata(dev);
+   struct cppi41_channel *c;
int i;
 
for (i = 0; i  DESCS_AREAS; i++)
cppi_writel(cdd-descs_phys, cdd-qmgr_mem + QMGR_MEMBASE(i));
 
+   list_for_each_entry(c, cdd-ddev.channels, chan.device_node)
+   if (!c-is_tx)
+   cppi_writel(c-q_num, c-gcr_reg + RXHPCRA0);
+
init_sched(cdd);
+
+   cppi_writel(cdd-dma_tdfdq, cdd-ctrl_mem + DMA_TDFDQ);
+   cppi_writel(cdd-scratch_phys, cdd-qmgr_mem + QMGR_LRAM0_BASE);
+   cppi_writel(QMGR_SCRATCH_SIZE, cdd-qmgr_mem + QMGR_LRAM_SIZE);
+   cppi_writel(0, cdd-qmgr_mem + QMGR_LRAM1_BASE);
+
cppi_writel(USBSS_IRQ_PD_COMP, cdd-usbss_mem + USBSS_IRQ_ENABLER);
 
return 0;
-- 
1.8.3.1

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


[PATCH 2/3] dma: cppi41: use cppi41_pop_desc() where possible

2013-10-01 Thread Daniel Mack
Use cppi41_pop_desc() when appropriate instead of open-coding the same
functionality again. That makes the code more readable. The function has
to be moved some lines up for this change.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/dma/cppi41.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 9a298b1..7747bf7 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -266,6 +266,15 @@ static u32 pd_trans_len(u32 val)
return val  ((1  (DESC_LENGTH_BITS_NUM + 1)) - 1);
 }
 
+static u32 cppi41_pop_desc(struct cppi41_dd *cdd, unsigned queue_num)
+{
+   u32 desc;
+
+   desc = cppi_readl(cdd-qmgr_mem + QMGR_QUEUE_D(queue_num));
+   desc = ~0x1f;
+   return desc;
+}
+
 static irqreturn_t cppi41_irq(int irq, void *data)
 {
struct cppi41_dd *cdd = data;
@@ -303,8 +312,7 @@ static irqreturn_t cppi41_irq(int irq, void *data)
q_num = __fls(val);
val = ~(1  q_num);
q_num += 32 * i;
-   desc = cppi_readl(cdd-qmgr_mem + QMGR_QUEUE_D(q_num));
-   desc = ~0x1f;
+   desc = cppi41_pop_desc(cdd, q_num);
c = desc_to_chan(cdd, desc);
if (WARN_ON(!c)) {
pr_err(%s() q %d desc %08x\n, __func__,
@@ -520,15 +528,6 @@ static void cppi41_compute_td_desc(struct cppi41_desc *d)
d-pd0 = DESC_TYPE_TEARD  DESC_TYPE;
 }
 
-static u32 cppi41_pop_desc(struct cppi41_dd *cdd, unsigned queue_num)
-{
-   u32 desc;
-
-   desc = cppi_readl(cdd-qmgr_mem + QMGR_QUEUE_D(queue_num));
-   desc = ~0x1f;
-   return desc;
-}
-
 static int cppi41_tear_down_chan(struct cppi41_channel *c)
 {
struct cppi41_dd *cdd = c-cdd;
@@ -612,7 +611,7 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
 
WARN_ON(!c-td_retry);
if (!c-td_desc_seen) {
-   desc_phys = cppi_readl(cdd-qmgr_mem + QMGR_QUEUE_D(c-q_num));
+   desc_phys = cppi41_pop_desc(cdd, c-q_num);
WARN_ON(!desc_phys);
}
 
-- 
1.8.3.1

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


[PATCH 0/3] dma: cppi41: more suspend/resume patches

2013-10-01 Thread Daniel Mack
 just changes the timing, and we're actually seeing a
race condition here.

Sebastian, can you give a comment on this? I'll post the musb patches
that are necessary as well now, and I'd appreciate more testers here.


Many thanks,
Daniel


Daniel Mack (3):
  dma: cppi41: restore more registers
  dma: cppi41: use cppi41_pop_desc() where possible
  dma: cppi41: move -EAGAIN in tear_down

 drivers/dma/cppi41.c | 43 +--
 1 file changed, 29 insertions(+), 14 deletions(-)

-- 
1.8.3.1

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


[PATCH 3/3] dma: cppi41: move -EAGAIN in tear_down

2013-10-01 Thread Daniel Mack
In cppi41_tear_down_chan(), bail out earlier in case td_seen is unset
instead of popping another descriptor when td_desc_seen is also unset.

My system ran into WARN() condition multiple times when
cppi41_tear_down_chan() was called for channels that had all of
td_queued, td_seen and td_seen set to false.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/dma/cppi41.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 7747bf7..6decf34 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -586,6 +586,9 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
}
c-td_seen = 1;
}
+
+   if (c-td_retry)
+   return -EAGAIN;
}
if (!c-td_desc_seen) {
desc_phys = cppi41_pop_desc(cdd, c-q_comp_num);
@@ -606,8 +609,6 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
 * descriptor before the TD we fetch it from enqueue, it has to be
 * there waiting for us.
 */
-   if (!c-td_seen  c-td_retry)
-   return -EAGAIN;
 
WARN_ON(!c-td_retry);
if (!c-td_desc_seen) {
-- 
1.8.3.1

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


[PATCH v2 0/5] usb: musb_dsps: support for suspend and resume

2013-10-01 Thread Daniel Mack
I've been working on some patches that allow suspending and resuming
the musb-dsps platform. This was tested for host mode only.

With these patches applied, I can successfully bring an AM335x board
to suspend with a USB media connected, and access it again after
resume.

This works for both PIO mode and CPPI41 enabled configurations,
together with my cppi41 patches that I posted here:

  http://marc.info/?l=linux-usbm=138063429219730w=2

More testing is certainly appreciated.


Thanks,
Daniel

Daniel Mack (5):
  usb: musb: move port reset to worker
  usb: musb: call musb_port_suspend from musb_bus_suspend
  usb: musb: conditionally save and restore the context on suspend
  usb: musb: dsps: add {tx,rx}_mode to wrapper
  usb: musb: dsps: add support for suspend and resume

 drivers/usb/musb/musb_core.c| 24 +++-
 drivers/usb/musb/musb_core.h|  3 ++
 drivers/usb/musb/musb_dsps.c| 64 +
 drivers/usb/musb/musb_host.c|  2 ++
 drivers/usb/musb/musb_host.h|  4 +++
 drivers/usb/musb/musb_virthub.c | 15 ++
 include/linux/usb/musb.h|  1 +
 7 files changed, 106 insertions(+), 7 deletions(-)

-- 
1.8.3.1

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


[PATCH v2 3/5] usb: musb: conditionally save and restore the context on suspend

2013-10-01 Thread Daniel Mack
It appears not all platforms featuring a musb core need to save the musb
core registers at suspend time and restore them on resume.

The dsps platform does, however. So add a bit in struct
musb_hdrc_platform_data to let platforms specify their need of such
action being taken.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.c | 17 -
 include/linux/usb/musb.h |  1 +
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 2b9f4b4..f17604e 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -2152,6 +2152,7 @@ static int musb_suspend(struct device *dev)
 {
struct musb *musb = dev_to_musb(dev);
unsigned long   flags;
+   struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
 
spin_lock_irqsave(musb-lock, flags);
 
@@ -2165,16 +2166,30 @@ static int musb_suspend(struct device *dev)
 */
}
 
+   if (plat-restore_after_suspend)
+   musb_save_context(musb);
+
spin_unlock_irqrestore(musb-lock, flags);
return 0;
 }
 
 static int musb_resume_noirq(struct device *dev)
 {
-   /* for static cmos like DaVinci, register values were preserved
+   struct musb *musb = dev_to_musb(dev);
+   struct musb_hdrc_platform_data *plat = dev_get_platdata(dev);
+
+   /*
+* For static cmos like DaVinci, register values were preserved
 * unless for some reason the whole soc powered down or the USB
 * module got reset through the PSC (vs just being disabled).
+*
+* The plaform data tells us about the necessity of saving and
+* restoring the context across a suspend cycle.
 */
+
+   if (plat-restore_after_suspend)
+   musb_restore_context(musb);
+
return 0;
 }
 
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..296be6c 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -100,6 +100,7 @@ struct musb_hdrc_platform_data {
u8  mode;
 
u8  has_mailbox:1;
+   u8  restore_after_suspend:1;
 
/* for clk_get() */
const char  *clock;
-- 
1.8.3.1

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


[PATCH v2 5/5] usb: musb: dsps: add support for suspend and resume

2013-10-01 Thread Daniel Mack
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 60 
 1 file changed, 60 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f3085bc..ac68e29 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
u8  poll_seconds;
 };
 
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+   u32 control;
+   u32 epintr;
+   u32 coreintr;
+   u32 phy_utmi;
+   u32 mode;
+   u32 tx_mode;
+   u32 rx_mode;
+};
+
 /**
  * DSPS glue structure.
  */
@@ -121,6 +134,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+   struct dsps_context context;
 };
 
 /**
@@ -504,6 +519,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
}
pdata.config = config;
pdata.platform_ops = dsps_ops;
+   pdata.restore_after_suspend = 1;
 
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
@@ -627,11 +643,55 @@ static const struct of_device_id musb_dsps_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
 
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   glue-context.control = dsps_readl(mbase, wrp-control);
+   glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+   glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+   glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+   glue-context.mode = dsps_readl(mbase, wrp-mode);
+   glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
+   glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
+
+   return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   dsps_writel(mbase, wrp-control, glue-context.control);
+   dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+   dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+   dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+   dsps_writel(mbase, wrp-mode, glue-context.mode);
+   dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+   dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+   musb-port_reset_state = false;
+   schedule_work(musb-port_reset_work);
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
.remove = dsps_remove,
.driver = {
.name   = musb-dsps,
+   .pm = dsps_pm_ops,
.of_match_table = of_match_ptr(musb_dsps_of_match),
},
 };
-- 
1.8.3.1

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


[PATCH v2 4/5] usb: musb: dsps: add {tx,rx}_mode to wrapper

2013-10-01 Thread Daniel Mack
rx_mode and tx_mode need to be read at suspend time and restored on
resume for dsps platforms. So add it to the wrapper struct first, and
initialize the values.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 4047cbb..f3085bc 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -83,6 +83,8 @@ struct dsps_musb_wrapper {
u16 coreintr_status;
u16 phy_utmi;
u16 mode;
+   u16 tx_mode;
+   u16 rx_mode;
 
/* bit positions for control */
unsignedreset:5;
@@ -600,6 +602,8 @@ static const struct dsps_musb_wrapper am33xx_driver_data = {
.coreintr_status= 0x34,
.phy_utmi   = 0xe0,
.mode   = 0xe8,
+   .tx_mode= 0x70,
+   .rx_mode= 0x74,
.reset  = 0,
.otg_disable= 21,
.iddig  = 8,
-- 
1.8.3.1

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


[PATCH v2 1/5] usb: musb: move port reset to worker

2013-10-01 Thread Daniel Mack
musb_port_reset() sleeps, so we can't call it from atomic context. It
is, however, called from places inside musb_hub_control() while
musb-lock is held, which leads to a scheduling while atomic warning.

Fix this by moving the logic into a worker, and call it where the
function was previously called directly.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_core.c|  7 +++
 drivers/usb/musb/musb_core.h|  3 +++
 drivers/usb/musb/musb_host.h|  2 ++
 drivers/usb/musb/musb_virthub.c | 13 -
 4 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 18e877f..2b9f4b4 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1699,6 +1699,12 @@ static void musb_irq_work(struct work_struct *data)
}
 }
 
+static void musb_port_reset_work(struct work_struct *data)
+{
+   struct musb *musb = container_of(data, struct musb, port_reset_work);
+   musb_port_reset(musb);
+}
+
 /* --
  * Init support
  */
@@ -1857,6 +1863,7 @@ musb_init_controller(struct device *dev, int nIrq, void 
__iomem *ctrl)
 
/* Init IRQ workqueue before request_irq */
INIT_WORK(musb-irq_work, musb_irq_work);
+   INIT_WORK(musb-port_reset_work, musb_port_reset_work);
 
/* attach to the IRQ */
if (request_irq(nIrq, musb-isr, 0, dev_name(dev), musb)) {
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 65f3917..9529512 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -294,6 +294,9 @@ struct musb {
 
irqreturn_t (*isr)(int, void *);
struct work_struct  irq_work;
+   struct work_struct  port_reset_work;
+   boolport_reset_state;
+
u16 hwvers;
 
u16 intrrxe;
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 960d735..843f48e 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -92,6 +92,7 @@ extern void musb_host_rx(struct musb *, u8);
 extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
+extern void musb_port_reset(struct musb *musb);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -121,6 +122,7 @@ static inline void musb_root_disconnect(struct musb *musb)  
{}
 static inline void musb_host_resume_root_hub(struct musb *musb){}
 static inline void musb_host_poll_rh_status(struct musb *musb) {}
 static inline void musb_host_poke_root_hub(struct musb *musb)  {}
+static inline void musb_port_reset(struct musb *musb)  {}
 #endif
 
 struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index a523950..30b43a1 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -155,7 +155,7 @@ static void musb_port_suspend(struct musb *musb, bool 
do_suspend)
}
 }
 
-static void musb_port_reset(struct musb *musb, bool do_reset)
+void musb_port_reset(struct musb *musb)
 {
u8  power;
void __iomem*mbase = musb-mregs;
@@ -173,7 +173,7 @@ static void musb_port_reset(struct musb *musb, bool 
do_reset)
 * the appropriate amount of time has passed
 */
power = musb_readb(mbase, MUSB_POWER);
-   if (do_reset) {
+   if (musb-port_reset_state) {
 
/*
 * If RESUME is set, we must make sure it stays minimum 20 ms.
@@ -356,8 +356,10 @@ int musb_hub_control(
 
/* finish RESET signaling? */
if ((musb-port1_status  USB_PORT_STAT_RESET)
-time_after_eq(jiffies, musb-rh_timer))
-   musb_port_reset(musb, false);
+time_after_eq(jiffies, musb-rh_timer)) {
+   musb-port_reset_state = false;
+   schedule_work(musb-port_reset_work);
+   }
 
/* finish RESUME signaling? */
if ((musb-port1_status  MUSB_PORT_STAT_RESUME)
@@ -412,7 +414,8 @@ int musb_hub_control(
musb_start(musb);
break;
case USB_PORT_FEAT_RESET:
-   musb_port_reset(musb, true);
+   musb-port_reset_state = true;
+   schedule_work(musb-port_reset_work);
break;
case USB_PORT_FEAT_SUSPEND:
musb_port_suspend(musb, true);
-- 
1.8.3.1

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


[PATCH v2 2/5] usb: musb: call musb_port_suspend from musb_bus_suspend

2013-10-01 Thread Daniel Mack
Make musb_port_suspend() externally available, and call it when to host
goes into suspend. This allows the core to go into suspend while a
device is connected.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_host.c| 2 ++
 drivers/usb/musb/musb_host.h| 2 ++
 drivers/usb/musb/musb_virthub.c | 2 +-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
index 9a2b8c8..2b60596 100644
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2433,6 +2433,8 @@ static int musb_bus_suspend(struct usb_hcd *hcd)
struct musb *musb = hcd_to_musb(hcd);
u8  devctl;
 
+   musb_port_suspend(musb, true);
+
if (!is_host_active(musb))
return 0;
 
diff --git a/drivers/usb/musb/musb_host.h b/drivers/usb/musb/musb_host.h
index 843f48e..dcffea7 100644
--- a/drivers/usb/musb/musb_host.h
+++ b/drivers/usb/musb/musb_host.h
@@ -93,6 +93,7 @@ extern void musb_root_disconnect(struct musb *musb);
 extern void musb_host_resume_root_hub(struct musb *musb);
 extern void musb_host_poke_root_hub(struct musb *musb);
 extern void musb_port_reset(struct musb *musb);
+extern void musb_port_suspend(struct musb *musb, bool do_suspend);
 #else
 static inline struct musb *hcd_to_musb(struct usb_hcd *hcd)
 {
@@ -123,6 +124,7 @@ static inline void musb_host_resume_root_hub(struct musb 
*musb) {}
 static inline void musb_host_poll_rh_status(struct musb *musb) {}
 static inline void musb_host_poke_root_hub(struct musb *musb)  {}
 static inline void musb_port_reset(struct musb *musb)  {}
+static inline void musb_port_suspend(struct musb *musb, bool do_suspend) {}
 #endif
 
 struct usb_hcd;
diff --git a/drivers/usb/musb/musb_virthub.c b/drivers/usb/musb/musb_virthub.c
index 30b43a1..9f3a0f3 100644
--- a/drivers/usb/musb/musb_virthub.c
+++ b/drivers/usb/musb/musb_virthub.c
@@ -90,7 +90,7 @@ static void musb_start(struct musb *musb)
musb_writeb(regs, MUSB_DEVCTL, devctl);
 }
 
-static void musb_port_suspend(struct musb *musb, bool do_suspend)
+void musb_port_suspend(struct musb *musb, bool do_suspend)
 {
struct usb_otg  *otg = musb-xceiv-otg;
u8  power;
-- 
1.8.3.1

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


[PATCH] ARM: omap: edma: add suspend suspend/resume hooks

2013-10-01 Thread Daniel Mack
This patch adds support for edma driver.

I know the intermediate code in arch/arm/common is going to be purged
eventually when the real dma-engine driver lands, so I don't know
whether it's reasonable to include my patch after all. It might just
server as template for the suspend/resume functions in the final
driver, or maybe anyone wants to include that intermediate hack for the
time being.

Successfully tested on an AM335x board with davinci-mcasp enabled
audio. A patch to make the latter work after suspend has been posted
on alsa-devel.


Thanks,
Dainel


Daniel Mack (1):
  ARM: omap: edma: add suspend suspend/resume hooks

 arch/arm/common/edma.c | 133 +
 1 file changed, 133 insertions(+)

-- 
1.8.3.1

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


[PATCH] ARM: omap: edma: add suspend suspend/resume hooks

2013-10-01 Thread Daniel Mack
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams.

The code was shamelessly taken from an ancient BSP tree.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 arch/arm/common/edma.c | 133 +
 1 file changed, 133 insertions(+)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 2a72169..d787f14 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -258,6 +258,20 @@ struct edma {
void *data);
void *data;
} intr_data[EDMA_MAX_DMACH];
+
+   struct {
+   struct edmacc_param *prm_set;
+   unsigned int *ch_map;   /* 64 registers */
+   unsigned int *que_num;  /* 8 registers */
+   unsigned int sh_esr;
+   unsigned int sh_esrh;
+   unsigned int sh_eesr;
+   unsigned int sh_eesrh;
+   unsigned int sh_iesr;
+   unsigned int sh_iesrh;
+   unsigned int que_tc_map;
+   unsigned int que_pri;
+   } context;
 };
 
 static struct edma *edma_cc[EDMA_MAX_CC];
@@ -1655,6 +1669,16 @@ static int edma_probe(struct platform_device *pdev)
memcpy_toio(edmacc_regs_base[j] + PARM_OFFSET(i),
dummy_paramset, PARM_SIZE);
 
+   /* resume context */
+   edma_cc[j]-context.prm_set =
+   kzalloc((sizeof(struct edmacc_param) *
+edma_cc[j]-num_slots), GFP_KERNEL);
+   edma_cc[j]-context.ch_map =
+   kzalloc((sizeof(unsigned int) *
+edma_cc[j]-num_channels), GFP_KERNEL);
+   edma_cc[j]-context.que_num =
+   kzalloc((sizeof(unsigned int) * 8), GFP_KERNEL);
+
/* Mark all channels as unused */
memset(edma_cc[j]-edma_unused, 0xff,
sizeof(edma_cc[j]-edma_unused));
@@ -1762,6 +1786,114 @@ static int edma_probe(struct platform_device *pdev)
return 0;
 }
 
+static int edma_pm_suspend(struct device *dev)
+{
+   int i, j;
+
+   pm_runtime_get_sync(dev);
+
+   for (i = 0; i  arch_num_cc; i++) {
+   struct edma *ecc = edma_cc[i];
+
+   /* backup channel data */
+   for (j = 0; j  ecc-num_channels; j++)
+   ecc-context.ch_map[j] =
+   edma_read_array(i, EDMA_DCHMAP, j);
+
+   /* backup DMA Queue Number */
+   for (j = 0; j  8; j++)
+   ecc-context.que_num[j] =
+   edma_read_array(i, EDMA_DMAQNUM, j);
+
+   /* backup DMA shadow Event Set data */
+   ecc-context.sh_esr = edma_shadow0_read_array(i, SH_ESR, 0);
+   ecc-context.sh_esrh = edma_shadow0_read_array(i, SH_ESR, 1);
+
+   /* backup DMA Shadow Event Enable Set data */
+   ecc-context.sh_eesr =
+   edma_shadow0_read_array(i, SH_EER, 0);
+   ecc-context.sh_eesrh =
+   edma_shadow0_read_array(i, SH_EER, 1);
+
+   /* backup DMA Shadow Interrupt Enable Set data */
+   ecc-context.sh_iesr =
+   edma_shadow0_read_array(i, SH_IER, 0);
+   ecc-context.sh_iesrh =
+   edma_shadow0_read_array(i, SH_IER, 1);
+
+   ecc-context.que_tc_map = edma_read(i, EDMA_QUETCMAP);
+
+   /* backup DMA Queue Priority data */
+   ecc-context.que_pri = edma_read(i, EDMA_QUEPRI);
+
+   /* backup paramset */
+   for (j = 0; j  ecc-num_slots; j++)
+   memcpy_fromio(ecc-context.prm_set[j],
+ edmacc_regs_base[i] + PARM_OFFSET(j),
+ PARM_SIZE);
+   }
+
+   pm_runtime_put_sync(dev);
+
+   return 0;
+}
+
+static int edma_pm_resume(struct device *dev)
+{
+   int i, j;
+
+   pm_runtime_get_sync(dev);
+
+   for (i = 0; i  arch_num_cc; i++) {
+   struct edma *ecc = edma_cc[i];
+
+   /* restore channel data */
+   for (j = 0; j  ecc-num_channels; j++) {
+   edma_write_array(i, EDMA_DCHMAP, j,
+ecc-context.ch_map[j]);
+   }
+
+   /* restore DMA Queue Number */
+   for (j = 0; j  8; j++) {
+   edma_write_array(i, EDMA_DMAQNUM, j,
+ecc-context.que_num[j]);
+   }
+
+   /* restore DMA shadow Event Set data */
+   edma_shadow0_write_array(i, SH_ESR, 0, ecc-context.sh_esr);
+   edma_shadow0_write_array(i, SH_ESR, 1, ecc-context.sh_esrh

Re: [PATCH v2 5/5] usb: musb: dsps: add support for suspend and resume

2013-10-01 Thread Daniel Mack
On 01.10.2013 16:59, Felipe Balbi wrote:
 On Tue, Oct 01, 2013 at 03:39:57PM +0200, Daniel Mack wrote:
 The dsps platform needs to save save some registers at suspend time and
 restore them after resume. This patch adds a struct for these registers,
 and also lets the musb core know that the core registers need to be
 saved as well.

 Signed-off-by: Daniel Mack zon...@gmail.com
 
 this last patch didn't apply. can you rebase on my 'testing' branch ?

I've seen that you already applied the others, so I'm going to resend
only that last one. Hope that's ok.


Daniel

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


[PATCH v3] ARM: omap: edma: add suspend suspend/resume hooks

2013-10-01 Thread Daniel Mack
This patch makes the edma driver resume correctly after suspend. Tested
on an AM33xx platform with cyclic audio streams.

The code was shamelessly taken from an ancient BSP tree.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 arch/arm/common/edma.c | 133 +
 1 file changed, 133 insertions(+)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 2a72169..d787f14 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -258,6 +258,20 @@ struct edma {
void *data);
void *data;
} intr_data[EDMA_MAX_DMACH];
+
+   struct {
+   struct edmacc_param *prm_set;
+   unsigned int *ch_map;   /* 64 registers */
+   unsigned int *que_num;  /* 8 registers */
+   unsigned int sh_esr;
+   unsigned int sh_esrh;
+   unsigned int sh_eesr;
+   unsigned int sh_eesrh;
+   unsigned int sh_iesr;
+   unsigned int sh_iesrh;
+   unsigned int que_tc_map;
+   unsigned int que_pri;
+   } context;
 };
 
 static struct edma *edma_cc[EDMA_MAX_CC];
@@ -1655,6 +1669,16 @@ static int edma_probe(struct platform_device *pdev)
memcpy_toio(edmacc_regs_base[j] + PARM_OFFSET(i),
dummy_paramset, PARM_SIZE);
 
+   /* resume context */
+   edma_cc[j]-context.prm_set =
+   kzalloc((sizeof(struct edmacc_param) *
+edma_cc[j]-num_slots), GFP_KERNEL);
+   edma_cc[j]-context.ch_map =
+   kzalloc((sizeof(unsigned int) *
+edma_cc[j]-num_channels), GFP_KERNEL);
+   edma_cc[j]-context.que_num =
+   kzalloc((sizeof(unsigned int) * 8), GFP_KERNEL);
+
/* Mark all channels as unused */
memset(edma_cc[j]-edma_unused, 0xff,
sizeof(edma_cc[j]-edma_unused));
@@ -1762,6 +1786,114 @@ static int edma_probe(struct platform_device *pdev)
return 0;
 }
 
+static int edma_pm_suspend(struct device *dev)
+{
+   int i, j;
+
+   pm_runtime_get_sync(dev);
+
+   for (i = 0; i  arch_num_cc; i++) {
+   struct edma *ecc = edma_cc[i];
+
+   /* backup channel data */
+   for (j = 0; j  ecc-num_channels; j++)
+   ecc-context.ch_map[j] =
+   edma_read_array(i, EDMA_DCHMAP, j);
+
+   /* backup DMA Queue Number */
+   for (j = 0; j  8; j++)
+   ecc-context.que_num[j] =
+   edma_read_array(i, EDMA_DMAQNUM, j);
+
+   /* backup DMA shadow Event Set data */
+   ecc-context.sh_esr = edma_shadow0_read_array(i, SH_ESR, 0);
+   ecc-context.sh_esrh = edma_shadow0_read_array(i, SH_ESR, 1);
+
+   /* backup DMA Shadow Event Enable Set data */
+   ecc-context.sh_eesr =
+   edma_shadow0_read_array(i, SH_EER, 0);
+   ecc-context.sh_eesrh =
+   edma_shadow0_read_array(i, SH_EER, 1);
+
+   /* backup DMA Shadow Interrupt Enable Set data */
+   ecc-context.sh_iesr =
+   edma_shadow0_read_array(i, SH_IER, 0);
+   ecc-context.sh_iesrh =
+   edma_shadow0_read_array(i, SH_IER, 1);
+
+   ecc-context.que_tc_map = edma_read(i, EDMA_QUETCMAP);
+
+   /* backup DMA Queue Priority data */
+   ecc-context.que_pri = edma_read(i, EDMA_QUEPRI);
+
+   /* backup paramset */
+   for (j = 0; j  ecc-num_slots; j++)
+   memcpy_fromio(ecc-context.prm_set[j],
+ edmacc_regs_base[i] + PARM_OFFSET(j),
+ PARM_SIZE);
+   }
+
+   pm_runtime_put_sync(dev);
+
+   return 0;
+}
+
+static int edma_pm_resume(struct device *dev)
+{
+   int i, j;
+
+   pm_runtime_get_sync(dev);
+
+   for (i = 0; i  arch_num_cc; i++) {
+   struct edma *ecc = edma_cc[i];
+
+   /* restore channel data */
+   for (j = 0; j  ecc-num_channels; j++) {
+   edma_write_array(i, EDMA_DCHMAP, j,
+ecc-context.ch_map[j]);
+   }
+
+   /* restore DMA Queue Number */
+   for (j = 0; j  8; j++) {
+   edma_write_array(i, EDMA_DMAQNUM, j,
+ecc-context.que_num[j]);
+   }
+
+   /* restore DMA shadow Event Set data */
+   edma_shadow0_write_array(i, SH_ESR, 0, ecc-context.sh_esr);
+   edma_shadow0_write_array(i, SH_ESR, 1, ecc-context.sh_esrh

[PATCH v3] usb: musb: dsps: add support for suspend and resume

2013-10-01 Thread Daniel Mack
The dsps platform needs to save save some registers at suspend time and
restore them after resume. This patch adds a struct for these registers,
and also lets the musb core know that the core registers need to be
saved as well.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/musb_dsps.c | 60 
 1 file changed, 60 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 5eba143..f2f4b3a 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -112,6 +112,19 @@ struct dsps_musb_wrapper {
u8  poll_seconds;
 };
 
+/*
+ * register shadow for suspend
+ */
+struct dsps_context {
+   u32 control;
+   u32 epintr;
+   u32 coreintr;
+   u32 phy_utmi;
+   u32 mode;
+   u32 tx_mode;
+   u32 rx_mode;
+};
+
 /**
  * DSPS glue structure.
  */
@@ -121,6 +134,8 @@ struct dsps_glue {
const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
+
+   struct dsps_context context;
 };
 
 /**
@@ -504,6 +519,7 @@ static int dsps_create_musb_pdev(struct dsps_glue *glue,
}
pdata.config = config;
pdata.platform_ops = dsps_ops;
+   pdata.restore_after_suspend = 1;
 
config-num_eps = get_int_prop(dn, mentor,num-eps);
config-ram_bits = get_int_prop(dn, mentor,ram-bits);
@@ -627,11 +643,55 @@ static const struct of_device_id musb_dsps_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, musb_dsps_of_match);
 
+#ifdef CONFIG_PM
+static int dsps_suspend(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   glue-context.control = dsps_readl(mbase, wrp-control);
+   glue-context.epintr = dsps_readl(mbase, wrp-epintr_set);
+   glue-context.coreintr = dsps_readl(mbase, wrp-coreintr_set);
+   glue-context.phy_utmi = dsps_readl(mbase, wrp-phy_utmi);
+   glue-context.mode = dsps_readl(mbase, wrp-mode);
+   glue-context.tx_mode = dsps_readl(mbase, wrp-tx_mode);
+   glue-context.rx_mode = dsps_readl(mbase, wrp-rx_mode);
+
+   return 0;
+}
+
+static int dsps_resume(struct device *dev)
+{
+   struct dsps_glue *glue = dev_get_drvdata(dev);
+   const struct dsps_musb_wrapper *wrp = glue-wrp;
+   struct musb *musb = platform_get_drvdata(glue-musb);
+   void __iomem *mbase = musb-ctrl_base;
+
+   dsps_writel(mbase, wrp-control, glue-context.control);
+   dsps_writel(mbase, wrp-epintr_set, glue-context.epintr);
+   dsps_writel(mbase, wrp-coreintr_set, glue-context.coreintr);
+   dsps_writel(mbase, wrp-phy_utmi, glue-context.phy_utmi);
+   dsps_writel(mbase, wrp-mode, glue-context.mode);
+   dsps_writel(mbase, wrp-tx_mode, glue-context.tx_mode);
+   dsps_writel(mbase, wrp-rx_mode, glue-context.rx_mode);
+
+   musb-port_reset_state = false;
+   schedule_work(musb-port_reset_work);
+
+   return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dsps_pm_ops, dsps_suspend, dsps_resume);
+
 static struct platform_driver dsps_usbss_driver = {
.probe  = dsps_probe,
.remove = dsps_remove,
.driver = {
.name   = musb-dsps,
+   .pm = dsps_pm_ops,
.of_match_table = musb_dsps_of_match,
},
 };
-- 
1.8.3.1

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


Re: [PATCH v3 4/5] dma: cppi41: only allocate descriptor memory once

2013-10-01 Thread Daniel Mack
On 01.10.2013 18:22, Sebastian Andrzej Siewior wrote:
 On 10/01/2013 03:09 PM, Daniel Mack wrote:

 A simplified version of the code as it stands is:

   for (i = 0; i  DESCS_AREAS; i++)
 cdd-cd = dma_alloc_coherent(dev, ..., cdd-descs_phys, GFP_KERNEL);

   for (i = 0; i  DESCS_AREAS; i++)
 dma_free_coherent(dev, mem_decs, cdd-cd, cdd-descs_phys);

...

 So, after all, my patch doesn't really change any of the runtime
 behaviour. Consider it a cosmetic cleanup if you wish :)
 
 But it looks strange (in my opinion at least).

I still disagree, but maybe that doesn't matter any more, because ...

 But now, that I look
 again at it yes you moved the alloc out of the loop and replaced
 mem_decs with the computation. So nothing changed but you moved it
 outside.
 
 Right I think one desc area should be enough so I would just remove the
 for loop and DESCS_AREAS as well. How does this sound to you?

That sound's like a good idea. Everything that make the driver smaller
and easier to understand is certainly a good thing :)

So we can drop this patch favor of your cleanup. However, I appreciate
if you did it on top of the second round of patches I sent today please,
because my resume() implementation uses DESCS_AREAS as well.


Thanks,
Daniel
--
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/4] usb: musb: am35x: use SIMPLE_DEV_PM_OPS

2013-09-30 Thread Daniel Mack
On 30.09.2013 18:25, Felipe Balbi wrote:
 On Fri, Sep 27, 2013 at 08:47:10PM +0200, Daniel Mack wrote:
 On 25.09.2013 15:48, Felipe Balbi wrote:
 On Tue, Sep 24, 2013 at 08:57:08AM +0200, Daniel Mack wrote:
 On 23.09.2013 23:20, Felipe Balbi wrote:
 On Sun, Sep 22, 2013 at 01:46:58PM +0200, Daniel Mack wrote:

 -static struct dev_pm_ops am35x_pm_ops = {
 -.suspend= am35x_suspend,
 -.resume = am35x_resume,
 -};
 +static SIMPLE_DEV_PM_OPS(am35x_pm_ops, am35x_suspend, am35x_resume);

 you could as well remove the DEV_PM_OPS trickery. Ditto for all other
 patches

 Yes, I noticed that too. That's why I sent out a v2 of the series :)

 Awesome :-) Thanks dude

 So are you happy with this v2?
 It's just a cosmetic cleanup after all ...
 
 I can't see v2 anywhere... The only version I have is the one with
 DEV_PM_OPS still in it.

Ok, I'll resend them later.


Daniel

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


[PATCH v2 RESEND 2/3] usb: musb: blackfin: use SIMPLE_DEV_PM_OPS

2013-09-30 Thread Daniel Mack
This makes bfin_pm_ops const and will stub the struct out in case
CONFIG_PM_SLEEP is not set.

Signed-off-by: Daniel Mack zon...@gmail.com
---
 drivers/usb/musb/blackfin.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index 72e2056..d9692f7 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -561,23 +561,16 @@ static int bfin_resume(struct device *dev)
 
return 0;
 }
-
-static struct dev_pm_ops bfin_pm_ops = {
-   .suspend= bfin_suspend,
-   .resume = bfin_resume,
-};
-
-#define DEV_PM_OPS bfin_pm_ops
-#else
-#define DEV_PM_OPS NULL
 #endif
 
+static SIMPLE_DEV_PM_OPS(bfin_pm_ops, bfin_suspend, bfin_resume);
+
 static struct platform_driver bfin_driver = {
.probe  = bfin_probe,
.remove = __exit_p(bfin_remove),
.driver = {
.name   = musb-blackfin,
-   .pm = DEV_PM_OPS,
+   .pm = bfin_pm_ops,
},
 };
 
-- 
1.8.3.1

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


  1   2   3   4   >