[PATCH 2/3] [media] exynos4-is: Annotate unused functions
__is_set_init_isp_aa and fimc_is_hw_set_tune currently do not have
any callers. However these functions may be used in the future. Hence
instead of deleting them, staticize and annotate them with __maybe_unused
flag to avoid compiler warnings.
Signed-off-by: Sachin Kamat
---
drivers/media/platform/exynos4-is/fimc-is-param.c |2 +-
drivers/media/platform/exynos4-is/fimc-is-regs.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-is-param.c
b/drivers/media/platform/exynos4-is/fimc-is-param.c
index a353be0..9bf3ddd 100644
--- a/drivers/media/platform/exynos4-is/fimc-is-param.c
+++ b/drivers/media/platform/exynos4-is/fimc-is-param.c
@@ -287,7 +287,7 @@ void __is_set_sensor(struct fimc_is *is, int fps)
fimc_is_set_param_bit(is, PARAM_ISP_OTF_INPUT);
}
-void __is_set_init_isp_aa(struct fimc_is *is)
+static void __maybe_unused __is_set_init_isp_aa(struct fimc_is *is)
{
struct isp_param *isp;
diff --git a/drivers/media/platform/exynos4-is/fimc-is-regs.c
b/drivers/media/platform/exynos4-is/fimc-is-regs.c
index 63c68ec..cf2e13a 100644
--- a/drivers/media/platform/exynos4-is/fimc-is-regs.c
+++ b/drivers/media/platform/exynos4-is/fimc-is-regs.c
@@ -96,7 +96,7 @@ int fimc_is_hw_set_param(struct fimc_is *is)
return 0;
}
-int fimc_is_hw_set_tune(struct fimc_is *is)
+static int __maybe_unused fimc_is_hw_set_tune(struct fimc_is *is)
{
fimc_is_hw_wait_intmsr0_intmsd0(is);
--
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 3/3] [media] exynos4-is: Fix potential NULL pointer dereference
dev->of_node could be NULL. Hence check for the same and return before
dereferencing it in the subsequent error message.
Signed-off-by: Sachin Kamat
---
drivers/media/platform/exynos4-is/fimc-lite.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c
b/drivers/media/platform/exynos4-is/fimc-lite.c
index 08fbfed..214bde2 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -1513,6 +1513,9 @@ static int fimc_lite_probe(struct platform_device *pdev)
if (of_id)
drv_data = (struct flite_drvdata *)of_id->data;
fimc->index = of_alias_get_id(dev->of_node, "fimc-lite");
+ } else {
+ dev_err(dev, "device node not found\n");
+ return -EINVAL;
}
if (!drv_data || fimc->index >= drv_data->num_instances ||
--
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 1/3] [media] exynos4-is: Staticize local symbol
__fimc_is_hw_update_param is used only in this file. Make it static.
Signed-off-by: Sachin Kamat
---
drivers/media/platform/exynos4-is/fimc-is-param.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-is-param.c
b/drivers/media/platform/exynos4-is/fimc-is-param.c
index c7e7f69..a353be0 100644
--- a/drivers/media/platform/exynos4-is/fimc-is-param.c
+++ b/drivers/media/platform/exynos4-is/fimc-is-param.c
@@ -56,7 +56,7 @@ static void __fimc_is_hw_update_param_sensor_framerate(struct
fimc_is *is)
__hw_param_copy(dst, src);
}
-int __fimc_is_hw_update_param(struct fimc_is *is, u32 offset)
+static int __fimc_is_hw_update_param(struct fimc_is *is, u32 offset)
{
struct is_param_region *par = &is->is_p_region->parameter;
struct chain_config *cfg = &is->config[is->config_index];
--
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: Doing a v4l-utils-1.0.0 release
Hi Gregor, Let me know when you've branched 1.0.0. I want to merge Bård's work for qv4l2 (openGL support, upcoming audio support and other improvements), but I can't do that until after you made the 1.0.0 branch. Thanks! Hans On 08/01/2013 08:28 PM, Gregor Jasny wrote: > Hello, > > On 6/14/13 9:15 AM, Hans de Goede wrote: >> IIRC the 0.9.x series were meant as development releases leading up to a >> new >> stable 1.0.0 release. Lately there have been no maintenance 0.8.x releases >> and a lot of interesting development going on in the 0.9.x, while at the >> same time there have been no issues reported against 0.9.x (iow it seems >> stable). >> >> So how about taking current master and releasing that as a 1.0.0 release ? > > If nobody objects I'll do a 1.0.0 release this weekend. > > Thanks, > Gregor > > -- > 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
Re: [PATCH 2/2] videobuf2-dma-sg: Replace vb2_dma_sg_desc with sg_table
Hello,
On 7/19/2013 7:02 PM, Ricardo Ribalda Delgado wrote:
Replace the private struct vb2_dma_sg_desc with the struct sg_table so
we can benefit from all the helping functions in lib/scatterlist.c for
things like allocating the sg or compacting the descriptor
marvel-ccic and solo6x10 drivers, that uses this api has been updated
Signed-off-by: Ricardo Ribalda Delgado
Acked-by: Marek Szyprowski
---
drivers/media/platform/marvell-ccic/mcam-core.c| 14 +--
drivers/media/v4l2-core/videobuf2-dma-sg.c | 103
drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 20 ++--
include/media/videobuf2-dma-sg.h | 10 +-
4 files changed, 63 insertions(+), 84 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 64ab91e..0ac51bd 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -1040,16 +1040,16 @@ static int mcam_vb_sg_buf_prepare(struct vb2_buffer *vb)
{
struct mcam_vb_buffer *mvb = vb_to_mvb(vb);
struct mcam_camera *cam = vb2_get_drv_priv(vb->vb2_queue);
- struct vb2_dma_sg_desc *sgd = vb2_dma_sg_plane_desc(vb, 0);
+ struct sg_table *sg_table = vb2_dma_sg_plane_desc(vb, 0);
struct mcam_dma_desc *desc = mvb->dma_desc;
struct scatterlist *sg;
int i;
- mvb->dma_desc_nent = dma_map_sg(cam->dev, sgd->sglist, sgd->num_pages,
- DMA_FROM_DEVICE);
+ mvb->dma_desc_nent = dma_map_sg(cam->dev, sg_table->sgl,
+ sg_table->nents, DMA_FROM_DEVICE);
if (mvb->dma_desc_nent <= 0)
return -EIO; /* Not sure what's right here */
- for_each_sg(sgd->sglist, sg, mvb->dma_desc_nent, i) {
+ for_each_sg(sg_table->sgl, sg, mvb->dma_desc_nent, i) {
desc->dma_addr = sg_dma_address(sg);
desc->segment_len = sg_dma_len(sg);
desc++;
@@ -1060,9 +1060,11 @@ static int mcam_vb_sg_buf_prepare(struct vb2_buffer *vb)
static int mcam_vb_sg_buf_finish(struct vb2_buffer *vb)
{
struct mcam_camera *cam = vb2_get_drv_priv(vb->vb2_queue);
- struct vb2_dma_sg_desc *sgd = vb2_dma_sg_plane_desc(vb, 0);
+ struct sg_table *sg_table = vb2_dma_sg_plane_desc(vb, 0);
- dma_unmap_sg(cam->dev, sgd->sglist, sgd->num_pages, DMA_FROM_DEVICE);
+ if (sg_table)
+ dma_unmap_sg(cam->dev, sg_table->sgl,
+ sg_table->nents, DMA_FROM_DEVICE);
return 0;
}
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index c053605..4b30ad5 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -35,7 +35,9 @@ struct vb2_dma_sg_buf {
struct page **pages;
int write;
int offset;
- struct vb2_dma_sg_desc sg_desc;
+ struct sg_table sg_table;
+ size_t size;
+ unsigned intnum_pages;
atomic_trefcount;
struct vb2_vmarea_handler handler;
};
@@ -46,7 +48,7 @@ static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf
*buf,
gfp_t gfp_flags)
{
unsigned int last_page = 0;
- int size = buf->sg_desc.size;
+ int size = buf->size;
while (size > 0) {
struct page *pages;
@@ -74,12 +76,8 @@ static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf
*buf,
}
split_page(pages, order);
- for (i = 0; i < (1sg_desc.sglist[last_page],
- buf->pages[last_page], PAGE_SIZE, 0);
- last_page++;
- }
+ for (i = 0; i < (1vaddr = NULL;
buf->write = 0;
buf->offset = 0;
- buf->sg_desc.size = size;
+ buf->size = size;
/* size is already page aligned */
- buf->sg_desc.num_pages = size >> PAGE_SHIFT;
-
- buf->sg_desc.sglist = vzalloc(buf->sg_desc.num_pages *
- sizeof(*buf->sg_desc.sglist));
- if (!buf->sg_desc.sglist)
- goto fail_sglist_alloc;
- sg_init_table(buf->sg_desc.sglist, buf->sg_desc.num_pages);
+ buf->
Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag
Hi Rob,
On 2 August 2013 06:03, Rob Clark wrote:
> On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa wrote:
>> Hi Vikas,
>>
>> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
>>> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
>>> connected with resolution 2560x1600, following error occured even with
>>> IOMMU enabled:
>>> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
>>> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>>
>>> This patch fixes the issue by adding a check for IOMMU.
>>>
>>> Signed-off-by: Vikas Sajjan
>>> Signed-off-by: Arun Kumar
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
>>> 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>> @@ -16,6 +16,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include "exynos_drm_drv.h"
>>> #include "exynos_drm_fb.h"
>>> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
>>> drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
>>> unsigned long size;
>>> int ret;
>>> + unsigned int flag;
>>>
>>> DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
>>> sizes->surface_width, sizes->surface_height,
>>> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
>>> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
>>>
>>> /* 0 means to allocate physically continuous memory */
>>> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
>>> + if (!is_drm_iommu_supported(dev))
>>> + flag = 0;
>>> + else
>>> + flag = EXYNOS_BO_NONCONTIG;
>>
>> While noncontig memory might be used for devices that support IOMMU, there
>> should be no problem with using contig memory for them, so this seems more
>> like masking the original problem rather than tracking it down.
>
> it is probably a good idea to not require contig memory when it is not
> needed for performance or functionality (and if it is only
> performance, then fallback gracefully to non-contig).. but yeah, would
> be good to know if this is masking another issue all the same
>
Whats happening with CONTIG flag and with IOMMU, is
__iommu_alloc_buffer() ---> dma_alloc_from_contiguous() and in this
function it fails at
this condition check if (pageno >= cma->count)
So I tried increasing the CONFIG_CMA_SIZE_MBYTES to 24, this check
succeeds and it works well without my patch.
But what about the case where CONFIG_CMA is disabled , yet i want
bigger memory for a device.
I think using IOMMU we can achieve this.
correct me, if i am wrong.
> BR,
> -R
>
>> Could you check why the allocation fails when requesting contiguous
>> memory?
>>
>> Best regards,
>> Tomasz
>>
>> --
>> 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
--
Thanks and Regards
Vikas Sajjan
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] videobuf2-dma-sg: Allocate pages as contiguous as possible
Hello,
On 7/19/2013 7:02 PM, Ricardo Ribalda Delgado wrote:
Most DMA engines have limitations regarding the number of DMA segments
(sg-buffers) that they can handle. Videobuffers can easily spread
through houndreds of pages.
In the previous aproach, the pages were allocated individually, this
could led to the creation houndreds of dma segments (sg-buffers) that
could not be handled by some DMA engines.
This patch tries to minimize the number of DMA segments by using
alloc_pages. In the worst case it will behave as before, but most
of the times it will reduce the number of dma segments
Signed-off-by: Ricardo Ribalda Delgado
Acked-by: Marek Szyprowski
---
drivers/media/v4l2-core/videobuf2-dma-sg.c | 60 +++-
1 file changed, 49 insertions(+), 11 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 16ae3dc..c053605 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -42,10 +42,55 @@ struct vb2_dma_sg_buf {
static void vb2_dma_sg_put(void *buf_priv);
+static int vb2_dma_sg_alloc_compacted(struct vb2_dma_sg_buf *buf,
+ gfp_t gfp_flags)
+{
+ unsigned int last_page = 0;
+ int size = buf->sg_desc.size;
+
+ while (size > 0) {
+ struct page *pages;
+ int order;
+ int i;
+
+ order = get_order(size);
+ /* Dont over allocate*/
+ if ((PAGE_SIZE << order) > size)
+ order--;
+
+ pages = NULL;
+ while (!pages) {
+ pages = alloc_pages(GFP_KERNEL | __GFP_ZERO |
+ __GFP_NOWARN | gfp_flags, order);
+ if (pages)
+ break;
+
+ if (order == 0)
+ while (last_page--) {
+ __free_page(buf->pages[last_page]);
+ return -ENOMEM;
+ }
+ order--;
+ }
+
+ split_page(pages, order);
+ for (i = 0; i < (1sg_desc.sglist[last_page],
+ buf->pages[last_page], PAGE_SIZE, 0);
+ last_page++;
+ }
+
+ size -= PAGE_SIZE << order;
+ }
+
+ return 0;
+}
+
static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long size, gfp_t
gfp_flags)
{
struct vb2_dma_sg_buf *buf;
- int i;
+ int ret;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
@@ -69,14 +114,9 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned
long size, gfp_t gfp_fla
if (!buf->pages)
goto fail_pages_array_alloc;
- for (i = 0; i < buf->sg_desc.num_pages; ++i) {
- buf->pages[i] = alloc_page(GFP_KERNEL | __GFP_ZERO |
- __GFP_NOWARN | gfp_flags);
- if (NULL == buf->pages[i])
- goto fail_pages_alloc;
- sg_set_page(&buf->sg_desc.sglist[i],
- buf->pages[i], PAGE_SIZE, 0);
- }
+ ret = vb2_dma_sg_alloc_compacted(buf, gfp_flags);
+ if (ret)
+ goto fail_pages_alloc;
buf->handler.refcount = &buf->refcount;
buf->handler.put = vb2_dma_sg_put;
@@ -89,8 +129,6 @@ static void *vb2_dma_sg_alloc(void *alloc_ctx, unsigned long
size, gfp_t gfp_fla
return buf;
fail_pages_alloc:
- while (--i >= 0)
- __free_page(buf->pages[i]);
kfree(buf->pages);
fail_pages_array_alloc:
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] drm/exynos: Add check for IOMMU while passing physically continous memory flag
Hi Vikas,
On 1 August 2013 16:49, Vikas Sajjan wrote:
> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> connected with resolution 2560x1600, following error occured even with
> IOMMU enabled:
> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
> [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>
> This patch fixes the issue by adding a check for IOMMU.
>
> Signed-off-by: Vikas Sajjan
> Signed-off-by: Arun Kumar
> ---
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index 8e60bd6..2a8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include "exynos_drm_drv.h"
> #include "exynos_drm_fb.h"
> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
> *helper,
> struct platform_device *pdev = dev->platformdev;
> unsigned long size;
> int ret;
> + unsigned int flag;
>
> DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
> sizes->surface_width, sizes->surface_height,
> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
> *helper,
> size = mode_cmd.pitches[0] * mode_cmd.height;
>
> /* 0 means to allocate physically continuous memory */
This comment is now wrongly placed. Please use EXYNOS_BO_CONTIG instead of 0
and get rid of this comment altogether.
> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> + if (!is_drm_iommu_supported(dev))
> + flag = 0;
> + else
> + flag = EXYNOS_BO_NONCONTIG;
> +
> + exynos_gem_obj = exynos_drm_gem_create(dev, flag, size);
> if (IS_ERR(exynos_gem_obj)) {
> ret = PTR_ERR(exynos_gem_obj);
> goto err_release_framebuffer;
--
With warm regards,
Sachin
--
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] drm/exynos: Add check for IOMMU while passing physically continous memory flag
Hi Vikas,
On 2 August 2013 09:23, Vikas Sajjan wrote:
> Hi Tomasz,
>
>
> On 2 August 2013 04:50, Tomasz Figa wrote:
>>
>> Hi Vikas,
>>
>> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
>> > While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
>> > connected with resolution 2560x1600, following error occured even with
>> > IOMMU enabled:
>> > [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
>> > buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>> >
>> > This patch fixes the issue by adding a check for IOMMU.
>> >
>> > Signed-off-by: Vikas Sajjan
>> > Signed-off-by: Arun Kumar
>> > ---
>> > drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
>> > 1 file changed, 8 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> > b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
>> > 100644
>> > --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> > @@ -16,6 +16,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> >
>> > #include "exynos_drm_drv.h"
>> > #include "exynos_drm_fb.h"
>> > @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
>> > drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
>> > unsigned long size;
>> > int ret;
>> > + unsigned int flag;
>> >
>> > DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
>> > sizes->surface_width, sizes->surface_height,
>> > @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
>> > drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
>> >
>> > /* 0 means to allocate physically continuous memory */
>> > - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
>> > + if (!is_drm_iommu_supported(dev))
>> > + flag = 0;
>> > + else
>> > + flag = EXYNOS_BO_NONCONTIG;
>>
>> While noncontig memory might be used for devices that support IOMMU, there
>> should be no problem with using contig memory for them, so this seems more
>> like masking the original problem rather than tracking it down.
>>
>> Could you check why the allocation fails when requesting contiguous
>> memory?
>>
>
> It is failing if i am giving bigger resolution like 2560x1600, but if
> i try for 1280x780 resolution, it works fine.
> Looks like arm_dma_alloc() is NOT able to allocate bigger buffer of
> size 2560 * 1600 * 4.
You may need to increase the zoneorder (from current default 11 to say
13) if you need large physically contiguous pages.
However I am not sure if it is recommended.
--
With warm regards,
Sachin
--
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: [RFC v2 06/10] exynos5-fimc-is: Adds isp subdev
Hi Sylwester,
On Fri, Jun 21, 2013 at 4:55 AM, Sylwester Nawrocki
wrote:
> On 05/31/2013 03:03 PM, Arun Kumar K wrote:
>>
>> fimc-is driver takes video data input from the ISP video node
>> which is added in this patch. This node accepts Bayer input
>> buffers which is given from the IS sensors.
>>
>> Signed-off-by: Arun Kumar K
>> Signed-off-by: Kilyeon Im
>> ---
>> drivers/media/platform/exynos5-is/fimc-is-isp.c | 438
>> +++
>> drivers/media/platform/exynos5-is/fimc-is-isp.h | 89 +
>> 2 files changed, 527 insertions(+)
>> create mode 100644 drivers/media/platform/exynos5-is/fimc-is-isp.c
>> create mode 100644 drivers/media/platform/exynos5-is/fimc-is-isp.h
>>
[snip]
>> + * Video node ioctl operations
>> + */
>> +static int isp_querycap_output(struct file *file, void *priv,
>> + struct v4l2_capability *cap)
>> +{
>> + strncpy(cap->driver, ISP_DRV_NAME, sizeof(cap->driver) - 1);
>> + strncpy(cap->card, ISP_DRV_NAME, sizeof(cap->card) - 1);
>> + strncpy(cap->bus_info, ISP_DRV_NAME, sizeof(cap->bus_info) - 1);
>> + cap->capabilities = V4L2_CAP_STREAMING |
>> V4L2_CAP_VIDEO_OUTPUT_MPLANE;
>> + cap->device_caps = V4L2_CAP_STREAMING |
>> V4L2_CAP_VIDEO_OUTPUT_MPLANE;
>
>
> cap->capabilities = V4L2_CAP_STREAMING;
>
> cap->device_caps = V4L2_CAP_STREAMING |
> V4L2_CAP_VIDEO_OUTPUT_MPLANE;
>
> This should be:
>
> cap->device_caps = V4L2_CAP_STREAMING;
> cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
>
> Media Controller device nodes must not use V4L2_CAP_VIDEO_{OUTPUT,
> CAPTURE}_(_MPLANE)
> capability flags.
>
If I dont provide any video capabilities, the v4l2-compliance tool
gives a fail :
fail: v4l2-compliance.cpp(298) : node->is_video && !(dcaps & video_caps)
test VIDIOC_QUERYCAP: FAIL
This error doesn't come if I give V4L2_CAP_VIDEO_OUTPUT_MPLANE capability.
One more related error compliance tool gives is :
fail: v4l2-test-formats.cpp(286): Video Output Multiplanar cap not
set, but Video Output Multiplanar formats defined
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL
Shall these errors be ignored?
Regards
Arun
--
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] drm/exynos: Add check for IOMMU while passing physically continous memory flag
Hi Tomasz,
On 2 August 2013 04:50, Tomasz Figa wrote:
>
> Hi Vikas,
>
> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
> > While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> > connected with resolution 2560x1600, following error occured even with
> > IOMMU enabled:
> > [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
> > buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
> >
> > This patch fixes the issue by adding a check for IOMMU.
> >
> > Signed-off-by: Vikas Sajjan
> > Signed-off-by: Arun Kumar
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
> > 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "exynos_drm_drv.h"
> > #include "exynos_drm_fb.h"
> > @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
> > drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
> > unsigned long size;
> > int ret;
> > + unsigned int flag;
> >
> > DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
> > sizes->surface_width, sizes->surface_height,
> > @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
> > drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
> >
> > /* 0 means to allocate physically continuous memory */
> > - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> > + if (!is_drm_iommu_supported(dev))
> > + flag = 0;
> > + else
> > + flag = EXYNOS_BO_NONCONTIG;
>
> While noncontig memory might be used for devices that support IOMMU, there
> should be no problem with using contig memory for them, so this seems more
> like masking the original problem rather than tracking it down.
>
> Could you check why the allocation fails when requesting contiguous
> memory?
>
It is failing if i am giving bigger resolution like 2560x1600, but if
i try for 1280x780 resolution, it works fine.
Looks like arm_dma_alloc() is NOT able to allocate bigger buffer of
size 2560 * 1600 * 4.
Hence i used flag = EXYNOS_BO_NONCONTIG;
>
> Best regards,
> Tomasz
>
--
Thanks and Regards
Vikas Sajjan
--
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: mb86a20s and cx23885
Hi El 01/08/13 15:48, Mauro Carvalho Chehab escribió: > This time it arrived fine, thanks! > > Btw, those changes at mb86a20s are required for it to work, or just alters > somewhat the tuning? > > Regards, > Mauro Without these changes do not work. With the original controller I get: mb86a20s: mb86a20s_read_status: val = 9, status = 0x1f but not video, not sound. That is the reason why I tested with kernel 3.2. Those changes I got to sniff the i2c traffic under windows. I have all traffic from i2c until obtaining image(I did it as the more repetitive than 10 samples). If it helps something I put on the list. Also I use "modprobe cx23885 debug = 3", but I saw nothing significant Thanks, Alfredo -- 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 v5 5/9] v4l: Add media format codes for ARGB8888 and AYUV8888 on 32-bit busses
Signed-off-by: Laurent Pinchart Reviewed-by: Sylwester Nawrocki --- Documentation/DocBook/media/v4l/subdev-formats.xml | 609 + Documentation/DocBook/media_api.tmpl | 6 + include/uapi/linux/v4l2-mediabus.h | 6 +- 3 files changed, 254 insertions(+), 367 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 0c2b1f2..f72c1cc 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -97,31 +97,39 @@ - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Identifier @@ -133,6 +141,14 @@ Bit + 31 + 30 + 29 + 28 + 27 + 26 + 25 + 24 23 22 21 @@ -164,7 +180,7 @@ V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE 0x1001 - &dash-ent-16; + &dash-ent-24; 0 0 0 @@ -178,7 +194,7 @@ - &dash-ent-16; + &dash-ent-24; g3 g2 g1 @@ -192,7 +208,7 @@ V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE 0x1002 - &dash-ent-16; + &dash-ent-24; g3 g2 g1 @@ -206,7 +222,7 @@ - &dash-ent-16; + &dash-ent-24; 0 0 0 @@ -220,7 +236,7 @@ V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE 0x1003 - &dash-ent-16; + &dash-ent-24; 0 r4 r3 @@ -234,7 +250,7 @@ - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -248,7 +264,7 @@ V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE 0x1004 - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -262,7 +278,7 @@ - &dash-ent-16; + &dash-ent-24; 0 r4 r3 @@ -276,7 +292,7 @@ V4L2_MBUS_FMT_BGR565_2X8_BE 0x1005 - &dash-ent-16; + &dash-ent-24; b4 b3 b2 @@ -290,7 +306,7 @@ - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -304,7 +320,7 @@ V4L2_MBUS_FMT_BGR565_2X8_LE 0x1006 - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -318,7 +334,7 @@ - &dash-ent-16; + &dash-ent-24; b4 b3 b2 @@ -332,7 +348,7 @@ V4L2_MBUS_FMT_RGB565_2X8_BE 0x1007 - &dash-ent-16; + &dash-ent-24; r4 r3 r2 @@ -346,7 +362,7 @@ - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -360,7 +376,7 @@ V4L2_MBUS_FMT_RGB565_2X8_LE 0x1008 - &dash-ent-16; + &dash-ent-24; g2 g1 g0 @@ -374,7 +390,7 @@ - &dash-ent-16; + &dash-ent-24; r4 r3 r2 @@ -388,12 +404,7 @@ V4L2_MBUS_FMT_RGB666_1X18 0x1009 - - - - - - - - - - - - + &dash-ent-14; r5 r4 r3 @@ -417,6 +428,7 @@ V4L2_MBUS_FMT_RGB888_1X24 0x100a + &
[PATCH v5 8/9] vsp1: Fix lack of the sink entity registration for enabled links
From: Katsuya Matsubara Each source entity maintains a pointer to the counterpart sink entity while an enabled link connects them. It should be managed by the setup_link callback in the media controller framework at runtime. However, enabled links which connect RPFs and WPFs that have an equivalent index number are created during initialization. This registers the pointer to a sink entity from the source entity when an enabled link is created. Signed-off-by: Katsuya Matsubara Signed-off-by: Laurent Pinchart Acked-by: Sakari Ailus --- drivers/media/platform/vsp1/vsp1_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/vsp1/vsp1_drv.c b/drivers/media/platform/vsp1/vsp1_drv.c index e58e49c..41dd891 100644 --- a/drivers/media/platform/vsp1/vsp1_drv.c +++ b/drivers/media/platform/vsp1/vsp1_drv.c @@ -101,6 +101,9 @@ static int vsp1_create_links(struct vsp1_device *vsp1, struct vsp1_entity *sink) entity, pad, flags); if (ret < 0) return ret; + + if (flags & MEDIA_LNK_FL_ENABLED) + source->sink = entity; } } -- 1.8.1.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 v5 9/9] vsp1: Use the maximum number of entities defined in platform data
From: Katsuya Matsubara
The VSP1 driver allows to define the maximum number of each module
such as RPF, WPF, and UDS in a platform data definition.
This suppresses operations for nonexistent or unused modules.
Signed-off-by: Katsuya Matsubara
Signed-off-by: Laurent Pinchart
Acked-by: Sakari Ailus
---
drivers/media/platform/vsp1/vsp1_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index 41dd891..8700842 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -35,7 +35,7 @@ static irqreturn_t vsp1_irq_handler(int irq, void *data)
irqreturn_t ret = IRQ_NONE;
unsigned int i;
- for (i = 0; i < VPS1_MAX_WPF; ++i) {
+ for (i = 0; i < vsp1->pdata->wpf_count; ++i) {
struct vsp1_rwpf *wpf = vsp1->wpf[i];
struct vsp1_pipeline *pipe;
u32 status;
@@ -243,7 +243,7 @@ static int vsp1_device_init(struct vsp1_device *vsp1)
/* Reset any channel that might be running. */
status = vsp1_read(vsp1, VI6_STATUS);
- for (i = 0; i < VPS1_MAX_WPF; ++i) {
+ for (i = 0; i < vsp1->pdata->wpf_count; ++i) {
unsigned int timeout;
if (!(status & VI6_STATUS_SYS_ACT(i)))
@@ -267,10 +267,10 @@ static int vsp1_device_init(struct vsp1_device *vsp1)
vsp1_write(vsp1, VI6_CLK_DCSWT, (8 << VI6_CLK_DCSWT_CSTPW_SHIFT) |
(8 << VI6_CLK_DCSWT_CSTRW_SHIFT));
- for (i = 0; i < VPS1_MAX_RPF; ++i)
+ for (i = 0; i < vsp1->pdata->rpf_count; ++i)
vsp1_write(vsp1, VI6_DPR_RPF_ROUTE(i), VI6_DPR_NODE_UNUSED);
- for (i = 0; i < VPS1_MAX_UDS; ++i)
+ for (i = 0; i < vsp1->pdata->uds_count; ++i)
vsp1_write(vsp1, VI6_DPR_UDS_ROUTE(i), VI6_DPR_NODE_UNUSED);
vsp1_write(vsp1, VI6_DPR_SRU_ROUTE, VI6_DPR_NODE_UNUSED);
--
1.8.1.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 v5 6/9] v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats
NV16M and NV61M are planar YCbCr 4:2:2 and YCrCb 4:2:2 formats with a
luma plane followed by an interleaved chroma plane. The planes are not
required to be contiguous in memory, and the formats can only be used
with the multi-planar formats API.
Signed-off-by: Laurent Pinchart
Reviewed-by: Sylwester Nawrocki
Reviewed-by: Sakari Ailus
---
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 171 +++
Documentation/DocBook/media/v4l/pixfmt.xml | 1 +
include/uapi/linux/videodev2.h | 2 +
3 files changed, 174 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
new file mode 100644
index 000..afec039
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -0,0 +1,171 @@
+
+
+ V4L2_PIX_FMT_NV16M ('NM16'), V4L2_PIX_FMT_NV61M
('NM61')
+ &manvol;
+
+
+ V4L2_PIX_FMT_NV16M
+ V4L2_PIX_FMT_NV61M
+ Variation of V4L2_PIX_FMT_NV16 and
V4L2_PIX_FMT_NV61 with planes
+ non contiguous in memory.
+
+
+ Description
+
+ This is a multi-planar, two-plane version of the YUV 4:2:0 format.
+The three components are separated into two sub-images or planes.
+V4L2_PIX_FMT_NV16M differs from
V4L2_PIX_FMT_NV16
+ in that the two planes are non-contiguous in memory, i.e. the
chroma
+plane do not necessarily immediately follows the luma plane.
+The luminance data occupies the first plane. The Y plane has one byte per
pixel.
+In the second plane there is a chrominance data with alternating chroma
samples.
+The CbCr plane is the same width and height, in bytes, as the Y plane.
+Each CbCr pair belongs to four pixels. For example,
+Cb0/Cr0 belongs to
+Y'00, Y'01,
+Y'10, Y'11.
+V4L2_PIX_FMT_NV61M is the same as
V4L2_PIX_FMT_NV16M
+except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr
byte.
+
+ V4L2_PIX_FMT_NV16M and
+V4L2_PIX_FMT_NV61M are intended to be used only in drivers
+and applications that support the multi-planar API, described in
+.
+
+
+ V4L2_PIX_FMT_NV16M 4 × 4 pixel
image
+
+
+ Byte Order.
+ Each cell is one byte.
+
+
+
+
+
+ start0 + 0:
+ Y'00
+ Y'01
+ Y'02
+ Y'03
+
+
+ start0 + 4:
+ Y'10
+ Y'11
+ Y'12
+ Y'13
+
+
+ start0 + 8:
+ Y'20
+ Y'21
+ Y'22
+ Y'23
+
+
+ start0 + 12:
+ Y'30
+ Y'31
+ Y'32
+ Y'33
+
+
+
+
+
+ start1 + 0:
+ Cb00
+ Cr00
+ Cb02
+ Cr02
+
+
+ start1 + 4:
+ Cb10
+ Cr10
+ Cb12
+ Cr12
+
+
+ start1 + 8:
+ Cb20
+ Cr20
+ Cb22
+ Cr22
+
+
+ start1 + 12:
+ Cb30
+ Cr30
+ Cb32
+ Cr32
+
+
+
+
+
+
+
+
+ Color Sample Location.
+
+
+
+
+
+
+
01
+ 23
+
+
+ 0
+
YY
+ YY
+
+
+
+
C
+ C
+
+
+ 1
+
YY
+ YY
+
+
+
+
C
+ C
+
+
+
+
+
+ 2
+
YY
+ YY
+
+
+
+
C
+ C
+
+
[PATCH v5 2/9] Documentation: media: Clarify the VIDIOC_CREATE_BUFS format requirements
The VIDIOC_CREATE_BUFS ioctl takes a format argument that must contain a valid format supported by the driver. Clarify the documentation. Signed-off-by: Laurent Pinchart --- Documentation/DocBook/media/v4l/vidioc-create-bufs.xml | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml index cd99436..407937a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml @@ -69,10 +69,11 @@ the v4l2_create_buffers structure. They set the structure, to the respective stream or buffer type. count must be set to the number of required buffers. memory specifies the required I/O method. The -format field shall typically be filled in using -either the VIDIOC_TRY_FMT or -VIDIOC_G_FMT ioctl(). Additionally, applications can adjust -sizeimage fields to fit their specific needs. The +format field must be a valid format supported by the +driver. Applications shall typically fill it using either the +VIDIOC_TRY_FMT or VIDIOC_G_FMT +ioctl(). Any format that would be modified by the +VIDIOC_TRY_FMT ioctl() will be rejected with an error. The reserved array must be zeroed. When the ioctl is called with a pointer to this structure the driver @@ -144,9 +145,9 @@ mapped I/O. EINVAL - The buffer type (type field) or the -requested I/O method (memory) is not -supported. + The buffer type (type field), +requested I/O method (memory) or format +(format field) is not valid. -- 1.8.1.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 v5 3/9] videobuf2: Clarify queue_setup() and buf_prepare() usage documentation
Explain how the two operations must handle formats and validate buffer
sizes when used with VIDIOC_CREATE_BUFS.
Signed-off-by: Laurent Pinchart
---
include/media/videobuf2-core.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index d88a098..6781258 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -219,8 +219,9 @@ struct vb2_buffer {
* configured format and *num_buffers is the total number
* of buffers, that are being allocated. When called from
* VIDIOC_CREATE_BUFS, fmt != NULL and it describes the
- * target frame format. In this case *num_buffers are being
- * allocated additionally to q->num_buffers.
+ * target frame format (if the format isn't valid the
+ * callback must return -EINVAL). In this case *num_buffers
+ * are being allocated additionally to q->num_buffers.
* @wait_prepare: release any locks taken while calling vb2 functions;
* it is called before an ioctl needs to wait for a new
* buffer to arrive; required to avoid a deadlock in
@@ -236,8 +237,10 @@ struct vb2_buffer {
* @buf_prepare: called every time the buffer is queued from userspace
* and from the VIDIOC_PREPARE_BUF ioctl; drivers may
* perform any initialization required before each hardware
- * operation in this callback; if an error is returned, the
- * buffer will not be queued in driver; optional
+ * operation in this callback; drivers that support
+ * VIDIOC_CREATE_BUFS must also validate the buffer size;
+ * if an error is returned, the buffer will not be queued
+ * in driver; optional
* @buf_finish:called before every dequeue of the buffer back
to
* userspace; drivers may perform any operations required
* before userspace accesses the buffer; optional
--
1.8.1.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 v5 4/9] v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value
The V4L2_MBUS_FMT_YUV10_1X30 code is documented as being equal to 0x2014, while the v4l2-mediabus.h header defines it as 0x2016. Fix the documentation. Signed-off-by: Laurent Pinchart Acked-by: Sakari Ailus --- Documentation/DocBook/media/v4l/subdev-formats.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index adc6198..0c2b1f2 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -2574,7 +2574,7 @@ V4L2_MBUS_FMT_YUV10_1X30 - 0x2014 + 0x2016 y9 y8 -- 1.8.1.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 v5 0/9] Renesas VSP1 driver
Hello, Here's the fifth version of the VSP1 engine (a Video Signal Processor found in several Renesas R-Car SoCs) driver. This version adds two additional documentation clarification patches that I hope won't trigger another round of review :-) The VSP1 is a video processing engine that includes a blender, scalers, filters and statistics computation. Configurable data path routing logic allows ordering the internal blocks in a flexible way, making this driver a prime candidate for the media controller API. Due to the configurable nature of the pipeline the driver doesn't use the V4L2 mem-to-mem framework, even though the device usually operates in memory to memory mode. Only the read pixel formatters, up/down scalers, write pixel formatters and LCDC interface are supported at this stage. The patch series starts with a fix for the media controller graph traversal code, three documentation fixes and new pixel format and media bus code definitions. The last three patches finally add the VSP1 driver and fix two issues (I haven't squashed the patches together to keep proper attribution). Changes since v1: - Updated to the v3.11 media controller API changes - Only add the LIF entity to the entities list when the LIF is present - Added a MODULE_ALIAS() - Fixed file descriptions in comment blocks - Removed function prototypes for the unimplemented destroy functions - Fixed a typo in the HST register name - Fixed format propagation for the UDS entities - Added v4l2_capability::device_caps support - Prefix the device name with "platform:" in bus_info - Zero the v4l2_pix_format priv field in the internal try format handler - Use vb2_is_busy() instead of vb2_is_streaming() when setting the format - Use the vb2_ioctl_* handlers where possible Changes since v2: - Use a bitmap to track visited entities during graph traversal - Fixed a typo in the V4L2_MBUS_FMT_ARGB888_1X32 documentation - Fix register macros that were missing a n argument - Mask unused bits when clearing the interrupt status register - Explain why stride alignment to 128 bytes is needed - Use the aligned stride value when computing the image size - Assorted cosmetic changes Changes since v3: - Handle timeout errors when resetting WPFs - Use DECLARE_BITMAP - Update the NV16M/NV61M documentation to mention the multi-planar API for NV61M Changes since v4: - Clarify the VIDIOC_CREATE_BUFS format requirements in the V4L2 documentation - Clarify vb2 queue_setup() and buf_prepare() usage documentation - Remove duplicate printk's in devm_* error paths - Implement VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF support - Reject invalid buffers in the .buffer_queue() handler Katsuya Matsubara (2): vsp1: Fix lack of the sink entity registration for enabled links vsp1: Use the maximum number of entities defined in platform data Laurent Pinchart (7): media: Add support for circular graph traversal Documentation: media: Clarify the VIDIOC_CREATE_BUFS format requirements videobuf2: Clarify queue_setup() and buf_prepare() usage documentation v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value v4l: Add media format codes for ARGB and AYUV on 32-bit busses v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats v4l: Renesas R-Car VSP1 driver Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 171 +++ Documentation/DocBook/media/v4l/pixfmt.xml |1 + Documentation/DocBook/media/v4l/subdev-formats.xml | 611 -- .../DocBook/media/v4l/vidioc-create-bufs.xml | 15 +- Documentation/DocBook/media_api.tmpl |6 + drivers/media/media-entity.c | 14 +- drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile|2 + drivers/media/platform/vsp1/Makefile |5 + drivers/media/platform/vsp1/vsp1.h | 73 ++ drivers/media/platform/vsp1/vsp1_drv.c | 495 drivers/media/platform/vsp1/vsp1_entity.c | 181 +++ drivers/media/platform/vsp1/vsp1_entity.h | 68 ++ drivers/media/platform/vsp1/vsp1_lif.c | 238 drivers/media/platform/vsp1/vsp1_lif.h | 37 + drivers/media/platform/vsp1/vsp1_regs.h| 581 ++ drivers/media/platform/vsp1/vsp1_rpf.c | 209 drivers/media/platform/vsp1/vsp1_rwpf.c| 124 ++ drivers/media/platform/vsp1/vsp1_rwpf.h| 53 + drivers/media/platform/vsp1/vsp1_uds.c | 346 ++ drivers/media/platform/vsp1/vsp1_uds.h | 40 + drivers/media/platform/vsp1/vsp1_video.c | 1208 drivers/media/platform/vsp1/vsp1_video.h | 144 +++ drivers/media/platform/vsp1/vsp1_wpf.c | 233 include/linux/platform_data/vsp1.h | 25 + include/media/media-entity.h |4 + include/media/videobuf2-core.h
[PATCH v5 1/9] media: Add support for circular graph traversal
The graph traversal API (media_entity_graph_walk_*) doesn't support
cyclic graphs and will fail to correctly walk a graph when circular
links exist. Support circular graph traversal by checking whether an
entity has already been visited before pushing it to the stack.
Signed-off-by: Laurent Pinchart
Acked-by: Sakari Ailus
---
drivers/media/media-entity.c | 14 +++---
include/media/media-entity.h | 4
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index cb30ffb..2c286c3 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -20,6 +20,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#include
#include
#include
#include
@@ -121,7 +122,6 @@ static struct media_entity *stack_pop(struct
media_entity_graph *graph)
return entity;
}
-#define stack_peek(en) ((en)->stack[(en)->top - 1].entity)
#define link_top(en) ((en)->stack[(en)->top].link)
#define stack_top(en) ((en)->stack[(en)->top].entity)
@@ -140,6 +140,12 @@ void media_entity_graph_walk_start(struct
media_entity_graph *graph,
{
graph->top = 0;
graph->stack[graph->top].entity = NULL;
+ bitmap_zero(graph->entities, MEDIA_ENTITY_ENUM_MAX_ID);
+
+ if (WARN_ON(entity->id >= MEDIA_ENTITY_ENUM_MAX_ID))
+ return;
+
+ __set_bit(entity->id, graph->entities);
stack_push(graph, entity);
}
EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
@@ -180,9 +186,11 @@ media_entity_graph_walk_next(struct media_entity_graph
*graph)
/* Get the entity in the other end of the link . */
next = media_entity_other(entity, link);
+ if (WARN_ON(next->id >= MEDIA_ENTITY_ENUM_MAX_ID))
+ return NULL;
- /* Was it the entity we came here from? */
- if (next == stack_peek(graph)) {
+ /* Has the entity already been visited? */
+ if (__test_and_set_bit(next->id, graph->entities)) {
link_top(graph)++;
continue;
}
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 06bacf9..10df551 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -23,6 +23,7 @@
#ifndef _MEDIA_ENTITY_H
#define _MEDIA_ENTITY_H
+#include
#include
#include
@@ -113,12 +114,15 @@ static inline u32 media_entity_subtype(struct
media_entity *entity)
}
#define MEDIA_ENTITY_ENUM_MAX_DEPTH16
+#define MEDIA_ENTITY_ENUM_MAX_ID 64
struct media_entity_graph {
struct {
struct media_entity *entity;
int link;
} stack[MEDIA_ENTITY_ENUM_MAX_DEPTH];
+
+ DECLARE_BITMAP(entities, MEDIA_ENTITY_ENUM_MAX_ID);
int top;
};
--
1.8.1.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] drm/exynos: Add check for IOMMU while passing physically continous memory flag
On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa wrote:
> Hi Vikas,
>
> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
>> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
>> connected with resolution 2560x1600, following error occured even with
>> IOMMU enabled:
>> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
>> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>>
>> This patch fixes the issue by adding a check for IOMMU.
>>
>> Signed-off-by: Vikas Sajjan
>> Signed-off-by: Arun Kumar
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
>> 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>> @@ -16,6 +16,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "exynos_drm_drv.h"
>> #include "exynos_drm_fb.h"
>> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
>> drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
>> unsigned long size;
>> int ret;
>> + unsigned int flag;
>>
>> DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
>> sizes->surface_width, sizes->surface_height,
>> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
>> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
>>
>> /* 0 means to allocate physically continuous memory */
>> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
>> + if (!is_drm_iommu_supported(dev))
>> + flag = 0;
>> + else
>> + flag = EXYNOS_BO_NONCONTIG;
>
> While noncontig memory might be used for devices that support IOMMU, there
> should be no problem with using contig memory for them, so this seems more
> like masking the original problem rather than tracking it down.
it is probably a good idea to not require contig memory when it is not
needed for performance or functionality (and if it is only
performance, then fallback gracefully to non-contig).. but yeah, would
be good to know if this is masking another issue all the same
BR,
-R
> Could you check why the allocation fails when requesting contiguous
> memory?
>
> Best regards,
> Tomasz
>
> --
> 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
Re: [PATCH v4 5/7] v4l: Renesas R-Car VSP1 driver
Hi Sylwester,
On Friday 02 August 2013 00:31:15 Sylwester Nawrocki wrote:
> On 08/01/2013 12:03 AM, Laurent Pinchart wrote:
> > On Wednesday 31 July 2013 23:02:05 Sylwester Nawrocki wrote:
> >> On 07/31/2013 05:52 PM, Laurent Pinchart wrote:
> >>> The VSP1 is a video processing engine that includes a blender, scalers,
> >>> filters and statistics computation. Configurable data path routing logic
> >>> allows ordering the internal blocks in a flexible way.
> >>>
> >>> Due to the configurable nature of the pipeline the driver implements the
> >>> media controller API and doesn't use the V4L2 mem-to-mem framework, even
> >>> though the device usually operates in memory to memory mode.
> >>>
> >>> Only the read pixel formatters, up/down scalers, write pixel formatters
> >>> and LCDC interface are supported at this stage.
> >>>
> >>> Signed-off-by: Laurent
> >>> Pinchart
>
> [...]
>
> >>> +static int vsp1_pipeline_stop(struct vsp1_pipeline *pipe)
> >>> +{
> >>> + struct vsp1_entity *entity;
> >>> + unsigned long flags;
> >>> + int ret;
> >>> +
> >>> + spin_lock_irqsave(&pipe->irqlock, flags);
> >>> + pipe->state = VSP1_PIPELINE_STOPPING;
> >>> + spin_unlock_irqrestore(&pipe->irqlock, flags);
> >>> +
> >>> + ret = wait_event_timeout(pipe->wq, pipe->state ==
> >>> VSP1_PIPELINE_STOPPED,
> >>> + msecs_to_jiffies(500));
> >>> + ret = ret == 0 ? -ETIMEDOUT : 0;
> >>
> >> Wouldn't be -ETIME more appropriate ?
> >>
> >> #defineETIME 62 /* Timer expired */
> >> ...
> >> #defineETIMEDOUT 110 /* Connection timed out */
> >
> > $ find Documentation/ -type f -exec egrep -- ETIME[^DO] {} \; | wc
> >7 45 347
> > $ find Documentation/ -type f -exec egrep -- ETIMED?OUT {} \; | wc
> > 22 1351162
> >
> > The only two places where ETIME is used in the Documentation are USB and
> > the RxRPC network protocol.
> >
> > $ find drivers/ -type f -name \*.[ch] -exec grep -- -ETIME[^DO] {} \; | wc
> > 29510377339
> > $ find drivers/ -type f -name \*.[ch] -exec grep -- -ETIMEDOUT {} \; | wc
> > 11563769 30590
> >
> > According to man errno, ETIME seems to be related to XSI STREAMS. I'm fine
> > with both, but it seems the kernel is goind towards -ETIMEDOUT.
>
> Indeed, ETIMEDOUT seems to be more widely used. It's a bit strange because
> "Connection timed out" looks like a network specific error message and ETIME
> ("Timer expired") appeared more suitable for cases as above.
>
> I guess it better to stay with ETIMEDOUT then.
OK. It's easier as well, no change needed :-)
> >>> + list_for_each_entry(entity,&pipe->entities, list_pipe) {
> >>> + if (entity->route)
> >>> + vsp1_write(entity->vsp1, entity->route,
> >>> +VI6_DPR_NODE_UNUSED);
> >>> +
> >>> + v4l2_subdev_call(&entity->subdev, video, s_stream, 0);
> >>> + }
> >>> +
> >>> + return ret;
> >>> +}
> >>
> >> [...]
> >>
> >>> +/*
> >>> --
> >>> + * videobuf2 Queue Operations
> >>> + */
> >>> +
> >>> +static int
> >>> +vsp1_video_queue_setup(struct vb2_queue *vq, const struct v4l2_format
> >>> *fmt,
> >>> + unsigned int *nbuffers, unsigned int *nplanes,
> >>> + unsigned int sizes[], void *alloc_ctxs[])
> >>> +{
> >>> + struct vsp1_video *video = vb2_get_drv_priv(vq);
> >>> + struct v4l2_pix_format_mplane *format =&video->format;
> >>> + unsigned int i;
> >>
> >> If you don't support VIDIOC_CREATE_BUFS ioctl then there should probably
> >>
> >> be at least something like:
> >>if (fmt)
> >>
> >>return -EINVAL;
> >>
> >> But it's likely better to add proper handling of 'fmt' right away.
> >
> > OK, I will do so. What is the driver supposed to do when *fmt isn't
> > supported ? Use the closest format as would be returned by try_format() ?
>
> Normally user space should pass valid format, as returned from
> VIDIOC_TRY_FMT or VIDIOC_G_FMT (this is what V4L2 spec says, as you may
> already know).
>
> The drivers I wrote just return -EINVAL if an unsupported fourcc is passed.
> I'm not sure if this is the behaviour we want in general. I'm inclined to
> keep VIDIOC_CREATE_BUFS simple and require user space to pass supported
> formats, otherwise the ioctl would fail. Applications anyway have to verify
> the format, e.g. with VIDIOC_TRY_FMT.
I agree with that, applications should pass a valid format to
VIDIOC_CREATE_BUFS. I will thus return -EINVAL if any of the format fields is
not valid (most likely by running the format through TRY_FMT and check if
anything changes).
> In any case it would be nice to have the expected behaviour documented in
> the videobuf2-core.h header. And perhaps in the VIDIOC_CREATE_BUFS ioctl
> DocBook section.
That's a good idea. I'll submit patches.
> > I suppose this also implies that buffer_prepare() should check whether the
> > buffer matches the current for
[PATCH V3 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN
It's convenient to have ethernet mac addresses use
ETH_ALEN to be able to grep for them a bit easier and
also to ensure that the addresses are __aligned(2).
Add #include as necessary.
Signed-off-by: Joe Perches
Acked-by: Mauro Carvalho Chehab
---
include/linux/dm9000.h | 4 ++-
include/linux/fs_enet_pd.h | 3 ++-
include/linux/ieee80211.h | 59 +
include/linux/mlx4/device.h | 11
include/linux/mlx4/qp.h | 5 ++--
include/linux/mv643xx_eth.h | 3 ++-
include/linux/sh_eth.h | 3 ++-
include/linux/smsc911x.h| 3 ++-
include/linux/uwb/spec.h| 5 ++--
include/media/tveeprom.h| 4 ++-
include/net/irda/irlan_common.h | 3 ++-
11 files changed, 58 insertions(+), 45 deletions(-)
diff --git a/include/linux/dm9000.h b/include/linux/dm9000.h
index 96e8769..841925f 100644
--- a/include/linux/dm9000.h
+++ b/include/linux/dm9000.h
@@ -14,6 +14,8 @@
#ifndef __DM9000_PLATFORM_DATA
#define __DM9000_PLATFORM_DATA __FILE__
+#include
+
/* IO control flags */
#define DM9000_PLATF_8BITONLY (0x0001)
@@ -27,7 +29,7 @@
struct dm9000_plat_data {
unsigned intflags;
- unsigned char dev_addr[6];
+ unsigned char dev_addr[ETH_ALEN];
/* allow replacement IO routines */
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 51b7934..343d82a 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -18,6 +18,7 @@
#include
#include
+#include
#include
#define FS_ENET_NAME "fs_enet"
@@ -135,7 +136,7 @@ struct fs_platform_info {
const struct fs_mii_bus_info *bus_info;
int rx_ring, tx_ring; /* number of buffers on rx */
- __u8 macaddr[6];/* mac address */
+ __u8 macaddr[ETH_ALEN]; /* mac address */
int rx_copybreak; /* limit we copy small frames */
int use_napi; /* use NAPI*/
int napi_weight;/* NAPI weight */
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index b0dc87a..4e101af 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -16,6 +16,7 @@
#define LINUX_IEEE80211_H
#include
+#include
#include
/*
@@ -209,28 +210,28 @@ static inline u16 ieee80211_sn_sub(u16 sn1, u16 sn2)
struct ieee80211_hdr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
- u8 addr4[6];
+ u8 addr4[ETH_ALEN];
} __packed __aligned(2);
struct ieee80211_hdr_3addr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
} __packed __aligned(2);
struct ieee80211_qos_hdr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
__le16 qos_ctrl;
} __packed __aligned(2);
@@ -608,8 +609,8 @@ struct ieee80211s_hdr {
u8 flags;
u8 ttl;
__le32 seqnum;
- u8 eaddr1[6];
- u8 eaddr2[6];
+ u8 eaddr1[ETH_ALEN];
+ u8 eaddr2[ETH_ALEN];
} __packed __aligned(2);
/* Mesh flags */
@@ -758,7 +759,7 @@ struct ieee80211_rann_ie {
u8 rann_flags;
u8 rann_hopcount;
u8 rann_ttl;
- u8 rann_addr[6];
+ u8 rann_addr[ETH_ALEN];
__le32 rann_seq;
__le32 rann_interval;
__le32 rann_metric;
@@ -802,9 +803,9 @@ enum ieee80211_vht_opmode_bits {
struct ieee80211_mgmt {
__le16 frame_control;
__le16 duration;
- u8 da[6];
- u8 sa[6];
- u8 bssid[6];
+ u8 da[ETH_ALEN];
+ u8 sa[ETH_ALEN];
+ u8 bssid[ETH_ALEN];
__le16 seq_ctrl;
union {
struct {
@@ -833,7 +834,7 @@ struct ieee80211_mgmt {
struct {
__le16 capab_info;
__le16 listen_interval;
- u8 current_ap[6];
+ u8 current_ap[ETH_ALEN];
/* followed by SSID and Supported rates */
u8 variable[0];
} __packed reassoc_req;
@@ -966,21 +967,21 @@ struct ieee80211_vendor_ie {
struct ieee80211_rts {
__le16 frame_control;
__le16 duration;
- u8 ra[6];
- u8 ta[6];
+ u8 ra[ETH_ALEN];
+ u8 ta[ETH_ALEN];
} __packed __aligned(2);
struct ieee80211_cts {
__le16 frame_control;
__le16 duration;
- u8 ra[6];
+ u8 ra[ETH_ALEN];
} __packed __aligned(2);
struct ieee80211_
[PATCH V3 0/3] networking: Use ETH_ALEN where appropriate
Convert the uses mac addresses to ETH_ALEN so it's easier to find and verify where mac addresses need to be __aligned(2) Change in V2: - Remove include/acpi/actbl2.h conversion It's a file copied from outside ACPI sources Changes in V3: - Don't move the pasemi_mac.h mac address to be aligned(2) Just note that it's unaligned. Joe Perches (3): uapi: Convert some uses of 6 to ETH_ALEN include: Convert ethernet mac address declarations to use ETH_ALEN ethernet: Convert mac address uses of 6 to ETH_ALEN drivers/net/ethernet/8390/ax88796.c| 4 +- drivers/net/ethernet/amd/pcnet32.c | 6 +-- drivers/net/ethernet/broadcom/cnic_if.h| 6 +-- drivers/net/ethernet/dec/tulip/tulip_core.c| 8 +-- drivers/net/ethernet/i825xx/sun3_82586.h | 4 +- drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 2 +- drivers/net/ethernet/nuvoton/w90p910_ether.c | 4 +- drivers/net/ethernet/pasemi/pasemi_mac.c | 13 ++--- drivers/net/ethernet/pasemi/pasemi_mac.h | 2 +- drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 4 +- drivers/net/ethernet/qlogic/qlge/qlge.h| 2 +- include/linux/dm9000.h | 4 +- include/linux/fs_enet_pd.h | 3 +- include/linux/ieee80211.h | 59 +++--- include/linux/mlx4/device.h| 11 ++-- include/linux/mlx4/qp.h| 5 +- include/linux/mv643xx_eth.h| 3 +- include/linux/sh_eth.h | 3 +- include/linux/smsc911x.h | 3 +- include/linux/uwb/spec.h | 5 +- include/media/tveeprom.h | 4 +- include/net/irda/irlan_common.h| 3 +- include/uapi/linux/dn.h| 3 +- include/uapi/linux/if_bridge.h | 3 +- include/uapi/linux/netfilter_bridge/ebt_802_3.h| 5 +- include/uapi/linux/netfilter_ipv4/ipt_CLUSTERIP.h | 3 +- include/uapi/linux/virtio_net.h| 2 +- include/uapi/linux/wimax/i2400m.h | 4 +- 28 files changed, 99 insertions(+), 79 deletions(-) -- 1.8.1.2.459.gbcd45b4.dirty -- 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] drm/exynos: Add check for IOMMU while passing physically continous memory flag
Hi Vikas,
On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:
> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
> connected with resolution 2560x1600, following error occured even with
> IOMMU enabled:
> [0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
> buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
>
> This patch fixes the issue by adding a check for IOMMU.
>
> Signed-off-by: Vikas Sajjan
> Signed-off-by: Arun Kumar
> ---
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a8
> 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include "exynos_drm_drv.h"
> #include "exynos_drm_fb.h"
> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct
> drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;
> unsigned long size;
> int ret;
> + unsigned int flag;
>
> DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
> sizes->surface_width, sizes->surface_height,
> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct
> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;
>
> /* 0 means to allocate physically continuous memory */
> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
> + if (!is_drm_iommu_supported(dev))
> + flag = 0;
> + else
> + flag = EXYNOS_BO_NONCONTIG;
While noncontig memory might be used for devices that support IOMMU, there
should be no problem with using contig memory for them, so this seems more
like masking the original problem rather than tracking it down.
Could you check why the allocation fails when requesting contiguous
memory?
Best regards,
Tomasz
--
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 v4 5/7] v4l: Renesas R-Car VSP1 driver
Hi Laurent,
On 08/01/2013 12:03 AM, Laurent Pinchart wrote:
On Wednesday 31 July 2013 23:02:05 Sylwester Nawrocki wrote:
On 07/31/2013 05:52 PM, Laurent Pinchart wrote:
The VSP1 is a video processing engine that includes a blender, scalers,
filters and statistics computation. Configurable data path routing logic
allows ordering the internal blocks in a flexible way.
Due to the configurable nature of the pipeline the driver implements the
media controller API and doesn't use the V4L2 mem-to-mem framework, even
though the device usually operates in memory to memory mode.
Only the read pixel formatters, up/down scalers, write pixel formatters
and LCDC interface are supported at this stage.
Signed-off-by: Laurent Pinchart
[...]
+static int vsp1_pipeline_stop(struct vsp1_pipeline *pipe)
+{
+ struct vsp1_entity *entity;
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(&pipe->irqlock, flags);
+ pipe->state = VSP1_PIPELINE_STOPPING;
+ spin_unlock_irqrestore(&pipe->irqlock, flags);
+
+ ret = wait_event_timeout(pipe->wq, pipe->state ==
VSP1_PIPELINE_STOPPED,
+msecs_to_jiffies(500));
+ ret = ret == 0 ? -ETIMEDOUT : 0;
Wouldn't be -ETIME more appropriate ?
#define ETIME 62 /* Timer expired */
...
#define ETIMEDOUT 110 /* Connection timed out */
$ find Documentation/ -type f -exec egrep -- ETIME[^DO] {} \; | wc
7 45 347
$ find Documentation/ -type f -exec egrep -- ETIMED?OUT {} \; | wc
22 1351162
The only two places where ETIME is used in the Documentation are USB and the
RxRPC network protocol.
$ find drivers/ -type f -name \*.[ch] -exec grep -- -ETIME[^DO] {} \; | wc
29510377339
$ find drivers/ -type f -name \*.[ch] -exec grep -- -ETIMEDOUT {} \; | wc
11563769 30590
According to man errno, ETIME seems to be related to XSI STREAMS. I'm fine
with both, but it seems the kernel is goind towards -ETIMEDOUT.
Indeed, ETIMEDOUT seems to be more widely used. It's a bit strange because
"Connection timed out" looks like a network specific error message and ETIME
("Timer expired") appeared more suitable for cases as above.
I guess it better to stay with ETIMEDOUT then.
+ list_for_each_entry(entity,&pipe->entities, list_pipe) {
+ if (entity->route)
+ vsp1_write(entity->vsp1, entity->route,
+ VI6_DPR_NODE_UNUSED);
+
+ v4l2_subdev_call(&entity->subdev, video, s_stream, 0);
+ }
+
+ return ret;
+}
[...]
+/* --
+ * videobuf2 Queue Operations
+ */
+
+static int
+vsp1_video_queue_setup(struct vb2_queue *vq, const struct v4l2_format
*fmt,
+unsigned int *nbuffers, unsigned int *nplanes,
+unsigned int sizes[], void *alloc_ctxs[])
+{
+ struct vsp1_video *video = vb2_get_drv_priv(vq);
+ struct v4l2_pix_format_mplane *format =&video->format;
+ unsigned int i;
If you don't support VIDIOC_CREATE_BUFS ioctl then there should probably
be at least something like:
if (fmt)
return -EINVAL;
But it's likely better to add proper handling of 'fmt' right away.
OK, I will do so. What is the driver supposed to do when *fmt isn't supported
? Use the closest format as would be returned by try_format() ?
Normally user space should pass valid format, as returned from
VIDIOC_TRY_FMT
or VIDIOC_G_FMT (this is what V4L2 spec says, as you may already know).
The drivers I wrote just return -EINVAL if an unsupported fourcc is passed.
I'm not sure if this is the behaviour we want in general. I'm inclined to
keep VIDIOC_CREATE_BUFS simple and require user space to pass supported
formats, otherwise the ioctl would fail. Applications anyway have to verify
the format, e.g. with VIDIOC_TRY_FMT.
In any case it would be nice to have the expected behaviour documented in
the videobuf2-core.h header. And perhaps in the VIDIOC_CREATE_BUFS ioctl
DocBook section.
I suppose this also implies that buffer_prepare() should check whether the
buffer matches the current format.
Right, buffers unsuitable for the current format should be rejected in
buffer_prepare().
+ *nplanes = format->num_planes;
+
+ for (i = 0; i< format->num_planes; ++i) {
+ sizes[i] = format->plane_fmt[i].sizeimage;
+ alloc_ctxs[i] = video->alloc_ctx;
+ }
+
+ return 0;
+}
[snip]
+static int __vsp1_video_try_format(struct vsp1_video *video,
+ struct v4l2_pix_format_mplane *pix,
+ const struct vsp1_format_info **fmtinfo)
+{
+ const struct vsp1_format_info *info;
+ unsigned int width = pix->width;
+ unsigned int height = pix->height;
+ unsigned int i;
+
+ /* Retrieve format information and select the default format i
[PATCH V2 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN
It's convenient to have ethernet mac addresses use
ETH_ALEN to be able to grep for them a bit easier and
also to ensure that the addresses are __aligned(2).
Add #include as necessary.
Signed-off-by: Joe Perches
Acked-by: Mauro Carvalho Chehab
---
include/linux/dm9000.h | 4 ++-
include/linux/fs_enet_pd.h | 3 ++-
include/linux/ieee80211.h | 59 +
include/linux/mlx4/device.h | 11
include/linux/mlx4/qp.h | 5 ++--
include/linux/mv643xx_eth.h | 3 ++-
include/linux/sh_eth.h | 3 ++-
include/linux/smsc911x.h| 3 ++-
include/linux/uwb/spec.h| 5 ++--
include/media/tveeprom.h| 4 ++-
include/net/irda/irlan_common.h | 3 ++-
11 files changed, 58 insertions(+), 45 deletions(-)
diff --git a/include/linux/dm9000.h b/include/linux/dm9000.h
index 96e8769..841925f 100644
--- a/include/linux/dm9000.h
+++ b/include/linux/dm9000.h
@@ -14,6 +14,8 @@
#ifndef __DM9000_PLATFORM_DATA
#define __DM9000_PLATFORM_DATA __FILE__
+#include
+
/* IO control flags */
#define DM9000_PLATF_8BITONLY (0x0001)
@@ -27,7 +29,7 @@
struct dm9000_plat_data {
unsigned intflags;
- unsigned char dev_addr[6];
+ unsigned char dev_addr[ETH_ALEN];
/* allow replacement IO routines */
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 51b7934..343d82a 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -18,6 +18,7 @@
#include
#include
+#include
#include
#define FS_ENET_NAME "fs_enet"
@@ -135,7 +136,7 @@ struct fs_platform_info {
const struct fs_mii_bus_info *bus_info;
int rx_ring, tx_ring; /* number of buffers on rx */
- __u8 macaddr[6];/* mac address */
+ __u8 macaddr[ETH_ALEN]; /* mac address */
int rx_copybreak; /* limit we copy small frames */
int use_napi; /* use NAPI*/
int napi_weight;/* NAPI weight */
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index b0dc87a..4e101af 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -16,6 +16,7 @@
#define LINUX_IEEE80211_H
#include
+#include
#include
/*
@@ -209,28 +210,28 @@ static inline u16 ieee80211_sn_sub(u16 sn1, u16 sn2)
struct ieee80211_hdr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
- u8 addr4[6];
+ u8 addr4[ETH_ALEN];
} __packed __aligned(2);
struct ieee80211_hdr_3addr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
} __packed __aligned(2);
struct ieee80211_qos_hdr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
__le16 qos_ctrl;
} __packed __aligned(2);
@@ -608,8 +609,8 @@ struct ieee80211s_hdr {
u8 flags;
u8 ttl;
__le32 seqnum;
- u8 eaddr1[6];
- u8 eaddr2[6];
+ u8 eaddr1[ETH_ALEN];
+ u8 eaddr2[ETH_ALEN];
} __packed __aligned(2);
/* Mesh flags */
@@ -758,7 +759,7 @@ struct ieee80211_rann_ie {
u8 rann_flags;
u8 rann_hopcount;
u8 rann_ttl;
- u8 rann_addr[6];
+ u8 rann_addr[ETH_ALEN];
__le32 rann_seq;
__le32 rann_interval;
__le32 rann_metric;
@@ -802,9 +803,9 @@ enum ieee80211_vht_opmode_bits {
struct ieee80211_mgmt {
__le16 frame_control;
__le16 duration;
- u8 da[6];
- u8 sa[6];
- u8 bssid[6];
+ u8 da[ETH_ALEN];
+ u8 sa[ETH_ALEN];
+ u8 bssid[ETH_ALEN];
__le16 seq_ctrl;
union {
struct {
@@ -833,7 +834,7 @@ struct ieee80211_mgmt {
struct {
__le16 capab_info;
__le16 listen_interval;
- u8 current_ap[6];
+ u8 current_ap[ETH_ALEN];
/* followed by SSID and Supported rates */
u8 variable[0];
} __packed reassoc_req;
@@ -966,21 +967,21 @@ struct ieee80211_vendor_ie {
struct ieee80211_rts {
__le16 frame_control;
__le16 duration;
- u8 ra[6];
- u8 ta[6];
+ u8 ra[ETH_ALEN];
+ u8 ta[ETH_ALEN];
} __packed __aligned(2);
struct ieee80211_cts {
__le16 frame_control;
__le16 duration;
- u8 ra[6];
+ u8 ra[ETH_ALEN];
} __packed __aligned(2);
struct ieee80211_
[PATCH V2 0/3] networking: Use ETH_ALEN where appropriate
Convert the uses mac addresses to ETH_ALEN so it's easier to find and verify where mac addresses need to be __aligned(2) Change from initial submission: - Remove include/acpi/actbl2.h conversion It's a file copied from outside ACPI sources Joe Perches (3): uapi: Convert some uses of 6 to ETH_ALEN include: Convert ethernet mac address declarations to use ETH_ALEN ethernet: Convert mac address uses of 6 to ETH_ALEN drivers/net/ethernet/8390/ax88796.c| 4 +- drivers/net/ethernet/amd/pcnet32.c | 6 +-- drivers/net/ethernet/broadcom/cnic_if.h| 6 +-- drivers/net/ethernet/dec/tulip/tulip_core.c| 8 +-- drivers/net/ethernet/i825xx/sun3_82586.h | 4 +- drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 2 +- drivers/net/ethernet/nuvoton/w90p910_ether.c | 4 +- drivers/net/ethernet/pasemi/pasemi_mac.c | 13 ++--- drivers/net/ethernet/pasemi/pasemi_mac.h | 4 +- drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c | 4 +- drivers/net/ethernet/qlogic/qlge/qlge.h| 2 +- include/linux/dm9000.h | 4 +- include/linux/fs_enet_pd.h | 3 +- include/linux/ieee80211.h | 59 +++--- include/linux/mlx4/device.h| 11 ++-- include/linux/mlx4/qp.h| 5 +- include/linux/mv643xx_eth.h| 3 +- include/linux/sh_eth.h | 3 +- include/linux/smsc911x.h | 3 +- include/linux/uwb/spec.h | 5 +- include/media/tveeprom.h | 4 +- include/net/irda/irlan_common.h| 3 +- include/uapi/linux/dn.h| 3 +- include/uapi/linux/if_bridge.h | 3 +- include/uapi/linux/netfilter_bridge/ebt_802_3.h| 5 +- include/uapi/linux/netfilter_ipv4/ipt_CLUSTERIP.h | 3 +- include/uapi/linux/virtio_net.h| 2 +- include/uapi/linux/wimax/i2400m.h | 4 +- 28 files changed, 100 insertions(+), 80 deletions(-) -- 1.8.1.2.459.gbcd45b4.dirty -- 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: mb86a20s and cx23885
Em Thu, 01 Aug 2013 15:09:35 -0300
Alfredo Jesús Delaiti escreveu:
> Hi
>
> El 01/08/13 14:37, Mauro Carvalho Chehab escribió:
> > Em Thu, 01 Aug 2013 14:16:32 -0300
> > Alfredo Jesús Delaiti escreveu:
> >
> >> Hi
> >>
> >> El 01/08/13 09:04, Mauro Carvalho Chehab escribió:
> I found the patch that affects the X8507 board is: commit
> a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
>
>
> alfredo@linux-puon:/usr/src/git/linux> git stash
> Saved working directory and index state WIP on (no branch): c6f56e7
> [media] dvb: don't use DVBv3 bandwidth macros
> HEAD is now at c6f56e7 [media] dvb: don't use DVBv3 bandwidth macros
> alfredo@linux-puon:/usr/src/git/linux> git bisect good
> a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb is the first bad commit
> commit a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
> Author: Mauro Carvalho Chehab
> Date: Mon Dec 26 20:48:54 2011 -0300
>
> [media] cx23885-dvb: Remove a dirty hack that would require DVBv3
>
> The cx23885-dvb driver has a dirty hack:
> 1) it hooks the DVBv3 legacy call to FE_SET_FRONTEND;
> 2) it uses internally the DVBv3 struct to decide some
> configs.
>
> Replace it by a change during the gate control. This will
> likely work, but requires testing. Anyway, the current way
> will break, as soon as we stop copying data for DVBv3 for
> pure DVBv5 calls.
>
> Compile-tested only.
>
> Cc: Michael Krufky
> Signed-off-by: Mauro Carvalho Chehab
>
> :04 04 6d0695eb9e59b837425ed64d4e2be6625864b609
> 89700b867069ec0ad2713367e607763e91798e98 M drivers
>
>
>
> I manually removed the patch, then the TV card works.
>
>
> Unfortunately my lack of knowledge prevents me fix it.
>
> I test new code with pleasure :) !
> >>> Hi Alfredo,
> >>>
> >>>
> >>> Please send me the patches you've made to make isdb-t work on
> >>> it, and I'll try to address this issue.
> >>>
> >>> Regards,
> >>> Mauro
> >>>
> >>>
> >> Mauro thank you very much for your interest.
> >>
> >> I send the patch. 3.2 is on a kernel.
> >>
> >> ---
> >>
> >>.../{ => }/media/dvb/frontends/mb86a20s.c | 332
> >> ++--
> > Hmm... unfortunately, your emailer broke the patch. It made a total mess
> > with whitespaces. Could you please resend it in a way that whitespaces
> > won't be damaged? Otherwise, patch tool won't apply it.
> >
> > Cheers,
> > Mauro
>
> GR
>
> I send attached, I hope it will not break this time.
This time it arrived fine, thanks!
Btw, those changes at mb86a20s are required for it to work, or just alters
somewhat the tuning?
Regards,
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: Doing a v4l-utils-1.0.0 release
Hello, On 6/14/13 9:15 AM, Hans de Goede wrote: IIRC the 0.9.x series were meant as development releases leading up to a new stable 1.0.0 release. Lately there have been no maintenance 0.8.x releases and a lot of interesting development going on in the 0.9.x, while at the same time there have been no issues reported against 0.9.x (iow it seems stable). So how about taking current master and releasing that as a 1.0.0 release ? If nobody objects I'll do a 1.0.0 release this weekend. Thanks, Gregor -- 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: ERRORS
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: Thu Aug 1 19:00:22 CEST 2013 git branch: test git hash: b43ea8068d2090cb1e44632c8a938ab40d2c7419 gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.slh.1-amd64 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: ERRORS linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
Re: mb86a20s and cx23885
Hi
El 01/08/13 14:37, Mauro Carvalho Chehab escribió:
Em Thu, 01 Aug 2013 14:16:32 -0300
Alfredo Jesús Delaiti escreveu:
Hi
El 01/08/13 09:04, Mauro Carvalho Chehab escribió:
I found the patch that affects the X8507 board is: commit
a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
alfredo@linux-puon:/usr/src/git/linux> git stash
Saved working directory and index state WIP on (no branch): c6f56e7
[media] dvb: don't use DVBv3 bandwidth macros
HEAD is now at c6f56e7 [media] dvb: don't use DVBv3 bandwidth macros
alfredo@linux-puon:/usr/src/git/linux> git bisect good
a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb is the first bad commit
commit a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
Author: Mauro Carvalho Chehab
Date: Mon Dec 26 20:48:54 2011 -0300
[media] cx23885-dvb: Remove a dirty hack that would require DVBv3
The cx23885-dvb driver has a dirty hack:
1) it hooks the DVBv3 legacy call to FE_SET_FRONTEND;
2) it uses internally the DVBv3 struct to decide some
configs.
Replace it by a change during the gate control. This will
likely work, but requires testing. Anyway, the current way
will break, as soon as we stop copying data for DVBv3 for
pure DVBv5 calls.
Compile-tested only.
Cc: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab
:04 04 6d0695eb9e59b837425ed64d4e2be6625864b609
89700b867069ec0ad2713367e607763e91798e98 M drivers
I manually removed the patch, then the TV card works.
Unfortunately my lack of knowledge prevents me fix it.
I test new code with pleasure :) !
Hi Alfredo,
Please send me the patches you've made to make isdb-t work on
it, and I'll try to address this issue.
Regards,
Mauro
Mauro thank you very much for your interest.
I send the patch. 3.2 is on a kernel.
---
.../{ => }/media/dvb/frontends/mb86a20s.c | 332
++--
Hmm... unfortunately, your emailer broke the patch. It made a total mess
with whitespaces. Could you please resend it in a way that whitespaces
won't be damaged? Otherwise, patch tool won't apply it.
Cheers,
Mauro
GR
I send attached, I hope it will not break this time.
Again, Thanks
Alfredo
.../{ => }/media/dvb/frontends/mb86a20s.c | 332 ++--
.../{ => }/media/video/cx23885/cx23885-cards.c | 38 +++
.../{ => }/media/video/cx23885/cx23885-dvb.c | 26 ++
.../{ => }/media/video/cx23885/cx23885-video.c |1 +
.../cx23885/{ => }/media/video/cx23885/cx23885.h |1 +
5 files changed, 163 insertions(+), 235 deletions(-)
diff --git a/drivers/media/dvb/frontends/mb86a20s.c b/drivers/media/dvb/frontends/mb86a20s.c
index 0f867a5..26e06b4 100644
--- a/drivers/media/dvb/frontends/mb86a20s.c
+++ b/drivers/media/dvb/frontends/mb86a20s.c
@@ -47,271 +47,133 @@ struct mb86a20s_state {
bool need_init;
};
struct regdata {
u8 reg;
u8 data;
};
/*
* Initialization sequence: Use whatevere default values that PV SBTVD
* does on its initialisation, obtained via USB snoop
*/
static struct regdata mb86a20s_init[] = {
{ 0x70, 0x0f },
{ 0x70, 0xff },
- { 0x08, 0x01 },
- { 0x09, 0x3e },
- { 0x50, 0xd1 },
- { 0x51, 0x22 },
- { 0x39, 0x01 },
- { 0x71, 0x00 },
- { 0x28, 0x2a },
- { 0x29, 0x00 },
- { 0x2a, 0xff },
- { 0x2b, 0x80 },
- { 0x28, 0x20 },
- { 0x29, 0x33 },
- { 0x2a, 0xdf },
- { 0x2b, 0xa9 },
+ { 0x09, 0x3a },
+ { 0x50, 0xd1 }, { 0x51, 0x22 },
+ { 0x39, 0x00 },
+ { 0x28, 0x2a }, { 0x29, 0x00 }, { 0x2a, 0xfd }, { 0x2b, 0xc8 },
{ 0x3b, 0x21 },
- { 0x3c, 0x3a },
+ { 0x3c, 0x38 },
+ { 0x28, 0x20 }, { 0x29, 0x3e }, { 0x2a, 0xde }, { 0x2b, 0x4d },
+ { 0x28, 0x22 }, { 0x29, 0x00 }, { 0x2a, 0x1f }, { 0x2b, 0xf0 },
{ 0x01, 0x0d },
- { 0x04, 0x08 },
- { 0x05, 0x05 },
- { 0x04, 0x0e },
- { 0x05, 0x00 },
- { 0x04, 0x0f },
- { 0x05, 0x14 },
- { 0x04, 0x0b },
- { 0x05, 0x8c },
- { 0x04, 0x00 },
- { 0x05, 0x00 },
- { 0x04, 0x01 },
- { 0x05, 0x07 },
- { 0x04, 0x02 },
- { 0x05, 0x0f },
- { 0x04, 0x03 },
- { 0x05, 0xa0 },
- { 0x04, 0x09 },
- { 0x05, 0x00 },
- { 0x04, 0x0a },
- { 0x05, 0xff },
- { 0x04, 0x27 },
- { 0x05, 0x64 },
- { 0x04, 0x28 },
- { 0x05, 0x00 },
- { 0x04, 0x1e },
- { 0x05, 0xff },
- { 0x04, 0x29 },
- { 0x05, 0x0a },
- { 0x04, 0x32 },
- { 0x05, 0x0a },
- { 0x04, 0x14 },
- { 0x05, 0x02 },
- { 0x04, 0x04 },
- { 0x05, 0x00 },
- { 0x04, 0x05 },
- { 0x05, 0x22 },
- { 0x04, 0x06 },
- { 0x05, 0x0e },
- { 0x04, 0x07 },
- { 0x05, 0xd8 },
- { 0x04, 0x12 },
- { 0x05, 0x00 },
- { 0x04, 0x13 },
- { 0x05, 0xff },
+ { 0x04, 0x08 }, { 0x05, 0x03 },
+ { 0x04, 0x0e }, { 0x05, 0x00 },
+ { 0x04, 0x0f }, { 0x05, 0x32 },
+ { 0x04, 0x0b }, { 0x05, 0x78 },
+ { 0x04, 0x00 }, { 0x05, 0x00 },
+ { 0x04, 0x01 }, { 0x05, 0x1e },
+ { 0x04, 0x02 }, { 0x05, 0x07 },
+ { 0x04, 0x03 }, { 0x05, 0xd0 },
+ { 0x04, 0x09 }, { 0x05, 0x00 },
+ { 0x04, 0x0a }, { 0x05, 0xff },
+ { 0x04, 0x27 }, { 0x05, 0x00 },
Re: Prof p7500 DVB-S2 USB device
In theory, no, it should be identical. Hopeing you don't have any USB issue, I think you should let the maintainer know that this is happening. I'm sorry but I lack knowledge in this area to help you any further. Oliver On 08/01/13 16:36, Krishna Kishore wrote: Hi Oliver, Thanks for your response. I think I confused you. Sorry! Let me summarize.. Please ignore the crash related problem. I could get that working. The status is: usb dvb device (7500) is getting enumerated. But on pandaboard /dev/dvb/* gets created only after 20-25 min Whereas it works fine on desktop ubuntu (kernel 3.8.0). USB related drivers are fine on pandaboard. Why there is difference in behaviour in dvb drivers on desktop and pandaboard? Regards, Kishore. Oliver Schinagl wrote: You are making it very hard to troubleshoot your problem and since the driver seems to work on your PC this is almost the wrong place for your support questions. I suppose the panda board forums would be better? Anyway, if your issue on the pandaboard is that it's not showing up in lsusb, you probably are missing USB drivers (i think we talked about that previously) Those crashes you posted, I have no idea where or what they cause. If this is from booting without USB stick plugged in, deffinatly ask on some pandaboard list/forum. If it only happens when plugging in your device, then it might be related to the dvb driver, but even there I have my doubts. Oliver On 01-08-13 16:06, Krishna Kishore wrote: Krishna Kishore wrote: Hi, When I used buildroot filesystem, I am not seeing this problem. However, my device still doenot work. Ubuntu 13.04 desktop kernel 3.8.0 works Pandaboard kernel >=3.8.4 doesnot work I am suspecting only kernel configuration. Please provide any inputs for me to proceed. Thanks. Regards, Kishore. Krishna Kishore wrote: Hi, Does anyone know about the following error? I am using Linux kernel 3.9.0. I am getting this error with 3.8.4 also. [ 233.017242] PM: Syncing filesystems ... done. [ 233.253112] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 233.273712] Freezing remaining freezable tasks ... [ 253.291076] Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0): [ 253.300445] khubd D c053586c 0 446 2 0x [ 253.307220] [] (__schedule+0x37c/0x7e0) from [] (schedule_timeout+0x124/0x220) [ 253.316741] [] (schedule_timeout+0x124/0x220) from [] (wait_for_common+0xac/0x150) [ 253.326599] [] (wait_for_common+0xac/0x150) from [] (usb_start_wait_urb+0x60/0x128) [ 253.336547] [] (usb_start_wait_urb+0x60/0x128) from [] (usb_control_msg+0xc0/0xe4) [ 253.346405] [] (usb_control_msg+0xc0/0xe4) from [] (dw210x_op_rw+0x94/0x108) [ 253.355712] [] (dw210x_op_rw+0x94/0x108) from [] (s6x0_i2c_transfer+0x3c0/0x3e0) [ 253.365386] [] (s6x0_i2c_transfer+0x3c0/0x3e0) from [] (s6x0_read_mac_address+0x70/0xc0) [ 253.375823] [] (s6x0_read_mac_address+0x70/0xc0) from [] (dvb_usb_adapter_dvb_init+0x64/0x1c0) [ 253.386810] [] (dvb_usb_adapter_dvb_init+0x64/0x1c0) from [] (dvb_usb_device_init+0x444/0x608) [ 253.397766] [] (dvb_usb_device_init+0x444/0x608) from [] (dw2102_probe+0x24c/0x340) [ 253.407714] [] (dw2102_probe+0x24c/0x340) from [] (usb_probe_interface+0x1c0/0x260) [ 253.417663] [] (usb_probe_interface+0x1c0/0x260) from [] (driver_probe_device+0x108/0x21c) [ 253.428253] [] (driver_probe_device+0x108/0x21c) from [] (bus_for_each_drv+0x5c/0x88) [ 253.438385] [] (bus_for_each_drv+0x5c/0x88) from [] (device_attach+0x78/0x90) [ 253.447784] [] (device_attach+0x78/0x90) from [] (bus_probe_device+0x88/0xac) [ 253.457183] [] (bus_probe_device+0x88/0xac) from [] (device_add+0x4b0/0x584) [ 253.466491] [] (device_add+0x4b0/0x584) from [] (usb_set_configuration+0x574/0x78c) [ 253.476470] [] (usb_set_configuration+0x574/0x78c) from [] (generic_probe+0x34/0x78) [ 253.486511] [] (generic_probe+0x34/0x78) from [] (usb_probe_device+0x3c/0x60) [ 253.495910] [] (usb_probe_device+0x3c/0x60) from [] (driver_probe_device+0x108/0x21c) [ 253.506042] [] (driver_probe_device+0x108/0x21c) from [] (bus_for_each_drv+0x5c/0x88) [ 253.516174] [] (bus_for_each_drv+0x5c/0x88) from [] (device_attach+0x78/0x90) [ 253.525573] [] (device_attach+0x78/0x90) from [] (bus_probe_device+0x88/0xac) [ 253.534973] [] (bus_probe_device+0x88/0xac) from [] (device_add+0x4b0/0x584) [ 253.544281] [] (device_add+0x4b0/0x584) from [] (usb_new_device+0x1ec/0x360) [ 253.553588] [] (usb_new_device+0x1ec/0x360) from [] (hub_thread+0x714/0x1360) [ 253.563018] [] (hub_thread+0x714/0x1360) from [] (kthread+0xa4/0xb0) [ 253.571624] [] (kthread+0xa4/0xb0) from [] (ret_from_fork+0x14/0x24) [ 253.580169] [ 253.581756] Restarting kernel threads ... done. [ 253.587005] Restarting tasks ... done. [ 259.016845] PM: Syncing filesystems ... done. [ 259.155700] Freezing user space processes ... (elapsed 0.02 seconds) done. Regards, Kishore _
Re: [PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN
Em Sun, 28 Jul 2013 22:29:04 -0700
Joe Perches escreveu:
> It's convenient to have ethernet mac addresses use
> ETH_ALEN to be able to grep for them a bit easier and
> also to ensure that the addresses are __aligned(2).
>
> Add #include as necessary.
>
> Signed-off-by: Joe Perches
> ---
> include/acpi/actbl2.h | 4 ++-
> include/linux/dm9000.h | 4 ++-
> include/linux/fs_enet_pd.h | 3 ++-
> include/linux/ieee80211.h | 59
> +
> include/linux/mlx4/device.h | 11
> include/linux/mlx4/qp.h | 5 ++--
> include/linux/mv643xx_eth.h | 3 ++-
> include/linux/sh_eth.h | 3 ++-
> include/linux/smsc911x.h| 3 ++-
> include/linux/uwb/spec.h| 5 ++--
> include/media/tveeprom.h| 4 ++-
I'm ok with the change at media/tveeprom.h.
Please add my ack on the next version after handling Rafael's request
on acpi.
Acked-by: Mauro Carvalho Chehab
> include/net/irda/irlan_common.h | 3 ++-
> 12 files changed, 61 insertions(+), 46 deletions(-)
>
> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
> index ffaac0e..3f0f11c 100644
> --- a/include/acpi/actbl2.h
> +++ b/include/acpi/actbl2.h
> @@ -44,6 +44,8 @@
> #ifndef __ACTBL2_H__
> #define __ACTBL2_H__
>
> +#include
> +
>
> /***
> *
> * Additional ACPI Tables (2)
> @@ -605,7 +607,7 @@ struct acpi_ibft_nic {
> u8 secondary_dns[16];
> u8 dhcp[16];
> u16 vlan;
> - u8 mac_address[6];
> + u8 mac_address[ETH_ALEN];
> u16 pci_address;
> u16 name_length;
> u16 name_offset;
> diff --git a/include/linux/dm9000.h b/include/linux/dm9000.h
> index 96e8769..841925f 100644
> --- a/include/linux/dm9000.h
> +++ b/include/linux/dm9000.h
> @@ -14,6 +14,8 @@
> #ifndef __DM9000_PLATFORM_DATA
> #define __DM9000_PLATFORM_DATA __FILE__
>
> +#include
> +
> /* IO control flags */
>
> #define DM9000_PLATF_8BITONLY(0x0001)
> @@ -27,7 +29,7 @@
>
> struct dm9000_plat_data {
> unsigned intflags;
> - unsigned char dev_addr[6];
> + unsigned char dev_addr[ETH_ALEN];
>
> /* allow replacement IO routines */
>
> diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
> index 51b7934..343d82a 100644
> --- a/include/linux/fs_enet_pd.h
> +++ b/include/linux/fs_enet_pd.h
> @@ -18,6 +18,7 @@
>
> #include
> #include
> +#include
> #include
>
> #define FS_ENET_NAME "fs_enet"
> @@ -135,7 +136,7 @@ struct fs_platform_info {
> const struct fs_mii_bus_info *bus_info;
>
> int rx_ring, tx_ring; /* number of buffers on rx */
> - __u8 macaddr[6];/* mac address */
> + __u8 macaddr[ETH_ALEN]; /* mac address */
> int rx_copybreak; /* limit we copy small frames */
> int use_napi; /* use NAPI*/
> int napi_weight;/* NAPI weight */
> diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
> index b0dc87a..4e101af 100644
> --- a/include/linux/ieee80211.h
> +++ b/include/linux/ieee80211.h
> @@ -16,6 +16,7 @@
> #define LINUX_IEEE80211_H
>
> #include
> +#include
> #include
>
> /*
> @@ -209,28 +210,28 @@ static inline u16 ieee80211_sn_sub(u16 sn1, u16 sn2)
> struct ieee80211_hdr {
> __le16 frame_control;
> __le16 duration_id;
> - u8 addr1[6];
> - u8 addr2[6];
> - u8 addr3[6];
> + u8 addr1[ETH_ALEN];
> + u8 addr2[ETH_ALEN];
> + u8 addr3[ETH_ALEN];
> __le16 seq_ctrl;
> - u8 addr4[6];
> + u8 addr4[ETH_ALEN];
> } __packed __aligned(2);
>
> struct ieee80211_hdr_3addr {
> __le16 frame_control;
> __le16 duration_id;
> - u8 addr1[6];
> - u8 addr2[6];
> - u8 addr3[6];
> + u8 addr1[ETH_ALEN];
> + u8 addr2[ETH_ALEN];
> + u8 addr3[ETH_ALEN];
> __le16 seq_ctrl;
> } __packed __aligned(2);
>
> struct ieee80211_qos_hdr {
> __le16 frame_control;
> __le16 duration_id;
> - u8 addr1[6];
> - u8 addr2[6];
> - u8 addr3[6];
> + u8 addr1[ETH_ALEN];
> + u8 addr2[ETH_ALEN];
> + u8 addr3[ETH_ALEN];
> __le16 seq_ctrl;
> __le16 qos_ctrl;
> } __packed __aligned(2);
> @@ -608,8 +609,8 @@ struct ieee80211s_hdr {
> u8 flags;
> u8 ttl;
> __le32 seqnum;
> - u8 eaddr1[6];
> - u8 eaddr2[6];
> + u8 eaddr1[ETH_ALEN];
> + u8 eaddr2[ETH_ALEN];
> } __packed __aligned(2);
>
> /* Mesh flags */
> @@ -758,7 +759,7 @@ struct ieee80211_rann_ie {
> u8 rann_flags;
> u8 rann_hopcount;
> u8 rann_ttl;
> - u8 rann_addr[6];
> + u8 rann_addr[ETH_ALEN];
> __le32 rann_seq;
> __le32 rann_interval;
> __le32 rann_metric;
> @@ -802,9 +803,9 @@ enum ieee80211_vht_opmode_bits {
> struct ieee80211_mgmt {
> __le16 frame_control;
> __le16 dura
Re: mb86a20s and cx23885
Em Thu, 01 Aug 2013 14:16:32 -0300
Alfredo Jesús Delaiti escreveu:
> Hi
>
> El 01/08/13 09:04, Mauro Carvalho Chehab escribió:
> >>
> >> I found the patch that affects the X8507 board is: commit
> >> a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
> >>
> >>
> >> alfredo@linux-puon:/usr/src/git/linux> git stash
> >> Saved working directory and index state WIP on (no branch): c6f56e7
> >> [media] dvb: don't use DVBv3 bandwidth macros
> >> HEAD is now at c6f56e7 [media] dvb: don't use DVBv3 bandwidth macros
> >> alfredo@linux-puon:/usr/src/git/linux> git bisect good
> >> a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb is the first bad commit
> >> commit a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
> >> Author: Mauro Carvalho Chehab
> >> Date: Mon Dec 26 20:48:54 2011 -0300
> >>
> >> [media] cx23885-dvb: Remove a dirty hack that would require DVBv3
> >>
> >> The cx23885-dvb driver has a dirty hack:
> >> 1) it hooks the DVBv3 legacy call to FE_SET_FRONTEND;
> >> 2) it uses internally the DVBv3 struct to decide some
> >> configs.
> >>
> >> Replace it by a change during the gate control. This will
> >> likely work, but requires testing. Anyway, the current way
> >> will break, as soon as we stop copying data for DVBv3 for
> >> pure DVBv5 calls.
> >>
> >> Compile-tested only.
> >>
> >> Cc: Michael Krufky
> >> Signed-off-by: Mauro Carvalho Chehab
> >>
> >> :04 04 6d0695eb9e59b837425ed64d4e2be6625864b609
> >> 89700b867069ec0ad2713367e607763e91798e98 M drivers
> >>
> >>
> >>
> >> I manually removed the patch, then the TV card works.
> >>
> >>
> >> Unfortunately my lack of knowledge prevents me fix it.
> >>
> >> I test new code with pleasure :) !
> > Hi Alfredo,
> >
> >
> > Please send me the patches you've made to make isdb-t work on
> > it, and I'll try to address this issue.
> >
> > Regards,
> > Mauro
> >
> >
> Mauro thank you very much for your interest.
>
> I send the patch. 3.2 is on a kernel.
>
> ---
>
> .../{ => }/media/dvb/frontends/mb86a20s.c | 332
> ++--
Hmm... unfortunately, your emailer broke the patch. It made a total mess
with whitespaces. Could you please resend it in a way that whitespaces
won't be damaged? Otherwise, patch tool won't apply it.
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: mb86a20s and cx23885
Hi
El 01/08/13 09:04, Mauro Carvalho Chehab escribió:
I found the patch that affects the X8507 board is: commit
a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
alfredo@linux-puon:/usr/src/git/linux> git stash
Saved working directory and index state WIP on (no branch): c6f56e7
[media] dvb: don't use DVBv3 bandwidth macros
HEAD is now at c6f56e7 [media] dvb: don't use DVBv3 bandwidth macros
alfredo@linux-puon:/usr/src/git/linux> git bisect good
a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb is the first bad commit
commit a7d44baaed0a8c7d4c4fb47938455cb3fc2bb1eb
Author: Mauro Carvalho Chehab
Date: Mon Dec 26 20:48:54 2011 -0300
[media] cx23885-dvb: Remove a dirty hack that would require DVBv3
The cx23885-dvb driver has a dirty hack:
1) it hooks the DVBv3 legacy call to FE_SET_FRONTEND;
2) it uses internally the DVBv3 struct to decide some
configs.
Replace it by a change during the gate control. This will
likely work, but requires testing. Anyway, the current way
will break, as soon as we stop copying data for DVBv3 for
pure DVBv5 calls.
Compile-tested only.
Cc: Michael Krufky
Signed-off-by: Mauro Carvalho Chehab
:04 04 6d0695eb9e59b837425ed64d4e2be6625864b609
89700b867069ec0ad2713367e607763e91798e98 M drivers
I manually removed the patch, then the TV card works.
Unfortunately my lack of knowledge prevents me fix it.
I test new code with pleasure :) !
Hi Alfredo,
Please send me the patches you've made to make isdb-t work on
it, and I'll try to address this issue.
Regards,
Mauro
Mauro thank you very much for your interest.
I send the patch. 3.2 is on a kernel.
---
.../{ => }/media/dvb/frontends/mb86a20s.c | 332
++--
.../{ => }/media/video/cx23885/cx23885-cards.c | 38 +++
.../{ => }/media/video/cx23885/cx23885-dvb.c | 26 ++
.../{ => }/media/video/cx23885/cx23885-video.c |1 +
.../cx23885/{ => }/media/video/cx23885/cx23885.h |1 +
5 files changed, 163 insertions(+), 235 deletions(-)
diff --git a/drivers/media/dvb/frontends/mb86a20s.c
b/drivers/media/dvb/frontends/mb86a20s.c
index 0f867a5..26e06b4 100644
--- a/drivers/media/dvb/frontends/mb86a20s.c
+++ b/drivers/media/dvb/frontends/mb86a20s.c
@@ -47,271 +47,133 @@ struct mb86a20s_state {
bool need_init;
};
struct regdata {
u8 reg;
u8 data;
};
/*
* Initialization sequence: Use whatevere default values that PV SBTVD
* does on its initialisation, obtained via USB snoop
*/
static struct regdata mb86a20s_init[] = {
{ 0x70, 0x0f },
{ 0x70, 0xff },
-{ 0x08, 0x01 },
-{ 0x09, 0x3e },
-{ 0x50, 0xd1 },
-{ 0x51, 0x22 },
-{ 0x39, 0x01 },
-{ 0x71, 0x00 },
-{ 0x28, 0x2a },
-{ 0x29, 0x00 },
-{ 0x2a, 0xff },
-{ 0x2b, 0x80 },
-{ 0x28, 0x20 },
-{ 0x29, 0x33 },
-{ 0x2a, 0xdf },
-{ 0x2b, 0xa9 },
+{ 0x09, 0x3a },
+{ 0x50, 0xd1 }, { 0x51, 0x22 },
+{ 0x39, 0x00 },
+{ 0x28, 0x2a }, { 0x29, 0x00 }, { 0x2a, 0xfd }, { 0x2b, 0xc8 },
{ 0x3b, 0x21 },
-{ 0x3c, 0x3a },
+{ 0x3c, 0x38 },
+{ 0x28, 0x20 }, { 0x29, 0x3e }, { 0x2a, 0xde }, { 0x2b, 0x4d },
+{ 0x28, 0x22 }, { 0x29, 0x00 }, { 0x2a, 0x1f }, { 0x2b, 0xf0 },
{ 0x01, 0x0d },
-{ 0x04, 0x08 },
-{ 0x05, 0x05 },
-{ 0x04, 0x0e },
-{ 0x05, 0x00 },
-{ 0x04, 0x0f },
-{ 0x05, 0x14 },
-{ 0x04, 0x0b },
-{ 0x05, 0x8c },
-{ 0x04, 0x00 },
-{ 0x05, 0x00 },
-{ 0x04, 0x01 },
-{ 0x05, 0x07 },
-{ 0x04, 0x02 },
-{ 0x05, 0x0f },
-{ 0x04, 0x03 },
-{ 0x05, 0xa0 },
-{ 0x04, 0x09 },
-{ 0x05, 0x00 },
-{ 0x04, 0x0a },
-{ 0x05, 0xff },
-{ 0x04, 0x27 },
-{ 0x05, 0x64 },
-{ 0x04, 0x28 },
-{ 0x05, 0x00 },
-{ 0x04, 0x1e },
-{ 0x05, 0xff },
-{ 0x04, 0x29 },
-{ 0x05, 0x0a },
-{ 0x04, 0x32 },
-{ 0x05, 0x0a },
-{ 0x04, 0x14 },
-{ 0x05, 0x02 },
-{ 0x04, 0x04 },
-{ 0x05, 0x00 },
-{ 0x04, 0x05 },
-{ 0x05, 0x22 },
-{ 0x04, 0x06 },
-{ 0x05, 0x0e },
-{ 0x04, 0x07 },
-{ 0x05, 0xd8 },
-{ 0x04, 0x12 },
-{ 0x05, 0x00 },
-{ 0x04, 0x13 },
-{ 0x05, 0xff },
+{ 0x04, 0x08 }, { 0x05, 0x03 },
+{ 0x04, 0x0e }, { 0x05, 0x00 },
+{ 0x04, 0x0f }, { 0x05, 0x32 },
+{ 0x04, 0x0b }, { 0x05, 0x78 },
+{ 0x04, 0x00 }, { 0x05, 0x00 },
+{ 0x04, 0x01 }, { 0x05, 0x1e },
+{ 0x04, 0x02 }, { 0x05, 0x07 },
+{ 0x04, 0x03 }, { 0x05, 0xd0 },
+{ 0x04, 0x09 }, { 0x05, 0x00 },
+{ 0x04, 0x0a }, { 0x05, 0xff },
+{ 0x04, 0x27 }, { 0x05, 0x00 },
+{ 0x04, 0x28 }, { 0x05, 0x00 },
+{ 0x04, 0x1e }, { 0x05, 0x00 },
+{ 0x04, 0x29 }, { 0x05, 0x64 },
+{ 0x04, 0x32 }, { 0x05, 0x64 },
+{ 0x04, 0x14 }, { 0x05, 0x02 },
+{ 0x04, 0x04 }, { 0x05, 0x00 },
+{ 0x04, 0x05 }, { 0x05, 0x22 },
+{ 0x04,
Re: dib8000 scanning not working on 3.10.3
Em Thu, 1 Aug 2013 13:36:25 -0300 Ezequiel Garcia escreveu: > Hi Luis, > > (I'm Ccing Mauro, who mantains this driver and might know what's going on). > > On Wed, Jul 31, 2013 at 03:47:10PM -0300, Luis Polasek wrote: > > Hi, I just upgraded my kernel to 3.10.3, and dib8000 scanning does not > > work anymore. > > > > I tested using dvbscan (from dvb-apps/util/) and w_scan on a Prolink > > Pixelview SBTVD (dib8000 module*).This tools worked very well on > > version 3.9.9 , but now it does not produces any result, and also > > there are no error messages in the logs (dmesg). > > > > Please run a git bisect and report your findings. > > Note that dibcom8000 shows just a handful of commit on 2013, > so you could start reverting those and see what happens. Perhaps it is a failure at the DVBv3 emulation. Did it also break using dvbv5-scan (part of v4l-utils)? Regards, Mauro -- 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: Fwd: dib8000 scanning not working on 3.10.3
Hi Luis, (I'm Ccing Mauro, who mantains this driver and might know what's going on). On Wed, Jul 31, 2013 at 03:47:10PM -0300, Luis Polasek wrote: > Hi, I just upgraded my kernel to 3.10.3, and dib8000 scanning does not > work anymore. > > I tested using dvbscan (from dvb-apps/util/) and w_scan on a Prolink > Pixelview SBTVD (dib8000 module*).This tools worked very well on > version 3.9.9 , but now it does not produces any result, and also > there are no error messages in the logs (dmesg). > Please run a git bisect and report your findings. Note that dibcom8000 shows just a handful of commit on 2013, so you could start reverting those and see what happens. -- 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 v4 1/3] [media] coda: Fix error paths
Hi Fabio,
> From: Philipp Zabel [mailto:p.za...@pengutronix.de]
> Sent: Wednesday, July 24, 2013 11:47 AM
> To: Fabio Estevam
> Cc: k.deb...@samsung.com; m.che...@samsung.com; ker...@pengutronix.de;
> linux-media@vger.kernel.org
> Subject: Re: [PATCH v4 1/3] [media] coda: Fix error paths
>
> Hi Fabio,
>
> Am Dienstag, den 23.07.2013, 15:04 -0300 schrieb Fabio Estevam:
> > Some resources were not being released in the error path and some
> were
> > released in the incorrect order.
> >
> > Signed-off-by: Fabio Estevam
> > ---
> > Changes since v3:
> > - Only disable the clocks after v4l2_m2m_ctx_release() Changes since
> > v2:
> > - Newly introduced in this series
> >
> > drivers/media/platform/coda.c | 38
> > --
> > 1 file changed, 24 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/media/platform/coda.c
> > b/drivers/media/platform/coda.c index df4ada88..9384f02 100644
> > --- a/drivers/media/platform/coda.c
> > +++ b/drivers/media/platform/coda.c
> > @@ -1514,21 +1514,26 @@ static int coda_open(struct file *file)
> > int ret = 0;
> > int idx;
> >
> > - idx = coda_next_free_instance(dev);
> > - if (idx >= CODA_MAX_INSTANCES)
> > - return -EBUSY;
> > - set_bit(idx, &dev->instance_mask);
> > -
> > ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
> > if (!ctx)
> > return -ENOMEM;
> >
> > + idx = coda_next_free_instance(dev);
> > + if (idx >= CODA_MAX_INSTANCES) {
> > + ret = -EBUSY;
> > + goto err_coda_max;
> > + }
> > + set_bit(idx, &dev->instance_mask);
> > +
> > v4l2_fh_init(&ctx->fh, video_devdata(file));
> > file->private_data = &ctx->fh;
> > v4l2_fh_add(&ctx->fh);
> > ctx->dev = dev;
> > ctx->idx = idx;
> >
> > + clk_prepare_enable(dev->clk_per);
> > + clk_prepare_enable(dev->clk_ahb);
> > +
> > set_default_params(ctx);
> > ctx->m2m_ctx = v4l2_m2m_ctx_init(dev->m2m_dev, ctx,
> > &coda_queue_init);
> > @@ -1537,12 +1542,12 @@ static int coda_open(struct file *file)
> >
> > v4l2_err(&dev->v4l2_dev, "%s return error (%d)\n",
> > __func__, ret);
> > - goto err;
> > + goto err_ctx_init;
> > }
> > ret = coda_ctrls_setup(ctx);
> > if (ret) {
> > v4l2_err(&dev->v4l2_dev, "failed to setup coda controls\n");
> > - goto err;
> > + goto err_ctrls_setup;
> > }
> >
> > ctx->fh.ctrl_handler = &ctx->ctrls;
> > @@ -1552,24 +1557,29 @@ static int coda_open(struct file *file)
> > if (!ctx->parabuf.vaddr) {
> > v4l2_err(&dev->v4l2_dev, "failed to allocate parabuf");
> > ret = -ENOMEM;
> > - goto err;
> > + goto err_dma_alloc;
> > }
> >
> > coda_lock(ctx);
> > list_add(&ctx->list, &dev->instances);
> > coda_unlock(ctx);
> >
> > - clk_prepare_enable(dev->clk_per);
> > - clk_prepare_enable(dev->clk_ahb);
> > -
> > v4l2_dbg(1, coda_debug, &dev->v4l2_dev, "Created instance %d
> (%p)\n",
> > ctx->idx, ctx);
> >
> > return 0;
> >
> > -err:
> > +err_dma_alloc:
> > + v4l2_ctrl_handler_free(&ctx->ctrls);
> > +err_ctrls_setup:
> > + v4l2_m2m_ctx_release(ctx->m2m_ctx);
> > +err_ctx_init:
> > + clk_disable_unprepare(dev->clk_ahb);
> > + clk_disable_unprepare(dev->clk_per);
> > v4l2_fh_del(&ctx->fh);
> > v4l2_fh_exit(&ctx->fh);
> > + clear_bit(ctx->idx, &dev->instance_mask);
> > +err_coda_max:
> > kfree(ctx);
> > return ret;
> > }
> > @@ -1588,10 +1598,10 @@ static int coda_release(struct file *file)
> >
> > dma_free_coherent(&dev->plat_dev->dev, CODA_PARA_BUF_SIZE,
> > ctx->parabuf.vaddr, ctx->parabuf.paddr);
> > - v4l2_m2m_ctx_release(ctx->m2m_ctx);
> > v4l2_ctrl_handler_free(&ctx->ctrls);
> > - clk_disable_unprepare(dev->clk_per);
> > + v4l2_m2m_ctx_release(ctx->m2m_ctx);
> > clk_disable_unprepare(dev->clk_ahb);
> > + clk_disable_unprepare(dev->clk_per);
> > v4l2_fh_del(&ctx->fh);
> > v4l2_fh_exit(&ctx->fh);
> > clear_bit(ctx->idx, &dev->instance_mask);
>
> this looks better, thanks. Could you rebase the patches onto Kamil's
> http://git.linuxtv.org/kdebski/media.git/shortlog/refs/heads/new-for-
> 3.12
> branch?
Could you rebase these patches onto
http://git.linuxtv.org/kdebski/media.git/shortlog/refs/heads/new-for-3.12-2nd
?
I get some conflicts and I am not sure how to resolve them.
Best wishes,
--
Kamil Debski
Linux Kernel Developer
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] This brings the genpix line of devices snr reporting in line with other drivers
Em Tue, 23 Jul 2013 09:12:06 -0600
Chris Lee escreveu:
> Signed-off-by: Chris Lee
Hi Chris,
Please better describe your patches. It is not clear what you're
wanting to do on them.
A good patch should contain a detailed explanation about it,
describing the changes with some detail. Please don't be shy in it.
In this specific case, I'm seeing that you're doing some changes at
SNR, but it is not clear if the change is just extending the range
of a SNR relative measurement, or if you need that change to put
the unit as 0.1dB (that's the default unit that most DVBv3 stats
do).
Also, while you are there, the better is to add support on this
driver for DVBv5 stats, were the units of each statistics is properly
docummented.
For this reason, I'll this this patch and your next ones as
"Changes requested" at patchwork. Please re-submit them when ready.
Thanks!
Mauro
>
> ---
> drivers/media/usb/dvb-usb/gp8psk-fe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/dvb-usb/gp8psk-fe.c
> b/drivers/media/usb/dvb-usb/gp8psk-fe.c
> index 67957dd..5864f37 100644
> --- a/drivers/media/usb/dvb-usb/gp8psk-fe.c
> +++ b/drivers/media/usb/dvb-usb/gp8psk-fe.c
> @@ -45,7 +45,7 @@ static int gp8psk_fe_update_status(struct gp8psk_fe_state
> *st)
> if (time_after(jiffies,st->next_status_check)) {
> gp8psk_usb_in_op(st->d, GET_SIGNAL_LOCK, 0,0,&st->lock,1);
> gp8psk_usb_in_op(st->d, GET_SIGNAL_STRENGTH, 0,0,buf,6);
> - st->snr = (buf[1]) << 8 | buf[0];
> + st->snr = ((buf[1]) << 8 | buf[0]) << 4;
> st->next_status_check = jiffies +
> (st->status_check_interval*HZ)/1000;
> }
> return 0;
--
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: Prof p7500 DVB-S2 USB device
You are making it very hard to troubleshoot your problem and since the driver seems to work on your PC this is almost the wrong place for your support questions. I suppose the panda board forums would be better? Anyway, if your issue on the pandaboard is that it's not showing up in lsusb, you probably are missing USB drivers (i think we talked about that previously) Those crashes you posted, I have no idea where or what they cause. If this is from booting without USB stick plugged in, deffinatly ask on some pandaboard list/forum. If it only happens when plugging in your device, then it might be related to the dvb driver, but even there I have my doubts. Oliver On 01-08-13 16:06, Krishna Kishore wrote: Krishna Kishore wrote: Hi, When I used buildroot filesystem, I am not seeing this problem. However, my device still doenot work. Ubuntu 13.04 desktop kernel 3.8.0 works Pandaboard kernel >=3.8.4 doesnot work I am suspecting only kernel configuration. Please provide any inputs for me to proceed. Thanks. Regards, Kishore. Krishna Kishore wrote: Hi, Does anyone know about the following error? I am using Linux kernel 3.9.0. I am getting this error with 3.8.4 also. [ 233.017242] PM: Syncing filesystems ... done. [ 233.253112] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 233.273712] Freezing remaining freezable tasks ... [ 253.291076] Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0): [ 253.300445] khubd D c053586c 0 446 2 0x [ 253.307220] [] (__schedule+0x37c/0x7e0) from [] (schedule_timeout+0x124/0x220) [ 253.316741] [] (schedule_timeout+0x124/0x220) from [] (wait_for_common+0xac/0x150) [ 253.326599] [] (wait_for_common+0xac/0x150) from [] (usb_start_wait_urb+0x60/0x128) [ 253.336547] [] (usb_start_wait_urb+0x60/0x128) from [] (usb_control_msg+0xc0/0xe4) [ 253.346405] [] (usb_control_msg+0xc0/0xe4) from [] (dw210x_op_rw+0x94/0x108) [ 253.355712] [] (dw210x_op_rw+0x94/0x108) from [] (s6x0_i2c_transfer+0x3c0/0x3e0) [ 253.365386] [] (s6x0_i2c_transfer+0x3c0/0x3e0) from [] (s6x0_read_mac_address+0x70/0xc0) [ 253.375823] [] (s6x0_read_mac_address+0x70/0xc0) from [] (dvb_usb_adapter_dvb_init+0x64/0x1c0) [ 253.386810] [] (dvb_usb_adapter_dvb_init+0x64/0x1c0) from [] (dvb_usb_device_init+0x444/0x608) [ 253.397766] [] (dvb_usb_device_init+0x444/0x608) from [] (dw2102_probe+0x24c/0x340) [ 253.407714] [] (dw2102_probe+0x24c/0x340) from [] (usb_probe_interface+0x1c0/0x260) [ 253.417663] [] (usb_probe_interface+0x1c0/0x260) from [] (driver_probe_device+0x108/0x21c) [ 253.428253] [] (driver_probe_device+0x108/0x21c) from [] (bus_for_each_drv+0x5c/0x88) [ 253.438385] [] (bus_for_each_drv+0x5c/0x88) from [] (device_attach+0x78/0x90) [ 253.447784] [] (device_attach+0x78/0x90) from [] (bus_probe_device+0x88/0xac) [ 253.457183] [] (bus_probe_device+0x88/0xac) from [] (device_add+0x4b0/0x584) [ 253.466491] [] (device_add+0x4b0/0x584) from [] (usb_set_configuration+0x574/0x78c) [ 253.476470] [] (usb_set_configuration+0x574/0x78c) from [] (generic_probe+0x34/0x78) [ 253.486511] [] (generic_probe+0x34/0x78) from [] (usb_probe_device+0x3c/0x60) [ 253.495910] [] (usb_probe_device+0x3c/0x60) from [] (driver_probe_device+0x108/0x21c) [ 253.506042] [] (driver_probe_device+0x108/0x21c) from [] (bus_for_each_drv+0x5c/0x88) [ 253.516174] [] (bus_for_each_drv+0x5c/0x88) from [] (device_attach+0x78/0x90) [ 253.525573] [] (device_attach+0x78/0x90) from [] (bus_probe_device+0x88/0xac) [ 253.534973] [] (bus_probe_device+0x88/0xac) from [] (device_add+0x4b0/0x584) [ 253.544281] [] (device_add+0x4b0/0x584) from [] (usb_new_device+0x1ec/0x360) [ 253.553588] [] (usb_new_device+0x1ec/0x360) from [] (hub_thread+0x714/0x1360) [ 253.563018] [] (hub_thread+0x714/0x1360) from [] (kthread+0xa4/0xb0) [ 253.571624] [] (kthread+0xa4/0xb0) from [] (ret_from_fork+0x14/0x24) [ 253.580169] [ 253.581756] Restarting kernel threads ... done. [ 253.587005] Restarting tasks ... done. [ 259.016845] PM: Syncing filesystems ... done. [ 259.155700] Freezing user space processes ... (elapsed 0.02 seconds) done. Regards, Kishore From: Krishna Kishore Sent: Wednesday, July 31, 2013 4:08 PM To: Oliver Schinagl Cc: linux-media@vger.kernel.org Subject: RE: Prof DVB-S2 USB device Hi Oliver, I migrated to Ubuntu 13.04 on desktop and tried. It worked ! It uses linux kernel 3.8.0. If I use this version of linux kernel or greater on Pandaboard, it may work on Pandaboard also. Regards, Kishore. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Tuesday, July 30, 2013 12:18 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 30-07-13 08:25, Krishna Kishore wrote: Hi Oliver, 3.10.2 booted on Pandaboard. Now, I am trying to connect Prof 7500 DVB-S2 device. It does not get
Re: [PATCH 1/2] videobuf2-dma-sg: Allocate pages as contiguous as possible
Hi Sakarius I think the whole point of the videobuf2 is sharing pages with the user space, so until vm_insert_page does not support high order pages we should split them. Unfortunately the mm is completely out of my topic, so I don't think that I could be very useful there. With my patch, in the worst case scenario, the image is split in as many blocks as today, but in a normal setup the ammount of blocks is 1 or two blocks in total!. Best regards. On Wed, Jul 31, 2013 at 8:37 AM, Sakari Ailus wrote: > Hi Jon and Sylwester, > > On Mon, Jul 29, 2013 at 09:16:44AM -0600, Jonathan Corbet wrote: >> On Mon, 29 Jul 2013 13:27:12 +0200 >> Marek Szyprowski wrote: >> >> > > You've gone to all this trouble to get a higher-order allocation so you'd >> > > have fewer segments, then you undo it all by splitting things apart into >> > > individual pages. Why? Clearly I'm missing something, this seems to >> > > defeat the purpose of the whole exercise? >> > >> > Individual zero-order pages are required to get them mapped to userspace in >> > mmap callback. >> >> Yeah, Ricardo explained that too. The right solution might be to fix that >> problem rather than work around it, but I can see why one might shy at that >> task! :) >> >> I do wonder, though, if an intermediate solution using huge pages might be >> the best approach? That would get the number of segments down pretty far, >> and using huge pages for buffers would reduce TLB pressure significantly >> if the CPU is working through the data at all. Meanwhile, inserting huge >> pages into the process's address space should work easily. Just a thought. > > My ack to that. > > And in the case of dma-buf the buffer doesn't need to be mapped to user > space. It'd be quite nice to be able to share higher order allocations even > if they couldn't be mapped to user space as such. > > Using 2 MiB pages would probably solve Ricardo's issue, but used alone > they'd waste lots of memory for small buffers. If small pages (in Ricardo's > case) were used when 2 MiB pages would be too big, e.g. 1 MiB buffer would > already have 256 pages in it. Perhaps it'd be useful to specify whether > large pages should be always preferred over smaller ones. > > -- > Kind regards, > > Sakari Ailus > e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- Ricardo Ribalda -- 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 1/2] libv4lconvert: Support for Y16 pixel format
This patch adds support for V4L2_PIX_FMT_Y16 format.
Signed-off-by: Ricardo Ribalda Delgado
---
lib/libv4lconvert/libv4lconvert-priv.h |6 ++
lib/libv4lconvert/libv4lconvert.c | 19 +++
lib/libv4lconvert/rgbyuv.c | 30 ++
3 files changed, 55 insertions(+)
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
b/lib/libv4lconvert/libv4lconvert-priv.h
index c37e220..6422fdd 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -152,6 +152,12 @@ void v4lconvert_grey_to_rgb24(const unsigned char *src,
unsigned char *dest,
void v4lconvert_grey_to_yuv420(const unsigned char *src, unsigned char *dest,
const struct v4l2_format *src_fmt);
+void v4lconvert_y16_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height);
+
+void v4lconvert_y16_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt);
+
int v4lconvert_y10b_to_rgb24(struct v4lconvert_data *data,
const unsigned char *src, unsigned char *dest, int width, int height);
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index 60010f1..bc5e34f 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -128,6 +128,7 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_Y4, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y6, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y10BPACK,10, 20, 20, 0 },
+ { V4L2_PIX_FMT_Y16, 16, 20, 20, 0 },
};
static const struct v4lconvert_pixfmt supported_dst_pixfmts[] = {
@@ -989,6 +990,24 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
break;
}
+ case V4L2_PIX_FMT_Y16:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_y16_to_rgb24(src, dest, width, height);
+ break;
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ v4lconvert_y16_to_yuv420(src, dest, fmt);
+ break;
+ }
+ if (src_size < (width * height * 2)) {
+ V4LCONVERT_ERR("short y16 data frame\n");
+ errno = EPIPE;
+ result = -1;
+ }
+ break;
+
case V4L2_PIX_FMT_GREY:
case V4L2_PIX_FMT_Y4:
case V4L2_PIX_FMT_Y6:
diff --git a/lib/libv4lconvert/rgbyuv.c b/lib/libv4lconvert/rgbyuv.c
index d05abe9..bef034f 100644
--- a/lib/libv4lconvert/rgbyuv.c
+++ b/lib/libv4lconvert/rgbyuv.c
@@ -586,6 +586,36 @@ void v4lconvert_rgb565_to_yuv420(const unsigned char *src,
unsigned char *dest,
}
}
+void v4lconvert_y16_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height)
+{
+ int j;
+ while (--height >= 0) {
+ for (j = 0; j < width; j++) {
+ *dest++ = *src;
+ *dest++ = *src;
+ *dest++ = *src;
+ src+=2;
+ }
+ }
+}
+
+void v4lconvert_y16_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt)
+{
+ int x, y;
+
+ /* Y */
+ for (y = 0; y < src_fmt->fmt.pix.height; y++)
+ for (x = 0; x < src_fmt->fmt.pix.width; x++){
+ *dest++ = *src;
+ src+=2;
+ }
+
+ /* Clear U/V */
+ memset(dest, 0x80, src_fmt->fmt.pix.width * src_fmt->fmt.pix.height /
2);
+}
+
void v4lconvert_grey_to_rgb24(const unsigned char *src, unsigned char *dest,
int width, int height)
{
--
1.7.10.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 v4 6/7] vsp1: Fix lack of the sink entity registration for enabled links
Hi Laurent, On Thu, Aug 01, 2013 at 12:48:39AM +0200, Laurent Pinchart wrote: > Hi Sakari, > > On Thursday 01 August 2013 00:29:21 Sakari Ailus wrote: > > On Wed, Jul 31, 2013 at 05:52:33PM +0200, Laurent Pinchart wrote: > > > From: Katsuya Matsubara > > > > > > Each source entity maintains a pointer to the counterpart sink > > > entity while an enabled link connects them. It should be managed by > > > the setup_link callback in the media controller framework at runtime. > > > However, enabled links which connect RPFs and WPFs that have an > > > equivalent index number are created during initialization. > > > This registers the pointer to a sink entity from the source entity > > > when an enabled link is created. > > > > > > Signed-off-by: Katsuya Matsubara > > > Signed-off-by: Laurent Pinchart > > > > > > --- > > > > > > drivers/media/platform/vsp1/vsp1_drv.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/media/platform/vsp1/vsp1_drv.c > > > b/drivers/media/platform/vsp1/vsp1_drv.c index b05aee1..4d338ce 100644 > > > --- a/drivers/media/platform/vsp1/vsp1_drv.c > > > +++ b/drivers/media/platform/vsp1/vsp1_drv.c > > > @@ -101,6 +101,9 @@ static int vsp1_create_links(struct vsp1_device *vsp1, > > > struct vsp1_entity *sink)> > > > entity, pad, flags); > > > > > > if (ret < 0) > > > return ret; > > > + > > > + if (flags & MEDIA_LNK_FL_ENABLED) > > > + source->sink = entity; > > > > "entity" here is in fact an entity which is a sink. It could have a more > > descriptive name. Up to you; should be changed in the 5th patch first. > > There's already a local variable called sink that points to the sink > vsp1_entity. entity points to the media_entity contained in the vsp1_entity. > Feel free to propose different names, otherwise I'll keep it as-is. How about sink_entity, for instance? But I'm fine with "entity", too. -- Cheers, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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/2] Add support for V4L2_PIX_FMT_Y16, V4L2_PIX_FMT_RGB32 and V4L2_PIX_FMT_BGR32
This patch adds support for 3 new formats. Ricardo Ribalda Delgado (2): libv4lconvert: Support for Y16 pixel format libv4lconvert: Support for RGB32 and BGR32 format lib/libv4lconvert/libv4lconvert-priv.h | 11 +++- lib/libv4lconvert/libv4lconvert.c | 77 +++-- lib/libv4lconvert/rgbyuv.c | 96 3 files changed, 166 insertions(+), 18 deletions(-) -- 1.7.10.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 2/2] libv4lconvert: Support for RGB32 and BGR32 format
This patch adds support for V4L2_PIX_FMT_BGR32 and V4L2_PIX_FMT_BGR32
formats.
Signed-off-by: Ricardo Ribalda Delgado
---
lib/libv4lconvert/libv4lconvert-priv.h |5 ++-
lib/libv4lconvert/libv4lconvert.c | 58 +---
lib/libv4lconvert/rgbyuv.c | 66 ++--
3 files changed, 111 insertions(+), 18 deletions(-)
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h
b/lib/libv4lconvert/libv4lconvert-priv.h
index 6422fdd..2f411ea 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -108,7 +108,7 @@ unsigned char *v4lconvert_alloc_buffer(int needed,
int v4lconvert_oom_error(struct v4lconvert_data *data);
void v4lconvert_rgb24_to_yuv420(const unsigned char *src, unsigned char *dest,
- const struct v4l2_format *src_fmt, int bgr, int yvu);
+ const struct v4l2_format *src_fmt, int bgr, int yvu, int rgb32);
void v4lconvert_yuv420_to_rgb24(const unsigned char *src, unsigned char *dst,
int width, int height, int yvu);
@@ -158,6 +158,9 @@ void v4lconvert_y16_to_rgb24(const unsigned char *src,
unsigned char *dest,
void v4lconvert_y16_to_yuv420(const unsigned char *src, unsigned char *dest,
const struct v4l2_format *src_fmt);
+void v4lconvert_rgb32_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height, int bgr);
+
int v4lconvert_y10b_to_rgb24(struct v4lconvert_data *data,
const unsigned char *src, unsigned char *dest, int width, int height);
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index bc5e34f..a5ada5b 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -84,6 +84,8 @@ static const struct v4lconvert_pixfmt supported_src_pixfmts[]
= {
SUPPORTED_DST_PIXFMTS,
/* packed rgb formats */
{ V4L2_PIX_FMT_RGB565, 16, 4, 6, 0 },
+ { V4L2_PIX_FMT_BGR32, 32, 4, 6, 0 },
+ { V4L2_PIX_FMT_RGB32, 32, 4, 6, 0 },
/* yuv 4:2:2 formats */
{ V4L2_PIX_FMT_YUYV,16, 5, 4, 0 },
{ V4L2_PIX_FMT_YVYU,16, 5, 4, 0 },
@@ -981,10 +983,10 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
v4lconvert_swap_rgb(d, dest, width, height);
break;
case V4L2_PIX_FMT_YUV420:
- v4lconvert_rgb24_to_yuv420(d, dest, fmt, 0, 0);
+ v4lconvert_rgb24_to_yuv420(d, dest, fmt, 0, 0, 0);
break;
case V4L2_PIX_FMT_YVU420:
- v4lconvert_rgb24_to_yuv420(d, dest, fmt, 0, 1);
+ v4lconvert_rgb24_to_yuv420(d, dest, fmt, 0, 1, 0);
break;
}
break;
@@ -1079,10 +1081,10 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
v4lconvert_swap_rgb(src, dest, width, height);
break;
case V4L2_PIX_FMT_YUV420:
- v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 0);
+ v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 0, 0);
break;
case V4L2_PIX_FMT_YVU420:
- v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 1);
+ v4lconvert_rgb24_to_yuv420(src, dest, fmt, 0, 1, 0);
break;
}
if (src_size < (width * height * 3)) {
@@ -1101,10 +1103,10 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
memcpy(dest, src, width * height * 3);
break;
case V4L2_PIX_FMT_YUV420:
- v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 0);
+ v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 0, 0);
break;
case V4L2_PIX_FMT_YVU420:
- v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 1);
+ v4lconvert_rgb24_to_yuv420(src, dest, fmt, 1, 1, 0);
break;
}
if (src_size < (width * height * 3)) {
@@ -1114,6 +1116,50 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
}
break;
+ case V4L2_PIX_FMT_RGB32:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ v4lconvert_rgb32_to_rgb24(src, dest, width, height, 0);
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_rgb32_to_rgb24(src, dest, width, height, 1);
+ break;
+ case V4L2_PIX_FMT_YUV420:
+ v4lconvert_rgb24_to
[PATCH] libv4lconvert: Support for Y16 pixel format
This patch adds support for V4L2_PIX_FMT_Y16 format.
Signed-off-by: Ricardo Ribalda Delgado
---
lib/libv4lconvert/libv4lconvert.c | 19 +++
lib/libv4lconvert/rgbyuv.c| 30 ++
2 files changed, 49 insertions(+)
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index 60010f1..bc5e34f 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -128,6 +128,7 @@ static const struct v4lconvert_pixfmt
supported_src_pixfmts[] = {
{ V4L2_PIX_FMT_Y4, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y6, 8, 20, 20, 0 },
{ V4L2_PIX_FMT_Y10BPACK,10, 20, 20, 0 },
+ { V4L2_PIX_FMT_Y16, 16, 20, 20, 0 },
};
static const struct v4lconvert_pixfmt supported_dst_pixfmts[] = {
@@ -989,6 +990,24 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
break;
}
+ case V4L2_PIX_FMT_Y16:
+ switch (dest_pix_fmt) {
+ case V4L2_PIX_FMT_RGB24:
+ case V4L2_PIX_FMT_BGR24:
+ v4lconvert_y16_to_rgb24(src, dest, width, height);
+ break;
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ v4lconvert_y16_to_yuv420(src, dest, fmt);
+ break;
+ }
+ if (src_size < (width * height * 2)) {
+ V4LCONVERT_ERR("short y16 data frame\n");
+ errno = EPIPE;
+ result = -1;
+ }
+ break;
+
case V4L2_PIX_FMT_GREY:
case V4L2_PIX_FMT_Y4:
case V4L2_PIX_FMT_Y6:
diff --git a/lib/libv4lconvert/rgbyuv.c b/lib/libv4lconvert/rgbyuv.c
index d05abe9..bef034f 100644
--- a/lib/libv4lconvert/rgbyuv.c
+++ b/lib/libv4lconvert/rgbyuv.c
@@ -586,6 +586,36 @@ void v4lconvert_rgb565_to_yuv420(const unsigned char *src,
unsigned char *dest,
}
}
+void v4lconvert_y16_to_rgb24(const unsigned char *src, unsigned char *dest,
+ int width, int height)
+{
+ int j;
+ while (--height >= 0) {
+ for (j = 0; j < width; j++) {
+ *dest++ = *src;
+ *dest++ = *src;
+ *dest++ = *src;
+ src+=2;
+ }
+ }
+}
+
+void v4lconvert_y16_to_yuv420(const unsigned char *src, unsigned char *dest,
+ const struct v4l2_format *src_fmt)
+{
+ int x, y;
+
+ /* Y */
+ for (y = 0; y < src_fmt->fmt.pix.height; y++)
+ for (x = 0; x < src_fmt->fmt.pix.width; x++){
+ *dest++ = *src;
+ src+=2;
+ }
+
+ /* Clear U/V */
+ memset(dest, 0x80, src_fmt->fmt.pix.width * src_fmt->fmt.pix.height /
2);
+}
+
void v4lconvert_grey_to_rgb24(const unsigned char *src, unsigned char *dest,
int width, int height)
{
--
1.7.10.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] drm/exynos: Add check for IOMMU while passing physically continous memory flag
While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
connected with resolution 2560x1600, following error occured even with
IOMMU enabled:
[0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
[0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
This patch fixes the issue by adding a check for IOMMU.
Signed-off-by: Vikas Sajjan
Signed-off-by: Arun Kumar
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 8e60bd6..2a8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "exynos_drm_drv.h"
#include "exynos_drm_fb.h"
@@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
*helper,
struct platform_device *pdev = dev->platformdev;
unsigned long size;
int ret;
+ unsigned int flag;
DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",
sizes->surface_width, sizes->surface_height,
@@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
*helper,
size = mode_cmd.pitches[0] * mode_cmd.height;
/* 0 means to allocate physically continuous memory */
- exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
+ if (!is_drm_iommu_supported(dev))
+ flag = 0;
+ else
+ flag = EXYNOS_BO_NONCONTIG;
+
+ exynos_gem_obj = exynos_drm_gem_create(dev, flag, size);
if (IS_ERR(exynos_gem_obj)) {
ret = PTR_ERR(exynos_gem_obj);
goto err_release_framebuffer;
--
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: [PATCHv2 FINAL 6/6] qv4l2: add OpenGL rendering
On Tuesday, July 30, 2013 10:15:24 AM you wrote:
> [PATCHv2 FINAL 6/6] qv4l2: add OpenGL rendering
>From 505e803da95dd7c4aeb9d7ec4661c83bb743da1e Mon Sep 17 00:00:00 2001
Message-Id:
<505e803da95dd7c4aeb9d7ec4661c83bb743da1e.1375355021.git.bwint...@cisco.com>
From: =?UTF-8?q?B=C3=A5rd=20Eirik=20Winther?=
Date: Thu, 1 Aug 2013 13:02:43 +0200
Subject: [PATCH] qv4l2: fix compile error
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Fixes a compile error caused when opengl is not available
Signed-off-by: Bård Eirik Winther
---
utils/qv4l2/capture-win-gl.cpp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/utils/qv4l2/capture-win-gl.cpp b/utils/qv4l2/capture-win-gl.cpp
index 807d9e9..52412c7 100644
--- a/utils/qv4l2/capture-win-gl.cpp
+++ b/utils/qv4l2/capture-win-gl.cpp
@@ -26,7 +26,9 @@
CaptureWinGL::CaptureWinGL()
{
+#ifdef ENABLE_GL
CaptureWin::buildWindow(&m_videoSurface);
+#endif
CaptureWin::setWindowTitle("V4L2 Capture (OpenGL)");
}
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Prof DVB-S2 USB device
Hi, Does anyone know about the following error? I am using Linux kernel 3.9.0. I am getting this error with 3.8.4 also. [ 233.017242] PM: Syncing filesystems ... done. [ 233.253112] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 233.273712] Freezing remaining freezable tasks ... [ 253.291076] Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0): [ 253.300445] khubd D c053586c 0 446 2 0x [ 253.307220] [] (__schedule+0x37c/0x7e0) from [] (schedule_timeout+0x124/0x220) [ 253.316741] [] (schedule_timeout+0x124/0x220) from [] (wait_for_common+0xac/0x150) [ 253.326599] [] (wait_for_common+0xac/0x150) from [] (usb_start_wait_urb+0x60/0x128) [ 253.336547] [] (usb_start_wait_urb+0x60/0x128) from [] (usb_control_msg+0xc0/0xe4) [ 253.346405] [] (usb_control_msg+0xc0/0xe4) from [] (dw210x_op_rw+0x94/0x108) [ 253.355712] [] (dw210x_op_rw+0x94/0x108) from [] (s6x0_i2c_transfer+0x3c0/0x3e0) [ 253.365386] [] (s6x0_i2c_transfer+0x3c0/0x3e0) from [] (s6x0_read_mac_address+0x70/0xc0) [ 253.375823] [] (s6x0_read_mac_address+0x70/0xc0) from [] (dvb_usb_adapter_dvb_init+0x64/0x1c0) [ 253.386810] [] (dvb_usb_adapter_dvb_init+0x64/0x1c0) from [] (dvb_usb_device_init+0x444/0x608) [ 253.397766] [] (dvb_usb_device_init+0x444/0x608) from [] (dw2102_probe+0x24c/0x340) [ 253.407714] [] (dw2102_probe+0x24c/0x340) from [] (usb_probe_interface+0x1c0/0x260) [ 253.417663] [] (usb_probe_interface+0x1c0/0x260) from [] (driver_probe_device+0x108/0x21c) [ 253.428253] [] (driver_probe_device+0x108/0x21c) from [] (bus_for_each_drv+0x5c/0x88) [ 253.438385] [] (bus_for_each_drv+0x5c/0x88) from [] (device_attach+0x78/0x90) [ 253.447784] [] (device_attach+0x78/0x90) from [] (bus_probe_device+0x88/0xac) [ 253.457183] [] (bus_probe_device+0x88/0xac) from [] (device_add+0x4b0/0x584) [ 253.466491] [] (device_add+0x4b0/0x584) from [] (usb_set_configuration+0x574/0x78c) [ 253.476470] [] (usb_set_configuration+0x574/0x78c) from [] (generic_probe+0x34/0x78) [ 253.486511] [] (generic_probe+0x34/0x78) from [] (usb_probe_device+0x3c/0x60) [ 253.495910] [] (usb_probe_device+0x3c/0x60) from [] (driver_probe_device+0x108/0x21c) [ 253.506042] [] (driver_probe_device+0x108/0x21c) from [] (bus_for_each_drv+0x5c/0x88) [ 253.516174] [] (bus_for_each_drv+0x5c/0x88) from [] (device_attach+0x78/0x90) [ 253.525573] [] (device_attach+0x78/0x90) from [] (bus_probe_device+0x88/0xac) [ 253.534973] [] (bus_probe_device+0x88/0xac) from [] (device_add+0x4b0/0x584) [ 253.544281] [] (device_add+0x4b0/0x584) from [] (usb_new_device+0x1ec/0x360) [ 253.553588] [] (usb_new_device+0x1ec/0x360) from [] (hub_thread+0x714/0x1360) [ 253.563018] [] (hub_thread+0x714/0x1360) from [] (kthread+0xa4/0xb0) [ 253.571624] [] (kthread+0xa4/0xb0) from [] (ret_from_fork+0x14/0x24) [ 253.580169] [ 253.581756] Restarting kernel threads ... done. [ 253.587005] Restarting tasks ... done. [ 259.016845] PM: Syncing filesystems ... done. [ 259.155700] Freezing user space processes ... (elapsed 0.02 seconds) done. Regards, Kishore From: Krishna Kishore Sent: Wednesday, July 31, 2013 4:08 PM To: Oliver Schinagl Cc: linux-media@vger.kernel.org Subject: RE: Prof DVB-S2 USB device Hi Oliver, I migrated to Ubuntu 13.04 on desktop and tried. It worked ! It uses linux kernel 3.8.0. If I use this version of linux kernel or greater on Pandaboard, it may work on Pandaboard also. Regards, Kishore. -Original Message- From: Oliver Schinagl [mailto:oliver+l...@schinagl.nl] Sent: Tuesday, July 30, 2013 12:18 PM To: Krishna Kishore Cc: linux-media@vger.kernel.org Subject: Re: Prof DVB-S2 USB device On 30-07-13 08:25, Krishna Kishore wrote: > Hi Oliver, > > 3.10.2 booted on Pandaboard. Now, I am trying to connect Prof 7500 > DVB-S2 device. It does not get detected as new USB device. > > .config file is attached to this email. Am I missing any config? Can you > please let me know? From a quick glance I noticed you are missing the CONFIG_USB_EHCI_HCD (EHCI Host controller) it appears you don't have a USB host controller enabled at all? But i'm not sure what kind of USB controller omap4 has. oliver > > Regards, > Kishore. > > From: Oliver Schinagl [oliver+l...@schinagl.nl] > Sent: Wednesday, July 24, 2013 5:47 PM > To: Krishna Kishore > Cc: linux-media@vger.kernel.org > Subject: Re: Prof DVB-S2 USB device > > On 24-07-13 13:20, Krishna Kishore wrote: >> >> On Desktop PC (Ubuntu 12.04 which has 3.2.0 Kernel) also, I am not getting >> the list of channels when I scan. I am using Kaffeine. > While I understand you prefer to run a LTS distro, 3.2.0 is old! > > The reason why I keep bringing this up, media drivers are almost > updated daily. So if you want to see if your issue is fixed, the most > ideal start for this investigation is the media git kernel
Re: [RESEND PATCH v10 1/8] drivers: phy: add generic PHY framework
On Fri, Jul 26, 2013 at 06:19:16PM +0530, Kishon Vijay Abraham I wrote:
> +static int phy_get_id(void)
> +{
> + int ret;
> + int id;
> +
> + ret = ida_pre_get(&phy_ida, GFP_KERNEL);
> + if (!ret)
> + return -ENOMEM;
> +
> + ret = ida_get_new(&phy_ida, &id);
> + if (ret < 0)
> + return ret;
> +
> + return id;
> +}
ida_simple_get() instead? And if you do that, you can get rid of this
function entirely.
thanks,
greg k-h
--
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
