Re: [PATCH] media: v4l: omap_vout: vrfb: remove an unused variable
On 2018-03-13 14:05, Arnd Bergmann wrote:
> We now get a warning after the 'dmadev' variable is no longer used:
>
> drivers/media/platform/omap/omap_vout_vrfb.c: In function
> 'omap_vout_prepare_vrfb':
> drivers/media/platform/omap/omap_vout_vrfb.c:239:21: error: unused variable
> 'dmadev' [-Werror=unused-variable]
>
> Fixes: 8f0aa38292f2 ("media: v4l: omap_vout: vrfb: Use the wrapper for
> prep_interleaved_dma()")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
Reviewed-by: Peter Ujfalusi <peter.ujfal...@ti.com>
> ---
> drivers/media/platform/omap/omap_vout_vrfb.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c
> b/drivers/media/platform/omap/omap_vout_vrfb.c
> index 72c0ac2cbf3d..1d8508237220 100644
> --- a/drivers/media/platform/omap/omap_vout_vrfb.c
> +++ b/drivers/media/platform/omap/omap_vout_vrfb.c
> @@ -236,7 +236,6 @@ int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
> struct dma_async_tx_descriptor *tx;
> enum dma_ctrl_flags flags = DMA_PREP_INTERRUPT | DMA_CTRL_ACK;
> struct dma_chan *chan = vout->vrfb_dma_tx.chan;
> - struct dma_device *dmadev = chan->device;
> struct dma_interleaved_template *xt = vout->vrfb_dma_tx.xt;
> dma_cookie_t cookie;
> enum dma_status status;
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH] media: v4l: omap_vout: vrfb: Use the wrapper for prep_interleaved_dma()
Instead of directly accessing to dmadev->device_prep_interleaved_dma() use
the dmaengine_prep_interleaved_dma() wrapper instead.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/media/platform/omap/omap_vout_vrfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c
b/drivers/media/platform/omap/omap_vout_vrfb.c
index 123c2b26a933..72c0ac2cbf3d 100644
--- a/drivers/media/platform/omap/omap_vout_vrfb.c
+++ b/drivers/media/platform/omap/omap_vout_vrfb.c
@@ -271,7 +271,7 @@ int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
xt->dst_sgl = true;
xt->dst_inc = true;
- tx = dmadev->device_prep_interleaved_dma(chan, xt, flags);
+ tx = dmaengine_prep_interleaved_dma(chan, xt, flags);
if (tx == NULL) {
pr_err("%s: DMA interleaved prep error\n", __func__);
return -EINVAL;
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH] [BUGREPORT] media: v4l: omap_vout: vrfb: initialize DMA flags
Arnd,
sorry for the delayed response, I was away w/o internet connection for
the past weeks.
On 2017-07-10 14:18, Arnd Bergmann wrote:
> Passing uninitialized flags into device_prep_interleaved_dma is clearly
> a bad idea, and we get a compiler warning for it:
>
> drivers/media/platform/omap/omap_vout_vrfb.c: In function
> 'omap_vout_prepare_vrfb':
> drivers/media/platform/omap/omap_vout_vrfb.c:273:5: error: 'flags' may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
I can not explain why I have missed this.
> It seems that the OMAP dmaengine ignores the flags, but we should
> pick the right ones anyway. Unfortunately I don't know what they
> should be, so I just picked the most common flags. Please set the
> right flags here and fold the modified patch.
The flags are fine.
>
> Fixes: 6a1560ecaa8c ("media: v4l: omap_vout: vrfb: Convert to dmaengine")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
Acked-by: Peter Ujfalusi <peter.ujfal...@ti.com>
> ---
> drivers/media/platform/omap/omap_vout_vrfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c
> b/drivers/media/platform/omap/omap_vout_vrfb.c
> index 45a553d4f5b2..fed28b6bbbc0 100644
> --- a/drivers/media/platform/omap/omap_vout_vrfb.c
> +++ b/drivers/media/platform/omap/omap_vout_vrfb.c
> @@ -233,7 +233,7 @@ int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
> struct videobuf_buffer *vb)
> {
> struct dma_async_tx_descriptor *tx;
> - enum dma_ctrl_flags flags;
> + enum dma_ctrl_flags flags = DMA_PREP_INTERRUPT | DMA_CTRL_ACK;
> struct dma_chan *chan = vout->vrfb_dma_tx.chan;
> struct dma_device *dmadev = chan->device;
> struct dma_interleaved_template *xt = vout->vrfb_dma_tx.xt;
>
- Péter
Re: [RESEND v2 PATCH] v4l: omap_vout: vrfb: Convert to dmaengine
On 2017-05-03 14:08, Peter Ujfalusi wrote:
The dmaengine driver for sDMA now have support for interleaved transfer.
This trasnfer type was open coded with the legacy omap-dma API, but now
we can move it to dmaengine.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
Hi,
changes since RESEND (27.10.2016):
- rebased on next-20170503
I can not test it on real HW (still), but I have validated [1] that the change
is correct and should not cause any regression.
Laurent: can you verify the patch on a real hardware?
[1]
https://github.com/omap-audio/linux-audio/blob/peter/linux-next-wip/drivers/misc/ovv_dmaengine.c
Regards,
Peter
drivers/media/platform/omap/omap_vout_vrfb.c | 133 ---
drivers/media/platform/omap/omap_voutdef.h | 6 +-
2 files changed, 83 insertions(+), 56 deletions(-)
diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c
b/drivers/media/platform/omap/omap_vout_vrfb.c
index 92c4e1826356..45a553d4f5b2 100644
--- a/drivers/media/platform/omap/omap_vout_vrfb.c
+++ b/drivers/media/platform/omap/omap_vout_vrfb.c
@@ -16,7 +16,6 @@
#include
#include
-#include
#include
#include "omap_voutdef.h"
@@ -63,7 +62,7 @@ static int omap_vout_allocate_vrfb_buffers(struct
omap_vout_device *vout,
/*
* Wakes up the application once the DMA transfer to VRFB space is completed.
*/
-static void omap_vout_vrfb_dma_tx_callback(int lch, u16 ch_status, void *data)
+static void omap_vout_vrfb_dma_tx_callback(void *data)
{
struct vid_vrfb_dma *t = (struct vid_vrfb_dma *) data;
@@ -94,6 +93,7 @@ int omap_vout_setup_vrfb_bufs(struct platform_device *pdev,
int vid_num,
int ret = 0, i, j;
struct omap_vout_device *vout;
struct video_device *vfd;
+ dma_cap_mask_t mask;
int image_width, image_height;
int vrfb_num_bufs = VRFB_NUM_BUFS;
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
@@ -131,18 +131,27 @@ int omap_vout_setup_vrfb_bufs(struct platform_device
*pdev, int vid_num,
/*
* Request and Initialize DMA, for DMA based VRFB transfer
*/
- vout->vrfb_dma_tx.dev_id = OMAP_DMA_NO_DEVICE;
- vout->vrfb_dma_tx.dma_ch = -1;
- vout->vrfb_dma_tx.req_status = DMA_CHAN_ALLOTED;
- ret = omap_request_dma(vout->vrfb_dma_tx.dev_id, "VRFB DMA TX",
- omap_vout_vrfb_dma_tx_callback,
- (void *) >vrfb_dma_tx, >vrfb_dma_tx.dma_ch);
- if (ret < 0) {
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_INTERLEAVE, mask);
+ vout->vrfb_dma_tx.chan = dma_request_chan_by_mask();
+ if (IS_ERR(vout->vrfb_dma_tx.chan)) {
vout->vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
+ } else {
+ size_t xt_size = sizeof(struct dma_interleaved_template) +
+sizeof(struct data_chunk);
+
+ vout->vrfb_dma_tx.xt = kzalloc(xt_size, GFP_KERNEL);
+ if (!vout->vrfb_dma_tx.xt) {
+ dma_release_channel(vout->vrfb_dma_tx.chan);
+ vout->vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
+ }
+ }
+
+ if (vout->vrfb_dma_tx.req_status == DMA_CHAN_NOT_ALLOTED)
dev_info(>dev,
": failed to allocate DMA Channel for video%d\n",
vfd->minor);
- }
+
init_waitqueue_head(>vrfb_dma_tx.wait);
/* statically allocated the VRFB buffer is done through
@@ -177,7 +186,9 @@ void omap_vout_release_vrfb(struct omap_vout_device *vout)
if (vout->vrfb_dma_tx.req_status == DMA_CHAN_ALLOTED) {
vout->vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
- omap_free_dma(vout->vrfb_dma_tx.dma_ch);
+ kfree(vout->vrfb_dma_tx.xt);
+ dmaengine_terminate_sync(vout->vrfb_dma_tx.chan);
+ dma_release_channel(vout->vrfb_dma_tx.chan);
}
}
@@ -219,70 +230,84 @@ int omap_vout_vrfb_buffer_setup(struct omap_vout_device
*vout,
}
int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
- struct videobuf_buffer *vb)
+ struct videobuf_buffer *vb)
{
- dma_addr_t dmabuf;
- struct vid_vrfb_dma *tx;
+ struct dma_async_tx_descriptor *tx;
+ enum dma_ctrl_flags flags;
+ struct dma_chan *chan = vout->vrfb_dma_tx.chan;
+ struct dma_device *dmadev = chan->device;
+ struct dma_interleaved_template *xt = vout->vrfb_dma_tx.xt;
+ dma_cookie_t cookie;
+ enum dma_status status;
enum dss_rotation rotation;
- u32 dest_frame_index = 0, src_element_index = 0;
- u32 dest_element_index = 0, src_frame_index = 0;
- u32 elem_count = 0, frame_count = 0, pixsize = 2;
+ size_t dst_icg;
+ u32 p
[RESEND v2 PATCH] v4l: omap_vout: vrfb: Convert to dmaengine
The dmaengine driver for sDMA now have support for interleaved transfer.
This trasnfer type was open coded with the legacy omap-dma API, but now
we can move it to dmaengine.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
Hi,
changes since RESEND (27.10.2016):
- rebased on next-20170503
I can not test it on real HW (still), but I have validated [1] that the change
is correct and should not cause any regression.
Laurent: can you verify the patch on a real hardware?
Regards,
Peter
drivers/media/platform/omap/omap_vout_vrfb.c | 133 ---
drivers/media/platform/omap/omap_voutdef.h | 6 +-
2 files changed, 83 insertions(+), 56 deletions(-)
diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c
b/drivers/media/platform/omap/omap_vout_vrfb.c
index 92c4e1826356..45a553d4f5b2 100644
--- a/drivers/media/platform/omap/omap_vout_vrfb.c
+++ b/drivers/media/platform/omap/omap_vout_vrfb.c
@@ -16,7 +16,6 @@
#include
#include
-#include
#include
#include "omap_voutdef.h"
@@ -63,7 +62,7 @@ static int omap_vout_allocate_vrfb_buffers(struct
omap_vout_device *vout,
/*
* Wakes up the application once the DMA transfer to VRFB space is completed.
*/
-static void omap_vout_vrfb_dma_tx_callback(int lch, u16 ch_status, void *data)
+static void omap_vout_vrfb_dma_tx_callback(void *data)
{
struct vid_vrfb_dma *t = (struct vid_vrfb_dma *) data;
@@ -94,6 +93,7 @@ int omap_vout_setup_vrfb_bufs(struct platform_device *pdev,
int vid_num,
int ret = 0, i, j;
struct omap_vout_device *vout;
struct video_device *vfd;
+ dma_cap_mask_t mask;
int image_width, image_height;
int vrfb_num_bufs = VRFB_NUM_BUFS;
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
@@ -131,18 +131,27 @@ int omap_vout_setup_vrfb_bufs(struct platform_device
*pdev, int vid_num,
/*
* Request and Initialize DMA, for DMA based VRFB transfer
*/
- vout->vrfb_dma_tx.dev_id = OMAP_DMA_NO_DEVICE;
- vout->vrfb_dma_tx.dma_ch = -1;
- vout->vrfb_dma_tx.req_status = DMA_CHAN_ALLOTED;
- ret = omap_request_dma(vout->vrfb_dma_tx.dev_id, "VRFB DMA TX",
- omap_vout_vrfb_dma_tx_callback,
- (void *) >vrfb_dma_tx, >vrfb_dma_tx.dma_ch);
- if (ret < 0) {
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_INTERLEAVE, mask);
+ vout->vrfb_dma_tx.chan = dma_request_chan_by_mask();
+ if (IS_ERR(vout->vrfb_dma_tx.chan)) {
vout->vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
+ } else {
+ size_t xt_size = sizeof(struct dma_interleaved_template) +
+sizeof(struct data_chunk);
+
+ vout->vrfb_dma_tx.xt = kzalloc(xt_size, GFP_KERNEL);
+ if (!vout->vrfb_dma_tx.xt) {
+ dma_release_channel(vout->vrfb_dma_tx.chan);
+ vout->vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
+ }
+ }
+
+ if (vout->vrfb_dma_tx.req_status == DMA_CHAN_NOT_ALLOTED)
dev_info(>dev,
": failed to allocate DMA Channel for video%d\n",
vfd->minor);
- }
+
init_waitqueue_head(>vrfb_dma_tx.wait);
/* statically allocated the VRFB buffer is done through
@@ -177,7 +186,9 @@ void omap_vout_release_vrfb(struct omap_vout_device *vout)
if (vout->vrfb_dma_tx.req_status == DMA_CHAN_ALLOTED) {
vout->vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
- omap_free_dma(vout->vrfb_dma_tx.dma_ch);
+ kfree(vout->vrfb_dma_tx.xt);
+ dmaengine_terminate_sync(vout->vrfb_dma_tx.chan);
+ dma_release_channel(vout->vrfb_dma_tx.chan);
}
}
@@ -219,70 +230,84 @@ int omap_vout_vrfb_buffer_setup(struct omap_vout_device
*vout,
}
int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
- struct videobuf_buffer *vb)
+ struct videobuf_buffer *vb)
{
- dma_addr_t dmabuf;
- struct vid_vrfb_dma *tx;
+ struct dma_async_tx_descriptor *tx;
+ enum dma_ctrl_flags flags;
+ struct dma_chan *chan = vout->vrfb_dma_tx.chan;
+ struct dma_device *dmadev = chan->device;
+ struct dma_interleaved_template *xt = vout->vrfb_dma_tx.xt;
+ dma_cookie_t cookie;
+ enum dma_status status;
enum dss_rotation rotation;
- u32 dest_frame_index = 0, src_element_index = 0;
- u32 dest_element_index = 0, src_frame_index = 0;
- u32 elem_count = 0, frame_count = 0, pixsize = 2;
+ size_t dst_icg;
+ u32 pixsize;
if (!is_rotation_enabled(vout))
return 0;
- dmabuf = vout->buf_phy_addr[vb->i];
/* If rotation is enabled, c
Re: [PATCH RESEND] media: omap3isp: Use dma_request_chan() to requesting DMA channel
Hi Laurent, On 11/03/2016 05:12 PM, Laurent Pinchart wrote: >> It is a bit misleading that it used dma_request_slave_channel_compat() >> for getting the channel. >> >> I think what would be correct is: >> dma_cap_mask_t mask; >> >> dma_cap_zero(mask); >> dma_cap_set(DMA_SLAVE, mask); >> hist->dma_ch = dma_request_chan_by_mask(); >> >> We will get any DMA channel capable of slave configuration, but we will >> configure no DMA request number for the channel. > > I believe that should work. It could in theory result in a different > behaviour > as it could return a DMA channel not handled by the OMAP SDMA engine, but I > don't think that would be an issue. Yes, that could be the case if we would have more than one DMAs in SoCs where the omap3isp is used, but we only have sDMA. The reason why I would like to move the driver to use the generic API is that my plan is to remove the legacy sDMA support in the future so the filter_fn is not going to be available outside of the DMAengine driver. I do believe that this is safe to do in this way and if the IP shows up somewhere else where we have more than one DMAs - which is unlikely - I'm sure it can be fixed up, but w/o device it is hard to guess what needs to be done. FWIW: if omap3isp shows up where we have sDMA and eDMA we can set the mask as DMA_SLAVE | DMA_MEMCPY as eDMA does not set both for a channel - it is either slave or memcpy. >> and document this in the driver... > -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] media: omap3isp: Use dma_request_chan_by_mask() to request the DMA channel
When requesting the DMA channel it was mandatory that we do not have DMA
resource nor valid DMA channel via DT. In this case the
dma_request_slave_channel_compat() would fall back and request any channel
with SW trigger.
The same can be achieved with the dma_request_chan_by_mask() without the
misleading use of the DMAengine API - implying that the omap3isp does
need to have DMA resource or valid dma binding in DT.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
CC: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
CC: Mauro Carvalho Chehab <mche...@osg.samsung.com>
---
Hi,
Changes sicne v1:
- use dma_request_chan_by_mask() to request the channel as for the histogram
data reading we do not have hw syncronisation. Add comment about this also to
clarify the reason.
Regards,
Peter
drivers/media/platform/omap3isp/isphist.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isphist.c
b/drivers/media/platform/omap3isp/isphist.c
index 7138b043a4aa..a4ed5d140d48 100644
--- a/drivers/media/platform/omap3isp/isphist.c
+++ b/drivers/media/platform/omap3isp/isphist.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
@@ -486,27 +485,30 @@ int omap3isp_hist_init(struct isp_device *isp)
hist->isp = isp;
if (HIST_CONFIG_DMA) {
- struct platform_device *pdev = to_platform_device(isp->dev);
- struct resource *res;
- unsigned int sig = 0;
dma_cap_mask_t mask;
+ /*
+* We need slave capable channel without DMA request line for
+* reading out the data.
+* For this we can use dma_request_chan_by_mask() as we are
+* happy with any channel as long as it is capable of slave
+* configuration.
+*/
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
+ hist->dma_ch = dma_request_chan_by_mask();
+ if (IS_ERR(hist->dma_ch)) {
+ ret = PTR_ERR(hist->dma_ch);
+ if (ret == -EPROBE_DEFER)
+ return ret;
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- "hist");
- if (res)
- sig = res->start;
-
- hist->dma_ch = dma_request_slave_channel_compat(mask,
- omap_dma_filter_fn, , isp->dev, "hist");
- if (!hist->dma_ch)
+ hist->dma_ch = NULL;
dev_warn(isp->dev,
"hist: DMA channel request failed, using
PIO\n");
- else
+ } else {
dev_dbg(isp->dev, "hist: using DMA channel %s\n",
dma_chan_name(hist->dma_ch));
+ }
}
hist->ops = _ops;
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] media: omap3isp: Use dma_request_chan() to requesting DMA channel
On 11/03/2016 11:23 AM, Peter Ujfalusi wrote:
>
> On 11/02/2016 11:19 PM, Laurent Pinchart wrote:
>> > Hi Peter,
>> >
>> > Thank you for the patch.
>> >
>> > On Wednesday 02 Nov 2016 14:39:59 Peter Ujfalusi wrote:
>>> >> With the new dma_request_chan() the client driver does not need to look
>>> >> for
>>> >> the DMA resource and it does not need to pass filter_fn anymore.
>>> >> By switching to the new API the driver can now support deferred probing
>>> >> against DMA.
>> >
>> > I believe this breaks the OMAP3 ISP driver.
>> > dma_request_slave_channel_compat()
>> > is a superset of dma_request_chan() that will, when called with
>> > omap_dma_filter_fn, return as a fallback any free channel handled by the
>> > OMAP
>> > DMA engine driver. This feature is actively used by this driver and must
>> > be
>> > preserved.
> The fallback to use the filter_fn is used only when booted in legacy
> mode or when requesting a channel for non slave DMA operation.
> Based on the code in the driver it is handling slave transfers, so it
> must have DMA request line coming from somewhere. If that is missing the
> driver should not be able to work as it will not start the transfer.
>
> dma_request_chan() is to be used when you want to have slave channel
> with DMA request.
>
> If legacy mode needs to be supported then adding the hist DMA request
> number to the omap3xxx_sdma_map in arch/arm/mach-omap2/dma.c should be done.
> The reason the omap3isp is not in the table is that I could not find any
> place where the DMA resource was set (nor the DMA is specified in DT).
>
> I'm unsure how this driver could work w/o DMA request line over a random
> (and SW triggered) DMA channel with slave operation. For the slave DMA
> you need to have DMA request line.
I see now.
The omap3isp never supposed to get valid DMA request line via
platform_get_resource_byname(), it should never find the "hist" DMA in
the DT data. If it does, the driver would stop working as there is no
DMA request associated with the histogram data reading.
It is a bit misleading that it used dma_request_slave_channel_compat()
for getting the channel.
I think what would be correct is:
dma_cap_mask_t mask;
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
hist->dma_ch = dma_request_chan_by_mask();
We will get any DMA channel capable of slave configuration, but we will
configure no DMA request number for the channel.
and document this in the driver...
--
Péter
> -- Péter
>>> >> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
>>> >> CC: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
>>> >> CC: Mauro Carvalho Chehab <mche...@osg.samsung.com>
>>> >> ---
>>> >> Hi,
>>> >>
>>> >> the original patch was sent 29.04.2016:
>>> >> https://patchwork.kernel.org/patch/8981811/
>>> >>
>>> >> I have rebased it on top of linux-next.
>>> >>
>>> >> Regards,
>>> >> Peter
>>> >>
>>> >> drivers/media/platform/omap3isp/isphist.c | 27
>>> >> +--
>>> >> 1 file changed, 9 insertions(+), 18 deletions(-)
>>> >>
>>> >> diff --git a/drivers/media/platform/omap3isp/isphist.c
>>> >> b/drivers/media/platform/omap3isp/isphist.c index
>>> >> 7138b043a4aa..e163e3d92517 100644
>>> >> --- a/drivers/media/platform/omap3isp/isphist.c
>>> >> +++ b/drivers/media/platform/omap3isp/isphist.c
>>> >> @@ -18,7 +18,6 @@
>>> >> #include
>>> >> #include
>>> >> #include
>>> >> -#include
>>> >> #include
>>> >> #include
>>> >>
>>> >> @@ -486,27 +485,19 @@ int omap3isp_hist_init(struct isp_device *isp)
>>> >> hist->isp = isp;
>>> >>
>>> >> if (HIST_CONFIG_DMA) {
>>> >> -struct platform_device *pdev =
>>> >> to_platform_device(isp->dev);
>>> >> -struct resource *res;
>>> >> -unsigned int sig = 0;
>>> >> -dma_cap_mask_t mask;
>>> >> -
>>> >> -dma_cap_zero(mask);
>>> >> -dma_cap_set(DMA_SLAVE, mask);
>>> >> -
>>> >> -res = platform_get_resource_b
Re: [PATCH RESEND] media: omap3isp: Use dma_request_chan() to requesting DMA channel
On 11/02/2016 11:19 PM, Laurent Pinchart wrote:
> Hi Peter,
>
> Thank you for the patch.
>
> On Wednesday 02 Nov 2016 14:39:59 Peter Ujfalusi wrote:
>> With the new dma_request_chan() the client driver does not need to look for
>> the DMA resource and it does not need to pass filter_fn anymore.
>> By switching to the new API the driver can now support deferred probing
>> against DMA.
>
> I believe this breaks the OMAP3 ISP driver.
> dma_request_slave_channel_compat()
> is a superset of dma_request_chan() that will, when called with
> omap_dma_filter_fn, return as a fallback any free channel handled by the OMAP
> DMA engine driver. This feature is actively used by this driver and must be
> preserved.
The fallback to use the filter_fn is used only when booted in legacy
mode or when requesting a channel for non slave DMA operation.
Based on the code in the driver it is handling slave transfers, so it
must have DMA request line coming from somewhere. If that is missing the
driver should not be able to work as it will not start the transfer.
dma_request_chan() is to be used when you want to have slave channel
with DMA request.
If legacy mode needs to be supported then adding the hist DMA request
number to the omap3xxx_sdma_map in arch/arm/mach-omap2/dma.c should be done.
The reason the omap3isp is not in the table is that I could not find any
place where the DMA resource was set (nor the DMA is specified in DT).
I'm unsure how this driver could work w/o DMA request line over a random
(and SW triggered) DMA channel with slave operation. For the slave DMA
you need to have DMA request line.
--
Péter
>> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
>> CC: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
>> CC: Mauro Carvalho Chehab <mche...@osg.samsung.com>
>> ---
>> Hi,
>>
>> the original patch was sent 29.04.2016:
>> https://patchwork.kernel.org/patch/8981811/
>>
>> I have rebased it on top of linux-next.
>>
>> Regards,
>> Peter
>>
>> drivers/media/platform/omap3isp/isphist.c | 27 +--
>> 1 file changed, 9 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/media/platform/omap3isp/isphist.c
>> b/drivers/media/platform/omap3isp/isphist.c index
>> 7138b043a4aa..e163e3d92517 100644
>> --- a/drivers/media/platform/omap3isp/isphist.c
>> +++ b/drivers/media/platform/omap3isp/isphist.c
>> @@ -18,7 +18,6 @@
>> #include
>> #include
>> #include
>> -#include
>> #include
>> #include
>>
>> @@ -486,27 +485,19 @@ int omap3isp_hist_init(struct isp_device *isp)
>> hist->isp = isp;
>>
>> if (HIST_CONFIG_DMA) {
>> -struct platform_device *pdev = to_platform_device(isp->dev);
>> -struct resource *res;
>> -unsigned int sig = 0;
>> -dma_cap_mask_t mask;
>> -
>> -dma_cap_zero(mask);
>> -dma_cap_set(DMA_SLAVE, mask);
>> -
>> -res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
>> - "hist");
>> -if (res)
>> -sig = res->start;
>> -
>> -hist->dma_ch = dma_request_slave_channel_compat(mask,
>> -omap_dma_filter_fn, , isp->dev, "hist");
>> -if (!hist->dma_ch)
>> +hist->dma_ch = dma_request_chan(isp->dev, "hist");
>> +if (IS_ERR(hist->dma_ch)) {
>> +ret = PTR_ERR(hist->dma_ch);
>> +if (ret == -EPROBE_DEFER)
>> +return ret;
>> +
>> +hist->dma_ch = NULL;
>> dev_warn(isp->dev,
>> "hist: DMA channel request failed, using
> PIO\n");
>> -else
>> +} else {
>> dev_dbg(isp->dev, "hist: using DMA channel %s\n",
>> dma_chan_name(hist->dma_ch));
>> +}
>> }
>>
>> hist->ops = _ops;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND] media: omap3isp: Use dma_request_chan() to requesting DMA channel
With the new dma_request_chan() the client driver does not need to look for
the DMA resource and it does not need to pass filter_fn anymore.
By switching to the new API the driver can now support deferred probing
against DMA.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
CC: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
CC: Mauro Carvalho Chehab <mche...@osg.samsung.com>
---
Hi,
the original patch was sent 29.04.2016:
https://patchwork.kernel.org/patch/8981811/
I have rebased it on top of linux-next.
Regards,
Peter
drivers/media/platform/omap3isp/isphist.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isphist.c
b/drivers/media/platform/omap3isp/isphist.c
index 7138b043a4aa..e163e3d92517 100644
--- a/drivers/media/platform/omap3isp/isphist.c
+++ b/drivers/media/platform/omap3isp/isphist.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
@@ -486,27 +485,19 @@ int omap3isp_hist_init(struct isp_device *isp)
hist->isp = isp;
if (HIST_CONFIG_DMA) {
- struct platform_device *pdev = to_platform_device(isp->dev);
- struct resource *res;
- unsigned int sig = 0;
- dma_cap_mask_t mask;
-
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
-
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- "hist");
- if (res)
- sig = res->start;
-
- hist->dma_ch = dma_request_slave_channel_compat(mask,
- omap_dma_filter_fn, , isp->dev, "hist");
- if (!hist->dma_ch)
+ hist->dma_ch = dma_request_chan(isp->dev, "hist");
+ if (IS_ERR(hist->dma_ch)) {
+ ret = PTR_ERR(hist->dma_ch);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ hist->dma_ch = NULL;
dev_warn(isp->dev,
"hist: DMA channel request failed, using
PIO\n");
- else
+ } else {
dev_dbg(isp->dev, "hist: using DMA channel %s\n",
dma_chan_name(hist->dma_ch));
+ }
}
hist->ops = _ops;
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] v4l: omap_vout: vrfb: Convert to dmaengine
Hi,
On 08/18/16 13:22, Peter Ujfalusi wrote:
> The dmaengine driver for sDMA now have support for interleaved transfer.
> This trasnfer type was open coded with the legacy omap-dma API, but now
> we can move it to dmaengine.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
> ---
> The dmaengine driver for sDMA now have support for interleaved transfer.
> This trasnfer type was open coded with the legacy omap-dma API, but now
> we can move it to dmaengine.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
> ---
> Hi,
>
> I do not have access to any hardware where I could test if the conversion
> works
> correctly. I think it should. The dmaengine part looks fine to me - not that
> this means too much as I have written it ;)
> Based on debugging the code with starring at it I think the old and the new
> way
> would end up setting up the DMA in a same way. However the dmaengine driver
> will
> set CSDP_DST_PACKED | CSDP_SRC_PACKED.
>
> Laurent: would you be able to test this?
I managed to test the dmaengine interleaved with:
https://github.com/omap-audio/linux-audio/blob/peter/linux-next-wip/drivers/misc/ovv_dmaengine.c
Basically I have ripped the relevant code from omap_vout_vrfb.c, added the
dmaengine implementation. Then:
0. allocate and init the three buffers
1. copy from buffer0 to buffer1 with legacy omap-dma
2. copy from buffer0 to buffer2 with legacy omap-dma
3. compare buffer1 and buffer2
4. reinit buffer2
5. copy from buffer0 to buffer2 with dmaengine
6. compare buffer1 and buffer2
The result is:
[ 100.578943] ovv_init: ENTER
[ 100.626871] ovv_setup_buffers: pattern is good
[ 100.774526] ovv_setup_buffers: pattern is good
[ 100.911386] ovv_setup_buffers: pattern is good
[ 101.136397] ovv_get_legacy_dma: got channel: 6
[ 101.140859] ovv_get_dmaengine_dma: got channel
[ 101.160475] omap_vout_vrfb_dma_tx_callback: ENTER
[ 101.180357] omap_vout_vrfb_dma_tx_callback: ENTER
[ 101.470146] ovv_init: Legacy vs Legacy: they are identical
[ 101.595408] ovv_init: pattern is good
[ 101.599104] dmaengine_callback: ENTER
[ 101.888070] ovv_init: Legacy vs dmaengine: they are identical
--
Péter
>
> Regards,
> Peter
>
> drivers/media/platform/omap/omap_vout_vrfb.c | 133
> ---
> drivers/media/platform/omap/omap_voutdef.h | 6 +-
> 2 files changed, 83 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c
> b/drivers/media/platform/omap/omap_vout_vrfb.c
> index b8638e4e1627..957ff7621652 100644
> --- a/drivers/media/platform/omap/omap_vout_vrfb.c
> +++ b/drivers/media/platform/omap/omap_vout_vrfb.c
> @@ -16,7 +16,6 @@
> #include
> #include
>
> -#include
> #include
>
> #include "omap_voutdef.h"
> @@ -63,7 +62,7 @@ static int omap_vout_allocate_vrfb_buffers(struct
> omap_vout_device *vout,
> /*
> * Wakes up the application once the DMA transfer to VRFB space is completed.
> */
> -static void omap_vout_vrfb_dma_tx_callback(int lch, u16 ch_status, void
> *data)
> +static void omap_vout_vrfb_dma_tx_callback(void *data)
> {
> struct vid_vrfb_dma *t = (struct vid_vrfb_dma *) data;
>
> @@ -94,6 +93,7 @@ int omap_vout_setup_vrfb_bufs(struct platform_device *pdev,
> int vid_num,
> int ret = 0, i, j;
> struct omap_vout_device *vout;
> struct video_device *vfd;
> + dma_cap_mask_t mask;
> int image_width, image_height;
> int vrfb_num_bufs = VRFB_NUM_BUFS;
> struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
> @@ -131,17 +131,26 @@ int omap_vout_setup_vrfb_bufs(struct platform_device
> *pdev, int vid_num,
> /*
>* Request and Initialize DMA, for DMA based VRFB transfer
>*/
> - vout->vrfb_dma_tx.dev_id = OMAP_DMA_NO_DEVICE;
> - vout->vrfb_dma_tx.dma_ch = -1;
> - vout->vrfb_dma_tx.req_status = DMA_CHAN_ALLOTED;
> - ret = omap_request_dma(vout->vrfb_dma_tx.dev_id, "VRFB DMA TX",
> - omap_vout_vrfb_dma_tx_callback,
> - (void *) >vrfb_dma_tx, >vrfb_dma_tx.dma_ch);
> - if (ret < 0) {
> + dma_cap_zero(mask);
> + dma_cap_set(DMA_INTERLEAVE, mask);
> + vout->vrfb_dma_tx.chan = dma_request_chan_by_mask();
> + if (IS_ERR(vout->vrfb_dma_tx.chan)) {
> vout->vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
> + } else {
> + size_t xt_size = sizeof(struct dma_interleaved_template) +
> + sizeof(struct data_chunk);
> +
> + vout->vrfb_dma_tx.xt = kzalloc(xt_size, GFP_KERNEL);
> + if (!vout->vrfb_dma_tx.xt) {
> + dma_r
[PATCH] [media] m2m-deinterlace: Fix error print during probe
v4l2_err() can not be used for printing error for missing interleaved
support in DMA as this point the pcdev->v4l2_dev is not valid.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
drivers/media/platform/m2m-deinterlace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/m2m-deinterlace.c
b/drivers/media/platform/m2m-deinterlace.c
index 0fcb5c78031d..5a5dec348f4d 100644
--- a/drivers/media/platform/m2m-deinterlace.c
+++ b/drivers/media/platform/m2m-deinterlace.c
@@ -1016,7 +1016,7 @@ static int deinterlace_probe(struct platform_device *pdev)
return -ENODEV;
if (!dma_has_cap(DMA_INTERLEAVE, pcdev->dma_chan->device->cap_mask)) {
- v4l2_err(>v4l2_dev, "DMA does not support INTERLEAVE\n");
+ dev_err(>dev, "DMA does not support INTERLEAVE\n");
goto rel_dma;
}
--
2.9.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] v4l: omap_vout: vrfb: Convert to dmaengine
The dmaengine driver for sDMA now have support for interleaved transfer.
This trasnfer type was open coded with the legacy omap-dma API, but now
we can move it to dmaengine.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
The dmaengine driver for sDMA now have support for interleaved transfer.
This trasnfer type was open coded with the legacy omap-dma API, but now
we can move it to dmaengine.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
---
Hi,
I do not have access to any hardware where I could test if the conversion works
correctly. I think it should. The dmaengine part looks fine to me - not that
this means too much as I have written it ;)
Based on debugging the code with starring at it I think the old and the new way
would end up setting up the DMA in a same way. However the dmaengine driver will
set CSDP_DST_PACKED | CSDP_SRC_PACKED.
Laurent: would you be able to test this?
Regards,
Peter
drivers/media/platform/omap/omap_vout_vrfb.c | 133 ---
drivers/media/platform/omap/omap_voutdef.h | 6 +-
2 files changed, 83 insertions(+), 56 deletions(-)
diff --git a/drivers/media/platform/omap/omap_vout_vrfb.c
b/drivers/media/platform/omap/omap_vout_vrfb.c
index b8638e4e1627..957ff7621652 100644
--- a/drivers/media/platform/omap/omap_vout_vrfb.c
+++ b/drivers/media/platform/omap/omap_vout_vrfb.c
@@ -16,7 +16,6 @@
#include
#include
-#include
#include
#include "omap_voutdef.h"
@@ -63,7 +62,7 @@ static int omap_vout_allocate_vrfb_buffers(struct
omap_vout_device *vout,
/*
* Wakes up the application once the DMA transfer to VRFB space is completed.
*/
-static void omap_vout_vrfb_dma_tx_callback(int lch, u16 ch_status, void *data)
+static void omap_vout_vrfb_dma_tx_callback(void *data)
{
struct vid_vrfb_dma *t = (struct vid_vrfb_dma *) data;
@@ -94,6 +93,7 @@ int omap_vout_setup_vrfb_bufs(struct platform_device *pdev,
int vid_num,
int ret = 0, i, j;
struct omap_vout_device *vout;
struct video_device *vfd;
+ dma_cap_mask_t mask;
int image_width, image_height;
int vrfb_num_bufs = VRFB_NUM_BUFS;
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
@@ -131,17 +131,26 @@ int omap_vout_setup_vrfb_bufs(struct platform_device
*pdev, int vid_num,
/*
* Request and Initialize DMA, for DMA based VRFB transfer
*/
- vout->vrfb_dma_tx.dev_id = OMAP_DMA_NO_DEVICE;
- vout->vrfb_dma_tx.dma_ch = -1;
- vout->vrfb_dma_tx.req_status = DMA_CHAN_ALLOTED;
- ret = omap_request_dma(vout->vrfb_dma_tx.dev_id, "VRFB DMA TX",
- omap_vout_vrfb_dma_tx_callback,
- (void *) >vrfb_dma_tx, >vrfb_dma_tx.dma_ch);
- if (ret < 0) {
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_INTERLEAVE, mask);
+ vout->vrfb_dma_tx.chan = dma_request_chan_by_mask();
+ if (IS_ERR(vout->vrfb_dma_tx.chan)) {
vout->vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
+ } else {
+ size_t xt_size = sizeof(struct dma_interleaved_template) +
+sizeof(struct data_chunk);
+
+ vout->vrfb_dma_tx.xt = kzalloc(xt_size, GFP_KERNEL);
+ if (!vout->vrfb_dma_tx.xt) {
+ dma_release_channel(vout->vrfb_dma_tx.chan);
+ vout->vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
+ }
+ }
+
+ if (vout->vrfb_dma_tx.req_status == DMA_CHAN_NOT_ALLOTED)
dev_info(>dev, ": failed to allocate DMA Channel for"
" video%d\n", vfd->minor);
- }
+
init_waitqueue_head(>vrfb_dma_tx.wait);
/* statically allocated the VRFB buffer is done through
@@ -176,7 +185,9 @@ void omap_vout_release_vrfb(struct omap_vout_device *vout)
if (vout->vrfb_dma_tx.req_status == DMA_CHAN_ALLOTED) {
vout->vrfb_dma_tx.req_status = DMA_CHAN_NOT_ALLOTED;
- omap_free_dma(vout->vrfb_dma_tx.dma_ch);
+ kfree(vout->vrfb_dma_tx.xt);
+ dmaengine_terminate_sync(vout->vrfb_dma_tx.chan);
+ dma_release_channel(vout->vrfb_dma_tx.chan);
}
}
@@ -218,70 +229,84 @@ int omap_vout_vrfb_buffer_setup(struct omap_vout_device
*vout,
}
int omap_vout_prepare_vrfb(struct omap_vout_device *vout,
- struct videobuf_buffer *vb)
+ struct videobuf_buffer *vb)
{
- dma_addr_t dmabuf;
- struct vid_vrfb_dma *tx;
+ struct dma_async_tx_descriptor *tx;
+ enum dma_ctrl_flags flags;
+ struct dma_chan *chan = vout->vrfb_dma_tx.chan;
+ struct dma_device *dmadev = chan->device;
+ struct dma_interleaved_template *xt = vout->vrfb_dma_tx.xt;
+ dma_cookie_t cookie;
+
[PATCH] media: omap3isp: Use dma_request_chan() to requesting DMA channel
With the new dma_request_chan() the client driver does not need to look for
the DMA resource and it does not need to pass filter_fn anymore.
By switching to the new API the driver can now support deferred probing
against DMA.
Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
CC: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
CC: Mauro Carvalho Chehab <mche...@osg.samsung.com>
---
drivers/media/platform/omap3isp/isphist.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isphist.c
b/drivers/media/platform/omap3isp/isphist.c
index 7138b043a4aa..e163e3d92517 100644
--- a/drivers/media/platform/omap3isp/isphist.c
+++ b/drivers/media/platform/omap3isp/isphist.c
@@ -18,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
@@ -486,27 +485,19 @@ int omap3isp_hist_init(struct isp_device *isp)
hist->isp = isp;
if (HIST_CONFIG_DMA) {
- struct platform_device *pdev = to_platform_device(isp->dev);
- struct resource *res;
- unsigned int sig = 0;
- dma_cap_mask_t mask;
-
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
-
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- "hist");
- if (res)
- sig = res->start;
-
- hist->dma_ch = dma_request_slave_channel_compat(mask,
- omap_dma_filter_fn, , isp->dev, "hist");
- if (!hist->dma_ch)
+ hist->dma_ch = dma_request_chan(isp->dev, "hist");
+ if (IS_ERR(hist->dma_ch)) {
+ ret = PTR_ERR(hist->dma_ch);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ hist->dma_ch = NULL;
dev_warn(isp->dev,
"hist: DMA channel request failed, using
PIO\n");
- else
+ } else {
dev_dbg(isp->dev, "hist: using DMA channel %s\n",
dma_chan_name(hist->dma_ch));
+ }
}
hist->ops = _ops;
--
2.8.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 11/20/2015 02:24 PM, Andy Shevchenko wrote: > On Fri, Nov 20, 2015 at 12:58 PM, Arnd Bergmann <a...@arndb.de> wrote: >> On Friday 20 November 2015 12:25:06 Peter Ujfalusi wrote: >>> On 11/19/2015 01:25 PM, Arnd Bergmann wrote: > >> Another idea would be to remove the filter function from struct dma_chan_map >> and pass the map through platform data > > Why not unified device properties? Is this some Windows/ACPI feature? Quick search gives mostly MSDN and Windows10 related links. We only need dma_chan_map for platforms which has not been converted to DT and still using legacy boot. Or platforms which can still boot in legacy mode. In DT/ACPI mode we do not need this map at all. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 11/20/2015 12:58 PM, Arnd Bergmann wrote:
>>> That way the vast majority of drivers can use one of the two nice interfaces
>>> and the rest can be converted to use __dma_request_chan().
>>>
>>> On a related topic, we had in the past considered providing a way for
>>> platform code to register a lookup table of some sort, to associate
>>> a device/name pair with a configuration. That would let us use the
>>> simplified dma_request_slavechan(dev, name) pair everywhere. We could
>>> use the same method that we have for clk_register_clkdevs() or
>>> pinctrl_register_map().
>>>
>>> Something like either
>>>
>>> static struct dma_chan_map myplatform_dma_map[] = {
>>> { .devname = "omap-aes0", .slave = "tx", .filter = omap_dma_filter_fn,
>>> .arg = (void *)65, },
>>> { .devname = "omap-aes0", .slave = "rx", .filter = omap_dma_filter_fn,
>>> .arg = (void *)66, },
>>> };
>>>
>>> or
>>>
>>> static struct dma_chan_map myplatform_dma_map[] = {
>>> { .devname = "omap-aes0", .slave = "tx", .master = "omap-dma-engine0",
>>> .req = 65, },
>>> { .devname = "omap-aes0", .slave = "rx", .master = "omap-dma-engine0",
>>> .req = 66, },
>>
>> sa11x0-dma expects the fn_param as string :o
>
> Some of them do, but the new API requires changes in both the DMA master and
> slave drivers, so that could be changed if we wanted to, or we just allow
> both methods indefinitely and let sa11x0-dma pass the filterfn+data rather
> than
> a number.
Hrm, I would say that we need to push everyone to use the new API. sa11x0
should not be a big deal to fix IMHO and other users should be reasonably
simple to convert.
>>> };
>>
>> Basically we are deprecating the use of IORESOURCE_DMA?
>
> I thought we already had ;-)
For DT boot, yes. Not for the legacy boot.
>> For legacy the filter function is pretty much needed to handle the
>> differences
>> between the platforms as not all of them does the filtering in a same way. So
>> the first type of map would be feasible IMHO.
>
> It certainly makes the transition to a map table much easier.
And the aim anyway is to convert everything to DT, right?
>>> we could even allow a combination of the two, so the simple case just
>>> specifies
>>> master and req number, which requires changes to the dmaengine driver, but
>>> we could
>>> also do a mass-conversion to the .filter/.arg variant.
>>
>> This will get rid of the need for the fn and fn_param parameters when
>> requesting dma channel, but it will not get rid of the exported function from
>> the dma engine drivers since in arch code we need to have visibility to the
>> filter_fn.
>
> Correct. A lot of dmaengine drivers already need to be built-in so the
> platform
> code can put a pointer to the filter function, so it would not be worse for
> them.
>
> Another idea would be to remove the filter function from struct dma_chan_map
> and pass the map through platform data to the dmaengine driver, which then
> registers it to the core along with the mask. Something like:
>
> /* platform code */
> static struct dma_chan_map oma_dma_map[] = {
> { .devname = "omap-aes0", .slave = "tx", .arg = (void *)65, },
> { .devname = "omap-aes0", .slave = "rx", .arg = (void *)66, },
> ...
> {},
> };
>
> static struct omap_system_dma_plat_info dma_plat_info __initdata = {
> .dma_map = _dma_map,
> ...
> };
>
> machine_init(void)
> {
> ...
> platform_device_register_data(NULL, "omap-dma-engine", 0,
> _plat_info, sizeof(dma_plat_info);
> ...
> }
>
> /* dmaengine driver */
>
> static int omap_dma_probe(struct platform_device *pdev)
> {
> struct omap_system_dma_plat_info *pdata = dev_get_platdata(>dev);
> ...
>
> dmam_register_platform_map(>dev, omap_dma_filter_fn,
> pdata->dma_map);
> }
>
> /* dmaengine core */
>
> struct dma_map_list {
> struct list_head node;
> struct device *master;
> dma_filter_fn filter;
> struct dma_chan_map *map;
> };
>
> static LIST_HEAD(dma_map_list);
> static DEFINE_MUTEX(dma_map_mutex);
>
> int dmam_register_platform_map(struct device *dev, dma_filter_fn filter,
> struct dma_chan_map *map)
> {
> struct dma_map_list *list = kmalloc(sizeof(*list), GFP_KERNEL);
>
> if (!list)
> return -ENOMEM;
>
> list->dev = dev;
> list->filter = filter;
> list->map = map;
>
> mutex_lock(_map_mutex);
> list_add(_map_list, >node);
> mutex_unlock(_map_mutex);
> }
>
> Now we can completely remove the dependency on the filter function definition
> from platform code and slave drivers.
Sounds feasible for OMAP and daVinci and for others as well. I think ;)
I would go with this if someone asks my opinion :D
The core change to add the new API + the dma_map support should be pretty
straight forward. It can live alongside with the old API and we can phase out
the users of the old one.
The legacy support would need more time since we need to modify the arch
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 11/19/2015 01:25 PM, Arnd Bergmann wrote:
>> If we have two main APIs, one to request slave channels and one to get any
>> channel with given capability
>> dma_request_slave_channel(NULL, NULL, , fn, fn_param); /* Legacy slave
>> */
>> dma_request_slave_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current
>>slave */
>> dma_request_slave_channel(dev, name, , fn, fn_param); /* current
>> compat*/
>>
>> This way we can omit the mask also in cases when the client only want to get
>> DMA_SLAVE, we can just build up the mask within the function. If the mask is
>> provided we would copy the bits from the provided mask, so for example if you
>> want to have DMA_SLAVE+DMA_CYCLIC, the driver only needs to pass DMA_CYCLIC,
>> the DMA_SLAVE is going to be set anyways.
>
> I think it's more logical here to have mask=NULL mean that we want DMA_SLAVE,
> but otherwise pass the full mask as DMA_SLAVE|DMA_CYCLIC etc.
Yep, could be, while I would write the core part to set the DMA_SLAVE
unconditionally anyways. If the API say it is dma_request_slavechan() it is
expected to get channel which is capable of DMA_SLAVE.
>> dma_request_channel(mask); /* memcpy. etc, non slave mostly */
>>
>> Not sure how to name this as reusing existing (good, descriptive) function
>> names would mean changes all over the kernel to start off this.
>>
>> Not used and
>> request_dma_channel(); /* as _irq/_mem_region/_resource, etc */
>> request_dma();
>> dma_channel_request();
>
> dma_request_slavechan();
> dma_request_slave();
> dma_request_mask();
Let me think aloud here a bit...
1. To request slave channel which will return you the channel your device is
bind via DT/ACPI or the platform map table you propose later:
dma_request_chan(struct device *dev, const char *name);
2. To request a channel (any channel) matching with the capabilities the
driver needs, like memcpy, memset, etc:
#define dma_request_chan_by_mask(mask) __dma_request_chan_by_mask(&(mask))
__dma_request_chan_by_mask(const dma_cap_mask_t *mask);
I think the dma_request_chan() does not need mask to be passed, since via this
we request a specific channel which has been defined/set by DT/ACPI or the
lookup map. We could add a mask parameter which could be used to sanity check
the channel we got against the capabilities the driver needs from the channel.
We currently do this in the drivers where the author wanted to make sure that
the channel is capable of what it should be capable.
So two API to request channel:
struct dma_chan *dma_request_chan(struct device *dev, const char *name);
struct dma_chan *dma_request_chan_by_mask(const dma_cap_mask_t *mask);
Both will return with the valid channel pointer or in case of failure with
ERR_PTR().
We need to go through the code in regards to return codes also to have sane
mapping.
>
>> All in all, not sure which way would be better...
>
> I think I would prefer the simplest API to have only the dev+name
> arguments, as we tend to move that way for all platforms anyway, and it
> seems silly to have all drivers pass three NULL arguments all the time.
> At the moment, there are 139 references to dma_request_slave_channel_*
> in the kernel, and only 46 of them are dma_request_slave_channel_compat.
> Out of those 46, a couple can already be converted back to use
> dma_request_slave_channel() because the platform now only supports
> devicetree based boots and will not go back to platform data.
>
> How about something like
>
> extern struct dma_chan *
> __dma_request_chan(struct device *dev, const char *name,
> const dma_cap_mask_t *mask, dma_filter_fn fn, void
> *fn_param);
>
> static inline struct dma_chan *
> dma_request_slavechan(struct device *dev, const char *name)
> {
> return __dma_request_chan(dev, name, NULL, NULL, NULL);
> }
>
> static inline struct dma_chan *
> dma_request_chan(const dma_cap_mask_t *mask)
> {
> return __dma_request_chan(NULL, NULL, mask, NULL, NULL);
> }
>
> That way the vast majority of drivers can use one of the two nice interfaces
> and the rest can be converted to use __dma_request_chan().
>
> On a related topic, we had in the past considered providing a way for
> platform code to register a lookup table of some sort, to associate
> a device/name pair with a configuration. That would let us use the
> simplified dma_request_slavechan(dev, name) pair everywhere. We could
> use the same method that we have for clk_register_clkdevs() or
> pinctrl_register_map().
>
> Something like either
>
> static struct dma_chan_map myplatform_dma_map[] = {
> { .devname = "omap-aes0", .slave = "tx", .filter = omap_dma_filter_fn,
> .arg = (void *)65, },
> { .devname = "omap-aes0", .slave = "rx", .filter = omap_dma_filter_fn,
> .arg = (void *)66, },
> };
>
> or
>
> static struct dma_chan_map myplatform_dma_map[] = {
> { .devname = "omap-aes0", .slave = "tx", .master = "omap-dma-engine0",
> .req
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 11/18/2015 05:46 PM, Andy Shevchenko wrote: > On Wed, Nov 18, 2015 at 4:21 PM, Peter Ujfalusi <peter.ujfal...@ti.com> wrote: >> Hi Vinod, >> >> bringing this old thread back to life as I just started to work on this. > > What I remember we need to convert drivers to use new API meanwhile it > is good to keep old one to avoid patch storm which does nothing useful > (IIRC Russel's opinion). I tend to agree. But we need to start converting the users at some point either way. Another issue is the fact that the current dmaengine API is using all the good names I can think of ;) > On the other hand there are a lot of drivers that are used on the set > of platforms starting from legacy and abandoned ones (like AVR32) to > relatively new and newest. > > And I'm not a fan of those thousands of API calls either. > -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 11/18/2015 05:07 PM, Arnd Bergmann wrote:
> On Wednesday 18 November 2015 16:41:35 Peter Ujfalusi wrote:
>> On 11/18/2015 04:29 PM, Arnd Bergmann wrote:
>>> On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
>>>> 2. non slave channel requests, where only the functionality matters, like
>>>> memcpy, interleaved, memset, etc.
>>>> We could have a simple:
>>>> dma_request_channel(mask);
>>>>
>>>> But looking at the drivers using dmaengine legacy dma_request_channel()
>>>> API:
>>>> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
>>>> drivers/misc/carma/carma-fpga.c
>>>> DMA_INTERRUPT|DMA_SLAVE|DMA_SG
>>>> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
>>>> drivers/media/platform/soc_camera/mx3_camera.c DMA_SLAVE|DMA_PRIVATE
>>>> sound/soc/intel/common/sst-firmware.c DMA_SLAVE|DMA_MEMCPY
>>>>
>>>> as examples.
>>>> Not sure how valid are these...
>
> I just had a look myself. carma has been removed fortunately in linux-next,
> so we don't have to worry about that any more.
>
> I assume that the sst-firmware.c case is a mistake, it should just use a
> plain DMA_SLAVE and not DMA_MEMCPY.
>
> Aside from these, everyone else uses either DMA_CYCLIC in addition to
> DMA_SLAVE, which seems valid, or they use DMA_PRIVATE, which I think is
> redundant in slave drivers and can be removed.
Yep, CYCLIC. How could I forgot that ;)
>>> It's usually not much harder to separate out the legacy case from
>>> the normal dma_request_slave_channel_reason(), so those drivers don't
>>> really need to use the unified compat API.
>>
>> The current dma_request_slave_channel()/_reason() is not the 'legacy' API.
>> Currently there is no way to get the reason why the dma channel request fails
>> when using the _compat() version of the API, which is used by drivers which
>> can be used in DT or in legacy mode as well. Sure, they all could have local
>> if(){}else{} for handling this, but it is not a nice thing.
>>
>> As it was discussed instead of adding the _reason() version for the _compat
>> call, we should simplify the dmaengine API for getting the channel and at the
>> same time we will have ERR_PTR returned instead of NULL.
>
> What I meant was that we don't need to handle them with the unified
> simple interface. The users of DMA_CYCLIC can just keep using
> an internal helper that only deals with the legacy case, or use
> dma_request_slave() or whatever is the new API for the DT case.
I think we can go with a single API, but I don't really like that:
dma_request_channel(dev, name, *mask, fn, fn_param);
This would cover all current uses being legacy, DT/ACPI, compat, etc:
dma_request_channel(NULL, NULL, , fn, fn_param); /* Legacy slave */
dma_request_channel(NULL, NULL, , NULL, NULL); /* memcpy. etc */
dma_request_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current slave */
dma_request_channel(dev, name, , fn, fn_param); /* current compat */
Note, that we need "const dma_cap_mask_t *mask" to be able to make the mask
optional.
If we have two main APIs, one to request slave channels and one to get any
channel with given capability
dma_request_slave_channel(NULL, NULL, , fn, fn_param); /* Legacy slave */
dma_request_slave_channel(dev, name, NULL, NULL, NULL); /* DT/ACPI, current
slave */
dma_request_slave_channel(dev, name, , fn, fn_param); /* current compat*/
This way we can omit the mask also in cases when the client only want to get
DMA_SLAVE, we can just build up the mask within the function. If the mask is
provided we would copy the bits from the provided mask, so for example if you
want to have DMA_SLAVE+DMA_CYCLIC, the driver only needs to pass DMA_CYCLIC,
the DMA_SLAVE is going to be set anyways.
dma_request_channel(mask); /* memcpy. etc, non slave mostly */
Not sure how to name this as reusing existing (good, descriptive) function
names would mean changes all over the kernel to start off this.
Not used and
request_dma_channel(); /* as _irq/_mem_region/_resource, etc */
request_dma();
dma_channel_request();
All in all, not sure which way would be better...
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 11/18/2015 04:29 PM, Arnd Bergmann wrote:
> On Wednesday 18 November 2015 16:21:26 Peter Ujfalusi wrote:
>> 2. non slave channel requests, where only the functionality matters, like
>> memcpy, interleaved, memset, etc.
>> We could have a simple:
>> dma_request_channel(mask);
>>
>> But looking at the drivers using dmaengine legacy dma_request_channel() API:
>> Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE:
>> drivers/misc/carma/carma-fpga.c
>> DMA_INTERRUPT|DMA_SLAVE|DMA_SG
>> drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG
>> drivers/media/platform/soc_camera/mx3_camera.c DMA_SLAVE|DMA_PRIVATE
>> sound/soc/intel/common/sst-firmware.c DMA_SLAVE|DMA_MEMCPY
>>
>> as examples.
>> Not sure how valid are these...
>
> It's usually not much harder to separate out the legacy case from
> the normal dma_request_slave_channel_reason(), so those drivers don't
> really need to use the unified compat API.
The current dma_request_slave_channel()/_reason() is not the 'legacy' API.
Currently there is no way to get the reason why the dma channel request fails
when using the _compat() version of the API, which is used by drivers which
can be used in DT or in legacy mode as well. Sure, they all could have local
if(){}else{} for handling this, but it is not a nice thing.
As it was discussed instead of adding the _reason() version for the _compat
call, we should simplify the dmaengine API for getting the channel and at the
same time we will have ERR_PTR returned instead of NULL.
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
Hi Vinod, bringing this old thread back to life as I just started to work on this. On 06/24/2015 07:24 PM, Vinod Koul wrote: >> We would end up with the following APIs, all returning with error code on >> failure: >> dma_request_slave_channel(dev, name); >> dma_request_channel_legacy(mask, fn, fn_param); >> dma_request_slave_channel_compat(mask, fn, fn_param, dev, name); >> dma_request_any_channel(mask); > This is good idea but still we end up with 4 APIs. Why not just converge to > two API, one legacy + memcpy + filer fn and one untimate API for slave? Looked at the current API and it's use and, well, it is a bit confusing. What I hoped that we can separate users to two category: 1. Slave channel requests, where we request a specific channel to handle HW requests/triggers. For this we could have: dma_request_slave_channel(dev, name, fn, fn_param); In DT/ACPI only drivers we can NULL out the fn and fn_param, in pure legacy mode we null out the name, I would keep the dev so we could print dev specific error in dmaengine core, but it could be optional, IN case of drivers used both DT/ACPI and legacy mode all parameter can be filled and the core will decide what to do. For the legacy needs the dmaengine code would provide the mask dows with DMA_SLAVE flag set. 2. non slave channel requests, where only the functionality matters, like memcpy, interleaved, memset, etc. We could have a simple: dma_request_channel(mask); But looking at the drivers using dmaengine legacy dma_request_channel() API: Some sets DMA_INTERRUPT or DMA_PRIVATE or DMA_SG along with DMA_SLAVE: drivers/misc/carma/carma-fpga.c DMA_INTERRUPT|DMA_SLAVE|DMA_SG drivers/misc/carma/carma-fpga-program.c DMA_MEMCPY|DMA_SLAVE|DMA_SG drivers/media/platform/soc_camera/mx3_camera.c DMA_SLAVE|DMA_PRIVATE sound/soc/intel/common/sst-firmware.c DMA_SLAVE|DMA_MEMCPY as examples. Not sure how valid are these... Some drivers do pass fn and fn_param when requesting channel for DMA_MEMCPY drivers/misc/mic/host/mic_device.h drivers/mtd/nand/fsmc_nand.c sound/soc/intel/common/sst-firmware.c (well, this request DMA_SLAVE capability at the same time). Some driver sets the fn_param w/o fn, which means fn_param is ignored. So the dma_request_slave_channel(dev, name, fn, fn_param); dma_request_channel(mask); almost covers the current users and would be pretty clean ;) If we add the mask to the slave channel API - which will become universal, drop in replacement for dma_request_channel, and we might have only one API: dma_request_channel(dev, name, mask, fn, fn_param); > > Internally we may have 4 APIs for cleaner handling... > > Thoughts... ?? Yes, as we need to arrange the code internally to keep things neat. -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/13] [media] omap3isp: Support for deferred probing when requesting DMA channel
Hi Laurent,
On 11/09/2015 09:50 PM, Laurent Pinchart wrote:
> Hi Peter,
>
> Thank you for the patch.
>
> What happened to this patch series ? It looks like
> dma_request_slave_channel_compat_reason() isn't in mainline, so I can't apply
> this patch.
>
> I'll mark this patch as deferred in patchwork, please resubmit it if you
> resubmit the series
The original series - containing this patch - generated a bit of discussion
and it seams that I will need to do bigger change in the dmaengine API
compared to this.
I think this patch can be dropped as the dmaengine changes will not go in as
they were.
(and by the look of it the issue you're trying to fix
> still exists, so it would be nice if you could get it eventually fixed).
Yes, the issue still valid for the OMAP/DaVinci driver the series was touching.
I will try to send a new series in the coming weeks.
Thanks,
Péter
>
> On Tuesday 26 May 2015 16:26:07 Peter Ujfalusi wrote:
>> Switch to use ma_request_slave_channel_compat_reason() to request the DMA
>> channel. Only fall back to pio mode if the error code returned is not
>> -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
>>
>> Signed-off-by: Peter Ujfalusi <peter.ujfal...@ti.com>
>> CC: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
>> CC: Mauro Carvalho Chehab <mche...@osg.samsung.com>
>> ---
>> drivers/media/platform/omap3isp/isphist.c | 12 +---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/platform/omap3isp/isphist.c
>> b/drivers/media/platform/omap3isp/isphist.c index
>> 7138b043a4aa..e690ca13af0e 100644
>> --- a/drivers/media/platform/omap3isp/isphist.c
>> +++ b/drivers/media/platform/omap3isp/isphist.c
>> @@ -499,14 +499,20 @@ int omap3isp_hist_init(struct isp_device *isp)
>> if (res)
>> sig = res->start;
>>
>> -hist->dma_ch = dma_request_slave_channel_compat(mask,
>> +hist->dma_ch = dma_request_slave_channel_compat_reason(mask,
>> omap_dma_filter_fn, , isp->dev, "hist");
>> -if (!hist->dma_ch)
>> +if (IS_ERR(hist->dma_ch)) {
>> +ret = PTR_ERR(hist->dma_ch);
>> +if (ret == -EPROBE_DEFER)
>> +return ret;
>> +
>> +hist->dma_ch = NULL;
>> dev_warn(isp->dev,
>> "hist: DMA channel request failed, using
>> PIO\n");
>> -else
>> +} else {
>> dev_dbg(isp->dev, "hist: using DMA channel %s\n",
>> dma_chan_name(hist->dma_ch));
>> +}
>> }
>>
>> hist->ops = _ops;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 06/12/2015 03:58 PM, Vinod Koul wrote: Sorry this slipped thru I was away for a week anyways ;) Thinking about it again, I think we should coverge to two APIs and mark the legacy depracuated and look to convert folks and phase that out Currently, w/o this series we have these APIs: /* to be used with DT/ACPI */ dma_request_slave_channel(dev, name)/* NULL on failure */ dma_request_slave_channel_reason(dev, name) /* error code on failure */ /* Legacy mode only - no DT/ACPI lookup */ dma_request_channel(mask, fn, fn_param) /* NULL on failure */ /* to be used with DT/ACPI or legacy boot */ dma_request_slave_channel_compat(mask, fn, fn_param, dev, name) /* NULL on failure */ To request _any_ channel to be used for memcpy one has to use dma_request_channel(mask, NULL, NULL); If I did not missed something. As we need different types of parameters for DT/ACPI and legacy (non DT/ACPI lookup) and the good API names are already taken, we might need to settle: /* to be used with DT/ACPI */ dma_request_slave_channel(dev, name) /* error code on failure */ - Convert users to check IS_ERR_OR_NULL() instead against NULL - Mark dma_request_slave_channel_reason() deprecated and convert the current users /* to be used with DT/ACPI or legacy boot */ dma_request_slave_channel_compat(mask, fn, fn_param, dev, name) /* error code on failure */ - Convert users to check IS_ERR_OR_NULL() instead against NULL - Do not try legacy mode if either OF or ACPI failed because of real error /* Legacy mode only - no DT/ACPI lookup */ dma_request_channel_legacy(mask, fn, fn_param) /* error code on failure */ - convert users of dma_request_channel() - mark dma_request_channel() deprecated /* to be used to get a channel for memcpy for example */ dma_request_any_channel(mask) /* error code on failure */ - Convert current dma_request_channel(mask, NULL, NULL) users I know, any of the other function could be prepared to handle this when parameters are missing, but it is a bit cleaner to have separate API for this. It would be nice to find another name for the dma_request_slave_channel_compat() so with the new name we could have chance to rearrange the parameters: (dev, name, mask, fn, fn_param) We would end up with the following APIs, all returning with error code on failure: dma_request_slave_channel(dev, name); dma_request_channel_legacy(mask, fn, fn_param); dma_request_slave_channel_compat(mask, fn, fn_param, dev, name); dma_request_any_channel(mask); What do you think? -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-media in
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
Vinod, On 06/02/2015 03:55 PM, Vinod Koul wrote: On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote: On 05/29/2015 01:18 PM, Vinod Koul wrote: On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote: On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com wrote: On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote: dma_request_slave_channel_compat() 'eats' up the returned error codes which prevents drivers using the compat call to be able to do deferred probing. The new wrapper is identical in functionality but it will return with error code in case of failure and will pass the -EPROBE_DEFER to the caller in case dma_request_slave_channel_reason() returned with it. This is okay but am worried about one more warpper, how about fixing dma_request_slave_channel_compat() Then all callers of dma_request_slave_channel_compat() have to be modified to handle ERR_PTR first. The same is true for (the existing) dma_request_slave_channel_reason() vs. dma_request_slave_channel(). Good point, looking again, I think we should rather fix dma_request_slave_channel_reason() as it was expected to return err code and add new users. Anyway users of this API do expect the reason... Hrm, they are for different use.dma_request_slave_channel()/_reason() is for drivers only working via DT or ACPI while dma_request_slave_channel_compat()/_reason() is for drivers expected to run in DT/ACPI or legacy mode as well. I added the dma_request_slave_channel_compat_reason() because OMAP/daVinci drivers are using this to request channels - they need to support DT and legacy mode. I think we should hide these things behind the API and do this behind the hood for ACPI/DT systems. Also it makes sense to use right API and mark rest as depricated So to convert the dma_request_slave_channel_compat() and not to create _reason variant? Or to have single API to request channel? The problem with that is that we need different parameters for legacy and DT for example. But it is doable to do this for both the non _compat and _compat version: 1. change all users to check IS_ERR_OR_NULL(chan) return the PTR_ERR if not NULL, or do whatever the driver was doing in case of chan == NULL. 2. change the non _compat and _compat versions to do the same as the _reason variants, #define the _reason ones to the non _reason names 3. Rename the _reason use to non _reason function in drivers 4. Remove the #defines for the _reason functions 5. Change the IS_ERR_OR_NULL(chan) to IS_ERR(chan) in all drivers The result: Both dma_request_slave_channel() and dma_request_slave_channel_compat() will return ERR_PTR in case of failure or in success they will return the pinter to chan. Is this what you were asking? It is a bit broader than what this series was doing: taking care of OMAP/daVinci drivers for deferred probing regarding to dmaengine ;) Yes but it would make sense right? I know it is a larger work but then we wouldn't want another dma_request_slave_xxx API, at some point we have stop it exapnding, perhpas now :) Yes, it make sense to get rid if the _reason() things and have the dma_request_slave_channel() and dma_request_slave_channel_compat() return with error code One thing we need to do for this is to change the error codes coming back from the _dt() and _acpi() calls when we boot in legacy mode. Right now the only error code which comes back is -ENODEV and -EPROBE_DEFER. We need to differentiate between 'real' errors and from the fact that we did not booted with DT or the ACPI is not available. IMHO if we boot with DT and the channel request fails with other than -EPROBE_DEFER we should not go and try to get the channel via legacy API. Yes I am all ears to stage this work and not do transition gardually.. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On 05/29/2015 01:18 PM, Vinod Koul wrote: On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote: On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com wrote: On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote: dma_request_slave_channel_compat() 'eats' up the returned error codes which prevents drivers using the compat call to be able to do deferred probing. The new wrapper is identical in functionality but it will return with error code in case of failure and will pass the -EPROBE_DEFER to the caller in case dma_request_slave_channel_reason() returned with it. This is okay but am worried about one more warpper, how about fixing dma_request_slave_channel_compat() Then all callers of dma_request_slave_channel_compat() have to be modified to handle ERR_PTR first. The same is true for (the existing) dma_request_slave_channel_reason() vs. dma_request_slave_channel(). Good point, looking again, I think we should rather fix dma_request_slave_channel_reason() as it was expected to return err code and add new users. Anyway users of this API do expect the reason... Hrm, they are for different use.dma_request_slave_channel()/_reason() is for drivers only working via DT or ACPI while dma_request_slave_channel_compat()/_reason() is for drivers expected to run in DT/ACPI or legacy mode as well. I added the dma_request_slave_channel_compat_reason() because OMAP/daVinci drivers are using this to request channels - they need to support DT and legacy mode. But it is doable to do this for both the non _compat and _compat version: 1. change all users to check IS_ERR_OR_NULL(chan) return the PTR_ERR if not NULL, or do whatever the driver was doing in case of chan == NULL. 2. change the non _compat and _compat versions to do the same as the _reason variants, #define the _reason ones to the non _reason names 3. Rename the _reason use to non _reason function in drivers 4. Remove the #defines for the _reason functions 5. Change the IS_ERR_OR_NULL(chan) to IS_ERR(chan) in all drivers The result: Both dma_request_slave_channel() and dma_request_slave_channel_compat() will return ERR_PTR in case of failure or in success they will return the pinter to chan. Is this what you were asking? It is a bit broader than what this series was doing: taking care of OMAP/daVinci drivers for deferred probing regarding to dmaengine ;) -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/13] serial: 8250_dma: Support for deferred probing when requesting DMA channels
On 05/26/2015 06:08 PM, Tony Lindgren wrote:
* Peter Ujfalusi peter.ujfal...@ti.com [150526 06:28]:
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channels. In case of error, return the error code we received including
-EPROBE_DEFER
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/tty/serial/8250/8250_dma.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 21d01a491405..a617eca4e97d 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -182,21 +182,19 @@ int serial8250_request_dma(struct uart_8250_port *p)
dma_cap_set(DMA_SLAVE, mask);
/* Get a channel for RX */
-dma-rxchan = dma_request_slave_channel_compat(mask,
- dma-fn, dma-rx_param,
- p-port.dev, rx);
-if (!dma-rxchan)
-return -ENODEV;
+dma-rxchan = dma_request_slave_channel_compat_reason(mask, dma-fn,
+dma-rx_param, p-port.dev, rx);
+if (IS_ERR(dma-rxchan))
+return PTR_ERR(dma-rxchan);
dmaengine_slave_config(dma-rxchan, dma-rxconf);
/* Get a channel for TX */
-dma-txchan = dma_request_slave_channel_compat(mask,
- dma-fn, dma-tx_param,
- p-port.dev, tx);
-if (!dma-txchan) {
+dma-txchan = dma_request_slave_channel_compat_reason(mask, dma-fn,
+dma-tx_param, p-port.dev, tx);
+if (IS_ERR(dma-txchan)) {
dma_release_channel(dma-rxchan);
-return -ENODEV;
+return PTR_ERR(dma-txchan);
}
dmaengine_slave_config(dma-txchan, dma-txconf);
In general the drivers need to work just fine also without DMA.
Does this handle the case properly where no DMA channel is configured
for the driver in the dts file?
The 8250 core will fall back to PIO mode if the DMA can not be requested.
At the morning I was looking at the 8250 stack and realized that
serial8250_request_dma() will not be called at driver probe time so this patch
can be ignored and will be dropped from the v2 series.
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/13] serial: 8250_dma: Support for deferred probing when requesting DMA channels
On 05/26/2015 05:44 PM, Greg Kroah-Hartman wrote: On Tue, May 26, 2015 at 04:25:58PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. In case of error, return the error code we received including -EPROBE_DEFER I think you typed the function name wrong here :( Oops. Also in other drivers :( I will fix up the messages for the v2 series, which will not going to include the patch against 8250_dma. If I understand things right around the 8250_* is that the serial8250_request_dma() which is called from serial8250_do_startup() is not called at module probe time, so it can not be used to handle deferred probing. Thus this patch can be dropped IMO. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels
Mark, On 05/26/2015 06:27 PM, Mark Brown wrote: On Tue, May 26, 2015 at 04:26:06PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. Only fall back to pio mode if the error code returned is not -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER. I've got two patches from a patch series here with no cover letter... I'm guessing there's no interdependencies or anything? Please always ensure that when sending a patch series everyone getting the patches can tell what the series as a whole looks like (if there's no dependencies consider posting as individual patches rather than a series). I have put the maintainers of the relevant subsystems as CC in the commit message and sent the series to all of the mailing lists. This series was touching 7 subsystems and I thought not spamming every maintainer with all the mails might be better. In v2 I will keep this in mind. The series depends on the first two patch, which adds the dma_request_slave_channel_compat_reason() function. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/13] serial: 8250_dma: Support for deferred probing when requesting DMA channels
On 05/27/2015 01:41 PM, Peter Ujfalusi wrote: On 05/26/2015 05:44 PM, Greg Kroah-Hartman wrote: On Tue, May 26, 2015 at 04:25:58PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. In case of error, return the error code we received including -EPROBE_DEFER I think you typed the function name wrong here :( Oops. Also in other drivers :( I mean in other patches ;) I will fix up the messages for the v2 series, which will not going to include the patch against 8250_dma. If I understand things right around the 8250_* is that the serial8250_request_dma() which is called from serial8250_do_startup() is not called at module probe time, so it can not be used to handle deferred probing. Thus this patch can be dropped IMO. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/13] crypto: omap-des - Support for deferred probing when requesting DMA channels
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channels. Only fall back to pio mode if the error code returned is not
-EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Lokesh Vutla lokeshvu...@ti.com
---
drivers/crypto/omap-des.c | 38 --
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c
index 46307098f8ba..06be02f520da 100644
--- a/drivers/crypto/omap-des.c
+++ b/drivers/crypto/omap-des.c
@@ -340,7 +340,7 @@ static void omap_des_dma_out_callback(void *data)
static int omap_des_dma_init(struct omap_des_dev *dd)
{
- int err = -ENOMEM;
+ int err;
dma_cap_mask_t mask;
dd-dma_lch_out = NULL;
@@ -349,21 +349,20 @@ static int omap_des_dma_init(struct omap_des_dev *dd)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- dd-dma_lch_in = dma_request_slave_channel_compat(mask,
- omap_dma_filter_fn,
- dd-dma_in,
- dd-dev, rx);
- if (!dd-dma_lch_in) {
+ dd-dma_lch_in = dma_request_slave_channel_compat_reason(mask,
+ omap_dma_filter_fn, dd-dma_in,
+ dd-dev, rx);
+ if (IS_ERR(dd-dma_lch_in)) {
dev_err(dd-dev, Unable to request in DMA channel\n);
- goto err_dma_in;
+ return PTR_ERR(dd-dma_lch_in);
}
- dd-dma_lch_out = dma_request_slave_channel_compat(mask,
- omap_dma_filter_fn,
- dd-dma_out,
- dd-dev, tx);
- if (!dd-dma_lch_out) {
+ dd-dma_lch_out = dma_request_slave_channel_compat_reason(mask,
+ omap_dma_filter_fn, dd-dma_out,
+ dd-dev, tx);
+ if (IS_ERR(dd-dma_lch_out)) {
dev_err(dd-dev, Unable to request out DMA channel\n);
+ err = PTR_ERR(dd-dma_lch_out);
goto err_dma_out;
}
@@ -371,14 +370,15 @@ static int omap_des_dma_init(struct omap_des_dev *dd)
err_dma_out:
dma_release_channel(dd-dma_lch_in);
-err_dma_in:
- if (err)
- pr_err(error: %d\n, err);
+
return err;
}
static void omap_des_dma_cleanup(struct omap_des_dev *dd)
{
+ if (dd-pio_only)
+ return;
+
dma_release_channel(dd-dma_lch_out);
dma_release_channel(dd-dma_lch_in);
}
@@ -1110,7 +1110,9 @@ static int omap_des_probe(struct platform_device *pdev)
tasklet_init(dd-queue_task, omap_des_queue_task, (unsigned long)dd);
err = omap_des_dma_init(dd);
- if (err DES_REG_IRQ_STATUS(dd) DES_REG_IRQ_ENABLE(dd)) {
+ if (err == -EPROBE_DEFER) {
+ goto err_irq;
+ } else if (err DES_REG_IRQ_STATUS(dd) DES_REG_IRQ_ENABLE(dd)) {
dd-pio_only = 1;
irq = platform_get_irq(pdev, 0);
@@ -1154,8 +1156,8 @@ err_algs:
for (j = dd-pdata-algs_info[i].registered - 1; j = 0; j--)
crypto_unregister_alg(
dd-pdata-algs_info[i].algs_list[j]);
- if (!dd-pio_only)
- omap_des_dma_cleanup(dd);
+
+ omap_des_dma_cleanup(dd);
err_irq:
tasklet_kill(dd-done_task);
tasklet_kill(dd-queue_task);
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/13] mmc: davinci_mmc: Support for deferred probing when requesting DMA channels
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channels. Only fall back to pio mode if the error code returned is not
-EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Ulf Hansson ulf.hans...@linaro.org
---
drivers/mmc/host/davinci_mmc.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index b2b3f8bbfd8c..df81e4e2f662 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -530,20 +530,20 @@ static int __init davinci_acquire_dma_channels(struct
mmc_davinci_host *host)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-dma_tx =
- dma_request_slave_channel_compat(mask, edma_filter_fn,
- host-txdma, mmc_dev(host-mmc), tx);
- if (!host-dma_tx) {
+ host-dma_tx = dma_request_slave_channel_compat_reason(mask,
+ edma_filter_fn, host-txdma,
+ mmc_dev(host-mmc), tx);
+ if (IS_ERR(host-dma_tx)) {
dev_err(mmc_dev(host-mmc), Can't get dma_tx channel\n);
- return -ENODEV;
+ return PTR_ERR(host-dma_tx);
}
- host-dma_rx =
- dma_request_slave_channel_compat(mask, edma_filter_fn,
- host-rxdma, mmc_dev(host-mmc), rx);
- if (!host-dma_rx) {
+ host-dma_rx = dma_request_slave_channel_compat_reason(mask,
+ edma_filter_fn, host-rxdma,
+ mmc_dev(host-mmc), rx);
+ if (IS_ERR(host-dma_rx)) {
dev_err(mmc_dev(host-mmc), Can't get dma_rx channel\n);
- r = -ENODEV;
+ r = PTR_ERR(host-dma_rx);
goto free_master_write;
}
@@ -1307,8 +1307,12 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
host-mmc_irq = irq;
host-sdio_irq = platform_get_irq(pdev, 1);
- if (host-use_dma davinci_acquire_dma_channels(host) != 0)
+ if (host-use_dma) {
+ ret = davinci_acquire_dma_channels(host);
+ if (ret == -EPROBE_DEFER)
+ goto out;
host-use_dma = 0;
+ }
/* REVISIT: someday, support IRQ-driven card detection. */
mmc-caps |= MMC_CAP_NEEDS_POLL;
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/13] dmaengine: of_dma: Correct return code for of_dma_request_slave_channel in case !CONFIG_OF
of_dma_request_slave_channel should return either pointer for valid
dma_chan or ERR_PTR() error code, NULL is not expected to be returned.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Grant Likely grant.lik...@linaro.org
CC: Rob Herring robh...@kernel.org
---
include/linux/of_dma.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index 98ba7525929e..0fd80be152c4 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -80,7 +80,7 @@ static inline int of_dma_router_register(struct device_node
*np,
static inline struct dma_chan *of_dma_request_slave_channel(struct device_node
*np,
const char *name)
{
- return NULL;
+ return ERR_PTR(-ENODEV);
}
static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args
*dma_spec,
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/13] mmc: omap_hsmmc: Support for deferred probing when requesting DMA channels
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channels. In case of error, return the error code we received including
-EPROBE_DEFER
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Ulf Hansson ulf.hans...@linaro.org
---
drivers/mmc/host/omap_hsmmc.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 57bb85930f81..d252478391ee 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2088,23 +2088,21 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-rx_chan =
- dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
-rx_req, pdev-dev, rx);
+ host-rx_chan = dma_request_slave_channel_compat_reason(mask,
+ omap_dma_filter_fn, rx_req, pdev-dev, rx);
- if (!host-rx_chan) {
+ if (IS_ERR(host-rx_chan)) {
dev_err(mmc_dev(host-mmc), unable to obtain RX DMA engine
channel %u\n, rx_req);
- ret = -ENXIO;
+ ret = PTR_ERR(host-rx_chan);
goto err_irq;
}
- host-tx_chan =
- dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
-tx_req, pdev-dev, tx);
+ host-tx_chan = dma_request_slave_channel_compat_reason(mask,
+ omap_dma_filter_fn, tx_req, pdev-dev, tx);
- if (!host-tx_chan) {
+ if (IS_ERR(host-tx_chan)) {
dev_err(mmc_dev(host-mmc), unable to obtain TX DMA engine
channel %u\n, tx_req);
- ret = -ENXIO;
+ ret = PTR_ERR(host-tx_chan);
goto err_irq;
}
@@ -2166,9 +2164,9 @@ err_slot_name:
if (host-use_reg)
omap_hsmmc_reg_put(host);
err_irq:
- if (host-tx_chan)
+ if (!IS_ERR_OR_NULL(host-tx_chan))
dma_release_channel(host-tx_chan);
- if (host-rx_chan)
+ if (!IS_ERR_OR_NULL(host-rx_chan))
dma_release_channel(host-rx_chan);
pm_runtime_put_sync(host-dev);
pm_runtime_disable(host-dev);
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/13] mmc: omap_hsmmc: No need to check DMA channel validity at module remove
The driver will not probe without valid DMA channels so no need to check if they are valid when the module is removed. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com CC: Ulf Hansson ulf.hans...@linaro.org --- drivers/mmc/host/omap_hsmmc.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 2cd828f42151..57bb85930f81 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2190,10 +2190,8 @@ static int omap_hsmmc_remove(struct platform_device *pdev) if (host-use_reg) omap_hsmmc_reg_put(host); - if (host-tx_chan) - dma_release_channel(host-tx_chan); - if (host-rx_chan) - dma_release_channel(host-rx_chan); + dma_release_channel(host-tx_chan); + dma_release_channel(host-rx_chan); pm_runtime_put_sync(host-dev); pm_runtime_disable(host-dev); -- 2.3.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
dma_request_slave_channel_compat() 'eats' up the returned error codes which
prevents drivers using the compat call to be able to do deferred probing.
The new wrapper is identical in functionality but it will return with error
code in case of failure and will pass the -EPROBE_DEFER to the caller in
case dma_request_slave_channel_reason() returned with it.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/linux/dmaengine.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index abf63ceabef9..6c777394835c 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1120,4 +1120,26 @@ static inline struct dma_chan
return __dma_request_channel(mask, fn, fn_param);
}
+
+#define dma_request_slave_channel_compat_reason(mask, x, y, dev, name) \
+ __dma_request_slave_channel_compat_reason((mask), x, y, dev, name)
+
+static inline struct dma_chan
+*__dma_request_slave_channel_compat_reason(const 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_reason(dev, name);
+ /* Try via legacy API if not requesting for deferred probing */
+ if (IS_ERR(chan) PTR_ERR(chan) != -EPROBE_DEFER)
+ chan = __dma_request_channel(mask, fn, fn_param);
+
+ if (!chan)
+ chan = ERR_PTR(-ENODEV);
+
+ return chan;
+}
+
#endif /* DMAENGINE_H */
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/13] dmaengine + omap drivers: support fro deferred probing
Hi, Vinod: as I promised: https://lkml.org/lkml/2015/5/8/80 With this series it is possible to put omap-dma or edma to even late_initcall and the drivers will figure out the load order fine(ish). We need to add dma_request_slave_channel_compat_reason() which is the equivalent of dma_request_slave_channel_compat() but returning with error codes in case of failure instead of NULL pointer. The rest of the series just converts the OMAP/daVinci drivers to use this new function to get the channel(s) and to handle the deferred probing. I did not moved the omap-dma, edma or ti-dma-crossbar from arch_initcall. If I do so UART will only comes up after the DMA driver is loaded since we are using, or going to use 8250 with DAM support. This delays the kernel messages. Other issue is the MMC/SD cards. On board with eMMC and SD card slot the mmcblk0/1 might get swapped due to different probe order for the MMC/SD drivers. For example in omap5-uevm: 1. omap-dma in arch_initcall the SD card is mmcblk1 (4809c000.mmc) and eMMC is mmcblk0 (480b4000.mmc) 2. omap-dma in late_initcall the SD card is mmcblk0 (4809c000.mmc) and eMMC is mmcblk1 (480b4000.mmc) Because in case 1 the 4809c000.mmc got deferred by missing regulator so 480b4000.mmc got registered first. In case 2 both deferring because of DMA and at the end 4809c000.mmc get registered first. So far I have not found a way to bind mmcblk0/1 to a specific node... Regards, Peter --- Peter Ujfalusi (13): dmaengine: of_dma: Correct return code for of_dma_request_slave_channel in case !CONFIG_OF dmaengine: Introduce dma_request_slave_channel_compat_reason() serial: 8250_dma: Support for deferred probing when requesting DMA channels mmc: omap_hsmmc: No need to check DMA channel validity at module remove mmc: omap_hsmmc: Support for deferred probing when requesting DMA channels mmc: omap: Support for deferred probing when requesting DMA channels mmc: davinci_mmc: Support for deferred probing when requesting DMA channels crypto: omap-aes - Support for deferred probing when requesting DMA channels crypto: omap-des - Support for deferred probing when requesting DMA channels crypto: omap-sham - Support for deferred probing when requesting DMA channel spi: omap2-mcspi: Support for deferred probing when requesting DMA channels [media] omap3isp: Support for deferred probing when requesting DMA channel ASoC: omap-pcm: Switch to use dma_request_slave_channel_compat_reason() drivers/crypto/omap-aes.c | 38 --- drivers/crypto/omap-des.c | 38 --- drivers/crypto/omap-sham.c| 15 drivers/media/platform/omap3isp/isphist.c | 12 +++--- drivers/mmc/host/davinci_mmc.c| 26 - drivers/mmc/host/omap.c | 20 drivers/mmc/host/omap_hsmmc.c | 28 ++- drivers/spi/spi-omap2-mcspi.c | 36 + drivers/tty/serial/8250/8250_dma.c| 18 +++ include/linux/dmaengine.h | 22 ++ include/linux/of_dma.h| 2 +- sound/soc/omap/omap-pcm.c | 16 - 12 files changed, 164 insertions(+), 107 deletions(-) -- 2.3.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/13] crypto: omap-sham - Support for deferred probing when requesting DMA channel
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channel. Only fall back to polling mode if the error code returned is not
-EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Lokesh Vutla lokeshvu...@ti.com
---
drivers/crypto/omap-sham.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index b2024c95a3cf..66bae8288741 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1946,9 +1946,14 @@ static int omap_sham_probe(struct platform_device *pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- dd-dma_lch = dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
- dd-dma, dev, rx);
- if (!dd-dma_lch) {
+ dd-dma_lch = dma_request_slave_channel_compat_reason(mask,
+ omap_dma_filter_fn,
+ dd-dma, dev, rx);
+ if (IS_ERR(dd-dma_lch)) {
+ err = PTR_ERR(dd-dma_lch);
+ if (err == -EPROBE_DEFER)
+ goto data_err;
+
dd-polling_mode = 1;
dev_dbg(dev, using polling mode instead of dma\n);
}
@@ -1995,7 +2000,7 @@ err_algs:
dd-pdata-algs_info[i].algs_list[j]);
err_pm:
pm_runtime_disable(dev);
- if (dd-dma_lch)
+ if (!dd-polling_mode)
dma_release_channel(dd-dma_lch);
data_err:
dev_err(dev, initialization failed.\n);
@@ -2021,7 +2026,7 @@ static int omap_sham_remove(struct platform_device *pdev)
tasklet_kill(dd-done_task);
pm_runtime_disable(pdev-dev);
- if (dd-dma_lch)
+ if (!dd-polling_mode)
dma_release_channel(dd-dma_lch);
return 0;
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/13] crypto: omap-aes - Support for deferred probing when requesting DMA channels
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channels. Only fall back to pio mode if the error code returned is not
-EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Lokesh Vutla lokeshvu...@ti.com
---
drivers/crypto/omap-aes.c | 38 --
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 9a28b7e07c71..699a14509adb 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -356,7 +356,7 @@ static void omap_aes_dma_out_callback(void *data)
static int omap_aes_dma_init(struct omap_aes_dev *dd)
{
- int err = -ENOMEM;
+ int err;
dma_cap_mask_t mask;
dd-dma_lch_out = NULL;
@@ -365,21 +365,20 @@ static int omap_aes_dma_init(struct omap_aes_dev *dd)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- dd-dma_lch_in = dma_request_slave_channel_compat(mask,
- omap_dma_filter_fn,
- dd-dma_in,
- dd-dev, rx);
- if (!dd-dma_lch_in) {
+ dd-dma_lch_in = dma_request_slave_channel_compat_reason(mask,
+ omap_dma_filter_fn, dd-dma_in,
+ dd-dev, rx);
+ if (IS_ERR(dd-dma_lch_in)) {
dev_err(dd-dev, Unable to request in DMA channel\n);
- goto err_dma_in;
+ return PTR_ERR(dd-dma_lch_in);
}
- dd-dma_lch_out = dma_request_slave_channel_compat(mask,
- omap_dma_filter_fn,
- dd-dma_out,
- dd-dev, tx);
- if (!dd-dma_lch_out) {
+ dd-dma_lch_out = dma_request_slave_channel_compat_reason(mask,
+ omap_dma_filter_fn, dd-dma_out,
+ dd-dev, tx);
+ if (IS_ERR(dd-dma_lch_out)) {
dev_err(dd-dev, Unable to request out DMA channel\n);
+ err = PTR_ERR(dd-dma_lch_out);
goto err_dma_out;
}
@@ -387,14 +386,15 @@ static int omap_aes_dma_init(struct omap_aes_dev *dd)
err_dma_out:
dma_release_channel(dd-dma_lch_in);
-err_dma_in:
- if (err)
- pr_err(error: %d\n, err);
+
return err;
}
static void omap_aes_dma_cleanup(struct omap_aes_dev *dd)
{
+ if (dd-pio_only)
+ return;
+
dma_release_channel(dd-dma_lch_out);
dma_release_channel(dd-dma_lch_in);
}
@@ -1218,7 +1218,9 @@ static int omap_aes_probe(struct platform_device *pdev)
tasklet_init(dd-queue_task, omap_aes_queue_task, (unsigned long)dd);
err = omap_aes_dma_init(dd);
- if (err AES_REG_IRQ_STATUS(dd) AES_REG_IRQ_ENABLE(dd)) {
+ if (err == -EPROBE_DEFER) {
+ goto err_irq;
+ } else if (err AES_REG_IRQ_STATUS(dd) AES_REG_IRQ_ENABLE(dd)) {
dd-pio_only = 1;
irq = platform_get_irq(pdev, 0);
@@ -1262,8 +1264,8 @@ err_algs:
for (j = dd-pdata-algs_info[i].registered - 1; j = 0; j--)
crypto_unregister_alg(
dd-pdata-algs_info[i].algs_list[j]);
- if (!dd-pio_only)
- omap_aes_dma_cleanup(dd);
+
+ omap_aes_dma_cleanup(dd);
err_irq:
tasklet_kill(dd-done_task);
tasklet_kill(dd-queue_task);
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channels. Only fall back to pio mode if the error code returned is not
-EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Mark Brown broo...@kernel.org
---
drivers/spi/spi-omap2-mcspi.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index a7d85c5ab2fa..e6ff937688ff 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -948,6 +948,7 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
struct omap2_mcspi_dma *mcspi_dma;
dma_cap_mask_t mask;
unsigned sig;
+ int ret = 0;
mcspi = spi_master_get_devdata(master);
mcspi_dma = mcspi-dma_channels + spi-chip_select;
@@ -959,30 +960,35 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma-dma_rx_sync_dev;
- mcspi_dma-dma_rx =
- dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
-sig, master-dev,
-mcspi_dma-dma_rx_ch_name);
- if (!mcspi_dma-dma_rx)
+ mcspi_dma-dma_rx = dma_request_slave_channel_compat_reason(mask,
+ omap_dma_filter_fn, sig, master-dev,
+ mcspi_dma-dma_rx_ch_name);
+ if (IS_ERR(mcspi_dma-dma_rx)) {
+ ret = PTR_ERR(mcspi_dma-dma_rx);
+ mcspi_dma-dma_rx = NULL;
+ if (ret != -EPROBE_DEFER)
+ ret = -EAGAIN;
goto no_dma;
+ }
sig = mcspi_dma-dma_tx_sync_dev;
- mcspi_dma-dma_tx =
- dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
-sig, master-dev,
-mcspi_dma-dma_tx_ch_name);
+ mcspi_dma-dma_tx = dma_request_slave_channel_compat_reason(mask,
+ omap_dma_filter_fn, sig, master-dev,
+ mcspi_dma-dma_tx_ch_name);
- if (!mcspi_dma-dma_tx) {
+ if (IS_ERR(mcspi_dma-dma_tx)) {
+ ret = PTR_ERR(mcspi_dma-dma_tx);
+ mcspi_dma-dma_tx = NULL;
dma_release_channel(mcspi_dma-dma_rx);
mcspi_dma-dma_rx = NULL;
- goto no_dma;
+ if (ret != -EPROBE_DEFER)
+ ret = -EAGAIN;
}
- return 0;
-
no_dma:
- dev_warn(spi-dev, not using DMA for McSPI\n);
- return -EAGAIN;
+ if (ret ret != -EPROBE_DEFER)
+ dev_warn(spi-dev, not using DMA for McSPI\n);
+ return ret;
}
static int omap2_mcspi_setup(struct spi_device *spi)
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/13] [media] omap3isp: Support for deferred probing when requesting DMA channel
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channel. Only fall back to pio mode if the error code returned is not
-EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Laurent Pinchart laurent.pinch...@ideasonboard.com
CC: Mauro Carvalho Chehab mche...@osg.samsung.com
---
drivers/media/platform/omap3isp/isphist.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isphist.c
b/drivers/media/platform/omap3isp/isphist.c
index 7138b043a4aa..e690ca13af0e 100644
--- a/drivers/media/platform/omap3isp/isphist.c
+++ b/drivers/media/platform/omap3isp/isphist.c
@@ -499,14 +499,20 @@ int omap3isp_hist_init(struct isp_device *isp)
if (res)
sig = res-start;
- hist-dma_ch = dma_request_slave_channel_compat(mask,
+ hist-dma_ch = dma_request_slave_channel_compat_reason(mask,
omap_dma_filter_fn, sig, isp-dev, hist);
- if (!hist-dma_ch)
+ if (IS_ERR(hist-dma_ch)) {
+ ret = PTR_ERR(hist-dma_ch);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ hist-dma_ch = NULL;
dev_warn(isp-dev,
hist: DMA channel request failed, using
PIO\n);
- else
+ } else {
dev_dbg(isp-dev, hist: using DMA channel %s\n,
dma_chan_name(hist-dma_ch));
+ }
}
hist-ops = hist_ops;
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/13] mmc: omap: Support for deferred probing when requesting DMA channels
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channels. Only fall back to pio mode if the error code returned is not
-EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Ulf Hansson ulf.hans...@linaro.org
CC: Jarkko Nikula jarkko.nik...@bitmer.com
---
drivers/mmc/host/omap.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 68dd6c79c378..29238d0fbc24 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -1390,20 +1390,32 @@ static int mmc_omap_probe(struct platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_DMA, tx);
if (res)
sig = res-start;
- host-dma_tx = dma_request_slave_channel_compat(mask,
+ host-dma_tx = dma_request_slave_channel_compat_reason(mask,
omap_dma_filter_fn, sig, pdev-dev, tx);
- if (!host-dma_tx)
+ if (IS_ERR(host-dma_tx)) {
+ ret = PTR_ERR(host-dma_tx);
+ if (ret == -EPROBE_DEFER)
+ goto err_free_dma;
+
+ host-dma_tx = NULL;
dev_warn(host-dev, unable to obtain TX DMA engine channel
%u\n,
sig);
+ }
res = platform_get_resource_byname(pdev, IORESOURCE_DMA, rx);
if (res)
sig = res-start;
- host-dma_rx = dma_request_slave_channel_compat(mask,
+ host-dma_rx = dma_request_slave_channel_compat_reason(mask,
omap_dma_filter_fn, sig, pdev-dev, rx);
- if (!host-dma_rx)
+ if (IS_ERR(host-dma_rx)) {
+ ret = PTR_ERR(host-dma_rx);
+ if (ret == -EPROBE_DEFER)
+ goto err_free_dma;
+
+ host-dma_rx = NULL;
dev_warn(host-dev, unable to obtain RX DMA engine channel
%u\n,
sig);
+ }
ret = request_irq(host-irq, mmc_omap_irq, 0, DRIVER_NAME, host);
if (ret)
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/13] serial: 8250_dma: Support for deferred probing when requesting DMA channels
Switch to use ma_request_slave_channel_compat_reason() to request the DMA
channels. In case of error, return the error code we received including
-EPROBE_DEFER
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/tty/serial/8250/8250_dma.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_dma.c
b/drivers/tty/serial/8250/8250_dma.c
index 21d01a491405..a617eca4e97d 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -182,21 +182,19 @@ int serial8250_request_dma(struct uart_8250_port *p)
dma_cap_set(DMA_SLAVE, mask);
/* Get a channel for RX */
- dma-rxchan = dma_request_slave_channel_compat(mask,
- dma-fn, dma-rx_param,
- p-port.dev, rx);
- if (!dma-rxchan)
- return -ENODEV;
+ dma-rxchan = dma_request_slave_channel_compat_reason(mask, dma-fn,
+ dma-rx_param, p-port.dev, rx);
+ if (IS_ERR(dma-rxchan))
+ return PTR_ERR(dma-rxchan);
dmaengine_slave_config(dma-rxchan, dma-rxconf);
/* Get a channel for TX */
- dma-txchan = dma_request_slave_channel_compat(mask,
- dma-fn, dma-tx_param,
- p-port.dev, tx);
- if (!dma-txchan) {
+ dma-txchan = dma_request_slave_channel_compat_reason(mask, dma-fn,
+ dma-tx_param, p-port.dev, tx);
+ if (IS_ERR(dma-txchan)) {
dma_release_channel(dma-rxchan);
- return -ENODEV;
+ return PTR_ERR(dma-txchan);
}
dmaengine_slave_config(dma-txchan, dma-txconf);
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/13] ASoC: omap-pcm: Switch to use dma_request_slave_channel_compat_reason()
dmaengine provides a wrapper function to handle DT and non DT boots when
requesting DMA channel. Use that instead of checking for of_node in the
platform driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Mark Brown broo...@kernel.org
CC: Jarkko Nikula jarkko.nik...@bitmer.com
CC: Liam Girdwood lgirdw...@gmail.com
---
sound/soc/omap/omap-pcm.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
index 52fd7cbbd1f4..ae04834f4697 100644
--- a/sound/soc/omap/omap-pcm.c
+++ b/sound/soc/omap/omap-pcm.c
@@ -132,6 +132,7 @@ static int omap_pcm_open(struct snd_pcm_substream
*substream)
struct snd_dmaengine_dai_dma_data *dma_data;
struct dma_slave_caps dma_caps;
struct dma_chan *chan;
+ dma_cap_mask_t mask;
u32 addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
@@ -139,12 +140,15 @@ static int omap_pcm_open(struct snd_pcm_substream
*substream)
dma_data = snd_soc_dai_get_dma_data(rtd-cpu_dai, substream);
- if (rtd-cpu_dai-dev-of_node)
- chan = dma_request_slave_channel(rtd-cpu_dai-dev,
-dma_data-filter_data);
- else
- chan = snd_dmaengine_pcm_request_channel(omap_dma_filter_fn,
-dma_data-filter_data);
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_SLAVE, mask);
+ dma_cap_set(DMA_CYCLIC, mask);
+ chan = dma_request_slave_channel_compat_reason(mask, omap_dma_filter_fn,
+ dma_data-filter_data, rtd-cpu_dai-dev,
+ dma_data-filter_data);
+
+ if (IS_ERR(chan))
+ return PTR_ERR(chan);
if (!dma_get_slave_caps(chan, dma_caps)) {
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] WL1273 FM Radio driver...
On 02/08/11 12:09, ext Bensaid, Selma wrote: 2 Digital interfaces are possible for FM WL1273: - the external connection: the I2S lines are used for the FM PCM samples - the internal connection: the BT PCM interface is used for the FM PCM samples Yes, that is correct, I just did not wanted to go into details. Currently the ASoC codec driver only supports the BT/FM PCM interface. Adding the dedicated I2S interface for the FM radio should not be a big effort, we just need to add another dai to the codec driver, and connect that to the host processor. As I said before, we only implemented the BT/FM PCM interface support, since we do not have HW, where we could verify the dedicated FM I2S lines. But adding the support should not be a big deal IMHO (and can be done even without any means of testing it). For both configuration we have a set of HCI commands to configure the FM audio path and one of my concerns is to know if the wl1273_codec should handle the audio path configuration and the switch between FM and BT SCO? It would be better if the codec could handle the configuration, depending on which DAI is in use. If we can send HCI commands from kernel, I think that would be the cleanest way. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
