Re: [PATCH] dma: cppi41: delete channel from pending list when stop channel

[Vinod Koul]

On 28-11-18, 13:15, Peter Ujfalusi wrote:
> 
> 
> On 12/11/2018 17.40, Bin Liu wrote:
> 
> Can you fix up the subject line to:
> dmaengine: ti: cppi4: delete channel from pending list when stop channel
> 
> > The driver defines three states for a cppi channel.
> > - idle: .chan_busy == 0 && not in .pending list
> > - pending: .chan_busy == 0 && in .pending list
> > - busy: .chan_busy == 1 && not in .pending list
> > 
> > There are cases in which the cppi channel could be in the pending state
> > when cppi41_dma_issue_pending() is called after cppi41_runtime_suspend()
> > is called.
> > 
> > cppi41_stop_chan() has a bug for these cases to set channels to idle state.
> > It only checks the .chan_busy flag, but not the .pending list, then later
> > when cppi41_runtime_resume() is called the channels in .pending list will
> > be transitioned to busy state.
> > 
> > Removing channels from the .pending list solves the problem.
> 
> So, let me see if I understand this correctly:
> - client issued a transfer _after_ the cppi4 driver is suspended
> - cppi41_dma_issue_pending() will place it to pending list and will not
> start the transfer right away as cdd->is_suspended is true.
> - on resume the cppi4 will pick up the pending transfers from the
> pending list
> 
> This is so far a sane thing to do.
> 
> If I guess right, then after the issue_pending the client driver will
> call terminate_all, presumably from it's suspend callback?
> 
> As per the purpose of terminate_all we should terminated all future
> transfers on the channel, so clearing the pending list is the correct
> thing to do.
> 
> With the fixed subject:
> Reviewed-by: Peter Ujfalusi 

Thanks Peter,

Applied after fixing the title, thanks

-- 
~Vinod

Re: [PATCH] dma: cppi41: delete channel from pending list when stop channel

[Vinod Koul]

On 12-11-18, 09:43, Bin Liu wrote:
> The driver defines three states for a cppi channel.
> - idle: .chan_busy == 0 && not in .pending list
> - pending: .chan_busy == 0 && in .pending list
> - busy: .chan_busy == 1 && not in .pending list
> 
> There are cases in which the cppi channel could be in the pending state
> when cppi41_dma_issue_pending() is called after cppi41_runtime_suspend()
> is called.
> 
> cppi41_stop_chan() has a bug for these cases to set channels to idle state.
> It only checks the .chan_busy flag, but not the .pending list, then later
> when cppi41_runtime_resume() is called the channels in .pending list will
> be transitioned to busy state.
> 
> Removing channels from the .pending list solves the problem.

I would like some testing, given that intent is to go to stable.
Peter..?

> 
> Fixes: 975faaeb9985 ("dma: cppi41: start tear down only if channel is busy")
> Cc: sta...@vger.kernel.org # v3.15+
> Signed-off-by: Bin Liu 
> ---
>  drivers/dma/ti/cppi41.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/ti/cppi41.c b/drivers/dma/ti/cppi41.c
> index 1497da367710..e507ec36c0d3 100644
> --- a/drivers/dma/ti/cppi41.c
> +++ b/drivers/dma/ti/cppi41.c
> @@ -723,8 +723,22 @@ static int cppi41_stop_chan(struct dma_chan *chan)
>  
>   desc_phys = lower_32_bits(c->desc_phys);
>   desc_num = (desc_phys - cdd->descs_phys) / sizeof(struct cppi41_desc);
> - if (!cdd->chan_busy[desc_num])
> + if (!cdd->chan_busy[desc_num]) {
> + struct cppi41_channel *cc, *_ct;
> +
> + /*
> +  * channels might still be in the pendling list if
> +  * cppi41_dma_issue_pending() is called after
> +  * cppi41_runtime_suspend() is called
> +  */
> + list_for_each_entry_safe(cc, _ct, >pending, node) {
> + if (cc != c)
> + continue;
> + list_del(>node);
> + break;
> + }
>   return 0;
> + }
>  
>   ret = cppi41_tear_down_chan(c);
>   if (ret)
> -- 
> 2.17.1

-- 
~Vinod

Re: [PATCH v3 1/9] dmaengine: omap-dma: port_window support correction for both direction

[Vinod Koul]

On Fri, May 12, 2017 at 04:57:44PM +0300, Peter Ujfalusi wrote:
> When the port_window support was verified it was done on setup where only
> the MEM_TO_DEV direction was enabled. This got un-noticed and thus only
> this direction worked.
> 
> Now that I have managed to get a setup to verify both direction it turned
> out that the setup was incorrect:
> omap_desc members are settings for the slave port while the omap_sg members
> apply to the memory side of the sDMA setup.

Acked-by: Vinod Koul <vinod.k...@intel.com>

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

Re: [PATCH][linux-next] dmaengine: cppi41: Fix an Oops happening in cppi41_dma_probe()

[Vinod Koul]

On Wed, Apr 05, 2017 at 06:35:16PM +0200, Alexandre Bailon wrote:
> This fix an Oops happening on all platforms using the old dt bindings
> (all platforms but da8xx).
> This update cppi41_dma_probe() to use the index variable which is
> required to keep compatibility between old and new dt bindings.

Applied, thanks

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 0/3] dmaengine: cppi41: Add dma support to da8xx

[Vinod Koul]

On Mon, Jan 30, 2017 at 06:49:18PM +0100, Alexandre Bailon wrote:
> This series add support of DA8xx to CPPI 4.1 driver.
> As the CPPI 4.1 is now generic, we only had to add the glue for DA8xx.

Applied this one as well, thanks

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

Re: [PATCH v5 0/5] dmaengine: cppi41: Make CPPI 4.1 driver more generic

[Vinod Koul]

On Wed, Feb 15, 2017 at 02:56:31PM +0100, Alexandre Bailon wrote:
> This series intend to make the CPPI 4.1 more generic in order to
> add a new platform (the DA8xx).
> To achieve that, all the IRQ code present in CPPI 4.1 driver has been moved
> to MUSB DSPS driver.
> Other changes mainly update the glue layer and platform code to make the
> whole driver more generic.

Applied thanks

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

Re: [PATCH v5 0/5] dmaengine: cppi41: Make CPPI 4.1 driver more generic

[Vinod Koul]

On Wed, Feb 15, 2017 at 02:56:31PM +0100, Alexandre Bailon wrote:
> This series intend to make the CPPI 4.1 more generic in order to
> add a new platform (the DA8xx).
> To achieve that, all the IRQ code present in CPPI 4.1 driver has been moved
> to MUSB DSPS driver.
> Other changes mainly update the glue layer and platform code to make the
> whole driver more generic.
> 
> Changes in v5:
>  - Rebase on linux-next
>  - No dependencies on other series anymore (they have been applied)

Not really, we dont apply patches on linux-next but on subsystem tree's.
So since we are soo close to merge window, am going to defer this series and
apply once merge window closes.

> 
> Changes in v4:
>  - Remove dev argument in patch 4
>  - Remove the isr callback from glue
> 
> Changes in v3:
> - To prevent build error report from kbuild test robot, move the first
>   patch of v2 to another patchset.
> - Make CPPI 4.1 driver compatible with old and new binddings.
> - Remove the patch updating the am33xx-usb binddings.
> - Remove useless changes in patch 4
> - Remove a patch that was fixing PM runtime issue that was happenning
>   during a teardown. Tony Lindgren's patches fix the issue.
> 
> Alexandre Bailon (5):
>   dmaengine: cppi41: Remove usbss_mem
>   dmaengine: cppi41: rename platform variables
>   dmaengine: cppi41: Move some constants to glue layer
>   dmaengine: cppi41: init_sched(): Get number of channels from DT
>   dmaengine: cppi41: Remove isr callback from glue layer
> 
>  drivers/dma/cppi41.c | 79 
> ++--
>  1 file changed, 46 insertions(+), 33 deletions(-)
> 
> -- 
> 2.10.2
> 

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

Re: [PATCH v5 6/6] usb: musb: dsps: Manage CPPI 4.1 DMA interrupt in DSPS

[Vinod Koul]

On Wed, Jan 25, 2017 at 11:17:09AM +0100, Alexandre Bailon wrote:
> Despite the CPPI 4.1 is a generic DMA, it is tied to USB.
> On the DSPS, CPPI 4.1 interrupt's registers are in USBSS (the MUSB glue).
> Currently, to enable / disable and clear interrupts, the CPPI 4.1 driver
> maps and accesses to USBSS's register, which making CPPI 4.1 driver not
> really generic.
> Move the interrupt management to DSPS driver.
> 
> Signed-off-by: Alexandre Bailon <abai...@baylibre.com>
> ---
>  drivers/dma/cppi41.c | 28 ++++---

Acked-by: Vinod Koul <vinod.k...@intel.com>

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

Re: [PATCHv4 0/2] cppi41 dma fixes for v4.10-rc cycle

[Vinod Koul]

On Thu, Jan 19, 2017 at 08:49:06AM -0800, Tony Lindgren wrote:
> Hi all,
> 
> I'm using v4 naming here as the earlier patch "dmaengine: cppi41: Add dma
> support to da8xx" has been separated from the error -115 issue. We've
> identified so far three musb and cppi41 regressions:
> 
> 1. Error -71 regression with musb
> 
>This is not dma related, and fixed with recently posted patch
>"[PATCH 1/2] usb: musb: Fix host mode error -71 regression".
> 
> 2. Error -115 regression with cppi41 dma with musb
> 
>This regression was caused by commit 098de42ad670 ("dmaengine:
>cppi41: Fix unpaired pm runtime when only a USB hub is connected")
>and causes runtime PM autosuspend delay to time out on active dma
>transfers when connecting a mass storage device to a usb hub.
>This is fixed in the first patch in this series.
> 
> 3. Race with runtime PM and cppi41_dma_issue_pending()
> 
>This is really a separate issue from the error -115 problem, and
>fixed with the second patch in this series. That's minimal v4
>version of the "dmaengine: cppi41: Fix oops in cppi41_runtime_resume"
>patch.

Applied, thanks

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

Re: [PATCHv4 0/2] cppi41 dma fixes for v4.10-rc cycle

[Vinod Koul]

On Thu, Jan 19, 2017 at 08:49:06AM -0800, Tony Lindgren wrote:
> Hi all,
> 
> I'm using v4 naming here as the earlier patch "dmaengine: cppi41: Add dma
> support to da8xx" has been separated from the error -115 issue. We've
> identified so far three musb and cppi41 regressions:

Hi,

Can we get some tested-by for this series?

> 
> 1. Error -71 regression with musb
> 
>This is not dma related, and fixed with recently posted patch
>"[PATCH 1/2] usb: musb: Fix host mode error -71 regression".
> 
> 2. Error -115 regression with cppi41 dma with musb
> 
>This regression was caused by commit 098de42ad670 ("dmaengine:
>cppi41: Fix unpaired pm runtime when only a USB hub is connected")
>and causes runtime PM autosuspend delay to time out on active dma
>transfers when connecting a mass storage device to a usb hub.
>This is fixed in the first patch in this series.
> 
> 3. Race with runtime PM and cppi41_dma_issue_pending()
> 
>This is really a separate issue from the error -115 problem, and
>fixed with the second patch in this series. That's minimal v4
>version of the "dmaengine: cppi41: Fix oops in cppi41_runtime_resume"
>patch.
> 
> Regards,
> 
> Tony
> 
> 
> Tony Lindgren (2):
>   dmaengine: cppi41: Fix runtime PM timeouts with USB mass storage
>   dmaengine: cppi41: Fix oops in cppi41_runtime_resume
> 
>  drivers/dma/cppi41.c | 56 
> ++--
>  1 file changed, 41 insertions(+), 15 deletions(-)
> 
> -- 
> 2.11.0

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

Re: [PATCH] dmaengine: cppi41: More PM runtime fixes

[Vinod Koul]

On Wed, Nov 16, 2016 at 10:24:15AM -0800, Tony Lindgren wrote:
> Fix use of u32 instead of int for checking for negative errors values
> as pointed out by Dan Carpenter .
> 
> And while testing the PM runtime error path by randomly returning
> failed values in runtime resume, I noticed two more places that need
> fixing:
> 
> - If pm_runtime_get_sync() fails in probe, we still need to do
>   pm_runtime_put_sync() to keep the use count happy. We could call
>   pm_runtime_put_noidle() on the error path, but we're just going
>   to call pm_runtime_disable() after that so pm_runtime_put_sync()
>   will do what we want
> 
> - We should print an error if pm_runtime_get_sync() fails in
>   cppi41_dma_alloc_chan_resources() so we know where it happens

Applied now. Would have been ideal if the patches were split per fix

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

Re: [PATCH 0/2] Two cpp41 pm runtime found when testing with usb

[Vinod Koul]

On Mon, Nov 14, 2016 at 06:49:12AM -0800, Tony Lindgren wrote:
> * Vinod Koul <vinod.k...@intel.com> [161113 21:19]:
> > On Wed, Nov 09, 2016 at 09:47:57AM -0700, Tony Lindgren wrote:
> > > Hi,
> > > 
> > > I found two pm runtime issues when testing with usb on beaglebone.
> > > 
> > > In the am335x case cppi41 and two instances of musb controller share
> > > the same interconnect wrapper module, so any pm issues with musb or
> > > cppi41 will keep the interconnect wrapper module busy.
> > 
> > Applied both. And as I have told you previously please use the correct
> > subsystem tag. I have fixed them again!
> 
> Sorry about that. What do you prefer for future reference? We are using
> both "dma: cppi41" and "dmaengine: cppi41" currently..

"dmaengine: cppi41: xxx" would be better

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

Re: [PATCH 0/2] Two cpp41 pm runtime found when testing with usb

[Vinod Koul]

On Wed, Nov 09, 2016 at 09:47:57AM -0700, Tony Lindgren wrote:
> Hi,
> 
> I found two pm runtime issues when testing with usb on beaglebone.
> 
> In the am335x case cppi41 and two instances of musb controller share
> the same interconnect wrapper module, so any pm issues with musb or
> cppi41 will keep the interconnect wrapper module busy.

Applied both. And as I have told you previously please use the correct
subsystem tag. I have fixed them again!

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

Re: [PATCH] dmaengine: cppi41: Ignore EINPROGRESS for PM runtime

[Vinod Koul]

On Tue, Sep 13, 2016 at 10:22:43AM -0700, Tony Lindgren wrote:
> We can occasionally get -EINPROGRESS for pm_runtime_get. In that case
> we can just continue as we're queueing transfers anyways when
> pm_runtime_active is not set.

Applied, thanks

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

Re: [PATCH 2/2] dmaengine: cppi41: Add basic PM runtime support

[Vinod Koul]

On Wed, Aug 31, 2016 at 07:30:55AM -0700, Tony Lindgren wrote:
> * Vinod Koul <vinod.k...@intel.com> [160830 21:45]:
> > On Fri, Aug 19, 2016 at 03:59:40PM -0700, Tony Lindgren wrote:
> > > Let's keep the device enabled between cppi41_dma_issue_pending()
> > > and dmaengine_desc_get_callback_invoke() and rely on the PM runtime
> > > autoidle timeout elsewhere.
> > > 
> > > As the PM runtime is for whole device, not for each channel,
> > > we need to queue pending transfers if the device is PM runtime
> > > suspended. Then we start the pending transfers in PM runtime
> > > resume.
> > 
> > This fails to apply for me :(
> > 
> > Can you please rebase and resend this one.
> 
> OK sorry about that, that was against Linux next. The conflict
> is with c->txd.callback and dmaengine_desc_get_callback_invoke.
> 
> Below is a version against your cppi branch.

Thanks, applied now

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

Re: [PATCH 1/2] dmaengine: cppi41: Prepare to add PM runtime support

[Vinod Koul]

On Fri, Aug 19, 2016 at 03:59:39PM -0700, Tony Lindgren wrote:
> Let's just move code from cppi41_dma_issue_pending() to
> push_desc_queue() as that's the only call to push_desc_queue().
> 
> We want to do this for PM runtime as we need to call push_desc_queue()
> also for pending queued transfers from PM runtime resume.
> 
> No functional changes, just moves code around.

Applied, now

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

Re: [PATCH 2/2] dmaengine: cppi41: Add basic PM runtime support

[Vinod Koul]

On Fri, Aug 19, 2016 at 03:59:40PM -0700, Tony Lindgren wrote:
> Let's keep the device enabled between cppi41_dma_issue_pending()
> and dmaengine_desc_get_callback_invoke() and rely on the PM runtime
> autoidle timeout elsewhere.
> 
> As the PM runtime is for whole device, not for each channel,
> we need to queue pending transfers if the device is PM runtime
> suspended. Then we start the pending transfers in PM runtime
> resume.

This fails to apply for me :(

Can you please rebase and resend this one.

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

Re: [PATCH 2/2] dmaengine: cppi41: Add basic PM runtime support

[Vinod Koul]

On Mon, Aug 22, 2016 at 07:21:48AM -0700, Tony Lindgren wrote:
> Hi,
> 
> * Vinod Koul <vinod.k...@intel.com> [160821 23:34]:
> > On Fri, Aug 19, 2016 at 03:59:40PM -0700, Tony Lindgren wrote:
> > @@ -349,6 +358,12 @@ static dma_cookie_t cppi41_tx_submit(struct 
> > dma_async_tx_descriptor *tx)
> > >  static int cppi41_dma_alloc_chan_resources(struct dma_chan *chan)
> > >  {
> > >   struct cppi41_channel *c = to_cpp41_chan(chan);
> > > + struct cppi41_dd *cdd = c->cdd;
> > > + int error;
> > > +
> > > + error = pm_runtime_get_sync(cdd->ddev.dev);
> > 
> > This will be problematic. The alloc callback are not supposed to sleep, so
> > we cannot use a _sync() call here :(
> > 
> > This is explicitly documented in Documentation/dmaengine/provider.txt
> 
> Hmm but for device_alloc_chan_resources and device_free_chan_resources
> we have "These functions can sleep" in the documentation?

which is correct :)

> 
> Maybe you got confused with the patch @@ line saying cppi41_tx_submit
> although the pm_runtime_get is in cppi41_dma_alloc_chan_resources?
> Or else I'm confused :)

Ah, I was trying to finish this before I took my lunch break and looks like
messed it up. Sorry..
Never to rush a review again!

> Anyways, if necessary we could move the call to cppi_writel out of
> cppi41_dma_alloc_chan_resources I think.

I think alloc is fine, I will take a detailed look tomorrow...

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

Re: [PATCH 2/2] dmaengine: cppi41: Add basic PM runtime support

[Vinod Koul]

On Fri, Aug 19, 2016 at 03:59:40PM -0700, Tony Lindgren wrote:
> Let's keep the device enabled between cppi41_dma_issue_pending()
> and dmaengine_desc_get_callback_invoke() and rely on the PM runtime
> autoidle timeout elsewhere.
> 
> As the PM runtime is for whole device, not for each channel,
> we need to queue pending transfers if the device is PM runtime
> suspended. Then we start the pending transfers in PM runtime
> resume.
> 
> Signed-off-by: Tony Lindgren 
> ---
>  drivers/dma/cppi41.c | 104 
> ---
>  1 file changed, 99 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
> index 66b84fe..ce8739f 100644
> --- a/drivers/dma/cppi41.c
> +++ b/drivers/dma/cppi41.c
> @@ -108,6 +108,8 @@ struct cppi41_channel {
>   unsigned td_queued:1;
>   unsigned td_seen:1;
>   unsigned td_desc_seen:1;
> +
> + struct list_head node;  /* Node for pending list */
>  };
>  
>  struct cppi41_desc {
> @@ -146,6 +148,9 @@ struct cppi41_dd {
>   const struct chan_queues *queues_tx;
>   struct chan_queues td_queue;
>  
> + struct list_head pending;   /* Pending queued transfers */
> + spinlock_t lock;/* Lock for pending list */
> +
>   /* context for suspend/resume */
>   unsigned int dma_tdfdq;
>  };
> @@ -332,6 +337,10 @@ static irqreturn_t cppi41_irq(int irq, void *data)
>   c->residue = pd_trans_len(c->desc->pd6) - len;
>   dma_cookie_complete(>txd);
>   dmaengine_desc_get_callback_invoke(>txd, NULL);
> +
> + /* Paired with cppi41_dma_issue_pending */
> + pm_runtime_mark_last_busy(cdd->ddev.dev);
> + pm_runtime_put_autosuspend(cdd->ddev.dev);
>   }
>   }
>   return IRQ_HANDLED;
> @@ -349,6 +358,12 @@ static dma_cookie_t cppi41_tx_submit(struct 
> dma_async_tx_descriptor *tx)
>  static int cppi41_dma_alloc_chan_resources(struct dma_chan *chan)
>  {
>   struct cppi41_channel *c = to_cpp41_chan(chan);
> + struct cppi41_dd *cdd = c->cdd;
> + int error;
> +
> + error = pm_runtime_get_sync(cdd->ddev.dev);

This will be problematic. The alloc callback are not supposed to sleep, so
we cannot use a _sync() call here :(

This is explicitly documented in Documentation/dmaengine/provider.txt

> + if (error < 0)
> + return error;
>  
>   dma_cookie_init(chan);
>   dma_async_tx_descriptor_init(>txd, chan);
> @@ -357,11 +372,26 @@ static int cppi41_dma_alloc_chan_resources(struct 
> dma_chan *chan)
>   if (!c->is_tx)
>   cppi_writel(c->q_num, c->gcr_reg + RXHPCRA0);
>  
> + pm_runtime_mark_last_busy(cdd->ddev.dev);
> + pm_runtime_put_autosuspend(cdd->ddev.dev);
> +
>   return 0;
>  }
>  
>  static void cppi41_dma_free_chan_resources(struct dma_chan *chan)
>  {
> + struct cppi41_channel *c = to_cpp41_chan(chan);
> + struct cppi41_dd *cdd = c->cdd;
> + int error;
> +
> + error = pm_runtime_get_sync(cdd->ddev.dev);

same applies here too


-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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/3] dmaengine: sun4i: support module autoloading

[Vinod Koul]

On Sun, Feb 21, 2016 at 10:26:35PM -0300, Emilio López wrote:
> From: Emilio López 
> 
> MODULE_DEVICE_TABLE() is missing, so the module isn't auto-loading on
> supported systems. This commit adds the missing line so it loads
> automatically when building it as a module and running on a system
> with the early sunxi DMA engine.

Applied, thanks

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

Re: [PATCHv2] dma: cppi41: add missing bitfields

[Vinod Koul]

On Wed, Apr 08, 2015 at 11:45:42AM -0500, Felipe Balbi wrote:
 Add missing directions, residue_granularity,
 srd_addr_widths and dst_addr_widths bitfields.
 
 Without those we will see a kernel WARN()
 when loading musb on am335x devices.
I have applied this and will send to Linus as well

-- 
~Vinod

 
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
 
 retested with AM335x BeagleBone Black
 
  drivers/dma/cppi41.c | 9 +
  1 file changed, 9 insertions(+)
 
 diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
 index 512cb8e2805e..ceedafbd23e0 100644
 --- a/drivers/dma/cppi41.c
 +++ b/drivers/dma/cppi41.c
 @@ -903,6 +903,11 @@ static const struct cppi_glue_infos 
 *get_glue_info(struct device *dev)
   return of_id-data;
  }
  
 +#define CPPI41_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
 + BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
 + BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
 + BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
 +
  static int cppi41_dma_probe(struct platform_device *pdev)
  {
   struct cppi41_dd *cdd;
 @@ -926,6 +931,10 @@ static int cppi41_dma_probe(struct platform_device *pdev)
   cdd-ddev.device_issue_pending = cppi41_dma_issue_pending;
   cdd-ddev.device_prep_slave_sg = cppi41_dma_prep_slave_sg;
   cdd-ddev.device_terminate_all = cppi41_stop_chan;
 + cdd-ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
 + cdd-ddev.src_addr_widths = CPPI41_DMA_BUSWIDTHS;
 + cdd-ddev.dst_addr_widths = CPPI41_DMA_BUSWIDTHS;
 + cdd-ddev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
   cdd-ddev.dev = dev;
   INIT_LIST_HEAD(cdd-ddev.channels);
   cpp41_dma_info.dma_cap = cdd-ddev.cap_mask;
 -- 
 2.3.0
 

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

Re: [PATCH] dma: cppi41: add missing directions bitfield

[Vinod Koul]

On Wed, Feb 25, 2015 at 04:54:02PM -0600, Felipe Balbi wrote:
 Without those we will see a kernel WARN()
 when loading musb on am335x devices.
 
 Signed-off-by: Felipe Balbi ba...@ti.com
 ---
  drivers/dma/cppi41.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
 index 512cb8e2805e..4e9cc8e8100c 100644
 --- a/drivers/dma/cppi41.c
 +++ b/drivers/dma/cppi41.c
 @@ -926,6 +926,7 @@ static int cppi41_dma_probe(struct platform_device *pdev)
   cdd-ddev.device_issue_pending = cppi41_dma_issue_pending;
   cdd-ddev.device_prep_slave_sg = cppi41_dma_prep_slave_sg;
   cdd-ddev.device_terminate_all = cppi41_stop_chan;
 + cdd-ddev.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
   cdd-ddev.dev = dev;
   INIT_LIST_HEAD(cdd-ddev.channels);
   cpp41_dma_info.dma_cap = cdd-ddev.cap_mask;
Along with this please set src/dstn_addr_widths and residue_granularity
please

-- 
~Vinod

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

Re: [PATCH 00/12] dmaengine: remove users of device_control

[Vinod Koul]

On Sat, Oct 11, 2014 at 09:09:33PM +0530, Vinod Koul wrote:
 The recent discussion [1] on the API have resulted in moving away from
 device_control ioctl method to proper channel APIs.
 There are still few users on the device_control which should use the wrappers
 existing rather than access device_control.
 This will aid us in deprecating and removing device_control, possibly after
 the merge window.
 
 These can be merged thru respective subsystem tree or dmaengine tree. Either
 way please just let me know.

Applying to dmaengine-next with acks recived, dropping the ones which are
applied by respective folks

-- 
~Vinod

 
 Feng's kbuild has tested these as well [2]
 
 [1]: http://www.spinics.net/lists/dmaengine/msg02212.html
 [2]: 
 http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dma_control_cleanup
 
 Vinod Koul (12):
   pata_arasan_cf: use dmaengine_terminate_all() API
   dmaengine: coh901318: use dmaengine_terminate_all() API
   [media] V4L2: mx3_camer: use dmaengine_pause() API
   mtd: fsmc_nand: use dmaengine_terminate_all() API
   mtd: sh_flctl: use dmaengine_terminate_all() API
   net: ks8842: use dmaengine_terminate_all() API
   spi/atmel: use dmaengine_terminate_all() API
   spi/spi-dw-mid.c: use dmaengine_slave_config() API
   serial: sh-sci: use dmaengine_terminate_all() API
   usb: musb: ux500_dma: use dmaengine_xxx() APIs
   ASoC: txx9: use dmaengine_terminate_all() API
   video: mx3fb: use dmaengine_terminate_all() API
 
  drivers/ata/pata_arasan_cf.c   |5 ++---
  drivers/dma/coh901318.c|2 +-
  drivers/media/platform/soc_camera/mx3_camera.c |6 ++
  drivers/mtd/nand/fsmc_nand.c   |2 +-
  drivers/mtd/nand/sh_flctl.c|2 +-
  drivers/net/ethernet/micrel/ks8842.c   |6 ++
  drivers/spi/spi-atmel.c|6 ++
  drivers/spi/spi-dw-mid.c   |6 ++
  drivers/tty/serial/sh-sci.c|2 +-
  drivers/usb/musb/ux500_dma.c   |7 ++-
  drivers/video/fbdev/mx3fb.c|3 +--
  sound/soc/txx9/txx9aclc.c  |7 +++
  12 files changed, 20 insertions(+), 34 deletions(-)
 
 --
 To unsubscribe from this list: send the line unsubscribe dmaengine in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[PATCH 00/12] dmaengine: remove users of device_control

[Vinod Koul]

The recent discussion [1] on the API have resulted in moving away from
device_control ioctl method to proper channel APIs.
There are still few users on the device_control which should use the wrappers
existing rather than access device_control.
This will aid us in deprecating and removing device_control, possibly after
the merge window.

These can be merged thru respective subsystem tree or dmaengine tree. Either
way please just let me know.

Feng's kbuild has tested these as well [2]

[1]: http://www.spinics.net/lists/dmaengine/msg02212.html
[2]: 
http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dma_control_cleanup

Vinod Koul (12):
  pata_arasan_cf: use dmaengine_terminate_all() API
  dmaengine: coh901318: use dmaengine_terminate_all() API
  [media] V4L2: mx3_camer: use dmaengine_pause() API
  mtd: fsmc_nand: use dmaengine_terminate_all() API
  mtd: sh_flctl: use dmaengine_terminate_all() API
  net: ks8842: use dmaengine_terminate_all() API
  spi/atmel: use dmaengine_terminate_all() API
  spi/spi-dw-mid.c: use dmaengine_slave_config() API
  serial: sh-sci: use dmaengine_terminate_all() API
  usb: musb: ux500_dma: use dmaengine_xxx() APIs
  ASoC: txx9: use dmaengine_terminate_all() API
  video: mx3fb: use dmaengine_terminate_all() API

 drivers/ata/pata_arasan_cf.c   |5 ++---
 drivers/dma/coh901318.c|2 +-
 drivers/media/platform/soc_camera/mx3_camera.c |6 ++
 drivers/mtd/nand/fsmc_nand.c   |2 +-
 drivers/mtd/nand/sh_flctl.c|2 +-
 drivers/net/ethernet/micrel/ks8842.c   |6 ++
 drivers/spi/spi-atmel.c|6 ++
 drivers/spi/spi-dw-mid.c   |6 ++
 drivers/tty/serial/sh-sci.c|2 +-
 drivers/usb/musb/ux500_dma.c   |7 ++-
 drivers/video/fbdev/mx3fb.c|3 +--
 sound/soc/txx9/txx9aclc.c  |7 +++
 12 files changed, 20 insertions(+), 34 deletions(-)

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

Re: [PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

[Vinod Koul]

On Wed, Sep 24, 2014 at 10:28:07PM +0200, Rafael J. Wysocki wrote:
 
 OK, I guess this is as good as it gets.
 
 What tree would you like it go through?

Since rest of the patches are dependent upon 1st patch which should go thru
your tree, we should merge this thru your tree

Thanks
-- 
~Vinod

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

[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper

[Vinod Koul]

This patch series adds a simple macro pm_runtime_last_busy_and_autosuspend()
which invokes pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend()
sequentially. Then we do a tree wide update of current patterns which are
present. As evident from log below this pattern is frequent in the
kernel.

This series can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git
topic/pm_runtime_last_busy_and_autosuspend

Fengguang's kbuild has tested it so it shouldn't break things for anyone.
Barring one patch (explictyly mentioned in its changelog) rest are simple
replacements.

If all are okay, this should be merged thru PM tree as it depends on macro
addition.

Subhransu S. Prusty (1):
  PM: Add helper pm_runtime_last_busy_and_autosuspend()

Vinod Koul (26):
  dmaengine: ste_dma: use pm_runtime_last_busy_and_autosuspend helper
  extcon: arizona: use pm_runtime_last_busy_and_autosuspend helper
  drm/i915: use pm_runtime_last_busy_and_autosuspend helper
  drm/nouveau: use pm_runtime_last_busy_and_autosuspend helper
  drm/radeon: use pm_runtime_last_busy_and_autosuspend helper
  vga_switcheroo: use pm_runtime_last_busy_and_autosuspend helper
  i2c: designware: use pm_runtime_last_busy_and_autosuspend helper
  i2c: omap: use pm_runtime_last_busy_and_autosuspend helper
  i2c: qup: use pm_runtime_last_busy_and_autosuspend helper
  mfd: ab8500-gpadc: use pm_runtime_last_busy_and_autosuspend helper
  mfd: arizona: use pm_runtime_last_busy_and_autosuspend helper
  mei: use pm_runtime_last_busy_and_autosuspend helper
  mmc: use pm_runtime_last_busy_and_autosuspend helper
  mmc: mmci: use pm_runtime_last_busy_and_autosuspend helper
  mmc: omap_hsmmc: use pm_runtime_last_busy_and_autosuspend helper
  mmc: sdhci-pxav3: use pm_runtime_last_busy_and_autosuspend helper
  mmc: sdhci: use pm_runtime_last_busy_and_autosuspend helper
  NFC: trf7970a: use pm_runtime_last_busy_and_autosuspend helper
  pm2301-charger: use pm_runtime_last_busy_and_autosuspend helper
  spi: omap2-mcspi: use pm_runtime_last_busy_and_autosuspend helper
  spi: orion: use pm_runtime_last_busy_and_autosuspend helper
  spi: ti-qspi: use pm_runtime_last_busy_and_autosuspend helper
  spi: core: use pm_runtime_last_busy_and_autosuspend helper
  tty: serial: omap: use pm_runtime_last_busy_and_autosuspend helper
  usb: musb: omap2430: use pm_runtime_last_busy_and_autosuspend helper
  video: fbdev: use pm_runtime_last_busy_and_autosuspend helper

 Documentation/power/runtime_pm.txt  |4 ++
 drivers/dma/ste_dma40.c |   30 -
 drivers/extcon/extcon-arizona.c |6 +--
 drivers/gpu/drm/i915/intel_pm.c |3 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c |3 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |9 +---
 drivers/gpu/drm/radeon/radeon_connectors.c  |   15 ++
 drivers/gpu/drm/radeon/radeon_drv.c |5 +-
 drivers/gpu/drm/radeon/radeon_kms.c |6 +--
 drivers/gpu/vga/vga_switcheroo.c|7 +--
 drivers/i2c/busses/i2c-designware-core.c|3 +-
 drivers/i2c/busses/i2c-omap.c   |6 +--
 drivers/i2c/busses/i2c-qup.c|3 +-
 drivers/mfd/ab8500-gpadc.c  |6 +--
 drivers/mfd/arizona-irq.c   |3 +-
 drivers/misc/mei/client.c   |   12 ++
 drivers/mmc/core/core.c |3 +-
 drivers/mmc/host/mmci.c |   12 ++
 drivers/mmc/host/omap_hsmmc.c   |   19 ++---
 drivers/mmc/host/sdhci-pxav3.c  |6 +--
 drivers/mmc/host/sdhci.c|3 +-
 drivers/nfc/trf7970a.c  |3 +-
 drivers/power/pm2301_charger.c  |3 +-
 drivers/spi/spi-omap2-mcspi.c   |9 +---
 drivers/spi/spi-orion.c |3 +-
 drivers/spi/spi-ti-qspi.c   |5 +-
 drivers/spi/spi.c   |6 +--
 drivers/tty/serial/omap-serial.c|   60 +--
 drivers/usb/musb/omap2430.c |6 +--
 drivers/video/fbdev/auo_k190x.c |9 +---
 include/linux/pm_runtime.h  |6 +++
 31 files changed, 97 insertions(+), 177 deletions(-)


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

[PATCH 26/27] usb: musb: omap2430: use pm_runtime_last_busy_and_autosuspend helper

[Vinod Koul]

Use the new pm_runtime_last_busy_and_autosuspend helper instead of open
coding the same code

Signed-off-by: Vinod Koul vinod.k...@intel.com
---
 drivers/usb/musb/omap2430.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index d369bf1..17c6c49 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -293,8 +293,7 @@ static void omap_musb_set_mailbox(struct omap2430_glue 
*glue)
musb-xceiv-last_event = USB_EVENT_NONE;
if (musb-gadget_driver) {
omap2430_musb_set_vbus(musb, 0);
-   pm_runtime_mark_last_busy(dev);
-   pm_runtime_put_autosuspend(dev);
+   pm_runtime_last_busy_and_autosuspend(dev);
}
 
if (data-interface_type == MUSB_INTERFACE_UTMI)
@@ -321,8 +320,7 @@ static void omap_musb_mailbox_work(struct work_struct 
*mailbox_work)
 
pm_runtime_get_sync(dev);
omap_musb_set_mailbox(glue);
-   pm_runtime_mark_last_busy(dev);
-   pm_runtime_put_autosuspend(dev);
+   pm_runtime_last_busy_and_autosuspend(dev);
 }
 
 static irqreturn_t omap2430_musb_interrupt(int irq, void *__hci)
-- 
1.7.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-usb 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 1/7] dma: cppi41: handle 0-length packets

[Vinod Koul]

On Mon, May 26, 2014 at 02:52:34PM +0200, Daniel Mack wrote:
 When a 0-length packet is received on the bus, desc-pd0 yields 1,
 which confuses the driver's users. This information is clearly wrong
 and not in accordance to the datasheet, but it's been observed on an
 AM335x board, very reproducible.
 
 Fix this by looking at bit 19 in PD2 of the completed packet. This bit
 will tell us if a zero-length packet was received on a queue. If it's
 set, ignore the value in PD0 and report a total length of 0 instead.

Applied this one, Thanks

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-usb 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 1/7] dma: cppi41: handle 0-length packets

[Vinod Koul]

On Mon, Jun 30, 2014 at 09:40:06PM +0200, Daniel Mack wrote:
 On 06/30/2014 09:31 PM, Felipe Balbi wrote:
  On Mon, Jun 30, 2014 at 09:29:10PM +0200, Daniel Mack wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  On 06/30/2014 09:26 PM, Felipe Balbi wrote:
  On Mon, Jun 30, 2014 at 09:19:08PM +0200, Daniel Mack wrote:
 
  I also asked Vinod to pick this single patch for his tree, but
  there was no answer yet.
 
  cool. hopefully we can get a better v3.17.
 
  Ultimately it's your decision of course, but I really think the
  patches sould make it for v3.16, as they fix real bugs.
  
  only patchs 4 and 6 seem to be -rc material. Will it work if I apply
  only those during this -rc ?
  
 
 Hmm, I'd say #3 and #5 are -rc material, too.
 
 #3 fixes a reproducible kernel crash when unplugging streaming audio
 devices, and #5 causes data stream starvation which makes using many
 Wifi adapters with musb impossible,
 
 #1 should better go through Vinod's tree, and #2 and #7 are just
 cosmetic things.
Sorry been bit busy, I will pick this one and queue it for fixes.

And yes, rest would make sense to go thru usb tree

-- 
~Vinod

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

Re: [PATCH 0/2] Fix CPPI Warnings during tear down after ISOCH transfers

[Vinod Koul]

On Thu, Feb 27, 2014 at 10:44:39AM +0530, George Cherian wrote:
 Warinings are seen after  ISOCH transfers, during channel tear down.
 This is mainly beacause we handle ISOCH differently as compared to 
 other transfers. 
 
 Patch 1: make sure we do channel tear down only if channel is busy.
If not the tear down will never succeed.
 
 Patch 2: ISOCH completions are done differently, so this might lead to 
   reprogram of dma channel on which already a teardown is done.
Applied, Thanks

-- 
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-usb 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 5/5] dma: cppi41: add support for suspend and resume

[Vinod Koul]

On Mon, Sep 23, 2013 at 07:53:11AM +0200, Daniel Mack wrote:
 On 23.09.2013 06:09, Vinod Koul wrote:
  On Sun, Sep 22, 2013 at 04:50:04PM +0200, Daniel Mack wrote:
 
  +#ifdef CONFIG_PM_SLEEP
  a
  
  +static int cppi41_suspend(struct device *dev)
  +{
  +  struct cppi41_dd *cdd = dev_get_drvdata(dev);
  +
  +  cppi_writel(0, cdd-usbss_mem + USBSS_IRQ_CLEARR);
  +  disable_sched(cdd);
  +
  +  return 0;
  +}
  +
  +static int cppi41_resume(struct device *dev)
  +{
  +  struct cppi41_dd *cdd = dev_get_drvdata(dev);
  +  int i;
  +
  +  for (i = 0; i  DESCS_AREAS; i++)
  +  cppi_writel(cdd-descs_phys, cdd-qmgr_mem + QMGR_MEMBASE(i));
  +
  +  init_sched(cdd);
  +  cppi_writel(USBSS_IRQ_PD_COMP, cdd-usbss_mem + USBSS_IRQ_ENABLER);
  +
  +  return 0;
  +}
  +#endif
  +
  +static SIMPLE_DEV_PM_OPS(cppi41_pm_ops, cppi41_suspend, cppi41_resume);
  Here is the macro in pm.h
 
 [...]
 
  Now since you are using the macro there should be no need to wrap ifdef 
  around
  your code, the macro will take care of it.
 
 Well yes, which is why I put the macro itself *outside* of the #ifdef
 block. Without that #ifdef, however, and with CONFIG_PM_SLEEP unset, I get:
 
 drivers/dma/cppi41.c:1043:12: warning: ‘cppi41_suspend’ defined but not
 used [-Wunused-function]
  static int cppi41_suspend(struct device *dev)
 ^
 drivers/dma/cppi41.c:1053:12: warning: ‘cppi41_resume’ defined but not
 used [-Wunused-function]
  static int cppi41_resume(struct device *dev)
 ^
 
 ... which doesn't surprise me much. Or do I still not get your point?
And this is what i had expected... I was thinking we should ignore this, but
this is better too, so I will try to apply this now

~Vinod

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-usb 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 5/5] dma: cppi41: add support for suspend and resume

[Vinod Koul]

On Sun, Sep 22, 2013 at 04:50:04PM +0200, Daniel Mack wrote:
 This patch adds support for suspend/resume functionality to the cppi41
 DMA driver. The steps necessary to make the system resume properly were
 figured out by trial-and-error. The code as it stands now is the
 minimum that has to be done to put the musb host system on an AM33xx
 system into an operable state after resume.
Applied, thanks

~Vinod
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/dma/cppi41.c | 29 +
  1 file changed, 29 insertions(+)
 
 diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
 index 3347321..89decc9 100644
 --- a/drivers/dma/cppi41.c
 +++ b/drivers/dma/cppi41.c
 @@ -1040,12 +1040,41 @@ static int cppi41_dma_remove(struct platform_device 
 *pdev)
   return 0;
  }
  
 +#ifdef CONFIG_PM_SLEEP
 +static int cppi41_suspend(struct device *dev)
 +{
 + struct cppi41_dd *cdd = dev_get_drvdata(dev);
 +
 + cppi_writel(0, cdd-usbss_mem + USBSS_IRQ_CLEARR);
 + disable_sched(cdd);
 +
 + return 0;
 +}
 +
 +static int cppi41_resume(struct device *dev)
 +{
 + struct cppi41_dd *cdd = dev_get_drvdata(dev);
 + int i;
 +
 + for (i = 0; i  DESCS_AREAS; i++)
 + cppi_writel(cdd-descs_phys, cdd-qmgr_mem + QMGR_MEMBASE(i));
 +
 + init_sched(cdd);
 + cppi_writel(USBSS_IRQ_PD_COMP, cdd-usbss_mem + USBSS_IRQ_ENABLER);
 +
 + return 0;
 +}
 +#endif
 +
 +static SIMPLE_DEV_PM_OPS(cppi41_pm_ops, cppi41_suspend, cppi41_resume);
 +
  static struct platform_driver cpp41_dma_driver = {
   .probe  = cppi41_dma_probe,
   .remove = cppi41_dma_remove,
   .driver = {
   .name = cppi41-dma-engine,
   .owner = THIS_MODULE,
 + .pm = cppi41_pm_ops,
   .of_match_table = of_match_ptr(cppi41_dma_ids),
   },
  };
 -- 
 1.8.3.1
 

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

Re: [alsa-devel] [PATCH 23/51] DMA-API: dma: pl08x: add dma_set_mask_and_coherent() call

[Vinod Koul]

On Thu, Sep 19, 2013 at 10:48:01PM +0100, Russell King wrote:
 The DMA API requires drivers to call the appropriate dma_set_mask()
 functions before doing any DMA mapping.  Add this required call to
 the AMBA PL08x driver.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Vinod Koul vinod.k...@intel.com

~Vinod
 ---
  drivers/dma/amba-pl08x.c |5 +
  1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
 index fce46c5..e51a983 100644
 --- a/drivers/dma/amba-pl08x.c
 +++ b/drivers/dma/amba-pl08x.c
 @@ -2055,6 +2055,11 @@ static int pl08x_probe(struct amba_device *adev, const 
 struct amba_id *id)
   if (ret)
   return ret;
  
 + /* Ensure that we can do DMA */
 + ret = dma_set_mask_and_coherent(adev-dev, DMA_BIT_MASK(32));
 + if (ret)
 + goto out_no_pl08x;
 +
   /* Create the driver state holder */
   pl08x = kzalloc(sizeof(*pl08x), GFP_KERNEL);
   if (!pl08x) {
 -- 
 1.7.4.4
 
 ___
 Alsa-devel mailing list
 alsa-de...@alsa-project.org
 http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

Re: [alsa-devel] [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks

[Vinod Koul]

On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
 register_platform_device_full() can setup the DMA mask provided the
 appropriate member is set in struct platform_device_info.  So lets
 make that be the case.  This avoids a direct reference to the DMA
 masks by this driver.
 
 Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Vinod Koul vinod.k...@intel.com

This also brings me question that should we force the driver to use the
dma_set_mask_and_coherent() API or they have below flexiblity too?

~Vinod

 ---
  drivers/dma/edma.c |6 ++
  1 files changed, 2 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index ff50ff4..7f9fe30 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -702,11 +702,13 @@ static struct platform_device *pdev0, *pdev1;
  static const struct platform_device_info edma_dev_info0 = {
   .name = edma-dma-engine,
   .id = 0,
 + .dma_mask = DMA_BIT_MASK(32),
  };
  
  static const struct platform_device_info edma_dev_info1 = {
   .name = edma-dma-engine,
   .id = 1,
 + .dma_mask = DMA_BIT_MASK(32),
  };


  
  static int edma_init(void)
 @@ -720,8 +722,6 @@ static int edma_init(void)
   ret = PTR_ERR(pdev0);
   goto out;
   }
 - pdev0-dev.dma_mask = pdev0-dev.coherent_dma_mask;
 - pdev0-dev.coherent_dma_mask = DMA_BIT_MASK(32);
   }
  
   if (EDMA_CTLRS == 2) {
 @@ -731,8 +731,6 @@ static int edma_init(void)
   platform_device_unregister(pdev0);
   ret = PTR_ERR(pdev1);
   }
 - pdev1-dev.dma_mask = pdev1-dev.coherent_dma_mask;
 - pdev1-dev.coherent_dma_mask = DMA_BIT_MASK(32);
   }
  
  out:
 -- 
 1.7.4.4
 
 ___
 Alsa-devel mailing list
 alsa-de...@alsa-project.org
 http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

Re: [alsa-devel] [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call

[Vinod Koul]

On Sat, Sep 21, 2013 at 09:00:00PM +0100, Russell King - ARM Linux wrote:
 On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
  Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
   The DMA API requires drivers to call the appropriate dma_set_mask()
   functions before doing any DMA mapping.  Add this required call to
   the AMBA PL08x driver.
  ^--- copy and paste error - should of course be PL330
 
 Fixed, thanks.
with fixed changelog...

Acked-by: Vinod Koul vinod.k...@intel.com

~Vinod

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-usb 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 5/5] dma: cppi41: add support for suspend and resume

[Vinod Koul]

On Sun, Sep 22, 2013 at 04:50:04PM +0200, Daniel Mack wrote:
 This patch adds support for suspend/resume functionality to the cppi41
 DMA driver. The steps necessary to make the system resume properly were
 figured out by trial-and-error. The code as it stands now is the
 minimum that has to be done to put the musb host system on an AM33xx
 system into an operable state after resume.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
 ---
  drivers/dma/cppi41.c | 29 +
  1 file changed, 29 insertions(+)
 
 diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
 index 3347321..89decc9 100644
 --- a/drivers/dma/cppi41.c
 +++ b/drivers/dma/cppi41.c
 @@ -1040,12 +1040,41 @@ static int cppi41_dma_remove(struct platform_device 
 *pdev)
   return 0;
  }
  
 +#ifdef CONFIG_PM_SLEEP
a

 +static int cppi41_suspend(struct device *dev)
 +{
 + struct cppi41_dd *cdd = dev_get_drvdata(dev);
 +
 + cppi_writel(0, cdd-usbss_mem + USBSS_IRQ_CLEARR);
 + disable_sched(cdd);
 +
 + return 0;
 +}
 +
 +static int cppi41_resume(struct device *dev)
 +{
 + struct cppi41_dd *cdd = dev_get_drvdata(dev);
 + int i;
 +
 + for (i = 0; i  DESCS_AREAS; i++)
 + cppi_writel(cdd-descs_phys, cdd-qmgr_mem + QMGR_MEMBASE(i));
 +
 + init_sched(cdd);
 + cppi_writel(USBSS_IRQ_PD_COMP, cdd-usbss_mem + USBSS_IRQ_ENABLER);
 +
 + return 0;
 +}
 +#endif
 +
 +static SIMPLE_DEV_PM_OPS(cppi41_pm_ops, cppi41_suspend, cppi41_resume);
Here is the macro in pm.h

#ifdef CONFIG_PM_SLEEP
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \
.suspend = suspend_fn, \
.resume = resume_fn, \
.freeze = suspend_fn, \
.thaw = resume_fn, \
.poweroff = suspend_fn, \
.restore = resume_fn,
#else
#define SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn)
#endif

/*
 * Use this if you want to use the same suspend and resume callbacks for suspend
 * to RAM and hibernation.
 */
#define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
const struct dev_pm_ops name = { \
SET_SYSTEM_SLEEP_PM_OPS(suspend_fn, resume_fn) \

Now since you are using the macro there should be no need to wrap ifdef around
your code, the macro will take care of it. 

~Vinod

 +
  static struct platform_driver cpp41_dma_driver = {
   .probe  = cppi41_dma_probe,
   .remove = cppi41_dma_remove,
   .driver = {
   .name = cppi41-dma-engine,
   .owner = THIS_MODULE,
 + .pm = cppi41_pm_ops,
   .of_match_table = of_match_ptr(cppi41_dma_ids),
   },
  };
 -- 
 1.8.3.1
 

-- 
--
To unsubscribe from this list: send the line unsubscribe linux-usb 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 2/5] dma: cppi41: s/deinit_cpii41/deinit_cppi41/

[Vinod Koul]

On Sun, Sep 22, 2013 at 04:50:01PM +0200, Daniel Mack wrote:
 Fix a misspelled function name.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
Applied, thanks

~Vinod
-- 
--
To unsubscribe from this list: send the line unsubscribe linux-usb 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 1/5] dma: cppi41: pass around device instead of platform_device

[Vinod Koul]

On Sun, Sep 22, 2013 at 04:50:00PM +0200, Daniel Mack wrote:
 Instead of passing around struct plafform_device, use struct device and
 save one level of dereferencing. This affects the following functions:
 
  * cppi41_add_chans
  * purge_descs
  * deinit_cpii41
  * init_descs
  * init_cppi41
  * cppi_glue_infos
 
 It's just a cosmetic cleanup that makes the code more readable.
Applied, thanks

~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-usb 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 3/5] dma: cppi41: add shortcut to pdev-dev in cppi41_dma_probe()

[Vinod Koul]

On Sun, Sep 22, 2013 at 04:50:02PM +0200, Daniel Mack wrote:
 Makes the code more readable and compact. No functional change.
 
 Signed-off-by: Daniel Mack zon...@gmail.com
Applied, thanks

~Vinod
-- 
--
To unsubscribe from this list: send the line unsubscribe linux-usb 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

[Vinod Koul]

On Sun, Sep 22, 2013 at 04:50:03PM +0200, Daniel Mack wrote:
 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).

Looks fine, Sebastian cna you test it pls

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

Re: [PATCH 11/11] dma: cpp41: enable pm_runtime during init

[Vinod Koul]

On Tue, Aug 20, 2013 at 06:35:53PM +0200, Sebastian Andrzej Siewior wrote:
 With enabled pm_runtime in the kernel the device won't work because it
 is not on during the probe function. This patch enables the device via
 pm_runtime on probe so it remains activated.
 
 Cc: Vinod Koul vinod.k...@intel.com
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Acked-by Vinod Koul vinod.k...@intel.com

~Vinod
 ---
  drivers/dma/cppi41.c | 11 +++
  1 file changed, 11 insertions(+)
 
 diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
 index e696178..6c4e64f 100644
 --- a/drivers/dma/cppi41.c
 +++ b/drivers/dma/cppi41.c
 @@ -9,6 +9,7 @@
  #include linux/dmapool.h
  #include linux/interrupt.h
  #include linux/of_address.h
 +#include linux/pm_runtime.h
  #include dmaengine.h
  
  #define DESC_TYPE27
 @@ -960,6 +961,11 @@ static int cppi41_dma_probe(struct platform_device *pdev)
   goto err_remap;
   }
  
 + pm_runtime_enable(pdev-dev);
 + ret = pm_runtime_get_sync(pdev-dev);
 + if (ret)
 + goto err_get_sync;
 +
   cdd-queues_rx = glue_info-queues_rx;
   cdd-queues_tx = glue_info-queues_tx;
   cdd-td_queue = glue_info-td_queue;
 @@ -1005,6 +1011,9 @@ static int cppi41_dma_probe(struct platform_device 
 *pdev)
  err_chans:
   deinit_cpii41(pdev, cdd);
  err_init_cppi:
 + pm_runtime_put(pdev-dev);
 +err_get_sync:
 + pm_runtime_disable(pdev-dev);
   iounmap(cdd-usbss_mem);
   iounmap(cdd-ctrl_mem);
   iounmap(cdd-sched_mem);
 @@ -1029,6 +1038,8 @@ static int cppi41_dma_remove(struct platform_device 
 *pdev)
   iounmap(cdd-ctrl_mem);
   iounmap(cdd-sched_mem);
   iounmap(cdd-qmgr_mem);
 + pm_runtime_put(pdev-dev);
 + pm_runtime_disable(pdev-dev);
   kfree(cdd);
   return 0;
  }
 -- 
 1.8.4.rc2
 

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

Re: [PATCH] dma: cpp41: make it compile with CONFIG_BUG=n

[Vinod Koul]

On Fri, Aug 16, 2013 at 05:40:55PM +0200, Sebastian Andrzej Siewior wrote:
 From: Sebastian Andrzej Siewior bige...@linutronix.de
 
 Before Randy figures out that this does not compile with CONFIG_BUG=n
 here is a fix for it.
 
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Acked-by: Vinod Koul vinod.k...@intel.com

~Vinod
 ---
  drivers/dma/cppi41.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
 index 5dcebca..e696178 100644
 --- a/drivers/dma/cppi41.c
 +++ b/drivers/dma/cppi41.c
 @@ -579,7 +579,7 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
   WARN_ON(!c-is_tx  !(pd0  TD_DESC_IS_RX));
   WARN_ON((pd0  0x1f) != c-port_num);
   } else {
 - __WARN();
 + WARN_ON_ONCE(1);
   }
   c-td_seen = 1;
   }
 -- 
 1.8.4.rc2
 

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

Re: [PATCH 15/16] dmaengine: add transfered member to dma_async_tx_descriptor

[Vinod Koul]

On Mon, Jul 22, 2013 at 08:10:06PM +0200, Sebastian Andrzej Siewior wrote:
 In USB RX path it is possible that the we receive less bytes than
 requested. Take the following example:
 The driver for USB-to-UART submits an URB with 256 bytes in size and the
 dmaengine driver in turn programs a transfer of 256 bytes. The transfer
 is programmed and the dma engine waits for the data to arrive. Once data
 is sent on the UART the dma engine begins to move data. If there was
 only one data byte in the USB packet received then the DMA engine will
 only move one byte due to USB restrictions / rules. The real size of the
 transfer has to be notified to the user / caller so he set this to the
 caller.
 This patch adds the transfered member to the dma_async_tx_descriptor
 where the caller can obtain the final size.
 
 Cc: Vinod Koul vinod.k...@intel.com
 Cc: Dan Williams d...@fb.com
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
  include/linux/dmaengine.h | 3 +++
  1 file changed, 3 insertions(+)
 
 diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
 index cb286b1..c3a4635 100644
 --- a/include/linux/dmaengine.h
 +++ b/include/linux/dmaengine.h
 @@ -403,6 +403,8 @@ typedef void (*dma_async_tx_callback)(void 
 *dma_async_param);
   * @tx_submit: set the prepared descriptor(s) to be executed by the engine
   * @callback: routine to call after this operation is complete
   * @callback_param: general parameter to pass to the callback routine
 + * @transfered: number of bytes that were really transfered in case the 
 channel
 + *   transfered less than requested.
   * ---async_tx api specific fields---
   * @next: at completion submit this descriptor
   * @parent: pointer to the next level up in the dependency chain
 @@ -416,6 +418,7 @@ struct dma_async_tx_descriptor {
   dma_cookie_t (*tx_submit)(struct dma_async_tx_descriptor *tx);
   dma_async_tx_callback callback;
   void *callback_param;
 + unsigned int transfered;
I think this should be doable with residue as well. You can return DMA_SUCCESS
for status and fill in what is NOT transfered indicating that txn completed but
lesser number of bytes are valid

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

Re: [RFC] ux500 dma short transfers on MUSB

[Vinod Koul]

On Thu, Jul 18, 2013 at 01:21:55PM +0200, Sebastian Andrzej Siewior wrote:
 On 07/11/2013 07:14 PM, Sebastian Andrzej Siewior wrote:
 
 Dan, Vinod,
 
 do you guys have an idea how the dma driver could inform its user how
 much of the requested data got really transferred? This requirement
 seems unique to USB where this happens and is not an error. Below an
 reply to Greg where I tried to explain the problem. The original thread
 started at [0].
 I've been browsing by some drivers and did not find anything close to
 this. The UART drivers which use DMA seem to know the exact number of
 bytes in advance. The dmaengine_tx_status() seems to serve a different
 purpose.
Please look into the residue field

/**
 * struct dma_tx_state - filled in to report the status of
 * a transfer.
 * @last: last completed DMA cookie
 * @used: last issued DMA cookie (i.e. the one in progress)
 * @residue: the remaining number of bytes left to transmit
 *  on the selected transfer for states DMA_IN_PROGRESS and
 *  DMA_PAUSED if this is implemented in the driver, else 0
 */
struct dma_tx_state {
dma_cookie_t last;
dma_cookie_t used;
u32 residue;
};

Typically this is set to 0 when DMA_SUCCESS is returned for the
dmaengine_tx_status() API. But in your case I feel its perfectly valid to return
DMA_SUCCESS but with a non zero residue indiactaing how much was not transmitted

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

Re: MUSB multiplatform work?

[Vinod Koul]

On Wed, Jun 12, 2013 at 05:27:53PM +0530, Jassi Brar wrote:
 IIRC,  TI's Sundaram Raju proposed a TI specific api to DMAEngine for
 this very purpose, which was generalized into
 device_prep_interleaved_dma().  Which I think should already be enough
 to serve the purpose. Is it not?
The interleaved for having to get/set data from interleaved or an 2d array.
Think of a raw image from camera where you need to get some region only and skip
rest. In those case interleaved API helps

Here this is just normal slave DMA with changing FIFO address and which just
loops over the FIFO value

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

Re: MUSB multiplatform work?

[Vinod Koul]

On Thu, May 30, 2013 at 11:19:33PM +0200, Linus Walleij wrote:
 On Thu, May 30, 2013 at 10:31 PM, Tony Lindgren t...@atomide.com wrote:
 
  There are many devices where the device FIFO is memory mapped to the
  GPMC bus on omaps, like TUSB, OneNAND, smc911x etc. I believe the
  only reason why these have not been converted to the dmaengine is
  the fact that dmaengine cannot configure the DMA hardware to do
  autoincrement and loop over the device FIFO.
 
 OK that seems like something pretty generic that we could just add
 to the struct dma_slave_config actually, something like:
 
 u32 src_fifoloop;
 u32 dst_fifoloop;
Yes for genric but not for loop. For most of our cases we are considering the
FIFO address as a constant. Typically DMA controllers have this ability to
perform incremental/decremental/constant FIFO address.

What would make sense to have is:

enum dmaengine_slave_addr_mode {
DMAENGINE_SLAVE_ADDR_CONSTANT = 0,
DMAENGINE_SLAVE_ADDR_INCREMANT,
DMAENGINE_SLAVE_ADDR_DECREMENT,
};

and add these to struct dma_slave_config:
enum dmaengine_slave_addr_mode src_mode;
enum dmaengine_slave_addr_mode dstn_mode;

For loopover we can have:
u32 loop_counter;

on 0 means no loop, and valid value tells when to loopover (offset).

will this help for all of the above controllers and their conversion?
 
 Given in # of words on the src/dst address simply, left as zero
 for hitting a constant address over and over again.
 
 We'd need both to make space for device-device transfers.
 
 If this is all that is needed to convert them do DMAengine
 I'd surely ACK it (FWIW).

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

Re: [PATCH 35/39] dmaengine: ste_dma40_ll: Replace meaningless register set with comment

[Vinod Koul]

On Thu, May 30, 2013 at 11:04:23AM +0200, Linus Walleij wrote:
 On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote:
 
  Unsure of the author's intentions, rather than just removing the nop,
  we're replacing it with a comment containing the possible intention
  of the statement OR:ing with 0.
 
  Cc: Vinod Koul vinod.k...@intel.com
  Cc: Dan Williams d...@fb.com
  Cc: Per Forlin per.for...@stericsson.com
  Cc: Rabin Vincent ra...@rab.in
  Signed-off-by: Lee Jones lee.jo...@linaro.org
 
 Tentatively applied. Missing Vinod's ACK.
Acked-by: Vinod Koul vinod.k...@intel.com

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

Re: [PATCH 39/39] dmaengine: ste_dma40: Fetch disabled channels from DT

[Vinod Koul]

On Wed, May 15, 2013 at 10:52:02AM +0100, Lee Jones wrote:
 Some platforms have channels which are not available for normal use.
 This information is currently passed though platform data in internal
 BSP kernels. Once those platforms land, they'll need to configure them
 appropriately, so we may as well add the infrastructure.
 
 Cc: Vinod Koul vinod.k...@intel.com
 Cc: Dan Williams d...@fb.com
 Cc: Per Forlin per.for...@stericsson.com
 Cc: Rabin Vincent ra...@rab.in
 Acked-by: Arnd Bergmann a...@arndb.de
 Signed-off-by: Lee Jones lee.jo...@linaro.org
Acked-by: Vinod Koul vinod.k...@intel.com

 ---
  Documentation/devicetree/bindings/dma/ste-dma40.txt |2 ++
  drivers/dma/ste_dma40.c |   17 -
  2 files changed, 18 insertions(+), 1 deletion(-)
 
 diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt 
 b/Documentation/devicetree/bindings/dma/ste-dma40.txt
 index aa272d8..bea5b73 100644
 --- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
 +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
 @@ -11,6 +11,7 @@ Required properties:
  Optional properties:
  - dma-channels: Number of channels supported by hardware - if not present
   the driver will attempt to obtain the information from H/W
 +- disabled-channels: Channels which can not be used
  
  Example:
  
 @@ -23,6 +24,7 @@ Example:
  
   #dma-cells = 2;
   memcpy-channels  = 56 57 58 59 60;
 + disabled-channels  = 12;
   dma-channels = 8;
   };
  
 diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
 index 4e528dd..ffac822 100644
 --- a/drivers/dma/ste_dma40.c
 +++ b/drivers/dma/ste_dma40.c
 @@ -3482,7 +3482,7 @@ static int __init d40_of_probe(struct platform_device 
 *pdev,
  struct device_node *np)
  {
   struct stedma40_platform_data *pdata;
 - int num_phy = 0, num_memcpy = 0;
 + int num_phy = 0, num_memcpy = 0, num_disabled = 0;
   const const __be32 *list;
  
   pdata = devm_kzalloc(pdev-dev,
 @@ -3511,6 +3511,21 @@ static int __init d40_of_probe(struct platform_device 
 *pdev,
  dma40_memcpy_channels,
  num_memcpy);
  
 + list = of_get_property(np, disabled-channels, num_disabled);
 + num_disabled /= sizeof(*list);
 +
 + if (num_disabled  STEDMA40_MAX_PHYS || num_disabled  0) {
 + d40_err(pdev-dev,
 + Invalid number of disabled channels specified (%d)\n,
 + num_disabled);
 + return -EINVAL;
 + }
 +
 + of_property_read_u32_array(np, disabled-channels,
 +pdata-disabled_channels,
 +num_disabled);
 + pdata-disabled_channels[num_disabled] = -1;
 +
   pdev-dev.platform_data = pdata;
  
   return 0;
 -- 
 1.7.10.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 34/39] dmaengine: ste_dma40: Convert data_width from register bit format to value

[Vinod Koul]

On Wed, May 15, 2013 at 10:51:57AM +0100, Lee Jones wrote:
 When a DMA client requests and configures a DMA channel, it requests
 data_width in Bytes. The DMA40 driver then swiftly converts it over to
 the necessary register bit value. Unfortunately, for any subsequent
 calculations we have to shift '1' by the bit pattern (1  data_width)
 times to make any sense of it.
 
 This patch flips the semantics on its head and only converts the value
 to its respective register bit pattern when writing to registers. This
 way we can use the true data_width (in Bytes) value.
 
 Cc: Vinod Koul vinod.k...@intel.com
 Cc: Dan Williams d...@fb.com
 Cc: Per Forlin per.for...@stericsson.com
 Cc: Rabin Vincent ra...@rab.in
 Signed-off-by: Lee Jones lee.jo...@linaro.org
 ---
  
 @@ -2804,14 +2781,24 @@ static int d40_set_runtime_config(struct dma_chan 
 *chan,
   src_maxburst = dst_maxburst * dst_addr_width / src_addr_width;
   }
  
 + /* Only valid widths are; 1, 2, 4 and 8. */
 + if (src_addr_width = DMA_SLAVE_BUSWIDTH_UNDEFINED ||
 + src_addr_width   DMA_SLAVE_BUSWIDTH_8_BYTES   ||
 + dst_addr_width = DMA_SLAVE_BUSWIDTH_UNDEFINED ||
 + dst_addr_width   DMA_SLAVE_BUSWIDTH_8_BYTES   ||
 + ((src_addr_width  1)  (src_addr_width  1)) ||
 + ((dst_addr_width  1)  (dst_addr_width  1)))
 + return -EINVAL;
how about a simple macro to check above..

 +
 + cfg-src_info.data_width = src_addr_width;
 + cfg-dst_info.data_width = dst_addr_width;
 +
   ret = dma40_config_to_halfchannel(d40c, cfg-src_info,
 -   src_addr_width,
 src_maxburst);
   if (ret)
   return ret;
  
   ret = dma40_config_to_halfchannel(d40c, cfg-dst_info,
 -   dst_addr_width,
 dst_maxburst);
   if (ret)
   return ret;
 diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
 index 5ddd724..a035dfe 100644
 --- a/drivers/dma/ste_dma40_ll.c
 +++ b/drivers/dma/ste_dma40_ll.c
 @@ -10,6 +10,18 @@
  
  #include ste_dma40_ll.h
  
 +u8 d40_width_to_bits(enum dma_slave_buswidth width)
 +{
 + if (width == DMA_SLAVE_BUSWIDTH_1_BYTE)
 + return STEDMA40_ESIZE_8_BIT;
 + else if (width == DMA_SLAVE_BUSWIDTH_2_BYTES)
 + return STEDMA40_ESIZE_16_BIT;
 + else if (width == DMA_SLAVE_BUSWIDTH_8_BYTES)
 + return STEDMA40_ESIZE_64_BIT;
 + else
 + return STEDMA40_ESIZE_32_BIT;
 +}
 +
Switch looks better for this and how about
return fls(width);

as your defines are 0...3 and dmaengine define 1,2,..8 for same thing
then you can also get rid of STEDMA40_XXX_WIDTH macros!


 @@ -70,13 +70,6 @@ enum stedma40_flow_ctrl {
   STEDMA40_FLOW_CTRL,
  };
  
 -enum stedma40_periph_data_width {
 - STEDMA40_BYTE_WIDTH = STEDMA40_ESIZE_8_BIT,
 - STEDMA40_HALFWORD_WIDTH = STEDMA40_ESIZE_16_BIT,
 - STEDMA40_WORD_WIDTH = STEDMA40_ESIZE_32_BIT,
 - STEDMA40_DOUBLEWORD_WIDTH = STEDMA40_ESIZE_64_BIT
 -};
nice

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

Re: [PATCH 38/39] dmaengine: ste_dma40: Fetch the number of physical channels from DT

[Vinod Koul]

On Wed, May 15, 2013 at 10:52:01AM +0100, Lee Jones wrote:
 Some platforms insist on obscure physical channel availability. This
 information is currently passed though platform data in internal BSP
 kernels. Once those platforms land, they'll need to configure them
 appropriately, so we may as well add the infrastructure.
 
 Cc: Vinod Koul vinod.k...@intel.com
 Cc: Dan Williams d...@fb.com
 Cc: Per Forlin per.for...@stericsson.com
 Cc: Rabin Vincent ra...@rab.in
 Signed-off-by: Lee Jones lee.jo...@linaro.org
 ---
Acked-by: Vinod Koul vinod.k...@intel.com

  drivers/dma/ste_dma40.c |7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
 index ae462d3..4e528dd 100644
 --- a/drivers/dma/ste_dma40.c
 +++ b/drivers/dma/ste_dma40.c
 @@ -3482,7 +3482,7 @@ static int __init d40_of_probe(struct platform_device 
 *pdev,
  struct device_node *np)
  {
   struct stedma40_platform_data *pdata;
 - int num_memcpy = 0;
 + int num_phy = 0, num_memcpy = 0;
   const const __be32 *list;
  
   pdata = devm_kzalloc(pdev-dev,
 @@ -3491,6 +3491,11 @@ static int __init d40_of_probe(struct platform_device 
 *pdev,
   if (!pdata)
   return -ENOMEM;
  
 + /* If absent this value will be obtained from h/w. */
 + of_property_read_u32(np, dma-channels, num_phy);
 + if (num_phy  0)
 + pdata-num_of_phy_chans = num_phy;
 +
   list = of_get_property(np, memcpy-channels, num_memcpy);
   num_memcpy /= sizeof(*list);
  
 -- 
 1.7.10.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/39] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking

[Vinod Koul]

On Wed, May 15, 2013 at 06:29:51PM +0200, Linus Walleij wrote:
 On Wed, May 15, 2013 at 11:51 AM, Lee Jones lee.jo...@linaro.org wrote:
 
  During the initial setup of a logical channel, it is necessary to unmask
  the GIM in order to receive generated terminal count and error interrupts.
  We're separating out this required code so it will be possible to move
  the remaining code in d40_phy_cfg(), which is mostly runtime configuration
  into the runtime_config() routine.
 
  Cc: Vinod Koul vinod.k...@intel.com
  Cc: Dan Williams d...@fb.com
  Cc: Per Forlin per.for...@stericsson.com
  Cc: Rabin Vincent ra...@rab.in
  Acked-by: Arnd Bergmann a...@arndb.de
  Signed-off-by: Lee Jones lee.jo...@linaro.org
 
 Tentatively applied to my ux500-dma40 branch.
 
 This lacks an ACK from Vinod...
Acked-by: Vinod Koul vinod.k...@intel.com
 
 I cannot get any of this stack of patches up to ARM SoC
 before I have Vinod's ACK on all hitting drivers/dma/*
Wip ... :)

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

Re: [PATCH 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()

[Vinod Koul]

On Wed, May 15, 2013 at 10:51:25AM +0100, Lee Jones wrote:
 All configuration left in d40_phy_cfg() is runtime configurable and
 there is already a call into it from d40_runtime_config(), so let's
 rely on that.
 
 Acked-by: Vinod Koul vnod.k...@intel.com
That needs up update!

 Acked-by: Arnd Bergmann a...@arndb.de
 Signed-off-by: Lee Jones lee.jo...@linaro.org
 ---
  drivers/dma/ste_dma40.c|   14 +++---
  drivers/dma/ste_dma40_ll.c |  101 
 +---
  drivers/dma/ste_dma40_ll.h |3 +-
  3 files changed, 58 insertions(+), 60 deletions(-)
 
 diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
 index 759293e..b7fe46b 100644
 --- a/drivers/dma/ste_dma40.c
 +++ b/drivers/dma/ste_dma40.c
 @@ -2043,6 +2043,14 @@ static int d40_config_memcpy(struct d40_chan *d40c)
   } else if (dma_has_cap(DMA_MEMCPY, cap) 
  dma_has_cap(DMA_SLAVE, cap)) {
   d40c-dma_cfg = dma40_memcpy_conf_phy;
 +
 + /* Generate interrrupt at end of transfer or relink. */
 + d40c-dst_def_cfg |= BIT(D40_SREG_CFG_TIM_POS);
 +
 + /* Generate interrupt on error. */
 + d40c-src_def_cfg |= BIT(D40_SREG_CFG_EIM_POS);
 + d40c-dst_def_cfg |= BIT(D40_SREG_CFG_EIM_POS);
 +
   } else {
   chan_err(d40c, No memcpy\n);
   return -EINVAL;
 @@ -2496,9 +2504,6 @@ static int d40_alloc_chan_resources(struct dma_chan 
 *chan)
   }
  
   pm_runtime_get_sync(d40c-base-dev);
 - /* Fill in basic CFG register values */
 - d40_phy_cfg(d40c-dma_cfg, d40c-src_def_cfg,
 - d40c-dst_def_cfg, chan_is_logical(d40c));
  
   d40_set_prio_realtime(d40c);
  
 @@ -2862,8 +2867,7 @@ static int d40_set_runtime_config(struct dma_chan *chan,
   if (chan_is_logical(d40c))
   d40_log_cfg(cfg, d40c-log_def.lcsp1, d40c-log_def.lcsp3);
   else
 - d40_phy_cfg(cfg, d40c-src_def_cfg,
 - d40c-dst_def_cfg, false);
 + d40_phy_cfg(cfg, d40c-src_def_cfg, d40c-dst_def_cfg);
  
   /* These settings will take precedence later */
   d40c-runtime_addr = config_addr;
 diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
 index 435a223..ab5a2a7 100644
 --- a/drivers/dma/ste_dma40_ll.c
 +++ b/drivers/dma/ste_dma40_ll.c
 @@ -50,63 +50,58 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
  
  }
  
 -/* Sets up SRC and DST CFG register for both logical and physical channels */
 -void d40_phy_cfg(struct stedma40_chan_cfg *cfg,
 -  u32 *src_cfg, u32 *dst_cfg, bool is_log)
 +void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 *src_cfg, u32 *dst_cfg)
  {
   u32 src = 0;
   u32 dst = 0;
  
 - if (!is_log) {
 - /* Physical channel */
 - if ((cfg-dir ==  STEDMA40_PERIPH_TO_MEM) ||
 - (cfg-dir == STEDMA40_PERIPH_TO_PERIPH)) {
 - /* Set master port to 1 */
 - src |= 1  D40_SREG_CFG_MST_POS;
 - src |= D40_TYPE_TO_EVENT(cfg-dev_type);
 -
 - if (cfg-src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
 - src |= 1  D40_SREG_CFG_PHY_TM_POS;
 - else
 - src |= 3  D40_SREG_CFG_PHY_TM_POS;
 - }
 - if ((cfg-dir ==  STEDMA40_MEM_TO_PERIPH) ||
 - (cfg-dir == STEDMA40_PERIPH_TO_PERIPH)) {
 - /* Set master port to 1 */
 - dst |= 1  D40_SREG_CFG_MST_POS;
 - dst |= D40_TYPE_TO_EVENT(cfg-dev_type);
 -
 - if (cfg-dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
 - dst |= 1  D40_SREG_CFG_PHY_TM_POS;
 - else
 - dst |= 3  D40_SREG_CFG_PHY_TM_POS;
 - }
 - /* Interrupt on end of transfer for destination */
 - dst |= 1  D40_SREG_CFG_TIM_POS;
 -
 - /* Generate interrupt on error */
 - src |= 1  D40_SREG_CFG_EIM_POS;
 - dst |= 1  D40_SREG_CFG_EIM_POS;
 -
 - /* PSIZE */
 - if (cfg-src_info.psize != STEDMA40_PSIZE_PHY_1) {
 - src |= 1  D40_SREG_CFG_PHY_PEN_POS;
 - src |= cfg-src_info.psize  D40_SREG_CFG_PSIZE_POS;
 - }
 - if (cfg-dst_info.psize != STEDMA40_PSIZE_PHY_1) {
 - dst |= 1  D40_SREG_CFG_PHY_PEN_POS;
 - dst |= cfg-dst_info.psize  D40_SREG_CFG_PSIZE_POS;
 - }
 -
 - /* Element size */
 - src |= cfg-src_info.data_width  D40_SREG_CFG_ESIZE_POS;
 - dst |= cfg-dst_info.data_width  D40_SREG_CFG_ESIZE_POS;
 -
 - /* Set the priority bit to high for the physical channel */
 - if (cfg-high_priority) {
 - src |= 1  D40_SREG_CFG_PRI_POS;
 - dst

Re: [PATCH 08/39] dmaengine: ste_dma40: Remove redundant address fetching function

[Vinod Koul]

On Wed, May 15, 2013 at 10:51:31AM +0100, Lee Jones wrote:
 Addresses are now stored in local data structures and are easy to
 obtain, thus a specialist function used to fetch them is now surplus
 to requirement.
 
 Signed-off-by: Lee Jones lee.jo...@linaro.org
 ---
Acked-by: Vinod Koul vinod.k...@intel.com

--
~Vinod
  drivers/dma/ste_dma40.c |   18 --
  1 file changed, 18 deletions(-)
 
 diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
 index 57a127e..6ed7757 100644
 --- a/drivers/dma/ste_dma40.c
 +++ b/drivers/dma/ste_dma40.c
 @@ -2267,24 +2267,6 @@ err:
   return NULL;
  }
  
 -static dma_addr_t
 -d40_get_dev_addr(struct d40_chan *chan, enum dma_transfer_direction 
 direction)
 -{
 - struct stedma40_platform_data *plat = chan-base-plat_data;
 - struct stedma40_chan_cfg *cfg = chan-dma_cfg;
 - dma_addr_t addr = 0;
 -
 - if (chan-runtime_addr)
 - return chan-runtime_addr;
 -
 - if (direction == DMA_DEV_TO_MEM)
 - addr = plat-dev_rx[cfg-dev_type];
 - else if (direction == DMA_MEM_TO_DEV)
 - addr = plat-dev_tx[cfg-dev_type];
 -
 - return addr;
 -}
 -
  static struct dma_async_tx_descriptor *
  d40_prep_sg(struct dma_chan *dchan, struct scatterlist *sg_src,
   struct scatterlist *sg_dst, unsigned int sg_len,
 -- 
 1.7.10.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 10/39] dmaengine: ste_dma40: Correct copy/paste error

[Vinod Koul]

On Wed, May 15, 2013 at 10:51:33AM +0100, Lee Jones wrote:
 'struct stedma40_half_channel_info's header comment says that it's
 called 'struct stedma40_chan_cfg'. Let's straighten that out.
 
 Signed-off-by: Lee Jones lee.jo...@linaro.org
 ---
Acked-by: Vinod Koul vinod.k...@intel.com

--
~Vinod
  include/linux/platform_data/dma-ste-dma40.h |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/include/linux/platform_data/dma-ste-dma40.h 
 b/include/linux/platform_data/dma-ste-dma40.h
 index af0064e..288dc24 100644
 --- a/include/linux/platform_data/dma-ste-dma40.h
 +++ b/include/linux/platform_data/dma-ste-dma40.h
 @@ -86,7 +86,7 @@ enum stedma40_xfer_dir {
  
  
  /**
 - * struct stedma40_chan_cfg - dst/src channel configuration
 + * struct stedma40_half_channel_info - dst/src channel configuration
   *
   * @big_endian: true if the src/dst should be read as big endian
   * @data_width: Data width of the src/dst hardware
 -- 
 1.7.10.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 31/39] dmaengine: ste_dma40: Replace ST-E's home-brew DMA direction defs with generic ones

[Vinod Koul]

On Thu, May 16, 2013 at 08:06:38AM +0100, Lee Jones wrote:
 On Thu, 16 May 2013, Vinod Koul wrote:
 
  On Wed, May 15, 2013 at 10:51:54AM +0100, Lee Jones wrote:
   STEDMA40_*_TO_* direction definitions are identical in all but name to
   the pre-defined generic DMA_*_TO_* ones. Let's make things easy by not
   duplicating such things.
   
   Cc: Vinod Koul vinod.k...@intel.com
   Cc: Dan Williams d...@fb.com
   Cc: Per Forlin per.for...@stericsson.com
   Cc: Rabin Vincent ra...@rab.in
   Signed-off-by: Lee Jones lee.jo...@linaro.org
  Nice :)
 
 :)
 
  1) I dont see the STE macro getting removed, why do we need it
 
 They are removed later in the set, once their use has been removed
 from platform code and all the other drivers.
 
  2) last i checked the direction values had a bit idfference b/w what you are
  using and what dmaengine defines, so hopefully that is taken care of..
 
 Yes, no problem.
 
 place Ack here ;)
Acked-by: Vinod Koul vinod.k...@intel.com

--
~Vinod
 
 -- 
 Lee Jones
 Linaro ST-Ericsson Landing Team Lead
 Linaro.org │ Open source software for ARM SoCs
 Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()

[Vinod Koul]

On Thu, May 16, 2013 at 08:25:57AM +0100, Lee Jones wrote:
 On Thu, 16 May 2013, Vinod Koul wrote:
 
  On Wed, May 15, 2013 at 10:51:25AM +0100, Lee Jones wrote:
   All configuration left in d40_phy_cfg() is runtime configurable and
   there is already a call into it from d40_runtime_config(), so let's
   rely on that.
   
   Acked-by: Vinod Koul vnod.k...@intel.com
  That needs up update!
 
 Ah, where did I get that from that?
 
 Was that my mistake, or was this in the MAINTAINERS file?
Certainly not in MAINTAINERS file :)

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

Re: [PATCH 34/39] dmaengine: ste_dma40: Convert data_width from register bit format to value

[Vinod Koul]

On Thu, May 16, 2013 at 08:35:53AM +0100, Lee Jones wrote:
 On Thu, 16 May 2013, Vinod Koul wrote:
 
  On Wed, May 15, 2013 at 10:51:57AM +0100, Lee Jones wrote:
   +u8 d40_width_to_bits(enum dma_slave_buswidth width)
   +{
   + if (width == DMA_SLAVE_BUSWIDTH_1_BYTE)
   + return STEDMA40_ESIZE_8_BIT;
   + else if (width == DMA_SLAVE_BUSWIDTH_2_BYTES)
   + return STEDMA40_ESIZE_16_BIT;
   + else if (width == DMA_SLAVE_BUSWIDTH_8_BYTES)
   + return STEDMA40_ESIZE_64_BIT;
   + else
   + return STEDMA40_ESIZE_32_BIT;
   +}
   +
  Switch looks better for this and how about
  return fls(width);
  
  as your defines are 0...3 and dmaengine define 1,2,..8 for same thing
  then you can also get rid of STEDMA40_XXX_WIDTH macros!
 
 I like it.
 
 Will you let me do it as a follow-up patch?
Okay...

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

Re: [PATCH 36/39] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT

[Vinod Koul]

On Wed, May 15, 2013 at 10:51:59AM +0100, Lee Jones wrote:
 At this moment in time the memcpy channels which can be used by the D40
 are fixed, as each supported platform in Mainline uses the same ones.
 However, platforms do exist which don't follow this convention, so
 these will need to be tailored. Fortunately, these platforms will be DT
 only, so this change has very little impact on platform data.
 
 Cc: Vinod Koul vinod.k...@intel.com
 Cc: Dan Williams d...@fb.com
 Cc: Per Forlin per.for...@stericsson.com
 Cc: Rabin Vincent ra...@rab.in
 Acked-by: Arnd Bergmann a...@arndb.de
 Signed-off-by: Lee Jones lee.jo...@linaro.org
Acked-by: Vinod Koul vinod.k...@intel.com

 ---
  .../devicetree/bindings/dma/ste-dma40.txt  |2 +
  drivers/dma/ste_dma40.c|   40 
 
  include/linux/platform_data/dma-ste-dma40.h|2 +
  3 files changed, 36 insertions(+), 8 deletions(-)
 
 diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt 
 b/Documentation/devicetree/bindings/dma/ste-dma40.txt
 index 2679a87..aa272d8 100644
 --- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
 +++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
 @@ -6,6 +6,7 @@ Required properties:
  - reg-names: Names of the above areas to use during resource look-up
  - interrupt: Should contain the DMAC interrupt number
  - #dma-cells: must be 3
 +- memcpy-channels: Channels to be used for memcpy
  
  Optional properties:
  - dma-channels: Number of channels supported by hardware - if not present
 @@ -21,6 +22,7 @@ Example:
   interrupts = 0 25 0x4;
  
   #dma-cells = 2;
 + memcpy-channels  = 56 57 58 59 60;
   dma-channels = 8;
   };
  
 diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
 index 76c255f..ae462d3 100644
 --- a/drivers/dma/ste_dma40.c
 +++ b/drivers/dma/ste_dma40.c
 @@ -58,6 +58,8 @@
  #define D40_ALLOC_PHYBIT(30)
  #define D40_ALLOC_LOG_FREE   0
  
 +#define D40_MEMCPY_MAX_CHANS 8
 +
  /* Reserved event lines for memcpy only. */
  #define DB8500_DMA_MEMCPY_EV_0   51
  #define DB8500_DMA_MEMCPY_EV_1   56
 @@ -522,6 +524,8 @@ struct d40_gen_dmac {
   * @phy_start: Physical memory start of the DMA registers.
   * @phy_size: Size of the DMA register map.
   * @irq: The IRQ number.
 + * @num_memcpy_chans: The number of channels used for memcpy (mem-to-mem
 + * transfers).
   * @num_phy_chans: The number of physical channels. Read from HW. This
   * is the number of available channels for this driver, not counting Secure
   * mode allocated physical channels.
 @@ -565,6 +569,7 @@ struct d40_base {
   phys_addr_t   phy_start;
   resource_size_t   phy_size;
   int   irq;
 + int   num_memcpy_chans;
   int   num_phy_chans;
   int   num_log_chans;
   struct device_dma_parameters  dma_parms;
 @@ -2938,7 +2943,7 @@ static int __init d40_dmaengine_init(struct d40_base 
 *base,
   }
  
   d40_chan_init(base, base-dma_memcpy, base-log_chans,
 -   base-num_log_chans, ARRAY_SIZE(dma40_memcpy_channels));
 +   base-num_log_chans, base-num_memcpy_chans);
  
   dma_cap_zero(base-dma_memcpy.cap_mask);
   dma_cap_set(DMA_MEMCPY, base-dma_memcpy.cap_mask);
 @@ -3139,6 +3144,7 @@ static struct d40_base * __init 
 d40_hw_detect_init(struct platform_device *pdev)
   struct d40_base *base = NULL;
   int num_log_chans = 0;
   int num_phy_chans;
 + int num_memcpy_chans;
   int clk_ret = -EINVAL;
   int i;
   u32 pid;
 @@ -3209,6 +3215,12 @@ static struct d40_base * __init 
 d40_hw_detect_init(struct platform_device *pdev)
   else
   num_phy_chans = 4 * (readl(virtbase + D40_DREG_ICFG)  0x7) + 4;
  
 + /* The number of channels used for memcpy */
 + if (plat_data-num_of_memcpy_chans)
 + num_memcpy_chans = plat_data-num_of_memcpy_chans;
 + else
 + num_memcpy_chans = ARRAY_SIZE(dma40_memcpy_channels);
 +
   num_log_chans = num_phy_chans * D40_MAX_LOG_CHAN_PER_PHY;
  
   dev_info(pdev-dev,
 @@ -3216,7 +3228,7 @@ static struct d40_base * __init 
 d40_hw_detect_init(struct platform_device *pdev)
rev, res-start, num_phy_chans, num_log_chans);
  
   base = kzalloc(ALIGN(sizeof(struct d40_base), 4) +
 -(num_phy_chans + num_log_chans + 
 ARRAY_SIZE(dma40_memcpy_channels)) *
 +(num_phy_chans + num_log_chans + num_memcpy_chans) *
  sizeof(struct d40_chan), GFP_KERNEL);
  
   if (base == NULL) {
 @@ -3226,6 +3238,7 @@ static struct d40_base * __init 
 d40_hw_detect_init(struct platform_device *pdev)
  
   base-rev = rev;
   base-clk = clk;
 + base-num_memcpy_chans = num_memcpy_chans;
   base

Re: [PATCH 33/39] dmaengine: ste_dma40_ll: Use the BIT macro to replace ugly '(1 x)'s

[Vinod Koul]

On Wed, May 15, 2013 at 10:51:56AM +0100, Lee Jones wrote:
 The aim is to make the code that little more readable.
 
 Cc: Vinod Koul vinod.k...@intel.com
 Cc: Dan Williams d...@fb.com
 Cc: Per Forlin per.for...@stericsson.com
 Cc: Rabin Vincent ra...@rab.in
 Signed-off-by: Lee Jones lee.jo...@linaro.org
Acked-by: Vinod Koul vinod.k...@intel.com

Hopefully all the BIT conversion in the driver are done in this

--
~Vinod
 ---
  drivers/dma/ste_dma40_ll.c |   44 
 ++--
  1 file changed, 22 insertions(+), 22 deletions(-)
 
 diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
 index 121c0ce..5ddd724 100644
 --- a/drivers/dma/ste_dma40_ll.c
 +++ b/drivers/dma/ste_dma40_ll.c
 @@ -20,28 +20,28 @@ void d40_log_cfg(struct stedma40_chan_cfg *cfg,
   /* src is mem? - increase address pos */
   if (cfg-dir ==  DMA_MEM_TO_DEV ||
   cfg-dir ==  DMA_MEM_TO_MEM)
 - l1 |= 1  D40_MEM_LCSP1_SCFG_INCR_POS;
 + l1 |= BIT(D40_MEM_LCSP1_SCFG_INCR_POS);
  
   /* dst is mem? - increase address pos */
   if (cfg-dir ==  DMA_DEV_TO_MEM ||
   cfg-dir ==  DMA_MEM_TO_MEM)
 - l3 |= 1  D40_MEM_LCSP3_DCFG_INCR_POS;
 + l3 |= BIT(D40_MEM_LCSP3_DCFG_INCR_POS);
  
   /* src is hw? - master port 1 */
   if (cfg-dir ==  DMA_DEV_TO_MEM ||
   cfg-dir ==  DMA_DEV_TO_DEV)
 - l1 |= 1  D40_MEM_LCSP1_SCFG_MST_POS;
 + l1 |= BIT(D40_MEM_LCSP1_SCFG_MST_POS);
  
   /* dst is hw? - master port 1 */
   if (cfg-dir ==  DMA_MEM_TO_DEV ||
   cfg-dir ==  DMA_DEV_TO_DEV)
 - l3 |= 1  D40_MEM_LCSP3_DCFG_MST_POS;
 + l3 |= BIT(D40_MEM_LCSP3_DCFG_MST_POS);
  
 - l3 |= 1  D40_MEM_LCSP3_DCFG_EIM_POS;
 + l3 |= BIT(D40_MEM_LCSP3_DCFG_EIM_POS);
   l3 |= cfg-dst_info.psize  D40_MEM_LCSP3_DCFG_PSIZE_POS;
   l3 |= cfg-dst_info.data_width  D40_MEM_LCSP3_DCFG_ESIZE_POS;
  
 - l1 |= 1  D40_MEM_LCSP1_SCFG_EIM_POS;
 + l1 |= BIT(D40_MEM_LCSP1_SCFG_EIM_POS);
   l1 |= cfg-src_info.psize  D40_MEM_LCSP1_SCFG_PSIZE_POS;
   l1 |= cfg-src_info.data_width  D40_MEM_LCSP1_SCFG_ESIZE_POS;
  
 @@ -58,39 +58,39 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 
 *src_cfg, u32 *dst_cfg)
   if ((cfg-dir == DMA_DEV_TO_MEM) ||
   (cfg-dir == DMA_DEV_TO_DEV)) {
   /* Set master port to 1 */
 - src |= 1  D40_SREG_CFG_MST_POS;
 + src |= BIT(D40_SREG_CFG_MST_POS);
   src |= D40_TYPE_TO_EVENT(cfg-dev_type);
  
   if (cfg-src_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
 - src |= 1  D40_SREG_CFG_PHY_TM_POS;
 + src |= BIT(D40_SREG_CFG_PHY_TM_POS);
   else
   src |= 3  D40_SREG_CFG_PHY_TM_POS;
   }
   if ((cfg-dir == DMA_MEM_TO_DEV) ||
   (cfg-dir == DMA_DEV_TO_DEV)) {
   /* Set master port to 1 */
 - dst |= 1  D40_SREG_CFG_MST_POS;
 + dst |= BIT(D40_SREG_CFG_MST_POS);
   dst |= D40_TYPE_TO_EVENT(cfg-dev_type);
  
   if (cfg-dst_info.flow_ctrl == STEDMA40_NO_FLOW_CTRL)
 - dst |= 1  D40_SREG_CFG_PHY_TM_POS;
 + dst |= BIT(D40_SREG_CFG_PHY_TM_POS);
   else
   dst |= 3  D40_SREG_CFG_PHY_TM_POS;
   }
   /* Interrupt on end of transfer for destination */
 - dst |= 1  D40_SREG_CFG_TIM_POS;
 + dst |= BIT(D40_SREG_CFG_TIM_POS);
  
   /* Generate interrupt on error */
 - src |= 1  D40_SREG_CFG_EIM_POS;
 - dst |= 1  D40_SREG_CFG_EIM_POS;
 + src |= BIT(D40_SREG_CFG_EIM_POS);
 + dst |= BIT(D40_SREG_CFG_EIM_POS);
  
   /* PSIZE */
   if (cfg-src_info.psize != STEDMA40_PSIZE_PHY_1) {
 - src |= 1  D40_SREG_CFG_PHY_PEN_POS;
 + src |= BIT(D40_SREG_CFG_PHY_PEN_POS);
   src |= cfg-src_info.psize  D40_SREG_CFG_PSIZE_POS;
   }
   if (cfg-dst_info.psize != STEDMA40_PSIZE_PHY_1) {
 - dst |= 1  D40_SREG_CFG_PHY_PEN_POS;
 + dst |= BIT(D40_SREG_CFG_PHY_PEN_POS);
   dst |= cfg-dst_info.psize  D40_SREG_CFG_PSIZE_POS;
   }
  
 @@ -100,14 +100,14 @@ void d40_phy_cfg(struct stedma40_chan_cfg *cfg, u32 
 *src_cfg, u32 *dst_cfg)
  
   /* Set the priority bit to high for the physical channel */
   if (cfg-high_priority) {
 - src |= 1  D40_SREG_CFG_PRI_POS;
 - dst |= 1  D40_SREG_CFG_PRI_POS;
 + src |= BIT(D40_SREG_CFG_PRI_POS);
 + dst |= BIT(D40_SREG_CFG_PRI_POS);
   }
  
   if (cfg-src_info.big_endian)
 - src |= 1  D40_SREG_CFG_LBE_POS;
 + src |= BIT(D40_SREG_CFG_LBE_POS);
   if (cfg-dst_info.big_endian)
 - dst |= 1  D40_SREG_CFG_LBE_POS;
 + dst |= BIT(D40_SREG_CFG_LBE_POS);
  
   *src_cfg = src;
   *dst_cfg = dst;
 @@ -157,15 +157,15 @@ static int

Re: [PATCH 31/39] dmaengine: ste_dma40: Replace ST-E's home-brew DMA direction defs with generic ones

[Vinod Koul]

On Wed, May 15, 2013 at 10:51:54AM +0100, Lee Jones wrote:
 STEDMA40_*_TO_* direction definitions are identical in all but name to
 the pre-defined generic DMA_*_TO_* ones. Let's make things easy by not
 duplicating such things.
 
 Cc: Vinod Koul vinod.k...@intel.com
 Cc: Dan Williams d...@fb.com
 Cc: Per Forlin per.for...@stericsson.com
 Cc: Rabin Vincent ra...@rab.in
 Signed-off-by: Lee Jones lee.jo...@linaro.org
Nice :)

1) I dont see the STE macro getting removed, why do we need it
2) last i checked the direction values had a bit idfference b/w what you are
using and what dmaengine defines, so hopefully that is taken care of..

--
~Vinod
 ---
  drivers/dma/ste_dma40.c|   56 
 ++--
  drivers/dma/ste_dma40_ll.c |   24 +--
  2 files changed, 40 insertions(+), 40 deletions(-)
 
 diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
 index 08bc58a..483da16 100644
 --- a/drivers/dma/ste_dma40.c
 +++ b/drivers/dma/ste_dma40.c
 @@ -78,7 +78,7 @@ static int dma40_memcpy_channels[] = {
  /* Default configuration for physcial memcpy */
  struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
   .mode = STEDMA40_MODE_PHYSICAL,
 - .dir = STEDMA40_MEM_TO_MEM,
 + .dir = DMA_MEM_TO_MEM,
  
   .src_info.data_width = STEDMA40_BYTE_WIDTH,
   .src_info.psize = STEDMA40_PSIZE_PHY_1,
 @@ -92,7 +92,7 @@ struct stedma40_chan_cfg dma40_memcpy_conf_phy = {
  /* Default configuration for logical memcpy */
  struct stedma40_chan_cfg dma40_memcpy_conf_log = {
   .mode = STEDMA40_MODE_LOGICAL,
 - .dir = STEDMA40_MEM_TO_MEM,
 + .dir = DMA_MEM_TO_MEM,
  
   .src_info.data_width = STEDMA40_BYTE_WIDTH,
   .src_info.psize = STEDMA40_PSIZE_LOG_1,
 @@ -843,7 +843,7 @@ static void d40_log_lli_to_lcxa(struct d40_chan *chan, 
 struct d40_desc *desc)
* that uses linked lists.
*/
   if (!(chan-phy_chan-use_soft_lli 
 - chan-dma_cfg.dir == STEDMA40_PERIPH_TO_MEM))
 + chan-dma_cfg.dir == DMA_DEV_TO_MEM))
   curr_lcla = d40_lcla_alloc_one(chan, desc);
  
   first_lcla = curr_lcla;
 @@ -1311,12 +1311,12 @@ static void d40_config_set_event(struct d40_chan 
 *d40c,
   u32 event = D40_TYPE_TO_EVENT(d40c-dma_cfg.dev_type);
  
   /* Enable event line connected to device (or memcpy) */
 - if ((d40c-dma_cfg.dir ==  STEDMA40_PERIPH_TO_MEM) ||
 - (d40c-dma_cfg.dir == STEDMA40_PERIPH_TO_PERIPH))
 + if ((d40c-dma_cfg.dir == DMA_DEV_TO_MEM) ||
 + (d40c-dma_cfg.dir == DMA_DEV_TO_DEV))
   __d40_config_set_event(d40c, event_type, event,
  D40_CHAN_REG_SSLNK);
  
 - if (d40c-dma_cfg.dir !=  STEDMA40_PERIPH_TO_MEM)
 + if (d40c-dma_cfg.dir !=  DMA_DEV_TO_MEM)
   __d40_config_set_event(d40c, event_type, event,
  D40_CHAN_REG_SDLNK);
  }
 @@ -1774,7 +1774,7 @@ static int d40_validate_conf(struct d40_chan *d40c,
   res = -EINVAL;
   }
  
 - if (conf-dir == STEDMA40_PERIPH_TO_PERIPH) {
 + if (conf-dir == DMA_DEV_TO_DEV) {
   /*
* DMAC HW supports it. Will be added to this driver,
* in case any dma client requires it.
 @@ -1905,11 +1905,11 @@ static int d40_allocate_channel(struct d40_chan 
 *d40c, bool *first_phy_user)
   phys = d40c-base-phy_res;
   num_phy_chans = d40c-base-num_phy_chans;
  
 - if (d40c-dma_cfg.dir == STEDMA40_PERIPH_TO_MEM) {
 + if (d40c-dma_cfg.dir == DMA_DEV_TO_MEM) {
   log_num = 2 * dev_type;
   is_src = true;
 - } else if (d40c-dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
 -d40c-dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
 + } else if (d40c-dma_cfg.dir == DMA_MEM_TO_DEV ||
 +d40c-dma_cfg.dir == DMA_MEM_TO_MEM) {
   /* dst event lines are used for logical memcpy */
   log_num = 2 * dev_type + 1;
   is_src = false;
 @@ -1920,7 +1920,7 @@ static int d40_allocate_channel(struct d40_chan *d40c, 
 bool *first_phy_user)
   event_line = D40_TYPE_TO_EVENT(dev_type);
  
   if (!is_log) {
 - if (d40c-dma_cfg.dir == STEDMA40_MEM_TO_MEM) {
 + if (d40c-dma_cfg.dir == DMA_MEM_TO_MEM) {
   /* Find physical half channel */
   if (d40c-dma_cfg.use_fixed_channel) {
   i = d40c-dma_cfg.phy_channel;
 @@ -2068,10 +2068,10 @@ static int d40_free_dma(struct d40_chan *d40c)
   return -EINVAL;
   }
  
 - if (d40c-dma_cfg.dir == STEDMA40_MEM_TO_PERIPH ||
 - d40c-dma_cfg.dir == STEDMA40_MEM_TO_MEM)
 + if (d40c-dma_cfg.dir == DMA_MEM_TO_DEV ||
 + d40c-dma_cfg.dir == DMA_MEM_TO_MEM)
   is_src = false;
 - else if (d40c-dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
 + else if (d40c-dma_cfg.dir

Re: [PATCH 35/39] dmaengine: ste_dma40_ll: Replace meaningless register set with comment

[Vinod Koul]

On Wed, May 15, 2013 at 10:51:58AM +0100, Lee Jones wrote:
 Unsure of the author's intentions, rather than just removing the nop,
 we're replacing it with a comment containing the possible intention
 of the statement OR:ing with 0.
Would be worthwhile to check w/ Linus W on this (or check whom to blame)

--
~Vinod
 
 Cc: Vinod Koul vinod.k...@intel.com
 Cc: Dan Williams d...@fb.com
 Cc: Per Forlin per.for...@stericsson.com
 Cc: Rabin Vincent ra...@rab.in
 Signed-off-by: Lee Jones lee.jo...@linaro.org
 ---
  drivers/dma/ste_dma40_ll.c |6 --
  1 file changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/dma/ste_dma40_ll.c b/drivers/dma/ste_dma40_ll.c
 index a035dfe..27b818d 100644
 --- a/drivers/dma/ste_dma40_ll.c
 +++ b/drivers/dma/ste_dma40_ll.c
 @@ -182,8 +182,10 @@ static int d40_phy_fill_lli(struct d40_phy_lli *lli,
   else
   lli-reg_cfg = ~BIT(D40_SREG_CFG_TIM_POS);
  
 - /* Post link */
 - lli-reg_lnk |= 0  D40_SREG_LNK_PHY_PRE_POS;
 + /*
 +  * Post link - D40_SREG_LNK_PHY_PRE_POS = 0
 +  * Relink happens after transfer completion.
 +  */
  
   return 0;
  }
 -- 
 1.7.10.4
 
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: Build break on usb-next with exynos_defconfig

[Vinod Koul]

On Thu, Feb 28, 2013 at 03:55:51AM +, PADMAVATHI VENNA wrote:
  Hi,
 
 
  Trying to compile 'usb-next' branch with exynos_defconfig, but hit
  upon compilation error.
 
  arch/arm/plat-samsung/dma-ops.c: In function 'samsung_dmadev_request':
  arch/arm/plat-samsung/dma-ops.c:39: error: implicit declaration of
  function 'dma_request_slave_channel'
  make[1]: *** [arch/arm/plat-samsung/dma-ops.o] Error 1
  make[1]: *** Waiting for unfinished jobs
 
  Anyone noticed this ?
 
  I tried git bisecting and get following result.
 
  Any reason why you didn't include the people who wrote this patch on
  your email?  They would be the natural ones to help fix it :)
 
 
 Yes, ofcourse. missed :-(
 Thanks
 
 These set of patches are dependent on vinod koul generic dma dt binding 
 patches. I mentioned the dependency info in my cover-letter.
 
 Hi Vinod,
 Can you please tell when the generic dma dt patches will come in mainline? 
They are already there... 

--
~Vinod
 
 Thanks
 Padma
 
  e7ba5f1d0f6292e1b99c63cc4bb74c70232e9065 is the first bad commit
  commit e7ba5f1d0f6292e1b99c63cc4bb74c70232e9065
  Author: Padmavathi Venna 
  Date:   Fri Jan 18 17:17:02 2013 +0530
 
  ARM: SAMSUNG: Make dma request compatible to generic dma bindings.
 
  This patch make the dma dev request operation compatible for both
  DT and non-DT cases. It takes the all the arguments required for
  dma_request_slave_channel and dma_request_channel. If the driver
  is initiated via DT or non-DT the corresponding call will be made.
 
  Signed-off-by: Padmavathi Venna 
  Signed-off-by: Mark Brown 
 
  :04 04 3a6948e1d7fee3cfa84a3cf4b0065d87301b79f2
  b4ee1e9354a7bd9b223ea78c4c98950504951cb3 March
 
 
 
 
 
 
 
 -- 
 Thanks  Regards
 Vivek
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html