Compile error at media_build
I've tried to compile media_build in a 2.6.38 kernel. I got a compile error related to implicit declaration of 'kzalloc'. The solution was to add #include to this file: media_build/v4l/as3645a.c -- Denilson Figueiredo de Sá Belo Horizonte - Brasil -- 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: [Linaro-mm-sig] [PATCH 04/11] mm: page_alloc: introduce alloc_contig_range()
My understanding of that situation is that the page is on pcp list in which cases it's page_private is not updated. Draining and the first patch in the series (and also the commit I've pointed to above) are designed to fix that but I'm unsure why they don't work all the time. On Wed, 18 Jan 2012 01:46:37 +0100, sandeep patil wrote: Will verify this if the page is found on the pcp list as well . I was wondering in general if “!PageBuddy(page) && !page_count(page)” means page is on PCP. From what I've seen in page_isolate.c it seems to be the case. I've also had a test case where it failed because (page_count() != 0) With this, when it failed the page_count() returned a value of 2. I am not sure why, but I will try and see If I can reproduce this. If I'm not mistaken, page_count() != 0 means the page is allocated. I can see the following scenarios which can lead to page being allocated in when test_pages_isolated() is called: 1. The page failed to migrate. In this case however, the code would abort earlier. 2. The page was migrated but then allocated. This is not possible since migrated pages are freed which puts the page on MIGRATE_ISOLATE freelist which guarantees that the page will not be migrated. 3. The page was removed from PCP list but with migratetype == MIGRATE_CMA. This is something the first patch in the series as well as the commit I've mentioned tries to address so hopefully it won't be an issue any more. 4. The page was allocated from PCP list. This may happen because draining of PCP list happens after IRQs are enabled in set_migratetype_isolate(). I don't have a solution for that just yet. One is to alter update_pcp_isolate_block() to remove page from the PCP list. I haven't looked at specifics of how to implement this just yet. Moving the check outside of __alloc_contig_migrate_range() after outer_start is calculated in alloc_contig_range() could help. I was going to suggest that, moving the check until after outer_start is calculated will definitely help IMO. I am sure I've seen a case where page_count(page) = page->private = 0 and PageBuddy(page) was false. Yep, I've pushed new content to my branch (git://github.com/mina86/linux-2.6.git cma) and will try to get Marek to test it some time soon (I'm currently swamped with non-Linux related work myself). -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- -- 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: [Linaro-mm-sig] [PATCH 04/11] mm: page_alloc: introduce alloc_contig_range()
> Yeah, we are wondering ourselves about that. Could you try cherry-picking > commit ad10eb079c97e27b4d27bc755c605226ce1625de (update migrate type on pcp > when isolating) from git://github.com/mina86/linux-2.6.git? It probably > won't > apply cleanly but resolving the conflicts should not be hard (alternatively > you can try branch cma from the same repo but it is a work in progress at > the > moment). > I'll try this patch and report back ,, >> is set to MIGRATE_CMA instead of MIGRATE_ISOLATED. > > > My understanding of that situation is that the page is on pcp list in which > cases it's page_private is not updated. Draining and the first patch in > the series (and also the commit I've pointed to above) are designed to fix > that but I'm unsure why they don't work all the time. > > Will verify this if the page is found on the pcp list as well . >> I've also had a test case where it failed because (page_count() != 0) With this, when it failed the page_count() returned a value of 2. I am not sure why, but I will try and see If I can reproduce this. > > >> Have you or anyone else seen this during the CMA testing? >> >> Also, could this be because we are finding a page within (start, end) >> that actually belongs to a higher order Buddy block ? > > > Higher order free buddy blocks are skipped in the “if (PageBuddy(page))” > path of __test_page_isolated_in_pageblock(). Then again, now that I think > of it, something fishy may be happening on the edges. Moving the check > outside of __alloc_contig_migrate_range() after outer_start is calculated > in alloc_contig_range() could help. I'll take a look at it. I was going to suggest that, moving the check until after outer_start is calculated will definitely help IMO. I am sure I've seen a case where page_count(page) = page->private = 0 and PageBuddy(page) was false. I will try and reproduce this as well. Thanks, Sandeep -- 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: [Linaro-mm-sig] [PATCH 04/11] mm: page_alloc: introduce alloc_contig_range()
On Tue, 17 Jan 2012 22:54:28 +0100, sandeep patil wrote: Marek, I am running a CMA test where I keep allocating from a CMA region as long as the allocation fails due to lack of space. However, I am seeing failures much before I expect them to happen. When the allocation fails, I see a warning coming from __alloc_contig_range(), because test_pages_isolated() returned "true". Yeah, we are wondering ourselves about that. Could you try cherry-picking commit ad10eb079c97e27b4d27bc755c605226ce1625de (update migrate type on pcp when isolating) from git://github.com/mina86/linux-2.6.git? It probably won't apply cleanly but resolving the conflicts should not be hard (alternatively you can try branch cma from the same repo but it is a work in progress at the moment). I tried to find out why this happened and added in a debug print inside __test_page_isolated_in_pageblock(). Here's the resulting log .. [...] From the log it looks like the warning showed up because page->private is set to MIGRATE_CMA instead of MIGRATE_ISOLATED. My understanding of that situation is that the page is on pcp list in which cases it's page_private is not updated. Draining and the first patch in the series (and also the commit I've pointed to above) are designed to fix that but I'm unsure why they don't work all the time. I've also had a test case where it failed because (page_count() != 0) Have you or anyone else seen this during the CMA testing? Also, could this be because we are finding a page within (start, end) that actually belongs to a higher order Buddy block ? Higher order free buddy blocks are skipped in the “if (PageBuddy(page))” path of __test_page_isolated_in_pageblock(). Then again, now that I think of it, something fishy may be happening on the edges. Moving the check outside of __alloc_contig_migrate_range() after outer_start is calculated in alloc_contig_range() could help. I'll take a look at it. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michał “mina86” Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- -- 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: OMAP3 ISP & BT656
On 2012-01-17 14:50, Gary Thomas wrote: I have a number of boards with OMAP 3530/3730 that use the TVP5150AM1 video decoder. On most of these boards, I can capture reasonable quality video. However, I have some (more than a few which is reason for concern) where the video is either really bad or even the ISP doesn't seem to recognize the BT656 data stream. On the ones that have "bad" video, the data is all blown out and barely recognizable. All the boards are running the same kernel (3.0+ with the YUV patches that Lennart and others proposed late last year). I've verified that the component registers (ISPCCDC and TVP5150) match. I can't see what could be the cause of such radically variable behaviour. Sorry, attribution should be to Laurent Pinchart :-) The one thing I've found is on the boards that don't work at all, the CCDC_SYN_MODE[FLDSTAT] bit is not toggling, which in turn causes no data to be pushed through the V4L2 pipeline. Any ideas what can cause this? More importantly, what I can try to fix it? The really scary thing is that all the boards in my lab work great, but in the factory (some 6000 miles away), more than not don't work :-( Would it be possible to configure the CCDC to capture the raw BT656 data? These boards are very small and it's impossible to get onto the video data lines going into the processor (they are all hidden within the circuit board). Any help/ideas gladly accepted. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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
OMAP3 ISP & BT656
I have a number of boards with OMAP 3530/3730 that use the TVP5150AM1 video decoder. On most of these boards, I can capture reasonable quality video. However, I have some (more than a few which is reason for concern) where the video is either really bad or even the ISP doesn't seem to recognize the BT656 data stream. On the ones that have "bad" video, the data is all blown out and barely recognizable. All the boards are running the same kernel (3.0+ with the YUV patches that Lennart and others proposed late last year). I've verified that the component registers (ISPCCDC and TVP5150) match. I can't see what could be the cause of such radically variable behaviour. The one thing I've found is on the boards that don't work at all, the CCDC_SYN_MODE[FLDSTAT] bit is not toggling, which in turn causes no data to be pushed through the V4L2 pipeline. Any ideas what can cause this? More importantly, what I can try to fix it? The really scary thing is that all the boards in my lab work great, but in the factory (some 6000 miles away), more than not don't work :-( Would it be possible to configure the CCDC to capture the raw BT656 data? These boards are very small and it's impossible to get onto the video data lines going into the processor (they are all hidden within the circuit board). Any help/ideas gladly accepted. -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- 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: [Linaro-mm-sig] [PATCH 04/11] mm: page_alloc: introduce alloc_contig_range()
Marek,
I am running a CMA test where I keep allocating from a CMA region as long
as the allocation fails due to lack of space.
However, I am seeing failures much before I expect them to happen.
When the allocation fails, I see a warning coming from __alloc_contig_range(),
because test_pages_isolated() returned "true".
The new retry code does try a new range and eventually succeeds.
> +
> +static int __alloc_contig_migrate_range(unsigned long start, unsigned long
> end)
> +{
> +
> +done:
> + /* Make sure all pages are isolated. */
> + if (!ret) {
> + lru_add_drain_all();
> + drain_all_pages();
> + if (WARN_ON(test_pages_isolated(start, end)))
> + ret = -EBUSY;
> + }
I tried to find out why this happened and added in a debug print inside
__test_page_isolated_in_pageblock(). Here's the resulting log ..
---
[ 133.563140] !!! Found unexpected page(pfn=9aaab), (count=0),
(isBuddy=no), (private=0x0004), (flags=0x), (_mapcount=0)
!!!
[ 133.576690] [ cut here ]
[ 133.582489] WARNING: at mm/page_alloc.c:5804 alloc_contig_range+0x1a4/0x2c4()
[ 133.594757] [] (unwind_backtrace+0x0/0xf0) from
[] (warn_slowpath_common+0x4c/0x64)
[ 133.605468] [] (warn_slowpath_common+0x4c/0x64) from
[] (warn_slowpath_null+0x18/0x1c)
[ 133.616424] [] (warn_slowpath_null+0x18/0x1c) from
[] (alloc_contig_range+0x1a4/0x2c4)
[ 133.627471] EXT4-fs (mmcblk0p25): re-mounted. Opts: (null)
[ 133.633728] [] (alloc_contig_range+0x1a4/0x2c4) from
[] (dma_alloc_from_contiguous+0x114/0x1c8)
[ 133.697113] !!! Found unexpected page(pfn=9aaac), (count=0),
(isBuddy=no), (private=0x0004), (flags=0x), (_mapcount=0)
!!!
[ 133.710510] EXT4-fs (mmcblk0p26): re-mounted. Opts: (null)
[ 133.716766] [ cut here ]
[ 133.721954] WARNING: at mm/page_alloc.c:5804 alloc_contig_range+0x1a4/0x2c4()
[ 133.734100] Emergency Remount complete
[ 133.742584] [] (unwind_backtrace+0x0/0xf0) from
[] (warn_slowpath_common+0x4c/0x64)
[ 133.753448] [] (warn_slowpath_common+0x4c/0x64) from
[] (warn_slowpath_null+0x18/0x1c)
[ 133.764373] [] (warn_slowpath_null+0x18/0x1c) from
[] (alloc_contig_range+0x1a4/0x2c4)
[ 133.775299] [] (alloc_contig_range+0x1a4/0x2c4) from
[] (dma_alloc_from_contiguous+0x114/0x1c8)
---
>From the log it looks like the warning showed up because page->private
is set to MIGRATE_CMA instead of MIGRATE_ISOLATED.
I've also had a test case where it failed because (page_count() != 0)
Have you or anyone else seen this during the CMA testing?
Also, could this be because we are finding a page within (start, end)
that actually belongs
to a higher order Buddy block ?
Thanks,
Sandeep
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 7/8] media: video: introduce object detection driver module
On 01/04/2012 09:13 AM, Ming Lei wrote:
>>> +
>>> +int odif_open(struct file *file)
>>> +{
>>> + struct odif_dev *dev = video_drvdata(file);
>>> +
>>> + kref_get(&dev->ref);
>>> + return v4l2_fh_open(file);
>>> +}
>>
>> Individual drivers may need to perform some initialization when
>> device node is opened. So I consider taking this possibility away
>> from them not a good idea.
>
> OK, it can be handled easily by introducing new callbacks(such as.
> .open_detect and .close_detect for close) in struct odif_ops.
Certainly, we can introduce plenty of new callbacks, another levels of
indirection that would just obfuscate things. It should rather be done
like v4l2-mem2mem does, where file operation handlers are implemented
by each driver and from their open()/close() handlers relevant init
and release functions are called (v4l2_m2m_init/v4l2_m2m_release).
I think we can always change the kernel interfaces once there is more
devices like OMAP4 FDIF. It may look easy for you when you refer to
just one hardware implementation with your theoretically generic module.
Or have you referred to other devices than OMAP4 FDIF when designing it ?
>>> +static int vidioc_g_od_result(struct file *file, void *priv,
>>> + struct v4l2_od_result *f)
>>> +{
>>> + struct odif_dev *dev = video_drvdata(file);
>>> + unsigned long flags;
>>> + struct v4l2_odif_result *tmp;
>>> + struct v4l2_odif_result *fr = NULL;
>>> + unsigned int cnt = 0;
>>> + int ret = -EINVAL;
>>> +
>>> + spin_lock_irqsave(&dev->lock, flags);
>>> + list_for_each_entry(tmp,&dev->odif_dq.complete, list)
>>> + if (tmp->frm_seq == f->frm_seq) {
>>> + fr = tmp;
>>> + list_del(&tmp->list);
>>> + break;
>>> + }
>>> + spin_unlock_irqrestore(&dev->lock, flags);
>>> +
>>> + if (fr) {
>>> + ret = 0;
>>> + cnt = min(f->obj_cnt, fr->obj_cnt);
>>> + if (cnt)
>>> + memcpy(f->od, fr->objs,
>>> + sizeof(struct v4l2_od_object) * cnt);
>>> + f->obj_cnt = cnt;
>>> +
>>> + free_result(fr);
>>
>> Some drivers may be designed so they do not discard the result data
>> automatically once it is read by user application. AFAICS this module
>> doesn't allow such behaviour.
>>
>> For instance, it might be required to discard the oldest results data
>> when the ring buffer gets filled in.
>
> Looks like no any benefit about keeping the old result data, could you
> give some use cases which require the old results need to be kept for
> some time?
Consider scenario where one thread writes image data and multiple threads
read the FD results. Having all data discarded on first read only one
thread could get the data. This is not what we want in a standard API.
Also in V4L2 it is always assumed that multiple applications can read
state of a device, and the application priority API [1] aims at
managing the devices state modifications among multiple processes.
...
>>> +static int buffer_init(struct vb2_buffer *vb)
>>> +{
>>> + struct odif_dev *dev = vb2_get_drv_priv(vb->vb2_queue);
>>> +
>>> + /*
>>> + * This callback is called once per buffer, after its allocation.
>>> + *
>>> + * Vivi does not allow changing format during streaming, but it is
>>> + * possible to do so when streaming is paused (i.e. in streamoff
>>> state).
>>> + * Buffers however are not freed when going into streamoff and so
>>> + * buffer size verification has to be done in buffer_prepare, on each
>>> + * qbuf.
>>> + * It would be best to move verification code here to buf_init and
>>> + * s_fmt though.
>>> + */
>>> + dprintk(dev, 1, "%s vaddr=%p\n", __func__,
>>> + vb2_plane_vaddr(vb, 0));
>>> +
>>> + return 0;
>>> +}
>>
>> As I already mentioned this empty callback can be removed. Anyway IMO the
>> implementation of the buffer queue operations should be left to individual
>> drivers. Having them in generic module doesn't sound flexible enough.
>
> IMO, the buffer queue operations can be shared for use case of
> detecting objects from user space images, so it may be kept it in
> generic driver.
Not necessarily, sometimes device specific logic needs to be implemented
in these callbacks. And the ioctl handlers (vidioc_*) should be just
pass-through for the vb2 callbacks.
>>
>>> +void odif_add_detection(struct odif_dev *dev,
>>> + struct v4l2_odif_result *v4l2_fr)
>>> +{
>>> + unsigned long flags;
>>> + struct v4l2_odif_result *old = NULL;
>>> + struct v4l2_odif_result *tmp;
>>> +
>>> + spin_lock_irqsave(&dev->lock, flags);
>>> + list_for_each_entry(tmp,&dev->odif_dq.complete, list)
>>> + if (tmp->frm_seq == v4l2_fr->frm_seq) {
>>> + old = tmp;
>>> + list_del(&tmp->li
Re: White Balance Temperature
Hi Laurent yes, I tried with saturation=137 and gamma=100, but no success. Unfortunately I am not so familiar with sniffing USB traffic, but I could try to send you a file captured with wireshark, when switching on the camera in Windows. Only thing I have to figure out, how to filter out required traffic, since it might be a very long file otherwise. Would this be ok for you? Regards Aurel -- 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: DM04 USB DVB-S TUNER
On Tue, 2012-01-17 at 13:46 -0500, Dream HTPC wrote: > >On Sat, 2011-06-25 at 22:10 +0100, Malcolm Priestley wrote: > >> On Wed, 2011-06-08 at 16:20 +0100, Malcolm Priestley wrote: > >> > On Wed, 2011-06-08 at 14:18 +0300, Mehmet Altan Pire wrote: > >> > > 07-06-2011 22:34, Malcolm Priestley yazmis: > >> > > > On Tue, 2011-06-07 at 06:31 +0100, Malcolm Priestley wrote: > >> > > > > On Tue, 2011-06-07 at 02:28 +0300, Mehmet Altan Pire wrote: > >> > > > > > 06-06-2011 00:47, Malcolm Priestley yazmis: > >> > > > > > > On Sun, 2011-06-05 at 21:42 +0100, Malcolm Priestley wrote: > >> > > > > > > > On Sun, 2011-06-05 at 19:34 +0300, Mehmet Altan Pire wrote: > >> > > > > > > > > 05-06-2011 17:16, Malcolm Priestley yazmis: > >> > > > > > > > > > On Sun, 2011-06-05 at 03:35 +0300, Mehmet Altan Pire > >> > > > > > > > > > wrote: > >> > > > > > > > > > > Hi, > >> > > > > > > > > > > I have "DM04 USB DVBS TUNER", using ubuntu with v4l > >> > > > > > > > > > > media-build > >> > > > > > > > > > > drivers/modules but device doesn't working (unknown > >> > > > > > > > > > > device). > >> > > > > > > > > > > > >> > > > > > > > > > > lsusb message: > >> > > > > > > > > > > ID 3344:22f0 > >> > > > > > > > > > > > >> > > > > > > > > > > under of the box: > >> > > > > > > > > > > DM04P2011050176 > >> > > > > > > > > Yes, i have windows xp driver, name is "US2B0D.sys" I > >> > > > > > > > > sending it, > >> > > > > > > > > attached in this mail. Thanks. > >> > > > > > > > Here is a modified lmedm04.c and lme2510b_fw.sh using the > >> > > > > > > > US2B0D.sys > >> > > > > > > > > >> > > > > > to modify the interrupt return. > >> > > > > > Ok, i tested it. Device recognized on WinXP with original > >> > > > > > driver, but tv > >> > > > > > application says "no lock". > >> > > > > > I'm not sure it worked on WinXP but driver cd is original and > >> > > > > > succesfully loaded and recognized. > >> > > > > > Again tested on ubuntu with new lmedm04.c and lme2510b_fw.sh > >> > > > > > than make, > >> > > > > > make install, and restart. > >> > > > > > > >> > > > > > lsusb says: > >> > > > > > Bus 001 Device 008: ID 3344:1120 (changes 22f0 to 1120) > >> > > > > > dmesg says: > >> > > > > Yes this should happen. The firmware will reboot with the correct > >> > > > > id. > >> > > > > > My device different or chip is damaged? Label, box and driver cd > >> > > > > > title > >> > > > > > writes "DM04P". DM04 and DM04P different devices? > >> > > > > I think the id of the chip is faulty or default. > >> > > > > > >> > > > > I will test the firmware with LG tuner later. > >> > > > It is not the LG, s7395 or S0194 tuner. > >> > > > > >> > > > So the id is intentional. > >> > > > > >> > > > How does it identify itself in windows? > >> > > > > >> > > > > >> > > > tvboxspy > >> > > > > >> > > 3. Tests > >> > > > >> > > :WinXP Test: > >> > > > >> > > I'm sure it worked on WinXP now. Tested with ProgDVB application. > >> > > Signal, channel search and watching tv as succesfully. > >> > > My Device working without problems on WinXP and it's not damaged. > >> > > When device running on stream, green led is active, if not running, > >> > > green led is passive (red led is power led and it's always active). > >> > > Driver Info: LME_PCTV_DVBS_RS2000 "VID3344 PID22F0" 22f0 this number > >> > > correct... > >> > > >> > I need to find out what exactly the RS2000 tuner is. So currently the > >> > linux driver is not supported with your device. > >> > >> A little update... > >> > >> I now have one of these devices. The chip is actually a M8BRS2000 which > >> is a combi frontend/tuner device. > >> > >> The ID is confirmed as 3344:22f0, it appears to be patched by the > >> Windows Driver as 3344:1120 devices try wrongly to use the RS2000 > >> driver. > >> > >> There is no Linux frontend driver for this device. I will start to write > >> one shortly, so support could be several months away. > >> > >I have written the M8BRS2000 frontend, which has been on test for the > >last two weeks. > > > >Unfortunately, on Friday my device has partially failed, in that the > >m8brs2000 chip starts to fail with prolonged use. > > > >It seems to be an heat issue as cooling the device restores normal > >operation. I will do some more tests in a lab this week for dry-joints. > > > >Have you or anyone else noticed any similar problems running the device > >under Windows? > > > >This means the device driver for Linux is back on Alpha and cannot be > >released. > > > >Regards > > > >Malcolm > > > > Hi Malcolm, > > first of all, thanks for all your effort making Linux drivers available for > the LME2510/LME2510C based devices. I also own one of those with the > non-SHARP / non-LG tuner. > > I did further digging and found that the chipset used for tuner/demodulation > is actually named M88RS2000 (double "8" instead of 8B). I've confirmed that > via several google searches as well as looking into my pcb with a magnifier > (picture attached). It is manufactured
Re: [PATCH 19/23] omap3isp: Default error handling for ccp2, csi2, preview and resizer
On Mon, Jan 16, 2012 at 03:50:07PM +0100, Laurent Pinchart wrote: > Hi Sakari, > > Thanks for the patch. > > On Wednesday 11 January 2012 22:26:56 Sakari Ailus wrote: > > Signed-off-by: Sakari Ailus > > --- > > drivers/media/video/omap3isp/ispccp2.c|2 ++ > > drivers/media/video/omap3isp/ispcsi2.c|2 ++ > > drivers/media/video/omap3isp/isppreview.c |2 ++ > > drivers/media/video/omap3isp/ispresizer.c |2 ++ > > drivers/media/video/omap3isp/ispvideo.c | 18 -- > > 5 files changed, 16 insertions(+), 10 deletions(-) > > [snip] > > Does the below code belong to this patch ? The commit message doesn't explain > why this is needed. I separated these changes from the rest. I'll send a new patchset in the near future. -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/23] v4l: Implement v4l2_subdev_link_validate()
Hi Laurent,
Thanks for the review!
On Mon, Jan 16, 2012 at 03:44:08PM +0100, Laurent Pinchart wrote:
> On Wednesday 11 January 2012 22:26:54 Sakari Ailus wrote:
> > v4l2_subdev_link_validate() is the default op for validating a link. In
> > V4L2 subdev context, it is used to call a pad op which performs the proper
> > link check without much extra work.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> > drivers/media/video/v4l2-subdev.c | 62
> > + include/media/v4l2-subdev.h |
> > 10 ++
> > 2 files changed, 72 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/media/video/v4l2-subdev.c
> > b/drivers/media/video/v4l2-subdev.c index 836270d..4b329a0 100644
> > --- a/drivers/media/video/v4l2-subdev.c
> > +++ b/drivers/media/video/v4l2-subdev.c
> > @@ -367,6 +367,68 @@ const struct v4l2_file_operations v4l2_subdev_fops = {
> > .poll = subdev_poll,
> > };
> >
> > +#ifdef CONFIG_MEDIA_CONTROLLER
> > +int v4l2_subdev_link_validate_default(struct v4l2_subdev *sd,
> > + struct media_link *link,
> > + struct v4l2_subdev_format *source_fmt,
> > + struct v4l2_subdev_format *sink_fmt)
> > +{
> > + if (source_fmt->format.width != sink_fmt->format.width
> > + || source_fmt->format.height != sink_fmt->format.height
> > + || source_fmt->format.code != sink_fmt->format.code)
> > + return -EINVAL;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(v4l2_subdev_link_validate_default);
>
> What about calling this function directly from v4l2_subdev_link_validate() if
> the pad::link_validate operation is NULL ? That wouldn't require changing all
> subdev drivers to explicitly use the default implementation.
I can do that. I still want to keep the function available for those that
want to call it explicitly to perform the above check.
> > +
> > +static struct v4l2_subdev_format
> > +*v4l2_subdev_link_validate_get_format(struct media_pad *pad,
> > + struct v4l2_subdev_format *fmt)
> > +{
> > + int rval;
> > +
> > + switch (media_entity_type(pad->entity)) {
> > + case MEDIA_ENT_T_V4L2_SUBDEV:
> > + fmt->which = V4L2_SUBDEV_FORMAT_ACTIVE;
> > + fmt->pad = pad->index;
> > + rval = v4l2_subdev_call(media_entity_to_v4l2_subdev(
> > + pad->entity),
> > + pad, get_fmt, NULL, fmt);
> > + if (rval < 0)
> > + return NULL;
> > + return fmt;
> > + case MEDIA_ENT_T_DEVNODE_V4L:
> > + return NULL;
> > + default:
> > + BUG();
>
> Maybe WARN() and return NULL ?
It's a clear driver BUG() if this happens. If you think the correct response
to that is WARN() and return NULL, I can do that.
> > + }
> > +}
> > +
> > +int v4l2_subdev_link_validate(struct media_link *link)
> > +{
> > + struct v4l2_subdev *sink = NULL, *source = NULL;
> > + struct v4l2_subdev_format _sink_fmt, _source_fmt;
> > + struct v4l2_subdev_format *sink_fmt, *source_fmt;
> > +
> > + source_fmt = v4l2_subdev_link_validate_get_format(
> > + link->source, &_source_fmt);
> > + sink_fmt = v4l2_subdev_link_validate_get_format(
> > + link->sink, &_sink_fmt);
> > +
> > + if (source_fmt)
> > + source = media_entity_to_v4l2_subdev(link->source->entity);
> > + if (sink_fmt)
> > + sink = media_entity_to_v4l2_subdev(link->sink->entity);
> > +
> > + if (source_fmt && sink_fmt)
> > + return v4l2_subdev_call(sink, pad, link_validate, link,
> > + source_fmt, sink_fmt);
>
> This looks overly complex. Why don't you return 0 if one of the two entities
> is of a type different than MEDIA_ENT_T_V4L2_SUBDEV, then retrieve the
> formats
> for the two entities and return 0 if one of the two operation fails, and
> finally call pad::link_validate ?
Now that you mention that, I agree. :-) I'll fix it.
Regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/23] media: Add link_validate op to check links to the sink pad
Hi Laurent,
Thanks for the review.
On Mon, Jan 16, 2012 at 03:35:07PM +0100, Laurent Pinchart wrote:
> On Wednesday 11 January 2012 22:26:53 Sakari Ailus wrote:
> > Signed-off-by: Sakari Ailus
> > ---
> > drivers/media/media-entity.c | 73
> > - include/media/media-entity.h |
> > 5 ++-
> > 2 files changed, 74 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> > index 056138f..62ef4b8 100644
> > --- a/drivers/media/media-entity.c
> > +++ b/drivers/media/media-entity.c
> > @@ -196,6 +196,35 @@ media_entity_graph_walk_next(struct media_entity_graph
> > *graph) }
> > EXPORT_SYMBOL_GPL(media_entity_graph_walk_next);
> >
> > +struct media_link_enum {
> > + int i;
> > + struct media_entity *entity;
> > + unsigned long flags, mask;
> > +};
> > +
> > +static struct media_link
> > +*media_link_walk_next(struct media_link_enum *link_enum)
> > +{
> > + do {
> > + link_enum->i++;
> > + if (link_enum->i >= link_enum->entity->num_links)
> > + return NULL;
> > + } while ((link_enum->entity->links[link_enum->i].flags
> > + & link_enum->mask) != link_enum->flags);
> > +
> > + return &link_enum->entity->links[link_enum->i];
> > +}
> > +
> > +static void media_link_walk_start(struct media_link_enum *link_enum,
> > + struct media_entity *entity,
> > + unsigned long flags, unsigned long mask)
> > +{
> > + link_enum->i = -1;
> > + link_enum->entity = entity;
> > + link_enum->flags = flags;
> > + link_enum->mask = mask;
> > +}
>
> Do we really need a generic link walking code for a single user ? Merging
> this
> in the function below would result in much simpler code.
It's a single funcition but it's being used from two locations in it. I
would keep it as-is, since performing the same in the function itself would
much complicate it.
> > +
> > /*
> > --
> > --- * Pipeline management
> > */
> > @@ -214,23 +243,63 @@ EXPORT_SYMBOL_GPL(media_entity_graph_walk_next);
> > * pipeline pointer must be identical for all nested calls to
> > * media_entity_pipeline_start().
> > */
> > -void media_entity_pipeline_start(struct media_entity *entity,
> > -struct media_pipeline *pipe)
> > +__must_check int media_entity_pipeline_start(struct media_entity *entity,
> > +struct media_pipeline *pipe)
> > {
> > struct media_device *mdev = entity->parent;
> > struct media_entity_graph graph;
> > + struct media_entity *tmp = entity;
> > + int ret = 0;
> >
> > mutex_lock(&mdev->graph_mutex);
> >
> > media_entity_graph_walk_start(&graph, entity);
> >
> > while ((entity = media_entity_graph_walk_next(&graph))) {
> > + struct media_entity_graph tmp_graph;
> > + struct media_link_enum link_enum;
> > + struct media_link *link;
> > +
> > entity->stream_count++;
> > WARN_ON(entity->pipe && entity->pipe != pipe);
> > entity->pipe = pipe;
> > +
> > + if (!entity->ops || !entity->ops->link_validate)
> > + continue;
> > +
> > + media_link_walk_start(&link_enum, entity,
> > + MEDIA_LNK_FL_ENABLED,
> > + MEDIA_LNK_FL_ENABLED);
> > +
> > + while ((link = media_link_walk_next(&link_enum))) {
> > + if (link->sink->entity != entity)
> > + continue;
> > +
> > + ret = entity->ops->link_validate(link);
> > + if (ret < 0 && ret != -ENOIOCTLCMD)
> > + break;
> > + }
> > + if (!ret || ret == -ENOIOCTLCMD)
> > + continue;
>
> What about a goto error instead ? That would keep the error code out of the
> loop.
Fixed.
> > +
> > + /*
> > +* Link validation on graph failed. We revert what we
> > +* did and return the error.
> > +*/
> > + media_entity_graph_walk_start(&tmp_graph, tmp);
>
> I've never liked tmp as a variable name. As the graph variable isn't used
> anymore from this point on, you can reuse it. tmp can then be renamed to
> something more descriptive.
I re-use graph, and tmp is called entity_err now.
> > + do {
> > + tmp = media_entity_graph_walk_next(&tmp_graph);
> > + tmp->stream_count--;
> > + if (entity->stream_count == 0)
> > + entity->pipe = NULL;
> > + } while (tmp != entity);
> > +
> > + break;
> > }
> >
> > mutex_unlock(&mdev->graph_mutex);
> > +
> > + return ret == 0 || ret == -ENOIOCTLCMD ? 0 : ret;
> > }
> > EXPORT_SYMBOL_GPL(media_entity_pipeli
[PATCH] dvbv5-scan: bugfix possible crash by parsing strings
From: Stefan Ringel PID 0x0010, TableID 0x40 ID=0x3001, version 4, size 132 40 f0 81 30 01 c9 00 00 f0 26 40 18 44 56 42 2d 54 20 42 65 72 6c 69 6e 2f 42 72 61 6e 64 65 6e 62 75 72 67 6c 0a 01 01 49 9a 08 89 21 01 ec 00 f0 4e 01 01 21 14 f0 24 5a 0b 04 10 a6 40 1f 41 12 ff ff ff ff 6d 07 01 01 04 10 a6 40 00 41 0c 00 02 01 00 41 01 00 61 01 00 81 01 01 02 21 14 f0 1e 5a 0b 03 1c 82 40 1f 41 12 ff ff ff ff 41 0f 00 0b 01 00 0c 01 00 0d 01 00 0e 01 00 0f 01 5a 5e 75 59 section_length = 129 section 0, last section 0 Descriptors table len 38 network_name_descriptor (0x40), len 24 44 56 42 2d 54 20 42 65 72 6c 69 6e 2f 42 72 61 6e 64 65 6e 62 75 72 67 *** glibc detected *** ./dvbv5-scan: free(): invalid pointer: 0x00618dc0 *** === Backtrace: = /lib64/libc.so.6(+0x74c06)[0x7ffe9b15dc06] ./dvbv5-scan[0x407ba6] ./dvbv5-scan[0x407339] ./dvbv5-scan[0x405c7e] ./dvbv5-scan[0x4067d3] ./dvbv5-scan[0x401749] /lib64/libc.so.6(__libc_start_main+0xed)[0x7ffe9b10a23d] ./dvbv5-scan[0x401dd5] === Memory map: 0040-0040e000 r-xp 08:03 15084544 /home/stefan/build/dvb_utils/v4l-utils/utils/dvb/dvbv5-scan 0060d000-0060e000 r--p d000 08:03 15084544 /home/stefan/build/dvb_utils/v4l-utils/utils/dvb/dvbv5-scan 0060e000-0061 rw-p e000 08:03 15084544 /home/stefan/build/dvb_utils/v4l-utils/utils/dvb/dvbv5-scan 0061-00631000 rw-p 00:00 0 [heap] 7ffe9acd-7ffe9ace5000 r-xp 08:03 15859816 /lib64/libgcc_s.so.1 7ffe9ace5000-7ffe9aee4000 ---p 00015000 08:03 15859816 /lib64/libgcc_s.so.1 7ffe9aee4000-7ffe9aee5000 r--p 00014000 08:03 15859816 /lib64/libgcc_s.so.1 7ffe9aee5000-7ffe9aee6000 rw-p 00015000 08:03 15859816 /lib64/libgcc_s.so.1 7ffe9aee6000-7ffe9aee8000 r-xp 08:03 59904690 /usr/lib64/gconv/ISO8859-1.so 7ffe9aee8000-7ffe9b0e7000 ---p 2000 08:03 59904690 /usr/lib64/gconv/ISO8859-1.so 7ffe9b0e7000-7ffe9b0e8000 r--p 1000 08:03 59904690 /usr/lib64/gconv/ISO8859-1.so 7ffe9b0e8000-7ffe9b0e9000 rw-p 2000 08:03 59904690 /usr/lib64/gconv/ISO8859-1.so 7ffe9b0e9000-7ffe9b26e000 r-xp 08:03 15859719 /lib64/libc-2.14.1.so 7ffe9b26e000-7ffe9b46e000 ---p 00185000 08:03 15859719 /lib64/libc-2.14.1.so 7ffe9b46e000-7ffe9b472000 r--p 00185000 08:03 15859719 /lib64/libc-2.14.1.so 7ffe9b472000-7ffe9b473000 rw-p 00189000 08:03 15859719 /lib64/libc-2.14.1.so 7ffe9b473000-7ffe9b478000 rw-p 00:00 0 7ffe9b478000-7ffe9b498000 r-xp 08:03 15859714 /lib64/ld-2.14.1.so 7ffe9b671000-7ffe9b674000 rw-p 00:00 0 7ffe9b68e000-7ffe9b68f000 rw-p 00:00 0 7ffe9b68f000-7ffe9b696000 r--s 08:03 59904753 /usr/lib64/gconv/gconv-modules.cache 7ffe9b696000-7ffe9b698000 rw-p 00:00 0 7ffe9b698000-7ffe9b699000 r--p 0002 08:03 15859714 /lib64/ld-2.14.1.so 7ffe9b699000-7ffe9b69a000 rw-p 00021000 08:03 15859714 /lib64/ld-2.14.1.so 7ffe9b69a000-7ffe9b69b000 rw-p 00:00 0 7fffab429000-7fffab44a000 rw-p 00:00 0 [stack] 7fffab51c000-7fffab51d000 r-xp 00:00 0 [vdso] ff60-ff601000 r-xp 00:00 0 [vsyscall] Abgebrochen localhost:/home/stefan/build/dvb_utils/v4l-utils/utils/dvb # Signed-off-by: Stefan Ringel --- utils/dvb/parse_string.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/utils/dvb/parse_string.c b/utils/dvb/parse_string.c index f073a07..37f5c3a 100644 --- a/utils/dvb/parse_string.c +++ b/utils/dvb/parse_string.c @@ -410,8 +410,8 @@ void parse_string(char **dest, char **emph, * Handles the ISO/IEC 10646 1-byte control codes * (EN 300 468 v1.11.1 Table A.1) */ - tmp1 = malloc(len); - tmp2 = malloc(len); + tmp1 = malloc(len + 2); + tmp2 = malloc(len + 2); p = (char *)tmp1; p2 = (char *)tmp2; s = src; -- 1.7.7 -- 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 14/23] omap3isp: Configure CSI-2 phy based on platform data
Hi Laurent,
Many thanks for reviewing these!
On Mon, Jan 16, 2012 at 03:22:42PM +0100, Laurent Pinchart wrote:
> On Wednesday 11 January 2012 22:26:51 Sakari Ailus wrote:
> > Configure CSI-2 phy based on platform data in the ISP driver. For that, the
> > new V4L2_CID_IMAGE_SOURCE_PIXEL_RATE control is used. Previously the same
> > was configured from the board code.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> > drivers/media/video/omap3isp/isp.c | 29 ++-
> > drivers/media/video/omap3isp/isp.h |4 --
> > drivers/media/video/omap3isp/ispcsi2.c | 42 ++-
> > drivers/media/video/omap3isp/ispcsiphy.c | 84
> > ++ drivers/media/video/omap3isp/ispcsiphy.h |
> > 5 ++
> > 5 files changed, 148 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/media/video/omap3isp/isp.c
> > b/drivers/media/video/omap3isp/isp.c index b818cac..d268d55 100644
> > --- a/drivers/media/video/omap3isp/isp.c
> > +++ b/drivers/media/video/omap3isp/isp.c
> > @@ -765,6 +765,34 @@ static int isp_pipeline_enable(struct isp_pipeline
> > *pipe, if (ret < 0 && ret != -ENOIOCTLCMD)
> > return ret;
> >
> > + /*
> > +* Configure CCDC pixel clock. host_priv != NULL so
> > +* this one is a sensor.
> > +*/
> > + if (subdev->host_priv) {
> > + struct v4l2_ext_controls ctrls;
> > + struct v4l2_ext_control ctrl;
> > +
> > + memset(&ctrls, 0, sizeof(ctrls));
> > + memset(&ctrl, 0, sizeof(ctrl));
> > +
> > + ctrl.id = V4L2_CID_IMAGE_SOURCE_PIXEL_RATE;
> > +
> > + ctrls.ctrl_class = V4L2_CTRL_ID2CLASS(ctrl.id);
> > + ctrls.count = 1;
> > + ctrls.controls = &ctrl;
> > +
> > + ret = v4l2_g_ext_ctrls(subdev->ctrl_handler, &ctrls);
> > + if (ret < 0) {
> > + dev_warn(isp->dev,
> > +"no pixel rate control in subdev %s\n",
> > +subdev->name);
> > + return -EPIPE;
> > + }
> > +
> > + isp_set_pixel_clock(isp, ctrl.value64);
>
> Isn't this too late ? The CCDC has already been started. What about moving
> this code to ccdc_config_vp() ?
I think you're right. I've mostly rewritten this part of the patchset and I
think it's much cleaner now.
I have validate_link() functions where I'm validating the link and also
gathering information alongside that process into a few fields in
isp_pipeline struct.
Then those fields can be used in streamon time. Some additional checks for
those parameters are also done there and they may result into an error which
is then handled.
> > + }
> > +
> > if (subdev == &isp->isp_ccdc.subdev) {
> > v4l2_subdev_call(&isp->isp_aewb.subdev, video,
> > s_stream, mode);
> > @@ -2072,7 +2100,6 @@ static int isp_probe(struct platform_device *pdev)
> >
> > isp->autoidle = autoidle;
> > isp->platform_cb.set_xclk = isp_set_xclk;
> > - isp->platform_cb.set_pixel_clock = isp_set_pixel_clock;
> >
> > mutex_init(&isp->isp_mutex);
> > spin_lock_init(&isp->stat_lock);
> > diff --git a/drivers/media/video/omap3isp/isp.h
> > b/drivers/media/video/omap3isp/isp.h index ff1c422..dd1b61e 100644
> > --- a/drivers/media/video/omap3isp/isp.h
> > +++ b/drivers/media/video/omap3isp/isp.h
> > @@ -126,10 +126,6 @@ struct isp_reg {
> >
> > struct isp_platform_callback {
> > u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
> > - int (*csiphy_config)(struct isp_csiphy *phy,
> > -struct isp_csiphy_dphy_cfg *dphy,
> > -struct isp_csiphy_lanes_cfg *lanes);
> > - void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
> > };
> >
> > /*
> > diff --git a/drivers/media/video/omap3isp/ispcsi2.c
> > b/drivers/media/video/omap3isp/ispcsi2.c index 0c5f1cb..0b3e705 100644
> > --- a/drivers/media/video/omap3isp/ispcsi2.c
> > +++ b/drivers/media/video/omap3isp/ispcsi2.c
> > @@ -1055,7 +1055,45 @@ static int csi2_set_stream(struct v4l2_subdev *sd,
> > int enable) struct isp_video *video_out = &csi2->video_out;
> >
> > switch (enable) {
> > - case ISP_PIPELINE_STREAM_CONTINUOUS:
> > + case ISP_PIPELINE_STREAM_CONTINUOUS: {
> > + struct media_pad *remote_pad =
> > + media_entity_remote_source(&sd->entity.pads[0]);
>
> As you will need to locate the sensor in ccdc_config_vp() as well, you should
> store a pointer to the sensor in the pipeline structure in
> isp_video_streamon(). I think I've sent you code that does just that,
> originally written by Stan if my memory is correct.
Stan's patch assumed all external subdevs will be sensors. That may not be
true in all
Re: [PATCH 09/23] v4l: Add DPCM compressed formats
Hi Laurent,
Thanks for the review!
On Mon, Jan 16, 2012 at 03:01:50PM +0100, Laurent Pinchart wrote:
> On Wednesday 11 January 2012 22:26:46 Sakari Ailus wrote:
> > Add three other colour orders for 10-bit to 8-bit DPCM compressed formats.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> > Documentation/DocBook/media/v4l/pixfmt-srggb10.xml |2 +-
> > .../DocBook/media/v4l/pixfmt-srggb10dpcm8.xml | 29
> > Documentation/DocBook/media/v4l/pixfmt.xml |
> > 1 +
> > include/linux/videodev2.h |3 ++
> > 4 files changed, 34 insertions(+), 1 deletions(-)
> > create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
> >
> > diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> > b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml index
> > 7b27409..c1c62a9 100644
> > --- a/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> > +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10.xml
> > @@ -1,4 +1,4 @@
> > -
> > +
> >
> > V4L2_PIX_FMT_SRGGB10 ('RG10'),
> > V4L2_PIX_FMT_SGRBG10 ('BA10'),
> > diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
> > b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml new file mode
> > 100644
> > index 000..985440c
> > --- /dev/null
> > +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml
> > @@ -0,0 +1,29 @@
> > +
> > +
> > +
> > +V4L2_PIX_FMT_SRGGB10DPCM8 ('bBA8'),
> > +V4L2_PIX_FMT_SGBRG10DPCM8 ('bGA8'),
> > +V4L2_PIX_FMT_SGRBG10DPCM8 ('BD10'),
> > +V4L2_PIX_FMT_SBGGR10DPCM8 ('bRA8'),
>
> Could you briefly explain the rationale behind the FOURCCs in the patch
> commit
> message ? Manjunath needs similar FOURCCs for A-law compression, what should
> he use ?
Sure; I'll do that.
> > +
> > + &manvol;
> > +
> > +
> > +> id="V4L2-PIX-FMT-SRGGB10DPCM8">V4L2_PIX_FMT_SRGGB10DPCM8 > nt> + > id="V4L2-PIX-FMT-SGRBG10DPCM8">V4L2_PIX_FMT_SGRBG10DPCM8 > nt> + > id="V4L2-PIX-FMT-SGBRG10DPCM8">V4L2_PIX_FMT_SGBRG10DPCM8 > nt> + > id="V4L2-PIX-FMT-SBGGR10DPCM8">V4L2_PIX_FMT_SBGGR10DPCM8 > nt> + 10-bit Bayer formats compressed to 8
> > bits +
> > +
> > + Description
> > +
> > + The following four pixel formats are raw sRGB / Bayer
> > + formats with 10 bits per colour compressed to 8 bits each,
> > + using the DPCM. DPCM, differential pulse-code modulation, is
>
> s/the DPCM/DPCM/ ?
Fixed. It's now s/the DPCM/DPCM compression/.
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/23] omap3isp: Add lane configuration to platform data
Hi Laurent,
Thanks for the review!
On Mon, Jan 16, 2012 at 03:08:26PM +0100, Laurent Pinchart wrote:
> On Wednesday 11 January 2012 22:26:50 Sakari Ailus wrote:
> > Add lane configuration (order of clock and data lane) to platform data on
> > both CCP2 and CSI-2.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> > drivers/media/video/omap3isp/ispcsiphy.h | 15 ++-
> > include/media/omap3isp.h | 25 +
> > 2 files changed, 27 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/media/video/omap3isp/ispcsiphy.h
> > b/drivers/media/video/omap3isp/ispcsiphy.h index 9596dc6..e93a661 100644
> > --- a/drivers/media/video/omap3isp/ispcsiphy.h
> > +++ b/drivers/media/video/omap3isp/ispcsiphy.h
> > @@ -27,22 +27,11 @@
> > #ifndef OMAP3_ISP_CSI_PHY_H
> > #define OMAP3_ISP_CSI_PHY_H
> >
> > +#include
> > +
> > struct isp_csi2_device;
> > struct regulator;
> >
> > -struct csiphy_lane {
> > - u8 pos;
> > - u8 pol;
> > -};
> > -
> > -#define ISP_CSIPHY2_NUM_DATA_LANES 2
> > -#define ISP_CSIPHY1_NUM_DATA_LANES 1
> > -
> > -struct isp_csiphy_lanes_cfg {
> > - struct csiphy_lane data[ISP_CSIPHY2_NUM_DATA_LANES];
> > - struct csiphy_lane clk;
> > -};
> > -
> > struct isp_csiphy_dphy_cfg {
> > u8 ths_term;
> > u8 ths_settle;
> > diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
> > index 9c1a001..bc14099 100644
> > --- a/include/media/omap3isp.h
> > +++ b/include/media/omap3isp.h
> > @@ -91,6 +91,29 @@ enum {
> > };
> >
> > /**
> > + * struct isp_csiphy_lane: CCP2/CSI2 lane position and polarity
> > + * @pos: position of the lane
> > + * @pol: polarity of the lane
> > + */
> > +struct isp_csiphy_lane {
> > + u8 pos;
> > + u8 pol;
> > +};
> > +
> > +#define ISP_CSIPHY2_NUM_DATA_LANES 2
> > +#define ISP_CSIPHY1_NUM_DATA_LANES 1
>
> Any reason not to put CSIPHY1 first ? :-)
Yes. I believe wrote it that way. ;-)
I'll change it.
> With that modification,
>
> Acked-by: Laurent Pinchart
Thanks!
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] [media] dvb_frontend: Don't call get_frontend() if idle
If the frontend is in idle state, don't call get_frontend.
Calling get_frontend() when the device is not tuned may
result in wrong parameters to be returned to the
userspace.
I was tempted to not call get_frontend() at all, except
inside the dvb frontend thread, but this won't work for
all cases. The ISDB-T specs (ABNT NBR 15601 and ARIB
STD-B31) allow the broadcaster to dynamically change the
channel specs at runtime. That means that an ISDB-T optimized
application may want/need to monitor the TMCC tables, decoded
at the frontends via get_frontend call.
So, let's do the simpler change here.
Eventually, the logic could be changed to work only if
the device is tuned and has lock, but, even so, the
lock is also standard-dependent. For ISDB-T, the right
lock to wait is that the demod has TMCC lock. So, drivers
may need to implement some logic to detect if the get_frontend
info was retrieved or not.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index f5fa7aa..2998f38 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1744,6 +1744,7 @@ static int dvb_frontend_ioctl_properties(struct file
*file,
{
struct dvb_device *dvbdev = file->private_data;
struct dvb_frontend *fe = dvbdev->priv;
+ struct dvb_frontend_private *fepriv = fe->frontend_priv;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
int err = 0;
@@ -1810,9 +1811,14 @@ static int dvb_frontend_ioctl_properties(struct file
*file,
/*
* Fills the cache out struct with the cache contents, plus
-* the data retrieved from get_frontend.
+* the data retrieved from get_frontend, if the frontend
+* is not idle. Otherwise, returns the cached content
*/
- dtv_get_frontend(fe, NULL);
+ if (fepriv->state != FESTATE_IDLE) {
+ err = dtv_get_frontend(fe, NULL);
+ if (err < 0)
+ goto out;
+ }
for (i = 0; i < tvps->num; i++) {
err = dtv_property_process_get(fe, c, tvp + i, file);
if (err < 0)
--
1.7.8
--
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/4] [media] DocBook/dvbproperty.xml: Remove DTV_MODULATION from ISDB-T
On ISDB-T, each layer can have its own independent modulation,
applied to the carriers that belong to the segments associated
with them. So, there's no sense to define a global modulation
parameter.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/DocBook/media/dvb/dvbproperty.xml |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 2de2bb3..c7a4ca5 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -737,7 +737,6 @@ typedef enum fe_hierarchy {
DTV_TUNE
DTV_CLEAR
DTV_FREQUENCY
- DTV_MODULATION
DTV_BANDWIDTH_HZ
DTV_INVERSION
DTV_GUARD_INTERVAL
--
1.7.8
--
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/4] [media] DocBook/dvbproperty.xml: Fix the units for DTV_FREQUENCY
The units for DTV_FREQUENCY are kHz for satellital delivery systems (DVB-S/DVB-S2/DVB-TURBO/ISDB-S). Fix it at the API spec. Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/dvb/dvbproperty.xml |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml index ffee1fb..0496641 100644 --- a/Documentation/DocBook/media/dvb/dvbproperty.xml +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml @@ -163,14 +163,16 @@ get/set up to 64 properties. The actual meaning of each property is described on DTV_FREQUENCY - Central frequency of the channel, in HZ. + Central frequency of the channel. Notes: - 1)For ISDB-T, the channels are usually transmitted with an offset of 143kHz. + 1)For satellital delivery systems, it is measured in kHz. + For the other ones, it is measured in Hz. + 2)For ISDB-T, the channels are usually transmitted with an offset of 143kHz. E.g. a valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of the channel which is 6MHz. - 2)As in ISDB-Tsb the channel consists of only one or three segments the + 3)As in ISDB-Tsb the channel consists of only one or three segments the frequency step is 429kHz, 3*429 respectively. As for ISDB-T the central frequency of the channel is expected. -- 1.7.8 -- 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/4] [media] DocBook/dvbproperty.xml: Fix ISDB-T delivery system parameters
The ISDB-T differs on its way to implement the hierarchical
transmissions: instead of using a low-priority/high-priority
FEC codes, it does that by using different layers, each layer
with their groups of segments. So, those parameters don't make sense
for ISDB-T.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/DocBook/media/dvb/dvbproperty.xml |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml
b/Documentation/DocBook/media/dvb/dvbproperty.xml
index 0496641..2de2bb3 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -740,11 +740,8 @@ typedef enum fe_hierarchy {
DTV_MODULATION
DTV_BANDWIDTH_HZ
DTV_INVERSION
- DTV_CODE_RATE_HP
- DTV_CODE_RATE_LP
DTV_GUARD_INTERVAL
DTV_TRANSMISSION_MODE
- DTV_HIERARCHY
DTV_ISDBT_LAYER_ENABLED
DTV_ISDBT_PARTIAL_RECEPTION
DTV_ISDBT_SOUND_BROADCASTING
--
1.7.8
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Some DVB fixes (3 for API, 1 for dvb_frontend)
This series of patches contain 3 API fixes. I'm not increasing the DVB API number because it will be increased anyway by Antti's API additions for DTMB. Those fixes on this series are: 1) DTV_FREQUENCY is kHz on DVB-S & friends; 2) There are more parameters for ISDB-T than supported. On ISDB-T, the hierarchical transmission is completely different than the one on DVB-T: the OFDM carriers are grouped into up to 3 layers. each layer can be decoded independently from the others, as each layer group of carriers use their own modulation. So, there's no such concept as code rate HP/LP; 3) Some frontends behave badly if they're called while sleeping. As DVB FE_GET_PROPERTY is called before tuning, to retrieve the DVB version and the current and supported delivery systems, this can cause troubles for them. The fix for (3) is not complete, as a DVBv3 call can still do bad things. Also, the DVB frontend thread may call get_frontend before the frontend is ready to provide the needed information. A deeper analysis will be needed to fix it completely, but at least the regression is fixed with this change. Mauro Carvalho Chehab (4): [media] DocBook/dvbproperty.xml: Fix the units for DTV_FREQUENCY [media] DocBook/dvbproperty.xml: Fix ISDB-T delivery system parameters [media] DocBook/dvbproperty.xml: Remove DTV_MODULATION from ISDB-T [media] dvb_frontend: Don't call get_frontend() if idle Documentation/DocBook/media/dvb/dvbproperty.xml | 12 +--- drivers/media/dvb/dvb-core/dvb_frontend.c | 10 -- 2 files changed, 13 insertions(+), 9 deletions(-) -- 1.7.8 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Tue Jan 17 19:00:18 CET 2012 git hash:d04ca8df70f0e1c3fe6ee2aeb1114b03a3a3de88 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DM04 USB DVB-S TUNER
>On Sat, 2011-06-25 at 22:10 +0100, Malcolm Priestley wrote: >> On Wed, 2011-06-08 at 16:20 +0100, Malcolm Priestley wrote: >> > On Wed, 2011-06-08 at 14:18 +0300, Mehmet Altan Pire wrote: >> > > 07-06-2011 22:34, Malcolm Priestley yazmis: >> > > > On Tue, 2011-06-07 at 06:31 +0100, Malcolm Priestley wrote: >> > > > > On Tue, 2011-06-07 at 02:28 +0300, Mehmet Altan Pire wrote: >> > > > > > 06-06-2011 00:47, Malcolm Priestley yazmis: >> > > > > > > On Sun, 2011-06-05 at 21:42 +0100, Malcolm Priestley wrote: >> > > > > > > > On Sun, 2011-06-05 at 19:34 +0300, Mehmet Altan Pire wrote: >> > > > > > > > > 05-06-2011 17:16, Malcolm Priestley yazmis: >> > > > > > > > > > On Sun, 2011-06-05 at 03:35 +0300, Mehmet Altan Pire wrote: >> > > > > > > > > > > Hi, >> > > > > > > > > > > I have "DM04 USB DVBS TUNER", using ubuntu with v4l >> > > > > > > > > > > media-build >> > > > > > > > > > > drivers/modules but device doesn't working (unknown >> > > > > > > > > > > device). >> > > > > > > > > > > >> > > > > > > > > > > lsusb message: >> > > > > > > > > > > ID 3344:22f0 >> > > > > > > > > > > >> > > > > > > > > > > under of the box: >> > > > > > > > > > > DM04P2011050176 >> > > > > > > > > Yes, i have windows xp driver, name is "US2B0D.sys" I >> > > > > > > > > sending it, >> > > > > > > > > attached in this mail. Thanks. >> > > > > > > > Here is a modified lmedm04.c and lme2510b_fw.sh using the >> > > > > > > > US2B0D.sys >> > > > > > > > >> > > > > > to modify the interrupt return. >> > > > > > Ok, i tested it. Device recognized on WinXP with original driver, >> > > > > > but tv >> > > > > > application says "no lock". >> > > > > > I'm not sure it worked on WinXP but driver cd is original and >> > > > > > succesfully loaded and recognized. >> > > > > > Again tested on ubuntu with new lmedm04.c and lme2510b_fw.sh than >> > > > > > make, >> > > > > > make install, and restart. >> > > > > > >> > > > > > lsusb says: >> > > > > > Bus 001 Device 008: ID 3344:1120 (changes 22f0 to 1120) >> > > > > > dmesg says: >> > > > > Yes this should happen. The firmware will reboot with the correct id. >> > > > > > My device different or chip is damaged? Label, box and driver cd >> > > > > > title >> > > > > > writes "DM04P". DM04 and DM04P different devices? >> > > > > I think the id of the chip is faulty or default. >> > > > > >> > > > > I will test the firmware with LG tuner later. >> > > > It is not the LG, s7395 or S0194 tuner. >> > > > >> > > > So the id is intentional. >> > > > >> > > > How does it identify itself in windows? >> > > > >> > > > >> > > > tvboxspy >> > > > >> > > 3. Tests >> > > >> > > :WinXP Test: >> > > >> > > I'm sure it worked on WinXP now. Tested with ProgDVB application. >> > > Signal, channel search and watching tv as succesfully. >> > > My Device working without problems on WinXP and it's not damaged. >> > > When device running on stream, green led is active, if not running, >> > > green led is passive (red led is power led and it's always active). >> > > Driver Info: LME_PCTV_DVBS_RS2000 "VID3344 PID22F0" 22f0 this number >> > > correct... >> > >> > I need to find out what exactly the RS2000 tuner is. So currently the >> > linux driver is not supported with your device. >> >> A little update... >> >> I now have one of these devices. The chip is actually a M8BRS2000 which >> is a combi frontend/tuner device. >> >> The ID is confirmed as 3344:22f0, it appears to be patched by the >> Windows Driver as 3344:1120 devices try wrongly to use the RS2000 >> driver. >> >> There is no Linux frontend driver for this device. I will start to write >> one shortly, so support could be several months away. >> >I have written the M8BRS2000 frontend, which has been on test for the >last two weeks. > >Unfortunately, on Friday my device has partially failed, in that the >m8brs2000 chip starts to fail with prolonged use. > >It seems to be an heat issue as cooling the device restores normal >operation. I will do some more tests in a lab this week for dry-joints. > >Have you or anyone else noticed any similar problems running the device >under Windows? > >This means the device driver for Linux is back on Alpha and cannot be >released. > >Regards > >Malcolm > Hi Malcolm, first of all, thanks for all your effort making Linux drivers available for the LME2510/LME2510C based devices. I also own one of those with the non-SHARP / non-LG tuner. I did further digging and found that the chipset used for tuner/demodulation is actually named M88RS2000 (double "8" instead of 8B). I've confirmed that via several google searches as well as looking into my pcb with a magnifier (picture attached). It is manufactured by Montage Tech, with some product info in the links below (nothing too technical, unfortunately): http://www.montage-tech.com/products_DTV.htm http://www.montage-tech.com/Product_RS2000.html I've sent them an email (inf...@montage-tech.com) asking for info that could help us on building a linux driver for their p
[PATCH] [RFC] dib8000: return an error if the TMCC is not locked
On ISDB-T, a few carriers are reserved for TMCC decoding
(1 to 20 carriers, depending on the mode). Those carriers
use the DBPSK modulation, and contain the information about
each of the three layers of carriers (modulation, partial
reception, inner code, interleaving, and number of segments).
If the TMCC carrier was not locked and decoded, no information
would be provided by get_frontend(). So, instead of returning
false values, return -EAGAIN.
Another alternative for this patch would be to add a flag to
fe_status (FE_HAS_GET_FRONTEND?), to indicate that the ISDB-T
TMCC carriers (and DVB-T TPS?), required for get_frontend
to work, are locked.
Comments?
Cc: Patrick Boettcher
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb/frontends/dib8000.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/frontends/dib8000.c
b/drivers/media/dvb/frontends/dib8000.c
index 9ca34f4..c566be2 100644
--- a/drivers/media/dvb/frontends/dib8000.c
+++ b/drivers/media/dvb/frontends/dib8000.c
@@ -2813,7 +2813,7 @@ EXPORT_SYMBOL(dib8000_set_tune_state);
static int dib8000_get_frontend(struct dvb_frontend *fe)
{
struct dib8000_state *state = fe->demodulator_priv;
- u16 i, val = 0;
+ u16 i, val = 0, lock;
fe_status_t stat;
u8 index_frontend, sub_index_frontend;
@@ -2840,7 +2840,7 @@ static int dib8000_get_frontend(struct dvb_frontend *fe)
}
}
}
- return 0;
+ goto ret;
}
}
@@ -2953,6 +2953,17 @@ static int dib8000_get_frontend(struct dvb_frontend *fe)
state->fe[index_frontend]->dtv_property_cache.layer[i].modulation =
fe->dtv_property_cache.layer[i].modulation;
}
}
+
+ret:
+ if (state->revision != 0x8090)
+ lock = dib8000_read_word(state, 568);
+ else
+ lock = dib8000_read_word(state, 570);
+
+ /* Check if the TMCC decoder is locked */
+ if ((lock & 0x1e) != 0x1e)
+ return -EAGAIN;
+
return 0;
}
--
1.7.8
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] DVB: dib0700, move Nova-TD Stick to a separate set
H Jiri, On Tuesday 10 January 2012 18:11:22 Jiri Slaby wrote: > To properly support the three LEDs which are on the stick, we need > a special handling in the ->frontend_attach function. Thus let's have > a separate ->frontend_attach instead of ifs in the common one. > > The hadnling itself will be added in further patches. > > Signed-off-by: Jiri Slaby > --- > [..] Thanks. I reviewed and added those commits to my tree (apparently Mike did the same and asked Mauro to pull as well). We will see how it turns out. :) best regards, -- Patrick Boettcher Kernel Labs Inc. http://www.kernellabs.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Adding YUV input support for OMAP3ISP driver
Hi Abhishek,
Thank you for the patch, and sorry for the very late reply. For some reason
the mail slipped through and I've only noticed it now.
First of all, please fix your mailer. The message is sent in plain text + HTML
format, which is refused by many mailing lists. You should use plain text
only. The message also has tabs converted to spaces. This will break the
scripts that handle patches sent by e-mail.
The preferred way to send patches is to use the 'git send-email' tool. This
will make sure that patches are properly formatted. I've reformatted the patch
manually to comment it this time, but please make sure it gets formatted
properly next time.
On Tuesday 06 December 2011 12:45:51 Abhishek Reddy Kondaveeti wrote:
> Adding YUV input support for Omap3ISp driver, so that we don't need to
> use entire pipeline while working with SOC camera chips.
>
> Signed-off-by: Abhishek
>
> From 32d0984fa18fa324dd9dc628d1cfb1d369c2298f Mon Sep 17 00:00:00 2001
> From: Abhishek
> Date: Tue, 6 Dec 2011 15:11:06 +0530
> Subject: [PATCH 10217/10217] "Added YUV Support for OMAP3ISP driver"
>
> ---
>
> drivers/media/video/omap3isp/isp.c |2 +-
> drivers/media/video/omap3isp/ispccdc.c |9 +
> drivers/media/video/omap3isp/ispvideo.c |4 ++--
> 3 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/video/omap3isp/isp.c
> b/drivers/media/video/omap3isp/isp.c
> index b818cac..417d97b 100644
> --- a/drivers/media/video/omap3isp/isp.c
> +++ b/drivers/media/video/omap3isp/isp.c
> @@ -308,7 +308,7 @@ void omap3isp_configure_bridge(struct isp_device
> *isp,
> case CCDC_INPUT_PARALLEL:
> ispctrl_val |= ISPCTRL_PAR_SER_CLK_SEL_PARALLEL;
> ispctrl_val |= pdata->clk_pol <<
> ISPCTRL_PAR_CLK_POL_SHIFT;
> - ispctrl_val |= pdata->bridge <<
> ISPCTRL_PAR_BRIDGE_SHIFT;
> + ispctrl_val |= pdata->bridge;
Why is this needed ? Board code should use the constants defined in
include/media/omap3isp.h (ISP_BRIDGE_DISABLE, ISP_BRIDGE_LITTLE_ENDIAN or
ISP_BRIDGE_BIG_ENDIAN), so they should be shifted left here.
> shift += pdata->data_lane_shift * 2;
> break;
>
> diff --git a/drivers/media/video/omap3isp/ispccdc.c
> b/drivers/media/video/omap3isp/ispccdc.c
> index b0b0fa5..0268097 100644
> --- a/drivers/media/video/omap3isp/ispccdc.c
> +++ b/drivers/media/video/omap3isp/ispccdc.c
> @@ -58,6 +58,8 @@ static const unsigned int ccdc_fmts[] = {
> V4L2_MBUS_FMT_SRGGB12_1X12,
> V4L2_MBUS_FMT_SBGGR12_1X12,
> V4L2_MBUS_FMT_SGBRG12_1X12,
> + V4L2_MBUS_FMT_UYVY8_1X16,
> + V4L2_MBUS_FMT_YUYV8_1X16,
You should use V4L2_MBUS_FMT_UYVY8_2X8 and V4L2_MBUS_FMT_YUYV8_2X8 instead, as
the sensor bus is 8 bits wide, not 16 bits wide.
The format at the CCDC output, however, will be V4L2_MBUS_FMT_UYVY8_1X16 or
V4L2_MBUS_FMT_YUYV8_1X16. ccdc_try_format() needs to be modified to handle
that.
> };
> /*
>
> @@ -1158,6 +1160,13 @@ static void ccdc_configure(struct isp_ccdc_device
> *ccdc)
> format = &ccdc->formats[CCDC_PAD_SINK];
> syn_mode = isp_reg_readl(isp, OMAP3_ISP_IOMEM_CCDC,
> ISPCCDC_SYN_MODE);
>
> + if((format->code == V4L2_MBUS_FMT_UYVY8_1X16) ||
> +(format->code == V4L2_MBUS_FMT_YUYV8_1X16))
> + {
> + syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
> + syn_mode |= ISPCCDC_SYN_MODE_DATSIZ_10;
> + }
> +
Why DATSIZ_10 ? Isn't the input data 8-bits wide ?
I already had a couple of YUV support patches in my OMAP3 ISP tree at
git.kernel.org. I've rebased them on top of the lastest V4L/DVB tree and
pushed them to
http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-
omap3isp-yuv. Could you please try them, and see if they're usable with your
sensor ?
> /* Use the raw, unprocessed data when writing to memory. The
> H3A and
>* histogram modules are still fed with lens shading corrected
> data.
>
> diff --git a/drivers/media/video/omap3isp/ispvideo.c
> b/drivers/media/video/omap3isp/ispvideo.c
> index d100072..be738a5 100644
> --- a/drivers/media/video/omap3isp/ispvideo.c
> +++ b/drivers/media/video/omap3isp/ispvideo.c
> @@ -95,10 +95,10 @@ static struct isp_format_info formats[] = {
> V4L2_MBUS_FMT_SRGGB12_1X12, V4L2_MBUS_FMT_SRGGB8_1X8,
> V4L2_PIX_FMT_SRGGB12, 12, },
> { V4L2_MBUS_FMT_UYVY8_1X16, V4L2_MBUS_FMT_UYVY8_1X16,
> - V4L2_MBUS_FMT_UYVY8_1X16, 0,
> + V4L2_MBUS_FMT_UYVY8_1X16, 8,
> V4L2_PIX_FMT_UYVY, 16, },
> { V4L2_MBUS_FMT_YUYV8_1X16, V4L2_MBUS_FMT_YUYV8_1X16,
> - V4L2_MBUS_FMT_YUYV8_1X16, 0,
> + V4L2_MBUS_FMT_YUYV8_1X16, 8,
> V4L2_PIX_FMT_YUYV
[GIT PULL FOR v3.3] as3645a compilation fix
Hi Mauro, The following changes since commit d04ca8df70f0e1c3fe6ee2aeb1114b03a3a3de88: [media] cxd2820r: do not switch to DVB-T when DVB-C fails (2012-01-16 12:47:32 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/media.git omap3isp-omap3isp-stable Laurent Pinchart (1): as3645a: Fix compilation by including slab.h drivers/media/video/as3645a.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) -- 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: [git:v4l-dvb/for_v3.3] [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation
On Tuesday 17 January 2012 11:54:10 Guennadi Liakhovetski wrote: > On Tue, 17 Jan 2012, Mauro Carvalho Chehab wrote: > > Em 17-01-2012 08:16, Guennadi Liakhovetski escreveu: > > > Hi Hans > > > > > > On Tue, 17 Jan 2012, Hans Verkuil wrote: > > >> On Monday 16 January 2012 23:16:31 Guennadi Liakhovetski wrote: > > >>> On Mon, 16 Jan 2012, Mauro Carvalho Chehab wrote: > > This is an automatic generated email to let you know that the > > following patch were queued at the > > http://git.linuxtv.org/media_tree.git tree: > > > > Subject: [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT > > documentation Author: Hans Verkuil > > Date:Wed Jan 11 07:37:54 2012 -0300 > > >>> > > >>> [snip] > > >>> > > diff --git a/Documentation/DocBook/media/v4l/vidioc-g-output.xml > > b/Documentation/DocBook/media/v4l/vidioc-g-output.xml index > > fd45f1c..4533068 100644 > > --- a/Documentation/DocBook/media/v4l/vidioc-g-output.xml > > +++ b/Documentation/DocBook/media/v4l/vidioc-g-output.xml > > @@ -61,8 +61,9 @@ desired output in an integer and call the > > > > VIDIOC_S_OUTPUT ioctl with a pointer to this > > integer. Side effects are possible. For example outputs may support > > different video standards, so the driver may implicitly switch the > > current > > > > -standard. It is good practice to select an output before querying > > or -negotiating any other parameters. > > +standard. > > +standard. Because of these possible side effects applications > > +must select an output before querying or negotiating any other > > parameters. > > >>> > > >>> something seems to be wrong here. > > >> > > >> Hi Guennadi! > > >> > > >> What's wrong here? I've no idea what you mean. > > >> > > +standard. > > +standard. Because of these possible side effects applications > > > > > > doesn't seem to make much sense? > > > > Are you referring to grammar? > > Sorry, am I being blind? The above seems to produce > > > different video standards, so the driver may implicitly switch the > current standard. standard. Because of these possible side effects > applications > > > i.e., double "standard." - one too many. LOL! You are right, and I completely missed that :-) I'm the one that's blind. Mauro, can you fix this? Thanks, Hans > > Thanks > Guennadi > > > I think that a comma is missing there [1]: > > Because of these possible side effects, applications > > must select an output before querying or negotiating any other > > parameters. > > > > IMO, reverting the order of the explanation clause is semantically > > better, as it bolds the need to select an output, and put the phrase at > > the > > > > cause-effect order: > > Applications must select an output before querying or negotiating > > any other parameters, because of these possible side effects. > > > > But this is really a matter of choice. In any case, except for the > > comma, that makes sense for me. > > > > [1] Rule 4 of http://grammar.ccc.commnet.edu/grammar/commas.htm > > > > > > Regards, > > Mauro > > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ > -- > 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: White Balance Temperature
Hi Aurel, On Sunday 15 January 2012 21:25:53 Aurel wrote: > Laurent Pinchart ideasonboard.com> writes: > > On Sunday 15 January 2012 11:16:30 Aurel wrote: > > > Hi there > > > > > > my "Live! Cam Socialize HD VF0610", Device ID: 041e:4080, Driver: > > > uvcvideo is running perfectly on Fedora 16 Linux, except one thing: > > > When I try to switch on "White Balance Temperature, Auto" or just try > > > to change "White Balance Temperature" slider I get a failure message > > > and it won't work. All other controls, like contrast, gamma, etc. are > > > working. "v4l2-ctl -d 1 --set-ctrl=white_balance_temperature_auto=1" > > > produces an error message: > > > "VIDIOC_S_CTRL: failed: Input/output error > > > white_balance_temperature_auto: Input/output error" > > > > > > As soon as I boot Windows (inside Linux out of a Virtual Box), start > > > the camera there and go back to Linux, I am able to adjust and switch > > > on the White Balance things in Linux. > > > "v4l2-ctl -d 1 --set-ctrl=white_balance_temperature_auto=1" working > > > fine after running the camera in Windows. > > > > > > Everytime I switch off my computer or disconnect the camera, I have to > > > run the camera in Windows again, bevor I can adjust White Balance in > > > Linux. > > > > > > What can I do to get White Balance controls working in Linux, without > > > having to run the camera in Windows every time? > > > Is there a special command I have to send to the camera for > > > initializing or so? > > > > Not that I know of. If you use the stock UVC driver in Windows, without > > having installed a custom driver for your device, that's quite unlikely. > > > > Could you dump the value of all controls in Linux before and after > > booting Windows ? [snip] > Here are the values before... [snip] >saturation (int): min=0 max=255 step=1 default=128 value=128 > gamma (int): min=72 max=500 step=1 default=100 value=128 [snip] > ...and after Windows... [snip] >saturation (int): min=0 max=255 step=1 default=128 value=137 > gamma (int): min=72 max=500 step=1 default=100 value=100 [snip] > ...not so much difference. Indeed, only saturation and gamma differ. Have you tried setting saturation to 137 and gamma to 100 in Linux (without booting Windows) and then changing the white balance controls ? I don't expect that to make any difference, but just in case... > And may be I didn't tell right before: I did install the original Live! > Central 3 software by Creative in Windows. All I do is just start it and > switch off again. Ah, that can play a role. The software might configure the camera when you plug it in using vendor-specific requests or extension units. Sniffing USB traffic in Windows could help verifying that. > The interesting thing here is the "exposure_absolute" value. Much too high, > but can also be changed before Windows. -- 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: [git:v4l-dvb/for_v3.3] [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation
On Tue, 17 Jan 2012, Mauro Carvalho Chehab wrote: > Em 17-01-2012 08:16, Guennadi Liakhovetski escreveu: > > Hi Hans > > > > On Tue, 17 Jan 2012, Hans Verkuil wrote: > > > >> On Monday 16 January 2012 23:16:31 Guennadi Liakhovetski wrote: > >>> On Mon, 16 Jan 2012, Mauro Carvalho Chehab wrote: > This is an automatic generated email to let you know that the following > patch were queued at the http://git.linuxtv.org/media_tree.git tree: > > Subject: [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation > Author: Hans Verkuil > Date:Wed Jan 11 07:37:54 2012 -0300 > >>> > >>> [snip] > >>> > diff --git a/Documentation/DocBook/media/v4l/vidioc-g-output.xml > b/Documentation/DocBook/media/v4l/vidioc-g-output.xml index > fd45f1c..4533068 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-g-output.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-g-output.xml > @@ -61,8 +61,9 @@ desired output in an integer and call the > > VIDIOC_S_OUTPUT ioctl with a pointer to this > integer. Side effects are possible. For example outputs may support > different video standards, so the driver may implicitly switch the > current > > -standard. It is good practice to select an output before querying or > -negotiating any other parameters. > +standard. > +standard. Because of these possible side effects applications > +must select an output before querying or negotiating any other > parameters. > >>> > >>> something seems to be wrong here. > >> > >> Hi Guennadi! > >> > >> What's wrong here? I've no idea what you mean. > > > +standard. > +standard. Because of these possible side effects applications > > > > doesn't seem to make much sense? > > Are you referring to grammar? Sorry, am I being blind? The above seems to produce different video standards, so the driver may implicitly switch the current standard. standard. Because of these possible side effects applications i.e., double "standard." - one too many. Thanks Guennadi > I think that a comma is missing there [1]: > > Because of these possible side effects, applications > must select an output before querying or negotiating any other > parameters. > > IMO, reverting the order of the explanation clause is semantically better, > as it bolds the need to select an output, and put the phrase at the > cause-effect order: > > Applications must select an output before querying or negotiating > any other parameters, because of these possible side effects. > > But this is really a matter of choice. In any case, except for the > comma, that makes sense for me. > > [1] Rule 4 of http://grammar.ccc.commnet.edu/grammar/commas.htm > > > Regards, > Mauro > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [git:v4l-dvb/for_v3.3] [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation
Em 17-01-2012 08:16, Guennadi Liakhovetski escreveu: > Hi Hans > > On Tue, 17 Jan 2012, Hans Verkuil wrote: > >> On Monday 16 January 2012 23:16:31 Guennadi Liakhovetski wrote: >>> On Mon, 16 Jan 2012, Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation Author: Hans Verkuil Date:Wed Jan 11 07:37:54 2012 -0300 >>> >>> [snip] >>> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-output.xml b/Documentation/DocBook/media/v4l/vidioc-g-output.xml index fd45f1c..4533068 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-output.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-output.xml @@ -61,8 +61,9 @@ desired output in an integer and call the VIDIOC_S_OUTPUT ioctl with a pointer to this integer. Side effects are possible. For example outputs may support different video standards, so the driver may implicitly switch the current -standard. It is good practice to select an output before querying or -negotiating any other parameters. +standard. +standard. Because of these possible side effects applications +must select an output before querying or negotiating any other parameters. >>> >>> something seems to be wrong here. >> >> Hi Guennadi! >> >> What's wrong here? I've no idea what you mean. > +standard. +standard. Because of these possible side effects applications > > doesn't seem to make much sense? Are you referring to grammar? I think that a comma is missing there [1]: Because of these possible side effects, applications must select an output before querying or negotiating any other parameters. IMO, reverting the order of the explanation clause is semantically better, as it bolds the need to select an output, and put the phrase at the cause-effect order: Applications must select an output before querying or negotiating any other parameters, because of these possible side effects. But this is really a matter of choice. In any case, except for the comma, that makes sense for me. [1] Rule 4 of http://grammar.ccc.commnet.edu/grammar/commas.htm Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.3] [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation
Hi Hans On Tue, 17 Jan 2012, Hans Verkuil wrote: > On Monday 16 January 2012 23:16:31 Guennadi Liakhovetski wrote: > > On Mon, 16 Jan 2012, Mauro Carvalho Chehab wrote: > > > This is an automatic generated email to let you know that the following > > > patch were queued at the http://git.linuxtv.org/media_tree.git tree: > > > > > > Subject: [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation > > > Author: Hans Verkuil > > > Date:Wed Jan 11 07:37:54 2012 -0300 > > > > [snip] > > > > > diff --git a/Documentation/DocBook/media/v4l/vidioc-g-output.xml > > > b/Documentation/DocBook/media/v4l/vidioc-g-output.xml index > > > fd45f1c..4533068 100644 > > > --- a/Documentation/DocBook/media/v4l/vidioc-g-output.xml > > > +++ b/Documentation/DocBook/media/v4l/vidioc-g-output.xml > > > @@ -61,8 +61,9 @@ desired output in an integer and call the > > > > > > VIDIOC_S_OUTPUT ioctl with a pointer to this > > > integer. Side effects are possible. For example outputs may support > > > different video standards, so the driver may implicitly switch the > > > current > > > > > > -standard. It is good practice to select an output before querying or > > > -negotiating any other parameters. > > > +standard. > > > +standard. Because of these possible side effects applications > > > +must select an output before querying or negotiating any other > > > parameters. > > > > something seems to be wrong here. > > Hi Guennadi! > > What's wrong here? I've no idea what you mean. > > > +standard. > > > +standard. Because of these possible side effects applications doesn't seem to make much sense? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: [git:v4l-dvb/for_v3.3] [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation
On Monday 16 January 2012 23:16:31 Guennadi Liakhovetski wrote: > On Mon, 16 Jan 2012, Mauro Carvalho Chehab wrote: > > This is an automatic generated email to let you know that the following > > patch were queued at the http://git.linuxtv.org/media_tree.git tree: > > > > Subject: [media] V4L2 Spec: improve the G/S_INPUT/OUTPUT documentation > > Author: Hans Verkuil > > Date:Wed Jan 11 07:37:54 2012 -0300 > > [snip] > > > diff --git a/Documentation/DocBook/media/v4l/vidioc-g-output.xml > > b/Documentation/DocBook/media/v4l/vidioc-g-output.xml index > > fd45f1c..4533068 100644 > > --- a/Documentation/DocBook/media/v4l/vidioc-g-output.xml > > +++ b/Documentation/DocBook/media/v4l/vidioc-g-output.xml > > @@ -61,8 +61,9 @@ desired output in an integer and call the > > > > VIDIOC_S_OUTPUT ioctl with a pointer to this > > integer. Side effects are possible. For example outputs may support > > different video standards, so the driver may implicitly switch the > > current > > > > -standard. It is good practice to select an output before querying or > > -negotiating any other parameters. > > +standard. > > +standard. Because of these possible side effects applications > > +must select an output before querying or negotiating any other > > parameters. > > something seems to be wrong here. Hi Guennadi! What's wrong here? I've no idea what you mean. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365
Hi Manjunath,
On Tuesday 17 January 2012 07:59:35 Hadli, Manjunath wrote:
> On Mon, Jan 02, 2012 at 16:51:06, Laurent Pinchart wrote:
> > On Wednesday 28 December 2011 12:16:27 Sakari Ailus wrote:
> > > On Wed, Dec 21, 2011 at 11:23:26PM +0100, Laurent Pinchart wrote:
> > > > On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote:
> > > > > On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
> > > > > > On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
> > > > > > > On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
> > > > > > > > On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
> > > > > > > > > add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer
> > > > > > > > > format frames compressed by A-LAW alogorithm.
> > > > > > > > > add V4L2_PIX_FMT_UV8 to represent storage of C (UV
> > > > > > > > > interleved) only.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Manjunath Hadli
> > > > > > > > > Cc: Laurent Pinchart
> > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > include/linux/videodev2.h |6 ++
> > > > > > > > > 1 files changed, 6 insertions(+), 0 deletions(-)
> > > > > > > >
> > > > > > > > Could you please also document these formats in
> > > > > > > > Documentation/DocBook/media/v4l ?
> > > > > > >
> > > > > > > I will. Sorry to have missed that out.
> > > > > > >
> > > > > > > > > diff --git a/include/linux/videodev2.h
> > > > > > > > > b/include/linux/videodev2.h index 4b752d5..969112d 100644
> > > > > > > > > --- a/include/linux/videodev2.h
> > > > > > > > > +++ b/include/linux/videodev2.h
> > > > > > > > > @@ -338,6 +338,9 @@ struct v4l2_pix_format {
> > > > > > > > >
> > > > > > > > > #define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1',
> > > > > > > > > '2') /* 8 YUV
> > > > > > > > >
> > > > > > > > > 4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
> > > > > > > > > v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines
> > > > > > > > > y, 1 line uv interleaved */
> > > > > > > > >
> > > > > > > > > +/* Chrominance formats */
> > > > > > > > > +#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', '
> > > > > > > > > ') /* 8 UV 4:4 */ +
> > > > > > > > >
> > > > > > > > > /* two planes -- one Y, one Cr + Cb interleaved */
> > > > > > > > > #define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1',
> > > > > > > > > '2') /* 12 Y/CbCr
> > > > > > > > >
> > > > > > > > > 4:2:0 */ #define V4L2_PIX_FMT_NV21v4l2_fourcc('N',
> > > > > > > > > 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@
> > > > > > > > > struct v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12
> > > > > > > > > v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /*
> > > > > > > > > 10bit raw bayer DPCM compressed to 8 bits */ #define
> > > > > > > > > V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
> > > > > > > > > + /* 10bit raw bayer a-law compressed to 8 bits */ #define
> > > > > > > > > +V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
> > > > > > > > > +
> > > > > > > >
> > > > > > > > That's not very future-proof, how would you describe
> > > > > > > > SGBRG10ALAW8 for instance ?
> > > > > > > >
> > > > > > > > Maybe it's time to standardize FOURCCs for Bayer new
> > > > > > > > formats. We have 4 characters, we could start with 'B' to
> > > > > > > > denote Bayer, followed by one character for the order, one
> > > > > > > > for the compression, and one for the number of bits.
> > > > > > >
> > > > > > > I agree.
> > > > > > > May be ('B', 'G', 'A', '8') is fine for the above?
> > > > > >
> > > > > > We need to describe at last BGGR, GBRG, GRBG and RGGB. We could
> > > > > > use 'B', 'g', 'G' and 'R' respectively for the second character.
> > > > > > The third character would be 'A' for A-law and 'D' for DPCM, and
> > > > > > the fourth character could describe the bus width in bits from 0
> > > > > > to 15 with '0' - '9', 'A' - 'F'. However, I suspect that we will
> > > > > > need 16-bit wide busses for raw Bayer at some point, and a 0
> > > > > > width is definitely not useful. We could thus offset the width by
> > > > > > some value.
> > > > > >
> > > > > > This is just a preliminary idea, I'm open to suggestions.
> > > > >
> > > > > I think it is a very good suggestion that we can go with.
> > > > > B : BGGR
> > > > > g : GBRG
> > > > > G : GRBG
> > > > > R : RGGB
> > > > >
> > > > > and 0-F can signify 1-16.
> > > >
> > > > Hans, Guennadi, Sakari, any opinion on that as well ?
> > >
> > > I think four letters simply aren't enough to universally describe a
> > > media bus format in a human-readable way. We can aim to that, but we
> > > will have to make compromises.
> > >
> > > For example, DPCM compressed format has two important parameters
> > > beyond pixel order and the colour space, the uncompressed depth and
> > > the compressed depth. Typically one doesn't compress the data too
> > > much, but things like
> > > 10-to-6 bits are well possible.
> > >
> > > Could we us
PULL request: remove superfluous DTV_CMDs
Hi Mauro I fixed a warning caused by a commit made a long time ago in dvb_frontend.c . Thanks to Dan Carpenter for pointing this one out. - The following changes since commit 1e73fa5d56333230854ae9460579eb2fcee8af02: Mauro Carvalho Chehab (1): [media] stb6100: Properly retrieve symbol rate are available in the git repository at: http://linuxtv.org/git/pb/media_tree.git staging/for_v3.3 Patrick Boettcher (1): [media] DVB-CORE: remove superfluous DTV_CMDs drivers/media/dvb/dvb-core/dvb_frontend.c | 19 --- 1 files changed, 0 insertions(+), 19 deletions(-) best regards, -- Patrick Boettcher Kernel Labs Inc. http://www.kernellabs.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] s5p-fimc: Remove linux/version.h include from fimc-mdevice.c
Signed-off-by: Sachin Kamat --- drivers/media/video/s5p-fimc/fimc-mdevice.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/s5p-fimc/fimc-mdevice.c b/drivers/media/video/s5p-fimc/fimc-mdevice.c index 615c862..8ea4ee1 100644 --- a/drivers/media/video/s5p-fimc/fimc-mdevice.c +++ b/drivers/media/video/s5p-fimc/fimc-mdevice.c @@ -21,7 +21,6 @@ #include #include #include -#include #include #include -- 1.7.4.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: V4L/DVB (12892): DVB-API: add support for ISDB-T and ISDB-Tsb (version 5.1)
On Friday 13 January 2012 13:37:57 Dan Carpenter wrote: > Hello Patrick Boettcher, > > I know this patch is really old but I was hoping you still might be > able to take a look at it. > > The patch b6e760f30975: "V4L/DVB (12892): DVB-API: add support for > ISDB-T and ISDB-Tsb (version 5.1)" from Aug 3, 2009, leads to the > following warning: > drivers/media/dvb/dvb-core/dvb_frontend.c:993:9: warning: Initializer > entry defined twice > drivers/media/dvb/dvb-core/dvb_frontend.c:1012:9: also defined > here How does this thing has lived such a long time without being noticed by anyone? Very strange. Of course this is wrong and it should be fixed by removing the second section. IOW, we should keep the section with the 1s. > drivers/media/dvb/dvb-core/dvb_frontend.c > > + _DTV_CMD(DTV_ISDBT_PARTIAL_RECEPTION, 1, 0), > + _DTV_CMD(DTV_ISDBT_SOUND_BROADCASTING, 1, 0), > + _DTV_CMD(DTV_ISDBT_SB_SUBCHANNEL_ID, 1, 0), > + _DTV_CMD(DTV_ISDBT_SB_SEGMENT_IDX, 1, 0), > + _DTV_CMD(DTV_ISDBT_SB_SEGMENT_COUNT, 1, 0), > + _DTV_CMD(DTV_ISDBT_LAYERA_FEC, 1, 0), > + _DTV_CMD(DTV_ISDBT_LAYERA_MODULATION, 1, 0), > + _DTV_CMD(DTV_ISDBT_LAYERA_SEGMENT_COUNT, 1, 0), > + _DTV_CMD(DTV_ISDBT_LAYERA_TIME_INTERLEAVING, 1, 0), > + _DTV_CMD(DTV_ISDBT_LAYERB_FEC, 1, 0), > + _DTV_CMD(DTV_ISDBT_LAYERB_MODULATION, 1, 0), > + _DTV_CMD(DTV_ISDBT_LAYERB_SEGMENT_COUNT, 1, 0), > + _DTV_CMD(DTV_ISDBT_LAYERB_TIME_INTERLEAVING, 1, 0), > + _DTV_CMD(DTV_ISDBT_LAYERC_FEC, 1, 0), > + _DTV_CMD(DTV_ISDBT_LAYERC_MODULATION, 1, 0), > + _DTV_CMD(DTV_ISDBT_LAYERC_SEGMENT_COUNT, 1, 0), > + _DTV_CMD(DTV_ISDBT_LAYERC_TIME_INTERLEAVING, 1, 0), I prepared a patch for this in my repo. I will send a pull-request right away. Thanks for pointing this out. regards, -- Patrick. -- 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 linux/version.h include from s5p_mfc.c
Signed-off-by: Sachin Kamat --- drivers/media/video/s5p-mfc/s5p_mfc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/s5p-mfc/s5p_mfc.c b/drivers/media/video/s5p-mfc/s5p_mfc.c index e43e128..ec7f000 100644 --- a/drivers/media/video/s5p-mfc/s5p_mfc.c +++ b/drivers/media/video/s5p-mfc/s5p_mfc.c @@ -18,7 +18,6 @@ #include #include #include -#include #include #include #include -- 1.7.4.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: v4l-utils migrated to autotools
Hi, On 01/15/2012 10:37 PM, Gregor Jasny wrote: Hello, I'm Gregor the Debian (and thus Ubuntu) Maintainer of v4l-utils. I took the challenge to convert the Makefile based build system into an autotools one. This weekend I polished the last bits and submitted my changes. If you build v4l-utils from source, please clean your tree via "git clean" after the pull. Then make sure you have autotools, libtool and pkg-config installed. Bootstrap the autotools environment by calling "autoreconf -vfi". The rest is the usual configure&& make&& make install. Good work! And many thanks for working on this. Regards, Hans -- 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
