Re: [RFC] [PATCH] v4l2: use unsigned rather than enums in ioctl() structs

2012-04-12 Thread James Courtier-Dutton 
2012/4/11 Rémi Denis-Courmont :
>        Hello,
>
> Le mercredi 11 avril 2012 20:02:00 Mauro Carvalho Chehab, vous avez écrit :
>> Using unsigned instead of enum is not a good idea, from API POV, as
>> unsigned has different sizes on 32 bits and 64 bits.
>
> Fair enough. But then we can do that instead:
> typedef XXX __enum_t;
> where XXX is the unsigned integer with the right number of bits. Since Linux
> does not use short enums, this ought to work fine.
>
>> Yet, using enum was really a very bad idea, and, on all new stuff,
>> we're not accepting any new enum field.
>
> That is unfortunately not true. You do follow that rule for new fields to
> existing V4L2 structure. But you have been royally ignoring that rule when it
> comes to extending existing enumerations:
>
> linux-media does regularly add new enum values to existing enums. That is new
> stuff too, and every single time you do that, you do BREAK THE USERSPACE ABI.
> This is entirely unacceptable and against established kernel development
> policies.
>
> For instance, in Linux 3.1, V4L2_CTRL_TYPE_BITMASK was added. This broke
> userspace. And there are some pending patches adding more of the same thing...
> And V4L2_MEMORY_DMABUF will similarly break the user-to-kernel interface,
> which is yet worse.
>

I agree that breaking user-to-kernel interface is not advised.
We came across a similar problem some years ago with the ALSA sound
kernel drivers.
The solution we used was:
1) If a change is likely to change the user-to-kernel API, add a new
IOCTL for it.
Then old userland software can use the old IOCTL, and new userland
software can use the new IOCTL.
2) Add an version IOCTL that returns the current API level, so that
the app can be written to support more than one API interface,
depending on which kernel it is running on. The version IOCTL simply
returns an u32 value. This is a consistent part of the user-kernel API
that will never change.
3) Add "depreciated" compiler warnings to all the old API IOCTL calls,
so app developers know they should be working to update their apps.
4) After a few years, remove the old IOCTLs.
5) Use "uint32_t" and "uint64_t" types for all IOCTL calls, and not
"unsigned int" or "unsigned long int".
I.e. All structures passed in IOCTLs use fixed bit sized parameters
for everything except of course pointers. Pointers depend on
architecture.
6) Add a #if #endif around the old API, so a user compiling their own
kernel can decide if the old API exists or not. User might want to do
this for security reasons.

Kind Regards

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

[yavta PATCH 3/3] Support additional dpcm compressed bayer formats.

2012-04-12 Thread Sakari Ailus 
Signed-off-by: Sakari Ailus 
---
 yavta.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/yavta.c b/yavta.c
index 532fb1f..a89d475 100644
--- a/yavta.c
+++ b/yavta.c
@@ -149,7 +149,10 @@ static struct {
{ "SGBRG8", V4L2_PIX_FMT_SGBRG8 },
{ "SGRBG8", V4L2_PIX_FMT_SGRBG8 },
{ "SRGGB8", V4L2_PIX_FMT_SRGGB8 },
+   { "SBGGR10_DPCM8", V4L2_PIX_FMT_SBGGR10DPCM8 },
+   { "SGBRG10_DPCM8", V4L2_PIX_FMT_SGBRG10DPCM8 },
{ "SGRBG10_DPCM8", V4L2_PIX_FMT_SGRBG10DPCM8 },
+   { "SRGGB10_DPCM8", V4L2_PIX_FMT_SRGGB10DPCM8 },
{ "SBGGR10", V4L2_PIX_FMT_SBGGR10 },
{ "SGBRG10", V4L2_PIX_FMT_SGBRG10 },
{ "SGRBG10", V4L2_PIX_FMT_SGRBG10 },
-- 
1.7.2.5

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

[yavta PATCH 1/3] Support integer menus.

2012-04-12 Thread Sakari Ailus 
Signed-off-by: Sakari Ailus 
---
 yavta.c |   18 +++---
 1 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/yavta.c b/yavta.c
index 72679c2..8db6e1e 100644
--- a/yavta.c
+++ b/yavta.c
@@ -564,19 +564,22 @@ static int video_enable(struct device *dev, int enable)
return 0;
 }
 
-static void video_query_menu(struct device *dev, unsigned int id,
-unsigned int min, unsigned int max)
+static void video_query_menu(struct device *dev, struct v4l2_queryctrl *query)
 {
struct v4l2_querymenu menu;
int ret;
 
-   for (menu.index = min; menu.index <= max; menu.index++) {
-   menu.id = id;
+   for (menu.index = query->minimum; menu.index <= query->maximum;
+menu.index++) {
+   menu.id = query->id;
ret = ioctl(dev->fd, VIDIOC_QUERYMENU, &menu);
if (ret < 0)
continue;
 
-   printf("  %u: %.32s\n", menu.index, menu.name);
+   if (query->type == V4L2_CTRL_TYPE_MENU)
+   printf("  %u: %.32s\n", menu.index, menu.name);
+   else
+   printf("  %u: %lld\n", menu.index, menu.value);
};
 }
 
@@ -621,8 +624,9 @@ static void video_list_controls(struct device *dev)
query.id, query.name, query.minimum, query.maximum,
query.step, query.default_value, value);
 
-   if (query.type == V4L2_CTRL_TYPE_MENU)
-   video_query_menu(dev, query.id, query.minimum, 
query.maximum);
+   if (query.type == V4L2_CTRL_TYPE_MENU ||
+   query.type == V4L2_CTRL_TYPE_INTEGER_MENU)
+   video_query_menu(dev, &query);
 
nctrls++;
}
-- 
1.7.2.5

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

[yavta PATCH 2/3] Support extended controls, including 64-bit integers.

2012-04-12 Thread Sakari Ailus 
Fall back to regular S_CTRL / G_CTRL if extended controls aren't available.

Signed-off-by: Sakari Ailus 
---
 yavta.c |  129 --
 1 files changed, 100 insertions(+), 29 deletions(-)

diff --git a/yavta.c b/yavta.c
index 8db6e1e..532fb1f 100644
--- a/yavta.c
+++ b/yavta.c
@@ -249,40 +249,104 @@ static void video_close(struct device *dev)
close(dev->fd);
 }
 
-static void uvc_get_control(struct device *dev, unsigned int id)
+static unsigned int get_control_type(struct device *dev, unsigned int id)
 {
-   struct v4l2_control ctrl;
+   struct v4l2_queryctrl query;
+   int ret;
+
+   memset(&query, 0, sizeof(query));
+
+   query.id = id;
+   ret = ioctl(dev->fd, VIDIOC_QUERYCTRL, &query);
+   if (ret == -1)
+   return V4L2_CTRL_TYPE_INTEGER;
+
+   return query.type;
+}
+
+static int get_control(struct device *dev, unsigned int id, int type,
+  int64_t *val)
+{
+   struct v4l2_ext_controls ctrls;
+   struct v4l2_ext_control ctrl;
int ret;
+   
+   memset(&ctrls, 0, sizeof(ctrls));
+   memset(&ctrl, 0, sizeof(ctrl));
+
+   ctrls.ctrl_class = V4L2_CTRL_ID2CLASS(id);
+   ctrls.count = 1;
+   ctrls.controls = &ctrl;
 
ctrl.id = id;
 
-   ret = ioctl(dev->fd, VIDIOC_G_CTRL, &ctrl);
-   if (ret < 0) {
-   printf("unable to get control: %s (%d).\n",
-   strerror(errno), errno);
-   return;
+   ret = ioctl(dev->fd, VIDIOC_G_EXT_CTRLS, &ctrls);
+   if (ret != -1) {
+   if (type == V4L2_CTRL_TYPE_INTEGER64)
+   *val = ctrl.value64;
+   else
+   *val = ctrl.value;
+   return 0;
+   }
+   if (errno == EINVAL || errno == ENOTTY) {
+   struct v4l2_control old;
+
+   old.id = id;
+   ret = ioctl(dev->fd, VIDIOC_G_CTRL, &old);
+   if (ret != -1) {
+   *val = old.value;
+   return 0;
+   }
}
 
-   printf("Control 0x%08x value %u\n", id, ctrl.value);
+   printf("unable to get control 0x%8.8x: %s (%d).\n",
+   id, strerror(errno), errno);
+   return -1;
 }
 
-static void uvc_set_control(struct device *dev, unsigned int id, int value)
+static void set_control(struct device *dev, unsigned int id, int type,
+   int64_t val)
 {
-   struct v4l2_control ctrl;
+   struct v4l2_ext_controls ctrls;
+   struct v4l2_ext_control ctrl;
+   int is_64 = type == V4L2_CTRL_TYPE_INTEGER64;
+   int64_t old_val = val;
int ret;
+   
+   memset(&ctrls, 0, sizeof(ctrls));
+   memset(&ctrl, 0, sizeof(ctrl));
+
+   ctrls.ctrl_class = V4L2_CTRL_ID2CLASS(id);
+   ctrls.count = 1;
+   ctrls.controls = &ctrl;
 
ctrl.id = id;
-   ctrl.value = value;
+   if (is_64)
+   ctrl.value64 = val;
+   else
+   ctrl.value = val;
 
-   ret = ioctl(dev->fd, VIDIOC_S_CTRL, &ctrl);
-   if (ret < 0) {
-   printf("unable to set control: %s (%d).\n",
-   strerror(errno), errno);
+   ret = ioctl(dev->fd, VIDIOC_S_EXT_CTRLS, &ctrls);
+   if (ret != -1) {
+   if (is_64)
+   val = ctrl.value64;
+   else
+   val = ctrl.value;
+   } else if (errno == EINVAL || errno == ENOTTY) {
+   struct v4l2_control old;
+
+   old.id = id;
+   ret = ioctl(dev->fd, VIDIOC_S_CTRL, &old);
+   if (ret != -1)
+   val = old.value;
+   }
+   if (ret == -1) {
+   printf("unable to set control 0x%8.8x: %s (%d).\n",
+   id, strerror(errno), errno);
return;
}
-
-   printf("Control 0x%08x set to %u, is %u\n", id, value,
-   ctrl.value);
+   
+   printf("Control 0x%08x set to %lld, is %lld\n", id, old_val, val);
 }
 
 static int video_get_format(struct device *dev)
@@ -588,7 +652,8 @@ static void video_list_controls(struct device *dev)
struct v4l2_queryctrl query;
struct v4l2_control ctrl;
unsigned int nctrls = 0;
-   char value[12];
+   char value[24];
+   int64_t val64;
int ret;
 
 #ifndef V4L2_CTRL_FLAG_NEXT_CTRL
@@ -608,18 +673,17 @@ static void video_list_controls(struct device *dev)
if (query.flags & V4L2_CTRL_FLAG_DISABLED)
continue;
 
-   ctrl.id = query.id;
-   ret = ioctl(dev->fd, VIDIOC_G_CTRL, &ctrl);
-   if (ret < 0)
-   strcpy(value, "n/a");
-   else
-   sprintf(value, "%d", ctrl.value);
-
if (query.type == V4L2_CTRL_TYPE_CTRL_CLASS) {
printf("--- %s (class 0x%0

[PATCH v2] tinyjpeg: Dynamic luminance quantization table for Pixart JPEG

2012-04-12 Thread Jean-Francois Moine 
In PJPG blocks, a marker gives the quantization tables to use for image
decoding. This patch dynamically updates the luminance table when the
marker changes.

Note that the values of this table have been guessed from a small
number of images and that they may not work fine in some situations,
but, in most cases, the images are better.

Signed-off-by: Jean-François Moine 

diff --git a/lib/libv4lconvert/tinyjpeg-internal.h 
b/lib/libv4lconvert/tinyjpeg-internal.h
index 702a2a2..4041251 100644
--- a/lib/libv4lconvert/tinyjpeg-internal.h
+++ b/lib/libv4lconvert/tinyjpeg-internal.h
@@ -103,6 +103,7 @@ struct jdec_private {
 #if SANITY_CHECK
unsigned int current_cid;   /* For planar JPEG */
 #endif
+   unsigned char marker;   /* for PJPG (Pixart JPEG) */
 
/* Temp space used after the IDCT to store each components */
uint8_t Y[64 * 4], Cr[64], Cb[64];
diff --git a/lib/libv4lconvert/tinyjpeg.c b/lib/libv4lconvert/tinyjpeg.c
index 2c2d4af..d986a45 100644
--- a/lib/libv4lconvert/tinyjpeg.c
+++ b/lib/libv4lconvert/tinyjpeg.c
@@ -1376,6 +1376,8 @@ static void decode_MCU_2x1_3planes(struct jdec_private 
*priv)
IDCT(&priv->component_infos[cCr], priv->Cr, 8);
 }
 
+static void build_quantization_table(float *qtable, const unsigned char 
*ref_table);
+
 static void pixart_decode_MCU_2x1_3planes(struct jdec_private *priv)
 {
unsigned char marker;
@@ -1384,10 +1386,8 @@ static void pixart_decode_MCU_2x1_3planes(struct 
jdec_private *priv)
/* I think the marker indicates which quantization table to use, iow
   a Pixart JPEG may have a different quantization table per MCU, most
   MCU's have 0x44 as marker for which our special Pixart quantization
-  tables are correct. Unfortunately with a 7302 some blocks also have 
0x48,
-  and sometimes even other values. As 0x48 is quite common too, we 
really
-  need to find out the correct table for that, as currently the blocks
-  with a 0x48 marker look wrong. During normal operation the marker 
stays
+  tables are correct. [jfm: snip]
+  During normal operation the marker stays
   within the range below, if it gets out of this range we're most 
likely
   decoding garbage */
if (marker < 0x20 || marker > 0x7f) {
@@ -1396,6 +1396,53 @@ static void pixart_decode_MCU_2x1_3planes(struct 
jdec_private *priv)
(unsigned int)marker);
longjmp(priv->jump_state, -EIO);
}
+
+   /* rebuild the Y quantization table when the marker changes */
+   if (marker != priv->marker) {
+   unsigned char quant_new[64];
+   int i, j;
+   /*
+* table to rebuild the Y quantization table
+*  index 1 = marker / 4
+*  index 2 = 4 end indexes in the quantization table
+*  values = 0x08, 0x10, 0x20, 0x40, 0x63
+* jfm: The values have been guessed from 4 images, so,
+*  better values may be found...
+*/
+   static const unsigned char q_tb[12][4] = {
+   { 64, 64, 64, 64 }, /* 68 */
+   {  8, 32, 64, 64 },
+   {  1, 16, 50, 64 },
+   {  1, 16, 30, 60 }, /* 80 */
+   {  1,  8, 16, 32 },
+   {  1,  4, 16, 31 },
+   {  1,  3, 16, 30 },
+   {  1,  2, 16, 21 },
+   {  1,  1, 16, 18 }, /* 100 */
+   {  1,  1, 16, 17 },
+   {  1,  1, 16, 16 },
+   {  1,  1, 15, 15 },
+   };
+
+   priv->marker = marker;
+   j = marker - 68;
+   if (j < 0)
+   j = 0;
+   j >>= 2;
+   if (j > sizeof q_tb / sizeof q_tb[0])
+   j = sizeof q_tb / sizeof q_tb[0] - 1;
+   for (i = 0; i < q_tb[j][0]; i++)
+   quant_new[i] = 0x08;
+   for (; i < q_tb[j][1]; i++)
+   quant_new[i] = 0x10;
+   for (; i < q_tb[j][2]; i++)
+   quant_new[i] = 0x20;
+   for (; i < q_tb[j][3]; i++)
+   quant_new[i] = 0x40;
+   for (; i < 64; i++)
+   quant_new[i] = 0x63;
+   build_quantization_table(priv->Q_tables[0], quant_new);
+   }
skip_nbits(priv->reservoir, priv->nbits_in_reservoir, priv->stream, 8);
 
// Y
@@ -1948,6 +1995,7 @@ static int parse_JFIF(struct jdec_private *priv, const 
unsigned char *stream)
if (!priv->default_huffman_table_initialized) {
build_quantization_table(priv->Q_tables[0], 
pixart_quantization[0]);
build_quantization_table(priv->

Re: RTL28XX driver

2012-04-12 Thread Oliver Schinagl 
Would love to,  even tried a bit, but don't really know how to start, 
what to use as a template. I think I can extract the i2c messages from 
the dreaded ugly af903 driver however, using src or usbsniff.


On 11-04-12 23:57, Antti Palosaari wrote:

On 12.04.2012 00:33, Oliver Schinagl wrote:

On 04/11/12 21:12, Antti Palosaari wrote:

I have some old stubbed drivers that just works for one frequency using
combination of RTL2832U + FC2580. Also I have rather well commented USB
sniff from that device. I can sent those if you wish.


FC2580? Do you have anything for/from that driver? My USB stick as an
AFA9035 based one, using that specific tuner.


Nothing but stubbed driver that contains static register values taken 
from the sniff and it just tunes to one channel (IIRC 634 MHz / 8 MHz 
BW).


Feel free to contribute new tuner driver in order to add support for 
your AF9035 device.


regards
Antti


--
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: RTL28XX driver

2012-04-12 Thread Thomas Mair 
Hi Oliver,

the Realtek driver sources I have also contain a fc2580 driver. Maybe
the source code will help you together with the usb sniff.

2012/4/12 Oliver Schinagl :
> Would love to,  even tried a bit, but don't really know how to start, what
> to use as a template. I think I can extract the i2c messages from the
> dreaded ugly af903 driver however, using src or usbsniff.
>
> On 11-04-12 23:57, Antti Palosaari wrote:
>>
>> On 12.04.2012 00:33, Oliver Schinagl wrote:
>>>
>>> On 04/11/12 21:12, Antti Palosaari wrote:

 I have some old stubbed drivers that just works for one frequency using
 combination of RTL2832U + FC2580. Also I have rather well commented USB
 sniff from that device. I can sent those if you wish.

>>> FC2580? Do you have anything for/from that driver? My USB stick as an
>>> AFA9035 based one, using that specific tuner.
>>
>>
>> Nothing but stubbed driver that contains static register values taken from
>> the sniff and it just tunes to one channel (IIRC 634 MHz / 8 MHz BW).
>>
>> Feel free to contribute new tuner driver in order to add support for your
>> AF9035 device.
>>
--
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: [PATCHv24 00/16] Contiguous Memory Allocator

2012-04-12 Thread cary.zou 
Hello all,
I'm using CMA to malloc contiguous memory, and I have following failure:

__alloc_contig_migrate_range: test_pages_isolated(3bc00, 3c000) failed

I try to dump_page, it shows:

page:81778620 count:1 mapcount:0 mapping: (null) index:0x88b
page flags: 0x4000()

since I am not familiar with mm, can someone give me some hint on this
failure?




于 2012年04月03日 22:10, Marek Szyprowski 写道:
> Hi,
>
> This is (yet another) update of CMA patches. I've rebased them onto
> recent v3.4-rc1 kernel tree and integrated some minor bugfixes. The
> first issue has been pointed by Sandeep Patil - alloc_contig_range
> reclaimed two times too many pages, second issue (possible mismatch
> between pageblock size and MAX_ORDER pages) has been recently spotted
> by Michal Nazarewicz.
>
> These patches are also available on my git repository:
> git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git 3.4-rc1-cma-v24
>
> Best regards
> Marek Szyprowski
> Samsung Poland R&D Center
>
> Links to previous versions of the patchset:
> v23: 
> v22: 
> v21: 
> v20: 
> v19: 
> v18: 
> v17: 
> v16: 
> v15: 
> v14: 
> v13: (internal, intentionally not released)
> v12: 
> v11: 
> v10: 
>  v9: 
>  v8: 
>  v7: 
>  v6: 
>  v5: (intentionally left out as CMA v5 was identical to CMA v4)
>  v4: 
>  v3: 
>  v2: 
>  v1: 
>
>
> Changelog:
>
> v24:
> 1. fixed handling of diffrent sizes of pageblock and MAX_ORDER size
>pages
>
> 2. fixed number of the reclaimed pages before performing the allocation
>(thanks to Sandeep Patil for pointing this issue)
>
> 3. rebased onto Linux v3.4-rc1
>
> v23:
> 1. fixed bug spotted by Aaro Koskinen (incorrect check inside VM_BUG_ON)
>
> 2. rebased onto next-20120222 tree from
>git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 
>
> v22:
> 1. Fixed compilation break caused by missing fixup patch in v21
>
> 2. Fixed typos in the comments
>
> 3. Removed superfluous #include entries
>
> v21:
> 1. Fixed incorrect check which broke memory compaction code
>
> 2. Fixed hacky and racy min_free_kbytes handling
>
> 3. Added serialization patch to watermark calculation
>
> 4. Fixed typos here and there in the comments
>
> v20 and earlier - see previous patchsets.
>
>
> Patches in this patchset:
>
> Marek Szyprowski (6):
>   mm: extract reclaim code from __alloc_pages_direct_reclaim()
>   mm: trigger page reclaim in alloc_contig_range() to stabilise
> watermarks
>   drivers: add Contiguous Memory Allocator
>   X86: integrate CMA with DMA-mapping subsystem
>   ARM: integrate CMA with DMA-mapping subsystem
>   ARM: Samsung: use CMA for 2 memory banks for s5p-mfc device
>
> Mel Gorman (1):
>   mm: Serialize access to min_free_kbytes
>
> Michal Nazarewicz (9):
>   mm: page_alloc: remove trailing whitespace
>   mm: compaction: introduce isolate_migratepages_range()
>   mm: compaction: introduce map_pages()
>   mm: compaction: introduce isolate_freepages_range()
>   mm: compaction: export some of the functions
>   mm: page_alloc: introduce alloc_contig_range()
>   mm: page_alloc: change fallbacks array handling
>   mm: mmzone: MIGRATE_CMA migration type added
>   mm: page_isolation: MIGRATE_CMA isolation functions added
>
>  Documentation/kernel-parameters.txt   |9 +
>  arch/Kconfig  |3 +
>  arch/arm/Kconfig  |2 +
>  arch/arm/include/asm/dma-contiguous.h |   15 ++
>  arch/arm/include/asm/mach/map.h   |1 +
>  arch/arm/kernel/setup.c   |9 +-
>  arch/arm/mm/dma-mapping.c |  370 --
>  arch/arm/mm/init.c|   23 ++-
>  arch/arm/mm/mm.h  |3 +
>  arch/arm/mm/mmu.c |   31 ++-
>  arch/arm/plat-s5p/dev-mfc.c   |   51 +
>  arch/x86/Kcon

Re: RTL28XX driver

2012-04-12 Thread Oliver Schinagl 
I accept the challenge :p but where is your fc2580 driver? And in that 
thought, where is antti's stub driver :)


That might help me get started :)

On 12-04-12 14:18, Thomas Mair wrote:

Hi Oliver,

the Realtek driver sources I have also contain a fc2580 driver. Maybe
the source code will help you together with the usb sniff.

2012/4/12 Oliver Schinagl:

Would love to,  even tried a bit, but don't really know how to start, what
to use as a template. I think I can extract the i2c messages from the
dreaded ugly af903 driver however, using src or usbsniff.

On 11-04-12 23:57, Antti Palosaari wrote:

On 12.04.2012 00:33, Oliver Schinagl wrote:

On 04/11/12 21:12, Antti Palosaari wrote:

I have some old stubbed drivers that just works for one frequency using
combination of RTL2832U + FC2580. Also I have rather well commented USB
sniff from that device. I can sent those if you wish.


FC2580? Do you have anything for/from that driver? My USB stick as an
AFA9035 based one, using that specific tuner.


Nothing but stubbed driver that contains static register values taken from
the sniff and it just tunes to one channel (IIRC 634 MHz / 8 MHz BW).

Feel free to contribute new tuner driver in order to add support for your
AF9035 device.


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

[PATCH] dib7000p: remove duplicate code and comment

2012-04-12 Thread Gianluca Gennari 
Remove duplicate code and comment, probably due to a patch applied twice.

Signed-off-by: Gianluca Gennari 
---
 drivers/media/dvb/frontends/dib7000p.c |5 -
 1 files changed, 0 insertions(+), 5 deletions(-)

diff --git a/drivers/media/dvb/frontends/dib7000p.c 
b/drivers/media/dvb/frontends/dib7000p.c
index 5ceadc2..3e1eefa 100644
--- a/drivers/media/dvb/frontends/dib7000p.c
+++ b/drivers/media/dvb/frontends/dib7000p.c
@@ -2396,11 +2396,6 @@ struct dvb_frontend *dib7000p_attach(struct i2c_adapter 
*i2c_adap, u8 i2c_addr,
   more common) */
st->i2c_master.gated_tuner_i2c_adap.dev.parent = i2c_adap->dev.parent;
 
-   /* FIXME: make sure the dev.parent field is initialized, or else
-  request_firmware() will hit an OOPS (this should be moved somewhere
-  more common) */
-   st->i2c_master.gated_tuner_i2c_adap.dev.parent = i2c_adap->dev.parent;
-
dibx000_init_i2c_master(&st->i2c_master, DIB7000P, st->i2c_adap, 
st->i2c_addr);
 
/* init 7090 tuner adapter */
-- 
1.7.0.4

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

Re: RTL28XX driver

2012-04-12 Thread Thomas Mair 
It is not my driver ;) And at the beginning it looks quite scary but
it may help together with the dump. You can find it
here:https://github.com/tmair/DVB-Realtek-RTL2832U-2.2.2-10tuner-mod_kernel-3.0.0/blob/master/RTL2832-2.2.2_kernel-3.0.0/tuner_fc2580.c

2012/4/12 Oliver Schinagl :
> I accept the challenge :p but where is your fc2580 driver? And in that
> thought, where is antti's stub driver :)
>
> That might help me get started :)
>
> On 12-04-12 14:18, Thomas Mair wrote:
>>
>> Hi Oliver,
>>
>> the Realtek driver sources I have also contain a fc2580 driver. Maybe
>> the source code will help you together with the usb sniff.
>>
>> 2012/4/12 Oliver Schinagl:
>>>
>>> Would love to,  even tried a bit, but don't really know how to start,
>>> what
>>> to use as a template. I think I can extract the i2c messages from the
>>> dreaded ugly af903 driver however, using src or usbsniff.
>>>
>>> On 11-04-12 23:57, Antti Palosaari wrote:

 On 12.04.2012 00:33, Oliver Schinagl wrote:
>
> On 04/11/12 21:12, Antti Palosaari wrote:
>>
>> I have some old stubbed drivers that just works for one frequency
>> using
>> combination of RTL2832U + FC2580. Also I have rather well commented
>> USB
>> sniff from that device. I can sent those if you wish.
>>
> FC2580? Do you have anything for/from that driver? My USB stick as an
> AFA9035 based one, using that specific tuner.


 Nothing but stubbed driver that contains static register values taken
 from
 the sniff and it just tunes to one channel (IIRC 634 MHz / 8 MHz BW).

 Feel free to contribute new tuner driver in order to add support for
 your
 AF9035 device.

>> --
>> 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: RTL28XX driver

2012-04-12 Thread Antti Palosaari 

On 12.04.2012 15:54, Thomas Mair wrote:

It is not my driver ;) And at the beginning it looks quite scary but
it may help together with the dump. You can find it
here:https://github.com/tmair/DVB-Realtek-RTL2832U-2.2.2-10tuner-mod_kernel-3.0.0/blob/master/RTL2832-2.2.2_kernel-3.0.0/tuner_fc2580.c

2012/4/12 Oliver Schinagl:

I accept the challenge :p but where is your fc2580 driver? And in that
thought, where is antti's stub driver :)

That might help me get started :)

On 12-04-12 14:18, Thomas Mair wrote:


Hi Oliver,

the Realtek driver sources I have also contain a fc2580 driver. Maybe
the source code will help you together with the usb sniff.

2012/4/12 Oliver Schinagl:


Would love to,  even tried a bit, but don't really know how to start,
what
to use as a template. I think I can extract the i2c messages from the
dreaded ugly af903 driver however, using src or usbsniff.

On 11-04-12 23:57, Antti Palosaari wrote:


On 12.04.2012 00:33, Oliver Schinagl wrote:


On 04/11/12 21:12, Antti Palosaari wrote:


I have some old stubbed drivers that just works for one frequency
using
combination of RTL2832U + FC2580. Also I have rather well commented
USB
sniff from that device. I can sent those if you wish.


FC2580? Do you have anything for/from that driver? My USB stick as an
AFA9035 based one, using that specific tuner.



Nothing but stubbed driver that contains static register values taken
from
the sniff and it just tunes to one channel (IIRC 634 MHz / 8 MHz BW).

Feel free to contribute new tuner driver in order to add support for
your
AF9035 device.


Here are my sniffs and stubbed driver etc. what I found from the HD. 
Those well commented sniffs, both RTL2831U and RTL2832U, are surely most 
valuable material.


http://palosaari.fi/linux/v4l-dvb/rtl283xu/

FC2580 can be found from both AF9035 and RTL2832U codes.

Generally, as coding new demod driver for example, you want to use that 
kind of stubbed tuner "driver" for example:



/* FC0011: 634 MHz / BW 8 MHz */
struct {
u8 r[8];
int len;
} regs[] = {
{{ 0x07, 0x0f }, 2 },
{{ 0x08, 0x3e }, 2 },
{{ 0x0a, 0xb8 }, 2 },
{{ 0x0b, 0x80 }, 2 },
{{ 0x0d, 0x04 }, 2 },
{{ 0x00, 0x00, 0x05, 0x11, 0xf1, 0xc7, 0x0a, 0x30 }, 8 },
{{ 0x0e, 0x80 }, 2 },
{{ 0x0e, 0x00 }, 2 },
{{ 0x0e, 0x00 }, 2 },
{{ 0x0e }, 1 },
{{ 0x06, 0x30 }, 2 },
{{ 0x0d }, 1 },
{{ 0x0d, 0x14 }, 2 },
{{ 0x10, 0x0b }, 2 },
};

for (i = 0; i < ARRAY_SIZE(regs); i++) {
		pr_debug("%s: i=%d len=%d data=%02x\n", __func__, i, regs[i].len, 
regs[i].r[0]);

struct i2c_msg msg[1] = {
{
.addr = 0x60,
.flags = 0,
.len = regs[i].len,
.buf = regs[i].r,
}
};
ret = i2c_transfer(state->i2c, msg, 1);
if (ret != 1)
			pr_debug("%s: I2C write failed i=%d len=%d data=%02x\n", __func__, i, 
regs[i].len, regs[i].r[0]);

}


regards
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] [PATCH] v4l2: use unsigned rather than enums in ioctl() structs

2012-04-12 Thread Mauro Carvalho Chehab 
Em 12-04-2012 05:04, James Courtier-Dutton escreveu:
> 2012/4/11 Rémi Denis-Courmont :
>>Hello,
>>
>> Le mercredi 11 avril 2012 20:02:00 Mauro Carvalho Chehab, vous avez écrit :
>>> Using unsigned instead of enum is not a good idea, from API POV, as
>>> unsigned has different sizes on 32 bits and 64 bits.
>>
>> Fair enough. But then we can do that instead:
>> typedef XXX __enum_t;
>> where XXX is the unsigned integer with the right number of bits. Since Linux
>> does not use short enums, this ought to work fine.
>>
>>> Yet, using enum was really a very bad idea, and, on all new stuff,
>>> we're not accepting any new enum field.
>>
>> That is unfortunately not true. You do follow that rule for new fields to
>> existing V4L2 structure. But you have been royally ignoring that rule when it
>> comes to extending existing enumerations:
>>
>> linux-media does regularly add new enum values to existing enums. That is new
>> stuff too, and every single time you do that, you do BREAK THE USERSPACE ABI.
>> This is entirely unacceptable and against established kernel development
>> policies.
>>
>> For instance, in Linux 3.1, V4L2_CTRL_TYPE_BITMASK was added. This broke
>> userspace. And there are some pending patches adding more of the same 
>> thing...
>> And V4L2_MEMORY_DMABUF will similarly break the user-to-kernel interface,
>> which is yet worse.
>>
> 
> I agree that breaking user-to-kernel interface is not advised.
> We came across a similar problem some years ago with the ALSA sound
> kernel drivers.
> The solution we used was:
> 1) If a change is likely to change the user-to-kernel API, add a new
> IOCTL for it.
> Then old userland software can use the old IOCTL, and new userland
> software can use the new IOCTL.

V4L2 API has about 80 ioctl's. Add compat code for most of them (as most have
enum's) is not fun.

Also, the issue is not that trivial. Just to give you one example:

struct v4l2_pix_format {
__u32   width;
__u32   height;
__u32   pixelformat;
enum v4l2_field field;
__u32   bytesperline;   /* for padding, zero if unused 
*/
__u32   sizeimage;
enum v4l2_colorspacecolorspace;
__u32   priv;   /* private data, depends on 
pixelformat */
};


This struct has 2 enums, and it is used by a couple structs, like this one:

struct v4l2_framebuffer {
__u32   capability;
__u32   flags;
void*base;
struct v4l2_pix_format  fmt;
};

This struct is used by a couple ioctls:

#define VIDIOC_G_FBUF_IOR('V', 10, struct v4l2_framebuffer)
#define VIDIOC_S_FBUF_IOW('V', 11, struct v4l2_framebuffer)

The better is to really replace "enum" by an integer (__u32?) at the structs,
but this will break existing apps.

One alternative would be to fork this header and add a compat layer
that would print a WARN_ONCE message, if ever reached, asking the user
to re-compile the application against the new header. 

We did that strategy in the past, appending _OLD to the legacy api ioctl's.

> 2) Add an version IOCTL that returns the current API level, so that
> the app can be written to support more than one API interface,
> depending on which kernel it is running on. The version IOCTL simply
> returns an u32 value. This is a consistent part of the user-kernel API
> that will never change.

There's one ioctl that already provides the API level, plus other info.
This ioctl doesn't contain any enum, so it is backward compatible.

> 3) Add "depreciated" compiler warnings to all the old API IOCTL calls,
> so app developers know they should be working to update their apps.

The issue here is with binaries compiled against the old headers. So, this
won't work.

> 4) After a few years, remove the old IOCTLs.
> 5) Use "uint32_t" and "uint64_t" types for all IOCTL calls, and not
> "unsigned int" or "unsigned long int".

No ioctls (well, except for 2 deprecated ones 
VIDIOC_G_JPEGCOMP/VIDIOC_S_JPEGCOMP)
are using __u8/__u32/__u64 for integers. The only issue there is with enum's.

> I.e. All structures passed in IOCTLs use fixed bit sized parameters
> for everything except of course pointers. Pointers depend on
> architecture.
> 6) Add a #if #endif around the old API, so a user compiling their own
> kernel can decide if the old API exists or not. User might want to do
> this for security reasons.

Add an #if block there will make the header very hard to deal with, as this
is already complex enough without it. The V4L2 API header has 2420 lines.
Such #if blocks will almost duplicate the header size.

I can see only two viable fixes for it:

1) add a typedef for the enum, using the sizeof(enum) in order to select the
size of the used integer.

Pros:
- Patch is easy to write/easy to review;
- Won't change the struct size, so applications compile

Re: [RFC] HDMI-CEC proposal

2012-04-12 Thread Florian Fainelli 

Hi Hans, Martin,

Sorry to jump in so late in the HDMI-CEC discussion, here are some 
comments from my perspective on your proposal:


- the HDMI-CEC implementation deserves its own bus and class of devices 
because by definition it is a physical bus, which is even electrically 
independant from the rest of the HDMI bus (A/V path)


- I don't think it is a good idea to tight it so closely to v4l, because 
one can perfectly have CEC-capable hardware without video, or at least 
not use v4l and have HDMI-CEC hardware


- it was suggested to use sockets at some point, I think it is 
over-engineered and should only lead


- processing messages in user-space is definitively the way to go, even 
input can be either re-injected using an uinput driver, or be handled in 
user-space entirely, eventually we might want to install "filters" based 
on opcodes to divert some opcodes to a kernel consumer, and the others 
to an user-space one


Right now, I have a very simple implementation that I developed for the 
company I work for which can be found here: 
https://github.com/ffainelli/linux-hdmi-cec


It is designed like this:

1) A core module, which registers a cec bus, and provides an abstraction 
for a CEC adapter (both device & driver):

- basic CEC adapter operations: logical address setting, queueing management
- counters, rx filtering
- host attaching/detaching in case the hardware is capable of 
self-processing CEC messages (for wakeup in particular)


2) A character device module, which exposes a character device per CEC 
adapter and only allows one consumer at a time and exposes the following 
ioctl's:


- SET_LOGICAL_ADDRESS
- RESET_DEVICE
- GET_COUNTERS
- SET_RX_MODE (my adapter can be set in a promiscuous mode)

the character device supports read/write/poll, which are the prefered 
ways for transfering/receiving data


3) A CEC adapter implementation which registers and calls into the core 
module when receiving a CEC message, and which the core module calls in 
response to the IOCTLs described below.


At first I thought about defining a generic netlink family in order to 
allow multiple user-space listeners receive CEC messages, but in the end 
having only one consumer per adapter device is fine by me and a more 
traditionnal approach for programmers.


I am relying on external components for knowing my HDMI physical address.

Hope this is not too late to (re)start the discussion on HDMI-CEC.

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

Re: [RFC] [PATCH] v4l2: use unsigned rather than enums in ioctl() structs

2012-04-12 Thread Rémi Denis-Courmont 
On Thu, 12 Apr 2012 11:55:12 -0300, Mauro Carvalho Chehab

 wrote:

> I can see only two viable fixes for it:

> 

> 1) add a typedef for the enum, using the sizeof(enum) in order to select

> the

> size of the used integer.

> 

> Pros:

>   - Patch is easy to write/easy to review;

>   - Won't change the struct size, so applications compiled without

> strong gcc optimization won't break;

> Cons:

>   - It will add a typedef, with is ugly;

>   - struct size on 32 bits will be different thant he size on 64 bits

> (not really an issue, as v4l2-compat32 will handle that;



On which platforms do enums occupy 64-bits? Alpha? More to the point, on

which platform is enum not the same size as unsigned?



At least on x86-64, enum is 32-bits and so is unsigned.



>   - v4l2-compat32 code may require changes.

> 

> 2) just replace it by a 32 bits integer.

> 

> Pros:

>   - no typedefs;

>   - struct size won't change between 32/64 bits (except when they also

> have pointers);

> Cons:

>   - will break ABI. So, a compat code is required;

>   - will require a "videodev2.h" fork for the legacy API with the enum's;

>   - will require a compat code to convert from enum into integer and

> vice-versa.

> 

> Comments/Votes?



-- 

Rémi Denis-Courmont

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

[PATCH 1/3] adv7180: add support to user controls

2012-04-12 Thread Federico Vaga 
Video user controls such as brightness, contrast, saturation, and
hue are now handled.

Signed-off-by: Federico Vaga 
Acked-by: Giancarlo Asnaghi 
Cc: Alan Cox 
---
 drivers/media/video/adv7180.c |  417 ++---
 1 files changed, 350 insertions(+), 67 deletions(-)

diff --git a/drivers/media/video/adv7180.c b/drivers/media/video/adv7180.c
index b8b6c4b..174bffa 100644
--- a/drivers/media/video/adv7180.c
+++ b/drivers/media/video/adv7180.c
@@ -48,6 +48,7 @@
 #define ADV7180_INPUT_CONTROL_PAL_COMB_N_PED   0xd0
 #define ADV7180_INPUT_CONTROL_PAL_SECAM0xe0
 #define ADV7180_INPUT_CONTROL_PAL_SECAM_PED0xf0
+#define ADV7180_INPUT_CONTROL_INSEL_MASK   0x0f
 
 #define ADV7180_EXTENDED_OUTPUT_CONTROL_REG0x04
 #define ADV7180_EXTENDED_OUTPUT_CONTROL_NTSCDIS0xC5
@@ -55,9 +56,29 @@
 #define ADV7180_AUTODETECT_ENABLE_REG  0x07
 #define ADV7180_AUTODETECT_DEFAULT 0x7f
 
+#define ADV7180_CON_REG0x08/*Unsigned */
+#define CON_REG_MIN0
+#define CON_REG_DEF128
+#define CON_REG_MAX255
+
+#define ADV7180_BRI_REG0x0a/*Signed */
+#define BRI_REG_MIN-128
+#define BRI_REG_DEF0
+#define BRI_REG_MAX127
+
+#define ADV7180_HUE_REG0x0b/*Signed, inverted */
+#define HUE_REG_MIN-127
+#define HUE_REG_DEF0
+#define HUE_REG_MAX128
+
 #define ADV7180_ADI_CTRL_REG   0x0e
 #define ADV7180_ADI_CTRL_IRQ_SPACE 0x20
 
+#define ADV7180_PWR_MAN_REG0x0f
+#define ADV7180_PWR_MAN_ON 0x04
+#define ADV7180_PWR_MAN_OFF0x24
+#define ADV7180_PWR_MAN_RES0x80
+
 #define ADV7180_STATUS1_REG0x10
 #define ADV7180_STATUS1_IN_LOCK0x01
 #define ADV7180_STATUS1_AUTOD_MASK 0x70
@@ -78,6 +99,12 @@
 #define ADV7180_ICONF1_PSYNC_ONLY  0x10
 #define ADV7180_ICONF1_ACTIVE_TO_CLR   0xC0
 
+#define ADV7180_SD_SAT_CB_REG  0xe3/*Unsigned */
+#define ADV7180_SD_SAT_CR_REG  0xe4/*Unsigned */
+#define SAT_REG_MIN0
+#define SAT_REG_DEF128
+#define SAT_REG_MAX255
+
 #define ADV7180_IRQ1_LOCK  0x01
 #define ADV7180_IRQ1_UNLOCK0x02
 #define ADV7180_ISR1_ADI   0x42
@@ -90,6 +117,9 @@
 #define ADV7180_IMR3_ADI   0x4C
 #define ADV7180_IMR4_ADI   0x50
 
+#define ADV7180_NTSC_V_BIT_END_REG 0xE6
+#define ADV7180_NTSC_V_BIT_END_MANUAL_NVEND0x4F
+
 struct adv7180_state {
struct v4l2_subdev  sd;
struct work_struct  work;
@@ -97,6 +127,11 @@ struct adv7180_state {
int irq;
v4l2_std_id curr_norm;
boolautodetect;
+   s8  brightness;
+   s16 hue;
+   u8  contrast;
+   u8  saturation;
+   u8  input;
 };
 
 static v4l2_std_id adv7180_std_to_v4l2(u8 status1)
@@ -155,7 +190,7 @@ static u32 adv7180_status_to_v4l2(u8 status1)
 }
 
 static int __adv7180_status(struct i2c_client *client, u32 *status,
-   v4l2_std_id *std)
+   v4l2_std_id *std)
 {
int status1 = i2c_smbus_read_byte_data(client, ADV7180_STATUS1_REG);
 
@@ -192,6 +227,36 @@ static int adv7180_querystd(struct v4l2_subdev *sd, 
v4l2_std_id *std)
return err;
 }
 
+static int adv7180_s_routing(struct v4l2_subdev *sd, u32 input,
+u32 output, u32 config)
+{
+   struct adv7180_state *state = to_state(sd);
+   int ret = mutex_lock_interruptible(&state->mutex);
+   struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+   if (ret)
+   return ret;
+
+   /*We cannot discriminate between LQFP and 40-pin LFCSP, so accept
+* all inputs and let the card driver take care of validation
+*/
+   if ((input & ADV7180_INPUT_CONTROL_INSEL_MASK) != input)
+   goto out;
+
+   ret = i2c_smbus_read_byte_data(client, ADV7180_INPUT_CONTROL_REG);
+
+   if (ret < 0)
+   goto out;
+
+   ret &= ~ADV7180_INPUT_CONTROL_INSEL_MASK;
+   ret = i2c_smbus_write_byte_data(client,
+   ADV7180_INPUT_CONTROL_REG, ret | input);
+   state->input = input;
+out:
+   mutex_unlock(&state->mutex);
+   return ret;
+}
+
 static int adv7180_g_input_status(struct v4l2_subdev *sd, u32 *status)
 {
struct adv7180_state *state = to_state(sd);
@@ -205,7 +270,7 @@ static int adv7180_g_input_status(struct v4l2_subdev *sd, 
u32 *status)
 }
 
 static int adv7180_g_chip_ident(struct v4l2_subdev *sd,
-   struct v4l2_dbg_chip_ident *chip)
+   struct v4l2_dbg_chip_ident *chip)
 {
struct i2c_client *client =

[PATCH 2/3] videobuf-dma-contig: add cache support

2012-04-12 Thread Federico Vaga 
Signed-off-by: Federico Vaga 
Acked-by: Giancarlo Asnaghi 
Cc: Alan Cox 
---
 drivers/media/video/videobuf-dma-contig.c |  199 +---
 include/media/videobuf-dma-contig.h   |   10 ++
 2 files changed, 159 insertions(+), 50 deletions(-)

diff --git a/drivers/media/video/videobuf-dma-contig.c 
b/drivers/media/video/videobuf-dma-contig.c
index c969111..b6b5cc1 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -27,6 +27,7 @@ struct videobuf_dma_contig_memory {
u32 magic;
void *vaddr;
dma_addr_t dma_handle;
+   bool cached;
unsigned long size;
 };
 
@@ -37,8 +38,58 @@ struct videobuf_dma_contig_memory {
BUG();  \
}
 
-static void
-videobuf_vm_open(struct vm_area_struct *vma)
+static int __videobuf_dc_alloc(struct device *dev,
+  struct videobuf_dma_contig_memory *mem,
+  unsigned long size, unsigned long flags)
+{
+   mem->size = size;
+   if (mem->cached) {
+   mem->vaddr = alloc_pages_exact(mem->size, flags | GFP_DMA);
+   if (mem->vaddr) {
+   int err;
+
+   mem->dma_handle = dma_map_single(dev, mem->vaddr,
+mem->size,
+DMA_FROM_DEVICE);
+   err = dma_mapping_error(dev, mem->dma_handle);
+   if (err) {
+   dev_err(dev, "dma_map_single failed\n");
+
+   free_pages_exact(mem->vaddr, mem->size);
+   mem->vaddr = 0;
+   return err;
+   }
+   }
+   } else
+   mem->vaddr = dma_alloc_coherent(dev, mem->size,
+   &mem->dma_handle, flags);
+
+   if (!mem->vaddr) {
+   dev_err(dev, "memory alloc size %ld failed\n", mem->size);
+   return -ENOMEM;
+   }
+
+   dev_dbg(dev, "dma mapped data is at %p (%ld)\n", mem->vaddr, mem->size);
+
+   return 0;
+}
+
+static void __videobuf_dc_free(struct device *dev,
+  struct videobuf_dma_contig_memory *mem)
+{
+   if (mem->cached) {
+   if (!mem->vaddr)
+   return;
+   dma_unmap_single(dev, mem->dma_handle, mem->size,
+DMA_FROM_DEVICE);
+   free_pages_exact(mem->vaddr, mem->size);
+   } else
+   dma_free_coherent(dev, mem->size, mem->vaddr, mem->dma_handle);
+
+   mem->vaddr = NULL;
+}
+
+static void videobuf_vm_open(struct vm_area_struct *vma)
 {
struct videobuf_mapping *map = vma->vm_private_data;
 
@@ -91,12 +142,11 @@ static void videobuf_vm_close(struct vm_area_struct *vma)
dev_dbg(q->dev, "buf[%d] freeing %p\n",
i, mem->vaddr);
 
-   dma_free_coherent(q->dev, mem->size,
- mem->vaddr, mem->dma_handle);
+   __videobuf_dc_free(q->dev, mem);
mem->vaddr = NULL;
}
 
-   q->bufs[i]->map   = NULL;
+   q->bufs[i]->map = NULL;
q->bufs[i]->baddr = 0;
}
 
@@ -107,8 +157,8 @@ static void videobuf_vm_close(struct vm_area_struct *vma)
 }
 
 static const struct vm_operations_struct videobuf_vm_ops = {
-   .open = videobuf_vm_open,
-   .close= videobuf_vm_close,
+   .open   = videobuf_vm_open,
+   .close  = videobuf_vm_close,
 };
 
 /**
@@ -178,26 +228,38 @@ static int videobuf_dma_contig_user_get(struct 
videobuf_dma_contig_memory *mem,
pages_done++;
}
 
- out_up:
+out_up:
up_read(¤t->mm->mmap_sem);
 
return ret;
 }
 
-static struct videobuf_buffer *__videobuf_alloc_vb(size_t size)
+static struct videobuf_buffer *__videobuf_alloc_vb(size_t size, bool cached)
 {
struct videobuf_dma_contig_memory *mem;
struct videobuf_buffer *vb;
 
vb = kzalloc(size + sizeof(*mem), GFP_KERNEL);
if (vb) {
-   mem = vb->priv = ((char *)vb) + size;
+   vb->priv = ((char *)vb) + size;
+   mem = vb->priv;
mem->magic = MAGIC_DC_MEM;
+   mem->cached = cached;
}
 
return vb;
 }
 
+static struct videobuf_buffer *__videobuf_alloc_uncached(size_t size)
+{
+   return __videobuf_alloc_vb(size, false);
+}
+
+static struct videobuf_buffer *__videobuf_alloc_cached(size_t size)
+{
+   return __videobuf_alloc_vb(size, true);
+}
+
 static void *__videobuf_to_vaddr(struct videobuf_buffer *buf)

[PATCH 3/3] STA2X11 VIP: new V4L2 driver

2012-04-12 Thread Federico Vaga 
V4L2 driver for the Video Input Port within STA2X11 board

Signed-off-by: Federico Vaga 
Acked-by: Giancarlo Asnaghi 
Cc: Alan Cox 
---
 drivers/media/video/Kconfig   |   13 +
 drivers/media/video/Makefile  |1 +
 drivers/media/video/sta2x11_vip.c | 1550 +
 drivers/media/video/sta2x11_vip.h |   40 +
 4 files changed, 1604 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/sta2x11_vip.c
 create mode 100644 drivers/media/video/sta2x11_vip.h

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f2479c5..32c6c0e 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -794,6 +794,19 @@ source "drivers/media/video/saa7164/Kconfig"
 
 source "drivers/media/video/zoran/Kconfig"
 
+config STA2X11_VIP
+   tristate "STA2X11 VIP Video For Linux"
+   depends on STA2X11
+   select VIDEO_ADV7180 if VIDEO_HELPER_CHIPS_AUTO
+   select VIDEOBUF_DMA_CONTIG
+   depends on PCI && VIDEO_V4L2 && VIRT_TO_BUS
+   help
+ Say Y for support for STA2X11 VIP (Video Input Port) capture
+ device.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sta2x11_vip.
+
 endif # V4L_PCI_DRIVERS
 
 #
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index a6282a3..2a05b9a 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_VIDEO_TM6000) += tm6000/
 obj-$(CONFIG_VIDEO_MXB) += mxb.o
 obj-$(CONFIG_VIDEO_HEXIUM_ORION) += hexium_orion.o
 obj-$(CONFIG_VIDEO_HEXIUM_GEMINI) += hexium_gemini.o
+obj-$(CONFIG_STA2X11_VIP) += sta2x11_vip.o
 obj-$(CONFIG_VIDEO_TIMBERDALE) += timblogiw.o
 
 obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
diff --git a/drivers/media/video/sta2x11_vip.c 
b/drivers/media/video/sta2x11_vip.c
new file mode 100644
index 000..636643f
--- /dev/null
+++ b/drivers/media/video/sta2x11_vip.c
@@ -0,0 +1,1550 @@
+/*
+ * This is the driver for the STA2x11 Video Input Port.
+ *
+ * Copyright (C) 2010   WindRiver Systems, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
+ *
+ * Author: Andreas Kies 
+ * Vlad Lungu 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sta2x11_vip.h"
+
+#define DRV_NAME "sta2x11_vip"
+#define DRV_VERSION "1.3"
+
+#ifndef PCI_DEVICE_ID_STMICRO_VIP
+#define PCI_DEVICE_ID_STMICRO_VIP 0xCC0D
+#endif
+
+#define MAX_FRAMES 4
+
+/*Register offsets*/
+#define DVP_CTL0x00
+#define DVP_TFO0x04
+#define DVP_TFS0x08
+#define DVP_BFO0x0C
+#define DVP_BFS0x10
+#define DVP_VTP 0x14
+#define DVP_VBP 0x18
+#define DVP_VMP0x1C
+#define DVP_ITM0x98
+#define DVP_ITS0x9C
+#define DVP_STA0xA0
+#define DVP_HLFLN  0xA8
+#define DVP_RGB0xC0
+#define DVP_PKZ0xF0
+
+/*Register fields*/
+#define DVP_CTL_ENA0x0001
+#define DVP_CTL_RST0x8000
+#define DVP_CTL_DIS(~0x00040001)
+
+#define DVP_IT_VSB 0x0008
+#define DVP_IT_VST 0x0010
+#define DVP_IT_FIFO0x0020
+
+#define DVP_HLFLN_SD   0x0001
+
+#define REG_WRITE(vip, reg, value) iowrite32((value), (vip->iomem)+(reg))
+#define REG_READ(vip, reg) ioread32((vip->iomem)+(reg))
+
+#define SAVE_COUNT 8
+#define AUX_COUNT 3
+#define IRQ_COUNT 1
+
+/**
+ * struct sta2x11_vip - All internal data for one instance of device
+ * @v4l2_dev: device registered in v4l layer
+ * @video_dev: properties of our device
+ * @pdev: PCI device
+ * @adapter: contains I2C adapter information
+ * @register_save_area: All relevant register are saved here during suspend
+ * @decoder: contains information about video DAC
+ * @format: pixel format, fixed UYVY
+ * @std: video standard (e.g. PAL/NTSC)
+ * @input: input line for video signal ( 0 or 1 )
+ * @users: Number of open of device ( max. 1 )
+ * @disabled: Device is in power down state
+ * @mutex: ensures exclusive opening of device
+ * @

Re: [RFC] [PATCH] v4l2: use unsigned rather than enums in ioctl() structs

2012-04-12 Thread Nick Bowler 
On 2012-04-11 23:32 +0300, Rémi Denis-Courmont wrote:
> From the perspective of the compiler, this is a feature not a bug. In
> C and C++, loading or storing a value in an enumerated variable
> whereby the value is not a member of the enumeration is undefined.

I'm afraid that this is not the case in C, although it may be in C++
(enums are very different in C++ than they are in C).  In C, enum types
are required to be compatible with some integer type capable of storing
the values of all the enum members (see C11§6.7.2.2#4).  Compatibility
is a very strong condition, and implies that the two types are
interchangable without affecting the meaning of the program (see
C11§6.2.7).  Integer types have a number of specific requirements, one
thing that's relevant here is that they do not have "holes" in their
representable values: there is a minimum and maximum representable
value, and all integers between them are representable (C11§6.2.6.2#1).

Thus, while the choice of integer type used may depend on the values of
the corresponding enum constants, storing any value (regardless of
whether or not its a member of the enumeration) is subject to the same
rules as the implementation-defined compatbile integer type.  This is
always well-defined for values within the range of the type.
(C11§6.3.1.3#1 and C11§6.3.1.4#1).

> In other words, the compiler can assume that this does not happen, and
> optimize it away.

No, a conforming C compiler cannot assume such assignments do not
happen, for the reasons outlined above.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

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

cron job: media_tree daily build: ERRORS

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

Results of the daily build of media_tree:

date:Thu Apr 12 19:00:22 CEST 2012
git hash:976a87b9ce3172065e21f0d136353a01df06d0d6
gcc version:  i686-linux-gcc (GCC) 4.6.3
host hardware:x86_64
host os:  3.1-2.slh.1-amd64

linux-git-arm-eabi-exynos: WARNINGS
linux-git-arm-eabi-omap: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: ERRORS
linux-2.6.33-i686: ERRORS
linux-2.6.34-i686: ERRORS
linux-2.6.35.3-i686: ERRORS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: WARNINGS
linux-3.1-i686: WARNINGS
linux-3.2.1-i686: WARNINGS
linux-3.3-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: ERRORS
linux-2.6.33-x86_64: ERRORS
linux-2.6.34-x86_64: ERRORS
linux-2.6.35.3-x86_64: ERRORS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2.1-x86_64: WARNINGS
linux-3.3-x86_64: WARNINGS
apps: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

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

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

Re: [RFC] HDMI-CEC proposal

2012-04-12 Thread Oliver Schinagl 
Since a lot of video cards dont' support CEC at all (not even 
connected), don't have hdmi, but work perfectly fine with dvi->hdmi 
adapters, CEC can be implemented in many other ways (think media centers)


One such exammple is using USB/Arduino

http://code.google.com/p/cec-arduino/wiki/ElectricalInterface

Having an AVR with v-usb code and cec code doesn't look all that hard 
nor impossible, so one could simply have a USB plug on one end, and an 
HDMI plug on the other end, utilizing only the CEC pins.


This would make it more something like LIRC if anything.

On 04/12/12 17:24, Florian Fainelli wrote:

Hi Hans, Martin,

Sorry to jump in so late in the HDMI-CEC discussion, here are some
comments from my perspective on your proposal:

- the HDMI-CEC implementation deserves its own bus and class of devices
because by definition it is a physical bus, which is even electrically
independant from the rest of the HDMI bus (A/V path)

- I don't think it is a good idea to tight it so closely to v4l, because
one can perfectly have CEC-capable hardware without video, or at least
not use v4l and have HDMI-CEC hardware

- it was suggested to use sockets at some point, I think it is
over-engineered and should only lead

- processing messages in user-space is definitively the way to go, even
input can be either re-injected using an uinput driver, or be handled in
user-space entirely, eventually we might want to install "filters" based
on opcodes to divert some opcodes to a kernel consumer, and the others
to an user-space one

Right now, I have a very simple implementation that I developed for the
company I work for which can be found here:
https://github.com/ffainelli/linux-hdmi-cec

It is designed like this:

1) A core module, which registers a cec bus, and provides an abstraction
for a CEC adapter (both device & driver):
- basic CEC adapter operations: logical address setting, queueing
management
- counters, rx filtering
- host attaching/detaching in case the hardware is capable of
self-processing CEC messages (for wakeup in particular)

2) A character device module, which exposes a character device per CEC
adapter and only allows one consumer at a time and exposes the following
ioctl's:

- SET_LOGICAL_ADDRESS
- RESET_DEVICE
- GET_COUNTERS
- SET_RX_MODE (my adapter can be set in a promiscuous mode)

the character device supports read/write/poll, which are the prefered
ways for transfering/receiving data

3) A CEC adapter implementation which registers and calls into the core
module when receiving a CEC message, and which the core module calls in
response to the IOCTLs described below.

At first I thought about defining a generic netlink family in order to
allow multiple user-space listeners receive CEC messages, but in the end
having only one consumer per adapter device is fine by me and a more
traditionnal approach for programmers.

I am relying on external components for knowing my HDMI physical address.

Hope this is not too late to (re)start the discussion on HDMI-CEC.

Thank you very much.
--
Florian
--
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

cron job: media_tree daily build: ERRORS

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

Results of the daily build of media_tree:

date:Thu Apr 12 22:10:05 CEST 2012
git hash:f4d4e7656b26a6013bc5072c946920d2e2c44e8e
gcc version:  i686-linux-gcc (GCC) 4.6.3
host hardware:x86_64
host os:  3.1-2.slh.1-amd64

linux-git-arm-eabi-exynos: WARNINGS
linux-git-arm-eabi-omap: ERRORS
linux-git-armv5-ixp: WARNINGS
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: ERRORS
linux-2.6.32.6-i686: ERRORS
linux-2.6.33-i686: ERRORS
linux-2.6.34-i686: ERRORS
linux-2.6.35.3-i686: ERRORS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: OK
linux-3.1-i686: OK
linux-3.2.1-i686: OK
linux-3.3-i686: WARNINGS
linux-2.6.31.12-x86_64: ERRORS
linux-2.6.32.6-x86_64: ERRORS
linux-2.6.33-x86_64: ERRORS
linux-2.6.34-x86_64: ERRORS
linux-2.6.35.3-x86_64: ERRORS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2.1-x86_64: WARNINGS
linux-3.3-x86_64: WARNINGS
apps: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.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

[PATCH linux-next] staging: go7007: Add MODULE_FIRMWARE

2012-04-12 Thread Tim Gardner 
Cc: Mauro Carvalho Chehab 
Cc: Greg Kroah-Hartman 
Cc: linux-media@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Signed-off-by: Tim Gardner 
---
 drivers/staging/media/go7007/s2250-loader.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/media/go7007/s2250-loader.c 
b/drivers/staging/media/go7007/s2250-loader.c
index 4e13251..829c248 100644
--- a/drivers/staging/media/go7007/s2250-loader.c
+++ b/drivers/staging/media/go7007/s2250-loader.c
@@ -189,3 +189,5 @@ module_exit(s2250loader_cleanup);
 MODULE_AUTHOR("");
 MODULE_DESCRIPTION("firmware loader for Sensoray 2250/2251");
 MODULE_LICENSE("GPL v2");
+MODULE_FIRMWARE(S2250_LOADER_FIRMWARE);
+MODULE_FIRMWARE(S2250_FIRMWARE);
-- 
1.7.9.5

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

[PATCH linux-next] video: vicam: Add MODULE_FIRMWARE

2012-04-12 Thread Tim Gardner 
Cc: Jean-Francois Moine 
Cc: Mauro Carvalho Chehab 
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner 
---
 drivers/media/video/gspca/vicam.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/video/gspca/vicam.c 
b/drivers/media/video/gspca/vicam.c
index 911152e..e48ec4d 100644
--- a/drivers/media/video/gspca/vicam.c
+++ b/drivers/media/video/gspca/vicam.c
@@ -37,9 +37,12 @@
 #include 
 #include "gspca.h"
 
+#define VICAM_FIRMWARE "vicam/firmware.fw"
+
 MODULE_AUTHOR("Hans de Goede ");
 MODULE_DESCRIPTION("GSPCA ViCam USB Camera Driver");
 MODULE_LICENSE("GPL");
+MODULE_FIRMWARE(VICAM_FIRMWARE);
 
 enum e_ctrl {
GAIN,
@@ -268,7 +271,7 @@ static int sd_init(struct gspca_dev *gspca_dev)
const struct firmware *uninitialized_var(fw);
u8 *firmware_buf;
 
-   ret = request_ihex_firmware(&fw, "vicam/firmware.fw",
+   ret = request_ihex_firmware(&fw, VICAM_FIRMWARE,
&gspca_dev->dev->dev);
if (ret) {
pr_err("Failed to load \"vicam/firmware.fw\": %d\n", ret);
-- 
1.7.9.5

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

Re: [RFC] HDMI-CEC proposal

2012-04-12 Thread Hans Verkuil 
You both hit the main problem of the CEC support: how to implement the API.

Cisco's work on CEC has been stalled as we first want to get HDMI support in
V4L. Hopefully that will happen in the next few months. After that we will
resume working on the CEC API.

Regards,

Hans

On Thursday, April 12, 2012 22:36:55 Oliver Schinagl wrote:
> Since a lot of video cards dont' support CEC at all (not even 
> connected), don't have hdmi, but work perfectly fine with dvi->hdmi 
> adapters, CEC can be implemented in many other ways (think media centers)
> 
> One such exammple is using USB/Arduino
> 
> http://code.google.com/p/cec-arduino/wiki/ElectricalInterface
> 
> Having an AVR with v-usb code and cec code doesn't look all that hard 
> nor impossible, so one could simply have a USB plug on one end, and an 
> HDMI plug on the other end, utilizing only the CEC pins.
> 
> This would make it more something like LIRC if anything.
> 
> On 04/12/12 17:24, Florian Fainelli wrote:
> > Hi Hans, Martin,
> >
> > Sorry to jump in so late in the HDMI-CEC discussion, here are some
> > comments from my perspective on your proposal:
> >
> > - the HDMI-CEC implementation deserves its own bus and class of devices
> > because by definition it is a physical bus, which is even electrically
> > independant from the rest of the HDMI bus (A/V path)
> >
> > - I don't think it is a good idea to tight it so closely to v4l, because
> > one can perfectly have CEC-capable hardware without video, or at least
> > not use v4l and have HDMI-CEC hardware
> >
> > - it was suggested to use sockets at some point, I think it is
> > over-engineered and should only lead
> >
> > - processing messages in user-space is definitively the way to go, even
> > input can be either re-injected using an uinput driver, or be handled in
> > user-space entirely, eventually we might want to install "filters" based
> > on opcodes to divert some opcodes to a kernel consumer, and the others
> > to an user-space one
> >
> > Right now, I have a very simple implementation that I developed for the
> > company I work for which can be found here:
> > https://github.com/ffainelli/linux-hdmi-cec
> >
> > It is designed like this:
> >
> > 1) A core module, which registers a cec bus, and provides an abstraction
> > for a CEC adapter (both device & driver):
> > - basic CEC adapter operations: logical address setting, queueing
> > management
> > - counters, rx filtering
> > - host attaching/detaching in case the hardware is capable of
> > self-processing CEC messages (for wakeup in particular)
> >
> > 2) A character device module, which exposes a character device per CEC
> > adapter and only allows one consumer at a time and exposes the following
> > ioctl's:
> >
> > - SET_LOGICAL_ADDRESS
> > - RESET_DEVICE
> > - GET_COUNTERS
> > - SET_RX_MODE (my adapter can be set in a promiscuous mode)
> >
> > the character device supports read/write/poll, which are the prefered
> > ways for transfering/receiving data
> >
> > 3) A CEC adapter implementation which registers and calls into the core
> > module when receiving a CEC message, and which the core module calls in
> > response to the IOCTLs described below.
> >
> > At first I thought about defining a generic netlink family in order to
> > allow multiple user-space listeners receive CEC messages, but in the end
> > having only one consumer per adapter device is fine by me and a more
> > traditionnal approach for programmers.
> >
> > I am relying on external components for knowing my HDMI physical address.
> >
> > Hope this is not too late to (re)start the discussion on HDMI-CEC.
> >
> > Thank you very much.
> > --
> > Florian
> > --
> > 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
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: ERRORS

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

Results of the daily build of media_tree:

date:Fri Apr 13 06:55:22 CEST 2012
git hash:f4d4e7656b26a6013bc5072c946920d2e2c44e8e
gcc version:  i686-linux-gcc (GCC) 4.6.3
host hardware:x86_64
host os:  3.1-2.slh.1-amd64

linux-git-arm-eabi-exynos: WARNINGS
linux-git-arm-eabi-omap: ERRORS
linux-git-armv5-ixp: WARNINGS
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-x86_64: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-i686: WARNINGS
linux-2.6.35.3-i686: WARNINGS
linux-2.6.36-i686: WARNINGS
linux-2.6.37-i686: WARNINGS
linux-2.6.38.2-i686: WARNINGS
linux-2.6.39.1-i686: WARNINGS
linux-3.0-i686: OK
linux-3.1-i686: OK
linux-3.2.1-i686: OK
linux-3.3-i686: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35.3-x86_64: WARNINGS
linux-2.6.36-x86_64: WARNINGS
linux-2.6.37-x86_64: WARNINGS
linux-2.6.38.2-x86_64: WARNINGS
linux-2.6.39.1-x86_64: WARNINGS
linux-3.0-x86_64: WARNINGS
linux-3.1-x86_64: WARNINGS
linux-3.2.1-x86_64: WARNINGS
linux-3.3-x86_64: WARNINGS
apps: WARNINGS
spec-git: WARNINGS
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.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