Re: camera control interface
Hi Laurent, On 30-05-18, 10:31, Laurent Pinchart wrote: > On Wednesday, 30 May 2018 10:28:58 EEST Vinod wrote: > > On 30-05-18, 10:04, Laurent Pinchart wrote: > > >> I am writing a driver for camera control inteface which is an i2c > > >> controller. So looking up the code I think it can be a v4l subdev, > > >> right? Can it be an independent i2c master and not v4l subdev? > > > > > > What do you mean by "camera control interface" here ? A hardware device > > > handling communication with camera sensors ? I assume the communication > > > bus is I2C ? Is that "camera control interface" plain I2C or does it have > > > additional features ? > > > > > > If we're talking about an I2C controller a V4L2 subdev is not only > > > unneeded, but it wouldn't help. You need an I2C master. > > > > Sorry if I wasn't quite right in description, the control interface is > > indeed i2c master and gpio. The camera sensors are i2c slaves connected to > > this i2c master and gpio for sensors are connected to this as well. > > No worries. This clarifies the context. > > > >> Second the control sports GPIOs. It can support a set of > > >> synchronization primitives so it's possible to drive I2C clients and > > >> GPIOs with hardware controlled timing to allow for sync control of > > >> sensors hooked and also for fancy strobe. How would we represent these > > >> gpios in v4l2 and allow the control, any ideas on that. > > > > > > Even if your main use case it related to camera, synchronization of I2C > > > and GPIO doesn't seem to be a V4L2 feature to me. It sounds that you need > > > to implement that int he I2C and GPIO subsystems. > > > > Well if a user wants to capture multiple cameras and synchronise, > > wouldn't that need sync of i2c and gpio. I understand it may not be > > supported but the question is would it be a nice feature for v4l, if so > > how to go about it? > > You need two parts to implement this in my opinion. First, you need a > synchronized I2C + GPIO mechanism on which to base the implementation. That's > not V4L2-specific and should I believe be handled in the I2C and GPIO > subsystems. Then, you need to expose the concept of camera synchronization in > V4L2. That part will likely require API extensions, both inside the kernel > and > towards userspace. Okay thanks. So should I do a v4l subdev for i2c master or leave it in i2c subsystem. Does subdev make sense for gpio too.. How does one go about 'linking' the two? Btw where is v4l userspace located? -- ~Vinod
Re: camera control interface
Hey Laurent, On 30-05-18, 10:04, Laurent Pinchart wrote: > > > > I am writing a driver for camera control inteface which is an i2c > > controller. So looking up the code I think it can be a v4l subdev, > > right? Can it be an independent i2c master and not v4l subdev? > > What do you mean by "camera control interface" here ? A hardware device > handling communication with camera sensors ? I assume the communication bus > is > I2C ? Is that "camera control interface" plain I2C or does it have additional > features ? > > If we're talking about an I2C controller a V4L2 subdev is not only unneeded, > but it wouldn't help. You need an I2C master. Sorry if I wasn't quite right in description, the control interface is indeed i2c master and gpio. The camera sensors are i2c slaves connected to this i2c master and gpio for sensors are connected to this as well. > > Second the control sports GPIOs. It can support a set of > > synchronization primitives so it's possible to drive I2C clients and > > GPIOs with hardware controlled timing to allow for sync control of > > sensors hooked and also for fancy strobe. How would we represent these > > gpios in v4l2 and allow the control, any ideas on that. > > Even if your main use case it related to camera, synchronization of I2C and > GPIO doesn't seem to be a V4L2 feature to me. It sounds that you need to > implement that int he I2C and GPIO subsystems. Well if a user wants to capture multiple cameras and synchronise, wouldn't that need sync of i2c and gpio. I understand it may not be supported but the question is would it be a nice feature for v4l, if so how to go about it? Thanks -- ~Vinod
camera control interface
Hi folks, I am writing a driver for camera control inteface which is an i2c controller. So looking up the code I think it can be a v4l subdev, right? Can it be an independent i2c master and not v4l subdev? Second the control sports GPIOs. It can support a set of synchronization primitives so it's possible to drive I2C clients and GPIOs with hardware controlled timing to allow for sync control of sensors hooked and also for fancy strobe. How would we represent these gpios in v4l2 and allow the control, any ideas on that. Thanks -- ~Vinod
Re: [PATCH v2 11/13] dmaengine: pxa: make the filter function internal
On 24-05-18, 09:07, Robert Jarzmik wrote: > As the pxa architecture and all its related drivers do not rely anymore > on the filter function, thanks to the slave map conversion, make > pxad_filter_fn() static, and remove it from the global namespace. Acked-by: Vinod Koul <vk...@kernel.org> -- ~Vinod
Re: [PATCH v2 10/13] dmaengine: pxa: document pxad_param
On 24-05-18, 09:07, Robert Jarzmik wrote: > Add some documentation for the pxad_param structure, and describe the > contract behind the minimal required priority of a DMA channel. Acked-by: Vinod Koul <vk...@kernel.org> -- ~Vinod
Re: [PATCH 2/8] dmaengine: shdmac: Change platform check to CONFIG_ARCH_RENESAS
On Fri, Apr 20, 2018 at 03:28:28PM +0200, Geert Uytterhoeven wrote:
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
> CONFIG_ARCH_SHMOBILE, hence use the former.
>
> Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
> check, just like before support for Renesas ARM SoCs was added.
>
> Instead of blindly changing all the #ifdefs, switch the main code block
> in sh_dmae_probe() to IS_ENABLED(), as this allows to remove all the
> remaining #ifdefs.
>
> This will allow to drop ARCH_SHMOBILE on ARM in the near future.
Applied, thanks
--
~Vinod
Re: [PATCH 5/7] mtd: provide helper to prepare buffers for DMA operations
On Tue, Mar 08, 2016 at 12:15:13PM +0100, Boris Brezillon wrote: > > +#ifdef CONFIG_HAS_DMA Shouldn't this be CONFIG_DMA_ENGINE as you are preparing these descriptors for DMA transfer? -- ~Vinod -- 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: [TRIVIAL PATCH] treewide: Remove unnecessary 0x prefixes before %pa extension uses
On Fri, Mar 04, 2016 at 11:46:32PM -0800, Joe Perches wrote:
> Since commit 3cab1e711297 ("lib/vsprintf: refactor duplicate code
> to special_hex_number()") %pa uses have been ouput with a 0x prefix.
>
> These 0x prefixes in the formats are unnecessary.
>
For this:
> drivers/dma/at_hdmac_regs.h | 2 +-
Acked-by: Vinod Koul <vinod.k...@intel.com>
--
~Vinod
--
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 2/3] dmaengine: sun4i: support module autoloading
On Sun, Feb 21, 2016 at 10:26:35PM -0300, Emilio López wrote: > From: Emilio López <emilio.lo...@collabora.co.uk> > > MODULE_DEVICE_TABLE() is missing, so the module isn't auto-loading on > supported systems. This commit adds the missing line so it loads > automatically when building it as a module and running on a system > with the early sunxi DMA engine. Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-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 Wed, Nov 18, 2015 at 04:51:54PM +0100, Arnd Bergmann wrote: > On Wednesday 18 November 2015 17:43:04 Andy Shevchenko wrote: > > > > > > I assume that the sst-firmware.c case is a mistake, it should just use a > > > plain DMA_SLAVE and not DMA_MEMCPY. > > > > Other way around. > > > > Ok, I see. In that case I guess it also shouldn't call > dmaengine_slave_config(), right? I don't think that's valid > on a MEMCPY channel. Yes it is not valid. In this case the dma driver should invoke a generic memcpy and not need slave parameters, knowing the hw and reason for this (firmware download to DSP memory), this doesn't qualify for slave case. In fact filter function doesn't need a channel, any channel in this controller will be good -- ~Vinod -- 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 Mon, Jun 22, 2015 at 02:31:00PM +0300, Peter Ujfalusi wrote: 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. I dont think so :) 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 Should we keep the filter fn and an API for this, I am still not too sure about that part. Anyway users should be on DT/ACPI. if someone wants filter then let them use dma_request_channel() /* 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 Why should we create a new API, how about marking dma_request_channel() as legacy and generic memcpy API and let other users be migrated? /* 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. Though it has merits but adds another API. We cna have internal _dma_request_xxx API where parameters are missing and clean but to users single API might be a better idea 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); 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? Internally we may have 4 APIs for cleaner handling... Thoughts... ?? -- ~Vinod -- 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 2/2] genalloc: rename of_get_named_gen_pool() to of_gen_pool_get()
On Thu, Jun 11, 2015 at 04:28:32PM +0300, Vladimir Zapolskiy wrote: To be consistent with other kernel interface namings, rename of_get_named_gen_pool() to of_gen_pool_get(). In the original function name _named suffix references to a device tree property, which contains a phandle to a device and the corresponding device driver is assumed to register a gen_pool object. Due to a weak relation and to avoid any confusion (e.g. in future possible scenario if gen_pool objects are named) the suffix is removed. Signed-off-by: Vladimir Zapolskiy vladimir_zapols...@mentor.com --- drivers/dma/mmp_tdma.c| 2 +- For this: Acked-by: Vinod Koul vinod.k...@intel.com -- ~Vinod -- 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 Thu, Jun 04, 2015 at 06:58:06PM +0300, Peter Ujfalusi wrote: 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. Sorry this slipped thru 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 -- ~Vinod -- 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 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 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 I am all ears to stage this work and not do transition gardually.. -- ~Vinod -- 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 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()
--
~Vinod
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
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
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... -- ~Vinod -- 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 00/12] dmaengine: remove users of device_control
On Sat, Oct 11, 2014 at 09:09:33PM +0530, Vinod Koul wrote: The recent discussion [1] on the API have resulted in moving away from device_control ioctl method to proper channel APIs. There are still few users on the device_control which should use the wrappers existing rather than access device_control. This will aid us in deprecating and removing device_control, possibly after the merge window. These can be merged thru respective subsystem tree or dmaengine tree. Either way please just let me know. Applying to dmaengine-next with acks recived, dropping the ones which are applied by respective folks -- ~Vinod Feng's kbuild has tested these as well [2] [1]: http://www.spinics.net/lists/dmaengine/msg02212.html [2]: http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dma_control_cleanup Vinod Koul (12): pata_arasan_cf: use dmaengine_terminate_all() API dmaengine: coh901318: use dmaengine_terminate_all() API [media] V4L2: mx3_camer: use dmaengine_pause() API mtd: fsmc_nand: use dmaengine_terminate_all() API mtd: sh_flctl: use dmaengine_terminate_all() API net: ks8842: use dmaengine_terminate_all() API spi/atmel: use dmaengine_terminate_all() API spi/spi-dw-mid.c: use dmaengine_slave_config() API serial: sh-sci: use dmaengine_terminate_all() API usb: musb: ux500_dma: use dmaengine_xxx() APIs ASoC: txx9: use dmaengine_terminate_all() API video: mx3fb: use dmaengine_terminate_all() API drivers/ata/pata_arasan_cf.c |5 ++--- drivers/dma/coh901318.c|2 +- drivers/media/platform/soc_camera/mx3_camera.c |6 ++ drivers/mtd/nand/fsmc_nand.c |2 +- drivers/mtd/nand/sh_flctl.c|2 +- drivers/net/ethernet/micrel/ks8842.c |6 ++ drivers/spi/spi-atmel.c|6 ++ drivers/spi/spi-dw-mid.c |6 ++ drivers/tty/serial/sh-sci.c|2 +- drivers/usb/musb/ux500_dma.c |7 ++- drivers/video/fbdev/mx3fb.c|3 +-- sound/soc/txx9/txx9aclc.c |7 +++ 12 files changed, 20 insertions(+), 34 deletions(-) -- To unsubscribe from this list: send the line unsubscribe dmaengine in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- -- To unsubscribe from this list: send the line unsubscribe linux-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/12] dmaengine: remove users of device_control
The recent discussion [1] on the API have resulted in moving away from device_control ioctl method to proper channel APIs. There are still few users on the device_control which should use the wrappers existing rather than access device_control. This will aid us in deprecating and removing device_control, possibly after the merge window. These can be merged thru respective subsystem tree or dmaengine tree. Either way please just let me know. Feng's kbuild has tested these as well [2] [1]: http://www.spinics.net/lists/dmaengine/msg02212.html [2]: http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dma_control_cleanup Vinod Koul (12): pata_arasan_cf: use dmaengine_terminate_all() API dmaengine: coh901318: use dmaengine_terminate_all() API [media] V4L2: mx3_camer: use dmaengine_pause() API mtd: fsmc_nand: use dmaengine_terminate_all() API mtd: sh_flctl: use dmaengine_terminate_all() API net: ks8842: use dmaengine_terminate_all() API spi/atmel: use dmaengine_terminate_all() API spi/spi-dw-mid.c: use dmaengine_slave_config() API serial: sh-sci: use dmaengine_terminate_all() API usb: musb: ux500_dma: use dmaengine_xxx() APIs ASoC: txx9: use dmaengine_terminate_all() API video: mx3fb: use dmaengine_terminate_all() API drivers/ata/pata_arasan_cf.c |5 ++--- drivers/dma/coh901318.c|2 +- drivers/media/platform/soc_camera/mx3_camera.c |6 ++ drivers/mtd/nand/fsmc_nand.c |2 +- drivers/mtd/nand/sh_flctl.c|2 +- drivers/net/ethernet/micrel/ks8842.c |6 ++ drivers/spi/spi-atmel.c|6 ++ drivers/spi/spi-dw-mid.c |6 ++ drivers/tty/serial/sh-sci.c|2 +- drivers/usb/musb/ux500_dma.c |7 ++- drivers/video/fbdev/mx3fb.c|3 +-- sound/soc/txx9/txx9aclc.c |7 +++ 12 files changed, 20 insertions(+), 34 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-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/12] [media] V4L2: mx3_camer: use dmaengine_pause() API
The drivers should use dmaengine_pause() API instead of
accessing the device_control which will be deprecated soon
Signed-off-by: Vinod Koul vinod.k...@intel.com
---
drivers/media/platform/soc_camera/mx3_camera.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx3_camera.c
b/drivers/media/platform/soc_camera/mx3_camera.c
index 83315df..7696a87 100644
--- a/drivers/media/platform/soc_camera/mx3_camera.c
+++ b/drivers/media/platform/soc_camera/mx3_camera.c
@@ -415,10 +415,8 @@ static void mx3_stop_streaming(struct vb2_queue *q)
struct mx3_camera_buffer *buf, *tmp;
unsigned long flags;
- if (ichan) {
- struct dma_chan *chan = ichan-dma_chan;
- chan-device-device_control(chan, DMA_PAUSE, 0);
- }
+ if (ichan)
+ dmaengine_pause(ichan-dma_chan);
spin_lock_irqsave(mx3_cam-lock, flags);
--
1.7.0.4
--
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] platform: Fix timberdale dependencies
On Thu, Apr 03, 2014 at 11:32:06AM +0200, Jean Delvare wrote: VIDEO_TIMBERDALE selects TIMB_DMA which itself depends on MFD_TIMBERDALE, so VIDEO_TIMBERDALE should either select or depend on MFD_TIMBERDALE as well. I chose to make it depend on it because I think it makes more sense and it is consistent with what other options are doing. Adding a || HAS_IOMEM to the TIMB_DMA dependencies silenced the kconfig warning about unmet direct dependencies but it was wrong: without MFD_TIMBERDALE, TIMB_DMA is useless as the driver has no device to bind to. Applied, thanks -- ~Vinod -- 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 3/8] dma: mmp_tdma: use gen_pool_dma_alloc() to allocate descriptor
On Fri, Nov 01, 2013 at 07:48:16PM +0800, Nicolin Chen wrote: Since gen_pool_dma_alloc() is introduced, we implement it to simplify code. Acked-by: Vinod Koul vinod.k...@intel.com -- ~Vinod -- 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] [PATCH 23/51] DMA-API: dma: pl08x: add dma_set_mask_and_coherent() call
On Thu, Sep 19, 2013 at 10:48:01PM +0100, Russell King wrote:
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Vinod Koul vinod.k...@intel.com
~Vinod
---
drivers/dma/amba-pl08x.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index fce46c5..e51a983 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -2055,6 +2055,11 @@ static int pl08x_probe(struct amba_device *adev, const
struct amba_id *id)
if (ret)
return ret;
+ /* Ensure that we can do DMA */
+ ret = dma_set_mask_and_coherent(adev-dev, DMA_BIT_MASK(32));
+ if (ret)
+ goto out_no_pl08x;
+
/* Create the driver state holder */
pl08x = kzalloc(sizeof(*pl08x), GFP_KERNEL);
if (!pl08x) {
--
1.7.4.4
___
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
--
To unsubscribe from this list: send the line unsubscribe linux-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] [PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks
On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info. So lets
make that be the case. This avoids a direct reference to the DMA
masks by this driver.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Vinod Koul vinod.k...@intel.com
This also brings me question that should we force the driver to use the
dma_set_mask_and_coherent() API or they have below flexiblity too?
~Vinod
---
drivers/dma/edma.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index ff50ff4..7f9fe30 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -702,11 +702,13 @@ static struct platform_device *pdev0, *pdev1;
static const struct platform_device_info edma_dev_info0 = {
.name = edma-dma-engine,
.id = 0,
+ .dma_mask = DMA_BIT_MASK(32),
};
static const struct platform_device_info edma_dev_info1 = {
.name = edma-dma-engine,
.id = 1,
+ .dma_mask = DMA_BIT_MASK(32),
};
static int edma_init(void)
@@ -720,8 +722,6 @@ static int edma_init(void)
ret = PTR_ERR(pdev0);
goto out;
}
- pdev0-dev.dma_mask = pdev0-dev.coherent_dma_mask;
- pdev0-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
if (EDMA_CTLRS == 2) {
@@ -731,8 +731,6 @@ static int edma_init(void)
platform_device_unregister(pdev0);
ret = PTR_ERR(pdev1);
}
- pdev1-dev.dma_mask = pdev1-dev.coherent_dma_mask;
- pdev1-dev.coherent_dma_mask = DMA_BIT_MASK(32);
}
out:
--
1.7.4.4
___
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
--
To unsubscribe from this list: send the line unsubscribe linux-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] [PATCH 24/51] DMA-API: dma: pl330: add dma_set_mask_and_coherent() call
On Sat, Sep 21, 2013 at 09:00:00PM +0100, Russell King - ARM Linux wrote: On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote: Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King: The DMA API requires drivers to call the appropriate dma_set_mask() functions before doing any DMA mapping. Add this required call to the AMBA PL08x driver. ^--- copy and paste error - should of course be PL330 Fixed, thanks. with fixed changelog... Acked-by: Vinod Koul vinod.k...@intel.com ~Vinod -- -- 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 1/2] dmaengine: ipu-idmac: add support for the DMA_PAUSE control
On Thu, 2011-08-25 at 18:45 +0200, Guennadi Liakhovetski wrote:
To support multi-size buffers in the mx3_camera V4L2 driver we have to be
able to stop DMA on a channel without releasing descriptors and completely
halting the hardware. Use the DMA_PAUSE control to implement this mode.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by Vinod Koul vinod.k...@linux.intel.com
Do you want this to go thru slave-dma or media tree?
--
~Vinod
---
drivers/dma/ipu/ipu_idmac.c | 65 +++---
1 files changed, 42 insertions(+), 23 deletions(-)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index c1a125e..42cdf1c 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1306,6 +1306,7 @@ static irqreturn_t idmac_interrupt(int irq, void
*dev_id)
ipu_submit_buffer(ichan, descnew, sgnew, ichan-active_buffer) 0)
{
callback = descnew-txd.callback;
callback_param = descnew-txd.callback_param;
+ list_del_init(descnew-list);
spin_unlock(ichan-lock);
if (callback)
callback(callback_param);
@@ -1427,39 +1428,58 @@ static int __idmac_control(struct dma_chan *chan,
enum dma_ctrl_cmd cmd,
{
struct idmac_channel *ichan = to_idmac_chan(chan);
struct idmac *idmac = to_idmac(chan-device);
+ struct ipu *ipu = to_ipu(idmac);
+ struct list_head *list, *tmp;
unsigned long flags;
int i;
- /* Only supports DMA_TERMINATE_ALL */
- if (cmd != DMA_TERMINATE_ALL)
- return -ENXIO;
+ switch (cmd) {
+ case DMA_PAUSE:
+ spin_lock_irqsave(ipu-lock, flags);
+ ipu_ic_disable_task(ipu, chan-chan_id);
- ipu_disable_channel(idmac, ichan,
- ichan-status = IPU_CHANNEL_ENABLED);
+ /* Return all descriptors into prepared state */
+ list_for_each_safe(list, tmp, ichan-queue)
+ list_del_init(list);
- tasklet_disable(to_ipu(idmac)-tasklet);
+ ichan-sg[0] = NULL;
+ ichan-sg[1] = NULL;
- /* ichan-queue is modified in ISR, have to spinlock */
- spin_lock_irqsave(ichan-lock, flags);
- list_splice_init(ichan-queue, ichan-free_list);
+ spin_unlock_irqrestore(ipu-lock, flags);
- if (ichan-desc)
- for (i = 0; i ichan-n_tx_desc; i++) {
- struct idmac_tx_desc *desc = ichan-desc + i;
- if (list_empty(desc-list))
- /* Descriptor was prepared, but not submitted */
- list_add(desc-list, ichan-free_list);
+ ichan-status = IPU_CHANNEL_INITIALIZED;
+ break;
+ case DMA_TERMINATE_ALL:
+ ipu_disable_channel(idmac, ichan,
+ ichan-status = IPU_CHANNEL_ENABLED);
- async_tx_clear_ack(desc-txd);
- }
+ tasklet_disable(ipu-tasklet);
- ichan-sg[0] = NULL;
- ichan-sg[1] = NULL;
- spin_unlock_irqrestore(ichan-lock, flags);
+ /* ichan-queue is modified in ISR, have to spinlock */
+ spin_lock_irqsave(ichan-lock, flags);
+ list_splice_init(ichan-queue, ichan-free_list);
- tasklet_enable(to_ipu(idmac)-tasklet);
+ if (ichan-desc)
+ for (i = 0; i ichan-n_tx_desc; i++) {
+ struct idmac_tx_desc *desc = ichan-desc + i;
+ if (list_empty(desc-list))
+ /* Descriptor was prepared, but not
submitted */
+ list_add(desc-list,
ichan-free_list);
- ichan-status = IPU_CHANNEL_INITIALIZED;
+ async_tx_clear_ack(desc-txd);
+ }
+
+ ichan-sg[0] = NULL;
+ ichan-sg[1] = NULL;
+ spin_unlock_irqrestore(ichan-lock, flags);
+
+ tasklet_enable(ipu-tasklet);
+
+ ichan-status = IPU_CHANNEL_INITIALIZED;
+ break;
+ default:
+ return -ENOSYS;
+ }
return 0;
}
@@ -1662,7 +1682,6 @@ static void __exit ipu_idmac_exit(struct ipu *ipu)
struct idmac_channel *ichan = ipu-channel + i;
idmac_control(ichan-dma_chan, DMA_TERMINATE_ALL, 0);
- idmac_prep_slave_sg(ichan-dma_chan, NULL, 0, DMA_NONE, 0);
}
dma_async_device_unregister(idmac-dma);
--
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
