[PATCH] [media] exynos-gsc: Handle ctx job finish when aborted
When the current context is running,
1] If release() or streamoff() is called on the current context,
it waits until the job is aborted or finished.
2] If the job is finished, driver will call the v4l2_m2m_job_finish().
3] If the job is aborted inside device_run callback, then driver
has to inform the v4l2 mem2mem framework about the same by calling
v4l2_m2m_job_finish() with VB2_BUF_STATE_ERROR.
The current code doesn't call v4l2_m2m_job_finish() in the case, where
the job is aborted from the device_run callback. This scenerio is
producing a hang as the other queued contexts are not getting scheduled.
By adding the ABORT state, driver can understand the current job
is aborted and not finished. By checking this flag, driver can call
v4l2_m2m_job_finish() with VB2_BUF_STATE_ERROR.
Signed-off-by: Shaik Ameer Basha
Signed-off-by: avnd kiran
---
drivers/media/platform/exynos-gsc/gsc-core.h |1 +
drivers/media/platform/exynos-gsc/gsc-m2m.c | 29 ++
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/exynos-gsc/gsc-core.h
b/drivers/media/platform/exynos-gsc/gsc-core.h
index 76435d3..ef0a656 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.h
+++ b/drivers/media/platform/exynos-gsc/gsc-core.h
@@ -45,6 +45,7 @@
#define GSC_DST_FMT(1 << 2)
#define GSC_CTX_M2M(1 << 3)
#define GSC_CTX_STOP_REQ (1 << 6)
+#defineGSC_CTX_ABORT (1 << 7)
enum gsc_dev_flags {
/* for global */
diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c
b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index e576ff2..810c3e1 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -46,6 +46,17 @@ static int gsc_m2m_ctx_stop_req(struct gsc_ctx *ctx)
return ret == 0 ? -ETIMEDOUT : ret;
}
+static void __gsc_m2m_job_abort(struct gsc_ctx *ctx)
+{
+ int ret;
+
+ ret = gsc_m2m_ctx_stop_req(ctx);
+ if ((ret == -ETIMEDOUT) || (ctx->state & GSC_CTX_ABORT)) {
+ gsc_ctx_state_lock_clear(GSC_CTX_STOP_REQ | GSC_CTX_ABORT, ctx);
+ gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+ }
+}
+
static int gsc_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
{
struct gsc_ctx *ctx = q->drv_priv;
@@ -58,11 +69,8 @@ static int gsc_m2m_start_streaming(struct vb2_queue *q,
unsigned int count)
static int gsc_m2m_stop_streaming(struct vb2_queue *q)
{
struct gsc_ctx *ctx = q->drv_priv;
- int ret;
- ret = gsc_m2m_ctx_stop_req(ctx);
- if (ret == -ETIMEDOUT)
- gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+ __gsc_m2m_job_abort(ctx);
pm_runtime_put(&ctx->gsc_dev->pdev->dev);
@@ -91,15 +99,9 @@ void gsc_m2m_job_finish(struct gsc_ctx *ctx, int vb_state)
}
}
-
static void gsc_m2m_job_abort(void *priv)
{
- struct gsc_ctx *ctx = priv;
- int ret;
-
- ret = gsc_m2m_ctx_stop_req(ctx);
- if (ret == -ETIMEDOUT)
- gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+ __gsc_m2m_job_abort((struct gsc_ctx *)priv);
}
static int gsc_get_bufs(struct gsc_ctx *ctx)
@@ -150,9 +152,10 @@ static void gsc_m2m_device_run(void *priv)
gsc->m2m.ctx = ctx;
}
- is_set = (ctx->state & GSC_CTX_STOP_REQ) ? 1 : 0;
- ctx->state &= ~GSC_CTX_STOP_REQ;
+ is_set = ctx->state & GSC_CTX_STOP_REQ;
if (is_set) {
+ ctx->state &= ~GSC_CTX_STOP_REQ;
+ ctx->state |= GSC_CTX_ABORT;
wake_up(&gsc->irq_queue);
goto put_device;
}
--
1.7.9.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] [media] v4l2-mem2mem: Don't schedule the context if abort job is called
When the current context is running,
1] If release is called, it waits until the job is finished.
2] As soon as the job is finished, v4l2_mem_ctx_release()tries to
release the vb2 queues.
3] But if the current context can be scheduled in the v4l2_m2m_job_finish()
it schedules the context and tries to call device_run().
4] As the release() and device_run() sequence can't be predicted sometimes
device_run() may get empty vb2 buffers.
This patch adds the ABORT state to the job_flags. Once the job_abort() or
release() is called on the context, the same context will not be scheduled in
the v4l2_m2m_job_finish().
Signed-off-by: Shaik Ameer Basha
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 7c43712..d5741be 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -41,6 +41,8 @@ module_param(debug, bool, 0644);
#define TRANS_QUEUED (1 << 0)
/* Instance is currently running in hardware */
#define TRANS_RUNNING (1 << 1)
+/* Instance is currently aborting */
+#define TRANS_ABORT(1 << 2)
/* Offset base for buffers on the destination queue - used to distinguish
@@ -221,6 +223,14 @@ static void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx
*m2m_ctx)
}
spin_lock_irqsave(&m2m_dev->job_spinlock, flags_job);
+
+ /* If the context is aborted then don't schedule it */
+ if (m2m_ctx->job_flags & TRANS_ABORT) {
+ spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags_job);
+ dprintk("Aborted context\n");
+ return;
+ }
+
if (m2m_ctx->job_flags & TRANS_QUEUED) {
spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags_job);
dprintk("On job queue already\n");
@@ -280,6 +290,8 @@ static void v4l2_m2m_cancel_job(struct v4l2_m2m_ctx
*m2m_ctx)
m2m_dev = m2m_ctx->m2m_dev;
spin_lock_irqsave(&m2m_dev->job_spinlock, flags);
+
+ m2m_ctx->job_flags |= TRANS_ABORT;
if (m2m_ctx->job_flags & TRANS_RUNNING) {
spin_unlock_irqrestore(&m2m_dev->job_spinlock, flags);
m2m_dev->m2m_ops->job_abort(m2m_ctx->priv);
--
1.7.9.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 v11 0/8] PHY framework
On Fri, Sep 20, 2013 at 11:04:40AM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > On Tuesday 17 September 2013 09:11 PM, Felipe Balbi wrote: > > On Wed, Sep 04, 2013 at 02:27:06PM +0530, Kishon Vijay Abraham I wrote: > >> On Tuesday 03 September 2013 09:20 PM, Greg KH wrote: > >>> On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote: > Hi Greg, > > On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote: > > Hi, > > > > On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: > >> On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: > >>> Added a generic PHY framework that provides a set of APIs for the PHY > >>> drivers > >>> to create/destroy a PHY and APIs for the PHY users to obtain a > >>> reference to > >>> the PHY with or without using phandle. > >>> > >>> This framework will be of use only to devices that uses external PHY > >>> (PHY > >>> functionality is not embedded within the controller). > >>> > >>> The intention of creating this framework is to bring the phy drivers > >>> spread > >>> all over the Linux kernel to drivers/phy to increase code re-use and > >>> to > >>> increase code maintainability. > >>> > >>> Comments to make PHY as bus wasn't done because PHY devices can be > >>> part of > >>> other bus and making a same device attached to multiple bus leads to > >>> bad > >>> design. > >>> > >>> If the PHY driver has to send notification on connect/disconnect, the > >>> PHY > >>> driver should make use of the extcon framework. Using this susbsystem > >>> to use extcon framwork will have to be analysed. > >>> > >>> You can find this patch series @ > >>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git > >>> testing > >> > >> Looks like there are not further comments on this series. Can you take > >> this in > >> your misc tree? > > > > Do you want me to queue these for you ? There are quite a few users for > > this framework already and I know of at least 2 others which will show > > up for v3.13. > > Can you queue this patch series? There are quite a few users already for > this > framework. > >>> > >>> It will have to wait for 3.13 as the merge window for new features has > >>> been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1 > >>> is out. > >> > >> Alright, thanks. > > > > Just a gentle ping on this one... > > Let me know if you want me to rebase this patch series on the latest mainline > HEAD. Yes please. -- 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 v11 0/8] PHY framework
Hi Greg, On Tuesday 17 September 2013 09:11 PM, Felipe Balbi wrote: > On Wed, Sep 04, 2013 at 02:27:06PM +0530, Kishon Vijay Abraham I wrote: >> On Tuesday 03 September 2013 09:20 PM, Greg KH wrote: >>> On Tue, Sep 03, 2013 at 08:55:23PM +0530, Kishon Vijay Abraham I wrote: Hi Greg, On Wednesday 28 August 2013 12:50 AM, Felipe Balbi wrote: > Hi, > > On Mon, Aug 26, 2013 at 01:44:49PM +0530, Kishon Vijay Abraham I wrote: >> On Wednesday 21 August 2013 11:16 AM, Kishon Vijay Abraham I wrote: >>> Added a generic PHY framework that provides a set of APIs for the PHY >>> drivers >>> to create/destroy a PHY and APIs for the PHY users to obtain a >>> reference to >>> the PHY with or without using phandle. >>> >>> This framework will be of use only to devices that uses external PHY >>> (PHY >>> functionality is not embedded within the controller). >>> >>> The intention of creating this framework is to bring the phy drivers >>> spread >>> all over the Linux kernel to drivers/phy to increase code re-use and to >>> increase code maintainability. >>> >>> Comments to make PHY as bus wasn't done because PHY devices can be part >>> of >>> other bus and making a same device attached to multiple bus leads to bad >>> design. >>> >>> If the PHY driver has to send notification on connect/disconnect, the >>> PHY >>> driver should make use of the extcon framework. Using this susbsystem >>> to use extcon framwork will have to be analysed. >>> >>> You can find this patch series @ >>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git >>> testing >> >> Looks like there are not further comments on this series. Can you take >> this in >> your misc tree? > > Do you want me to queue these for you ? There are quite a few users for > this framework already and I know of at least 2 others which will show > up for v3.13. Can you queue this patch series? There are quite a few users already for this framework. >>> >>> It will have to wait for 3.13 as the merge window for new features has >>> been closed for a week or so. Sorry, I'll queue this up after 3.12-rc1 >>> is out. >> >> Alright, thanks. > > Just a gentle ping on this one... Let me know if you want me to rebase this patch series on the latest mainline HEAD. Thanks Kishon -- 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Sep 20 04:00:15 CEST 2013 git branch: test git hash: f66b2a1c7f2ae3fb0d5b67d07ab4f5055fd3cf16 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.10.1 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.10.1-i686: OK linux-3.1.10-i686: OK linux-3.11.1-i686: OK linux-3.12-rc1-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.10.1-x86_64: OK linux-3.1.10-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-rc1-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK apps: WARNINGS spec-git: OK ABI WARNING: change for arm-at91 ABI WARNING: change for arm-davinci ABI WARNING: change for arm-exynos ABI WARNING: change for arm-mx ABI WARNING: change for arm-omap ABI WARNING: change for arm-omap1 ABI WARNING: change for arm-pxa ABI WARNING: change for blackfin ABI WARNING: change for i686 ABI WARNING: change for m32r ABI WARNING: change for mips ABI WARNING: change for powerpc64 ABI WARNING: change for sh ABI WARNING: change for x86_64 sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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 40/51] DMA-API: crypto: fix ixp4xx crypto platform device support
Don't statically allocate struct device's in modules, and shut the
warning up with an empty release() function. There's a reason that
warning is there and that's not for people to hide in this way. It's
there to persuade people to use the correct APIs to allocate platform
devices.
Signed-off-by: Russell King
---
drivers/crypto/ixp4xx_crypto.c | 37 +
1 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 21180d6..8306185 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -218,23 +218,10 @@ static dma_addr_t crypt_phys;
static int support_aes = 1;
-static void dev_release(struct device *dev)
-{
- return;
-}
-
#define DRIVER_NAME "ixp4xx_crypto"
-static struct platform_device pseudo_dev = {
- .name = DRIVER_NAME,
- .id = 0,
- .num_resources = 0,
- .dev = {
- .coherent_dma_mask = DMA_BIT_MASK(32),
- .release = dev_release,
- }
-};
-static struct device *dev = &pseudo_dev.dev;
+static struct platform_device *pdev;
+static struct device *dev;
static inline dma_addr_t crypt_virt2phys(struct crypt_ctl *virt)
{
@@ -1418,20 +1405,30 @@ static struct ixp_alg ixp4xx_algos[] = {
} };
#define IXP_POSTFIX "-ixp4xx"
+
+static const struct platform_device_info ixp_dev_info __initdata = {
+ .name = DRIVER_NAME,
+ .id = 0,
+ .dma_mask = DMA_BIT_MASK(32),
+};
+
static int __init ixp_module_init(void)
{
int num = ARRAY_SIZE(ixp4xx_algos);
- int i,err ;
+ int i, err ;
- if (platform_device_register(&pseudo_dev))
- return -ENODEV;
+ pdev = platform_device_register_full(&ixp_dev_info);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ dev = &pdev->dev;
spin_lock_init(&desc_lock);
spin_lock_init(&emerg_lock);
err = init_ixp_crypto();
if (err) {
- platform_device_unregister(&pseudo_dev);
+ platform_device_unregister(pdev);
return err;
}
for (i=0; i< num; i++) {
@@ -1496,7 +1493,7 @@ static void __exit ixp_module_exit(void)
crypto_unregister_alg(&ixp4xx_algos[i].crypto);
}
release_ixp_crypto();
- platform_device_unregister(&pseudo_dev);
+ platform_device_unregister(pdev);
}
module_init(ixp_module_init);
--
1.7.4.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
[PATCH 41/51] DMA-API: crypto: remove last references to 'static struct device *dev'
Signed-off-by: Russell King
---
drivers/crypto/ixp4xx_crypto.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/ixp4xx_crypto.c b/drivers/crypto/ixp4xx_crypto.c
index 8306185..214357e 100644
--- a/drivers/crypto/ixp4xx_crypto.c
+++ b/drivers/crypto/ixp4xx_crypto.c
@@ -221,7 +221,6 @@ static int support_aes = 1;
#define DRIVER_NAME "ixp4xx_crypto"
static struct platform_device *pdev;
-static struct device *dev;
static inline dma_addr_t crypt_virt2phys(struct crypt_ctl *virt)
{
@@ -250,6 +249,7 @@ static inline const struct ix_hash_algo *ix_hash(struct
crypto_tfm *tfm)
static int setup_crypt_desc(void)
{
+ struct device *dev = &pdev->dev;
BUILD_BUG_ON(sizeof(struct crypt_ctl) != 64);
crypt_virt = dma_alloc_coherent(dev,
NPE_QLEN * sizeof(struct crypt_ctl),
@@ -350,6 +350,7 @@ static void finish_scattered_hmac(struct crypt_ctl *crypt)
static void one_packet(dma_addr_t phys)
{
+ struct device *dev = &pdev->dev;
struct crypt_ctl *crypt;
struct ixp_ctx *ctx;
int failed;
@@ -419,7 +420,7 @@ static void crypto_done_action(unsigned long arg)
tasklet_schedule(&crypto_done_tasklet);
}
-static int init_ixp_crypto(void)
+static int init_ixp_crypto(struct device *dev)
{
int ret = -ENODEV;
u32 msg[2] = { 0, 0 };
@@ -506,7 +507,7 @@ static int init_ixp_crypto(void)
return ret;
}
-static void release_ixp_crypto(void)
+static void release_ixp_crypto(struct device *dev)
{
qmgr_disable_irq(RECV_QID);
tasklet_kill(&crypto_done_tasklet);
@@ -873,6 +874,7 @@ static int ablk_perform(struct ablkcipher_request *req, int
encrypt)
enum dma_data_direction src_direction = DMA_BIDIRECTIONAL;
struct ablk_ctx *req_ctx = ablkcipher_request_ctx(req);
struct buffer_desc src_hook;
+ struct device *dev = &pdev->dev;
gfp_t flags = req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP ?
GFP_KERNEL : GFP_ATOMIC;
@@ -997,6 +999,7 @@ static int aead_perform(struct aead_request *req, int
encrypt,
unsigned int cryptlen;
struct buffer_desc *buf, src_hook;
struct aead_ctx *req_ctx = aead_request_ctx(req);
+ struct device *dev = &pdev->dev;
gfp_t flags = req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP ?
GFP_KERNEL : GFP_ATOMIC;
@@ -1426,7 +1429,7 @@ static int __init ixp_module_init(void)
spin_lock_init(&desc_lock);
spin_lock_init(&emerg_lock);
- err = init_ixp_crypto();
+ err = init_ixp_crypto(&pdev->dev);
if (err) {
platform_device_unregister(pdev);
return err;
@@ -1492,7 +1495,7 @@ static void __exit ixp_module_exit(void)
if (ixp4xx_algos[i].registered)
crypto_unregister_alg(&ixp4xx_algos[i].crypto);
}
- release_ixp_crypto();
+ release_ixp_crypto(&pdev->dev);
platform_device_unregister(pdev);
}
--
1.7.4.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
[PATCH 44/51] DMA-API: dcdbas: update DMA mask handing
dcdbas was explicitly initializing DMA masks thusly:
dcdbas_pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
dcdbas_pdev->dev.dma_mask = &dcdbas_pdev->dev.coherent_dma_mask;
which bypasses the architecture check. Moreover, it is creating the
dcdbas_pdev device itself, and using the platform_device_register_full()
avoids some of this explicit initialization.
Convert the driver to use platform_device_register_full(), and as it
makes use of coherent DMA, also call dma_set_coherent_mask() to ensure
that the architecture gets to check the mask.
Signed-off-by: Russell King
---
drivers/firmware/dcdbas.c | 23 ---
1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index ff080ee..a85fda2 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -549,8 +549,9 @@ static int dcdbas_probe(struct platform_device *dev)
* BIOS SMI calls require buffer addresses be in 32-bit address space.
* This is done by setting the DMA mask below.
*/
- dcdbas_pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
- dcdbas_pdev->dev.dma_mask = &dcdbas_pdev->dev.coherent_dma_mask;
+ error = dma_set_coherent_mask(&dcdbas_pdev->dev, DMA_BIT_MASK(32));
+ if (error)
+ return error;
error = sysfs_create_group(&dev->dev.kobj, &dcdbas_attr_group);
if (error)
@@ -581,6 +582,12 @@ static struct platform_driver dcdbas_driver = {
.remove = dcdbas_remove,
};
+static const struct platform_device_info dcdbas_dev_info __initdata = {
+ .name = DRIVER_NAME,
+ .id = -1,
+ .dma_mask = DMA_BIT_MASK(32),
+};
+
/**
* dcdbas_init: initialize driver
*/
@@ -592,20 +599,14 @@ static int __init dcdbas_init(void)
if (error)
return error;
- dcdbas_pdev = platform_device_alloc(DRIVER_NAME, -1);
- if (!dcdbas_pdev) {
- error = -ENOMEM;
+ dcdbas_pdev = platform_device_register_full(&dcdbas_dev_info);
+ if (IS_ERR(dcdbas_pdev)) {
+ error = PTR_ERR(dcdbas_pdev);
goto err_unregister_driver;
}
- error = platform_device_add(dcdbas_pdev);
- if (error)
- goto err_free_device;
-
return 0;
- err_free_device:
- platform_device_put(dcdbas_pdev);
err_unregister_driver:
platform_driver_unregister(&dcdbas_driver);
return error;
--
1.7.4.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
[PATCH 43/51] DMA-API: dma: edma.c: no need to explicitly initialize DMA masks
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
---
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
--
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 35/51] DMA-API: parport: parport_pc.c: use dma_coerce_mask_and_coherent()
The code sequence:
dev->coherent_dma_mask = DMA_BIT_MASK(24);
dev->dma_mask = &dev->coherent_dma_mask;
bypasses the architectures check on the DMA mask. It can be replaced
with dma_coerce_mask_and_coherent(), avoiding the direct initialization
of this mask.
Signed-off-by: Russell King
---
drivers/parport/parport_pc.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 903e128..9637615 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -2004,6 +2004,7 @@ struct parport *parport_pc_probe_port(unsigned long int
base,
struct resource *ECR_res = NULL;
struct resource *EPP_res = NULL;
struct platform_device *pdev = NULL;
+ int ret;
if (!dev) {
/* We need a physical device to attach to, but none was
@@ -2014,8 +2015,11 @@ struct parport *parport_pc_probe_port(unsigned long int
base,
return NULL;
dev = &pdev->dev;
- dev->coherent_dma_mask = DMA_BIT_MASK(24);
- dev->dma_mask = &dev->coherent_dma_mask;
+ ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(24));
+ if (ret) {
+ dev_err(dev, "Unable to set coherent dma mask:
disabling DMA\n");
+ dma = PARPORT_DMA_NONE;
+ }
}
ops = kmalloc(sizeof(struct parport_operations), GFP_KERNEL);
--
1.7.4.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 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote: > Provide a helper to set both the DMA and coherent DMA masks to the > same value - this avoids duplicated code in a number of drivers, > sometimes with buggy error handling, and also allows us identify > which drivers do things differently. > > Signed-off-by: Russell King > --- > Documentation/DMA-API-HOWTO.txt | 37 ++--- > Documentation/DMA-API.txt |8 > include/linux/dma-mapping.h | 14 ++ > 3 files changed, 44 insertions(+), 15 deletions(-) > > diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt > index 14129f1..5e98303 100644 > --- a/Documentation/DMA-API-HOWTO.txt > +++ b/Documentation/DMA-API-HOWTO.txt [...] > -dma_set_coherent_mask() will always be able to set the same or a > -smaller mask as dma_set_mask(). However for the rare case that a > +The coherent coherent mask will always be able to set the same or a > +smaller mask as the streaming mask. However for the rare case that a [...] The new wording doesn't make sense; a mask doesn't set itself. I would suggest: "The coherent mask can always be set to the same or a smaller mask than the streaming mask." Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. -- 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
[stable] Re: Dependency bug in the uvcvideo Kconfig
On 09/19/13 13:17, Randy Dunlap wrote: > On 09/18/13 20:44, Jeff P. Zacher wrote: >> >> >> You are correct that this problem shown in the forum was in 3.5.4. However, >> I am >> having wither the same or similar problem in 3.10.7. >> Here is the broken config file, saved as .config-bad >> > > The failing kernel config file is attached. For Linux 3.10.x: This is already fixed in mainline but patches need to be backported. Specifically these 2 commits (in this order): commit a0f9354b1a319cb29c331bfd2e5a15d7f9b87fa4 Author: Randy Dunlap Date: Wed May 8 17:28:13 2013 -0300 [media] media/usb: fix kconfig dependencies and commit 5077ac3b8108007f4a2b4589f2d373cf55453206 Author: Mauro Carvalho Chehab Date: Wed May 22 11:25:52 2013 -0300 Properly handle tristate dependencies on USB/PCI menus >> >> >> >> >> On Wednesday, September 18, 2013 03:52:36 PM you wrote: >> >>> On 09/18/13 08:37, Peter Senna Tschudin wrote: >> Hi Randy, >> >> I've tried to download the .config file from the link on the forum, >> but it tries to install something in my browser and the file is not >> downloadable for me. Can you provide it over an simpler interface such >> as pastebin.com? >> >> Thanks >> >>> >> >>> The original poster (Jeff) should have mentioned that is is a build bug >> >>> problem in Linux 3.5.4. Jeff, have you tried 3.5.7? I expect that this >> >>> problem is already fixed, if not in 3.5.x then in some later kernel >> >>> version. >> >>> >> >>> Jeff, also please provide the kernel .config file as an attachment here >> >>> since the one posted in the forum does not download (or has been deleted). >> On Wed, Sep 18, 2013 at 4:59 PM, Randy Dunlap wrote: >> > [adding linux-media mailing list] >> > >> > On 09/18/13 06:18, Jeff P. Zacher wrote: >> >> Not subscribed, please CC'me in replies: >> >> >> >> There seems to be a dependency bug in the Kconfig for the uvcvideo >> >> kernel >> >> module. If uvcvideo is built in and usb support is built as a module, >> >> the >> >> kernel build will fail with the obviously missing dependanies. >> >> >> >> >> >> Error logs: >> >> >> >> * ERROR: Failed to compile the "bzImage" target... >> >> * >> >> * -- Grepping log... -- >> >> * >> >> * SHIPPED scripts/genksyms/keywords.hash.c >> >> * SHIPPED scripts/genksyms/parse.tab.h >> >> * SHIPPED scripts/genksyms/parse.tab.c >> >> * HOSTCC scripts/genksyms/lex.lex.o >> >> *scripts/genksyms/lex.lex.c_shipped: In function ‘yylex1’: >> >> *scripts/genksyms/lex.lex.c_shipped:904:1: warning: ignoring return >> >> value of ‘fwrite’, declared with attribute warn_unused_result >> >> [-Wunused-result] *-- >> >> * CC drivers/video/console/font_8x16.o >> >> * CC drivers/video/console/softcursor.o >> >> * CC sound/core/seq/seq_memory.o >> >> * CC drivers/video/console/fbcondecor.o >> >> * CC sound/core/seq/seq_queue.o >> >> *drivers/video/console/fbcondecor.c:511:6: warning: function declaration >> >> isn’t a prototype [-Wstrict-prototypes] >> >> *-- >> >> *(.text+0xf8fb1): undefined reference to `usb_submit_urb' >> >> *drivers/built-in.o: In function `uvc_init': >> >> *uvc_driver.c:(.init.text+0x908a): undefined reference to >> >> `usb_register_driver' >> >> *drivers/built-in.o: In function `uvc_cleanup': >> >> *uvc_driver.c:(.exit.text+0x67e): undefined reference to >> >> `usb_deregister' >> >> *make: *** [vmlinux] Error 1 >> >> *-- >> >> * Running with options: --lvm --menuconfig all >> >> * Using genkernel.conf from /etc/genkernel.conf >> >> * Sourcing arch-specific config.sh from >> >> /usr/share/genkernel/arch/x86_64/config.sh .. >> >> * Sourcing arch-specific modules_load from >> >> /usr/share/genkernel/arch/x86_64/modules_load .. >> >> * >> >> * ERROR: Failed to compile the "bzImage" target... >> >> * >> >> * -- End log... -- >> >> >> >> Compiling uvc as a module allows the compilation to complete. >> >> >> >> Platform x86_64 >> >> >> >> Ref: http://forums.gentoo.org/viewtopic-p-7398782.html#7398782 -- ~Randy -- 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/51] DMA-API: net: intel/ixgbevf: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(&pdev->dev, "No usable DMA "
"configuration, aborting\n");
goto err_dma;
}
}
pci_using_dac = 0;
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 59a62bb..e34c2da 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -3326,19 +3326,14 @@ static int ixgbevf_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (err)
return err;
- if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
- !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(&pdev->dev, "No usable DMA "
- "configuration, aborting\n");
- goto err_dma;
- }
+ dev_err(&pdev->dev, "No usable DMA "
+ "configuration, aborting\n");
+ goto err_dma;
}
pci_using_dac = 0;
}
--
1.7.4.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
[PATCH 04/51] DMA-API: net: intel/igb: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(&pdev->dev,
"No usable DMA configuration,
aborting\n");
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King
---
drivers/net/ethernet/intel/igb/igb_main.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index 8cf44f2..7579383 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -2034,21 +2034,15 @@ static int igb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(&pdev->dev,
- "No usable DMA configuration,
aborting\n");
- goto err_dma;
- }
+ dev_err(&pdev->dev,
+ "No usable DMA configuration, aborting\n");
+ goto err_dma;
}
}
--
1.7.4.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
[PATCH 07/51] DMA-API: net: intel/ixgbe: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(&pdev->dev,
"No usable DMA configuration,
aborting\n");
goto err_dma;
}
}
pci_using_dac = 0;
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 7aba452..b1dc844 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -7475,19 +7475,14 @@ static int ixgbe_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (err)
return err;
- if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
- !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(&pdev->dev,
- "No usable DMA configuration,
aborting\n");
- goto err_dma;
- }
+ dev_err(&pdev->dev,
+ "No usable DMA configuration, aborting\n");
+ goto err_dma;
}
pci_using_dac = 0;
}
--
1.7.4.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
[PATCH 06/51] DMA-API: net: intel/ixgb: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err) {
pr_err("No usable DMA configuration,
aborting\n");
goto err_dma_mask;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King
---
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 +---
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index 9f6b236..57e390c 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -408,20 +408,14 @@ ixgb_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err) {
- pr_err("No usable DMA configuration,
aborting\n");
- goto err_dma_mask;
- }
+ pr_err("No usable DMA configuration, aborting\n");
+ goto err_dma_mask;
}
}
--
1.7.4.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
[PATCH 05/51] DMA-API: net: intel/igbvf: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(&pdev->dev, "No usable DMA "
"configuration, aborting\n");
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King
---
drivers/net/ethernet/intel/igbvf/netdev.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c
b/drivers/net/ethernet/intel/igbvf/netdev.c
index 93eb7ee..4e6b02f 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -2638,21 +2638,15 @@ static int igbvf_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(&pdev->dev, "No usable DMA "
- "configuration, aborting\n");
- goto err_dma;
- }
+ dev_err(&pdev->dev, "No usable DMA "
+ "configuration, aborting\n");
+ goto err_dma;
}
}
--
1.7.4.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
[PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
Provide a helper to set both the DMA and coherent DMA masks to the
same value - this avoids duplicated code in a number of drivers,
sometimes with buggy error handling, and also allows us identify
which drivers do things differently.
Signed-off-by: Russell King
---
Documentation/DMA-API-HOWTO.txt | 37 ++---
Documentation/DMA-API.txt |8
include/linux/dma-mapping.h | 14 ++
3 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 14129f1..5e98303 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -101,14 +101,23 @@ style to do this even if your device holds the default
setting,
because this shows that you did think about these issues wrt. your
device.
-The query is performed via a call to dma_set_mask():
+The query is performed via a call to dma_set_mask_and_coherent():
- int dma_set_mask(struct device *dev, u64 mask);
+ int dma_set_mask_and_coherent(struct device *dev, u64 mask);
-The query for consistent allocations is performed via a call to
-dma_set_coherent_mask():
+which will query the mask for both streaming and coherent APIs together.
+If you have some special requirements, then the following two separate
+queries can be used instead:
- int dma_set_coherent_mask(struct device *dev, u64 mask);
+ The query for streaming mappings is performed via a call to
+ dma_set_mask():
+
+ int dma_set_mask(struct device *dev, u64 mask);
+
+ The query for consistent allocations is performed via a call
+ to dma_set_coherent_mask():
+
+ int dma_set_coherent_mask(struct device *dev, u64 mask);
Here, dev is a pointer to the device struct of your device, and mask
is a bit mask describing which bits of an address your device
@@ -137,7 +146,7 @@ exactly why.
The standard 32-bit addressing device would do something like this:
- if (dma_set_mask(dev, DMA_BIT_MASK(32))) {
+ if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
printk(KERN_WARNING
"mydev: No suitable DMA available.\n");
goto ignore_this_device;
@@ -171,22 +180,20 @@ If a card is capable of using 64-bit consistent
allocations as well,
int using_dac, consistent_using_dac;
- if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
using_dac = 1;
consistent_using_dac = 1;
- dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
- } else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
+ } else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
using_dac = 0;
consistent_using_dac = 0;
- dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
} else {
printk(KERN_WARNING
"mydev: No suitable DMA available.\n");
goto ignore_this_device;
}
-dma_set_coherent_mask() will always be able to set the same or a
-smaller mask as dma_set_mask(). However for the rare case that a
+The coherent coherent mask will always be able to set the same or a
+smaller mask as the streaming mask. However for the rare case that a
device driver only uses consistent allocations, one would have to
check the return value from dma_set_coherent_mask().
@@ -199,9 +206,9 @@ Finally, if your device can only drive the low 24-bits of
goto ignore_this_device;
}
-When dma_set_mask() is successful, and returns zero, the kernel saves
-away this mask you have provided. The kernel will use this
-information later when you make DMA mappings.
+When dma_set_mask() or dma_set_mask_and_coherent() is successful, and
+returns zero, the kernel saves away this mask you have provided. The
+kernel will use this information later when you make DMA mappings.
There is a case which we are aware of at this time, which is worth
mentioning in this documentation. If your device supports multiple
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 78a6c56..e865279 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -142,6 +142,14 @@ internal API for use by the platform than an external API
for use by
driver writers.
int
+dma_set_mask_and_coherent(struct device *dev, u64 mask)
+
+Checks to see if the mask is possible and updates the device
+streaming and coherent DMA mask parameters if it is.
+
+Returns: 0 if successful and a negative error if not.
+
+int
dma_set_mask(struct device *dev, u64 mask)
Checks to see if the mask is possible and updates the device
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 3a8d0a2..ec951f9 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -97,6 +97,20 @@ static inline int dma_set_coheren
[PATCH 03/51] DMA-API: net: intel/e1000e: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
if (!err)
pci_using_dac = 1;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err) {
dev_err(&pdev->dev,
"No usable DMA configuration,
aborting\n");
goto err_dma;
}
}
}
This means we only set the coherent DMA mask in the fallback path if
the DMA mask set failed, which is silly. This fixes it to set the
coherent DMA mask only if dma_set_mask() succeeded, and to error out
if either fails.
Signed-off-by: Russell King
---
drivers/net/ethernet/intel/e1000e/netdev.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index e87e9b0..519e293 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6553,21 +6553,15 @@ static int e1000_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
return err;
pci_using_dac = 0;
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(64));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
if (!err) {
- err = dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64));
- if (!err)
- pci_using_dac = 1;
+ pci_using_dac = 1;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err) {
- dev_err(&pdev->dev,
- "No usable DMA configuration,
aborting\n");
- goto err_dma;
- }
+ dev_err(&pdev->dev,
+ "No usable DMA configuration, aborting\n");
+ goto err_dma;
}
}
--
1.7.4.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
[PATCH 02/51] DMA-API: net: brocade/bna/bnad.c: fix 32-bit DMA mask handling
The fallback to 32-bit DMA mask is rather odd:
if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
!dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
if (err) {
err = dma_set_coherent_mask(&pdev->dev,
DMA_BIT_MASK(32));
if (err)
goto release_regions;
}
This means we only try and set the coherent DMA mask if we failed to
set a 32-bit DMA mask, and only if both fail do we fail the driver.
Adjust this so that if either setting fails, we fail the driver - and
thereby end up properly setting both the DMA mask and the coherent
DMA mask in the fallback case.
Signed-off-by: Russell King
---
drivers/net/ethernet/brocade/bna/bnad.c | 13 -
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c
b/drivers/net/ethernet/brocade/bna/bnad.c
index b78e69e..45ce6e2 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -3300,17 +3300,12 @@ bnad_pci_init(struct bnad *bnad,
err = pci_request_regions(pdev, BNAD_NAME);
if (err)
goto disable_device;
- if (!dma_set_mask(&pdev->dev, DMA_BIT_MASK(64)) &&
- !dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64))) {
+ if (!dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
*using_dac = true;
} else {
- err = dma_set_mask(&pdev->dev, DMA_BIT_MASK(32));
- if (err) {
- err = dma_set_coherent_mask(&pdev->dev,
- DMA_BIT_MASK(32));
- if (err)
- goto release_regions;
- }
+ err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
+ if (err)
+ goto release_regions;
*using_dac = false;
}
pci_set_master(pdev);
--
1.7.4.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
[PATCH 00/51] DMA mask changes
This started out as a request to look at the DMA mask situation, and how to solve the issues which we have on ARM - notably how the DMA mask should be setup. However, I started off reviewing how the dma_mask and coherent_dma_mask was being used, and what I found was rather messy, and in some cases rather buggy. I tried to get some of the bug fixes in before the last merge window, but it seems that the maintainers preferred to have the full solution rather than a simple -rc suitable bug fix. So, this is an attempt to clean things up. The first point here is that drivers performing DMA should be calling dma_set_mask()/dma_set_coherent_mask() in their probe function to verify that DMA can be performed. Lots of ARM drivers omit this step; please refer to the DMA API documentation on this subject. What this means is that the DMA mask provided by bus code is a default value - nothing more. It doesn't have to accurately reflect what the device is actually capable of. Apart from the storage for dev->dma_mask being initialised for any device which is DMA capable, there is no other initialisation which is strictly necessary at device creation time. Now, these cleanups address two major areas: 1. The setting of DMA masks, particularly when both the coherent and streaming DMA masks are set together. 2. The initialisation of DMA masks by drivers - this seems to be becoming a popular habbit, one which may not be entirely the right solution. Rather than having this scattered throughout the tree, I've pulled that into a central location (and called it coercing the DMA mask - because it really is about forcing the DMA mask to be that value.) 3. Finally, addressing the long held misbelief that DMA masks somehow correspond with physical addresses. We already have established long ago that dma_addr_t values returned from the DMA API are the values which you program into the DMA controller, and so are the bus addresses. It is _only_ sane that DMA masks are also bus related too, and not related to physical address spaces. (3) is a very important point for LPAE systems, which may still have less than 4GB of memory, but this memory is all located above the 4GB physical boundary. This means with the current model, any device using a 32-bit DMA mask fails - even though the DMA controller is still only a 32-bit DMA controller but the 32-bit bus addresses map to system memory. To put it another way, the bus addresses have a 4GB physical offset on them. This email is only being sent to the mailing lists in question, not to anyone personally. The list of individuals is far to great to do that. I'm hoping no mailing lists reject the patches based on the number of recipients. Patches based on v3.12-rc1. Documentation/DMA-API-HOWTO.txt | 37 +-- Documentation/DMA-API.txt |8 +++ arch/arm/include/asm/dma-mapping.h|8 +++ arch/arm/mm/dma-mapping.c | 49 ++-- arch/arm/mm/init.c| 12 +++--- arch/arm/mm/mm.h |2 + arch/powerpc/kernel/vio.c |3 +- block/blk-settings.c |8 ++-- drivers/amba/bus.c|6 +-- drivers/ata/pata_ixp4xx_cf.c |5 ++- drivers/ata/pata_octeon_cf.c |5 +- drivers/block/nvme-core.c | 10 ++--- drivers/crypto/ixp4xx_crypto.c| 48 ++-- drivers/dma/amba-pl08x.c |5 ++ drivers/dma/dw/platform.c |8 +-- drivers/dma/edma.c|6 +-- drivers/dma/pl330.c |4 ++ drivers/firmware/dcdbas.c | 23 +- drivers/firmware/google/gsmi.c| 13 +++-- drivers/gpu/drm/exynos/exynos_drm_drv.c |6 ++- drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |5 +- drivers/media/platform/omap3isp/isp.c |6 +- drivers/media/platform/omap3isp/isp.h |3 - drivers/mmc/card/queue.c |3 +- drivers/mmc/host/sdhci-acpi.c |5 +- drivers/net/ethernet/broadcom/b44.c |3 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |8 +--- drivers/net/ethernet/brocade/bna/bnad.c | 13 ++ drivers/net/ethernet/emulex/benet/be_main.c | 12 + drivers/net/ethernet/intel/e1000/e1000_main.c |9 +--- drivers/net/ethernet/intel/e1000e/netdev.c| 18 +++- drivers/net/ethernet/intel/igb/igb_main.c | 18 +++- drivers/net/ethernet/intel/igbvf/netdev.c | 18 +++- drivers/net/ethernet/intel/ixgb/ixgb_main.c | 16 ++- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
Re: [PATCH] media: i2c: adv7343: fix the DT binding properties
On 09/19/2013 06:06 PM, Prabhakar Lad wrote: On Mon, Sep 16, 2013 at 9:54 PM, Stephen Warren wrote: On 09/13/2013 11:23 PM, Prabhakar Lad wrote: On Sat, Sep 14, 2013 at 4:16 AM, Stephen Warren wrote: On 09/13/2013 05:57 AM, Prabhakar Lad wrote: From: "Lad, Prabhakar" This patch fixes the DT binding properties of adv7343 decoder. The pdata which was being read from the DT property, is removed as this can done internally in the driver using cable detection register. This patch also removes the pdata of ADV7343 which was passed from DA850 machine. diff --git a/Documentation/devicetree/bindings/media/i2c/adv7343.txt b/Documentation/devicetree/bindings/media/i2c/adv7343.txt Required Properties : - compatible: Must be "adi,adv7343" +- reg: I2C device address. +- vddio-supply: I/O voltage supply. +- vddcore-supply: core voltage supply. +- vaa-supply: Analog power supply. +- pvdd-supply: PLL power supply. Old DTs won't contain those properties. This breaks the DT ABI if those properties are required. Is that acceptable? As of now adv7343 via DT binding is not enabled in any platforms so this wont break any DT ABI. Well, if the binding has already been written, it technically already is an ABI. Perhaps the binding can be fixed if it isn't in use yet, but this is definitely not the correct approach to DT. The binding got merged for 3.12-rc1 and the intention of this patch was to correct that binding. There we some issues like mismatch between names of properties documented and used in the driver. After Mark's suggestion Prabhakar removed some properties and the platform data usage altogether. IMHO there should be only minimal changes in that "fixup" patch, i.e. no platform data usage should be removed. Perhaps it is fine since that's just code removal. I guess it is better to do this sort of cleanup for the next kernel release. Also I believe the argument of backward compatibility shouldn't really be considered here. The $subject patch is supposed to correct the binding before it becomes and ABI. If it is, I think we should document that older versions of the binding didn't require those properties, so they may in fact be missing. I note that this patch doesn't actually update the driver to regulator_get() anything. Shouldn't it? As of now the driver isn’t enabling/accepting the regulators, so should I add those in DT properties or not ? The binding should describe the HW, not what the driver does/doesn't yet do. I wrote the above because it looked like the driver was broken, not to encourage you to remove properties from the binding. OK How does the driver work if it doesn't enable the required regulators though, I wonder? I suppose the boards this driver has been tested on all must used fixed (non-SW-controlled) regulators. on all the boards on which this decoder is connected the power to it is provided by static circuit and not by regulators, So for this how would you suggest to add the DT nodes for regulators ? I believe the regulator DT properties should be made optional. Since some (actually all upstream) boards don't bother with software controlled regulators. We might have specified them and have defined relevant fixed regulator(s) in DT. But I doubt it is sensible, given that it may never happen in practice the regulators are required to be controlled by software through the regulators API. Such devices can often be put in a low power mode by a write to one of the registers, where their supply current is at uA level. Looking at the datasheet ADV7343 has SLEEP_MODE in which its typical current consumption is 5 uA. That said the chip could be supplied from shared voltage regulators and the driver would then have to properly request and enable the regulators. Anyway I'm inclined to make the regulator properties optional. -- Thanks, Sylwester -- 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: Easycap DC60 stk1160 driver
On Thu, Sep 19, 2013 at 05:29:42PM +0200, C. Bassa wrote: > Hi Ezequiel and Andrew, > > Andrew replied to my request on his easycap forum, so I'll answer you both > here. > > On Thu, Sep 19, 2013 at 2:39 PM, Ezequiel Garcia > wrote: > > If you have any chance to test a v3.11 or later kernel, please report > > let me know if this is your problem or there's something new going on. > > I'm running Xubuntu 13.10 live and stk1160 recognizes the device and > cheese and ffmpeg show the video. Unfortunately the frames are garbled > as if the size of the frames is wrong. Do you know of this problem and > a possible fix for it? > Hm, easycap and stk1160 are completely different drivers. So any parameters you were using might need some re-check. Could you try mplayer and post your command line and your results? Do you see an *all* green frame or just a garbled frame? Can you upload a snapshot somewhere? > > Also, if you can crack open (carefully) your easycap and check the > > encoder is gm7113 then that confirms you need either a newer kernel > > or request Ubuntu people to backport the fix (it's really very easy). > > Yes, it indeed uses the gm7113 encoder, so the new kernel is necessary. > > Would it be possible, or at all advisable, to try to compile the > easycap driver from Ubuntu 12.04 on the newer kernels? > I guess you can try to build easycap and see if it works. If you've been using it all this time without problems, then you can keep on using it. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- 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: i2c: adv7343: fix the DT binding properties
Hi Stephen, On Mon, Sep 16, 2013 at 9:54 PM, Stephen Warren wrote: > On 09/13/2013 11:23 PM, Prabhakar Lad wrote: >> Hi Stephen, >> >> This patch should have been marked as RFC. >> >> Thanks for the review. >> >> On Sat, Sep 14, 2013 at 4:16 AM, Stephen Warren >> wrote: >>> On 09/13/2013 05:57 AM, Prabhakar Lad wrote: From: "Lad, Prabhakar" This patch fixes the DT binding properties of adv7343 decoder. The pdata which was being read from the DT property, is removed as this can done internally in the driver using cable detection register. This patch also removes the pdata of ADV7343 which was passed from DA850 machine. >>> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7343.txt b/Documentation/devicetree/bindings/media/i2c/adv7343.txt >>> Required Properties : - compatible: Must be "adi,adv7343" +- reg: I2C device address. +- vddio-supply: I/O voltage supply. +- vddcore-supply: core voltage supply. +- vaa-supply: Analog power supply. +- pvdd-supply: PLL power supply. >>> >>> Old DTs won't contain those properties. This breaks the DT ABI if those >>> properties are required. Is that acceptable? >> >> As of now adv7343 via DT binding is not enabled in any platforms >> so this wont break any DT ABI. > > Well, if the binding has already been written, it technically already is > an ABI. Perhaps the binding can be fixed if it isn't in use yet, but > this is definitely not the correct approach to DT. > Ok >>> If it is, I think we should document that older versions of the binding >>> didn't require those properties, so they may in fact be missing. >>> >>> I note that this patch doesn't actually update the driver to >>> regulator_get() anything. Shouldn't it? >> >> As of now the driver isn’t enabling/accepting the regulators, >> so should I add those in DT properties or not ? > > The binding should describe the HW, not what the driver does/doesn't yet > do. I wrote the above because it looked like the driver was broken, not > to encourage you to remove properties from the binding. OK > How does the > driver work if it doesn't enable the required regulators though, I > wonder? I suppose the boards this driver has been tested on all must > used fixed (non-SW-controlled) regulators. > on all the boards on which this decoder is connected the power to it is provided by static circuit and not by regulators, So for this how would you suggest to add the DT nodes for regulators ? Optional Properties : -- adi,power-mode-sleep-mode: on enable the current consumption is reduced to - micro ampere level. All DACs and the internal PLL - circuit are disabled. -- adi,power-mode-pll-ctrl: PLL and oversampling control. This control allows -internal PLL 1 circuit to be powered down and the -oversampling to be switched off. -- ad,adv7343-power-mode-dac: array configuring the power on/off DAC's 1..6, - 0 = OFF and 1 = ON, Default value when this - property is not specified is <0 0 0 0 0 0>. -- ad,adv7343-sd-config-dac-out: array configure SD DAC Output's 1 and 2, 0 = OFF - and 1 = ON, Default value when this property is - not specified is <0 0>. >>> >>> At a very quick glance, it's not really clear why those properties are >>> being removed. They seem like HW configuration, so might be fine to put >>> into DT. What replaces these? >> >> Yes these were HW configuration but, its now internally handled in >> the driver. The 'ad,adv7343-power-mode-dac' property which enabled the >> DAC's 1..6 , so now in the driver by default all the DAC's are enabled by >> default and enable unconnected DAC auto power down. Similarly >> 'ad,adv7343-sd-config-dac-out' property enabled SD DAC's 1..2 but >> now is enabled by reading the CABLE DETECT register which tells >> the status of DAC1/2. > > OK, that's probably fine for the two properties you mentioned (you > didn't describe two of them...). Some more discussion on why SW doesn't > need these options might be useful in the patch description. Note that > the discussion should be written for software in general (i.e. any OS's > driver), and not for Linux's specific driver, since DT is not tied to > any one OS. OK will update the description. Regards, --Prabhakar Lad -- 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: Easycap DC60 stk1160 driver
Hi Ezequiel and Andrew, Andrew replied to my request on his easycap forum, so I'll answer you both here. On Thu, Sep 19, 2013 at 2:39 PM, Ezequiel Garcia wrote: > If you have any chance to test a v3.11 or later kernel, please report > let me know if this is your problem or there's something new going on. I'm running Xubuntu 13.10 live and stk1160 recognizes the device and cheese and ffmpeg show the video. Unfortunately the frames are garbled as if the size of the frames is wrong. Do you know of this problem and a possible fix for it? > Also, if you can crack open (carefully) your easycap and check the > encoder is gm7113 then that confirms you need either a newer kernel > or request Ubuntu people to backport the fix (it's really very easy). Yes, it indeed uses the gm7113 encoder, so the new kernel is necessary. Would it be possible, or at all advisable, to try to compile the easycap driver from Ubuntu 12.04 on the newer kernels? Regards, Cees -- 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: Kernel Summit Media Mini-summit attendees on Oct 23 in Edinburgh
Em Tue, 17 Sep 2013 14:08:31 -0300 Mauro Carvalho Chehab escreveu: > Hi, > > I'm trying to consolidate the list of interested people on participating at > this year's the media mini-summit. From what I got from the discussions, we > have, so far: > > Benjamin Gaignard > Guennadi Liakhovetski > Hans Verkuil > Hugues FRUCHET > Laurent Pinchart > Mauro Carvalho Chehab > Michael Krufky > Oliver Schinagl > Pawel Osciak > Peter Senna Tschudin > Ricardo Ribalda Delgado > Sakari Ailus > > Please let me know if I'm missing someone, or if one of the above won't be > able to go to the meeting, as my plan is to send the invitations tomorrow. Ok, It follows a version 2 of the list. I'll be sending the invitations in a few. Alex Luccisano Andrzej Hajda Benjamin Gaignard Guennadi Liakhovetski Hans Verkuil Hugues FRUCHET Laurent Pinchart Mauro Carvalho Chehab Michael Krufky Pawel Osciak Peter Senna Tschudin Ricardo Ribalda Delgado Sakari Ailus Sylwester Nawrocki > > Thank you! > Mauro > -- > 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 -- Cheers, Mauro -- 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: Kernel Summit Media Mini-summit attendees on Oct 23 in Edinburgh
Em Tue, 17 Sep 2013 19:49:21 +0200 Oliver Schinagl escreveu: > On 09/17/13 19:08, Mauro Carvalho Chehab wrote: > > Hi, > > > > I'm trying to consolidate the list of interested people on participating at > > this year's the media mini-summit. From what I got from the discussions, we > > have, so far: > > > > Benjamin Gaignard > > Guennadi Liakhovetski > > Hans Verkuil > > Hugues FRUCHET > > Laurent Pinchart > > Mauro Carvalho Chehab > > Michael Krufky > > Oliver Schinagl > > Pawel Osciak > > Peter Senna Tschudin > > Ricardo Ribalda Delgado > > Sakari Ailus > > > > Please let me know if I'm missing someone, or if one of the above won't be > > able to go to the meeting, as my plan is to send the invitations tomorrow. > While I'd really love to go there, I was only asking a question really > :) and am unable to attend. Wishfully there would be a video recording > of sorts. Sorry, nobody will be recording any video, AFAIKT. We'll write a summary of the conference and post at both ML and linuxtv.org after the event. > > Will try to attend fosdem 2014 though ;) > > Oliver > > > > > Thank you! > > Mauro > > -- > > 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 > > > > -- > 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 -- Cheers, Mauro -- 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: Easycap DC60 stk1160 driver
Hi Cees Bassa, On Thu, Sep 19, 2013 at 02:14:57PM +0200, C. Bassa wrote: > > My EasyCAP DC60 device works fine in Xubuntu 12.04.3 (kernel 3.2.0) > but when I try to use it in Xubuntu 13.04 (kernel 3.8.0) it displays a > green screen when using mplayer, or fails to stream all together using > cheese. > > No error messages are reported in /var/log/syslog, so I am not sure > what may be wrong. > > Any help will be greatly appreciated. > The staging easycap driver was completely rewritten from scratch and a new 'stk1160' driver replaced it in v3.7. This new driver uses the saa7115 driver to support the encoder chip as found on those devices. However, some devices are using an encoder called 'gm7113c' which is not supported by the saa7115 driver present in older kernels. A fix was found this year by Jon Arne Jørgensen and it's included in v3.11 or later. If you have any chance to test a v3.11 or later kernel, please report let me know if this is your problem or there's something new going on. Also, if you can crack open (carefully) your easycap and check the encoder is gm7113 then that confirms you need either a newer kernel or request Ubuntu people to backport the fix (it's really very easy). Good luck! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- 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
Easycap DC60 stk1160 driver
Hi, My EasyCAP DC60 device works fine in Xubuntu 12.04.3 (kernel 3.2.0) but when I try to use it in Xubuntu 13.04 (kernel 3.8.0) it displays a green screen when using mplayer, or fails to stream all together using cheese. No error messages are reported in /var/log/syslog, so I am not sure what may be wrong. Any help will be greatly appreciated. Kind regards, Cees Bassa -- 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 v4] media: st-rc: Add ST remote control driver
From: Srinivas Kandagatla
This patch adds support to ST RC driver, which is basically a IR/UHF
receiver and transmitter. This IP (IRB) is common across all the ST
parts for settop box platforms. IRB is embedded in ST COMMS IP block.
It supports both Rx & Tx functionality.
In this driver adds only Rx functionality via LIRC codec.
Signed-off-by: Srinivas Kandagatla
Acked-by: Sean Young
---
Hi Chehab,
This is a very simple rc driver for IRB controller found in STi ARM CA9 SOCs.
This driver is a raw driver which feeds data to lirc codec for the user lircd
to decode the keys.
This patch is based on v3.12-rc1.
Changes since v3:
- updated dt bindings doc with suggestions from Mark R.
Changes since v2:
- Updated Kconfig dependencies as suggested by Sean and Chehab.
- Fixed a logical check spoted by Sean.
Changes since v1:
- Device tree bindings cleaned up as suggested by Mark and Pawel
- use ir_raw_event_reset under overflow conditions as suggested by Sean.
- call ir_raw_event_handle in interrupt handler as suggested by Sean.
- correct allowed_protos flag with RC_BIT_ types as suggested by Sean.
- timeout and rx resolution added as suggested by Sean.
Thankyou all for reviewing and commenting.
Thanks,
srini
Documentation/devicetree/bindings/media/st-rc.txt | 27 ++
drivers/media/rc/Kconfig | 10 +
drivers/media/rc/Makefile |1 +
drivers/media/rc/st_rc.c | 396 +
4 files changed, 434 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/st-rc.txt
create mode 100644 drivers/media/rc/st_rc.c
diff --git a/Documentation/devicetree/bindings/media/st-rc.txt
b/Documentation/devicetree/bindings/media/st-rc.txt
new file mode 100644
index 000..71de22b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st-rc.txt
@@ -0,0 +1,27 @@
+Device-Tree bindings for ST IRB IP
+
+Required properties:
+ - compatible: should contain "st,comms-irb".
+ - reg: base physical address of the controller and length of memory
+ mapped region.
+ - interrupts: interrupt-specifier for the sole interrupt generated by
+ the device. The interrupt specifier format depends on the
+ interrupt controller parent.
+ - rx-mode: can be "infrared" or "uhf". rx-mode should be present iff the
+ rx pins are wired up.
+ - tx-mode: should be "infrared". tx-mode should be present iff the tx
+ pins are wired up.
+
+Optional properties:
+ - pinctrl-names, pinctrl-0: the pincontrol settings to configure
+ muxing properly for IRB pins.
+ - clocks : phandle with clock-specifier pair.
+
+Example node:
+
+ rc: rc@fe518000 {
+ compatible = "st,comms-irb";
+ reg = <0xfe518000 0x234>;
+ interrupts = <0 203 0>;
+ rx-mode = "infrared";
+ };
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 11e84bc..557afc5 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -322,4 +322,14 @@ config IR_GPIO_CIR
To compile this driver as a module, choose M here: the module will
be called gpio-ir-recv.
+config RC_ST
+ tristate "ST remote control receiver"
+ depends on ARCH_STI && RC_CORE
+ help
+Say Y here if you want support for ST remote control driver
+which allows both IR and UHF RX.
+The driver passes raw pluse and space information to the LIRC decoder.
+
+If you're not sure, select N here.
+
endif #RC_DEVICES
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 56bacf0..f4eb32c 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
obj-$(CONFIG_IR_IGUANA) += iguanair.o
obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
+obj-$(CONFIG_RC_ST) += st_rc.o
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
new file mode 100644
index 000..e2dad9c
--- /dev/null
+++ b/drivers/media/rc/st_rc.c
@@ -0,0 +1,396 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics Limited
+ * Author: Srinivas Kandagatla
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct st_rc_device {
+ struct device *dev;
+ int irq;
+ int irq_wake;
+ struct clk *sys_clock;
+ void*base; /* Register base address */
+
[PATCH 08/10] [media] coda: v4l2-compliance fix: overwrite invalid pixel formats with the current setting
This patch fixes the v4l2-compliance "TRY_FMT(G_FMT) != G_FMT" issue.
The driver now overwrites invalid formats with the current setting, using
coda_get_max_dimensions to find device specific max width/height.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 72 +--
1 file changed, 56 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 9091664..1d44a4b 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -54,8 +54,6 @@
#define CODA_MAX_FRAMEBUFFERS 8
-#define MAX_W 8192
-#define MAX_H 8192
#define CODA_MAX_FRAME_SIZE0x10
#define FMO_SLICE_SAVE_BUF_SIZE (32)
#define CODA_DEFAULT_GAMMA 4096
@@ -394,6 +392,31 @@ static struct coda_codec *coda_find_codec(struct coda_dev
*dev, int src_fourcc,
return &codecs[k];
}
+static void coda_get_max_dimensions(struct coda_dev *dev,
+ struct coda_codec *codec,
+ int *max_w, int *max_h)
+{
+ struct coda_codec *codecs = dev->devtype->codecs;
+ int num_codecs = dev->devtype->num_codecs;
+ unsigned int w, h;
+ int k;
+
+ if (codec) {
+ w = codec->max_w;
+ h = codec->max_h;
+ } else {
+ for (k = 0, w = 0, h = 0; k < num_codecs; k++) {
+ w = max(w, codecs[k].max_w);
+ h = max(h, codecs[k].max_h);
+ }
+ }
+
+ if (max_w)
+ *max_w = w;
+ if (max_h)
+ *max_h = h;
+}
+
static char *coda_product_name(int product)
{
static char buf[9];
@@ -537,8 +560,11 @@ static int coda_vidioc_g_fmt(struct file *file, void *priv,
return 0;
}
-static int coda_vidioc_try_fmt(struct coda_codec *codec, struct v4l2_format *f)
+static int coda_vidioc_try_fmt(struct coda_ctx *ctx, struct coda_codec *codec,
+ struct v4l2_format *f)
{
+ struct coda_dev *dev = ctx->dev;
+ struct coda_q_data *q_data;
unsigned int max_w, max_h;
enum v4l2_field field;
@@ -552,25 +578,39 @@ static int coda_vidioc_try_fmt(struct coda_codec *codec,
struct v4l2_format *f)
* if any of the dimensions is unsupported */
f->fmt.pix.field = field;
- if (codec) {
- max_w = codec->max_w;
- max_h = codec->max_h;
- } else {
- max_w = MAX_W;
- max_h = MAX_H;
+ coda_get_max_dimensions(dev, codec, &max_w, &max_h);
+ v4l_bound_align_image(&f->fmt.pix.width, MIN_W, max_w, W_ALIGN,
+ &f->fmt.pix.height, MIN_H, max_h, H_ALIGN,
+ S_ALIGN);
+
+ switch (f->fmt.pix.pixelformat) {
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ case V4L2_PIX_FMT_H264:
+ case V4L2_PIX_FMT_MPEG4:
+ case V4L2_PIX_FMT_JPEG:
+ break;
+ default:
+ q_data = get_q_data(ctx, f->type);
+ f->fmt.pix.pixelformat = q_data->fourcc;
}
- v4l_bound_align_image(&f->fmt.pix.width, MIN_W, max_w,
- W_ALIGN, &f->fmt.pix.height,
- MIN_H, max_h, H_ALIGN, S_ALIGN);
- if (coda_format_is_yuv(f->fmt.pix.pixelformat)) {
+ switch (f->fmt.pix.pixelformat) {
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
/* Frame stride must be multiple of 8 */
f->fmt.pix.bytesperline = round_up(f->fmt.pix.width, 8);
f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
f->fmt.pix.height * 3 / 2;
- } else { /*encoded formats h.264/mpeg4 */
+ break;
+ case V4L2_PIX_FMT_H264:
+ case V4L2_PIX_FMT_MPEG4:
+ case V4L2_PIX_FMT_JPEG:
f->fmt.pix.bytesperline = 0;
f->fmt.pix.sizeimage = CODA_MAX_FRAME_SIZE;
+ break;
+ default:
+ BUG();
}
return 0;
@@ -605,7 +645,7 @@ static int coda_vidioc_try_fmt_vid_cap(struct file *file,
void *priv,
f->fmt.pix.colorspace = ctx->colorspace;
- ret = coda_vidioc_try_fmt(codec, f);
+ ret = coda_vidioc_try_fmt(ctx, codec, f);
if (ret < 0)
return ret;
@@ -634,7 +674,7 @@ static int coda_vidioc_try_fmt_vid_out(struct file *file,
void *priv,
if (!f->fmt.pix.colorspace)
f->fmt.pix.colorspace = V4L2_COLORSPACE_REC709;
- return coda_vidioc_try_fmt(codec, f);
+ return coda_vidioc_try_fmt(ctx, codec, f);
}
static int coda_vidioc_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
--
1.8.4.rc3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More maj
[PATCH 04/10] [media] coda: fix FMO value setting for CodaDx6
The register is only written on CodaDx6, so the temporary variable
to be written only needs to be initialized on CodaDx6.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 53539c1..e8acff3 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -2074,10 +2074,10 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
coda_setup_iram(ctx);
if (dst_fourcc == V4L2_PIX_FMT_H264) {
- value = (FMO_SLICE_SAVE_BUF_SIZE << 7);
- value |= (0 & CODA_FMOPARAM_TYPE_MASK) <<
CODA_FMOPARAM_TYPE_OFFSET;
- value |= 0 & CODA_FMOPARAM_SLICENUM_MASK;
if (dev->devtype->product == CODA_DX6) {
+ value = (FMO_SLICE_SAVE_BUF_SIZE << 7);
+ value |= (0 & CODA_FMOPARAM_TYPE_MASK) <<
CODA_FMOPARAM_TYPE_OFFSET;
+ value |= 0 & CODA_FMOPARAM_SLICENUM_MASK;
coda_write(dev, value, CODADX6_CMD_ENC_SEQ_FMO);
} else {
coda_write(dev, ctx->iram_info.search_ram_paddr,
--
1.8.4.rc3
--
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/10] [media] coda: v4l2-compliance fix: zero pixel format priv field
Signed-off-by: Philipp Zabel --- drivers/media/platform/coda.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c index d15238a..6dec34d 100644 --- a/drivers/media/platform/coda.c +++ b/drivers/media/platform/coda.c @@ -556,6 +556,7 @@ static int coda_vidioc_g_fmt(struct file *file, void *priv, f->fmt.pix.sizeimage= q_data->sizeimage; f->fmt.pix.colorspace = ctx->colorspace; + f->fmt.pix.priv = 0; return 0; } @@ -613,6 +614,8 @@ static int coda_vidioc_try_fmt(struct coda_ctx *ctx, struct coda_codec *codec, BUG(); } + f->fmt.pix.priv = 0; + return 0; } -- 1.8.4.rc3 -- 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/10] [media] coda: add compressed flag to format enumeration output
Correctly flag compressed formats in the ENUM_FMT ioctl output. Signed-off-by: Philipp Zabel --- drivers/media/platform/coda.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c index 945c539..53539c1 100644 --- a/drivers/media/platform/coda.c +++ b/drivers/media/platform/coda.c @@ -457,6 +457,8 @@ static int enum_fmt(void *priv, struct v4l2_fmtdesc *f, fmt = &formats[i]; strlcpy(f->description, fmt->name, sizeof(f->description)); f->pixelformat = fmt->fourcc; + if (!coda_format_is_yuv(fmt->fourcc)) + f->flags |= V4L2_FMT_FLAG_COMPRESSED; return 0; } -- 1.8.4.rc3 -- 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/10] [media] coda: prefix v4l2_ioctl_ops with coda_
Moving the ioctl handler callbacks into the coda namespace helps
tremendously to make sense of backtraces.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 123 +-
1 file changed, 63 insertions(+), 60 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 4f038c2..9091664 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -412,8 +412,8 @@ static char *coda_product_name(int product)
/*
* V4L2 ioctl() operations.
*/
-static int vidioc_querycap(struct file *file, void *priv,
- struct v4l2_capability *cap)
+static int coda_vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *cap)
{
struct coda_ctx *ctx = fh_to_ctx(priv);
@@ -484,8 +484,8 @@ static int enum_fmt(void *priv, struct v4l2_fmtdesc *f,
return -EINVAL;
}
-static int vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
- struct v4l2_fmtdesc *f)
+static int coda_vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
{
struct coda_ctx *ctx = fh_to_ctx(priv);
struct vb2_queue *src_vq;
@@ -503,13 +503,14 @@ static int vidioc_enum_fmt_vid_cap(struct file *file,
void *priv,
return enum_fmt(priv, f, V4L2_BUF_TYPE_VIDEO_CAPTURE, 0);
}
-static int vidioc_enum_fmt_vid_out(struct file *file, void *priv,
- struct v4l2_fmtdesc *f)
+static int coda_vidioc_enum_fmt_vid_out(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
{
return enum_fmt(priv, f, V4L2_BUF_TYPE_VIDEO_OUTPUT, 0);
}
-static int vidioc_g_fmt(struct file *file, void *priv, struct v4l2_format *f)
+static int coda_vidioc_g_fmt(struct file *file, void *priv,
+struct v4l2_format *f)
{
struct vb2_queue *vq;
struct coda_q_data *q_data;
@@ -536,7 +537,7 @@ static int vidioc_g_fmt(struct file *file, void *priv,
struct v4l2_format *f)
return 0;
}
-static int vidioc_try_fmt(struct coda_codec *codec, struct v4l2_format *f)
+static int coda_vidioc_try_fmt(struct coda_codec *codec, struct v4l2_format *f)
{
unsigned int max_w, max_h;
enum v4l2_field field;
@@ -575,8 +576,8 @@ static int vidioc_try_fmt(struct coda_codec *codec, struct
v4l2_format *f)
return 0;
}
-static int vidioc_try_fmt_vid_cap(struct file *file, void *priv,
- struct v4l2_format *f)
+static int coda_vidioc_try_fmt_vid_cap(struct file *file, void *priv,
+ struct v4l2_format *f)
{
struct coda_ctx *ctx = fh_to_ctx(priv);
struct coda_codec *codec;
@@ -604,7 +605,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void
*priv,
f->fmt.pix.colorspace = ctx->colorspace;
- ret = vidioc_try_fmt(codec, f);
+ ret = coda_vidioc_try_fmt(codec, f);
if (ret < 0)
return ret;
@@ -620,8 +621,8 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void
*priv,
return 0;
}
-static int vidioc_try_fmt_vid_out(struct file *file, void *priv,
- struct v4l2_format *f)
+static int coda_vidioc_try_fmt_vid_out(struct file *file, void *priv,
+ struct v4l2_format *f)
{
struct coda_ctx *ctx = fh_to_ctx(priv);
struct coda_codec *codec;
@@ -633,10 +634,10 @@ static int vidioc_try_fmt_vid_out(struct file *file, void
*priv,
if (!f->fmt.pix.colorspace)
f->fmt.pix.colorspace = V4L2_COLORSPACE_REC709;
- return vidioc_try_fmt(codec, f);
+ return coda_vidioc_try_fmt(codec, f);
}
-static int vidioc_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
+static int coda_vidioc_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
{
struct coda_q_data *q_data;
struct vb2_queue *vq;
@@ -666,61 +667,62 @@ static int vidioc_s_fmt(struct coda_ctx *ctx, struct
v4l2_format *f)
return 0;
}
-static int vidioc_s_fmt_vid_cap(struct file *file, void *priv,
- struct v4l2_format *f)
+static int coda_vidioc_s_fmt_vid_cap(struct file *file, void *priv,
+struct v4l2_format *f)
{
struct coda_ctx *ctx = fh_to_ctx(priv);
int ret;
- ret = vidioc_try_fmt_vid_cap(file, priv, f);
+ ret = coda_vidioc_try_fmt_vid_cap(file, priv, f);
if (ret)
return ret;
- return vidioc_s_fmt(ctx, f);
+ return coda_vidioc_s_fmt(ctx, f);
}
-static int vidioc_s_fmt_vid_out(struct file *file, void *priv,
- struct v4l2_format *f)
+static int coda_vidioc_s_fmt_vid_out(struct file *file, void *priv,
+struct v4l2_form
[PATCH 06/10] [media] coda: use picture type returned from hardware
Instead of copying v4l2_buf.flags from the source buffer, set
the destination buffer flags as reported by the hardware codec.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 4598b60..4f038c2 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -2746,7 +2746,6 @@ static void coda_finish_encode(struct coda_ctx *ctx)
dst_buf = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
/* Get results from the coda */
- coda_read(dev, CODA_RET_ENC_PIC_TYPE);
start_ptr = coda_read(dev, CODA_CMD_ENC_PIC_BB_START);
wr_ptr = coda_read(dev, CODA_REG_BIT_WR_PTR(ctx->reg_idx));
@@ -2766,7 +2765,7 @@ static void coda_finish_encode(struct coda_ctx *ctx)
coda_read(dev, CODA_RET_ENC_PIC_SLICE_NUM);
coda_read(dev, CODA_RET_ENC_PIC_FLAG);
- if (src_buf->v4l2_buf.flags & V4L2_BUF_FLAG_KEYFRAME) {
+ if (coda_read(dev, CODA_RET_ENC_PIC_TYPE) == 0) {
dst_buf->v4l2_buf.flags |= V4L2_BUF_FLAG_KEYFRAME;
dst_buf->v4l2_buf.flags &= ~V4L2_BUF_FLAG_PFRAME;
} else {
--
1.8.4.rc3
--
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 0/10] CODA driver fixes
This series contains a few fixes for the CODA driver to allow more than four simultaneous instances on i.MX53, and to make v4l2-compliance a bit happier. regards Philipp --- drivers/media/platform/coda.c | 281 ++ 1 file changed, 175 insertions(+), 106 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 05/10] [media] coda: move coda_product_name above vidioc_querycap
Use the product name (currently CodaDx6 or CODA7541)
to fill the v4l2_capabilities.name field.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 35 +++
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index e8acff3..4598b60 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -394,14 +394,32 @@ static struct coda_codec *coda_find_codec(struct coda_dev
*dev, int src_fourcc,
return &codecs[k];
}
+static char *coda_product_name(int product)
+{
+ static char buf[9];
+
+ switch (product) {
+ case CODA_DX6:
+ return "CodaDx6";
+ case CODA_7541:
+ return "CODA7541";
+ default:
+ snprintf(buf, sizeof(buf), "(0x%04x)", product);
+ return buf;
+ }
+}
+
/*
* V4L2 ioctl() operations.
*/
static int vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
+ struct coda_ctx *ctx = fh_to_ctx(priv);
+
strlcpy(cap->driver, CODA_NAME, sizeof(cap->driver));
- strlcpy(cap->card, CODA_NAME, sizeof(cap->card));
+ strlcpy(cap->card, coda_product_name(ctx->dev->devtype->product),
+ sizeof(cap->card));
strlcpy(cap->bus_info, "platform:" CODA_NAME, sizeof(cap->bus_info));
/*
* This is only a mem-to-mem video device. The capture and output
@@ -2870,21 +2888,6 @@ static bool coda_firmware_supported(u32 vernum)
return false;
}
-static char *coda_product_name(int product)
-{
- static char buf[9];
-
- switch (product) {
- case CODA_DX6:
- return "CodaDx6";
- case CODA_7541:
- return "CODA7541";
- default:
- snprintf(buf, sizeof(buf), "(0x%04x)", product);
- return buf;
- }
-}
-
static int coda_hw_init(struct coda_dev *dev)
{
u16 product, major, minor, release;
--
1.8.4.rc3
--
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/10] [media] coda: v4l2-compliance fix: implement decoder_try_cmd
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 1d44a4b..d15238a 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -835,23 +835,34 @@ static int coda_vidioc_streamoff(struct file *file, void
*priv,
return ret;
}
-static int coda_vidioc_decoder_cmd(struct file *file, void *fh,
- struct v4l2_decoder_cmd *dc)
+static int coda_vidioc_try_decoder_cmd(struct file *file, void *fh,
+ struct v4l2_decoder_cmd *dc)
{
- struct coda_ctx *ctx = fh_to_ctx(fh);
-
if (dc->cmd != V4L2_DEC_CMD_STOP)
return -EINVAL;
- if ((dc->flags & V4L2_DEC_CMD_STOP_TO_BLACK) ||
- (dc->flags & V4L2_DEC_CMD_STOP_IMMEDIATELY))
+ if (dc->flags & V4L2_DEC_CMD_STOP_TO_BLACK)
return -EINVAL;
- if (dc->stop.pts != 0)
+ if (!(dc->flags & V4L2_DEC_CMD_STOP_IMMEDIATELY) && (dc->stop.pts != 0))
return -EINVAL;
+ return 0;
+}
+
+static int coda_vidioc_decoder_cmd(struct file *file, void *fh,
+ struct v4l2_decoder_cmd *dc)
+{
+ struct coda_ctx *ctx = fh_to_ctx(fh);
+ int ret;
+
+ ret = coda_vidioc_try_decoder_cmd(file, fh, dc);
+ if (ret < 0)
+ return ret;
+
+ /* Ignore decoder stop command silently in encoder context */
if (ctx->inst_type != CODA_INST_DECODER)
- return -EINVAL;
+ return 0;
/* Set the strem-end flag on this context */
ctx->bit_stream_param |= CODA_BIT_STREAM_END_FLAG;
@@ -894,6 +905,7 @@ static const struct v4l2_ioctl_ops coda_ioctl_ops = {
.vidioc_streamon= coda_vidioc_streamon,
.vidioc_streamoff = coda_vidioc_streamoff,
+ .vidioc_try_decoder_cmd = coda_vidioc_try_decoder_cmd,
.vidioc_decoder_cmd = coda_vidioc_decoder_cmd,
.vidioc_subscribe_event = coda_vidioc_subscribe_event,
--
1.8.4.rc3
--
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/10] [media] coda: allow more than four instances on CODA7541
With the new firmware, there are not anymore four register sets,
but a single register set, which the driver has to conserve across
context switches. This allows to handle more than four instances
at the same time.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 449d2fe..2805538 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -39,7 +39,7 @@
#define CODA_NAME "coda"
-#define CODA_MAX_INSTANCES 4
+#define CODADX6_MAX_INSTANCES 4
#define CODA_FMO_BUF_SIZE 32
#define CODADX6_WORK_BUF_SIZE (288 * 1024 + CODA_FMO_BUF_SIZE * 8 * 1024)
@@ -2371,7 +2371,13 @@ static int coda_queue_init(void *priv, struct vb2_queue
*src_vq,
static int coda_next_free_instance(struct coda_dev *dev)
{
- return ffz(dev->instance_mask);
+ int idx = ffz(dev->instance_mask);
+
+ if ((idx < 0) ||
+ (dev->devtype->product == CODA_DX6 && idx > CODADX6_MAX_INSTANCES))
+ return -EBUSY;
+
+ return idx;
}
static int coda_open(struct file *file)
@@ -2386,8 +2392,8 @@ static int coda_open(struct file *file)
return -ENOMEM;
idx = coda_next_free_instance(dev);
- if (idx >= CODA_MAX_INSTANCES) {
- ret = -EBUSY;
+ if (idx < 0) {
+ ret = idx;
goto err_coda_max;
}
set_bit(idx, &dev->instance_mask);
--
1.8.4.rc3
--
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/10] [media] coda: only set buffered input queue for decoder
Signed-off-by: Philipp Zabel --- drivers/media/platform/coda.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c index 2805538..945c539 100644 --- a/drivers/media/platform/coda.c +++ b/drivers/media/platform/coda.c @@ -1928,8 +1928,9 @@ static int coda_start_streaming(struct vb2_queue *q, unsigned int count) if (!(ctx->streamon_out & ctx->streamon_cap)) return 0; - /* Allow device_run with no buffers queued and after streamoff */ - v4l2_m2m_set_src_buffered(ctx->m2m_ctx, true); + /* Allow decoder device_run with no new buffers queued */ + if (ctx->inst_type == CODA_INST_DECODER) + v4l2_m2m_set_src_buffered(ctx->m2m_ctx, true); ctx->gopcounter = ctx->params.gop_size - 1; buf = v4l2_m2m_next_dst_buf(ctx->m2m_ctx); -- 1.8.4.rc3 -- 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] videobuf2-core: call __setup_offsets only for mmap memory type
Hi Pawel, Am Donnerstag, den 19.09.2013, 16:54 +0900 schrieb Pawel Osciak: > On Thu, Sep 19, 2013 at 4:37 PM, Philipp Zabel wrote: > > __setup_offsets fills the v4l2_planes' mem_offset fields, which is only > > valid > > for V4L2_MEMORY_MMAP type buffers. For V4L2_MEMORY_DMABUF and _USERPTR > > buffers, > > this incorrectly overwrites the fd and userptr fields. > > I'm not particularly against this change, but I'm curious if anything > that you were doing was broken by this call? The buffers are created > here, so their fields don't contain anything that could be overwritten > (although keeping them at 0 is preferable). nothing was actually broken, but even though the spec doesn't say anything about the QUERYBUF return values in the DMABUF/USERPTR cases, setting them to some random initial value doesn't seem right. Maybe the documentation could be amended to mention fd and userptr, although in this case the fd should probably be set to -1 initially. QUERYBUF could then be used to find free slots. regards Philipp -- 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] videobuf2-core: call __setup_offsets only for mmap memory type
Hello, On 9/19/2013 9:37 AM, Philipp Zabel wrote: __setup_offsets fills the v4l2_planes' mem_offset fields, which is only valid for V4L2_MEMORY_MMAP type buffers. For V4L2_MEMORY_DMABUF and _USERPTR buffers, this incorrectly overwrites the fd and userptr fields. Reported-by: Michael Olbrich Signed-off-by: Philipp Zabel Acked-by: Marek Szyprowski --- drivers/media/v4l2-core/videobuf2-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 9c865da..95a798e 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -241,7 +241,8 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum v4l2_memory memory, q->bufs[q->num_buffers + buffer] = vb; } - __setup_offsets(q, buffer); + if (memory == V4L2_MEMORY_MMAP) + __setup_offsets(q, buffer); dprintk(1, "Allocated %d buffers, %d plane(s) each\n", buffer, num_planes); Best regards -- Marek Szyprowski Samsung R&D Institute Poland -- 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] videobuf2-core: call __setup_offsets only for mmap memory type
On Thu, Sep 19, 2013 at 4:37 PM, Philipp Zabel wrote: > __setup_offsets fills the v4l2_planes' mem_offset fields, which is only valid > for V4L2_MEMORY_MMAP type buffers. For V4L2_MEMORY_DMABUF and _USERPTR > buffers, > this incorrectly overwrites the fd and userptr fields. I'm not particularly against this change, but I'm curious if anything that you were doing was broken by this call? The buffers are created here, so their fields don't contain anything that could be overwritten (although keeping them at 0 is preferable). > > Reported-by: Michael Olbrich > Signed-off-by: Philipp Zabel > --- > drivers/media/v4l2-core/videobuf2-core.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/v4l2-core/videobuf2-core.c > b/drivers/media/v4l2-core/videobuf2-core.c > index 9c865da..95a798e 100644 > --- a/drivers/media/v4l2-core/videobuf2-core.c > +++ b/drivers/media/v4l2-core/videobuf2-core.c > @@ -241,7 +241,8 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum > v4l2_memory memory, > q->bufs[q->num_buffers + buffer] = vb; > } > > - __setup_offsets(q, buffer); > + if (memory == V4L2_MEMORY_MMAP) > + __setup_offsets(q, buffer); > > dprintk(1, "Allocated %d buffers, %d plane(s) each\n", > buffer, num_planes); > -- > 1.8.4.rc3 > -- Best regards, Pawel Osciak -- 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] v4l2-mem2mem: clear m2m queue ready counter in v4l2_m2m_streamoff
v4l2_m2m_streamoff drops the list of ready buffers but failed to reset the
num_rdy counter to zero. This would lead to v4l2_m2m_num_src/dst_bufs_ready
reporting wrong values after streamoff.
Signed-off-by: Philipp Zabel
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 8f116c2..796de33 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -488,6 +488,7 @@ int v4l2_m2m_streamoff(struct file *file, struct
v4l2_m2m_ctx *m2m_ctx,
/* Drop queue, since streamoff returns device to the same state as after
* calling reqbufs. */
INIT_LIST_HEAD(&q_ctx->rdy_queue);
+ q_ctx->num_rdy = 0;
spin_unlock_irqrestore(&q_ctx->rdy_spinlock, flags);
if (m2m_dev->curr_ctx == m2m_ctx) {
--
1.8.4.rc3
--
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] v4l2-mem2mem: fix context removal from job queue in v4l2_m2m_streamoff
Just clearing the m2m_ctx->queue list_head will leave the m2m_dev->job_queue in a broken state and can cause scheduling of device_runs after streamoff was called. Signed-off-by: Philipp Zabel --- drivers/media/v4l2-core/v4l2-mem2mem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-core/v4l2-mem2mem.c index 7c43712..8f116c2 100644 --- a/drivers/media/v4l2-core/v4l2-mem2mem.c +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c @@ -480,7 +480,8 @@ int v4l2_m2m_streamoff(struct file *file, struct v4l2_m2m_ctx *m2m_ctx, m2m_dev = m2m_ctx->m2m_dev; spin_lock_irqsave(&m2m_dev->job_spinlock, flags_job); /* We should not be scheduled anymore, since we're dropping a queue. */ - INIT_LIST_HEAD(&m2m_ctx->queue); + if (m2m_ctx->job_flags & TRANS_QUEUED) + list_del(&m2m_ctx->queue); m2m_ctx->job_flags = 0; spin_lock_irqsave(&q_ctx->rdy_spinlock, flags); -- 1.8.4.rc3 -- 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] videobuf2-core: call __setup_offsets only for mmap memory type
__setup_offsets fills the v4l2_planes' mem_offset fields, which is only valid for V4L2_MEMORY_MMAP type buffers. For V4L2_MEMORY_DMABUF and _USERPTR buffers, this incorrectly overwrites the fd and userptr fields. Reported-by: Michael Olbrich Signed-off-by: Philipp Zabel --- drivers/media/v4l2-core/videobuf2-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 9c865da..95a798e 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -241,7 +241,8 @@ static int __vb2_queue_alloc(struct vb2_queue *q, enum v4l2_memory memory, q->bufs[q->num_buffers + buffer] = vb; } - __setup_offsets(q, buffer); + if (memory == V4L2_MEMORY_MMAP) + __setup_offsets(q, buffer); dprintk(1, "Allocated %d buffers, %d plane(s) each\n", buffer, num_planes); -- 1.8.4.rc3 -- 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
