Re: [linuxtv-media:master 378/499] ERROR: "__udivdi3" [drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined!
Moikka! On 07/23/2014 02:20 PM, kbuild test robot wrote: tree: git://linuxtv.org/media_tree.git master head: eb9da073bd002f2968c84129a5c49625911a3199 commit: 77bbb2b049c1c3e935f5bec510bec337d94ae8f8 [378/499] rtl2832_sdr: move from staging to media config: i386-randconfig-ha2-0723 (attached as .config) Note: the linuxtv-media/master HEAD eb9da073bd002f2968c84129a5c49625911a3199 builds fine. It only hurts bisectibility. All error/warnings: ERROR: "__udivdi3" [drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined! Could you say what I should do for that? Bug is fixed and solution is merged as that patch: commit a98ccfcf4804beb2651b9f44a4bc5cbb387019ec Author: Antti Palosaari Date: Tue Jul 22 00:18:19 2014 -0300 [media] rtl2832_sdr: remove plain 64-bit divisions Do you want Mauro to rebase whole media/master in order to make bisectibility possible in any case? regards Antti -- http://palosaari.fi/ -- 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: [V4l2-library] FourCC support
On 07/23/2014 07:04 AM, Monica, Agnes wrote: > Hi, > > It would be good if support exists for full and limited range. > > 1. So can we re-use(map) the existing colorspace for our different color > format. Well, no, obviously. You need to propose new colorspace defines. The list of colorspace defines is in videodev2.h. the best procedure is to post an RFC to the linux-media mailinglist with the new defines that you need and explain why you need them. The next step would be to write patches adding those defines and updating the DocBook documentation (Documentation/DocBook/media/v4l/pixfmt.xml). Contact me first before working on the docbook since I plan on rewriting that section. There is always a chicken-and-egg problem in that a driver actually need to use the new defines before they can go in. However, in this case you can try to add support for it to e.g. adv7604 and/or adv7511. That might be the fastest way of getting it in. > 2. Or is it a good way to use custom control command. Absolutely not. Colorspace handling is done through the colorspace defines. So if you need new ones, just add them properly. For what chip(s) are you developing? Quite a few adv drivers are already in the kernel. Perhaps it is wise to coordinate this? In particular, take a look at existing drivers like the adv7604 and adv7511. > > So in future if we come across some specific features with respect to > our chip, is it good to use custom control or duplicate the > functionality of the existing enums. First you ask on the mailinglist, then we can give an answer what the best approach will be. Abuse of existing APIs will make it very hard if not impossible to get such a driver merged in the kernel. So please don't do that. In general either proper support should be added to v4l2 for the feature you want to add, or it is a driver-specific control or ioctl. But all too often what you think is driver specific is really a lot more common than you thought. But above all, ask first on the mailinglist! If your goal is to upstream the drivers (I hope so, speaking as one customer of Analog), then please avoid taking shortcuts. It will only cause problems later. I'm happy to help out with pointers, review, etc. Regards, Hans > > Regards, > Monica > > -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: Tuesday, July 22, 2014 1:08 PM > To: Monica, Agnes; v4l2-libr...@linuxtv.org; linux-media; Lars-Peter Clausen > Subject: Re: [V4l2-library] FourCC support > > On 07/22/14 09:23, Hans Verkuil wrote: >> Hi Monica, >> >> The v4l2-library is not the best mailinglist for that so I've added >> linux-media as well, which is more appropriate. I've also added >> Lars-Peter since he does a lot of adv work as well. >> >> The short answer is that those colorspaces are not supported at the >> moment, but that it is not a problem to add them, provided the driver >> you are working on is going to be upstreamed (i.e., we'd like to have >> users for the API elements we add). >> >> One note of interest: there is currently no API mechanism to tell >> userspace if the image data is limited or full range. YCbCr is always >> assumed to be limited range and RGB full range. If you need to signal >> that, then let me know. A flags field has been added to struct >> v4l2_pix_format in the last few days that would allow you to add a >> 'ALT_RANGE' flag, telling userspace that the alternate quantization >> range is used. This flag doesn't exist yet, but it is no problem to add it. > > To prevent any confusion: the colorspace isn't determined by the format > fourcc, it's a separate colorspace field using the V4L2_COLORSPACE_* defines. > The pixelformat and colorspace are two very different things. > > Regards, > > Hans > >> >> Hope this helps, >> >> Hans >> >> On 07/22/14 08:18, Monica, Agnes wrote: >>> Hi , >>> >>> One of drivers which we are developing supports formats like sYcc , >>> AdobeRGB and AdobeYCC601 which was added recently in HDMI spec1.4. So >>> can you please tell me how will these formats be supported by fmt. >>> >>> Regards, >>> >>> Monica >> >> -- >> 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
[PATCH for v3.17] vb2: fix videobuf2-core.h comments
A lot of work was done in vb2 to regulate how drivers and the vb2 core handle
buffer ownership, but inexplicably the videobuf2-core.h comments were never
updated. Do so now. The same was true for the replacement of the -ENOBUFS
mechanism by the min_buffers_needed field.
Signed-off-by: Hans Verkuil
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 1a262ae..fc910a6 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -294,15 +294,19 @@ struct vb2_buffer {
* of already queued buffers in count parameter; driver
* can return an error if hardware fails, in that case all
* buffers that have been already given by the @buf_queue
- * callback are invalidated.
- * If there were not enough queued buffers to start
- * streaming, then this callback returns -ENOBUFS, and the
- * vb2 core will retry calling @start_streaming when a new
- * buffer is queued.
+ * callback are to be returned by the driver by calling
+ * @vb2_buffer_done(VB2_BUF_STATE_DEQUEUED).
+ * If you need a minimum number of buffers before you can
+ * start streaming, then set @min_buffers_needed in the
+ * vb2_queue structure. If that is non-zero then
+ * start_streaming won't be called until at least that
+ * many buffers have been queued up by userspace.
* @stop_streaming:called when 'streaming' state must be disabled; driver
* should stop any DMA transactions or wait until they
* finish and give back all buffers it got from buf_queue()
- * callback; may use vb2_wait_for_all_buffers() function
+ * callback by calling @vb2_buffer_done() with either
+ * VB2_BUF_STATE_DONE or VB2_BUF_STATE_ERROR; may use
+ * vb2_wait_for_all_buffers() function
* @buf_queue: passes buffer vb to the driver; driver may start
* hardware operation on this buffer; driver should give
* the buffer back by calling vb2_buffer_done() function;
--
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] v4l2: don't warn before we release buffer
On 07/24/2014 05:53 AM, Scott Jiang wrote:
> In fact we only need to give a warning if the driver still use the
> buffer after we release all queued buffers.
>
> Signed-off-by: Scott Jiang
Nacked-by: Hans Verkuil
You're removing the warning telling you that your driver has a bug instead
of fixing the driver bug itself. In stop_streaming the driver must hand over
any buffers it owns to vb2 (vb2_buffer_done(..., STATE_ERROR)). If it doesn't
you'll get this warning and vb2 will forcefully reclaim them, quite possibly
leaving the driver with a corrupt buffer list.
The same should occur in start_streaming if an error occurs. In that case
start_streaming must return the buffers to STATE_DEQUEUED.
So fix your driver instead :-)
Regards,
Hans
> ---
> drivers/media/v4l2-core/videobuf2-core.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 7c4489c..fa5dd73 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -2112,7 +2112,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
> if (q->start_streaming_called)
> call_void_qop(q, stop_streaming, q);
>
> - if (WARN_ON(atomic_read(&q->owned_by_drv_count))) {
> + if (atomic_read(&q->owned_by_drv_count)) {
> for (i = 0; i < q->num_buffers; ++i)
> if (q->bufs[i]->state == VB2_BUF_STATE_ACTIVE)
> vb2_buffer_done(q->bufs[i],
> VB2_BUF_STATE_ERROR);
>
--
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: [V4l2-library] FourCC support
Hi, It would be good if support exists for full and limited range. 1. So can we re-use(map) the existing colorspace for our different color format. 2. Or is it a good way to use custom control command. So in future if we come across some specific features with respect to our chip, is it good to use custom control or duplicate the functionality of the existing enums. Regards, Monica -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, July 22, 2014 1:08 PM To: Monica, Agnes; v4l2-libr...@linuxtv.org; linux-media; Lars-Peter Clausen Subject: Re: [V4l2-library] FourCC support On 07/22/14 09:23, Hans Verkuil wrote: > Hi Monica, > > The v4l2-library is not the best mailinglist for that so I've added > linux-media as well, which is more appropriate. I've also added > Lars-Peter since he does a lot of adv work as well. > > The short answer is that those colorspaces are not supported at the > moment, but that it is not a problem to add them, provided the driver > you are working on is going to be upstreamed (i.e., we'd like to have > users for the API elements we add). > > One note of interest: there is currently no API mechanism to tell > userspace if the image data is limited or full range. YCbCr is always > assumed to be limited range and RGB full range. If you need to signal > that, then let me know. A flags field has been added to struct > v4l2_pix_format in the last few days that would allow you to add a > 'ALT_RANGE' flag, telling userspace that the alternate quantization > range is used. This flag doesn't exist yet, but it is no problem to add it. To prevent any confusion: the colorspace isn't determined by the format fourcc, it's a separate colorspace field using the V4L2_COLORSPACE_* defines. The pixelformat and colorspace are two very different things. Regards, Hans > > Hope this helps, > > Hans > > On 07/22/14 08:18, Monica, Agnes wrote: >> Hi , >> >> One of drivers which we are developing supports formats like sYcc , >> AdobeRGB and AdobeYCC601 which was added recently in HDMI spec1.4. So >> can you please tell me how will these formats be supported by fmt. >> >> Regards, >> >> Monica > > -- > 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
[PATCH] media: s5p_mfc: remove unnecessary calling to function video_devdata()
Since we have get vdev by calling video_devdata() at the beginning of s5p_mfc_open(), we should just use vdev instead of calling video_devdata() again in the following code. Signed-off-by: Zhaowei Yuan --- drivers/media/platform/s5p-mfc/s5p_mfc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index d57b306..d508cbc 100755 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -709,7 +709,7 @@ static int s5p_mfc_open(struct file *file) ret = -ENOMEM; goto err_alloc; } - v4l2_fh_init(&ctx->fh, video_devdata(file)); + v4l2_fh_init(&ctx->fh, vdev); file->private_data = &ctx->fh; v4l2_fh_add(&ctx->fh); ctx->dev = dev; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: s5p_mfc: Check the right pointer after allocation
It should be bank2_virt to be checked after dma allocation
instead of dev->fw_virt_addr.
Signed-off-by: Zhaowei Yuan
---
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index dc1fc94..55ad881 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -50,7 +50,7 @@ int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
bank2_virt = dma_alloc_coherent(dev->mem_dev_r, 1 <<
MFC_BASE_ALIGN_ORDER,
&bank2_dma_addr, GFP_KERNEL);
- if (IS_ERR(dev->fw_virt_addr)) {
+ if (IS_ERR(bank2_virt)) {
mfc_err("Allocating bank2 base failed\n");
dma_free_coherent(dev->mem_dev_l, dev->fw_size,
dev->fw_virt_addr, dev->bank1);
--
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] v4l2: don't warn before we release buffer
In fact we only need to give a warning if the driver still use the
buffer after we release all queued buffers.
Signed-off-by: Scott Jiang
---
drivers/media/v4l2-core/videobuf2-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 7c4489c..fa5dd73 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2112,7 +2112,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
if (q->start_streaming_called)
call_void_qop(q, stop_streaming, q);
- if (WARN_ON(atomic_read(&q->owned_by_drv_count))) {
+ if (atomic_read(&q->owned_by_drv_count)) {
for (i = 0; i < q->num_buffers; ++i)
if (q->bufs[i]->state == VB2_BUF_STATE_ACTIVE)
vb2_buffer_done(q->bufs[i],
VB2_BUF_STATE_ERROR);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] exynos-gsc: Remove PM_RUNTIME dependency
Hi Sachin,
Thanks for testing.
Even I tested with both PM enable/disable with EXYNOS_IOMMU. I didn't
face any issues.
Let me check with out IOMMU. I will update the status soon.
Regards,
Shaik Ameer Basha
On Tue, Jul 22, 2014 at 10:31 AM, Sachin Kamat wrote:
> Hi Shaik,
>
> On Mon, Jul 21, 2014 at 10:24 AM, Shaik Ameer Basha
> wrote:
>> 1] Currently Gscaler clock is enabled only inside pm_runtime callbacks.
>>If PM_RUNTIME is disabled, driver hangs. This patch removes the
>>PM_RUNTIME dependency by keeping the clock enable/disable functions
>>in m2m start/stop streaming callbacks.
>>
>> 2] For Exynos5420/5800, Gscaler clock has to be Turned ON before powering
>>on/off the Gscaler power domain. This dependency is taken care by
>>this patch at driver level.
>>
>> Signed-off-by: Shaik Ameer Basha
>> ---
>> drivers/media/platform/exynos-gsc/gsc-core.c | 10 ++
>> drivers/media/platform/exynos-gsc/gsc-m2m.c | 13 +
>> 2 files changed, 15 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c
>> b/drivers/media/platform/exynos-gsc/gsc-core.c
>> index 9d0cc04..39c0953 100644
>> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
>> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
>> @@ -1132,23 +1132,17 @@ static int gsc_probe(struct platform_device *pdev)
>>
>> platform_set_drvdata(pdev, gsc);
>> pm_runtime_enable(dev);
>> - ret = pm_runtime_get_sync(&pdev->dev);
>> - if (ret < 0)
>> - goto err_m2m;
>>
>> /* Initialize continious memory allocator */
>> gsc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
>> if (IS_ERR(gsc->alloc_ctx)) {
>> ret = PTR_ERR(gsc->alloc_ctx);
>> - goto err_pm;
>> + goto err_m2m;
>> }
>>
>> dev_dbg(dev, "gsc-%d registered successfully\n", gsc->id);
>> -
>> - pm_runtime_put(dev);
>> return 0;
>> -err_pm:
>> - pm_runtime_put(dev);
>> +
>> err_m2m:
>> gsc_unregister_m2m_device(gsc);
>> err_v4l2:
>> diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c
>> b/drivers/media/platform/exynos-gsc/gsc-m2m.c
>> index e434f1f0..a98462c 100644
>> --- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
>> +++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
>> @@ -60,19 +60,32 @@ static void __gsc_m2m_job_abort(struct gsc_ctx *ctx)
>> static int gsc_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
>> {
>> struct gsc_ctx *ctx = q->drv_priv;
>> + struct gsc_dev *gsc = ctx->gsc_dev;
>> int ret;
>>
>> + ret = clk_enable(gsc->clock);
>> + if (ret)
>> + return ret;
>> +
>> ret = pm_runtime_get_sync(&ctx->gsc_dev->pdev->dev);
>> +
>> + if (!pm_runtime_enabled(&gsc->pdev->dev)) {
>> + gsc_hw_set_sw_reset(gsc);
>> + gsc_wait_reset(gsc);
>> + }
>> +
>> return ret > 0 ? 0 : ret;
>> }
>>
>> static void gsc_m2m_stop_streaming(struct vb2_queue *q)
>> {
>> struct gsc_ctx *ctx = q->drv_priv;
>> + struct gsc_dev *gsc = ctx->gsc_dev;
>>
>> __gsc_m2m_job_abort(ctx);
>>
>> pm_runtime_put(&ctx->gsc_dev->pdev->dev);
>> + clk_disable(gsc->clock);
>> }
>>
>> void gsc_m2m_job_finish(struct gsc_ctx *ctx, int vb_state)
>> --
>> 1.7.9.5
>>
>
> Looks like there is some issue while runtime PM is disabled. The
> conversion operation hangs. Tested on 5420 based Arndale Octa
> board with latest next kernel.
>
> --
> 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] media: s5p_mfc: remove unnecessary calling to function video_devdata()
Hi Zhaowei, On 07/23/2014 09:49 AM, Zhaowei Yuan wrote: > Since we have get vdev by calling video_devdata() at the beginning of > s5p_mfc_open(), we should just use vdev instead of calling video_devdata() > again in the following code. > > Change-Id: I869051762d33b50a7c0dbc8149b072e70b89c6b9 Please don't put this in patch when you submit at upstream. Change-Id means nothing to us. > Signed-off-by: Zhaowei Yuan > --- > drivers/media/platform/s5p-mfc/s5p_mfc.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c > b/drivers/media/platform/s5p-mfc/s5p_mfc.c > index d57b306..d508cbc 100755 > --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c > @@ -709,7 +709,7 @@ static int s5p_mfc_open(struct file *file) > ret = -ENOMEM; > goto err_alloc; > } > - v4l2_fh_init(&ctx->fh, video_devdata(file)); > + v4l2_fh_init(&ctx->fh, vdev); > file->private_data = &ctx->fh; > v4l2_fh_add(&ctx->fh); > ctx->dev = dev; > -- > 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 > -- 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: OK
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: Wed Jul 23 04:00:19 CEST 2014 git branch: test git hash: eb9da073bd002f2968c84129a5c49625911a3199 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-16-g1db35d0 host hardware: x86_64 host os:3.15-5.slh.2-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.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.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: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: s5p_mfc: remove unnecessary calling to function video_devdata()
Since we have get vdev by calling video_devdata() at the beginning of s5p_mfc_open(), we should just use vdev instead of calling video_devdata() again in the following code. Change-Id: I869051762d33b50a7c0dbc8149b072e70b89c6b9 Signed-off-by: Zhaowei Yuan --- drivers/media/platform/s5p-mfc/s5p_mfc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index d57b306..d508cbc 100755 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -709,7 +709,7 @@ static int s5p_mfc_open(struct file *file) ret = -ENOMEM; goto err_alloc; } - v4l2_fh_init(&ctx->fh, video_devdata(file)); + v4l2_fh_init(&ctx->fh, vdev); file->private_data = &ctx->fh; v4l2_fh_add(&ctx->fh); ctx->dev = dev; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: s5p_mfc: Check the right pointer after allocation
It should be bank2_virt to be checked after dma allocation
instead of dev->fw_virt_addr.
Change-Id: I03ed5603de3ef1d97bf76d7d42097d9489b6b003
Signed-off-by: Zhaowei Yuan
---
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index dc1fc94..55ad881 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -50,7 +50,7 @@ int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
bank2_virt = dma_alloc_coherent(dev->mem_dev_r, 1 <<
MFC_BASE_ALIGN_ORDER,
&bank2_dma_addr, GFP_KERNEL);
- if (IS_ERR(dev->fw_virt_addr)) {
+ if (IS_ERR(bank2_virt)) {
mfc_err("Allocating bank2 base failed\n");
dma_free_coherent(dev->mem_dev_l, dev->fw_size,
dev->fw_virt_addr, dev->bank1);
--
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
[Kaffeine PATCH] Be sure to select the delivery system
Hi Christoph,
I know you don't have any time for Kaffeine anymore. Still, it is a very
nice application, with helps me to test some stuff.
However, its DVB support is too outdated, and doesn't work fine with devices
with multiple delivery systems, as it doesn't have support yet for
DTV_ENUM_DELSYS and DTV_DELIVERY_SYSTEM properties.
The enclosed patch should fix it. Could you please commit it at the master
repository?
With that, devices like PCTV 292e that supports both DVB-C and DVB-T will
open a dialog box that will allow configuring channels for both DVB-C and
DVB-T. It will also change to the proper standard at tuner setting.
I might eventually produce other patches for it if I have some time, in order
to make it support ISDB-T and DVB-T2, likely via libdvbv5.
Anyway, this one is an interesting to have, as it avoids the need of calling
an external program to switch between DVB-C and DVB-T on devices that support
both.
Regards,
Mauro
PS.: I created a clone of the Kaffeine tree at:
http://git.linuxtv.org/cgit.cgi/mchehab/kaffeine.git
with the patch below, for those that want to test it.
Regards,
Mauro
---
Subject: [PATCH] Be sure to select the delivery system
Some devices support multiple delivery systems. Enumerate and
select the right delivery system when needed.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/src/dvb/dvbdevice_linux.cpp b/src/dvb/dvbdevice_linux.cpp
index 98da579..eee067c 100644
--- a/src/dvb/dvbdevice_linux.cpp
+++ b/src/dvb/dvbdevice_linux.cpp
@@ -63,6 +63,41 @@ void DvbLinuxDevice::startDevice(const QString &deviceId_)
return;
}
+ struct dtv_properties props;
+ struct dtv_property dvb_prop;
+
+ dvb_prop.cmd = DTV_ENUM_DELSYS;
+ props.num = 1;
+ props.props = &dvb_prop;
+
+ transmissionTypes = 0;
+
+ if (!ioctl(fd, FE_GET_PROPERTY, &props)) {
+ HasDelSys = true;
+
+ for (unsigned i = 0; i < dvb_prop.u.buffer.len; i++) {
+ switch (dvb_prop.u.buffer.data[i]) {
+ case SYS_DVBS:
+ transmissionTypes |= DvbS;
+ break;
+ case SYS_DVBS2:
+ transmissionTypes |= DvbS2;
+ break;
+ case SYS_DVBT:
+ transmissionTypes |= DvbT;
+ break;
+ case SYS_DVBC_ANNEX_A:
+ transmissionTypes |= DvbC;
+ break;
+ case SYS_ATSC:
+ transmissionTypes |= Atsc;
+ break;
+ }
+ }
+ } else {
+ HasDelSys = false;
+ }
+
dvb_frontend_info frontend_info;
memset(&frontend_info, 0, sizeof(frontend_info));
@@ -77,31 +112,33 @@ void DvbLinuxDevice::startDevice(const QString &deviceId_)
deviceId = deviceId_;
frontendName = QString::fromUtf8(frontend_info.name);
- switch (frontend_info.type) {
- case FE_QAM:
- transmissionTypes = DvbC;
- break;
- case FE_QPSK:
- transmissionTypes = DvbS;
-
- if (((frontend_info.caps & FE_CAN_2G_MODULATION) != 0) ||
- (strcmp(frontend_info.name, "Conexant CX24116/CX24118") ==
0) ||
- (strcmp(frontend_info.name, "Genpix 8psk-to-USB2 DVB-S") ==
0) ||
- (strcmp(frontend_info.name, "STB0899 Multistandard") == 0))
{
- transmissionTypes |= DvbS2;
- }
+ if (!transmissionTypes) {
+ switch (frontend_info.type) {
+ case FE_QAM:
+ transmissionTypes = DvbC;
+ break;
+ case FE_QPSK:
+ transmissionTypes = DvbS;
+
+ if (((frontend_info.caps & FE_CAN_2G_MODULATION) != 0)
||
+ (strcmp(frontend_info.name, "Conexant
CX24116/CX24118") == 0) ||
+ (strcmp(frontend_info.name, "Genpix 8psk-to-USB2
DVB-S") == 0) ||
+ (strcmp(frontend_info.name, "STB0899
Multistandard") == 0)) {
+ transmissionTypes |= DvbS2;
+ }
- break;
- case FE_OFDM:
- transmissionTypes = DvbT;
- break;
- case FE_ATSC:
- transmissionTypes = Atsc;
- break;
- default:
- Log("DvbLinuxDevice::startDevice: unknown type") <<
frontend_info.type <<
- QLatin1String("for frontend") << frontendPath;
- return;
+ break;
+ case FE_OFDM:
+ transmissionTypes = DvbT;
+ break;
+
[PATCH 3/8] cx23885: Add si2165 support for HVR-5500
The same card entry is used for HVR-4400 and HVR-5500.
Only HVR-5500 has been tested.
Signed-off-by: Matthias Schwarzott
---
drivers/media/pci/cx23885/Kconfig | 1 +
drivers/media/pci/cx23885/cx23885-cards.c | 17 +---
drivers/media/pci/cx23885/cx23885-dvb.c | 43 +++
3 files changed, 53 insertions(+), 8 deletions(-)
diff --git a/drivers/media/pci/cx23885/Kconfig
b/drivers/media/pci/cx23885/Kconfig
index d1dcb1d..6cd1db2 100644
--- a/drivers/media/pci/cx23885/Kconfig
+++ b/drivers/media/pci/cx23885/Kconfig
@@ -31,6 +31,7 @@ config VIDEO_CX23885
select DVB_TDA10071 if MEDIA_SUBDRV_AUTOSELECT
select DVB_A8293 if MEDIA_SUBDRV_AUTOSELECT
select DVB_MB86A20S if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_SI2165 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MT2063 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MT2131 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_XC2028 if MEDIA_SUBDRV_AUTOSELECT
diff --git a/drivers/media/pci/cx23885/cx23885-cards.c
b/drivers/media/pci/cx23885/cx23885-cards.c
index 9723067..e63d447 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -619,7 +619,12 @@ struct cx23885_board cx23885_boards[] = {
},
[CX23885_BOARD_HAUPPAUGE_HVR4400] = {
.name = "Hauppauge WinTV-HVR4400",
+ .porta = CX23885_ANALOG_VIDEO,
.portb = CX23885_MPEG_DVB,
+ .portc = CX23885_MPEG_DVB,
+ .tuner_type = TUNER_NXP_TDA18271,
+ .tuner_addr = 0x60, /* 0xc0 >> 1 */
+ .tuner_bus = 1,
},
[CX23885_BOARD_AVERMEDIA_HC81R] = {
.name = "AVerTV Hybrid Express Slim HC81R",
@@ -1475,13 +1480,16 @@ void cx23885_gpio_setup(struct cx23885_dev *dev)
break;
case CX23885_BOARD_HAUPPAUGE_HVR4400:
/* GPIO-8 tda10071 demod reset */
+ /* GPIO-9 si2165 demod reset */
/* Put the parts into reset and back */
- cx23885_gpio_enable(dev, GPIO_8, 1);
- cx23885_gpio_clear(dev, GPIO_8);
+ cx23885_gpio_enable(dev, GPIO_8 | GPIO_9, 1);
+
+ cx23885_gpio_clear(dev, GPIO_8 | GPIO_9);
mdelay(100);
- cx23885_gpio_set(dev, GPIO_8);
+ cx23885_gpio_set(dev, GPIO_8 | GPIO_9);
mdelay(100);
+
break;
case CX23885_BOARD_AVERMEDIA_HC81R:
cx_clear(MC417_CTL, 1);
@@ -1826,6 +1834,9 @@ void cx23885_card_setup(struct cx23885_dev *dev)
ts1->gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
ts1->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
+ ts2->gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
+ ts2->ts_clk_en_val = 0x1; /* Enable TS_CLK */
+ ts2->src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
break;
case CX23885_BOARD_HAUPPAUGE_HVR1250:
case CX23885_BOARD_HAUPPAUGE_HVR1500:
diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
b/drivers/media/pci/cx23885/cx23885-dvb.c
index d037459..4822776 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -71,6 +71,7 @@
#include "tda10071.h"
#include "a8293.h"
#include "mb86a20s.h"
+#include "si2165.h"
static unsigned int debug;
@@ -302,6 +303,11 @@ static struct tda18271_config
hauppauge_hvr1210_tuner_config = {
.output_opt = TDA18271_OUTPUT_LT_OFF,
};
+static struct tda18271_config hauppauge_hvr4400_tuner_config = {
+ .gate= TDA18271_GATE_DIGITAL,
+ .output_opt = TDA18271_OUTPUT_LT_OFF,
+};
+
static struct tda18271_std_map hauppauge_hvr127x_std_map = {
.atsc_6 = { .if_freq = 3250, .agc_mode = 3, .std = 4,
.if_lvl = 1, .rfagc_top = 0x58 },
@@ -702,6 +708,12 @@ static const struct a8293_config hauppauge_a8293_config = {
.i2c_addr = 0x0b,
};
+static const struct si2165_config hauppauge_hvr4400_si2165_config = {
+ .i2c_addr = 0x64,
+ .chip_mode = SI2165_MODE_PLL_XTAL,
+ .ref_freq_Hz= 1600,
+};
+
static int netup_altera_fpga_rw(void *device, int flag, int data, int read)
{
struct cx23885_dev *dev = (struct cx23885_dev *)device;
@@ -1335,13 +1347,34 @@ static int dvb_register(struct cx23885_tsport *port)
break;
case CX23885_BOARD_HAUPPAUGE_HVR4400:
i2c_bus = &dev->i2c_bus[0];
- fe0->dvb.frontend = dvb_attach(tda10071_attach,
+ i2c_bus2 = &dev->i2c_bus[1];
+ switch (port->nr) {
+ /* port b */
+ case 1:
+ fe0->dvb.frontend = dvb_attach(tda10071_attach,
[PATCH 1/8] get_dvb_firmware: Add firmware extractor for si2165
Signed-off-by: Matthias Schwarzott
---
Documentation/dvb/get_dvb_firmware | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dvb_firmware
index d91b8be..26c623d 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -29,7 +29,7 @@ use IO::Handle;
"af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
"lme2510c_s7395_old", "drxk", "drxk_terratec_h5",
"drxk_hauppauge_hvr930c", "tda10071", "it9135", "drxk_pctv",
- "drxk_terratec_htc_stick", "sms1xxx_hcw");
+ "drxk_terratec_htc_stick", "sms1xxx_hcw", "si2165");
# Check args
syntax() if (scalar(@ARGV) != 1);
@@ -783,6 +783,37 @@ sub sms1xxx_hcw {
$allfiles;
}
+sub si2165 {
+my $sourcefile = "model_111xxx_122xxx_driver_6_0_119_31191_WHQL.zip";
+my $url = "http://www.hauppauge.de/files/drivers/";;
+my $hash = "76633e7c76b0edee47c3ba18ded99336";
+my $fwfile = "dvb-demod-si2165.fw";
+my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
+
+checkstandard();
+
+wgetfile($sourcefile, $url . $sourcefile);
+verify($sourcefile, $hash);
+unzip($sourcefile, $tmpdir);
+extract("$tmpdir/Driver10/Hcw10bda.sys", 0x80788, 0x81E08-0x80788,
"$tmpdir/fw1");
+
+delzero("$tmpdir/fw1","$tmpdir/fw1-1");
+#verify("$tmpdir/fw1","5e0909858fdf0b5b09ad48b9fe622e70");
+
+my $CRC="\x0A\xCC";
+my $BLOCKS_MAIN="\x27";
+open FW,">$fwfile";
+print FW "\x01\x00"; # just a version id for the driver itself
+print FW "\x9A"; # fw version
+print FW "\x00"; # padding
+print FW "$BLOCKS_MAIN"; # number of blocks of main part
+print FW "\x00"; # padding
+print FW "$CRC"; # 16bit crc value of main part
+appendfile(FW,"$tmpdir/fw1");
+
+"$fwfile";
+}
+
# ---
# Utilities
--
2.0.0
--
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/8] si2165: Add demod driver for DVB-T only
DVB-T was tested with 8MHz BW channels in germany
This driver is the simplest possible, it uses automatic mode for all
parameters (TPS).
Added spectrum inversion support.
Signed-off-by: Matthias Schwarzott
---
drivers/media/dvb-frontends/Kconfig |9 +
drivers/media/dvb-frontends/Makefile |1 +
drivers/media/dvb-frontends/si2165.c | 1040 +
drivers/media/dvb-frontends/si2165.h | 64 ++
drivers/media/dvb-frontends/si2165_priv.h | 23 +
5 files changed, 1137 insertions(+)
create mode 100644 drivers/media/dvb-frontends/si2165.c
create mode 100644 drivers/media/dvb-frontends/si2165.h
create mode 100644 drivers/media/dvb-frontends/si2165_priv.h
diff --git a/drivers/media/dvb-frontends/Kconfig
b/drivers/media/dvb-frontends/Kconfig
index 78a95a6..b62fcfd 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -63,6 +63,15 @@ config DVB_TDA18271C2DD
Say Y when you want to support this tuner.
+config DVB_SI2165
+ tristate "Silicon Labs si2165 based"
+ depends on DVB_CORE && I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ A DVB-C/T demodulator.
+
+ Say Y when you want to support this frontend.
+
comment "DVB-S (satellite) frontends"
depends on DVB_CORE
diff --git a/drivers/media/dvb-frontends/Makefile
b/drivers/media/dvb-frontends/Makefile
index 655e3c8..edf103d 100644
--- a/drivers/media/dvb-frontends/Makefile
+++ b/drivers/media/dvb-frontends/Makefile
@@ -105,6 +105,7 @@ obj-$(CONFIG_DVB_STV0367) += stv0367.o
obj-$(CONFIG_DVB_CXD2820R) += cxd2820r.o
obj-$(CONFIG_DVB_DRXK) += drxk.o
obj-$(CONFIG_DVB_TDA18271C2DD) += tda18271c2dd.o
+obj-$(CONFIG_DVB_SI2165) += si2165.o
obj-$(CONFIG_DVB_A8293) += a8293.o
obj-$(CONFIG_DVB_TDA10071) += tda10071.o
obj-$(CONFIG_DVB_RTL2830) += rtl2830.o
diff --git a/drivers/media/dvb-frontends/si2165.c
b/drivers/media/dvb-frontends/si2165.c
new file mode 100644
index 000..3a2d6c5
--- /dev/null
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -0,0 +1,1040 @@
+/*
+Driver for Silicon Labs SI2165 DVB-C/-T Demodulator
+
+Copyright (C) 2013-2014 Matthias Schwarzott
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+References:
+http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2165-short.pdf
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dvb_frontend.h"
+#include "dvb_math.h"
+#include "si2165_priv.h"
+#include "si2165.h"
+
+/* Hauppauge WinTV-HVR-930C-HD B130 / PCTV QuatroStick 521e 1113xx
+ * uses 16 MHz xtal */
+
+/* Hauppauge WinTV-HVR-930C-HD B131 / PCTV QuatroStick 522e 1114xx
+ * uses 24 MHz clock provided by tuner */
+
+struct si2165_state {
+ struct i2c_adapter *i2c;
+
+ struct dvb_frontend frontend;
+
+ struct si2165_config config;
+
+ /* chip revision */
+ u8 revcode;
+ /* chip type */
+ u8 chip_type;
+
+ /* calculated by xtal and div settings */
+ u32 fvco_hz;
+ u32 sys_clk;
+ u32 adc_clk;
+
+ bool has_dvbc;
+ bool has_dvbt;
+ bool firmware_loaded;
+};
+
+#define DEBUG_OTHER0x01
+#define DEBUG_I2C_WRITE0x02
+#define DEBUG_I2C_READ 0x04
+#define DEBUG_REG_READ 0x08
+#define DEBUG_REG_WRITE0x10
+#define DEBUG_FW_LOAD 0x20
+
+static int debug = 0x00;
+
+#define dprintk(args...) \
+ do { \
+ if (debug & DEBUG_OTHER) \
+ printk(KERN_DEBUG "si2165: " args); \
+ } while (0)
+
+#define deb_i2c_write(args...) \
+ do { \
+ if (debug & DEBUG_I2C_WRITE) \
+ printk(KERN_DEBUG "si2165: i2c write: " args); \
+ } while (0)
+
+#define deb_i2c_read(args...) \
+ do { \
+ if (debug & DEBUG_I2C_READ) \
+ printk(KERN_DEBUG "si2165: i2c read: " args); \
+ } while (0)
+
+#define deb_readreg(args...) \
+ do { \
+ if (debug & DEBUG_REG_READ) \
+ printk(KERN_DEBUG "si2165: reg read: " args); \
+ } while (0)
+
+#define deb_writereg(args...) \
+ do { \
+ if (debug & DEBUG_REG_WRITE) \
+ printk(KERN_DEBUG "si2165: reg write: " args); \
+ } while (0)
+
+#define deb_fw_load(args...) \
+ do { \
+ if (debug & DEBUG_FW_LOAD) \
+ printk(KERN_DEBUG "si2165: fw load: " args); \
+ } while (0)
+
+static int
[PATCH 0/8] add si2165 demod driver
This series adds support for Si2165 demod. The driver is DVB-T only for now. Then it adds support for these devices: * Hauppauge WinTV 930C-HD model 1113xx * Hauppauge WinTV 930C-HD model 1114xx * Hauppauge HVR-5500 (add DVB-T support) * PCTV QuatroStick 521e * PCTV QuatroStick 522e Regards Matthias -- 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 8/8] cx231xx: Add [2013:025e] PCTV QuatroStick 522e
The hardware is identical to Hauppauge WinTV 930C-HD (model 1114xx)
Signed-off-by: Matthias Schwarzott
---
drivers/media/usb/cx231xx/cx231xx-cards.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index 0085ccd..b2fa05d 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -744,7 +744,7 @@ struct cx231xx_board cx231xx_boards[] = {
} },
},
[CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx] = {
- .name = "Hauppauge WinTV 930C-HD (1114xx)",
+ .name = "Hauppauge WinTV 930C-HD (1114xx) / PCTV QuatroStick
522e",
.tuner_type = TUNER_ABSENT,
.tuner_addr = 0x60,
.tuner_gpio = RDE250_XCV_TUNER,
@@ -822,6 +822,9 @@ struct usb_device_id cx231xx_id_table[] = {
/* PCTV QuatroStick 521e */
{USB_DEVICE(0x2013, 0x0259),
.driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx},
+ /* PCTV QuatroStick 522e */
+ {USB_DEVICE(0x2013, 0x025e),
+.driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx},
{USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x4000,
0x4001),
.driver_info = CX231XX_BOARD_PV_PLAYTV_USB_HYBRID},
{USB_DEVICE(USB_VID_PIXELVIEW, 0x5014),
--
2.0.0
--
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 6/8] cx231xx: Add digital support for [2040:b131] Hauppauge WinTV 930C-HD (model 1114xx)
Signed-off-by: Matthias Schwarzott
---
drivers/media/usb/cx231xx/Kconfig | 1 +
drivers/media/usb/cx231xx/cx231xx-cards.c | 42 +
drivers/media/usb/cx231xx/cx231xx-dvb.c | 63 +++
drivers/media/usb/cx231xx/cx231xx.h | 1 +
4 files changed, 107 insertions(+)
diff --git a/drivers/media/usb/cx231xx/Kconfig
b/drivers/media/usb/cx231xx/Kconfig
index 036454e..569aa29 100644
--- a/drivers/media/usb/cx231xx/Kconfig
+++ b/drivers/media/usb/cx231xx/Kconfig
@@ -48,6 +48,7 @@ config VIDEO_CX231XX_DVB
select DVB_LGDT3305 if MEDIA_SUBDRV_AUTOSELECT
select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
select DVB_SI2165 if MEDIA_SUBDRV_AUTOSELECT
+ select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT
---help---
This adds support for DVB cards based on the
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index 8b80f88..8857fdd 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -743,6 +743,45 @@ struct cx231xx_board cx231xx_boards[] = {
.gpio = NULL,
} },
},
+ [CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx] = {
+ .name = "Hauppauge WinTV 930C-HD (1114xx)",
+ .tuner_type = TUNER_ABSENT,
+ .tuner_addr = 0x60,
+ .tuner_gpio = RDE250_XCV_TUNER,
+ .tuner_sif_gpio = 0x05,
+ .tuner_scl_gpio = 0x1a,
+ .tuner_sda_gpio = 0x1b,
+ .decoder = CX231XX_AVDECODER,
+ .output_mode = OUT_MODE_VIP11,
+ .demod_xfer_mode = 0,
+ .ctl_pin_status_mask = 0xFFC4,
+ .agc_analog_digital_select_gpio = 0x0c,
+ .gpio_pin_status_mask = 0x4001000,
+ .tuner_i2c_master = 1,
+ .demod_i2c_master = 2,
+ .has_dvb = 1,
+ .demod_addr = 0x0e,
+ .norm = V4L2_STD_PAL,
+
+ .input = {{
+ .type = CX231XX_VMUX_TELEVISION,
+ .vmux = CX231XX_VIN_3_1,
+ .amux = CX231XX_AMUX_VIDEO,
+ .gpio = NULL,
+ }, {
+ .type = CX231XX_VMUX_COMPOSITE1,
+ .vmux = CX231XX_VIN_2_1,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ }, {
+ .type = CX231XX_VMUX_SVIDEO,
+ .vmux = CX231XX_VIN_1_1 |
+ (CX231XX_VIN_1_2 << 8) |
+ CX25840_SVIDEO_ON,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ } },
+ },
};
const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
@@ -774,6 +813,8 @@ struct usb_device_id cx231xx_id_table[] = {
.driver_info = CX231XX_BOARD_HAUPPAUGE_EXETER},
{USB_DEVICE(0x2040, 0xb130),
.driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx},
+ {USB_DEVICE(0x2040, 0xb131),
+.driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx},
{USB_DEVICE(0x2040, 0xb140),
.driver_info = CX231XX_BOARD_HAUPPAUGE_EXETER},
{USB_DEVICE(0x2040, 0xc200),
@@ -998,6 +1039,7 @@ void cx231xx_card_setup(struct cx231xx *dev)
switch (dev->model) {
case CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx:
+ case CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx:
{
struct tveeprom tvee;
static u8 eeprom[256];
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 4ff6f7f..1fa7974 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -34,6 +34,7 @@
#include "lgdt3305.h"
#include "si2165.h"
#include "mb86a20s.h"
+#include "si2157.h"
MODULE_DESCRIPTION("driver for cx231xx based DVB cards");
MODULE_AUTHOR("Srinivasa Deevi ");
@@ -159,6 +160,12 @@ static const struct si2165_config
hauppauge_930C_HD_1113xx_si2165_config = {
.ref_freq_Hz= 1600,
};
+static const struct si2165_config pctv_quatro_stick_1114xx_si2165_config = {
+ .i2c_addr = 0x64,
+ .chip_mode = SI2165_MODE_PLL_EXT,
+ .ref_freq_Hz= 2400,
+};
+
static inline void print_err_status(struct cx231xx *dev, int packet, int
status)
{
char *errmsg = "Unknown";
@@ -746,6 +753,62 @@ static int dvb_init(struct cx231xx *dev)
dev->cx231xx_reset_analog_tuner = NULL;
break;
+ case CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx:
+ {
+ struct i2c_client *client;
+ struct i2c_board_info info;
+ struct si2157_config si2157_config;
+
+ memset(&info, 0, sizeof(struct i2c_board_info));
+
+
[PATCH 7/8] cx231xx: Add [2013:0259] PCTV QuatroStick 521e
The hardware is identical to Hauppauge WinTV 930C-HD (model 1113xx)
Signed-off-by: Matthias Schwarzott
---
drivers/media/usb/cx231xx/cx231xx-cards.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index 8857fdd..0085ccd 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -705,7 +705,7 @@ struct cx231xx_board cx231xx_boards[] = {
},
},
[CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx] = {
- .name = "Hauppauge WinTV 930C-HD (1113xx)",
+ .name = "Hauppauge WinTV 930C-HD (1113xx) / PCTV QuatroStick
521e",
.tuner_type = TUNER_NXP_TDA18271,
.tuner_addr = 0x60,
.tuner_gpio = RDE250_XCV_TUNER,
@@ -819,6 +819,9 @@ struct usb_device_id cx231xx_id_table[] = {
.driver_info = CX231XX_BOARD_HAUPPAUGE_EXETER},
{USB_DEVICE(0x2040, 0xc200),
.driver_info = CX231XX_BOARD_HAUPPAUGE_USBLIVE2},
+ /* PCTV QuatroStick 521e */
+ {USB_DEVICE(0x2013, 0x0259),
+.driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx},
{USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x4000,
0x4001),
.driver_info = CX231XX_BOARD_PV_PLAYTV_USB_HYBRID},
{USB_DEVICE(USB_VID_PIXELVIEW, 0x5014),
--
2.0.0
--
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 4/8] cx231xx: prepare for i2c_client attachment
This is needed to support PCTV QuatroStick 522e which uses a si2157.
The si2157 driver is written using i2c_client attachment.
Signed-off-by: Matthias Schwarzott
---
drivers/media/usb/cx231xx/cx231xx-dvb.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 4504bc6..5c69be7 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -67,6 +67,7 @@ struct cx231xx_dvb {
struct dmx_frontend fe_hw;
struct dmx_frontend fe_mem;
struct dvb_net net;
+ struct i2c_client *i2c_client_tuner;
};
static struct s5h1432_config dvico_s5h1432_config = {
@@ -549,11 +550,18 @@ fail_adapter:
static void unregister_dvb(struct cx231xx_dvb *dvb)
{
+ struct i2c_client *client;
dvb_net_release(&dvb->net);
dvb->demux.dmx.remove_frontend(&dvb->demux.dmx, &dvb->fe_mem);
dvb->demux.dmx.remove_frontend(&dvb->demux.dmx, &dvb->fe_hw);
dvb_dmxdev_release(&dvb->dmxdev);
dvb_dmx_release(&dvb->demux);
+ client = dvb->i2c_client_tuner;
+ /* remove I2C tuner */
+ if (client) {
+ module_put(client->dev.driver->owner);
+ i2c_unregister_device(client);
+ }
dvb_unregister_frontend(dvb->frontend);
dvb_frontend_detach(dvb->frontend);
dvb_unregister_adapter(&dvb->adapter);
--
2.0.0
--
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 5/8] cx231xx: Add digital support for [2040:b130] Hauppauge WinTV 930C-HD (model 1113xx)
After loading the driver the first open to dvb device node fails.
Signed-off-by: Matthias Schwarzott
---
drivers/media/usb/cx231xx/Kconfig | 1 +
drivers/media/usb/cx231xx/cx231xx-avcore.c | 1 +
drivers/media/usb/cx231xx/cx231xx-cards.c | 92 ++
drivers/media/usb/cx231xx/cx231xx-core.c | 3 +
drivers/media/usb/cx231xx/cx231xx-dvb.c| 34 +++
drivers/media/usb/cx231xx/cx231xx.h| 1 +
6 files changed, 132 insertions(+)
diff --git a/drivers/media/usb/cx231xx/Kconfig
b/drivers/media/usb/cx231xx/Kconfig
index f14c5e8..036454e 100644
--- a/drivers/media/usb/cx231xx/Kconfig
+++ b/drivers/media/usb/cx231xx/Kconfig
@@ -47,6 +47,7 @@ config VIDEO_CX231XX_DVB
select DVB_MB86A20S if MEDIA_SUBDRV_AUTOSELECT
select DVB_LGDT3305 if MEDIA_SUBDRV_AUTOSELECT
select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_SI2165 if MEDIA_SUBDRV_AUTOSELECT
---help---
This adds support for DVB cards based on the
diff --git a/drivers/media/usb/cx231xx/cx231xx-avcore.c
b/drivers/media/usb/cx231xx/cx231xx-avcore.c
index 89de00b..a428c10 100644
--- a/drivers/media/usb/cx231xx/cx231xx-avcore.c
+++ b/drivers/media/usb/cx231xx/cx231xx-avcore.c
@@ -352,6 +352,7 @@ int cx231xx_afe_update_power_control(struct cx231xx *dev,
case CX231XX_BOARD_CNXT_RDU_253S:
case CX231XX_BOARD_CNXT_VIDEO_GRABBER:
case CX231XX_BOARD_HAUPPAUGE_EXETER:
+ case CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx:
case CX231XX_BOARD_HAUPPAUGE_USBLIVE2:
case CX231XX_BOARD_PV_PLAYTV_USB_HYBRID:
case CX231XX_BOARD_HAUPPAUGE_USB2_FM_PAL:
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index 2ee03e4..8b80f88 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -704,6 +704,45 @@ struct cx231xx_board cx231xx_boards[] = {
}
},
},
+ [CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx] = {
+ .name = "Hauppauge WinTV 930C-HD (1113xx)",
+ .tuner_type = TUNER_NXP_TDA18271,
+ .tuner_addr = 0x60,
+ .tuner_gpio = RDE250_XCV_TUNER,
+ .tuner_sif_gpio = 0x05,
+ .tuner_scl_gpio = 0x1a,
+ .tuner_sda_gpio = 0x1b,
+ .decoder = CX231XX_AVDECODER,
+ .output_mode = OUT_MODE_VIP11,
+ .demod_xfer_mode = 0,
+ .ctl_pin_status_mask = 0xFFC4,
+ .agc_analog_digital_select_gpio = 0x0c,
+ .gpio_pin_status_mask = 0x4001000,
+ .tuner_i2c_master = 1,
+ .demod_i2c_master = 2,
+ .has_dvb = 1,
+ .demod_addr = 0x0e,
+ .norm = V4L2_STD_PAL,
+
+ .input = {{
+ .type = CX231XX_VMUX_TELEVISION,
+ .vmux = CX231XX_VIN_3_1,
+ .amux = CX231XX_AMUX_VIDEO,
+ .gpio = NULL,
+ }, {
+ .type = CX231XX_VMUX_COMPOSITE1,
+ .vmux = CX231XX_VIN_2_1,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ }, {
+ .type = CX231XX_VMUX_SVIDEO,
+ .vmux = CX231XX_VIN_1_1 |
+ (CX231XX_VIN_1_2 << 8) |
+ CX25840_SVIDEO_ON,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ } },
+ },
};
const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
@@ -733,6 +772,8 @@ struct usb_device_id cx231xx_id_table[] = {
.driver_info = CX231XX_BOARD_HAUPPAUGE_USB2_FM_NTSC},
{USB_DEVICE(0x2040, 0xb120),
.driver_info = CX231XX_BOARD_HAUPPAUGE_EXETER},
+ {USB_DEVICE(0x2040, 0xb130),
+.driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx},
{USB_DEVICE(0x2040, 0xb140),
.driver_info = CX231XX_BOARD_HAUPPAUGE_EXETER},
{USB_DEVICE(0x2040, 0xc200),
@@ -886,6 +927,43 @@ static void cx231xx_config_tuner(struct cx231xx *dev)
}
+static int read_eeprom(struct cx231xx *dev, u8 *eedata, int len)
+{
+ int ret = 0;
+ u8 addr = 0xa0 >> 1;
+ u8 start_offset = 0;
+ int len_todo = len;
+ u8 *eedata_cur = eedata;
+ int i;
+ struct i2c_msg msg_write = { .addr = addr, .flags = 0,
+ .buf = &start_offset, .len = 1 };
+ struct i2c_msg msg_read = { .addr = addr, .flags = I2C_M_RD };
+
+ /* mutex_lock(&dev->i2c_lock); */
+ cx231xx_enable_i2c_port_3(dev, false);
+
+ /* start reading at offset 0 */
+ ret = i2c_transfer(&dev->i2c_bus[1].i2c_adap, &msg_write, 1);
+
+ while (len_todo > 0) {
+ msg_read.len = (len_todo > 64) ? 64 : len_todo;
+ msg_read.buf = eeda
Re: [PATCH] si2168: Fix a badly solved merge conflict
Acked-by: Antti Palosaari Reviewed-by: Antti Palosaari Could you merge it directly from patchwork. regards Antti On 07/22/2014 10:25 PM, Mauro Carvalho Chehab wrote: changeset a733291d6934 didn't merge the fixes well. It ended by restoring some bad logic removed there. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/dvb-frontends/si2168.c | 14 -- 1 file changed, 14 deletions(-) diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c index 842c4a555d01..02127613eeff 100644 --- a/drivers/media/dvb-frontends/si2168.c +++ b/drivers/media/dvb-frontends/si2168.c @@ -381,20 +381,6 @@ static int si2168_init(struct dvb_frontend *fe) if (ret) goto err; - cmd.args[0] = 0x05; - cmd.args[1] = 0x00; - cmd.args[2] = 0xaa; - cmd.args[3] = 0x4d; - cmd.args[4] = 0x56; - cmd.args[5] = 0x40; - cmd.args[6] = 0x00; - cmd.args[7] = 0x00; - cmd.wlen = 8; - cmd.rlen = 1; - ret = si2168_cmd_execute(s, &cmd); - if (ret) - goto err; - chip_id = cmd.args[1] << 24 | cmd.args[2] << 16 | cmd.args[3] << 8 | cmd.args[4] << 0; -- http://palosaari.fi/ -- 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] si2168: Fix a badly solved merge conflict
changeset a733291d6934 didn't merge the fixes well. It ended by restoring some bad logic removed there. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/dvb-frontends/si2168.c | 14 -- 1 file changed, 14 deletions(-) diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c index 842c4a555d01..02127613eeff 100644 --- a/drivers/media/dvb-frontends/si2168.c +++ b/drivers/media/dvb-frontends/si2168.c @@ -381,20 +381,6 @@ static int si2168_init(struct dvb_frontend *fe) if (ret) goto err; - cmd.args[0] = 0x05; - cmd.args[1] = 0x00; - cmd.args[2] = 0xaa; - cmd.args[3] = 0x4d; - cmd.args[4] = 0x56; - cmd.args[5] = 0x40; - cmd.args[6] = 0x00; - cmd.args[7] = 0x00; - cmd.wlen = 8; - cmd.rlen = 1; - ret = si2168_cmd_execute(s, &cmd); - if (ret) - goto err; - chip_id = cmd.args[1] << 24 | cmd.args[2] << 16 | cmd.args[3] << 8 | cmd.args[4] << 0; -- 1.9.3 -- 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] si2168: Fix unknown chip version message
At least here with my PCTV 292e, it is printing this error: si2168 10-0064: si2168: unkown chip version Si21170- without a \n at the end. Probably because it is doing something weird or firmware didn't load well. Anyway, better to print it in hex, instead of using %c. While here, fix the typo. Signed-off-by: Mauro Carvalho Chehab --- drivers/media/dvb-frontends/si2168.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c index 41bdbc4d9f6c..842c4a555d01 100644 --- a/drivers/media/dvb-frontends/si2168.c +++ b/drivers/media/dvb-frontends/si2168.c @@ -414,9 +414,8 @@ static int si2168_init(struct dvb_frontend *fe) break; default: dev_err(&s->client->dev, - "%s: unkown chip version Si21%d-%c%c%c\n", - KBUILD_MODNAME, cmd.args[2], cmd.args[1], - cmd.args[3], cmd.args[4]); + "%s: unknown chip version: 0x%04x\n", + KBUILD_MODNAME, chip_id); ret = -EINVAL; goto err; } -- 1.9.3 -- 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] si2157: Fix DVB-C bandwidth.
On 07/22/2014 08:03 PM, Mauro Carvalho Chehab wrote: Em Tue, 22 Jul 2014 17:28:07 +0100 Luis Alves escreveu: That's right, A few days ago I also checked that with Antti. I've also had made some debugging and DVB core is in fact passing the correct bandwidth to the driver. But the true is that it doesn't work... The sample I have is a dvb-c mux using QAM128 @ 6 Mbaud (which results in 7MHz bw) using 7MHz filter value will make the TS stream unwatchable (lots of continuity errors). Can this be a hardware fault? All closed source drivers I've seen are hardcoding this value to 8MHz when working in dvb-c (easily seen on i2c sniffs). Could be. Well, here, the DVB-C channel operators use 6MHz-spaced channels, with symbol rate equal to 5,217 Kbaud. I'll see if I can test it latter this week with a PCTV 292e. I could also test it against modulator. However, that patch seems to be wrong for my eyes too. Generally speaking RF tuner needs to know bandwidth to adjust filters on signal path. For narrow suitable is filter, the better will be signal. If you have 7MHz filter then you definitely want use it in a case your carrier fits that space. Larger filter will work, but CNR is worse. If filter is too narrow and cuts your carrier, you are not able to receive mux or at lest performance drop notably. What is you channel raster? Could you tell center frequencies of all your DVB-C muxes? Could you test with 7MHz bw, but adjust center frequency off from nominal ~0-500kHz to see if it helps. regards Antti -- http://palosaari.fi/ -- 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: Fresco Logic FL2000
as sudo su root@SDR-client:/home/mike# lsusb -v -d 1d5c:2000 Bus 002 Device 003: ID 1d5c:2000 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x1d5c idProduct 0x2000 bcdDevice1.00 iManufacturer 0 iProduct0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 269 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 270mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 3 bFunctionClass 14 Video bFunctionSubClass 1 Video Control bFunctionProtocol 3 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass16 bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass16 bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 04 21 00 01 ** UNRECOGNIZED: 06 25 01 00 00 00 ** UNRECOGNIZED: 06 25 02 00 00 00 ** UNRECOGNIZED: 0a 22 01 00 05 00 02 00 00 00 ** UNRECOGNIZED: 06 25 01 00 00 00 ** UNRECOGNIZED: 0a 22 02 00 10 00 14 00 0d 00 ** UNRECOGNIZED: 0a 23 03 00 0d 00 05 00 00 00 ** UNRECOGNIZED: 06 25 02 00 01 00 ** UNRECOGNIZED: 10 26 01 00 00 00 00 00 64 00 00 00 01 00 00 00 ** UNRECOGNIZED: 0a 24 01 00 14 00 00 00 00 00 ** UNRECOGNIZED: 06 25 03 00 01 00 ** UNRECOGNIZED: 0a 24 02 00 02 00 00 00 00 00 ** UNRECOGNIZED: 06 25 03 00 01 00 ** UNRECOGNIZED: 06 25 0c 00 00 00 ** UNRECOGNIZED: 06 25 09 00 02 00 ** UNRECOGNIZED: 06 25 0b 00 01 00 ** UNRECOGNIZED: 14 27 00 00 01 00 3c 00 01 00 02 00 03 00 00 00 00 00 02 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass16 bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass16 bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None
[linuxtv-media:master 499/499] drivers/media/usb/go7007/go7007-usb.c:699:30: sparse: cast to restricted __le16
tree: git://linuxtv.org/media_tree.git master
head: 7955f03d18d14d18188f94581a4ea336c94b1e2d
commit: 7955f03d18d14d18188f94581a4ea336c94b1e2d [499/499] [media] go7007: move
out of staging into drivers/media/usb.
reproduce: make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/media/usb/go7007/go7007-usb.c:699:30: sparse: cast to restricted
>> __le16
>> drivers/media/usb/go7007/go7007-usb.c:769:38: sparse: cast to restricted
>> __le16
>> drivers/media/usb/go7007/go7007-usb.c:770:39: sparse: cast to restricted
>> __le16
vim +699 drivers/media/usb/go7007/go7007-usb.c
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 693usb_rcvctrlpipe(usb->usbdev, 0),
0x14,
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 694USB_TYPE_VENDOR |
USB_RECIP_DEVICE | USB_DIR_IN,
9b6ebf33 drivers/staging/media/go7007/go7007-usb.c Hans Verkuil
2013-03-09 6950, HPI_STATUS_ADDR, go->usb_buf,
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 696sizeof(status_reg), timeout);
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 697if (r < 0)
9b6ebf33 drivers/staging/media/go7007/go7007-usb.c Hans Verkuil
2013-03-09 698break;
9b6ebf33 drivers/staging/media/go7007/go7007-usb.c Hans Verkuil
2013-03-09 @699status_reg = le16_to_cpu(*((u16 *)go->usb_buf));
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 700if (!(status_reg & 0x0010))
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 701break;
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 702msleep(10);
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 703}
9b6ebf33 drivers/staging/media/go7007/go7007-usb.c Hans Verkuil
2013-03-09 704if (r < 0)
9b6ebf33 drivers/staging/media/go7007/go7007-usb.c Hans Verkuil
2013-03-09 705goto write_int_error;
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 706if (i == 100) {
44ee8e80 drivers/staging/media/go7007/go7007-usb.c Dulshani Gunawardhana
2013-10-20 707dev_err(go->dev, "device is hung, status reg =
0x%04x\n", status_reg);
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 708return -1;
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 709}
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 710r = usb_control_msg(usb->usbdev,
usb_sndctrlpipe(usb->usbdev, 0), 0x12,
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 711USB_TYPE_VENDOR | USB_RECIP_DEVICE, data,
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 712INT_PARAM_ADDR, NULL, 0, timeout);
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 713if (r < 0)
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 714goto write_int_error;
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 715r = usb_control_msg(usb->usbdev,
usb_sndctrlpipe(usb->usbdev, 0),
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 7160x12, USB_TYPE_VENDOR |
USB_RECIP_DEVICE, addr,
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 717INT_INDEX_ADDR, NULL, 0, timeout);
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 718if (r < 0)
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 719goto write_int_error;
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 720return 0;
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 721
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 722 write_int_error:
44ee8e80 drivers/staging/media/go7007/go7007-usb.c Dulshani Gunawardhana
2013-10-20 723dev_err(go->dev, "error in WriteInterrupt: %d\n", r);
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 724return r;
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
2008-02-15 725 }
866b8695 drivers/staging/go7007/go7007-usb.c Greg Kroah-Hartman
[PATCH] [media] tuners/Kconfig: fix build when just DTV or SDR is enabled
As reported by Kbuildtest: warning: (VIDEO_PVRUSB2 && VIDEO_TLG2300 && VIDEO_USBVISION && VIDEO_GO7007 && VIDEO_AU0828_V4L2 && VIDEO_CX231XX && VIDEO_TM6000 && VIDEO_EM28XX && VIDEO_IVTV && VIDEO_MXB && VIDEO_CX18 && VIDEO_CX23885 && VIDEO_CX88 && VIDEO_BT848 && VIDEO_SAA7134 && VIDEO_SAA7164) selects VIDEO_TUNER which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_TUNER) That happens when: # CONFIG_MEDIA_ANALOG_TV_SUPPORT is not set CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y # CONFIG_MEDIA_RADIO_SUPPORT is not set # CONFIG_MEDIA_SDR_SUPPORT is not set CONFIG_VIDEO_AU0828_V4L2=y CONFIG_VIDEO_CX231XX=y CONFIG_VIDEO_TM6000=y CONFIG_VIDEO_EM28XX=y CONFIG_VIDEO_TUNER=y CONFIG_MEDIA_SUPPORT=y With means that we need to enable MEDIA_TUNER also when DTV is enabled. While the above config doesn't cover, if we enable SDR, the same error can also happen. Reported-by: kbuild test robot Signed-off-by: Mauro Carvalho Chehab --- drivers/media/tuners/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig index 906461da1310..51edd101f250 100644 --- a/drivers/media/tuners/Kconfig +++ b/drivers/media/tuners/Kconfig @@ -1,7 +1,7 @@ # Analog TV tuners, auto-loaded via tuner.ko config MEDIA_TUNER tristate - depends on (MEDIA_ANALOG_TV_SUPPORT || MEDIA_RADIO_SUPPORT) && I2C + depends on (MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT || MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT) && I2C default y select MEDIA_TUNER_XC2028 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_XC5000 if MEDIA_SUBDRV_AUTOSELECT -- 1.9.3 -- 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
[linuxtv-media:master 498/499] drivers/media/pci/solo6x10/solo6x10-core.c:209:48: sparse: incorrect type in argument 3 (different base types)
tree: git://linuxtv.org/media_tree.git master
head: 7955f03d18d14d18188f94581a4ea336c94b1e2d
commit: 28cae868cd245b6bb2f27bce807e9d78afcf8ea2 [498/499] [media] solo6x10:
move out of staging into drivers/media/pci.
reproduce: make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
>> drivers/media/pci/solo6x10/solo6x10-core.c:209:48: sparse: incorrect type in
>> argument 3 (different base types)
drivers/media/pci/solo6x10/solo6x10-core.c:209:48:expected unsigned
short [unsigned] data
drivers/media/pci/solo6x10/solo6x10-core.c:209:48:got restricted __be16
[usertype]
>> drivers/media/pci/solo6x10/solo6x10-core.c:226:24: sparse: cast to
>> restricted __be16
>> drivers/media/pci/solo6x10/solo6x10-core.c:226:24: sparse: cast to
>> restricted __be16
>> drivers/media/pci/solo6x10/solo6x10-core.c:226:24: sparse: cast to
>> restricted __be16
>> drivers/media/pci/solo6x10/solo6x10-core.c:226:24: sparse: cast to
>> restricted __be16
--
>> drivers/media/pci/solo6x10/solo6x10-disp.c:184:24: sparse: incorrect type in
>> assignment (different base types)
drivers/media/pci/solo6x10/solo6x10-disp.c:184:24:expected unsigned
short [unsigned] [short] [usertype]
drivers/media/pci/solo6x10/solo6x10-disp.c:184:24:got restricted __le16
[usertype]
>> drivers/media/pci/solo6x10/solo6x10-disp.c:221:32: sparse: incorrect type in
>> assignment (different base types)
drivers/media/pci/solo6x10/solo6x10-disp.c:221:32:expected unsigned
short [unsigned] [short] [usertype]
drivers/media/pci/solo6x10/solo6x10-disp.c:221:32:got restricted __le16
[usertype]
vim +209 drivers/media/pci/solo6x10/solo6x10-core.c
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 203
}
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 204
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 205
solo_eeprom_ewen(solo_dev, 1);
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 206
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 207
for (i = full_eeprom ? 0 : 32; i < min((int)(full_eeprom ? 64 : 32),
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 208
(int)(count / 2)); i++)
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 @209
solo_eeprom_write(solo_dev, i, cpu_to_be16(p[i]));
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 210
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 211
solo_eeprom_ewen(solo_dev, 0);
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 212
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 213
return count;
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 214 }
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 215
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 216
static ssize_t eeprom_show(struct device *dev, struct device_attribute *attr,
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 217
char *buf)
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 218 {
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 219
struct solo_dev *solo_dev =
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 220
container_of(dev, struct solo_dev, dev);
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 221
unsigned short *p = (unsigned short *)buf;
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 222
int count = (full_eeprom ? 128 : 64);
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 223
int i;
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 224
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 225
for (i = (full_eeprom ? 0 : 32); i < (count / 2); i++)
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 @226
p[i] = be16_to_cpu(solo_eeprom_read(solo_dev, i));
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 227
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 228
return count;
dcae5dac drivers/staging/media/solo6x10/core.c Hans Verkuil 2013-03-25 229 }
:: The code at line 209 was first introduced by commit
:: dcae5dacbce518513abf7776cb450b7bd95d722b [media] solo6x10: sync to
latest code from Bluecherry's git repo
:: TO: Hans Verkuil
:: CC: Mauro Carvalho Chehab
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a
Re: [PATCH] si2157: Fix DVB-C bandwidth.
Em Tue, 22 Jul 2014 17:28:07 +0100 Luis Alves escreveu: > That's right, > A few days ago I also checked that with Antti. I've also had made some > debugging and DVB core is in fact passing the correct bandwidth to the > driver. > > But the true is that it doesn't work... > The sample I have is a dvb-c mux using QAM128 @ 6 Mbaud (which results > in 7MHz bw) using 7MHz filter value will make the TS stream > unwatchable (lots of continuity errors). > > Can this be a hardware fault? > All closed source drivers I've seen are hardcoding this value to 8MHz > when working in dvb-c (easily seen on i2c sniffs). Could be. Well, here, the DVB-C channel operators use 6MHz-spaced channels, with symbol rate equal to 5,217 Kbaud. I'll see if I can test it latter this week with a PCTV 292e. Regards, Mauro > > > On Tue, Jul 22, 2014 at 5:10 PM, Mauro Carvalho Chehab > wrote: > > Em Tue, 22 Jul 2014 12:09:48 +0100 > > Luis Alves escreveu: > > > >> This patch fixes DVB-C reception. > >> Without setting the bandwidth to 8MHz the received stream gets corrupted. > >> > >> Regards, > >> Luis > >> > >> Signed-off-by: Luis Alves > >> --- > >> drivers/media/tuners/si2157.c | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c > >> index 6c53edb..e2de428 100644 > >> --- a/drivers/media/tuners/si2157.c > >> +++ b/drivers/media/tuners/si2157.c > >> @@ -245,6 +245,7 @@ static int si2157_set_params(struct dvb_frontend *fe) > >> break; > >> case SYS_DVBC_ANNEX_A: > >> delivery_system = 0x30; > >> + bandwidth = 0x08; > > > > Hmm... this patch looks wrong, as it will break DVB-C support where > > the bandwidth is lower than 6MHz. > > > > The DVB core sets c->bandwidth_hz for DVB-C based on the rolloff and > > the symbol rate. If this is not working for you, then something else > > is likely wrong. > > > > I suggest you to add a printk() there to show what's the value set > > at c->bandwidth_hz and what's the symbol rate that you're using. > > > > On DVB-C, the rolloff is fixed (1.15 for annex A and 1.13 for Annex C). > > Not sure if DVB-C2 allows selecting a different rolloff factor, nor > > if si2157 works with DVB-C2. > > > >> break; > >> default: > >> ret = -EINVAL; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] OMAP3 ISP BT.656 support
On Tue, Jul 22, 2014 at 6:04 PM, Laurent Pinchart wrote: > Hi Enrico, > > You will need to upgrade media-ctl and yavta to versions that support > interlaced formats. media-ctl has been moved to v4l-utils > (http://git.linuxtv.org/cgit.cgi/v4l-utils.git/) and yavta is hosted at > git://git.ideasonboard.org/yavta.git. You want to use the master branch for > both trees. It seems that in v4l-utils there is no field support in media-ctl, am i wrong? I forgot to add that i'm using yavta master and media-ctl "field" branch (from ideasonboard). Enrico -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] OMAP3 ISP BT.656 support
Hi Enrico, On Tuesday 22 July 2014 18:26:52 Enrico wrote: > On Tue, Jul 22, 2014 at 6:04 PM, Laurent Pinchart wrote: > > Hi Enrico, > > > > You will need to upgrade media-ctl and yavta to versions that support > > interlaced formats. media-ctl has been moved to v4l-utils > > (http://git.linuxtv.org/cgit.cgi/v4l-utils.git/) and yavta is hosted at > > git://git.ideasonboard.org/yavta.git. You want to use the master branch > > for both trees. > > It seems that in v4l-utils there is no field support in media-ctl, am i > wrong? Oops, my bad, you're absolutely right. > I forgot to add that i'm using yavta master and media-ctl "field" > branch (from ideasonboard). Could you please try media-ctl from git://linuxtv.org/pinchartl/v4l-utils.git field The IOB repository is deprecated, although the version of media-ctl present there might work, I'd like to rule out that issue. The media-ctl output you've posted doesn't show field information, so you're probably running either the wrong media-ctl version or the wrong kernel version. -- Regards, Laurent Pinchart -- 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] si2157: Fix DVB-C bandwidth.
That's right, A few days ago I also checked that with Antti. I've also had made some debugging and DVB core is in fact passing the correct bandwidth to the driver. But the true is that it doesn't work... The sample I have is a dvb-c mux using QAM128 @ 6 Mbaud (which results in 7MHz bw) using 7MHz filter value will make the TS stream unwatchable (lots of continuity errors). Can this be a hardware fault? All closed source drivers I've seen are hardcoding this value to 8MHz when working in dvb-c (easily seen on i2c sniffs). On Tue, Jul 22, 2014 at 5:10 PM, Mauro Carvalho Chehab wrote: > Em Tue, 22 Jul 2014 12:09:48 +0100 > Luis Alves escreveu: > >> This patch fixes DVB-C reception. >> Without setting the bandwidth to 8MHz the received stream gets corrupted. >> >> Regards, >> Luis >> >> Signed-off-by: Luis Alves >> --- >> drivers/media/tuners/si2157.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c >> index 6c53edb..e2de428 100644 >> --- a/drivers/media/tuners/si2157.c >> +++ b/drivers/media/tuners/si2157.c >> @@ -245,6 +245,7 @@ static int si2157_set_params(struct dvb_frontend *fe) >> break; >> case SYS_DVBC_ANNEX_A: >> delivery_system = 0x30; >> + bandwidth = 0x08; > > Hmm... this patch looks wrong, as it will break DVB-C support where > the bandwidth is lower than 6MHz. > > The DVB core sets c->bandwidth_hz for DVB-C based on the rolloff and > the symbol rate. If this is not working for you, then something else > is likely wrong. > > I suggest you to add a printk() there to show what's the value set > at c->bandwidth_hz and what's the symbol rate that you're using. > > On DVB-C, the rolloff is fixed (1.15 for annex A and 1.13 for Annex C). > Not sure if DVB-C2 allows selecting a different rolloff factor, nor > if si2157 works with DVB-C2. > >> break; >> default: >> ret = -EINVAL; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] OMAP3 ISP BT.656 support
Hi Raymond, On Tuesday 22 July 2014 09:20:34 Raymond Jender wrote: > Please remove me from this mailing list. It does not provide me with what I > thought it would. We can't do that, but you can easily perform the operation yourself. Look at the bottom of any e-mail you receive from the list (but not the e-mails that are explicitly sent to you, like this one, as they don't go through the mailing list manager) for instructions. -- Regards, Laurent Pinchart -- 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] si2157: Fix DVB-C bandwidth.
Em Tue, 22 Jul 2014 12:09:48 +0100 Luis Alves escreveu: > This patch fixes DVB-C reception. > Without setting the bandwidth to 8MHz the received stream gets corrupted. > > Regards, > Luis > > Signed-off-by: Luis Alves > --- > drivers/media/tuners/si2157.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c > index 6c53edb..e2de428 100644 > --- a/drivers/media/tuners/si2157.c > +++ b/drivers/media/tuners/si2157.c > @@ -245,6 +245,7 @@ static int si2157_set_params(struct dvb_frontend *fe) > break; > case SYS_DVBC_ANNEX_A: > delivery_system = 0x30; > + bandwidth = 0x08; Hmm... this patch looks wrong, as it will break DVB-C support where the bandwidth is lower than 6MHz. The DVB core sets c->bandwidth_hz for DVB-C based on the rolloff and the symbol rate. If this is not working for you, then something else is likely wrong. I suggest you to add a printk() there to show what's the value set at c->bandwidth_hz and what's the symbol rate that you're using. On DVB-C, the rolloff is fixed (1.15 for annex A and 1.13 for Annex C). Not sure if DVB-C2 allows selecting a different rolloff factor, nor if si2157 works with DVB-C2. > break; > default: > ret = -EINVAL; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] OMAP3 ISP BT.656 support
Hi Enrico, On Tuesday 22 July 2014 17:52:27 Enrico wrote: > On Tue, Jun 24, 2014 at 5:19 PM, Enrico wrote: > > On Tue, May 27, 2014 at 10:38 AM, Enrico wrote: > >> On Mon, May 26, 2014 at 9:50 PM, Laurent Pinchart wrote: > >>> Hello, > >>> > >>> This patch sets implements support for BT.656 and interlaced formats in > >>> the OMAP3 ISP driver. Better late than never I suppose, although given > >>> how long this has been on my to-do list there's probably no valid > >>> excuse. > >> > >> Thanks Laurent! > >> > >> I hope to have time soon to test it :) > > > > Hi Laurent, > > > > i wanted to try your patches but i'm having a problem (probably not > > caused by your patches). > > > > I merged media_tree master and omap3isp branches, applied your patches > > and added camera platform data in pdata-quirks, but when loading the > > omap3-isp driver i have: > > > > omap3isp: clk_set_rate for cam_mclk failed > > > > The returned value from clk_set_rate is -22 (EINVAL), but i can't see > > any other debug message to track it down. Any ides? > > I'm testing it on an igep proton (omap3530 version). > > I found out that my previous email was not working anymore, so i > didn't read about Stefan patch (ti,set-rate-parent). > > With that patch i can setup my pipeline (attached), but i can't make > yavta capture: > > root@igep00x0:~/field# ./yavta -f UYVY -n4 -s 720x624 -c100 /dev/video2 > Device /dev/video2 opened. > Device `OMAP3 ISP CCDC output' on `media' is a video output (without > mplanes) device. > Video format set: UYVY (59565955) 720x624 (stride 1440) field none > buffer size 898560 > Video format: UYVY (59565955) 720x624 (stride 1440) field none buffer > size 898560 > 4 buffers requested. > length: 898560 offset: 0 timestamp type/source: mono/EoF > Buffer 0/0 mapped at address 0xb6ce4000. > length: 898560 offset: 901120 timestamp type/source: mono/EoF > Buffer 1/0 mapped at address 0xb6c08000. > length: 898560 offset: 1802240 timestamp type/source: mono/EoF > Buffer 2/0 mapped at address 0xb6b2c000. > length: 898560 offset: 2703360 timestamp type/source: mono/EoF > Buffer 3/0 mapped at address 0xb6a5. > Unable to start streaming: Invalid argument (22). > 4 buffers released. > > strace: > > ioctl(3, VIDIOC_STREAMON, 0xbef9c75c) = -1 EINVAL (Invalid argument) > > any ideas? You will need to upgrade media-ctl and yavta to versions that support interlaced formats. media-ctl has been moved to v4l-utils (http://git.linuxtv.org/cgit.cgi/v4l-utils.git/) and yavta is hosted at git://git.ideasonboard.org/yavta.git. You want to use the master branch for both trees. -- Regards, Laurent Pinchart -- 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] si2157: Fix DVB-C bandwidth.
On 22.07.2014 13:09, Luis Alves wrote: > This patch fixes DVB-C reception. > Without setting the bandwidth to 8MHz the received stream gets corrupted. Hi Luis, I also wonder if some code should default to bandwidth of 8MHz if none is set. But then I grepped for it and found code in drivers/media/dvb-core/dvb_frontend.c to calculate the bandwidth depending on delivery system and symbol rate. So if this works, the bandwidth should already be correct. Regards Matthias -- 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] si2168: Add ts_mode config.
This patch adds the TS mode as a config option:
- ts_mode added to config struct.
- Possible (interesting) values are
* Parallel mode = 0x06
* Serial mode = 0x03
Currently the modules using this demod only use parallel mode.
Regards,
Luis
Signed-off-by: Luis Alves
---
drivers/media/dvb-frontends/si2168.c | 17 ++---
drivers/media/dvb-frontends/si2168.h | 6 ++
drivers/media/usb/dvb-usb/cxusb.c | 1 +
drivers/media/usb/em28xx/em28xx-dvb.c | 1 +
4 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 41bdbc4..d45a1c6 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -297,13 +297,6 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
if (ret)
goto err;
- memcpy(cmd.args, "\x14\x00\x01\x10\x16\x00", 6);
- cmd.wlen = 6;
- cmd.rlen = 4;
- ret = si2168_cmd_execute(s, &cmd);
- if (ret)
- goto err;
-
memcpy(cmd.args, "\x14\x00\x09\x10\xe3\x18", 6);
cmd.wlen = 6;
cmd.rlen = 4;
@@ -350,6 +343,7 @@ err:
static int si2168_init(struct dvb_frontend *fe)
{
struct si2168 *s = fe->demodulator_priv;
+ struct si2168_config *config = s->client->dev.platform_data;
int ret, len, remaining;
const struct firmware *fw = NULL;
u8 *fw_file;
@@ -479,6 +473,15 @@ static int si2168_init(struct dvb_frontend *fe)
dev_info(&s->client->dev, "%s: found a '%s' in warm state\n",
KBUILD_MODNAME, si2168_ops.info.name);
+ /* Set TSMODE */
+ memcpy(cmd.args, "\x14\x00\x01\x10\x10\x00", 6);
+ cmd.args[4] |= config->ts_mode;
+ cmd.wlen = 6;
+ cmd.rlen = 4;
+ ret = si2168_cmd_execute(s, &cmd);
+ if (ret)
+ goto err;
+
s->active = true;
return 0;
diff --git a/drivers/media/dvb-frontends/si2168.h
b/drivers/media/dvb-frontends/si2168.h
index 3c5b5ab..ebbf309 100644
--- a/drivers/media/dvb-frontends/si2168.h
+++ b/drivers/media/dvb-frontends/si2168.h
@@ -34,6 +34,12 @@ struct si2168_config {
* returned by driver
*/
struct i2c_adapter **i2c_adapter;
+
+ /* TS mode */
+ u8 ts_mode;
};
+#define SI2168_TSMODE_PARALLEL 0x06
+#define SI2168_TSMODE_SERIAL 0x03
+
#endif
diff --git a/drivers/media/usb/dvb-usb/cxusb.c
b/drivers/media/usb/dvb-usb/cxusb.c
index b7461ac..18a2720 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -1369,6 +1369,7 @@ static int cxusb_tt_ct2_4400_attach(struct
dvb_usb_adapter *adap)
/* attach frontend */
si2168_config.i2c_adapter = &adapter;
si2168_config.fe = &adap->fe_adap[0].fe;
+ si2168_config.ts_mode = SI2168_TSMODE_PARALLEL;
memset(&info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, "si2168", I2C_NAME_SIZE);
info.addr = 0x64;
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 96a0bdb..27d5d84 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1525,6 +1525,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
/* attach demod */
si2168_config.i2c_adapter = &adapter;
si2168_config.fe = &dvb->fe[0];
+ si2168_config.ts_mode = SI2168_TSMODE_PARALLEL;
memset(&info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, "si2168", I2C_NAME_SIZE);
info.addr = 0x64;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] OMAP3 ISP BT.656 support
On Tue, Jun 24, 2014 at 5:19 PM, Enrico wrote: > On Tue, May 27, 2014 at 10:38 AM, Enrico wrote: >> On Mon, May 26, 2014 at 9:50 PM, Laurent Pinchart >> wrote: >>> Hello, >>> >>> This patch sets implements support for BT.656 and interlaced formats in the >>> OMAP3 ISP driver. Better late than never I suppose, although given how long >>> this has been on my to-do list there's probably no valid excuse. >> >> Thanks Laurent! >> >> I hope to have time soon to test it :) > > Hi Laurent, > > i wanted to try your patches but i'm having a problem (probably not > caused by your patches). > > I merged media_tree master and omap3isp branches, applied your patches > and added camera platform data in pdata-quirks, but when loading the > omap3-isp driver i have: > > omap3isp: clk_set_rate for cam_mclk failed > > The returned value from clk_set_rate is -22 (EINVAL), but i can't see > any other debug message to track it down. Any ides? > I'm testing it on an igep proton (omap3530 version). I found out that my previous email was not working anymore, so i didn't read about Stefan patch (ti,set-rate-parent). With that patch i can setup my pipeline (attached), but i can't make yavta capture: root@igep00x0:~/field# ./yavta -f UYVY -n4 -s 720x624 -c100 /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video output (without mplanes) device. Video format set: UYVY (59565955) 720x624 (stride 1440) field none buffer size 898560 Video format: UYVY (59565955) 720x624 (stride 1440) field none buffer size 898560 4 buffers requested. length: 898560 offset: 0 timestamp type/source: mono/EoF Buffer 0/0 mapped at address 0xb6ce4000. length: 898560 offset: 901120 timestamp type/source: mono/EoF Buffer 1/0 mapped at address 0xb6c08000. length: 898560 offset: 1802240 timestamp type/source: mono/EoF Buffer 2/0 mapped at address 0xb6b2c000. length: 898560 offset: 2703360 timestamp type/source: mono/EoF Buffer 3/0 mapped at address 0xb6a5. Unable to start streaming: Invalid argument (22). 4 buffers released. strace: ioctl(3, VIDIOC_STREAMON, 0xbef9c75c) = -1 EINVAL (Invalid argument) any ideas? Thanks, Enrico Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Media controller API version 0.0.0 Media device information driver omap3isp model TI OMAP3 ISP serial bus info hw revision 0x20 driver version 0.0.0 Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Sink [SGRBG10 4096x4096] <- "OMAP3 ISP CCP2 input":0 [] pad1: Source [SGRBG10 4096x4096] -> "OMAP3 ISP CCDC":0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Source -> "OMAP3 ISP CCP2":0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Sink [SGRBG10 4096x4096] pad1: Source [SGRBG10 4096x4096] -> "OMAP3 ISP CSI2a output":0 [] -> "OMAP3 ISP CCDC":0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Sink <- "OMAP3 ISP CSI2a":1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Sink [UYVY2X8 720x625] <- "OMAP3 ISP CCP2":1 [] <- "OMAP3 ISP CSI2a":1 [] <- "tvp5150 1-005c":0 [ENABLED] pad1: Source [UYVY 720x624 (0,0)/720x624] -> "OMAP3 ISP CCDC output":0 [ENABLED] -> "OMAP3 ISP resizer":0 [] pad2: Source [unknown 720x624] -> "OMAP3 ISP preview":0 [] -> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE] -> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE] -> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Sink <- "OMAP3 ISP CCDC":1 [ENABLED] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Sink [SGRBG10 4096x4096 (8,4)/4082x4088] <- "OMAP3 ISP CCDC":2 [] <- "OMAP3 ISP preview input":0 [] pad1: Source [YUYV 4082x4088] -> "OMAP3 ISP preview output":0 [] -> "OMAP3 ISP resizer":0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Source -> "OMAP3 ISP preview":0
Re: [PATCH 3/3] driver:gpio remove all usage of gpio_remove retval in driver
On Sat, Jul 12, 2014 at 10:30 PM, abdoulaye berthe wrote: Heads up. Requesting ACKs for this patch or I'm atleast warning that it will be applied. We're getting rid of the return value from gpiochip_remove(). > this remove all reference to gpio_remove retval in all driver > except pinctrl and gpio. the same thing is done for gpio and > pinctrl in two different patches. > > Signed-off-by: abdoulaye berthe (...) I think this patch probably needs to be broken down per-subsystem as it hits all over the map. But let's start requesting ACKs for the individual pieces. Actually I think it will be OK to merge because there is likely not much churn around these code sites. I'm a bit torn between just wanting a big patch for this hitting drivers/gpio and smaller patches hitting one subsystem at a time. We should be able to hammer this in one switch strike. > arch/arm/common/scoop.c| 10 ++ ARM SoC folks, can you ACK this? > arch/mips/txx9/generic/setup.c | 4 ++-- Ralf can you ACK this? > arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c | 3 ++- Benji, can you ACK this? > arch/sh/boards/mach-x3proto/gpio.c | 6 ++ Aha noone can ACK this, whatever... > drivers/bcma/driver_gpio.c | 3 ++- Rafał can you ACK this? > drivers/hid/hid-cp2112.c | 6 ++ Jiri can you ACK this? > drivers/input/keyboard/adp5588-keys.c | 4 +--- > drivers/input/keyboard/adp5589-keys.c | 4 +--- > drivers/input/touchscreen/ad7879.c | 10 +++--- Dmitry can you ACK this? > drivers/leds/leds-pca9532.c| 10 ++ > drivers/leds/leds-tca6507.c| 7 ++- Bryan can you ACK this? > drivers/media/dvb-frontends/cxd2820r_core.c| 10 +++--- Mauro can you ACK this? (Hm that looks weird. Mental note to look closer at this.) > drivers/mfd/asic3.c| 3 ++- > drivers/mfd/htc-i2cpld.c | 8 +--- > drivers/mfd/sm501.c| 17 +++-- > drivers/mfd/tc6393xb.c | 13 - > drivers/mfd/ucb1x00-core.c | 8 ++-- Lee/Sam can either of you ACK this? > drivers/pinctrl/pinctrl-abx500.c | 15 +++ > drivers/pinctrl/pinctrl-exynos5440.c | 6 +- > drivers/pinctrl/pinctrl-msm.c | 10 +++--- > drivers/pinctrl/pinctrl-nomadik.c | 2 +- > drivers/pinctrl/pinctrl-samsung.c | 14 -- Abdoulaye: these should be in the other patch for pinctrl. > drivers/platform/x86/intel_pmic_gpio.c | 3 +-- Matthew can you ACK this? > drivers/ssb/driver_gpio.c | 3 ++- Michael can you (A) ACK this and (B) think of moving this driver to drivers/gpio... Patches welcome. > drivers/staging/vme/devices/vme_pio2_gpio.c| 4 +--- > drivers/tty/serial/max310x.c | 10 -- Greg can you ACK this? > drivers/video/fbdev/via/via-gpio.c | 10 +++--- Tomi can you ACK this? > sound/soc/codecs/wm5100.c | 5 + > sound/soc/codecs/wm8903.c | 6 +- > sound/soc/codecs/wm8962.c | 5 + > sound/soc/codecs/wm8996.c | 6 +- Liam || Mark can you ACK this? Yours, Linus Walleij -- 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 v2 8/9] Documentation: devicetree: Document sclk-jpeg clock for exynos3250 SoC
On 22/07/14 16:44, Arnd Bergmann wrote: > I'd vote for listing it as an optional clock independent of the compatible > string and changing the driver to just use it when it's provided. That sounds good to me, thanks for the suggestion. -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 8/9] Documentation: devicetree: Document sclk-jpeg clock for exynos3250 SoC
On Tuesday 22 July 2014 16:18:25 Sylwester Nawrocki wrote:
>
> All right, then I would rephrase it to:
>
> - clock-names : should contain:
>- "jpeg" for the common gate clock,
>- "sclk" for the special clock (only for Exynos3250).
> - clocks: should contain the clock specifier and clock ID list
> matching entries in the clock-names property, according
> to the common clock bindings.
>
> I went through documentation of these clocks in various SoCs' datasheets:
> exynos4210, exynos4212/4412, exynos3250, exynos5250 and I think for all
> SoCs the "jpeg" clock can be referred as "gating all clocks for the IP".
> That means there is a single bit in a CMU register masking all the clocks
> for the IP, I suppose this includes the control bus (APB) clock and the
> IP functional ("special") clock.
>
> It looks like e.g. exynos4412 also has the SCLK clock, after muxes and
> a divider, so rate can be configured for this clock. However there is
> no separate gate for SCLK as in case of exynos3250. Thus there is no
> need to to enable/disable the second clock on anything except exynos3250
> currently.
>
> I think ideally sclk should also be defined for SoCs like exynos4x12,
> exynos5250, even if now drivers are not touching sclk. All in all the
> IP functional clock frequency should be normally set to some known value,
> now we rely on the default divider value which results in divider
> ratio = 1.
> It would break backward compatibility though if we now made sclk
> mandatory. I'm inclined to also specify sclk for exynos4x12, just
> not sure if it should be optional or mandatory.
I'd vote for listing it as an optional clock independent of the compatible
string and changing the driver to just use it when it's provided.
Arnd
--
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 v2 8/9] Documentation: devicetree: Document sclk-jpeg clock for exynos3250 SoC
On 22/07/14 13:48, Arnd Bergmann wrote:
> -- clocks : should contain the JPEG codec IP gate clock specifier, from
> the
> > >> > +- clocks : should contain the JPEG codec IP gate clock specifier
> > >> > and
> > >> > +for the Exynos3250 SoC additionally the SCLK_JPEG
> > >> > entry; from the
> > >> > common clock bindings;
> > >> > -- clock-names : should contain "jpeg" entry.
> > >> > +- clock-names : should contain "jpeg" entry and additionally
> > >> > "sclk-jpeg" entry
> > >> > +for Exynos3250 SoC
>>> > >
>>> > > Please turn this into a list for easier reading, e.g.
>>> > >
>>> > > - clock-names: should contain:
>>> > > * "jpeg" for the gate clock.
>>> > > * "sclk-jpeg" for the SCLK_JPEG clock (only for Exynos3250).
>>> > >
>>> > > You could also define clocks in terms of clock-names to avoid
>>> > > redundancy.
>>> > >
>>> > > The SCLK_JPEG name sounds like a global name for the clock. Is there a
>>> > > name for the input line on the JPEG block this is plugged into?
>> >
>> > There is unfortunately no such name for SCLK_JPEG clock in the IP's block
>> > documentation. For most of the multimedia IPs clocks are documented
>> > only in the clock controller chapter, hence the names may appear global.
>> > Probably "gate", "sclk" would be good names, rather than "",
>> > "-sclk". But people kept using the latter convention and now
>> > it's spread all over and it's hard to change it.
>> > Since now we can't rename "jpeg" and other IPs I'd assume it's best
>> > to stay with "jpeg", "sclk-jpeg".
>
> We just had the exact same discussion about the addition of the sclk for
> the adc in exynos3250 and ended up calling it just "sclk" instead of
> "sclk-adc"
> there. I think it would be best to do the same here and use "sclk" instead
> of "sclk-jpeg".
All right, then I would rephrase it to:
- clock-names : should contain:
- "jpeg" for the common gate clock,
- "sclk" for the special clock (only for Exynos3250).
- clocks: should contain the clock specifier and clock ID list
matching entries in the clock-names property, according
to the common clock bindings.
I went through documentation of these clocks in various SoCs' datasheets:
exynos4210, exynos4212/4412, exynos3250, exynos5250 and I think for all
SoCs the "jpeg" clock can be referred as "gating all clocks for the IP".
That means there is a single bit in a CMU register masking all the clocks
for the IP, I suppose this includes the control bus (APB) clock and the
IP functional ("special") clock.
It looks like e.g. exynos4412 also has the SCLK clock, after muxes and
a divider, so rate can be configured for this clock. However there is
no separate gate for SCLK as in case of exynos3250. Thus there is no
need to to enable/disable the second clock on anything except exynos3250
currently.
I think ideally sclk should also be defined for SoCs like exynos4x12,
exynos5250, even if now drivers are not touching sclk. All in all the
IP functional clock frequency should be normally set to some known value,
now we rely on the default divider value which results in divider
ratio = 1.
It would break backward compatibility though if we now made sclk
mandatory. I'm inclined to also specify sclk for exynos4x12, just
not sure if it should be optional or mandatory.
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Good Day
I have a business proposal I would like to share with you, on your response I will email you with more details. I await your quick response. Kind regards Richard Wong -- 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 v3 06/32] [media] coda: Add encoder/decoder support for CODA960
Am Montag, den 21.07.2014, 21:19 +0200 schrieb Robert Schwebel:
> Hi Mauro,
>
> On Mon, Jul 21, 2014 at 04:01:28PM -0300, Mauro Carvalho Chehab wrote:
> > > This patch adds support for the CODA960 VPU in Freescale i.MX6 SoCs.
> > >
> > > It enables h.264 and MPEG4 encoding and decoding support. Besides the
> > > usual
> > > register shifting, the CODA960 gains frame memory control and GDI
> > > registers
> > > that are set up for linear mapping right now, needs ENC_PIC_SRC_INDEX to
> > > be
> > > set beyond the number of internal buffers for some reason, and has
> > > subsampling
> > > buffers that need to be set up. Also, the work buffer size is increased to
> > > 80 KiB.
> > >
> > > The CODA960 firmware spins if there is not enough input data in the
> > > bitstream
> > > buffer. To make it continue, buffers need to be copied into the bitstream
> > > as
> > > soon as they are queued. As the bitstream fifo is written into from two
> > > places,
> > > it must be protected with a mutex. For that, using a threaded interrupt
> > > handler
> > > is necessary.
> > >
> > > Signed-off-by: Philipp Zabel
> > > ---
> >
> > ...
> >
> > > + [CODA_IMX6Q] = {
> > > + .firmware = "v4l-coda960-imx6q.bin",
> > > + .product= CODA_960,
> > > + .codecs = coda9_codecs,
> > > + .num_codecs = ARRAY_SIZE(coda9_codecs),
> > > + },
> > > + [CODA_IMX6DL] = {
> > > + .firmware = "v4l-coda960-imx6dl.bin",
> > > + .product= CODA_960,
> > > + .codecs = coda9_codecs,
> > > + .num_codecs = ARRAY_SIZE(coda9_codecs),
> > > + },
> >
> > Where are those firmware files available?
>
> Freescale currently distributes the firmware with their multimedia
> packages, but in header hex array form; we are trying to find a proper
> solution (hopefully by using the linux firmware repository) for
> mainline.
The firmware-imx packages referenced in the Freescale meta-fsl-arm
repository on github.com contain VPU firmware files. Their use is
restricted by an EULA. For example:
http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-3.0.35-4.0.0.bin
This contains the files vpu_fw_imx6q.bin and vpu_fw_imx6d.bin, which can
be converted into v4l-coda960-imx6q.bin and v4l-coda960-imx6dl.bin,
respectively, by dropping the headers and reordering the rest.
I described this for i.MX53 earlier here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/181101.html
> The Freescale kernel people are currently discussing this internally
> with their legal folks, see this discussion:
>
> http://www.spinics.net/lists/linux-media/msg78273.html
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] [media] v4l2-mem2mem: export v4l2_m2m_try_schedule
From: Michael Olbrich
Some drivers might allow to decode remaining frames from an internal ringbuffer
after a decoder stop command. Allow those to call v4l2_m2m_try_schedule
directly.
Signed-off-by: Michael Olbrich
Signed-off-by: Philipp Zabel
---
Changes since v3:
- Export v4l2_m2m_try_schedule using EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 3 ++-
include/media/v4l2-mem2mem.h | 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 178ce96..5f5c175 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -208,7 +208,7 @@ static void v4l2_m2m_try_run(struct v4l2_m2m_dev *m2m_dev)
* An example of the above could be an instance that requires more than one
* src/dst buffer per transaction.
*/
-static void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
+void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
{
struct v4l2_m2m_dev *m2m_dev;
unsigned long flags_job, flags_out, flags_cap;
@@ -274,6 +274,7 @@ static void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx
*m2m_ctx)
v4l2_m2m_try_run(m2m_dev);
}
+EXPORT_SYMBOL_GPL(v4l2_m2m_try_schedule);
/**
* v4l2_m2m_cancel_job() - cancel pending jobs for the context
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
index 12ea5a6..c5f3914 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -95,6 +95,8 @@ void *v4l2_m2m_get_curr_priv(struct v4l2_m2m_dev *m2m_dev);
struct vb2_queue *v4l2_m2m_get_vq(struct v4l2_m2m_ctx *m2m_ctx,
enum v4l2_buf_type type);
+void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx);
+
void v4l2_m2m_job_finish(struct v4l2_m2m_dev *m2m_dev,
struct v4l2_m2m_ctx *m2m_ctx);
--
2.0.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] drm: panel: simple-panel: add support for bus_format retrieval
Provide a way to specify panel requirement in terms of supported media bus
format (particularly useful for panels connected to an RGB or LVDS bus).
Signed-off-by: Boris BREZILLON
---
drivers/gpu/drm/panel/panel-simple.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 3f76944..42fd6d1 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -41,6 +41,8 @@ struct panel_desc {
unsigned int width;
unsigned int height;
} size;
+
+ enum video_bus_format bus_format;
};
struct panel_simple {
@@ -89,6 +91,9 @@ static int panel_simple_get_fixed_modes(struct panel_simple
*panel)
connector->display_info.width_mm = panel->desc->size.width;
connector->display_info.height_mm = panel->desc->size.height;
+ if (panel->desc->bus_format)
+ drm_display_info_set_bus_formats(&connector->display_info,
+&panel->desc->bus_format, 1);
return num;
}
--
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
[PATCH 2/5] video: add RGB444_1X12 and RGB565_1X16 bus formats
Add RGB444 format using a 12 bits bus and RGB565 using a 16 bits bus.
These formats will later be used by atmel-hlcdc driver.
Signed-off-by: Boris BREZILLON
---
include/uapi/linux/v4l2-mediabus.h| 2 ++
include/uapi/linux/video-bus-format.h | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/v4l2-mediabus.h
b/include/uapi/linux/v4l2-mediabus.h
index 8c31f11..319f860 100644
--- a/include/uapi/linux/v4l2-mediabus.h
+++ b/include/uapi/linux/v4l2-mediabus.h
@@ -30,6 +30,8 @@
#define V4L2_MBUS_FMT_RGB888_2X12_BE VIDEO_BUS_FMT_RGB888_2X12_BE
#define V4L2_MBUS_FMT_RGB888_2X12_LE VIDEO_BUS_FMT_RGB888_2X12_LE
#define V4L2_MBUS_FMT_ARGB_1X32VIDEO_BUS_FMT_ARGB_1X32
+#define V4L2_BUS_FMT_RGB444_1X12 VIDEO_BUS_FMT_RGB444_1X12
+#define V4L2_BUS_FMT_RGB565_1X16 VIDEO_BUS_FMT_RGB565_1X16
#define V4L2_MBUS_FMT_Y8_1X8 VIDEO_BUS_FMT_Y8_1X8
#define V4L2_MBUS_FMT_UV8_1X8 VIDEO_BUS_FMT_UV8_1X8
diff --git a/include/uapi/linux/video-bus-format.h
b/include/uapi/linux/video-bus-format.h
index 4abbd5d..f85f7ee 100644
--- a/include/uapi/linux/video-bus-format.h
+++ b/include/uapi/linux/video-bus-format.h
@@ -34,7 +34,7 @@
enum video_bus_format {
VIDEO_BUS_FMT_FIXED = 0x0001,
- /* RGB - next is 0x100e */
+ /* RGB - next is 0x1010 */
VIDEO_BUS_FMT_RGB444_2X8_PADHI_BE = 0x1001,
VIDEO_BUS_FMT_RGB444_2X8_PADHI_LE = 0x1002,
VIDEO_BUS_FMT_RGB555_2X8_PADHI_BE = 0x1003,
@@ -48,6 +48,8 @@ enum video_bus_format {
VIDEO_BUS_FMT_RGB888_2X12_BE = 0x100b,
VIDEO_BUS_FMT_RGB888_2X12_LE = 0x100c,
VIDEO_BUS_FMT_ARGB_1X32 = 0x100d,
+ VIDEO_BUS_FMT_RGB444_1X12 = 0x100e,
+ VIDEO_BUS_FMT_RGB565_1X16 = 0x100f,
/* YUV (including grey) - next is 0x2024 */
VIDEO_BUS_FMT_Y8_1X8 = 0x2001,
--
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
[PATCH 1/5] video: move mediabus format definition to a more standard place
Rename mediabus formats and move the enum into a separate header file so
that it can be used by DRM/KMS subsystem without any reference to the V4L2
subsystem.
Old V4L2_MBUS_FMT_ definitions are now macros that points to VIDEO_BUS_FMT_
definitions.
Signed-off-by: Boris BREZILLON
---
include/uapi/linux/Kbuild | 1 +
include/uapi/linux/v4l2-mediabus.h| 183 ++
include/uapi/linux/video-bus-format.h | 127 +++
3 files changed, 205 insertions(+), 106 deletions(-)
create mode 100644 include/uapi/linux/video-bus-format.h
diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index 24e9033..371874b 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -408,6 +408,7 @@ header-y += veth.h
header-y += vfio.h
header-y += vhost.h
header-y += videodev2.h
+header-y += video-bus-format.h
header-y += virtio_9p.h
header-y += virtio_balloon.h
header-y += virtio_blk.h
diff --git a/include/uapi/linux/v4l2-mediabus.h
b/include/uapi/linux/v4l2-mediabus.h
index 1445e85..8c31f11 100644
--- a/include/uapi/linux/v4l2-mediabus.h
+++ b/include/uapi/linux/v4l2-mediabus.h
@@ -13,119 +13,90 @@
#include
#include
+#include
-/*
- * These pixel codes uniquely identify data formats on the media bus. Mostly
- * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0 is
- * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs, where the
- * data format is fixed. Additionally, "2X8" means that one pixel is
transferred
- * in two 8-bit samples, "BE" or "LE" specify in which order those samples are
- * transferred over the bus: "LE" means that the least significant bits are
- * transferred first, "BE" means that the most significant bits are transferred
- * first, and "PADHI" and "PADLO" define which bits - low or high, in the
- * incomplete high byte, are filled with padding bits.
- *
- * The pixel codes are grouped by type, bus_width, bits per component, samples
- * per pixel and order of subsamples. Numerical values are sorted using generic
- * numerical sort order (8 thus comes before 10).
- *
- * As their value can't change when a new pixel code is inserted in the
- * enumeration, the pixel codes are explicitly given a numerical value. The
next
- * free values for each category are listed below, update them when inserting
- * new pixel codes.
- */
-enum v4l2_mbus_pixelcode {
- V4L2_MBUS_FMT_FIXED = 0x0001,
-
- /* RGB - next is 0x100e */
- V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE = 0x1001,
- V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE = 0x1002,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 0x1003,
- V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 0x1004,
- V4L2_MBUS_FMT_BGR565_2X8_BE = 0x1005,
- V4L2_MBUS_FMT_BGR565_2X8_LE = 0x1006,
- V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
- V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
- V4L2_MBUS_FMT_RGB666_1X18 = 0x1009,
- V4L2_MBUS_FMT_RGB888_1X24 = 0x100a,
- V4L2_MBUS_FMT_RGB888_2X12_BE = 0x100b,
- V4L2_MBUS_FMT_RGB888_2X12_LE = 0x100c,
- V4L2_MBUS_FMT_ARGB_1X32 = 0x100d,
+#define V4L2_MBUS_FMT_FIXEDVIDEO_BUS_FMT_FIXED
- /* YUV (including grey) - next is 0x2024 */
- V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
- V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
- V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
- V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
- V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004,
- V4L2_MBUS_FMT_YVYU8_1_5X8 = 0x2005,
- V4L2_MBUS_FMT_UYVY8_2X8 = 0x2006,
- V4L2_MBUS_FMT_VYUY8_2X8 = 0x2007,
- V4L2_MBUS_FMT_YUYV8_2X8 = 0x2008,
- V4L2_MBUS_FMT_YVYU8_2X8 = 0x2009,
- V4L2_MBUS_FMT_Y10_1X10 = 0x200a,
- V4L2_MBUS_FMT_UYVY10_2X10 = 0x2018,
- V4L2_MBUS_FMT_VYUY10_2X10 = 0x2019,
- V4L2_MBUS_FMT_YUYV10_2X10 = 0x200b,
- V4L2_MBUS_FMT_YVYU10_2X10 = 0x200c,
- V4L2_MBUS_FMT_Y12_1X12 = 0x2013,
- V4L2_MBUS_FMT_UYVY8_1X16 = 0x200f,
- V4L2_MBUS_FMT_VYUY8_1X16 = 0x2010,
- V4L2_MBUS_FMT_YUYV8_1X16 = 0x2011,
- V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
- V4L2_MBUS_FMT_YDYUYDYV8_1X16 = 0x2014,
- V4L2_MBUS_FMT_UYVY10_1X20 = 0x201a,
- V4L2_MBUS_FMT_VYUY10_1X20 = 0x201b,
- V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
- V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
- V4L2_MBUS_FMT_YUV10_1X30 = 0x2016,
- V4L2_MBUS_FMT_AYUV8_1X32 = 0x2017,
- V4L2_MBUS_FMT_UYVY12_2X12 = 0x201c,
- V4L2_MBUS_FMT_VYUY12_2X12 = 0x201d,
- V4L2_MBUS_FMT_YUYV12_2X12 = 0x201e,
- V4L2_MBUS_FMT_YVYU12_2X12 = 0x201f,
- V4L2_MBUS_FMT_UYVY12_1X24 = 0x2020,
- V4L2_MBUS_FMT_VYUY12_1X24 = 0x2021,
- V4L2_MBUS_FMT_YUYV12_1X24 = 0x2022,
- V4L2_MBUS_FMT_YVYU12_1X24 = 0x2023,
+#define V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE
VIDEO_BUS_FMT_RGB444_2X8_PADHI_BE
+#define V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE
VIDEO_BUS_FMT_RGB444_2X8_PADHI_LE
+#define V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE
VIDEO_BUS_FMT_RGB555_2X8_
[PATCH 0/5] video: describe data bus formats
Hello, This patch series is a proposal to describe the different data formats used by HW components to connect with each other. This is just a copy of the existing V4L2_MBUS_FMT defintions with a neutral name so that it can be used by V4L2 and DRM/KMS subsystem. This series also makes use of this video_bus_format enum in the DRM/KMS subsystem to define the data fomats supported on the connector <-> device link. The video bus formats are not documented yet (and I don't know where this doc should be stored), but I'm pretty sure this version won't be the last one ;-). Best Regards, Boris Boris BREZILLON (5): video: move mediabus format definition to a more standard place video: add RGB444_1X12 and RGB565_1X16 bus formats drm: add bus_formats and nbus_formats fields to drm_display_info drm: panel: simple-panel: add support for bus_format retrieval drm: panel: simple-panel: add bus format information for foxlink panel drivers/gpu/drm/drm_crtc.c| 28 + drivers/gpu/drm/panel/panel-simple.c | 6 ++ include/drm/drm_crtc.h| 8 ++ include/uapi/linux/Kbuild | 1 + include/uapi/linux/v4l2-mediabus.h| 185 +++--- include/uapi/linux/video-bus-format.h | 129 6 files changed, 251 insertions(+), 106 deletions(-) create mode 100644 include/uapi/linux/video-bus-format.h -- 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
[PATCH 5/5] drm: panel: simple-panel: add bus format information for foxlink panel
Foxlink's fl500wvr00-a0t supports RGB888 format.
Signed-off-by: Boris BREZILLON
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 42fd6d1..f1e49fd 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -428,6 +428,7 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
.width = 108,
.height = 65,
},
+ .bus_format = VIDEO_BUS_FMT_RGB888_1X24,
};
static const struct drm_display_mode lg_lp129qe_mode = {
--
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
[PATCH 3/5] drm: add bus_formats and nbus_formats fields to drm_display_info
Add bus_formats and nbus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.
This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).
Signed-off-by: Boris BREZILLON
---
drivers/gpu/drm/drm_crtc.c | 28
include/drm/drm_crtc.h | 8
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c808a09..50c8395 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -825,6 +825,34 @@ static void drm_mode_remove(struct drm_connector
*connector,
drm_mode_destroy(connector->dev, mode);
}
+/*
+ * drm_display_info_set_bus_formats - set the supported bus formats
+ * @info: display info to store bus formats in
+ * @fmts: array containing the supported bus formats
+ * @nfmts: the number of entries in the fmts array
+ *
+ * Store the suppported bus formats in display info structure.
+ */
+int drm_display_info_set_bus_formats(struct drm_display_info *info,
+const enum video_bus_format *fmts,
+int nfmts)
+{
+ enum video_bus_format *formats = NULL;
+
+ if (fmts && nfmts) {
+ formats = kmemdup(fmts, sizeof(*fmts) * nfmts, GFP_KERNEL);
+ if (!formats)
+ return -ENOMEM;
+ }
+
+ kfree(info->bus_formats);
+ info->bus_formats = formats;
+ info->nbus_formats = formats ? nfmts : 0;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_display_info_set_bus_formats);
+
/**
* drm_connector_init - Init a preallocated connector
* @dev: DRM device
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e529b68..957729b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -121,6 +122,9 @@ struct drm_display_info {
enum subpixel_order subpixel_order;
u32 color_formats;
+ const enum video_bus_format *bus_formats;
+ int nbus_formats;
+
/* Mask of supported hdmi deep color modes */
u8 edid_hdmi_dc_modes;
@@ -964,6 +968,10 @@ extern int drm_mode_connector_set_path_property(struct
drm_connector *connector,
extern int drm_mode_connector_update_edid_property(struct drm_connector
*connector,
struct edid *edid);
+extern int drm_display_info_set_bus_formats(struct drm_display_info *info,
+ const enum video_bus_format *fmts,
+ int nfmts);
+
static inline bool drm_property_type_is(struct drm_property *property,
uint32_t type)
{
--
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: [PATCH v2 8/9] Documentation: devicetree: Document sclk-jpeg clock for exynos3250 SoC
On Tuesday 22 July 2014 13:42:00 Sylwester Nawrocki wrote: > On 14/07/14 11:56, Mark Rutland wrote: > >> diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt > >> b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt > >> > index 937b755..3142745 100644 > >> > --- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt > >> > +++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt > >> > @@ -3,9 +3,12 @@ Samsung S5P/EXYNOS SoC series JPEG codec > >> > Required properties: > >> > > >> > - compatible : should be one of: > >> > -"samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg"; > >> > +"samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg", > >> > +"samsung,exynos3250-jpeg"; > >> > - reg : address and length of the JPEG codec IP register > >> > set; > >> > - interrupts : specifies the JPEG codec IP interrupt; > >> > -- clocks : should contain the JPEG codec IP gate clock specifier, from > >> > the > >> > +- clocks : should contain the JPEG codec IP gate clock specifier and > >> > +for the Exynos3250 SoC additionally the SCLK_JPEG entry; > >> > from the > >> > common clock bindings; > >> > -- clock-names : should contain "jpeg" entry. > >> > +- clock-names : should contain "jpeg" entry and additionally > >> > "sclk-jpeg" entry > >> > +for Exynos3250 SoC > > > > Please turn this into a list for easier reading, e.g. > > > > - clock-names: should contain: > > * "jpeg" for the gate clock. > > * "sclk-jpeg" for the SCLK_JPEG clock (only for Exynos3250). > > > > You could also define clocks in terms of clock-names to avoid > > redundancy. > > > > The SCLK_JPEG name sounds like a global name for the clock. Is there a > > name for the input line on the JPEG block this is plugged into? > > There is unfortunately no such name for SCLK_JPEG clock in the IP's block > documentation. For most of the multimedia IPs clocks are documented > only in the clock controller chapter, hence the names may appear global. > Probably "gate", "sclk" would be good names, rather than "", > "-sclk". But people kept using the latter convention and now > it's spread all over and it's hard to change it. > Since now we can't rename "jpeg" and other IPs I'd assume it's best > to stay with "jpeg", "sclk-jpeg". We just had the exact same discussion about the addition of the sclk for the adc in exynos3250 and ended up calling it just "sclk" instead of "sclk-adc" there. I think it would be best to do the same here and use "sclk" instead of "sclk-jpeg". Arnd -- 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 v2 8/9] Documentation: devicetree: Document sclk-jpeg clock for exynos3250 SoC
On 14/07/14 11:56, Mark Rutland wrote: >> diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt >> b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt >> > index 937b755..3142745 100644 >> > --- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt >> > +++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt >> > @@ -3,9 +3,12 @@ Samsung S5P/EXYNOS SoC series JPEG codec >> > Required properties: >> > >> > - compatible : should be one of: >> > -"samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg"; >> > +"samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg", >> > +"samsung,exynos3250-jpeg"; >> > - reg : address and length of the JPEG codec IP register set; >> > - interrupts : specifies the JPEG codec IP interrupt; >> > -- clocks : should contain the JPEG codec IP gate clock specifier, from >> > the >> > +- clocks : should contain the JPEG codec IP gate clock specifier and >> > +for the Exynos3250 SoC additionally the SCLK_JPEG entry; from >> > the >> > common clock bindings; >> > -- clock-names : should contain "jpeg" entry. >> > +- clock-names : should contain "jpeg" entry and additionally >> > "sclk-jpeg" entry >> > +for Exynos3250 SoC > > Please turn this into a list for easier reading, e.g. > > - clock-names: should contain: > * "jpeg" for the gate clock. > * "sclk-jpeg" for the SCLK_JPEG clock (only for Exynos3250). > > You could also define clocks in terms of clock-names to avoid > redundancy. > > The SCLK_JPEG name sounds like a global name for the clock. Is there a > name for the input line on the JPEG block this is plugged into? There is unfortunately no such name for SCLK_JPEG clock in the IP's block documentation. For most of the multimedia IPs clocks are documented only in the clock controller chapter, hence the names may appear global. Probably "gate", "sclk" would be good names, rather than "", "-sclk". But people kept using the latter convention and now it's spread all over and it's hard to change it. Since now we can't rename "jpeg" and other IPs I'd assume it's best to stay with "jpeg", "sclk-jpeg". -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] si2157: Fix DVB-C bandwidth.
This patch fixes DVB-C reception. Without setting the bandwidth to 8MHz the received stream gets corrupted. Regards, Luis Signed-off-by: Luis Alves --- drivers/media/tuners/si2157.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c index 6c53edb..e2de428 100644 --- a/drivers/media/tuners/si2157.c +++ b/drivers/media/tuners/si2157.c @@ -245,6 +245,7 @@ static int si2157_set_params(struct dvb_frontend *fe) break; case SYS_DVBC_ANNEX_A: delivery_system = 0x30; + bandwidth = 0x08; break; default: ret = -EINVAL; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 18/32] [media] v4l2-mem2mem: export v4l2_m2m_try_schedule
Am Montag, den 21.07.2014, 16:04 -0300 schrieb Mauro Carvalho Chehab:
> Em Fri, 11 Jul 2014 11:36:29 +0200
> Philipp Zabel escreveu:
>
> > From: Michael Olbrich
> >
> > Some drivers might allow to decode remaining frames from an internal
> > ringbuffer
> > after a decoder stop command. Allow those to call v4l2_m2m_try_schedule
> > directly.
> >
> > Signed-off-by: Michael Olbrich
> > Signed-off-by: Philipp Zabel
> > ---
> > drivers/media/v4l2-core/v4l2-mem2mem.c | 3 ++-
> > include/media/v4l2-mem2mem.h | 2 ++
> > 2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
> > b/drivers/media/v4l2-core/v4l2-mem2mem.c
> > index 178ce96..5f5c175 100644
> > --- a/drivers/media/v4l2-core/v4l2-mem2mem.c
> > +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
> > @@ -208,7 +208,7 @@ static void v4l2_m2m_try_run(struct v4l2_m2m_dev
> > *m2m_dev)
> > * An example of the above could be an instance that requires more than one
> > * src/dst buffer per transaction.
> > */
> > -static void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
> > +void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
> > {
> > struct v4l2_m2m_dev *m2m_dev;
> > unsigned long flags_job, flags_out, flags_cap;
> > @@ -274,6 +274,7 @@ static void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx
> > *m2m_ctx)
> >
> > v4l2_m2m_try_run(m2m_dev);
> > }
> > +EXPORT_SYMBOL(v4l2_m2m_try_schedule);
>
> Please use EXPORT_SYMBOL_GPL() instead.
Are you sure about this? I see that Pawel (added to Cc:) exported
v4l2_m2m_get_vq, v4l2_m2m_get_curr_priv, v4l2_m2m_mmap, and
v4l2_m2m_job_finish (which calls v4l2_m2m_try_schedule) also using
EXPORT_SYMBOL() while all other functions are EXPORT_SYMBOL_GPL()
Is there some reasoning behind this, or is it accidental?
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] Mirics MSi3101/MSi2500 driver changes
The following changes since commit a733291d6934d0663af9e7d9f2266ab87a2946cd: Merge commit '67dd8f35c2d8ed80f26c9654b474cffc11c6674d' into patchwork (2014-07-22 02:03:59 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git sdr_pull for you to fetch changes up to 7b845e2cd9081683743f3f3688456ea3b09c8ad8: msi2500: rename namespace msi3101 => msi2500 (2014-07-22 11:47:29 +0300) Antti Palosaari (3): msi2500: correct style issues msi2500: refactor USB stream copying msi2500: rename namespace msi3101 => msi2500 drivers/media/usb/msi2500/msi2500.c | 745 - 1 file changed, 273 insertions(+), 472 deletions(-) -- http://palosaari.fi/ -- 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] msi2500: rename namespace msi3101 => msi2500
Rename driver namespace according to current driver name. Old
msi3101 was name of reference design, msi2500 is name of chip
itself.
Signed-off-by: Antti Palosaari
---
drivers/media/usb/msi2500/msi2500.c | 256 ++--
1 file changed, 128 insertions(+), 128 deletions(-)
diff --git a/drivers/media/usb/msi2500/msi2500.c
b/drivers/media/usb/msi2500/msi2500.c
index 5bce38e..26b1334 100644
--- a/drivers/media/usb/msi2500/msi2500.c
+++ b/drivers/media/usb/msi2500/msi2500.c
@@ -34,8 +34,8 @@
#include
#include
-static bool msi3101_emulated_fmt;
-module_param_named(emulated_formats, msi3101_emulated_fmt, bool, 0644);
+static bool msi2500_emulated_fmt;
+module_param_named(emulated_formats, msi2500_emulated_fmt, bool, 0644);
MODULE_PARM_DESC(emulated_formats, "enable emulated formats (disappears in
future)");
/*
@@ -76,14 +76,14 @@ static const struct v4l2_frequency_band bands[] = {
};
/* stream formats */
-struct msi3101_format {
+struct msi2500_format {
char*name;
u32 pixelformat;
u32 buffersize;
};
/* format descriptions for capture and preview */
-static struct msi3101_format formats[] = {
+static struct msi2500_format formats[] = {
{
.name = "Complex S8",
.pixelformat= V4L2_SDR_FMT_CS8,
@@ -114,12 +114,12 @@ static struct msi3101_format formats[] = {
static const unsigned int NUM_FORMATS = ARRAY_SIZE(formats);
/* intermediate buffers with raw data from the USB device */
-struct msi3101_frame_buf {
+struct msi2500_frame_buf {
struct vb2_buffer vb; /* common v4l buffer stuff -- must be first */
struct list_head list;
};
-struct msi3101_state {
+struct msi2500_state {
struct video_device vdev;
struct v4l2_device v4l2_dev;
struct v4l2_subdev *v4l2_subdev;
@@ -157,17 +157,17 @@ struct msi3101_state {
};
/* Private functions */
-static struct msi3101_frame_buf *msi3101_get_next_fill_buf(
- struct msi3101_state *s)
+static struct msi2500_frame_buf *msi2500_get_next_fill_buf(
+ struct msi2500_state *s)
{
unsigned long flags = 0;
- struct msi3101_frame_buf *buf = NULL;
+ struct msi2500_frame_buf *buf = NULL;
spin_lock_irqsave(&s->queued_bufs_lock, flags);
if (list_empty(&s->queued_bufs))
goto leave;
- buf = list_entry(s->queued_bufs.next, struct msi3101_frame_buf, list);
+ buf = list_entry(s->queued_bufs.next, struct msi2500_frame_buf, list);
list_del(&buf->list);
leave:
spin_unlock_irqrestore(&s->queued_bufs_lock, flags);
@@ -256,7 +256,7 @@ leave:
* signed 14-bit sample
*/
-static int msi3101_convert_stream(struct msi3101_state *s, u8 *dst, u8 *src,
+static int msi2500_convert_stream(struct msi2500_state *s, u8 *dst, u8 *src,
unsigned int src_len)
{
unsigned int i, j, transactions, dst_len = 0;
@@ -378,12 +378,12 @@ static int msi3101_convert_stream(struct msi3101_state
*s, u8 *dst, u8 *src,
* This gets called for the Isochronous pipe (stream). This is done in
interrupt
* time, so it has to be fast, not crash, and not stall. Neat.
*/
-static void msi3101_isoc_handler(struct urb *urb)
+static void msi2500_isoc_handler(struct urb *urb)
{
- struct msi3101_state *s = (struct msi3101_state *)urb->context;
+ struct msi2500_state *s = (struct msi2500_state *)urb->context;
int i, flen, fstatus;
unsigned char *iso_buf = NULL;
- struct msi3101_frame_buf *fbuf;
+ struct msi2500_frame_buf *fbuf;
if (unlikely(urb->status == -ENOENT || urb->status == -ECONNRESET ||
urb->status == -ESHUTDOWN)) {
@@ -394,7 +394,7 @@ static void msi3101_isoc_handler(struct urb *urb)
if (unlikely(urb->status != 0)) {
dev_dbg(&s->udev->dev,
- "msi3101_isoc_handler() called with status
%d\n",
+ "msi2500_isoc_handler() called with status
%d\n",
urb->status);
/* Give up after a number of contiguous errors */
if (++s->isoc_errors > MAX_ISOC_ERRORS)
@@ -427,7 +427,7 @@ static void msi3101_isoc_handler(struct urb *urb)
iso_buf = urb->transfer_buffer + urb->iso_frame_desc[i].offset;
/* Get free framebuffer */
- fbuf = msi3101_get_next_fill_buf(s);
+ fbuf = msi2500_get_next_fill_buf(s);
if (unlikely(fbuf == NULL)) {
s->vb_full++;
dev_dbg_ratelimited(&s->udev->dev,
@@ -438,7 +438,7 @@ static void msi3101_isoc_handler(struct urb *urb)
/* fill framebuffer */
ptr = vb2_plane_vaddr(&fbuf->vb, 0);
- flen = msi3101_convert_stream(s, ptr, iso_buf, flen);
+ flen = msi2500_convert_stream(s, ptr, iso_buf, flen);
[PATCH] msi2500: refactor USB stream copying
There was a lot of duplicated functionality between different
stream format handling. Refactor functionality in order to get
rid of duplicated code.
Signed-off-by: Antti Palosaari
---
drivers/media/usb/msi2500/msi2500.c | 437 +---
1 file changed, 103 insertions(+), 334 deletions(-)
diff --git a/drivers/media/usb/msi2500/msi2500.c
b/drivers/media/usb/msi2500/msi2500.c
index 755f959..5bce38e 100644
--- a/drivers/media/usb/msi2500/msi2500.c
+++ b/drivers/media/usb/msi2500/msi2500.c
@@ -146,8 +146,6 @@ struct msi3101_state {
unsigned int vb_full; /* vb is full and packets dropped */
struct urb *urbs[MAX_ISO_BUFS];
- int (*convert_stream)(struct msi3101_state *s, u8 *dst, u8 *src,
- unsigned int src_len);
/* Controls */
struct v4l2_ctrl_handler hdl;
@@ -188,118 +186,8 @@ leave:
* +---
* signed 8-bit sample
* 504 * 2 = 1008 samples
- */
-static int msi3101_convert_stream_504(struct msi3101_state *s, u8 *dst,
- u8 *src, unsigned int src_len)
-{
- int i, i_max, dst_len = 0;
- u32 sample_num[3];
-
- /* There could be 1-3 1024 bytes URB frames */
- i_max = src_len / 1024;
-
- for (i = 0; i < i_max; i++) {
- sample_num[i] = src[3] << 24 | src[2] << 16 | src[1] << 8 |
src[0] << 0;
- if (i == 0 && s->next_sample != sample_num[0]) {
- dev_dbg_ratelimited(&s->udev->dev,
- "%d samples lost, %d %08x:%08x\n",
- sample_num[0] - s->next_sample,
- src_len, s->next_sample, sample_num[0]);
- }
-
- /*
-* Dump all unknown 'garbage' data - maybe we will discover
-* someday if there is something rational...
-*/
- dev_dbg_ratelimited(&s->udev->dev, "%*ph\n", 12, &src[4]);
-
- /* 504 x I+Q samples */
- src += 16;
- memcpy(dst, src, 1008);
- src += 1008;
- dst += 1008;
- dst_len += 1008;
- }
-
- /* calculate samping rate and output it in 10 seconds intervals */
- if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
- unsigned long jiffies_now = jiffies;
- unsigned long msecs = jiffies_to_msecs(jiffies_now) -
jiffies_to_msecs(s->jiffies_next);
- unsigned int samples = sample_num[i_max - 1] - s->sample;
-
- s->jiffies_next = jiffies_now;
- s->sample = sample_num[i_max - 1];
- dev_dbg(&s->udev->dev,
- "slen=%d samples=%u msecs=%lu sampling
rate=%lu\n",
- src_len, samples, msecs,
- samples * 1000UL / msecs);
- }
-
- /* next sample (sample = sample + i * 504) */
- s->next_sample = sample_num[i_max - 1] + 504;
-
- return dst_len;
-}
-
-static int msi3101_convert_stream_504_u8(struct msi3101_state *s, u8 *dst,
- u8 *src, unsigned int src_len)
-{
- int i, j, i_max, dst_len = 0;
- u32 sample_num[3];
- s8 *s8src;
- u8 *u8dst;
-
- /* There could be 1-3 1024 bytes URB frames */
- i_max = src_len / 1024;
- u8dst = (u8 *) dst;
-
- for (i = 0; i < i_max; i++) {
- sample_num[i] = src[3] << 24 | src[2] << 16 | src[1] << 8 |
src[0] << 0;
- if (i == 0 && s->next_sample != sample_num[0]) {
- dev_dbg_ratelimited(&s->udev->dev,
- "%d samples lost, %d %08x:%08x\n",
- sample_num[0] - s->next_sample,
- src_len, s->next_sample, sample_num[0]);
- }
-
- /*
-* Dump all unknown 'garbage' data - maybe we will discover
-* someday if there is something rational...
-*/
- dev_dbg_ratelimited(&s->udev->dev, "%*ph\n", 12, &src[4]);
-
- /* 504 x I+Q samples */
- src += 16;
-
- s8src = (s8 *) src;
- for (j = 0; j < 1008; j++)
- *u8dst++ = *s8src++ + 128;
-
- src += 1008;
- dst += 1008;
- dst_len += 1008;
- }
-
- /* calculate samping rate and output it in 10 seconds intervals */
- if (unlikely(time_is_before_jiffies(s->jiffies_next))) {
-#define MSECS 1UL
- unsigned int samples = sample_num[i_max - 1] - s->sample;
-
- s->jiffies_next = jiffies + msecs_to_jiffies(MSECS);
- s->sample = sample_num[i_max - 1];
- dev_dbg(&s->udev->dev,
- "slen=%d samples=%u msecs=%lu sam
Re: [V4l2-library] FourCC support
On 07/22/14 09:23, Hans Verkuil wrote: > Hi Monica, > > The v4l2-library is not the best mailinglist for that so I've added > linux-media > as well, which is more appropriate. I've also added Lars-Peter since he does a > lot of adv work as well. > > The short answer is that those colorspaces are not supported at the moment, > but that it is not a problem to add them, provided the driver you are > working on is going to be upstreamed (i.e., we'd like to have users for > the API elements we add). > > One note of interest: there is currently no API mechanism to tell userspace > if the image data is limited or full range. YCbCr is always assumed to be > limited range and RGB full range. If you need to signal that, then let me > know. A flags field has been added to struct v4l2_pix_format in the last > few days that would allow you to add a 'ALT_RANGE' flag, telling userspace > that the alternate quantization range is used. This flag doesn't exist yet, > but it is no problem to add it. To prevent any confusion: the colorspace isn't determined by the format fourcc, it's a separate colorspace field using the V4L2_COLORSPACE_* defines. The pixelformat and colorspace are two very different things. Regards, Hans > > Hope this helps, > > Hans > > On 07/22/14 08:18, Monica, Agnes wrote: >> Hi , >> >> One of drivers which we are developing supports formats like sYcc , >> AdobeRGB and AdobeYCC601 which was added recently in HDMI spec1.4. So >> can you please tell me how will these formats be supported by fmt. >> >> Regards, >> >> Monica > > -- > 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: [V4l2-library] FourCC support
Hi Monica, The v4l2-library is not the best mailinglist for that so I've added linux-media as well, which is more appropriate. I've also added Lars-Peter since he does a lot of adv work as well. The short answer is that those colorspaces are not supported at the moment, but that it is not a problem to add them, provided the driver you are working on is going to be upstreamed (i.e., we'd like to have users for the API elements we add). One note of interest: there is currently no API mechanism to tell userspace if the image data is limited or full range. YCbCr is always assumed to be limited range and RGB full range. If you need to signal that, then let me know. A flags field has been added to struct v4l2_pix_format in the last few days that would allow you to add a 'ALT_RANGE' flag, telling userspace that the alternate quantization range is used. This flag doesn't exist yet, but it is no problem to add it. Hope this helps, Hans On 07/22/14 08:18, Monica, Agnes wrote: > Hi , > > One of drivers which we are developing supports formats like sYcc , > AdobeRGB and AdobeYCC601 which was added recently in HDMI spec1.4. So > can you please tell me how will these formats be supported by fmt. > > Regards, > > Monica -- 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
[linuxtv-media:master 441/499] ERROR: "__aeabi_uldivmod" [drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined!
tree: git://linuxtv.org/media_tree.git master head: a733291d6934d0663af9e7d9f2266ab87a2946cd commit: 77bbb2b049c1c3e935f5bec510bec337d94ae8f8 [441/499] rtl2832_sdr: move from staging to media config: make ARCH=arm allmodconfig Note: the linuxtv-media/master HEAD a733291d6934d0663af9e7d9f2266ab87a2946cd builds fine. It only hurts bisectibility. All error/warnings: >> ERROR: "__aeabi_uldivmod" [drivers/media/dvb-frontends/rtl2832_sdr.ko] >> undefined! --- 0-DAY kernel build testing backend Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- 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
