Re: [PATCH] Fix to qt1010 tuner frequency selection (media/dvb)

2011-10-19 Thread Jyrki Kuoppala 

I think my problem frequency has also been at the later spot. It is possible 
there is something more complicated going on at 474 MHz - so based on your 
testing, it's best to apply just the latter change, at least for now.

Jyrki



+else if (freq<   54600) rd[15].val = 0xd6; /* 546 MHz */

+else if (freq<   54600) rd[15].val = 0xd6; /* 546 MHz */


20.10.2011 00:06, Carlos Corbacho kirjoitti:

Jyrki,

So after a bit more testing...

[...]


/* 22 */
if  (freq<   45000) rd[15].val = 0xd0; /* 450 MHz
*/

-else if (freq<   48200) rd[15].val = 0xd1; /* 482 MHz */
+else if (freq<   48200) rd[15].val = 0xd2; /* 482 MHz */

This change isn't so good.

With this change, I can no longer tune to channel 21 (474 MHz). If I revert it
back to 0xd1, it's fine.

[...]


else if (freq<   51400) rd[15].val = 0xd4; /* 514 MHz
*/

-else if (freq<   54600) rd[15].val = 0xd7; /* 546 MHz */
+else if (freq<   54600) rd[15].val = 0xd6; /* 546 MHz */
+else if (freq<   57800) rd[15].val = 0xd8; /* 578 MHz */

(This change is still good though, as this does allow me to now tune to the
BBC channels in this range).

-Carlos


--
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: Staging questions: WAS Re: [PATCH 0/7] Staging submission: PCTV 74e drivers and some cleanup

2011-10-19 Thread Mauro Carvalho Chehab 
Em 19-10-2011 11:57, Devin Heitmueller escreveu:
> Hi Patrick,
> 
> On Wed, Oct 19, 2011 at 8:36 AM, Patrick Dickey  wrote:
>> I'm posting this question under this thread because the subject pertains
>> to the question (in that I'm asking about staging and about the PCTV 80e
>> drivers).
> 
> You should definitely be looking at the "as102" thread that is
> currently going on this mailing list.  Piotr is actually going through
> the same process as you are (he is working on upstreaming the as102
> driver from a kernellabs.com tree).  He made some pretty common
> mistakes (all perfectly understandable), and your reading the thread
> might help you avoid them (and having to redo your patch series).
> 
>> I started cleaning up the drx39xx* drivers for the PCTV-80e and have
>> them in a github repository. Ultimately I want to send a pull request,
>> so other people can finish the cleaning (as I'm not comfortable with
>> pulling out the #ifdef statements myself).
> 
> You should definitely ask Mauro how he expects to do a staging driver
> for a demodulator before you do any further work.  The staging tree
> works well for bridge drivers, but demod drivers such as the drx
> require code in the bridge driver (the em28xx in this case), so it's
> not clear how you would do staging for a product where the bridge
> driver isn't in staging as well.  The answer to that question will
> likely guide you in how to get the driver into staging.

Ah yes, good point. Well, just submit it as if it should be added at
the right place, but putting the Kconfig changes in separate. If this
driver is not that different than the other drx drivers, I may try to
find some time to fix it on the same way.

You may also take a look at the history for the drx-k merging patches.
I basically wrote a few small perl scripts to correct coding style, and
a few manual work.

> 
> If you have specific questions regarding anything you see in the
> driver, let me know.  I don't have much time nowadays but will find
> the time if you ask concise questions.
> 
> Good luck.  It will be great to finally see this merged upstream.
> 
> Devin
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: kernel OOPS when releasing usb webcam (random)

2011-10-19 Thread Mauro Carvalho Chehab 
Em 19-10-2011 18:21, David Rientjes escreveu:
> On Tue, 18 Oct 2011, David Rientjes wrote:
> 
>> Guennadi or Mauro, how is this going to Linus?  It sounds like 3.1 
>> material since we've received at least a couple of reports of this in the 
>> past week.
>>
> 
> This fix is now in Linus' tree at e58fced201ad ("[media] videodev: fix a 
> NULL pointer dereference in v4l2_device_release()") for 3.1.

Yes, I sent it upstream earlier today. Btw, Greg also picked it for stable.
It should be there for the next 3.0.x kernel as well.

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: [PATCH] Fix to qt1010 tuner frequency selection (media/dvb)

2011-10-19 Thread Carlos Corbacho 
Jyrki,

So after a bit more testing...

[...]

> >>/* 22 */
> >>if  (freq<  45000) rd[15].val = 0xd0; /* 450 MHz
> >>*/
> >> 
> >> -else if (freq<  48200) rd[15].val = 0xd1; /* 482 MHz */
> >> +else if (freq<  48200) rd[15].val = 0xd2; /* 482 MHz */

This change isn't so good.

With this change, I can no longer tune to channel 21 (474 MHz). If I revert it 
back to 0xd1, it's fine.

[...]

> >> 
> >>else if (freq<  51400) rd[15].val = 0xd4; /* 514 MHz
> >>*/
> >> 
> >> -else if (freq<  54600) rd[15].val = 0xd7; /* 546 MHz */
> >> +else if (freq<  54600) rd[15].val = 0xd6; /* 546 MHz */
> >> +else if (freq<  57800) rd[15].val = 0xd8; /* 578 MHz */

(This change is still good though, as this does allow me to now tune to the 
BBC channels in this range).

-Carlos
--
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] subdevice PM: .s_power() deprecation?

2011-10-19 Thread Sylwester Nawrocki 
On 10/18/2011 11:38 PM, Guennadi Liakhovetski wrote:
> On Tue, 18 Oct 2011, Sylwester Nawrocki wrote:
>> On 10/18/2011 01:07 AM, Laurent Pinchart wrote:
>>> On Monday 17 October 2011 23:26:28 Sylwester Nawrocki wrote:
 On 10/17/2011 05:23 PM, Guennadi Liakhovetski wrote:
> On Mon, 17 Oct 2011, Sylwester Nawrocki wrote:
> 
> [snip]
> 
>> The bridge driver could also choose to keep the sensor powered on,
>> whenever it sees appropriate, to avoid re-enabling the sensor to often.
>
> On what basis would the bridge driver make these decisions? How would it
> know in advance, when it'll have to re-enable the subdev next time?

 Re-enabling by allowing a subdev driver to entirely control the power
 state. The sensor might implement "lowest power consumption" policy, while
 the user might want "highest performance".
>>>
>>> Exactly, that's a policy decision. Would PM QoS help here ?
>>
>> Thanks for reminding about PM QoS. I didn't pay much attention to it but it
>> indeed appears to be a good fit for this sort of tasks.
> 
> But you anyway have to decide - who will implement those PM QoS callbacks?
> The bridge and then decide whether or not to call subdev's .s_power(), or
> the subdev driver itself? I think, the latter, in which case .s_power()
> remain unused.

Agreed. With some hints on how to handle power supply directly in the subdev
driver we should be able to do without s_power() at the "edge" subdevs.

> 
>> We would possibly just need to think of parameters which could be associated 
>> with
>> video, e.g. video_latency, etc. ?...
>>
>> I'm curious whether the whole power handling could be contained within a 
>> subdev
>> driver, most likely it could be done for subdevs exposing a devnode.
>>
>>>
 I'm referring only to camera sensor subdevs, as I don't have much 
 experience
 with other ones.

 Also there are some devices where you want to model power control
 explicitly, and it is critical to overall system operation. The s5p-tv
 driver is one example of these. The host driver knows exactly how the
 power state of its subdevs should be handled.
>>>
>>> The host probably knows about how to handle the power state of its internal
>>> subdevs, but what about external ones ?
>>
>> In this particular example there is no external subdevs associated with the 
>> host.
>>
>> But we don't seem to have separate callbacks for internal and external 
>> subdevs..
>> So removing s_power() puts the above described sort of drivers in trouble.
> 
> I understand what you're saying, but can you give us a specific example,
> when a subdev driver (your SoC internal subdev, that is) doesn't have a
> way to react to an event itself and only the bridge driver gets called
> into at that time? Something like an interrupt or an internal timer or
> some other internal event?

1. The S5P SoC video output subsystem (http://lwn.net/Articles/449661) comprises
 of multiple logical blocks, like Video Processor, Mixer, HDMI, HDMI PHY, SD TV 
Out.
 For instance the master video clock is during normal operation derived from
 (synchronized to, with PLL,) the HDMI-PHY output clock. The host driver can
 switch to this clock only when the HDMI-PHY (subdev) power and clocks are 
enabled.
 And it should be done before .s_stream(), to do some H/W configuration earlier
 in the pipeline, before streaming is enabled. Perhaps Tomasz could give some
 further explanation of what the s_power() op does and why in the driver. 
 
2. In some of our camera pipeline setups - "Sensor - MIPI-CSI receiver - 
host/DMA",
 the sensor won't boot properly if all MIPI-CSI regulators aren't enabled. So 
the  
 MIPI-CSI receiver must always be powered on before the sensor. With the subdevs
 doing their own magic wrt to power control the situation is getting slightly
 out of control. 
 
> 
>> I guess we all agree the power requirements of external subdevs are generally
>> unknown to the hosts.
>>
>> For these it might make lot of sense to let the subdev driver handle the 
>> device
>> power supplies on basis of requests like, s_ctrl, s_stream, etc.
> 
> Yes, right, so, most "external" (sensor, decoder,...) subdev drivers
> should never need to implement .s_power(), regardless of whether we decide
> to keep it or not. Well, ok, no, put it differently - in those drivers
> .s_power() should only really be called during system-wide suspend /
> resume.

Yes, I agree with that. But before we attempt to remove .s_power() or deprecate 
it on "external" subdevs, I'd like to get solved the issue with sensor master 
clock 
provided by the bridge. As these two are closely related - the sensor 
controller 
won't boot if the clock is disabled. And there are always advantages of not 
keeping
the clock always enabled. 

> 
>> With PM QoS it could be easier to decide in the driver when a device should 
>> be
>> put in a low power state.

-- 
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsub

Re: kernel OOPS when releasing usb webcam (random)

2011-10-19 Thread David Rientjes 
On Tue, 18 Oct 2011, David Rientjes wrote:

> Guennadi or Mauro, how is this going to Linus?  It sounds like 3.1 
> material since we've received at least a couple of reports of this in the 
> past week.
> 

This fix is now in Linus' tree at e58fced201ad ("[media] videodev: fix a 
NULL pointer dereference in v4l2_device_release()") for 3.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

cron job: media_tree daily build: WARNINGS

2011-10-19 Thread Hans Verkuil 
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:Wed Oct 19 19:00:17 CEST 2011
git hash:35a912455ff5640dc410e91279b03e04045265b2
gcc version:  i686-linux-gcc (GCC) 4.6.1
host hardware:x86_64
host os:  3.0-4.slh.7-amd64

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
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-rc1-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-rc1-x86_64: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2

The 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: omap3isp: BT.656 support

2011-10-19 Thread Stefan Herbrechtsmeier 
Am 18.10.2011 15:33, schrieb Boris Todorov:
> Hi
>
> I'm trying to run OMAP + TVP5151 in BT656 mode.
>
> I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git).
> Plus the following patches:
>
> TVP5151:
> https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150
>
> The latest RFC patches for BT656 support:
>
> Enrico Butera (2):
>   omap3isp: ispvideo: export isp_video_mbus_to_pix
>   omap3isp: ispccdc: configure CCDC registers and add BT656 support
>
> Javier Martinez Canillas (1):
>   omap3isp: ccdc: Add interlaced field mode to platform data
>
>
> I'm able to configure with media-ctl:
>
> media-ctl -v -r -l '"tvp5150 3-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3
> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
> media-ctl -v --set-format '"tvp5150 3-005c":0 [UYVY2X8 720x525]'
> media-ctl -v --set-format '"OMAP3 ISP CCDC":0 [UYVY2X8 720x525]'
> media-ctl -v --set-format '"OMAP3 ISP CCDC":1 [UYVY2X8 720x525]'
>
> But
> ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4
>
> sleeps after
> ...
> Buffer 1 mapped at address 0x4021d000.
> length: 756000 offset: 1515520
> Buffer 2 mapped at address 0x402d6000.
> length: 756000 offset: 2273280
> Buffer 3 mapped at address 0x4038f000.
>
> Anyone with the same issue??? This happens with every other v4l test app I 
> used.
I had the same issue.

Make sure that you disable the xclk when you remove your sensor driver.

isp->platform_cb.set_xclk(isp, 0, ISP_XCLK_A)

Regards,
Stefan

--
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: omap3isp: BT.656 support

2011-10-19 Thread Boris Todorov 
On Wed, Oct 19, 2011 at 4:06 PM, Boris Todorov
 wrote:
> On Wed, Oct 19, 2011 at 3:40 PM, Enrico  wrote:
>> On Wed, Oct 19, 2011 at 11:03 AM, Boris Todorov
>>  wrote:
>>> Here is my log:
>>> [   24.683685] omap3isp omap3isp: -CCDC Register 
>>> dump-
>>> [   24.683685] omap3isp omap3isp: ###CCDC PCR=0x
>>> [   24.683685] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80
>>> [   24.683715] omap3isp omap3isp: ###CCDC HD_VD_WID=0x
>>> [   24.683715] omap3isp omap3isp: ###CCDC PIX_LINES=0x
>>> [   24.683746] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f
>>> [   24.683746] omap3isp omap3isp: ###CCDC VERT_START=0x
>>> [   24.683746] omap3isp omap3isp: ###CCDC VERT_LINES=0x0105
>>> [   24.683776] omap3isp omap3isp: ###CCDC CULLING=0x00ff
>>> [   24.683776] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0
>>> [   24.683776] omap3isp omap3isp: ###CCDC SDOFST=0x0249
>>> [   24.683807] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000
>>> [   24.683807] omap3isp omap3isp: ###CCDC CLAMP=0x0010
>>> [   24.683807] omap3isp omap3isp: ###CCDC DCSUB=0x
>>> [   24.683837] omap3isp omap3isp: ###CCDC COLPTN=0x
>>> [   24.683837] omap3isp omap3isp: ###CCDC BLKCMP=0x
>>> [   24.683837] omap3isp omap3isp: ###CCDC FPC=0x
>>> [   24.683868] omap3isp omap3isp: ###CCDC FPC_ADDR=0x
>>> [   24.683868] omap3isp omap3isp: ###CCDC VDINT=0x0104
>>> [   24.683868] omap3isp omap3isp: ###CCDC ALAW=0x0004
>>> [   24.683898] omap3isp omap3isp: ###CCDC REC656IF=0x0003
>>> [   24.683898] omap3isp omap3isp: ###CCDC CFG=0x8800
>>> [   24.683898] omap3isp omap3isp: ###CCDC FMTCFG=0x6000
>>> [   24.683929] omap3isp omap3isp: ###CCDC FMT_HORZ=0x02d0
>>> [   24.683929] omap3isp omap3isp: ###CCDC FMT_VERT=0x020d
>>> [   24.683929] omap3isp omap3isp: ###CCDC PRGEVEN0=0x
>>> [   24.683959] omap3isp omap3isp: ###CCDC PRGEVEN1=0x
>>> [   24.683959] omap3isp omap3isp: ###CCDC PRGODD0=0x
>>> [   24.683959] omap3isp omap3isp: ###CCDC PRGODD1=0x
>>> [   24.683990] omap3isp omap3isp: ###CCDC VP_OUT=0x04182d00
>>> [   24.683990] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600
>>> [   24.683990] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x
>>> [   24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x
>>> [   24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x
>>> [   24.684051] omap3isp omap3isp: 
>>> 
>>>
>>> This is with:
>>>
>>> .data_lane_shift = 0,
>>> .clk_pol             = 0,
>>> .hs_pol             = 0,
>>> .vs_pol             = 0,
>>> .data_pol              = 0,
>>> .fldmode           = 1,
>>> .bt656               = 1,
>>>
>>> and the above mentioned media-ctl settings
>>
>> From a quick look It seems ok (apart ALAW that maybe should be 0).
>>
>> One thing to check: before loading omap3-isp kernel module you must
>> manually load iommu2, if you don't it will automatically load only
>> iommu and it will not work
>>
>> Enrico
>>
>
> When I started omap3-isp was embedded in kernel and my /dev/media0 was
> missing. Making it module resolved this issue.
> iommu2 is still embedded...
> will try with module now
>

I loaded the modules in this order:
iommu.ko -> iovmm.ko -> iommu2.ko -> omap_iommu.ko -> omap3_isp.ko

# lsmod
Module  Size  Used byNot tainted
omap3_isp 121471  0
omap_iommu  1276  0
iommu2  5118  0
iovmm  11389  1 omap3_isp
iommu  14627  3 omap3_isp,iommu2,iovmm

But it didn't solved my problem.
I just scoped PCLK and the data lines from TVP and everything looks
fine. I can see the BT.656 embedded sync information. But no ISP
irqs...
--
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

[RFCv2] Improved handling of presets

2011-10-19 Thread Hans Verkuil 
RFCv2: Improved handling of presets
===

Changes from RFCv1:

- Removed name[] in v4l2_enum_bt_timings.
- Improved the description of QUERY_DV_TIMINGS.
- Removed v4l2_query_dv_timings, instead reuse v4l2_dv_timings.
  The various 'states' of RFCv1 are now returned as error codes.
- Simplified signalling whether root permissions are required when
  setting the timings: just add a single flag to v4l2_dv_timings_cap.
- Add a section on EDID handling.



This RFC attempts to resolve the issues raised by this thread a few months ago:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg33981.html

The last post in this thread did a good job of summarizing the discussion:

http://www.mail-archive.com/linux-media@vger.kernel.org/msg34190.html

I think it is time to revisit this problem. It basically boils down to the fact
that the current preset API is too limited and somewhat awkward and I agree
with that.

Now, I really do not like the idea of creating a preset2 API. Instead I think
it is better to extend the current dv_timings API with new ioctls:

VIDIOC_QUERY_DV_TIMINGS
VIDIOC_ENUM_DV_TIMINGS
VIDIOC_DV_TIMINGS_CAP

These form a superset of the preset API and once this is in place we can
deprecate some or all of the preset ioctls and eventually remove them (say
in one or two years).

Here is the current definition of the v4l2_dv_timings struct from videodev2.h:

/* BT.656/BT.1120 timing data */
struct v4l2_bt_timings {
__u32   width;  /* width in pixels */
__u32   height; /* height in lines */
__u32   interlaced; /* Interlaced or progressive */
__u32   polarities; /* Positive or negative polarity */
__u64   pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->7425 */
__u32   hfrontporch;/* Horizpontal front porch in pixels */
__u32   hsync;  /* Horizontal Sync length in pixels */
__u32   hbackporch; /* Horizontal back porch in pixels */
__u32   vfrontporch;/* Vertical front porch in pixels */
__u32   vsync;  /* Vertical Sync length in lines */
__u32   vbackporch; /* Vertical back porch in lines */
__u32   il_vfrontporch; /* Vertical front porch for bottom field of
 * interlaced field formats
 */
__u32   il_vsync;   /* Vertical sync length for bottom field of
 * interlaced field formats
 */
__u32   il_vbackporch;  /* Vertical back porch for bottom field of
 * interlaced field formats
 */
__u32   reserved[16];
} __attribute__ ((packed));

/* Interlaced or progressive format */
#define V4L2_DV_PROGRESSIVE 0
#define V4L2_DV_INTERLACED  1

/* Polarities. If bit is not set, it is assumed to be negative polarity */
#define V4L2_DV_VSYNC_POS_POL   0x0001
#define V4L2_DV_HSYNC_POS_POL   0x0002

/* DV timings */
struct v4l2_dv_timings {
__u32 type;
union {
struct v4l2_bt_timings  bt;
__u32   reserved[32];
};
} __attribute__ ((packed));

/* Values for the type field */
#define V4L2_DV_BT_656_1120 0   /* BT.656/1120 timing type */

This API allows you to set and get all the timings details. Its current
use is to allow userspace to set non-standard timings and it is used only in
the dm646x davinci drivers at the moment.

I propose the following additions:

1) Add a standards field to v4l2_bt_timings:

__u32 standards;

   Currently I have four standards:

#define V4L2_DV_BT_STD_CEA861   (1 << 0)
#define V4L2_DV_BT_STD_DMT  (1 << 1)  /* VESA Discrete Monitor 
Timings */
#define V4L2_DV_BT_STD_CVT  (1 << 2)  /* VESA Coordinated Video 
Timings */
#define V4L2_DV_BT_STD_GTF  (1 << 3)  /* VESA Generalized Timings 
Formula */

   A particular timing can be part of 0 or more standards.
   Both CVT and GTF timings have a so-called 'reduced blanking' mode. It would 
be
   nice to represent this with a flag somewhere. I guess we need a flags field
   for that. The 'polarities' field really should have been called a 'flags' 
field.
   One option is just to rename 'polarities' to 'flags' if Mauro would agree to 
that.
   The ABI would be preserved, but applications using the polarities field 
would no
   longer compile.

   The standards field is ignored when setting timings.


2) Create a VIDIOC_ENUM_DV_TIMINGS ioctl:

struct v4l2_enum_dv_timings {
__u32 index;
__u32 reserved[3];
struct v4l2_dv_timings timings;
};

#define VIDIOC_ENUM_DV_TIMINGS _IOWR('V', XX, struct 
v4l2_enum_dv_timings)

   This ioctl enumerates over all discrete supported timings and returns their
   timings.

   The timings field can be used as an inp

Re: Staging questions: WAS Re: [PATCH 0/7] Staging submission: PCTV 74e drivers and some cleanup

2011-10-19 Thread Devin Heitmueller 
Hi Patrick,

On Wed, Oct 19, 2011 at 8:36 AM, Patrick Dickey  wrote:
> I'm posting this question under this thread because the subject pertains
> to the question (in that I'm asking about staging and about the PCTV 80e
> drivers).

You should definitely be looking at the "as102" thread that is
currently going on this mailing list.  Piotr is actually going through
the same process as you are (he is working on upstreaming the as102
driver from a kernellabs.com tree).  He made some pretty common
mistakes (all perfectly understandable), and your reading the thread
might help you avoid them (and having to redo your patch series).

> I started cleaning up the drx39xx* drivers for the PCTV-80e and have
> them in a github repository. Ultimately I want to send a pull request,
> so other people can finish the cleaning (as I'm not comfortable with
> pulling out the #ifdef statements myself).

You should definitely ask Mauro how he expects to do a staging driver
for a demodulator before you do any further work.  The staging tree
works well for bridge drivers, but demod drivers such as the drx
require code in the bridge driver (the em28xx in this case), so it's
not clear how you would do staging for a product where the bridge
driver isn't in staging as well.  The answer to that question will
likely guide you in how to get the driver into staging.

If you have specific questions regarding anything you see in the
driver, let me know.  I don't have much time nowadays but will find
the time if you ask concise questions.

Good luck.  It will be great to finally see this merged upstream.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
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 0/14] staging/media/as102: new driver submission (was Re: [PATCH 1/7] Staging submission: PCTV 74e driver (as102)

2011-10-19 Thread Piotr Chmura 



W dniu 19.10.2011 13:44, Mauro Carvalho Chehab pisze:

Em 19-10-2011 09:41, Javier Martinez Canillas escreveu:

On Tue, Oct 18, 2011 at 7:20 PM, Piotr Chmura  wrote:

On Tue, 18 Oct 2011 11:52:17 -0400
Devin Heitmueller  wrote:


On Tue, Oct 18, 2011 at 5:10 AM, Piotr Chmura  wrote:

Thanks for comments for all of you.

[PATCH 1-12/14] Following your guidelines i exported all changes from hg one by 
one. This way we will have all history in kernel tree.
I moved driver to staging/media and removed Kconfig/Makefile changes in parent 
directory in first patch.

Hello Piotr,

Not that I want to create more work for you, but it would appear that
your patches stripped off all the Signed-off-by lines for both myself
and Pierrick Hascoet (the developer from the hardware vendor).  You
have replaced them with "cc:" lines, which breaks the chain of
"Developer's Certificate of Origin".

When you take somebody else's patches, you need to preserve any
existing Signed-off-by lines, adding your own at the bottom of the
list.

In other words, the first patch should be:

Signed-off-by: Pierrick Hascoet
Signed-off-by: Devin Heitmueller
Signed-off-by: Piotr Chmura

instead of:

Signed-off-by: Piotr Chmura
Cc: Pierrick Hascoet
Cc: Devin Heitmueller

Devin

--
Devin J. Heitmueller - Kernel Labs
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

Ok, i'll resend them again.

Should I replay to every patch with something like [RESEND PATCH nn/mm]..., 
right ?

Peter

Hi Peter,

A common convention is to add the version of your patch in the subject like:

[PATCH v2 0/14] staging/media/as102: new driver submission

That way people can know that is actually a resend of a new patch-set
and not a resend of the last one.

Thanks, I'll do it this way next time.


Yes. Also, it seems that you've submitted only 12 patches of this 14 patch
series. Where are the other two missing patches?
13 and 14 were written by me, so they didn't suffer "signed-off-by" 
mistake. Do I need resend them too ?


Peter

--
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: omap3isp: BT.656 support

2011-10-19 Thread Boris Todorov 
On Wed, Oct 19, 2011 at 3:40 PM, Enrico  wrote:
> On Wed, Oct 19, 2011 at 11:03 AM, Boris Todorov
>  wrote:
>> Here is my log:
>> [   24.683685] omap3isp omap3isp: -CCDC Register 
>> dump-
>> [   24.683685] omap3isp omap3isp: ###CCDC PCR=0x
>> [   24.683685] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80
>> [   24.683715] omap3isp omap3isp: ###CCDC HD_VD_WID=0x
>> [   24.683715] omap3isp omap3isp: ###CCDC PIX_LINES=0x
>> [   24.683746] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f
>> [   24.683746] omap3isp omap3isp: ###CCDC VERT_START=0x
>> [   24.683746] omap3isp omap3isp: ###CCDC VERT_LINES=0x0105
>> [   24.683776] omap3isp omap3isp: ###CCDC CULLING=0x00ff
>> [   24.683776] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0
>> [   24.683776] omap3isp omap3isp: ###CCDC SDOFST=0x0249
>> [   24.683807] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000
>> [   24.683807] omap3isp omap3isp: ###CCDC CLAMP=0x0010
>> [   24.683807] omap3isp omap3isp: ###CCDC DCSUB=0x
>> [   24.683837] omap3isp omap3isp: ###CCDC COLPTN=0x
>> [   24.683837] omap3isp omap3isp: ###CCDC BLKCMP=0x
>> [   24.683837] omap3isp omap3isp: ###CCDC FPC=0x
>> [   24.683868] omap3isp omap3isp: ###CCDC FPC_ADDR=0x
>> [   24.683868] omap3isp omap3isp: ###CCDC VDINT=0x0104
>> [   24.683868] omap3isp omap3isp: ###CCDC ALAW=0x0004
>> [   24.683898] omap3isp omap3isp: ###CCDC REC656IF=0x0003
>> [   24.683898] omap3isp omap3isp: ###CCDC CFG=0x8800
>> [   24.683898] omap3isp omap3isp: ###CCDC FMTCFG=0x6000
>> [   24.683929] omap3isp omap3isp: ###CCDC FMT_HORZ=0x02d0
>> [   24.683929] omap3isp omap3isp: ###CCDC FMT_VERT=0x020d
>> [   24.683929] omap3isp omap3isp: ###CCDC PRGEVEN0=0x
>> [   24.683959] omap3isp omap3isp: ###CCDC PRGEVEN1=0x
>> [   24.683959] omap3isp omap3isp: ###CCDC PRGODD0=0x
>> [   24.683959] omap3isp omap3isp: ###CCDC PRGODD1=0x
>> [   24.683990] omap3isp omap3isp: ###CCDC VP_OUT=0x04182d00
>> [   24.683990] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600
>> [   24.683990] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x
>> [   24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x
>> [   24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x
>> [   24.684051] omap3isp omap3isp: 
>> 
>>
>> This is with:
>>
>> .data_lane_shift = 0,
>> .clk_pol             = 0,
>> .hs_pol             = 0,
>> .vs_pol             = 0,
>> .data_pol              = 0,
>> .fldmode           = 1,
>> .bt656               = 1,
>>
>> and the above mentioned media-ctl settings
>
> From a quick look It seems ok (apart ALAW that maybe should be 0).
>
> One thing to check: before loading omap3-isp kernel module you must
> manually load iommu2, if you don't it will automatically load only
> iommu and it will not work
>
> Enrico
>

When I started omap3-isp was embedded in kernel and my /dev/media0 was
missing. Making it module resolved this issue.
iommu2 is still embedded...
will try with module now
--
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: omap3isp: BT.656 support

2011-10-19 Thread Enrico 
On Wed, Oct 19, 2011 at 11:03 AM, Boris Todorov
 wrote:
> Here is my log:
> [   24.683685] omap3isp omap3isp: -CCDC Register dump-
> [   24.683685] omap3isp omap3isp: ###CCDC PCR=0x
> [   24.683685] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80
> [   24.683715] omap3isp omap3isp: ###CCDC HD_VD_WID=0x
> [   24.683715] omap3isp omap3isp: ###CCDC PIX_LINES=0x
> [   24.683746] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f
> [   24.683746] omap3isp omap3isp: ###CCDC VERT_START=0x
> [   24.683746] omap3isp omap3isp: ###CCDC VERT_LINES=0x0105
> [   24.683776] omap3isp omap3isp: ###CCDC CULLING=0x00ff
> [   24.683776] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0
> [   24.683776] omap3isp omap3isp: ###CCDC SDOFST=0x0249
> [   24.683807] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000
> [   24.683807] omap3isp omap3isp: ###CCDC CLAMP=0x0010
> [   24.683807] omap3isp omap3isp: ###CCDC DCSUB=0x
> [   24.683837] omap3isp omap3isp: ###CCDC COLPTN=0x
> [   24.683837] omap3isp omap3isp: ###CCDC BLKCMP=0x
> [   24.683837] omap3isp omap3isp: ###CCDC FPC=0x
> [   24.683868] omap3isp omap3isp: ###CCDC FPC_ADDR=0x
> [   24.683868] omap3isp omap3isp: ###CCDC VDINT=0x0104
> [   24.683868] omap3isp omap3isp: ###CCDC ALAW=0x0004
> [   24.683898] omap3isp omap3isp: ###CCDC REC656IF=0x0003
> [   24.683898] omap3isp omap3isp: ###CCDC CFG=0x8800
> [   24.683898] omap3isp omap3isp: ###CCDC FMTCFG=0x6000
> [   24.683929] omap3isp omap3isp: ###CCDC FMT_HORZ=0x02d0
> [   24.683929] omap3isp omap3isp: ###CCDC FMT_VERT=0x020d
> [   24.683929] omap3isp omap3isp: ###CCDC PRGEVEN0=0x
> [   24.683959] omap3isp omap3isp: ###CCDC PRGEVEN1=0x
> [   24.683959] omap3isp omap3isp: ###CCDC PRGODD0=0x
> [   24.683959] omap3isp omap3isp: ###CCDC PRGODD1=0x
> [   24.683990] omap3isp omap3isp: ###CCDC VP_OUT=0x04182d00
> [   24.683990] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600
> [   24.683990] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x
> [   24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x
> [   24.684020] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x
> [   24.684051] omap3isp omap3isp: 
>
> This is with:
>
> .data_lane_shift = 0,
> .clk_pol             = 0,
> .hs_pol             = 0,
> .vs_pol             = 0,
> .data_pol              = 0,
> .fldmode           = 1,
> .bt656               = 1,
>
> and the above mentioned media-ctl settings

>From a quick look It seems ok (apart ALAW that maybe should be 0).

One thing to check: before loading omap3-isp kernel module you must
manually load iommu2, if you don't it will automatically load only
iommu and it will not work

Enrico
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Staging questions: WAS Re: [PATCH 0/7] Staging submission: PCTV 74e drivers and some cleanup

2011-10-19 Thread Patrick Dickey 
I'm posting this question under this thread because the subject pertains
to the question (in that I'm asking about staging and about the PCTV 80e
drivers).

I started cleaning up the drx39xx* drivers for the PCTV-80e and have
them in a github repository. Ultimately I want to send a pull request,
so other people can finish the cleaning (as I'm not comfortable with
pulling out the #ifdef statements myself).

So my questions are these:

1.  If I move the drx39xx* and associated files into the staging
directory (staging/media/dvb/frontends to be exact), do I simply need to
point to staging/filename for any #include statements (specifically in
the em28xx-dvb.c and em28xx-cards.c files), or do I need to do something
else?

2.  In the Makefile for the frontends, I have the commands to make the
drivers for the drx39xx* files. Do I need to point those to the staging/
directory as well, or do I need to create Makefiles in that directory
for these files?  I ask this because on my system, I wasn't able to
"make" the files when they were in a subdirectory of frontends. I
actually had to move them to the frontends directory and transfer the
commands from the Makefile in the subdirectory to the frontends Makefile.

3.  If I submit a pull request as is right now (where these files will
go into the linux/drivers/media/dvb/frontends directory and the em28xx-*
files will point to those files), will they be pulled in, and someone
will help me to get them in the right places? Or do I need to move them
to staging, reconfigure everything, and then submit the pull request?

Thank you for any help and information, and have a great day:)
Patrick.


On 10/17/2011 05:31 PM, Greg KH wrote:
> On Sat, Oct 15, 2011 at 10:54:14PM +0200, Piotr Chmura wrote:
>> [PATCH 1/7] pull as102 driver 
>> fromhttp://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2/
>> with the only change needed to compile it in git tree[1]: usb_buffer_alloc()
>> to usb_alloc_coherent() and usb_buffer_free() to usb_free_coherent()
>>
>> [PATCH 2/7] as102: add new device nBox DVB-T Dongle
>> adds new device working on this driver
>>
>>
>> Next patches i made basing on Mauro Carvalho Chehab comments from previous 
>> pull try [2].
>>
>> [PATCH 3/7] as102: cleanup - get rid off typedefs
>> [PATCH 4/7] as102: cleanup - formatting code
>> [PATCH 5/7] as102: cleanup - set __attribute__(packed) instead of 
>> pragma(pack)
>> [PATCH 6/7] as102: cleanup - delete vim comments
>> [PATCH 7/7] as102: cleanup - get rid of unnecessary defines (WIN32, LINUX)
> 
> Mauro, care to take these and move them under your newly-created
> drivers/staging/media/ directory?
> 
> thanks,
> 
> greg k-h

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL for v3.1-rc10] media fix

2011-10-19 Thread Mauro Carvalho Chehab 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Linus,

Please pull from:
  git://linuxtv.org/mchehab/for_linus.git v4l_for_linus


For a one line fix at the V4L2 core, causing OOPSes at device release under
certain circumstances.

Thanks!
Mauro.

Latest commit at the branch: e58fced201ad6e6cb673f07499919c3b20792d94 [media] 
videodev: fix a NULL pointer dereference in v4l2_device_release()
The following changes since commit 899e3ee404961a90b828ad527573c39f0ab1:

  Linux 3.1-rc10 (2011-10-17 21:06:23 -0700)

are available in the git repository at:
  git://linuxtv.org/mchehab/for_linus.git v4l_for_linus

Antonio Ospite (1):
  [media] videodev: fix a NULL pointer dereference in v4l2_device_release()

 drivers/media/video/v4l2-dev.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOnrrNAAoJEGO08Bl/PELnIU4P/iiuqUGQnYr5NH/keGd562Cn
INrqAJ5SO9nNjgE2Eg9fuxVGriQazEJ8s+qs1wwZrpcRkrZVq2xzy7LtC/TuBdu1
c8lStlSLN2Cmo6kfkNBuNc++6X1SWh+Rdz4l5r3N8IKNQsu6XfW1idgKql3Pwavr
Afzb18vDL8rRQC9etbxzBgtOXHj6zJw+ehdKwqx9SglF1DH72afxAv7z3UhygZYp
UVJzgjVKgAyOVQfxHKzFrpNiLQpYWJtJaTpTw+t7hOp8kNZ4rXlinmy9UYsZ8Lrr
mlcWld1F2dmDuhxj0xU+QDDOhmfXnPWbLi/VWWramBq9ksNXQzxsQriI4ZKmHg5J
nnmvkrbKB+nL/51ITfXBTxYdC5zcDfEwD1m6mge3c8r4SJaRXOuHoMtVOpKAENFj
hqBRRDnb6LjnMJhdWrgFPHGs1k/T/BoduCphwZIAU2Ii7Tz0AqCnyKL4aaWHqcwp
0ECduB1Iyr1AUVnf5S7wH3m/gukasIEIGhEH2Yqr7mG1odguM5eSdHRYTLejZw+7
I2Nk71DI099Hrnt3GAer0hEzN8Pm96xMCh5kCqD2pz6H9zoijK7K7MFD0Nf2RhZV
JKy/UNwDTGAx3989G0nUu5KWmfYvvqgzZUYNgN1IZhde/YEHldIUOxY6yf3gZy9J
twUAlsCBnY/6povAvdMH
=RCnh
-END PGP SIGNATURE-
--
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 0/14] staging/media/as102: new driver submission (was Re: [PATCH 1/7] Staging submission: PCTV 74e driver (as102)

2011-10-19 Thread Mauro Carvalho Chehab 
Em 19-10-2011 09:41, Javier Martinez Canillas escreveu:
> On Tue, Oct 18, 2011 at 7:20 PM, Piotr Chmura  
> wrote:
>> On Tue, 18 Oct 2011 11:52:17 -0400
>> Devin Heitmueller  wrote:
>>
>>> On Tue, Oct 18, 2011 at 5:10 AM, Piotr Chmura  
>>> wrote:
 Thanks for comments for all of you.

 [PATCH 1-12/14] Following your guidelines i exported all changes from hg 
 one by one. This way we will have all history in kernel tree.
 I moved driver to staging/media and removed Kconfig/Makefile changes in 
 parent directory in first patch.
>>>
>>> Hello Piotr,
>>>
>>> Not that I want to create more work for you, but it would appear that
>>> your patches stripped off all the Signed-off-by lines for both myself
>>> and Pierrick Hascoet (the developer from the hardware vendor).  You
>>> have replaced them with "cc:" lines, which breaks the chain of
>>> "Developer's Certificate of Origin".
>>>
>>> When you take somebody else's patches, you need to preserve any
>>> existing Signed-off-by lines, adding your own at the bottom of the
>>> list.
>>>
>>> In other words, the first patch should be:
>>>
>>> Signed-off-by: Pierrick Hascoet 
>>> Signed-off-by: Devin Heitmueller 
>>> Signed-off-by: Piotr Chmura 
>>>
>>> instead of:
>>>
>>> Signed-off-by: Piotr Chmura 
>>> Cc: Pierrick Hascoet 
>>> Cc: Devin Heitmueller 
>>>
>>> Devin
>>>
>>> --
>>> Devin J. Heitmueller - Kernel Labs
>>> 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
>>
>> Ok, i'll resend them again.
>>
>> Should I replay to every patch with something like [RESEND PATCH nn/mm]..., 
>> right ?
>>
>> Peter
> 
> Hi Peter,
> 
> A common convention is to add the version of your patch in the subject like:
> 
> [PATCH v2 0/14] staging/media/as102: new driver submission
> 
> That way people can know that is actually a resend of a new patch-set
> and not a resend of the last one.

Yes. Also, it seems that you've submitted only 12 patches of this 14 patch
series. Where are the other two missing patches?

> 
> Anything that is between your Signed-off and the diff get trimmed by
> Git when applying a patch (that is why Devin and Pierrick Signed-off
> where stripped in first place). So you can add information about the
> changes there. Something like:
> 
> Signed-off-by: Pierrick Hascoet 
> Signed-off-by: Devin Heitmueller 
> Signed-off-by: Piotr Chmura 
> 
> 
> v2:  preserve any existing Signed-off-by lines so it doesn't get
> stripped when applied.
> 
> diff -Nur linux.clean/drivers/staging/as102/as102_drv.c
> linux.as102_initial/drivers/staging/as102/as102_drv.c
> --- linux.clean/drivers/staging/as102/as102_drv.c 1970-01-01
> 01:00:00.0 +0100
> +++ linux.as102_initial/drivers/staging/as102/as102_drv.c 2011-10-14
> 17:55:02.0 +0200
> @@ -0,0 +1,360 @@
> +/*
> + * Abilis Systems Single DVB-T Receiver
> + * Copyright (C) 2008 Pierrick Hascoet
> + * Copyright (C) 2010 Devin Heitmueller
> 
> Hope it helps,
> 

--
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 0/14] staging/media/as102: new driver submission (was Re: [PATCH 1/7] Staging submission: PCTV 74e driver (as102)

2011-10-19 Thread Javier Martinez Canillas 
On Tue, Oct 18, 2011 at 7:20 PM, Piotr Chmura  wrote:
> On Tue, 18 Oct 2011 11:52:17 -0400
> Devin Heitmueller  wrote:
>
>> On Tue, Oct 18, 2011 at 5:10 AM, Piotr Chmura  
>> wrote:
>> > Thanks for comments for all of you.
>> >
>> > [PATCH 1-12/14] Following your guidelines i exported all changes from hg 
>> > one by one. This way we will have all history in kernel tree.
>> > I moved driver to staging/media and removed Kconfig/Makefile changes in 
>> > parent directory in first patch.
>>
>> Hello Piotr,
>>
>> Not that I want to create more work for you, but it would appear that
>> your patches stripped off all the Signed-off-by lines for both myself
>> and Pierrick Hascoet (the developer from the hardware vendor).  You
>> have replaced them with "cc:" lines, which breaks the chain of
>> "Developer's Certificate of Origin".
>>
>> When you take somebody else's patches, you need to preserve any
>> existing Signed-off-by lines, adding your own at the bottom of the
>> list.
>>
>> In other words, the first patch should be:
>>
>> Signed-off-by: Pierrick Hascoet 
>> Signed-off-by: Devin Heitmueller 
>> Signed-off-by: Piotr Chmura 
>>
>> instead of:
>>
>> Signed-off-by: Piotr Chmura 
>> Cc: Pierrick Hascoet 
>> Cc: Devin Heitmueller 
>>
>> Devin
>>
>> --
>> Devin J. Heitmueller - Kernel Labs
>> 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
>
> Ok, i'll resend them again.
>
> Should I replay to every patch with something like [RESEND PATCH nn/mm]..., 
> right ?
>
> Peter

Hi Peter,

A common convention is to add the version of your patch in the subject like:

[PATCH v2 0/14] staging/media/as102: new driver submission

That way people can know that is actually a resend of a new patch-set
and not a resend of the last one.

Anything that is between your Signed-off and the diff get trimmed by
Git when applying a patch (that is why Devin and Pierrick Signed-off
where stripped in first place). So you can add information about the
changes there. Something like:

Signed-off-by: Pierrick Hascoet 
Signed-off-by: Devin Heitmueller 
Signed-off-by: Piotr Chmura 


v2:  preserve any existing Signed-off-by lines so it doesn't get
stripped when applied.

diff -Nur linux.clean/drivers/staging/as102/as102_drv.c
linux.as102_initial/drivers/staging/as102/as102_drv.c
--- linux.clean/drivers/staging/as102/as102_drv.c   1970-01-01
01:00:00.0 +0100
+++ linux.as102_initial/drivers/staging/as102/as102_drv.c   2011-10-14
17:55:02.0 +0200
@@ -0,0 +1,360 @@
+/*
+ * Abilis Systems Single DVB-T Receiver
+ * Copyright (C) 2008 Pierrick Hascoet
+ * Copyright (C) 2010 Devin Heitmueller

Hope it helps,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
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] em28xx: implement VIDIOC_ENUM_FRAMESIZES

2011-10-19 Thread Mauro Carvalho Chehab 
Pidgin uses gstreamer (and libv4l) to work. Without implementing this ioctl,
it won't detect properly the size range, and driver will fail.

So, this patch is required, in order to use an em27xx webcam, like
Silvercrest.

The pigdin/gstreamer/libv4l needs to be fixed, as it shouldn't assume
that all drivers will implement this optional ioctl, but, at least now,
devices with em28xx have a better chance of working with pidgin.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/video/em28xx/em28xx-video.c |   41 -
 1 files changed, 40 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/em28xx/em28xx-video.c 
b/drivers/media/video/em28xx/em28xx-video.c
index 62182e3..9b4557a 100644
--- a/drivers/media/video/em28xx/em28xx-video.c
+++ b/drivers/media/video/em28xx/em28xx-video.c
@@ -1802,6 +1802,45 @@ static int vidioc_enum_fmt_vid_cap(struct file *file, 
void  *priv,
return 0;
 }
 
+static int vidioc_enum_framesizes(struct file *file, void *priv,
+ struct v4l2_frmsizeenum *fsize)
+{
+   struct em28xx_fh  *fh  = priv;
+   struct em28xx *dev = fh->dev;
+   struct em28xx_fmt *fmt;
+   unsigned int  maxw = norm_maxw(dev);
+   unsigned int  maxh = norm_maxh(dev);
+
+   fmt = format_by_fourcc(fsize->pixel_format);
+   if (!fmt) {
+   em28xx_videodbg("Fourcc format (%08x) invalid.\n",
+   fsize->pixel_format);
+   return -EINVAL;
+   }
+
+   if (dev->board.is_em2800) {
+   if (fsize->index > 1)
+   return -EINVAL;
+   fsize->type = V4L2_FRMSIZE_TYPE_DISCRETE;
+   fsize->discrete.width = maxw / (1 + fsize->index);
+   fsize->discrete.height = maxh / (1 + fsize->index);
+   return 0;
+   }
+
+   if (fsize->index != 0)
+   return -EINVAL;
+
+   /* Report a continuous range */
+   fsize->type = V4L2_FRMSIZE_TYPE_STEPWISE;
+   fsize->stepwise.min_width = 48;
+   fsize->stepwise.min_height = 32;
+   fsize->stepwise.max_width = maxw;
+   fsize->stepwise.max_height = maxh;
+   fsize->stepwise.step_width = 1;
+   fsize->stepwise.step_height = 1;
+   return 0;
+}
+
 /* Sliced VBI ioctls */
 static int vidioc_g_fmt_sliced_vbi_cap(struct file *file, void *priv,
struct v4l2_format *f)
@@ -2356,10 +2395,10 @@ static const struct v4l2_ioctl_ops video_ioctl_ops = {
.vidioc_s_fmt_vid_cap   = vidioc_s_fmt_vid_cap,
.vidioc_g_fmt_vbi_cap   = vidioc_g_fmt_vbi_cap,
.vidioc_s_fmt_vbi_cap   = vidioc_s_fmt_vbi_cap,
+   .vidioc_enum_framesizes = vidioc_enum_framesizes,
.vidioc_g_audio = vidioc_g_audio,
.vidioc_s_audio = vidioc_s_audio,
.vidioc_cropcap = vidioc_cropcap,
-
.vidioc_g_fmt_sliced_vbi_cap   = vidioc_g_fmt_sliced_vbi_cap,
.vidioc_try_fmt_sliced_vbi_cap = vidioc_try_set_sliced_vbi_cap,
.vidioc_s_fmt_sliced_vbi_cap   = vidioc_try_set_sliced_vbi_cap,
-- 
1.7.6.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap3isp: BT.656 support

2011-10-19 Thread Boris Todorov 
On Wed, Oct 19, 2011 at 11:28 AM, Enrico  wrote:
> On Wed, Oct 19, 2011 at 9:01 AM, Boris Todorov
>  wrote:
>> On Tue, Oct 18, 2011 at 7:31 PM, Enrico  wrote:
>>> You can try if this:
>>>
>>> http://www.spinics.net/lists/linux-media/msg37795.html
>>>
>>> makes it work.
>>
>> Tried it but it's doesn't work for me.
>>
>> When yavta calls VIDIOC_DQBUF I'm stuck here:
>> omap3isp_video_queue_dqbuf() -> isp_video_buffer_wait()
>> "Wait for a buffer to be ready" with O_NONBLOCK
>>
>> Btw my kernel is 2.6.35 but ISP and V4L are taken from
>> omap3isp-omap3isp-yuv and according ISP/TVP register settings
>> everything should be OK...
>
> When you stop yavta you should have in the kernel log something like
> this (this comes from an old log i'm not 100% sure they are the
> correct values):
>
> [  655.470581] omap3isp omap3isp: ###CCDC PCR=0x
> [  655.475677] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80
> [  655.481231] omap3isp omap3isp: ###CCDC HD_VD_WID=0x
> [  655.486816] omap3isp omap3isp: ###CCDC PIX_LINES=0x
> [  655.492431] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f
> [  655.498046] omap3isp omap3isp: ###CCDC VERT_START=0x
> [  655.503784] omap3isp omap3isp: ###CCDC VERT_LINES=0x0139
> [  655.509460] omap3isp omap3isp: ###CCDC CULLING=0x00ff
> [  655.514892] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0
> [  655.520507] omap3isp omap3isp: ###CCDC SDOFST=0x0249
> [  655.525848] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000
> [  655.531372] omap3isp omap3isp: ###CCDC CLAMP=0x0010
> [  655.536651] omap3isp omap3isp: ###CCDC DCSUB=0x0040
> [  655.541900] omap3isp omap3isp: ###CCDC COLPTN=0xbb11bb11
> [  655.547271] omap3isp omap3isp: ###CCDC BLKCMP=0x
> [  655.552612] omap3isp omap3isp: ###CCDC FPC=0x
> [  655.557708] omap3isp omap3isp: ###CCDC FPC_ADDR=0x
> [  655.563232] omap3isp omap3isp: ###CCDC VDINT=0x013800d1
> [  655.568511] omap3isp omap3isp: ###CCDC ALAW=0x
> [  655.573669] omap3isp omap3isp: ###CCDC REC656IF=0x0003
> [  655.579193] omap3isp omap3isp: ###CCDC CFG=0x8800
> [  655.584289] omap3isp omap3isp: ###CCDC FMTCFG=0xe000
> [  655.589660] omap3isp omap3isp: ###CCDC FMT_HORZ=0x
> [  655.595184] omap3isp omap3isp: ###CCDC FMT_VERT=0x
> [  655.600769] omap3isp omap3isp: ###CCDC PRGEVEN0=0x
> [  655.606323] omap3isp omap3isp: ###CCDC PRGEVEN1=0x
> [  655.611816] omap3isp omap3isp: ###CCDC PRGODD0=0x
> [  655.617279] omap3isp omap3isp: ###CCDC PRGODD1=0x
> [  655.622711] omap3isp omap3isp: ###CCDC VP_OUT=0x
> [  655.628051] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600
> [  655.633758] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x
> [  655.639556] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x
> [  655.645599] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x
>
> Send your values so we can try to see where the problem is.
>
> Enrico
>

I really appreciate your help.

Here is my log:
[   24.683685] omap3isp omap3isp: -CCDC Register dump-
[   24.683685] omap3isp omap3isp: ###CCDC PCR=0x
[   24.683685] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80
[   24.683715] omap3isp omap3isp: ###CCDC HD_VD_WID=0x
[   24.683715] omap3isp omap3isp: ###CCDC PIX_LINES=0x
[   24.683746] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f
[   24.683746] omap3isp omap3isp: ###CCDC VERT_START=0x
[   24.683746] omap3isp omap3isp: ###CCDC VERT_LINES=0x0105
[   24.683776] omap3isp omap3isp: ###CCDC CULLING=0x00ff
[   24.683776] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0
[   24.683776] omap3isp omap3isp: ###CCDC SDOFST=0x0249
[   24.683807] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000
[   24.683807] omap3isp omap3isp: ###CCDC CLAMP=0x0010
[   24.683807] omap3isp omap3isp: ###CCDC DCSUB=0x
[   24.683837] omap3isp omap3isp: ###CCDC COLPTN=0x
[   24.683837] omap3isp omap3isp: ###CCDC BLKCMP=0x
[   24.683837] omap3isp omap3isp: ###CCDC FPC=0x
[   24.683868] omap3isp omap3isp: ###CCDC FPC_ADDR=0x
[   24.683868] omap3isp omap3isp: ###CCDC VDINT=0x0104
[   24.683868] omap3isp omap3isp: ###CCDC ALAW=0x0004
[   24.683898] omap3isp omap3isp: ###CCDC REC656IF=0x0003
[   24.683898] omap3isp omap3isp: ###CCDC CFG=0x8800
[   24.683898] omap3isp omap3isp: ###CCDC FMTCFG=0x6000
[   24.683929] omap3isp omap3isp: ###CCDC FMT_HORZ=0x02d0
[   24.683929] omap3isp omap3isp: ###CCDC FMT_VERT=0x020d
[   24.683929] omap3isp omap3isp: ###CCDC PRGEVEN0=0x
[   24.683959] omap3isp omap3isp: ###CCDC PRGEVEN1=0x
[   24.683959] omap3isp omap3isp: ###CCDC PRGODD0=0x
[   24.683959] omap3isp omap3isp: ###CCDC PRGODD1=0x
[   24.683990] omap3isp omap3isp: ###CCDC VP_OUT=0x04182d00
[   24.683990] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600
[   24.683990] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x
[   24.68

Re: omap3isp: BT.656 support

2011-10-19 Thread Enrico 
On Wed, Oct 19, 2011 at 9:01 AM, Boris Todorov
 wrote:
> On Tue, Oct 18, 2011 at 7:31 PM, Enrico  wrote:
>> You can try if this:
>>
>> http://www.spinics.net/lists/linux-media/msg37795.html
>>
>> makes it work.
>
> Tried it but it's doesn't work for me.
>
> When yavta calls VIDIOC_DQBUF I'm stuck here:
> omap3isp_video_queue_dqbuf() -> isp_video_buffer_wait()
> "Wait for a buffer to be ready" with O_NONBLOCK
>
> Btw my kernel is 2.6.35 but ISP and V4L are taken from
> omap3isp-omap3isp-yuv and according ISP/TVP register settings
> everything should be OK...

When you stop yavta you should have in the kernel log something like
this (this comes from an old log i'm not 100% sure they are the
correct values):

[  655.470581] omap3isp omap3isp: ###CCDC PCR=0x
[  655.475677] omap3isp omap3isp: ###CCDC SYN_MODE=0x00032f80
[  655.481231] omap3isp omap3isp: ###CCDC HD_VD_WID=0x
[  655.486816] omap3isp omap3isp: ###CCDC PIX_LINES=0x
[  655.492431] omap3isp omap3isp: ###CCDC HORZ_INFO=0x059f
[  655.498046] omap3isp omap3isp: ###CCDC VERT_START=0x
[  655.503784] omap3isp omap3isp: ###CCDC VERT_LINES=0x0139
[  655.509460] omap3isp omap3isp: ###CCDC CULLING=0x00ff
[  655.514892] omap3isp omap3isp: ###CCDC HSIZE_OFF=0x05a0
[  655.520507] omap3isp omap3isp: ###CCDC SDOFST=0x0249
[  655.525848] omap3isp omap3isp: ###CCDC SDR_ADDR=0x1000
[  655.531372] omap3isp omap3isp: ###CCDC CLAMP=0x0010
[  655.536651] omap3isp omap3isp: ###CCDC DCSUB=0x0040
[  655.541900] omap3isp omap3isp: ###CCDC COLPTN=0xbb11bb11
[  655.547271] omap3isp omap3isp: ###CCDC BLKCMP=0x
[  655.552612] omap3isp omap3isp: ###CCDC FPC=0x
[  655.557708] omap3isp omap3isp: ###CCDC FPC_ADDR=0x
[  655.563232] omap3isp omap3isp: ###CCDC VDINT=0x013800d1
[  655.568511] omap3isp omap3isp: ###CCDC ALAW=0x
[  655.573669] omap3isp omap3isp: ###CCDC REC656IF=0x0003
[  655.579193] omap3isp omap3isp: ###CCDC CFG=0x8800
[  655.584289] omap3isp omap3isp: ###CCDC FMTCFG=0xe000
[  655.589660] omap3isp omap3isp: ###CCDC FMT_HORZ=0x
[  655.595184] omap3isp omap3isp: ###CCDC FMT_VERT=0x
[  655.600769] omap3isp omap3isp: ###CCDC PRGEVEN0=0x
[  655.606323] omap3isp omap3isp: ###CCDC PRGEVEN1=0x
[  655.611816] omap3isp omap3isp: ###CCDC PRGODD0=0x
[  655.617279] omap3isp omap3isp: ###CCDC PRGODD1=0x
[  655.622711] omap3isp omap3isp: ###CCDC VP_OUT=0x
[  655.628051] omap3isp omap3isp: ###CCDC LSC_CONFIG=0x6600
[  655.633758] omap3isp omap3isp: ###CCDC LSC_INITIAL=0x
[  655.639556] omap3isp omap3isp: ###CCDC LSC_TABLE_BASE=0x
[  655.645599] omap3isp omap3isp: ###CCDC LSC_TABLE_OFFSET=0x

Send your values so we can try to see where the problem is.

Enrico
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] soc-camera: mt9t112: modify delay time after initialize

2011-10-19 Thread phil . edworthy 
Hi Guennadi, Morimoto-san,

> > > Both are needed.
> > > These are bug fix patches
> > 
> > I tried to capture several frames beginning with the very first one 
(as 
> > much as performance allowed), and I do see several black or wrongly 
> > coloured framed in the beginning, but none of those patches, including 
the 
> > proposed 300ms at the end of .s_stream() fixes the problem reliably. 
So, 
> > either this problems, that these patches fix, are specific to the 
Solution 
> > Engine board (is it the one, where the problems have been observed?), 
or 
> > one needs a different testing method. If they are SE-specific - I 
don't 
> > think, getting those fixes in the driver is very important, because 
> > mt9t112 data for SE is not in the mainline. If I was testing wrongly, 
> > please, tell me how exactly to reproduce those problems and see, how 
one 
> > or another patch fixes them.
> 
> I guess mt9t112 camera is used in SE (with local circuit ?)
> and Ecovec.
> But I forgot detail of this issue (I have no mt9t112 for now).
> 
> I think Phil is the person who wanted this patch.

There are capture issues on the Ecovec board with this camera. iirc, these 
patches made the situation better but still didn't completely fix all 
issues. Morimoto-san has made comments previously that the mt9t112 is a 
little difficult to setup and we don't have the relevant information from 
the manufacturer.

Thanks
Phil

--
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: omap3isp: BT.656 support

2011-10-19 Thread Boris Todorov 
On Tue, Oct 18, 2011 at 7:31 PM, Enrico  wrote:
> On Tue, Oct 18, 2011 at 3:33 PM, Boris Todorov
>  wrote:
>> Hi
>>
>> I'm trying to run OMAP + TVP5151 in BT656 mode.
>>
>> I'm using omap3isp-omap3isp-yuv (git.linuxtv.org/pinchartl/media.git).
>> Plus the following patches:
>>
>> TVP5151:
>> https://github.com/ebutera/meta-igep/tree/testing-v2/recipes-kernel/linux/linux-3.0+3.1rc/tvp5150
>>
>> The latest RFC patches for BT656 support:
>>
>> Enrico Butera (2):
>>  omap3isp: ispvideo: export isp_video_mbus_to_pix
>>  omap3isp: ispccdc: configure CCDC registers and add BT656 support
>>
>> Javier Martinez Canillas (1):
>>  omap3isp: ccdc: Add interlaced field mode to platform data
>>
>>
>> I'm able to configure with media-ctl:
>>
>> media-ctl -v -r -l '"tvp5150 3-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3
>> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
>> media-ctl -v --set-format '"tvp5150 3-005c":0 [UYVY2X8 720x525]'
>> media-ctl -v --set-format '"OMAP3 ISP CCDC":0 [UYVY2X8 720x525]'
>> media-ctl -v --set-format '"OMAP3 ISP CCDC":1 [UYVY2X8 720x525]'
>>
>> But
>> ./yavta -f UYVY -s 720x525 -n 4 --capture=4 -F /dev/video4
>>
>> sleeps after
>> ...
>> Buffer 1 mapped at address 0x4021d000.
>> length: 756000 offset: 1515520
>> Buffer 2 mapped at address 0x402d6000.
>> length: 756000 offset: 2273280
>> Buffer 3 mapped at address 0x4038f000.
>>
>> Anyone with the same issue??? This happens with every other v4l test app I 
>> used.
>> I can see data from TVP5151 but there are no interrupts in ISP.
>
> You can try if this:
>
> http://www.spinics.net/lists/linux-media/msg37795.html
>
> makes it work.

Tried it but it's doesn't work for me.

When yavta calls VIDIOC_DQBUF I'm stuck here:
omap3isp_video_queue_dqbuf() -> isp_video_buffer_wait()
"Wait for a buffer to be ready" with O_NONBLOCK

Btw my kernel is 2.6.35 but ISP and V4L are taken from
omap3isp-omap3isp-yuv and according ISP/TVP register settings
everything should be OK...

>
> Enrico
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html