Re: [PATCH 3/6] V4L/DVB: smsusb: enable IR port for Hauppauge WinTV MiniStick

2010-08-02 Thread Richard Zidlicky
On Sun, Aug 01, 2010 at 05:17:18PM -0300, Mauro Carvalho Chehab wrote:
> Add the proper gpio port for WinTV MiniStick, with the information provided
> by Michael.
> 
> Thanks-to: Michael Krufky 
> Signed-off-by: Mauro Carvalho Chehab 
> 
> diff --git a/drivers/media/dvb/siano/sms-cards.c 
> b/drivers/media/dvb/siano/sms-cards.c
> index cff77e2..dcde606 100644
> --- a/drivers/media/dvb/siano/sms-cards.c
> +++ b/drivers/media/dvb/siano/sms-cards.c
> @@ -67,6 +67,7 @@ static struct sms_board sms_boards[] = {
>   .board_cfg.leds_power = 26,
>   .board_cfg.led0 = 27,
>   .board_cfg.led1 = 28,
> + .board_cfg.ir = 9,
   

are you sure about this?

I am using the value of 4 for the ir port and it definitely works.. confused.

Thanks for looking at it, will test the patches as soon as I can.

Richard
--
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: Handling of large keycodes

2010-08-02 Thread Dmitry Torokhov
On Sat, Jul 31, 2010 at 10:23:45AM -0300, Mauro Carvalho Chehab wrote:
> Hi Dmitry,
> 
> Em 31-07-2010 06:19, Dmitry Torokhov escreveu:
> > Hi Mauro,
> > 
> > I finally got a chance to review the patches adding handling of large
> > scancodes to input core and there are a few things with this approach
> > that I do not like.
> 
> Thanks for the review!
> 
> > First of all I do not think that we should be working with scancode via
> > a pointer as it requires additional compat handling when running 32-bit
> > userspace on 64-bit kernel. We can use a static buffer of sufficient
> > size (lets say 32 bytes) to move scancode around and simply increase its
> > size if we come upon device that uses even bigger scancodes. As long as
> > buffer is at the end we can handle this in a compatible way.
> 
> Yes, this is the downside of using a pointer. I'm not aware of a Remote
> Controller protocol using more than 256 bits for scancode, so 32 bits
> should be ok.
> 
> > The other issue is that interface is notsymmetrical, setting is done by
> > scancode but retrieval is done by index. I think we should be able to
> > use both scancode and index in both operations.
> 
> Yes, this also bothered me. I was thinking to do something similar to your
> approach of having a bool to select between them. This change is welcome.
> 
> > The usefulnes of reserved data elements in the structure is doubtful,
> > since we do not seem to require them being set to a particular value and
> > so we'll be unable to distinguish betwee legacy and newer users.
> 
> David proposed some parameters that we rejected on our discussions. As we
> might need to add something similar, I decided to keep it on my approach,
> since a set of reserved fields wouldn't hurt (and removing it on our 
> discussions
> would be easy), but I'm ok on removing them.
> 
> > I also concerned about the code very messy with regard to using old/new
> > style interfaces instea dof converting old ones to use new
> > insfrastructure,
> 
> Good cleanup at the code!
> 
> > I below is something that addresses these issues and seems to be working
> > for me. It is on top of your patches and it also depends on a few
> > changes in my tree that I have not publushed yet but plan on doing that
> > tomorrow. I am also attaching patches converting sparse keymap and hid
> > to the new style of getkeycode and setkeycode as examples.
> > 
> > Please take a look and let me know if I missed something important.
> 
> It seems to work for me. After you add the patches on your git tree, I'll 
> work on porting the RC core to the new approach, and change the ir-keycode
> userspace program to work with, in order to be 100% sure that it will work, 
> but I can't foresee any missing part on it.
> 
> Currently, I'm not using my input patches, as I was waiting for your
> review. I just patched the userspace application, in order to test the legacy
> mode.
>

OK, great.

I want to fold all the patches from your tree plus this one into one and
apply in one shpt (mentioning Jarod and Dan as authors of fixup patches
in the changelog) - I do not believe we shoudl expose intermediate
versions in the code that will go to Linus. Are you OK with this?

Thanks.

-- 
Dmitry
--
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: Handling of large keycodes

2010-08-02 Thread Dmitry Torokhov
On Sat, Jul 31, 2010 at 01:03:26PM +0200, Stefan Richter wrote:
> Dmitry Torokhov wrote:
> > --- a/include/linux/input.h
> > +++ b/include/linux/input.h
> > @@ -56,22 +56,35 @@ struct input_absinfo {
> > __s32 resolution;
> >  };
> >  
> > -struct keycode_table_entry {
> > -   __u32 keycode;  /* e.g. KEY_A */
> > -   __u32 index;/* Index for the given scan/key table, on 
> > EVIOCGKEYCODEBIG */
> > -   __u32 len;  /* Length of the scancode */
> > -   __u32 reserved[2];  /* Reserved for future usage */
> > -   char *scancode; /* scancode, in machine-endian */
> > +/**
> > + * struct keymap_entry - used by EVIOCGKEYCODE/EVIOCSKEYCODE ioctls
> > + * @scancode: scancode represented in machine-endian form.
> > + * @len: length of the scancode that resides in @scancode buffer.
> > + * @index: index in the keymap, may be used instead of scancode
> > + * @by_index: boolean value indicating that kernel should perform
> > + * lookup in keymap by @index instead of @scancode
> > + * @keycode: key code assigned to this scancode
> > + *
> > + * The structure is used to retrieve and modify keymap data. Users have
> > + * of performing lookup either by @scancode itself or by @index in
> > + * keymap entry. EVIOCGKEYCODE will also return scancode or index
> > + * (depending on which element was used to perform lookup).
> > + */
> > +struct keymap_entry {
> > +   __u8  len;
> > +   __u8  by_index;
> > +   __u16 index;
> > +   __u32 keycode;
> > +   __u8  scancode[32];
> >  };
> 
> I agree with Dimitry; don't put a pointer typed member into a userspace
> ABI struct.
> 
> Two remarks:
> 
>   - Presently,  defines three structs named input_... for
> userspace, two structs named input_... for kernelspace, and a few
> structs named ff_... specially for force-feedback stuff.  How about
> calling struct keymap_entry perhaps struct input_keymap_entry
> instead, to keep namespaces tidy?

Good idea, changed.

> 
>   - I take it from your description that scan codes are fundamentally
> variable-length data.  How about defining it as __u8 scancode[0]?

In addition to difficulty in adding members (as you mentioned) it also
makes it more difficult for users to allocate such variables on stack or
make them global (anything but malloc with additional memory buffer)...

-- 
Dmitry
--
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 v5 0/3] Multi-planar video format and buffer support for the V4L2 API

2010-08-02 Thread Pawel Osciak
Hi,
thanks for the review.

>Karicheri, Muralidharan  wrote:
>
>>
>>
>>7. Format conversion
>>--
>>v4l2 core ioctl handling includes a simple conversion layer that allows
>>translation - when possible - between multi-planar and single-planar APIs,
>>transparently to drivers and applications.
>>
>>The table below summarizes conversion behavior for cases when driver and
>>application use different API versions:
>>
>>---
>>  | Application MP --> Driver SP --> Application MP
>>   G_FMT  |always OK   |   always OK
>>   S_FMT  |-EINVAL |   always OK
>> TRY_FMT  |-EINVAL |   always OK
>>---
>>  | Application SP --> Driver MP --> Application SP
>>   G_FMT  |always OK   |   -EBUSY
>>   S_FMT  |always OK   |   -EBUSY and WARN()
>> TRY_FMT  |always OK   |   -EBUSY and WARN()
>>
>
>What is the logic behind using -EBUSY for this? Why not -EINVAL? Also why use
>WARN()?
>

We think that it's better to return EBUSY from a G_FMT call to say:
"Your call is valid, but I cannot tell you the format now, but may be able to
later" (i.e. after I switch back to a single-planar format). EINVAL just says
"Your call is invalid", i.e. no point in retrying. Also, EINVAL doesn't really
make sense for G_FMT.

WARN because, as explained below, we think of it as a bug in driver to adjust
a 1-plane format to a >1-plane format on S/TRY.

>>Legend:
>>- SP - single-planar API used (NOT format!)
>>- MP - multi-planar API used (NOT format!)
>>- always OK - conversion is always valid irrespective of number of planes
>>- -EINVAL - if an MP application tries to TRY or SET a format with more
>>than 1 plane, EINVAL is returned from the conversion function
>>(of course, 1-plane multi-planar formats work and are
>>converted)
>>- -EBUSY - if an MP driver returns a more than 1-plane format to an SP
>>   application, the conversion layer returns EBUSY to the
>>application;
>>   this is useful in cases when the driver is currently set to a
>>more
>>   than 1-plane format, SP application would not be able to
>>understand
>>   it)
>>- -EBUSY and WARN() - there is only one reason for which SET or TRY from an
>>SP
>>   application would result in a driver returning a more than 1-
>>plane
>>   format - when the driver adjusts a 1-plane format to a more than
>>   1-plane format. This should not happen and is a bug in driver,
>>hence
>>   a WARN_ON(). Application receives EBUSY.
>>
>>
>
>Suppose, S_FMT/TRY_FMT is called with UYVY format and driver supports only
>NV12 (2 plane) only, then for
>
>Application SP --> Driver MP --> Application SP
>
>I guess in this case, new drivers that supports multi-plane format would have
>to return old NV12 format code (for backward compatibility). Is
>this handled by driver or translation layer?
>

Not really. If a driver supports a 2-plane format only, an SP application
won't be able to use it (unless we copy video data from two separate memory
buffers into one and back on each QBUF/DQBUF in core ioctl handling, I don't
think we want to go that far). The app expects one buffer, not two. So this is
an EINVAL.

>Application MP --> Driver SP --> Application MP
>
>In this case, new driver would return new NV12 format code and have no issue.
>Not sure what translation layer does in this scenario.
>

Again, not really. If an MP application requests a 2-plane format, the driver
cannot support it (it can support 1-plane formats only). So this is also
an EINVAL.

Overall, we do not convert v4l2_buffers, we only convert format structs (not
the actual formats).

>
>
>>
>>===
>>V. Using ioctl()s and mmap()
>>===
>>
>>* Format calls (VIDIOC_S/TRY/G_FMT) are converted transparently across APIs
>>  by the ioctl handling code, where possible. Conversion from single-planar
>>  to multi-planar cannot fail, but the other way around is possible only
>>for
>>  1-plane formats.
>>  Possible errors in conversion are described below.
>>
>
>Could you explain what you mean by conversion of formats? The idea of the
>translation layer functionality is not clear to me. An example would help.
>


I guess this needs to be rephrased:

It doesn't convert the actual formats, it only converts between APIs, i.e.
between different format structs. So it's a conversion between struct
v4l2_pix_format_mplane and struct v4l2_pix_format. It's not a conversion
of formats, the format stays completely identical.

So basically an NV12 format can be passed as well in a v4l2_pix_format
struct as in v4l2_pix_format_mplane. Fourccs and other fields will be
exactly the same. Only the location of those fields will differ,
a v4l2_pix

TeVii S470 periodically fails to tune/lock - needs poweroff

2010-08-02 Thread O&M Ugarcina

Hello Guys,

I have been using my TeVii S470 DVBS2 card for about one month . I am 
using it with mythtv on fedora 12 using latest kernel , and compiled the 
latest v4l drivers . The sensitivity and picture is very good both on 
dvbs and dvbs2 transponders , very happy with that . However several 
times already when trying to watch live tv on myth the channel failed to 
tune . Usually happens in the morning after box was running 24x7 for a 
few days . The only way to restore functionality is to do a power off 
and wait a couple of mins . If I just do a reboot , this does not help . 
Strange thing is that I see nothing in the mythtv logs or dmesg or 
messages log . When the card is in this no-lock state , it will not tune 
into any channel even when I run scandvb . After power off everything 
works again for a few more days . Any info welcome .


Best Regards

Milorad
--
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 v5 1/3] v4l: Add multi-planar API definitions to the V4L2 API

2010-08-02 Thread Pawel Osciak
Hi Hans,
thank you for the review.

>Hans Verkuil  wrote:
>On Friday 30 July 2010 10:49:41 Pawel Osciak wrote:



>> @@ -157,9 +158,23 @@ enum v4l2_buf_type {
>>  /* Experimental */
>>  V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
>>  #endif
>> +V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 17,
>> +V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE  = 18,
>
>Why 17 and 18 instead of 9 and 10?
>

To be able to test for "mplane" versions with a bit operation,
(type & 0x10), and to leave some space for future extensions
to "old" formats. I can go back to 9, 10 though if you prefer.


>> + *
>> + * Multi-planar buffers consist of one or more planes, e.g. an YCbCr
>buffer
>> + * with two planes can have one plane for Y, and another for interleaved
>CbCr
>> + * components. Each plane can reside in a separate memory buffer, or even
>in
>> + * a completely separate memory node (e.g. in embedded devices).
>> + */
>> +struct v4l2_plane {
>> +__u32   bytesused;
>> +__u32   length;
>> +union {
>> +__u32   mem_offset;
>> +unsigned long   userptr;
>> +} m;
>> +__u32   data_offset;
>> +__u32   reserved[11];
>> +};
>> +
>> +/**
>> + * struct v4l2_buffer - video buffer info
>> + * @index:  id number of the buffer
>> + * @type:   buffer type (type == *_MPLANE for multiplanar buffers)
>> + * @bytesused:  number of bytes occupied by data in the buffer 
>> (payload);
>> + *  unused (set to 0) for multiplanar buffers
>> + * @flags:  buffer informational flags
>> + * @field:  field order of the image in the buffer
>> + * @timestamp:  frame timestamp
>> + * @timecode:   frame timecode
>> + * @sequence:   sequence count of this frame
>> + * @memory: the method, in which the actual video data is passed
>> + * @offset: for non-multiplanar buffers with memory ==
>V4L2_MEMORY_MMAP;
>> + *  offset from the start of the device memory for this plane,
>> + *  (or a "cookie" that should be passed to mmap() as offset)
>> + * @userptr:for non-multiplanar buffers with memory ==
>V4L2_MEMORY_USERPTR;
>> + *  a userspace pointer pointing to this buffer
>> + * @planes: for multiplanar buffers; userspace pointer to the array
>of plane
>> + *  info structs for this buffer
>> + * @length: size in bytes of the buffer (NOT its payload) for single-
>plane
>> + *  buffers (when type != *_MPLANE); number of planes (and number
>> + *  of elements in the planes array) for multi-plane buffers
>
>This is confusing. Just write "number of elements in the planes array".
>
>> + * @input:  input number from which the video data has has been captured
>> + *
>> + * Contains data exchanged by application and driver using one of the
>Streaming
>> + * I/O methods.
>> + */
>>  struct v4l2_buffer {
>>  __u32   index;
>>  enum v4l2_buf_type  type;
>> @@ -529,6 +606,7 @@ struct v4l2_buffer {
>>  union {
>>  __u32   offset;
>>  unsigned long   userptr;
>> +struct v4l2_plane *planes;
>
>Should use the __user attribute.
>

We discussed this already, just for others: since we use the "planes" pointer
both as __user and kernel pointer, it's not worth it. We'd have to do some
obscure #ifdef magic and redefine the struct for parts of kernel code.
The same thing goes for controls pointer in v4l2_ext_controls.

Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center


--
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 v5 2/3] v4l: Add multi-planar ioctl handling code

2010-08-02 Thread Pawel Osciak
Hi,

>Hans Verkuil  wrote:
>On Friday 30 July 2010 10:49:42 Pawel Osciak wrote:



>>  static long __video_do_ioctl(struct file *file,
>>  unsigned int cmd, void *arg)
>>  {
>>  struct video_device *vfd = video_devdata(file);
>>  const struct v4l2_ioctl_ops *ops = vfd->ioctl_ops;
>>  void *fh = file->private_data;
>> +struct v4l2_format f_copy;
>>  long ret = -EINVAL;
>>
>>  if (ops == NULL) {
>> @@ -720,6 +822,11 @@ static long __video_do_ioctl(struct file *file,
>>  if (ops->vidioc_enum_fmt_vid_cap)
>>  ret = ops->vidioc_enum_fmt_vid_cap(file, fh, f);
>>  break;
>> +case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
>> +if (ops->vidioc_enum_fmt_vid_cap_mplane)
>> +ret = ops->vidioc_enum_fmt_vid_cap_mplane(file,
>> +fh, f);
>> +break;
>>  case V4L2_BUF_TYPE_VIDEO_OVERLAY:
>>  if (ops->vidioc_enum_fmt_vid_overlay)
>>  ret = ops->vidioc_enum_fmt_vid_overlay(file,
>> @@ -729,6 +836,11 @@ static long __video_do_ioctl(struct file *file,
>>  if (ops->vidioc_enum_fmt_vid_out)
>>  ret = ops->vidioc_enum_fmt_vid_out(file, fh, f);
>>  break;
>> +case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
>> +if (ops->vidioc_enum_fmt_vid_out_mplane)
>> +ret = ops->vidioc_enum_fmt_vid_out_mplane(file,
>> +fh, f);
>> +break;
>>  case V4L2_BUF_TYPE_PRIVATE:
>>  if (ops->vidioc_enum_fmt_type_private)
>>  ret = ops->vidioc_enum_fmt_type_private(file,
>> @@ -757,22 +869,79 @@ static long __video_do_ioctl(struct file *file,
>>
>>  switch (f->type) {
>>  case V4L2_BUF_TYPE_VIDEO_CAPTURE:
>> -if (ops->vidioc_g_fmt_vid_cap)
>> +if (ops->vidioc_g_fmt_vid_cap) {
>>  ret = ops->vidioc_g_fmt_vid_cap(file, fh, f);
>> +} else if (ops->vidioc_g_fmt_vid_cap_mplane) {
>> +if (fmt_sp_to_mp(f, &f_copy))
>> +break;
>> +ret = ops->vidioc_g_fmt_vid_cap_mplane(file, fh,
>> +
>> &f_copy);
>> +/* Driver is currently in multi-planar format,
>> + * we can't return it in single-planar API*/
>> +if (f_copy.fmt.pix_mp.num_planes > 1) {
>
>Only do this if ret == 0.
>

Good point, thanks. Driver-produced errors should take precedence over EBUSY.


Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center





--
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 v5 1/3] v4l: Add multi-planar API definitions to the V4L2 API

2010-08-02 Thread Hans Verkuil
Hi Pawel!

> Hi Hans,
> thank you for the review.
>
>>Hans Verkuil  wrote:
>>On Friday 30 July 2010 10:49:41 Pawel Osciak wrote:
>
> 
>
>>> @@ -157,9 +158,23 @@ enum v4l2_buf_type {
>>> /* Experimental */
>>> V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
>>>  #endif
>>> +   V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 17,
>>> +   V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE  = 18,
>>
>>Why 17 and 18 instead of 9 and 10?
>>
>
> To be able to test for "mplane" versions with a bit operation,
> (type & 0x10), and to leave some space for future extensions
> to "old" formats. I can go back to 9, 10 though if you prefer.

I prefer 9, 10. I would agree with you if there was some sort
of numbering scheme already, but it is just an enum with no particular
order.

>
>
>>> + *
>>> + * Multi-planar buffers consist of one or more planes, e.g. an YCbCr
>>buffer
>>> + * with two planes can have one plane for Y, and another for
>>> interleaved
>>CbCr
>>> + * components. Each plane can reside in a separate memory buffer, or
>>> even
>>in
>>> + * a completely separate memory node (e.g. in embedded devices).
>>> + */
>>> +struct v4l2_plane {
>>> +   __u32   bytesused;
>>> +   __u32   length;
>>> +   union {
>>> +   __u32   mem_offset;
>>> +   unsigned long   userptr;
>>> +   } m;
>>> +   __u32   data_offset;
>>> +   __u32   reserved[11];
>>> +};
>>> +
>>> +/**
>>> + * struct v4l2_buffer - video buffer info
>>> + * @index: id number of the buffer
>>> + * @type:  buffer type (type == *_MPLANE for multiplanar buffers)
>>> + * @bytesused: number of bytes occupied by data in the buffer
>>> (payload);
>>> + * unused (set to 0) for multiplanar buffers
>>> + * @flags: buffer informational flags
>>> + * @field: field order of the image in the buffer
>>> + * @timestamp: frame timestamp
>>> + * @timecode:  frame timecode
>>> + * @sequence:  sequence count of this frame
>>> + * @memory:the method, in which the actual video data is passed
>>> + * @offset:for non-multiplanar buffers with memory ==
>>V4L2_MEMORY_MMAP;
>>> + * offset from the start of the device memory for this 
>>> plane,
>>> + * (or a "cookie" that should be passed to mmap() as 
>>> offset)
>>> + * @userptr:   for non-multiplanar buffers with memory ==
>>V4L2_MEMORY_USERPTR;
>>> + * a userspace pointer pointing to this buffer
>>> + * @planes:for multiplanar buffers; userspace pointer to the array
>>of plane
>>> + * info structs for this buffer
>>> + * @length:size in bytes of the buffer (NOT its payload) for 
>>> single-
>>plane
>>> + * buffers (when type != *_MPLANE); number of planes (and 
>>> number
>>> + * of elements in the planes array) for multi-plane buffers
>>
>>This is confusing. Just write "number of elements in the planes array".
>>
>>> + * @input: input number from which the video data has has been
>>> captured
>>> + *
>>> + * Contains data exchanged by application and driver using one of the
>>Streaming
>>> + * I/O methods.
>>> + */
>>>  struct v4l2_buffer {
>>> __u32   index;
>>> enum v4l2_buf_type  type;
>>> @@ -529,6 +606,7 @@ struct v4l2_buffer {
>>> union {
>>> __u32   offset;
>>> unsigned long   userptr;
>>> +   struct v4l2_plane *planes;
>>
>>Should use the __user attribute.
>>
>
> We discussed this already, just for others: since we use the "planes"
> pointer
> both as __user and kernel pointer, it's not worth it. We'd have to do some
> obscure #ifdef magic and redefine the struct for parts of kernel code.
> The same thing goes for controls pointer in v4l2_ext_controls.

Indeed. This is also the reason why there is no __user in v4l2_ext_controls.

Regards,

 Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco

--
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: No audio in HW Compressed MPEG2 container on HVR-1300

2010-08-02 Thread lawrence rust
On Mon, 2010-08-02 at 14:15 +1200, Shane Harrison wrote:
> Hi There,
> 
> I am having a problem with getting an audio stream present in the
> MPEG2 stream from an HVR-1300 card.

[snip]

> Problem
> ~~
> The delivered MPEG-2 stream generally has no audio component. Mplayer
> reports "no audio found".
> 
> The same problem exists for both TV input and composite input.  By
> repeatedly switching between the TV input and the Composite input we
> can eventually get an audio component in the MPEG-2 stream.
> Thereafter we always get the audio component until a power off and
> restart.  Simply rebooting (no power off) seems to still leave things
> in a state where the audio component is in the MPEG-2 stream.
> 
> There is a second problem, the audio stream always contains white
> noise (I assume TV tuner noise - we don't have it tuned nor an aerial
> attached) mixed with the signal applied to the analog in ports.
> 
> Analysis
> ~~
> The most likely scenario is that the hardware is not being initialised
> correctly most of the time, once it is initialised correctly then it
> works thereafter.  Unfortunately it is difficult to determine the
> actual audio path being used.  Clearly the audio comes into the WM8775
> (DAC) via a bus switch that switches between the composite/audio on
> the back panel and the white header.  It then enters the CX2388x via
> the I2S input pins.  We initially assumed that the audio was then
> routed through to the CX23416 (MPEG Encoder) via the I2S output pins
> of the CX2388x, but we have begun to doubt this assumption since the
> CX2388x is set in normal mode by the drivers and the captured audio
> doesn't reflect the bit patterns we see on the I2S Data Out line using
> an oscilloscope.  That is, when we apply *no* signal to the analog
> input, the I2S Dout line is "quiet" yet we hear white noise.
> 
> Questions
> 
> 1) Anyone have any similar experiences?

This sounds very much like the problems that I had with my Nova-S-plus
card while developing a patch to capture line-in audio with composite
video.  Looking at the docs for the wm8775 it appeared that it wasn't
being correctly initialised.  I also found need to change the cx88 code
to mute/un-mute audio in.  Maybe you should try applying this patch, I
posted it to this group on Saturday - see.

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

-- Lawrence Rust


--
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] V4L/DVB: radio-si4713: Release i2c adapter in driver cleanup paths

2010-08-02 Thread Jarkko Nikula
On Mon, 05 Jul 2010 16:28:30 -0300
Mauro Carvalho Chehab  wrote:

> Hi Eduardo,
> 
> Could you please review those two patches?
> 
Hmm.. are these two patches already late for 2.6.36? I have two another
patches to arch/arm/mach-omap2/board-rx51-peripherals.c and
sound/soc/omap/rx51.c that are pending from patch 2/2.


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


STK7700D id is 1164:0871 on Toshiba A660 laptops, conflicts with Yuan MC770

2010-08-02 Thread Olivier Poulet
Hello all,

I am running Ubuntu 10.04 on a Toshiba A660-14x laptop. The hybrid
tuner is being reported in Windows 7 as based on the STK7700D. Both
tuners (dvb & analog) work correctly there.

However, it's usb vendor & device strings are 1164:0871, see the
output of hwinfo below. This makes the dvb modules configure it as if
it where a "Yuan High-Tech MC770"

This results in Linux only seeing the DVB tuner, which works fine. The
analog one isn't used, so I am missing all the analog channels (there
are still some :-) ) I can catch from my location.

Is there any module options I could pass to "force" it to be seen as a STK770D ?

Best regards,
Olivier

09: USB 00.0:  Unclassified device
[Created at usb.122]
UDI: /org/freedesktop/Hal/devices/usb_device_1164_871_01_if0
Unique ID: VBUu.DOCYvzmCULD
Parent ID: ADDn.0j9+vWlqL56
SysFS ID: /devices/pci:00/:00:1a.0/usb1/1-1/1-1.5/1-1.5:1.0
SysFS BusID: 1-1.5:1.0
Hardware Class: unknown
Model: "YUAN High-Tech Development STK7700D"
Hotplug: USB
Vendor: usb 0x1164 "YUAN High-Tech Development Co., Ltd"
Device: usb 0x0871 "STK7700D"
Revision: "1.00"
Serial ID: "01"
Driver: "dvb_usb_dib0700"
Driver Modules: "dvb_usb_dib0700"
Speed: 480 Mbps
Module Alias: "usb:v1164p0871d0100dc00dsc00dp00icFFisc00ip00"
Driver Info #0:
  Driver Status: dvb_usb_dib0700 is active
  Driver Activation Cmd: "modprobe dvb_usb_dib0700"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #5 (Hub)
--
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


Fwd: No audio in HW Compressed MPEG2 container on HVR-1300

2010-08-02 Thread Shane Harrison
On Mon, Aug 2, 2010 at 9:32 PM, lawrence rust  wrote:
>
> On Mon, 2010-08-02 at 14:15 +1200, Shane Harrison wrote:
> > Hi There,
> >
> > I am having a problem with getting an audio stream present in the
> > MPEG2 stream from an HVR-1300 card.
>
> [snip]
>
> > Problem
> > ~~
> > The delivered MPEG-2 stream generally has no audio component. Mplayer
> > reports "no audio found".
> >
> > The same problem exists for both TV input and composite input.  By
> > repeatedly switching between the TV input and the Composite input we
> > can eventually get an audio component in the MPEG-2 stream.
> > Thereafter we always get the audio component until a power off and
> > restart.  Simply rebooting (no power off) seems to still leave things
> > in a state where the audio component is in the MPEG-2 stream.
> >
> > There is a second problem, the audio stream always contains white
> > noise (I assume TV tuner noise - we don't have it tuned nor an aerial
> > attached) mixed with the signal applied to the analog in ports.
> >
> > Analysis
> > ~~
> > The most likely scenario is that the hardware is not being initialised
> > correctly most of the time, once it is initialised correctly then it
> > works thereafter.  Unfortunately it is difficult to determine the
> > actual audio path being used.  Clearly the audio comes into the WM8775
> > (DAC) via a bus switch that switches between the composite/audio on
> > the back panel and the white header.  It then enters the CX2388x via
> > the I2S input pins.  We initially assumed that the audio was then
> > routed through to the CX23416 (MPEG Encoder) via the I2S output pins
> > of the CX2388x, but we have begun to doubt this assumption since the
> > CX2388x is set in normal mode by the drivers and the captured audio
> > doesn't reflect the bit patterns we see on the I2S Data Out line using
> > an oscilloscope.  That is, when we apply *no* signal to the analog
> > input, the I2S Dout line is "quiet" yet we hear white noise.
> >
> > Questions
> > 
> > 1) Anyone have any similar experiences?
>
> This sounds very much like the problems that I had with my Nova-S-plus
> card while developing a patch to capture line-in audio with composite
> video.  Looking at the docs for the wm8775 it appeared that it wasn't
> being correctly initialised.  I also found need to change the cx88 code
> to mute/un-mute audio in.  Maybe you should try applying this patch, I
> posted it to this group on Saturday - see.
>
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg21030.html
>
> -- Lawrence Rust
>
>
Thanks Lawrence, will give that a whirl tomorrow and the muting idea
might be important in this case as well.  Wierd you posted Saturday
the day after I last worked on this and looked at the archives :-)

I am not ruling out initialisation problems with the WM8775 but I do
always seem to get an I2S output from it that has data in it that
reflects the input.  However it could be the wrong variant of I2S or
some other configuration that isn't set right.  Strange how eventually
I do get audio (albeit mixed with the TV source it appears) simply by
looping thru and changing input sources with v4l2-ctl.

I note that the Nova-S doesn't have the hardware MPEG encoding so
still hoping someone can enlighten me on the audio path when using
that chip.

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


RE: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface

2010-08-02 Thread Pawel Osciak
Hello,

>Kukjin Kim  wrote:
>Sylwester Nawrocki wrote:
>>
>> Add register definitions for the camera interface/video postprocessor
>> contained in Samsung's S5P SoC series.
>>
>> Signed-off-by: Sylwester Nawrocki 
>> Signed-off-by: Kyungmin Park 
>> Reviewed-by: Pawel Osciak 
>> Reviewed-by: Marek Szyprowski 
>> ---
>>  arch/arm/plat-samsung/include/plat/regs-fimc.h |  294
>> 
>>  1 files changed, 294 insertions(+), 0 deletions(-)
>>  create mode 100644 arch/arm/plat-samsung/include/plat/regs-fimc.h
>>
>> diff --git a/arch/arm/plat-samsung/include/plat/regs-fimc.h
>b/arch/arm/plat-
>> samsung/include/plat/regs-fimc.h
>> new file mode 100644
>> index 000..7f3141c
>> --- /dev/null
>> +++ b/arch/arm/plat-samsung/include/plat/regs-fimc.h
>> @@ -0,0 +1,294 @@
>> +/* arch/arm/plat-s5p/include/plat/regs-fimc.h
>> + *
>> + * Register definition file for Samsung Camera Interface (FIMC) driver



>
>Looks ok...however, I'm still thinking whether really need all these
>definitions.
>
>Hmm...
>

Well, some of them are indeed unused, but it's not an uncommon practice in
kernel and might help future developers.


Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center





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


Re: [PATCH 00/20] MT9M111/MT9M131

2010-08-02 Thread Michael Grzeschik
Hey Guennadi, Robert

sorry for that lack of information to those patches. I also just have
been slicing one big patch into several canonical and tried to get rid
of most tofu. You see the result in that patchseries. But since some big
changes i could not figure out correctly, i left them in the stack for
review. I should have adding an RFC to the Subject on those. Since i
still have no response from the original author of these patches and you
also see no sense in some changes i will condense the stack to a
managable amount and will repost this v2 series in short time.

Thanks for your time,
Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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 09/13] IR: add helper function for hardware with small o/b buffer.

2010-08-02 Thread Maxim Levitsky
On Sun, 2010-08-01 at 22:11 -0400, Andy Walls wrote: 
> On Sat, 2010-07-31 at 17:59 +0300, Maxim Levitsky wrote:
> > Some ir input devices have small buffer, and interrupt the host
> > each time it is full (or half full)
> > 
> > Add a helper that automaticly handles timeouts, and also
> > automaticly merges samples of same time (space-space)
> > Such samples might be placed by hardware because size of
> > sample in the buffer is small (a byte for example).
> > 
> > Also remove constness from ir_dev_props, because it now contains timeout
> > settings that driver might want to change
> > 
> > Signed-off-by: Maxim Levitsky 
> > Acked-by: Jarod Wilson 
> 
> Hi Maxim and Jarod,
> 
> I've started looking at this patch, and patch 10/13, to work with them
> and build upon them.  I have some comments, below:
> 
> 
> > ---
> >  drivers/media/IR/ir-core-priv.h |1 +
> >  drivers/media/IR/ir-keytable.c  |2 +-
> >  drivers/media/IR/ir-raw-event.c |   84 
> > +++
> >  include/media/ir-core.h |   23 +-
> >  4 files changed, 106 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/media/IR/ir-core-priv.h 
> > b/drivers/media/IR/ir-core-priv.h
> > index be68172..8053e3b 100644
> > --- a/drivers/media/IR/ir-core-priv.h
> > +++ b/drivers/media/IR/ir-core-priv.h
> > @@ -41,6 +41,7 @@ struct ir_raw_event_ctrl {
> >  
> > /* raw decoder state follows */
> > struct ir_raw_event prev_ev;
> > +   struct ir_raw_event this_ev;
> > struct nec_dec {
> > int state;
> > unsigned count;
> > diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
> > index 94a8577..34b9c07 100644
> > --- a/drivers/media/IR/ir-keytable.c
> > +++ b/drivers/media/IR/ir-keytable.c
> > @@ -428,7 +428,7 @@ static void ir_close(struct input_dev *input_dev)
> >   */
> >  int __ir_input_register(struct input_dev *input_dev,
> >   const struct ir_scancode_table *rc_tab,
> > - const struct ir_dev_props *props,
> > + struct ir_dev_props *props,
> >   const char *driver_name)
> >  {
> > struct ir_input_dev *ir_dev;
> > diff --git a/drivers/media/IR/ir-raw-event.c 
> > b/drivers/media/IR/ir-raw-event.c
> > index d0c18db..43094e7 100644
> > --- a/drivers/media/IR/ir-raw-event.c
> > +++ b/drivers/media/IR/ir-raw-event.c
> > @@ -140,6 +140,90 @@ int ir_raw_event_store_edge(struct input_dev 
> > *input_dev, enum raw_event_type typ
> >  EXPORT_SYMBOL_GPL(ir_raw_event_store_edge);
> >  
> >  /**
> > + * ir_raw_event_store_with_filter() - pass next pulse/space to decoders 
> > with some processing
> > + * @input_dev: the struct input_dev device descriptor
> > + * @type:  the type of the event that has occurred
> > + *
> > + * This routine (which may be called from an interrupt context) works
> > + * in similiar manner to ir_raw_event_store_edge.
> > + * This routine is intended for devices with limited internal buffer
> > + * It automerges samples of same type, and handles timeouts
> > + */
> 
> I think this comment might need to explain the filtering being performed
> a little more explicitly, because "handles timeouts" wasn't enough to go
> on.
> 
> >From what I can tell, it performs
> 
>   a. space aggrregation
>   b. auto "idle" of the receiver and some state
>   c. gap measurment and gap space event generation
>   d, decoder reset at the end of the gap
> 
> (For my needs, c. is very useful, and a. & d. don't hurt.)
> 
> What is idle supposed to do for hardware that provides interrupts?
In my case, I can program hardware not to interrupt host until it has
a sample that isn't a overflow sample
Exaplanation what overflow sample is:
Hardware stores samples in small 8 bytes buffer, and has a  flag which
half of this buffer to read.
Each sample is 8 bits, out of which 7 are timing and 8th is pulse/space.
So larger sample is sample period * 127.
If hardware wants to send larger sample, it sends this sample, and
another.
When I enable idle mode, it won't send sample with 127 within them.
Note that this is only supported on my receiver. Newer receivers don't
have that function, but rather stop sending samples on their own after
about 250 ms.



> 
> Aside from asking the hardware driver to do something, idle otherwise
> appears to be used to keep track of being in a gap or not.
> Did I get that all right?
Yes of course.

> 
> > +int ir_raw_event_store_with_filter(struct input_dev *input_dev,
> > +   struct ir_raw_event *ev)
> > +{
> > +   struct ir_input_dev *ir = input_get_drvdata(input_dev);
> > +   struct ir_raw_event_ctrl *raw = ir->raw;
> > +
> > +   if (!raw || !ir->props)
> > +   return -EINVAL;
> > +
> > +   /* Ignore spaces in idle mode */
> > +   if (ir->idle && !ev->pulse)
> > +   return 0;
> > +   else if (ir->idle)
> > +   ir_raw_event_set_idle(input_dev, 0);
> > +
> > +   if (!raw->this_ev.durat

Re: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface

2010-08-02 Thread Russell King - ARM Linux
On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote:
> Well, some of them are indeed unused, but it's not an uncommon practice in
> kernel and might help future developers.

On the other hand, arch/arm is getting soo big that we need to do
something about this - and one solution is to avoid unnecessary
definitions that we're not using.

Another good idea is to put definitions along side the drivers which
they're relevant to - maybe in a local driver-name.h file which
driver-name.c includes, or maybe even within driver-name.c if they're
not excessive.  This has the advantage of distributing the "bloat" to
where its actually used, and means that the driver isn't dependent so
much on arch/arm or even the SoC itself.

Take a look at arch/arm/mach-vexpress/include/mach/ct-ca9x4.h and
arch/arm/mach-vexpress/include/mach/motherboard.h - these are the only
two files which contain platform definitions which are actually used
for Versatile Express.  Compare that with
arch/arm/mach-realview/include/mach/platform.h which contains lots
more...
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface

2010-08-02 Thread Marek Szyprowski
Hello,

On Monday, August 02, 2010 12:52 PM Russell King wrote:

> On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote:
> > Well, some of them are indeed unused, but it's not an uncommon practice
> in
> > kernel and might help future developers.
> 
> On the other hand, arch/arm is getting soo big that we need to do
> something about this - and one solution is to avoid unnecessary
> definitions that we're not using.
> 
> Another good idea is to put definitions along side the drivers which
> they're relevant to - maybe in a local driver-name.h file which
> driver-name.c includes, or maybe even within driver-name.c if they're
> not excessive.  This has the advantage of distributing the "bloat" to
> where its actually used, and means that the driver isn't dependent so
> much on arch/arm or even the SoC itself.

Well, with FIMC driver we just followed the style from other Samsung
drivers. Just take a look at video/s3c-fb or usb/gadget/s3c-hsotg.c.
I personally like to keep the same style for all drivers for Samsung
IPs. Changing the style of all of them requires some amount of work,
that would delay this particular driver even more so we will definitely
miss the merge window.

Best regards
--
Marek Szyprowski
Samsung Poland R&D Center


--
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: Handling of large keycodes

2010-08-02 Thread Mauro Carvalho Chehab
Em 02-08-2010 05:02, Dmitry Torokhov escreveu:
> On Sat, Jul 31, 2010 at 10:23:45AM -0300, Mauro Carvalho Chehab wrote:
>> Hi Dmitry,
>>
>> Em 31-07-2010 06:19, Dmitry Torokhov escreveu:
>>> Hi Mauro,
>>>
>>> I finally got a chance to review the patches adding handling of large
>>> scancodes to input core and there are a few things with this approach
>>> that I do not like.
>>
>> Thanks for the review!
>>
>>> First of all I do not think that we should be working with scancode via
>>> a pointer as it requires additional compat handling when running 32-bit
>>> userspace on 64-bit kernel. We can use a static buffer of sufficient
>>> size (lets say 32 bytes) to move scancode around and simply increase its
>>> size if we come upon device that uses even bigger scancodes. As long as
>>> buffer is at the end we can handle this in a compatible way.
>>
>> Yes, this is the downside of using a pointer. I'm not aware of a Remote
>> Controller protocol using more than 256 bits for scancode, so 32 bits
>> should be ok.
>>
>>> The other issue is that interface is notsymmetrical, setting is done by
>>> scancode but retrieval is done by index. I think we should be able to
>>> use both scancode and index in both operations.
>>
>> Yes, this also bothered me. I was thinking to do something similar to your
>> approach of having a bool to select between them. This change is welcome.
>>
>>> The usefulnes of reserved data elements in the structure is doubtful,
>>> since we do not seem to require them being set to a particular value and
>>> so we'll be unable to distinguish betwee legacy and newer users.
>>
>> David proposed some parameters that we rejected on our discussions. As we
>> might need to add something similar, I decided to keep it on my approach,
>> since a set of reserved fields wouldn't hurt (and removing it on our 
>> discussions
>> would be easy), but I'm ok on removing them.
>>
>>> I also concerned about the code very messy with regard to using old/new
>>> style interfaces instea dof converting old ones to use new
>>> insfrastructure,
>>
>> Good cleanup at the code!
>>
>>> I below is something that addresses these issues and seems to be working
>>> for me. It is on top of your patches and it also depends on a few
>>> changes in my tree that I have not publushed yet but plan on doing that
>>> tomorrow. I am also attaching patches converting sparse keymap and hid
>>> to the new style of getkeycode and setkeycode as examples.
>>>
>>> Please take a look and let me know if I missed something important.
>>
>> It seems to work for me. After you add the patches on your git tree, I'll 
>> work on porting the RC core to the new approach, and change the ir-keycode
>> userspace program to work with, in order to be 100% sure that it will work, 
>> but I can't foresee any missing part on it.
>>
>> Currently, I'm not using my input patches, as I was waiting for your
>> review. I just patched the userspace application, in order to test the legacy
>> mode.
>>
> 
> OK, great.
> 
> I want to fold all the patches from your tree plus this one into one and
> apply in one shpt (mentioning Jarod and Dan as authors of fixup patches
> in the changelog) - I do not believe we shoudl expose intermediate
> versions in the code that will go to Linus. Are you OK with this?

I'm OK. If you want, you can add my ack on your patch:

Acked-by: Mauro Carvalho Chehab 

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


Re: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface

2010-08-02 Thread Mauro Carvalho Chehab
Em 02-08-2010 07:52, Russell King - ARM Linux escreveu:
> On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote:
>> Well, some of them are indeed unused, but it's not an uncommon practice in
>> kernel and might help future developers.
> 
> On the other hand, arch/arm is getting soo big that we need to do
> something about this - and one solution is to avoid unnecessary
> definitions that we're not using.
> 
> Another good idea is to put definitions along side the drivers which
> they're relevant to - maybe in a local driver-name.h file which
> driver-name.c includes, or maybe even within driver-name.c if they're
> not excessive.  This has the advantage of distributing the "bloat" to
> where its actually used, and means that the driver isn't dependent so
> much on arch/arm or even the SoC itself.

Very much appreciated from my side. It is very hard to sync changes that
happen via arm trees when merging from my tree. There were several cases
in the past were I needed to coordinate with an ARM maintainer about when
he would merge from his tree, as the patches I had on media tree were
highly dependent on the patches at arch.

On several cases, I suspect that we had git bisect breakages (compilation
or driver miss-functioning) due to those sync issues between two trees.

A per-driver *.h file makes things easier, as such header file can be
merged/maintained together with the subsystem tree where the driver belongs.

> Take a look at arch/arm/mach-vexpress/include/mach/ct-ca9x4.h and
> arch/arm/mach-vexpress/include/mach/motherboard.h - these are the only
> two files which contain platform definitions which are actually used
> for Versatile Express.  Compare that with
> arch/arm/mach-realview/include/mach/platform.h which contains lots
> more...
> --
> 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

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


Re: Fwd: No audio in HW Compressed MPEG2 container on HVR-1300

2010-08-02 Thread lawrence rust
On Mon, 2010-08-02 at 22:19 +1200, Shane Harrison wrote:
[snip]
> Thanks Lawrence, will give that a whirl tomorrow and the muting idea
> might be important in this case as well.  Wierd you posted Saturday
> the day after I last worked on this and looked at the archives :-)
> 
> I am not ruling out initialisation problems with the WM8775 but I do
> always seem to get an I2S output from it that has data in it that
> reflects the input.  However it could be the wrong variant of I2S or
> some other configuration that isn't set right.

Currently in wm8775.c line 223, R11 is set to 0x21 which is 24-bit left
justified mode.  This is wrong, it should be i2s mode (0x22).  My patch
correctly sets this register and also disables ALC mode which is
irrelevant when setting input level via ALSA and can cause hiss during
quiet sections.

> Strange how eventually
> I do get audio (albeit mixed with the TV source it appears) simply by
> looping thru and changing input sources with v4l2-ctl.

Probably switching glitches eventually hit the right data
synchronisation format.

> I note that the Nova-S doesn't have the hardware MPEG encoding

Correct.

>  so
> still hoping someone can enlighten me on the audio path when using
> that chip.

When a Blackbird cx23416 MPEG encoder is fitted, i2s audio data from the
wm8775 is routed through the cx23883.  The i2s output of the cx23883 is
enabled by the function set_audio_finish() in cx88-tvaudio.c line 148.
The cx23416 can accept stereo Sony I2S format audio data when quoting
from the Conexant datasheet "running its AILR sync signal through an
inverting flip-flop, clocked by an inverted AICKIN".

-- Lawrence Rust


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


Re: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface

2010-08-02 Thread Russell King - ARM Linux
On Mon, Aug 02, 2010 at 08:51:06AM -0300, Mauro Carvalho Chehab wrote:
> Em 02-08-2010 07:52, Russell King - ARM Linux escreveu:
> > On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote:
> >> Well, some of them are indeed unused, but it's not an uncommon practice in
> >> kernel and might help future developers.
> > 
> > On the other hand, arch/arm is getting soo big that we need to do
> > something about this - and one solution is to avoid unnecessary
> > definitions that we're not using.
> > 
> > Another good idea is to put definitions along side the drivers which
> > they're relevant to - maybe in a local driver-name.h file which
> > driver-name.c includes, or maybe even within driver-name.c if they're
> > not excessive.  This has the advantage of distributing the "bloat" to
> > where its actually used, and means that the driver isn't dependent so
> > much on arch/arm or even the SoC itself.
> 
> Very much appreciated from my side. It is very hard to sync changes that
> happen via arm trees when merging from my tree. There were several cases
> in the past were I needed to coordinate with an ARM maintainer about when
> he would merge from his tree, as the patches I had on media tree were
> highly dependent on the patches at arch.

That's a separate problem - one which occurs when there's platform
code in arch/arm/ which shares a common data structure with driver
code under drivers/.

I don't think there's an easy resolution to that one, because if
you split the arch/arm/ change (which may depend on other arch/arm/
changes) from the drivers/ change, someone ends up losing no matter
where the header file with the common data structure is placed.

One answer to that is to kill the idea that every ARM architecture
needs to define their own watchdog platform data - and instead
replace it with a shared watchdog_platform_data structure, much like
the flash_platform_data structure in arch/arm/include/asm/mach/flash.h
(which'd would be nice to be under include/linux ...)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface

2010-08-02 Thread Pawel Osciak
>Russell King - ARM Linux  wrote:
>On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote:
>> Well, some of them are indeed unused, but it's not an uncommon practice in
>> kernel and might help future developers.
>
>On the other hand, arch/arm is getting soo big that we need to do
>something about this - and one solution is to avoid unnecessary
>definitions that we're not using.
>
>Another good idea is to put definitions along side the drivers which
>they're relevant to - maybe in a local driver-name.h file which
>driver-name.c includes, or maybe even within driver-name.c if they're
>not excessive.  This has the advantage of distributing the "bloat" to
>where its actually used, and means that the driver isn't dependent so
>much on arch/arm or even the SoC itself.
>
>Take a look at arch/arm/mach-vexpress/include/mach/ct-ca9x4.h and
>arch/arm/mach-vexpress/include/mach/motherboard.h - these are the only
>two files which contain platform definitions which are actually used
>for Versatile Express.  Compare that with
>arch/arm/mach-realview/include/mach/platform.h which contains lots
>more...

So basically, what you and Mauro are recommending is that we move the *.h
file with register definitions to drivers/media?


Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center



--
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 0/4] FM V4L2 driver for WL128x

2010-08-02 Thread raja_mani
From: Raja-Mani 

The following patches are FM V4L2-Radio drivers for WL128x
(backward compatible for WL127x).
This driver makes use of TI Shared Transport driver for its
transport via UART/TTY.

Only FM Rx is supported as of now. Any FM V4L2 Radio standard application
can make use of the '/dev/radioX' interface exposed by this driver to
communicate with the TI FM chip.

This doesn't include the handling of audio path and has support for
RDS, FM firmware download, HW Seek, Tune, Volume control,etc.

Tested with internal FM app and as well as with open source gnome-radio
application and verified on SDP4430, kernel 2.6.35-rc5.

Note: The patches however are re-based to the Stephen Rothwell's linux-next's
drivers/staging/ti-st since the latest version of ST drivers exist there.

Raja-Mani (4):
  drivers:staging:ti-st: sources for FM common interfaces
  drivers:staging:ti-st: Sources for FM RX
  drivers:staging:ti-st: Sources for FM V4L2 interfaces
  drivers:staging:ti-st: Sources for FM common header

 drivers/staging/ti-st/fmdrv.h|  225 
 drivers/staging/ti-st/fmdrv_common.c | 2127 ++
 drivers/staging/ti-st/fmdrv_common.h |  459 
 drivers/staging/ti-st/fmdrv_rx.c |  805 +
 drivers/staging/ti-st/fmdrv_rx.h |   56 +
 drivers/staging/ti-st/fmdrv_v4l2.c   |  550 +
 drivers/staging/ti-st/fmdrv_v4l2.h   |   32 +
 7 files changed, 4254 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/ti-st/fmdrv.h
 create mode 100644 drivers/staging/ti-st/fmdrv_common.c
 create mode 100644 drivers/staging/ti-st/fmdrv_common.h
 create mode 100644 drivers/staging/ti-st/fmdrv_rx.c
 create mode 100644 drivers/staging/ti-st/fmdrv_rx.h
 create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.c
 create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.h

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


[RFC 3/4] drivers:staging:ti-st: Sources for FM V4L2 interfaces

2010-08-02 Thread raja_mani
From: Raja-Mani 

This module interfaces V4L2 subsystem and FM common
module. It registers itself with V4L2 as Radio module.

Signed-off-by: Pramodh AG 
Signed-off-by: Raja-Mani 
---
 drivers/staging/ti-st/fmdrv_v4l2.c |  550 
 drivers/staging/ti-st/fmdrv_v4l2.h |   32 ++
 2 files changed, 582 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.c
 create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.h

diff --git a/drivers/staging/ti-st/fmdrv_v4l2.c 
b/drivers/staging/ti-st/fmdrv_v4l2.c
new file mode 100644
index 000..047bce5
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv_v4l2.c
@@ -0,0 +1,550 @@
+/*
+ *  FM Driver for Connectivity chip of Texas Instruments.
+ *  This file provides interfaces to V4L2 subsystem.
+ *
+ *  This module registers with V4L2 subsystem as Radio
+ *  data system interface (/dev/radio). During the registration,
+ *  it will expose two set of function pointers to V4L2 subsystem.
+ *
+ *1) File operation related API (open, close, read, write, poll...etc).
+ *2) Set of V4L2 IOCTL complaint API.
+ *
+ *  Copyright (C) 2010 Texas Instruments
+ *
+ *  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, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include "fmdrv.h"
+#include "fmdrv_v4l2.h"
+#include "fmdrv_common.h"
+#include "fmdrv_rx.h"
+/* TODO: Enable when FM TX is supported */
+/* #include "fmdrv_tx.h" */
+
+static struct video_device *gradio_dev;
+static unsigned char radio_disconnected;
+
+/* Query control */
+static struct v4l2_queryctrl fmdrv_v4l2_queryctrl[] = {
+   {
+.id = V4L2_CID_AUDIO_VOLUME,
+.type = V4L2_CTRL_TYPE_INTEGER,
+.name = "Volume",
+.minimum = FM_RX_VOLUME_MIN,
+.maximum = FM_RX_VOLUME_MAX,
+.step = 1,
+.default_value = FM_DEFAULT_RX_VOLUME,
+},
+   {
+.id = V4L2_CID_AUDIO_BALANCE,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+   {
+.id = V4L2_CID_AUDIO_BASS,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+   {
+.id = V4L2_CID_AUDIO_TREBLE,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+   {
+.id = V4L2_CID_AUDIO_MUTE,
+.type = V4L2_CTRL_TYPE_BOOLEAN,
+.name = "Mute",
+.minimum = 0,
+.maximum = 2,
+.step = 1,
+.default_value = FM_MUTE_OFF,
+},
+   {
+.id = V4L2_CID_AUDIO_LOUDNESS,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+};
+
+/* -- V4L2 RADIO (/dev/radioX) device file operation interfaces --- */
+/* Read RX RDS data */
+static ssize_t fm_v4l2_fops_read(struct file *file, char __user * buf,
+   size_t count, loff_t *ppos)
+{
+   unsigned char rds_mode;
+   int ret;
+   struct fmdrv_ops *fmdev;
+
+   fmdev = video_drvdata(file);
+
+   if (!radio_disconnected) {
+   pr_err("(fmdrv): FM device is already disconnected\n");
+   ret = -EIO;
+   goto exit;
+   }
+
+   /* Turn on RDS mode , if it is disabled */
+   ret = fm_rx_get_rds_mode(fmdev, &rds_mode);
+   if (ret < 0) {
+   pr_err("(fmdrv): Unable to read current rds mode");
+   goto exit;
+   }
+   if (rds_mode == FM_RDS_DISABLE) {
+   ret = fmc_set_rds_mode(fmdev, FM_RDS_ENABLE);
+   if (ret < 0) {
+   pr_err("(fmdrv): Failed to enable rds mode");
+   goto exit;
+   }
+   }
+   /* Copy RDS data from internal buffer to user buffer */
+   ret = fmc_transfer_rds_from_internal_buff(fmdev, file, buf, count);
+
+exit:
+   return ret;
+}
+
+/* Write RDS data.
+ * TODO: When FM TX support is added, use "V4L2_CID_RDS_TX_" codes,
+ * instead of write operation.
+ */
+static ssize_t fm_v4l2_fops_write(struct file *file, const char __user * buf,
+   size_t count, loff_t *ppos)
+{
+   struct tx_rds rds;
+   int ret;
+   struct fmdrv_ops *fmdev;
+
+   ret = copy_from_user(&rds, buf, sizeof(rds));
+   pr_info("(fmdrv): (%d)type: %d, text %s, af %d",
+  ret, rds.text_type, rds.text, rds.af_freq);
+
+   fmdev = video_drvdata(file);
+   /* TODO: Enable when FM TX is supported */
+   /* fm_tx_set_radio_text(fmdev, rds.text, rds.text_type); */
+

[RFC 4/4] drivers:staging:ti-st: Sources for FM common header

2010-08-02 Thread raja_mani
From: Raja-Mani 

This is a common header used in all FM submodules
(FM V4L2,FM common,FM Rx).

Signed-off-by: Pramodh AG 
Signed-off-by: Raja-Mani 
---
 drivers/staging/ti-st/fmdrv.h |  225 +
 1 files changed, 225 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/ti-st/fmdrv.h

diff --git a/drivers/staging/ti-st/fmdrv.h b/drivers/staging/ti-st/fmdrv.h
new file mode 100644
index 000..d560570
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv.h
@@ -0,0 +1,225 @@
+/*
+ *  FM Driver for Connectivity chip of Texas Instruments.
+ *
+ *  Common header for all FM driver sub-modules.
+ *
+ *  Copyright (C) 2009 Texas Instruments
+ *
+ *  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, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#ifndef _FM_DRV_H
+#define _FM_DRV_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define FM_DRV_VERSION"0.01"
+/* Should match with FM_DRV_VERSION */
+#define FM_DRV_RADIO_VERSION  KERNEL_VERSION(0, 0, 1)
+#define FM_DRV_NAME   "ti_fmdrv"
+#define FM_DRV_CARD_SHORT_NAME"TI FM Radio"
+#define FM_DRV_CARD_LONG_NAME "Texas Instruments FM Radio"
+
+/* Flag info */
+#define FM_INTTASK_RUNNING0
+#define FM_INTTASK_SCHEDULE_PENDING   1
+#define FM_FIRMWARE_DW_INPROGRESS 2
+#define FM_CORE_READY 3
+#define FM_CORE_TRANSPORT_READY   4
+#define FM_AF_SWITCH_INPROGRESS  5
+#define FM_CORE_TX_XMITING   6
+
+#define FM_DRV_TX_TIMEOUT  (5*HZ)  /* 5 seconds */
+#define FM_DRV_RX_SEEK_TIMEOUT (20*HZ) /* 20 seconds */
+
+#define NO_OF_ENTRIES_IN_ARRAY(array) (sizeof(array) / sizeof(array[0]))
+
+enum {
+   FM_MODE_OFF,
+   FM_MODE_TX,
+   FM_MODE_RX,
+   FM_MODE_ENTRY_MAX
+};
+
+#define FM_RX_RDS_INFO_FIELD_MAX   8   /* 4 Group * 2 Bytes */
+
+/* RX RDS data format */
+struct fm_rdsdata_format {
+   union {
+   struct {
+   unsigned char rdsbuff[FM_RX_RDS_INFO_FIELD_MAX];
+   } groupdatabuff;
+   struct {
+   unsigned short pidata;
+   unsigned char block_b_byte1;
+   unsigned char block_b_byte2;
+   unsigned char block_c_byte1;
+   unsigned char block_c_byte2;
+   unsigned char block_d_byte1;
+   unsigned char block_d_byte2;
+   } groupgeneral;
+   struct {
+   unsigned short pidata;
+   unsigned char block_b_byte1;
+   unsigned char block_b_byte2;
+   unsigned char firstaf;
+   unsigned char secondaf;
+   unsigned char firstpsbyte;
+   unsigned char secondpsbyte;
+   } group0A;
+
+   struct {
+   unsigned short pidata;
+   unsigned char block_b_byte1;
+   unsigned char block_b_byte2;
+   unsigned short pidata2;
+   unsigned char firstpsbyte;
+   unsigned char secondpsbyte;
+   } group0B;
+   } rdsdata;
+};
+
+/* FM region (Europe/US, Japan) info */
+struct region_info {
+   unsigned int channel_spacing;
+   unsigned int bottom_frequency;
+   unsigned int top_frequency;
+   unsigned char region_index;
+};
+
+typedef void (*int_handler_prototype) (void *);
+
+/* FM Interrupt processing related info */
+struct fm_irq {
+   unsigned char stage_index;
+   unsigned short flag;/* FM interrupt flag */
+   unsigned short mask;/* FM interrupt mask */
+   /* Interrupt process timeout handler */
+   struct timer_list int_timeout_timer;
+   unsigned char irq_service_timeout_retry;
+   int_handler_prototype *fm_int_handlers;
+};
+
+/* RDS info */
+struct fm_rds {
+   unsigned char flag; /* RX RDS on/off status */
+   unsigned char last_block_index; /* Last received RDS block */
+
+   /* RDS buffer */
+   wait_queue_head_t read_queue;
+   unsigned int buf_size;  /* Size is always multiple of 3 */
+   unsigned int wr_index;
+   unsigned int rd_index;
+   unsigned char *buffer;
+};
+
+#define FM_RDS_MAX_AF_LIST 25
+
+/* Current RX chann

[RFC 2/4] drivers:staging:ti-st: Sources for FM RX

2010-08-02 Thread raja_mani
From: Raja-Mani 

This has implementation for FM RX functionality.
It communicates with FM V4l2 module and FM common module.

Signed-off-by: Pramodh AG 
Signed-off-by: Raja-Mani 
---
 drivers/staging/ti-st/fmdrv_rx.c |  805 ++
 drivers/staging/ti-st/fmdrv_rx.h |   56 +++
 2 files changed, 861 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/ti-st/fmdrv_rx.c
 create mode 100644 drivers/staging/ti-st/fmdrv_rx.h

diff --git a/drivers/staging/ti-st/fmdrv_rx.c b/drivers/staging/ti-st/fmdrv_rx.c
new file mode 100644
index 000..8d5b9e9
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv_rx.c
@@ -0,0 +1,805 @@
+/*
+ *  FM Driver for Connectivity chip of Texas Instruments.
+ *  This sub-module of FM driver implements FM RX functionality.
+ *
+ *  Copyright (C) 2010 Texas Instruments
+ *
+ *  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, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+#include "fmdrv.h"
+#include "fmdrv_common.h"
+#include "fmdrv_rx.h"
+
+void fm_rx_reset_rds_cache(struct fmdrv_ops *fmdev)
+{
+   fmdev->rx.rds.flag = FM_RDS_DISABLE;
+   fmdev->rx.rds.last_block_index = 0;
+   fmdev->rx.rds.wr_index = 0;
+   fmdev->rx.rds.rd_index = 0;
+
+   if (fmdev->rx.af_mode == FM_RX_RDS_AF_SWITCH_MODE_ON)
+   fmdev->irq_info.mask |= FM_LEV_EVENT;
+
+}
+
+void fm_rx_reset_curr_station_info(struct fmdrv_ops *fmdev)
+{
+   fmdev->rx.cur_station_info.picode = FM_NO_PI_CODE;
+   fmdev->rx.cur_station_info.no_of_items_in_afcache = 0;
+   fmdev->rx.cur_station_info.af_list_max = 0;
+}
+
+int fm_rx_set_frequency(struct fmdrv_ops *fmdev, unsigned int freq_to_set)
+{
+   unsigned long timeleft;
+   unsigned short payload, curr_frq, frq_index;
+   unsigned int curr_frq_in_khz;
+   int ret, resp_len;
+
+   if (fmdev->curr_fmmode != FM_MODE_RX) {
+   ret = -EPERM;
+   goto exit;
+   }
+
+   if (freq_to_set < fmdev->rx.region.bottom_frequency ||
+   freq_to_set > fmdev->rx.region.top_frequency) {
+   pr_err("(fmdrv): Invalid frequency %d", freq_to_set);
+   ret = -EINVAL;
+   goto exit;
+   }
+   /* Set audio enable */
+   FM_STORE_LE16_TO_BE16(payload, FM_RX_FM_AUDIO_ENABLE_I2S_AND_ANALOG);
+   ret = fmc_send_cmd(fmdev, AUDIO_ENABLE_SET, &payload, sizeof(payload),
+   &fmdev->maintask_completion, NULL, NULL);
+   FM_CHECK_SEND_CMD_STATUS(ret);
+
+   /* Set hilo to automatic selection */
+   FM_STORE_LE16_TO_BE16(payload, FM_RX_IFFREQ_HILO_AUTOMATIC);
+   ret = fmc_send_cmd(fmdev, HILO_SET, &payload, sizeof(payload),
+   &fmdev->maintask_completion, NULL, NULL);
+   FM_CHECK_SEND_CMD_STATUS(ret);
+
+   /* Calculate frequency index to write */
+   frq_index = (freq_to_set - fmdev->rx.region.bottom_frequency) /
+   fmdev->rx.region.channel_spacing;
+
+   /* Set frequency index */
+   FM_STORE_LE16_TO_BE16(payload, frq_index);
+   ret = fmc_send_cmd(fmdev, FREQ_SET, &payload, sizeof(payload),
+   &fmdev->maintask_completion, NULL, NULL);
+   FM_CHECK_SEND_CMD_STATUS(ret);
+
+   /* Read flags - just to clear any pending interrupts if we had */
+   ret = fmc_send_cmd(fmdev, FLAG_GET, NULL, 2,
+   &fmdev->maintask_completion, NULL, NULL);
+   FM_CHECK_SEND_CMD_STATUS(ret);
+
+   /* Enable FR, BL interrupts */
+   fmdev->irq_info.mask |= (FM_FR_EVENT | FM_BL_EVENT);
+   FM_STORE_LE16_TO_BE16(payload, fmdev->irq_info.mask);
+   ret = fmc_send_cmd(fmdev, INT_MASK_SET, &payload, sizeof(payload),
+   &fmdev->maintask_completion, NULL, NULL);
+   FM_CHECK_SEND_CMD_STATUS(ret);
+
+   /* Start tune */
+   FM_STORE_LE16_TO_BE16(payload, FM_TUNER_PRESET_MODE);
+   ret = fmc_send_cmd(fmdev, TUNER_MODE_SET, &payload, sizeof(payload),
+  &fmdev->maintask_completion, NULL, NULL);
+   FM_CHECK_SEND_CMD_STATUS(ret);
+
+   /* Wait for tune ended interrupt */
+   init_completion(&fmdev->maintask_completion);
+   timeleft = wait_for_completion_timeout(&fmdev->maintask_completion,
+  FM_DRV_TX_TIMEOUT);
+   if (!timeleft) {
+   pr_e

Re: [Q]: any DVB-S2 card which is 45MS/s capable?

2010-08-02 Thread Marko Ristola


Hi.

I have written some Mantis bandwidth related
DMA transfer optimizations on June/July this year.
They are now waiting for approval by Manu Abraham.

Those reduce CPU pressure, increasing the bandwidth
that can be received from the DVB card. 45MS/s bandwidth
support will surely benefit from those patches.

Main features:
1. Do one CPU interrupt per 16KB data instead per 4KB data.
My implementation benefits only Mantis cards.
https://patchwork.kernel.org/patch/107036/

2. Remove unnecessary big CPU overhead, when data is delivered
from the DVB card's DMA buffer into Linux kernel's DVB subsystem.
Number 2 reduces the CPU pressure by almost 50%.
This implementation benefits many other Linux supported DVB cards too.
http://patchwork.kernel.org/patch/108274/

Those helped with my older single CPU Core computer with 256-QAM,
delivering HDTV channel into the network and watching the
HDTV channel with a faster computer.

The performance bottlenecks could be seen on the
command line with "perf top".

I had to increase PCI bus latency setting into 64 too from the BIOS.
Moving DVB device into separate IRQ line with Ethernet card helped too,
because Ethernet card did an interrupt per ethernet packet.

So if the hardware can deliver 45MS/s data fast enough, software side 
can be optimized up
to some point. My patches contain the most easy major optimizations that 
I found.
If you can test some of those patches, it might help to get them into 
Linux kernel

faster.

Best regards,
Marko Ristola

27.07.2010 18:11, VDR User wrote:

On Tue, Jul 27, 2010 at 5:52 AM, Emmanuel  wrote:

VDR User a écrit :

Look at the vp-1041 I think.

 From what I gathered it is not able to do 45MS/s for DVB-S2.
Thanks anyway,

You may want to ask Manu Abraham (author of the mantis driver) about
that to be sure.  It seems I recall him telling me it could quite some
time ago.
--
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: [RFC/PATCH v3 01/10] media: Media device node support

2010-08-02 Thread Laurent Pinchart
Hi Hans,

On Sunday 01 August 2010 13:14:18 Hans Verkuil wrote:
> On Thursday 29 July 2010 18:06:34 Laurent Pinchart wrote:
> > The media_devnode structure provides support for registering and
> > unregistering character devices using a dynamic major number. Reference
> > counting is handled internally, making device drivers easier to write
> > without having to solve the open/disconnect race condition issue over
> > and over again.
> > 
> > The code is based on video/v4l2-dev.c.
> > 
> > Signed-off-by: Laurent Pinchart 
> > ---
> > 
> >  drivers/media/Makefile|8 +-
> >  drivers/media/media-devnode.c |  326
> >  + include/media/media-devnode.h
> >  |   84 +++
> >  3 files changed, 416 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/media/media-devnode.c
> >  create mode 100644 include/media/media-devnode.h
> 
> 
> 
> > diff --git a/drivers/media/media-devnode.c
> > b/drivers/media/media-devnode.c new file mode 100644
> > index 000..6f5558c
> > --- /dev/null
> > +++ b/drivers/media/media-devnode.c
> 
> 
> 
> > +/* Override for the open function */
> > +static int media_open(struct inode *inode, struct file *filp)
> > +{
> > +   struct media_devnode *mdev;
> > +   int ret;
> > +
> > +   /* Check if the media device is available. This needs to be done with
> > +* the media_devnode_lock held to prevent an open/unregister race:
> > +* without the lock, the device could be unregistered and freed between
> > +* the media_devnode_is_registered() and get_device() calls, leading to
> > +* a crash.
> > +*/
> > +   mutex_lock(&media_devnode_lock);
> > +   mdev = container_of(inode->i_cdev, struct media_devnode, cdev);
> > +   /* return ENODEV if the media device has been removed
> > +  already or if it is not registered anymore. */
> > +   if (!media_devnode_is_registered(mdev)) {
> > +   mutex_unlock(&media_devnode_lock);
> > +   return -ENODEV;
> > +   }
> > +   /* and increase the device refcount */
> > +   get_device(&mdev->dev);
> > +   mutex_unlock(&media_devnode_lock);
> > +   if (mdev->fops->open) {
> > +   ret = mdev->fops->open(filp);
> > +   if (ret) {
> > +   put_device(&mdev->dev);
> > +   return ret;
> > +   }
> > +   }
> > +
> > +   filp->private_data = mdev;
> 
> This line should be moved up to before the if: that way the open op can
> rely on private_data being setup correctly.

Agreed, I'll fix that.

> > +   return 0;
> > +}

-- 
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: [RFC/PATCH v3 03/10] media: Entities, pads and links

2010-08-02 Thread Laurent Pinchart
Hi Sakari,

On Friday 30 July 2010 16:00:31 Sakari Ailus wrote:
> Laurent Pinchart wrote:

[snip]

> > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > new file mode 100644
> > index 000..37a25bf
> > --- /dev/null
> > +++ b/include/media/media-entity.h
> > @@ -0,0 +1,85 @@
> > +#ifndef _MEDIA_ENTITY_H
> > +#define _MEDIA_ENTITY_H
> > +
> > +#include 
> > +
> > +#define MEDIA_ENTITY_TYPE_NODE (1 << 16)
> 
> About that 16 there, could that be replaced by a #define instead? Like
> MEDIA_ENTITY_TYPE_SHIFT? (I don't think we'd need
> MEDIA_ENTITY_SUBTYPE_SHIFT.)

Agreed.

> > +#define MEDIA_ENTITY_TYPE_NODE_V4L (MEDIA_ENTITY_TYPE_NODE + 1)
> > +#define MEDIA_ENTITY_TYPE_NODE_FB  (MEDIA_ENTITY_TYPE_NODE + 2)
> > +#define MEDIA_ENTITY_TYPE_NODE_ALSA(MEDIA_ENTITY_TYPE_NODE 
> > + 3)
> > +#define MEDIA_ENTITY_TYPE_NODE_DVB (MEDIA_ENTITY_TYPE_NODE + 4)
> > +
> > +#define MEDIA_ENTITY_TYPE_SUBDEV   (2 << 16)
> > +#define MEDIA_ENTITY_TYPE_SUBDEV_VID_DECODER   
> > (MEDIA_ENTITY_TYPE_SUBDEV +
> > 1) +#define
> > MEDIA_ENTITY_TYPE_SUBDEV_VID_ENCODER(MEDIA_ENTITY_TYPE_SUBDEV + 2)
> > +#define MEDIA_ENTITY_TYPE_SUBDEV_MISC  
> > (MEDIA_ENTITY_TYPE_SUBDEV + 3) 
+
> > +#define MEDIA_LINK_FLAG_ACTIVE (1 << 0)
> > +#define MEDIA_LINK_FLAG_IMMUTABLE  (1 << 1)
> > +
> > +#define MEDIA_PAD_FLAG_INPUT   (1 << 0)
> > +#define MEDIA_PAD_FLAG_OUTPUT  (1 << 1)
> > +
> > +struct media_link {
> > +   struct media_pad *source;   /* Source pad */
> > +   struct media_pad *sink; /* Sink pad  */
> > +   struct media_link *other;   /* Link in the reverse direction */
> > +   unsigned long flags;/* Link flags (MEDIA_LINK_FLAG_*) */
> > +};
> > +
> > +struct media_pad {
> > +   struct media_entity *entity;/* Entity this pad belongs to */
> > +   u16 index;  /* Pad index in the entity pads array */
> > +   unsigned long flags;/* Pad flags (MEDIA_PAD_FLAG_*) */
> > +};
> > +
> > +struct media_entity {
> > +   struct list_head list;
> > +   struct media_device *parent;/* Media device this entity belongs to*/
> > +   u32 id; /* Entity ID, unique in the parent media
> > +* device context */
> > +   const char *name;   /* Entity name */
> > +   u32 type;   /* Entity type (MEDIA_ENTITY_TYPE_*) */
> > +
> > +   u8 num_pads;/* Number of input and output pads */
> 
> Hans suggested u16 for pads. This is a kernel structure but still it'd
> be good to keep them the same IMO, even if that u16 was there for the
> future.
> 
> u8 is used on some function arguments as well for these purposes.

Will fix.

> > +   u8 num_links;   /* Number of existing links, both active
> > +* and inactive */
> > +   u8 num_backlinks;   /* Number of backlinks */
> > +   u8 max_links;   /* Maximum number of links */
> 
> Same for these.

Agreed. The number of links is expected to be >= number of pads. I'll change 
num_links, num_backlinks and max_links to u16 as well.

> > +   struct media_pad *pads; /* Pads array (num_pads elements) */
> > +   struct media_link *links;   /* Links array (max_links elements)*/
> > +
> > +   union {
> > +   /* Node specifications */
> > +   struct {
> > +   u32 major;
> > +   u32 minor;
> 
> How about dev_t here?

dev_t doesn't seem to be a public kernel type.

> > +   } v4l;
> > +   struct {
> > +   u32 major;
> > +   u32 minor;
> 
> And here.
> 
> > +   } fb;
> > +   int alsa;
> > +   int dvb;
> > +
> > +   /* Sub-device specifications */
> > +   /* Nothing needed 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


[PATCH v7 5/5] Documentation: v4l: Add hw_seek spacing and FM_RX class

2010-08-02 Thread Matti J. Aaltonen
Add a couple of words about the spacing field in ithe HW seek struct and
about the new FM RX control class.

Signed-off-by: Matti J. Aaltonen 
---
 Documentation/DocBook/v4l/controls.xml |   71 
 .../DocBook/v4l/vidioc-s-hw-freq-seek.xml  |   10 ++-
 2 files changed, 79 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/v4l/controls.xml 
b/Documentation/DocBook/v4l/controls.xml
index e1bdbb6..bba3f4d 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -2062,6 +2062,77 @@ manually or automatically if set to zero. Unit, range 
and step are driver-specif
 For more details about RDS specification, refer to
  document, from CENELEC.
 
+
+  FM Tuner Control Reference
+
+  The FM Tuner (FM_RX) class includes controls for common features of
+devices that are capable of receiving FM transmissions. Currently this class 
includes a parameter
+defining the FM radio band being used.
+
+  
+  FM_RX Control IDs
+
+  
+   
+   
+   
+   
+   
+   
+   
+ 
+   ID
+   Type
+ Description
+ 
+   
+   
+ 
+ 
+   V4L2_CID_FM_RX_CLASS 
+   class
+ The FM_RX class
+descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a
+description of this control class.
+ 
+ 
+   V4L2_CID_FM_RX_BAND 
+   integer
+ 
+ Configures the FM 
radio
+frequency range being used. Currently there are three bands in use, see  http://en.wikipedia.org/wiki/FM_broadcasting";>Wikipedia.
+Usually 87.5 to 108.0 MHz is used, or some portion thereof, with a few 
exceptions:
+In Japan, the band 76-90 MHz is used and in the former Soviet republics
+and some Eastern European countries, the older 65-74 MHz band,
+referred also to as the OIRT band, is still used.
+
+The enum  v4l2_fm_rx_band defines possible values for the FM band. They 
are:
+   
+   
+ 
+   
+ 
V4L2_FM_BAND_OTHER 
+ Frequencies from 87.5 to 108.0 MHz
+   
+   
+ 
V4L2_FM_BAND_JAPAN 
+ from 65 to 74 MHz
+   
+   
+ 
V4L2_FM_BAND_OIRT 
+ from 65 to 74 MHz
+   
+ 
+   
+
+ 
+ 
+   
+  
+  
+
+
 
 
   

[PATCH v7 0/5] TI WL1273 FM Radio driver.

2010-08-02 Thread Matti J. Aaltonen
Hello all,

and thanks for the comments Hans.

Now I've done a couple of iterations with the codec on the ALSA mailing
list and that still continues... I've removed all "#undef DEBUG" lines,
because the ALSA people didn't like them.

I'll go through the comments and the rest of the changes:

>> + tuner->capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_RDS |
>> + V4L2_TUNER_CAP_STEREO;
>> +
>
> audmode must be set even when the device is in TX mode. Best is to just set it
> to the last set audmode.

I added a state field for the audmode. I used a boolean variable because
that seemed to lead to clearer code than using an int. Other two valued
entities - like the digital/analog mode - could also be modeled with booleans
but I didn't do it because it could be condemned by the community :-)

Should there also be audmode for the modulator?

>> + if (val == WL1273_RX_MONO) {
>> + tuner->rxsubchans = V4L2_TUNER_SUB_MONO;
>> + tuner->audmode = V4L2_TUNER_MODE_MONO;
>> + } else {
>> + tuner->rxsubchans = V4L2_TUNER_SUB_STEREO;
>> + tuner->audmode = V4L2_TUNER_MODE_STEREO;
>> + }
>
> There are two separate things: detecting whether the signal is stereo or mono
> and selecting the audio mode (this is the format of the audio that is sent to
> userspace). The first is set in rxsubchans and is dynamic, the second is fixed
> and set by the application.
>
> If the device can detect mono vs stereo signals, then rxsubchans should be set
> accordingly. If the device cannot do this, then both mono and stereo should be
> specified in rxsubchans.
>
> The audmode field is like a control: it does not automatically change if the
> signal switches from mono to stereo or vice versa. Unless the hardware is
> unable to map a mono signal to a stereo audio stream or a stereo signal to a
> mono audio stream.
>
> The fact that the code above sets both rxsubchans and audmode suggests either
> that the hardware cannot map stereo to mono or vice versa, or a program bug.
> In the first case we need a comment here, in the second case it should be
> fixed.

I kind of new I was doing something wrong here... but then I thought: why
isn't there a control variable for the RDS? Anyway, now I've made the
distinction between subchans flags and the audmode field.

>> +
>> + if (core->rds_on)
>> + modulator->txsubchans |= V4L2_TUNER_SUB_RDS;
>> + else
>> + modulator->txsubchans &= ~V4L2_TUNER_SUB_RDS;
>
> This else is not needed.

Else removed...

> Just make this Hz. There is no need to restrict the precision to
> kHz. S_FREQUENCY supports units of 67.5 Hz, so using kHz for the
> spacing seems unnecessary.
> 
> Alternatively the same resolution as S_FREQUENCY can be used (67.5 Hz
> or 67.5 kHz, depending on the CAP_LOW capability). Not sure which is
> best, though.

I think using Hz is the most straightforward policy here so I chose that.

Cheers,
Matti

Matti J. Aaltonen (5):
  V4L2: Add seek spacing and FM RX class.
  MFD: WL1273 FM Radio: MFD driver for the FM radio.
  ASoC: WL1273 FM Radio Digital audio codec.
  V4L2: WL1273 FM Radio: Controls for the FM radio.
  Documentation: v4l: Add hw_seek spacing and FM_RX class

 Documentation/DocBook/v4l/controls.xml |   71 +
 .../DocBook/v4l/vidioc-s-hw-freq-seek.xml  |   10 +-
 drivers/media/radio/Kconfig|   15 +
 drivers/media/radio/Makefile   |1 +
 drivers/media/radio/radio-wl1273.c | 1972 
 drivers/media/video/v4l2-common.c  |   12 +
 drivers/mfd/Kconfig|6 +
 drivers/mfd/Makefile   |2 +
 drivers/mfd/wl1273-core.c  |  612 ++
 include/linux/mfd/wl1273-core.h|  314 
 include/linux/videodev2.h  |   15 +-
 sound/soc/codecs/Kconfig   |6 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/wl1273.c  |  591 ++
 sound/soc/codecs/wl1273.h  |   42 +
 15 files changed, 3668 insertions(+), 3 deletions(-)
 create mode 100644 drivers/media/radio/radio-wl1273.c
 create mode 100644 drivers/mfd/wl1273-core.c
 create mode 100644 include/linux/mfd/wl1273-core.h
 create mode 100644 sound/soc/codecs/wl1273.c
 create mode 100644 sound/soc/codecs/wl1273.h

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


[PATCH v7 2/5] MFD: WL1273 FM Radio: MFD driver for the FM radio.

2010-08-02 Thread Matti J. Aaltonen
This is a parent for two child drivers: a V4L2 driver and
an ALSA codec driver. The MFD part implements I2C communication
to the device and provides a couple of functions that are called
from both children.

Signed-off-by: Matti J. Aaltonen 
---
 drivers/mfd/wl1273-core.c   |  612 +++
 include/linux/mfd/wl1273-core.h |  314 
 2 files changed, 926 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mfd/wl1273-core.c
 create mode 100644 include/linux/mfd/wl1273-core.h

diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
new file mode 100644
index 000..603b922
--- /dev/null
+++ b/drivers/mfd/wl1273-core.c
@@ -0,0 +1,612 @@
+/*
+ * MFD driver for wl1273 FM radio and audio codec submodules.
+ *
+ * Author: Matti Aaltonen 
+ *
+ * Copyright:   (C) 2010 Nokia Corporation
+ *
+ * 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, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_DESC "WL1273 FM Radio Core"
+
+#define WL1273_IRQ_MASK (WL1273_FR_EVENT   |   \
+ WL1273_POW_ENB_EVENT)
+
+static const struct band_info bands[] = {
+   /* USA & Europe */
+   {
+   .bottom_frequency   = 87500,
+   .top_frequency  = 108000,
+   .band   = V4L2_FM_BAND_OTHER,
+   },
+   /* Japan */
+   {
+   .bottom_frequency   = 76000,
+   .top_frequency  = 9,
+   .band   = V4L2_FM_BAND_JAPAN,
+   },
+};
+
+/*
+ * static unsigned char radio_band - Band
+ *
+ * The bands are 0 == USA-Europe, 1 == Japan. USA-Europe is the default.
+ */
+static unsigned char radio_band;
+module_param(radio_band, byte, 0);
+MODULE_PARM_DESC(radio_band, "Band: 0=USA-Europe, 1=Japan");
+
+/*
+ * static unsigned int rds_buf - the number of RDS buffer blocks used.
+ *
+ * The default number is 100.
+ */
+static unsigned int rds_buf = 100;
+module_param(rds_buf, uint, 0);
+MODULE_PARM_DESC(rds_buf, "RDS buffer entries: *100*");
+
+int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
+{
+   struct i2c_client *client = core->i2c_dev;
+   u8 b[2];
+   int r;
+
+   r = i2c_smbus_read_i2c_block_data(client, reg, 2, b);
+   if (r != 2) {
+   dev_err(&client->dev, "%s: Read: %d fails.\n", __func__, reg);
+   return -EREMOTEIO;
+   }
+
+   *value = (u16)b[0] << 8 | b[1];
+
+   return 0;
+}
+EXPORT_SYMBOL(wl1273_fm_read_reg);
+
+int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
+{
+   struct i2c_client *client = core->i2c_dev;
+   u8 buf[] = { (param >> 8) & 0xff, param & 0xff };
+   int r;
+
+   r = i2c_smbus_write_i2c_block_data(client, cmd, 2, buf);
+   if (r) {
+   dev_err(&client->dev, "%s: Cmd: %d fails.\n", __func__, cmd);
+   return r;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(wl1273_fm_write_cmd);
+
+int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len)
+{
+   struct i2c_client *client = core->i2c_dev;
+   struct i2c_msg msg[1];
+   int r;
+
+   msg[0].addr = client->addr;
+   msg[0].flags = 0;
+   msg[0].buf = data;
+   msg[0].len = len;
+
+   r = i2c_transfer(client->adapter, msg, 1);
+
+   if (r != 1) {
+   dev_err(&client->dev, "%s: write error.\n", __func__);
+   return -EREMOTEIO;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(wl1273_fm_write_data);
+
+/**
+ * wl1273_fm_set_audio() - Set audio mode.
+ * @core:  A pointer to the device struct.
+ * @new_mode:  The new audio mode.
+ *
+ * Audio modes are WL1273_AUDIO_DIGITAL and WL1273_AUDIO_ANALOG.
+ */
+int wl1273_fm_set_audio(struct wl1273_core *core, unsigned int new_mode)
+{
+   int r = 0;
+
+   if (core->mode == WL1273_MODE_OFF ||
+   core->mode == WL1273_MODE_SUSPENDED)
+   return -EPERM;
+
+   if (core->mode == WL1273_MODE_RX && new_mode == WL1273_AUDIO_DIGITAL) {
+   r = wl1273_fm_write_cmd(core, WL1273_PCM_MODE_SET,
+   WL1273_PCM_DEF_MODE);
+   if (r)
+   goto out;
+
+   r = wl1273_fm_write_cmd(core, WL1273_I2S

[PATCH v7 3/5] ASoC: WL1273 FM Radio Digital audio codec.

2010-08-02 Thread Matti J. Aaltonen
The codec handles digital audio input to and output from the
WL1273 FM radio.

Signed-off-by: Matti J. Aaltonen 
---
 sound/soc/codecs/Kconfig  |6 +
 sound/soc/codecs/Makefile |2 +
 sound/soc/codecs/wl1273.c |  591 +
 sound/soc/codecs/wl1273.h |   42 
 4 files changed, 641 insertions(+), 0 deletions(-)
 create mode 100644 sound/soc/codecs/wl1273.c
 create mode 100644 sound/soc/codecs/wl1273.h

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 52b005f..c4769f2 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -35,6 +35,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
+   select SND_SOC_WL1273 if I2C
select SND_SOC_WM8350 if MFD_WM8350
select SND_SOC_WM8400 if MFD_WM8400
select SND_SOC_WM8510 if SND_SOC_I2C_AND_SPI
@@ -161,6 +162,11 @@ config SND_SOC_UDA134X
 config SND_SOC_UDA1380
 tristate
 
+config SND_SOC_WL1273
+   tristate
+   select WL1273_CORE
+   default n
+
 config SND_SOC_WM8350
tristate
 
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index dbaecb1..2a7c564 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -22,6 +22,7 @@ snd-soc-tlv320dac33-objs := tlv320dac33.o
 snd-soc-twl4030-objs := twl4030.o
 snd-soc-uda134x-objs := uda134x.o
 snd-soc-uda1380-objs := uda1380.o
+snd-soc-wl1273-objs := wl1273.o
 snd-soc-wm8350-objs := wm8350.o
 snd-soc-wm8400-objs := wm8400.o
 snd-soc-wm8510-objs := wm8510.o
@@ -78,6 +79,7 @@ obj-$(CONFIG_SND_SOC_TLV320DAC33) += snd-soc-tlv320dac33.o
 obj-$(CONFIG_SND_SOC_TWL4030)  += snd-soc-twl4030.o
 obj-$(CONFIG_SND_SOC_UDA134X)  += snd-soc-uda134x.o
 obj-$(CONFIG_SND_SOC_UDA1380)  += snd-soc-uda1380.o
+obj-$(CONFIG_SND_SOC_WL1273)   += snd-soc-wl1273.o
 obj-$(CONFIG_SND_SOC_WM8350)   += snd-soc-wm8350.o
 obj-$(CONFIG_SND_SOC_WM8400)   += snd-soc-wm8400.o
 obj-$(CONFIG_SND_SOC_WM8510)   += snd-soc-wm8510.o
diff --git a/sound/soc/codecs/wl1273.c b/sound/soc/codecs/wl1273.c
new file mode 100644
index 000..2c0b89c
--- /dev/null
+++ b/sound/soc/codecs/wl1273.c
@@ -0,0 +1,591 @@
+/*
+ * ALSA SoC WL1273 codec driver
+ *
+ * Author:  Matti Aaltonen, 
+ *
+ * Copyright:   (C) 2010 Nokia Corporation
+ *
+ * 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, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "wl1273.h"
+
+static int snd_wl1273_fm_set_i2s_mode(struct wl1273_core *core,
+ int rate, int width)
+{
+   struct device *dev = &core->i2c_dev->dev;
+   int r = 0;
+   u16 mode;
+
+   dev_dbg(dev, "rate: %d\n", rate);
+   dev_dbg(dev, "width: %d\n", width);
+
+   mutex_lock(&core->lock);
+
+   mode = core->i2s_mode & ~WL1273_IS2_WIDTH & ~WL1273_IS2_RATE;
+
+   switch (rate) {
+   case 48000:
+   mode |= WL1273_IS2_RATE_48K;
+   break;
+   case 44100:
+   mode |= WL1273_IS2_RATE_44_1K;
+   break;
+   case 32000:
+   mode |= WL1273_IS2_RATE_32K;
+   break;
+   case 22050:
+   mode |= WL1273_IS2_RATE_22_05K;
+   break;
+   case 16000:
+   mode |= WL1273_IS2_RATE_16K;
+   break;
+   case 12000:
+   mode |= WL1273_IS2_RATE_12K;
+   break;
+   case 11025:
+   mode |= WL1273_IS2_RATE_11_025;
+   break;
+   case 8000:
+   mode |= WL1273_IS2_RATE_8K;
+   break;
+   default:
+   dev_err(dev, "Sampling rate: %d not supported\n", rate);
+   r = -EINVAL;
+   goto out;
+   }
+
+   switch (width) {
+   case 16:
+   mode |= WL1273_IS2_WIDTH_32;
+   break;
+   case 20:
+   mode |= WL1273_IS2_WIDTH_40;
+   break;
+   case 24:
+   mode |= WL1273_IS2_WIDTH_48;
+   break;
+   case 25:
+   mode |= WL1273_IS2_WIDTH_50;
+   break;
+   case 30:
+   mode |= WL1273_IS2_WIDTH_60;
+   break;
+   case 32:
+   mode |= WL1273_IS2_WIDTH_64;
+   break;
+   case 40:
+  

[PATCH v7 1/5] V4L2: Add seek spacing and FM RX class.

2010-08-02 Thread Matti J. Aaltonen
Add spacing field to v4l2_hw_freq_seek and also add FM RX class to
control classes.

Signed-off-by: Matti J. Aaltonen 
---
 drivers/media/video/v4l2-common.c |   12 
 include/linux/videodev2.h |   15 ++-
 2 files changed, 26 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/v4l2-common.c 
b/drivers/media/video/v4l2-common.c
index cd1f21d..41b1bb2 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -351,6 +351,12 @@ const char **v4l2_ctrl_get_menu(u32 id)
"75 useconds",
NULL,
};
+   static const char *fm_band[] = {
+   "87.5 - 108. MHz",
+   "76. - 90. MHz, Japan",
+   "65. - 74. MHz, OIRT",
+   NULL,
+   };
 
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -391,6 +397,8 @@ const char **v4l2_ctrl_get_menu(u32 id)
return colorfx;
case V4L2_CID_TUNE_PREEMPHASIS:
return tune_preemphasis;
+   case V4L2_CID_FM_BAND:
+   return fm_band;
default:
return NULL;
}
@@ -515,6 +523,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_TUNE_PREEMPHASIS: return "Pre-emphasis settings";
case V4L2_CID_TUNE_POWER_LEVEL: return "Tune Power Level";
case V4L2_CID_TUNE_ANTENNA_CAPACITOR:   return "Tune Antenna Capacitor";
+   case V4L2_CID_FM_RX_CLASS:  return "FM Radio Tuner 
Controls";
+   case V4L2_CID_FM_BAND:  return "FM Band";
 
default:
return NULL;
@@ -580,6 +590,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32 
min, s32 max, s32 ste
case V4L2_CID_EXPOSURE_AUTO:
case V4L2_CID_COLORFX:
case V4L2_CID_TUNE_PREEMPHASIS:
+   case V4L2_CID_FM_BAND:
qctrl->type = V4L2_CTRL_TYPE_MENU;
step = 1;
break;
@@ -591,6 +602,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32 
min, s32 max, s32 ste
case V4L2_CID_CAMERA_CLASS:
case V4L2_CID_MPEG_CLASS:
case V4L2_CID_FM_TX_CLASS:
+   case V4L2_CID_FM_RX_CLASS:
qctrl->type = V4L2_CTRL_TYPE_CTRL_CLASS;
qctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
min = max = step = def = 0;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 418dacf..26522cb 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -935,6 +935,7 @@ struct v4l2_ext_controls {
 #define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression controls */
 #define V4L2_CTRL_CLASS_CAMERA 0x009a  /* Camera class controls */
 #define V4L2_CTRL_CLASS_FM_TX 0x009b   /* FM Modulator control class */
+#define V4L2_CTRL_CLASS_FM_RX 0x009c   /* FM Tuner control class */
 
 #define V4L2_CTRL_ID_MASK(0x0fff)
 #define V4L2_CTRL_ID2CLASS(id)((id) & 0x0fffUL)
@@ -1313,6 +1314,17 @@ enum v4l2_preemphasis {
 #define V4L2_CID_TUNE_POWER_LEVEL  (V4L2_CID_FM_TX_CLASS_BASE + 
113)
 #define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FM_TX_CLASS_BASE + 114)
 
+/* FM Tuner class control IDs */
+#define V4L2_CID_FM_RX_CLASS_BASE  (V4L2_CTRL_CLASS_FM_RX | 0x900)
+#define V4L2_CID_FM_RX_CLASS   (V4L2_CTRL_CLASS_FM_RX | 1)
+
+#define V4L2_CID_FM_BAND   (V4L2_CID_FM_RX_CLASS_BASE + 1)
+enum v4l2_fm_band {
+   V4L2_FM_BAND_OTHER  = 0,
+   V4L2_FM_BAND_JAPAN  = 1,
+   V4L2_FM_BAND_OIRT   = 2
+};
+
 /*
  * T U N I N G
  */
@@ -1377,7 +1389,8 @@ struct v4l2_hw_freq_seek {
enum v4l2_tuner_type  type;
__u32 seek_upward;
__u32 wrap_around;
-   __u32 reserved[8];
+   __u32 spacing;
+   __u32 reserved[7];
 };
 
 /*
-- 
1.6.1.3

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


[PATCH v7 4/5] V4L2: WL1273 FM Radio: Controls for the FM radio.

2010-08-02 Thread Matti J. Aaltonen
This driver implements V4L2 controls for the Texas Instruments
WL1273 FM Radio.

Signed-off-by: Matti J. Aaltonen 
---
 drivers/media/radio/Kconfig|   15 +
 drivers/media/radio/Makefile   |1 +
 drivers/media/radio/radio-wl1273.c | 1972 
 drivers/mfd/Kconfig|6 +
 drivers/mfd/Makefile   |2 +
 5 files changed, 1996 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/radio/radio-wl1273.c

diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 83567b8..209fd37 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -452,4 +452,19 @@ config RADIO_TIMBERDALE
  found behind the Timberdale FPGA on the Russellville board.
  Enabling this driver will automatically select the DSP and tuner.
 
+config RADIO_WL1273
+   tristate "Texas Instruments WL1273 I2C FM Radio"
+depends on I2C && VIDEO_V4L2 && SND
+   select FW_LOADER
+   ---help---
+ Choose Y here if you have this FM radio chip.
+
+ In order to control your radio card, you will need to use programs
+ that are compatible with the Video For Linux 2 API.  Information on
+ this API and pointers to "v4l2" programs may be found at
+ .
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-wl1273.
+
 endif # RADIO_ADAPTERS
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index f615583..d297074 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
 obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o
 obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
 obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
+obj-$(CONFIG_RADIO_WL1273) += radio-wl1273.o
 
 EXTRA_CFLAGS += -Isound
diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
new file mode 100644
index 000..9c7f01f
--- /dev/null
+++ b/drivers/media/radio/radio-wl1273.c
@@ -0,0 +1,1972 @@
+/*
+ * Driver for the Texas Instruments WL1273 FM radio.
+ *
+ * Copyright (C) Nokia Corporation
+ * Author: Matti J. Aaltonen 
+ *
+ * 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, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_DESC "Wl1273 FM Radio - V4L2"
+
+#define WL1273_POWER_SET_OFF   0
+#define WL1273_POWER_SET_FM(1 << 0)
+#define WL1273_POWER_SET_RDS   (1 << 1)
+#define WL1273_POWER_SET_RETENTION (1 << 4)
+
+#define WL1273_PUPD_SET_OFF0x00
+#define WL1273_PUPD_SET_ON 0x01
+#define WL1273_PUPD_SET_RETENTION  0x10
+
+#define WL1273_FREQ(x) (x * 1 / 625)
+#define WL1273_INV_FREQ(x) (x * 625 / 1)
+
+/*
+ * static int radio_nr - The number of the radio device
+ *
+ * The default is 0.
+ */
+static int radio_nr = -1;
+module_param(radio_nr, int, 0);
+MODULE_PARM_DESC(radio_nr, "Radio Nr");
+
+struct wl1273_device {
+   struct v4l2_device v4l2dev;
+   struct video_device videodev;
+   struct device *dev;
+   struct wl1273_core *core;
+   struct file *owner;
+   char *write_buf;
+   bool rds_on;
+};
+
+static int wl1273_fm_set_tx_freq(struct wl1273_core *core, unsigned int freq)
+{
+   int r = 0;
+
+   if (freq < 76000) {
+   dev_err(&core->i2c_dev->dev,
+   "Frequency out of range: %d < %d\n",
+   freq, core->bands[core->band].bottom_frequency);
+   return -EDOM;
+   }
+
+   if (freq > 108000) {
+   dev_err(&core->i2c_dev->dev,
+   "Frequency out of range: %d > %d\n",
+   freq, core->bands[core->band].top_frequency);
+   return -EDOM;
+   }
+
+   /*
+*  The driver works better with this msleep,
+*  the documentation doesn't mention it.
+*/
+   msleep(5);
+   dev_dbg(&core->i2c_dev->dev, "%s: freq: %d kHz\n", __func__, freq);
+
+   INIT_COMPLETION(core->busy);
+   /* Set the current tx channel */
+   r = wl1273_fm_write_cmd(core, WL1273_CHANL_SET, freq / 10);
+   if (r)
+   return r;
+
+   /* wait for the FR IRQ */
+   r = wait_for_completion_timeout(&core->busy, msecs_to_jiffies(2

Re: [RFC/PATCH v3 03/10] media: Entities, pads and links

2010-08-02 Thread Laurent Pinchart
Hi Hans,

On Sunday 01 August 2010 13:32:50 Hans Verkuil wrote:
> On Thursday 29 July 2010 18:06:36 Laurent Pinchart wrote:



> > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > new file mode 100644
> > index 000..37a25bf
> > --- /dev/null
> > +++ b/include/media/media-entity.h
> > @@ -0,0 +1,85 @@
> > +#ifndef _MEDIA_ENTITY_H
> > +#define _MEDIA_ENTITY_H
> > +
> > +#include 
> > +
> > +#define MEDIA_ENTITY_TYPE_NODE (1 << 16)
> 
> I agree with Sakari that '16' should be a define.

Will do.

> > +#define MEDIA_ENTITY_TYPE_NODE_V4L (MEDIA_ENTITY_TYPE_NODE + 1)
> > +#define MEDIA_ENTITY_TYPE_NODE_FB  (MEDIA_ENTITY_TYPE_NODE + 2)
> > +#define MEDIA_ENTITY_TYPE_NODE_ALSA(MEDIA_ENTITY_TYPE_NODE 
> > + 3)
> > +#define MEDIA_ENTITY_TYPE_NODE_DVB (MEDIA_ENTITY_TYPE_NODE + 4)
> > +
> > +#define MEDIA_ENTITY_TYPE_SUBDEV   (2 << 16)
> > +#define MEDIA_ENTITY_TYPE_SUBDEV_VID_DECODER   
> > (MEDIA_ENTITY_TYPE_SUBDEV +
> > 1)
> > +#define MEDIA_ENTITY_TYPE_SUBDEV_VID_ENCODER   
> > (MEDIA_ENTITY_TYPE_SUBDEV +
> > 2)
> > +#define MEDIA_ENTITY_TYPE_SUBDEV_MISC  
> > (MEDIA_ENTITY_TYPE_SUBDEV + 3) 
+
> > +#define MEDIA_LINK_FLAG_ACTIVE (1 << 0)
> > +#define MEDIA_LINK_FLAG_IMMUTABLE  (1 << 1)
> > +
> > +#define MEDIA_PAD_FLAG_INPUT   (1 << 0)
> > +#define MEDIA_PAD_FLAG_OUTPUT  (1 << 1)
> > +
> > +struct media_link {
> > +   struct media_pad *source;   /* Source pad */
> > +   struct media_pad *sink; /* Sink pad  */
> > +   struct media_link *other;   /* Link in the reverse direction */
> 
> Why not rename 'other' to 'back' or 'backlink'? 'other' is not a good name
> IMHO.

For forward links other is the backlink, but for backlinks other is the 
forward link. I'll rename it to reverse.

> > +   unsigned long flags;/* Link flags (MEDIA_LINK_FLAG_*) */
> > +};
> > +
> > +struct media_pad {
> > +   struct media_entity *entity;/* Entity this pad belongs to */
> > +   u16 index;  /* Pad index in the entity pads array */
> > +   unsigned long flags;/* Pad flags (MEDIA_PAD_FLAG_*) */
> > +};
> > +
> > +struct media_entity {
> > +   struct list_head list;
> > +   struct media_device *parent;/* Media device this entity belongs to*/
> > +   u32 id; /* Entity ID, unique in the parent media
> > +* device context */
> > +   const char *name;   /* Entity name */
> > +   u32 type;   /* Entity type (MEDIA_ENTITY_TYPE_*) */
> > +
> > +   u8 num_pads;/* Number of input and output pads */
> > +   u8 num_links;   /* Number of existing links, both active
> > +* and inactive */
> > +   u8 num_backlinks;   /* Number of backlinks */
> > +   u8 max_links;   /* Maximum number of links */
> > +
> > +   struct media_pad *pads; /* Pads array (num_pads elements) */
> > +   struct media_link *links;   /* Links array (max_links elements)*/
> > +
> > +   union {
> > +   /* Node specifications */
> > +   struct {
> > +   u32 major;
> > +   u32 minor;
> > +   } v4l;
> > +   struct {
> > +   u32 major;
> > +   u32 minor;
> > +   } fb;
> > +   int alsa;
> > +   int dvb;
> > +
> > +   /* Sub-device specifications */
> > +   /* Nothing needed yet */
> > +   };
> > +};
> > +
> > +#define MEDIA_ENTITY_TYPE_MASK 0x
> > +#define MEDIA_ENTITY_SUBTYPE_MASK  0x
> > +
> > +#define media_entity_type(entity) \
> > +   ((entity)->type & MEDIA_ENTITY_TYPE_MASK)
> > +#define media_entity_subtype(entity) \
> > +   ((entity)->type & MEDIA_ENTITY_SUBTYPE_MASK)
> 
> Make these inline functions to ensure correct typechecking.

OK.

> Since bit 31 of the entity ID is reserved for MEDIA_ENTITY_ID_FLAG_NEXT you
> probably should change the TYPE_MASK to 0x7fff. Actually, I would
> change the type mask to 0x00ff, that way all top 8 bits are available
> for the future.

Agreed.

> > +
> > +int media_entity_init(struct media_entity *entity, u8 num_pads,
> > +   struct media_pad *pads, u8 extra_links);
> > +void media_entity_cleanup(struct media_entity *entity);
> > +int media_entity_create_link(struct media_entity *source, u8 source_pad,
> > +   struct media_entity *sink, u8 sink_pad, u32 flags);
> > +
> > +#endif

-- 
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: [RFC/PATCH v3 06/10] media: Entities, pads and links enumeration

2010-08-02 Thread Laurent Pinchart
Hi Hans,

On Sunday 01 August 2010 13:58:20 Hans Verkuil wrote:
> On Thursday 29 July 2010 18:06:39 Laurent Pinchart wrote:

[snip]

> > diff --git a/Documentation/media-framework.txt
> > b/Documentation/media-framework.txt index 6d680c6..1192feb 100644
> > --- a/Documentation/media-framework.txt
> > +++ b/Documentation/media-framework.txt
> > @@ -273,3 +273,134 @@ required, drivers don't need to provide a set_power

[snip]

> > +- struct media_entity_desc
> > +
> > +__u32  id  Entity id, set by the application. When the id 
> > is
> > +   or'ed with MEDIA_ENTITY_ID_FLAG_NEXT, the driver
> > +   clears the flag and returns the first entity with a
> > +   larger id.
> > +char   name[32]Entity name. UTF-8 NULL-terminated string.
> > +__u32  typeEntity type.
> > +__u8   padsNumber of pads.
> 
> Should be u16.

Thanks. Will fix.

[snip]

> > diff --git a/include/linux/media.h b/include/linux/media.h
> > new file mode 100644
> > index 000..9b8acc0
> > --- /dev/null
> > +++ b/include/linux/media.h
> > @@ -0,0 +1,77 @@

[snip]

> > +struct media_entity_desc {
> > +   __u32 id;
> > +   char name[32];
> > +   __u32 type;
> > +   __u8 pads;
> 
> u16.

Thanks. Will fix.

[snip]

> 
> > +   __u32 links;
> > +
> > +   __u32 reserved[4];
> > +
> > +   union {
> > +   /* Node specifications */
> > +   struct {
> > +   __u32 major;
> > +   __u32 minor;
> > +   } v4l;
> > +   struct {
> > +   __u32 major;
> > +   __u32 minor;
> > +   } fb;
> > +   int alsa;
> > +   int dvb;
> > +
> > +   /* Sub-device specifications */
> > +   /* Nothing needed yet */
> > +   __u8 raw[64];
> > +   };
> > +};
> 
> Would there be anything else that we want to describe with these pad_desc
> and entity_desc structs?

Definitely. Thanks for reminding me :-)

> For subdevs you want to return a chip ident and revision field (same as
> VIDIOC_DBG_G_CHIP_IDENT does).

Do we still need a chip ID when we now have a name ? Keeping the chip ID 
registry updated is painful, it would be nice if we could do away with it.

A revision field is a very good idea, I'll add it.

> Should we allow (possibly optional) names for pads? Or 'tooltip'-type
> descriptions that can be a lot longer than 32 chars? (Just brainstorming
> here).
>
> I am of course thinking of apps where the user can setup the media flow
> using a GUI. If the driver can provide more extensive descriptions of the
> various entities/pads, then that would make it much easier for the user to
> experiment.

It would be nice to have, yes. Some kind of pad capabilities would be 
interesting too.

> Note that I also think that obtaining such detailed information might be
> better done through separate ioctls (e.g. MEDIA_IOC_G_PAD_INFO, etc.).

I agree. So we can leave the additional pad information out for now and add it 
later if needed :-)
 
> What is definitely missing and *must* be added is a QUERYCAP type ioctl
> that provides driver/versioning info.

I'll create one.

> Another thing that we need to figure out is how to tell the application
> which audio and video nodes belong together.

What about adding a group ID field in media_entity ?

> Not only that, but we need to be able to inform the driver how audio is
> hooked up: through an audio loopback cable, an alsa device,

Doesn't the loopback cable connect the audio signal to audio hardware that 
exposes an ALSA device ? How will drivers be able to tell if the user has 
connected a loopback cable and what he has connected it to ?

> part of an mpeg stream,

In that case there will be no audio device.

> or as a V4L2 audio device (ivtv can do that, and I think pvrusb2 does the
> same for radio). I'm not entirely sure we want to expose that last option as
> it is not really spec compliant.

I'm not sure either :-) Why doesn't ivtv use an ALSA device ?

> Other things we may want to expose: is the video stream raw or compressed?

I think that belongs to V4L2.

> What are the default video/audio/vbi streams? (That allows an app to find
> the default video device node if a driver has lots of them).

What about adding a __u32 flags field to media_entity, and defining a 
MEDIA_ENTITY_FLAG_DEFAULT bit ?

> Some of this information should perhaps be exposed through the v4l2 API,
> but other parts definitely belong here.
> 
> I've not thought about this in detail, but we need to set some time aside
> to brainstorm on how to provide this information in a logical and
> consistent manner.

IRC ? A real meeting would be better, but the next scheduled one is in 
November and that's a bit too far away.

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

Re: [PATCH v2]Resend:videobuf_dma_sg: a new implementation for mmap

2010-08-02 Thread Figo.zhang
On Fri, 2010-07-30 at 19:39 +0800, Figo.zhang wrote:
> On Fri, 2010-07-30 at 11:31 +0200, Laurent Pinchart wrote:
> > Hi,
> > 
> > On Friday 30 July 2010 02:08:02 Figo.zhang wrote:
> > > a mmap issue for videobuf-dma-sg: it will alloc a new page for mmaping 
> > > when
> > > it encounter page fault at video_vm_ops->fault(). pls see
> > > http://www.spinics.net/lists/linux-media/msg21243.html
> > > 
> > > a new implementation for mmap, it translate to vmalloc to page at
> > > video_vm_ops->fault().
> > > 
> > > in v2, if mem->dma.vmalloc is NULL at video_vm_ops->fault(), it will alloc
> > > memory by vmlloc_32().
> > 
> > You're replacing allocation in videobuf_vm_fault by allocationg in 
> > videobuf_vm_fault. I don't see the point. videobuf_vm_fault needs to go 
> > away 
> > completely.
> in now videobuf code, the mmap alloc a new buf, the capture dma buffer
> using vmalloc() alloc buffer, how is
> relationship with them? in usrspace , the mmap region will not the
> actual capture dma data, how is work? 


hmm, I understand with some mistake before.for mmap in videobuf-sg, it
is not call vmalloc_32() to alloc memory, it call
videobuf_dma_init_user_locked()->get_user_pages(), and the end, it will
handle_mm_fault()-> vm_ops->fault(). Because in mmap(), it have assigned
vaule for "baddr" variable.

it is too obscure for videobuf-sg, hope for videbuf2. ~~


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


Remote that breaks current system (was: IR: Port ene driver...) it.

2010-08-02 Thread Jarod Wilson
On Sat, Jul 31, 2010 at 05:53:33PM -0400, Jon Smirl wrote:
> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls  wrote:
...
> > Since these two protocols have such close timings that systematic errors
> > can cause misclassification when using simple mark or space measurements
> > against fixed thresholds, it indicates that a more sophisticated
> > discrimination mechanism would be needed.  Perhaps one that takes multiple
> > successive measurements into account?
> 
> If we get to the point where we need more sophisticated
> classifications we can build it. But are we at that point yet? I'd
> prefer to initially leave everything pretty strict as a way of
> flushing out driver implementation bugs.
> 
> Find some remotes and receivers that break the current system.

Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
ported over the weekend, but this remote just won't decode correctly w/the
in-kernel RC5 decoder.

Working:
Streamzap receiver + RC6 (MCE) remote, in-kernel decoding
Streamzap receiver + RC5 (Streamzap) remote, lirc decoding

Not working:
Streamzap receiver + RC5 (Streamzap) remote, in-kernel decoding
MCE transceiver + RC5 (Streamzap) remote, in-kernel decoding

Failure mode is identical between the two, leading me to believe my
streamzap port is good to go, we just have an issue to track down with rc5
decoding.

Said failure mode is that RC5 fails at STATE_INACTIVE (0) with the initial
space provided by both receivers, then gets rolling with (I believe) the
first pulse. It then gets all the way to STATE_FINISHED, and bails,
because it should be on a space there, but its on a pulse.

I've twiddled the decoder to proceed even if its a pulse, but the
resulting decoding is still no good, as multiple adjacent keys (which have
proper decoded values that only differ by 1, per lirc decoding) get
decoded to the same value as one another.

Still poking around trying to figure out the problem, but here's what the
(slightly modified to not bail when it gets to STATE_FINISHED with a
pulse) rc5 decoder is seeing/doing:

ir_rc5_decode: RC5(x) decode started at state 0 (4292819813us space)
ir_rc5_decode: RC5(x) decode failed at state 0 (4292819813us space)
ir_rc5_decode: RC5(x) decode started at state 0 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (7us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 3 (7us pulse)
ir_rc5_decode: RC5(x) decode started at state 3 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
ir_rc5_decode: RC5(x) decode started at state 4 (1031us pulse)
ir_rc5_decode: RC5 usually ends w/space, wtf?
ir_rc5_decode: RC5 scancode 0x1129 (toggle: 0)
ir_getkeycode: unknown key for scancode 0x1129

This was for the OK button on the remote, which in lircd, decodes to
scancode 0x12 in the lower 6 bits, high 8 bits are 0xa3 for all buttons.
At least, I think I'm decoding lircd.conf correctly. See here to be sure:

http://lirc.sourceforge.net/remotes/streamzap/lircd.conf.streamzap

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

Re: Handling of large keycodes

2010-08-02 Thread Jarod Wilson
On Mon, Aug 02, 2010 at 08:35:37AM -0300, Mauro Carvalho Chehab wrote:
> Em 02-08-2010 05:02, Dmitry Torokhov escreveu:
> > On Sat, Jul 31, 2010 at 10:23:45AM -0300, Mauro Carvalho Chehab wrote:
> >> Hi Dmitry,
> >>
> >> Em 31-07-2010 06:19, Dmitry Torokhov escreveu:
> >>> Hi Mauro,
> >>>
> >>> I finally got a chance to review the patches adding handling of large
> >>> scancodes to input core and there are a few things with this approach
> >>> that I do not like.
> >>
> >> Thanks for the review!
> >>
> >>> First of all I do not think that we should be working with scancode via
> >>> a pointer as it requires additional compat handling when running 32-bit
> >>> userspace on 64-bit kernel. We can use a static buffer of sufficient
> >>> size (lets say 32 bytes) to move scancode around and simply increase its
> >>> size if we come upon device that uses even bigger scancodes. As long as
> >>> buffer is at the end we can handle this in a compatible way.
> >>
> >> Yes, this is the downside of using a pointer. I'm not aware of a Remote
> >> Controller protocol using more than 256 bits for scancode, so 32 bits
> >> should be ok.
> >>
> >>> The other issue is that interface is notsymmetrical, setting is done by
> >>> scancode but retrieval is done by index. I think we should be able to
> >>> use both scancode and index in both operations.
> >>
> >> Yes, this also bothered me. I was thinking to do something similar to your
> >> approach of having a bool to select between them. This change is welcome.
> >>
> >>> The usefulnes of reserved data elements in the structure is doubtful,
> >>> since we do not seem to require them being set to a particular value and
> >>> so we'll be unable to distinguish betwee legacy and newer users.
> >>
> >> David proposed some parameters that we rejected on our discussions. As we
> >> might need to add something similar, I decided to keep it on my approach,
> >> since a set of reserved fields wouldn't hurt (and removing it on our 
> >> discussions
> >> would be easy), but I'm ok on removing them.
> >>
> >>> I also concerned about the code very messy with regard to using old/new
> >>> style interfaces instea dof converting old ones to use new
> >>> insfrastructure,
> >>
> >> Good cleanup at the code!
> >>
> >>> I below is something that addresses these issues and seems to be working
> >>> for me. It is on top of your patches and it also depends on a few
> >>> changes in my tree that I have not publushed yet but plan on doing that
> >>> tomorrow. I am also attaching patches converting sparse keymap and hid
> >>> to the new style of getkeycode and setkeycode as examples.
> >>>
> >>> Please take a look and let me know if I missed something important.
> >>
> >> It seems to work for me. After you add the patches on your git tree, I'll 
> >> work on porting the RC core to the new approach, and change the ir-keycode
> >> userspace program to work with, in order to be 100% sure that it will 
> >> work, 
> >> but I can't foresee any missing part on it.
> >>
> >> Currently, I'm not using my input patches, as I was waiting for your
> >> review. I just patched the userspace application, in order to test the 
> >> legacy
> >> mode.
> >>
> > 
> > OK, great.
> > 
> > I want to fold all the patches from your tree plus this one into one and
> > apply in one shpt (mentioning Jarod and Dan as authors of fixup patches
> > in the changelog) - I do not believe we shoudl expose intermediate
> > versions in the code that will go to Linus. Are you OK with this?
> 
> I'm OK. If you want, you can add my ack on your patch:
> 
> Acked-by: Mauro Carvalho Chehab 

Yeah, works for me too.

-- 
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: [PATCHv2 2/4] mm: cma: Contiguous Memory Allocator added

2010-08-02 Thread Michał Nazarewicz

On Wednesday 28 July 2010 11:04:56 Marek Szyprowski wrote:

Let me introduce one more example. As you may know we have 3 video-processor
capture devices (Samsung FIMC) and a hardware codec (like Samsung MFC). FIMC
can capture video data from camera sensor and accelerate common video
processing tasks (like up/down scaling and color space conversion). Two FIMC
and MFC are require for things like HD video encoding or decoding with
online display/preview. This task require huge video buffers that are
usually allocated and freed at the same time. The third FIMC can be used for
gfx acceleration (color space conversion and scaling are quite common tasks
in GUI). This latter task usually introduces a lot of memory fragmentation,
as gfx surfaces are usually quite small (definitely smaller than HD frames
or 8MPix picture from camera). It would be really wise to get that third
FIMC device to use memory buffer that will be shared with 3D accelerator
(which has quite similar usage scenarios and suffers from similar memory
fragmentation).


On Sun, 01 Aug 2010 15:26:13 +0200, Hans Verkuil  wrote:

OK, I understand. And I assume both gfx and 3D acceleration need to use a
specific region? If they can use any type of memory, then this might be more
appropriate for kmalloc and friends.


I've been thinking about providing a "fake" region with a "fake" allocator which
would allow in a generic way passing requests to kmalloc() and friends.  Such
regions could prove valuable for small allocations in things like 3D 
accelerator.

But as you've said, it's better to provide something small first and later add 
to
it so I'm postponing implementation of this feature.

Note, however, that 3D accelerator does not operate only on small chunks of 
memory.
A 1024x1024 texture is 1 Mipx.  RGB makes it 3MiB.  With mipmap it's 4MiB.  Even
512x512 texture can reach 1MiB this way.  It ma be impossible to allocate such
chunks with just a kmalloc().


We don't want to allocate X buffers of Y MB memory each on boot. Instead we
want to just reserve XX MB memory and then dynamically allocate buffers from
it. This enables us to perform the following 2 tasks:
1. movie decoding in HD-quality (only one instance)
2. two instances of SD-quality movie decoding and SD-quality move encoding
   (example: video conference)

We know that these two use cases are exclusive, so they can use the same
reserved memory.



When I said 'allocating X buffers of Y MB memory' I meant that you need to
allocate a known amount of memory (X * Y MB in this case). So the boot args
say e.g. dma=40MB and the driver just allocates X buffers from that region.


But the point is that driver does not allocate memory at boot time.  If video
codec would allocate memory at boot time no one else could use it even if the
codec is not used.  The idea is to make other devices use the memory when
codec is idle.  For instance, one could work on huge JPEG images and need
buffers for a hardware JPEG codec.

Or have I misunderstood your point?


Switching to SD quality requires releasing those buffers and instead allocating
a number of smaller buffers from the same region.


Our intention is that driver would allocate buffers only when needed so the 
buffers
would be freed when video codec driver is released.  So when the device is 
opened
(whatever that would mean for a particular device) it would allocate enough 
memory
for the requested task.


For these use-cases the allocator can be very simple and probably covers most
use-cases.


Yes, this is our experience.  The best-fit algorithm, even though simple, seem 
to
handle use cases tested on our system with little fragmentation.


Anyway, I'm no expert on memory allocators and people on the linux-mm list are
no doubt much more qualified to discuss this. My main concern is that of
trying to add too much for a first release. It is simply easier to start simple
and extend as needed. That makes it easier to be accepted in the mainline.


I'm trying to keep it as simple as possible :) still making it useful for us.

In particular we need a way to specify where different regions reside (different
memory banks, etc.) as well as specify which drivers should use which regions.
What's more, we need the notion of a "kind" of memory as one driver may need
memory buffers from different regions (ie. MFC needs to allocate buffers from
both banks).


+2. CMA allows a run-time configuration of the memory regions it
+   will use to allocate chunks of memory from.  The set of memory
+   regions is given on command line so it can be easily changed
+   without the need for recompiling the kernel.
+
+   Each region has it's own size, alignment demand, a start
+   address (physical address where it should be placed) and an
+   allocator algorithm assigned to the region.
+
+   This means that there can be different algorithms running at
+   the same time, if different devices on the platform have
+   distinct memory usage 

Re: [PATCH 09/13] IR: add helper function for hardware with small o/b buffer.

2010-08-02 Thread Jarod Wilson
On Sun, Aug 01, 2010 at 10:11:01PM -0400, Andy Walls wrote:
> On Sat, 2010-07-31 at 17:59 +0300, Maxim Levitsky wrote:
...
> >  struct ir_input_dev {
> > @@ -69,9 +81,10 @@ struct ir_input_dev {
> > char*driver_name;   /* Name of the driver 
> > module */
> > struct ir_scancode_tablerc_tab; /* scan/key table */
> > unsigned long   devno;  /* device number */
> > -   const struct ir_dev_props   *props; /* Device properties */
> > +   struct ir_dev_props *props; /* Device properties */
> 
> So I don't think the struct ir_dev_props structure is the right place to
> be storing current operating parameters. IMO, operating parameters
> stored in the ir_dev_props are "too far" from the lower level driver,
> and are essentially mirroring what the low level driver should be
> tracking internally as it's own state anyway.
> 
> 
> So in summary, I think we need to keep the opertions in struct
> ir_dev_props simple using ,get_parameters() and .set_parameters() to
> contol the lower level driver and to fetch, retrieve, and store
> parameters.

Yeah, I neglected to consider this change the first pass through an
earlier revision. Making props modifiable on the fly does feel like we're
mixing up hardware features with hardware state, and perhaps the
on-the-fly-modifiable state bits should be stored somewhere else.

-- 
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: Remote that breaks current system (was: IR: Port ene driver...) it.

2010-08-02 Thread Jon Smirl
On Mon, Aug 2, 2010 at 11:12 AM, Jarod Wilson  wrote:
> On Sat, Jul 31, 2010 at 05:53:33PM -0400, Jon Smirl wrote:
>> On Sat, Jul 31, 2010 at 2:51 PM, Andy Walls  wrote:
> ...
>> > Since these two protocols have such close timings that systematic errors
>> > can cause misclassification when using simple mark or space measurements
>> > against fixed thresholds, it indicates that a more sophisticated
>> > discrimination mechanism would be needed.  Perhaps one that takes multiple
>> > successive measurements into account?
>>
>> If we get to the point where we need more sophisticated
>> classifications we can build it. But are we at that point yet? I'd
>> prefer to initially leave everything pretty strict as a way of
>> flushing out driver implementation bugs.
>>
>> Find some remotes and receivers that break the current system.
>
> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
> ported over the weekend, but this remote just won't decode correctly w/the
> in-kernel RC5 decoder.

Manchester encoding may need a decoder that waits to get 2-3 edge
changes before deciding what the first bit. As you decode the output
is always a couple bits behind the current input data.

You can build of a table of states
L0 S1 S0 L1  - emit a 1, move forward an edge
S0 S1 L0 L1 - emit a 0, move forward an edge

By doing it that way you don't have to initially figure out the bit clock.

The current decoder code may not be properly tracking the leading
zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
off by 1/2 a bit cycle.

Did you note the comment that Extended RC-5 has only a single start
bit instead of two?

>
> Working:
> Streamzap receiver + RC6 (MCE) remote, in-kernel decoding
> Streamzap receiver + RC5 (Streamzap) remote, lirc decoding
>
> Not working:
> Streamzap receiver + RC5 (Streamzap) remote, in-kernel decoding
> MCE transceiver + RC5 (Streamzap) remote, in-kernel decoding
>
> Failure mode is identical between the two, leading me to believe my
> streamzap port is good to go, we just have an issue to track down with rc5
> decoding.
>
> Said failure mode is that RC5 fails at STATE_INACTIVE (0) with the initial
> space provided by both receivers, then gets rolling with (I believe) the
> first pulse. It then gets all the way to STATE_FINISHED, and bails,
> because it should be on a space there, but its on a pulse.
>
> I've twiddled the decoder to proceed even if its a pulse, but the
> resulting decoding is still no good, as multiple adjacent keys (which have
> proper decoded values that only differ by 1, per lirc decoding) get
> decoded to the same value as one another.
>
> Still poking around trying to figure out the problem, but here's what the
> (slightly modified to not bail when it gets to STATE_FINISHED with a
> pulse) rc5 decoder is seeing/doing:
>
> ir_rc5_decode: RC5(x) decode started at state 0 (4292819813us space)
> ir_rc5_decode: RC5(x) decode failed at state 0 (4292819813us space)
> ir_rc5_decode: RC5(x) decode started at state 0 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (7us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (896us pulse)
> ir_rc5_decode: RC5(x) decode started at state 3 (7us pulse)
> ir_rc5_decode: RC5(x) decode started at state 3 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1920us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (1031us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us space)
> ir_rc5_decode: RC5(x) decode started at state 2 (1664us pulse)
> ir_rc5_decode: RC5(x) decode started at state 1 (775us pulse)
> ir_rc5_decode: RC5(x) decode started at state 2 (896us space)
> ir_rc5_decode: RC5(x) decode started at state 1 (7us space)
> ir_rc5_decode: RC5(

Re: Remote that breaks current system

2010-08-02 Thread Christoph Bartelmus
Hi!

Jon Smirl "jonsm...@gmail.com" wrote:
[...]
>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
>> ported over the weekend, but this remote just won't decode correctly w/the
>> in-kernel RC5 decoder.

> Manchester encoding may need a decoder that waits to get 2-3 edge
> changes before deciding what the first bit. As you decode the output
> is always a couple bits behind the current input data.
>
> You can build of a table of states
> L0 S1 S0 L1  - emit a 1, move forward an edge
> S0 S1 L0 L1 - emit a 0, move forward an edge
>
> By doing it that way you don't have to initially figure out the bit clock.
>
> The current decoder code may not be properly tracking the leading
> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
> off by 1/2 a bit cycle.
>
> Did you note the comment that Extended RC-5 has only a single start
> bit instead of two?

It has nothing to do with start bits.
The Streamzap remote just sends 14 (sic!) bits instead of 13.
The decoder expects 13 bits.
Yes, the Streamzap remote does _not_ use standard RC-5.
Did I mention this already? Yes. ;-)

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


Re: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface

2010-08-02 Thread Russell King - ARM Linux
On Mon, Aug 02, 2010 at 02:08:42PM +0200, Pawel Osciak wrote:
> >Russell King - ARM Linux  wrote:
> >On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote:
> >> Well, some of them are indeed unused, but it's not an uncommon practice in
> >> kernel and might help future developers.
> >
> >On the other hand, arch/arm is getting soo big that we need to do
> >something about this - and one solution is to avoid unnecessary
> >definitions that we're not using.
> >
> >Another good idea is to put definitions along side the drivers which
> >they're relevant to - maybe in a local driver-name.h file which
> >driver-name.c includes, or maybe even within driver-name.c if they're
> >not excessive.  This has the advantage of distributing the "bloat" to
> >where its actually used, and means that the driver isn't dependent so
> >much on arch/arm or even the SoC itself.
> >
> >Take a look at arch/arm/mach-vexpress/include/mach/ct-ca9x4.h and
> >arch/arm/mach-vexpress/include/mach/motherboard.h - these are the only
> >two files which contain platform definitions which are actually used
> >for Versatile Express.  Compare that with
> >arch/arm/mach-realview/include/mach/platform.h which contains lots
> >more...
> 
> So basically, what you and Mauro are recommending is that we move the *.h
> file with register definitions to drivers/media?

What I'm suggesting is what's been pretty standard in Linux for a long
time.  Take a look at: drivers/net/3c503.[ch], or for a more recent
driver, drivers/net/e1000/*.[ch].  Or drivers/mmc/host/mmci.[ch]

Putting definitions which are only used by one driver in arch/arm/*/include
is silly.
--
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: Remote that breaks current system

2010-08-02 Thread Jon Smirl
On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus  wrote:
> Hi!
>
> Jon Smirl "jonsm...@gmail.com" wrote:
> [...]
>>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
>>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
>>> ported over the weekend, but this remote just won't decode correctly w/the
>>> in-kernel RC5 decoder.
>
>> Manchester encoding may need a decoder that waits to get 2-3 edge
>> changes before deciding what the first bit. As you decode the output
>> is always a couple bits behind the current input data.
>>
>> You can build of a table of states
>> L0 S1 S0 L1  - emit a 1, move forward an edge
>> S0 S1 L0 L1 - emit a 0, move forward an edge
>>
>> By doing it that way you don't have to initially figure out the bit clock.
>>
>> The current decoder code may not be properly tracking the leading
>> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
>> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
>> off by 1/2 a bit cycle.
>>
>> Did you note the comment that Extended RC-5 has only a single start
>> bit instead of two?
>
> It has nothing to do with start bits.
> The Streamzap remote just sends 14 (sic!) bits instead of 13.
> The decoder expects 13 bits.
> Yes, the Streamzap remote does _not_ use standard RC-5.
> Did I mention this already? Yes. ;-)

If the remote is sending a weird protocol then there are several choices:
  1) implement raw mode
  2) make a Stream-Zap protocol engine (it would be a 14b version of
RC-5). Standard RC5 engine will still reject the messages.
  3) throw away your Stream-Zap remotes

I'd vote for #3, but #2 will probably make people happier.


>
> Christoph
>



-- 
Jon Smirl
jonsm...@gmail.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: Remote that breaks current system

2010-08-02 Thread Jarod Wilson
On Mon, Aug 02, 2010 at 06:42:00PM +0200, Christoph Bartelmus wrote:
> Hi!
> 
> Jon Smirl "jonsm...@gmail.com" wrote:
> [...]
> >> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
> >> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
> >> ported over the weekend, but this remote just won't decode correctly w/the
> >> in-kernel RC5 decoder.
> 
> > Manchester encoding may need a decoder that waits to get 2-3 edge
> > changes before deciding what the first bit. As you decode the output
> > is always a couple bits behind the current input data.
> >
> > You can build of a table of states
> > L0 S1 S0 L1  - emit a 1, move forward an edge
> > S0 S1 L0 L1 - emit a 0, move forward an edge
> >
> > By doing it that way you don't have to initially figure out the bit clock.
> >
> > The current decoder code may not be properly tracking the leading
> > zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
> > They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
> > off by 1/2 a bit cycle.
> >
> > Did you note the comment that Extended RC-5 has only a single start
> > bit instead of two?
> 
> It has nothing to do with start bits.
> The Streamzap remote just sends 14 (sic!) bits instead of 13.
> The decoder expects 13 bits.
> Yes, the Streamzap remote does _not_ use standard RC-5.
> Did I mention this already? Yes. ;-)

D'oh, yeah, sorry, completely forgot you already mentioned this. That
would certainly explain why the rc5 decoder isn't happy with it. So the
*receiver* itself is perfectly functional, its just a goofy IR protocol
sent by its default remote. Blah. So yet another reason having ongoing
lirc compatibility is a Good Thing. ;)

-- 
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: Remote that breaks current system

2010-08-02 Thread Jarod Wilson
On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus  
> wrote:
> > Hi!
> >
> > Jon Smirl "jonsm...@gmail.com" wrote:
> > [...]
> >>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to properly
> >>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
> >>> ported over the weekend, but this remote just won't decode correctly w/the
> >>> in-kernel RC5 decoder.
> >
> >> Manchester encoding may need a decoder that waits to get 2-3 edge
> >> changes before deciding what the first bit. As you decode the output
> >> is always a couple bits behind the current input data.
> >>
> >> You can build of a table of states
> >> L0 S1 S0 L1  - emit a 1, move forward an edge
> >> S0 S1 L0 L1 - emit a 0, move forward an edge
> >>
> >> By doing it that way you don't have to initially figure out the bit clock.
> >>
> >> The current decoder code may not be properly tracking the leading
> >> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
> >> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
> >> off by 1/2 a bit cycle.
> >>
> >> Did you note the comment that Extended RC-5 has only a single start
> >> bit instead of two?
> >
> > It has nothing to do with start bits.
> > The Streamzap remote just sends 14 (sic!) bits instead of 13.
> > The decoder expects 13 bits.
> > Yes, the Streamzap remote does _not_ use standard RC-5.
> > Did I mention this already? Yes. ;-)
> 
> If the remote is sending a weird protocol then there are several choices:
>   1) implement raw mode
>   2) make a Stream-Zap protocol engine (it would be a 14b version of
> RC-5). Standard RC5 engine will still reject the messages.
>   3) throw away your Stream-Zap remotes
> 
> I'd vote for #3, but #2 will probably make people happier.

Hm. Yeah, I know a few people who are quite attached to their Streamzap
remotes. I'm not a particularly big fan of it, I only got the thing off
ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
probably not the best route. But I don't know that I'm a huge fan of #2
either. Another decoder engine just for one quirky remote seems excessive,
and there's an option #4:

4) just keep passing data out to lirc by default.

Let lircd handle the default remote in this case. If you want to use
another remote that actually uses a standard protocol, and want to use
in-kernel decoding for that, its just an ir-keytable call away.

For giggles, I may tinker with implementing another decoder engine though,
if only to force myself to actually pay more attention to protocol
specifics. For the moment, I'm inclined to go ahead with the streamzap
port as it is right now, and include either an empty or not-empty, but
not-functional key table.

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


[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2010-08-02 Thread 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:Mon Aug  2 19:00:25 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14993:9652f85e688a
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328
gcc version:  i686-linux-gcc (GCC) 4.4.3
host hardware:x86_64
host os:  2.6.32.5

linux-2.6.32.6-armv5: OK
linux-2.6.33-armv5: OK
linux-2.6.34-armv5: WARNINGS
linux-2.6.35-rc1-armv5: ERRORS
linux-2.6.32.6-armv5-davinci: OK
linux-2.6.33-armv5-davinci: OK
linux-2.6.34-armv5-davinci: WARNINGS
linux-2.6.35-rc1-armv5-davinci: ERRORS
linux-2.6.32.6-armv5-ixp: WARNINGS
linux-2.6.33-armv5-ixp: WARNINGS
linux-2.6.34-armv5-ixp: WARNINGS
linux-2.6.35-rc1-armv5-ixp: ERRORS
linux-2.6.32.6-armv5-omap2: OK
linux-2.6.33-armv5-omap2: OK
linux-2.6.34-armv5-omap2: WARNINGS
linux-2.6.35-rc1-armv5-omap2: ERRORS
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.17-i686: ERRORS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.20-i686: WARNINGS
linux-2.6.26.8-i686: WARNINGS
linux-2.6.27.44-i686: WARNINGS
linux-2.6.28.10-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: WARNINGS
linux-2.6.31.12-i686: OK
linux-2.6.32.6-i686: OK
linux-2.6.33-i686: OK
linux-2.6.34-i686: WARNINGS
linux-2.6.35-rc1-i686: ERRORS
linux-2.6.32.6-m32r: OK
linux-2.6.33-m32r: OK
linux-2.6.34-m32r: WARNINGS
linux-2.6.35-rc1-m32r: ERRORS
linux-2.6.32.6-mips: OK
linux-2.6.33-mips: OK
linux-2.6.34-mips: WARNINGS
linux-2.6.35-rc1-mips: ERRORS
linux-2.6.32.6-powerpc64: OK
linux-2.6.33-powerpc64: OK
linux-2.6.34-powerpc64: WARNINGS
linux-2.6.35-rc1-powerpc64: ERRORS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.17-x86_64: ERRORS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.20-x86_64: WARNINGS
linux-2.6.26.8-x86_64: WARNINGS
linux-2.6.27.44-x86_64: WARNINGS
linux-2.6.28.10-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: WARNINGS
linux-2.6.31.12-x86_64: OK
linux-2.6.32.6-x86_64: OK
linux-2.6.33-x86_64: OK
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35-rc1-x86_64: ERRORS
linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-x86_64: WARNINGS
spec: ERRORS
spec-git: OK
sparse: ERRORS
linux-2.6.16.62-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.7-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.62-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.7-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.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: [PATCH] IR keymap: Add print button for HP OEM version of MCE remote

2010-08-02 Thread Jarod Wilson
On Sat, Jul 31, 2010 at 1:23 PM, Andy Walls  wrote:
> This patch adds a defintion for the "Print" button found on HP OEM
> versions of the MCE remote.  All of the other keys found on the HP OEM
> version of the remote match the other keys as already defined.
>
> Because, who doesn't need "remote printing", while one is sitting on the
> couch across from one's PC? ;)

Hah, nice. Most Useful Remote Button Ever.

> Signed-off-by: Andy Walls 

Acked-by: Jarod Wilson 

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


Re: [PATCH 2/7] V4L/DVB: dvb-usb: get rid of struct dvb_usb_rc_key

2010-08-02 Thread Jarod Wilson
On Sat, Jul 31, 2010 at 10:54 PM, Mauro Carvalho Chehab
 wrote:
> dvb-usb has its own IR handle code. Now that we have a Remote
> Controller subsystem, we should start using it. So, remove this
> struct, in favor of the similar struct defined at the RC subsystem.
>
> This is a big, but trivial patch. It is a 3 line delect, plus
> lots of rename on several dvb-usb files.
>
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Jarod Wilson 

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


Re: [PATCH 3/7] V4L/DVB: dvb-usb: prepare drivers for using rc-core

2010-08-02 Thread Jarod Wilson
On Sat, Jul 31, 2010 at 10:54 PM, Mauro Carvalho Chehab
 wrote:
> This is a big patch, yet trivial. It just move the RC properties
> to a separate struct, in order to prepare the dvb-usb drivers to
> use rc-core. There's no change on the behavior of the drivers.
>
> With this change, it is possible to have both legacy and rc-core
> based code inside the dvb-usb-remote, allowing a gradual migration
> to rc-core, driver per driver.
>
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Jarod Wilson 

-- 
Jarod Wilson
ja...@wilsonet.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


[GIT PULL for 2.6.36] V4L/DVB updates

2010-08-02 Thread Mauro Carvalho Chehab
Linus,

Please pull from:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
v4l_for_2.6.35

This is the LIRC pull request ;) After years of being maintained out-of-tree 
and being
merged on almost all distros, it is finally ready for its addition upstream.
The core got converted to work together with the Remote Controller subsystem, 
and one
driver got ported to it, on this series (there are more to come on a next pull 
request).
The drivers that are still waiting to be ported were at drivers/staging.

It also removes several V4L1 drivers that were replaced by gspca.

The net balance is that this series is removing 31665 lines, and adding "only" 
27791 lines. 
So, lots of cleanups.

The rest of this series are the usual improvements at V4L, DVB and RC (remote 
controllers),
including a port of two DVB drivers to use the new RC core, and a few new 
drivers.

---

The following changes since commit 9fe6206f400646a2322096b56c59891d530e8d51:

  Linux 2.6.35 (2010-08-01 15:11:14 -0700)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
v4l_for_2.6.35

Abylay Ospan (1):
  V4L/DVB: Fix kernel Oops when number of NetUP Dual DVB-S2-CI cards more 
than DVB_MAX_ADAPTERS limit

Amerigo Wang (6):
  V4L/DVB: Remove usbvideo quickcam_messenger driver
  V4L/DVB: Remove obsolete ov511 driver
  V4L/DVB: Remove obsolete w9968cf v4l1 driver
  V4L/DVB: Remove obsolete ovcamchip sensor framework
  V4L/DVB: Remove obsolete stv680 v4l1 driver
  V4L/DVB: Remove obsolete zc0301 v4l driver

Anatolij Gustschin (2):
  V4L/DVB: v4l: Add MPC5121e VIU video capture driver
  V4L/DVB: v4l2-dev: fix memory leak

Andrew Morton (1):
  V4L/DVB: "dib3000mc: reduce large stack usage" fix

Andy Walls (3):
  V4L/DVB: ivtv: Increment driver version due to firmware loading changes
  V4L/DVB: cx23885: Convert from struct card_ir to struct cx23885_ir_input 
for IR Rx
  V4L/DVB: cx23885: Convert cx23885-input to use new in kernel IR pulse 
decoders

Antti Palosaari (7):
  V4L/DVB: af9013: add support for firmware 5.1.0.0
  V4L/DVB: get_dvb_firmware: update af9015
  V4L/DVB: af9015: support for AverMedia AVerTV Volar M (A815Mac)
  V4L/DVB: af9013: program tuner before demodulator
  V4L/DVB: af9013: af9013_read_status() refactoring
  V4L/DVB: af9013: output fw version as four digit long
  V4L/DVB: af9013: fix comments

Arnd Bergmann (1):
  V4L/DVB: lirc: use unlocked_ioctl

Ben Hutchings (2):
  V4L/DVB: mantis: Select correct frontends
  V4L/DVB: lgs8gxx: remove firmware for lgs8g75

Christian Dietrich (1):
  V4L/DVB: drivers/media/video: Remove dead 
CONFIG_FB_OMAP2_FORCE_AUTO_UPDATE

Christoph Egger (1):
  V4L/DVB: remove obsolete conditionalizing on DVB_DIBCOM_DEBUG

Dan Carpenter (7):
  V4L/DVB: dvb-usb-init.c: white space changes in dvb-usb-init
  V4L/DVB: remove unneeded null check in anysee_probe()
  V4L/DVB: cpia_usb: remove unneeded variable
  V4L/DVB: media/radio: fix copy_to_user to user handling
  V4L/DVB: dvb_ca_en50221: return -EFAULT on copy_to_user errors
  V4L/DVB: media/IR: testing the wrong variable
  V4L/DVB: au0828: move dereference below sanity checks

Daniel Mack (2):
  V4L/DVB: drivers/media/dvb/dvb-usb/dib0700: fix return values
  V4L/DVB: drivers/media/dvb/dvb-usb/dib0700: CodingStyle fixes

David Härdeman (4):
  V4L/DVB: ir-core: convert mantis to not use ir-functions.c
  V4L/DVB: ir-core: convert em28xx to not use ir-functions.c
  V4L/DVB: ir-core: centralize sysfs raw decoder enabling/disabling
  V4L/DVB: ir-core: move decoding state to ir_raw_event_ctrl

David Härdeman (2):
  V4L/DVB: ir-core: partially convert cx88 to not use ir-functions.c
  V4L/DVB: ir-core: partially convert ir-kbd-i2c.c to not use ir-functions.c

Dean Anderson (1):
  V4L/DVB: s2255drv: cleanup of device structure

Devin Heitmueller (2):
  V4L/DVB: Add closed captioning support for the HVR-950q
  V4L/DVB: Fix case where fields were not at the correct start location

Dmitri Belimov (2):
  V4L/DVB: tm6000: Fix Video decoder initialization
  V4L/DVB: xc5000, rework xc_write_reg

Guennadi Liakhovetski (9):
  V4L/DVB: sh_mobile_ceu_camera: fix debugging message
  V4L/DVB: V4L2: fix sh_vou.c compile breakage: #include 
  V4L/DVB: mediabus: fix ambiguous pixel code names
  V4L/DVB: V4L2: mediabus: add 12-bit Bayer and YUV420 pixel formats
  V4L/DVB: V4L2: soc-camera: export soc-camera bus type for notifications
  V4L/DVB: V4L2: soc-camera: add a MIPI CSI-2 driver for SH-Mobile platforms
  V4L/DVB: V4L2: sh_mobile_camera_ceu: add support for CSI2
  V4L/DVB: V4L2: sh_vou: VOU does support the full PAL resolution too
  V4L/DVB: rj54n1cb0c: fix a comment in the driver

Guillaume Audirac (4):
  V4L/DVB: tda10048: fix the uncomplete function tda10048_read_ber

Re: Remote that breaks current system

2010-08-02 Thread Jon Smirl
On Mon, Aug 2, 2010 at 2:09 PM, Jarod Wilson  wrote:
> On Mon, Aug 02, 2010 at 01:13:22PM -0400, Jon Smirl wrote:
>> On Mon, Aug 2, 2010 at 12:42 PM, Christoph Bartelmus  
>> wrote:
>> > Hi!
>> >
>> > Jon Smirl "jonsm...@gmail.com" wrote:
>> > [...]
>> >>> Got one. The Streamzap PC Remote. Its 14-bit RC5. Can't get it to 
>> >>> properly
>> >>> decode in-kernel for the life of me. I got lirc_streamzap 99% of the way
>> >>> ported over the weekend, but this remote just won't decode correctly 
>> >>> w/the
>> >>> in-kernel RC5 decoder.
>> >
>> >> Manchester encoding may need a decoder that waits to get 2-3 edge
>> >> changes before deciding what the first bit. As you decode the output
>> >> is always a couple bits behind the current input data.
>> >>
>> >> You can build of a table of states
>> >> L0 S1 S0 L1  - emit a 1, move forward an edge
>> >> S0 S1 L0 L1 - emit a 0, move forward an edge
>> >>
>> >> By doing it that way you don't have to initially figure out the bit clock.
>> >>
>> >> The current decoder code may not be properly tracking the leading
>> >> zero. In Manchester encoding it is illegal for a bit to be 11 or 00.
>> >> They have to be 01 or 10. If you get a 11 or 00 bit, your decoding is
>> >> off by 1/2 a bit cycle.
>> >>
>> >> Did you note the comment that Extended RC-5 has only a single start
>> >> bit instead of two?
>> >
>> > It has nothing to do with start bits.
>> > The Streamzap remote just sends 14 (sic!) bits instead of 13.
>> > The decoder expects 13 bits.
>> > Yes, the Streamzap remote does _not_ use standard RC-5.
>> > Did I mention this already? Yes. ;-)
>>
>> If the remote is sending a weird protocol then there are several choices:
>>   1) implement raw mode
>>   2) make a Stream-Zap protocol engine (it would be a 14b version of
>> RC-5). Standard RC5 engine will still reject the messages.
>>   3) throw away your Stream-Zap remotes
>>
>> I'd vote for #3, but #2 will probably make people happier.
>
> Hm. Yeah, I know a few people who are quite attached to their Streamzap
> remotes. I'm not a particularly big fan of it, I only got the thing off
> ebay to have the hardware so I could work on the driver. :) So yeah, #3 is
> probably not the best route. But I don't know that I'm a huge fan of #2
> either. Another decoder engine just for one quirky remote seems excessive,
> and there's an option #4:
>
> 4) just keep passing data out to lirc by default.

That's a decent idea. Implement the mainstream, standard protocols in
the kernel and kick the weird stuff out to LIRC. We can avoid the
whole world of raw mode, config files, etc. Let LIRC deal with all
that. If the weird stuff gets enough users bring it in-kernel.  Maybe
StreamZap will suddenly sell a million units, you never know.

It is easy to implement a StreamZap engine. Just copy the RC5 one.
Rename everything and adjust it to require one more bit. You'll have
to modify the RC5 to wait for a bit interval (timeout) before sending
the data up. If you want to get fancy use a weak symbol in the
StrreamZap engine to tell the RC5 engine if Stream Zap is loaded. Then
you can decide to wait the extra bit interval or not.

> Let lircd handle the default remote in this case. If you want to use
> another remote that actually uses a standard protocol, and want to use
> in-kernel decoding for that, its just an ir-keytable call away.
>
> For giggles, I may tinker with implementing another decoder engine though,
> if only to force myself to actually pay more attention to protocol
> specifics. For the moment, I'm inclined to go ahead with the streamzap
> port as it is right now, and include either an empty or not-empty, but
> not-functional key table.
>
> --
> Jarod Wilson
> ja...@redhat.com
>
>



-- 
Jon Smirl
jonsm...@gmail.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: Fwd: No audio in HW Compressed MPEG2 container on HVR-1300

2010-08-02 Thread Shane Harrison
On Mon, Aug 2, 2010 at 11:59 PM, lawrence rust
 wrote:
> On Mon, 2010-08-02 at 22:19 +1200, Shane Harrison wrote:
> [snip]

>> I am not ruling out initialisation problems with the WM8775 but I do
>> always seem to get an I2S output from it that has data in it that
>> reflects the input.  However it could be the wrong variant of I2S or
>> some other configuration that isn't set right.
>
> Currently in wm8775.c line 223, R11 is set to 0x21 which is 24-bit left
> justified mode.  This is wrong, it should be i2s mode (0x22).  My patch
> correctly sets this register and also disables ALC mode which is
> irrelevant when setting input level via ALSA and can cause hiss during
> quiet sections.
>
>> Strange how eventually
>> I do get audio (albeit mixed with the TV source it appears) simply by
>> looping thru and changing input sources with v4l2-ctl.
>
> Probably switching glitches eventually hit the right data
> synchronisation format.
>
>> I note that the Nova-S doesn't have the hardware MPEG encoding
>
> Correct.
>
>>  so
>> still hoping someone can enlighten me on the audio path when using
>> that chip.
>
> When a Blackbird cx23416 MPEG encoder is fitted, i2s audio data from the
> wm8775 is routed through the cx23883.  The i2s output of the cx23883 is
> enabled by the function set_audio_finish() in cx88-tvaudio.c line 148.
> The cx23416 can accept stereo Sony I2S format audio data when quoting
> from the Conexant datasheet "running its AILR sync signal through an
> inverting flip-flop, clocked by an inverted AICKIN".
>
> -- Lawrence Rust
>
>
>
Yes we had noticed that the WM8775 was in left justified rather than
I2S and had corrected that already.

Thanks for the audio path info.  While you are on a roll, a few more questions ?
1) So do you know how the I2S input (from WM8775) is looped back to
the I2S output that is fed to the MPEG encoder?  I can only assume in
software?  I note that the driver has a comment re. using passthrough
mode in the CX2388x but actually uses normal mode which isn't a
loopback.  Hence something else must generate the I2S output source.
2)  I interpreted the following note in the CX23416 datasheet slightly
differently than you:
   "The CX23416 audio input interface is designed to work with most commonly
   available audio analog-to-digital converters (ADCs) that are
compatible with the Sony
   I2S data format. An I2S-compatible audio part can be supported
by running its AILR
   sync signal through an inverting flip-flop, clocked by an
inverted AICKIN, before
   passing it to the CX23416.
I assumed it was saying it accepted standard Sony variant but you
could connect to Philips I2S if you used a flip-flop to invert and
synchronise with the AICKIN.  I did notice that the HVR1300 board has
a footprint for an IC that is connected to the I2S outputs in some
manner.  I wondered what this was - does something need to be fitted
then to make these two devices talk directly?  I also note that the
driver sets the I2S input to be Philips (as output by the WM8775) and
the I2S output as Sony which seems like an attempt to talk directly.
A bit confused here.
3) Given I am getting audio sometimes in the MPEG2 stream, is it using
another path into the CX23416.  The idea of getting lucky on switching
glitches seems improbable on the I2S interface since once I get audio
I continue to have it until a hard reboot.  Switching glitches and
race conditions on the control interfaces being successful every so
often I could buy.

Still to try the patch - will let you know.  Unfortunately our
HVR-1300 is in the process of being swapped out since the supplier
wanted to try swapping boards first :-(

Cheers
Shane
--
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 06/10] media: Entities, pads and links enumeration

2010-08-02 Thread Hans Verkuil
On Monday 02 August 2010 16:35:54 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Sunday 01 August 2010 13:58:20 Hans Verkuil wrote:
> > On Thursday 29 July 2010 18:06:39 Laurent Pinchart wrote:
> 
> [snip]

> > For subdevs you want to return a chip ident and revision field (same as
> > VIDIOC_DBG_G_CHIP_IDENT does).
> 
> Do we still need a chip ID when we now have a name ? Keeping the chip ID 
> registry updated is painful, it would be nice if we could do away with it.

It's not that easy I think. The name of the subdev entity is set by the host
(bridge) driver and that doesn't know the exact chip ID. E.g. the audio msp3400
subdev driver actually supports dozens of msp variants. Knowing which variant
it is may actually be important information on an embedded system.

Note also that the chip ID is optional: it is only required when using the
debug ioctls to get/set registers and to obtain the chip ident.
 
> A revision field is a very good idea, I'll add it.
> 
> > Should we allow (possibly optional) names for pads? Or 'tooltip'-type
> > descriptions that can be a lot longer than 32 chars? (Just brainstorming
> > here).
> >
> > I am of course thinking of apps where the user can setup the media flow
> > using a GUI. If the driver can provide more extensive descriptions of the
> > various entities/pads, then that would make it much easier for the user to
> > experiment.
> 
> It would be nice to have, yes. Some kind of pad capabilities would be 
> interesting too.

What sort of caps do you have in mind?
 
> > Note that I also think that obtaining such detailed information might be
> > better done through separate ioctls (e.g. MEDIA_IOC_G_PAD_INFO, etc.).
> 
> I agree. So we can leave the additional pad information out for now and add 
> it 
> later if needed :-)
>  
> > What is definitely missing and *must* be added is a QUERYCAP type ioctl
> > that provides driver/versioning info.
> 
> I'll create one.
> 
> > Another thing that we need to figure out is how to tell the application
> > which audio and video nodes belong together.
> 
> What about adding a group ID field in media_entity ?

It's a possibility, but it's always a bit of a hassle in an application to
work with group IDs. I wonder if there is a more elegant method.
 
> > Not only that, but we need to be able to inform the driver how audio is
> > hooked up: through an audio loopback cable, an alsa device,
> 
> Doesn't the loopback cable connect the audio signal to audio hardware that 
> exposes an ALSA device ? How will drivers be able to tell if the user has 
> connected a loopback cable and what he has connected it to ?

If the audio is passed out from the card through a loopback cable, then the
application knows that it has to ask the user for the alsa device. It is
obviously impossible to know in advance which alsa device the card is hooked up
to.
 
> > part of an mpeg stream,
> 
> In that case there will be no audio device.
> 
> > or as a V4L2 audio device (ivtv can do that, and I think pvrusb2 does the
> > same for radio). I'm not entirely sure we want to expose that last option as
> > it is not really spec compliant.
> 
> I'm not sure either :-) Why doesn't ivtv use an ALSA device ?

With earlier firmwares the audio was out of sync with the video so you needed
timestamps to sync them up. And alsa didn't (and doesn't) support this.
 
> > Other things we may want to expose: is the video stream raw or compressed?
> 
> I think that belongs to V4L2.

V4L2 has something along these lines: VIDIOC_ENUM_FMT can set a COMPRESSED flag
when enumerating formats. After thinking about this a bit more I've come to the
conclusion that for now at least we should keep this in V4L2.
 
> > What are the default video/audio/vbi streams? (That allows an app to find
> > the default video device node if a driver has lots of them).
> 
> What about adding a __u32 flags field to media_entity, and defining a 
> MEDIA_ENTITY_FLAG_DEFAULT bit ?

I had the same idea. Not just useful for alsa, v4l and dvb nodes, but also for
IR inputs. We should look at IR as well: it is nice if you can easily discover
the IR input associated with the board.
 
> > Some of this information should perhaps be exposed through the v4l2 API,
> > but other parts definitely belong here.
> > 
> > I've not thought about this in detail, but we need to set some time aside
> > to brainstorm on how to provide this information in a logical and
> > consistent manner.
> 
> IRC ? A real meeting would be better, but the next scheduled one is in 
> November and that's a bit too far away.

If there is enough to discuss, then an interim meeting might well be useful.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
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] IR/mceusb: less generic callback name and remove cruft

2010-08-02 Thread Jarod Wilson
Signed-off-by: Jarod Wilson 
---
 drivers/media/IR/mceusb.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index 65b0738..ac6bb2c 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -427,7 +427,7 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir, 
char *buf,
}
 }
 
-static void usb_async_callback(struct urb *urb, struct pt_regs *regs)
+static void mce_async_callback(struct urb *urb, struct pt_regs *regs)
 {
struct mceusb_dev *ir;
int len;
@@ -476,7 +476,7 @@ static void mce_request_packet(struct mceusb_dev *ir,
/* outbound data */
usb_fill_int_urb(async_urb, ir->usbdev,
usb_sndintpipe(ir->usbdev, ep->bEndpointAddress),
-   async_buf, size, (usb_complete_t) usb_async_callback,
+   async_buf, size, (usb_complete_t)mce_async_callback,
ir, ep->bInterval);
memcpy(async_buf, data, size);
 
@@ -919,7 +919,6 @@ static int __devinit mceusb_dev_probe(struct usb_interface 
*intf,
struct usb_endpoint_descriptor *ep = NULL;
struct usb_endpoint_descriptor *ep_in = NULL;
struct usb_endpoint_descriptor *ep_out = NULL;
-   struct usb_host_config *config;
struct mceusb_dev *ir = NULL;
int pipe, maxp, i;
char buf[63], name[128] = "";
@@ -929,7 +928,6 @@ static int __devinit mceusb_dev_probe(struct usb_interface 
*intf,
 
dev_dbg(&intf->dev, ": %s called\n", __func__);
 
-   config = dev->actconfig;
idesc  = intf->cur_altsetting;
 
is_gen3 = usb_match_id(intf, gen3_list) ? 1 : 0;
-- 
1.7.2

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


[announce] changes on my git tree

2010-08-02 Thread Mauro Carvalho Chehab
Dear developers and users,

After merging patches directly on my git tree, I was impressed by the number
of things I discovered that I should not do when handling it ;) 
Living and learning :)

There are lots of trash there, due to the way patches get merged back from
upstream.

As reverting a patch there will break things for everybody that clones from
my tree, I decided to go to an easier way: let's start from scratch.

I've created a new tree, at:
http://git.linuxtv.org/media_tree.git

Currently, it is just a clone of Linus tree, all pointing to v2.6.35. I'll soon
be adding more patches there.

In order to avoid the same kind of troubles I had in the past, I intend to
use the following guidelines:

1) branch "master" - will have the contents of Linus tree.
2) branch "staging/2.6.35" - will have patches for the current stable kernel;
2) branch "staging/2.6.36" - will have patches for the current development 
cycle;
3) branch "staging/2.6.37" - will have patches for linux-next

On every new kernel release, I'll create another branch.

No branches will be rebased, but I won't merge from a staging branch into
master. If needed, I'll just update master to from Linus tree after having
a changeset pulled there.

As need arises, I'll be adding some development branches there with stuff that
are already accepted, but there are still pending patches that are needed before
sending that patch set upstream (for example, new internal/external API's
added, while there's no driver actually using them).

For those that already sent me pull requests, and for a few weeks, there's no
action need. I'll be manually handling the tree differences for a while. Yet,
the better is to rebase your trees using the new one as the basis.

Except when needed (like depending on a third-party patch applied on my tree), 
the better is to have your local git trees always based on master.

Cheers,
Mauro.

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


[PATCH 1/2] staging/lirc: port lirc_streamzap to ir-core

2010-08-02 Thread Jarod Wilson
This ports lirc_streamzap.c over to ir-core in-place, to be followed by
a patch moving the driver over to drivers/media/IR/streamzap.c and
enabling the proper Kconfig bits.

Presently, the in-kernel keymap doesn't work, as the stock Streamzap
remote uses an RC-5-like, but not-quite-RC-5 protocol, which the
in-kernel RC-5 decoder doesn't cope with. The remote can be used right
now with the lirc bridge driver though, and other remotes (at least an
RC-6(A) MCE remote) work perfectly with the driver.

I'll take a look at making the existing RC-5 decoder cope with this odd
duck, possibly implement another standalone decoder engine, or just
throw up my hands and say "meh, use lirc"... But the driver itself
should be perfectly sound.

Remaining items on the streamzap TODO list:
- add LIRC_SET_REC_TIMEOUT-alike support
- add LIRC_GET_M{AX,IN}_TIMEOUT-alike support
- add LIRC_GET_REC_RESOLUTION-alike support

All of the above should be trivial to add. There are patches pending to
add this support to ir-core from Maxim Levitsky, and I'll take care of
these once his patches get integrated. None of them are currently
essential though.

CC: Maxim Levitsky 
CC: Christoph Bartelmus 
Signed-off-by: Jarod Wilson 
---
 drivers/media/IR/keymaps/Makefile   |1 +
 drivers/media/IR/keymaps/rc-rc5-streamzap.c |   81 +++
 drivers/staging/lirc/lirc_streamzap.c   |  812 ---
 include/media/rc-map.h  |1 +
 4 files changed, 449 insertions(+), 446 deletions(-)
 create mode 100644 drivers/media/IR/keymaps/rc-rc5-streamzap.c

diff --git a/drivers/media/IR/keymaps/Makefile 
b/drivers/media/IR/keymaps/Makefile
index 86d3d1f..af81224 100644
--- a/drivers/media/IR/keymaps/Makefile
+++ b/drivers/media/IR/keymaps/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-purpletv.o \
rc-pv951.o \
rc-rc5-hauppauge-new.o \
+   rc-rc5-streamzap.o \
rc-rc5-tv.o \
rc-rc6-mce.o \
rc-real-audio-220-32-keys.o \
diff --git a/drivers/media/IR/keymaps/rc-rc5-streamzap.c 
b/drivers/media/IR/keymaps/rc-rc5-streamzap.c
new file mode 100644
index 000..4c19c58
--- /dev/null
+++ b/drivers/media/IR/keymaps/rc-rc5-streamzap.c
@@ -0,0 +1,81 @@
+/* rc-rc5-streamzap.c - Keytable for Streamzap PC Remote, for use
+ * with the Streamzap PC Remote IR Receiver.
+ *
+ * Copyright (c) 2010 by Jarod Wilson 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+
+static struct ir_scancode rc5_streamzap[] = {
+/*
+ * FIXME: The Streamzap remote isn't actually true RC-5, it has an extra
+ * bit in it, which presently throws the in-kernel RC-5 decoder for a loop.
+ * We either have to enhance the decoder to support it, add a new decoder,
+ * or just rely on lirc userspace decoding.
+ */
+   { 0x00, KEY_NUMERIC_0 },
+   { 0x01, KEY_NUMERIC_1 },
+   { 0x02, KEY_NUMERIC_2 },
+   { 0x03, KEY_NUMERIC_3 },
+   { 0x04, KEY_NUMERIC_4 },
+   { 0x05, KEY_NUMERIC_5 },
+   { 0x06, KEY_NUMERIC_6 },
+   { 0x07, KEY_NUMERIC_7 },
+   { 0x08, KEY_NUMERIC_8 },
+   { 0x0a, KEY_POWER },
+   { 0x0b, KEY_MUTE },
+   { 0x0c, KEY_CHANNELUP },
+   { 0x0d, KEY_VOLUMEUP },
+   { 0x0e, KEY_CHANNELDOWN },
+   { 0x0f, KEY_VOLUMEDOWN },
+   { 0x10, KEY_UP },
+   { 0x11, KEY_LEFT },
+   { 0x12, KEY_OK },
+   { 0x13, KEY_RIGHT },
+   { 0x14, KEY_DOWN },
+   { 0x15, KEY_MENU },
+   { 0x16, KEY_EXIT },
+   { 0x17, KEY_PLAY },
+   { 0x18, KEY_PAUSE },
+   { 0x19, KEY_STOP },
+   { 0x1a, KEY_BACK },
+   { 0x1b, KEY_FORWARD },
+   { 0x1c, KEY_RECORD },
+   { 0x1d, KEY_REWIND },
+   { 0x1e, KEY_FASTFORWARD },
+   { 0x20, KEY_RED },
+   { 0x21, KEY_GREEN },
+   { 0x22, KEY_YELLOW },
+   { 0x23, KEY_BLUE },
+
+};
+
+static struct rc_keymap rc5_streamzap_map = {
+   .map = {
+   .scan= rc5_streamzap,
+   .size= ARRAY_SIZE(rc5_streamzap),
+   .ir_type = IR_TYPE_RC5,
+   .name= RC_MAP_RC5_STREAMZAP,
+   }
+};
+
+static int __init init_rc_map_rc5_streamzap(void)
+{
+   return ir_register_map(&rc5_streamzap_map);
+}
+
+static void __exit exit_rc_map_rc5_streamzap(void)
+{
+   ir_unregister_map(&rc5_streamzap_map);
+}
+
+module_init(init_rc_map_rc5_streamzap)
+module_exit(exit_rc_map_rc5_streamzap)
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Jarod Wilson ");
diff --git a/drivers/staging/lirc/lirc_streamzap.c 
b/drivers/staging/lirc/lirc_streamzap.c
index 5b46ac4..058e29f 100644
--- a/drivers/staging/lirc/lirc_streamzap.c
+++ b/drivers/staging/lirc/li

[PATCH 2/2] IR: put newly ported streamzap driver in proper home

2010-08-02 Thread Jarod Wilson
Moves drivers/staging/lirc/lirc_streamzap.c to
drivers/media/IR/streamzap.c, along with making the requisite Kconfig
and Makefile changes.

Signed-off-by: Jarod Wilson 
---
 drivers/media/IR/Kconfig  |   12 +
 drivers/media/IR/Makefile |1 +
 drivers/media/IR/streamzap.c  |  741 +
 drivers/staging/lirc/Kconfig  |6 -
 drivers/staging/lirc/Makefile |1 -
 drivers/staging/lirc/lirc_streamzap.c |  741 -
 6 files changed, 754 insertions(+), 748 deletions(-)
 create mode 100644 drivers/media/IR/streamzap.c
 delete mode 100644 drivers/staging/lirc/lirc_streamzap.c

diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig
index e557ae0..19a9003 100644
--- a/drivers/media/IR/Kconfig
+++ b/drivers/media/IR/Kconfig
@@ -102,3 +102,15 @@ config IR_MCEUSB
 
   To compile this driver as a module, choose M here: the
   module will be called mceusb.
+
+config IR_STREAMZAP
+   tristate "Streamzap PC Remote IR Receiver"
+   depends on USB_ARCH_HAS_HCD
+   depends on IR_CORE
+   select USB
+   ---help---
+  Say Y here if you want to use a Streamzap PC Remote
+  Infrared Receiver.
+
+  To compile this driver as a module, choose M here: the
+  module will be called streamzap.
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index 2ae4f3a..2566fb4 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
 # stand-alone IR receivers/transmitters
 obj-$(CONFIG_IR_IMON) += imon.o
 obj-$(CONFIG_IR_MCEUSB) += mceusb.o
+obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
diff --git a/drivers/media/IR/streamzap.c b/drivers/media/IR/streamzap.c
new file mode 100644
index 000..058e29f
--- /dev/null
+++ b/drivers/media/IR/streamzap.c
@@ -0,0 +1,741 @@
+/*
+ * Streamzap Remote Control driver
+ *
+ * Copyright (c) 2005 Christoph Bartelmus 
+ * Copyright (c) 2010 Jarod Wilson 
+ *
+ * This driver was based on the work of Greg Wickham and Adrian
+ * Dewhurst. It was substantially rewritten to support correct signal
+ * gaps and now maintains a delay buffer, which is used to present
+ * consistent timing behaviour to user space applications. Without the
+ * delay buffer an ugly hack would be required in lircd, which can
+ * cause sluggish signal decoding in certain situations.
+ *
+ * Ported to in-kernel ir-core interface by Jarod Wilson
+ *
+ * This driver is based on the USB skeleton driver packaged with the
+ * kernel; copyright (C) 2001-2003 Greg Kroah-Hartman (g...@kroah.com)
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_VERSION "1.60"
+#define DRIVER_NAME"streamzap"
+#define DRIVER_DESC"Streamzap Remote Control driver"
+
+#ifdef CONFIG_USB_DEBUG
+static int debug = 1;
+#else
+static int debug;
+#endif
+
+#define USB_STREAMZAP_VENDOR_ID0x0e9c
+#define USB_STREAMZAP_PRODUCT_ID   0x
+
+/* table of devices that work with this driver */
+static struct usb_device_id streamzap_table[] = {
+   /* Streamzap Remote Control */
+   { USB_DEVICE(USB_STREAMZAP_VENDOR_ID, USB_STREAMZAP_PRODUCT_ID) },
+   /* Terminating entry */
+   { }
+};
+
+MODULE_DEVICE_TABLE(usb, streamzap_table);
+
+#define STREAMZAP_PULSE_MASK 0xf0
+#define STREAMZAP_SPACE_MASK 0x0f
+#define STREAMZAP_TIMEOUT0xff
+#define STREAMZAP_RESOLUTION 256
+
+/* number of samples buffered */
+#define SZ_BUF_LEN 128
+
+enum StreamzapDecoderState {
+   PulseSpace,
+   FullPulse,
+   FullSpace,
+   IgnorePulse
+};
+
+/* structure to hold our device specific stuff */
+struct streamzap_ir {
+
+   /* ir-core */
+   struct ir_dev_props *props;
+   struct ir_raw_event rawir;
+
+   /* core device info */
+   struct device *dev;
+   struct input_dev *idev;
+
+   /* usb */
+   struct usb_device   *usbdev;
+   struct usb_interface*interface;
+   struct usb_endpoint_descriptor *endpoint;
+   struct urb  *urb_in;
+
+   /* buffer & dma */
+   unsigned char   *buf_in;
+   dma_addr_t  dma_in;

Avermedia Avertv DVB-T Super 007 PCI (M135D)

2010-08-02 Thread lists
Hello all,

I'm interested in buying a PCI DVB-T card that is available cheaply in NZ
and is supported by Gnu/Linux and MythTV. I only need one DVB-T tuner, as I
have a dual-tuner already and our region only has three multiplexes (so
three will do everything with multirec).

The best bet that I have found so far is the Avermedia Avertv DVB-T Super
007 PCI Digital Terrestrial Television Receiver Card (M135D):
http://www.alphacity.co.nz/index.php?main_page=product_info&cPath=261&products_id=61014

Looking on the wikis:
http://www.linuxtv.org/wiki/index.php/AVerMedia_AVerTV_DVB-T_Super_007
( http://www.mythtv.org/wiki/AVerTV_DVB-T_Super_007 has virtually nothing)
"It is currently not supported under Linux. However, experimental support
exists (see below for details)."

Lower down, it says that "As of January 25, 2008: DVB-T works fine with
modules from the Mercurial (hg) repository. This is a DVB-T card only." 

I have searched Google for any update on this card, but the best that I
could find was this:
http://ubuntuforums.org/showthread.php?t=1537985

I had thought that, if the card worked fine with modules in testing back
in 2008, the drivers may have made it into the main releases by now. Have
they?

If I want to use this card with MythTV (on Mythbuntu), will I have to pull
down the Mercurial repository and compile the drivers myself from there as
set out in that ubuntuforums post?

Thanks in advance,

Aaron

--
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] staging/lirc: port lirc_streamzap to ir-core

2010-08-02 Thread Greg KH
On Mon, Aug 02, 2010 at 05:29:22PM -0400, Jarod Wilson wrote:
>  drivers/media/IR/keymaps/Makefile   |1 +

Uppercase "IR"?  Any reason why you all picked that?

Just curious.

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


Re: [PATCH 1/2] staging/lirc: port lirc_streamzap to ir-core

2010-08-02 Thread Mauro Carvalho Chehab
Em 02-08-2010 19:35, Greg KH escreveu:
> On Mon, Aug 02, 2010 at 05:29:22PM -0400, Jarod Wilson wrote:
>>  drivers/media/IR/keymaps/Makefile   |1 +
> 
> Uppercase "IR"?  Any reason why you all picked that?

Infra Red. Well, it were not probably a good idea ;)

Anyway, I intend to rename it to "rc" (for Remote Controller), change lots of 
internal structures and eventually move it to drivers/ or drivers/input, as the
idea is to use the subsystem also to other kinds of remote controllers.

I'll likely do it after finishing the merge of the pending patches, and send
upstream during this merge window. It seems better to rename during the merge
window.
> 
> Just curious.
> 
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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


RE: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface

2010-08-02 Thread Kukjin Kim
Russell King wrote:
> 
> On Mon, Aug 02, 2010 at 02:08:42PM +0200, Pawel Osciak wrote:
> > >Russell King - ARM Linux  wrote:
> > >On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote:
> > >> Well, some of them are indeed unused, but it's not an uncommon
practice in
> > >> kernel and might help future developers.
> > >
> > >On the other hand, arch/arm is getting soo big that we need to do
> > >something about this - and one solution is to avoid unnecessary
> > >definitions that we're not using.
> > >
> > >Another good idea is to put definitions along side the drivers which
> > >they're relevant to - maybe in a local driver-name.h file which
> > >driver-name.c includes, or maybe even within driver-name.c if they're
> > >not excessive.  This has the advantage of distributing the "bloat" to
> > >where its actually used, and means that the driver isn't dependent so
> > >much on arch/arm or even the SoC itself.
> > >
> > >Take a look at arch/arm/mach-vexpress/include/mach/ct-ca9x4.h and
> > >arch/arm/mach-vexpress/include/mach/motherboard.h - these are the only
> > >two files which contain platform definitions which are actually used
> > >for Versatile Express.  Compare that with
> > >arch/arm/mach-realview/include/mach/platform.h which contains lots
> > >more...
> >
> > So basically, what you and Mauro are recommending is that we move the
*.h
> > file with register definitions to drivers/media?
> 
> What I'm suggesting is what's been pretty standard in Linux for a long
> time.  Take a look at: drivers/net/3c503.[ch], or for a more recent
> driver, drivers/net/e1000/*.[ch].  Or drivers/mmc/host/mmci.[ch]
> 
I agree with Russell's opinion.
I don't want to add unnecessary(or unavailable in arch/arm) definitions in
arch/arm/*/include

> Putting definitions which are only used by one driver in
arch/arm/*/include
> is silly.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

--
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] staging/lirc: port lirc_streamzap to ir-core

2010-08-02 Thread Greg KH
On Mon, Aug 02, 2010 at 09:24:14PM -0300, Mauro Carvalho Chehab wrote:
> Em 02-08-2010 19:35, Greg KH escreveu:
> > On Mon, Aug 02, 2010 at 05:29:22PM -0400, Jarod Wilson wrote:
> >>  drivers/media/IR/keymaps/Makefile   |1 +
> > 
> > Uppercase "IR"?  Any reason why you all picked that?
> 
> Infra Red. Well, it were not probably a good idea ;)
> 
> Anyway, I intend to rename it to "rc" (for Remote Controller), change lots of 
> internal structures and eventually move it to drivers/ or drivers/input, as 
> the
> idea is to use the subsystem also to other kinds of remote controllers.
> 
> I'll likely do it after finishing the merge of the pending patches, and send
> upstream during this merge window. It seems better to rename during the merge
> window.

Renames are usually good for after -rc1 is out to help everyone sync up
better.

thanks,

greg k-h


> > 
> > Just curious.
> > 
> > greg k-h
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> Cheers,
> Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 3/6] V4L/DVB: smsusb: enable IR port for Hauppauge WinTV MiniStick

2010-08-02 Thread Mauro Carvalho Chehab
Hi Richard,

Em 02-08-2010 04:27, Richard Zidlicky escreveu:
> On Sun, Aug 01, 2010 at 05:17:18PM -0300, Mauro Carvalho Chehab wrote:
>> Add the proper gpio port for WinTV MiniStick, with the information provided
>> by Michael.
>>
>> Thanks-to: Michael Krufky 
>> Signed-off-by: Mauro Carvalho Chehab 
>>
>> diff --git a/drivers/media/dvb/siano/sms-cards.c 
>> b/drivers/media/dvb/siano/sms-cards.c
>> index cff77e2..dcde606 100644
>> --- a/drivers/media/dvb/siano/sms-cards.c
>> +++ b/drivers/media/dvb/siano/sms-cards.c
>> @@ -67,6 +67,7 @@ static struct sms_board sms_boards[] = {
>>  .board_cfg.leds_power = 26,
>>  .board_cfg.led0 = 27,
>>  .board_cfg.led1 = 28,
>> +.board_cfg.ir = 9,
>
> 
> are you sure about this?
> 
> I am using the value of 4 for the ir port and it definitely works.. confused.

I got this from a reliable source, and that worked perfectly  my with a Model 
55009 
LF Rev B1F7. What's the model of your device?

> Thanks for looking at it, will test the patches as soon as I can.

I'd appreciate if you could test those patches, as the new implementation is 
feature-rich,
as it uses the in-kernel decoders via RC subsystem.
> 
> Richard
> --
> 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

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


Re: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface

2010-08-02 Thread Kyungmin Park
On Tue, Aug 3, 2010 at 9:46 AM, Kukjin Kim  wrote:
> Russell King wrote:
>>
>> On Mon, Aug 02, 2010 at 02:08:42PM +0200, Pawel Osciak wrote:
>> > >Russell King - ARM Linux  wrote:
>> > >On Mon, Aug 02, 2010 at 12:32:20PM +0200, Pawel Osciak wrote:
>> > >> Well, some of them are indeed unused, but it's not an uncommon
> practice in
>> > >> kernel and might help future developers.
>> > >
>> > >On the other hand, arch/arm is getting soo big that we need to do
>> > >something about this - and one solution is to avoid unnecessary
>> > >definitions that we're not using.
>> > >
>> > >Another good idea is to put definitions along side the drivers which
>> > >they're relevant to - maybe in a local driver-name.h file which
>> > >driver-name.c includes, or maybe even within driver-name.c if they're
>> > >not excessive.  This has the advantage of distributing the "bloat" to
>> > >where its actually used, and means that the driver isn't dependent so
>> > >much on arch/arm or even the SoC itself.
>> > >
>> > >Take a look at arch/arm/mach-vexpress/include/mach/ct-ca9x4.h and
>> > >arch/arm/mach-vexpress/include/mach/motherboard.h - these are the only
>> > >two files which contain platform definitions which are actually used
>> > >for Versatile Express.  Compare that with
>> > >arch/arm/mach-realview/include/mach/platform.h which contains lots
>> > >more...
>> >
>> > So basically, what you and Mauro are recommending is that we move the
> *.h
>> > file with register definitions to drivers/media?
>>
>> What I'm suggesting is what's been pretty standard in Linux for a long
>> time.  Take a look at: drivers/net/3c503.[ch], or for a more recent
>> driver, drivers/net/e1000/*.[ch].  Or drivers/mmc/host/mmci.[ch]
>>
> I agree with Russell's opinion.
> I don't want to add unnecessary(or unavailable in arch/arm) definitions in
> arch/arm/*/include
>
>> Putting definitions which are only used by one driver in
> arch/arm/*/include
>> is silly.

I also happy with this method.

Thank you,
Kyungmin Park
--
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: [Q]: any DVB-S2 card which is 45MS/s capable?

2010-08-02 Thread Emmanuel

Marko Ristola a écrit :


Hi.

I have written some Mantis bandwidth related
DMA transfer optimizations on June/July this year.
They are now waiting for approval by Manu Abraham.

Those reduce CPU pressure, increasing the bandwidth
that can be received from the DVB card. 45MS/s bandwidth
support will surely benefit from those patches.

Main features:
1. Do one CPU interrupt per 16KB data instead per 4KB data.
My implementation benefits only Mantis cards.
https://patchwork.kernel.org/patch/107036/

2. Remove unnecessary big CPU overhead, when data is delivered
from the DVB card's DMA buffer into Linux kernel's DVB subsystem.
Number 2 reduces the CPU pressure by almost 50%.
This implementation benefits many other Linux supported DVB cards too.
http://patchwork.kernel.org/patch/108274/

Those helped with my older single CPU Core computer with 256-QAM,
delivering HDTV channel into the network and watching the
HDTV channel with a faster computer.

The performance bottlenecks could be seen on the
command line with "perf top".

I had to increase PCI bus latency setting into 64 too from the BIOS.
Moving DVB device into separate IRQ line with Ethernet card helped too,
because Ethernet card did an interrupt per ethernet packet.

So if the hardware can deliver 45MS/s data fast enough, software side 
can be optimized up
to some point. My patches contain the most easy major optimizations 
that I found.
If you can test some of those patches, it might help to get them into 
Linux kernel

faster.

Best regards,
Marko Ristola

OK these optimizations look like a step into the good direction. I guess 
what is also missing is a tuner which can handle that in DVB-S2, which 
does not seem obvious. The mantis card  can do that?

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


[GIT PULL REQUEST] IR and lirc updates for pre-2.6.36-rc1

2010-08-02 Thread Jarod Wilson
Hey Mauro,

First time trying this route out, so hopefully, I've gotten it
right... ;) This tree was based on the linuxtv v4l-dvb.git
staging/other branch as of the referenced commit, and should contain
all the currently pending bits I've got. I believe the two
staging/lirc fixes may already be merged (since they were to fix
specific linux-next build breakages), but I don't believe the rest
are, and as I understand it, you have handy-dandy scripts to filter
out what's already merged anyway. On with the show... Hopefully,
gmail's web ui doesn't butcher the output too badly...

The following changes since commit 520d05b87c4b631fc9c4482c989adfd45f0a549c:

  V4L/DVB: staging/lirc: CodingStyle cleanups (2010-07-27 18:44:45 -0300)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/jarod/linux-2.6-lirc.git staging

Janne Grunau (1):
  V4L/DVB: staging/lirc: fix Kconfig dependencies

Jarod Wilson (7):
  IR/imon: remove incorrect calls to input_free_device
  IR/imon: remove bad ir_input_dev use
  IR/mceusb: remove bad ir_input_dev use
  staging/lirc: fix non-CONFIG_MODULES build horkage
  IR/mceusb: less generic callback name and remove cruft
  staging/lirc: port lirc_streamzap to ir-core
  IR: put newly ported streamzap driver in proper home

 drivers/media/IR/Kconfig|   12 +
 drivers/media/IR/Makefile   |1 +
 drivers/media/IR/imon.c |   20 +-
 drivers/media/IR/keymaps/Makefile   |1 +
 drivers/media/IR/keymaps/rc-rc5-streamzap.c |   81 +++
 drivers/media/IR/mceusb.c   |   21 +-
 drivers/media/IR/streamzap.c|  741 
 drivers/staging/lirc/Kconfig|   23 +-
 drivers/staging/lirc/Makefile   |1 -
 drivers/staging/lirc/lirc_it87.c|9 +-
 drivers/staging/lirc/lirc_parallel.c|4 +-
 drivers/staging/lirc/lirc_streamzap.c   |  821 ---
 include/media/rc-map.h  |1 +
 13 files changed, 858 insertions(+), 878 deletions(-)
 create mode 100644 drivers/media/IR/keymaps/rc-rc5-streamzap.c
 create mode 100644 drivers/media/IR/streamzap.c
 delete mode 100644 drivers/staging/lirc/lirc_streamzap.c


-- 
Jarod Wilson
ja...@wilsonet.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


V4L hg tree fails to compile against latest stable kernel 2.6.35

2010-08-02 Thread VDR User
Any idea when this will be fixed?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: V4L hg tree fails to compile against latest stable kernel 2.6.35

2010-08-02 Thread VDR User
On Mon, Aug 2, 2010 at 11:36 PM, VDR User  wrote:
> Any idea when this will be fixed?

Sorry, forgot to paste in the details:

make -C /lib/modules/2.6.35.amd.080210.2/build
SUBDIRS=/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l  modules
make[2]: Entering directory `/usr/src/linux-2.6.35'
  CC [M]  /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvbdev.o
  CC [M]  /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dmxdev.o
  CC [M]  /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_demux.o
  CC [M]  /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_filter.o
  CC [M]  /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_ca_en50221.o
  CC [M]  /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_frontend.o
  CC [M]  /usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.o
/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1190:
warning: 'struct dev_mc_list' declared inside parameter list
/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1190:
warning: its scope is only this definition or declaration, which is
probably not what you want
/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c: In
function 'dvb_set_mc_filter':
/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1197:
error: dereferencing pointer to incomplete type
/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c: In
function 'wq_set_multicast_list':
/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1247:
error: 'struct net_device' has no member named 'mc_list'
/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1249:
error: dereferencing pointer to incomplete type
/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1249:
warning: left-hand operand of comma expression has no effect
/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1249:
warning: value computed is not used
/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1250:
warning: passing argument 2 of 'dvb_set_mc_filter' from incompatible
pointer type
/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.c:1190:
note: expected 'struct dev_mc_list *' but argument is of type 'struct
dev_mc_list *'
make[3]: *** [/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l/dvb_net.o]
Error 1
make[2]: *** [_module_/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l]
Error 2
make[2]: Leaving directory `/usr/src/linux-2.6.35'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/usr/local/dvb/v4l.source/v4l.20100802/v4l-dvb/v4l'
make: *** [all] Error 2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html