Re: [PATCH v2] ioat: remove chanerr mask setting for IOAT v3.x
On Wed, Nov 28, 2012 at 03:46:08AM +0530, Jiang, Dave wrote:
> The existing code set a value in the PCI_CHANERRMSK_INT register
> for a workaround to address a pre-silicon bug on the Intel 5520 IO hub that
> has been fixed when the hardware was released. There is no need for this
> code.
>
> Signed-off-by: Dave Jiang
> ---
>
> drivers/dma/ioat/dma_v3.c |7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/dma/ioat/dma_v3.c b/drivers/dma/ioat/dma_v3.c
> index f7f1dc6..fda3b8a1 100644
> --- a/drivers/dma/ioat/dma_v3.c
> +++ b/drivers/dma/ioat/dma_v3.c
> @@ -1126,12 +1126,7 @@ static int ioat3_reset_hw(struct ioat_chan_common
> *chan)
> chanerr = readl(chan->reg_base + IOAT_CHANERR_OFFSET);
> writel(chanerr, chan->reg_base + IOAT_CHANERR_OFFSET);
>
> - /* -= IOAT ver.3 workarounds =- */
> - /* Write CHANERRMSK_INT with 3E07h to mask out the errors
> - * that can cause stability issues for IOAT ver.3, and clear any
> - * pending errors
> - */
What is this code based against? i dont have above lines in -rc1 or my next?
> - pci_write_config_dword(pdev, IOAT_PCI_CHANERRMASK_INT_OFFSET, 0x3e07);
> + /* clear any pending errors */
> err = pci_read_config_dword(pdev, IOAT_PCI_CHANERR_INT_OFFSET,
> &chanerr);
> if (err) {
> dev_err(&pdev->dev, "channel error register unreachable\n");
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/10] dmatest: update the module to use debugfs
On Mon, Mar 04, 2013 at 11:09:24AM +0200, Andy Shevchenko wrote: > The first approach to get dmatest module more flexible and easier to play > with. > The amount of patches could be reduced, but I would like to get a comments > first on smaller pieces. The entire series creates dmatest.txt file in the > Documentation folder. Similar description is scattered through the commit > messages. > > Module was tested on Intel Medfield and Lynxpoint systems with dw_dmac DMA > controller embedded. Applied thanks... > > Andy Shevchenko (10): > dmatest: cancel thread immediately when asked for > dmatest: allocate memory for pq_coefs from heap > dmatest: create dmatest_info to keep test parameters > dmatest: move dmatest_channels and nr_channels to dmatest_info > dmatest: split test parameters to separate structure > dmatest: run test via debugfs > dmatest: return actual state in 'run' file > dmatest: define MAX_ERROR_COUNT constant > dmatest: gather test results in the linked list > dmatest: append verify result to results > > Documentation/dmatest.txt | 81 + > drivers/dma/dmatest.c | 887 > +++--- > 2 files changed, 832 insertions(+), 136 deletions(-) > create mode 100644 Documentation/dmatest.txt > > -- > 1.8.2.rc0.22.gb3600c3 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: timb_dma: Fix compiler warning
On Tue, Feb 19, 2013 at 10:33:53PM +0200, maxin.j...@gmail.com wrote:
> From: "Maxin B. John"
>
> Fix this compiler warning:
> warning: 'td_remove' defined but not used [-Wunused-function]
>
> Signed-off-by: Maxin B. John
Applied, thanks
> ---
> drivers/dma/timb_dma.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/dma/timb_dma.c b/drivers/dma/timb_dma.c
> index 952f823..26107ba 100644
> --- a/drivers/dma/timb_dma.c
> +++ b/drivers/dma/timb_dma.c
> @@ -823,7 +823,7 @@ static struct platform_driver td_driver = {
> .owner = THIS_MODULE,
> },
> .probe = td_probe,
> - .remove = __exit_p(td_remove),
> + .remove = td_remove,
> };
>
> module_platform_driver(td_driver);
> --
> 1.7.7
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH Resend] dma: pl330: Convert to devm_ioremap_resource()
On Mon, Mar 04, 2013 at 02:36:27PM +0530, Sachin Kamat wrote: > Use the newly introduced devm_ioremap_resource() instead of > devm_request_and_ioremap() which provides more consistent error handling. > > Signed-off-by: Sachin Kamat > Reviewed-by: Thierry Reding Applied thanks > --- > drivers/dma/pl330.c |7 --- > 1 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c > index 7181531..10005ec 100644 > --- a/drivers/dma/pl330.c > +++ b/drivers/dma/pl330.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > > #include "dmaengine.h" > #define PL330_MAX_CHAN 8 > @@ -2904,9 +2905,9 @@ pl330_probe(struct amba_device *adev, const struct > amba_id *id) > pi->mcbufsz = pdat ? pdat->mcbuf_sz : 0; > > res = &adev->res; > - pi->base = devm_request_and_ioremap(&adev->dev, res); > - if (!pi->base) > - return -ENXIO; > + pi->base = devm_ioremap_resource(&adev->dev, res); > + if (IS_ERR(pi->base)) > + return PTR_ERR(pi->base); > > amba_set_drvdata(adev, pdmac); > > -- > 1.7.4.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] dmaengine: add dma_get_slave_sg_limits()
On Wed, Mar 06, 2013 at 02:56:05PM -0500, Matt Porter wrote:
> Add a dmaengine API to retrieve slave SG transfer limits.
>
> The API is optionally implemented by dmaengine drivers and when
> unimplemented will return a NULL pointer. A client driver using
> this API provides the required dma channel, address width, and
> burst size of the transfer. dma_get_slave_sg_limits() returns an
> SG limits structure with the maximum number and size of SG segments
> that the given channel can handle.
>
> Signed-off-by: Matt Porter
> ---
> +static inline struct dma_slave_sg_limits
> +*dma_get_slave_sg_limits(struct dma_chan *chan,
> +enum dma_slave_buswidth addr_width,
> +u32 maxburst)
> +{
> + if (chan->device->device_slave_sg_limits)
> + return chan->device->device_slave_sg_limits(chan,
> + addr_width,
> + maxburst);
Hi Matt,
Sorry for delayed reply, this series was sent just before i went for vacation :)
I agree with Lars, that returning pointer maynot be good idea. So this bit needs
work. Also the readblity of above is bad by complying to 80char limit. I would
make it easier to read
--
~Vinod
> +
> + return NULL;
> +}
> +
> enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
> #ifdef CONFIG_DMA_ENGINE
> enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] dmaengine: add slave sg transfer limits api
On Wed, Mar 06, 2013 at 02:56:04PM -0500, Matt Porter wrote: > Changes since v3: > - Change api name to dma_get_slave_sg_limits() to avoid > confusion with h/w caps which are static. > > Changes since v2: > - Change to a separate slave sg specific api. Drop the > generic per-channel capabilities api that is not used. > > Changes since v1: > - Use the existing dma_transaction_type enums instead of > adding the mostly duplicated dmaengine_apis enums > > This series adds a new dmaengine api, dma_get_slave_sg_limits(), which > may be used by a client driver to get slave SG transfer limits for a > particular channel. At this time, these include the max number of > segments and max length of a segment that a channel can handle for a > SG transfer. Looks fine, should be ready for merge once we fix the API. Also I was under the impression that you will add another API to calculate the limits, the stuff which you were doing in caps API earlier. -- ~Vinod > > Along with the API implementation, this series implements the backend > device_slave_sg_limits() in the EDMA DMA Engine driver and converts the > davinci_mmc driver to use dma_get_slave_sg_limits() to replace hardcoded > limits. > > This is tested on the AM1808-EVM. > > Matt Porter (3): > dmaengine: add dma_get_slave_sg_limits() > dma: edma: add device_slave_sg_limits() support > mmc: davinci: get SG segment limits with dma_get_slave_sg_limits() > > drivers/dma/edma.c| 17 + > drivers/mmc/host/davinci_mmc.c| 37 --- > include/linux/dmaengine.h | 39 > + > include/linux/platform_data/mmc-davinci.h |3 --- > 4 files changed, 66 insertions(+), 30 deletions(-) > > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH REPOST] dma: tegra: assume CONFIG_OF
On Mon, Mar 11, 2013 at 04:30:26PM -0600, Stephen Warren wrote: > From: Stephen Warren > > Tegra only supports, and always enables, device tree. Remove all ifdefs > and runtime checks for DT support from the driver. > > Signed-off-by: Stephen Warren Applied thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: ipu: ipu_idmac: Fix section mismatch
On Tue, Mar 12, 2013 at 08:53:37PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> Since commit 84c1e63c12 (dma: Remove erroneous __exit and __exit_p()
> references)
> the following section mismatch happens:
>
> WARNING: drivers/built-in.o(.text+0x20f94): Section mismatch in reference
> from the function ipu_remove() to the function .exit.text:ipu_idmac_exit()
> The function ipu_remove() references a function in an exit section.
> Often the function ipu_idmac_exit() has valid usage outside the exit section
> and the fix is to remove the __exit annotation of ipu_idmac_exit.
>
> Remove the '__exit' annotation from ipu_idmac_exit in order to fix it.
>
> Signed-off-by: Fabio Estevam
Applied Thanks
--
~Vinod
> ---
> drivers/dma/ipu/ipu_idmac.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
> index d6d5d7e..d39c2cd 100644
> --- a/drivers/dma/ipu/ipu_idmac.c
> +++ b/drivers/dma/ipu/ipu_idmac.c
> @@ -1642,7 +1642,7 @@ static int __init ipu_idmac_init(struct ipu *ipu)
> return dma_async_device_register(&idmac->dma);
> }
>
> -static void __exit ipu_idmac_exit(struct ipu *ipu)
> +static void ipu_idmac_exit(struct ipu *ipu)
> {
> int i;
> struct idmac *idmac = &ipu->idmac;
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DMA: of: Constant names
On Sun, Feb 24, 2013 at 04:36:09PM +0100, Markus Pargmann wrote:
> No DMA of-function alters the name, so this patch changes the name arguments
> to be constant. Most drivers will probably request DMA channels using a
> constant name.
>
> Signed-off-by: Markus Pargmann
Applied thanks
--
~Vinod
> ---
> drivers/dma/dmaengine.c | 2 +-
> drivers/dma/of-dma.c | 6 +++---
> include/linux/dmaengine.h | 4 ++--
> include/linux/of_dma.h| 4 ++--
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 242b8c0..779f43a 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -555,7 +555,7 @@ EXPORT_SYMBOL_GPL(__dma_request_channel);
> * @dev: pointer to client device structure
> * @name:slave channel name
> */
> -struct dma_chan *dma_request_slave_channel(struct device *dev, char *name)
> +struct dma_chan *dma_request_slave_channel(struct device *dev, const char
> *name)
> {
> /* If device-tree is present get slave info from here */
> if (dev->of_node)
> diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
> index 69d04d2..6036cd0 100644
> --- a/drivers/dma/of-dma.c
> +++ b/drivers/dma/of-dma.c
> @@ -172,8 +172,8 @@ EXPORT_SYMBOL_GPL(of_dma_controller_free);
> * specifiers, matches the name provided. Returns 0 if the name matches and
> * a valid pointer to the DMA specifier is found. Otherwise returns -ENODEV.
> */
> -static int of_dma_match_channel(struct device_node *np, char *name, int
> index,
> - struct of_phandle_args *dma_spec)
> +static int of_dma_match_channel(struct device_node *np, const char *name,
> + int index, struct of_phandle_args *dma_spec)
> {
> const char *s;
>
> @@ -198,7 +198,7 @@ static int of_dma_match_channel(struct device_node *np,
> char *name, int index,
> * Returns pointer to appropriate dma channel on success or NULL on error.
> */
> struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
> - char *name)
> + const char *name)
> {
> struct of_phandle_args dma_spec;
> struct of_dma *ofdma;
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index f593999..f062f89 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -968,7 +968,7 @@ enum dma_status dma_sync_wait(struct dma_chan *chan,
> dma_cookie_t cookie);
> enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
> void dma_issue_pending_all(void);
> struct dma_chan *__dma_request_channel(dma_cap_mask_t *mask, dma_filter_fn
> fn, void *fn_param);
> -struct dma_chan *dma_request_slave_channel(struct device *dev, char *name);
> +struct dma_chan *dma_request_slave_channel(struct device *dev, const char
> *name);
> void dma_release_channel(struct dma_chan *chan);
> #else
> static inline enum dma_status dma_wait_for_async_tx(struct
> dma_async_tx_descriptor *tx)
> @@ -984,7 +984,7 @@ static inline struct dma_chan
> *__dma_request_channel(dma_cap_mask_t *mask,
> return NULL;
> }
> static inline struct dma_chan *dma_request_slave_channel(struct device *dev,
> - char *name)
> + const char *name)
> {
> return NULL;
> }
> diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
> index d15073e..ce6a8ab 100644
> --- a/include/linux/of_dma.h
> +++ b/include/linux/of_dma.h
> @@ -40,7 +40,7 @@ extern int of_dma_controller_register(struct device_node
> *np,
> void *data);
> extern int of_dma_controller_free(struct device_node *np);
> extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
> - char *name);
> + const char *name);
> extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
> struct of_dma *ofdma);
> #else
> @@ -58,7 +58,7 @@ static inline int of_dma_controller_free(struct device_node
> *np)
> }
>
> static inline struct dma_chan *of_dma_request_slave_channel(struct
> device_node *np,
> - char *name)
> + const char *name)
> {
> return NULL;
> }
> --
> 1.8.1.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: imx-dma: Remove redundant NULL check before kfree
On Mon, Feb 25, 2013 at 04:46:26AM +0530, Syam Sidhardhan wrote: > kfree on NULL pointer is a no-op. > > Signed-off-by: Syam Sidhardhan Applied thanks > --- > drivers/dma/imx-dma.c |3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c > index 70b8975..0988583 100644 > --- a/drivers/dma/imx-dma.c > +++ b/drivers/dma/imx-dma.c > @@ -859,8 +859,7 @@ static struct dma_async_tx_descriptor > *imxdma_prep_dma_cyclic( > > desc = list_first_entry(&imxdmac->ld_free, struct imxdma_desc, node); > > - if (imxdmac->sg_list) > - kfree(imxdmac->sg_list); > + kfree(imxdmac->sg_list); > > imxdmac->sg_list = kcalloc(periods + 1, > sizeof(struct scatterlist), GFP_KERNEL); > -- > 1.7.9.5 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DMA: OF: Check properties value before running be32_to_cpup() on it
On Fri, Mar 15, 2013 at 02:18:20PM +0530, Viresh Kumar wrote:
> In of_dma_controller_register() routine we are calling of_get_property() as an
> parameter to be32_to_cpup(). In case the property doesn't exist we will get a
> crash.
>
> This patch changes this code to check if we got a valid property first and
> then
> runs be32_to_cpup() on it.
>
> Signed-off-by: Viresh Kumar
> ---
>
> My mails are broken, i have pushed this patch here:
I noticed you used git send-email. Usually it will send patch properly
independent of whatever MUA you use. So I have the patch and its applied now :)
--
~Vinod
>
> http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/dma-of-fix
>
> drivers/dma/of-dma.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
> index 69d04d2..09c7ad1 100644
> --- a/drivers/dma/of-dma.c
> +++ b/drivers/dma/of-dma.c
> @@ -93,6 +93,7 @@ int of_dma_controller_register(struct device_node *np,
> {
> struct of_dma *ofdma;
> int nbcells;
> + const __be32*prop;
>
> if (!np || !of_dma_xlate) {
> pr_err("%s: not enough information provided\n", __func__);
> @@ -103,8 +104,11 @@ int of_dma_controller_register(struct device_node *np,
> if (!ofdma)
> return -ENOMEM;
>
> - nbcells = be32_to_cpup(of_get_property(np, "#dma-cells", NULL));
> - if (!nbcells) {
> + prop = of_get_property(np, "#dma-cells", NULL);
> + if (prop)
> + nbcells = be32_to_cpup(prop);
> +
> + if (!prop || !nbcells) {
> pr_err("%s: #dma-cells property is missing or invalid\n",
> __func__);
> kfree(ofdma);
> --
> 1.7.12.rc2.18.g61b472e
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: request line field in the generic slave config structure
On Mon, Mar 18, 2013 at 01:30:29PM +, Arnd Bergmann wrote: > On Monday 18 March 2013, Shevchenko, Andriy wrote: > > Hello! > > > > It seems the one (as I think good) question was left unanswered: > > http://www.spinics.net/lists/arm-kernel/msg186120.html > > > > What is your opinions, comments? > > I'm not sure I understand what the question was. Is this about > whether we should remove the "slave_id" field in the slave > configuration? Ditto :) The slave_id memeber in dma_slave_config should be used for this > > Those sort of duplicate the request line information that comes > from the platform in a data structure that should be filled by > the device driver without platform specific knowledge. > > I believe that is currently used by shmobile, and we won't be able > to kill that before that platform has been converted to use > dma_request_slave_channel. > > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DMA: OF: Check properties value before running be32_to_cpup() on it
On Thu, Mar 21, 2013 at 03:48:50PM +0530, Viresh Kumar wrote: > On 21 March 2013 15:16, Vinod Koul wrote: > > On Fri, Mar 15, 2013 at 02:18:20PM +0530, Viresh Kumar wrote: > >> In of_dma_controller_register() routine we are calling of_get_property() > >> as an > >> parameter to be32_to_cpup(). In case the property doesn't exist we will > >> get a > >> crash. > >> > >> This patch changes this code to check if we got a valid property first and > >> then > >> runs be32_to_cpup() on it. > >> > >> Signed-off-by: Viresh Kumar > >> --- > >> > >> My mails are broken, i have pushed this patch here: > > I noticed you used git send-email. Usually it will send patch properly > > independent of whatever MUA you use. > > Probably not!! Its the famous (Infamous) Microsoft exchange server working in > background and it breaks mails without treating mails coming from git > send-email > specially :) I have seen usually receiving patches is a problem, not sending. at least at my work place till now my sent patches have not been broken but what I receive has thus forcing me to use non exchange accounts for receiving email but somehow situation is better for receiving too :) -- ~Vinod > > > So I have the patch and its applied now :) > > I have seen this kind of discrimination on breaking patches based on the size > of > patch. If its very small (like this one), you may get a unbroken patch > but if the size > is a bit large then nobody can save you :) > > -- > viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: don't wait for FIFO_EMPTY endlessly in dwc_chan_pause
On Thu, Mar 21, 2013 at 11:49:17AM +0200, Andy Shevchenko wrote:
> When we pause the channel after transfer is completed we might stuck in the
> dwc_chan_pause() because the FIFO_EMPTY flag will never be asserted. To avoid
> the endless loop we introduce a timeout here (*). The proper solution is to
> somehow get the residue in FIFO and avoid busyloop when transfer is done, but
> this task is not simple and fast.
>
> Unfortunately we can't use cpu_relax() in conjunction with jiffies checker,
> due
> to we have interrupts disabled by spin_lock_irqsave() and there is a big
> chance
> that no interrupts will come to update the jiffies..
>
> (*) The worst case is
> AHB write * FIFO size / hclk = 5.12 us,
> where
> AHB write = 2 cycles,
> hclk = 100 MHz,
> burst size = 1 byte,
> FIFO size = 256 bytes.
> The proposed 40us timeout might be considered as a big one, though we
> enter
> to that state only when we have the transfer already completed.
>
> Signed-off-by: Andy Shevchenko
Applied Thanks
> ---
> drivers/dma/dw_dmac.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index 43a5329..43e2e89 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -1030,10 +1030,11 @@ set_runtime_config(struct dma_chan *chan, struct
> dma_slave_config *sconfig)
> static inline void dwc_chan_pause(struct dw_dma_chan *dwc)
> {
> u32 cfglo = channel_readl(dwc, CFG_LO);
> + unsigned int count = 20;/* timeout iterations */
>
> channel_writel(dwc, CFG_LO, cfglo | DWC_CFGL_CH_SUSP);
> - while (!(channel_readl(dwc, CFG_LO) & DWC_CFGL_FIFO_EMPTY))
> - cpu_relax();
> + while (!(channel_readl(dwc, CFG_LO) & DWC_CFGL_FIFO_EMPTY) && count--)
> + udelay(2);
>
> dwc->paused = true;
> }
> --
> 1.8.2.rc0.22.gb3600c3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: adjust slave_id accordingly to request line base
On Tue, Jan 29, 2013 at 10:29:43AM +0530, Viresh Kumar wrote:
> Next time, please direct these mails to my Linaro id :)
>
> On Mon, Jan 28, 2013 at 4:34 PM, Andy Shevchenko
> wrote:
> > On some hardware configurations we have got the request line with the
> > offset.
> > The patch introduces convert_slave_id() helper for that cases. The request
> > line
> > base is got from the platform device resources provided by the
> > IORESOURCE_DMA
> > type.
>
> @Vinod: Is IORESOURCE_DMA suitable for this purpose?
Looks unlikely...
But why do we need this in first place?
I know this is due to common platform probe. Clearly one size not fitting all.
If you had dedicated PCI probe you wouldnt worrry right?
--
~Vinod
>
> > Signed-off-by: Mika Westerberg
> > Signed-off-by: Andy Shevchenko
> > ---
> > drivers/dma/dw_dmac.c | 13 +
> > drivers/dma/dw_dmac_regs.h |1 +
> > 2 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> > index 3155c11..8484ca1 100644
> > --- a/drivers/dma/dw_dmac.c
> > +++ b/drivers/dma/dw_dmac.c
> > @@ -995,6 +995,13 @@ static inline void convert_burst(u32 *maxburst)
> > *maxburst = 0;
> > }
> >
> > +static inline void convert_slave_id(struct dw_dma_chan *dwc)
> > +{
> > + struct dw_dma *dw = to_dw_dma(dwc->chan.device);
> > +
> > + dwc->dma_sconfig.slave_id -= dw->request_line_base;
> > +}
> > +
> > static int
> > set_runtime_config(struct dma_chan *chan, struct dma_slave_config *sconfig)
> > {
> > @@ -1009,6 +1016,7 @@ set_runtime_config(struct dma_chan *chan, struct
> > dma_slave_config *sconfig)
> >
> > convert_burst(&dwc->dma_sconfig.src_maxburst);
> > convert_burst(&dwc->dma_sconfig.dst_maxburst);
> > + convert_slave_id(dwc);
> >
> > return 0;
> > }
> > @@ -1717,6 +1725,11 @@ static int dw_probe(struct platform_device *pdev)
> > memcpy(dw->data_width, pdata->data_width, 4);
> > }
> >
> > + /* Get the base request line if set */
> > + io = platform_get_resource(pdev, IORESOURCE_DMA, 0);
> > + if (io)
> > + dw->request_line_base = (unsigned int)io->start;
> > +
>
> How will it work in case of DT?
>
> > /* Calculate all channel mask before DMA setup */
> > dw->all_chan_mask = (1 << nr_channels) - 1;
> >
> > diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
> > index 88dd8eb..3eeb766 100644
> > --- a/drivers/dma/dw_dmac_regs.h
> > +++ b/drivers/dma/dw_dmac_regs.h
> > @@ -248,6 +248,7 @@ struct dw_dma {
> > /* hardware configuration */
> > unsigned char nr_masters;
> > unsigned char data_width[4];
> > + unsigned intrequest_line_base;
> >
> > struct dw_dma_chan chan[0];
> > };
>
> --
> viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: adjust slave_id accordingly to request line base
On Wed, Jan 30, 2013 at 09:32:56AM +0200, Andy Shevchenko wrote: > On Tue, 2013-01-29 at 20:57 +0530, Viresh Kumar wrote: > > On Tue, Jan 29, 2013 at 10:52 AM, Mika Westerberg > > wrote: > > > We had a discusssion about this with Andy as well. The thing is that there > > > is no way in current resource to pass DMA request line numbers supported > > > by > > > the controller to the driver in a generic way. We on the other hand have > > > to > > > deal this somehow as we have a shared DMA controller on Lynxpoint where > > > the > > > offset will start from 16 (but it might be something else as well). > > > > > > Is there something which limits the usage of IORESOUCE_DMA to be only > > > usable for ISA DMA channels? > > > > Andy, > > > > Why do we need this request_line_base? Why not program the actual value > > directly into the slave structure (base + offset)? > > Slave device exactly has knowledge about this number slave_id = (base > +offset). However... Btw request line needs to be programmed by client in slave_id field. So why exactly is this required for dma driver? -- ~Vinod > > In case it is required, add it in platform data field or can add DT > > binding for it. > > We get a device from the ACPI CSRT table. During enumeration we don't > know what kind of the device it is. From the enumeration point of view > each device enumerated from CSRT is a platform device (see > drivers/acpi/csrt.c for the details). > > That's why we have to pass this info somehow to the DMAC driver. And > like Mika already mentioned we have no other generic way except > IORESOURCE_DMA. If you have something better in mind, please share. We > could adopt our code then. > > > -- > Andy Shevchenko > Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: add support for Lynxpoint DMA controllers
On Fri, Feb 08, 2013 at 09:25:11AM +0200, Andy Shevchenko wrote: > On Fri, Feb 8, 2013 at 6:28 AM, Viresh Kumar wrote: > > On Thu, Feb 7, 2013 at 10:35 PM, Andy Shevchenko > > wrote: > >> On Thu, Feb 7, 2013 at 5:39 PM, Viresh Kumar > >> wrote: > >>> On 7 February 2013 21:06, Andy Shevchenko > >>> wrote: > From: Mika Westerberg > ... > Signed-off-by: Andy Shevchenko > >>> > >>> Looks like Mika is Author and you have your signed-off :) > >> > >> In this literally small and clear patch it doesn't matter who is who. > > > > I believe it doesn't matter how small or big is the patch, but the author > > should > > be there in SOBs too.. > True. Then in that case you need to re-read Documentation/SubmittingPatches SOB is also acnowlegement of Origin of the Code, hence mandatory even for single line of change. > > > >> However for sake of equity I could add Mika's signed-off-by as well. > >> > >> It should be: > >> Signed-off-by: Mika Westerberg > > > > Thanks. > > Shall I resend it? It will fix it up, and thanks to greg now you owe me a beverage :) > > -- > With Best Regards, > Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: apply default dma_mask if needed
On Tue, Jan 29, 2013 at 05:06:24PM +0200, Andy Shevchenko wrote:
> In some cases we got the device without dma_mask configured. We have to apply
> the default value to avoid crashes during memory mapping.
>
what was this generated against, it fails to apply for me.
> Signed-off-by: Andy Shevchenko
> ---
> drivers/dma/dw_dmac.c |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index e8d0679..a572a1e 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -1673,6 +1673,12 @@ static int dw_probe(struct platform_device *pdev)
> if (IS_ERR(regs))
> return PTR_ERR(regs);
>
> + /* Apply default dma_mask if needed */
> + if (!pdev->dev.dma_mask) {
> + pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + }
> +
> dw_params = dma_read_byaddr(regs, DW_PARAMS);
> autocfg = dw_params >> DW_PARAMS_EN & 0x1;
>
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: add support for Lynxpoint DMA controllers
On Thu, Feb 07, 2013 at 05:36:28PM +0200, Andy Shevchenko wrote:
> From: Mika Westerberg
>
> Intel Lynxpoint PCH Low Power Subsystem has DMA controller to support general
> purpose serial buses like SPI, I2C, and HSUART. This controller is enumerated
> from ACPI namespace with ACPI ID INTL9C60.
>
Applied with correct SOBs...
> Signed-off-by: Andy Shevchenko
> ---
> drivers/dma/dw_dmac.c |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index d6abea8..5feee76 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -1977,6 +1977,11 @@ static const struct of_device_id dw_dma_id_table[] = {
> MODULE_DEVICE_TABLE(of, dw_dma_id_table);
> #endif
>
> +static const struct platform_device_id dw_dma_ids[] = {
> + { "INTL9C60", 0 },
> + { }
> +};
> +
> static struct platform_driver dw_driver = {
> .probe = dw_probe,
> .remove = dw_remove,
> @@ -1986,6 +1991,7 @@ static struct platform_driver dw_driver = {
> .pm = &dw_dev_pm_ops,
> .of_match_table = of_match_ptr(dw_dma_id_table),
> },
> + .id_table = dw_dma_ids,
> };
>
> static int __init dw_init(void)
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ioatdma: fix race between updating ioat->head and IOAT_COMPLETION_PENDING
On Thu, Feb 07, 2013 at 02:38:32PM -0700, Dave Jiang wrote: > There is a race that can hit during __cleanup() when the ioat->head pointer is > incremented during descriptor submission. The __cleanup() can clear the > PENDING flag when it does not see any active descriptors. This causes new > submitted descriptors to be ignored because the COMPLETION_PENDING flag is > cleared. This was introduced when code was adapted from ioatdma v1 to ioatdma > v2. For v2 and v3, IOAT_COMPLETION_PENDING flag will be abandoned and a new > flag IOAT_CHAN_ACTIVE will be utilized. This flag will also be protected under > the prep_lock when being modified in order to avoid the race. > > Signed-off-by: Dave Jiang > Reviewed-by: Dan Williams Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 07/10] dmaengine: add dma_request_slave_channel_compat()
On Fri, Feb 01, 2013 at 01:22:52PM -0500, Matt Porter wrote:
> Adds a dma_request_slave_channel_compat() wrapper which accepts
> both the arguments from dma_request_channel() and
> dma_request_slave_channel(). Based on whether the driver is
> instantiated via DT, the appropriate channel request call will be
> made.
>
> This allows for a much cleaner migration of drivers to the
> dmaengine DT API as platforms continue to be mixed between those
> that boot using DT and those that do not.
>
> Suggested-by: Tony Lindgren
> Signed-off-by: Matt Porter
> Acked-by: Tony Lindgren
> Acked-by: Arnd Bergmann
Acked-by: Vinod Koul
> ---
> include/linux/dmaengine.h | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index bfcdecb..17d8ffd 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -1001,6 +1001,22 @@ void dma_run_dependencies(struct
> dma_async_tx_descriptor *tx);
> struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
> struct dma_chan *net_dma_find_channel(void);
> #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
> +#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
> + __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
> +
> +static inline struct dma_chan
> +*__dma_request_slave_channel_compat(dma_cap_mask_t *mask, dma_filter_fn fn,
> + void *fn_param, struct device *dev,
> + char *name)
> +{
> + struct dma_chan *chan;
> +
> + chan = dma_request_slave_channel(dev, name);
> + if (chan)
> + return chan;
> +
> + return __dma_request_channel(mask, fn, fn_param);
> +}
>
> /* --- Helper iov-locking functions --- */
>
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] dmaengine: add dma_get_slave_sg_caps()
On Mon, Feb 04, 2013 at 02:47:02PM -0500, Matt Porter wrote:
> Add a dmaengine API to retrieve slave SG transfer capabilities.
>
> The API is optionally implemented by dmaengine drivers and when
> unimplemented will return a NULL pointer. A client driver using
> this API provides the required dma channel, address width, and
> burst size of the transfer. dma_get_slave_sg_caps() returns an
> SG caps structure with the maximum number and size of SG segments
> that the given channel can handle.
Okay this sounds much better :-)
few points though:
- you added API for caps, but is actually calculating for given configuration
the max allowed range. IMHO that is not caps, perhaps renaming to get_max_sg
/some_better_name would be more apt.
- Still I like the idea of caps, but it should give H/W support capablity. If
you want to add that, pls develop on same line...
--
~Vinod
>
> Signed-off-by: Matt Porter
> ---
> include/linux/dmaengine.h | 40
> 1 file changed, 40 insertions(+)
>
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index d3201e4..5b5b220 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -371,6 +371,19 @@ struct dma_slave_config {
> unsigned int slave_id;
> };
>
> +/* struct dma_slave_sg_caps - expose SG transfer capability of a
> + * channel.
> + *
> + * @max_seg_nr: maximum number of SG segments supported on a SG/SLAVE
> + * channel (0 for no maximum or not a SG/SLAVE channel)
> + * @max_seg_len: maximum length of SG segments supported on a SG/SLAVE
> + *channel (0 for no maximum or not a SG/SLAVE channel)
> + */
> +struct dma_slave_sg_caps {
> + u32 max_seg_nr;
> + u32 max_seg_len;
> +};
> +
> static inline const char *dma_chan_name(struct dma_chan *chan)
> {
> return dev_name(&chan->dev->device);
> @@ -534,6 +547,7 @@ struct dma_tx_state {
> * struct with auxiliary transfer status information, otherwise the call
> * will just return a simple status code
> * @device_issue_pending: push pending transactions to hardware
> + * @device_slave_sg_caps: return the slave SG capabilities
> */
> struct dma_device {
>
> @@ -602,6 +616,9 @@ struct dma_device {
> dma_cookie_t cookie,
> struct dma_tx_state *txstate);
> void (*device_issue_pending)(struct dma_chan *chan);
> + struct dma_slave_sg_caps *(*device_slave_sg_caps)(
> + struct dma_chan *chan, enum dma_slave_buswidth addr_width,
> + u32 maxburst);
> };
>
> static inline int dmaengine_device_control(struct dma_chan *chan,
> @@ -969,6 +986,29 @@ dma_set_tx_state(struct dma_tx_state *st, dma_cookie_t
> last, dma_cookie_t used,
> }
> }
>
> +/**
> + * dma_get_slave_sg_caps - get DMAC SG transfer capabilities
> + * @chan: target DMA channel
> + * @addr_width: address width of the DMA transfer
> + * @maxburst: maximum DMA transfer burst size
> + *
> + * Get SG transfer capabilities for a specified channel. If the dmaengine
> + * driver does not implement SG transfer capabilities then NULL is
> + * returned.
> + */
> +static inline struct dma_slave_sg_caps
> +*dma_get_slave_sg_caps(struct dma_chan *chan,
> +enum dma_slave_buswidth addr_width,
> +u32 maxburst)
> +{
> + if (chan->device->device_slave_sg_caps)
> + return chan->device->device_slave_sg_caps(chan,
> + addr_width,
> + maxburst);
> +
> + return NULL;
> +}
> +
> enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie);
> #ifdef CONFIG_DMA_ENGINE
> enum dma_status dma_wait_for_async_tx(struct dma_async_tx_descriptor *tx);
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: adjust slave_id accordingly to request line base
On Tue, Feb 12, 2013 at 06:43:51PM +0200, Mika Westerberg wrote: > On Tue, Feb 12, 2013 at 07:53:34AM -0800, Vinod Koul wrote: > > On Tue, Jan 29, 2013 at 10:29:43AM +0530, Viresh Kumar wrote: > > > Next time, please direct these mails to my Linaro id :) > > > > > > On Mon, Jan 28, 2013 at 4:34 PM, Andy Shevchenko > > > wrote: > > > > On some hardware configurations we have got the request line with the > > > > offset. > > > > The patch introduces convert_slave_id() helper for that cases. The > > > > request line > > > > base is got from the platform device resources provided by the > > > > IORESOURCE_DMA > > > > type. > > > > > > @Vinod: Is IORESOURCE_DMA suitable for this purpose? > > Looks unlikely... > > > > But why do we need this in first place? > > > > I know this is due to common platform probe. Clearly one size not fitting > > all. > > If you had dedicated PCI probe you wouldnt worrry right? > > This is all related to new ACPI 5.0 features for devices enumerated from > ACPI namespace, such as SPI controller. > > ACPI 5.0 allows BIOS to specify DMA request lines and channels used by a > slave device with FixedDMA() descriptors, such as: > > FixedDMA (0x0010, 0x, Width32bit,) // TX > FixedDMA (0x0011, 0x0001, Width32bit,) // RX > > The first field (0x10, 0x11) is the request line assigned to the device. In > this particular case it is the SPI controller. > > Now there is only one DMA controller in this platform but the request lines > still start from 0x10 (16). > > Then there is another ACPI table called CSRT (Core System Resources Table) > that assings request line range to the DMA controller itself. This range > starts from 0x10 (16) for this platform. > > So what we do is that we parse this CSRT table, create platform device for > the DMA controller of found and pass the request line range as > IORESOURCE_DMA resource with the platform device. Okay, who parses the CSRT table and how is this presented to OS. Can we do this in platform data and complete the base calculation. In ACPI 5, is DMA a PCI device or platfrom device? -- ~Vinod > > In this patch then Andy uses that resource to map the FixedDMA() request > line to the actual hardware request line, which is for the SPI case: > > 0x10 -> 0 > 0x11 -> 1 > > Unfortunately we didn't find any better way to pass this information than > IORESOURCE_DMA. However, if you have better solution we certainly can > change that :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of: dma.c: fix memory leakage
On Tue, Jan 22, 2013 at 10:10:53AM +, Cong Ding wrote: > On Sun, Jan 20, 2013 at 04:24:49PM -0600, Rob Herring wrote: > > On 01/19/2013 07:06 AM, Cong Ding wrote: > > > The memory allocated to ofdma might be a leakage when error occurs. > > > > > > Signed-off-by: Cong Ding > > > > You need to send this to whomever is working on DMA bindings. > Thank you bob, I added Vinod the the receiver list. I have moved the of/dma.c to dma/of-dma.c, can you regenerate this patch and resend to me -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] dma: pl330: Use the generic of_dma_xlate_by_chan_id
On Tue, Apr 02, 2013 at 12:44:36PM +0200, Lars-Peter Clausen wrote: > On 04/02/2013 11:12 AM, PADMAVATHI VENNA wrote: > >> Use the generic of_dma_xlate_by_chan_id xlate callback instead of a custom > >> implementation. Hi Padma, Can you please fix your MUA to 1) not break the message ids 2) reply inline which makes a distinction for quoted text > >> > >> There is one minor difference between the generic of_dma_xlate_by_chan_id > >> function and the pl330 specific one. of_dma_xlate_by_chan_id only sets the > >> DMA_SLAVE capability for the channel capability mask, while the pl330 > >> driver > >> additionally sets the DMA_CYCLIC capability. But since all pl330 channels > >> which > >> have the DMA_SLAVE capability set also have DMA_CYCLIC capability set both > >> functions will have the same result. > >> > >> I am not clear about the dma capabilities. Is it mentioned some where that > >> if we set DMA_SLAVE capability > >> will that also set DMA_CYCLIC capability? > >> > > > > Well DMA_SLAVE won't automatically set DMA_CYCLIC. But the driver sets both. > > > > I tested your patches, it's woking for audio. But I need some clarification > > related to capabilities. > > As per my understanding, controller driver registers the available > > capabilities in the probe and > > client drivers requests for a particular capability. In both the cases, in > > the dmaengine it checks > > if the requested capability is satisfied. > > If we don't set the DMA_CYCLIC, how __dma_device_satisfies_mask works? > > > > Please correct me if I am wrong. > > > > Thanks > > Padma > > Hi, > > Well, DMA_SLAVE | DMA_CYCLIC is a more restrictive mask than DMA_SLAVE. So > any channel that matches DMA_SLAVE | DMA_CYCLIC will also match DMA_SLAVE. DMA_SLAVE means that controllers channel can do slave transactions and should support the slave APIs. DMA_CYCLIC means that controller can do a cyclic transfers for the sg list sent and will do so untill channel is aborted Now we are talking about DMA_CYCLIC for periphrals only so DMA_SLAVE cna be implied and is usually the normal usage though nothing prevent you from doing a cyclic memcpy if you would wish. Right thing would be to set mask aptly on both sides, and since you are doing DMA_CYCLIC, i would expect both the controller and client have done this, if not we need this to be fixed :) -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] dmaengine: mpc512x_dma: use generic DMA DT bindings
On Sun, Mar 31, 2013 at 06:17:59PM +0200, Anatolij Gustschin wrote:
> Add generic DMA bindings and register the DMA controller
> to DT DMA helpers.
I need someone who understands DT better than me to comment/ack...
Arnd...?
>
> Signed-off-by: Anatolij Gustschin
> ---
> arch/powerpc/boot/dts/mpc5121.dtsi |5 ++-
> drivers/dma/mpc512x_dma.c | 63
> ++--
> 2 files changed, 64 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi
> b/arch/powerpc/boot/dts/mpc5121.dtsi
> index 723e292..d1fe070 100644
> --- a/arch/powerpc/boot/dts/mpc5121.dtsi
> +++ b/arch/powerpc/boot/dts/mpc5121.dtsi
> @@ -384,10 +384,13 @@
> interrupts = <40 0x8>;
> };
>
> - dma@14000 {
> + dma0: dma@14000 {
> compatible = "fsl,mpc5121-dma";
> reg = <0x14000 0x1800>;
> interrupts = <65 0x8>;
> + #dma-cells = <1>;
> + #dma-channels = <64>;
> + #dma-requests = <64>;
> };
> };
>
> diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
> index 2d95673..bc6c356 100644
> --- a/drivers/dma/mpc512x_dma.c
> +++ b/drivers/dma/mpc512x_dma.c
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -641,6 +642,44 @@ mpc_dma_prep_memcpy(struct dma_chan *chan, dma_addr_t
> dst, dma_addr_t src,
> return &mdesc->desc;
> }
>
> +struct mpc_dma_filter_args {
> + struct mpc_dma *mdma;
> + unsigned int chan_id;
> +};
> +
> +static bool mpc_dma_filter(struct dma_chan *chan, void *param)
> +{
> + struct mpc_dma_filter_args *fargs = param;
> +
> + if (chan->device != &fargs->mdma->dma)
> + return false;
> +
> + return (chan->chan_id == fargs->chan_id);
> +}
> +
> +static struct dma_chan *mpc_dma_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + int count = dma_spec->args_count;
> + struct mpc_dma *mdma = ofdma->of_dma_data;
> + struct mpc_dma_filter_args fargs;
> + dma_cap_mask_t cap;
> +
> + if (!mdma)
> + return NULL;
> +
> + if (count != 1)
> + return NULL;
> +
> + fargs.mdma = mdma;
> + fargs.chan_id = dma_spec->args[0];
> +
> + dma_cap_zero(cap);
> + dma_cap_set(DMA_SLAVE, cap);
> +
> + return dma_request_channel(cap, mpc_dma_filter, &fargs);
> +}
> +
> static int mpc_dma_probe(struct platform_device *op)
> {
> struct device_node *dn = op->dev.of_node;
> @@ -791,11 +830,26 @@ static int mpc_dma_probe(struct platform_device *op)
> /* Register DMA engine */
> dev_set_drvdata(dev, mdma);
> retval = dma_async_device_register(dma);
> - if (retval) {
> - devm_free_irq(dev, mdma->irq, mdma);
> - irq_dispose_mapping(mdma->irq);
> + if (retval)
> + goto reg_err;
> +
> + if (dev->of_node) {
> + retval = of_dma_controller_register(dev->of_node,
> + mpc_dma_xlate, mdma);
> + if (retval) {
> + dev_err(&op->dev,
> + "could not register of_dma_controller\n");
> + goto of_err;
> + }
> }
>
> + return 0;
> +
> +of_err:
> + dma_async_device_unregister(&mdma->dma);
> +reg_err:
> + devm_free_irq(dev, mdma->irq, mdma);
> + irq_dispose_mapping(mdma->irq);
> return retval;
> }
>
> @@ -804,6 +858,9 @@ static int mpc_dma_remove(struct platform_device *op)
> struct device *dev = &op->dev;
> struct mpc_dma *mdma = dev_get_drvdata(dev);
>
> + if (dev->of_node)
> + of_dma_controller_free(dev->of_node);
> +
> dma_async_device_unregister(&mdma->dma);
> devm_free_irq(dev, mdma->irq, mdma);
> irq_dispose_mapping(mdma->irq);
> --
> 1.7.5.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] dmaengine: add per channel capabilities api
On Mon, Jan 21, 2013 at 01:19:23PM -0500, Matt Porter wrote: > > b) Sg segment length and numbers: Well these are capabilities, so it tells > > you what is the maximum I can do. IMO it doesn't make sense to tie it down > > to > > burst, width etc. For that configuration you are checking maximum. What this > > needs to return is what is the maximum length it supports and maximum > > number of > > sg list the h/w can use. Also if you return your burst and width capablity, > > then > > any client can easily find out what is the length byte value it can hold. > > Ok, so I could report the max burst size to the client, but on EDMA it's > going to be SZ_64K-1, as that's the hw limit. Max addr width would also > be the same or capped at the maximum enum the current API support of 8 > bytes. Yes IMO you should report the h/w limit and let client deduce what can be done with that h/w limit given the other parameters (burst, length etc...) > > This information is not useful to the client in my case. Only the client > knows its FIFO size, and thus the actual burst size it needs to request > as that is a value specific to the IP the client driver controls. So it > knows actual burst size and the width of that fifo transfer, because we > already support telling the dmaengine driver this info in the current > API. Your current API way is not very generic. We need to make sure it useful on other systems too. That is why it would make sense to query the DMA H/W capablities and then use it with above properties to get various parameters used for initiating a transfer, that way you dont need to set slave parameters -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/4] dw_dmac: return actual residue value
On Fri, Jan 25, 2013 at 11:47:59AM +0200, Andy Shevchenko wrote: > The patch series is targeted for getting proper residue value. Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: move soft LLP code from tasklet to dwc_scan_descriptors
> On Fri, Jan 18, 2013 at 5:44 PM, Andy Shevchenko > > The proper place for the main logic of the soft LLP mode is > > dwc_scan_descriptors. It prevents to get the transfer unexpectedly aborted > > in > > case the user calls dwc_tx_status. Can you rebase this, it failed to apply for me -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: print out DW_PARAMS and DWC_PARAMS when debug
On Fri, Jan 18, 2013 at 05:10:59PM +0200, Andy Shevchenko wrote: > It's usefull to have the values of the DW_PARAMS and DWC_PARAMS printed when > debug mode is enabled. Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/33] dma: Convert to devm_ioremap_resource()
On Mon, Jan 21, 2013 at 11:09:00AM +0100, Thierry Reding wrote: > Convert all uses of devm_request_and_ioremap() to the newly introduced > devm_ioremap_resource() which provides more consistent error handling. > > devm_ioremap_resource() provides its own error messages so all explicit > error messages can be removed from the failure code paths. Where is this symbol, applying this results in build failures for me? > > Signed-off-by: Thierry Reding > Cc: Vinod Koul > --- > drivers/dma/dw_dmac.c | 7 --- > drivers/dma/imx-dma.c | 7 --- > drivers/dma/mmp_pdma.c| 7 --- > drivers/dma/mmp_tdma.c| 7 --- > drivers/dma/tegra20-apb-dma.c | 10 -- > 5 files changed, 20 insertions(+), 18 deletions(-) > > diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c > index 3e8ba02..b33d1f6 100644 > --- a/drivers/dma/dw_dmac.c > +++ b/drivers/dma/dw_dmac.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1489,9 +1490,9 @@ static int dw_probe(struct platform_device *pdev) > if (irq < 0) > return irq; > > - regs = devm_request_and_ioremap(&pdev->dev, io); > - if (!regs) > - return -EBUSY; > + regs = devm_ioremap_resource(&pdev->dev, io); > + if (IS_ERR(regs)) > + return PTR_ERR(regs); > > dw_params = dma_read_byaddr(regs, DW_PARAMS); > autocfg = dw_params >> DW_PARAMS_EN & 0x1; > diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c > index dbf0e6f..84ae491 100644 > --- a/drivers/dma/imx-dma.c > +++ b/drivers/dma/imx-dma.c > @@ -14,6 +14,7 @@ > * http://www.opensource.org/licenses/gpl-license.html > * http://www.gnu.org/copyleft/gpl.html > */ > +#include > #include > #include > #include > @@ -1011,9 +1012,9 @@ static int __init imxdma_probe(struct platform_device > *pdev) > imxdma->devtype = pdev->id_entry->driver_data; > > res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > - imxdma->base = devm_request_and_ioremap(&pdev->dev, res); > - if (!imxdma->base) > - return -EADDRNOTAVAIL; > + imxdma->base = devm_ioremap_resource(&pdev->dev, res); > + if (IS_ERR(imxdma->base)) > + return PTR_ERR(imxdma->base); > > irq = platform_get_irq(pdev, 0); > if (irq < 0) > diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c > index c6d98c0..dc74665 100644 > --- a/drivers/dma/mmp_pdma.c > +++ b/drivers/dma/mmp_pdma.c > @@ -5,6 +5,7 @@ > * it under the terms of the GNU General Public License version 2 as > * published by the Free Software Foundation. > */ > +#include > #include > #include > #include > @@ -782,9 +783,9 @@ static int mmp_pdma_probe(struct platform_device *op) > if (!iores) > return -EINVAL; > > - pdev->base = devm_request_and_ioremap(pdev->dev, iores); > - if (!pdev->base) > - return -EADDRNOTAVAIL; > + pdev->base = devm_ioremap_resource(pdev->dev, iores); > + if (IS_ERR(pdev->base)) > + return PTR_ERR(pdev->base); > > of_id = of_match_device(mmp_pdma_dt_ids, pdev->dev); > if (of_id) > diff --git a/drivers/dma/mmp_tdma.c b/drivers/dma/mmp_tdma.c > index a9f1cd5..43d5a6c 100644 > --- a/drivers/dma/mmp_tdma.c > +++ b/drivers/dma/mmp_tdma.c > @@ -9,6 +9,7 @@ > * > */ > > +#include > #include > #include > #include > @@ -547,9 +548,9 @@ static int mmp_tdma_probe(struct platform_device *pdev) > if (!iores) > return -EINVAL; > > - tdev->base = devm_request_and_ioremap(&pdev->dev, iores); > - if (!tdev->base) > - return -EADDRNOTAVAIL; > + tdev->base = devm_ioremap_resource(&pdev->dev, iores); > + if (IS_ERR(tdev->base)) > + return PTR_ERR(tdev->base); > > INIT_LIST_HEAD(&tdev->device.channels); > > diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c > index c39e61b..7d6d8b4 100644 > --- a/drivers/dma/tegra20-apb-dma.c > +++ b/drivers/dma/tegra20-apb-dma.c > @@ -21,6 +21,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -1236,12 +1237,9 @@ static int tegra_dma_probe(struct platform_device > *pdev) > return -EINVAL; > } > > - tdma->base_addr = devm_request_and_ioremap(&pdev->dev, res); > - if (!tdma->
Re: crypto: omap-sham, omap-aes and dma_request_slave_channel_compat()
On Tue, Feb 26, 2013 at 03:52:05PM -0700, Mark A. Greer wrote: > [CC'ing more people & lists.] > > On Tue, Feb 26, 2013 at 11:36:46AM -0700, Tim Gardner wrote: > > Whats up with commits 0e87e73f4abe1ada69cf780fe2550c6361a1b53b and > > b4b87a934c30fb91cbdd18ae028acdc361e1cf0f. As far as I can tell, > > dma_request_slave_channel_compat() does not exist in 3.9 as of > > 52caa59ed335616c5254adff7911465a57ed9f14, nor does it exist in > > linux-next as of Feb 26. Am I just being dense ? > > Yeah, order got a little messed up. The problem is known and the > sub-thread talking about it starts about here: > > http://www.spinics.net/lists/arm-kernel/msg225241.html > > with the conclusion (AFAICT) that Vinod is to push it: > > http://www.spinics.net/lists/arm-kernel/msg226062.html > > > Reverting those 2 commits at least allows the compile complete. > > When the dependencies are sorted out, will you revert the revert > or do I need to do something? Yes we had agreed that I will send it. I have applied this one now, and will send second PULL request to Linus soon. Arnd, The second patch of dw_dmac you wnated to send me fails to apply for me. Can you either rebase or send with your updates with my ack? Either ways let me know -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: crypto: omap-sham, omap-aes and dma_request_slave_channel_compat()
On Wed, Feb 27, 2013 at 09:36:03PM +, Arnd Bergmann wrote:
> On Wednesday 27 February 2013, Vinod Koul wrote:
> > Yes we had agreed that I will send it.
> >
> > I have applied this one now, and will send second PULL request to Linus
> > soon.
> >
> > Arnd,
> > The second patch of dw_dmac you wnated to send me fails to apply for me.
> > Can you
> > either rebase or send with your updates with my ack?
>
> I would prefer if you send the patch. I've rebased my patch on top of
> today's upstream tree but could not see any difference to my previous
> version. Anyway, here it is again.
Thanks, I have applied and pushed it now :)
I will send PULL to linus this evening...
--
~Vinod
>
> Arnd
>
> 8<--
> Subject: [PATCH] dmaengine: dw_dmac: move to generic DMA binding
>
> The original device tree binding for this driver, from Viresh Kumar
> unfortunately conflicted with the generic DMA binding, and did not allow
> to completely seperate slave device configuration from the controller.
>
> This is an attempt to replace it with an implementation of the generic
> binding, but it is currently completely untested, because I do not have
> any hardware with this particular controller.
>
> The patch applies on top of the slave-dma tree, which contains both the base
> support for the generic DMA binding, as well as the earlier attempt from
> Viresh. Both of these are currently not merged upstream however.
>
> This version incorporates feedback from Viresh Kumar, Andy Shevchenko
> and Russell King.
>
> Signed-off-by: Arnd Bergmann
> Acked-by: Viresh Kumar
> Acked-by: Andy Shevchenko
> Cc: Vinod Koul
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
>
> diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt
> b/Documentation/devicetree/bindings/dma/snps-dma.txt
> index 5bb3dfb..d58675e 100644
> --- a/Documentation/devicetree/bindings/dma/snps-dma.txt
> +++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
> @@ -3,59 +3,61 @@
> Required properties:
> - compatible: "snps,dma-spear1340"
> - reg: Address range of the DMAC registers
> -- interrupt-parent: Should be the phandle for the interrupt controller
> - that services interrupts for this device
> - interrupt: Should contain the DMAC interrupt number
> -- nr_channels: Number of channels supported by hardware
> -- is_private: The device channels should be marked as private and not for by
> the
> - general purpose DMA channel allocator. False if not passed.
> +- dma-channels: Number of channels supported by hardware
> +- dma-requests: Number of DMA request lines supported, up to 16
> +- dma-masters: Number of AHB masters supported by the controller
> +- #dma-cells: must be <3>
> - chan_allocation_order: order of allocation of channel, 0 (default):
> ascending,
>1: descending
> - chan_priority: priority of channels. 0 (default): increase from chan 0->n,
> 1:
>increase from chan n->0
> - block_size: Maximum block size supported by the controller
> -- nr_masters: Number of AHB masters supported by the controller
> - data_width: Maximum data width supported by hardware per AHB master
>(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
> -- slave_info:
> - - bus_id: name of this device channel, not just a device name since
> - devices may have more than one channel e.g. "foo_tx". For using the
> - dw_generic_filter(), slave drivers must pass exactly this string as
> - param to filter function.
> - - cfg_hi: Platform-specific initializer for the CFG_HI register
> - - cfg_lo: Platform-specific initializer for the CFG_LO register
> - - src_master: src master for transfers on allocated channel.
> - - dst_master: dest master for transfers on allocated channel.
> +
> +
> +Optional properties:
> +- interrupt-parent: Should be the phandle for the interrupt controller
> + that services interrupts for this device
> +- is_private: The device channels should be marked as private and not for by
> the
> + general purpose DMA channel allocator. False if not passed.
>
> Example:
>
> - dma@fc00 {
> + dmahost: dma@fc00 {
> compatible = "snps,dma-spear1340";
> reg = <0xfc00 0x1000>;
> interrupt-parent = <&vic1>;
> interrupts = <12>;
>
> - nr_channels = <8>;
> + dma-channels = <8>;
> + dma-requests = <16>;
> + dma-masters = <2>;
> + #dma-cells = <3&
Re: [PATCH] pch_dma: Use GFP_ATOMIC because called from interrupt context
On Wed, Feb 20, 2013 at 11:26:54AM +0900, Tomoya MORINAGA wrote:
> Hi
>
> Could you review this patch ?
> 8 days have passed...
Sorry looks like I missed it. I have queued it up and will apply after -rc1
--
~Vinod
>
> thanks,
> tomoya
>
> On Tue, Feb 12, 2013 at 11:25 AM, Tomoya MORINAGA
> wrote:
> > pdc_desc_get() is called from pd_prep_slave_sg, and the function is
> > called from interrupt context(e.g. Uart driver "pch_uart.c").
> > In fact, I saw kernel error message.
> > So, GFP_ATOMIC must be used not GFP_NOIO.
> >
> > Signed-off-by: Tomoya MORINAGA
> > ---
> > drivers/dma/pch_dma.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
> > index 987ab5c..d5cbd44 100644
> > --- a/drivers/dma/pch_dma.c
> > +++ b/drivers/dma/pch_dma.c
> > @@ -476,7 +476,7 @@ static struct pch_dma_desc *pdc_desc_get(struct
> > pch_dma_chan *pd_chan)
> > dev_dbg(chan2dev(&pd_chan->chan), "scanned %d descriptors\n", i);
> >
> > if (!ret) {
> > - ret = pdc_alloc_desc(&pd_chan->chan, GFP_NOIO);
> > + ret = pdc_alloc_desc(&pd_chan->chan, GFP_ATOMIC);
> > if (ret) {
> > spin_lock(&pd_chan->lock);
> > pd_chan->descs_allocated++;
> > --
> > 1.7.4.4
>
> --
> ROHM Co., Ltd.
> tomoya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: adjust slave_id accordingly to request line base
On Tue, Feb 19, 2013 at 11:02:24AM +0200, Andy Shevchenko wrote: > On Mon, 2013-01-28 at 13:04 +0200, Andy Shevchenko wrote: > > On some hardware configurations we have got the request line with the > > offset. > > The patch introduces convert_slave_id() helper for that cases. The request > > line > > base is got from the platform device resources provided by the > > IORESOURCE_DMA > > type. > > Hi, Vinod. > > v3.8 is just out, and we have not got any proposal from anyone how to > make our approach better. So, I'm just wondering about current state. I was trying to go thru ACPI 5 and see a solution, i think we - use IORESOURCE_IO, but they have a specfic meaning - accpet this patch with IORESOURCE_DMA, but again this has specfic dma meaning too. Just becoz you are in slave-dma driver, doesn't justify use of IORESOURCE_DMA as well - use platform_data (somehow get this from CSRT into device parsing logic of ACPI where you create your platform device and add this in platform data > Rafael, could you share your opinion about our case with CSRT and > request line base (perhaps you need to go through the entire thread)? Sure, do we have anything better than above? -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] dw_dmac: introduce generic DMA binding for DT
On Fri, Feb 15, 2013 at 07:21:48PM +0100, Arnd Bergmann wrote: > Hi Vinod, > > As Andy pointed out today, we don't have a good solution for the > dw_dmac DT binding in linux-next yet. I have posted my series > once before and then got distracted after getting feedback from > Viresh, Andy and Russell. I have now updated my earlier patch > based on the feedback and rebased on your tree without any > of the arm-soc patches mixed in. > > Unfortunately the patches have never been tested on real hardware > so I don't think it's a good idea to use them in v3.9 on the > spear platform. However, your dma-slave tree still contains Viresh's > earlier patches, causing a few problems: > > * With those patches, the spear3xx platform currently does not build. > (this one would be easy to fix though) > * There is a conflict between those patches and my spear multiplatform > series, which I have not yet queued up for 3.9 because of this, > since that would have meant that Stephen Rothwell would have to > discard either the arm-soc tree or the dma-slave tree from linux-next. > * I really don't want the broken binding to appear in 3.9. > > I believe the best way out at this point is this series, which first > first reverts the patch f9965aa2 "ARM: SPEAr13xx: Pass DW DMAC > platform data from DT" from your tree and then adds my update. > > This will give us the right DT binding for dw-dmac but no in-tree > users, which means that nothing should break if I get it slightly > wrong. Please apply the first two patches from these set, and > optionally the two patches that based on this convert the pl011 > uart and pl022 spi controller drivers. Arnd, Since there is still churn, would it make sense if I just revert the SPEAr13xx patch (your first patch) and send a pull request to Linus. Since there are no users and not much testing has been done, I think we can push these to 3.10 via arm-soc/slave-dma tree. Gives more testing and usage will go along as well. Since merge window is open, I would like my pull to go soonish and not churn the tree much. -- ~Vinod > > I can then decide with Olof whether or not to take the spear multiplatform > changes that no longer conflict with the dma slave tree as a "late" > branch into 3.9 or wait until 3.10, but that is something you don't > need to worry about then. Also the conversion of spear to use > the new binding (patch 5 of my original series) can go through the > arm-soc tree for 3.10 after the ST folks have tested that it works. > > Arnd > > Arnd Bergmann (4): > Revert "ARM: SPEAr13xx: Pass DW DMAC platform data from DT" > dmaengine: dw_dmac: move to generic DMA binding > spi: pl022: use generic DMA slave configuration if possible > serial: pl011: use generic DMA slave configuration if possible > > .../devicetree/bindings/arm/primecell.txt | 19 ++- > Documentation/devicetree/bindings/dma/snps-dma.txt | 70 ++- > Documentation/devicetree/bindings/serial/pl011.txt | 17 +++ > .../devicetree/bindings/spi/spi_pl022.txt | 36 ++ > arch/arm/boot/dts/spear1340.dtsi | 19 --- > arch/arm/boot/dts/spear13xx.dtsi | 38 -- > arch/arm/mach-spear13xx/include/mach/spear.h | 2 + > arch/arm/mach-spear13xx/spear1310.c| 5 +- > arch/arm/mach-spear13xx/spear1340.c| 33 +++-- > arch/arm/mach-spear13xx/spear13xx.c| 55 - > drivers/dma/dw_dmac.c | 137 > ++--- > drivers/dma/dw_dmac_regs.h | 8 +- > drivers/spi/spi-pl022.c| 43 ++- > drivers/tty/serial/amba-pl011.c| 62 ++ > include/linux/dw_dmac.h| 5 - > 15 files changed, 333 insertions(+), 216 deletions(-) > create mode 100644 Documentation/devicetree/bindings/serial/pl011.txt > > -- > 1.8.1.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] dw_dmac: introduce generic DMA binding for DT
On Wed, Feb 20, 2013 at 09:50:25AM +, Arnd Bergmann wrote: > On Wednesday 20 February 2013, Vinod Koul wrote: > > Since there is still churn, would it make sense if I just revert the > > SPEAr13xx > > patch (your first patch) and send a pull request to Linus. > > Since there are no users and not much testing has been done, I think we can > > push > > these to 3.10 via arm-soc/slave-dma tree. > > > > Gives more testing and usage will go along as well. > > Since merge window is open, I would like my pull to go soonish and not > > churn the > > tree much. > > Reverting the SPEAr13xx would definitely help, yes. The reason why I'd also > like > to see the second patch get merged is so that we can do the SPEAr changes in > 3.10 > without having an interdependency between the trees. I tried very hard to > make the patch have a minimal impact on the non-DT code path to avoid > regressions. Ok, i have applied your revert patch. Will send the PULL to linus by friday. > Maybe you can send your tree now with just the revert applied, and then send > the > other one separately next week along with any bug fixes that may have > accumulated > by then? And then makes sense to send second PULL with fixes accumulated and the second patch, so that 3.10 is easier for all. think we can compact() patch is second request as well -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH resent] dma: add the freescale-provided MultiChannel DMA driver
On Thu, Feb 21, 2013 at 09:29:47AM +0100, Philippe De Muyter wrote: > > 2. If you are not using dmaengine APIs then drivers/dma/ is not a place for > > you. > > What would be the place then for a multi-architecture dma driver. Freescale > often > reuses the same blocks for its m68k (coldfire), powerpc and arm (iMX) product > lines. A dma driver with many similarities is already under the arch/powerpc > subtree. I would like to avoid that, because it clearly hurts reusability. So the question is will there be any more users of the driver other than the ethernet one? If No then it should live with ethernet driver. DMAengine framework should be used where you have a system dma controller used by different subsystems. > > > 3. While glancing at the code, I dont see why you cant use dmaengine APIs? > lack of need (the sole current user of this dma driver is a FEC ethernet > driver > which uses the current interface), time and expertise. but any help is > welcome. > > > 4. lastly, am blown off by your own implementation of memcpy, WHY? Kernel is > > smarter than you! > I agree, but don't shoot the messenger. I am not the original author, this is > freescale code. I only ensured that it compiles and works with current > kernels, > and suppressed many checkpatch warnings. Okay but you could have removed these before sending it. Hopefully next version will have these kind of stuff taken care of :) -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] slave-dmaengine updates
ical channels number correction Guennadi Liakhovetski (1): dma: sh: Don't use ENODEV for failing slave lookup Heikki Krogerus (3): dmaengine: dw_dmac: remove CLK dependency dmaengine: dw_dmac: amend description and indentation dma: dw_dmac: clear suspend bit during termination Jean Delvare (1): dma: ipu: Drop unused spinlock Joe Perches (1): dma: Convert dev_printk(KERN_ to dev_( Jon Hunter (4): dmaengine: add helper function to request a slave DMA channel of: Add generic device tree DMA helpers of: dma: fix potential deadlock when requesting a slave channel of: dma: fix protection of DMA controller data stored by DMA helpers Jon Mason (1): dmatest: Fix NULL pointer dereference on ioat Kees Cook (1): drivers/dma: remove CONFIG_EXPERIMENTAL Laxman Dewangan (2): dma: tegra: add support for channel wise pause dma: tegra: add support for Tegra114 SoC Maciej Sosnowski (1): dca: check against empty dca_domains list before unregister provider Matt Porter (2): of: dma: fix typos in generic dma binding definition dma: edma: fix slave config dependency on direction Mika Westerberg (1): dw_dmac: add support for Lynxpoint DMA controllers Narayanan (1): dmaengine: ste_dma40: reset priority bit for logical channels Narayanan G (1): dmaengine: ste_dma40: don't check for pm_runtime_suspended() Padmavathi Venna (4): DMA: PL330: Add new pl330 filter for DT case. DMA: PL330: Add xlate function DMA: PL330: Register the DMA controller with the generic DMA helpers ARM: dts: pl330: Add #dma-cells for generic dma binding support Per Forlin (3): dmaengine: ste_dma40: use writel_relaxed for lcxa dmaengine: ste_dma40: set dma max seg size dmaengine: ste_dma40: limit burst size to 16 Rabin Vincent (1): dmaengine: ste_dma40: don't allow high priority dest event lines Sachin Kamat (1): DMA: PL330: Use devm_* functions Shiraz Hashim (1): dmaengine/dmatest: terminate transfers only in case of errors Tong Liu (1): dmaengine: ste_dma40: support more than 128 event lines Vinod Koul (5): of: dma- fix build break for !CONFIG_OF dmaengine: fix build failure due to missing semi-colon dmaengine: fix !of_dma compilation warning Merge tag 'ux500-dma40' of //git.linaro.org/people/fabiobaltieri/linux.git dmaengine: move drivers/of/dma.c -> drivers/dma/of-dma.c Viresh Kumar (3): dmaengine: dw_dmac: Update documentation style comments for dw_dma_platform_data dmaengine: dw_dmac: Enhance device tree support ARM: SPEAr13xx: Pass DW DMAC platform data from DT Wei Yongjun (1): pch_dma: use module_pci_driver to simplify the code .../devicetree/bindings/dma/arm-pl330.txt | 21 +- Documentation/devicetree/bindings/dma/dma.txt | 81 +++ Documentation/devicetree/bindings/dma/snps-dma.txt | 44 ++ arch/arm/boot/dts/exynos5250.dtsi | 12 + arch/arm/mach-s3c64xx/dma.c|2 +- arch/arm/mach-spear3xx/spear3xx.c |1 - arch/arm/mach-spear6xx/spear6xx.c |2 +- crypto/async_tx/async_memcpy.c |6 + crypto/async_tx/async_memset.c |1 + crypto/async_tx/async_tx.c |9 +- crypto/async_tx/async_xor.c|4 +- drivers/dca/dca-core.c |5 + drivers/dma/Kconfig| 11 +- drivers/dma/Makefile |2 + drivers/dma/amba-pl08x.c | 10 +- drivers/dma/at_hdmac.c | 10 +- drivers/dma/at_hdmac_regs.h|8 +- drivers/dma/coh901318.c|4 +- drivers/dma/coh901318_lli.c|2 +- drivers/dma/dmaengine.c| 21 +- drivers/dma/dmatest.c | 22 +- drivers/dma/dw_dmac.c | 523 ++-- drivers/dma/dw_dmac_regs.h | 27 +- drivers/dma/edma.c | 61 ++-- drivers/dma/ep93xx_dma.c |3 +- drivers/dma/ioat/dma.c | 11 +- drivers/dma/ioat/dma.h |1 + drivers/dma/ioat/dma_v2.c | 113 +++-- drivers/dma/ioat/dma_v3.c | 216 ++--- drivers/dma/ioat/hw.h | 11 + drivers/dma/ioat/pci.c | 11 - drivers/dma/iop-adma.c | 45 +- drivers/dma/ipu/ipu_idmac.c|2 +- drivers/dma/ipu/ipu_irq.c |1 - drivers/dma/mmp_pdma.c |6 +-
Re: [PATCH] dma: tegra: remove useless include of
On Tue, 2012-08-28 at 10:21 -0700, Stephen Warren wrote: > On 08/28/2012 12:01 AM, Stephen Warren wrote: > > From: Stephen Warren > > > > Nothing from this file is needed, so remove the include. This helps > > single zImage work by reducing use of the mach-tegra/include/mach/ > > directory. > > BTW, it'd be easiest for me to take this through the Tegra tree, so it > can be consolidated with other header re-org changes. Sure, so here is the ack Acked-by: Vinod Koul -- ~Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: tegra: add const to of_device_id.data's structure
On Sun, 2012-08-26 at 21:25 -0700, Stephen Warren wrote: > On 08/26/2012 03:14 AM, Laxman Dewangan wrote: > > The membe "data" of structure of_device_id is changed to const > > pointer. Hence initializing this with const type data. > > This will fix the compilation warning like > > drivers/dma/tegra20-apb-dma.c:1217:9: warning: assignment discards 'const' > > qualifier from > > pointer target type [enabled by default] > > > > This warning came after the change > > - > > commit 98d7bbb9929bcc14e11ac8a55245a4f2dc174e17 > > Author: Uwe Kleine-König > > of: add const to struct *of_device_id.data > > - > > Acked-by: Stephen Warren Acked-by: Vinod Koul -- ~Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma/ste_dma40: Fixup clock usage during probe
On Thu, 2012-08-23 at 13:41 +0200, Ulf Hansson wrote: > From: Ulf Hansson > > Fixup some errorhandling for clocks during probe and make sure > to use clk_prepare as well as clk_enable. > > Signed-off-by: Ulf Hansson > Acked-by: Linus Walleij Applied, thanks -- ~Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ioat: Adding Ivy Bridge IOATDMA PCI device IDs
On Fri, 2012-08-24 at 16:36 -0700, Dave Jiang wrote:
> Signed-off-by: Dave Jiang
Sounds okay to me, I can carry it once Dan acks it
> ---
>
> drivers/dma/ioat/pci.c | 22 ++
> 1 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/dma/ioat/pci.c b/drivers/dma/ioat/pci.c
> index 5e3a40f..c057306 100644
> --- a/drivers/dma/ioat/pci.c
> +++ b/drivers/dma/ioat/pci.c
> @@ -40,6 +40,17 @@ MODULE_VERSION(IOAT_DMA_VERSION);
> MODULE_LICENSE("Dual BSD/GPL");
> MODULE_AUTHOR("Intel Corporation");
>
> +#define PCI_DEVICE_ID_INTEL_IOAT_IVB00x0e20
> +#define PCI_DEVICE_ID_INTEL_IOAT_IVB10x0e21
> +#define PCI_DEVICE_ID_INTEL_IOAT_IVB20x0e22
> +#define PCI_DEVICE_ID_INTEL_IOAT_IVB30x0e23
> +#define PCI_DEVICE_ID_INTEL_IOAT_IVB40x0e24
> +#define PCI_DEVICE_ID_INTEL_IOAT_IVB50x0e25
> +#define PCI_DEVICE_ID_INTEL_IOAT_IVB60x0e26
> +#define PCI_DEVICE_ID_INTEL_IOAT_IVB70x0e27
> +#define PCI_DEVICE_ID_INTEL_IOAT_IVB80x0e2e
> +#define PCI_DEVICE_ID_INTEL_IOAT_IVB90x0e2f
> +
> static struct pci_device_id ioat_pci_tbl[] = {
> /* I/OAT v1 platforms */
> { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_IOAT) },
> @@ -83,6 +94,17 @@ static struct pci_device_id ioat_pci_tbl[] = {
> { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_IOAT_SNB8) },
> { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_IOAT_SNB9) },
>
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_IOAT_IVB0) },
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_IOAT_IVB1) },
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_IOAT_IVB2) },
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_IOAT_IVB3) },
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_IOAT_IVB4) },
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_IOAT_IVB5) },
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_IOAT_IVB6) },
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_IOAT_IVB7) },
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_IOAT_IVB8) },
> + { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_IOAT_IVB9) },
> +
> { 0, }
> };
> MODULE_DEVICE_TABLE(pci, ioat_pci_tbl);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
~Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] ARM: EXYNOS: Set the capability of pdm0 and pdm1 as DMA_PRIVATE
On Wed, 2012-08-29 at 10:16 +0530, Tushar Behera wrote: > DMA clients pdma0 and pdma1 are internal to the SoC and are used only > by dedicated peripherals. Since they cannot be used for generic > purpose, their capability should be set as DMA_PRIVATE. > > The patches are rebased on top of v3.6-rc3. Kukjin, if you ack them I can take thru my tree, other way round is fine with me too. > > Tushar Behera (2): > ARM: EXYNOS: Set the capability of pdm0 and pdm1 as DMA_PRIVATE > DMA: PL330: Set the capability of pdm0 and pdm1 as DMA_PRIVATE > > arch/arm/mach-exynos/dma.c |2 ++ > drivers/dma/pl330.c|1 + > 2 files changed, 3 insertions(+), 0 deletions(-) > -- ~Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] spi: spi-davinci: convert to DMA engine API
On Thu, 2012-08-30 at 10:43 -0400, Matt Porter wrote: > On Thu, Aug 30, 2012 at 07:46:32PM +0530, Sekhar Nori wrote: > > Hi Matt, > > > > On 8/23/2012 6:39 AM, Matt Porter wrote: > > > Removes use of the DaVinci EDMA private DMA API and replaces > > > it with use of the DMA engine API. > > > > > > Signed-off-by: Matt Porter > > > > I tried testing this patch on my OMAP-L138 EVM, but SPI fails to > > initialize after applying the patch. > > > > root@arago:~# dmesg | grep -i spi > > > > spi_davinci spi_davinci.1: request RX DMA channel failed > > > > Hi Sekhar, > > Most likely CONFIG_TI_EDMA is off as it defaults to off in the v3 > series. Try enabling this and if it's the problem then this error > path can be fixed to properly fallback to PIO only or fail to > initialize as needed. I didnt see any update on this one, is it okay, if so care to send a tested-by? -- ~Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ioat: Adding Ivy Bridge IOATDMA PCI device IDs
On Fri, 2012-08-31 at 15:28 +, Dan Williams wrote: > > On Aug 30, 2012, at 5:30 PM, "Vinod Koul" wrote: > > > On Fri, 2012-08-24 at 16:36 -0700, Dave Jiang wrote: > >> Signed-off-by: Dave Jiang > > Sounds okay to me, I can carry it once Dan acks it > > Thanks Vinod. > > Acked-by: Dan Williams Applied, now -- ~Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] spi: spi-davinci: convert to DMA engine API
On Fri, 2012-08-31 at 21:32 +0530, Sekhar Nori wrote: > Hi Matt, > > On 8/30/2012 8:13 PM, Matt Porter wrote: > > On Thu, Aug 30, 2012 at 07:46:32PM +0530, Sekhar Nori wrote: > >> Hi Matt, > >> > >> On 8/23/2012 6:39 AM, Matt Porter wrote: > >>> Removes use of the DaVinci EDMA private DMA API and replaces > >>> it with use of the DMA engine API. > >>> > >>> Signed-off-by: Matt Porter > >> > >> I tried testing this patch on my OMAP-L138 EVM, but SPI fails to > >> initialize after applying the patch. > >> > >> root@arago:~# dmesg | grep -i spi > >> > >> spi_davinci spi_davinci.1: request RX DMA channel failed > >> > > > > Hi Sekhar, > > > > Most likely CONFIG_TI_EDMA is off as it defaults to off in the v3 > > series. Try enabling this and if it's the problem then this error > > path can be fixed to properly fallback to PIO only or fail to > > initialize as needed. > > Yes, this was the problem. Since the SPI driver now depends on > CONFIG_TI_EDMA for basic operation may be select CONFIG_TI_EDMA in > Kconfig if SPI is enabled? That should do until the fallback to PIO is > implemented. Then this should be enabled for SPI. Care to send a patch > > With that fixed, I tested SPI on OMAP-L138 EVM and it works great. > Tested a JFFS2 mount as well as some raw chardev read/write tests. > > Tested-by: Sekhar Nori > > Thanks, > Sekhar > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- ~Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] spi: spi-davinci: convert to DMA engine API
On Fri, 2012-08-31 at 22:01 +0530, Sekhar Nori wrote: > >> Yes, this was the problem. Since the SPI driver now depends on > >> CONFIG_TI_EDMA for basic operation may be select CONFIG_TI_EDMA in > >> Kconfig if SPI is enabled? That should do until the fallback to PIO > is > >> implemented. > > Then this should be enabled for SPI. Care to send a patch > > By 'this' you mean the Kconfig select? Then there should be no need of > a > new patch for this. It can be part of this patch itself, no? Either way is okay for me. -- ~Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] spi: spi-davinci: convert to DMA engine API
On Fri, 2012-08-31 at 22:32 +0530, Vinod Koul wrote:
> On Fri, 2012-08-31 at 22:01 +0530, Sekhar Nori wrote:
> > >> Yes, this was the problem. Since the SPI driver now depends on
> > >> CONFIG_TI_EDMA for basic operation may be select CONFIG_TI_EDMA in
> > >> Kconfig if SPI is enabled? That should do until the fallback to PIO
> > is
> > >> implemented.
> > > Then this should be enabled for SPI. Care to send a patch
> >
> > By 'this' you mean the Kconfig select? Then there should be no need of
> > a
> > new patch for this. It can be part of this patch itself, no?
> Either way is okay for me.
And am in good mood :)
Applied all with this as well
>From b5f14330590118e6a0659255476c0f24ab681e05 Mon Sep 17 00:00:00 2001
From: Vinod Koul
Date: Sat, 1 Sep 2012 06:29:22 +0530
Subject: [PATCH] spi: davici - make davinci select edma
Reported-by: Sekhar Nori
Signed-off-by: Vinod Koul
---
drivers/spi/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 5f84b55..b9fb9a1 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -134,6 +134,7 @@ config SPI_DAVINCI
tristate "Texas Instruments DaVinci/DA8x/OMAP-L/AM1x SoC SPI
controller"
depends on ARCH_DAVINCI
select SPI_BITBANG
+ select TI_EDMA
help
SPI master controller for DaVinci/DA8x/OMAP-L/AM1x SPI modules.
--
1.7.9.5
--
~Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] dmaengine: at_hdmac: fix comment in atc_prep_slave_sg()
On Tue, 2012-09-11 at 17:21 +0200, Nicolas Ferre wrote:
> s/dma_memcpy/slave_sg/ and it is sg length that we are
> talking about.
>
> Signed-off-by: Nicolas Ferre
> Cc: Stable [2.6.31+]
> ---
> drivers/dma/at_hdmac.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index 3934fcc..6c09e18 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -661,7 +661,7 @@ atc_prep_slave_sg(struct dma_chan *chan, struct
> scatterlist *sgl,
> flags);
>
> if (unlikely(!atslave || !sg_len)) {
> - dev_dbg(chan2dev(chan), "prep_dma_memcpy: length is zero!\n");
> + dev_dbg(chan2dev(chan), "prep_slave_sg: sg length is zero!\n");
> return NULL;
> }
Applied both, Thanks.
I will send this to Linus in couple of days
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: utilize slave_id to pass request line
On Mon, 2012-09-03 at 13:46 +0300, Andy Shevchenko wrote:
> There is slave_id field in the generic slave config structure that is
> dedicated
> for the uniq slave number. In our case we have the request lines wired to the
> certain hardware. Therefore the number of the request line is uniq and could
> be
> used as slave_id. It allows us in some cases to drop out the usage of the
> custom slave config structure.
>
> Signed-off-by: Andy Shevchenko
Applied thanks
> ---
> drivers/dma/dw_dmac.c |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index f0c9403..7a67673 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -187,6 +187,11 @@ static void dwc_initialize(struct dw_dma_chan *dwc)
>
> cfghi = dws->cfg_hi;
> cfglo |= dws->cfg_lo & ~DWC_CFGL_CH_PRIOR_MASK;
> + } else {
> + if (dwc->dma_sconfig.direction == DMA_MEM_TO_DEV)
> + cfghi = DWC_CFGH_DST_PER(dwc->dma_sconfig.slave_id);
> + else if (dwc->dma_sconfig.direction == DMA_DEV_TO_MEM)
> + cfghi = DWC_CFGH_SRC_PER(dwc->dma_sconfig.slave_id);
> }
>
> channel_writel(dwc, CFG_LO, cfglo);
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: tegra: use list_move_tail instead of list_del/list_add_tail
On Wed, 2012-09-05 at 15:08 +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Using list_move_tail() instead of list_del() + list_add_tail().
>
> spatch with a semantic match is used to found this problem.
> (http://coccinelle.lip6.fr/)
>
> Signed-off-by: Wei Yongjun
Applied thanks
> ---
> drivers/dma/tegra20-apb-dma.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma/tegra20-apb-dma.c b/drivers/dma/tegra20-apb-dma.c
> index 24acd71..6ed3f43 100644
> --- a/drivers/dma/tegra20-apb-dma.c
> +++ b/drivers/dma/tegra20-apb-dma.c
> @@ -475,8 +475,7 @@ static void tegra_dma_abort_all(struct tegra_dma_channel
> *tdc)
> while (!list_empty(&tdc->pending_sg_req)) {
> sgreq = list_first_entry(&tdc->pending_sg_req,
> typeof(*sgreq), node);
> - list_del(&sgreq->node);
> - list_add_tail(&sgreq->node, &tdc->free_sg_req);
> + list_move_tail(&sgreq->node, &tdc->free_sg_req);
> if (sgreq->last_sg) {
> dma_desc = sgreq->dma_desc;
> dma_desc->dma_status = DMA_ERROR;
> @@ -570,8 +569,7 @@ static void handle_cont_sngl_cycle_dma_done(struct
> tegra_dma_channel *tdc,
>
> /* If not last req then put at end of pending list */
> if (!list_is_last(&sgreq->node, &tdc->pending_sg_req)) {
> - list_del(&sgreq->node);
> - list_add_tail(&sgreq->node, &tdc->pending_sg_req);
> + list_move_tail(&sgreq->node, &tdc->pending_sg_req);
> sgreq->configured = false;
> st = handle_continuous_head_request(tdc, sgreq, to_terminate);
> if (!st)
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: ipu: Drop unused spinlock
On Thu, 2012-09-06 at 09:19 +0200, Jean Delvare wrote:
> I was checking why this spinlock was never initialized, but it turns
> out it's not used anywhere, so we can drop it.
>
> Signed-off-by: Jean Delvare
> Cc: Vinod Koul
> Cc: Dan Williams
> ---
> I can't even build-test this.
>
> drivers/dma/ipu/ipu_irq.c |1 -
> 1 file changed, 1 deletion(-)
>
> --- linux-3.6-rc4.orig/drivers/dma/ipu/ipu_irq.c 2012-08-04
> 21:49:26.0 +0200
> +++ linux-3.6-rc4/drivers/dma/ipu/ipu_irq.c 2012-09-06 09:13:31.034228670
> +0200
> @@ -45,7 +45,6 @@ static void ipu_write_reg(struct ipu *ip
> struct ipu_irq_bank {
> unsigned intcontrol;
> unsigned intstatus;
> - spinlock_t lock;
> struct ipu *ipu;
> };
>
Dan, you okay with this?
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/2] ARM: EXYNOS: Set the capability of pdm0 and pdm1 as DMA_PRIVATE
On Fri, 2012-09-07 at 14:30 +0900, Kukjin Kim wrote: > Vinod Koul wrote: > > > > On Wed, 2012-08-29 at 10:16 +0530, Tushar Behera wrote: > > > DMA clients pdma0 and pdma1 are internal to the SoC and are used only > > > by dedicated peripherals. Since they cannot be used for generic > > > purpose, their capability should be set as DMA_PRIVATE. > > > > > > The patches are rebased on top of v3.6-rc3. > > Kukjin, if you ack them I can take thru my tree, other way round is fine > > with me too. > > Hi Vinod, > > Looks good to me, please pick them into your tree with my ack. > > Acked-by: Kukjin Kim Okay applied both. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] DMA: PL330: Clock and runtime cleanup
On Fri, 2012-09-07 at 12:14 +0530, Inderpal Singh wrote: > The controller clock is being managed at AMBA bus level probe/remove and > pm_runtime/suspend functions. The existing driver does the clock > enable/disable > again in the same code paths, which unneccessarily increments the usage count > of > the clock for the same device. > > The following patches remove the redundant clock enable/disable from the > driver. Looks good, any tested by before I apply this.. Kukjin? > > Inderpal Singh (2): > DMA: PL330: Remove controller clock enable/disable > DMA: PL330: Remove redundant runtime_suspend/resume functions > > drivers/dma/pl330.c | 73 > --- > 1 file changed, 5 insertions(+), 68 deletions(-) > -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/16] ARM: imx: move platform_data definitions
On Tue, 2012-09-11 at 14:59 +0200, Arnd Bergmann wrote: > Platform data for device drivers should be defined in > include/linux/platform_data/*.h, not in the architecture > and platform specific directories. > > This moves such data out of the imx include directories For these: > drivers/dma/imx-dma.c |2 +- > drivers/dma/imx-sdma.c |4 +-- Acked-by: Vinod Koul -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/16] ARM: ep93xx: move platform_data definitions
On Tue, 2012-09-11 at 14:59 +0200, Arnd Bergmann wrote: > Platform data for device drivers should be defined in > include/linux/platform_data/*.h, not in the architecture > and platform specific directories. > > This moves such data out of the ep93xx include directories > > drivers/dma/ep93xx_dma.c | 2 +- Acked-by: Vinod Koul -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/16] ARM: at91: move platform_data definitions
On Tue, 2012-09-11 at 14:59 +0200, Arnd Bergmann wrote: > Platform data for device drivers should be defined in > include/linux/platform_data/*.h, not in the architecture > and platform specific directories. > > This moves such data out of the at91 include directories > > Signed-off-by: Arnd Bergmann > Cc: Nicolas Ferre > Cc: Jean-Christophe Plagniol-Villard > Cc: Vinod Koul > Cc: Dan Williams Acked-by: Vinod Koul -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 04/15] dmaengine: Pass no_wakeup parameter via device_prep_dma_cyclic() callback
On Thu, 2012-09-13 at 16:37 +0300, Peter Ujfalusi wrote: > Change the parameter list of device_prep_dma_cyclic() so the DMA drivers > can receive the no_wakeup request coming from client drivers. > This feature can be used during audio operation to disable all audio > related interrupts. We already have a flag to indicate this, see * @DMA_PREP_INTERRUPT - trigger an interrupt (callback) upon completion of * this transaction Unfortunately, the addition of cyclic API missed having this flag. So right way would be to add flag argument in the API. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
On Thu, 2012-09-13 at 17:27 +0200, Lars-Peter Clausen wrote: > Hi, > > Hm... Do you think it would work as well if we implement this by > setting the > callback for the descriptor to NULL? If the callback is NULL there is > nothing to at the end of a transfer/period and the dma engine driver > may > choose to disable interrupts. This would also benefit non cyclic > transfers > where the callback is NULL and we do not need add the new parameter to > dmaengine_prep_dma_cyclic. That will work too BUT the idea of no_wake mode in ALSA is that we should not have any interrupts, so anything which is going to cause interrupts to AP in undesired. The interrupts still happen and it just that dmaengine driver is not notifying client. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
On Thu, 2012-09-13 at 16:38 +0100, Russell King - ARM Linux wrote: > On Thu, Sep 13, 2012 at 05:27:09PM +0200, Lars-Peter Clausen wrote: > > Hm... Do you think it would work as well if we implement this by setting the > > callback for the descriptor to NULL? If the callback is NULL there is > > nothing to at the end of a transfer/period and the dma engine driver may > > choose to disable interrupts. This would also benefit non cyclic transfers > > where the callback is NULL and we do not need add the new parameter to > > dmaengine_prep_dma_cyclic. > > Actually, there's a way to do that already. DMA_PREP_INTERRUPT. > Unfortunately, most DMA engine slave API users don't set it when they > setup their transfer: > > * @DMA_PREP_INTERRUPT - trigger an interrupt (callback) upon completion of > * this transaction Looks like I have repeated the correct action! > > if we fixed that, then we could use the lack of it to avoid the interrupt. > > However, cyclic transfers don't have the flags parameter used to pass this > bit. Yet another bit of yucky inconsistent design in DMA engine land... > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
On Fri, 2012-09-14 at 10:13 +0200, Lars-Peter Clausen wrote: > On 09/14/2012 05:26 AM, Vinod Koul wrote: > > On Thu, 2012-09-13 at 17:27 +0200, Lars-Peter Clausen wrote: > >> Hi, > >> > >> Hm... Do you think it would work as well if we implement this by > >> setting the > >> callback for the descriptor to NULL? If the callback is NULL there is > >> nothing to at the end of a transfer/period and the dma engine driver > >> may > >> choose to disable interrupts. This would also benefit non cyclic > >> transfers > >> where the callback is NULL and we do not need add the new parameter to > >> dmaengine_prep_dma_cyclic. > > That will work too BUT the idea of no_wake mode in ALSA is that we > > should not have any interrupts, so anything which is going to cause > > interrupts to AP in undesired. The interrupts still happen and it just > > that dmaengine driver is not notifying client. > > Well, the idea was that the driver would disable interrupts if there is no > callback to call, since there would be nothing to do in the interrupt > handler anyway. But I guess the flags approach should work fine as well. Yes we _could_ do that, but this relies on dmaengine driver to have this implicit understanding. Anyone using dmaengine library in ASoC may or may not be aware of this, so i would consider it hackish. Using this flag explicitly makes everyone aware what the intended behaviour is. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dmaengine: add dmanegine slave map api's
when allocating a channel the dmaengine finds first channel that matches the
mask and calls filter function
In slave dmaengine model, there already exists a mapping, either hardwired in
SoC or thru a configurable mux. So we typically need channel from controller X
and in same cases a partcular channel Y.
Add new APIs which allow adding channel map for client-dma relationship.
This mapping needs to be registered with dmaengine by platform specfic code
which is aware of this mapping. This mapping needs to be added _before_ any
client tries to access a channel.
Then in order for slave devices to get a channel based on above mapping, add new
slave specfic dmanengine channel request/free APIs
Signed-off-by: Vinod Koul
---
this is the first attempt to do the slave dma mapping, we have been discussing
this and we all agree to need for this. This is the same patch which was shown
at KS and attempts to build the mapping information within dmaengine which is
platform and arch agnostic.
The arch code like DT/board-files/SFI etc can use these APIs to build dmaengine
mapping and then dmaengine filters channels based on this mapping.
Now Credits:
the orginal idea was from Linus Walleij and has been discussed in similar
format.
---
drivers/dma/dmaengine.c | 152 +
include/linux/dmaengine.h | 50 +++
2 files changed, 202 insertions(+)
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 3491654..293dfd0 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -1066,6 +1066,158 @@ void dma_run_dependencies(struct
dma_async_tx_descriptor *tx)
}
EXPORT_SYMBOL_GPL(dma_run_dependencies);
+/* slave channel mapping code*/
+static LIST_HEAD(dma_slave_map);
+
+/*called under lock held */
+static struct dma_chan *dmaengine_get_slave_channel(char *requestor,
dma_cap_mask_t *mask)
+{
+
+ struct dma_device *device, *_d;
+ struct dma_chan *chan = NULL;
+ int err;
+
+ list_for_each_entry_safe(device, _d, &dma_device_list, global_node) {
+ if (strcmp(requestor, dev_name(device->dev)))
+ continue;
+
+ chan = private_candidate(mask, device, NULL, NULL);
+ if (chan) {
+ /* Found a suitable channel, try to grab, prep, and
+* return it. We first set DMA_PRIVATE to disable
+* balance_ref_count as this channel will not be
+* published in the general-purpose allocator
+*/
+ dma_cap_set(DMA_PRIVATE, device->cap_mask);
+ device->privatecnt++;
+ err = dma_chan_get(chan);
+
+ if (err == -ENODEV) {
+ pr_debug("%s: %s module removed\n",
+__func__, dma_chan_name(chan));
+ list_del_rcu(&device->global_node);
+ } else if (err)
+ pr_debug("%s: failed to get %s: (%d)\n",
+__func__, dma_chan_name(chan), err);
+ else
+ break;
+ if (--device->privatecnt == 0)
+ dma_cap_clear(DMA_PRIVATE, device->cap_mask);
+ chan = NULL;
+ }
+ }
+ return chan;
+}
+
+/**
+ * dmaengine_request_slave_channel - request a slave channel for which
damengine
+ * knows the channel mapping
+ *
+ * This is generic API which should work on all arch and doesnt assume any arch
+ * implementation of how map is constructed. Arch code should call map apis to
+ * build the channel map first
+ *
+ * @requestor: client name
+ * @config: dma_slave_config, this is set post channle allocation
+ * @mask: capabilities that the channel must satisfy
+ * @fn: optional filter function should be unused typically
+ * @fn_param: filter fn params
+ */
+struct dma_chan *dmaengine_request_slave_channel(
+ char *requestor, struct dma_slave_config *config,
+ dma_cap_mask_t *mask, dma_filter_fn fn, void *fn_param)
+{
+ struct dma_chan *slave = NULL;
+ struct dmaengine_slave_map_entries *entry, *_e;
+
+ /* perhpas we dont need mask arg, it should be slave anyway */
+ if (!__dma_has_cap(DMA_SLAVE, mask))
+ return NULL;
+
+ mutex_lock(&dma_list_mutex);
+ /* find a channel which maps to this request */
+ list_for_each_entry_safe(entry, _e, &dma_slave_map, node) {
+ if (strcmp(requestor, entry->map->client))
+ continue;
+
+ /* have we already allocated this mapping */
+ if (entry->used == true)
+ continue;
+
+ /* now we hit an entry in ma
Re: [PATCH v2 03/15] dmaengine: Add no_wakeup parameter to dmaengine_prep_dma_cyclic()
On Fri, 2012-09-14 at 12:28 +0300, Peter Ujfalusi wrote: > Hi, > > On 09/14/2012 11:50 AM, Vinod Koul wrote: > >> Well, the idea was that the driver would disable interrupts if there is no > >> callback to call, since there would be nothing to do in the interrupt > >> handler anyway. But I guess the flags approach should work fine as well. > > Yes we _could_ do that, but this relies on dmaengine driver to have this > > implicit understanding. Anyone using dmaengine library in ASoC may or > > may not be aware of this, so i would consider it hackish. > > > > Using this flag explicitly makes everyone aware what the intended > > behaviour is. > > I'm not sure about which flags should ASoC set for the two case we are going > to have. I think it should be something like this: > > unsigned long flags = DMA_CTRL_ACK; usage of ACK flag is mostly async_tx thingy, we can skip it for slave. > > if (!substream->runtime->no_period_wakeup) > flags |= DMA_PREP_INTERRUPT; > I'm not 100% sure of the role of DMA_CTRL_ACK in this case. Or should we only > handle the DMA_PREP_INTERRUPT flag, like this: > > unsigned long flags = 0; > > if (!substream->runtime->no_period_wakeup) > flags |= DMA_PREP_INTERRUPT; > > > What do you think? Looks fine. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] dmaengine: add dmanegine slave map api's
On Fri, 2012-09-14 at 15:03 +0530, Vinod Koul wrote:
Sorry, this is a RFC, and not a PATCH yet.
> when allocating a channel the dmaengine finds first channel that matches the
> mask and calls filter function
> In slave dmaengine model, there already exists a mapping, either hardwired in
> SoC or thru a configurable mux. So we typically need channel from controller X
> and in same cases a partcular channel Y.
>
> Add new APIs which allow adding channel map for client-dma relationship.
> This mapping needs to be registered with dmaengine by platform specfic code
> which is aware of this mapping. This mapping needs to be added _before_ any
> client tries to access a channel.
>
> Then in order for slave devices to get a channel based on above mapping, add
> new
> slave specfic dmanengine channel request/free APIs
>
> Signed-off-by: Vinod Koul
> ---
> this is the first attempt to do the slave dma mapping, we have been discussing
> this and we all agree to need for this. This is the same patch which was shown
> at KS and attempts to build the mapping information within dmaengine which is
> platform and arch agnostic.
>
> The arch code like DT/board-files/SFI etc can use these APIs to build
> dmaengine
> mapping and then dmaengine filters channels based on this mapping.
>
> Now Credits:
> the orginal idea was from Linus Walleij and has been discussed in similar
> format.
> ---
> drivers/dma/dmaengine.c | 152
> +
> include/linux/dmaengine.h | 50 +++
> 2 files changed, 202 insertions(+)
>
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 3491654..293dfd0 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -1066,6 +1066,158 @@ void dma_run_dependencies(struct
> dma_async_tx_descriptor *tx)
> }
> EXPORT_SYMBOL_GPL(dma_run_dependencies);
>
> +/* slave channel mapping code*/
> +static LIST_HEAD(dma_slave_map);
> +
> +/*called under lock held */
> +static struct dma_chan *dmaengine_get_slave_channel(char *requestor,
> dma_cap_mask_t *mask)
> +{
> +
> + struct dma_device *device, *_d;
> + struct dma_chan *chan = NULL;
> + int err;
> +
> + list_for_each_entry_safe(device, _d, &dma_device_list, global_node) {
> + if (strcmp(requestor, dev_name(device->dev)))
> + continue;
> +
> + chan = private_candidate(mask, device, NULL, NULL);
> + if (chan) {
> + /* Found a suitable channel, try to grab, prep, and
> + * return it. We first set DMA_PRIVATE to disable
> + * balance_ref_count as this channel will not be
> + * published in the general-purpose allocator
> + */
> + dma_cap_set(DMA_PRIVATE, device->cap_mask);
> + device->privatecnt++;
> + err = dma_chan_get(chan);
> +
> + if (err == -ENODEV) {
> + pr_debug("%s: %s module removed\n",
> + __func__, dma_chan_name(chan));
> + list_del_rcu(&device->global_node);
> + } else if (err)
> + pr_debug("%s: failed to get %s: (%d)\n",
> + __func__, dma_chan_name(chan), err);
> + else
> + break;
> + if (--device->privatecnt == 0)
> + dma_cap_clear(DMA_PRIVATE, device->cap_mask);
> + chan = NULL;
> + }
> + }
> + return chan;
> +}
> +
> +/**
> + * dmaengine_request_slave_channel - request a slave channel for which
> damengine
> + * knows the channel mapping
> + *
> + * This is generic API which should work on all arch and doesnt assume any
> arch
> + * implementation of how map is constructed. Arch code should call map apis
> to
> + * build the channel map first
> + *
> + * @requestor: client name
> + * @config: dma_slave_config, this is set post channle allocation
> + * @mask: capabilities that the channel must satisfy
> + * @fn: optional filter function should be unused typically
> + * @fn_param: filter fn params
> + */
> +struct dma_chan *dmaengine_request_slave_channel(
> + char *requestor, struct dma_slave_config *config,
> + dma_cap_mask_t *mask, dma_filter_fn fn, void *fn_param)
> +{
> + struct dma_chan *slave = NULL;
> + struct dmaengine_slave_map_entries *ent
Re: [PATCH] dmaengine: add dmanegine slave map api's
On Fri, 2012-09-14 at 10:41 +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 14, 2012 at 03:03:09PM +0530, Vinod Koul wrote:
> > +/*called under lock held */
> > +static struct dma_chan *dmaengine_get_slave_channel(char *requestor,
> > dma_cap_mask_t *mask)
> > +{
> > +
> > + struct dma_device *device, *_d;
> > + struct dma_chan *chan = NULL;
> > + int err;
> > +
> > + list_for_each_entry_safe(device, _d, &dma_device_list, global_node) {
> > + if (strcmp(requestor, dev_name(device->dev)))
> > + continue;
>
> So, this finds a DMA device where the struct device's name corresponds
> with the name passed in as 'requestor' (note that requestor should be
> const.)
Yes that is the idea for search
>
> > +
> > + chan = private_candidate(mask, device, NULL, NULL);
> > + if (chan) {
>
> And this finds _any_ channel on the device.
initially yes, and then we further narrow down based on if _any_ channel
will suffice or we need specific channel (in cases where we have a mux
and not hardwired soc wiring)
>
> > + /* Found a suitable channel, try to grab, prep, and
> > +* return it. We first set DMA_PRIVATE to disable
> > +* balance_ref_count as this channel will not be
> > +* published in the general-purpose allocator
> > +*/
> > + dma_cap_set(DMA_PRIVATE, device->cap_mask);
> > + device->privatecnt++;
> > + err = dma_chan_get(chan);
> > +
> > + if (err == -ENODEV) {
> > + pr_debug("%s: %s module removed\n",
> > +__func__, dma_chan_name(chan));
> > + list_del_rcu(&device->global_node);
> > + } else if (err)
> > + pr_debug("%s: failed to get %s: (%d)\n",
> > +__func__, dma_chan_name(chan), err);
> > + else
> > + break;
> > + if (--device->privatecnt == 0)
> > + dma_cap_clear(DMA_PRIVATE, device->cap_mask);
> > + chan = NULL;
> > + }
> > + }
> > + return chan;
>
> and returns it...
>
> > +struct dma_chan *dmaengine_request_slave_channel(
> > + char *requestor, struct dma_slave_config *config,
> > + dma_cap_mask_t *mask, dma_filter_fn fn, void *fn_param)
> > +{
> > + struct dma_chan *slave = NULL;
> > + struct dmaengine_slave_map_entries *entry, *_e;
> > +
> > + /* perhpas we dont need mask arg, it should be slave anyway */
> > + if (!__dma_has_cap(DMA_SLAVE, mask))
> > + return NULL;
> > +
> > + mutex_lock(&dma_list_mutex);
> > + /* find a channel which maps to this request */
> > + list_for_each_entry_safe(entry, _e, &dma_slave_map, node) {
> > + if (strcmp(requestor, entry->map->client))
> > + continue;
> > +
> > + /* have we already allocated this mapping */
> > + if (entry->used == true)
> > + continue;
> > +
> > + /* now we hit an entry in map,
> > +* see if we can get a channel in controller */
> > + slave = dmaengine_get_slave_channel(requestor, mask);
> > + if (!slave)
> > + continue;
>
> Ok, so here we've got a channel - any old channel what so ever on the
> device described by 'requestor'. And we're holding a reference to it.
>
> > +
> > + /* check if client is requesting some specfic slave channel */
> > + if ((entry->map->ch != -1) && (entry->map->ch !=
> > slave->chan_id))
> > + continue;
>
> If the channel number isn't what we wanted, where do we drop this
> reference?
Yes that needs to be taken care :)
> Also note that this 'continue' causes us to move to the
> next entry in the map list - whereas what may have happened is that
> the channel on the DMA engine is free, but it simply wasn't the first
> free channel. I don't see how this can work sanely.
But that is not the controller we are interested in.
Think of platform where we have 3 dma controllers and 3 peripherals,
spi, mmc, i2s. Only third dmac can be used by i2s controller so even
though we have
Re: [PATCH] dw_dmac: fix a regression in dwc_prep_dma_memcpy
On Mon, 2012-10-01 at 13:06 +0300, Andy Shevchenko wrote: > Sometimes memory-to-memory test is failed, that's why we need to choose > minimum > data portion between source and destination limits together. > > Signed-off-by: Andy Shevchenko Applied, thanks for taking care of this -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/13] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
On Mon, 2012-10-01 at 12:39 -0400, Matt Porter wrote:
> Anything you can show at this point? ;) I'd be happy to drop the
> half-hack
> for a real API. If not, I'm going to carry that to v2 atm.
This is what I had done sometime back. Feel free to update
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 9c02a45..94ae006 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -86,11 +86,11 @@ enum dma_transaction_type {
* @DMA_DEV_TO_DEV: Slave mode & From Device to Device
*/
enum dma_transfer_direction {
- DMA_MEM_TO_MEM,
- DMA_MEM_TO_DEV,
- DMA_DEV_TO_MEM,
- DMA_DEV_TO_DEV,
- DMA_TRANS_NONE,
+ DMA_MEM_TO_MEM = 0x01,
+ DMA_MEM_TO_DEV = 0x02,
+ DMA_DEV_TO_MEM = 0x04,
+ DMA_DEV_TO_DEV = 0x08,
+ DMA_TRANS_NONE = 0x10,
};
/**
@@ -371,6 +371,41 @@ struct dma_slave_config {
unsigned int slave_id;
};
+enum dmaengine_apis {
+ DMAENGINE_MEMCPY= 0x0001,
+ DMAENGINE_XOR = 0x0002,
+ DMAENGINE_XOR_VAL = 0x0004,
+ DMAENGINE_PQ= 0x0008,
+ DMAENGINE_PQ_VAL= 0x0010,
+ DMAENGINE_MEMSET= 0x0020,
+ DMAENGINE_SLAVE = 0x0040,
+ DMAENGINE_CYCLIC= 0x0080,
+ DMAENGINE_INTERLEAVED = 0x0100,
+ DMAENGINE_SG= 0x0200,
+};
+
+/* struct dmaengine_chan_caps - expose capability of a channel
+ * Note: each channel can have same or different capabilities
+ *
+ * This primarily classifies capabilities into
+ * a) APIs/ops supported
+ * b) channel physical capabilities
+ *
+ * @ops: or'ed api capability
+ * @widths: channel widths supported
+ * @dirn: channel directions supported
+ * @bursts: bitmask of burst lengths supported
+ * @mux: configurable slave id or hard wired
+ * -1 for hard wired, otherwise valid positive slave id (including zero)
+ */
+struct dmaengine_chan_caps {
+ enum dmaengine_apis ops;
+ enum dma_slave_buswidth widths;
+ enum dma_transfer_direction dirn;
+ unsigned int dma_bursts;
+ int mux;
+};
+
static inline const char *dma_chan_name(struct dma_chan *chan)
{
return dev_name(&chan->dev->device);
@@ -534,6 +569,7 @@ struct dma_tx_state {
* struct with auxiliary transfer status information, otherwise the call
* will just return a simple status code
* @device_issue_pending: push pending transactions to hardware
+ * @device_channel_caps: return the capablities of channel
*/
struct dma_device {
@@ -602,6 +638,9 @@ struct dma_device {
dma_cookie_t cookie,
struct dma_tx_state *txstate);
void (*device_issue_pending)(struct dma_chan *chan);
+
+ struct dmaengine_chan_caps *(*device_channel_caps)(
+ struct dma_chan *chan);
};
static inline int dmaengine_device_control(struct dma_chan *chan,
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] dma: tegra: fix interrupt name issue with apb dma.
On Thu, 2012-10-04 at 08:26 +, Koul, Vinod wrote: > > > > > > (Dropping stable Cc; Olof/Arnd or Vinod, is it possible you could add > > > that into the patch description when applying this?) > > > > > > Reported-by: Stephen Warren > > > Acked-by: Stephen Warren > > > > Should be no problem. If Vinod wants to pick it up: > > > > Acked-by: Arnd Bergmann > Will do it later today... am travelling so slow on email :( Done, applied ith Stephen's credits :) Thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()
On Tue, 2012-10-23 at 15:54 -0700, Dan Williams wrote:
> > +struct dmaengine_chan_caps {
> > + enum dmaengine_apis ops;
> > + int seg_nr;
> > + int seg_len;
> > +};
>
> This makes sense for the potentially dynamic capability properties
> that get set after configuration, but why do we need the operation
> types here? They can be retrieved from the parent device.
I was thinking that each channel can have different capabilities.
You can assign one channel for mempcy operations exclusively and some
others for slave usage exclusively.
I believe some h/w do have such assignment so would help in doing that.
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] dmaengine: add dma_get_channel_caps()
On Tue, 2012-10-23 at 23:49 +0100, Grant Likely wrote:
> > +enum dmaengine_apis {
> > + DMAENGINE_MEMCPY= 0x0001,
> > + DMAENGINE_XOR = 0x0002,
> > + DMAENGINE_XOR_VAL = 0x0004,
> > + DMAENGINE_PQ= 0x0008,
> > + DMAENGINE_PQ_VAL= 0x0010,
> > + DMAENGINE_MEMSET= 0x0020,
> > + DMAENGINE_SLAVE = 0x0040,
> > + DMAENGINE_CYCLIC= 0x0080,
> > + DMAENGINE_INTERLEAVED = 0x0100,
> > + DMAENGINE_SG= 0x0200,
> > +};
>
> Actually, one more comment. Why the new enum? Why can't the
> dma_transaction_type enum be used directly along with dma_cap_mask_t?
Some of the capabilities above are not there in dma_caps_t like DMA_SG.
Also DMA_INTERRUPT and DMA_PRIVATE would not make much sense here.
BUT would help to keep things simpler if have one definition which
includes all.
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 041/193] drivers/dma: remove CONFIG_EXPERIMENTAL
On Tue, 2012-10-23 at 13:01 -0700, Kees Cook wrote: > This config item has not carried much meaning for a while now and is > almost always enabled by default. As agreed during the Linux kernel > summit, remove it. > > CC: Vinod Koul > CC: Dan Williams > Signed-off-by: Kees Cook > --- > drivers/dma/Kconfig |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig > index 677cd6e..dc8f4d1 100644 > --- a/drivers/dma/Kconfig > +++ b/drivers/dma/Kconfig > @@ -51,7 +51,7 @@ config ASYNC_TX_ENABLE_CHANNEL_SWITCH > > config AMBA_PL08X > bool "ARM PrimeCell PL080 or PL081 support" > - depends on ARM_AMBA && EXPERIMENTAL > + depends on ARM_AMBA > select DMA_ENGINE > select DMA_VIRTUAL_CHANNELS > help Applied thanks -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: imx-dma: fix missing unlock on error in imxdma_xfer_desc()
On Sun, 2012-10-21 at 19:58 +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Add the missing unlock on the error handling path in function
> imxdma_xfer_desc().
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/dma/imx-dma.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
> index f11b5b2..7d9554c 100644
> --- a/drivers/dma/imx-dma.c
> +++ b/drivers/dma/imx-dma.c
> @@ -474,8 +474,10 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
> slot = i;
> break;
> }
> - if (slot < 0)
> + if (slot < 0) {
> + spin_unlock_irqrestore(&imxdma->lock, flags);
> return -EBUSY;
> + }
>
> imxdma->slots_2d[slot].xsr = d->x;
> imxdma->slots_2d[slot].ysr = d->y;
>
>
> --
Thanks applied
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] ARM: tegra: dts: add slink controller dt entry
On Fri, 2012-10-19 at 09:56 -0600, Stephen Warren wrote:
> On 10/19/2012 03:10 AM, Laxman Dewangan wrote:
> > On Friday 19 October 2012 04:11 AM, Stephen Warren wrote:
> >> On 10/18/2012 04:56 AM, Laxman Dewangan wrote:
> >>> Add slink controller details in the dts file of
> >>> Tegra20 and Tegra30.
> >>> diff --git a/arch/arm/boot/dts/tegra20.dtsi
> >>> b/arch/arm/boot/dts/tegra20.dtsi
> >>> +slink@7000d400 {
> >>> +compatible = "nvidia,tegra20-slink";
> >>> +reg =<0x7000d400 0x200>;
> >>> +interrupts =<0 59 0x04>;
> >>> +nvidia,dma-req-sel =<15>;
> >
>
> (Oh, you need a space before and after the = in all the lines above)
>
> >> I thought the common DT DMA bindings were going to be in 3.7, and hence
> >> we could just use them here rather than inventing another custom
> >> property for this purpose?
> >
> > Adding Vinod here.
> >
> > I looked the dma devicetree bingind document and did not found the
> > generic binding name. Howvere, for arm-pl330.txt, it is explained as ...
>
> That's not the generic bindings. I guess they didn't get merged then. I
> guess we can continue with custom bindings until they are.
Yes they are in topic topic/dmaengine_dt in my tree. Will be merged once
we sort out slave apis.
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] DMA: PL330: Change allocation method to properly free DMA descriptors
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
> In probe, memory for multiple DMA descriptors were being allocated at once
> and then it was being split and added into DMA pool one by one. The address
> of this memory allocation is not being saved anywhere. To free this memory,
> the address is required. Initially the first node of the pool will be
> pointed by this address but as we use this pool the descs will shuffle and
> hence we will lose the track of the address.
>
> This patch does following:
>
> 1. Allocates DMA descs one by one and then adds them to pool so that all
>descs can be fetched and memory freed one by one. This way runtime
>added descs can also be freed.
> 2. Free DMA descs in case of error in probe and in module's remove function
For probe, again you have cleaner code by using devm_kzalloc.
On 1, if we use the devm_kzalloc then we don't need to allocate in
chunks right?
>
> Signed-off-by: Inderpal Singh
> ---
> drivers/dma/pl330.c | 35 +--
> 1 file changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 10c6b6a..bf71ff7 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2541,20 +2541,20 @@ static int add_desc(struct dma_pl330_dmac *pdmac,
> gfp_t flg, int count)
> if (!pdmac)
> return 0;
>
> - desc = kmalloc(count * sizeof(*desc), flg);
> - if (!desc)
> - return 0;
> + for (i = 0; i < count; i++) {
> + desc = kmalloc(sizeof(*desc), flg);
> + if (!desc)
> + break;
> + _init_desc(desc);
>
> - spin_lock_irqsave(&pdmac->pool_lock, flags);
> + spin_lock_irqsave(&pdmac->pool_lock, flags);
>
> - for (i = 0; i < count; i++) {
> - _init_desc(&desc[i]);
> - list_add_tail(&desc[i].node, &pdmac->desc_pool);
> - }
> + list_add_tail(&desc->node, &pdmac->desc_pool);
>
> - spin_unlock_irqrestore(&pdmac->pool_lock, flags);
> + spin_unlock_irqrestore(&pdmac->pool_lock, flags);
> + }
>
> - return count;
> + return i;
> }
>
> static struct dma_pl330_desc *
> @@ -2857,6 +2857,7 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
> struct dma_pl330_platdata *pdat;
> struct dma_pl330_dmac *pdmac;
> struct dma_pl330_chan *pch;
> + struct dma_pl330_desc *desc;
> struct pl330_info *pi;
> struct dma_device *pd;
> struct resource *res;
> @@ -2978,6 +2979,12 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
> probe_err5:
> kfree(pdmac->peripherals);
> probe_err4:
> + while (!list_empty(&pdmac->desc_pool)) {
> + desc = list_entry(pdmac->desc_pool.next,
> + struct dma_pl330_desc, node);
> + list_del(&desc->node);
> + kfree(desc);
> + }
> pl330_del(pi);
> probe_err3:
> free_irq(irq, pi);
> @@ -2994,6 +3001,7 @@ static int __devexit pl330_remove(struct amba_device
> *adev)
> {
> struct dma_pl330_dmac *pdmac = amba_get_drvdata(adev);
> struct dma_pl330_chan *pch, *_p;
> + struct dma_pl330_desc *desc;
> struct pl330_info *pi;
> struct resource *res;
> int irq;
> @@ -3015,6 +3023,13 @@ static int __devexit pl330_remove(struct amba_device
> *adev)
> pl330_free_chan_resources(&pch->chan);
> }
>
> + while (!list_empty(&pdmac->desc_pool)) {
> + desc = list_entry(pdmac->desc_pool.next,
> + struct dma_pl330_desc, node);
> + list_del(&desc->node);
> + kfree(desc);
> + }
> +
> pi = &pdmac->pif;
>
> pl330_del(pi);
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] DMA: PL330: Balance module remove function with probe
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
> Since peripheral channel resources are not being allocated at probe,
> no need to flush the channels and free the resources in remove function.
> In case, the channel is in use by some client, return EBUSY.
>
> Signed-off-by: Inderpal Singh
> ---
> drivers/dma/pl330.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index bf71ff7..4b7a34d 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -3009,18 +3009,21 @@ static int __devexit pl330_remove(struct amba_device
> *adev)
> if (!pdmac)
> return 0;
>
> + /* check if any client is using any channel */
> + list_for_each_entry(pch, &pdmac->ddma.channels,
> + chan.device_node) {
> +
> + if (pch->chan.client_count)
> + return -EBUSY;
> + }
> +
> while (!list_empty(&pdmac->desc_pool)) {
Did you get this code executed?
I think No.
The dmaengine holds the reference to channels, so if they are in use and
not freed by client your remove wont be called. So this check is
redundant
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] DMA: PL330: unregister dma_device in module's remove function
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote: > unregister dma_device in module's remove function. > > Signed-off-by: Inderpal Singh > --- > drivers/dma/pl330.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c > index 4b7a34d..e7dc040 100644 > --- a/drivers/dma/pl330.c > +++ b/drivers/dma/pl330.c > @@ -3017,6 +3017,8 @@ static int __devexit pl330_remove(struct amba_device > *adev) > return -EBUSY; > } > > + dma_async_device_unregister(&pdmac->ddma); > + > amba_set_drvdata(adev, NULL); > > list_for_each_entry_safe(pch, _p, &pdmac->ddma.channels, Ok with this one :) Tried applying but didn't work out. You would need to regenerate this one. Thanks -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] DMA: PL330: Free memory allocated for peripheral channels
On Fri, 2012-10-05 at 15:47 +0530, Inderpal Singh wrote:
> The allocated memory for peripheral channels is not being freed upon
> failure in probe and in module's remove funtion. It will lead to memory
> leakage. Hence free the allocated memory.
>
> Signed-off-by: Inderpal Singh
> ---
> drivers/dma/pl330.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 2ebd4cd..10c6b6a 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2962,7 +2962,7 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
> ret = dma_async_device_register(pd);
> if (ret) {
> dev_err(&adev->dev, "unable to register DMAC\n");
> - goto probe_err4;
> + goto probe_err5;
> }
>
> dev_info(&adev->dev,
> @@ -2975,6 +2975,8 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
>
> return 0;
>
> +probe_err5:
> + kfree(pdmac->peripherals);
> probe_err4:
> pl330_del(pi);
> probe_err3:
> @@ -3025,6 +3027,7 @@ static int __devexit pl330_remove(struct amba_device
> *adev)
> res = &adev->res;
> release_mem_region(res->start, resource_size(res));
>
> + kfree(pdmac->peripherals);
> kfree(pdmac);
>
> return 0;
This looks fine, but if you use devm_ functions then you dont need to do
all this.
Can you do that conversion instead?
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DMA: PL330: Add runtime pm support
On Wed, 2012-10-17 at 09:42 +0530, Inderpal Singh wrote:
> At the pl330's probe point the device is already in runtime resume state.
> Hence to manage the device with runtime, the probe should do pm_runtime_put
> and remove should do pm_runtime_get to balance with probe.
>
> And in between, the device is being get/put at alloc_chan_resources and
> free_chan_resources.
>
> Signed-off-by: Inderpal Singh
> ---
> This patch is based on slave-dma's next branch and on top
> of the clean up patches at [1].
>
> [1] https://lkml.org/lkml/2012/10/5/169
>
> drivers/dma/pl330.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 2ee1538..5ae19ea 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #include "dmaengine.h"
> #define PL330_MAX_CHAN 8
> @@ -2384,6 +2385,8 @@ static int pl330_alloc_chan_resources(struct dma_chan
> *chan)
> struct dma_pl330_dmac *pdmac = pch->dmac;
> unsigned long flags;
>
> + pm_runtime_get_sync(pdmac->ddma.dev);
it would be really good if we move this to tx_submit. That way you
resume the dmaengine when actual transactions happen, not when someone
requests a channel.
Yes thats a little more work, though initially we can have this way.
> +
> spin_lock_irqsave(&pch->lock, flags);
>
> dma_cookie_init(chan);
> @@ -2392,6 +2395,7 @@ static int pl330_alloc_chan_resources(struct dma_chan
> *chan)
> pch->pl330_chid = pl330_request_channel(&pdmac->pif);
> if (!pch->pl330_chid) {
> spin_unlock_irqrestore(&pch->lock, flags);
> + pm_runtime_put(pdmac->ddma.dev);
> return -ENOMEM;
> }
>
> @@ -2470,6 +2474,8 @@ static void pl330_free_chan_resources(struct dma_chan
> *chan)
> list_splice_tail_init(&pch->work_list, &pch->dmac->desc_pool);
>
> spin_unlock_irqrestore(&pch->lock, flags);
> +
> + pm_runtime_put(pch->dmac->ddma.dev);
> }
>
> static enum dma_status
> @@ -2974,6 +2980,8 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
> pi->pcfg.data_bus_width / 8, pi->pcfg.num_chan,
> pi->pcfg.num_peri, pi->pcfg.num_events);
>
> + pm_runtime_put(pd->dev);
pm_runtime_put_noidle is better. Yous should also do pm_runtime_allow
here and pm_runtime_forbid in your remove.
> +
> return 0;
>
> probe_err5:
> @@ -3017,6 +3025,8 @@ static int __devexit pl330_remove(struct amba_device
> *adev)
> return -EBUSY;
> }
>
> + pm_runtime_get(pdmac->ddma.dev);
> +
> dma_async_device_unregister(&pdmac->ddma);
>
> amba_set_drvdata(adev, NULL);
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pch_dma: use module_pci_driver to simplify the code
On Wed, 2012-10-10 at 21:04 +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Use the module_pci_driver() macro to make the code simpler
> by eliminating module_init and module_exit calls.
>
> dpatch engine is used to auto generate this patch.
> (https://github.com/weiyj/dpatch)
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/dma/pch_dma.c | 13 +
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
> index 987ab5c..b405916 100644
> --- a/drivers/dma/pch_dma.c
> +++ b/drivers/dma/pch_dma.c
> @@ -1029,18 +1029,7 @@ static struct pci_driver pch_dma_driver = {
> #endif
> };
>
> -static int __init pch_dma_init(void)
> -{
> - return pci_register_driver(&pch_dma_driver);
> -}
> -
> -static void __exit pch_dma_exit(void)
> -{
> - pci_unregister_driver(&pch_dma_driver);
> -}
> -
> -module_init(pch_dma_init);
> -module_exit(pch_dma_exit);
> +module_pci_driver(pch_dma_driver);
>
> MODULE_DESCRIPTION("Intel EG20T PCH / LAPIS Semicon ML7213/ML7223/ML7831 IOH
> "
> "DMA controller driver");
>
>
Applied thanks
--
Vinod Koul
Intel Corp.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 5/7] dmaengine: dw_dmac: add PCI part of the driver
On Mon, 2012-10-08 at 18:57 +0530, Viresh Kumar wrote: > I agree that there are some parts of your approach which might be having > few advantages. But it is actually adding more complexity without much > need of it. Logically speaking, we never had two devices for the same > dma controller. We are adding them just to have pci over platform.. Which > would mean the system become more and more complex.. > > So, during run time... > - there will be two device-driver binding loops.. Once for pci and then for > platform > - In suspend/resume... two devices will get into suspend, instead of one.. > - There might be other frameworks in kernel.. which react on struct device >basis... they will get affected too.. > - You have larger image size for pci case. as you compile platform too.. > > Just try to think from this perspective... we dont have two hardware devices > in the system Ideally speaking there must be a struct device associated > with a hardware device... > > @Arnd/Vinod: Can you guys throw some more light here.. on the adv/disadv > of both the approaches? I am worried about those tow. Runtime PM handlers in case PCI devices make life a lot easier am not sure what support will be there for platform devices in other systems. Also next version of this h/w on our systems is bringing subtle changes so having them separate seemed to me a better idea. -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 0/6] dw_dmac: few cleanups to the driver
On Thu, 2012-10-18 at 17:34 +0300, Andy Shevchenko wrote: > There are few cleanups to the driver which partialy acked and reviewed. > > Since v2: > - add one more clean up (patch 6/6) > - make a separate patch to WARN a user in dwc_handle_error (suggested by >Felipe Balbi) > - add a description to patch 4/6 > > Andy Shevchenko (4): > dw_dmac: change dev_printk() to corresponding macros > dw_dmac: don't call platform_get_drvdata twice > dw_dmac: change dev_crit to dev_WARN in dwc_handle_error > dw_dmac: introduce to_dw_desc() macro > > Heikki Krogerus (2): > dmaengine: dw_dmac: remove CLK dependency > dmaengine: dw_dmac: amend description and indentation > > drivers/dma/Kconfig|1 - > drivers/dma/dw_dmac.c | 33 ++--- > drivers/dma/dw_dmac_regs.h |2 ++ > 3 files changed, 16 insertions(+), 20 deletions(-) > Applied thanks -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] DMA: PL330: Balance module remove function with probe
On Thu, 2012-10-25 at 16:53 +0530, Inderpal Singh wrote: > > This code will get executed only in case of force removal of the > module which was discussed in the first version of the patch at [1]. > Now, if we do not have to think about force removal then this patch > will go back to the first version. But why are you doing force removal of driver even when client is holding a reference to you. What happens when client finally tries to free the channel? What is the problem you are trying to solve? > > Let me know your view. > > [1] https://patchwork.kernel.org/patch/1503171/ > -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Fri, 2012-10-26 at 14:25 +0530, Viresh Kumar wrote: > Hi Vinod, > > On 16 October 2012 09:49, Viresh Kumar wrote: > > dw_dmac driver already supports device tree but it used to have its platform > > data passed the non-DT way. > > > > This patch does following changes: > > - pass platform data via DT, non-DT way still takes precedence if both are > > used. > > - create generic filter routine > > - Earlier slave information was made available by slave specific filter > > routines > > in chan->private field. Now, this information would be passed from within > > dmac > > DT node. Slave drivers would now be required to pass bus_id (a string) as > > parameter to this generic filter(), which would be compared against the > > slave > > data passed from DT, by the generic filter routine. > > - Update binding document > > I can see that you applied these patches and they are present in > linux-next. But i feel > the order of patches is bad. Yes looks like I forgot to sort the mbox series :( since all patches were applied nicely, and they seem fairly independent of each other it should cause issue. Let me know if you wnat me to redo my -next. -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/3] dmaengine: dw_dmac: Enhance device tree support
On Fri, 2012-10-26 at 14:35 +0530, Viresh Kumar wrote: > >> I can see that you applied these patches and they are present in > >> linux-next. But i feel > >> the order of patches is bad. > > Yes looks like I forgot to sort the mbox series :( > > > > since all patches were applied nicely, and they seem fairly independent > > of each other it should cause issue. Let me know if you wnat me to redo > > my -next. > > yes. The ARCH specific patch 3/3 uses a routine created in 2/3. So they have > to be in right order for git bisect to work. Done, it should reflect now. Sorry for the mess. -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: use devm_* functions to simplify code
On Tue, 2012-07-24 at 11:00 +0300, Andy Shevchenko wrote: > Use devm_kzalloc, devm_clk_get, devm_request_irq, and devm_request_and_ioremap > to reduce the code and to simplify the error path. > > Signed-off-by: Andy Shevchenko > Cc: Viresh Kumar Applied thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9 v3] dma: shdma: convert to the shdma base library
On Wed, 2012-07-25 at 12:59 +0900, Paul Mundt wrote: > On Wed, May 09, 2012 at 05:09:21PM +0200, Guennadi Liakhovetski wrote: > > The shdma base library has originally been extracted from the shdma driver, > > which now can be converted to actually use it. > > > > Signed-off-by: Guennadi Liakhovetski > > --- > > drivers/dma/sh/shdma.c | 1122 > > > > drivers/dma/sh/shdma.h | 44 +- > > include/linux/sh_dma.h | 33 +- > > 3 files changed, 302 insertions(+), 897 deletions(-) > > > Now that this has hit mainline, the sh-sci with DMA enabled build is > broken: > > CC drivers/tty/serial/sh-sci.o > drivers/tty/serial/sh-sci.c: In function 'work_fn_rx': > drivers/tty/serial/sh-sci.c:1413:67: error: dereferencing pointer to > incomplete type > drivers/tty/serial/sh-sci.c:1413:81: warning: type defaults to 'int' in > declaration of '__mptr' > drivers/tty/serial/sh-sci.c:1413:90: warning: initialization from > incompatible pointer type > drivers/tty/serial/sh-sci.c:1413:161: error: invalid use of undefined type > 'struct sh_desc' > drivers/tty/serial/sh-sci.c:1419:83: error: dereferencing pointer to > incomplete type > drivers/tty/serial/sh-sci.c:1419:101: error: dereferencing pointer to > incomplete type > drivers/tty/serial/sh-sci.c:1423:42: error: dereferencing pointer to > incomplete type This was in -next for quite some time :( -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9 v3] dma: shdma: convert to the shdma base library
On Thu, 2012-07-26 at 15:58 +0900, Paul Mundt wrote: > On Thu, Jul 26, 2012 at 12:19:21PM +0530, Vinod Koul wrote: > > On Wed, 2012-07-25 at 12:59 +0900, Paul Mundt wrote: > > > On Wed, May 09, 2012 at 05:09:21PM +0200, Guennadi Liakhovetski wrote: > > > > The shdma base library has originally been extracted from the shdma > > > > driver, > > > > which now can be converted to actually use it. > > > > > > > > Signed-off-by: Guennadi Liakhovetski > > > > --- > > > > drivers/dma/sh/shdma.c | 1122 > > > > > > > > drivers/dma/sh/shdma.h | 44 +- > > > > include/linux/sh_dma.h | 33 +- > > > > 3 files changed, 302 insertions(+), 897 deletions(-) > > > > > > > Now that this has hit mainline, the sh-sci with DMA enabled build is > > > broken: > > > > > > CC drivers/tty/serial/sh-sci.o > > > drivers/tty/serial/sh-sci.c: In function 'work_fn_rx': > > > drivers/tty/serial/sh-sci.c:1413:67: error: dereferencing pointer to > > > incomplete type > > > drivers/tty/serial/sh-sci.c:1413:81: warning: type defaults to 'int' in > > > declaration of '__mptr' > > > drivers/tty/serial/sh-sci.c:1413:90: warning: initialization from > > > incompatible pointer type > > > drivers/tty/serial/sh-sci.c:1413:161: error: invalid use of undefined > > > type 'struct sh_desc' > > > drivers/tty/serial/sh-sci.c:1419:83: error: dereferencing pointer to > > > incomplete type > > > drivers/tty/serial/sh-sci.c:1419:101: error: dereferencing pointer to > > > incomplete type > > > drivers/tty/serial/sh-sci.c:1423:42: error: dereferencing pointer to > > > incomplete type > > This was in -next for quite some time :( > > > It seems we don't have any configs that have this default-enabled under > -next, so it wasn't noticed before. Still, as Guennadi wrote this code > I'm surprised it was overlooked. So did my script :( I tried checking this, struct sh_desc have moved to struct shdma_desc in shdma-base.h. But the field partial was dropped, so we need to use residue here. But, shdma or base doesn't calculate residue for err transactions, so you cannot use it to start a new one. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: imx-dma: Fix kernel crash due to missing clock conversion
On Thu, 2012-07-26 at 14:46 +0200, javier Martin wrote: > Who is responsible of applying this patch? > > It seems 3.5 has been released without it. > The buck stops here :( Sorry looks like this got missed while I was on vacation. Now that 3.5 is released, I will CC stable and apply this to my fixes and send to Linus for rc1. You should see this in -next once rc1 is declared, if not please do yell. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: imx-dma: Fix kernel crash due to missing clock conversion
On Tue, 2012-07-03 at 15:33 -0300, Fabio Estevam wrote: > From: Fabio Estevam > > With the new i.MX clock infrastructure we need to request the dma clocks > seperately: ahb and ipg clocks. > > This fixes the following kernel crash and make audio to be functional again: > > root@freescale /home$ aplay audio48k16S.wav > Playing WAVE 'audio48k16S.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, > Stereo > Unable to handle kernel NULL pointer dereference at virtual address > pgd = c7b74000 > [] *pgd=a7bb5831, *pte=, *ppte= > Internal error: Oops: 17 [#1] PREEMPT ARM > Modules linked in: > CPU: 0Not tainted (3.5.0-rc5-next-20120702-7-g3028b64 #1128) > PC is at snd_dmaengine_pcm_get_chan+0x8/0x10 > LR is at snd_imx_pcm_hw_params+0x18/0xdc > pc : []lr : []psr: a013 > sp : c7b45e30 ip : fp : c7ae58e0 > r10: r9 : c7ae981c r8 : c7b88800 > r7 : c7ae5a60 r6 : c7ae5b20 r5 : c7ae9810 r4 : c7afa060 > r3 : r2 : 0001 r1 : c7b88800 r0 : c7afa060 > Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > Control: 0005317f Table: a7b74000 DAC: 0015 > Process aplay (pid: 701, stack limit = 0xc7b44270) > Stack: (0xc7b45e30 to 0xc7b46000) > 5e20: 0010 0029 c7b88800 c02db870 > 5e40: c7ae5a60 c02d4594 0010 01ae5a60 c7ae5a60 c7ae9810 c7ae9810 c7afa060 > 5e60: c7ae5b20 c7ae5a60 c7b88800 c02e3ef0 c02e3e08 c7b1e400 c7afa060 c7b88800 > 5e80: c0014da8 c7b44000 bec566ac c02cd400 c7afa060 c7afa060 > 5ea0: bec56800 c7b88800 c0014da8 c02cdd7c c04ee710 c04ee7b8 0003 c005fc74 > 5ec0: 7fff c7b45f00 c7afa060 c7b67420 c7ba3070 0004 c0014da8 > 5ee0: c7b44000 bec566ac c02ced88 c04e95f8 b6f5ab04 c7b45fb0 0145a468 > 5f00: 0145a600 bec566bc bec56800 c7b67420 c7ba3070 c00d499c c7b45f18 c7b45f18 > 5f20: 001a 0004 0001 c7b44000 c0527f40 0009 0008 > 5f40: c7b44000 c002c9ec 0001 c04f0ab0 c04ebec0 0101 000a > 5f60: 6093 c7b67420 bec56800 c25c4111 0004 c0014da8 c7b44000 > 5f80: bec566ac c00d4f38 b6ffb658 c0522d80 0145a468 b6fd5000 0145a418 > 5fa0: 0036 c0014c00 0145a468 b6fd5000 0004 c25c4111 bec56800 00020001 > 5fc0: 0145a468 b6fd5000 0145a418 0036 0145a468 0145a600 bec566bc bec566ac > 5fe0: 0145a468 bec56388 b6f65ce4 b6dcebec 2010 0004 > [] (snd_dmaengine_pcm_get_chan+0x8/0x10) from [] > (snd_imx_pcm_hw_params+0x18/0xdc) > [] (snd_imx_pcm_hw_params+0x18/0xdc) from [] > (soc_pcm_hw_params+0xe8/0x1f0) > [] (soc_pcm_hw_params+0xe8/0x1f0) from [] > (snd_pcm_hw_params+0x124/0x474) > [] (snd_pcm_hw_params+0x124/0x474) from [] > (snd_pcm_common_ioctl1+0x4b4/0xf74) > [] (snd_pcm_common_ioctl1+0x4b4/0xf74) from [] > (snd_pcm_playback_ioctl1+0x30/0x510) > [] (snd_pcm_playback_ioctl1+0x30/0x510) from [] > (do_vfs_ioctl+0x80/0x5e4) > [] (do_vfs_ioctl+0x80/0x5e4) from [] (sys_ioctl+0x38/0x60) > [] (sys_ioctl+0x38/0x60) from [] > (ret_fast_syscall+0x0/0x2c) > Code: e593000c e12fff1e e59030a0 e59330bc (e593) > ---[ end trace fa518c8ba3a74e97 ]-- > > Reported-by: Javier Martin > Signed-off-by: Fabio Estevam Applied thanks (to fixes-for 3.7) Sorry for missing this out, please ping if you dont see a response to patch in week or so. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] serial: sh-sci: fix compilation breakage (3.6)
On Tue, 2012-07-31 at 15:07 +0900, Paul Mundt wrote: > On Mon, Jul 30, 2012 at 09:28:18PM +0200, Guennadi Liakhovetski wrote: > > Hi all > > > > as has been reported in this > > > > http://thread.gmane.org/gmane.linux.kernel/1294256/focus=16001 > > > > thread, currently sh-sci doesn't comiple in the mainline and in -next if > > CONFIG_SERIAL_SH_SCI_DMA is enabled. This patch series fixes this > > breakage. > > > Looks alright to me. Vinod, how do you want to handle this? I can roll > both of these patches in to my tree with your Acked-by, or I can provide > you with mine for the sh-sci bits if you want to take it via yours. I'm > planning on sending my next round of updates to Linus in the next couple > of days. Looks fine to me as well Acked-by: Vinod Koul -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: imx-dma: Fix kernel crash due to missing clock conversion
On Mon, 2012-07-30 at 14:38 +0200, javier Martin wrote: > On 30 July 2012 13:31, javier Martin wrote: > > Hi, > > > > On 27 July 2012 13:37, Fabio Estevam wrote: > >> On Fri, Jul 27, 2012 at 12:17 AM, Vinod Koul > >> wrote: > >> > >>>> Reported-by: Javier Martin > >>>> Signed-off-by: Fabio Estevam > >>> Applied thanks (to fixes-for 3.7) > >> > >> You mentioned that you would also copy stable. Would it be applied > >> into stable soon too? Once it hits the linus's tree, yes. > > > > I agree with Fabio, this patch should also be applied to stable. > I almost forgot, > Vinod, I am a bit confused about the branch you've used to merge this > patch. The branch is called 'fixes_for-3.7'. Does this mean that the > patch won't be applied for 3.6? I've seen you've added the line ' Cc: > sta...@vger.kernel.org' which ensures the patch will appear in 3.5.X > but what about 3.6? This patch will appear in 3.7-rc2 when I send the fixes to Linus post rc1, I guess early next week. Stable guys will pick this and apply to 3.6.X version. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] dma: tegra: enable/disable dma clock
On Fri, 2012-07-27 at 13:42 +0530, Laxman Dewangan wrote: > On Tuesday 24 July 2012 10:30 AM, Laxman Dewangan wrote: > > On Tuesday 24 July 2012 10:38 AM, Vinod Koul wrote: > >> On Fri, 2012-07-20 at 13:31 +0530, Laxman Dewangan wrote: > >>> Enable the DMA clock when allocating channel and > >>> disable clock when freeing channels. > >>> > >>> Signed-off-by: Laxman Dewangan > >>> --- > >>> + clk_disable_unprepare(tdma->dma_clk); > >> What if another channel is active, disabling clock can cause bad > >> behavior. You should check here if all channels are idle and then > >> disable, or is this handled by clock API? > > Yes, clock driver keeps the reference count and so client driver need > > not to take care. > > > Hi Vinod, > Is there any thing remaining from my side here? Nope, I will take care of it > Is it possible to make it for K3.6? Nope 3.6 is released, too late for that -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] dma: tegra: enable/disable dma clock
On Fri, 2012-07-20 at 13:31 +0530, Laxman Dewangan wrote: > Enable the DMA clock when allocating channel and > disable clock when freeing channels. > > Signed-off-by: Laxman Dewangan Thanks Applied to for-3.7 -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: imx-dma: Fix kernel crash due to missing clock conversion
On Tue, 2012-07-31 at 13:46 +0200, javier Martin wrote: > On 31 July 2012 13:38, Fabio Estevam wrote: > > On Tue, Jul 31, 2012 at 3:46 AM, Vinod Koul > > wrote: > > > >> This patch will appear in 3.7-rc2 when I send the fixes to Linus post > >> rc1, I guess early next week. > > > > I guess you mean 3.6-rc2, right? > > > >> Stable guys will pick this and apply to 3.6.X version. > > > > I guess you mean 3.5.x, right? > > Ditto. Yup :( -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] slave-dmaengine fixes
Hi Linus, Please consider pull to receive few fixes on slave dmanengine. There are two trivial fixes in pl330 driver and two in at_hdmac driver. The following changes since commit ffc493062ce9987156945aa21a677d83a179fc0a: Laxman Dewangan (1): dma: tegra: enable/disable dma clock are available in the git repository at: git://git.infradead.org/users/vkoul/slave-dma.git fixes Nicolas Ferre (2): dmaengine: at_hdmac: fix comment in atc_prep_slave_sg() dmaengine: at_hdmac: check that each sg data length is non-null Sachin Kamat (2): DMA: PL330: Fix potential NULL pointer dereference in pl330_submit_req() DMA: PL330: Check the pointer returned by kzalloc drivers/dma/at_hdmac.c | 13 - drivers/dma/pl330.c| 21 ++--- 2 files changed, 26 insertions(+), 8 deletions(-) -- ~Vinod signature.asc Description: This is a digitally signed message part
Re: [PATCH 0/2] dmaengine: Fix compillation issues in device_prep_dma_cyclic()
On Mon, 2012-09-24 at 10:58 +0300, Peter Ujfalusi wrote: > Hello, > > The reason for the breakage is the patch 1 got lost somewhere in the process. > I also greped the whole tree for device_prep_dma_cyclic() and the second patch > is the result of that. > > PS: I did build tested the series on ARM (OMAP), x86_32, x86_64 but not for > ppc > for sure. I though patch 1 was part of the series Mark was supposed to apply. Anyway both look fine to me so: Both Acked-By: Vinod Koul -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv1 6/6] MAINTAINERS: add recently created files to dw_dmac section
On Tue, 2012-09-25 at 16:37 +0300, Andy Shevchenko wrote: > > Perhaps these F: lines instead > > > > F:include/linux/dw_dmac.h > > F:drivers/dma/dw_dmac* > Might be. There is another idea to move them under drivers/dma/dw/ > folder. So, Viresh, what do you think is better? I think that a good idea. -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] slave-dmaengine fixes
Hi Linus, Please consider pull to receive three fixes for slave dmanegine. Two are for typo omissions in sifr dmaengine driver and last one is for imx driver fixing the misisng unlock The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linus Torvalds (1): Linux 3.7-rc1 are available in the git repository at: git://git.infradead.org/users/vkoul/slave-dma.git fixes Barry Song (2): dmaengine: sirf: fix a typo in dma_prep_interleaved dmaengine: sirf: fix a typo in moving running dma_desc to active queue Wei Yongjun (1): dmaengine: imx-dma: fix missing unlock on error in imxdma_xfer_desc() drivers/dma/imx-dma.c |4 +++- drivers/dma/sirf-dma.c |4 ++-- 2 files changed, 5 insertions(+), 3 deletions(-) -- Vinod Koul Intel Corp. signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 3/4] DMA: PL330: Balance module remove function with probe
On Sat, 2012-10-27 at 15:50 +0530, Inderpal Singh wrote: > Hi Vinod, > > On 26 October 2012 10:15, Vinod Koul wrote: > > On Thu, 2012-10-25 at 16:53 +0530, Inderpal Singh wrote: > >> > >> This code will get executed only in case of force removal of the > >> module which was discussed in the first version of the patch at [1]. > >> Now, if we do not have to think about force removal then this patch > >> will go back to the first version. > > But why are you doing force removal of driver even when client is > > holding a reference to you. > > > > What happens when client finally tries to free the channel? > Since we return EBUSY so forced removal won't succeed. Client can free > the channel eventually. And that is my concern. You have forcefully removed the dma module. What happens then? How will the free calll get executed, wont you hit a panic. > > > > > What is the problem you are trying to solve? > >> > > There was a long discussion about it in the first version of the > patch. Allow me to explain it to you. > > The existing driver does DMA_TERMINATE_ALL and frees resources for all > the channels in the _remove function. Which for starters may not be right thing to do. Shouldn't you first make sure client has freed all references to your driver and then only remove. Freeing resources in .remove without keeping client in sync doesn't sound to be good idea to me. > The first version of patch > removed this flushing and freeing of channel resources because they > are not getting allocated in the probe. Jassi pointed out that manual > flushing is needed if a force removal happens and some client is > queued. Then it was agreed that flushing is not needed, instead we > should return EBUSY if client is queued on some channel (this will > happen only in force removal case). Hence this additional check in v2 > version so that force removal does not succeeds if any client is > queued. > > If you think force removal is not a practical scenario and we should > not be bothering about it, this check can be removed and the patch > will go back to first version which just removes flushing and freeing > of channels beacues they are not getting allocated in probe. > > Let me know your view. > > Regards, > Inder > > > >> Let me know your view. > >> > >> [1] https://patchwork.kernel.org/patch/1503171/ > >> > > > > > > -- > > Vinod Koul > > Intel Corp. > > -- Vinod Koul Intel Corp. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
