RE: [PATCH v17 08/13] davinci: eliminate use of IO_ADDRESS() on sysmod

[Nori, Sekhar]

On Tue, Mar 22, 2011 at 18:45:03, Arnd Bergmann wrote:
> On Tuesday 22 March 2011, Nori, Sekhar wrote:
> > .. but forgot to fix this. There is nothing wrong with
> > using writel, but it doesn't fit into what the subject
> > of this patch is.
> 
> Well, to be more exact, the __raw_writel was actually
> wrong here and it should be writel(), but it's certainly
> better to mention the reason in the changelog, or to
> make a separate patch for it.

I wouldn't necessarily classify the use of __raw_writel as wrong
(as in a bug) - since the specific code is question is only run
on ARMv5 based SoCs. 

A lot of DaVinci code uses __raw_* variants, and perhaps should
be changed to use readl/writel instead - at least it will help
copying that code over for other uses.

That should be the subject of separate (series of) patches.

Thanks,
Sekhar

--
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: soc-camera layer2 driver

[Gilles]

Laurent,

>> the videobuf2-dma-contig allocator), look at sh_mobile_ceu for an advanced
>> example, or at one of mx3_camera, mx2_camera, mx1_camera for simpler ones.
>> omap1_camera is also trying to support both sg and contig... If you have
>> questions, don't hesitate to ask on the ML, also cc me and / or the
>> respective driver author. Maybe you end up writing some such howto too;)

Thank you for your help and pointers. I will definitely consider the
howto when I feel like I understand what I'm doing. I guess what
worries me is that there are many options I will not get to
exercice (because I may not need them in my case) so my howto would be
incomplete. But I'll be glad to write what I've learned.


>> I'm not aware about any 3d efforts in v4l2... I would've thought, that one
>> would want to synchronize frames at the driver level, the application
>> level is too indeterministic. So, you would need to add an API to retrieve
>> pairs of frames, I presume, one of which is marked left, other right. This
>> frame-pair handling is one addition to the generic V4L2 API. You'll also
>> need a way to open / associate two sensors with one v4l2 device node.
>> Then, how you assemble two different frames from two sensors in one
>> stereo-frame is up to your driver, I presume.

No questions about it. Both cameras should definitely be handled by the
same driver. The application should be able to select whether it wants to
capture frame-alternative or side-by-side and the driver would package
accordingly.

At this point, I have a hardware issue because I hooked up both cameras
to the same reset and same pixel clock but the HSync signals are not in
sync so it's relatively impossible for me (even at the driver level) to
control when a frame is captured. I think it has to do with I2C commands
changing the timing. This is outside of the scope of this thread but it
would be interesting to discuss how 3D would be added to V4L.

Anyway, Thank you for your help, I have some things to look at.

Thanks,
Gilles
.

--
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] tm6000: fix s-video input

[Dmitri Belimov]

Hi Stefan

> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>  
> Am 18.03.2011 01:08, schrieb Dmitri Belimov:
> > Hi
> >
> > Add compatibility for composite and s-video inputs. Some TV cards
> hasn't it.
> > Fix S-Video input, the s-video cable has only video signals no
> > audio.
> Call the function of audio configure kill chroma in signal. only b/w
> video.
> >
> > Known bugs:
> > after s-video the audio for radio didn't work, TV crashed hardly
> > after composite TV crashed hardly too.
> >
> > P.S. After this patch I'll want to rework the procedure of configure
> video. Now it has a lot of junk and dubles.
> >
> 
> Why you use caps to define video input and audio with avideo and/or
> aradio as flags? Better is , I think,  we use a struct for edge
> virtual input (Video type (s-vhs, composite, tuner), video input pin
> (video port a, video port b or both), video mode gpio, audio type ,
> audio input pin (adc 1, adc 2 or sif)). If we are called
> vidioc_s_input or radio_g_input setting input number. In tm6000_std.c
> we can use this input number and the input struct with the same number
> and can use all setting from here to set it.

It's very intresting but right now much better for me make full-working TV 
cards.
You can rework this part of code as you want. Or we can do it togehter.

With my best regards, Dmitry.

> Stefan Ringel
> 
> 
> > diff --git a/drivers/staging/tm6000/tm6000-cards.c
> b/drivers/staging/tm6000/tm6000-cards.c
> > index 88144a1..146c7e8 100644
> > --- a/drivers/staging/tm6000/tm6000-cards.c
> > +++ b/drivers/staging/tm6000/tm6000-cards.c
> > @@ -235,11 +235,13 @@ struct tm6000_board tm6000_boards[] = {
> > .avideo = TM6000_AIP_SIF1,
> > .aradio = TM6000_AIP_LINE1,
> > .caps = {
> > - .has_tuner = 1,
> > - .has_dvb = 1,
> > - .has_zl10353 = 1,
> > - .has_eeprom = 1,
> > - .has_remote = 1,
> > + .has_tuner = 1,
> > + .has_dvb = 1,
> > + .has_zl10353 = 1,
> > + .has_eeprom = 1,
> > + .has_remote = 1,
> > + .has_input_comp = 1,
> > + .has_input_svid = 1,
> > },
> > .gpio = {
> > .tuner_reset = TM6010_GPIO_0,
> > @@ -255,11 +257,13 @@ struct tm6000_board tm6000_boards[] = {
> > .avideo = TM6000_AIP_SIF1,
> > .aradio = TM6000_AIP_LINE1,
> > .caps = {
> > - .has_tuner = 1,
> > - .has_dvb = 0,
> > - .has_zl10353 = 0,
> > - .has_eeprom = 1,
> > - .has_remote = 1,
> > + .has_tuner = 1,
> > + .has_dvb = 0,
> > + .has_zl10353 = 0,
> > + .has_eeprom = 1,
> > + .has_remote = 1,
> > + .has_input_comp = 1,
> > + .has_input_svid = 1,
> > },
> > .gpio = {
> > .tuner_reset = TM6010_GPIO_0,
> > @@ -327,10 +331,13 @@ struct tm6000_board tm6000_boards[] = {
> > .avideo = TM6000_AIP_SIF1,
> > .aradio = TM6000_AIP_LINE1,
> > .caps = {
> > - .has_tuner = 1,
> > - .has_dvb = 1,
> > - .has_zl10353 = 1,
> > - .has_eeprom = 1,
> > + .has_tuner = 1,
> > + .has_dvb = 1,
> > + .has_zl10353 = 1,
> > + .has_eeprom = 1,
> > + .has_remote = 0,
> > + .has_input_comp = 0,
> > + .has_input_svid = 0,
> > },
> > .gpio = {
> > .tuner_reset = TM6010_GPIO_0,
> > @@ -346,10 +353,13 @@ struct tm6000_board tm6000_boards[] = {
> > .avideo = TM6000_AIP_SIF1,
> > .aradio = TM6000_AIP_LINE1,
> > .caps = {
> > - .has_tuner = 1,
> > - .has_dvb = 0,
> > - .has_zl10353 = 0,
> > - .has_eeprom = 1,
> > + .has_tuner = 1,
> > + .has_dvb = 0,
> > + .has_zl10353 = 0,
> > + .has_eeprom = 1,
> > + .has_remote = 0,
> > + .has_input_comp = 0,
> > + .has_input_svid = 0,
> > },
> > .gpio = {
> > .tuner_reset = TM6010_GPIO_0,
> > diff --git a/drivers/staging/tm6000/tm6000-stds.c
> b/drivers/staging/tm6000/tm6000-stds.c
> > index a4c07e5..da3e51b 100644
> > --- a/drivers/staging/tm6000/tm6000-stds.c
> > +++ b/drivers/staging/tm6000/tm6000-stds.c
> > @@ -1161,8 +1161,6 @@ int tm6000_set_standard(struct tm6000_core
> > *dev,
> v4l2_std_id * norm)
> > rc = tm6000_load_std(dev, svideo_stds[i].common,
> > sizeof(svideo_stds[i].
> > common));
> > - tm6000_set_audio_std(dev, svideo_stds[i].audio_default_std);
> > -
> > goto ret;
> > }
> > }
> > diff --git a/drivers/staging/tm6000/tm6000-video.c
> b/drivers/staging/tm6000/tm6000-video.c
> > index b550340..c80a316 100644
> > --- a/drivers/staging/tm6000/tm6000-video.c
> > +++ b/drivers/staging/tm6000/tm6000-video.c
> > @@ -1080,18 +1080,27 @@ static int vidioc_s_std (struct file *file,
> void *priv, v4l2_std_id *norm)
> > static int vidioc_enum_input(struct file *file, void *priv,
> > struct v4l2_input *inp)
> > {
> > + struct tm6000_fh *fh = priv;
> > + struct tm6000_core *dev = fh->dev;
> > +
> > switch (inp->index) {
> > case TM6000_INPUT_TV:
> > inp->type = V4L2_INPUT_TYPE_TUNER;
> > strcpy(inp->name, "Television");
> > break;
> > case TM6000_INPUT_COMPOSITE:
> > - inp->type = V4L2_INPUT_TYPE_CAMERA;
> > - strcpy(inp->name, "Composite");
> > + if (dev->caps.has_input_comp) {
> > + inp->type = V4L2_INPUT_TYPE_CAMERA;
> > + strcpy(inp->name, "Composite");
> > + } else
> > + return -EINVAL;
> > break;
> > case TM6000_INPUT_SVIDEO:
> > - inp->type = V4L2_INPUT_TYPE_CAMERA;
> > - strcpy(inp->name, "S-Vid

Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.

[Dave Airlie]

On Wed, Mar 23, 2011 at 3:32 AM, Mythri P K  wrote:
> Adding support for common EDID parsing in kernel.
>
> EDID - Extended display identification data is a data structure provided by
> a digital display to describe its capabilities to a video source, This a
> standard supported by CEA and VESA.
>
> There are several custom implementations for parsing EDID in kernel, some
> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
> parsing of EDID should be done in a library, which is agnostic of the
> framework (V4l2, DRM, FB)  which is using the functionality, just based on
> the raw EDID pointer with size/segment information.
>
> With other RFC's such as the one below, which tries to standardize HDMI API's
> It would be better to have a common EDID code in one place.It also helps to
> provide better interoperability with variety of TV/Monitor may be even by
> listing out quirks which might get missed with several custom implementation
> of EDID.
> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
>
> This patch tries to add functions to parse some portion EDID (detailed timing,
> monitor limits, AV delay information, deep color mode support, Audio and VSDB)
> If we can align on this library approach i can enhance this library to parse
> other blocks and probably we could also add quirks from other implementation
> as well.
>

If you want to take this approach, you need to start from the DRM EDID parser,
its the most well tested and I can guarantee its been plugged into more monitors
than any of the others. There is just no way we would move the DRM parser to a
library one that isn't derived from it + enhancements, as we'd throw away the
years of testing and the regression count would be way too high.

Dave.
--
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: [Query] VIDIOC_QBUF and VIDIOC_STREAMON order

[Jonghun Han]

Hi all,

On Tuesday, March 22, 2011 7:54 PM Laurent Pinchart wrote:
> On Tuesday 15 March 2011 08:50:45 Hans Verkuil wrote:
> > On Tuesday, March 15, 2011 04:21:05 Pawel Osciak wrote:
> > > On Mon, Mar 14, 2011 at 03:49, Subash Patel 
wrote:
> > > > VIDIOC_STREAMON expects buffers to be queued before hardware part
> > > > of image/video pipe is enabled. From my experience of V4L2 user
> > > > space, I have always QBUFfed before invoking the STREAMON. Below
> > > > is the API
> > >
> > > > specification which also speaks something same:
> > > Not exactly. It says that the API requires buffers to be queued for
> > > output devices. It does not require any buffers to be queued for
> > > input devices. Sylwester is right here.
> > >
> > > This feature of not having to queue input buffers before STREAMON
> > > introduces problems to driver implementations and I am personally
> > > not a big fan of it either. But I'm seeing some additional problems
here.
> > > Suppose we forced QBUF to be done before STREAMON. This would work,
> > > but what happens next? What should happen when we want to DQBUF the
> > > last buffer? If the device couldn't start without any buffers
> > > queued, can it continue streaming with all of them dequeued? I would
> > > guess not. So we'd either have to deny DQBUF of the last buffer
> > > (which for me personally is almost unacceptable) or have the last
> > > DQBUF automatically cause a STREAMOFF. So, for the latter, should
> > > applications, after they get all the data they wanted, be made to
> > > always have one more buffer queued as a "throwaway" buffer? This is
> > > probably the only reasonable solution here, but the applications
> > > would have to keep count of their queued buffers and be aware of this.
> > > Also, there might still be situations where being able to STREAMON
> > > without buffers queued would be beneficial. For example, enabling
> > > the device might be a slow/expensive operation and we might prefer
> > > to keep it running even if we don't want any data at the moment.
> > > Even for faster devices, being able to keep them on and periodically
> > > take a snapshot would be faster without having to call STREAMON
anyway...
> >
> > The problem is that what is possible is highly hardware dependent. All
> > video capture device I know of (composite in, HDMI in, etc) require
> > that buffers are queued and they won't release that buffer to
> > userspace until a new free buffer is available.
> 
> That's funny, all video capture devices I know of behave the opposite way
:-)
> They either pause the stream when they run out of buffers and resume it
when
> a new buffer gets queued, or they throw away the data when intermediate
> buffers are used (such as with USB devices).
> 

Laurent,
Exynos capture device is the same with your example.
It should pause the stream not to overwrite
when they run out of buffers and resume it when a new buffer gets queued.

Hans,
Do you mean that the buffer is overwritten without pause and resume
until a new free buffer is coming ?

> > They DMA continuously and stopping the DMA at the last buffer and
> > restarting it when a new one appears tends to be too expensive and
> > leads to additional loss of frames.
> >
> > In part how this should act depends on the use-case: if you are
> > streaming video, then requiring buffers to be present before STREAMON
> > and holding on to a buffer if userspace can't keep up seems quite
> reasonable to me.
> >
> > But for snapshot and codec type streams this behavior doesn't make
sense.
> > The main difference is that in this case the DMA is not driven by an
> > external input, but by internal (userspace) demand.
> >
> > Something for our meeting to discuss.
> 
> --
> 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

Best regards,

Jonghun Han


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

Re: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions

[Mauro Carvalho Chehab]

Em 22-03-2011 19:12, Malcolm Priestley escreveu:
> On Tue, 2011-03-22 at 02:43 +0200, Antti Palosaari wrote:
>> On 03/22/2011 02:32 AM, Malcolm Priestley wrote:
>>> On Mon, 2011-03-21 at 21:17 -0300, Mauro Carvalho Chehab wrote:
 Em 12-02-2011 23:35, Malcolm Priestley escreveu:
> Old versions of these boxes have the BS2F7HZ0194 tuner module on
> both the LME2510 and LME2510C.
>
> Firmware dvb-usb-lme2510-s0194.fw  and/or dvb-usb-lme2510c-s0194.fw
> files are required.
>
> See Documentation/dvb/lmedm04.txt
>
> Patch 535181 is also required.
>
> Signed-off-by: Malcolm Priestley
> ---

> @@ -1110,5 +1220,5 @@ module_exit(lme2510_module_exit);
>
>   MODULE_AUTHOR("Malcolm Priestley");
>   MODULE_DESCRIPTION("LME2510(C) DVB-S USB2.0");
> -MODULE_VERSION("1.76");
> +MODULE_VERSION("1.80");
>   MODULE_LICENSE("GPL");


 There were a merge conflict on this patch. The version we have was 1.75.

 Maybe some patch got missed?
>>>
>>> 1.76 relates to remote control patches.
>>>
>>> https://patchwork.kernel.org/patch/499391/
>>> https://patchwork.kernel.org/patch/499401/
>>
>> Those are NEC extended remotes. You are now setting it as 32 bit NEC, in 
>> my understanding it should be defined as 24 bit NEC extended.
>>
>> Anyhow, my opinion is still that we *should* make all NEC remotes as 32 
>> bit and leave handling of NEC 16, NEC 24, NEC 32 to NEC decoder. For 
>> example AF9015 current NEC handling is too complex for that reason... I 
>> don't like how it is implemented currently.
> 
> One of the reasons for using 32 bit was interference from other consumer
> remotes.  It appears, these near identical bubble remotes originate from
> a Chinese factory and supplied with the same product with completely
> different key mapping.
> 
> I am not sure how many of these remotes are common to other devices.

Drivers should get the 32 bit codes form NEC when hardware provides it.
What we currently do is to identify if the code has 16, 24 or 32 bits,
but it is probably better to always handle them as if they have 32 bits.
> 
> Regards
> 
> 
> Malcolm
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions

[Mauro Carvalho Chehab]

Em 22-03-2011 18:34, Malcolm Priestley escreveu:
> On Mon, 2011-03-21 at 21:40 -0300, Mauro Carvalho Chehab wrote:
>> Em 21-03-2011 21:32, Malcolm Priestley escreveu:
>>> On Mon, 2011-03-21 at 21:17 -0300, Mauro Carvalho Chehab wrote:
 Em 12-02-2011 23:35, Malcolm Priestley escreveu:
> Old versions of these boxes have the BS2F7HZ0194 tuner module on
> both the LME2510 and LME2510C.
>
> Firmware dvb-usb-lme2510-s0194.fw  and/or dvb-usb-lme2510c-s0194.fw
> files are required.
>
> See Documentation/dvb/lmedm04.txt
>
> Patch 535181 is also required.
>
> Signed-off-by: Malcolm Priestley 
> ---

> @@ -1110,5 +1220,5 @@ module_exit(lme2510_module_exit);
>  
>  MODULE_AUTHOR("Malcolm Priestley ");
>  MODULE_DESCRIPTION("LME2510(C) DVB-S USB2.0");
> -MODULE_VERSION("1.76");
> +MODULE_VERSION("1.80");
>  MODULE_LICENSE("GPL");


 There were a merge conflict on this patch. The version we have was 1.75.

 Maybe some patch got missed?
>>>
>>> 1.76 relates to remote control patches.
>>>
>>> https://patchwork.kernel.org/patch/499391/
>>> https://patchwork.kernel.org/patch/499401/
>>
>> Ah! Ok, I'll be applying them. Btw, please, move the keycode tables to the
>> proper place and use the RC core stuff. The idea is to remove all those 
>> keytables
>> from kernel in a near future, and use the userspace tool to load it via udev.
> 
> For some reason patch to 1.81(552551) was also missing from the
> Patchwork list earlier, although it is there now.
> 
> https://patchwork.kernel.org/patch/553551/

It where on my list of broken patches (due to the module_version change). 
Applied.

> 
> I will put the RC on the TODO list and hope to complete in the near
> future.

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

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

Re: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions

[Malcolm Priestley]

On Tue, 2011-03-22 at 02:43 +0200, Antti Palosaari wrote:
> On 03/22/2011 02:32 AM, Malcolm Priestley wrote:
> > On Mon, 2011-03-21 at 21:17 -0300, Mauro Carvalho Chehab wrote:
> >> Em 12-02-2011 23:35, Malcolm Priestley escreveu:
> >>> Old versions of these boxes have the BS2F7HZ0194 tuner module on
> >>> both the LME2510 and LME2510C.
> >>>
> >>> Firmware dvb-usb-lme2510-s0194.fw  and/or dvb-usb-lme2510c-s0194.fw
> >>> files are required.
> >>>
> >>> See Documentation/dvb/lmedm04.txt
> >>>
> >>> Patch 535181 is also required.
> >>>
> >>> Signed-off-by: Malcolm Priestley
> >>> ---
> >>
> >>> @@ -1110,5 +1220,5 @@ module_exit(lme2510_module_exit);
> >>>
> >>>   MODULE_AUTHOR("Malcolm Priestley");
> >>>   MODULE_DESCRIPTION("LME2510(C) DVB-S USB2.0");
> >>> -MODULE_VERSION("1.76");
> >>> +MODULE_VERSION("1.80");
> >>>   MODULE_LICENSE("GPL");
> >>
> >>
> >> There were a merge conflict on this patch. The version we have was 1.75.
> >>
> >> Maybe some patch got missed?
> >
> > 1.76 relates to remote control patches.
> >
> > https://patchwork.kernel.org/patch/499391/
> > https://patchwork.kernel.org/patch/499401/
> 
> Those are NEC extended remotes. You are now setting it as 32 bit NEC, in 
> my understanding it should be defined as 24 bit NEC extended.
> 
> Anyhow, my opinion is still that we *should* make all NEC remotes as 32 
> bit and leave handling of NEC 16, NEC 24, NEC 32 to NEC decoder. For 
> example AF9015 current NEC handling is too complex for that reason... I 
> don't like how it is implemented currently.

One of the reasons for using 32 bit was interference from other consumer
remotes.  It appears, these near identical bubble remotes originate from
a Chinese factory and supplied with the same product with completely
different key mapping.

I am not sure how many of these remotes are common to other devices.

Regards


Malcolm


--
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

[PULL] soc-camera: 4 more feature-commits for 2.6.39

[Guennadi Liakhovetski]

Hi Mauro

The following changes since commit c002e112822c2fe152e55feb5db036c642681b1a:

  [media] stv0367: typo in function parameter (2011-03-22 07:00:39 -0300)

are available in the git repository at:
  git://linuxtv.org/gliakhovetski/v4l-dvb.git for-2.6.39

Guennadi Liakhovetski (1):
  V4L: soc-camera: explicitly require V4L2_BUF_TYPE_VIDEO_CAPTURE

Pawel Osciak (2):
  sh_mobile_ceu_camera: Do not call vb2's mem_ops directly
  videobuf2-dma-contig: make cookie() return a pointer to dma_addr_t

Sergio Aguirre (1):
  v4l: soc-camera: Store negotiated buffer settings

 drivers/media/video/sh_mobile_ceu_camera.c |4 +---
 drivers/media/video/soc_camera.c   |   25 -
 drivers/media/video/videobuf2-dma-contig.c |2 +-
 include/media/soc_camera.h |2 ++
 include/media/videobuf2-dma-contig.h   |9 ++---
 5 files changed, 26 insertions(+), 16 deletions(-)

As I mentioned earlier today on the IRC, I've got a few more fixes, that I 
will be posting and pushing a bit later, they can also go in after -rc1.

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: [PATCH 1/2] v180 - DM04/QQBOX added support for BS2F7HZ0194 versions

[Malcolm Priestley]

On Mon, 2011-03-21 at 21:40 -0300, Mauro Carvalho Chehab wrote:
> Em 21-03-2011 21:32, Malcolm Priestley escreveu:
> > On Mon, 2011-03-21 at 21:17 -0300, Mauro Carvalho Chehab wrote:
> >> Em 12-02-2011 23:35, Malcolm Priestley escreveu:
> >>> Old versions of these boxes have the BS2F7HZ0194 tuner module on
> >>> both the LME2510 and LME2510C.
> >>>
> >>> Firmware dvb-usb-lme2510-s0194.fw  and/or dvb-usb-lme2510c-s0194.fw
> >>> files are required.
> >>>
> >>> See Documentation/dvb/lmedm04.txt
> >>>
> >>> Patch 535181 is also required.
> >>>
> >>> Signed-off-by: Malcolm Priestley 
> >>> ---
> >>
> >>> @@ -1110,5 +1220,5 @@ module_exit(lme2510_module_exit);
> >>>  
> >>>  MODULE_AUTHOR("Malcolm Priestley ");
> >>>  MODULE_DESCRIPTION("LME2510(C) DVB-S USB2.0");
> >>> -MODULE_VERSION("1.76");
> >>> +MODULE_VERSION("1.80");
> >>>  MODULE_LICENSE("GPL");
> >>
> >>
> >> There were a merge conflict on this patch. The version we have was 1.75.
> >>
> >> Maybe some patch got missed?
> > 
> > 1.76 relates to remote control patches.
> > 
> > https://patchwork.kernel.org/patch/499391/
> > https://patchwork.kernel.org/patch/499401/
> 
> Ah! Ok, I'll be applying them. Btw, please, move the keycode tables to the
> proper place and use the RC core stuff. The idea is to remove all those 
> keytables
> from kernel in a near future, and use the userspace tool to load it via udev.

For some reason patch to 1.81(552551) was also missing from the
Patchwork list earlier, although it is there now.

https://patchwork.kernel.org/patch/553551/

I will put the RC on the TODO list and hope to complete in the near
future.

Regards


Malcolm


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

Re: [PATCH] [media] mantis: trivial module parameter documentation fix

[Manu Abraham]

2011/3/22 Bjørn Mork :
> The default for "verbose" is 0.  Update description to match.
>
> Signed-off-by: Bjørn Mork 
> ---
>  drivers/media/dvb/mantis/hopper_cards.c |    2 +-
>  drivers/media/dvb/mantis/mantis_cards.c |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/dvb/mantis/hopper_cards.c 
> b/drivers/media/dvb/mantis/hopper_cards.c
> index 70e73af..1402062 100644
> --- a/drivers/media/dvb/mantis/hopper_cards.c
> +++ b/drivers/media/dvb/mantis/hopper_cards.c
> @@ -44,7 +44,7 @@
>
>  static unsigned int verbose;
>  module_param(verbose, int, 0644);
> -MODULE_PARM_DESC(verbose, "verbose startup messages, default is 1 (yes)");
> +MODULE_PARM_DESC(verbose, "verbose startup messages, default is 0 (no)");
>
>  #define DRIVER_NAME    "Hopper"
>
> diff --git a/drivers/media/dvb/mantis/mantis_cards.c 
> b/drivers/media/dvb/mantis/mantis_cards.c
> index 40da225..05cbb9d 100644
> --- a/drivers/media/dvb/mantis/mantis_cards.c
> +++ b/drivers/media/dvb/mantis/mantis_cards.c
> @@ -52,7 +52,7 @@
>
>  static unsigned int verbose;
>  module_param(verbose, int, 0644);
> -MODULE_PARM_DESC(verbose, "verbose startup messages, default is 1 (yes)");
> +MODULE_PARM_DESC(verbose, "verbose startup messages, default is 0 (no)");
>
>  static int devs;
>
> --
> 1.7.2.5
>
> --

Thanks.

Acked-by: Manu Abraham 
--
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] IR Updates for 2.6.39

[Jarod Wilson]

This heaping helping of patches goes a long way to improve the lirc_zilog
driver (courtesy of Andy Walls) to the point where it no longer crashes
and burns if you unplug a device while its loaded and cleans up a fair
bit of inconsistent key mappings, as well as making the
Hauppauge-specific keymaps much cleaner, with ir-kbd-i2c properly passing
entire rc5 scancodes, making use of non-Hauppauge RC5 remotes with
Hauppauge i2c-based receivers work much better (all courtesy of Mauro
Carvalho Chehab).

I fixed a few little things here and there too, and tested out the
zilog and ir-kbd-i2c changes. This series does include a rewritten i2c
master for the hdpvr, based heavily on the pvrusb2 driver's i2c master,
which in theory, was going to make it behave better, but has had no
noticeable impact yet. However, it may also be necessary for some more
forthcoming lirc_zilog changes based on Devin Heitmueller's work for
the Hauppauge Broadway device. There's also a small change to the NEC
IR decoder, which will make it try passing along full 32-bit scancodes
if/when the command/not_command checksum test fails. Should be of no
consequence for existing keymaps, and allow the creation of full 32-bit
ones for the likes of the Apple and TiVo remotes I've got. (Patches
adding those forthcoming).

The following changes since commit 97ad124749a060d8c4f546911474db3b555f:

  ite-cir: Fix a breakage caused by my cleanup patch (2011-03-22 17:20:34 -0300)

are available in the git repository at:
  
git+ssh://ja...@master.kernel.org/pub/scm/linux/kernel/git/jarod/linux-2.6-ir.git/
 staging

Andy Walls (13):
  lirc_zilog: Restore checks for existence of the IR_tx object
  lirc_zilog: Remove broken, ineffective reference counting
  lirc_zilog: Convert ir_device instance array to a linked list
  lirc_zilog: Convert the instance open count to an atomic_t
  lirc_zilog: Use kernel standard methods for marking device non-seekable
  lirc_zilog: Don't acquire the rx->buf_lock in the poll() function
  lirc_zilog: Remove unneeded rx->buf_lock
  lirc_zilog: Always allocate a Rx lirc_buffer object
  lirc_zilog: Move constants from ir_probe() into the lirc_driver template
  lirc_zilog: Add ref counting of struct IR, IR_tx, and IR_rx
  lirc_zilog: Add locking of the i2c_clients when in use
  lirc_zilog: Fix somewhat confusing information messages in ir_probe()
  lirc_zilog: Update TODO list based on work completed and revised plans

Jarod Wilson (9):
  docs: fix typo in lirc_device_interface.xml
  imon: add more panel scancode mappings
  hdpvr: i2c master enhancements
  ir-kbd-i2c: pass device code w/key in hauppauge case
  hdpvr: use same polling interval as other OS
  lirc: silence some compile warnings
  lirc_zilog: error out if buffer read bytes != chunk size
  mceusb: topseed 0x0011 needs gen3 init for tx to work
  rc: interim support for 32-bit NEC-ish scancodes

Mauro Carvalho Chehab (14):
  rc/keymaps: use KEY_CAMERA for snapshots
  rc/keymaps: Use KEY_VIDEO for Video Source
  rc/keymaps: Fix most KEY_PROG[n] keycodes
  rc/keymaps: Use KEY_LEFTMETA were pertinent
  dw2102: Use multimedia keys instead of an app-specific mapping
  opera1: Use multimedia keys instead of an app-specific mapping
  a800: Fix a few wrong IR key assignments
  rc-winfast: Fix the keycode tables
  rc-rc5-hauppauge-new: Add the old control to the table
  rc-rc5-hauppauge-new: Add support for the old Black RC
  rc-rc5-hauppauge-new: Fix Hauppauge Grey mapping
  rc/keymaps: Rename Hauppauge table as rc-hauppauge
  remove the old RC_MAP_HAUPPAUGE_NEW RC map
  [media] rc/keymaps: Remove the obsolete rc-rc5-tv keymap

 .../DocBook/v4l/lirc_device_interface.xml  |2 +-
 drivers/media/dvb/dvb-usb/a800.c   |8 +-
 drivers/media/dvb/dvb-usb/digitv.c |2 +-
 drivers/media/dvb/dvb-usb/dw2102.c |   40 +-
 drivers/media/dvb/dvb-usb/opera1.c |   33 +-
 drivers/media/dvb/siano/sms-cards.c|2 +-
 drivers/media/dvb/ttpci/budget-ci.c|   15 +-
 drivers/media/rc/imon.c|   11 +-
 drivers/media/rc/ir-nec-decoder.c  |   10 +-
 drivers/media/rc/keymaps/Makefile  |4 +-
 drivers/media/rc/keymaps/rc-adstech-dvb-t-pci.c|6 +-
 drivers/media/rc/keymaps/rc-avermedia-dvbt.c   |4 +-
 drivers/media/rc/keymaps/rc-avermedia-m135a.c  |2 +-
 .../media/rc/keymaps/rc-avermedia-m733a-rm-k6.c|2 +-
 drivers/media/rc/keymaps/rc-avermedia-rm-ks.c  |2 +-
 drivers/media/rc/keymaps/rc-behold-columbus.c  |2 +-
 drivers/media/rc/keymaps/rc-behold.c   |2 +-
 drivers/media/rc/keymaps/rc-budget-ci-old.c|3 +-
 drivers/media/rc/keymaps/rc-cinergy.c  |2 +-
 drivers/media/rc/keymaps/rc-dntv-live-dvb-t.c  | 

Re: S2-3200 switching-timeouts on 2.6.38

[Manu Abraham]

Hello Rico,

On Tue, Mar 22, 2011 at 5:03 PM, Rico Tzschichholz  wrote:
> Hello Manu,
>
>> Actually, quite a lot of effort was put in to get that part right. It
>> does the reverse thing that's to be done.
>> The revamped version is here [1] If the issue persists still, then it
>> needs to be investigated further.
>>
>> [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html
>
> I am not sure how this is related to stb6100?
>
> Does that mean the current stb0899 patch [2] isnt ready to be proposed
> for 2.6.39 yet? Or does the stb6100 patch has a better design to solve
> this issue which should be adapted for stb0899 then?
> I was hoping to see it included before the merge window is closed again.
>
> [2] https://patchwork.kernel.org/patch/244201/


stb0899 is a channel decoder (or demodulator in other words) while the
stb6100 is a
tuner which provides I-Q components to the demod.

When a tuner locks to a transponder, in the spectrum in the absence of
a signal, it will be contain White (Gaussian) noise. In such a case
the demod has a hard time to lock to the signal. In this particular
case, we had a bit of luck additionally, ie we  found a case where the
stb0899 demodulator functioned perfectly well with another tuner, but
with the same hardware configuration. This helped in narrowing the bug
to the tuner and hence the fix.

The one in patchwork, does modify the step size but that doesn't
reduce the white noise, which is something like a lucky dip. (similar
to what Bjorn pointed out in another post.) I am not really sure
whether modifying the step size of any benefit/disadvantage, but need
to do some research on that aspect.

Best Regards,
Manu
]
--
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 outputs 5555 5555 5555 5555 ...

[Laurent Pinchart]

Hi Bastian,

On Tuesday 22 March 2011 17:11:04 Bastian Hecht wrote:
> Hello omap isp devs,
> 
> maybe you can help me, I am a bit desperate with my current cam problem:
> 
> I use a ov5642 chip and get only 0x55 in my data output when I use a
> camclk > 1 MHz. With 1 MHz data rate from the camera chip to the omap
> all works (well the colorspace is strange - it's greenish, but that is
> not my main concern).
> I looked up the data on the oscilloscope and all flanks seem to be
> fine at the isp. Very clear cuts with 4 MHz and 10MHz. Also the data
> pins are flickering fine. Looks like a picture.
> 
> I found that the isp stats module uses 0x55 as a magic number but I
> don't see why it should confuse my readout.
> 
> I use 2592x1944 raw bayer output via the ccdc. Next to the logical
> right config I tried all possible configurations of vs/hs active high
> and low on camera and isp. The isp gets the vs flanks right as the
> images come out in time (sometimes it misses 1 frame).
> 
> Anyone of you had this behaviour before?

How do you capture images ? yavta will fill buffers with 0x55 before queueing 
them, so this might indicate that no data is written to the buffer at all.

-- 
Regards,

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

Re: [PATCH 5/6] lirc_zilog: error out if buffer read bytes != chunk size

[Jarod Wilson]

On Thu, Mar 17, 2011 at 08:50:33PM -0400, Andy Walls wrote:
> On Thu, 2011-03-17 at 15:08 -0400, Jarod Wilson wrote:
> > On Thu, Mar 17, 2011 at 12:16:31PM -0400, Andy Walls wrote:
> > > Jarod Wilson  wrote:
> > .
> > > 
> > > But the orignal intent of the check I put in was to avoid passing
> > partial/junk data to userspace, and go around again to see if good
> > data could be provided.  
> > > 
> > > Your check bails when good data that might be sitting there still.
> > That doesn't seem like a good trade for supporting backward compat for
> > old kernels.
> > 
> > Ah. Another thing I neglected to notice then. :)
> > 
> > Perhaps there should be a retry count check as well then, as otherwise,
> > its possible to get stuck in that loop forever (which is what was
> > happening on older kernels). Its conceivable that similar could happen on
> > a newer kernel for some reason.
> 
> Well, lets see,
> 
> >From the perspective of userspace & lircd:
> 
> 1. A specification compliance failure for a corner case isn't too bad
> (bailing out on junk and leaving good data behind)
> 
> 2. An unrecoverable failure for any case is very bad (spinning/hanging
> on a result that won't change)
> 
> 3. Sending unitialized bytes out to userspace with copy_to_user() is
> very bad.
> (I recall the old code would do the copy to user and always tell
> userspace it got a code whether it read anything out of the buffer or
> not.  IIRC, that leaked information off the stack.)
> 
> 
> If the code as patched avoids the two very bad things (#2 and #3), then
> the patch is OK by me.

I *think* what I've got now should address both 2 and 3, with a very
minimal risk of leaving data behind, since it'll retry a couple of times
before bailing out of the loop, so it should be pretty unlikely we'd leave
any good data behind. But even if we do, like you said, this is just an IR
signal, the user can press the button on the remote again. :)

-- 
Jarod Wilson
ja...@redhat.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: S2-3200 switching-timeouts on 2.6.38

[Manu Abraham]

On Tue, Mar 22, 2011 at 3:23 PM, Bjørn Mork  wrote:
> Manu Abraham  writes:
>> On Tue, Mar 22, 2011 at 1:46 AM, Randy Dunlap  wrote:
>>> On Mon, 21 Mar 2011 20:46:23 +0100 Rico Tzschichholz wrote:
>>>
 Hello,

 I would like to know if there is any intention to include this patch
 soon? https://patchwork.kernel.org/patch/244201/
>>>
>>> There are MANY posted but unmerged patches in patchwork from the linux-media
>>> mailing list.  What is going on (or not going on) with patch merging?
>>
>> Actually, quite a lot of effort was put in to get that part right. It
>> does the reverse thing that's to be done.
>> The revamped version is here [1] If the issue persists still, then it
>> needs to be investigated further.
>>
>> [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html
>
> So the patch state should be "Rejected" and not "Under Review".
>
> Would certainly help us all if the patchwork state was updated whenever
> a patch actually was processed...

Sure, I could've pointed it out to Mauro, but handling multiple
things, that slipped off my mind.

Best Regards,
Manu
--
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/6] get rid of on-stack dma buffers

[David Miller]

From: James Bottomley 
Date: Tue, 22 Mar 2011 08:35:04 -0500

> The API will round up so that the correct region covers the API.
> However, if you have other structures packed into the space (as very
> often happens on stack), you get cache line interference in the CPU if
> they get accessed:  The act of accessing an adjacent object pulls in
> cache above your object and destroys DMA coherence.  This is the
> principle reason why DMA to stack is a bad idea.

Another major real reason we can't DMA on-stack stuff is because the
stack is mapped virtually on some platforms.

And that is the original reason the restriction was put in place.
--
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

Analog input for Hauppauge express-card HVR-1400

[Emil Meier]

In the attached files I have added some code for the analog part of a HVR-1400 
card. (The patch is taken from a patch for HVR1800..)
Until now only the composite video input is functional. 
The s-video input captures only the b&w part of the video.
The patch in cx25840-core.c was needed to get PAL support for the video input. 
If the line
cx25840_write(client, 0x2, 0x76);
is needed by other cards, the skipping should depend on the card-name... but I 
don't know how I can get the card-model in this module...

Maybe this helps someone else in using the analog part of this card.

Emil


  *** ./drivers/media/video/cx23885/cx23885-cards.c~	2011-02-18 00:14:38.0 +0100
--- ./drivers/media/video/cx23885/cx23885-cards.c	2011-03-09 11:53:05.0 +0100
***
*** 154,160 
--- 154,183 
  	},
  	[CX23885_BOARD_HAUPPAUGE_HVR1400] = {
  		.name		= "Hauppauge WinTV-HVR1400",
+ 		.porta  = CX23885_ANALOG_VIDEO,
  		.portc		= CX23885_MPEG_DVB,
+ 		.tuner_type = TUNER_XC2028,
+ 		.tuner_addr = 0x61, /* 0x84 >> 1 */
+ 		.input  = {{
+ 		 .type   = CX23885_VMUX_TELEVISION,
+ 		 .vmux   =   CX25840_VIN7_CH3 |
+ 		 CX25840_VIN5_CH2 |
+ 		 CX25840_VIN2_CH1,
+ 		 .gpio0  = 0,
+ 		   }, {
+ 		 .type   = CX23885_VMUX_COMPOSITE1,
+ 		 .vmux   =   CX25840_VIN7_CH3 |
+ 		 CX25840_VIN4_CH2 |
+ 		 CX25840_VIN6_CH1,
+ 		 .gpio0  = 0,
+ 		   }, {
+ 		 .type   = CX23885_VMUX_SVIDEO,
+ 		 .vmux   =   CX25840_VIN7_CH3 |
+ 		 CX25840_VIN4_CH2 |
+ 		 CX25840_VIN8_CH1 |
+ 		 CX25840_SVIDEO_ON,
+ 		 .gpio0  = 0,
+ 	   	   } },
  	},
  	[CX23885_BOARD_DVICO_FUSIONHDTV_7_DUAL_EXP] = {
  		.name		= "DViCO FusionHDTV7 Dual Express",
***
*** 1245,1250 
--- 1268,1274 
  	case CX23885_BOARD_MAGICPRO_PROHDTVE2:
  	case CX23885_BOARD_HAUPPAUGE_HVR1290:
  	case CX23885_BOARD_LEADTEK_WINFAST_PXTV1200:
+ 	case CX23885_BOARD_HAUPPAUGE_HVR1400:
  		dev->sd_cx25840 = v4l2_i2c_new_subdev(&dev->v4l2_dev,
  &dev->i2c_bus[2].i2c_adap,
  "cx25840", "cx25840", 0x88 >> 1, NULL);
*** ./drivers/media/video/cx25840/cx25840-core.c~	2011-02-18 00:14:38.0 +0100
--- ./drivers/media/video/cx25840/cx25840-core.c	2011-03-09 11:54:24.0 +0100
***
*** 654,660 
  
  	/* Trust the default xtal, no division */
  	/* This changes for the cx23888 products */
! 	cx25840_write(client, 0x2, 0x76);
  
  	/* Bring down the regulator for AUX clk */
  	cx25840_write(client, 0x1, 0x40);
--- 654,661 
  
  	/* Trust the default xtal, no division */
  	/* This changes for the cx23888 products */
! 	// not for hvr1400 em 090818
! 	//cx25840_write(client, 0x2, 0x76);
  
  	/* Bring down the regulator for AUX clk */
  	cx25840_write(client, 0x1, 0x40);

[cron job] v4l-dvb daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Tue Mar 22 19:00:37 CET 2011
git hash:e359f4fd5b990576d6322a38658ad0f0abe177c9
gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: OK
linux-git-armv5-davinci: OK
linux-git-armv5-ixp: OK
linux-git-armv5-omap2: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-x86_64: OK
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: ERRORS
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.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: ERRORS
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
spec-git: OK
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: [RFC PATCH 4/3] remove radio-maestro

[Hans Verkuil]

On Saturday, March 19, 2011 17:23:47 Ondrej Zary wrote:
> Remove broken radio-maestro driver as the radio functionality is now
> integrated in the es1968 driver.
> 
> Signed-off-by: Ondrej Zary 

Acked-by: Hans Verkuil 

Also for patches 2 & 3 :-)

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: [RFC PATCH 1/3] tea575x-tuner: various improvements

[Hans Verkuil]

On Saturday, March 19, 2011 16:32:53 Ondrej Zary wrote:
> Improve tea575x-tuner with various good things from radio-maestro:
> - extend frequency range to 50-150MHz
> - fix querycap(): card name, CAP_RADIO
> - improve g_tuner(): CAP_STEREO, stereo and tuned indication
> - improve g_frequency(): tuner index checking and reading frequency from HW
> - improve s_frequency(): tuner index and type checking
> 
> Signed-off-by: Ondrej Zary 

Acked-by: Hans Verkuil 

BTW, can you run the v4l2-compliance utility for the two boards that use
this radio tuner?

This utility is part of the v4l-utils repository 
(http://git.linuxtv.org/v4l-utils.git).

Run as 'v4l2-compliance -r /dev/radioX -v2'.

I'm sure there will be some errors/warnings (warnings regarding G/S_PRIORITY
are to be expected). But I can use it to make a patch for 2.6.40 that fixes
any issues.

Regards,

Hans

> 
> --- linux-2.6.38-rc4-orig/sound/i2c/other/tea575x-tuner.c 2011-02-08 
> 01:03:55.0 +0100
> +++ linux-2.6.38-rc4/sound/i2c/other/tea575x-tuner.c  2011-03-19 
> 15:40:14.0 +0100
> @@ -37,8 +37,8 @@ static int radio_nr = -1;
>  module_param(radio_nr, int, 0);
>  
>  #define RADIO_VERSION KERNEL_VERSION(0, 0, 2)
> -#define FREQ_LO   (87 * 16000)
> -#define FREQ_HI  (108 * 16000)
> +#define FREQ_LO   (50UL * 16000)
> +#define FREQ_HI  (150UL * 16000)
>  
>  /*
>   * definitions
> @@ -77,15 +77,29 @@ static struct v4l2_queryctrl radio_qctrl
>   * lowlevel part
>   */
>  
> +static void snd_tea575x_get_freq(struct snd_tea575x *tea)
> +{
> + unsigned long freq;
> +
> + freq = tea->ops->read(tea) & TEA575X_BIT_FREQ_MASK;
> + /* freq *= 12.5 */
> + freq *= 125;
> + freq /= 10;
> + /* crystal fixup */
> + if (tea->tea5759)
> + freq += tea->freq_fixup;
> + else
> + freq -= tea->freq_fixup;
> +
> + tea->freq = freq * 16;  /* from kHz */
> +}
> +
>  static void snd_tea575x_set_freq(struct snd_tea575x *tea)
>  {
>   unsigned long freq;
>  
> - freq = tea->freq / 16;  /* to kHz */
> - if (freq > 108000)
> - freq = 108000;
> - if (freq < 87000)
> - freq = 87000;
> + freq = clamp(tea->freq, FREQ_LO, FREQ_HI);
> + freq /= 16; /* to kHz */
>   /* crystal fixup */
>   if (tea->tea5759)
>   freq -= tea->freq_fixup;
> @@ -109,29 +123,33 @@ static int vidioc_querycap(struct file *
>  {
>   struct snd_tea575x *tea = video_drvdata(file);
>  
> - strcpy(v->card, tea->tea5759 ? "TEA5759" : "TEA5757");
>   strlcpy(v->driver, "tea575x-tuner", sizeof(v->driver));
> - strlcpy(v->card, "Maestro Radio", sizeof(v->card));
> + strlcpy(v->card, tea->tea5759 ? "TEA5759" : "TEA5757", sizeof(v->card));
>   sprintf(v->bus_info, "PCI");
>   v->version = RADIO_VERSION;
> - v->capabilities = V4L2_CAP_TUNER;
> + v->capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
>   return 0;
>  }
>  
>  static int vidioc_g_tuner(struct file *file, void *priv,
>   struct v4l2_tuner *v)
>  {
> + struct snd_tea575x *tea = video_drvdata(file);
> +
>   if (v->index > 0)
>   return -EINVAL;
>  
> + tea->ops->read(tea);
> +
>   strcpy(v->name, "FM");
>   v->type = V4L2_TUNER_RADIO;
> + v->capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
>   v->rangelow = FREQ_LO;
>   v->rangehigh = FREQ_HI;
> - v->rxsubchans = V4L2_TUNER_SUB_MONO|V4L2_TUNER_SUB_STEREO;
> - v->capability = V4L2_TUNER_CAP_LOW;
> - v->audmode = V4L2_TUNER_MODE_MONO;
> - v->signal = 0x;
> + v->rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO;
> + v->audmode = tea->stereo ? V4L2_TUNER_MODE_STEREO : 
> V4L2_TUNER_MODE_MONO;
> + v->signal = tea->tuned ? 0x : 0;
> +
>   return 0;
>  }
>  
> @@ -148,7 +166,10 @@ static int vidioc_g_frequency(struct fil
>  {
>   struct snd_tea575x *tea = video_drvdata(file);
>  
> + if (f->tuner != 0)
> + return -EINVAL;
>   f->type = V4L2_TUNER_RADIO;
> + snd_tea575x_get_freq(tea);
>   f->frequency = tea->freq;
>   return 0;
>  }
> @@ -158,6 +179,9 @@ static int vidioc_s_frequency(struct fil
>  {
>   struct snd_tea575x *tea = video_drvdata(file);
>  
> + if (f->tuner != 0 || f->type != V4L2_TUNER_RADIO)
> + return -EINVAL;
> +
>   if (f->frequency < FREQ_LO || f->frequency > FREQ_HI)
>   return -EINVAL;
>  
> --- linux-2.6.38-rc4-orig/include/sound/tea575x-tuner.h   2011-02-08 
> 01:03:55.0 +0100
> +++ linux-2.6.38-rc4/include/sound/tea575x-tuner.h2011-03-19 
> 14:18:06.0 +0100
> @@ -38,8 +38,10 @@ struct snd_tea575x {
>   struct snd_card *card;
>   struct video_device *vd;/* video device */
>   int dev_nr; /* requested device number + 1 */
> - int tea5759;/* 575

New Signed-off-by and copyright starting with 2.6.40

[Hans Verkuil]

Hi all,

Just a short announcement that starting with 2.6.40 any V4L work I do will
have a Cisco Signed-of-by line and Cisco copyright instead of my regular email
and personal copyright.

Until recently all the V4L work I did was separate (although sponsored) from
my normal job at Cisco, but those boundaries were getting very murky indeed.

So to simplify things I'll be switching over to a Cisco SoB and copyright for
any future patches. This also means that this work is no longer sponsored but
that it is now part of my regular job.

I'll miss that 'sponsored by' signature :-)

There are no other changes, this is just a formality.

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: Prof_Revolution_DVB-S2_8000_PCI-E & Linux Kernel 2.6.38-rc8-next-20110314

[Mauro Carvalho Chehab]

Em 20-03-2011 16:32, Wojciech Myrda escreveu:

> It turns ot that revised patch not only applies cleanly but compiles as
> well agaist Linux Kernel 2.6.38-rc8-next-20110321. Looking at dmesg
> everything is recognized properly as well. Do you guys think if it is
> possible to include it into the tree?

Please post the patch again, with a few fixes (see bellow), and add your
Signed-off-by: (please read how to submit patches section at linuxtv.org wiki
for more details). 


> diff -r 1da5fed5c8b2 linux/drivers/media/video/cx23885/cx23885-cards.c
> --- a/linux/drivers/media/video/cx23885/cx23885-cards.c   Sun Sep 19 
> 02:23:09 2010 -0300
> +++ b/linux/drivers/media/video/cx23885/cx23885-cards.c   Sat Oct 02 
> 11:19:50 2010 +0300

/linux? Are you using the old -hg tree? Please don't do that. The mercurial
tree is not touched for the last 8 months! Please use, instead the 
media_tree.git
(media_build.git allows you to compile/test a driver against the media_tree.git 
tree). 

> @@ -169,6 +169,10 @@
>   .name   = "TurboSight TBS 6920",
>   .portb  = CX23885_MPEG_DVB,
>   },
> + [CX23885_BOARD_PROF_8000] = {
> + .name   = "Prof Revolution DVB-S2 8000",
> + .portb  = CX23885_MPEG_DVB,
> + },
>   [CX23885_BOARD_TEVII_S470] = {
>   .name   = "TeVii S470",
>   .portb  = CX23885_MPEG_DVB,
> @@ -388,6 +392,10 @@
>   .subdevice = 0x,
>   .card  = CX23885_BOARD_TBS_6920,
>   }, {
> + .subvendor = 0x8000,
> + .subdevice = 0x3034,
> + .card  = CX23885_BOARD_PROF_8000,
> + }, {
>   .subvendor = 0xd470,
>   .subdevice = 0x9022,
>   .card  = CX23885_BOARD_TEVII_S470,
> @@ -813,6 +821,7 @@
>   mdelay(20);
>   cx_set(GP0_IO, 0x00040004);
>   break;
> + case CX23885_BOARD_PROF_8000:
>   case CX23885_BOARD_TBS_6920:
>   cx_write(MC417_CTL, 0x0036);
>   cx_write(MC417_OEN, 0x1000);
> @@ -1043,6 +1052,7 @@
>   ts1->ts_clk_en_val = 0x1; /* Enable TS_CLK */
>   ts1->src_sel_val   = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO;
>   break;
> + case CX23885_BOARD_PROF_8000:
>   case CX23885_BOARD_TEVII_S470:
>   case CX23885_BOARD_DVBWORLD_2005:
>   ts1->gen_ctrl_val  = 0x5; /* Parallel */
> --- a/linux/drivers/media/video/cx23885/cx23885-dvb.c.old 2011-03-20 
> 08:20:37.384001338 +0100
> +++ b/linux/drivers/media/video/cx23885/cx23885-dvb.c 2011-03-20 
> 08:29:56.757001476 +0100
> @@ -47,6 +47,9 @@
>  #include "dibx000_common.h"
>  #include "zl10353.h"
>  #include "stv0900.h"
> +#include "stb6100.h"
> +#include "stb6100_proc.h"
> +#include "stv0900.h"

If you're adding more dependencies here, you'll need to touch also 
drivers/media/video/cx23885/Kconfig
in order to select the right frontends.

>  #include "stv0900_reg.h"
>  #include "stv6110.h"
>  #include "lnbh24.h"
> @@ -478,6 +478,35 @@
>   .if_khz = 5380,
>  };
>  
> +static int p8000_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t 
> voltage)
> +{
> + struct cx23885_tsport *port = fe->dvb->priv;
> + struct cx23885_dev *dev = port->dev;
> +
> + if (voltage == SEC_VOLTAGE_18)
> + cx_write(MC417_RWD, 0x1e00);
> + else if (voltage == SEC_VOLTAGE_13)
> + cx_write(MC417_RWD, 0x1a00);
> + else
> + cx_write(MC417_RWD, 0x1800);
> + return 0;
> +}
> +
> +static struct stv0900_config prof_8000_stv0900_config = {
> + .demod_address = 0x6a,
> + .xtal = 2700,
> + .clkmode = 3,
> + .diseqc_mode = 2,
> + .tun1_maddress = 0,
> + .tun1_adc = 0,
> + .path1_mode = 3,
> +};
> +
> +static struct stb6100_config prof_8000_stb6100_config = {
> + .tuner_address = 0x60,
> + .refclock = 2700,
> +};
> +
>  static int cx23885_dvb_set_frontend(struct dvb_frontend *fe,
>   struct dvb_frontend_parameters *param)
>  {
> @@ -1094,6 +1123,29 @@
>   goto frontend_detach;
>   }
>   break;
> + case CX23885_BOARD_PROF_8000: {
> + struct dvb_tuner_ops *tuner_ops = NULL;
> +
> + i2c_bus = &dev->i2c_bus[0];
> + fe0->dvb.frontend = dvb_attach(stv0900_attach,
> + &prof_8000_stv0900_config,
> + &i2c_bus->i2c_adap, 0);
> + if (fe0->dvb.frontend != NULL) {
> + if (dvb_attach(stb6100_attach, fe0->dvb.frontend,
> + &prof_8000_stb6100_config,
> + &i2c_bus->i2c_adap)) {
> + tuner_ops = &fe0->dvb.frontend->ops.tuner_ops;
> + tuner_ops->set_frequency = st

Re: [RFC PATCH 4/3] remove radio-maestro

[Mauro Carvalho Chehab]

Hi Takashi,

Em 19-03-2011 13:23, Ondrej Zary escreveu:
> Remove broken radio-maestro driver as the radio functionality is now
> integrated in the es1968 driver.

I prefer if you could also add it on your tree, as we want to make sure that
this patch will be applied together with the patches that moved Maestro
support into the es1968 driver.

I have no means to test if the es1968 changes work with a Maestro radio (as I
don't have this hardware), but I'm OK with this change. So:

Acked-by: Mauro Carvalho Chehab 

> 
> Signed-off-by: Ondrej Zary 
> 
> diff -urNp linux-2.6.38-rc4-orig/drivers/media/radio/Kconfig 
> linux-2.6.38-rc4/drivers/media/radio/Kconfig
> --- linux-2.6.38-rc4-orig/drivers/media/radio/Kconfig 2011-02-08 
> 01:03:55.0 +0100
> +++ linux-2.6.38-rc4/drivers/media/radio/Kconfig  2011-03-19 
> 17:12:32.0 +0100
> @@ -166,21 +166,6 @@ config RADIO_MAXIRADIO
> To compile this driver as a module, choose M here: the
> module will be called radio-maxiradio.
>  
> -config RADIO_MAESTRO
> - tristate "Maestro on board radio"
> - depends on VIDEO_V4L2 && PCI
> - ---help---
> -   Say Y here to directly support the on-board radio tuner on the
> -   Maestro 2 or 2E sound card.
> -
> -   In order to control your radio card, you will need to use programs
> -   that are compatible with the Video For Linux API.  Information on
> -   this API and pointers to "v4l" programs may be found at
> -   .
> -
> -   To compile this driver as a module, choose M here: the
> -   module will be called radio-maestro.
> -
>  config RADIO_MIROPCM20
>   tristate "miroSOUND PCM20 radio"
>   depends on ISA && VIDEO_V4L2 && SND
> diff -urNp linux-2.6.38-rc4-orig/drivers/media/radio/Makefile 
> linux-2.6.38-rc4/drivers/media/radio/Makefile
> --- linux-2.6.38-rc4-orig/drivers/media/radio/Makefile2011-02-08 
> 01:03:55.0 +0100
> +++ linux-2.6.38-rc4/drivers/media/radio/Makefile 2011-03-19 
> 17:12:39.0 +0100
> @@ -16,7 +16,6 @@ obj-$(CONFIG_RADIO_GEMTEK) += radio-gemt
>  obj-$(CONFIG_RADIO_TRUST) += radio-trust.o
>  obj-$(CONFIG_I2C_SI4713) += si4713-i2c.o
>  obj-$(CONFIG_RADIO_SI4713) += radio-si4713.o
> -obj-$(CONFIG_RADIO_MAESTRO) += radio-maestro.o
>  obj-$(CONFIG_RADIO_MIROPCM20) += radio-miropcm20.o
>  obj-$(CONFIG_USB_DSBR) += dsbr100.o
>  obj-$(CONFIG_RADIO_SI470X) += si470x/
> diff -urNp linux-2.6.38-rc4-orig/drivers/media/radio/radio-maestro.c 
> linux-2.6.38-rc4/drivers/media/radio/radio-maestro.c
> --- linux-2.6.38-rc4-orig/drivers/media/radio/radio-maestro.c 2011-02-08 
> 01:03:55.0 +0100
> +++ linux-2.6.38-rc4/drivers/media/radio/radio-maestro.c  1970-01-01 
> 01:00:00.0 +0100
> @@ -1,452 +0,0 @@
> -/* Maestro PCI sound card radio driver for Linux support
> - * (c) 2000 A. Tlalka, at...@pg.gda.pl
> - * Notes on the hardware
> - *
> - *  + Frequency control is done digitally
> - *  + No volume control - only mute/unmute - you have to use Aux line volume
> - *  control on Maestro card to set the volume
> - *  + Radio status (tuned/not_tuned and stereo/mono) is valid some time after
> - *  frequency setting (>100ms) and only when the radio is unmuted.
> - *  version 0.02
> - *  + io port is automatically detected - only the first radio is used
> - *  version 0.03
> - *  + thread access locking additions
> - *  version 0.04
> - * + code improvements
> - * + VIDEO_TUNER_LOW is permanent
> - *
> - * Converted to V4L2 API by Mauro Carvalho Chehab 
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include   /* for KERNEL_VERSION MACRO */
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -MODULE_AUTHOR("Adam Tlalka, at...@pg.gda.pl");
> -MODULE_DESCRIPTION("Radio driver for the Maestro PCI sound card radio.");
> -MODULE_LICENSE("GPL");
> -
> -static int radio_nr = -1;
> -module_param(radio_nr, int, 0);
> -
> -#define RADIO_VERSION KERNEL_VERSION(0, 0, 6)
> -#define DRIVER_VERSION   "0.06"
> -
> -#define GPIO_DATA0x60   /* port offset from ESS_IO_BASE */
> -
> -#define IO_MASK  4  /* mask  register offset from 
> GPIO_DATA
> - bits 1=unmask write to given bit */
> -#define IO_DIR   8  /* direction register offset from 
> GPIO_DATA
> - bits 0/1=read/write direction */
> -
> -#define GPIO60x0040 /* mask bits for GPIO lines */
> -#define GPIO70x0080
> -#define GPIO80x0100
> -#define GPIO90x0200
> -
> -#define STR_DATA GPIO6  /* radio TEA5757 pins and GPIO bits */
> -#define STR_CLK  GPIO7
> -#define STR_WREN GPIO8
> -#define STR_MOST GPIO9
> -
> -#define FREQ_LO   50*16000
> -#define FREQ_HI  150*16000
> -
> -#define FREQ_IF  171200 /* 10.7*16000   */
> -#define FREQ_STEP200/* 12.5*16  */
> -
> -#define FREQ2BI

Re: [RFC PATCH 1/3] tea575x-tuner: various improvements

[Mauro Carvalho Chehab]

Em 21-03-2011 08:48, Takashi Iwai escreveu:
> At Sat, 19 Mar 2011 16:32:53 +0100,
> Ondrej Zary wrote:
>>
>> Improve tea575x-tuner with various good things from radio-maestro:
>> - extend frequency range to 50-150MHz
>> - fix querycap(): card name, CAP_RADIO
>> - improve g_tuner(): CAP_STEREO, stereo and tuned indication
>> - improve g_frequency(): tuner index checking and reading frequency from HW
>> - improve s_frequency(): tuner index and type checking
>>
>> Signed-off-by: Ondrej Zary 
> 
> Applied these 3 patches now to topic/misc branch of sound git tree
> (i.e. for 2.6.40 kernel).

Patches look sane to me, you may add my ACK if you want.

Acked-by: Mauro Carvalho Chehab 

> 
> I leave the removal of radio-maestro to v4l guys, as this is fairly
> independent.
> 
> 
> thanks,
> 
> Takashi
> 
> 
>> --- linux-2.6.38-rc4-orig/sound/i2c/other/tea575x-tuner.c2011-02-08 
>> 01:03:55.0 +0100
>> +++ linux-2.6.38-rc4/sound/i2c/other/tea575x-tuner.c 2011-03-19 
>> 15:40:14.0 +0100
>> @@ -37,8 +37,8 @@ static int radio_nr = -1;
>>  module_param(radio_nr, int, 0);
>>  
>>  #define RADIO_VERSION KERNEL_VERSION(0, 0, 2)
>> -#define FREQ_LO  (87 * 16000)
>> -#define FREQ_HI (108 * 16000)
>> +#define FREQ_LO  (50UL * 16000)
>> +#define FREQ_HI (150UL * 16000)
>>  
>>  /*
>>   * definitions
>> @@ -77,15 +77,29 @@ static struct v4l2_queryctrl radio_qctrl
>>   * lowlevel part
>>   */
>>  
>> +static void snd_tea575x_get_freq(struct snd_tea575x *tea)
>> +{
>> +unsigned long freq;
>> +
>> +freq = tea->ops->read(tea) & TEA575X_BIT_FREQ_MASK;
>> +/* freq *= 12.5 */
>> +freq *= 125;
>> +freq /= 10;
>> +/* crystal fixup */
>> +if (tea->tea5759)
>> +freq += tea->freq_fixup;
>> +else
>> +freq -= tea->freq_fixup;
>> +
>> +tea->freq = freq * 16;  /* from kHz */
>> +}
>> +
>>  static void snd_tea575x_set_freq(struct snd_tea575x *tea)
>>  {
>>  unsigned long freq;
>>  
>> -freq = tea->freq / 16;  /* to kHz */
>> -if (freq > 108000)
>> -freq = 108000;
>> -if (freq < 87000)
>> -freq = 87000;
>> +freq = clamp(tea->freq, FREQ_LO, FREQ_HI);
>> +freq /= 16; /* to kHz */
>>  /* crystal fixup */
>>  if (tea->tea5759)
>>  freq -= tea->freq_fixup;
>> @@ -109,29 +123,33 @@ static int vidioc_querycap(struct file *
>>  {
>>  struct snd_tea575x *tea = video_drvdata(file);
>>  
>> -strcpy(v->card, tea->tea5759 ? "TEA5759" : "TEA5757");
>>  strlcpy(v->driver, "tea575x-tuner", sizeof(v->driver));
>> -strlcpy(v->card, "Maestro Radio", sizeof(v->card));
>> +strlcpy(v->card, tea->tea5759 ? "TEA5759" : "TEA5757", sizeof(v->card));
>>  sprintf(v->bus_info, "PCI");
>>  v->version = RADIO_VERSION;
>> -v->capabilities = V4L2_CAP_TUNER;
>> +v->capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
>>  return 0;
>>  }
>>  
>>  static int vidioc_g_tuner(struct file *file, void *priv,
>>  struct v4l2_tuner *v)
>>  {
>> +struct snd_tea575x *tea = video_drvdata(file);
>> +
>>  if (v->index > 0)
>>  return -EINVAL;
>>  
>> +tea->ops->read(tea);
>> +
>>  strcpy(v->name, "FM");
>>  v->type = V4L2_TUNER_RADIO;
>> +v->capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
>>  v->rangelow = FREQ_LO;
>>  v->rangehigh = FREQ_HI;
>> -v->rxsubchans = V4L2_TUNER_SUB_MONO|V4L2_TUNER_SUB_STEREO;
>> -v->capability = V4L2_TUNER_CAP_LOW;
>> -v->audmode = V4L2_TUNER_MODE_MONO;
>> -v->signal = 0x;
>> +v->rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO;
>> +v->audmode = tea->stereo ? V4L2_TUNER_MODE_STEREO : 
>> V4L2_TUNER_MODE_MONO;
>> +v->signal = tea->tuned ? 0x : 0;
>> +
>>  return 0;
>>  }
>>  
>> @@ -148,7 +166,10 @@ static int vidioc_g_frequency(struct fil
>>  {
>>  struct snd_tea575x *tea = video_drvdata(file);
>>  
>> +if (f->tuner != 0)
>> +return -EINVAL;
>>  f->type = V4L2_TUNER_RADIO;
>> +snd_tea575x_get_freq(tea);
>>  f->frequency = tea->freq;
>>  return 0;
>>  }
>> @@ -158,6 +179,9 @@ static int vidioc_s_frequency(struct fil
>>  {
>>  struct snd_tea575x *tea = video_drvdata(file);
>>  
>> +if (f->tuner != 0 || f->type != V4L2_TUNER_RADIO)
>> +return -EINVAL;
>> +
>>  if (f->frequency < FREQ_LO || f->frequency > FREQ_HI)
>>  return -EINVAL;
>>  
>> --- linux-2.6.38-rc4-orig/include/sound/tea575x-tuner.h  2011-02-08 
>> 01:03:55.0 +0100
>> +++ linux-2.6.38-rc4/include/sound/tea575x-tuner.h   2011-03-19 
>> 14:18:06.0 +0100
>> @@ -38,8 +38,10 @@ struct snd_tea575x {
>>  struct snd_card *card;
>>  struct video_device *vd;/* video device */
>>  int dev_nr; /* requested device number + 1 */
>> -int tea5759;/* 5759 chip is present */
>> -  

Re: [patch] Fix AF9015 Dual tuner i2c write failures

[Mauro Carvalho Chehab]

Em 22-03-2011 15:26, adq escreveu:
> On 22 March 2011 09:00, Mauro Carvalho Chehab  wrote:
>> Em 04-03-2011 20:11, Andrew de Quincey escreveu:
>>> On 4 March 2011 22:59, Antti Palosaari  wrote:
 On 03/05/2011 12:44 AM, Andrew de Quincey wrote:
>>>
>>> Adding a "bus lock" to af9015_i2c_xfer() will not work as demod/tuner
>>> accesses will take multiple i2c transactions.
>>>
>>> Therefore, the following patch overrides the dvb_frontend_ops
>>> functions to add a per-device lock around them: only one frontend can
>>> now use the i2c bus at a time. Testing with the scripts above shows
>>> this has eliminated the errors.
>>
>> This have annoyed me too, but since it does not broken functionality much
>> I
>> haven't put much effort for fixing it. I like that fix since it is in
>> AF9015
>> driver where it logically belongs to. But it looks still rather complex.
>> I
>> see you have also considered "bus lock" to af9015_i2c_xfer() which could
>> be
>> much smaller in code size (that's I have tried to implement long time
>> back).
>>
>> I would like to ask if it possible to check I2C gate open / close inside
>> af9015_i2c_xfer() and lock according that? Something like:
>
> Hmm, I did think about that, but I felt overriding the functions was
> just cleaner: I felt it was more obvious what it was doing. Doing
> exactly this sort of tweaking was one of the main reasons we added
> that function overriding feature.
>
> I don't like the idea of returning "error locked by FE" since that'll
> mean the tuning will randomly fail sometimes in a way visible to
> userspace (unless we change the core dvb_frontend code), which was one
> of the things I was trying to avoid. Unless, of course, I've
> misunderstood your proposal.

 Not returning error, but waiting in lock like that:
 if (mutex_lock_interruptible(&d->i2c_mutex) < 0)
  return -EAGAIN;
>>>
>>> Ah k, sorry
>>>
> However, looking at the code again, I realise it is possible to
> simplify it. Since its only the demod gates that cause a problem, we
> only /actually/ need to lock the get_frontend() and set_frontend()
> calls.

 I don't understand why .get_frontend() causes problem, since it does not
 access tuner at all. It only reads demod registers. The main problem is
 (like schema in af9015.c shows) that there is two tuners on same I2C bus
 using same address. And demod gate is only way to open access for desired
 tuner only.
>>>
>>> AFAIR /some/ tuner code accesses the tuner hardware to read the exact
>>> tuned frequency back on a get_frontend(); was just being extra
>>> paranoid :)
>>>
 You should block traffic based of tuner not demod. And I think those
 callbacks which are needed for override are tuner driver callbacks. 
 Consider
 situation device goes it v4l-core calls same time both tuner .sleep() ==
 problem.
>>>
>>> Hmm, yeah, you're right, let me have another look tomorrow.
>>
>> Andrew, Antti,
>>
>> I'm understanding that I should wait for another patch on this subject, 
>> right?
>> Please let me know when you have a patch ready for me to apply.
>>
>> Btw, I think that the long term solution would be, instead, to provide some 
>> sort of
>> resource locking inside DVB (and V4L) core. I have here 3 devices not 
>> supported yet that
>> uses the same tuner (and the same demod - DRX-K) for both DVB-C and DVB-T. 
>> It would
>> be a way better to use some core-provided solution to prevent that both 
>> DVB-C and DVB-T
>> would be used at the same time on such devices, instead of cloning the same 
>> code
>> (or modified versions on it) on each driver that have such issues.
>>
>> One solution could be to have a callback like:
>>
>> enum dvb_fe_lock_type {
>>ATV_DEMOD_LOCK,
>>DTV_DEMOD_T_LOCK,
>>DTV_DEMOD_S_LOCK,
>>DTV_DEMOD_C_LOCK,
>>TUNER_T_LOCK,
>>TUNER_S_LOCK,
>>TUNER_C_LOCK,
>>TUNER_FM_LOCK,
>>FM_DEMOD_LOCK,
>> };
>>
>> /**
>>  * dvb_fe_lock - locks a frontend resource
>>  * @fe: DVB frontend struct
>>  * @type:   type of resource to lock
>>  * @lock:   true indicates to lock the resource, false to unlock
>>  *
>>  * Returns true if the resource was locked, false otherwise.
>>  * routine may wait for a pending transaction to happen before returning.
>>  */
>> bool (*dvb_fe_lock)(struct dvb_frontend *fe, enum dvb_fe_lock_type type, 
>> bool lock);
>>
>> What do you think?
> 
> Have to think on it, but it does sound sensible to do it in the core
> if there are other things like this.

Yes, but the current way it is done right now (e. g. the "standard" i2c gate
control) is not fitting anymore. There are tons of cases where it is not 
covered,
and several different implementations to work around it. On complex devices like
cx231xx (that has 4 I2C buses, one of them with

Re: [RFC PATCH] HDMI:Support for EDID parsing in kernel.

[Alex Deucher]

Adding dri-devel.

On Tue, Mar 22, 2011 at 1:32 PM, Mythri P K  wrote:
> Adding support for common EDID parsing in kernel.
>
> EDID - Extended display identification data is a data structure provided by
> a digital display to describe its capabilities to a video source, This a
> standard supported by CEA and VESA.
>
> There are several custom implementations for parsing EDID in kernel, some
> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
> parsing of EDID should be done in a library, which is agnostic of the
> framework (V4l2, DRM, FB)  which is using the functionality, just based on
> the raw EDID pointer with size/segment information.
>
> With other RFC's such as the one below, which tries to standardize HDMI API's
> It would be better to have a common EDID code in one place.It also helps to
> provide better interoperability with variety of TV/Monitor may be even by
> listing out quirks which might get missed with several custom implementation
> of EDID.
> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
>
> This patch tries to add functions to parse some portion EDID (detailed timing,
> monitor limits, AV delay information, deep color mode support, Audio and VSDB)
> If we can align on this library approach i can enhance this library to parse
> other blocks and probably we could also add quirks from other implementation
> as well.
>
> Signed-off-by: Mythri P K 
> ---
>  arch/arm/include/asm/edid.h |  243 ++
>  drivers/video/edid.c        |  340 
> +++
>  2 files changed, 583 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/include/asm/edid.h
>  create mode 100644 drivers/video/edid.c
>
> diff --git a/arch/arm/include/asm/edid.h b/arch/arm/include/asm/edid.h
> new file mode 100644
> index 000..843346a
> --- /dev/null
> +++ b/arch/arm/include/asm/edid.h
> @@ -0,0 +1,243 @@
> +/*
> + * edid.h
> + *
> + * Copyright (C) 2011 Texas Instruments
> + * Author: Mythri P K 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + * History:
> + */
> +
> +#ifndef _EDID_H_
> +#define _EDID_H_
> +
> +/* HDMI EDID Length */
> +#define HDMI_EDID_MAX_LENGTH                   512
> +
> +/* HDMI EDID Extension Data Block Tags  */
> +#define HDMI_EDID_EX_DATABLOCK_TAG_MASK                0xE0
> +#define HDMI_EDID_EX_DATABLOCK_LEN_MASK                0x1F
> +
> +#define EDID_TIMING_DESCRIPTOR_SIZE            0x12
> +#define EDID_DESCRIPTOR_BLOCK0_ADDRESS         0x36
> +#define EDID_DESCRIPTOR_BLOCK1_ADDRESS         0x80
> +#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR     4
> +#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR     4
> +
> +/* EDID Detailed Timing        Info 0 begin offset */
> +#define HDMI_EDID_DETAILED_TIMING_OFFSET       0x36
> +
> +#define HDMI_EDID_PIX_CLK_OFFSET               0
> +#define HDMI_EDID_H_ACTIVE_OFFSET              2
> +#define HDMI_EDID_H_BLANKING_OFFSET            3
> +#define HDMI_EDID_V_ACTIVE_OFFSET              5
> +#define HDMI_EDID_V_BLANKING_OFFSET            6
> +#define HDMI_EDID_H_SYNC_OFFSET                        8
> +#define HDMI_EDID_H_SYNC_PW_OFFSET             9
> +#define HDMI_EDID_V_SYNC_OFFSET                        10
> +#define HDMI_EDID_V_SYNC_PW_OFFSET             11
> +#define HDMI_EDID_H_IMAGE_SIZE_OFFSET          12
> +#define HDMI_EDID_V_IMAGE_SIZE_OFFSET          13
> +#define HDMI_EDID_H_BORDER_OFFSET              15
> +#define HDMI_EDID_V_BORDER_OFFSET              16
> +#define HDMI_EDID_FLAGS_OFFSET                 17
> +
> +/* HDMI EDID DTDs */
> +#define HDMI_EDID_MAX_DTDS                     4
> +
> +/* HDMI EDID DTD Tags */
> +#define HDMI_EDID_DTD_TAG_MONITOR_NAME         0xFC
> +#define HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM    0xFF
> +#define HDMI_EDID_DTD_TAG_MONITOR_LIMITS       0xFD
> +#define HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA 0xFA
> +#define HDMI_EDID_DTD_TAG_COLOR_POINT_DATA     0xFB
> +#define HDMI_EDID_DTD_TAG_ASCII_STRING         0xFE
> +
> +#define HDMI_IMG_FORMAT_MAX_LENGTH             20
> +#define HDMI_AUDIO_FORMAT_MAX_LENGTH           10
> +
> +/* HDMI EDID Extenion Data Block Values: Video */
> +#define HDMI_EDID_EX_VIDEO_NATIVE              0x80
> +#define HDMI_EDID_EX_VIDEO_MASK                        0x7F
> +#define HDMI_EDID_EX_VIDEO_MAX                 35
> +
> +#define STANDARD_HDMI_TIMINGS_NB               34
> +#define STANDARD_HDMI_T

Re: [patch] Fix AF9015 Dual tuner i2c write failures

[adq]

On 22 March 2011 09:00, Mauro Carvalho Chehab  wrote:
> Em 04-03-2011 20:11, Andrew de Quincey escreveu:
>> On 4 March 2011 22:59, Antti Palosaari  wrote:
>>> On 03/05/2011 12:44 AM, Andrew de Quincey wrote:
>>
>> Adding a "bus lock" to af9015_i2c_xfer() will not work as demod/tuner
>> accesses will take multiple i2c transactions.
>>
>> Therefore, the following patch overrides the dvb_frontend_ops
>> functions to add a per-device lock around them: only one frontend can
>> now use the i2c bus at a time. Testing with the scripts above shows
>> this has eliminated the errors.
>
> This have annoyed me too, but since it does not broken functionality much
> I
> haven't put much effort for fixing it. I like that fix since it is in
> AF9015
> driver where it logically belongs to. But it looks still rather complex.
> I
> see you have also considered "bus lock" to af9015_i2c_xfer() which could
> be
> much smaller in code size (that's I have tried to implement long time
> back).
>
> I would like to ask if it possible to check I2C gate open / close inside
> af9015_i2c_xfer() and lock according that? Something like:

 Hmm, I did think about that, but I felt overriding the functions was
 just cleaner: I felt it was more obvious what it was doing. Doing
 exactly this sort of tweaking was one of the main reasons we added
 that function overriding feature.

 I don't like the idea of returning "error locked by FE" since that'll
 mean the tuning will randomly fail sometimes in a way visible to
 userspace (unless we change the core dvb_frontend code), which was one
 of the things I was trying to avoid. Unless, of course, I've
 misunderstood your proposal.
>>>
>>> Not returning error, but waiting in lock like that:
>>> if (mutex_lock_interruptible(&d->i2c_mutex) < 0)
>>>  return -EAGAIN;
>>
>> Ah k, sorry
>>
 However, looking at the code again, I realise it is possible to
 simplify it. Since its only the demod gates that cause a problem, we
 only /actually/ need to lock the get_frontend() and set_frontend()
 calls.
>>>
>>> I don't understand why .get_frontend() causes problem, since it does not
>>> access tuner at all. It only reads demod registers. The main problem is
>>> (like schema in af9015.c shows) that there is two tuners on same I2C bus
>>> using same address. And demod gate is only way to open access for desired
>>> tuner only.
>>
>> AFAIR /some/ tuner code accesses the tuner hardware to read the exact
>> tuned frequency back on a get_frontend(); was just being extra
>> paranoid :)
>>
>>> You should block traffic based of tuner not demod. And I think those
>>> callbacks which are needed for override are tuner driver callbacks. Consider
>>> situation device goes it v4l-core calls same time both tuner .sleep() ==
>>> problem.
>>
>> Hmm, yeah, you're right, let me have another look tomorrow.
>
> Andrew, Antti,
>
> I'm understanding that I should wait for another patch on this subject, right?
> Please let me know when you have a patch ready for me to apply.
>
> Btw, I think that the long term solution would be, instead, to provide some 
> sort of
> resource locking inside DVB (and V4L) core. I have here 3 devices not 
> supported yet that
> uses the same tuner (and the same demod - DRX-K) for both DVB-C and DVB-T. It 
> would
> be a way better to use some core-provided solution to prevent that both DVB-C 
> and DVB-T
> would be used at the same time on such devices, instead of cloning the same 
> code
> (or modified versions on it) on each driver that have such issues.
>
> One solution could be to have a callback like:
>
> enum dvb_fe_lock_type {
>        ATV_DEMOD_LOCK,
>        DTV_DEMOD_T_LOCK,
>        DTV_DEMOD_S_LOCK,
>        DTV_DEMOD_C_LOCK,
>        TUNER_T_LOCK,
>        TUNER_S_LOCK,
>        TUNER_C_LOCK,
>        TUNER_FM_LOCK,
>        FM_DEMOD_LOCK,
> };
>
> /**
>  * dvb_fe_lock - locks a frontend resource
>  * @fe:         DVB frontend struct
>  * @type:       type of resource to lock
>  * @lock:       true indicates to lock the resource, false to unlock
>  *
>  * Returns true if the resource was locked, false otherwise.
>  * routine may wait for a pending transaction to happen before returning.
>  */
> bool (*dvb_fe_lock)(struct dvb_frontend *fe, enum dvb_fe_lock_type type, bool 
> lock);
>
> What do you think?

Have to think on it, but it does sound sensible to do it in the core
if there are other things like this.

Definitely hold off on the dual patch though, as it doesn't fix the
tuner lockup issue I'm seeing unfortunately.
--
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 -next] drivers:media:radio: wl128x: fix printk format and text

[Mauro Carvalho Chehab]

Em 18-03-2011 13:18, Randy Dunlap escreveu:
> What happened to this driver in linux-next of 2011.0318?
> It's in linux-next of 2011.0317.
> 
> Here's a patch that was prepared against linux-next of 2011.0317.
> 
> ---
> From: Randy Dunlap 
> 
> Fix text spacing and grammar.
> Fix printk format warning:
> 
> drivers/media/radio/wl128x/fmdrv_common.c:274: warning: format '%d' expects 
> type 'int', but argument 4 has type 'long unsigned int'
> 
> Signed-off-by: Randy Dunlap 
> ---
>  drivers/media/radio/wl128x/fmdrv_common.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> --- linux-next-20110317.orig/drivers/media/radio/wl128x/fmdrv_common.c
> +++ linux-next-20110317/drivers/media/radio/wl128x/fmdrv_common.c
> @@ -271,8 +271,8 @@ static void recv_tasklet(unsigned long a
>   /* Process all packets in the RX queue */
>   while ((skb = skb_dequeue(&fmdev->rx_q))) {
>   if (skb->len < sizeof(struct fm_event_msg_hdr)) {
> - fmerr("skb(%p) has only %d bytes"
> - "atleast need %d bytes to decode\n", skb,
> + fmerr("skb(%p) has only %d bytes; "
> + "need at least %zd bytes to decode\n", skb,
>   skb->len, sizeof(struct fm_event_msg_hdr));
>   kfree_skb(skb);
>   continue;

Thanks, but it got superseeded by this one:

commit c6a721201f0ab67dc86709afe7b8f0e549bcdd07
Author: Hans Verkuil 
AuthorDate: Sun Mar 6 09:30:02 2011 -0300
Commit: Mauro Carvalho Chehab 
CommitDate: Fri Mar 11 14:13:23 2011 -0300

[media] fmdrv_common.c: fix compiler warning

drivers/media/radio/wl128x/fmdrv_common.c: In function 'recv_tasklet':
drivers/media/radio/wl128x/fmdrv_common.c:274:4: warning: format '%d' 
expects type 'int', but argument 4 has type 'long unsigned int'

The result of sizeof() should be printed with %zu.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/radio/wl128x/fmdrv_common.c 
b/drivers/media/radio/wl128x/fmdrv_common.c
index 12f4c65..64454d3 100644
--- a/drivers/media/radio/wl128x/fmdrv_common.c
+++ b/drivers/media/radio/wl128x/fmdrv_common.c
@@ -271,8 +271,8 @@ static void recv_tasklet(unsigned long arg)
/* Process all packets in the RX queue */
while ((skb = skb_dequeue(&fmdev->rx_q))) {
if (skb->len < sizeof(struct fm_event_msg_hdr)) {
-   fmerr("skb(%p) has only %d bytes"
-   "atleast need %d bytes to decode\n", skb,
+   fmerr("skb(%p) has only %d bytes, "
+   "at least need %zu bytes to decode\n", skb,
skb->len, sizeof(struct fm_event_msg_hdr));
kfree_skb(skb);
continue;

Thanks,
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: [RFC PATCH] HDMI:Support for EDID parsing in kernel.

[Paul Mundt]

On Tue, Mar 22, 2011 at 02:52:59PM -0300, Mauro Carvalho Chehab wrote:
> Em 22-03-2011 14:32, Mythri P K escreveu:
> > Adding support for common EDID parsing in kernel.
> > 
> > EDID - Extended display identification data is a data structure provided by
> > a digital display to describe its capabilities to a video source, This a 
> > standard supported by CEA and VESA.
> > 
> > There are several custom implementations for parsing EDID in kernel, some
> > of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
> > parsing of EDID should be done in a library, which is agnostic of the
> > framework (V4l2, DRM, FB)  which is using the functionality, just based on 
> > the raw EDID pointer with size/segment information.
> > 
> > With other RFC's such as the one below, which tries to standardize HDMI 
> > API's
> > It would be better to have a common EDID code in one place.It also helps to
> > provide better interoperability with variety of TV/Monitor may be even by
> > listing out quirks which might get missed with several custom implementation
> > of EDID.
> > http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
> > 
> > This patch tries to add functions to parse some portion EDID (detailed 
> > timing,
> > monitor limits, AV delay information, deep color mode support, Audio and 
> > VSDB)
> > If we can align on this library approach i can enhance this library to parse
> > other blocks and probably we could also add quirks from other implementation
> > as well.
> > 
> > Signed-off-by: Mythri P K 
> > ---
> >  arch/arm/include/asm/edid.h |  243 ++
> >  drivers/video/edid.c|  340 
> > +++
> 
> Hmm... if you want this to be agnostic, the header file should not be inside
> arch/arm, but on some other place, like include/video/.
> 
Ironically this adds a drivers/video/edid.c but completely ignores
drivers/video/edid.h which already exists and already contains many of
these definitions.

I like the idea of a generalized library, but it would be nice to see the
existing edid.h evolved and its users updated incrementally.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] New Jeilin dual-mode camera support

[Mauro Carvalho Chehab]

Em 14-03-2011 19:38, Patrice Chotard escreveu:
> I have forgotten to include the Documentation/video4linux/gspca.txt 
> modification in my previous patch
> 
> Patrice.
>
> Sportscam_DV15.patch
> 
> Signed-off-by: Patrice CHOTARD 
>  Theodore Kilgore 
> ---
>  Documentation/video4linux/gspca.txt |1 +
>  drivers/media/video/gspca/jeilinj.c |  396 
> ++-
> 2 files changed, 345 insertions(+), 52 deletions(-)

Please, don't send patches like that. It makes harder to handle. Instead, use:




Signed-off-by: Patrice CHOTARD 
Signed-off-by: Theodore Kilgore 

---

I have forgotten to include the Documentation/video4linux/gspca.txt 
modification in my previous patch
(and/or any other review comments that you might have - everything between 
"---" and the diff
will be discarded by usual scripts).

>  Documentation/video4linux/gspca.txt |1 +
>  drivers/media/video/gspca/jeilinj.c |  396 
> ++-
> 2 files changed, 345 insertions(+), 52 deletions(-)


-

/me is waiting for Jean-Francois final review, in order to apply it upstream.

Thanks,
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: [RFC PATCH] HDMI:Support for EDID parsing in kernel.

[Mauro Carvalho Chehab]

Em 22-03-2011 14:32, Mythri P K escreveu:
> Adding support for common EDID parsing in kernel.
> 
> EDID - Extended display identification data is a data structure provided by
> a digital display to describe its capabilities to a video source, This a 
> standard supported by CEA and VESA.
> 
> There are several custom implementations for parsing EDID in kernel, some
> of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
> parsing of EDID should be done in a library, which is agnostic of the
> framework (V4l2, DRM, FB)  which is using the functionality, just based on 
> the raw EDID pointer with size/segment information.
> 
> With other RFC's such as the one below, which tries to standardize HDMI API's
> It would be better to have a common EDID code in one place.It also helps to
> provide better interoperability with variety of TV/Monitor may be even by
> listing out quirks which might get missed with several custom implementation
> of EDID.
> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401
> 
> This patch tries to add functions to parse some portion EDID (detailed timing,
> monitor limits, AV delay information, deep color mode support, Audio and VSDB)
> If we can align on this library approach i can enhance this library to parse
> other blocks and probably we could also add quirks from other implementation
> as well.
> 
> Signed-off-by: Mythri P K 
> ---
>  arch/arm/include/asm/edid.h |  243 ++
>  drivers/video/edid.c|  340 
> +++

Hmm... if you want this to be agnostic, the header file should not be inside
arch/arm, but on some other place, like include/video/.

>  2 files changed, 583 insertions(+), 0 deletions(-)
>  create mode 100644 arch/arm/include/asm/edid.h
>  create mode 100644 drivers/video/edid.c
> 
> diff --git a/arch/arm/include/asm/edid.h b/arch/arm/include/asm/edid.h
> new file mode 100644
> index 000..843346a
> --- /dev/null
> +++ b/arch/arm/include/asm/edid.h
> @@ -0,0 +1,243 @@
> +/*
> + * edid.h
> + *
> + * Copyright (C) 2011 Texas Instruments
> + * Author: Mythri P K 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + * History:
> + */
> +
> +#ifndef _EDID_H_
> +#define _EDID_H_
> +
> +/* HDMI EDID Length */
> +#define HDMI_EDID_MAX_LENGTH 512
> +
> +/* HDMI EDID Extension Data Block Tags  */
> +#define HDMI_EDID_EX_DATABLOCK_TAG_MASK  0xE0
> +#define HDMI_EDID_EX_DATABLOCK_LEN_MASK  0x1F
> +
> +#define EDID_TIMING_DESCRIPTOR_SIZE  0x12
> +#define EDID_DESCRIPTOR_BLOCK0_ADDRESS   0x36
> +#define EDID_DESCRIPTOR_BLOCK1_ADDRESS   0x80
> +#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR   4
> +#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR   4
> +
> +/* EDID Detailed Timing  Info 0 begin offset */
> +#define HDMI_EDID_DETAILED_TIMING_OFFSET 0x36
> +
> +#define HDMI_EDID_PIX_CLK_OFFSET 0
> +#define HDMI_EDID_H_ACTIVE_OFFSET2
> +#define HDMI_EDID_H_BLANKING_OFFSET  3
> +#define HDMI_EDID_V_ACTIVE_OFFSET5
> +#define HDMI_EDID_V_BLANKING_OFFSET  6
> +#define HDMI_EDID_H_SYNC_OFFSET  8
> +#define HDMI_EDID_H_SYNC_PW_OFFSET   9
> +#define HDMI_EDID_V_SYNC_OFFSET  10
> +#define HDMI_EDID_V_SYNC_PW_OFFSET   11
> +#define HDMI_EDID_H_IMAGE_SIZE_OFFSET12
> +#define HDMI_EDID_V_IMAGE_SIZE_OFFSET13
> +#define HDMI_EDID_H_BORDER_OFFSET15
> +#define HDMI_EDID_V_BORDER_OFFSET16
> +#define HDMI_EDID_FLAGS_OFFSET   17
> +
> +/* HDMI EDID DTDs */
> +#define HDMI_EDID_MAX_DTDS   4
> +
> +/* HDMI EDID DTD Tags */
> +#define HDMI_EDID_DTD_TAG_MONITOR_NAME   0xFC
> +#define HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM  0xFF
> +#define HDMI_EDID_DTD_TAG_MONITOR_LIMITS 0xFD
> +#define HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA   0xFA
> +#define HDMI_EDID_DTD_TAG_COLOR_POINT_DATA   0xFB
> +#define HDMI_EDID_DTD_TAG_ASCII_STRING   0xFE
> +
> +#define HDMI_IMG_FORMAT_MAX_LENGTH   20
> +#define HDMI_AUDIO_FORMAT_MAX_LENGTH 10
> +
> +/* HDMI EDID Extenion Data Block Values: Video */
> +#define HDMI_EDID_EX_VIDEO_NATIVE0x80
> +#define HDMI_EDID_EX_VIDEO_MASK  0x7F
> +#define HDMI_EDID_EX_VIDE

[RFC PATCH] HDMI:Support for EDID parsing in kernel.

[Mythri P K]

Adding support for common EDID parsing in kernel.

EDID - Extended display identification data is a data structure provided by
a digital display to describe its capabilities to a video source, This a 
standard supported by CEA and VESA.

There are several custom implementations for parsing EDID in kernel, some
of them are present in fbmon.c, drm_edid.c, sh_mobile_hdmi.c, Ideally
parsing of EDID should be done in a library, which is agnostic of the
framework (V4l2, DRM, FB)  which is using the functionality, just based on 
the raw EDID pointer with size/segment information.

With other RFC's such as the one below, which tries to standardize HDMI API's
It would be better to have a common EDID code in one place.It also helps to
provide better interoperability with variety of TV/Monitor may be even by
listing out quirks which might get missed with several custom implementation
of EDID.
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/30401

This patch tries to add functions to parse some portion EDID (detailed timing,
monitor limits, AV delay information, deep color mode support, Audio and VSDB)
If we can align on this library approach i can enhance this library to parse
other blocks and probably we could also add quirks from other implementation
as well.

Signed-off-by: Mythri P K 
---
 arch/arm/include/asm/edid.h |  243 ++
 drivers/video/edid.c|  340 +++
 2 files changed, 583 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/edid.h
 create mode 100644 drivers/video/edid.c

diff --git a/arch/arm/include/asm/edid.h b/arch/arm/include/asm/edid.h
new file mode 100644
index 000..843346a
--- /dev/null
+++ b/arch/arm/include/asm/edid.h
@@ -0,0 +1,243 @@
+/*
+ * edid.h
+ *
+ * Copyright (C) 2011 Texas Instruments
+ * Author: Mythri P K 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ * History:
+ */
+
+#ifndef _EDID_H_
+#define _EDID_H_
+
+/* HDMI EDID Length */
+#define HDMI_EDID_MAX_LENGTH   512
+
+/* HDMI EDID Extension Data Block Tags  */
+#define HDMI_EDID_EX_DATABLOCK_TAG_MASK0xE0
+#define HDMI_EDID_EX_DATABLOCK_LEN_MASK0x1F
+
+#define EDID_TIMING_DESCRIPTOR_SIZE0x12
+#define EDID_DESCRIPTOR_BLOCK0_ADDRESS 0x36
+#define EDID_DESCRIPTOR_BLOCK1_ADDRESS 0x80
+#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4
+#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4
+
+/* EDID Detailed TimingInfo 0 begin offset */
+#define HDMI_EDID_DETAILED_TIMING_OFFSET   0x36
+
+#define HDMI_EDID_PIX_CLK_OFFSET   0
+#define HDMI_EDID_H_ACTIVE_OFFSET  2
+#define HDMI_EDID_H_BLANKING_OFFSET3
+#define HDMI_EDID_V_ACTIVE_OFFSET  5
+#define HDMI_EDID_V_BLANKING_OFFSET6
+#define HDMI_EDID_H_SYNC_OFFSET8
+#define HDMI_EDID_H_SYNC_PW_OFFSET 9
+#define HDMI_EDID_V_SYNC_OFFSET10
+#define HDMI_EDID_V_SYNC_PW_OFFSET 11
+#define HDMI_EDID_H_IMAGE_SIZE_OFFSET  12
+#define HDMI_EDID_V_IMAGE_SIZE_OFFSET  13
+#define HDMI_EDID_H_BORDER_OFFSET  15
+#define HDMI_EDID_V_BORDER_OFFSET  16
+#define HDMI_EDID_FLAGS_OFFSET 17
+
+/* HDMI EDID DTDs */
+#define HDMI_EDID_MAX_DTDS 4
+
+/* HDMI EDID DTD Tags */
+#define HDMI_EDID_DTD_TAG_MONITOR_NAME 0xFC
+#define HDMI_EDID_DTD_TAG_MONITOR_SERIALNUM0xFF
+#define HDMI_EDID_DTD_TAG_MONITOR_LIMITS   0xFD
+#define HDMI_EDID_DTD_TAG_STANDARD_TIMING_DATA 0xFA
+#define HDMI_EDID_DTD_TAG_COLOR_POINT_DATA 0xFB
+#define HDMI_EDID_DTD_TAG_ASCII_STRING 0xFE
+
+#define HDMI_IMG_FORMAT_MAX_LENGTH 20
+#define HDMI_AUDIO_FORMAT_MAX_LENGTH   10
+
+/* HDMI EDID Extenion Data Block Values: Video */
+#define HDMI_EDID_EX_VIDEO_NATIVE  0x80
+#define HDMI_EDID_EX_VIDEO_MASK0x7F
+#define HDMI_EDID_EX_VIDEO_MAX 35
+
+#define STANDARD_HDMI_TIMINGS_NB   34
+#define STANDARD_HDMI_TIMINGS_VESA_START   15
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+enum extension_edid_db {
+   DATABLOCK_AUDIO = 1,
+   DATABLOCK_VIDEO = 2,
+   DATABLOCK_VENDOR = 3,
+   DATABLOCK_SPEAKERS = 4,
+};
+
+struct img_edid {
+   bool pref;
+   int code;
+};
+
+struct image_fo

OMAP3 ISP outputs 5555 5555 5555 5555 ...

[Bastian Hecht]

Hello omap isp devs,

maybe you can help me, I am a bit desperate with my current cam problem:

I use a ov5642 chip and get only 0x55 in my data output when I use a
camclk > 1 MHz. With 1 MHz data rate from the camera chip to the omap
all works (well the colorspace is strange - it's greenish, but that is
not my main concern).
I looked up the data on the oscilloscope and all flanks seem to be
fine at the isp. Very clear cuts with 4 MHz and 10MHz. Also the data
pins are flickering fine. Looks like a picture.

I found that the isp stats module uses 0x55 as a magic number but I
don't see why it should confuse my readout.

I use 2592x1944 raw bayer output via the ccdc. Next to the logical
right config I tried all possible configurations of vs/hs active high
and low on camera and isp. The isp gets the vs flanks right as the
images come out in time (sometimes it misses 1 frame).

Anyone of you had this behaviour before?

Thanks so much for reading this,

Bastian Hecht
--
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 v17 12/13] davinci: dm644x: add support for v4l2 video display

[Nori, Sekhar]

On Tue, Mar 15, 2011 at 19:29:40, Hadli, Manjunath wrote:
> Create platform devices for various video modules like venc,osd,
> vpbe and v4l2 driver for dm644x.
> 
> Signed-off-by: Manjunath Hadli 
> ---

> +struct venc_platform_data dm644x_venc_pdata = {
> + .venc_type  = VPBE_VERSION_1,
> + .setup_clock= dm644x_venc_setup_clock,
> +};

Sparse pointed out that this symbol can
be static.

Can you please build the complete series with
C=1 on the command line? This will enable
sparse check on all files being re-compiled.

I also noticed some sparse warnings on vpbe_venc.c

Also, please build with CONFIG_DEBUG_SECTION_MISMATCH=y
on the command line. I noticed some section
mismatches as well with the new code.

Thanks,
Sekhar

--
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/6] get rid of on-stack dma buffers

[Florian Mickler]

2011/3/22 Roedel, Joerg :
> On Mon, Mar 21, 2011 at 05:03:15PM -0400, Florian Mickler wrote:
>> I guess (not verified), that the dma api takes sufficient precautions
>> to abort the dma transfer if a timeout happens.  So freeing _should_
>> not be an issue. (At least, I would expect big fat warnings everywhere
>> if that were the case)
>
> Freeing is very well an issue. All you can expect from the DMA-API is to
> give you a valid DMA handle for your device. But it can not prevent that
> a device uses this handle after you returned it. You need to make sure
> yourself that any pending DMA is canceled before calling kfree().

sorry, I meant usb_control_msg above when I said 'dma api'... as that
is the function these
drivers use to do the dma.

Regards,
Flo
--
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/6] get rid of on-stack dma buffers

[Florian Mickler]

2011/3/22 James Bottomley :
> On Mon, 2011-03-21 at 22:03 +0100, Florian Mickler wrote:
>> On Mon, 21 Mar 2011 15:26:43 -0400
>> Andy Walls  wrote:
>>
>> > Florian Mickler  wrote:
>>
>> To be blunt, I'm not shure I fully understand the requirements myself.
>> But as far as I grasped it, the main problem is that we need memory
>> which the processor can see as soon as the device has scribbled upon
>> it. (think caches and the like)
>>
>> Somewhere down the line, the buffer to usb_control_msg get's to be
>> a parameter to dma_map_single which is described as part of
>> the DMA API in Documentation/DMA-API.txt
>>
>> The main point I filter out from that is that the memory has to begin
>> exactly at a cache line boundary...
>
> The API will round up so that the correct region covers the API.
> However, if you have other structures packed into the space (as very
> often happens on stack), you get cache line interference in the CPU if
> they get accessed:  The act of accessing an adjacent object pulls in
> cache above your object and destroys DMA coherence.  This is the
> principle reason why DMA to stack is a bad idea.

Thanks, this was the missing piece of information to make sense of
 why it's bad for stack memory to be part of this.

>
>> I guess (not verified), that the dma api takes sufficient precautions
>> to abort the dma transfer if a timeout happens.  So freeing _should_
>> not be an issue. (At least, I would expect big fat warnings everywhere
>> if that were the case)

I did mean s/dma api/usb_control_msg/ in the above paragraph. As that is the
 ''dma api'' these drivers are using... sorry for the confusion there...

>
> No, it doesn't take any precautions like this.  the DMA API is just
> mapping (possibly via an IOMMU).  If the transfer times out, that's done
> in the DMA engine of the card, and must be cleaned up by the driver and
> unmapped.

ok.

> The general rule though is never DMA to stack.  On some processors, the
> way stack is allocated can actually make this not work.
>
> James

thanks,
Flo

p.s.: hope this message get's through to the list... I am on the road
at the moment,
 so I'm not shure that there won't be any html in it again :(
--
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/6] get rid of on-stack dma buffers

[James Bottomley]

On Mon, 2011-03-21 at 22:03 +0100, Florian Mickler wrote:
> On Mon, 21 Mar 2011 15:26:43 -0400
> Andy Walls  wrote:
> 
> > Florian Mickler  wrote:
> > 
> > >Hi all!
> > >
> > >These patches get rid of on-stack dma buffers for some of the dvb-usb
> > >drivers. 
> > >I do not own the hardware, so these are only compile tested. I would 
> > >appreciate testing and review.
> > >They were previously sent to the list, but some error on my side
> > >prevented (some of?) them from beeing delivered to all parties (the
> > >lists).
> > >
> > >These changes are motivated by 
> > >https://bugzilla.kernel.org/show_bug.cgi?id=15977 .
> > >
> > >The patches which got tested already were submitted to Mauro (and
> > >lkml/linux-media) yesterday seperately. Those fix this same issue for
> > >ec168,
> > >ce6230, au6610 and lmedm04. 
> > >
> > >A fix for vp702x has been submitted seperately for review on the list.
> > >I have
> > >similiar fixes like the vp702x-fix for dib0700 (overlooked some
> > >on-stack
> > >buffers in there in my original submission as well) and gp8psk, but I
> > >am
> > >holding them back 'till I got time to recheck those and getting some
> > >feedback
> > >on vp702x.
> > >
> > >Please review and test.
> > >
> > >Regards,
> > >Flo
> > >
> > >Florian Mickler (6):
> > >  [media] a800: get rid of on-stack dma buffers
> > >  [media v2] vp7045: get rid of on-stack dma buffers
> > >  [media] friio: get rid of on-stack dma buffers
> > >  [media] dw2102: get rid of on-stack dma buffer
> > >  [media] m920x: get rid of on-stack dma buffers
> > >  [media] opera1: get rid of on-stack dma buffer
> > >
> > > drivers/media/dvb/dvb-usb/a800.c   |   17 ++---
> > > drivers/media/dvb/dvb-usb/dw2102.c |   10 ++-
> > > drivers/media/dvb/dvb-usb/friio.c  |   23 ++---
> > > drivers/media/dvb/dvb-usb/m920x.c  |   33 
> > > drivers/media/dvb/dvb-usb/opera1.c |   31 +++
> > >drivers/media/dvb/dvb-usb/vp7045.c |   47
> > >++--
> > > 6 files changed, 116 insertions(+), 45 deletions(-)
> > >
> > >-- 
> > >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
> > 
> 
> > Florian,
> > 
> > For all of these, what happens when the USB call times out and you kfree() 
> > the buffer?  Can the USB DMA actually complete after this kfree(), possibly 
> > corrupting space that has been reallocated off the heap, since the kfree()?
> > 
> > This is the scenario for which I assume allocating off the stack is bad.  
> > 
> > Do these changes simply make corruption less noticable since heap gets 
> > corrupted vs stack?
> > 
> > Regards,
> > Andy
> 
> To be blunt, I'm not shure I fully understand the requirements myself.
> But as far as I grasped it, the main problem is that we need memory
> which the processor can see as soon as the device has scribbled upon
> it. (think caches and the like)
> 
> Somewhere down the line, the buffer to usb_control_msg get's to be
> a parameter to dma_map_single which is described as part of
> the DMA API in Documentation/DMA-API.txt 
> 
> The main point I filter out from that is that the memory has to begin
> exactly at a cache line boundary... 

The API will round up so that the correct region covers the API.
However, if you have other structures packed into the space (as very
often happens on stack), you get cache line interference in the CPU if
they get accessed:  The act of accessing an adjacent object pulls in
cache above your object and destroys DMA coherence.  This is the
principle reason why DMA to stack is a bad idea.

> I guess (not verified), that the dma api takes sufficient precautions
> to abort the dma transfer if a timeout happens.  So freeing _should_
> not be an issue. (At least, I would expect big fat warnings everywhere
> if that were the case)

No, it doesn't take any precautions like this.  the DMA API is just
mapping (possibly via an IOMMU).  If the transfer times out, that's done
in the DMA engine of the card, and must be cleaned up by the driver and
unmapped.

The general rule though is never DMA to stack.  On some processors, the
way stack is allocated can actually make this not work.

James


--
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] mantis: trivial module parameter documentation fix

[Bjørn Mork]

The default for "verbose" is 0.  Update description to match.

Signed-off-by: Bjørn Mork 
---
 drivers/media/dvb/mantis/hopper_cards.c |2 +-
 drivers/media/dvb/mantis/mantis_cards.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb/mantis/hopper_cards.c 
b/drivers/media/dvb/mantis/hopper_cards.c
index 70e73af..1402062 100644
--- a/drivers/media/dvb/mantis/hopper_cards.c
+++ b/drivers/media/dvb/mantis/hopper_cards.c
@@ -44,7 +44,7 @@
 
 static unsigned int verbose;
 module_param(verbose, int, 0644);
-MODULE_PARM_DESC(verbose, "verbose startup messages, default is 1 (yes)");
+MODULE_PARM_DESC(verbose, "verbose startup messages, default is 0 (no)");
 
 #define DRIVER_NAME"Hopper"
 
diff --git a/drivers/media/dvb/mantis/mantis_cards.c 
b/drivers/media/dvb/mantis/mantis_cards.c
index 40da225..05cbb9d 100644
--- a/drivers/media/dvb/mantis/mantis_cards.c
+++ b/drivers/media/dvb/mantis/mantis_cards.c
@@ -52,7 +52,7 @@
 
 static unsigned int verbose;
 module_param(verbose, int, 0644);
-MODULE_PARM_DESC(verbose, "verbose startup messages, default is 1 (yes)");
+MODULE_PARM_DESC(verbose, "verbose startup messages, default is 0 (no)");
 
 static int devs;
 
-- 
1.7.2.5

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

Re: [PATCH 0/6] get rid of on-stack dma buffers

[Johannes Stezenbach]

On Tue, Mar 22, 2011 at 11:59:32AM +0100, Jiri Kosina wrote:
> On Mon, 21 Mar 2011, Florian Mickler wrote:
> 
> > To be blunt, I'm not shure I fully understand the requirements myself. 
> > But as far as I grasped it, the main problem is that we need memory 
> > which the processor can see as soon as the device has scribbled upon it. 
> > (think caches and the like)
> > 
> > Somewhere down the line, the buffer to usb_control_msg get's to be a 
> > parameter to dma_map_single which is described as part of the DMA API in 
> > Documentation/DMA-API.txt
> > 
> > The main point I filter out from that is that the memory has to begin
> > exactly at a cache line boundary... 
> > 
> > I guess (not verified), that the dma api takes sufficient precautions to 
> > abort the dma transfer if a timeout happens.  So freeing _should_ not be 
> > an issue. (At least, I would expect big fat warnings everywhere if that 
> > were the case)
> > 
> > I cc'd some people that hopefully will correct me if I'm wrong...
> 
> It all boils down to making sure that you don't free the memory which is 
> used as target of DMA transfer.
> 
> This is very likely to hit you when DMA memory region is on stack, but 
> blindly just converting this to kmalloc()/kfree() isn't any better if you 
> don't make sure that all the DMA transfers have been finished and device 
> will not be making any more to that particular memory region.

I think it is important that one cache line is not shared between
a DMA buffer and other objects, especially on architectures where
cache coherency is managed in software (ARM, MIPS etc.).  If you
use kmalloc() for the DMA buffer that is guaranteed.
(E.g. DMA API will do writeback/invalidate before the DMA starts, but
if the CPU accesses a variable which is next to the buffer
while DMA is still pending then the whole cacheline is read back into
the cache.  If the CPU is then trying to read the DMA buffer after
the DMA finished it will see stale data from the cache.  You lose.)

It depends on the device doing DMA if it needs special alignment.
If you meet its alignment requirements, and wait for the end of the DMA before
returning, and make sure the buffer does not share cache lines with
neighbouring objects on the stack, then you can use DMA buffers on
stack.  In practice it's simpler and much less error prone to use kmalloc().

Regarding usb_control_msg(), since it is a synchronous API which
waits for the end of the transfer I'm relatively sure there is no
DMA pending when it returns, even if it aborts with timeout or any
other error code.


Johannes
--
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 v17 08/13] davinci: eliminate use of IO_ADDRESS() on sysmod

[Arnd Bergmann]

On Tuesday 22 March 2011, Nori, Sekhar wrote:
> .. but forgot to fix this. There is nothing wrong with
> using writel, but it doesn't fit into what the subject
> of this patch is.

Well, to be more exact, the __raw_writel was actually
wrong here and it should be writel(), but it's certainly
better to mention the reason in the changelog, or to
make a separate patch for it.

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

Re: [PATCH 0/6] get rid of on-stack dma buffers

[Oliver Neukum]

Am Dienstag, 22. März 2011, 14:08:17 schrieb Florian Mickler:
> Am 22.03.2011 12:10 schrieb "Roedel, Joerg" :
> >
> > On Mon, Mar 21, 2011 at 05:03:15PM -0400, Florian Mickler wrote:
> > > I guess (not verified), that the dma api takes sufficient precautions
> > > to abort the dma transfer if a timeout happens.  So freeing _should_
> > > not be an issue. (At least, I would expect big fat warnings everywhere
> > > if that were the case)
> >
> > Freeing is very well an issue. All you can expect from the DMA-API is to
> > give you a valid DMA handle for your device. But it can not prevent that
> > a device uses this handle after you returned it. You need to make sure
> > yourself that any pending DMA is canceled before calling kfree().
> 
> Does usb_control_msg do this? It waits for completion but takes also a
> timeout parameter. I will recheck this once I'm home.

It uses usb_start_wait_urb() which upon a timeout kills the URB. The
buffer is unused after usb_control_msg() returns.

HTH
Oliver
--
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: S2-3200 switching-timeouts on 2.6.38

[Bjørn Mork]

Rico Tzschichholz  writes:

>> Actually, quite a lot of effort was put in to get that part right. It
>> does the reverse thing that's to be done.
>> The revamped version is here [1] If the issue persists still, then it
>> needs to be investigated further.
>>
>> [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html
>
> I am not sure how this is related to stb6100?
>
> Does that mean the current stb0899 patch [2] isnt ready to be proposed
> for 2.6.39 yet? Or does the stb6100 patch has a better design to solve
> this issue which should be adapted for stb0899 then?

I believe the point was that the real issue was a noise problem in the
stb6100 tuner driver, and that the stb0899 frontend patch just papered
over this.

> I was hoping to see it included before the merge window is closed again.
>
> [2] https://patchwork.kernel.org/patch/244201/

Please test the driver with the patch Manu refers to and report if there
still are issues.  The patch is now upstream in the 2.6.38 kernel, so
testing it should be fairly easy.  

Do you still have this issue with a plain 2.6.38 driver?


Bjørn

--
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] omap3isp: implement ENUM_FMT

[Michael Jones]

>From dccbd4a0a717ee72a3271075b1e3456a9c67ca0e Mon Sep 17 00:00:00 2001
From: Michael Jones 
Date: Tue, 22 Mar 2011 11:47:22 +0100
Subject: [PATCH] omap3isp: implement ENUM_FMT

Whatever format is currently being delivered will be declared as the only
possible format

Signed-off-by: Michael Jones 
---

Some V4L2 apps require ENUM_FMT, which is a mandatory ioctl for V4L2.
This patch doesn't enumerate all of the formats which could possibly be
set (as is intended by ENUM_FMT), but at least it reports the one that
is currently set.

This patch applies to Laurent's 'media-2.6.38-0001-omap3isp' branch.

 drivers/media/video/omap3isp/ispvideo.c |   23 +++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/omap3isp/ispvideo.c 
b/drivers/media/video/omap3isp/ispvideo.c
index a0bb5db..8e25f47 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -642,6 +642,28 @@ isp_video_get_format(struct file *file, void *fh, struct 
v4l2_format *format)
 }
 
 static int
+isp_video_enum_format(struct file *file, void *fh, struct v4l2_fmtdesc 
*fmtdesc)
+{
+   struct isp_video_fh *vfh = to_isp_video_fh(fh);
+   struct isp_video *video = video_drvdata(file);
+
+   if (fmtdesc->index)
+   return -EINVAL;
+
+   if (fmtdesc->type != video->type)
+   return -EINVAL;
+
+   fmtdesc->flags = 0;
+   fmtdesc->description[0] = 0;
+
+   mutex_lock(&video->mutex);
+   fmtdesc->pixelformat = vfh->format.fmt.pix.pixelformat;
+   mutex_unlock(&video->mutex);
+
+   return 0;
+}
+
+static int
 isp_video_set_format(struct file *file, void *fh, struct v4l2_format *format)
 {
struct isp_video_fh *vfh = to_isp_video_fh(fh);
@@ -1059,6 +1081,7 @@ isp_video_s_input(struct file *file, void *fh, unsigned 
int input)
 
 static const struct v4l2_ioctl_ops isp_video_ioctl_ops = {
.vidioc_querycap= isp_video_querycap,
+   .vidioc_enum_fmt_vid_cap= isp_video_enum_format,
.vidioc_g_fmt_vid_cap   = isp_video_get_format,
.vidioc_s_fmt_vid_cap   = isp_video_set_format,
.vidioc_try_fmt_vid_cap = isp_video_try_format,
-- 
1.7.4.1


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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 v17 00/13] davinci vpbe: dm6446 v4l2 driver

[Nori, Sekhar]

Manju,

On Tue, Mar 22, 2011 at 12:23:14, Hadli, Manjunath wrote:
> Sekhar, Kevin, 
>  These patches have gone through considerable reviews. 
> Could you please ACK from your end?

I have some minor comments which I have already posted and
once you fix those you can add:

Acked-by: Sekhar Nori 

to the platform patches.

> 
> On Tue, Mar 15, 2011 at 19:26:28, Hadli, Manjunath wrote:
> > version17:
> > The more important among the patch history from previous comments 1. 
> > Replacing _raw_readl() with readl().

This is not valid.

Thanks,
Sekhar

--
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 v17 13/13] davinci: dm644x EVM: add support for VPBE display

[Nori, Sekhar]

On Tue, Mar 15, 2011 at 19:29:55, Hadli, Manjunath wrote:
> This patch adds support for V4L2 video display to DM6446 EVM.
> Support for SD and ED modes is provided, along with Composite
> and Component outputs.
> 
> Signed-off-by: Manjunath Hadli 
> ---
>  arch/arm/mach-davinci/board-dm644x-evm.c|  108 
> ++-
>  arch/arm/mach-davinci/dm644x.c  |4 +-
>  arch/arm/mach-davinci/include/mach/dm644x.h |3 +-

The changes adding the SoC support should be folded
into patch 12/13.

Thanks,
Sekhar

--
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 v17 10/13] davinci: dm644x: change vpfe capture structure variables for consistency

[Nori, Sekhar]

On Tue, Mar 15, 2011 at 19:29:12, Hadli, Manjunath wrote:
> change the vpfe capture related configuration structure variables from
>  to dm644xevm_ to make it consistent with the rest of
> the file.

This description is not fully accurate. You also have changes
where you add SoC prefix to variable names. I guess you can just
say "Add SoC and board prefixes to variable names so that.."

Thanks,
Sekhar

--
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 v17 08/13] davinci: eliminate use of IO_ADDRESS() on sysmod

[Nori, Sekhar]

On Tue, Mar 15, 2011 at 19:28:43, Hadli, Manjunath wrote:
> Current devices.c file has a number of instances where
> IO_ADDRESS() is used for system module register
> access. Eliminate this in favor of a ioremap()
> based access.
> 
> Consequent to this, a new global pointer davinci_sysmodbase
> has been introduced which gets initialized during
> the initialization of each relevant SoC.
> 
> In this patch davinci_sysmodbase is used by davinci_setup_mmc
> but the later patches in the series use the same in different
> places using DAVINCI_SYSMODULE_VIRT.This patch lays the
> foundation for that.
> 
> Signed-off-by: Manjunath Hadli 
> ---
>  arch/arm/mach-davinci/devices.c   |   23 ++-
>  arch/arm/mach-davinci/dm355.c |1 +
>  arch/arm/mach-davinci/dm365.c |1 +
>  arch/arm/mach-davinci/dm644x.c|1 +
>  arch/arm/mach-davinci/dm646x.c|1 +
>  arch/arm/mach-davinci/include/mach/hardware.h |6 ++
>  6 files changed, 24 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
> index d3b2040..b7ef950 100644
> --- a/arch/arm/mach-davinci/devices.c
> +++ b/arch/arm/mach-davinci/devices.c
> @@ -33,6 +33,14 @@
>  #define DM365_MMCSD0_BASE 0x01D11000
>  #define DM365_MMCSD1_BASE 0x01D0
>  
> +void __iomem  *davinci_sysmodbase;
> +
> +void davinci_map_sysmod(void)
> +{
> + davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800);
> + WARN_ON(!davinci_sysmodbase);
> +}
> +
>  static struct resource i2c_resources[] = {
>   {
>   .start  = DAVINCI_I2C_BASE,
> @@ -210,12 +218,12 @@ void __init davinci_setup_mmc(int module, struct 
> davinci_mmc_config *config)
>   davinci_cfg_reg(DM355_SD1_DATA2);
>   davinci_cfg_reg(DM355_SD1_DATA3);
>   } else if (cpu_is_davinci_dm365()) {
> - void __iomem *pupdctl1 =
> - IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE + 0x7c);
> -
>   /* Configure pull down control */
> - __raw_writel((__raw_readl(pupdctl1) & ~0xfc0),
> - pupdctl1);
> + void __iomem *pupdctl1 = DAVINCI_SYSMODULE_VIRT(0x7c);
> + unsigned v;
> +
> + v = __raw_readl(pupdctl1);
> + __raw_writel(v & ~0xfc0, pupdctl1);

You fixed this as Sergei requested...

>  
>   mmcsd1_resources[0].start = DM365_MMCSD1_BASE;
>   mmcsd1_resources[0].end = DM365_MMCSD1_BASE +
> @@ -244,11 +252,8 @@ void __init davinci_setup_mmc(int module, struct 
> davinci_mmc_config *config)
>   mmcsd0_resources[2].start = IRQ_DM365_SDIOINT0;
>   } else if (cpu_is_davinci_dm644x()) {
>   /* REVISIT: should this be in board-init code? */
> - void __iomem *base =
> - IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
> -
>   /* Power-on 3.3V IO cells */
> - __raw_writel(0, base + DM64XX_VDD3P3V_PWDN);
> + writel(0, DAVINCI_SYSMODULE_VIRT(DM64XX_VDD3P3V_PWDN));

.. but forgot to fix this. There is nothing wrong with
using writel, but it doesn't fit into what the subject
of this patch is.

Thanks,
Sekhar

--
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: Demande de support V4L2

[Michael Jones]

On 03/21/2011 06:43 PM, Laurent Pinchart wrote:
> Hi Loïc,
> 
> On Friday 18 March 2011 16:43:40 Loïc Akue wrote:
>> Hi,
>>
>> Do you know if Gstreamer or Mplayer are able to capture some vidéo from the
>> CCDC output?
>> I've been trying with the v4l2src plugin but Gstreamer "can negociate
>> format".
> 
> I haven't tried mplayer or v4l2src with the OAMP3 ISP, sorry.
> 


Hi Loïc,

GStreamer relies on ENUM_FMT to negotiate the format, which the current
ISP driver doesn't provide.  I have patched my kernel to do this and I
have gotten GStreamer to display UYVY images from the previewer output,
but I haven't spent much time trying to get it from the CCDC yet.  I
would be interested to hear your progress there.

I will submit my ENUM_FMT patch to the list in a different thread.

-Michael

MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
--
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 3/3] ARM: switch mackerel to dynamically manage the platform camera

[Magnus Damm]

On Mon, Mar 21, 2011 at 10:22 PM, Guennadi Liakhovetski
 wrote:
> On Wed, 16 Mar 2011, Magnus Damm wrote:
>
>> On Tue, Feb 22, 2011 at 6:57 PM, Guennadi Liakhovetski
>>  wrote:
>> > Use soc_camera_platform helper functions to dynamically manage the
>> > camera device.
>> >
>> > Signed-off-by: Guennadi Liakhovetski 
>> > ---
>> >  arch/arm/mach-shmobile/board-mackerel.c |   28 
>> > +++-
>> >  1 files changed, 7 insertions(+), 21 deletions(-)
>>
>> I just tested patch 1/3 and patch 3/3 on my Mackerel board.
>
> Thanks for testing!
>
>> Unfortunately I get this printout on the console:
>>
>> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera 0
>> soc_camera_platform soc_camera_platform.0: Platform has not set
>> soc_camera_device pointer!
>> soc_camera_platform: probe of soc_camera_platform.0 failed with error -22
>> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from camera >> 0
>>
>> Without these two patches everything work just fine. Any ideas on how
>> to fix it? I'd be happy to test V2. =)
>
> Hm, yes, looks like I'm initialising the pointer too late. Could you,
> please, test the patch below on top, if it helps, I'll send v2.

Yes, this incremental change solves the problem. Thanks!

Please post V2 and add:

Acked-by: Magnus Damm 
--
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 3/3] ARM: switch mackerel to dynamically manage the platform camera

[Magnus Damm]

On Mon, Mar 21, 2011 at 10:22 PM, Guennadi Liakhovetski
 wrote:
> On Wed, 16 Mar 2011, Magnus Damm wrote:
>
>> On Tue, Feb 22, 2011 at 6:57 PM, Guennadi Liakhovetski
>>  wrote:
>> > Use soc_camera_platform helper functions to dynamically manage the
>> > camera device.
>> >
>> > Signed-off-by: Guennadi Liakhovetski 
>> > ---
>> >  arch/arm/mach-shmobile/board-mackerel.c |   28 
>> > +++-
>> >  1 files changed, 7 insertions(+), 21 deletions(-)
>>
>> I just tested patch 1/3 and patch 3/3 on my Mackerel board.
>
> Thanks for testing!
>
>> Unfortunately I get this printout on the console:
>>
>> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver attached to camera 0
>> soc_camera_platform soc_camera_platform.0: Platform has not set
>> soc_camera_device pointer!
>> soc_camera_platform: probe of soc_camera_platform.0 failed with error -22
>> sh_mobile_ceu sh_mobile_ceu.0: SuperH Mobile CEU driver detached from camera >> 0
>>
>> Without these two patches everything work just fine. Any ideas on how
>> to fix it? I'd be happy to test V2. =)
>
> Hm, yes, looks like I'm initialising the pointer too late. Could you,
> please, test the patch below on top, if it helps, I'll send v2.

Yes, this fix incremental change solves the problem. Thanks!

Please post V2 and add:

Acked-by: Magnus Damm 
--
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: S2-3200 switching-timeouts on 2.6.38

[Rico Tzschichholz]

Hello Manu,

> Actually, quite a lot of effort was put in to get that part right. It
> does the reverse thing that's to be done.
> The revamped version is here [1] If the issue persists still, then it
> needs to be investigated further.
>
> [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html

I am not sure how this is related to stb6100?

Does that mean the current stb0899 patch [2] isnt ready to be proposed
for 2.6.39 yet? Or does the stb6100 patch has a better design to solve
this issue which should be adapted for stb0899 then?
I was hoping to see it included before the merge window is closed again.

[2] https://patchwork.kernel.org/patch/244201/

Best regards,
Rico



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 0/6] get rid of on-stack dma buffers

[Jiri Kosina]

On Mon, 21 Mar 2011, Florian Mickler wrote:

> To be blunt, I'm not shure I fully understand the requirements myself. 
> But as far as I grasped it, the main problem is that we need memory 
> which the processor can see as soon as the device has scribbled upon it. 
> (think caches and the like)
> 
> Somewhere down the line, the buffer to usb_control_msg get's to be a 
> parameter to dma_map_single which is described as part of the DMA API in 
> Documentation/DMA-API.txt
> 
> The main point I filter out from that is that the memory has to begin
> exactly at a cache line boundary... 
> 
> I guess (not verified), that the dma api takes sufficient precautions to 
> abort the dma transfer if a timeout happens.  So freeing _should_ not be 
> an issue. (At least, I would expect big fat warnings everywhere if that 
> were the case)
> 
> I cc'd some people that hopefully will correct me if I'm wrong...

It all boils down to making sure that you don't free the memory which is 
used as target of DMA transfer.

This is very likely to hit you when DMA memory region is on stack, but 
blindly just converting this to kmalloc()/kfree() isn't any better if you 
don't make sure that all the DMA transfers have been finished and device 
will not be making any more to that particular memory region.

-- 
Jiri Kosina
SUSE Labs, Novell Inc.

--
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: [Query] VIDIOC_QBUF and VIDIOC_STREAMON order

[Laurent Pinchart]

Hi Hans,

On Tuesday 15 March 2011 08:50:45 Hans Verkuil wrote:
> On Tuesday, March 15, 2011 04:21:05 Pawel Osciak wrote:
> > On Mon, Mar 14, 2011 at 03:49, Subash Patel  wrote:
> > > VIDIOC_STREAMON expects buffers to be queued before hardware part of
> > > image/video pipe is enabled. From my experience of V4L2 user space, I
> > > have always QBUFfed before invoking the STREAMON. Below is the API
> > 
> > > specification which also speaks something same:
> > Not exactly. It says that the API requires buffers to be queued for
> > output devices. It does not require any buffers to be queued for input
> > devices. Sylwester is right here.
> > 
> > This feature of not having to queue input buffers before STREAMON
> > introduces problems to driver implementations and I am personally not
> > a big fan of it either. But I'm seeing some additional problems here.
> > Suppose we forced QBUF to be done before STREAMON. This would work,
> > but what happens next? What should happen when we want to DQBUF the
> > last buffer? If the device couldn't start without any buffers queued,
> > can it continue streaming with all of them dequeued? I would guess
> > not. So we'd either have to deny DQBUF of the last buffer (which for
> > me personally is almost unacceptable) or have the last DQBUF
> > automatically cause a STREAMOFF. So, for the latter, should
> > applications, after they get all the data they wanted, be made to
> > always have one more buffer queued as a "throwaway" buffer? This is
> > probably the only reasonable solution here, but the applications would
> > have to keep count of their queued buffers and be aware of this.
> > Also, there might still be situations where being able to STREAMON
> > without buffers queued would be beneficial. For example, enabling the
> > device might be a slow/expensive operation and we might prefer to keep
> > it running even if we don't want any data at the moment. Even for
> > faster devices, being able to keep them on and periodically take a
> > snapshot would be faster without having to call STREAMON anyway...
> 
> The problem is that what is possible is highly hardware dependent. All
> video capture device I know of (composite in, HDMI in, etc) require that
> buffers are queued and they won't release that buffer to userspace until a
> new free buffer is available.

That's funny, all video capture devices I know of behave the opposite way :-) 
They either pause the stream when they run out of buffers and resume it when a 
new buffer gets queued, or they throw away the data when intermediate buffers 
are used (such as with USB devices).

> They DMA continuously and stopping the DMA
> at the last buffer and restarting it when a new one appears tends to be
> too expensive and leads to additional loss of frames.
> 
> In part how this should act depends on the use-case: if you are streaming
> video, then requiring buffers to be present before STREAMON and holding on
> to a buffer if userspace can't keep up seems quite reasonable to me.
> 
> But for snapshot and codec type streams this behavior doesn't make sense.
> The main difference is that in this case the DMA is not driven by an
> external input, but by internal (userspace) demand.
> 
> Something for our meeting to discuss.

-- 
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: soc-camera layer2 driver

[Laurent Pinchart]

On Tuesday 22 March 2011 10:37:36 Guennadi Liakhovetski wrote:
> On Tue, 22 Mar 2011, Gilles wrote:
> > Dear Dr Guennadi,
> > 
> > Thank you for your answer.
> > 
> > > 1. soc-camera core
> > > 2. camera host driver (receive from sensor, DMA to RAM)
> > > 3. camera sensor drivers
> > > 
> > > If you're developing new hardware, you'll have to write new layer 2
> > > driver for it.
> > 
> > I do understand that part, I guess what I was asking was for any
> > pointers to some up-to-date guides on how to do this. I couldn't find a
> > good documentation on how to to that. I must add that even though I have
> > written drivers to other operating systems, I am new at writing drivers
> > for Linux. The V4L2 layer appears very powerful and, at the same time,
> > there is a lot of documentation out there but, a lot also appears to be
> > obsolete. Of course, the best way is to modify something current. I will
> > attempt to do this but I would still appreciate any current howtos you
> > could point me to.
> 
> Well, there's a Documentation/video4linux/soc-camera.txt but it's not
> really that modern (it mentions 2.6.27 in it...). Last time it has been
> updated for 2.6.32. I have to update it again at some point, things change
> way too quickly. So, yes, your best bet would be to take existing drivers.
> If you plan to support scatter-gather DMA, look at pxa_camera.c, if your
> buffers are going to be contiguous (even though you're not going to use
> the videobuf2-dma-contig allocator), look at sh_mobile_ceu for an advanced
> example, or at one of mx3_camera, mx2_camera, mx1_camera for simpler ones.
> omap1_camera is also trying to support both sg and contig... If you have
> questions, don't hesitate to ask on the ML, also cc me and / or the
> respective driver author. Maybe you end up writing some such howto too;)
> 
> > > As for stereo vision: since you're going to use the same sensor, you
> > > will either have to put it on a different i2c bus, or wire it to
> > > configure a different i2c address. In either case communicating to it
> > > shouldn't be a problem.
> > 
> > Yes, of course and I can change the I2C address so I can use the same
> > bus. My question was more related to synchronization of both frames.
> > Initially, I thought about multiplexing the cameras at the hardware
> > level so that every frame, the data bus would switch to the other camera
> > but then, one has not control over the camera horizontal sync signals.
> > There is no way to guarantee that both cameras HSync are ... well
> > synchronized. Then of course, the other problem would be that the frames
> > would be out of sync in terms of time of capture.
> > 
> > Anyway, the question was more related to synchronicity. And I guess the
> > answer would depend on whether I wanted to capture frame-alternative 3D
> > or side-by-side 3D. Maybe this is too new, I just can't find detailed
> > information about 3D in V4L2.
> 
> I'm not aware about any 3d efforts in v4l2... I would've thought, that one
> would want to synchronize frames at the driver level, the application
> level is too indeterministic. So, you would need to add an API to retrieve
> pairs of frames, I presume, one of which is marked left, other right. This
> frame-pair handling is one addition to the generic V4L2 API. You'll also
> need a way to open / associate two sensors with one v4l2 device node.
> Then, how you assemble two different frames from two sensors in one
> stereo-frame is up to your driver, I presume.
> 
> Alternatively you could use two device nodes and reassemble stereo frames
> in user-space based on indices or timestamps. This should also be
> possible, as long as you guarantee in your driver, that that information
> is really consistent.
> 
> Those were just a couple of quick ideas, perhaps, 3d / stereo-vision
> support in v4l2 requires a careful study and some RFC-rounds...

What about using the multi-plane API for that ?

-- 
Regards,

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

Re: [PATCH 0/6] get rid of on-stack dma buffers

[Roedel, Joerg]

On Mon, Mar 21, 2011 at 05:03:15PM -0400, Florian Mickler wrote:
> I guess (not verified), that the dma api takes sufficient precautions
> to abort the dma transfer if a timeout happens.  So freeing _should_
> not be an issue. (At least, I would expect big fat warnings everywhere
> if that were the case)

Freeing is very well an issue. All you can expect from the DMA-API is to
give you a valid DMA handle for your device. But it can not prevent that
a device uses this handle after you returned it. You need to make sure
yourself that any pending DMA is canceled before calling kfree().


Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

--
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: S2-3200 switching-timeouts on 2.6.38

[Mauro Carvalho Chehab]

Em 22-03-2011 06:53, Bjørn Mork escreveu:
> Manu Abraham  writes:
>> On Tue, Mar 22, 2011 at 1:46 AM, Randy Dunlap  wrote:
>>> On Mon, 21 Mar 2011 20:46:23 +0100 Rico Tzschichholz wrote:
>>>
 Hello,

 I would like to know if there is any intention to include this patch
 soon? https://patchwork.kernel.org/patch/244201/
>>>
>>> There are MANY posted but unmerged patches in patchwork from the linux-media
>>> mailing list.  What is going on (or not going on) with patch merging?
>>
>> Actually, quite a lot of effort was put in to get that part right. It
>> does the reverse thing that's to be done.
>> The revamped version is here [1] If the issue persists still, then it
>> needs to be investigated further.
>>
>> [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html
> 
> So the patch state should be "Rejected" and not "Under Review".
> 
> Would certainly help us all if the patchwork state was updated whenever
> a patch actually was processed...

Yes, but the thing is that somebody needs to manually update me about status 
change,
as patchwork doesn't provide any way for it. Patchwork's permission for a 
project
is all or nothing: or you completely own a project, or you have just read-only
access. There's no way, currently, for me to delegate a patch to someone without
allowing that person to touch at the non-delegated patches. Also, patchwork
also doesn't allow me to change contributor status (there's just one global 
admin
that creates and/or modifies account access on patchwork).

Anyway, I've updated the status for #244201.

Thanks,
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: Yet another memory provider: can linaro organize a meeting?

[Laurent Pinchart]

On Monday 21 March 2011 19:03:38 Hans Verkuil wrote:
> On Wednesday, March 16, 2011 09:14:54 Kyungmin Park wrote:
> > Rough schedules.
> > 
> > 1. Warsaw meetings (3/16~3/18): mostly v4l2 person and some SoC vendors
> > 
> >   Make a consensence at media developers. and share the information.
> >   Please note that it's v4l2 brainstorming meeting. so memory management
> >   is not the main issue.
> 
> I have asked all participants to the meeting to try and assemble
> requirements for their hardware in the next week.
> 
> > 2. ELC (4/11~4/13): DRM, DRI and v4l2 person.
> > 
> >   Discuss GEM/TTM is acceptable for non-X86 system and find out the which
> >   modules are acceptable.
> >   We studied the GEM for our environment. but it's too huge and not much
> >   benefit for us since current frameworks are enough.
> >   The missing is that no generic memory passing mechanism. We need the
> >   generic memory passing interface. that's all.
> 
> Who will be there? Is there a BoF or something similar organized?
> 
> > 3. Linaro (5/9~5/13): ARM, SoC vendors and v4l2 persons.
> > 
> >   I hope several person are anticipated and made a small step for final
> >   goal.
> 
> I should be able to join, at least for the part related to buffer pools and
> related topics.

Same for me. I might not join for the whole week, so it would be nice if we 
could draft an agenda in the near future.

-- 
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

[GIT PATCHES FOR 2.6.39] gspca for_v2.6.39

[Jean-Francois Moine]

The following changes since commit
d2803205ff3be8e8ea4634709799606c5d5294b5:

  [media] via-camera: Fix OLPC serial check (2011-03-21 21:48:25 -0300)

are available in the git repository at:
  git://linuxtv.org/jfrancois/gspca.git for_v2.6.39

Jean-François Moine (9):
  gspca - nw80x: Cleanup source
  gspca - nw80x: The webcam dsb-c110 is the same as the twinkle
  gspca - nw80x: Do some initialization at probe time
  gspca - nw80x: Fix the gain, exposure and autogain
  gspca - nw80x: Check the bridge from the webcam type
  gspca - nw80x: Fix some image resolutions
  gspca - nw80x: Get the sensor ID when bridge et31x110
  gspca - nw80x: Fix exposure for some webcams
  gspca - zc3xx: Add exposure control for sensor hv7131r

Patrice Chotard (1):
  gspca - main: Add endpoint direction test in alt_xfer

 drivers/media/video/gspca/gspca.c |3 +-
 drivers/media/video/gspca/nw80x.c |  858 -
 drivers/media/video/gspca/zc3xx.c |   76 +++-
 3 files changed, 351 insertions(+), 586 deletions(-)
-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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 PATCHES FOR 2.6.39] Make the UVC API public (and bug fixes)

[Mauro Carvalho Chehab]

Em 22-03-2011 06:17, Laurent Pinchart escreveu:
> Hi Mauro,
> 
> Thanks for the review.
> 
> On Monday 21 March 2011 20:39:17 Mauro Carvalho Chehab wrote:
>> Em 27-02-2011 14:36, Laurent Pinchart escreveu:
>>> Hi Mauro,
>>>
>>> These patches move the uvcvideo.h header file from
>>> drivers/media/video/uvc to include/linux, making the UVC API public.
>>>
>>> Martin Rubli has committed support for the public API to libwebcam, so
>>> userspace support is up to date.
>>>
>>> The following changes since commit 
> 9e650fdb12171a5a5839152863eaab9426984317:
>>>   [media] drivers:media:radio: Update Kconfig and Makefile for wl128x FM
>>>   driver (2011-02-27 07:50:42 -0300)
>>>
>>> are available in the git repository at:
>>>   git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next
>>>
>>> Laurent Pinchart (6):
>>>   uvcvideo: Deprecate UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET}
>>
>> There are some places there saying that the removal will happen at 2.6.39.
> 
> I'll fix that.
> 
>>>   uvcvideo: Rename UVC_CONTROL_* flags to UVC_CTRL_FLAG_*
>>>   uvcvideo: Include linux/types.h in uvcvideo.h
>>>   uvcvideo: Move uvcvideo.h to include/linux
>>
>> -'U'00-0F   drivers/media/video/uvc/uvcvideo.h  conflict!
>> +'U'00-0F   linux/uvcvideo.hconflict!
>>
>> Please avoid conflicts at userspace API's.
> 
> The uvcvideo driver already uses 'U'. I can change it, but it will break the 
> ABI.

Yes, but, as we've discussed on IRC, API will be broken anyway, with the
removal of the 4 old ioctls. This is not so serious here, as the API is defined
on an internal header (drivers/media/video/uvc/uvcvideo.h) that are not exported
via make headers-install. Yet, we'll need to keep the old set of ioctls during
some kernel versions.
> 
>>>   uvcvideo: Fix descriptor parsing for video output devices
>>
>> This one seems independent from API changes. Applying it.
>>
>>>   v4l: videobuf2: Typo fix
> 
> What about this one ?

Were already applied:

commit 4c3e702cf541a6bee8afb345f22300b1e3c2fe08
Author: Laurent Pinchart 
AuthorDate: Sun Feb 27 14:38:19 2011 -0300
Commit: Mauro Carvalho Chehab 
CommitDate: Wed Mar 2 17:37:16 2011 -0300

> 
>>> Martin Rubli (2):
>>>   uvcvideo: Add UVCIOC_CTRL_QUERY ioctl
>>>   uvcvideo: Add driver documentation
>>
>> Please, don't use "enum" at the public API:
>>
>> +   __u32   id  V4L2 control identifier
>> +   __u8name[32]V4L2 control name
>> +   __u8entity[16]  UVC extension unit GUID
>> +   __u8selectorUVC control selector
>> +   __u8sizeV4L2 control size (in bits)
>> +   __u8offset  V4L2 control offset (in bits)
>> +   enum v4l2_ctrl_type
>> +   v4l2_type   V4L2 control type
>> +   enum uvc_control_data_type
>> +   data_type   UVC control data type
>> +   struct uvc_menu_info
>> +   *menu_info  Array of menu entries (for menu controls
>> only) +   __u32   menu_count  Number of menu entries (for menu
>> controls only) +
>> +   * struct uvc_menu_info
>> +
>> +   __u32   value   Menu entry value used by the device
>> +   __u8name[32]Menu entry name
>>
>>
>> enum size is not portable. (OK, I know that V4L2 API has some enum's, but
>> let's not add new stuff using it). Also, please be sure that the new API
>> won't require any compat32 bits.
> 
> OK I'll fix that.
> 
>>> Stephan Lachowsky (1):
>>>   uvcvideo: Fix uvc_fixup_video_ctrl() format search
>>
>> This one seems independent from API changes. Applying it.
> 

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: S2-3200 switching-timeouts on 2.6.38

[Bjørn Mork]

Manu Abraham  writes:
> On Tue, Mar 22, 2011 at 1:46 AM, Randy Dunlap  wrote:
>> On Mon, 21 Mar 2011 20:46:23 +0100 Rico Tzschichholz wrote:
>>
>>> Hello,
>>>
>>> I would like to know if there is any intention to include this patch
>>> soon? https://patchwork.kernel.org/patch/244201/
>>
>> There are MANY posted but unmerged patches in patchwork from the linux-media
>> mailing list.  What is going on (or not going on) with patch merging?
>
> Actually, quite a lot of effort was put in to get that part right. It
> does the reverse thing that's to be done.
> The revamped version is here [1] If the issue persists still, then it
> needs to be investigated further.
>
> [1] http://www.mail-archive.com/linuxtv-commits@linuxtv.org/msg09214.html

So the patch state should be "Rejected" and not "Under Review".

Would certainly help us all if the patchwork state was updated whenever
a patch actually was processed...


Bjørn



--
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: soc-camera layer2 driver

[Guennadi Liakhovetski]

Hi

On Tue, 22 Mar 2011, Gilles wrote:

> Dear Dr Guennadi,
> 
> Thank you for your answer.
> 
> 
> > 1. soc-camera core
> > 2. camera host driver (receive from sensor, DMA to RAM)
> > 3. camera sensor drivers
> > 
> > If you're developing new hardware, you'll have to write new layer 2 driver 
> > for it.
> 
> I do understand that part, I guess what I was asking was for any 
> pointers to some up-to-date guides on how to do this. I couldn't find a 
> good documentation on how to to that. I must add that even though I have 
> written drivers to other operating systems, I am new at writing drivers 
> for Linux. The V4L2 layer appears very powerful and, at the same time, 
> there is a lot of documentation out there but, a lot also appears to be 
> obsolete. Of course, the best way is to modify something current. I will 
> attempt to do this but I would still appreciate any current howtos you 
> could point me to.

Well, there's a Documentation/video4linux/soc-camera.txt but it's not 
really that modern (it mentions 2.6.27 in it...). Last time it has been 
updated for 2.6.32. I have to update it again at some point, things change 
way too quickly. So, yes, your best bet would be to take existing drivers. 
If you plan to support scatter-gather DMA, look at pxa_camera.c, if your 
buffers are going to be contiguous (even though you're not going to use 
the videobuf2-dma-contig allocator), look at sh_mobile_ceu for an advanced 
example, or at one of mx3_camera, mx2_camera, mx1_camera for simpler ones. 
omap1_camera is also trying to support both sg and contig... If you have 
questions, don't hesitate to ask on the ML, also cc me and / or the 
respective driver author. Maybe you end up writing some such howto too;)

> > As for stereo vision: since you're going to use the same sensor, you will 
> > either have to put it on a different i2c bus, or wire it to configure a 
> > different i2c address. In either case communicating to it shouldn't be a 
> > problem.
> 
> Yes, of course and I can change the I2C address so I can use the same 
> bus. My question was more related to synchronization of both frames. 
> Initially, I thought about multiplexing the cameras at the hardware 
> level so that every frame, the data bus would switch to the other camera 
> but then, one has not control over the camera horizontal sync signals. 
> There is no way to guarantee that both cameras HSync are ... well 
> synchronized. Then of course, the other problem would be that the frames 
> would be out of sync in terms of time of capture.
> 
> Anyway, the question was more related to synchronicity. And I guess the 
> answer would depend on whether I wanted to capture frame-alternative 3D 
> or side-by-side 3D. Maybe this is too new, I just can't find detailed 
> information about 3D in V4L2.

I'm not aware about any 3d efforts in v4l2... I would've thought, that one 
would want to synchronize frames at the driver level, the application 
level is too indeterministic. So, you would need to add an API to retrieve 
pairs of frames, I presume, one of which is marked left, other right. This 
frame-pair handling is one addition to the generic V4L2 API. You'll also 
need a way to open / associate two sensors with one v4l2 device node. 
Then, how you assemble two different frames from two sensors in one 
stereo-frame is up to your driver, I presume.

Alternatively you could use two device nodes and reassemble stereo frames 
in user-space based on indices or timestamps. This should also be 
possible, as long as you guarantee in your driver, that that information 
is really consistent.

Those were just a couple of quick ideas, perhaps, 3d / stereo-vision 
support in v4l2 requires a careful study and some RFC-rounds...

Thanks
Guennadi

> I appreciate any up-to-date documents you can point me to.
> 
> Cheers,
> Gilles
> .
> 
> 
> On Mar 21, 2011, at 01:02 , Guennadi Liakhovetski wrote:
> 
> > Hi Gilles
> > 
> > On Mon, 21 Mar 2011, Gilles wrote:
> > 
> >> Hi,
> >> 
> >> I am sorry to bother you but after hours of searching google without 
> >> luck I thought I'd ask you what might take you 5 minutes to answer if 
> >> you please would.
> >> 
> >> I have developed a custom hardware which can host one or two cameras and 
> >> I am a little confused (mainly because I can't seem to find up-to-date 
> >> documentation on how to do it) as to:
> > 
> > All (non-commercial) requests should really be discussed on the
> > 
> > Linux Media Mailing List 
> > 
> > mailing list. Please, repost your query to the list with my email in CC.
> > 
> > In short, if I understood you right, you are developing new hardware, that 
> > receives data from video sensors and DMAs it into RAM, correct? In general 
> > the soc-camera stack consists of 3 layers:
> > 
> > 1. soc-camera core
> > 2. camera host driver (receive from sensor, DMA to RAM)
> > 3. camera sensor drivers
> > 
> > If you're developing new hardware, you'll have to write new layer 2 driver 
> > for it.
> > 
> > As

Re: [RFC PATCH RESEND v2 2/3] v4l2-ctrls: modify uvc driver to use new menu type of V4L2_CID_FOCUS_AUTO

[Laurent Pinchart]

Hi Mauro,

On Tuesday 22 March 2011 01:27:44 Mauro Carvalho Chehab wrote:
> Em 03-03-2011 07:10, Laurent Pinchart escreveu:
> > On Thursday 03 March 2011 03:16:32 Kim, HeungJun wrote:
> >> As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu
> >> type, this uvc is modified the usage of V4L2_CID_FOCUS_AUTO, maintaining
> >> v4l2 menu index.
> >> 
> >> Signed-off-by: Heungjun Kim 
> >> Signed-off-by: Kyungmin Park 
> > 
> > Acked-by: Laurent Pinchart 
> 
> I'm assuming that you'll be applying those patches on your tree and sending
> me a pull request, right?

The patch depends on other V4L2 core patches in the same series, so I wasn't 
planning to push it through my tree, but it can be done. There are still 
issues with this series though, as we haven't reached an agreement on the 
auto-focus ABI yet.

-- 
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: soc-camera layer2 driver

[Gilles]

Dear Dr Guennadi,

Thank you for your answer.


> 1. soc-camera core
> 2. camera host driver (receive from sensor, DMA to RAM)
> 3. camera sensor drivers
> 
> If you're developing new hardware, you'll have to write new layer 2 driver 
> for it.

I do understand that part, I guess what I was asking was for any pointers to 
some up-to-date guides on how to do this. I couldn't find a good documentation 
on how to to that. I must add that even though I have written drivers to other 
operating systems, I am new at writing drivers for Linux. The V4L2 layer 
appears very powerful and, at the same time, there is a lot of documentation 
out there but, a lot also appears to be obsolete. Of course, the best way is to 
modify something current. I will attempt to do this but I would still 
appreciate any current howtos you could point me to.


> As for stereo vision: since you're going to use the same sensor, you will 
> either have to put it on a different i2c bus, or wire it to configure a 
> different i2c address. In either case communicating to it shouldn't be a 
> problem.


Yes, of course and I can change the I2C address so I can use the same bus. My 
question was more related to synchronization of both frames. Initially, I 
thought about multiplexing the cameras at the hardware level so that every 
frame, the data bus would switch to the other camera but then, one has not 
control over the camera horizontal sync signals. There is no way to guarantee 
that both cameras HSync are ... well synchronized. Then of course, the other 
problem would be that the frames would be out of sync in terms of time of 
capture.

Anyway, the question was more related to synchronicity. And I guess the answer 
would depend on whether I wanted to capture frame-alternative 3D or 
side-by-side 3D. Maybe this is too new, I just can't find detailed information 
about 3D in V4L2.

I appreciate any up-to-date documents you can point me to.

Cheers,
Gilles
.


On Mar 21, 2011, at 01:02 , Guennadi Liakhovetski wrote:

> Hi Gilles
> 
> On Mon, 21 Mar 2011, Gilles wrote:
> 
>> Hi,
>> 
>> I am sorry to bother you but after hours of searching google without 
>> luck I thought I'd ask you what might take you 5 minutes to answer if 
>> you please would.
>> 
>> I have developed a custom hardware which can host one or two cameras and 
>> I am a little confused (mainly because I can't seem to find up-to-date 
>> documentation on how to do it) as to:
> 
> All (non-commercial) requests should really be discussed on the
> 
> Linux Media Mailing List 
> 
> mailing list. Please, repost your query to the list with my email in CC.
> 
> In short, if I understood you right, you are developing new hardware, that 
> receives data from video sensors and DMAs it into RAM, correct? In general 
> the soc-camera stack consists of 3 layers:
> 
> 1. soc-camera core
> 2. camera host driver (receive from sensor, DMA to RAM)
> 3. camera sensor drivers
> 
> If you're developing new hardware, you'll have to write new layer 2 driver 
> for it.
> 
> As for stereo vision: since you're going to use the same sensor, you will 
> either have to put it on a different i2c bus, or wire it to configure a 
> different i2c address. In either case communicating to it shouldn't be a 
> problem.
> 
> We can further discuss details on the mailing list.
> 
> Thanks
> Guennadi
> 
>> - Which files do I need to modify so that soc-camera "knows" where/how 
>> to access the hardware pins where the camera is connected to.
>> 
>> - I'm not sure I understand how the H/V sync works. My camera is 
>> connected to a parallel interface which is designed to do DMA into 
>> memory (clocked by the camera pixel clock). Don't the H/V signals need 
>> to generate an interrupt to reset the DMA addresses? It appears as the 
>> soc infrastructure does not require that but I don't understand how the 
>> drivers know that a new frame is available?
>> 
>> - Curently, the hardware I designed is designed to handle one camera at 
>> once but I have been asked if it would be possible to modify the 
>> hardware to run both cameras at once (which I can easily do). How would 
>> you recommend implementing stereo-vision? If both cameras are of the 
>> same kind (same driver), I am also a little confused how the same soc 
>> driver would know which one of the two hardwares it needs to bind to.
>> 
>> If you could just point me to *any* documentation that would explain 
>> (something up-to-date) how to adapt linux to match my hardware, I would 
>> GREATLY appreciate it as I am a bit lost.
>> 
>> Thank you,
>> Gilles
>> .
>> 
>> 
> 
> ---
> 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 PATCHES FOR 2.6.39] Make the UVC API public (and bug fixes)

[Laurent Pinchart]

Hi Mauro,

Thanks for the review.

On Monday 21 March 2011 20:39:17 Mauro Carvalho Chehab wrote:
> Em 27-02-2011 14:36, Laurent Pinchart escreveu:
> > Hi Mauro,
> > 
> > These patches move the uvcvideo.h header file from
> > drivers/media/video/uvc to include/linux, making the UVC API public.
> > 
> > Martin Rubli has committed support for the public API to libwebcam, so
> > userspace support is up to date.
> > 
> > The following changes since commit 
9e650fdb12171a5a5839152863eaab9426984317:
> >   [media] drivers:media:radio: Update Kconfig and Makefile for wl128x FM
> >   driver (2011-02-27 07:50:42 -0300)
> > 
> > are available in the git repository at:
> >   git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next
> > 
> > Laurent Pinchart (6):
> >   uvcvideo: Deprecate UVCIOC_CTRL_{ADD,MAP_OLD,GET,SET}
> 
> There are some places there saying that the removal will happen at 2.6.39.

I'll fix that.

> >   uvcvideo: Rename UVC_CONTROL_* flags to UVC_CTRL_FLAG_*
> >   uvcvideo: Include linux/types.h in uvcvideo.h
> >   uvcvideo: Move uvcvideo.h to include/linux
> 
> -'U'00-0F   drivers/media/video/uvc/uvcvideo.h  conflict!
> +'U'00-0F   linux/uvcvideo.hconflict!
> 
> Please avoid conflicts at userspace API's.

The uvcvideo driver already uses 'U'. I can change it, but it will break the 
ABI.

> >   uvcvideo: Fix descriptor parsing for video output devices
> 
> This one seems independent from API changes. Applying it.
> 
> >   v4l: videobuf2: Typo fix

What about this one ?

> > Martin Rubli (2):
> >   uvcvideo: Add UVCIOC_CTRL_QUERY ioctl
> >   uvcvideo: Add driver documentation
> 
> Please, don't use "enum" at the public API:
> 
> +   __u32   id  V4L2 control identifier
> +   __u8name[32]V4L2 control name
> +   __u8entity[16]  UVC extension unit GUID
> +   __u8selectorUVC control selector
> +   __u8sizeV4L2 control size (in bits)
> +   __u8offset  V4L2 control offset (in bits)
> +   enum v4l2_ctrl_type
> +   v4l2_type   V4L2 control type
> +   enum uvc_control_data_type
> +   data_type   UVC control data type
> +   struct uvc_menu_info
> +   *menu_info  Array of menu entries (for menu controls
> only) +   __u32   menu_count  Number of menu entries (for menu
> controls only) +
> +   * struct uvc_menu_info
> +
> +   __u32   value   Menu entry value used by the device
> +   __u8name[32]Menu entry name
> 
> 
> enum size is not portable. (OK, I know that V4L2 API has some enum's, but
> let's not add new stuff using it). Also, please be sure that the new API
> won't require any compat32 bits.

OK I'll fix that.

> > Stephan Lachowsky (1):
> >   uvcvideo: Fix uvc_fixup_video_ctrl() format search
> 
> This one seems independent from API changes. Applying it.

-- 
Regards,

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

Re: [patch] Fix AF9015 Dual tuner i2c write failures

[Mauro Carvalho Chehab]

Em 04-03-2011 20:11, Andrew de Quincey escreveu:
> On 4 March 2011 22:59, Antti Palosaari  wrote:
>> On 03/05/2011 12:44 AM, Andrew de Quincey wrote:
>
> Adding a "bus lock" to af9015_i2c_xfer() will not work as demod/tuner
> accesses will take multiple i2c transactions.
>
> Therefore, the following patch overrides the dvb_frontend_ops
> functions to add a per-device lock around them: only one frontend can
> now use the i2c bus at a time. Testing with the scripts above shows
> this has eliminated the errors.

 This have annoyed me too, but since it does not broken functionality much
 I
 haven't put much effort for fixing it. I like that fix since it is in
 AF9015
 driver where it logically belongs to. But it looks still rather complex.
 I
 see you have also considered "bus lock" to af9015_i2c_xfer() which could
 be
 much smaller in code size (that's I have tried to implement long time
 back).

 I would like to ask if it possible to check I2C gate open / close inside
 af9015_i2c_xfer() and lock according that? Something like:
>>>
>>> Hmm, I did think about that, but I felt overriding the functions was
>>> just cleaner: I felt it was more obvious what it was doing. Doing
>>> exactly this sort of tweaking was one of the main reasons we added
>>> that function overriding feature.
>>>
>>> I don't like the idea of returning "error locked by FE" since that'll
>>> mean the tuning will randomly fail sometimes in a way visible to
>>> userspace (unless we change the core dvb_frontend code), which was one
>>> of the things I was trying to avoid. Unless, of course, I've
>>> misunderstood your proposal.
>>
>> Not returning error, but waiting in lock like that:
>> if (mutex_lock_interruptible(&d->i2c_mutex) < 0)
>>  return -EAGAIN;
> 
> Ah k, sorry
> 
>>> However, looking at the code again, I realise it is possible to
>>> simplify it. Since its only the demod gates that cause a problem, we
>>> only /actually/ need to lock the get_frontend() and set_frontend()
>>> calls.
>>
>> I don't understand why .get_frontend() causes problem, since it does not
>> access tuner at all. It only reads demod registers. The main problem is
>> (like schema in af9015.c shows) that there is two tuners on same I2C bus
>> using same address. And demod gate is only way to open access for desired
>> tuner only.
> 
> AFAIR /some/ tuner code accesses the tuner hardware to read the exact
> tuned frequency back on a get_frontend(); was just being extra
> paranoid :)
> 
>> You should block traffic based of tuner not demod. And I think those
>> callbacks which are needed for override are tuner driver callbacks. Consider
>> situation device goes it v4l-core calls same time both tuner .sleep() ==
>> problem.
> 
> Hmm, yeah, you're right, let me have another look tomorrow.

Andrew, Antti,

I'm understanding that I should wait for another patch on this subject, right?
Please let me know when you have a patch ready for me to apply.

Btw, I think that the long term solution would be, instead, to provide some 
sort of
resource locking inside DVB (and V4L) core. I have here 3 devices not supported 
yet that
uses the same tuner (and the same demod - DRX-K) for both DVB-C and DVB-T. It 
would
be a way better to use some core-provided solution to prevent that both DVB-C 
and DVB-T
would be used at the same time on such devices, instead of cloning the same code
(or modified versions on it) on each driver that have such issues.

One solution could be to have a callback like:

enum dvb_fe_lock_type {
ATV_DEMOD_LOCK,
DTV_DEMOD_T_LOCK,
DTV_DEMOD_S_LOCK,
DTV_DEMOD_C_LOCK,
TUNER_T_LOCK,
TUNER_S_LOCK,
TUNER_C_LOCK,
TUNER_FM_LOCK,
FM_DEMOD_LOCK,
};

/**
 * dvb_fe_lock - locks a frontend resource
 * @fe: DVB frontend struct
 * @type:   type of resource to lock
 * @lock:   true indicates to lock the resource, false to unlock
 *
 * Returns true if the resource was locked, false otherwise.
 * routine may wait for a pending transaction to happen before returning.
 */
bool (*dvb_fe_lock)(struct dvb_frontend *fe, enum dvb_fe_lock_type type, bool 
lock);

What do you think?

Thanks,
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

[RFC PATCH v3 2/2] v4l2-ctrls: update auto focus mode documentation

[Kim, Heungjun]

Document about the mode of auto focus and new controls about rectangle auto 
focus

Signed-off-by: Heungjun Kim 
Signed-off-by: Kyungmin Park 
---
 Documentation/DocBook/v4l/controls.xml|   67 +
 Documentation/DocBook/v4l/videodev2.h.xml |8 +++
 2 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/Documentation/DocBook/v4l/controls.xml 
b/Documentation/DocBook/v4l/controls.xml
index 2fae3e8..b940e21 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1860,6 +1860,73 @@ it one step further. This is a write-only 
control.
  
  
 
+ 
+   V4L2_CID_FOCUS_AUTO_MODE 
+   enum v4l2_focus_auto_mode_type
+ Enables setting modes of
+auto focus. The focus has 5 kinds of mode, and each enumerations express
+current auto focus mode in which the camera is. In the case of
+V4L2_FOCUS_AUTO_RECTANGLE, this control id can be clustered with
+4 control id which means focusing spot expressed by 4 point of rectangle.
+ 
+ 
+ 
+   
+ 
+   
+ 
V4L2_FOCUS_AUTO_NORMAL 
+ Normal mode Auto focus, single shot.
+   
+   
+ 
V4L2_FOCUS_AUTO_MACRO 
+ Macro mode Auto focus, single shot.
+   
+   
+ 
V4L2_FOCUS_AUTO_CONTINUOUS 
+ Continuous mode Auto focus, continuous shot.
+   
+   
+ 
V4L2_FOCUS_AUTO_FACE_DETECTION 
+ Face detection mode Auto focus, single shot.
+   
+   
+ 
V4L2_FOCUS_AUTO_RECTANGLE 
+ Rectangle mode Auto focus, single shot.
+   
+ 
+   
+ 
+ 
+
+ 
+   V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT 
+   integer
+ This control means the left
+side's point of the rectangle expressing focusing spot.
+ 
+ 
+
+   V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP 
+   integer
+ This control means the top
+side's point of the rectangle expressing focusing spot.
+ 
+ 
+
+   V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH 
+   integer
+ This control means the width
+length of the rectangle expressing focusing spot.
+ 
+ 
+
+   V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT 
+   integer
+ This control means the height
+length of the rectangle expressing focusing spot.
+ 
+ 
+
  
V4L2_CID_PRIVACY 
boolean
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml 
b/Documentation/DocBook/v4l/videodev2.h.xml
index 2b796a2..6bb67a6 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1385,6 +1385,14 @@ enum  v4l2_exposure_auto_type {
 #define V4L2_CID_IRIS_ABSOLUTE  (V4L2_CID_CAMERA_CLASS_BASE+17)
 #define V4L2_CID_IRIS_RELATIVE  (V4L2_CID_CAMERA_CLASS_BASE+18)
 
+enum  v4l2_focus_auto_mode_type {
+   V4L2_FOCUS_AUTO_NORMAL = 0,
+   V4L2_FOCUS_AUTO_MACRO = 1,
+   V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+   V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+   V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+
 /* FM Modulator class control IDs */
 #define V4L2_CID_FM_TX_CLASS_BASE   (V4L2_CTRL_CLASS_FM_TX | 0x900)
 #define V4L2_CID_FM_TX_CLASS(V4L2_CTRL_CLASS_FM_TX | 1)
-- 
1.7.0.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

[RFC PATCH v3 1/2] v4l2-ctrls: support various modes and 4 coordinates of rectangle auto focus

[Kim, Heungjun]

It supports various modes of auto focus. Each modes define as the enumerations
of menu type.

V4L2_FOCUS_AUTO_NORMAL,
V4L2_FOCUS_AUTO_MACRO,
V4L2_FOCUS_AUTO_CONTINUOUS,
V4L2_FOCUS_AUTO_FACE_DETECTION,
V4L2_FOCUS_AUTO_RECTANGLE

In the cause of rectangle it needs the 4 kinds of coordinate control ID of
integer type for expression about focus-spot, and each control ID means
similar to the struct v4l2_rect.

V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT
V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP
V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH
V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT

Signed-off-by: Kim, Heungjun 
Signed-off-by: Kyungmin Park 
---
 drivers/media/video/v4l2-ctrls.c |   16 
 include/linux/videodev2.h|   13 +
 2 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..365540f 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,14 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Aperture Priority Mode",
NULL
};
+   static const char * const camera_focus_auto_mode[] = {
+   "Normal Mode",
+   "Macro Mode",
+   "Continuous Mode",
+   "Face Detection Mode",
+   "Rectangle Mode",
+   NULL
+   };
static const char * const colorfx[] = {
"None",
"Black & White",
@@ -252,6 +260,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+   case V4L2_CID_FOCUS_AUTO_MODE:
+   return camera_focus_auto_mode;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -365,6 +375,11 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PRIVACY:  return "Privacy";
case V4L2_CID_IRIS_ABSOLUTE:return "Iris, Absolute";
case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative";
+   case V4L2_CID_FOCUS_AUTO_MODE:  return "Focus, Mode";
+   case V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT: return "Focus, Rectangle Left";
+   case V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP: return "Focus, Rectangle Top";
+   case V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH: return "Focus, Rectangle 
Width";
+   case V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT: return "Focus, Rectangle 
Height";
 
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -450,6 +465,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+   case V4L2_CID_FOCUS_AUTO_MODE:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index aa6c393..99cd1b7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1389,6 +1389,19 @@ enum  v4l2_exposure_auto_type {
 #define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
 #define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
 
+#define V4L2_CID_FOCUS_AUTO_MODE   (V4L2_CID_CAMERA_CLASS_BASE+19)
+enum  v4l2_focus_mode_type {
+   V4L2_FOCUS_AUTO_NORMAL = 0,
+   V4L2_FOCUS_AUTO_MACRO = 1,
+   V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+   V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+   V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT (V4L2_CID_CAMERA_CLASS_BASE+20)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP  (V4L2_CID_CAMERA_CLASS_BASE+21)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH(V4L2_CID_CAMERA_CLASS_BASE+22)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT   (V4L2_CID_CAMERA_CLASS_BASE+23)
+
 /* FM Modulator class control IDs */
 #define V4L2_CID_FM_TX_CLASS_BASE  (V4L2_CTRL_CLASS_FM_TX | 0x900)
 #define V4L2_CID_FM_TX_CLASS   (V4L2_CTRL_CLASS_FM_TX | 1)
-- 
1.7.0.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

[RFC PATCH v3 1/2] v4l2-ctrls: support various modes and 4 coordinates of rectangle auto focus

[Kim, Heungjun]

It supports various modes of auto focus. Each modes define as the enumerations
of menu type.

V4L2_FOCUS_AUTO_NORMAL,
V4L2_FOCUS_AUTO_MACRO,
V4L2_FOCUS_AUTO_CONTINUOUS,
V4L2_FOCUS_AUTO_FACE_DETECTION,
V4L2_FOCUS_AUTO_RECTANGLE

In the cause of rectangle it needs the 4 kinds of coordinate control ID of
integer type for expression about focus-spot, and each control ID means
similar to the struct v4l2_rect.

V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT
V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP
V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH
V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT

Signed-off-by: Kim, Heungjun 
Signed-off-by: Kyungmin Park 
---
 drivers/media/video/v4l2-ctrls.c |   16 
 include/linux/videodev2.h|   13 +
 2 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..365540f 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,14 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Aperture Priority Mode",
NULL
};
+   static const char * const camera_focus_auto_mode[] = {
+   "Normal Mode",
+   "Macro Mode",
+   "Continuous Mode",
+   "Face Detection Mode",
+   "Rectangle Mode",
+   NULL
+   };
static const char * const colorfx[] = {
"None",
"Black & White",
@@ -252,6 +260,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+   case V4L2_CID_FOCUS_AUTO_MODE:
+   return camera_focus_auto_mode;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -365,6 +375,11 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PRIVACY:  return "Privacy";
case V4L2_CID_IRIS_ABSOLUTE:return "Iris, Absolute";
case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative";
+   case V4L2_CID_FOCUS_AUTO_MODE:  return "Focus, Mode";
+   case V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT: return "Focus, Rectangle Left";
+   case V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP: return "Focus, Rectangle Top";
+   case V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH: return "Focus, Rectangle 
Width";
+   case V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT: return "Focus, Rectangle 
Height";
 
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -450,6 +465,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+   case V4L2_CID_FOCUS_AUTO_MODE:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index aa6c393..99cd1b7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1389,6 +1389,19 @@ enum  v4l2_exposure_auto_type {
 #define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
 #define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
 
+#define V4L2_CID_FOCUS_AUTO_MODE   (V4L2_CID_CAMERA_CLASS_BASE+19)
+enum  v4l2_focus_mode_type {
+   V4L2_FOCUS_AUTO_NORMAL = 0,
+   V4L2_FOCUS_AUTO_MACRO = 1,
+   V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+   V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+   V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT (V4L2_CID_CAMERA_CLASS_BASE+20)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP  (V4L2_CID_CAMERA_CLASS_BASE+21)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH(V4L2_CID_CAMERA_CLASS_BASE+22)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT   (V4L2_CID_CAMERA_CLASS_BASE+23)
+
 /* FM Modulator class control IDs */
 #define V4L2_CID_FM_TX_CLASS_BASE  (V4L2_CTRL_CLASS_FM_TX | 0x900)
 #define V4L2_CID_FM_TX_CLASS   (V4L2_CTRL_CLASS_FM_TX | 1)
-- 
1.7.0.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

[RFC PATCH v3 0/2] v4l2-ctrls: add auto focus mode and controls

[Kim, HeungJun]

Hello,

This is third version of RFC patch series about adding auto focus mode
and controls. The patch of the previous version bring about the issue
to be able to execute only once, not repeatedly. Because the each modes
are defined by menu type. To solve this, we add the new control of
choosing focus mode, and if doing repeatedly, it's alright that you
determine the focus mode and change the value of V4L2_CID_FOCUS_AUTO.

In the case of new added rectangle mode, these each controls belongs to
4 new controls, can make to point by the form of rectangle. These 4 new
each control values mean left x coordinate, top y coordinate,
width x length, height y length. It's similar to structure v4l2_rect.

You can find previous threads about this:
http://www.spinics.net/lists/linux-media/msg29446.html

Thanks and Regards,
Heungjun Kim
--
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 v3 0/2] v4l2-ctrls: add auto focus mode and controls

[Kim, HeungJun]

The comments of 2/2 patch are wrong. It's my fault.
Please ignore this. And I'll send again.
Sorry to confuse.

2011-03-22 오후 5:34, Kim, HeungJun 쓴 글:
> Hello,
> 
> This is third version of RFC patch series about adding auto focus mode
> and controls. The patch of the previous version bring about the issue
> to be able to execute only once, not repeatedly. Because the each modes
> are defined by menu type. To solve this, we add the new control of
> choosing focus mode, and if doing repeatedly, it's alright that you
> determine the focus mode and change the value of V4L2_CID_FOCUS_AUTO.
> 
> In the case of new added rectangle mode, these each controls belongs to
> 4 new controls, can make to point by the form of rectangle. These 4 new
> each control values mean left x coordinate, top y coordinate,
> width x length, height y length. It's similar to structure v4l2_rect.
> 
> You can find previous threads about this:
> http://www.spinics.net/lists/linux-media/msg29446.html
> 
> Thanks and Regards,
> Heungjun Kim
> --
> 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

[RFC PATCH v3 2/2] v4l2-ctrls: update auto focus mode documentation

[Kim, Heungjun]

As following to change the boolean type of V4L2_CID_FOCUS_AUTO to menu type,
this uvc is modified the usage of V4L2_CID_FOCUS_AUTO.

Signed-off-by: Heungjun Kim 
Signed-off-by: Kyungmin Park 
---
 Documentation/DocBook/v4l/controls.xml|   67 +
 Documentation/DocBook/v4l/videodev2.h.xml |8 +++
 2 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/Documentation/DocBook/v4l/controls.xml 
b/Documentation/DocBook/v4l/controls.xml
index 2fae3e8..b940e21 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1860,6 +1860,73 @@ it one step further. This is a write-only 
control.
  
  
 
+ 
+   V4L2_CID_FOCUS_AUTO_MODE 
+   enum v4l2_focus_auto_mode_type
+ Enables setting modes of
+auto focus. The focus has 5 kinds of mode, and each enumerations express
+current auto focus mode in which the camera is. In the case of
+V4L2_FOCUS_AUTO_RECTANGLE, this control id can be clustered with
+4 control id which means focusing spot expressed by 4 point of rectangle.
+ 
+ 
+ 
+   
+ 
+   
+ 
V4L2_FOCUS_AUTO_NORMAL 
+ Normal mode Auto focus, single shot.
+   
+   
+ 
V4L2_FOCUS_AUTO_MACRO 
+ Macro mode Auto focus, single shot.
+   
+   
+ 
V4L2_FOCUS_AUTO_CONTINUOUS 
+ Continuous mode Auto focus, continuous shot.
+   
+   
+ 
V4L2_FOCUS_AUTO_FACE_DETECTION 
+ Face detection mode Auto focus, single shot.
+   
+   
+ 
V4L2_FOCUS_AUTO_RECTANGLE 
+ Rectangle mode Auto focus, single shot.
+   
+ 
+   
+ 
+ 
+
+ 
+   V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT 
+   integer
+ This control means the left
+side's point of the rectangle expressing focusing spot.
+ 
+ 
+
+   V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP 
+   integer
+ This control means the top
+side's point of the rectangle expressing focusing spot.
+ 
+ 
+
+   V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH 
+   integer
+ This control means the width
+length of the rectangle expressing focusing spot.
+ 
+ 
+
+   V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT 
+   integer
+ This control means the height
+length of the rectangle expressing focusing spot.
+ 
+ 
+
  
V4L2_CID_PRIVACY 
boolean
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml 
b/Documentation/DocBook/v4l/videodev2.h.xml
index 2b796a2..6bb67a6 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1385,6 +1385,14 @@ enum  v4l2_exposure_auto_type {
 #define V4L2_CID_IRIS_ABSOLUTE  (V4L2_CID_CAMERA_CLASS_BASE+17)
 #define V4L2_CID_IRIS_RELATIVE  (V4L2_CID_CAMERA_CLASS_BASE+18)
 
+enum  v4l2_focus_auto_mode_type {
+   V4L2_FOCUS_AUTO_NORMAL = 0,
+   V4L2_FOCUS_AUTO_MACRO = 1,
+   V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+   V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+   V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+
 /* FM Modulator class control IDs */
 #define V4L2_CID_FM_TX_CLASS_BASE   (V4L2_CTRL_CLASS_FM_TX | 0x900)
 #define V4L2_CID_FM_TX_CLASS(V4L2_CTRL_CLASS_FM_TX | 1)
-- 
1.7.0.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

[RFC PATCH v3 1/2] v4l2-ctrls: support various modes and 4 coordinates of rectangle auto focus

[Kim, Heungjun]

It supports various modes of auto focus. Each modes define as the enumerations
of menu type.

V4L2_FOCUS_AUTO_NORMAL,
V4L2_FOCUS_AUTO_MACRO,
V4L2_FOCUS_AUTO_CONTINUOUS,
V4L2_FOCUS_AUTO_FACE_DETECTION,
V4L2_FOCUS_AUTO_RECTANGLE

In the cause of rectangle it needs the 4 kinds of coordinate control ID of
integer type for expression about focus-spot, and each control ID means
similar to the struct v4l2_rect.

V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT
V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP
V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH
V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT

Signed-off-by: Kim, Heungjun 
Signed-off-by: Kyungmin Park 
---
 drivers/media/video/v4l2-ctrls.c |   16 
 include/linux/videodev2.h|   13 +
 2 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 2412f08..365540f 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -197,6 +197,14 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Aperture Priority Mode",
NULL
};
+   static const char * const camera_focus_auto_mode[] = {
+   "Normal Mode",
+   "Macro Mode",
+   "Continuous Mode",
+   "Face Detection Mode",
+   "Rectangle Mode",
+   NULL
+   };
static const char * const colorfx[] = {
"None",
"Black & White",
@@ -252,6 +260,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return camera_power_line_frequency;
case V4L2_CID_EXPOSURE_AUTO:
return camera_exposure_auto;
+   case V4L2_CID_FOCUS_AUTO_MODE:
+   return camera_focus_auto_mode;
case V4L2_CID_COLORFX:
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
@@ -365,6 +375,11 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_PRIVACY:  return "Privacy";
case V4L2_CID_IRIS_ABSOLUTE:return "Iris, Absolute";
case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative";
+   case V4L2_CID_FOCUS_AUTO_MODE:  return "Focus, Mode";
+   case V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT: return "Focus, Rectangle Left";
+   case V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP: return "Focus, Rectangle Top";
+   case V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH: return "Focus, Rectangle 
Width";
+   case V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT: return "Focus, Rectangle 
Height";
 
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -450,6 +465,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_MPEG_STREAM_TYPE:
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
+   case V4L2_CID_FOCUS_AUTO_MODE:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
*type = V4L2_CTRL_TYPE_MENU;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index aa6c393..99cd1b7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1389,6 +1389,19 @@ enum  v4l2_exposure_auto_type {
 #define V4L2_CID_IRIS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+17)
 #define V4L2_CID_IRIS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+18)
 
+#define V4L2_CID_FOCUS_AUTO_MODE   (V4L2_CID_CAMERA_CLASS_BASE+19)
+enum  v4l2_focus_mode_type {
+   V4L2_FOCUS_AUTO_NORMAL = 0,
+   V4L2_FOCUS_AUTO_MACRO = 1,
+   V4L2_FOCUS_AUTO_CONTINUOUS = 2,
+   V4L2_FOCUS_AUTO_FACE_DETECTION = 3,
+   V4L2_FOCUS_AUTO_RECTANGLE = 4
+};
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_LEFT (V4L2_CID_CAMERA_CLASS_BASE+20)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_TOP  (V4L2_CID_CAMERA_CLASS_BASE+21)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_WIDTH(V4L2_CID_CAMERA_CLASS_BASE+22)
+#define V4L2_CID_FOCUS_AUTO_RECTANGLE_HEIGHT   (V4L2_CID_CAMERA_CLASS_BASE+23)
+
 /* FM Modulator class control IDs */
 #define V4L2_CID_FM_TX_CLASS_BASE  (V4L2_CTRL_CLASS_FM_TX | 0x900)
 #define V4L2_CID_FM_TX_CLASS   (V4L2_CTRL_CLASS_FM_TX | 1)
-- 
1.7.0.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

[RFC PATCH v3 0/2] v4l2-ctrls: add auto focus mode and controls

[Kim, HeungJun]

Hello,

This is third version of RFC patch series about adding auto focus mode
and controls. The patch of the previous version bring about the issue
to be able to execute only once, not repeatedly. Because the each modes
are defined by menu type. To solve this, we add the new control of
choosing focus mode, and if doing repeatedly, it's alright that you
determine the focus mode and change the value of V4L2_CID_FOCUS_AUTO.

In the case of new added rectangle mode, these each controls belongs to
4 new controls, can make to point by the form of rectangle. These 4 new
each control values mean left x coordinate, top y coordinate,
width x length, height y length. It's similar to structure v4l2_rect.

You can find previous threads about this:
http://www.spinics.net/lists/linux-media/msg29446.html

Thanks and Regards,
Heungjun Kim
--
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