Re: [PATCH] dmaengine: cppi41: Fix cppi41_dma_prep_slave_sg() when idle
On 23-10-19, 08:31, Tony Lindgren wrote: > Yegor Yefremov reported that musb and ftdi > uart can fail for the first open of the uart unless connected using > a hub. > > This is because the first dma call done by musb_ep_program() must wait > if cppi41 is PM runtime suspended. Otherwise musb_ep_program() continues > with other non-dma packets before the DMA transfer is started causing at > least ftdi uarts to fail to receive data. > > Let's fix the issue by waking up cppi41 with PM runtime calls added to > cppi41_dma_prep_slave_sg() and return NULL if still idled. This way we > have musb_ep_program() continue with PIO until cppi41 is awake. Applied and tagged stable, thanks -- ~Vinod
Re: [PATCH] dmaengine: cppi41: Fix issue with musb and ftdi uart
Hi Tony,
On 22-10-19, 07:55, Tony Lindgren wrote:
Patch subject should reflect the patch changes not the fix. The patch
title here is not telling me anything about the change below. Pls
consider updating the title.
> The first dma call done by musb_ep_program() must wait if cppi41 is PM
> runtime suspended. Otherwise musb_ep_program() continues with other
> non-dma packets before the DMA transfer is started causing at least ftdi
> uarts to fail to receive data.
>
> Let's fix the issue by waking up cppi41 with PM runtime calls added to
> cppi41_dma_prep_slave_sg() and return NULL if still idled. This way we
> have musb_ep_program() continue with PIO until cppi41 is awake.
>
> Fixes: fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support")
Cc stable?
> Cc: Bin Liu
> Cc: giulio.bene...@benettiengineering.com
> Cc: Sebastian Andrzej Siewior
> Cc: Sebastian Reichel
> Cc: Skvortsov
> Reported-by: Yegor Yefremov
> Signed-off-by: Tony Lindgren
> ---
> drivers/dma/ti/cppi41.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/ti/cppi41.c b/drivers/dma/ti/cppi41.c
> --- a/drivers/dma/ti/cppi41.c
> +++ b/drivers/dma/ti/cppi41.c
> @@ -586,9 +586,22 @@ static struct dma_async_tx_descriptor
> *cppi41_dma_prep_slave_sg(
> enum dma_transfer_direction dir, unsigned long tx_flags, void *context)
> {
> struct cppi41_channel *c = to_cpp41_chan(chan);
> + struct dma_async_tx_descriptor *txd = NULL;
> + struct cppi41_dd *cdd = c->cdd;
> struct cppi41_desc *d;
> struct scatterlist *sg;
> unsigned int i;
> + int error;
> +
> + error = pm_runtime_get(cdd->ddev.dev);
> + if (error < 0) {
> + pm_runtime_put_noidle(cdd->ddev.dev);
> +
> + return NULL;
> + }
> +
> + if (cdd->is_suspended)
> + goto err_out_not_ready;
>
> d = c->desc;
> for_each_sg(sgl, sg, sg_len, i) {
> @@ -611,7 +624,13 @@ static struct dma_async_tx_descriptor
> *cppi41_dma_prep_slave_sg(
> d++;
> }
>
> - return &c->txd;
> + txd = &c->txd;
> +
> +err_out_not_ready:
> + pm_runtime_mark_last_busy(cdd->ddev.dev);
> + pm_runtime_put_autosuspend(cdd->ddev.dev);
> +
> + return txd;
> }
>
> static void cppi41_compute_td_desc(struct cppi41_desc *d)
> --
> 2.23.0
--
~Vinod
Re: [PATCH 02/18] dmaengine: imx-sdma: pass struct device to DMA API functions
On 01-02-19, 09:47, Christoph Hellwig wrote: > The DMA API generally relies on a struct device to work properly, and > only barely works without one for legacy reasons. Pass the easily > available struct device from the platform_device to remedy this. This looks good to me but fails to apply. Can you please base it on dmaengine-next or linux-next please and resend Thanks -- ~Vinod
Re: [PATCH 6/6] dmaengine: sh: rcar-dmac: Use device_iommu_mapped()
On 11-12-18, 14:43, Joerg Roedel wrote: > From: Joerg Roedel > > Use Use device_iommu_mapped() to check if the device is > already mapped by an IOMMU. Acked-by: Vinod Koul -- ~Vinod
Re: [PATCH 1/6] driver core: Introduce device_iommu_mapped() function
On 11-12-18, 14:43, Joerg Roedel wrote: > From: Joerg Roedel > > Some places in the kernel check the iommu_group pointer in > 'struct device' in order to find ot whether a device is ^^ Typo -- ~Vinod
Re: [PATCH] dma: cppi41: delete channel from pending list when stop channel
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
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, &cdd->pending, node) {
> + if (cc != c)
> + continue;
> + list_del(&cc->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
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 -- 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()
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
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
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
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
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 > --- > drivers/dma/cppi41.c | 28 --- Acked-by: Vinod Koul -- ~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
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
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
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
On Mon, Nov 14, 2016 at 06:49:12AM -0800, Tony Lindgren wrote: > * Vinod Koul [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] dma: cpp41: Fix handling of error path
On Fri, Nov 11, 2016 at 11:28:52AM -0800, Tony Lindgren wrote: > If we return early on pm_runtime_get() error, we need to also call > pm_runtime_put_noidle() as pointed out in a musb related thread > by Johan Hovold . This is to keep the PM runtime > use counts happy. 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 0/2] Two cpp41 pm runtime found when testing with usb
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
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
On Wed, Aug 31, 2016 at 07:30:55AM -0700, Tony Lindgren wrote: > * Vinod Koul [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
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
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
On Mon, Aug 22, 2016 at 07:21:48AM -0700, Tony Lindgren wrote:
> Hi,
>
> * Vinod Koul [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
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(&c->txd);
> dmaengine_desc_get_callback_invoke(&c->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(&c->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
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
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
> ---
>
> 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
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 > --- > 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
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 10/12] usb: musb: ux500_dma: use dmaengine_xxx() APIs
The drivers should use dmaengine_terminate_all() or dmaengine_slave_config() API instead of accessing the device_control which will be deprecated soon Signed-off-by: Vinod Koul --- drivers/usb/musb/ux500_dma.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/usb/musb/ux500_dma.c b/drivers/usb/musb/ux500_dma.c index 9aad00f..874833d 100644 --- a/drivers/usb/musb/ux500_dma.c +++ b/drivers/usb/musb/ux500_dma.c @@ -121,8 +121,7 @@ static bool ux500_configure_channel(struct dma_channel *channel, slave_conf.dst_maxburst = 16; slave_conf.device_fc = false; - dma_chan->device->device_control(dma_chan, DMA_SLAVE_CONFIG, -(unsigned long) &slave_conf); + dmaengine_slave_config(dma_chan, &slave_conf); dma_desc = dmaengine_prep_slave_sg(dma_chan, &sg, 1, direction, DMA_PREP_INTERRUPT | DMA_CTRL_ACK); @@ -246,9 +245,7 @@ static int ux500_dma_channel_abort(struct dma_channel *channel) musb_writew(epio, MUSB_RXCSR, csr); } - ux500_channel->dma_chan->device-> - device_control(ux500_channel->dma_chan, - DMA_TERMINATE_ALL, 0); + dmaengine_terminate_all(ux500_channel->dma_chan); channel->status = MUSB_DMA_STATUS_FREE; } return 0; -- 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
[PATCH 00/12] dmaengine: remove users of device_control
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
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 26/27] usb: musb: omap2430: use pm_runtime_last_busy_and_autosuspend helper
Use the new pm_runtime_last_busy_and_autosuspend helper instead of open
coding the same code
Signed-off-by: Vinod Koul
---
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
[PATCH 00/27] add pm_runtime_last_busy_and_autosuspend() helper
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
Re: [PATCH v4 1/7] dma: cppi41: handle 0-length packets
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
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
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 4/5] dma: cppi41: only allocate descriptor memory once
On Mon, Sep 23, 2013 at 04:51:06PM +0200, Sebastian Andrzej Siewior wrote: > On 09/23/2013 06:17 AM, Vinod Koul wrote: > > Looks fine, Sebastian cna you test it pls > > Just noticed that you already applied some of them. I just got back > after a few weeks of. Will review & test as soon as I get to it. Yes, the first three were trvial, 5th one looked fine to me ! ~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: [alsa-devel] [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call
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 -- -- 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
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
Acked-by: Vinod Koul
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 23/51] DMA-API: dma: pl08x: add dma_set_mask_and_coherent() call
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
Acked-by: Vinod Koul
~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: [PATCH v3 5/5] dma: cppi41: add support for suspend and resume
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
> ---
> 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: [PATCH v3 5/5] dma: cppi41: add support for suspend and resume
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 4/5] dma: cppi41: only allocate descriptor memory once
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 v3 3/5] dma: cppi41: add shortcut to &pdev->dev in cppi41_dma_probe()
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 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
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 2/5] dma: cppi41: s/deinit_cpii41/deinit_cppi41/
On Sun, Sep 22, 2013 at 04:50:01PM +0200, Daniel Mack wrote: > Fix a misspelled function name. > > Signed-off-by: Daniel Mack 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
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
> ---
> 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 11/11] dma: cpp41: enable pm_runtime during init
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 > Signed-off-by: Sebastian Andrzej Siewior Acked-by Vinod Koul ~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 > #include > #include > +#include > #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
On Fri, Aug 16, 2013 at 05:40:55PM +0200, Sebastian Andrzej Siewior wrote:
> From: Sebastian Andrzej Siewior
>
> 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
Acked-by: Vinod Koul
~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: [RFC] ux500 dma & short transfers on MUSB
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: [PATCH 15/16] dmaengine: add transfered member to dma_async_tx_descriptor
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
> Cc: Dan Williams
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> 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: MUSB multiplatform work?
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?
On Thu, May 30, 2013 at 11:19:33PM +0200, Linus Walleij wrote:
> On Thu, May 30, 2013 at 10:31 PM, Tony Lindgren 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
On Thu, May 30, 2013 at 11:04:23AM +0200, Linus Walleij wrote: > On Wed, May 15, 2013 at 11:51 AM, 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. > > > > Cc: Vinod Koul > > Cc: Dan Williams > > Cc: Per Forlin > > Cc: Rabin Vincent > > Signed-off-by: Lee Jones > > Tentatively applied. Missing Vinod's ACK. Acked-by: Vinod Koul -- ~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
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 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
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 > > 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 31/39] dmaengine: ste_dma40: Replace ST-E's home-brew DMA direction defs with generic ones
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 > > > Cc: Dan Williams > > > Cc: Per Forlin > > > Cc: Rabin Vincent > > > Signed-off-by: Lee Jones > > 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. > > ;) Acked-by: Vinod Koul -- ~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 07/39] dmaengine: ste_dma40: Only use addresses passed as configuration information
On Wed, May 15, 2013 at 10:51:30AM +0100, Lee Jones wrote:
> Addresses are passed in from the client's driver via the invocation of
> dmaengine_slave_config(), so there's no need to fetch them from platform
> data too, hardwired or otherwise. This is a great step forward, as it
> elevates a large burden from platform data in the way of a look-up
> table.
>
> Signed-off-by: Lee Jones
> ---
Good code size reduction, always a good template for code improvements
Acked-by: Vinod Koul
--
~Vinod
> drivers/dma/ste_dma40.c | 51
> ++-
> 1 file changed, 11 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index ba84df8..57a127e 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -1774,22 +1774,6 @@ static int d40_validate_conf(struct d40_chan *d40c,
> res = -EINVAL;
> }
>
> - if (conf->dir == STEDMA40_MEM_TO_PERIPH &&
> - d40c->base->plat_data->dev_tx[conf->dev_type] == 0 &&
> - d40c->runtime_addr == 0) {
> - chan_err(d40c, "Invalid TX channel address (%d)\n",
> - conf->dev_type);
> - res = -EINVAL;
> - }
> -
> - if (conf->dir == STEDMA40_PERIPH_TO_MEM &&
> - d40c->base->plat_data->dev_rx[conf->dev_type] == 0 &&
> - d40c->runtime_addr == 0) {
> - chan_err(d40c, "Invalid RX channel address (%d)\n",
> - conf->dev_type);
> - res = -EINVAL;
> - }
> -
> if (conf->dir == STEDMA40_PERIPH_TO_PERIPH) {
> /*
>* DMAC HW supports it. Will be added to this driver,
> @@ -2327,14 +2311,10 @@ d40_prep_sg(struct dma_chan *dchan, struct
> scatterlist *sg_src,
> if (sg_next(&sg_src[sg_len - 1]) == sg_src)
> desc->cyclic = true;
>
> - if (direction != DMA_TRANS_NONE) {
> - dma_addr_t dev_addr = d40_get_dev_addr(chan, direction);
> -
> - if (direction == DMA_DEV_TO_MEM)
> - src_dev_addr = dev_addr;
> - else if (direction == DMA_MEM_TO_DEV)
> - dst_dev_addr = dev_addr;
> - }
> + if (direction == DMA_DEV_TO_MEM)
> + src_dev_addr = chan->runtime_addr;
> + else if (direction == DMA_MEM_TO_DEV)
> + dst_dev_addr = chan->runtime_addr;
>
> if (chan_is_logical(chan))
> ret = d40_prep_sg_log(chan, desc, sg_src, sg_dst,
> @@ -2782,15 +2762,8 @@ static int d40_set_runtime_config(struct dma_chan
> *chan,
> dst_maxburst = config->dst_maxburst;
>
> if (config->direction == DMA_DEV_TO_MEM) {
> - dma_addr_t dev_addr_rx =
> - d40c->base->plat_data->dev_rx[cfg->dev_type];
> -
> config_addr = config->src_addr;
> - if (dev_addr_rx)
> - dev_dbg(d40c->base->dev,
> - "channel has a pre-wired RX address %08x "
> - "overriding with %08x\n",
> - dev_addr_rx, config_addr);
> +
> if (cfg->dir != STEDMA40_PERIPH_TO_MEM)
> dev_dbg(d40c->base->dev,
> "channel was not configured for peripheral "
> @@ -2805,15 +2778,8 @@ static int d40_set_runtime_config(struct dma_chan
> *chan,
> dst_maxburst = src_maxburst;
>
> } else if (config->direction == DMA_MEM_TO_DEV) {
> - dma_addr_t dev_addr_tx =
> - d40c->base->plat_data->dev_tx[cfg->dev_type];
> -
> config_addr = config->dst_addr;
> - if (dev_addr_tx)
> - dev_dbg(d40c->base->dev,
> - "channel has a pre-wired TX address %08x "
> - "overriding with %08x\n",
> - dev_addr_tx, config_addr);
> +
> if (cfg->dir != STEDMA40_MEM_TO_PERIPH)
> dev_dbg(d40c->base->dev,
> "channel was not configured for memory "
> @@ -2833,6 +2799,11 @@ static int d40_set_runtime_config(struct dma_chan
> *chan,
> return -EINVAL;
> }
>
> + if (config_addr <= 0) {
> + dev_err(d40c->base->dev, "no address supplied\n");
> + return -EINVAL;
> + }
> +
> if (src_maxburst * src_addr_width != dst_maxburst * dst_addr_width) {
> dev_err(d40c->base->dev,
> "src/dst width/maxburst mismatch: %d*%d != %d*%d\n",
> --
> 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
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
> ---
Acked-by: Vinod Koul
--
~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 08/39] dmaengine: ste_dma40: Remove redundant address fetching function
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
> ---
Acked-by: Vinod Koul
--
~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 03/39] dmaengine: ste_dma40: Don't configure runtime configurable setup during allocate
On Wed, May 15, 2013 at 10:51:26AM +0100, Lee Jones wrote:
> Using the dmaengine API, allocating and configuring a channel are two
> separate actions. Here we're removing logical channel configuration from
> the channel allocating routines.
>
> Cc: Vinod Koul
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Rabin Vincent
> Signed-off-by: Lee Jones
> ---
Acked-by: Vinod Koul
--
~Vinod
> drivers/dma/ste_dma40.c |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
> index b7fe46b..ba84df8 100644
> --- a/drivers/dma/ste_dma40.c
> +++ b/drivers/dma/ste_dma40.c
> @@ -2040,6 +2040,9 @@ static int d40_config_memcpy(struct d40_chan *d40c)
> d40c->dma_cfg = dma40_memcpy_conf_log;
> d40c->dma_cfg.dev_type =
> dma40_memcpy_channels[d40c->chan.chan_id];
>
> + d40_log_cfg(&d40c->dma_cfg,
> + &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> +
> } else if (dma_has_cap(DMA_MEMCPY, cap) &&
> dma_has_cap(DMA_SLAVE, cap)) {
> d40c->dma_cfg = dma40_memcpy_conf_phy;
> @@ -2508,9 +2511,6 @@ static int d40_alloc_chan_resources(struct dma_chan
> *chan)
> d40_set_prio_realtime(d40c);
>
> if (chan_is_logical(d40c)) {
> - d40_log_cfg(&d40c->dma_cfg,
> - &d40c->log_def.lcsp1, &d40c->log_def.lcsp3);
> -
> if (d40c->dma_cfg.dir == STEDMA40_PERIPH_TO_MEM)
> d40c->lcpa = d40c->base->lcpa_base +
> d40c->dma_cfg.dev_type * D40_LCPA_CHAN_SIZE;
> --
> 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 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
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
That needs up update!
> Acked-by: Arnd Bergmann
> Signed-off-by: Lee Jones
> ---
> 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_SR
Re: [PATCH 01/39] dmaengine: ste_dma40: Separate Logical Global Interrupt Mask (GIM) unmasking
On Wed, May 15, 2013 at 06:29:51PM +0200, Linus Walleij wrote: > On Wed, May 15, 2013 at 11:51 AM, Lee Jones 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 > > Cc: Dan Williams > > Cc: Per Forlin > > Cc: Rabin Vincent > > Acked-by: Arnd Bergmann > > Signed-off-by: Lee Jones > > Tentatively applied to my ux500-dma40 branch. > > This lacks an ACK from Vinod... Acked-by: Vinod Koul > > 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 38/39] dmaengine: ste_dma40: Fetch the number of physical channels from DT
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
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Rabin Vincent
> Signed-off-by: Lee Jones
> ---
Acked-by: Vinod Koul
> 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 34/39] dmaengine: ste_dma40: Convert data_width from register bit format to value
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
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Rabin Vincent
> Signed-off-by: Lee Jones
> ---
> @@ -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 39/39] dmaengine: ste_dma40: Fetch disabled channels from DT
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
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Rabin Vincent
> Acked-by: Arnd Bergmann
> Signed-off-by: Lee Jones
Acked-by: Vinod Koul
> ---
> 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 35/39] dmaengine: ste_dma40_ll: Replace meaningless register set with comment
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 > Cc: Dan Williams > Cc: Per Forlin > Cc: Rabin Vincent > Signed-off-by: Lee Jones > --- > 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: [PATCH 31/39] dmaengine: ste_dma40: Replace ST-E's home-brew DMA direction defs with generic ones
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
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Rabin Vincent
> Signed-off-by: Lee Jones
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;
> @@
Re: [PATCH 33/39] dmaengine: ste_dma40_ll: Use the BIT macro to replace ugly '(1 << x)'s
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
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Rabin Vincent
> Signed-off-by: Lee Jones
Acked-by: Vinod Koul
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 phys
Re: [PATCH 36/39] dmaengine: ste_dma40: Allow memcpy channels to be configured from DT
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
> Cc: Dan Williams
> Cc: Per Forlin
> Cc: Rabin Vincent
> Acked-by: Arnd Bergmann
> Signed-off-by: Lee Jones
Acked-by: Vinod Koul
> ---
> .../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 +
Re: Re: Build break on usb-next with exynos_defconfig
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
