Re: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/

2009-12-01 Thread Patrick Boettcher

On Mon, 30 Nov 2009, Devin Heitmueller wrote:


On Mon, Nov 30, 2009 at 12:28 PM, Patrick Boettcher

- Add support for PCTV 74e (Pinnacle) + fix USB vendor IDs


Patrick,

You added the USB ID for the 74e?  Is that the result of actually
trying it with the hardware?  As far as I know, the 74e is not a
Dibcom design.


At that time I believed that the design should be a dib7770-design based 
on the list you gave in this email, which looked like a copy-paste of a 
the .inf-file of their windows driver:


http://osdir.com/ml/linux-media/2009-10/msg00598.html

No re-reading the mail, I see that you're not sure.

So another misunderstanding.

I will fix again the  hg.

thanks for the feedback.

--

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


Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-12-01 Thread Vincent McIntyre
Hi Rob

I missed your followup and tested the 'revert.diff' patch, attached
for reference.
I have been slow replying because I've been scratching my head over the results.

I used 'signaltest.pl' to test[1], which uses tzap under the hood.
Perhaps this is not the best choice, but I wanted something that I thought would
allow objective comparisons. That's trickier than I thought...
Unfortunately I only discovered last night how easy 'vlc
./channels.conf' makes doing quick visual checks. I didn't have enough
time to re-patch and test again.

My test procedure was:
 - get a baseline with tzap and signaltest.pl
 - patch, make, install. cold boot.
 - test with tzap and signaltest.pl
 - revert patch, for the moment.

I tested two kernels, and both cards. I tested all the tuners but I'll
spare you that for now.

 * 2.6.24-23-rt + v4l (c57f47cfb0e8+ tip)

   I got rather different baseline results. All channels had
significantly higher BER
   than I'd noticed before. After patching, snr on some channels
seemed a little higher
   and BER was lower. On ch9, I think snr was up and BER improved a little.

  here are the signaltest summary tables:
  without patch. usb device (dvb0) usbid db78:0fe9
 Frequency   Signal  Ber Unc
 =   
 17750 76.0 %   322.6   672.4  Seven
 191625000 76.0 %   320.2  1783.3  Nine
 21950 76.8 %   329.8  2948.2  Ten
 22650 76.9 %   296.6  4885.0  ABC
 57150 77.0 %   542.0  7529.4  SBS
 57850 77.1 %   539.5 10669.7  D44

 with patch. usb device (dvb0) usbid db78:0fe9
 Frequency   Signal  Ber Unc
 =   
 17750 76.6 % 2.3 0.0
 191625000 77.0 %   235.583.3
 21950 76.9 %   288.0   501.8
 22650 76.9 %   295.1  1416.4
 57150 77.0 %   523.4  3980.0
 57850 77.1 %   549.9  7409.4

 without patch. pcie device (dvb1) pciid db78:18ac
 Frequency   Signal  Ber Unc
 =   
 17750 71.2 % 3.1 0.0
 191625000 21.7 %   645.4   246.4
 21950 73.6 % 1.9  1632.0
 22650 73.5 % 2.8  1632.0
 57150 73.9 %13.6  2134.6
 57850 72.7 %58.2  6393.4

 with patch. pcie device (dvb1) pciid db78:18ac
 Frequency   Signal  Ber Unc
 =   
 17750 73.2 % 4.0 0.0
 191625000 74.0 %37.0 0.0
 21950 73.9 % 0.0 0.0
 22650 73.0 % 4.6 0.0
 57150 74.2 %76.7   193.6
 57850 72.8 %   213.8  4480.3


 * 2.6.31-14-generic + v4l (19c0469c02c3+ tip)
  Hard to say if I'm seeing an improvement.

before patching - adapter0 usbid db78:0fe9
Frequency   Signal  Ber Unc
=   
17750 75.5 %   293.7  1926.4
191625000 75.9 %   363.2  2993.3
21950 76.7 %   304.5  4225.8
22650 76.9 %   223.8  6153.3
57150 77.0 %   491.7  8726.0
57850 77.1 %   558.9 11787.1

adapter0 repeat usbid db78:0fe9 (not sure what happened to UNC here..)
Frequency   Signal  Ber Unc
=   
17750 75.9 %   327.9 13893.6
191625000 76.0 %   392.8 14939.0
21950 76.7 %   252.0 16052.0
22650 76.8 %   254.0 18063.1
57150 76.9 %   533.2 20644.1
57850 76.9 %   464.1 23836.8

after patching - adapter0 usbid db78:0fe9
Frequency   Signal  Ber Unc
=   
17750 76.3 % 2.5 0.0
191625000 76.8 %   227.6   119.0
21950 76.8 %   262.6   604.5
22650 76.8 %   282.7  1545.4
57150 77.0 %   486.8  3541.7
57850 77.1 %   521.5  6537.7


before patching - adapter1 pciid db78:18ac
Frequency   Signal  Ber Unc
=   
17750 

Re: [resend] radio-sf16fmi: fix mute, add SF16-FMP to texts

2009-12-01 Thread Petr Vandrovec

Ondrej Zary wrote:

Fix completely broken mute handling radio-sf16fmi.
The sound was muted immediately after tuning in KRadio.
Also fix typos and add SF16-FMP to the texts.


I do not have device anymore.  Looks OK to me.


Signed-off-by: Ondrej Zary li...@rainbow-software.org


Acked-by: Petr Vandrovec p...@vandrovec.name

To whom should I forward this (and your second patch), I did not do any 
SF16 work for 10 years (and no LKML for 3).

Thanks,
Petr



diff -urp linux-source-2.6.31-orig/drivers/media/radio/Kconfig 
linux-source-2.6.31/drivers/media/radio/Kconfig
--- linux-source-2.6.31-orig/drivers/media/radio/Kconfig2009-09-10 
00:13:59.0 +0200
+++ linux-source-2.6.31/drivers/media/radio/Kconfig 2009-11-28 
11:51:42.0 +0100
@@ -196,7 +196,7 @@ config RADIO_MAESTRO
  module will be called radio-maestro.
 
 config RADIO_SF16FMI

-   tristate SF16FMI Radio
+   tristate SF16-FMI/SF16-FMP Radio
depends on ISA  VIDEO_V4L2
---help---
  Choose Y here if you have one of these FM radio cards.  If you
diff -urp linux-source-2.6.31-orig/drivers/media/radio/radio-sf16fmi.c 
linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c
--- linux-source-2.6.31-orig/drivers/media/radio/radio-sf16fmi.c
2009-09-10 00:13:59.0 +0200
+++ linux-source-2.6.31/drivers/media/radio/radio-sf16fmi.c 2009-11-28 
11:39:35.0 +0100
@@ -1,4 +1,4 @@
-/* SF16FMI radio driver for Linux radio support
+/* SF16-FMI and SF16-FMP radio driver for Linux radio support
  * heavily based on rtrack driver...
  * (c) 1997 M. Kirkwood
  * (c) 1998 Petr Vandrovec, vandr...@vc.cvut.cz
@@ -11,7 +11,7 @@
  *
  *  Frequency control is done digitally -- ie out(port,encodefreq(95.8));
  *  No volume control - only mute/unmute - you have to use line volume
- *  control on SB-part of SF16FMI
+ *  control on SB-part of SF16-FMI/SF16-FMP
  *
  * Converted to V4L2 API by Mauro Carvalho Chehab mche...@infradead.org
  */
@@ -30,14 +30,14 @@
 #include media/v4l2-ioctl.h
 
 MODULE_AUTHOR(Petr Vandrovec, vandr...@vc.cvut.cz and M. Kirkwood);

-MODULE_DESCRIPTION(A driver for the SF16MI radio.);
+MODULE_DESCRIPTION(A driver for the SF16-FMI and SF16-FMP radio.);
 MODULE_LICENSE(GPL);
 
 static int io = -1;

 static int radio_nr = -1;
 
 module_param(io, int, 0);

-MODULE_PARM_DESC(io, I/O address of the SF16MI card (0x284 or 0x384));
+MODULE_PARM_DESC(io, I/O address of the SF16-FMI or SF16-FMP card (0x284 or 
0x384));
 module_param(radio_nr, int, 0);
 
 #define RADIO_VERSION KERNEL_VERSION(0, 0, 2)

@@ -47,7 +47,7 @@ struct fmi
struct v4l2_device v4l2_dev;
struct video_device vdev;
int io;
-   int curvol; /* 1 or 0 */
+   bool mute;
unsigned long curfreq; /* freq in kHz */
struct mutex lock;
 };
@@ -105,7 +105,7 @@ static inline int fmi_setfreq(struct fmi
outbits(8, 0xC0, fmi-io);
msleep(143);/* was schedule_timeout(HZ/7) */
mutex_unlock(fmi-lock);
-   if (fmi-curvol)
+   if (!fmi-mute)
fmi_unmute(fmi);
return 0;
 }
@@ -116,7 +116,7 @@ static inline int fmi_getsigstr(struct f
int res;
 
 	mutex_lock(fmi-lock);

-   val = fmi-curvol ? 0x08 : 0x00; /* unmute/mute */
+   val = fmi-mute ? 0x00 : 0x08;   /* mute/unmute */
outb(val, fmi-io);
outb(val | 0x10, fmi-io);
msleep(143);/* was schedule_timeout(HZ/7) */
@@ -204,7 +204,7 @@ static int vidioc_g_ctrl(struct file *fi
 
 	switch (ctrl-id) {

case V4L2_CID_AUDIO_MUTE:
-   ctrl-value = fmi-curvol;
+   ctrl-value = fmi-mute;
return 0;
}
return -EINVAL;
@@ -221,7 +221,7 @@ static int vidioc_s_ctrl(struct file *fi
fmi_mute(fmi);
else
fmi_unmute(fmi);
-   fmi-curvol = ctrl-value;
+   fmi-mute = ctrl-value;
return 0;
}
return -EINVAL;




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


Re: [PATCH 2/2 v2] soc-camera: convert to the new mediabus API

2009-12-01 Thread Hans Verkuil
On Monday 30 November 2009 15:48:24 Guennadi Liakhovetski wrote:
 On Mon, 30 Nov 2009, Hans Verkuil wrote:
  On Fri, 27 Nov 2009, Guennadi Liakhovetski wrote:
   On Fri, 27 Nov 2009, Hans Verkuil wrote:
Hi Guennadi,
   
 Convert soc-camera core and all soc-camera drivers to the new
 mediabus API. This also takes soc-camera client drivers one step
 closer to also be
 usable with generic v4l2-subdev host drivers.
   
Just a quick question:
 @@ -323,28 +309,39 @@ static int mt9m001_s_fmt(struct v4l2_subdev
 *sd, struct v4l2_format *f)
   /* No support for scaling so far, just crop. TODO: use skipping
 */ ret = mt9m001_s_crop(sd, a);
   if (!ret) {
 - pix-width = mt9m001-rect.width;
 - pix-height = mt9m001-rect.height;
 - mt9m001-fourcc = pix-pixelformat;
 + mf-width   = mt9m001-rect.width;
 + mf-height  = mt9m001-rect.height;
 + mt9m001-fmt= soc_mbus_find_datafmt(mf-code,
 + mt9m001-fmts, 
 mt9m001-num_fmts);
 + mf-colorspace  = mt9m001-fmt-colorspace;
   }

   return ret;
  }

 -static int mt9m001_try_fmt(struct v4l2_subdev *sd, struct
 v4l2_format *f)
 +static int mt9m001_try_fmt(struct v4l2_subdev *sd,
 +struct v4l2_mbus_framefmt *mf)
  {
   struct i2c_client *client = sd-priv;
   struct mt9m001 *mt9m001 = to_mt9m001(client);
 - struct v4l2_pix_format *pix = f-fmt.pix;
 + const struct soc_mbus_datafmt *fmt;

 - v4l_bound_align_image(pix-width, MT9M001_MIN_WIDTH,
 + v4l_bound_align_image(mf-width, MT9M001_MIN_WIDTH,
   MT9M001_MAX_WIDTH, 1,
 - pix-height, MT9M001_MIN_HEIGHT + mt9m001-y_skip_top,
 + mf-height, MT9M001_MIN_HEIGHT + mt9m001-y_skip_top,
   MT9M001_MAX_HEIGHT + mt9m001-y_skip_top, 0, 0);

 - if (pix-pixelformat == V4L2_PIX_FMT_SBGGR8 ||
 - pix-pixelformat == V4L2_PIX_FMT_SBGGR16)
 - pix-height = ALIGN(pix-height - 1, 2);
 + if (mt9m001-fmts == mt9m001_colour_fmts)
 + mf-height = ALIGN(mf-height - 1, 2);
 +
 + fmt = soc_mbus_find_datafmt(mf-code, mt9m001-fmts,
 + mt9m001-num_fmts);
 + if (!fmt) {
 + fmt = mt9m001-fmt;
 + mf-code = fmt-code;
 + }
 +
 + mf-colorspace  = fmt-colorspace;

   return 0;
  }
   
Why do the sensor drivers use soc_mbus_find_datafmt? They only seem
to be interested in the colorspace field, but I don't see the reason
for that. Most if not all sensors have a fixed colorspace depending
on the pixelcode, so they can just ignore the colorspace that the
caller requested and replace it with their own.
  
   Right, that's exactly what's done here. mt9m001 and mt9v022 drivers
   support different formats, depending on the exact detected or specified
   by the user model. That's why they have to search for the requested
   format in supported list. and then - yes, they just put the found
   format into user
  
   request:
 + mf-colorspace  = fmt-colorspace;
   
I didn't have time for a full review, so I might have missed
something.
 
  I looked at this more closely and I realized that I did indeed miss that
  soc_mbus_find_datafmt just searched in the pixelcode - colorspace
  mapping array.
 
  I also realized that there is no need for that data structure and
  function to be soc-camera specific. I believe I said otherwise in an
  earlier review. My apologies for that, all I can say is that I had very
  little time to do the reviews...

 No, you did not say otherwise about _these_ struct and function - they
 only appeared in v2 of the mediabus API, after you'd suggested to move
 colorspace into struct v4l2_mbus_framefmt.

  That said, there is no need for both the soc_mbus_datafmt struct and the
  soc_mbus_find_datafmt function. These can easily be replaced by something
  like this as a local function in each subdev:
 
  static enum v4l2_colorspace mt9m111_g_colorspace(enum v4l2_mbus_pixelcode
  code)
  {
  switch (code) {
  case V4L2_MBUS_FMT_YUYV:
  case V4L2_MBUS_FMT_YVYU:
  case V4L2_MBUS_FMT_UYVY:
  case V4L2_MBUS_FMT_VYUY:
  return V4L2_COLORSPACE_JPEG;
 
  case V4L2_MBUS_FMT_RGB555:
  case V4L2_MBUS_FMT_RGB565:
  case V4L2_MBUS_FMT_SBGGR8:
  case V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE:
  return V4L2_COLORSPACE_SRGB;
 
  default:
  return 0;
  }
  }
 
  So if mt9m111_g_colorspace() returns 0, then the format wasn't found.
  (Note that the compiler might give a warning for the return 0, so that
  might need some editing)
 
  Much simpler and much easier to understand.

 Drivers are 

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Gerd Hoffmann

  Hi,


The point is that for simple usage, like an user plugging his new USB stick
he just bought, he should be able to use the shipped IR without needing to
configure anything or manually calling any daemon. This currently works
with the existing drivers and it is a feature that needs to be kept.


Admittedly, LIRC is way behind when it comes to plug'n'play.


Should not be that hard to fixup.

When moving the keytable loading from kernel to userspace the kernel 
drivers have to inform userspace anyway what kind of hardware the IR 
device is, so udev can figure what keytable it should load.  A sysfs 
attribute is the way to go here I think.


lirc drivers can do the same, and lircd can startup with a reasonable 
(default) configuration.


Of course evdev and lirc subsytems/drivers should agree on which 
attributes should be defined and how they are filled.


cheers,
  Gerd
--
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 v3] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats

2009-12-01 Thread Hans Verkuil
On Monday 30 November 2009 14:49:07 Guennadi Liakhovetski wrote:
 On Mon, 30 Nov 2009, Hans Verkuil wrote:
  On Thu, 26 Nov 2009, Guennadi Liakhovetski wrote:
From 8b24c617e1ac4d324538a3eec476d48b85c2091f Mon Sep 17 00:00:00
2001
  
   From: Guennadi Liakhovetski g.liakhovet...@gmx.de
   Date: Thu, 26 Nov 2009 18:20:45 +0100
   Subject: [PATCH] v4l: add a media-bus API for configuring v4l2 subdev
   pixel and frame formats
  
   Video subdevices, like cameras, decoders, connect to video bridges over
   specialised busses. Data is being transferred over these busses in
   various formats, which only loosely correspond to fourcc codes,
   describing how video data is stored in RAM. This is not a one-to-one
   correspondence, therefore we cannot use fourcc codes to configure
   subdevice output data formats. This patch
   adds codes for several such on-the-bus formats and an API, similar to
   the familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for
   configuring those
   codes. After all users of the old API in struct v4l2_subdev_video_ops
   are converted, it will be removed. Also add helper routines to support
   generic pass-through mode for the soc-camera framework.
  
   Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
   ---
  
   v2 - v3: more comments:
  
   1. moved enum v4l2_mbus_packing, enum v4l2_mbus_order, and struct
   v4l2_mbus_pixelfmt to soc-camera specific header, renamed them into
   soc-namespace.
  
   2. commented enum v4l2_mbus_pixelcode and removed unused values.
  
   v1 - v2: addressed comments from Hans, namely:
  
   1. renamed image bus to media bus, now using mbus as a shorthand in
   function and data type names.
  
   2. made media-bus helper functions soc-camera local.
  
   3. moved colorspace from struct v4l2_mbus_pixelfmt to struct
   v4l2_mbus_framefmt.
  
   4. added documentation for data types and enums.
  
   5. added
  
V4L2_MBUS_FMT_FIXED = 1,
  
   format as the first in enum.
  
   soc-camera driver port will follow tomorrow.
  
   Thanks
   Guennadi
  
  
   drivers/media/video/Makefile   |2 +-
   drivers/media/video/soc_mediabus.c |  157
   
   include/media/soc_mediabus.h   |   84 +++
   include/media/v4l2-mediabus.h  |   59 ++
   include/media/v4l2-subdev.h|   19 -
 
  cut
 
   diff --git a/include/media/v4l2-mediabus.h
   b/include/media/v4l2-mediabus.h new file mode 100644
   index 000..359840c
   --- /dev/null
   +++ b/include/media/v4l2-mediabus.h
   @@ -0,0 +1,59 @@
   +/*
   + * Media Bus API header
   + *
   + * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de
   + *
   + * 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.
   + */
   +
   +#ifndef V4L2_MEDIABUS_H
   +#define V4L2_MEDIABUS_H
   +
   +/*
   + * These pixel codes uniquely identify data formats on the media bus.
   Mostly
   + * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0
   is + * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client
   pairs, where the
   + * data format is fixed. Additionally, 2X8 means that one pixel is
   transferred
   + * in two 8-bit samples, BE or LE specify in which order those
   samples + * should be stored in RAM, and PADHI and PADLO define
   which bits - low or
   + * high, in the incomplete high byte, are filled with padding bits.
   + */
 
  Hi Guennadi,
 
  This still needs some improvement. There are two things that need to be
  changed here:
 
  1) add the width of the data bus to the format name: so
  V4L2_MBUS_FMT_YUYV becomes _FMT_YUYV_8. This is required since I know
  several video receivers that can be programmed to use one of several data
  widths (8, 10, 12 bits per color component). Perhaps _1X8 is even better
  since that is nicely consistent with the 2X8 suffix that you already use.
  The PADHI and PADLO naming convention
  is fine and should be used whereever it is neeeded. Ditto for BE and LE.

 Ok, my first thought was no, there only very seldom will be a need for a
 different padding / order / bus-width, but the second thought was but
 if there ever will be one, you'll have to rename the original code too...

  2) Rephrase 'BE or LE specify in which order those samples should be
  stored
  in RAM' to:
 
  'BE or LE specify in which order those samples are transferred over
  the bus:
  BE means that the most significant bits are transferred first, LE means
  that the least significant bits are transferred first.'
 
  This also means that formats like RGB555 need to be renamed to
  RGB555_2X8_PADHI_LE.
 
  I think that this would make this list of pixelcodes unambiguous and
  understandable.

 Right, how about this:

 /*
  * These pixel codes uniquely identify data formats on the media bus.
 Mostly * they correspond to similarly 

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Gerd Hoffmann

  Hi,


A current related problem is that i2c based devices can only be bound to
only one of ir-kbd-i2c *or* lirc_i2c *or* lirc_zilog at any one time.
Currently it is somewhat up to the bridge driver which binding is
preferred.  Discussion about this for the pvrusb2 module had the biggest
email churn IIRC.


Once lirc_dev is merged you can easily fix this:  You'll have *one* 
driver which supports *both* evdev and lirc interfaces.  If lircd opens 
the lirc interface raw data will be sent there, keystrokes come in via 
uinput.  Otherwise keystrokes are send directly via evdev.  Problem solved.


cheers,
  Gerd

PS:  Not sure this actually makes sense for the i2c case, as far I know
 these do decoding in hardware and don't provide access to the raw
 samples, so killing the in-kernel IR limits to make ir-kbd-i2c
 being on par with lirc_i2c might be more useful in this case.

--
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 v3] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats

2009-12-01 Thread Guennadi Liakhovetski
On Tue, 1 Dec 2009, Hans Verkuil wrote:

 On Monday 30 November 2009 14:49:07 Guennadi Liakhovetski wrote:
 
  Right, how about this:
 
  /*
   * These pixel codes uniquely identify data formats on the media bus.
  Mostly * they correspond to similarly named V4L2_PIX_FMT_* formats, format
  0 is * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs,
  where the * data format is fixed. Additionally, 2X8 means that one pixel
  is transferred * in two 8-bit samples, BE or LE specify in which order
  those samples are * transferred over the bus: LE means that the least
  significant bits are * transferred first, BE means that the most
  significant bits are transferred * first, and PADHI and PADLO define
  which bits - low or high, in the * incomplete high byte, are filled with
  padding bits.
   */
  enum v4l2_mbus_pixelcode {
  V4L2_MBUS_FMT_FIXED = 1,
  V4L2_MBUS_FMT_YUYV_2X8_LE,
  V4L2_MBUS_FMT_YVYU_2X8_LE,
  V4L2_MBUS_FMT_UYVY_2X8_LE,
  V4L2_MBUS_FMT_VYUY_2X8_LE,
 
 These possibly may need a comment saying that each Y/U/V sample is 8 bits 
 wide. I'm not sure how far we want to go with systematic naming schemes here. 
 Adding a short comment if there is a possible ambiguity is probably 
 sufficient.

Is there an ambiguity? Aren't these formats standardised? Do we then have 
to explain what rgb555 means etc?

  V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
  V4L2_MBUS_FMT_RGB555X_2X8_PADHI_LE,
 
 Shouldn't this be: V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE? Since the 555X format 
 is 
 just the big-endian variant of the RGB555 if I am not mistaken.

No, don't think so. As an RGB555X format it is sent in LE order, if you 
send RGB555X in BE order you get RGB555 (without an X). In fact, you'll 
never have a RGB555X_BE format, because, that's just the RGB555_LE. So, 
you may only have BE variants for formats, whoch byte-swapped variants do 
not have an own name.

  V4L2_MBUS_FMT_RGB565_2X8_LE,
  V4L2_MBUS_FMT_RGB565X_2X8_LE,
 
 Ditto.
 
  V4L2_MBUS_FMT_SBGGR8_1X8,
  V4L2_MBUS_FMT_SBGGR10_1X10,
  V4L2_MBUS_FMT_GREY_1X8,
 
 This is also 8 bits per sample, right? This might be renamed to GREY8_1X8.

I named it after V4L2_PIX_FMT_GREY. If we ever get GREY7 or similar, I 
think, we anyway will need a new fourcc code for it, then we'll call the 
MBUS_FMT similarly.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2 v2] soc-camera: convert to the new mediabus API

2009-12-01 Thread Guennadi Liakhovetski
On Tue, 1 Dec 2009, Hans Verkuil wrote:

 On Monday 30 November 2009 15:48:24 Guennadi Liakhovetski wrote:
  On Mon, 30 Nov 2009, Hans Verkuil wrote:
   On Fri, 27 Nov 2009, Guennadi Liakhovetski wrote:
On Fri, 27 Nov 2009, Hans Verkuil wrote:
 Hi Guennadi,

  Convert soc-camera core and all soc-camera drivers to the new
  mediabus API. This also takes soc-camera client drivers one step
  closer to also be
  usable with generic v4l2-subdev host drivers.

 Just a quick question:
  @@ -323,28 +309,39 @@ static int mt9m001_s_fmt(struct v4l2_subdev
  *sd, struct v4l2_format *f)
  /* No support for scaling so far, just crop. TODO: use skipping
  */ ret = mt9m001_s_crop(sd, a);
  if (!ret) {
  -   pix-width = mt9m001-rect.width;
  -   pix-height = mt9m001-rect.height;
  -   mt9m001-fourcc = pix-pixelformat;
  +   mf-width   = mt9m001-rect.width;
  +   mf-height  = mt9m001-rect.height;
  +   mt9m001-fmt= soc_mbus_find_datafmt(mf-code,
  +   mt9m001-fmts, 
  mt9m001-num_fmts);
  +   mf-colorspace  = mt9m001-fmt-colorspace;
  }
 
  return ret;
   }
 
  -static int mt9m001_try_fmt(struct v4l2_subdev *sd, struct
  v4l2_format *f)
  +static int mt9m001_try_fmt(struct v4l2_subdev *sd,
  +  struct v4l2_mbus_framefmt *mf)
   {
  struct i2c_client *client = sd-priv;
  struct mt9m001 *mt9m001 = to_mt9m001(client);
  -   struct v4l2_pix_format *pix = f-fmt.pix;
  +   const struct soc_mbus_datafmt *fmt;
 
  -   v4l_bound_align_image(pix-width, MT9M001_MIN_WIDTH,
  +   v4l_bound_align_image(mf-width, MT9M001_MIN_WIDTH,
  MT9M001_MAX_WIDTH, 1,
  -   pix-height, MT9M001_MIN_HEIGHT + mt9m001-y_skip_top,
  +   mf-height, MT9M001_MIN_HEIGHT + mt9m001-y_skip_top,
  MT9M001_MAX_HEIGHT + mt9m001-y_skip_top, 0, 0);
 
  -   if (pix-pixelformat == V4L2_PIX_FMT_SBGGR8 ||
  -   pix-pixelformat == V4L2_PIX_FMT_SBGGR16)
  -   pix-height = ALIGN(pix-height - 1, 2);
  +   if (mt9m001-fmts == mt9m001_colour_fmts)
  +   mf-height = ALIGN(mf-height - 1, 2);
  +
  +   fmt = soc_mbus_find_datafmt(mf-code, mt9m001-fmts,
  +   mt9m001-num_fmts);
  +   if (!fmt) {
  +   fmt = mt9m001-fmt;
  +   mf-code = fmt-code;
  +   }
  +
  +   mf-colorspace  = fmt-colorspace;
 
  return 0;
   }

 Why do the sensor drivers use soc_mbus_find_datafmt? They only seem
 to be interested in the colorspace field, but I don't see the reason
 for that. Most if not all sensors have a fixed colorspace depending
 on the pixelcode, so they can just ignore the colorspace that the
 caller requested and replace it with their own.
   
Right, that's exactly what's done here. mt9m001 and mt9v022 drivers
support different formats, depending on the exact detected or specified
by the user model. That's why they have to search for the requested
format in supported list. and then - yes, they just put the found
format into user
   
request:
  +   mf-colorspace  = fmt-colorspace;

 I didn't have time for a full review, so I might have missed
 something.
  
   I looked at this more closely and I realized that I did indeed miss that
   soc_mbus_find_datafmt just searched in the pixelcode - colorspace
   mapping array.
  
   I also realized that there is no need for that data structure and
   function to be soc-camera specific. I believe I said otherwise in an
   earlier review. My apologies for that, all I can say is that I had very
   little time to do the reviews...
 
  No, you did not say otherwise about _these_ struct and function - they
  only appeared in v2 of the mediabus API, after you'd suggested to move
  colorspace into struct v4l2_mbus_framefmt.
 
   That said, there is no need for both the soc_mbus_datafmt struct and the
   soc_mbus_find_datafmt function. These can easily be replaced by something
   like this as a local function in each subdev:
  
   static enum v4l2_colorspace mt9m111_g_colorspace(enum v4l2_mbus_pixelcode
   code)
   {
 switch (code) {
 case V4L2_MBUS_FMT_YUYV:
 case V4L2_MBUS_FMT_YVYU:
 case V4L2_MBUS_FMT_UYVY:
 case V4L2_MBUS_FMT_VYUY:
 return V4L2_COLORSPACE_JPEG;
  
 case V4L2_MBUS_FMT_RGB555:
 case V4L2_MBUS_FMT_RGB565:
 case V4L2_MBUS_FMT_SBGGR8:
 case V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE:
 return V4L2_COLORSPACE_SRGB;
  
 default:
 return 0;
 }
   }
  
   So if mt9m111_g_colorspace() returns 0, then the format wasn't found.
   (Note that the compiler might give a warning for the return 0, so that
   might need some 

Re: [PATCH] usbvideo: limit the length of string creation

2009-12-01 Thread Laurent Pinchart
On Saturday 21 November 2009 18:02:56 Németh Márton wrote:
 From: Márton Németh nm...@freemail.hu
 
 Use strlcat() to append a string to the previously created first part.
 The strlcat() function limits the size of the string to the whole
 destination buffer.
 
 The semantic match that finds this kind of problem is as follows:
 (http://coccinelle.lip6.fr/)
 
 // smpl
 @@
 expression dev;
 expression phys;
 expression str;
 expression size;
 @@
   usb_make_path(dev, phys, size);
 - strncat(phys, str, size);
 + strlcat(phys, str, size);
 // /smpl
 
 Signed-off-by: Márton Németh nm...@freemail.hu

Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com

-- 
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Andy Walls
On Tue, 2009-12-01 at 08:45 +0100, Christoph Bartelmus wrote:
 Hi Jon,
 
 on 30 Nov 09 at 16:35, Jon Smirl wrote:


 Currently I would tend to an approach like this:
 - raw interface to userspace using LIRC
 - fixed set of in-kernel decoders that can handle bundled remotes
 
 That would allow zero configuration for simple use cases and full  
 flexibility for more advanced use cases.
 
 Christoph

I'd also prefer that approach.

That probably comes as no surprise, but I may not be able to keep
following/kibitzing in this thread. Christoph's statement sums up my
preference.

Regards,
Andy

--
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: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-12-01 Thread Robert Lowery
 Hi Rob

 I missed your followup and tested the 'revert.diff' patch, attached
 for reference.
 I have been slow replying because I've been scratching my head over the
 results.

 I used 'signaltest.pl' to test[1], which uses tzap under the hood.
 Perhaps this is not the best choice, but I wanted something that I thought
 would
 allow objective comparisons. That's trickier than I thought...
 Unfortunately I only discovered last night how easy 'vlc
 ./channels.conf' makes doing quick visual checks. I didn't have enough
 time to re-patch and test again.

 My test procedure was:
  - get a baseline with tzap and signaltest.pl
  - patch, make, install. cold boot.
  - test with tzap and signaltest.pl
  - revert patch, for the moment.

 I tested two kernels, and both cards. I tested all the tuners but I'll
 spare you that for now.

  * 2.6.24-23-rt + v4l (c57f47cfb0e8+ tip)

I got rather different baseline results. All channels had
 significantly higher BER
than I'd noticed before. After patching, snr on some channels
 seemed a little higher
and BER was lower. On ch9, I think snr was up and BER improved a
 little.

   here are the signaltest summary tables:
   without patch. usb device (dvb0) usbid db78:0fe9
  Frequency   Signal  Ber Unc
  =   
  17750 76.0 %   322.6   672.4  Seven
  191625000 76.0 %   320.2  1783.3  Nine
  21950 76.8 %   329.8  2948.2  Ten
  22650 76.9 %   296.6  4885.0  ABC
  57150 77.0 %   542.0  7529.4  SBS
  57850 77.1 %   539.5 10669.7  D44

  with patch. usb device (dvb0) usbid db78:0fe9
  Frequency   Signal  Ber Unc
  =   
  17750 76.6 % 2.3 0.0
  191625000 77.0 %   235.583.3
  21950 76.9 %   288.0   501.8
  22650 76.9 %   295.1  1416.4
  57150 77.0 %   523.4  3980.0
  57850 77.1 %   549.9  7409.4

  without patch. pcie device (dvb1) pciid db78:18ac
  Frequency   Signal  Ber Unc
  =   
  17750 71.2 % 3.1 0.0
  191625000 21.7 %   645.4   246.4
  21950 73.6 % 1.9  1632.0
  22650 73.5 % 2.8  1632.0
  57150 73.9 %13.6  2134.6
  57850 72.7 %58.2  6393.4

  with patch. pcie device (dvb1) pciid db78:18ac
  Frequency   Signal  Ber Unc
  =   
  17750 73.2 % 4.0 0.0
  191625000 74.0 %37.0 0.0
  21950 73.9 % 0.0 0.0
  22650 73.0 % 4.6 0.0
  57150 74.2 %76.7   193.6
  57850 72.8 %   213.8  4480.3


  * 2.6.31-14-generic + v4l (19c0469c02c3+ tip)
   Hard to say if I'm seeing an improvement.

 before patching - adapter0 usbid db78:0fe9
 Frequency   Signal  Ber Unc
 =   
 17750 75.5 %   293.7  1926.4
 191625000 75.9 %   363.2  2993.3
 21950 76.7 %   304.5  4225.8
 22650 76.9 %   223.8  6153.3
 57150 77.0 %   491.7  8726.0
 57850 77.1 %   558.9 11787.1

 adapter0 repeat usbid db78:0fe9 (not sure what happened to UNC here..)
 Frequency   Signal  Ber Unc
 =   
 17750 75.9 %   327.9 13893.6
 191625000 76.0 %   392.8 14939.0
 21950 76.7 %   252.0 16052.0
 22650 76.8 %   254.0 18063.1
 57150 76.9 %   533.2 20644.1
 57850 76.9 %   464.1 23836.8

 after patching - adapter0 usbid db78:0fe9
 Frequency   Signal  Ber Unc
 =   
 17750 76.3 % 2.5 0.0
 191625000 76.8 %   227.6   119.0
 21950 76.8 %   262.6   604.5
 22650 76.8 %   282.7  1545.4
 57150 77.0 %   486.8  3541.7
 57850 77.1 %   521.5  6537.7


 before patching - adapter1 pciid db78:18ac
 Frequency   Signal  

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Mauro Carvalho Chehab
Gerd Hoffmann wrote:
 On 11/30/09 13:34, Mauro Carvalho Chehab wrote:
 Christoph Bartelmus wrote:
 Hi Mauro,

 I just don't want to change a working interface just because it could be
 also implemented in a different way, but having no other visible
 advantage
 than using more recent kernel features.

 I agree. The main reasons to review the interface is:
 1) to avoid any overlaps (if are there any) with the evdev interface;
 
 Use lirc for raw samples.
 Use evdev for decoded data.
 
 Hardware/drivers which can handle both can support both interfaces.
 IMHO it makes no sense at all to squeeze raw samples through the input
 layer.  It looks more like a serial line than a input device.  In fact
 you can homebrew a receiver and connect it to the serial port, which was
 quite common in pre-usb-ir-receiver times.

I agree. 
 
 2) to have it stable enough to be used, without changes, for a long
time.
 
 It isn't like lirc is a new interface.  It has been used in practice for
 years.  I don't think API stability is a problem here.

You're probably right here, but, as, currently, changing the API is not a 
problem,
I don't doubt that the API has changed during those years (I haven't followed
lirc API, so this is just an educated guess).

So, all I'm saying is that we should do a final review considering API stability
before merging it, eventually considering to add a few reserved fields there, if
we suspect that we might need more space for some reason.

 True, but even if we want to merge lirc drivers as-is, the drivers will
 still need changes, due to kernel CodingStyle, due to the usage of
 some API's
 that may be deprecated, due to some breakage with non-Intel
 architectures, due
 to some bugs that kernel hackers may discover, etc.
 
 I assumed this did happen in already in preparation of this submission?

Yes, for just a few drivers that went on the first series of patches (on Jerod's
proposal, only 2 drivers were submitted).

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: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Gerd Hoffmann

On 12/01/09 12:49, Andy Walls wrote:

On Tue, 2009-12-01 at 11:46 +0100, Gerd Hoffmann wrote:

Once lirc_dev is merged you can easily fix this:  You'll have *one*
driver which supports *both* evdev and lirc interfaces.  If lircd opens
the lirc interface raw data will be sent there, keystrokes come in via
uinput.  Otherwise keystrokes are send directly via evdev.  Problem solved.


This will be kind of strange for lirc_zilog (aka lirc_pvr150).  It
supports IR transmit on the PVR-150, HVR-1600, and HD-PVR.  I don't know
if transmit is raw pulse timings, but I'm sure the unit provides codes
on receive.  Occasionally blocks of boot data need to be programmed
into the transmitter side.  I suspect lirc_zilog will likely need
rework


Well, for IR *output* it doesn't make sense to disable evdev.  One more 
reason which indicates it probaably is better to introduce a ioctl to 
disable evdev reporting.  lircd will probably turn it off, especially 
when sending data to uevent.  debug tools might not, likewise apps 
sending IR.



  so killing the in-kernel IR limits to make ir-kbd-i2c

   ^^^

   being on par with lirc_i2c might be more useful in this case.


I didn't quite understand that.  Can you provide a little more info?


Such as throwing away the address part of rc5 codes ...

cheers,
  Gerd
--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Maxim Levitsky
On Tue, 2009-12-01 at 06:38 -0500, Andy Walls wrote: 
 On Tue, 2009-12-01 at 08:45 +0100, Christoph Bartelmus wrote:
  Hi Jon,
  
  on 30 Nov 09 at 16:35, Jon Smirl wrote:
 
 
  Currently I would tend to an approach like this:
  - raw interface to userspace using LIRC
  - fixed set of in-kernel decoders that can handle bundled remotes
  
  That would allow zero configuration for simple use cases and full  
  flexibility for more advanced use cases.
  
  Christoph
 
 I'd also prefer that approach.

I also agree with this approach.
This way, there will be no need for configfs hacks, but just static
table for bundled remotes, and in fact this is very clean approach.
Also, since bundled remotes use standard protocols, there will be no
problem to add decoders for them.

For the rest, the remotes that were never meant to be used with the
computer, lircd will do just fine.

So, it a deal?

Best regards,
Maxim Levitsky



--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Mauro Carvalho Chehab
Gerd Hoffmann wrote:
   Hi,
 
 The point is that for simple usage, like an user plugging his new USB
 stick
 he just bought, he should be able to use the shipped IR without
 needing to
 configure anything or manually calling any daemon. This currently works
 with the existing drivers and it is a feature that needs to be kept.

 Admittedly, LIRC is way behind when it comes to plug'n'play.
 
 Should not be that hard to fixup.
 
 When moving the keytable loading from kernel to userspace the kernel
 drivers have to inform userspace anyway what kind of hardware the IR
 device is, so udev can figure what keytable it should load.  A sysfs
 attribute is the way to go here I think.
 
 lirc drivers can do the same, and lircd can startup with a reasonable
 (default) configuration.
 
 Of course evdev and lirc subsytems/drivers should agree on which
 attributes should be defined and how they are filled.

Yes, a sysfs attribute seems appropriate in this case.

This is the attributes that are currently available via sysfs:

  looking at device '/class/input/input13/event5':
KERNEL==event5
SUBSYSTEM==input
SYSFS{dev}==13:69

  looking at parent device '/class/input/input13':
ID==input13
BUS==input
DRIVER==
SYSFS{name}==em28xx IR _em28xx #0_
SYSFS{phys}==usb-:00:1d.7-8/input0
SYSFS{uniq}==

For the currently used attributes, we have:

The name attribute. If we do some effort to standardize it, it could be an 
option.
However, on several drivers, this attribute is filled with something that is 
generic
for the entire driver, and on several cases like the above, it adds a device 
number. 

The phys attribute has to do only with the bus address. Btw, the lirc drivers 
need
to follow the conventions here. We did a great effort at 2.6.30 or 2.6.31 to 
standardize
the phys attribute, as some drivers were using different conventions for it.

The uniq attribute is meant to be used as a serial number (no driver seems to 
use
it currently, from my tests with git grep).

By looking on other subsystems, ALSA defines two name attributes: a shortname 
and a longname.

The current board naming schema at the V4L drivers are a long name. For example:
Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker

The rationale is that they should be user-friendly.

Maybe a similar concept could be used here: we can add a sort of shortname 
string
that will uniquely describe a device and will have a rule to describe them 
unically.

For example, the above device is a Hauppauge HVR950 usb stick, that is supported
by em28xx driver.

We may call it as EM28xxHVR950-00 (the last 2 chars is to allow having board 
revisions, 
as some devices may have more than one variant).

Another alternative would be to create an integer SYSFS atribute and use some 
rule to
associate the device number with the driver.

The big issue here is: how do we document that EM28xxHVR950-00 is the 
Hauppauge Grey IR that
is shipped with their newer devices.

A third approach would be to identify, instead, the Remote Controller directly. 
So, we would
add a sysfs field like ir_type.

There are two issues here:
1) What's the name for this IR? We'll need to invent names for the 
existing IR's, as
those devices don't have a known brand name;
2) there are cases where the same device is provided with two or more 
different IR
types. If we identify the board type instead of the IR type, userspace can 
better handle
it, by providing a list of the possibilities.

---

No matter how we map, we'll still need to document it somehow to userspace. 
What would be
the better? A header file? A set of keymaps from the default IR's that will be 
added
on some directory at the Linux tree? A Documentation/IR ?

I'm for having the keymaps on some file at the kernel tree, maybe at 
Documentation/IR,
but this is just my 2 cents. We need to think more about that.

Comments?

Anyway, we shouldn't postpone lirc drivers addition due to that. There are 
still lots of work
to do before we'll be able to split the tables from the kernel drivers.

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: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Mauro Carvalho Chehab
Gerd Hoffmann wrote:
 On 12/01/09 12:49, Andy Walls wrote:
 On Tue, 2009-12-01 at 11:46 +0100, Gerd Hoffmann wrote:
 Once lirc_dev is merged you can easily fix this:  You'll have *one*
 driver which supports *both* evdev and lirc interfaces.  If lircd opens
 the lirc interface raw data will be sent there, keystrokes come in via
 uinput.  Otherwise keystrokes are send directly via evdev.  Problem
 solved.

 This will be kind of strange for lirc_zilog (aka lirc_pvr150).  It
 supports IR transmit on the PVR-150, HVR-1600, and HD-PVR.  I don't know
 if transmit is raw pulse timings, but I'm sure the unit provides codes
 on receive.  Occasionally blocks of boot data need to be programmed
 into the transmitter side.  I suspect lirc_zilog will likely need
 rework
 
 Well, for IR *output* it doesn't make sense to disable evdev.  One more
 reason which indicates it probaably is better to introduce a ioctl to
 disable evdev reporting.  lircd will probably turn it off, especially
 when sending data to uevent.  debug tools might not, likewise apps
 sending IR.
 
   so killing the in-kernel IR limits to make ir-kbd-i2c
^^^
being on par with lirc_i2c might be more useful in this case.

 I didn't quite understand that.  Can you provide a little more info?
 
 Such as throwing away the address part of rc5 codes ...

This limit were already removed from the subsystem core by the patches
I committed recently (still only at the devel tree - I should be adding
those patches to my linux-next tree likely today). 

The remaining issue is that we'll need to re-scan the IR tables for 
every supported remote to be sure that we're getting the full RC5 code.
It is not complex, but requires lots of work from people that actually have
those IR's.

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: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Jarod Wilson
On Dec 1, 2009, at 4:52 AM, Gerd Hoffmann wrote:

 On 11/30/09 13:34, Mauro Carvalho Chehab wrote:
 Christoph Bartelmus wrote:
 Hi Mauro,
 
 I just don't want to change a working interface just because it could be
 also implemented in a different way, but having no other visible advantage
 than using more recent kernel features.
 
 I agree. The main reasons to review the interface is:
  1) to avoid any overlaps (if are there any) with the evdev interface;
 
 Use lirc for raw samples.
 Use evdev for decoded data.

This is the approach I'm pretty well settled on wanting to take myself.

 Hardware/drivers which can handle both can support both interfaces.

Exactly.

 IMHO it makes no sense at all to squeeze raw samples through the input layer. 
  It looks more like a serial line than a input device.  In fact you can 
 homebrew a receiver and connect it to the serial port, which was quite common 
 in pre-usb-ir-receiver times.
 
  2) to have it stable enough to be used, without changes, for a long
 time.
 
 It isn't like lirc is a new interface.  It has been used in practice for 
 years.  I don't think API stability is a problem here.

Yeah, in the ~3 years I've been maintaining lirc patches for the Fedora 
kernels, only once has something happened where new userspace could no longer 
talk to old kernelspace. The majority of the work has been keeping things 
running as kernel interfaces change -- the 2.6.31 i2c changes are still biting 
us, as some capture card devices lagged behind a bit on converting to the new 
i2c scheme, making it impossible for lirc_i2c and/or lirc_zilog to bind (and 
ir-kbd-i2c, for that matter).

 True, but even if we want to merge lirc drivers as-is, the drivers will
 still need changes, due to kernel CodingStyle, due to the usage of some API's
 that may be deprecated, due to some breakage with non-Intel architectures, 
 due
 to some bugs that kernel hackers may discover, etc.
 
 I assumed this did happen in already in preparation of this submission?

Yes. There may still be a bit of work to do here, but there was a crew of us 
about a year, year and a half ago, that did a major sweep through all the lirc 
drivers, reformatting things so that we were at least mostly checkpatch-clean. 
The original lirc patches I put into the Fedora Core 6 kernel had several 
thousand lines of warnings and errors, while with the current lirc patches in 
Fedora 12, I get:

total: 1 errors, 12 warnings, 15987 lines checked

The error is new, hadn't seen that one before, going to fix it now... :) The 
warnings are almost all the same thing, WARNING: struct file_operations should 
normally be const, need to fix that too, though we actually do edit the 
lirc_fops on a per-device basis right now, so they can't be const...

Okay, the error and one of the warnings are gone from my local tree, now its 
all just the above.

But yeah, for the most part, I think the coding style and formatting of the 
lirc drivers *does* look like kernel code these days, minor fixages suggested 
in Mauro's review aside. I submitted only a 3-part series (lirc_dev, 
lirc_mceusb and lirc_imon) to keep from overwhelming anyone (myself included) 
with too much code at once, and went with the two device drivers that I've 
personally done the most work on and have several devices driven by (which 
includes the IR parts I've been using in my production MythTV setup for years 
now).

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


[RFC v2] Another approach to IR

2009-12-01 Thread Jon Smirl
While reading all of these IR threads another way of handling IR
occurred to me that pretty much eliminates the need for LIRC and
configuration files in default cases. The best way to make everything
just work is to eliminate it.

The first observation is that the IR profile of various devices are
well known. Most devices profiles are in the published One-for-All
database. These device profiles consist of vendor/device/command
triplets. There is one triplet for each command like play, pause, 1,
2, 3, power, etc.

The second observation is that universal remotes know how to generate
commands for all of the common devices.

Let's define evdev messages for IR than contain vendor/device/command
triplets. I already posted code for doing that in my original patch
set. These messages are generated from in-kernel code.

Now add a small amount of code to MythTV, etc to act on these evdev
messages. Default MythTV, etc to respond to the IR commands for a
common DVR device. Program your universal remote to send the commands
for this device. You're done. Everything will just work - no LIRC,
no irrecord, no config files, no command mapping, etc.

Of course there are details involved in making this work. MythTV will
have to have a config option to allow it to emulate several different
DVR devices so that you can pick one that you don't own. It should
also have choices for emulating the common devices defined for the
remotes included with various Linux video board like the Hauppauge
remote.

For apps that haven't been modified you will have to run a daemon
which will capture vendor/device/command evdev events and convert them
into keystroke commands than work the menus. You'll need a config file
for this and have to write scripts. Instead I'd just go modify the app
the respond to the IR events, it is easy to do.

Long run, we define a MythTV IR profile, mplayer profile, etc and get
these into the IR database for universal remotes. Now MythTV can stop
emulating another vendor's device.

For the default MythTV case no external support will need to be
installed if the protocol decode engines are in the kernel. The raw
data will come in, run through the engines, and pop out as evdev
messages with a vendor/device/command triplet. Devices that decode in
hardware will just send vendor/device/command triplets.

-- 
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: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/

2009-12-01 Thread Patrick Boettcher

Hi again,

On Mon, 30 Nov 2009, Devin Heitmueller wrote:


On Mon, Nov 30, 2009 at 12:28 PM, Patrick Boettcher

- Add support for PCTV 74e (Pinnacle) + fix USB vendor IDs


Patrick,

You added the USB ID for the 74e?  Is that the result of actually
trying it with the hardware?  As far as I know, the 74e is not a
Dibcom design.


You are right, the device is an Abilis design, where, as far as I know, no 
Linux or GPL driver is yet written or available.


Mauro: I added a patch which removes the USB IDs to my repository. The 
repo is now ready to be pulled.


thanks,
--

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


Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-01 Thread Gerd Hoffmann

  Hi,


The big issue here is: how do we document that EM28xxHVR950-00 is the 
Hauppauge Grey IR that
is shipped with their newer devices.



A third approach would be to identify, instead, the Remote Controller directly. 
So, we would
add a sysfs field like ir_type.


I'd pick a more descriptive name like 'bundled_remote'.
Maybe an additional attribute could say which protocol the bundled 
remote speaks (rc5, ...), so userspace could do something sensible by 
default even if it has no data about the bundled remote.



There are two issues here:
1) What's the name for this IR? We'll need to invent names for the 
existing IR's, as
those devices don't have a known brand name;


Name them by the hardware they are bundled with should work reasonable well.


2) there are cases where the same device is provided with two or more 
different IR
types. If we identify the board type instead of the IR type, userspace can 
better handle
it, by providing a list of the possibilities.


We also could also provide a list of possible remotes directly via sysfs 
instead of expecting userspace know which remotes can come bundled with 
which board.



No matter how we map, we'll still need to document it somehow to userspace. 
What would be
the better? A header file? A set of keymaps from the default IR's that will be 
added
on some directory at the Linux tree? A Documentation/IR ?


I'd suggest tools/ir/ (map loader intended to be called by udev) and the 
maps being files in the linux source tree (next to the drivers?).  The 
maps probably should be installed on some standard location (pretty much 
like firmware).



Anyway, we shouldn't postpone lirc drivers addition due to that. There are 
still lots of work
to do before we'll be able to split the tables from the kernel drivers.


Indeed.  The sysfs bits are future work for both lirc and evdev drivers. 
 There is no reason to make the lirc merge wait for it.


cheers,
  Gerd
--
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] bttv: fix MODULE_PARM_DESC for i2c_debug and i2c_hw

2009-12-01 Thread Jarod Wilson
Currently, i2c_debug shows up w/o a desc in modinfo, and i2c_hw shows
up with i2c_debug's desc. Fix that.

Signed-off-by: Jarod Wilson ja...@redhat.com

diff -r e0cd9a337600 linux/drivers/media/video/bt8xx/bttv-i2c.c
--- a/linux/drivers/media/video/bt8xx/bttv-i2c.cSun Nov 29 12:08:02 
2009 -0200
+++ b/linux/drivers/media/video/bt8xx/bttv-i2c.cTue Dec 01 10:23:54 
2009 -0500
@@ -40,7 +40,7 @@
 static int i2c_hw;
 static int i2c_scan;
 module_param(i2c_debug, int, 0644);
-MODULE_PARM_DESC(i2c_hw,configure i2c debug level);
+MODULE_PARM_DESC(i2c_debug,configure i2c debug level);
 module_param(i2c_hw,int, 0444);
 MODULE_PARM_DESC(i2c_hw,force use of hardware i2c support, 
instead of software bitbang);
--
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] V4L - Fix videobuf_dma_contig_user_get() getting page aligned physical address

2009-12-01 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

If a USERPTR address that is not aligned to page boundary is passed to the
videobuf_dma_contig_user_get() function, it saves a page aligned address to
the dma_handle. This is not correct. This issue is observed when using USERPTR
IO machism for buffer exchange.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next branch
 drivers/media/video/videobuf-dma-contig.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/videobuf-dma-contig.c 
b/drivers/media/video/videobuf-dma-contig.c
index d25f284..928dfa1 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -166,7 +166,8 @@ static int videobuf_dma_contig_user_get(struct 
videobuf_dma_contig_memory *mem,
break;
 
if (pages_done == 0)
-   mem-dma_handle = this_pfn  PAGE_SHIFT;
+   mem-dma_handle = (this_pfn  PAGE_SHIFT) +
+   (vb-baddr  ~PAGE_MASK);
else if (this_pfn != (prev_pfn + 1))
ret = -EFAULT;
 
-- 
1.6.0.4

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


[PATCH] gspca: implement vidioc_enum_frameintervals

2009-12-01 Thread Antonio Ospite
Some drivers support multiple frameintervals (framerates), make gspca able to
enumerate them.

Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---
Changes since the initial RFC version:
 - 'i' is now a __u32 and the variable 'index' has been dropped.
 - some more comments in gspca.h

Thanks to Hans de Goede for the review.

For now I am postponing the patch to ov534 which uses this one, because I am
verifying what the actual framerates supported by the subdriver are.

Thanks,
   Antonio Ospite

diff -r 39c1be9a2ff8 -r ef8cca705478 linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c   Tue Dec 01 11:20:34 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c   Tue Dec 01 13:15:39 2009 +0100
@@ -998,6 +998,34 @@
return -EINVAL;
 }
 
+static int vidioc_enum_frameintervals(struct file *filp, void *priv,
+ struct v4l2_frmivalenum *fival)
+{
+   struct gspca_dev *gspca_dev = priv;
+   int mode = wxh_to_mode(gspca_dev, fival-width, fival-height);
+   __u32 i;
+
+   if (gspca_dev-cam.mode_framerates == NULL ||
+   gspca_dev-cam.mode_framerates[mode].nrates == 0)
+   return -EINVAL;
+
+   if (fival-pixel_format !=
+   gspca_dev-cam.cam_mode[mode].pixelformat)
+   return -EINVAL;
+
+   for (i = 0; i  gspca_dev-cam.mode_framerates[mode].nrates; i++) {
+   if (fival-index == i) {
+   fival-type = V4L2_FRMSIZE_TYPE_DISCRETE;
+   fival-discrete.numerator = 1;
+   fival-discrete.denominator =
+   gspca_dev-cam.mode_framerates[mode].rates[i];
+   return 0;
+   }
+   }
+
+   return -EINVAL;
+}
+
 static void gspca_release(struct video_device *vfd)
 {
struct gspca_dev *gspca_dev = container_of(vfd, struct gspca_dev, vdev);
@@ -1990,6 +2018,7 @@
.vidioc_g_parm  = vidioc_g_parm,
.vidioc_s_parm  = vidioc_s_parm,
.vidioc_enum_framesizes = vidioc_enum_framesizes,
+   .vidioc_enum_frameintervals = vidioc_enum_frameintervals,
 #ifdef CONFIG_VIDEO_ADV_DEBUG
.vidioc_g_register  = vidioc_g_register,
.vidioc_s_register  = vidioc_s_register,
diff -r 39c1be9a2ff8 -r ef8cca705478 linux/drivers/media/video/gspca/gspca.h
--- a/linux/drivers/media/video/gspca/gspca.h   Tue Dec 01 11:20:34 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.h   Tue Dec 01 13:15:39 2009 +0100
@@ -45,11 +45,20 @@
 /* image transfers */
 #define MAX_NURBS 4/* max number of URBs */
 
+
+/* used to list framerates supported by a camera mode (resolution) */
+struct framerates {
+   int *rates;
+   int nrates;
+};
+
 /* device information - set at probe time */
 struct cam {
int bulk_size;  /* buffer size when image transfer by bulk */
const struct v4l2_pix_format *cam_mode; /* size nmodes */
char nmodes;
+   const struct framerates *mode_framerates; /* must have size nmode,
+  * just like cam_mode */
__u8 bulk_nurbs;/* number of URBs in bulk mode
 * - cannot be  MAX_NURBS
 * - when 0 and bulk_size != 0 means


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


architecture part of video driver patch

2009-12-01 Thread Karicheri, Muralidharan
Kevin,

Following patch merged to v4l-dvb linux-next has an architectural 
part as attached. If you have not merged it to your next branch
for linux-davinci tree, please do so at your earliest convenience
so that they are in sync.

Patch merged to linux-next is available at

http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=commitdiff;h=600cc66f7f3ec93ab4f09cf6b63980f4c5e8f8db

I will be pushing some more patches to upstream that are having
changes to arch part. I will notify once they are merged to linux-next.

Thanks.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

---BeginMessage---
From: Vaibhav Hiremath hvaib...@ti.com

The I2C adapter ID is actually depends on Board and may vary, Davinci
uses id=1, but in case of AM3517 id=3.

So modified respective davinci board files.

Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
 arch/arm/mach-davinci/board-dm355-evm.c  |1 +
 arch/arm/mach-davinci/board-dm644x-evm.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
b/arch/arm/mach-davinci/board-dm355-evm.c
index f683559..4a9252a 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -372,6 +372,7 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
 
 static struct vpfe_config vpfe_cfg = {
.num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+   .i2c_adapter_id = 1,
.sub_devs = vpfe_sub_devs,
.card_name = DM355 EVM,
.ccdc = DM355 CCDC,
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
b/arch/arm/mach-davinci/board-dm644x-evm.c
index cfd9afa..fed64e2 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -257,6 +257,7 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
 
 static struct vpfe_config vpfe_cfg = {
.num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+   .i2c_adapter_id = 1,
.sub_devs = vpfe_sub_devs,
.card_name = DM6446 EVM,
.ccdc = DM6446 CCDC,
-- 
1.6.2.4

___
Davinci-linux-open-source mailing list
davinci-linux-open-sou...@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
---End Message---


Re: Replace Mercurial with GIT as SCM

2009-12-01 Thread Domenico Andreoli
On Tue, Dec 01, 2009 at 03:59:20PM +0100, Patrick Boettcher wrote:
 Hi all,

hi,

 I would like to start a discussion which ideally results in either
 changing the SCM of v4l-dvb to git _or_ leaving everything as it is
 today with mercurial.

i should not be stopped by a tool i'm not familiar with (that is hg)
but actually it is a barrier for me. i'd like to regularly follow v4l-dvb
and surely with git i'd not waste the time as with hg.

the result is that i have a separate git tree for my tw68xx driver
and the integration with v4l-dvb and hg is not my topomost priority
given also that everything needs to be ported back to git before kernel
inclusion.

while i accept that people doing real work should use the tool the
prefer i consider this fracture with the kernel SCM a mistake.

this is only my opinion, my intent is not to start any flamewar.

regards,
Domenico

-[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50
--
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 v2] Another approach to IR

2009-12-01 Thread Maxim Levitsky
On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: 
 While reading all of these IR threads another way of handling IR
 occurred to me that pretty much eliminates the need for LIRC and
 configuration files in default cases. The best way to make everything
 just work is to eliminate it.
 
 The first observation is that the IR profile of various devices are
 well known. Most devices profiles are in the published One-for-All
 database. These device profiles consist of vendor/device/command
 triplets. There is one triplet for each command like play, pause, 1,
 2, 3, power, etc.
 
 The second observation is that universal remotes know how to generate
 commands for all of the common devices.
 
 Let's define evdev messages for IR than contain vendor/device/command
 triplets. I already posted code for doing that in my original patch
 set. These messages are generated from in-kernel code.
 
 Now add a small amount of code to MythTV, etc to act on these evdev
 messages. Default MythTV, etc to respond to the IR commands for a
 common DVR device. Program your universal remote to send the commands
 for this device. You're done. Everything will just work - no LIRC,
 no irrecord, no config files, no command mapping, etc.
You are making one  big wrong assumption that everyone that has a remote
uses mythtv, and only it.

Many users including me, use the remote just like a keyboard, or even
like a mouse.


 
 Of course there are details involved in making this work. MythTV will
 have to have a config option to allow it to emulate several different
 DVR devices so that you can pick one that you don't own. It should
 also have choices for emulating the common devices defined for the
 remotes included with various Linux video board like the Hauppauge
 remote.
 
 For apps that haven't been modified you will have to run a daemon
 which will capture vendor/device/command evdev events and convert them
 into keystroke commands than work the menus. You'll need a config file
 for this and have to write scripts. Instead I'd just go modify the app
 the respond to the IR events, it is easy to do.
 
 Long run, we define a MythTV IR profile, mplayer profile, etc and get
 these into the IR database for universal remotes. Now MythTV can stop
 emulating another vendor's device.
 
 For the default MythTV case no external support will need to be
 installed if the protocol decode engines are in the kernel. The raw
 data will come in, run through the engines, and pop out as evdev
 messages with a vendor/device/command triplet. Devices that decode in
 hardware will just send vendor/device/command triplets.
 


--
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: Replace Mercurial with GIT as SCM

2009-12-01 Thread Alex Deucher
On Tue, Dec 1, 2009 at 9:59 AM, Patrick Boettcher
pboettc...@kernellabs.com wrote:
 Hi all,

 I would like to start a discussion which ideally results in either changing
 the SCM of v4l-dvb to git _or_ leaving everything as it is today with
 mercurial.

 To start right away: I'm in favour of using GIT because of difficulties I
 have with my daily work with v4l-dvb. It is in my nature do to mistakes,
 so I need a tool which assists me in fixing those, I have not found a simple
 way to do my stuff with HG.

 I'm helping out myself using a citation from which basically describes why
 GIT fits the/my needs better than HG (*):

 The culture of mercurial is one of immutability. This is quite a good
 thing, and it's one of my favorite aspects of gnu arch. If I commit
 something, I like to know that it's going to be there. Because of this,
 there are no tools to manipulate history by default.

 git is all about manipulating history. There's rebase, commit amend,
 reset, filter-branch, and probably other commands I'm not thinking of,
 many of which make it into day-to-day workflows. Then again, there's
 reflog, which adds a big safety net around this mutability.

 The first paragraph here describes exactly my problem and the second
 descibes how to solve it.

 My suggestion is not to have the full Linux Kernel source as a new base for
 v4l-dvb development, but only to replace the current v4l-dvb hg with a GIT
 one. Importing all the history and everything.

 Unfortunately it will change nothing for Mauro's job.

 I also understand that it does not give a lot to people who haven't used GIT
 until now other than a new SCM to learn. But believe me, once you've done a
 rebase when Mauro has asked you to rebuild your tree before he can merge it,
 you will see what I mean.

 I'm waiting for comments.

I prefer git myself, but I'm not really actively working on v4l at the
moment, so, I leave it up to the active devs.  One nice thing about
git is the ability to maintain patch authorship.

Alex
--
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: Replace Mercurial with GIT as SCM

2009-12-01 Thread Antti Palosaari

On 12/01/2009 04:59 PM, Patrick Boettcher wrote:

I'm waiting for comments.


GIT

I have never used Git but as it is used by main Linux kernel devel tree 
I would prefer that too.


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


Re: [RFC v2] Another approach to IR

2009-12-01 Thread Jon Smirl
On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky maximlevit...@gmail.com wrote:
 On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote:
 While reading all of these IR threads another way of handling IR
 occurred to me that pretty much eliminates the need for LIRC and
 configuration files in default cases. The best way to make everything
 just work is to eliminate it.

 The first observation is that the IR profile of various devices are
 well known. Most devices profiles are in the published One-for-All
 database. These device profiles consist of vendor/device/command
 triplets. There is one triplet for each command like play, pause, 1,
 2, 3, power, etc.

 The second observation is that universal remotes know how to generate
 commands for all of the common devices.

 Let's define evdev messages for IR than contain vendor/device/command
 triplets. I already posted code for doing that in my original patch
 set. These messages are generated from in-kernel code.

 Now add a small amount of code to MythTV, etc to act on these evdev
 messages. Default MythTV, etc to respond to the IR commands for a
 common DVR device. Program your universal remote to send the commands
 for this device. You're done. Everything will just work - no LIRC,
 no irrecord, no config files, no command mapping, etc.
 You are making one  big wrong assumption that everyone that has a remote
 uses mythtv, and only it.

 Many users including me, use the remote just like a keyboard, or even
 like a mouse.

So let's try and figure out a just works scheme for doing this. What
I'm trying to do is to get everyone to step back and think about this
problem instead of rushing head long into merging LIRC as is. irrecord
is not something a non-technical user can easily handle.

A basic scheme that can be used to eliminate configuration is to take
well known IR device profiles and emulate them in Linux.  So pick
another well known device to emulate (call it A) and map it to
mouse/keyboard events.  Mapping vendor/device/command codes for a
couple devices to mouse/keyboard events is a tiny amount of data and
can be done in-kernel.

This case could also be made to just work. Set your universal remote
to device A. Commands from for device A will arrive and be mapped into
generic keyboard/mouse commands.

There are probably other solutions to making IR work without needing
irrecord and configuration. What would be some other possibilities?

Also consider the long term strategy of defining standard device
profiles and getting them into the IR database. Make an IR profile for
mouse/keyboard. After this gets into the database a universal remote
can be set to this profile which will be a better match than emulating
another device.





 Of course there are details involved in making this work. MythTV will
 have to have a config option to allow it to emulate several different
 DVR devices so that you can pick one that you don't own. It should
 also have choices for emulating the common devices defined for the
 remotes included with various Linux video board like the Hauppauge
 remote.

 For apps that haven't been modified you will have to run a daemon
 which will capture vendor/device/command evdev events and convert them
 into keystroke commands than work the menus. You'll need a config file
 for this and have to write scripts. Instead I'd just go modify the app
 the respond to the IR events, it is easy to do.

 Long run, we define a MythTV IR profile, mplayer profile, etc and get
 these into the IR database for universal remotes. Now MythTV can stop
 emulating another vendor's device.

 For the default MythTV case no external support will need to be
 installed if the protocol decode engines are in the kernel. The raw
 data will come in, run through the engines, and pop out as evdev
 messages with a vendor/device/command triplet. Devices that decode in
 hardware will just send vendor/device/command triplets.







-- 
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: [RFC v2] Another approach to IR

2009-12-01 Thread Mauro Carvalho Chehab
Hi Jon,

Jon Smirl wrote:
 On Tue, Dec 1, 2009 at 10:47 AM, Maxim Levitsky maximlevit...@gmail.com 
 wrote:
 On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote:
 While reading all of these IR threads another way of handling IR
 occurred to me that pretty much eliminates the need for LIRC and
 configuration files in default cases. The best way to make everything
 just work is to eliminate it.

 The first observation is that the IR profile of various devices are
 well known. Most devices profiles are in the published One-for-All
 database. These device profiles consist of vendor/device/command
 triplets. There is one triplet for each command like play, pause, 1,
 2, 3, power, etc.

 The second observation is that universal remotes know how to generate
 commands for all of the common devices.

 Let's define evdev messages for IR than contain vendor/device/command
 triplets. I already posted code for doing that in my original patch
 set. These messages are generated from in-kernel code.

 Now add a small amount of code to MythTV, etc to act on these evdev
 messages. Default MythTV, etc to respond to the IR commands for a
 common DVR device. Program your universal remote to send the commands
 for this device. You're done. Everything will just work - no LIRC,
 no irrecord, no config files, no command mapping, etc.
 You are making one  big wrong assumption that everyone that has a remote
 uses mythtv, and only it.

 Many users including me, use the remote just like a keyboard, or even
 like a mouse.
 
 So let's try and figure out a just works scheme for doing this. What
 I'm trying to do is to get everyone to step back and think about this
 problem instead of rushing head long into merging LIRC as is. irrecord
 is not something a non-technical user can easily handle.
 
 A basic scheme that can be used to eliminate configuration is to take
 well known IR device profiles and emulate them in Linux.  So pick
 another well known device to emulate (call it A) and map it to
 mouse/keyboard events.  Mapping vendor/device/command codes for a
 couple devices to mouse/keyboard events is a tiny amount of data and
 can be done in-kernel.
 
 This case could also be made to just work. Set your universal remote
 to device A. Commands from for device A will arrive and be mapped into
 generic keyboard/mouse commands.
 
 There are probably other solutions to making IR work without needing
 irrecord and configuration. What would be some other possibilities?
 
 Also consider the long term strategy of defining standard device
 profiles and getting them into the IR database. Make an IR profile for
 mouse/keyboard. After this gets into the database a universal remote
 can be set to this profile which will be a better match than emulating
 another device.

This is basically the way the current in-kernel IR drivers work. The
driver converts scancodes (device address/command sequence) into
an evdev standard code.

Just taking an example from the dibcom0700 driver (as the same driver 
supports several different RC5 and NEC codes at the same time), 
the kernel table has several keycodes added there, all working
at the same time. Providing that the scancodes won't overlap, you can
map two different scancodes (from different IR's) to return the same
keycode (table is not complete - I just got a few common keycodes):

# SCAN Key_code
#
0xeb13 KEY_RIGHT
0x1e17 KEY_RIGHT
0x1d17 KEY_RIGHT
0x860f KEY_RIGHT

0xeb11 KEY_LEFT
0x1e16 KEY_LEFT
0x1d16 KEY_LEFT
0x860e KEY_LEFT

0x0703 KEY_VOLUMEUP
0xeb1c KEY_VOLUMEUP
0x1e10 KEY_VOLUMEUP
0x037d KEY_VOLUMEUP
0x1d10 KEY_VOLUMEUP
0x8610 KEY_VOLUMEUP
0x7a12 KEY_VOLUMEUP

0x0709 KEY_VOLUMEDOWN
0xeb1e KEY_VOLUMEDOWN
0x1e11 KEY_VOLUMEDOWN
0x017d KEY_VOLUMEDOWN
0x1d11 KEY_VOLUMEDOWN
0x860c KEY_VOLUMEDOWN
0x7a13 KEY_VOLUMEDOWN

0x0706 KEY_CHANNELUP
0xeb1b KEY_CHANNELUP
0x1e20 KEY_CHANNELUP
0x0242 KEY_CHANNELUP
0x1d20 KEY_CHANNELUP
0x860d KEY_CHANNELUP
0x7a10 KEY_CHANNELUP

0x070c KEY_CHANNELDOWN
0xeb1f KEY_CHANNELDOWN
0x1e21 KEY_CHANNELDOWN
0x007d KEY_CHANNELDOWN
0x1d21 KEY_CHANNELDOWN
0x8619 KEY_CHANNELDOWN
0x7a11 KEY_CHANNELDOWN

It should be noticed, however, that some devices may be provided with a shipped
IR with a different keytable where the keycodes may overlap with this table.

So, what we can do is to have a default keycode table mapping several
different IR's there to be used by drivers that are shipped with an IR
that can be fully mapped by the default table. However, for devices
with scancodes that overlaps with the default table, we'll need a separate
table.

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: [RFC v2] Another approach to IR

2009-12-01 Thread Devin Heitmueller
On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Just taking an example from the dibcom0700 driver (as the same driver
 supports several different RC5 and NEC codes at the same time),
 the kernel table has several keycodes added there, all working
 at the same time. Providing that the scancodes won't overlap, you can
 map two different scancodes (from different IR's) to return the same
 keycode (table is not complete - I just got a few common keycodes):

Mauro,

Just to be clear, the dib0700 does not actually support receiving RC5
or NEC codes at the same time.  You have to tell the chip which mode
to operate in, via a REQUEST_SET_RC to the firmware (see
dib0700_core.c:405).  The em28xx works the same way (you have to tell
it what type of IR format to receive).

The fact that the driver currently uses the same lookup table for both
types of remote controls however, was perhaps not the best design
choice.  It really should be separated out, and merged with the
regular ir-functions.c.  I just never got around to it.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable

2009-12-01 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

v1  - updated based on comments from Vaibhav Hiremath.

On DM365 we use only vpss master clock, where as on DM355 and
DM6446, we use vpss master and slave clocks for vpfe capture and AM3517
we use internal clock and pixel clock. So this patch makes it configurable
on a per platform basis. This is needed for supporting DM365 for which patches
will be available soon.

Tested-by: Vaibhav Hiremath hvaib...@ti.com, Muralidharan Karicheri 
m-kariche...@ti.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
 drivers/media/video/davinci/vpfe_capture.c |   98 +--
 include/media/davinci/vpfe_capture.h   |   11 ++-
 2 files changed, 70 insertions(+), 39 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c 
b/drivers/media/video/davinci/vpfe_capture.c
index 12a1b3d..c3468ee 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1787,61 +1787,87 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
 }
 
+/**
+ * vpfe_disable_clock() - Disable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Disables clocks defined in vpfe configuration.
+ */
 static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
 {
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
+   int i;
 
-   clk_disable(vpfe_cfg-vpssclk);
-   clk_put(vpfe_cfg-vpssclk);
-   clk_disable(vpfe_cfg-slaveclk);
-   clk_put(vpfe_cfg-slaveclk);
-   v4l2_info(vpfe_dev-pdev-driver,
-vpfe vpss master  slave clocks disabled\n);
+   for (i = 0; i  vpfe_cfg-num_clocks; i++) {
+   clk_disable(vpfe_dev-clks[i]);
+   clk_put(vpfe_dev-clks[i]);
+   }
+   kfree(vpfe_dev-clks);
+   v4l2_info(vpfe_dev-pdev-driver, vpfe capture clocks disabled\n);
 }
 
+/**
+ * vpfe_enable_clock() - Enable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Enables clocks defined in vpfe configuration. The function
+ * assumes that at least one clock is to be defined which is
+ * true as of now. re-visit this if this assumption is not true
+ */
 static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
 {
struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-   int ret = -ENOENT;
+   int i;
 
-   vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
-   if (NULL == vpfe_cfg-vpssclk) {
-   v4l2_err(vpfe_dev-pdev-driver, No clock defined for
-vpss_master\n);
-   return ret;
-   }
+   if (!vpfe_cfg-num_clocks)
+   return 0;
 
-   if (clk_enable(vpfe_cfg-vpssclk)) {
-   v4l2_err(vpfe_dev-pdev-driver,
-   vpfe vpss master clock not enabled\n);
-   goto out;
-   }
-   v4l2_info(vpfe_dev-pdev-driver,
-vpfe vpss master clock enabled\n);
+   vpfe_dev-clks = kzalloc(vpfe_cfg-num_clocks *
+  sizeof(struct clock *), GFP_KERNEL);
 
-   vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, vpss_slave);
-   if (NULL == vpfe_cfg-slaveclk) {
-   v4l2_err(vpfe_dev-pdev-driver,
-   No clock defined for vpss slave\n);
-   goto out;
+   if (NULL == vpfe_dev-clks) {
+   v4l2_err(vpfe_dev-pdev-driver, Memory allocation failed\n);
+   return -ENOMEM;
}
 
-   if (clk_enable(vpfe_cfg-slaveclk)) {
-   v4l2_err(vpfe_dev-pdev-driver,
-vpfe vpss slave clock not enabled\n);
-   goto out;
+   for (i = 0; i  vpfe_cfg-num_clocks; i++) {
+   if (NULL == vpfe_cfg-clocks[i]) {
+   v4l2_err(vpfe_dev-pdev-driver,
+   clock %s is not defined in vpfe config\n,
+   vpfe_cfg-clocks[i]);
+   goto out;
+   }
+
+   vpfe_dev-clks[i] = clk_get(vpfe_dev-pdev,
+ vpfe_cfg-clocks[i]);
+   if (NULL == vpfe_dev-clks[i]) {
+   v4l2_err(vpfe_dev-pdev-driver,
+   Failed to get clock %s\n,
+   vpfe_cfg-clocks[i]);
+   goto out;
+   }
+
+   if (clk_enable(vpfe_dev-clks[i])) {
+   v4l2_err(vpfe_dev-pdev-driver,
+   vpfe clock %s not enabled\n,
+   vpfe_cfg-clocks[i]);
+   goto out;
+   }
+
+   v4l2_info(vpfe_dev-pdev-driver, vpss clock %s enabled,
+ vpfe_cfg-clocks[i]);
}
-   v4l2_info(vpfe_dev-pdev-driver, vpfe vpss slave clock enabled\n);
return 0;
 out:
-   if (vpfe_cfg-vpssclk)
-   

Re: [RFC v2] Another approach to IR

2009-12-01 Thread Patrick Boettcher

Hi,
On Tue, 1 Dec 2009, Devin Heitmueller wrote:


On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:

Just taking an example from the dibcom0700 driver (as the same driver
supports several different RC5 and NEC codes at the same time),
the kernel table has several keycodes added there, all working
at the same time. Providing that the scancodes won't overlap, you can
map two different scancodes (from different IR's) to return the same
keycode (table is not complete - I just got a few common keycodes):


Mauro,

Just to be clear, the dib0700 does not actually support receiving RC5
or NEC codes at the same time.  You have to tell the chip which mode
to operate in, via a REQUEST_SET_RC to the firmware (see
dib0700_core.c:405).  The em28xx works the same way (you have to tell
it what type of IR format to receive).

The fact that the driver currently uses the same lookup table for both
types of remote controls however, was perhaps not the best design
choice.  It really should be separated out, and merged with the
regular ir-functions.c.  I just never got around to it.


I did not follow all the discussion, still I have a comment:

I will soon work on a device where it is the driver who is doing the 
decoding of the IR-frames. It is (maybe, I'm still missing some pieces to 
be sure) possible to receive different protocols at the same time with 
this hardware.


--

Patrick 
http://www.kernellabs.com/

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


Re: [RFC v2] Another approach to IR

2009-12-01 Thread Mauro Carvalho Chehab
Maxim Levitsky wrote:
 On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: 
 While reading all of these IR threads another way of handling IR
 occurred to me that pretty much eliminates the need for LIRC and
 configuration files in default cases. The best way to make everything
 just work is to eliminate it.

 The first observation is that the IR profile of various devices are
 well known. Most devices profiles are in the published One-for-All
 database. These device profiles consist of vendor/device/command
 triplets. There is one triplet for each command like play, pause, 1,
 2, 3, power, etc.

 The second observation is that universal remotes know how to generate
 commands for all of the common devices.

 Let's define evdev messages for IR than contain vendor/device/command
 triplets. I already posted code for doing that in my original patch
 set. These messages are generated from in-kernel code.

 Now add a small amount of code to MythTV, etc to act on these evdev
 messages. Default MythTV, etc to respond to the IR commands for a
 common DVR device. Program your universal remote to send the commands
 for this device. You're done. Everything will just work - no LIRC,
 no irrecord, no config files, no command mapping, etc.
 You are making one  big wrong assumption that everyone that has a remote
 uses mythtv, and only it.
 
 Many users including me, use the remote just like a keyboard, or even
 like a mouse.

+1. 

I also use the remote as a keyboard replacement. I used an IR like
that for a long time while teaching, using a standard USB video board,
as a way to remotely control my notebook.

Well, now I have an USB IR for this usage, using HID, that emulates
both keyboard and mouse. In fact, the application didn't change. 
I'm just using the standard USB class for HID, instead of using
vendor class to generate the same kind of evdev events ;)

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: [RFC v2] Another approach to IR

2009-12-01 Thread Mauro Carvalho Chehab
Patrick Boettcher wrote:

 The fact that the driver currently uses the same lookup table for both
 types of remote controls however, was perhaps not the best design
 choice.  It really should be separated out, and merged with the
 regular ir-functions.c.  I just never got around to it.
 
 I did not follow all the discussion, still I have a comment:
 
 I will soon work on a device where it is the driver who is doing the
 decoding of the IR-frames. It is (maybe, I'm still missing some pieces
 to be sure) possible to receive different protocols at the same time
 with this hardware.

That's good news! Needing to pass a modprobe parameter to select the protocol
is not nice, and, while an ioctl will be needed to select IR protocols
(as there are some hardwares where this is not possible at all), the better
is to auto-detect the protocol.

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: DIY Satellite Web Radio

2009-12-01 Thread Manu Abraham
On Mon, Nov 30, 2009 at 11:13 PM, OrazioPirataDelloSpazio (Lorenzo)
ziducai...@autistici.org wrote:
 Hi all,
 I'm not a DVB expert but I'm wondering if this idea is feasible:
 For an amateur web radio, for what I know, it is really hard to
 being listened in cars, like people do with commercial satellite radio
 [1] . Basically this is unaffortable for private user and this is
 probably the most relevant factor that penalize web radios againt
 terrestrial one.

 My question is: is there any way to use the current, cheap, satellite
 internet connections to stream some data above all the coverage of a geo
 satellite? and make the receiver handy (so without any dishes) ?

FWIW, you wont need a satellite dish (some of them operate in the L
Band), unless you are very much out of the footprint, with a weak
signal. Nevertheless, a parabolic reflector will give you a higher
gain, but again that's not the choice for a receiving aerial in a
moving vehicle. Such use cases use in some cases a flat panel antenna
or an antenna array.

DVB-RCS wouldn't work as it needs to be really pointed to the
satellite, nor any Ku or C band transponders. The lower you are in the
spectrum, the more likely to have a better reception with a lower gain
reflector.


http://en.wikipedia.org/wiki/1worldspace
http://www.worldspace.com/howitworks/receivers/AGFwssr.html
http://www.worldspace.com/coveragemaps/antennaguide.html
http://www.satdirectory.com/--worldspace.html

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


[PATCH v0 1/2] V4L - vpfe capture - convert ccdc drivers to platform drivers

2009-12-01 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

Current implementation defines ccdc memory map in vpfe capture platform
file and update the same in ccdc through a function call. This will not
scale well. For example for DM365 CCDC, there are are additional memory
map for Linear table. So it is cleaner to define memory map for ccdc 
driver in the platform file and read it by the ccdc platform driver during
probe.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next tree
 drivers/media/video/davinci/dm355_ccdc.c   |   89 
 drivers/media/video/davinci/dm644x_ccdc.c  |   78 
 drivers/media/video/davinci/vpfe_capture.c |   49 +--
 3 files changed, 145 insertions(+), 71 deletions(-)

diff --git a/drivers/media/video/davinci/dm355_ccdc.c 
b/drivers/media/video/davinci/dm355_ccdc.c
index 56fbefe..aacb95f 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -37,6 +37,7 @@
 #include linux/platform_device.h
 #include linux/uaccess.h
 #include linux/videodev2.h
+#include mach/mux.h
 #include media/davinci/dm355_ccdc.h
 #include media/davinci/vpss.h
 #include dm355_ccdc_regs.h
@@ -105,7 +106,6 @@ static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
 
 static enum vpfe_hw_if_type ccdc_if_type;
 static void *__iomem ccdc_base_addr;
-static int ccdc_addr_size;
 
 /* Raw Bayer formats */
 static u32 ccdc_raw_bayer_pix_formats[] =
@@ -126,12 +126,6 @@ static inline void regw(u32 val, u32 offset)
__raw_writel(val, ccdc_base_addr + offset);
 }
 
-static void ccdc_set_ccdc_base(void *addr, int size)
-{
-   ccdc_base_addr = addr;
-   ccdc_addr_size = size;
-}
-
 static void ccdc_enable(int en)
 {
unsigned int temp;
@@ -938,7 +932,6 @@ static struct ccdc_hw_device ccdc_hw_dev = {
.hw_ops = {
.open = ccdc_open,
.close = ccdc_close,
-   .set_ccdc_base = ccdc_set_ccdc_base,
.enable = ccdc_enable,
.enable_out_to_sdram = ccdc_enable_output_to_sdram,
.set_hw_if_params = ccdc_set_hw_if_params,
@@ -959,19 +952,89 @@ static struct ccdc_hw_device ccdc_hw_dev = {
},
 };
 
-static int __init dm355_ccdc_init(void)
+static int __init dm355_ccdc_probe(struct platform_device *pdev)
 {
-   printk(KERN_NOTICE dm355_ccdc_init\n);
-   if (vpfe_register_ccdc_device(ccdc_hw_dev)  0)
-   return -1;
+   static resource_size_t  res_len;
+   struct resource *res;
+   int status = 0;
+
+   /**
+* first try to register with vpfe. If not correct platform, then we
+* don't have to iomap
+*/
+   status = vpfe_register_ccdc_device(ccdc_hw_dev);
+   if (status  0)
+   return status;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res) {
+   status = -ENOENT;
+   goto fail_nores;
+   }
+   res_len = res-end - res-start + 1;
+
+   res = request_mem_region(res-start, res_len, res-name);
+   if (!res) {
+   status = -EBUSY;
+   goto fail_nores;
+   }
+
+   ccdc_base_addr = ioremap_nocache(res-start, res_len);
+   if (!ccdc_base_addr) {
+   status = -EBUSY;
+   goto fail;
+   }
+   /**
+* setup Mux configuration for vpfe input and register
+* vpfe capture platform device
+*/
+   davinci_cfg_reg(DM355_VIN_PCLK);
+   davinci_cfg_reg(DM355_VIN_CAM_WEN);
+   davinci_cfg_reg(DM355_VIN_CAM_VD);
+   davinci_cfg_reg(DM355_VIN_CAM_HD);
+   davinci_cfg_reg(DM355_VIN_YIN_EN);
+   davinci_cfg_reg(DM355_VIN_CINL_EN);
+   davinci_cfg_reg(DM355_VIN_CINH_EN);
+
printk(KERN_NOTICE %s is registered with vpfe.\n,
ccdc_hw_dev.name);
return 0;
+fail:
+   release_mem_region(res-start, res_len);
+fail_nores:
+   vpfe_unregister_ccdc_device(ccdc_hw_dev);
+   return status;
 }
 
-static void __exit dm355_ccdc_exit(void)
+static int dm355_ccdc_remove(struct platform_device *pdev)
 {
+   struct resource *res;
+
+   iounmap(ccdc_base_addr);
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (res)
+   release_mem_region(res-start, res-end - res-start + 1);
vpfe_unregister_ccdc_device(ccdc_hw_dev);
+   return 0;
+}
+
+static struct platform_driver dm355_ccdc_driver = {
+   .driver = {
+   .name   = dm355_ccdc,
+   .owner = THIS_MODULE,
+   },
+   .remove = __devexit_p(dm355_ccdc_remove),
+   .probe = dm355_ccdc_probe,
+};
+
+static int __init dm355_ccdc_init(void)
+{
+   return platform_driver_register(dm355_ccdc_driver);
+}
+
+static void __exit dm355_ccdc_exit(void)
+{
+   platform_driver_unregister(dm355_ccdc_driver);
 }
 
 module_init(dm355_ccdc_init);
diff --git 

[PATCH 2/2] DaVinci - vpfe capture - converting ccdc to platform driver

2009-12-01 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

This is the platform part for converting ccdc to platform driver.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-davinci tree
 arch/arm/mach-davinci/dm355.c  |   27 +++
 arch/arm/mach-davinci/dm644x.c |   18 +-
 2 files changed, 32 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index dedf4d4..045cb0d 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -701,6 +701,10 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags  = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm355_ccdc_resource[] = {
/* CCDC Base address */
{
.flags  = IORESOURCE_MEM,
@@ -708,8 +712,17 @@ static struct resource vpfe_resources[] = {
.end= 0x01c70600 + 0x1ff,
},
 };
+static struct platform_device dm355_ccdc_dev = {
+   .name   = dm355_ccdc,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm355_ccdc_resource),
+   .resource   = dm355_ccdc_resource,
+   .dev = {
+   .dma_mask   = vpfe_capture_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   },
+};
 
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 static struct platform_device vpfe_capture_dev = {
.name   = CAPTURE_DRV_NAME,
.id = -1,
@@ -860,17 +873,7 @@ static int __init dm355_init_devices(void)
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(dm355_edma_device);
platform_device_register(dm355_vpss_device);
-   /*
-* setup Mux configuration for vpfe input and register
-* vpfe capture platform device
-*/
-   davinci_cfg_reg(DM355_VIN_PCLK);
-   davinci_cfg_reg(DM355_VIN_CAM_WEN);
-   davinci_cfg_reg(DM355_VIN_CAM_VD);
-   davinci_cfg_reg(DM355_VIN_CAM_HD);
-   davinci_cfg_reg(DM355_VIN_YIN_EN);
-   davinci_cfg_reg(DM355_VIN_CINL_EN);
-   davinci_cfg_reg(DM355_VIN_CINH_EN);
+   platform_device_register(dm355_ccdc_dev);
platform_device_register(vpfe_capture_dev);
 
return 0;
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 2cd0081..982be1f 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -612,6 +612,11 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags  = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm644x_ccdc_resource[] = {
+   /* CCDC Base address */
{
.start  = 0x01c70400,
.end= 0x01c70400 + 0xff,
@@ -619,7 +624,17 @@ static struct resource vpfe_resources[] = {
},
 };
 
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device dm644x_ccdc_dev = {
+   .name   = dm644x_ccdc,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_ccdc_resource),
+   .resource   = dm644x_ccdc_resource,
+   .dev = {
+   .dma_mask   = vpfe_capture_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   },
+};
+
 static struct platform_device vpfe_capture_dev = {
.name   = CAPTURE_DRV_NAME,
.id = -1,
@@ -772,6 +787,7 @@ static int __init dm644x_init_devices(void)
platform_device_register(dm644x_edma_device);
platform_device_register(dm644x_emac_device);
platform_device_register(dm644x_vpss_device);
+   platform_device_register(dm644x_ccdc_dev);
platform_device_register(vpfe_capture_dev);
 
return 0;
-- 
1.6.0.4

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


[PATCH -next] media/radio/miro: depends on SND

2009-12-01 Thread Randy Dunlap
From: Randy Dunlap randy.dun...@oracle.com

miropcm20 uses ALSA (snd_) interfaces from the SND_MIRO
driver, so it should depend on SND.
(selecting SND_MIRO when CONFIG_SND is not enabled is a
problem.)

drivers/built-in.o: In function `vidioc_s_ctrl':
radio-miropcm20.c:(.text+0x227499): undefined reference to `snd_aci_cmd'
drivers/built-in.o: In function `vidioc_s_frequency':
radio-miropcm20.c:(.text+0x227574): undefined reference to `snd_aci_cmd'
radio-miropcm20.c:(.text+0x227588): undefined reference to `snd_aci_cmd'
drivers/built-in.o: In function `pcm20_init':
radio-miropcm20.c:(.init.text+0x2a784): undefined reference to `snd_aci_get_aci'

Signed-off-by: Randy Dunlap randy.dun...@oracle.com
---
 drivers/media/radio/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20091201.orig/drivers/media/radio/Kconfig
+++ linux-next-20091201/drivers/media/radio/Kconfig
@@ -197,7 +197,7 @@ config RADIO_MAESTRO
 
 config RADIO_MIROPCM20
tristate miroSOUND PCM20 radio
-   depends on ISA  VIDEO_V4L2
+   depends on ISA  VIDEO_V4L2  SND
select SND_MIRO
---help---
  Choose Y here if you have this FM radio card. You also need to enable
--
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: DIY Satellite Web Radio

2009-12-01 Thread Manu Abraham
On Tue, Dec 1, 2009 at 12:42 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Em 30-11-2009 17:13, OrazioPirataDelloSpazio (Lorenzo) escreveu:
 Hi all,
 I'm not a DVB expert but I'm wondering if this idea is feasible:
 For an amateur web radio, for what I know, it is really hard to
 being listened in cars, like people do with commercial satellite radio
 [1] . Basically this is unaffortable for private user and this is
 probably the most relevant factor that penalize web radios againt
 terrestrial one.

 My question is: is there any way to use the current, cheap, satellite
 internet connections to stream some data above all the coverage of a geo
 satellite? and make the receiver handy (so without any dishes) ?

 Receiving sat signals without dishes? From some trials we had on a telco
 I used to work, You would need to use a network of low-orbit satellites,
 carefully choosing the better frequencies and it will provide you
 low bandwidth.

 This will likely cost a lot of money, if you find someone providing a
 service like that. One trial for such network were the Iridum
 project. AFAIK, the original company bankrupted due to the very high costs of
 launching and managing about a hundred satellite network.

Low orbital satellites aren't geo-stationary. Technically speaking, a
broadcaster would use only geo-stationary satellites for broadcast
services. The basic reason: A broadcaster simply would have rented out
a transponder on an existing satellite from a satellite operator, or
still: if the broadcaster is a major player, they would have a few
satellites of their own to provide coverage over multiple regions, but
still: they are indeed geo-stationary satellites (you will need a very
large number of satellites to provide services in a low orbital
position, similar to the Iridium network, which is not practically
feasible for a broadcaster. Even the Iridium network had a hard time
taking off!)

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


Re: [GIT PULL for 2.6.32] V4L/DVB updates

2009-12-01 Thread Mauro Carvalho Chehab
Mike Isely wrote:
 On Mon, 30 Nov 2009, Mauro Carvalho Chehab wrote:
 
 Em Sat, 28 Nov 2009 14:33:30 -0600 (CST)
 Mike Isely is...@isely.net escreveu:

 Mauro:

 I had also posted up two high priority pvrusb2 patches that should 
 really be cherry-picked for 2.6.32.  You've already pulled them into 
 v4l/dvb and I did mark them as high priority at the time.

 These patches enable use of FX2 microcontroller firmware that is 16KB in 
 size.  Hauppauge is no longer shipping 8KB firmware for HVR-1950 and 
 HVR-1900 and without these changes then those devices won't work AT ALL 
 in kernel 2.6.32.

 You can find these within the v4l-dvb Mercurial repository here:

 Changeset 13495:87c3853fe2b3 
 Subject: pvrusb2: Support 16KB FX2 firmware
 http://linuxtv.org/hg/v4l-dvb/rev/87c3853fe2b3

 Changeset 13500:d4c418d4b25c
 Subject: pvrusb2: Fix lingering 16KB FX2 Firmware issues
 http://linuxtv.org/hg/v4l-dvb/rev/d4c418d4b25c

 I do not believe these patches have any ordering dependencies with other 
 patches, though between the two the second one technically should come 
 after the first.
 
 
 
 There are. Picking just those patches broke compilation.
 
 Mauro:
 
 Please forward to me the compilation errors.  Right now I am just not 
 seeing how a patch this trivial could have any compilation dependencies.  
 And unfortunately I will not be able to reproduce your build setup until 
 at least Tuesday night.  I must be blind.
 
 
 Also, it seemed too late for adding support for newer boards/firmware when 
 Linus
 is about to release a kernel.
 
 This is not a new feature.  It's a bug fix due to something that 
 Hauppauge recently did.  Hauppauge is NO LONGER officially distributing 
 FX2 firmware with their hardware which the driver can use.  This simply 
 prevents any new HVR-1950 / HVR-1900 users from working under Linux.  
 This fixes breakage for previously working hardware.  The root cause is 
 simple - the firmware blob is just larger now - and the fix is trivial.  
 It absolutely needs to go in.  In fact, this should go back to a 
 2.6.31.x and a 2.6.27.x release as well, though in those cases I have to 
 figure out if driver source code is still close enough for the same 
 patches to still work.
 
 I am sorry this is showing up late for you.  There are multiple reasons 
 for this.  However I did mark these patches as high priority, 
 following your v4l-dvb changeset process.  I did comment on the pull 
 request that these were important but I guess I needed to also 
 specifically call these out in the pull request text as well.
 
 If these don't get in now as part of the official 2.6.32 release, these 
 absolutely need to be queued for 2.6.32.1.

We are very late for 2.6.32. I'm not sure if are there still time for it.

I'll seek for some time during this week to add those patches at the upstream
tree and removing them from the development tree and see what compilation
issues arise.

Cheers,
Mauro.
 
   -Mike
 
 

--
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 v2] Another approach to IR

2009-12-01 Thread Jon Smirl
On Tue, Dec 1, 2009 at 2:00 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Due to the lack of an API for it, each driver has their own way to handle the
 protocols, but basically, on almost all drivers, even supporting different 
 protocols,
 the driver limits the usage of just the protocol provided by the shipped 
 remote.

 To solve this, we really need to extend evdev API to do 3 things: enumberate 
 the
 supported protocols, get the current protocol(s), and select the protocol(s) 
 that
 will be used by a newer table.

evdev capabilities bits can support enumerating the supported
protocols. I'm not sure if you can write those bits back into evdev to
turn a feature off/on. If not its something that could be added to
evdev.

I agree that there is no consistency in the existing driver implementations.

-- 
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: [PATCH v0 1/2] V4L - vpfe capture - convert ccdc drivers to platform drivers

2009-12-01 Thread Hiremath, Vaibhav
 -Original Message-
 From: Karicheri, Muralidharan
 Sent: Tuesday, December 01, 2009 11:46 PM
 To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
 khil...@deeprootsystems.com
 Cc: davinci-linux-open-sou...@linux.davincidsp.com; Hiremath,
 Vaibhav; Karicheri, Muralidharan
 Subject: [PATCH v0 1/2] V4L - vpfe capture - convert ccdc drivers to
 platform drivers
 
 From: Muralidharan Karicheri m-kariche...@ti.com
 
 Current implementation defines ccdc memory map in vpfe capture
 platform
 file and update the same in ccdc through a function call. This will
 not
 scale well. For example for DM365 CCDC, there are are additional
 memory
 map for Linear table. So it is cleaner to define memory map for ccdc
 driver in the platform file and read it by the ccdc platform driver
 during
 probe.
 
 Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
 ---
 Applies to V4L-DVB linux-next tree
  drivers/media/video/davinci/dm355_ccdc.c   |   89
 
  drivers/media/video/davinci/dm644x_ccdc.c  |   78
 
  drivers/media/video/davinci/vpfe_capture.c |   49 +--
  3 files changed, 145 insertions(+), 71 deletions(-)
 
 diff --git a/drivers/media/video/davinci/dm355_ccdc.c
 b/drivers/media/video/davinci/dm355_ccdc.c
 index 56fbefe..aacb95f 100644
 --- a/drivers/media/video/davinci/dm355_ccdc.c
 +++ b/drivers/media/video/davinci/dm355_ccdc.c
 @@ -37,6 +37,7 @@
  #include linux/platform_device.h
  #include linux/uaccess.h
  #include linux/videodev2.h
 +#include mach/mux.h
[Hiremath, Vaibhav] This should not be here, this should get handled in board 
file. The driver should be generic.

  #include media/davinci/dm355_ccdc.h
  #include media/davinci/vpss.h
  #include dm355_ccdc_regs.h
 @@ -105,7 +106,6 @@ static struct ccdc_params_ycbcr
 ccdc_hw_params_ycbcr = {
 
  static enum vpfe_hw_if_type ccdc_if_type;
  static void *__iomem ccdc_base_addr;
 -static int ccdc_addr_size;
 
  /* Raw Bayer formats */
  static u32 ccdc_raw_bayer_pix_formats[] =
 @@ -126,12 +126,6 @@ static inline void regw(u32 val, u32 offset)
   __raw_writel(val, ccdc_base_addr + offset);
  }
 
 -static void ccdc_set_ccdc_base(void *addr, int size)
 -{
 - ccdc_base_addr = addr;
 - ccdc_addr_size = size;
 -}
 -
  static void ccdc_enable(int en)
  {
   unsigned int temp;
 @@ -938,7 +932,6 @@ static struct ccdc_hw_device ccdc_hw_dev = {
   .hw_ops = {
   .open = ccdc_open,
   .close = ccdc_close,
 - .set_ccdc_base = ccdc_set_ccdc_base,
   .enable = ccdc_enable,
   .enable_out_to_sdram = ccdc_enable_output_to_sdram,
   .set_hw_if_params = ccdc_set_hw_if_params,
 @@ -959,19 +952,89 @@ static struct ccdc_hw_device ccdc_hw_dev = {
   },
  };
 
 -static int __init dm355_ccdc_init(void)
 +static int __init dm355_ccdc_probe(struct platform_device *pdev)
  {
 - printk(KERN_NOTICE dm355_ccdc_init\n);
 - if (vpfe_register_ccdc_device(ccdc_hw_dev)  0)
 - return -1;
 + static resource_size_t  res_len;
 + struct resource *res;
 + int status = 0;
 +
 + /**
 +  * first try to register with vpfe. If not correct platform,
 then we
 +  * don't have to iomap
 +  */
 + status = vpfe_register_ccdc_device(ccdc_hw_dev);
 + if (status  0)
 + return status;
 +
 + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 + if (!res) {
 + status = -ENOENT;
[Hiremath, Vaibhav] I think right return value is -ENODEV.

 + goto fail_nores;
 + }
 + res_len = res-end - res-start + 1;
 +
 + res = request_mem_region(res-start, res_len, res-name);
[Hiremath, Vaibhav] You should use resource_size here for res_len here.

 + if (!res) {
 + status = -EBUSY;
 + goto fail_nores;
 + }
 +
 + ccdc_base_addr = ioremap_nocache(res-start, res_len);
 + if (!ccdc_base_addr) {
 + status = -EBUSY;
[Hiremath, Vaibhav] Is -EBUSY right return value, I think it should be -ENXIO 
or -ENOMEM.

 + goto fail;
 + }
 + /**
 +  * setup Mux configuration for vpfe input and register
 +  * vpfe capture platform device
 +  */
 + davinci_cfg_reg(DM355_VIN_PCLK);
 + davinci_cfg_reg(DM355_VIN_CAM_WEN);
 + davinci_cfg_reg(DM355_VIN_CAM_VD);
 + davinci_cfg_reg(DM355_VIN_CAM_HD);
 + davinci_cfg_reg(DM355_VIN_YIN_EN);
 + davinci_cfg_reg(DM355_VIN_CINL_EN);
 + davinci_cfg_reg(DM355_VIN_CINH_EN);
 +
[Hiremath, Vaibhav] This should not be here, this code must be generic and 
might get used in another SoC.

   printk(KERN_NOTICE %s is registered with vpfe.\n,
   ccdc_hw_dev.name);
   return 0;
 +fail:
 + release_mem_region(res-start, res_len);
 +fail_nores:
 + vpfe_unregister_ccdc_device(ccdc_hw_dev);
 + return status;
  }
 
 -static void __exit dm355_ccdc_exit(void)
 +static int dm355_ccdc_remove(struct platform_device *pdev)
  {

RE: [PATCH 2/2] DaVinci - vpfe capture - converting ccdc to platform driver

2009-12-01 Thread Hiremath, Vaibhav

 -Original Message-
 From: Karicheri, Muralidharan
 Sent: Tuesday, December 01, 2009 11:46 PM
 To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
 khil...@deeprootsystems.com
 Cc: davinci-linux-open-sou...@linux.davincidsp.com; Hiremath,
 Vaibhav; Karicheri, Muralidharan
 Subject: [PATCH 2/2] DaVinci - vpfe capture - converting ccdc to
 platform driver
 
 From: Muralidharan Karicheri m-kariche...@ti.com
 
 This is the platform part for converting ccdc to platform driver.
 
 Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
 ---
 Applies to linux-davinci tree
  arch/arm/mach-davinci/dm355.c  |   27 +++
  arch/arm/mach-davinci/dm644x.c |   18 +-
  2 files changed, 32 insertions(+), 13 deletions(-)
 
 diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-
 davinci/dm355.c
 index dedf4d4..045cb0d 100644
 --- a/arch/arm/mach-davinci/dm355.c
 +++ b/arch/arm/mach-davinci/dm355.c
 @@ -701,6 +701,10 @@ static struct resource vpfe_resources[] = {
   .end= IRQ_VDINT1,
   .flags  = IORESOURCE_IRQ,
   },
 +};
 +
 +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 +static struct resource dm355_ccdc_resource[] = {
   /* CCDC Base address */
   {
   .flags  = IORESOURCE_MEM,
 @@ -708,8 +712,17 @@ static struct resource vpfe_resources[] = {
   .end= 0x01c70600 + 0x1ff,
   },
  };
 +static struct platform_device dm355_ccdc_dev = {
 + .name   = dm355_ccdc,
 + .id = -1,
 + .num_resources  = ARRAY_SIZE(dm355_ccdc_resource),
 + .resource   = dm355_ccdc_resource,
 + .dev = {
 + .dma_mask   = vpfe_capture_dma_mask,
 + .coherent_dma_mask  = DMA_BIT_MASK(32),
 + },
 +};
 
 -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
  static struct platform_device vpfe_capture_dev = {
   .name   = CAPTURE_DRV_NAME,
   .id = -1,
 @@ -860,17 +873,7 @@ static int __init dm355_init_devices(void)
   davinci_cfg_reg(DM355_INT_EDMA_CC);
   platform_device_register(dm355_edma_device);
   platform_device_register(dm355_vpss_device);
 - /*
 -  * setup Mux configuration for vpfe input and register
 -  * vpfe capture platform device
 -  */
 - davinci_cfg_reg(DM355_VIN_PCLK);
 - davinci_cfg_reg(DM355_VIN_CAM_WEN);
 - davinci_cfg_reg(DM355_VIN_CAM_VD);
 - davinci_cfg_reg(DM355_VIN_CAM_HD);
 - davinci_cfg_reg(DM355_VIN_YIN_EN);
 - davinci_cfg_reg(DM355_VIN_CINL_EN);
 - davinci_cfg_reg(DM355_VIN_CINH_EN);
[Hiremath, Vaibhav] Why have you removed mux configuration from here and moved 
to CCDC driver? Any specific reason?

 + platform_device_register(dm355_ccdc_dev);
   platform_device_register(vpfe_capture_dev);
 
   return 0;
 diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-
 davinci/dm644x.c
 index 2cd0081..982be1f 100644
 --- a/arch/arm/mach-davinci/dm644x.c
 +++ b/arch/arm/mach-davinci/dm644x.c
 @@ -612,6 +612,11 @@ static struct resource vpfe_resources[] = {
   .end= IRQ_VDINT1,
   .flags  = IORESOURCE_IRQ,
   },
 +};
 +
 +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 +static struct resource dm644x_ccdc_resource[] = {
 + /* CCDC Base address */
   {
   .start  = 0x01c70400,
   .end= 0x01c70400 + 0xff,
 @@ -619,7 +624,17 @@ static struct resource vpfe_resources[] = {
   },
  };
 
 -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 +static struct platform_device dm644x_ccdc_dev = {
 + .name   = dm644x_ccdc,
 + .id = -1,
 + .num_resources  = ARRAY_SIZE(dm644x_ccdc_resource),
 + .resource   = dm644x_ccdc_resource,
 + .dev = {
 + .dma_mask   = vpfe_capture_dma_mask,
 + .coherent_dma_mask  = DMA_BIT_MASK(32),
 + },
 +};
 +
  static struct platform_device vpfe_capture_dev = {
   .name   = CAPTURE_DRV_NAME,
   .id = -1,
 @@ -772,6 +787,7 @@ static int __init dm644x_init_devices(void)
   platform_device_register(dm644x_edma_device);
   platform_device_register(dm644x_emac_device);
   platform_device_register(dm644x_vpss_device);
 + platform_device_register(dm644x_ccdc_dev);
   platform_device_register(vpfe_capture_dev);
 
   return 0;
 --
 1.6.0.4

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


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

2009-12-01 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:Tue Dec  1 19:00:02 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13538:e0cd9a337600
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.32-rc8-armv5: OK
linux-2.6.32-rc8-armv5-davinci: OK
linux-2.6.30-armv5-ixp: OK
linux-2.6.31-armv5-ixp: OK
linux-2.6.32-rc8-armv5-ixp: OK
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-armv5-omap2: OK
linux-2.6.32-rc8-armv5-omap2: OK
linux-2.6.22.19-i686: OK
linux-2.6.23.12-i686: OK
linux-2.6.24.7-i686: OK
linux-2.6.25.11-i686: OK
linux-2.6.26-i686: OK
linux-2.6.27-i686: OK
linux-2.6.28-i686: OK
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-i686: OK
linux-2.6.31-i686: OK
linux-2.6.32-rc8-i686: OK
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-rc8-m32r: OK
linux-2.6.30-mips: OK
linux-2.6.31-mips: OK
linux-2.6.32-rc8-mips: OK
linux-2.6.30-powerpc64: OK
linux-2.6.31-powerpc64: OK
linux-2.6.32-rc8-powerpc64: OK
linux-2.6.22.19-x86_64: OK
linux-2.6.23.12-x86_64: OK
linux-2.6.24.7-x86_64: OK
linux-2.6.25.11-x86_64: OK
linux-2.6.26-x86_64: OK
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-x86_64: OK
linux-2.6.31-x86_64: OK
linux-2.6.32-rc8-x86_64: OK
spec: OK
sparse (linux-2.6.31): ERRORS
sparse (linux-2.6.32-rc8): ERRORS
linux-2.6.16.61-i686: WARNINGS
linux-2.6.17.14-i686: WARNINGS
linux-2.6.18.8-i686: WARNINGS
linux-2.6.19.5-i686: WARNINGS
linux-2.6.20.21-i686: WARNINGS
linux-2.6.21.7-i686: WARNINGS
linux-2.6.16.61-x86_64: WARNINGS
linux-2.6.17.14-x86_64: WARNINGS
linux-2.6.18.8-x86_64: WARNINGS
linux-2.6.19.5-x86_64: WARNINGS
linux-2.6.20.21-x86_64: WARNINGS
linux-2.6.21.7-x86_64: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The V4L-DVB specification from this daily build is here:

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


Re: Replace Mercurial with GIT as SCM

2009-12-01 Thread Trent Piepho
On Tue, 1 Dec 2009, Patrick Boettcher wrote:
 To start right away: I'm in favour of using GIT because of difficulties I
 have with my daily work with v4l-dvb. It is in my nature do to mistakes,
 so I need a tool which assists me in fixing those, I have not found a
 simple way to do my stuff with HG.

Try the mq extension.  It's included by default with mercurial, you just
need to add:
[extensions]
hgext.mq=
to your .hgrc file.  It lets you maintain a stack of patches that you can
freely push and pop.  You can make changes and then commit them to one of
the existing patches.  Like git commit -amend, except you can amend any
patch not just the last one.  IMHO, it's better than stock git when you're
trying to make a good patch series.  There is something called stgit which
is very much like mq and a little better I think.
--
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 v2] Another approach to IR

2009-12-01 Thread Dmitry Torokhov
On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
 Dmitry Torokhov wrote:
  On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
  For sure we need to add an EVIOSETPROTO ioctl to allow the driver 
  to change the protocol in runtime.
 
  
  Mauro,
  
  I think this kind of confuguration belongs to lirc device space,
  not input/evdev. This is the same as protocol selection for psmouse
  module: while it is normally auto-detected we have sysfs attribute to
  force one or another and it is tied to serio device, not input
  device.
 
 Dmitry,
 
 This has nothing to do with the raw interface nor with lirc. This problem 
 happens with the evdev interface and already affects the in-kernel drivers.
 
 In this case, psmouse is not a good example. With a mouse, when a movement
 occurs, you'll receive some data from its port. So, a software can autodetect
 the protocol. The same principle can be used also with a raw pulse/space
 interface, where software can autodetect the protocol.

Or, in certain cases, it can not.

 
[... skipped rationale for adding a way to control protocol (with which
I agree) ...]

 
 To solve this, we really need to extend evdev API to do 3 things: enumberate 
 the
 supported protocols, get the current protocol(s), and select the protocol(s) 
 that
 will be used by a newer table.
 

And here we start disagreeing. My preference would be for adding this
API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace),
since it only applicable to IR, not to input devices in general.

Once you selected proper protocol(s) and maybe instantiated several
input devices then udev (by examining input device capabilities and
optionally looking up at the parent device properties) would use
input evdev API to load proper keymap. Because translation of
driver-specific codes into standard key definitions is in the input
realm. Reading these driver-specific codes from hardware is outside of
input layer domain.

Just as psmouse ability to specify protocol is not shoved into evdev;
just as atkbd quirks (force release key list and other driver-specific
options) are not in evdev either; we should not overload evdev interface
with IR-specific items.

-- 
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: [RFC v2] Another approach to IR

2009-12-01 Thread Mauro Carvalho Chehab
Dmitry Torokhov wrote:
 On Tue, Dec 01, 2009 at 05:00:40PM -0200, Mauro Carvalho Chehab wrote:
 Dmitry Torokhov wrote:
 On Tue, Dec 01, 2009 at 03:29:44PM -0200, Mauro Carvalho Chehab wrote:
 For sure we need to add an EVIOSETPROTO ioctl to allow the driver 
 to change the protocol in runtime.

 Mauro,

 I think this kind of confuguration belongs to lirc device space,
 not input/evdev. This is the same as protocol selection for psmouse
 module: while it is normally auto-detected we have sysfs attribute to
 force one or another and it is tied to serio device, not input
 device.
 Dmitry,

 This has nothing to do with the raw interface nor with lirc. This problem 
 happens with the evdev interface and already affects the in-kernel drivers.

 In this case, psmouse is not a good example. With a mouse, when a movement
 occurs, you'll receive some data from its port. So, a software can autodetect
 the protocol. The same principle can be used also with a raw pulse/space
 interface, where software can autodetect the protocol.
 
 Or, in certain cases, it can not.
 
 [... skipped rationale for adding a way to control protocol (with which
 I agree) ...]
 
 To solve this, we really need to extend evdev API to do 3 things: enumberate 
 the
 supported protocols, get the current protocol(s), and select the protocol(s) 
 that
 will be used by a newer table.

 
 And here we start disagreeing. My preference would be for adding this
 API on lirc device level (i.e. /syc/class/lirc/lircX/blah namespace),
 since it only applicable to IR, not to input devices in general.
 
 Once you selected proper protocol(s) and maybe instantiated several
 input devices then udev (by examining input device capabilities and
 optionally looking up at the parent device properties) would use
 input evdev API to load proper keymap. Because translation of
 driver-specific codes into standard key definitions is in the input
 realm. Reading these driver-specific codes from hardware is outside of
 input layer domain.
 
 Just as psmouse ability to specify protocol is not shoved into evdev;
 just as atkbd quirks (force release key list and other driver-specific
 options) are not in evdev either; we should not overload evdev interface
 with IR-specific items.

I'm not against mapping those features as sysfs atributes, but they don't belong
to lirc, as far as I understand. From all we've discussed, we'll create a lirc
interface to allow the direct usage of raw IO. However, IR protocol is a 
property
that is not related to raw IO mode but, instead, to evdev mode.

We might add a /sys/class/IR and add IR specific stuff there, but it seems
overkill to me and will hide the fact that those parameters are part of the 
evdev
interface.

So, I would just add the IR sysfs parameters at the /sys/class/input, if
the device is an IR (or create it is /sys/class/input/IR).

I agree that the code to implement the IR specific sysfs parameter should be 
kept
oustide input core, as they're specific to IR implementations.

Would this work for you?

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


af9015: tuner id:179 not supported, please report!

2009-12-01 Thread Jan Sundman
Hi,

I just received a usb DVB-T card and have been trying to get it to work
under Ubuntu 9.10, but to no avail. dmesg shows the following when
plugging in the card:

[   35.280024] usb 2-1: new high speed USB device using ehci_hcd and
address 4
[   35.435978] usb 2-1: configuration #1 chosen from 1 choice
[   35.450176] af9015: tuner id:179 not supported, please report!
[   35.452891] Afatech DVB-T 2: Fixing fullspeed to highspeed interval:
10 - 7
[   35.453097] input: Afatech DVB-T 2
as /devices/pci:00/:00:13.2/usb2/2-1/2-1:1.1/input/input8
[   35.453141] generic-usb 0003:15A4:9016.0005: input,hidraw3: USB HID
v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:13.2-1/input1

lsusb shows:
Bus 002 Device 005: ID 15a4:9016  

and finally lsmod | grep dvb
dvb_usb_af9015 37152  0 
dvb_usb22892  1 dvb_usb_af9015
dvb_core  109716  1 dvb_usb

While googling for an answer to my troubles I came across
http://ubuntuforums.org/showthread.php?t=606487page=5 which hints that
the card may use the TDA18218HK tuner chip which does not seem to be
supported currently.

Does anyone have any experience regarding this chip and know what to do
to get it working.

Best regards,

//Jan


--
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: [cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: WARNINGS

2009-12-01 Thread Németh Márton
Hans Verkuil wrote:
 This message is generated daily by a cron job that builds v4l-dvb for
 the kernels and architectures in the list below.
 
 Results of the daily build of v4l-dvb:
 
 date:Tue Dec  1 19:00:02 CET 2009
 path:http://www.linuxtv.org/hg/v4l-dvb
 changeset:   13538:e0cd9a337600
 gcc version: gcc (GCC) 4.3.1
 hardware:x86_64
 host os: 2.6.26
 [...]
 Detailed results are available here:
 
 http://www.xs4all.nl/~hverkuil/logs/Tuesday.log


 linux-2.6.29.1-i686: WARNINGS
 /marune/build/v4l-dvb-master/v4l/firedtv-1394.c:264: warning: initialization 
 discards qualifiers from pointer target type

 linux-2.6.29.1-x86_64: WARNINGS
 /marune/build/v4l-dvb-master/v4l/firedtv-1394.c:264: warning: initialization 
 discards qualifiers from pointer target type

I found about this two warnings that this module is not to be built with 
2.6.29.1
according to the following lines from version.txt:

 [2.6.30]
 # Needs const id_table pointer in struct hpsb_protocol_driver
 DVB_FIREDTV_IEEE1394

I'm not sure whether the script v4l/scripts/make_kconfig.pl is working 
correctly or not.

Regards,

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


[PATCH 2/5 - v0] V4L - vpfe capture enhancements to support DM365

2009-12-01 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

This patch adds support for handling CCDC configuration ioctl. A new
IOCTL added to support reading current configuration at CCDC.

NOTE: This is the initial version for review.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
 drivers/media/video/davinci/vpfe_capture.c |   74 +++-
 include/media/davinci/vpfe_capture.h   |5 ++-
 2 files changed, 76 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c 
b/drivers/media/video/davinci/vpfe_capture.c
index 35bbb08..ae8f993 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -759,12 +759,83 @@ static unsigned int vpfe_poll(struct file *file, 
poll_table *wait)
return 0;
 }
 
+static long vpfe_param_handler(struct file *file, void *priv,
+   int cmd, void *param)
+{
+   struct vpfe_device *vpfe_dev = video_drvdata(file);
+   int ret = 0;
+
+   v4l2_dbg(1, debug, vpfe_dev-v4l2_dev, vpfe_param_handler\n);
+
+   if (NULL == param) {
+   v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+   Invalid user ptr\n);
+   }
+
+   if (vpfe_dev-started) {
+   /* only allowed if streaming is not started */
+   v4l2_err(vpfe_dev-v4l2_dev, device already started\n);
+   return -EBUSY;
+   }
+
+
+   switch (cmd) {
+   case VPFE_CMD_S_CCDC_RAW_PARAMS:
+   v4l2_warn(vpfe_dev-v4l2_dev,
+ VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n);
+   ret = mutex_lock_interruptible(vpfe_dev-lock);
+   if (ret)
+   return ret;
+   ret = ccdc_dev-hw_ops.set_params(param);
+   if (ret) {
+   v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+   Error in setting parameters in CCDC\n);
+   goto unlock_out;
+   }
+
+   if (vpfe_get_ccdc_image_format(vpfe_dev, vpfe_dev-fmt)  0) {
+   v4l2_err(vpfe_dev-v4l2_dev,
+   Invalid image format at CCDC\n);
+   ret = -EINVAL;
+   }
+unlock_out:
+   mutex_unlock(vpfe_dev-lock);
+   break;
+   case VPFE_CMD_G_CCDC_RAW_PARAMS:
+   v4l2_warn(vpfe_dev-v4l2_dev,
+ VPFE_CMD_G_CCDC_RAW_PARAMS: experimental ioctl\n);
+   if (!ccdc_dev-hw_ops.get_params) {
+   ret = -EINVAL;
+   break;
+   }
+   ret = ccdc_dev-hw_ops.get_params(param);
+   if (ret) {
+   v4l2_dbg(1, debug, vpfe_dev-v4l2_dev,
+   Error in getting parameters from CCDC\n);
+   }
+   break;
+
+   default:
+   ret = -EINVAL;
+   }
+   return ret;
+}
+
+static long vpfe_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+   if (cmd == VPFE_CMD_S_CCDC_RAW_PARAMS ||
+   cmd == VPFE_CMD_G_CCDC_RAW_PARAMS)
+   return vpfe_param_handler(file, file-private_data, cmd,
+(void *)arg);
+   return video_ioctl2(file, cmd, arg);
+}
+
 /* vpfe capture driver file operations */
 static const struct v4l2_file_operations vpfe_fops = {
.owner = THIS_MODULE,
.open = vpfe_open,
.release = vpfe_release,
-   .unlocked_ioctl = video_ioctl2,
+   .unlocked_ioctl = vpfe_ioctl,
.mmap = vpfe_mmap,
.poll = vpfe_poll
 };
@@ -1751,7 +1822,6 @@ static const struct v4l2_ioctl_ops vpfe_ioctl_ops = {
.vidioc_cropcap  = vpfe_cropcap,
.vidioc_g_crop   = vpfe_g_crop,
.vidioc_s_crop   = vpfe_s_crop,
-   .vidioc_default  = vpfe_param_handler,
 };
 
 static struct vpfe_device *vpfe_initialize(void)
diff --git a/include/media/davinci/vpfe_capture.h 
b/include/media/davinci/vpfe_capture.h
index 7b62a5c..1e6817c 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -71,7 +71,7 @@ struct vpfe_subdev_info {
/* Sub dev routing information for each input */
struct vpfe_route *routes;
/* check if sub dev supports routing */
-   int can_route;
+   int can_route:1;
/* ccdc bus/interface configuration */
struct vpfe_hw_if_param ccdc_if_params;
/* i2c subdevice board info */
@@ -202,4 +202,7 @@ struct vpfe_config_params {
  **/
 #define VPFE_CMD_S_CCDC_RAW_PARAMS _IOW('V', BASE_VIDIOC_PRIVATE + 1, \
void *)
+#define VPFE_CMD_G_CCDC_RAW_PARAMS _IOR('V', BASE_VIDIOC_PRIVATE + 2, \
+   void *)
+
 #endif /* _DAVINCI_VPFE_H */
-- 
1.6.0.4

--
To unsubscribe from this list: send the line 

[PATCH 5/5 - v0] DaVinci - vpfe capture - platform changes for DM365 CCDC

2009-12-01 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

Adds platform and board specific changes to support YUV video capture on
DM365.

NOTE: This patch is for review purpose only

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
 arch/arm/mach-davinci/board-dm365-evm.c|   74 +++
 arch/arm/mach-davinci/dm365.c  |   90 +++-
 arch/arm/mach-davinci/include/mach/dm365.h |2 +
 3 files changed, 165 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-davinci/board-dm365-evm.c 
b/arch/arm/mach-davinci/board-dm365-evm.c
index 8d23972..c9f09e5 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -24,6 +24,7 @@
 #include linux/mtd/partitions.h
 #include linux/mtd/nand.h
 #include linux/input.h
+#include linux/videodev2.h
 
 #include asm/mach-types.h
 #include asm/mach/arch.h
@@ -37,6 +38,9 @@
 #include mach/nand.h
 #include mach/keyscan.h
 
+#include media/tvp514x.h
+#include media/davinci/vpfe_capture.h
+
 static inline int have_imager(void)
 {
/* REVISIT when it's supported, trigger via Kconfig */
@@ -305,6 +309,74 @@ static void dm365evm_mmc_configure(void)
davinci_cfg_reg(DM365_SD1_DATA0);
 }
 
+static struct tvp514x_platform_data tvp5146_pdata = {
+   .clk_polarity = 0,
+   .hs_polarity = 1,
+   .vs_polarity = 1
+};
+
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+   {
+   .index = 0,
+   .name = Composite,
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+   {
+   .index = 1,
+   .name = S-Video,
+   .type = V4L2_INPUT_TYPE_CAMERA,
+   .std = TVP514X_STD_ALL,
+   },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+   {
+   .input = INPUT_CVBS_VI2B,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+{
+   .input = INPUT_SVIDEO_VI2C_VI1C,
+   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+   },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+   {
+   .name = tvp5146,
+   .grp_id = 0,
+   .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+   .inputs = tvp5146_inputs,
+   .routes = tvp5146_routes,
+   .can_route = 1,
+   .ccdc_if_params = {
+   .if_type = VPFE_BT656,
+   .hdpol = VPFE_PINPOL_POSITIVE,
+   .vdpol = VPFE_PINPOL_POSITIVE,
+   },
+   .board_info = {
+   I2C_BOARD_INFO(tvp5146, 0x5d),
+   .platform_data = tvp5146_pdata,
+   },
+   },
+};
+
+static struct vpfe_config vpfe_cfg = {
+   .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+   .sub_devs = vpfe_sub_devs,
+   .card_name = DM365 EVM,
+   .ccdc = DM365 ISIF,
+   .num_clocks = 1,
+   .clocks = {vpss_master},
+};
+
 static void __init evm_init_i2c(void)
 {
davinci_init_i2c(i2c_pdata);
@@ -496,6 +568,8 @@ static struct davinci_uart_config uart_config __initdata = {
 
 static void __init dm365_evm_map_io(void)
 {
+   /* setup input configuration for VPFE input devices */
+   dm365_set_vpfe_config(vpfe_cfg);
dm365_init();
 }
 
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 2ec619e..d9718aa 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1009,6 +1009,87 @@ void __init dm365_init(void)
davinci_common_init(davinci_soc_info_dm365);
 }
 
+static struct resource dm365_vpss_resources[] = {
+   {
+   /* VPSS ISP5 Base address */
+   .name   = vpss,
+   .start  = 0x01c7,
+   .end= 0x01c7 + 0xff,
+   .flags  = IORESOURCE_MEM,
+   },
+   {
+   /* VPSS CLK Base address */
+   .name   = vpss,
+   .start  = 0x01c70200,
+   .end= 0x01c70200 + 0xff,
+   .flags  = IORESOURCE_MEM,
+   },
+};
+
+static struct platform_device dm365_vpss_device = {
+   .name   = vpss,
+   .id = -1,
+   .dev.platform_data  = dm365_vpss,
+   .num_resources  = ARRAY_SIZE(dm365_vpss_resources),
+   .resource   = dm365_vpss_resources,
+};
+
+static struct resource vpfe_resources[] = {
+   {
+   .start  = IRQ_VDINT0,
+   .end= IRQ_VDINT0,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+ 

[PATCH 4/5 - v0] V4L - vpfe capture - build environment to support DM365 CCDC

2009-12-01 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

Added support for building DM365 CCDC module. Also made VPSS module default
configuration variable value to n.

NOTE: This patch is for review purpose only

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
 drivers/media/video/Kconfig  |   15 ++-
 drivers/media/video/davinci/Makefile |1 +
 2 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9dc74c9..6d3ae06 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -552,7 +552,7 @@ config VIDEO_VPSS_SYSTEM
depends on ARCH_DAVINCI
help
  Support for vpss system module for video driver
-   default y
+   default n
 
 config VIDEO_VPFE_CAPTURE
tristate VPFE Video Capture Driver
@@ -596,6 +596,19 @@ config VIDEO_DM355_CCDC
   To compile this driver as a module, choose M here: the
   module will be called vpfe.
 
+config VIDEO_DM365_ISIF
+   tristate DM365 CCDC/ISIF HW module
+   depends on ARCH_DAVINCI_DM365  VIDEO_VPFE_CAPTURE
+   select VIDEO_VPSS_SYSTEM
+   default y
+   help
+  Enables DM365 ISIF hw module. This is the hardware module for
+  configuring ISIF in VPFE to capture Raw Bayer RGB data  from
+  a image sensor or YUV data from a YUV source.
+
+  To compile this driver as a module, choose M here: the
+  module will be called vpfe.
+
 source drivers/media/video/bt8xx/Kconfig
 
 config VIDEO_PMS
diff --git a/drivers/media/video/davinci/Makefile 
b/drivers/media/video/davinci/Makefile
index 1a8b8f3..3642d79 100644
--- a/drivers/media/video/davinci/Makefile
+++ b/drivers/media/video/davinci/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o
 obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o
 obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o
 obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o
+obj-$(CONFIG_VIDEO_DM365_ISIF) += dm365_ccdc.o
-- 
1.6.0.4

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


[PATCH 3/5] V4L - vpfe-capture - updates to vpss module to support DM365

2009-12-01 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

This patch does following changes:-
1) Added support for ISP5 and VPSS modules configuration for DM365
2) renamed few variables to make it more generic

NOTE: This is the initial version for review.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
 drivers/media/video/davinci/vpss.c |  290 +---
 include/media/davinci/vpss.h   |   41 +-
 2 files changed, 277 insertions(+), 54 deletions(-)

diff --git a/drivers/media/video/davinci/vpss.c 
b/drivers/media/video/davinci/vpss.c
index 6d709ca..3820e13 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -15,7 +15,7 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  *
- * common vpss driver for all video drivers.
+ * common vpss system module platform driver for all video drivers.
  */
 #include linux/kernel.h
 #include linux/sched.h
@@ -35,12 +35,52 @@ MODULE_AUTHOR(Texas Instruments);
 /* DM644x defines */
 #define DM644X_SBL_PCR_VPSS(4)
 
+#define DM355_VPSSBL_INTSEL0x10
+#define DM355_VPSSBL_EVTSEL0x14
 /* vpss BL register offsets */
 #define DM355_VPSSBL_CCDCMUX   0x1c
 /* vpss CLK register offsets */
 #define DM355_VPSSCLK_CLKCTRL  0x04
 /* masks and shifts */
 #define VPSS_HSSISEL_SHIFT 4
+/*
+ * VDINT0 - vpss_int0, VDINT1 - vpss_int1, H3A - vpss_int4,
+ * IPIPE_INT1_SDR - vpss_int5
+ */
+#define DM355_VPSSBL_INTSEL_DEFAULT0xff83ff10
+/* VENCINT - vpss_int8 */
+#define DM355_VPSSBL_EVTSEL_DEFAULT0x4
+
+#define DM365_ISP5_PCCR0x04
+#define DM365_ISP5_INTSEL1 0x10
+#define DM365_ISP5_INTSEL2 0x14
+#define DM365_ISP5_INTSEL3 0x18
+#define DM365_ISP5_CCDCMUX 0x20
+#define DM365_ISP5_PG_FRAME_SIZE   0x28
+#define DM365_VPBE_CLK_CTRL0x00
+/*
+ * vpss interrupts. VDINT0 - vpss_int0, VDINT1 - vpss_int1,
+ * AF - vpss_int3
+ */
+#define DM365_ISP5_INTSEL1_DEFAULT 0x0b1f0100
+/* AEW - vpss_int6, RSZ_INT_DMA - vpss_int5 */
+#define DM365_ISP5_INTSEL2_DEFAULT 0x1f0a0f1f
+/* VENC - vpss_int8 */
+#define DM365_ISP5_INTSEL3_DEFAULT 0x0015
+
+/* masks and shifts for DM365*/
+#define DM365_CCDC_PG_VD_POL_SHIFT 0
+#define DM365_CCDC_PG_HD_POL_SHIFT 1
+
+#define CCD_SRC_SEL_MASK   (BIT_MASK(5) | BIT_MASK(4))
+#define CCD_SRC_SEL_SHIFT  4
+
+/* Different SoC platforms supported by this driver */
+enum vpss_platform_type {
+   DM644X,
+   DM355,
+   DM365,
+};
 
 /*
  * vpss operations. Depends on platform. Not all functions are available
@@ -59,13 +99,9 @@ struct vpss_hw_ops {
 
 /* vpss configuration */
 struct vpss_oper_config {
-   __iomem void *vpss_bl_regs_base;
-   __iomem void *vpss_regs_base;
-   struct resource *r1;
-   resource_size_t len1;
-   struct resource *r2;
-   resource_size_t len2;
-   char vpss_name[32];
+   __iomem void *vpss_regs_base0;
+   __iomem void *vpss_regs_base1;
+   enum vpss_platform_type platform;
spinlock_t vpss_lock;
struct vpss_hw_ops hw_ops;
 };
@@ -75,22 +111,46 @@ static struct vpss_oper_config oper_cfg;
 /* register access routines */
 static inline u32 bl_regr(u32 offset)
 {
-   return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+   return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
 }
 
 static inline void bl_regw(u32 val, u32 offset)
 {
-   __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+   __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
 }
 
 static inline u32 vpss_regr(u32 offset)
 {
-   return __raw_readl(oper_cfg.vpss_regs_base + offset);
+   return __raw_readl(oper_cfg.vpss_regs_base1 + offset);
 }
 
 static inline void vpss_regw(u32 val, u32 offset)
 {
-   __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+   __raw_writel(val, oper_cfg.vpss_regs_base1 + offset);
+}
+
+/* For DM365 only */
+static inline u32 isp5_read(u32 offset)
+{
+   return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
+}
+
+/* For DM365 only */
+static inline void isp5_write(u32 val, u32 offset)
+{
+   __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
+}
+
+static void dm365_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+   u32 temp = isp5_read(DM365_ISP5_CCDCMUX)  ~CCD_SRC_SEL_MASK;
+
+   /* if we are using pattern generator, enable it */
+   if (src_sel == VPSS_PGLPBK || src_sel == VPSS_CCDCPG)
+   temp |= 0x08;
+
+   temp |= (src_sel  CCD_SRC_SEL_SHIFT);
+   isp5_write(temp, DM365_ISP5_CCDCMUX);
 }
 
 static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
@@ -101,9 +161,9 @@ static void dm355_select_ccdc_source(enum 
vpss_ccdc_source_sel src_sel)
 int vpss_select_ccdc_source(enum 

linux-media documentation fails to build

2009-12-01 Thread Karicheri, Muralidharan
Hi,

I had downloaded the v4l2-dvb tree few days back to create my video timings API 
documentation and it had compiled fine when I did,

make media-spec

I still can build using the old tar ball. But today, I downloaded 
v4l-dvb-e0cd9a337600.tar.gz, it fails immediately after running the 
make_myconfig.pl script with the error 

No rule to make target 'media-spec'. Stop

Has something changed last few days that broke the build?

I need to make updates to video timing API documentation based on Han's review 
comments and I am stuck at this issue now :(

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.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: linux-media documentation fails to build

2009-12-01 Thread Karicheri, Muralidharan
Some body removed media-spec target from v4l/Makefile.

I got it working with make spec.

Why to change target name like this? 

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Karicheri, Muralidharan
Sent: Tuesday, December 01, 2009 5:28 PM
To: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab; Hans Verkuil
Subject: linux-media documentation fails to build

Hi,

I had downloaded the v4l2-dvb tree few days back to create my video timings
API documentation and it had compiled fine when I did,

make media-spec

I still can build using the old tar ball. But today, I downloaded v4l-dvb-
e0cd9a337600.tar.gz, it fails immediately after running the
make_myconfig.pl script with the error

No rule to make target 'media-spec'. Stop

Has something changed last few days that broke the build?

I need to make updates to video timing API documentation based on Han's
review comments and I am stuck at this issue now :(

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.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
--
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: Replace Mercurial with GIT as SCM

2009-12-01 Thread Andy Walls
On Tue, 2009-12-01 at 15:59 +0100, Patrick Boettcher wrote:
 Hi all,
 
 I would like to start a discussion which ideally results in either 
 changing the SCM of v4l-dvb to git _or_ leaving everything as it is today 
 with mercurial.
 

 I'm waiting for comments.

I only have one requirement: reduce bandwidth usage between the server
and my home.

The less I have to clone out 65 M of history to start a new series of
patches the better.  I suppose that would include a rebase...

Regards,
Andy

--
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/3] radio-si470x: fix SYSCONFIG1 register set on si470x_start()

2009-12-01 Thread Tobias Lorenz
Hi,

what is the advantage in not setting SYSCONFIG1 into a known state?

Bye,
Toby

Am Mittwoch 18 November 2009 07:21:25 schrieb Joonyoung Shim:
 We should use the or operation to set value to the SYSCONFIG1 register
 on si470x_start().
 
 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 ---
  drivers/media/radio/si470x/radio-si470x-common.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/media/radio/si470x/radio-si470x-common.c 
 b/drivers/media/radio/si470x/radio-si470x-common.c
 index f33315f..09f631a 100644
 --- a/drivers/media/radio/si470x/radio-si470x-common.c
 +++ b/drivers/media/radio/si470x/radio-si470x-common.c
 @@ -357,7 +357,7 @@ int si470x_start(struct si470x_device *radio)
   goto done;
  
   /* sysconfig 1 */
 - radio-registers[SYSCONFIG1] = SYSCONFIG1_DE;
 + radio-registers[SYSCONFIG1] |= SYSCONFIG1_DE;
   retval = si470x_set_register(radio, SYSCONFIG1);
   if (retval  0)
   goto done;
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/3] radio-si470x: move some file operations to common file

2009-12-01 Thread Tobias Lorenz
Hi,

yes, good point.

Acked-by: Tobias Lorenz tobias.lor...@gmx.net

Bye,
Toby

Am Mittwoch 18 November 2009 07:21:30 schrieb Joonyoung Shim:
 The read and poll file operations of the si470x usb driver can be used
 also equally on the si470x i2c driver, so they go to the common file.
 
 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 ---
  drivers/media/radio/si470x/radio-si470x-common.c |   98 
 ++
  drivers/media/radio/si470x/radio-si470x-i2c.c|   15 +---
  drivers/media/radio/si470x/radio-si470x-usb.c|   97 
 +-
  drivers/media/radio/si470x/radio-si470x.h|3 +-
  4 files changed, 104 insertions(+), 109 deletions(-)
 
 diff --git a/drivers/media/radio/si470x/radio-si470x-common.c 
 b/drivers/media/radio/si470x/radio-si470x-common.c
 index 7296cf4..f4645d4 100644
 --- a/drivers/media/radio/si470x/radio-si470x-common.c
 +++ b/drivers/media/radio/si470x/radio-si470x-common.c
 @@ -426,6 +426,104 @@ int si470x_rds_on(struct si470x_device *radio)
  
  
  /**
 + * File Operations Interface
 + **/
 +
 +/*
 + * si470x_fops_read - read RDS data
 + */
 +static ssize_t si470x_fops_read(struct file *file, char __user *buf,
 + size_t count, loff_t *ppos)
 +{
 + struct si470x_device *radio = video_drvdata(file);
 + int retval = 0;
 + unsigned int block_count = 0;
 +
 + /* switch on rds reception */
 + if ((radio-registers[SYSCONFIG1]  SYSCONFIG1_RDS) == 0)
 + si470x_rds_on(radio);
 +
 + /* block if no new data available */
 + while (radio-wr_index == radio-rd_index) {
 + if (file-f_flags  O_NONBLOCK) {
 + retval = -EWOULDBLOCK;
 + goto done;
 + }
 + if (wait_event_interruptible(radio-read_queue,
 + radio-wr_index != radio-rd_index)  0) {
 + retval = -EINTR;
 + goto done;
 + }
 + }
 +
 + /* calculate block count from byte count */
 + count /= 3;
 +
 + /* copy RDS block out of internal buffer and to user buffer */
 + mutex_lock(radio-lock);
 + while (block_count  count) {
 + if (radio-rd_index == radio-wr_index)
 + break;
 +
 + /* always transfer rds complete blocks */
 + if (copy_to_user(buf, radio-buffer[radio-rd_index], 3))
 + /* retval = -EFAULT; */
 + break;
 +
 + /* increment and wrap read pointer */
 + radio-rd_index += 3;
 + if (radio-rd_index = radio-buf_size)
 + radio-rd_index = 0;
 +
 + /* increment counters */
 + block_count++;
 + buf += 3;
 + retval += 3;
 + }
 + mutex_unlock(radio-lock);
 +
 +done:
 + return retval;
 +}
 +
 +
 +/*
 + * si470x_fops_poll - poll RDS data
 + */
 +static unsigned int si470x_fops_poll(struct file *file,
 + struct poll_table_struct *pts)
 +{
 + struct si470x_device *radio = video_drvdata(file);
 + int retval = 0;
 +
 + /* switch on rds reception */
 + if ((radio-registers[SYSCONFIG1]  SYSCONFIG1_RDS) == 0)
 + si470x_rds_on(radio);
 +
 + poll_wait(file, radio-read_queue, pts);
 +
 + if (radio-rd_index != radio-wr_index)
 + retval = POLLIN | POLLRDNORM;
 +
 + return retval;
 +}
 +
 +
 +/*
 + * si470x_fops - file operations interface
 + */
 +static const struct v4l2_file_operations si470x_fops = {
 + .owner  = THIS_MODULE,
 + .read   = si470x_fops_read,
 + .poll   = si470x_fops_poll,
 + .ioctl  = video_ioctl2,
 + .open   = si470x_fops_open,
 + .release= si470x_fops_release,
 +};
 +
 +
 +
 +/**
   * Video4Linux Interface
   **/
  
 diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c 
 b/drivers/media/radio/si470x/radio-si470x-i2c.c
 index 2d53b6a..4816a6d 100644
 --- a/drivers/media/radio/si470x/radio-si470x-i2c.c
 +++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
 @@ -173,7 +173,7 @@ int si470x_disconnect_check(struct si470x_device *radio)
  /*
   * si470x_fops_open - file open
   */
 -static int si470x_fops_open(struct file *file)
 +int si470x_fops_open(struct file *file)
  {
   struct si470x_device *radio = video_drvdata(file);
   int retval = 0;
 @@ -194,7 +194,7 @@ static int si470x_fops_open(struct file *file)
  /*
   * si470x_fops_release - file release
   */
 -static int si470x_fops_release(struct file *file)
 +int si470x_fops_release(struct file *file)
  {
   struct si470x_device *radio = 

Re: [PATCH 1/3] radio-si470x: fix SYSCONFIG1 register set on si470x_start()

2009-12-01 Thread Joonyoung Shim
Hi, Tobias.

On 12/2/2009 8:39 AM, Tobias Lorenz wrote:
 Hi,
 
 what is the advantage in not setting SYSCONFIG1 into a known state?
 

At patch 3/3, i am setting the SYSCONFIG1 register for RDS interrupt in
i2c probe function, so i need this patch. Do you have other idea?

 Bye,
 Toby
 
 Am Mittwoch 18 November 2009 07:21:25 schrieb Joonyoung Shim:
 We should use the or operation to set value to the SYSCONFIG1 register
 on si470x_start().

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 ---
  drivers/media/radio/si470x/radio-si470x-common.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

 diff --git a/drivers/media/radio/si470x/radio-si470x-common.c 
 b/drivers/media/radio/si470x/radio-si470x-common.c
 index f33315f..09f631a 100644
 --- a/drivers/media/radio/si470x/radio-si470x-common.c
 +++ b/drivers/media/radio/si470x/radio-si470x-common.c
 @@ -357,7 +357,7 @@ int si470x_start(struct si470x_device *radio)
  goto done;
  
  /* sysconfig 1 */
 -radio-registers[SYSCONFIG1] = SYSCONFIG1_DE;
 +radio-registers[SYSCONFIG1] |= SYSCONFIG1_DE;
  retval = si470x_set_register(radio, SYSCONFIG1);
  if (retval  0)
  goto done;

 

--
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: Replace Mercurial with GIT as SCM

2009-12-01 Thread Domenico Andreoli
On Tue, Dec 01, 2009 at 06:25:00PM -0500, Andy Walls wrote:
 On Tue, 2009-12-01 at 15:59 +0100, Patrick Boettcher wrote:
  Hi all,
  
  I would like to start a discussion which ideally results in either 
  changing the SCM of v4l-dvb to git _or_ leaving everything as it is today 
  with mercurial.
  
 
  I'm waiting for comments.
 
 I only have one requirement: reduce bandwidth usage between the server
 and my home.
 
 The less I have to clone out 65 M of history to start a new series of
 patches the better.  I suppose that would include a rebase...

no, it would not. in case you feel better to clone something before a
rebase, you can clone it locally.

rebasing is an easily abused practice which destroys the history of
a branch and puts in trouble the followers of that branch. published
branch which is often rebased is usually frown upon.

git is a branch-merge-branch-throw-away-branch-branch-merge-... tool.
commit massaging is another tempting practice, it's so easy to produce a
cleaned up history of your branch. writing code in 2D is already pretty
difficult, God save us from writing code in 3D.

cheers,
Domenico

-[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50
--
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: Compile error saa7134 - compro videomate S350

2009-12-01 Thread hermann pitton
Hi,

Am Montag, den 30.11.2009, 14:35 -0800 schrieb Dominic Fernandes:
 Hi Hermann,
 
 There is a sign of life coming from the card (I connected my SAT finder and 
 got a loud tone from it).
 
  You might want to set dvb_powerdown_on_sleep=0 for dvb_core.
 
 How do you specify this and which file (saa7134-dvb.c or saa7134-core.c or 
 some other file)?

as said above, you set it for dvb_core.

 I tried Kaffeine, to scan Astra 19.2 but no luck, at first I can see the 
 signal meters light up and then stop.  The output from dmesg at this point 
 shows:
  
 [   72.944834] DVB: registering adapter 0 frontend 0 (Zarlink ZL10313 
 DVB-S)...
 [ 2183.208025] DVB: adapter 0 frontend 0 frequency 7401500 out of range 
 (95..215)
 [ 2191.756534] DVB: adapter 0 frontend 0 frequency 7401500 out of range 
 (95..215)
 [ 2195.908528] DVB: adapter 0 frontend 0 frequency 7401500 out of range 
 (95..215)
 
 
 Not sure what this means.

Nothing good at all. Likely there is some breakage in the maths across 
devices/modules,
often caused by different xtals/oscillators not sufficiently covered
yet.

For sure enough to get you out of the game for now.

If Richard's card still works with latest v4l-dvb and his patch, likely
you have slightly different hardware covered by the same driver too,
including to hit a freq calculation bug exclusively.

Can't tell from your input. The eeproms of yours and Richard's card
differ in byte 0x74 and 0x75. Don't know what that means.

Cheers,
Hermann








--
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/3] radio-si470x: fix SYSCONFIG1 register set on si470x_start()

2009-12-01 Thread Joonyoung Shim
On 12/2/2009 9:12 AM, Tobias Lorenz wrote:
 Hi,
 
 ok, understood this problem.
 So, why not set this in si470x_fops_open directly after the si470x_start?
 It seems more appropriate to enable the RDS interrupt after starting the 
 radio.
 

OK, it makes sense. I will move it in si470x_fops_open.

 Bye the way, you pointed me to a bug. Instead of always setting de-emphasis 
 in si470x_start:
 radio-registers[SYSCONFIG1] = SYSCONFIG1_DE;
 This should only be done, if requested by module parameter:
 radio-registers[SYSCONFIG1] = (de  11)  SYSCONFIG1_DE; /* DE */
 

Ah, That's right.

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


dvb_usb_dib0700 ( T14BR) not initializing on reboot

2009-12-01 Thread Paul

I have a DVB-T USB device ( T14BR),
which seems to work fine when I plug in my Fedora 10 box but I if I
reboot with device connected it regularity fails to initialise correctly
and to correct I have to remove unplug-device remove the module and
reload module to fix up and only after system has been fully booted

eg
modprobe -r dvb-usb-dib0700
then
modprobe dvb-usb-dib0700  adapter_nr=2
and then plug device in.
I get the following msgs when it seems to fail and the second set when
it works

kernel log (failed)

Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using
ohci_hcd and address 2
Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using
ohci_hcd and address 3
Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using
ohci_hcd and address 4
Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using
ohci_hcd and address 5
Nov 22 13:51:50 mythbox kernel: usb 2-8: new low speed USB device using
ohci_hcd and address 6
Nov 22 13:51:50 mythbox kernel: usb 2-8: configuration #1 chosen from 1
choice
Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device found,
idVendor=413c, idProduct=3010
Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device strings: Mfr=0,
Product=0, SerialNumber=0
Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver
hiddev
Nov 22 13:51:50 mythbox kernel: input: HID 413c:3010 as
/devices/pci:00/:00:02.0/usb2/2-8/2-8:1.0/input/input4
Nov 22 13:51:50 mythbox kernel: input,hidraw0: USB HID v1.00 Mouse [HID
413c:3010] on usb-:00:02.0-8
Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver
usbhid
Nov 22 13:51:50 mythbox kernel: usbhid: v2.6:USB HID core driver


http://www.artectv.com/ehtm/products/t14.htm

kernel log (working)

Nov 29 09:58:20 mythbox kernel: usb 1-8: new high speed USB device using
ehci_hcd and address 3
Nov 29 09:58:20 mythbox kernel: usb 1-8: configuration #1 chosen from 1
choice
Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device found,
idVendor=05d8, idProduct=810f
Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Nov 29 09:58:20 mythbox kernel: usb 1-8: Product: ART7070
Nov 29 09:58:20 mythbox kernel: usb 1-8: Manufacturer: Ultima
Nov 29 09:58:20 mythbox kernel: usb 1-8: SerialNumber: 001
Nov 29 09:58:20 mythbox kernel: dib0700: loaded with support for 7
different device-types
Nov 29 09:58:20 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in
cold state, will try to load a firmware
Nov 29 09:58:20 mythbox kernel: firmware: requesting dvb-usb-dib0700-1.10.fw
Nov 29 09:58:20 mythbox kernel: dvb-usb: downloading firmware from file
'dvb-usb-dib0700-1.10.fw'
Nov 29 09:58:22 mythbox kernel: dib0700: firmware started successfully.
Nov 29 09:58:23 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in
warm state.
Nov 29 09:58:23 mythbox kernel: dvb-usb: will pass the complete MPEG2
transport stream to the software demuxer.
Nov 29 09:58:23 mythbox kernel: DVB: registering new adapter (Artec
T14BR DVB-T)
Nov 29 09:58:23 mythbox kernel: DiB0070: successfully identified
Nov 29 09:58:23 mythbox kernel: input: IR-receiver inside an USB DVB
receiver as /devices/pci:00/:00:02.1/usb1/1
-8/input/input7
Nov 29 09:58:23 mythbox kernel: dvb-usb: schedule remote query interval
to 150 msecs.
Nov 29 09:58:23 mythbox kernel: dvb-usb: Artec T14BR DVB-T successfully
initialized and connected.

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


Re: [GIT PULL for 2.6.32] V4L/DVB updates

2009-12-01 Thread Mike Isely
On Tue, 1 Dec 2009, Mauro Carvalho Chehab wrote:

 Mike Isely wrote:
  On Mon, 30 Nov 2009, Mauro Carvalho Chehab wrote:
  
  Em Sat, 28 Nov 2009 14:33:30 -0600 (CST)
  Mike Isely is...@isely.net escreveu:
 
  Mauro:
 
  I had also posted up two high priority pvrusb2 patches that should 
  really be cherry-picked for 2.6.32.  You've already pulled them into 
  v4l/dvb and I did mark them as high priority at the time.
 
  These patches enable use of FX2 microcontroller firmware that is 16KB in 
  size.  Hauppauge is no longer shipping 8KB firmware for HVR-1950 and 
  HVR-1900 and without these changes then those devices won't work AT ALL 
  in kernel 2.6.32.
 
  You can find these within the v4l-dvb Mercurial repository here:
 
  Changeset 13495:87c3853fe2b3 
  Subject: pvrusb2: Support 16KB FX2 firmware
  http://linuxtv.org/hg/v4l-dvb/rev/87c3853fe2b3
 
  Changeset 13500:d4c418d4b25c
  Subject: pvrusb2: Fix lingering 16KB FX2 Firmware issues
  http://linuxtv.org/hg/v4l-dvb/rev/d4c418d4b25c
 
  I do not believe these patches have any ordering dependencies with other 
  patches, though between the two the second one technically should come 
  after the first.
  
  
  
  There are. Picking just those patches broke compilation.
  
  Mauro:
  
  Please forward to me the compilation errors.  Right now I am just not 
  seeing how a patch this trivial could have any compilation dependencies.  
  And unfortunately I will not be able to reproduce your build setup until 
  at least Tuesday night.  I must be blind.
  
  
  Also, it seemed too late for adding support for newer boards/firmware when 
  Linus
  is about to release a kernel.
  
  This is not a new feature.  It's a bug fix due to something that 
  Hauppauge recently did.  Hauppauge is NO LONGER officially distributing 
  FX2 firmware with their hardware which the driver can use.  This simply 
  prevents any new HVR-1950 / HVR-1900 users from working under Linux.  
  This fixes breakage for previously working hardware.  The root cause is 
  simple - the firmware blob is just larger now - and the fix is trivial.  
  It absolutely needs to go in.  In fact, this should go back to a 
  2.6.31.x and a 2.6.27.x release as well, though in those cases I have to 
  figure out if driver source code is still close enough for the same 
  patches to still work.
  
  I am sorry this is showing up late for you.  There are multiple reasons 
  for this.  However I did mark these patches as high priority, 
  following your v4l-dvb changeset process.  I did comment on the pull 
  request that these were important but I guess I needed to also 
  specifically call these out in the pull request text as well.
  
  If these don't get in now as part of the official 2.6.32 release, these 
  absolutely need to be queued for 2.6.32.1.
 
 We are very late for 2.6.32. I'm not sure if are there still time for it.
 
 I'll seek for some time during this week to add those patches at the upstream
 tree and removing them from the development tree and see what compilation
 issues arise.

Mauro:

Thanks.

Guess I also really need to get up to speed on git, finally...

  -Mike


-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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] Multifrontend support for saa7134

2009-12-01 Thread hermann pitton

Am Dienstag, den 24.11.2009, 02:08 +0100 schrieb hermann pitton:
 Hi Mauro,
 
 Am Montag, den 23.11.2009, 14:04 -0200 schrieb Mauro Carvalho Chehab:
  Hi Lukáš/Hermann,
  
  Any news about this patch? I'll mark it as RFC at the patchwork, since it 
  seems that this is not finished yet. Please let me know if you make some 
  progress.
  
   @@ -1352,6 +1353,7 @@ struct saa7134_board saa7134_boards[] =
 .tuner_addr = ADDR_UNSET,
 .radio_addr = ADDR_UNSET,
  .mpeg   = SAA7134_MPEG_DVB,
   +  .num_frontends  = 1,
  .inputs = {{
  .name = name_tv,
  .vmux = 1,
  
  Just one suggestion here: it is a way better to assume that an 
  uninitialized value (e. g. num_frontends = 0) for num_frontends to mean 
  that just one frontend exists. This saves space at the initialization 
  segment
  of the module and avoids the risk of someone forget to add num_frontends=0.
  
  cheers,
  Mauro.
 
 I currently don't have time to work on it and Lukáš' time is also
 limited.
 
 We stay in contact and I can provide a device not yet working for me to
 him, if he wants. I'll keep you posted. You can have one too ;)
 
 Currently the hardware reset in saa7134-dvb.c seems to break tda8275a
 hybrid tuners on my saa7131e devices for DVB-T. This is not restricted
 to the devices with multiple frontends, but also hits such with single
 frontend only. The TRIO has two tda8275a, they are not in use as hybrid
 tuners and don't need extra initialization again, that might be the
 difference.
 
 We should avoid such saa7133 hardware reset on those cards not needing
 it in any case, means all with single frontend.

Or find a solution for this ridiculous frontend is superior over the
bridge going on since years against any common sense and claiming to
cover hybrid stuff too, imposing total nonsense on all such interested. 

 ON DVB-S is also a regression visible, in one of two cases needs a
 second tuning attempt now and it also seems to be related to the
 hardware reset, since without works fine like previously.
 
 Patch is not ready yet for inclusion.

Getting hands dirty on what is around now on specs, that hardware reset
changes all gpios to be input on the bridge.

Of course nothing left after it for that five years work on such on that
dvb stuff. Mike proceed.

Cheers,
Hermann






--
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 v3] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats

2009-12-01 Thread Hans Verkuil
On Tuesday 01 December 2009 16:22:55 Guennadi Liakhovetski wrote:
 On Tue, 1 Dec 2009, Hans Verkuil wrote:
  On Monday 30 November 2009 14:49:07 Guennadi Liakhovetski wrote:
   Right, how about this:
  
   /*
* These pixel codes uniquely identify data formats on the media bus.
   Mostly * they correspond to similarly named V4L2_PIX_FMT_* formats,
   format 0 is * reserved, V4L2_MBUS_FMT_FIXED shall be used by
   host-client pairs, where the * data format is fixed. Additionally,
   2X8 means that one pixel is transferred * in two 8-bit samples, BE
   or LE specify in which order those samples are * transferred over the
   bus: LE means that the least significant bits are * transferred
   first, BE means that the most significant bits are transferred *
   first, and PADHI and PADLO define which bits - low or high, in the
   * incomplete high byte, are filled with padding bits.
*/
   enum v4l2_mbus_pixelcode {
 V4L2_MBUS_FMT_FIXED = 1,
 V4L2_MBUS_FMT_YUYV_2X8_LE,
 V4L2_MBUS_FMT_YVYU_2X8_LE,
 V4L2_MBUS_FMT_UYVY_2X8_LE,
 V4L2_MBUS_FMT_VYUY_2X8_LE,
 
  These possibly may need a comment saying that each Y/U/V sample is 8 bits
  wide. I'm not sure how far we want to go with systematic naming schemes
  here. Adding a short comment if there is a possible ambiguity is probably
  sufficient.

 Is there an ambiguity? Aren't these formats standardised?

HDMI receivers/transmitters can do YUV with 8, 10 or 12 bits. So when you say
YUYV_2X8_LE do you mean that 10 bits are transported over two bytes, or that
a Y and a U (or V) are transferred one after another? From the absence of a 
PADHI or PADLO I can infer that it is the latter, but it is not exactly 
obvious.

Actually, why not name these formats YUYV8, etc. and the order of the bytes 
going over the bus is just the order of the text 'YUYV'. There is not really 
any big or little endian issues since you just need to know the sequence of 
Ys, Us and Vs.

 Do we then have
 to explain what rgb555 means etc?

 V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
 V4L2_MBUS_FMT_RGB555X_2X8_PADHI_LE,
 
  Shouldn't this be: V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE? Since the 555X
  format is just the big-endian variant of the RGB555 if I am not mistaken.

 No, don't think so. As an RGB555X format it is sent in LE order, if you
 send RGB555X in BE order you get RGB555 (without an X). In fact, you'll
 never have a RGB555X_BE format, because, that's just the RGB555_LE. So,
 you may only have BE variants for formats, whoch byte-swapped variants do
 not have an own name.

RGB 5:5:5 consists of 16 bits argg gggb ('a' is either padding or an 
alpha bit).

RGB 5:5:5 over an 8 bit data bus is either with the MSB byte first (big endian 
aka RGB555X aka RGB555_2X8_PADHI_BE) or with the LSB byte first (little endian 
aka RGB555 aka RGB555_2X8_PADHI_LE).

The use of RGB555X in the pixel formats is a really ugly accident of history. 
'RGB555' is the name of the format, and _LE or _BE should define what the 
order of the LSB and MSB over the data bus is.


 V4L2_MBUS_FMT_RGB565_2X8_LE,
 V4L2_MBUS_FMT_RGB565X_2X8_LE,
 
  Ditto.
 
 V4L2_MBUS_FMT_SBGGR8_1X8,
 V4L2_MBUS_FMT_SBGGR10_1X10,
 V4L2_MBUS_FMT_GREY_1X8,
 
  This is also 8 bits per sample, right? This might be renamed to
  GREY8_1X8.

 I named it after V4L2_PIX_FMT_GREY. If we ever get GREY7 or similar, I
 think, we anyway will need a new fourcc code for it, then we'll call the
 MBUS_FMT similarly.

Why not do it right from the start? Frankly, the PIX_FMT names aren't that 
great. And since this will become a public API in the future I think it is 
reasonable to spend some time on it (and it is the reason why I'm so picky 
about it :-) ).

Regards,

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


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

2009-12-01 Thread Hans Verkuil
On Wednesday 02 December 2009 03:05:10 Németh Márton wrote:
 Hans Verkuil wrote:
  This message is generated daily by a cron job that builds v4l-dvb for
  the kernels and architectures in the list below.
 
  Results of the daily build of v4l-dvb:
 
  date:Tue Dec  1 19:00:02 CET 2009
  path:http://www.linuxtv.org/hg/v4l-dvb
  changeset:   13538:e0cd9a337600
  gcc version: gcc (GCC) 4.3.1
  hardware:x86_64
  host os: 2.6.26
  [...]
  Detailed results are available here:
 
  http://www.xs4all.nl/~hverkuil/logs/Tuesday.log
 
  linux-2.6.29.1-i686: WARNINGS
  /marune/build/v4l-dvb-master/v4l/firedtv-1394.c:264: warning:
  initialization discards qualifiers from pointer target type
 
  linux-2.6.29.1-x86_64: WARNINGS
  /marune/build/v4l-dvb-master/v4l/firedtv-1394.c:264: warning:
  initialization discards qualifiers from pointer target type

 I found about this two warnings that this module is not to be built with
 2.6.29.1

 according to the following lines from version.txt:
  [2.6.30]
  # Needs const id_table pointer in struct hpsb_protocol_driver
  DVB_FIREDTV_IEEE1394

 I'm not sure whether the script v4l/scripts/make_kconfig.pl is working
 correctly or not.

There are some weird conditions on that IEEE1394 config that seem to defeat 
the make_kconfig.pl script. I haven't had the time to look at it. It would be 
great if someone can take a look at it as I don't have the time.

Regards,

Hans


 Regards,

   Márton Németh

--
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] bttv: add i2c addr for old WinTV card to IR probe list

2009-12-01 Thread Jarod Wilson
There are old bttv-driven Hauppauge WinTV series cards that have
their IR part at i2c addr 0x71, which doesn't get considered in the
new 2.6.31 i2c code.

From a 2.6.29 kernel:

lirc_i2c: chip 0x10005 found @ 0x71 (Hauppauge PVR150)

Minor cosmetic glitch, the card in question isn't actually a PVR-150, its:

03:06.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture 
(rev 11)
Subsystem: Hauppauge computer works Inc. WinTV Series
Flags: bus master, medium devsel, latency 32, IRQ 19
Memory at f4ffe000 (32-bit, prefetchable) [size=4K]
Capabilities: [44] Vital Product Data
Capabilities: [4c] Power Management version 2
Kernel driver in use: bttv
Kernel modules: bttv

Device ID: 0x109e:0x036e, Sub-Device ID: 0x0070:0x13eb

This simply adds 0x71 to the list of addresses i2c_new_probed_device should
consider, which gets IR working on this card again.

Reported-by: Adam Williamson awill...@redhat.com
Signed-off-by: Jarod Wilson ja...@redhat.com
Tested-by: Adam Williamson awill...@redhat.com

---
diff -r e0cd9a337600 linux/drivers/media/video/bt8xx/bttv-i2c.c
--- a/linux/drivers/media/video/bt8xx/bttv-i2c.cSun Nov 29 12:08:02 
2009 -0200
+++ b/linux/drivers/media/video/bt8xx/bttv-i2c.cTue Dec 01 11:23:17 
2009 -0500
@@ -423,7 +423,7 @@
   That's why we probe 0x1a (~0x34) first. CB
*/
const unsigned short addr_list[] = {
-   0x1a, 0x18, 0x4b, 0x64, 0x30,
+   0x1a, 0x18, 0x4b, 0x64, 0x30, 0x71,
I2C_CLIENT_END
};
 
--
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: dvb_usb_dib0700 ( T14BR) not initializing on reboot

2009-12-01 Thread Paul

On 2/12/2009 12:35 PM, Paul wrote:

I have a DVB-T USB device ( T14BR),
which seems to work fine when I plug in my Fedora 10 box but I if I
reboot with device connected it regularity fails to initialise correctly
and to correct I have to remove unplug-device remove the module and
reload module to fix up and only after system has been fully booted

eg
modprobe -r dvb-usb-dib0700
then
modprobe dvb-usb-dib0700  adapter_nr=2
and then plug device in.
I get the following msgs when it seems to fail and the second set when
it works

kernel log (failed)

Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using
ohci_hcd and address 2
Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using
ohci_hcd and address 3
Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using
ohci_hcd and address 4
Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using
ohci_hcd and address 5
Nov 22 13:51:50 mythbox kernel: usb 2-8: new low speed USB device using
ohci_hcd and address 6
Nov 22 13:51:50 mythbox kernel: usb 2-8: configuration #1 chosen from 1
choice
Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device found,
idVendor=413c, idProduct=3010
Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device strings: Mfr=0,
Product=0, SerialNumber=0
Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver
hiddev
Nov 22 13:51:50 mythbox kernel: input: HID 413c:3010 as
/devices/pci:00/:00:02.0/usb2/2-8/2-8:1.0/input/input4
Nov 22 13:51:50 mythbox kernel: input,hidraw0: USB HID v1.00 Mouse [HID
413c:3010] on usb-:00:02.0-8
Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver
usbhid
Nov 22 13:51:50 mythbox kernel: usbhid: v2.6:USB HID core driver


http://www.artectv.com/ehtm/products/t14.htm

kernel log (working)

Nov 29 09:58:20 mythbox kernel: usb 1-8: new high speed USB device using
ehci_hcd and address 3
Nov 29 09:58:20 mythbox kernel: usb 1-8: configuration #1 chosen from 1
choice
Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device found,
idVendor=05d8, idProduct=810f
Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device strings: Mfr=1,
Product=2, SerialNumber=3
Nov 29 09:58:20 mythbox kernel: usb 1-8: Product: ART7070
Nov 29 09:58:20 mythbox kernel: usb 1-8: Manufacturer: Ultima
Nov 29 09:58:20 mythbox kernel: usb 1-8: SerialNumber: 001
Nov 29 09:58:20 mythbox kernel: dib0700: loaded with support for 7
different device-types
Nov 29 09:58:20 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in
cold state, will try to load a firmware
Nov 29 09:58:20 mythbox kernel: firmware: requesting 
dvb-usb-dib0700-1.10.fw

Nov 29 09:58:20 mythbox kernel: dvb-usb: downloading firmware from file
'dvb-usb-dib0700-1.10.fw'
Nov 29 09:58:22 mythbox kernel: dib0700: firmware started successfully.
Nov 29 09:58:23 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in
warm state.
Nov 29 09:58:23 mythbox kernel: dvb-usb: will pass the complete MPEG2
transport stream to the software demuxer.
Nov 29 09:58:23 mythbox kernel: DVB: registering new adapter (Artec
T14BR DVB-T)
Nov 29 09:58:23 mythbox kernel: DiB0070: successfully identified
Nov 29 09:58:23 mythbox kernel: input: IR-receiver inside an USB DVB
receiver as /devices/pci:00/:00:02.1/usb1/1
-8/input/input7
Nov 29 09:58:23 mythbox kernel: dvb-usb: schedule remote query interval
to 150 msecs.
Nov 29 09:58:23 mythbox kernel: dvb-usb: Artec T14BR DVB-T successfully
initialized and connected.





Note I googled a few other people with the same issue:

http://www.linuxtv.org/pipermail/linux-dvb/2007-November/022145.html
http://ubuntuforums.org/archive/index.php/t-1233131.html

so I'm assuming its a known issue, right?

Paul
--
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: dvb_usb_dib0700 ( T14BR) not initializing on reboot

2009-12-01 Thread ALi
Are you sure that your usb is dib0700?
if you look on the sources  you wont see idVendor=413c,
idProduct=3010 however there is

os...@x-evian:/usr/src/linux-source-2.6.30/drivers/media/dvb/dvb-usb$
grep 05d8 * -iR
Coincidencia en el fichero binario dvb-usb-dib0700.ko
dvb-usb-dib0700.mod.c:MODULE_ALIAS(usb:v05D8p810Fd*dc*dsc*dp*ic*isc*ip*);


in the file  so  try to recompile it with your device id, and
pray for it :)

On Wed, Dec 2, 2009 at 5:15 AM, Paul myli...@wilsononline.id.au wrote:
 On 2/12/2009 12:35 PM, Paul wrote:

 I have a DVB-T USB device ( T14BR),
 which seems to work fine when I plug in my Fedora 10 box but I if I
 reboot with device connected it regularity fails to initialise correctly
 and to correct I have to remove unplug-device remove the module and
 reload module to fix up and only after system has been fully booted

 eg
 modprobe -r dvb-usb-dib0700
 then
 modprobe dvb-usb-dib0700  adapter_nr=2
 and then plug device in.
 I get the following msgs when it seems to fail and the second set when
 it works

 kernel log (failed)

 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using
 ohci_hcd and address 2
 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using
 ohci_hcd and address 3
 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using
 ohci_hcd and address 4
 Nov 22 13:51:50 mythbox kernel: usb 2-7: new full speed USB device using
 ohci_hcd and address 5
 Nov 22 13:51:50 mythbox kernel: usb 2-8: new low speed USB device using
 ohci_hcd and address 6
 Nov 22 13:51:50 mythbox kernel: usb 2-8: configuration #1 chosen from 1
 choice
 Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device found,
 idVendor=413c, idProduct=3010
 Nov 22 13:51:50 mythbox kernel: usb 2-8: New USB device strings: Mfr=0,
 Product=0, SerialNumber=0
 Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver
 hiddev
 Nov 22 13:51:50 mythbox kernel: input: HID 413c:3010 as
 /devices/pci:00/:00:02.0/usb2/2-8/2-8:1.0/input/input4
 Nov 22 13:51:50 mythbox kernel: input,hidraw0: USB HID v1.00 Mouse [HID
 413c:3010] on usb-:00:02.0-8
 Nov 22 13:51:50 mythbox kernel: usbcore: registered new interface driver
 usbhid
 Nov 22 13:51:50 mythbox kernel: usbhid: v2.6:USB HID core driver


 http://www.artectv.com/ehtm/products/t14.htm

 kernel log (working)

 Nov 29 09:58:20 mythbox kernel: usb 1-8: new high speed USB device using
 ehci_hcd and address 3
 Nov 29 09:58:20 mythbox kernel: usb 1-8: configuration #1 chosen from 1
 choice
 Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device found,
 idVendor=05d8, idProduct=810f
 Nov 29 09:58:20 mythbox kernel: usb 1-8: New USB device strings: Mfr=1,
 Product=2, SerialNumber=3
 Nov 29 09:58:20 mythbox kernel: usb 1-8: Product: ART7070
 Nov 29 09:58:20 mythbox kernel: usb 1-8: Manufacturer: Ultima
 Nov 29 09:58:20 mythbox kernel: usb 1-8: SerialNumber: 001
 Nov 29 09:58:20 mythbox kernel: dib0700: loaded with support for 7
 different device-types
 Nov 29 09:58:20 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in
 cold state, will try to load a firmware
 Nov 29 09:58:20 mythbox kernel: firmware: requesting
 dvb-usb-dib0700-1.10.fw
 Nov 29 09:58:20 mythbox kernel: dvb-usb: downloading firmware from file
 'dvb-usb-dib0700-1.10.fw'
 Nov 29 09:58:22 mythbox kernel: dib0700: firmware started successfully.
 Nov 29 09:58:23 mythbox kernel: dvb-usb: found a 'Artec T14BR DVB-T' in
 warm state.
 Nov 29 09:58:23 mythbox kernel: dvb-usb: will pass the complete MPEG2
 transport stream to the software demuxer.
 Nov 29 09:58:23 mythbox kernel: DVB: registering new adapter (Artec
 T14BR DVB-T)
 Nov 29 09:58:23 mythbox kernel: DiB0070: successfully identified
 Nov 29 09:58:23 mythbox kernel: input: IR-receiver inside an USB DVB
 receiver as /devices/pci:00/:00:02.1/usb1/1
 -8/input/input7
 Nov 29 09:58:23 mythbox kernel: dvb-usb: schedule remote query interval
 to 150 msecs.
 Nov 29 09:58:23 mythbox kernel: dvb-usb: Artec T14BR DVB-T successfully
 initialized and connected.




 Note I googled a few other people with the same issue:

 http://www.linuxtv.org/pipermail/linux-dvb/2007-November/022145.html
 http://ubuntuforums.org/archive/index.php/t-1233131.html

 so I'm assuming its a known issue, right?

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