Re: [PATCH/RFC 1/1] Add a libv4l plugin for Exynos4 camera

2014-10-09 Thread Jacek Anaszewski 

On 10/08/2014 05:49 PM, Antonio Ospite wrote:

On Wed, 08 Oct 2014 15:22:43 +0200
Jacek Anaszewski  wrote:


Hi Hans,

On 10/08/2014 02:42 PM, Hans de Goede wrote:

Hi,

On 10/08/2014 10:46 AM, Jacek Anaszewski wrote:

The plugin provides support for the media device on Exynos4 SoC.
Added is also a media device configuration file parser.
The media configuration file is used for conveying information
about media device links that need to be established as well
as V4L2 user control ioctls redirection to a particular
sub-device.

The plugin performs single plane <-> multi plane API conversion,
video pipeline linking and takes care of automatic data format
negotiation for the whole pipeline, after intercepting
VIDIOC_S_FMT or VIDIOC_TRY_FMT ioctls.

Signed-off-by: Jacek Anaszewski 
Acked-by: Kyungmin Park 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
---
   configure.ac   |1 +
   lib/Makefile.am|5 +-
   lib/libv4l-exynos4-camera/Makefile.am  |7 +
   .../libv4l-devconfig-parser.h  |  145 ++
   lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c  | 2486 

   5 files changed, 2642 insertions(+), 2 deletions(-)
   create mode 100644 lib/libv4l-exynos4-camera/Makefile.am
   create mode 100644 lib/libv4l-exynos4-camera/libv4l-devconfig-parser.h
   create mode 100644 lib/libv4l-exynos4-camera/libv4l-exynos4-camera.c


Ugh, that is a big plugin. Can you please split out the parser stuff
into a separate file ?


Yes, I tried to split it, but spent so much time fighting with
autotools, that I decided to submit it in this form and ask
more experienced v4l-utils build system maintainers for the advice.
I mentioned this in the cover letter.



What autotools issue in particular?
The following change followed by "automake && ./configure" should be
enough to add a new file libv4l-devconfig-parser.c:


The same modifications produced libv4l-exynos4-camera.so without parser 
symbols, when I applied them previously, but when I tried them again

everything is ok. Probably I wasn't doing proper cleanup.
Thanks for the hints.

Best Regards,
Jacek Anaszewski
--
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/RFC 1/1] Add a libv4l plugin for Exynos4 camera

2014-10-09 Thread Hans de Goede 
Hi,

On 10/08/2014 03:22 PM, Jacek Anaszewski wrote:
> Hi Hans,
> 
> On 10/08/2014 02:42 PM, Hans de Goede wrote:



>>> +}
>>> +
>>> +/* refresh device topology data after linking */
>>> +release_entities(mdev);
>>> +
>>> +ret = get_device_topology(mdev);
>>> +
>>> +/* close media device fd as it won't be longer required */
>>> +close(mdev->media_fd);
>>> +
>>> +if (ret < 0)
>>> +goto err_get_dev_topology;
>>> +
>>> +/* discover a pipeline for the capture device */
>>> +ret = discover_pipeline_by_fd(mdev, fd);
>>> +if (ret < 0)
>>> +goto err_discover_pipeline;
>>
>> There does not seem to be any code here to ensure that this plugin does
>> not bind to non exonys4 fimc devices. Please fix that.
> 
> There is. Please look above at the
> 
> "if (!capture_entity(media_entity_name))" condition above.

I already checked that, that just checks for the string "capture", which is
way too generic, please add a more narrow guard.

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: [PATCH v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.

2014-10-09 Thread Kamil Debski 
Hi,

> From: Nicolas Dufresne [mailto:nicolas.dufre...@collabora.com]
> Sent: Wednesday, October 08, 2014 4:35 PM
> 
> 
> Le 2014-10-08 06:24, Kamil Debski a écrit :
> > Hi,
> >
> > This patch seems complicated and I do not understand your motives.
> >
> > Could you explain what is the problem with the current aligning of
> the
> > values?
> > Is this a hardware problem? Which MFC version does it affect?
> > Is it a software problem? If so, maybe the user space application
> should
> > take extra care on what value it passes/receives to try_fmt?
> This looks like something I wanted to bring here as an RFC but never
> manage to get the time. In an Odroid Integration we have started using
> the following simple patch to work around this:
> 
> https://github.com/dsd/linux-
> odroid/commit/c76b38c1d682b9870ea3b00093ad6500a9c5f5f6
> 
> The context is that right now we have decided that alignment in s_fmt
> shall be done with a closest rounding. So the format returned may be
> bigger, or smaller, that's basically random. I've been digging through
> a
> lot, and so far I have found no rational that explains this choice
> other
> that this felt right.
> 
> In real life, whenever the resulting format is smaller then request,
> there is little we can do other then fail or try again blindly other
> sizes. But with bigger raw buffers, we can use zero-copy  cropping
> techniques to keep going. Here's a example:
> 
> image_generator -> hw_converter -> display
> 
> As hw_converter is a V4L2 M2M, an ideal use case here would be for
> image_generator to use buffers from the hw_converter. For the scenario,
> it is likely that a fixed video size is wanted, but this size is also
> likely not to match HW requirement. If hw_converter decide to give back
> something smaller, there is nothing image_generator can do. It would
> have to try again with random size to find out that best match. It's a
> bit silly to force that on application, as the hw_converter know the
> closest best match, which is simply the next valid bigger size if that
> exist.
> 
> hope that helps,
> Nicolas

Nicolas, thank you for shedding light on this problem. I see that it is
not MFC specific. It seems that the problem applies to all Video4Linux2
devices that use v4l_bound_align_image. I agree with you that this deservers
an RFC and some discussion as this would change the behaviour of quite
a few drivers. 

I think the documentation does not specify how TRY_FMT/S_FMT should adjust
the parameters. Maybe it would a good idea to add some flagS that determine
the behaviour?

Best wishes,
-- 
Kamil Debski
Samsung R&D Institute Poland


--
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-next: Tree for Oct 8 (media/usb/gspca)

2014-10-09 Thread Mauro Carvalho Chehab 
Em Thu, 09 Oct 2014 08:45:28 +0200
Paul Bolle  escreveu:

> On Wed, 2014-10-08 at 22:50 -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 08 Oct 2014 13:53:33 -0700
> > Randy Dunlap  escreveu:
> > > On 10/08/14 11:31, Mauro Carvalho Chehab wrote:
> > > > From gpsca's PoV, IMHO, it should be fine to disable the webcam buttons 
> > > > if
> > > > the webcam was compiled as builtin and the input subsystem is compiled 
> > > > as 
> > > > module. The core feature expected on a camera is to capture streams. 
> > > > Buttons are just a plus.
> > > > 
> > > > Also, most cams don't even have buttons. The gspca subdriver has 
> > > > support 
> > > > for buttons for the few models that have it.
> > > > 
> > > > So, IMHO, it should be ok to have GSPCA=y and INPUT=m, provided that 
> > > > the buttons will be disabled.
> > > 
> > > Then all of the sub-drivers that use IS_ENABLED(CONFIG_INPUT) should be
> > > changed to use IS_BUILTIN(CONFIG_INPUT).
> > > 
> > > But that is too restrictive IMO.  The input subsystem will work fine when
> > > CONFIG_INPUT=m and the GSPCA drivers are also loadable modules.
> > 
> > Agreed.
> > 
> > Maybe the solution would be something more complex like 
> > (for drivers/media/usb/gspca/zc3xx.c):
> > 
> > #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && 
> > !IS_BUILTIN(CONFIG_USB_GSPCA_ZC3XX))
> 
> The above discussion meanders a bit, and I just stumbled onto it, but
> would
> #if IS_BUILTIN(CONFIG_INPUT) || (IS_MODULE(CONFIG_INPUT) && 
> defined(MODULE))
> 
> cover your requirements when using macros?

No. What we need to do, for all gspca sub-drivers that have optional
support for buttons is to only enable the buttons support if:

CONFIG_INPUT=y
or
CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=m

If we use a reverse logic, we need to disable the code if:
# CONFIG_INPUT is not set
or
CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=y

The rationale for disabling the code on the last expression is that a
builtin code cannot call a function inside a module.

Also, as the submodule is already being compiled, we know that
CONFIG_USB_GSPCA_submodule is either module or builtin.

So, either one of those expressions should work:
#if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && 
!IS_BUILTIN(CONFIG_USB_GSPCA_submodule))
or
#if (IS_BUILTIN(CONFIG_INPUT)) || (IS_MODULE(CONFIG_INPUT) && 
IS_MODULE(CONFIG_USB_GSPCA_submodule) && defined(MODULE))
or
#if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && 
IS_MODULE(CONFIG_USB_GSPCA_submodule))

> 
> > Probably the best would be to write another macro that would evaluate
> > like the above.
> 
> 
> Paul Bolle
> 
--
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-next: Tree for Oct 8 (media/usb/gspca)

2014-10-09 Thread Paul Bolle 
On Thu, 2014-10-09 at 07:30 -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 09 Oct 2014 08:45:28 +0200
> Paul Bolle  escreveu:
> > The above discussion meanders a bit, and I just stumbled onto it, but
> > would
> > #if IS_BUILTIN(CONFIG_INPUT) || (IS_MODULE(CONFIG_INPUT) && 
> > defined(MODULE))
> > 
> > cover your requirements when using macros?
> 
> No. What we need to do, for all gspca sub-drivers that have optional
> support for buttons is to only enable the buttons support if:
> 
>   CONFIG_INPUT=y
> or
>   CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=m
> 
> If we use a reverse logic, we need to disable the code if:
>   # CONFIG_INPUT is not set
> or
>   CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=y
> 
> The rationale for disabling the code on the last expression is that a
> builtin code cannot call a function inside a module.
> 
> Also, as the submodule is already being compiled, we know that
> CONFIG_USB_GSPCA_submodule is either module or builtin.
> 
> So, either one of those expressions should work:
>   #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && 
> !IS_BUILTIN(CONFIG_USB_GSPCA_submodule))
> or
>   #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_MODULE(CONFIG_INPUT) && 
> IS_MODULE(CONFIG_USB_GSPCA_submodule) && defined(MODULE))

I thought MODULE was only defined for code that will be part of a
module. So "IS_MODULE(CONFIG_USB_GSPCA_submodule)" and "defined(MODULE)"
should be equal when used _inside_ [...]/usb/gspca/that_submodule.c,
shouldn't they? That would make this option basically identical to my
suggestion. Or are you thinking about using these tests outside of these
submodules themselves?

> or
>   #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && 
> IS_MODULE(CONFIG_USB_GSPCA_submodule))

I think it's clearer to use
IS_BUILTIN(CONFIG_FOO) || (IS_MODULE(CONFIG_FOO) && [...])

Ditto above. Perhaps just a matter of taste.

(Depending on INPUT is apparently not possible for these submodules. So
obviously any solution needs to check whether input is available, say
like
if (IS_MODULE(CONFIG_INPUT))
if (!is_input_loaded())
goto no_input;

Doesn't it?)

Thanks,


Paul Bolle

--
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-next: Tree for Oct 8 (media/usb/gspca)

2014-10-09 Thread Mauro Carvalho Chehab 
Em Thu, 09 Oct 2014 13:26:10 +0200
Paul Bolle  escreveu:

> On Thu, 2014-10-09 at 07:30 -0300, Mauro Carvalho Chehab wrote:
> > Em Thu, 09 Oct 2014 08:45:28 +0200
> > Paul Bolle  escreveu:
> > > The above discussion meanders a bit, and I just stumbled onto it, but
> > > would
> > > #if IS_BUILTIN(CONFIG_INPUT) || (IS_MODULE(CONFIG_INPUT) && 
> > > defined(MODULE))
> > > 
> > > cover your requirements when using macros?
> > 
> > No. What we need to do, for all gspca sub-drivers that have optional
> > support for buttons is to only enable the buttons support if:
> > 
> > CONFIG_INPUT=y
> > or
> > CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=m
> > 
> > If we use a reverse logic, we need to disable the code if:
> > # CONFIG_INPUT is not set
> > or
> > CONFIG_INPUT=m and CONFIG_USB_GSPCA_submodule=y
> > 
> > The rationale for disabling the code on the last expression is that a
> > builtin code cannot call a function inside a module.
> > 
> > Also, as the submodule is already being compiled, we know that
> > CONFIG_USB_GSPCA_submodule is either module or builtin.
> > 
> > So, either one of those expressions should work:
> > #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && 
> > !IS_BUILTIN(CONFIG_USB_GSPCA_submodule))
> > or
> > #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_MODULE(CONFIG_INPUT) && 
> > IS_MODULE(CONFIG_USB_GSPCA_submodule) && defined(MODULE))
> 
> I thought MODULE was only defined for code that will be part of a
> module. So "IS_MODULE(CONFIG_USB_GSPCA_submodule)" and "defined(MODULE)"
> should be equal when used _inside_ [...]/usb/gspca/that_submodule.c,

Ah, I didn't know that. In such case, your suggestion is indeed better,
as it is easier to write the patch.

> shouldn't they? That would make this option basically identical to my
> suggestion. Or are you thinking about using these tests outside of these
> submodules themselves?

> 
> > or
> > #if (IS_BUILTIN(CONFIG_INPUT)) || (IS_ENABLED(CONFIG_INPUT) && 
> > IS_MODULE(CONFIG_USB_GSPCA_submodule))
> 
> I think it's clearer to use
> IS_BUILTIN(CONFIG_FOO) || (IS_MODULE(CONFIG_FOO) && [...])
> 
> Ditto above. Perhaps just a matter of taste.
> 
> (Depending on INPUT is apparently not possible for these submodules. 

No, because the main functionality (webcam support) doesn't depend on
INPUT.

> So
> obviously any solution needs to check whether input is available, say
> like
> if (IS_MODULE(CONFIG_INPUT))
> if (!is_input_loaded())
> goto no_input;
> 
> Doesn't it?)

Yeah, but the thing is that it breaks at compilation time, because
the builtin module would try to use some symbols that are defined only
at runtime.

So, the above won't solve the issue.

One possibility for future Kernels would be to add some logic that would
automatically load the module if a call to one of those symbols defined
inside a module happens inside a builtin module.

The DVB subsystem actually does that for I2C frontend drivers, 
using those macros:

#define dvb_attach(FUNCTION, ARGS...) ({ \
void *__r = NULL; \
typeof(&FUNCTION) __a = symbol_request(FUNCTION); \
if (__a) { \
__r = (void *) __a(ARGS); \
if (__r == NULL) \
symbol_put(FUNCTION); \
} else { \
printk(KERN_ERR "DVB: Unable to find symbol "#FUNCTION"()\n"); \
} \
__r; \
})

#define dvb_detach(FUNC)symbol_put_addr(FUNC)

The above works reasonably fine when there's just one symbol needed
from the module driver.

There are, however, some issues with such approach:

1) as symbol_request increments refcount, this works very badly when
   there's more than one symbol needed, as symbol_put() would need
   to be called as many times as symbol_request() is called;

2) lsmod doesn't list what module is actually requesting such symbol
   (if the caller is also a module). It just increments refcounting.
There were some patches meant to fix that, send a long time ago,
but were never merged. Can't remember why:
http://linuxtv.org/pipermail/linux-dvb/2006-August/012322.html

Due to the above issues, and because we want to better use the I2C
binding model, we're currently trying to get rid of such approach for
the DVB subsystem, but there are too many changes to get rid of it.
So, the migration is slow.

Anyway, IMHO, having such sort of logic would help to solve the issues
with some weird configs like INPUT=m.

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

Re: [RFC PATCH 00/11] Add configuration store support

2014-10-09 Thread Sakari Ailus 
Hi Hans,

Thank you for the set, and my apologies for taking a look only now.

On Sun, Sep 21, 2014 at 04:48:18PM +0200, Hans Verkuil wrote:
> This patch series adds support for configuration stores to the control
> framework. This allows you to store control values for a particular
> configuration (up to VIDEO_MAX_FRAME configuration stores are currently
> supported). When you queue a new buffer you can supply the store ID and
> the driver will apply all controls for that configuration store.
> 
> When you set a new value for a configuration store then you can choose
> whether this is 'fire and forget', i.e. after the driver applies the
> control value for that store it won't be applied again until a new value
> is set. Or you can set the value every time that configuration store is
> applied.

This does work for video device nodes but not for sub-device nodes which
have no buffer queues. Also if you think of using just a value from the
closest video buffer queue, that doesn't work either since there could be
more than one of those.

Most of the time the controls that need to be applied on per-frame basis are
present in embedded systems with complex media pipelines where most of the
controls are present on sub-device nodes.

In other words this approach alone is not sufficient to bind control related
configurations to individual frames. For preparing and applying
configurations it is applicable.

Thinking about the Android camera API v3, controls are a part of the picture
only: capture requests contain buffer sets as well. I think the concept
makes sense also outside Android. Let's discuss this further at the Media
summit.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 00/11] Add configuration store support

2014-10-09 Thread Hans Verkuil 
On 10/09/14 13:55, Sakari Ailus wrote:
> Hi Hans,
> 
> Thank you for the set, and my apologies for taking a look only now.
> 
> On Sun, Sep 21, 2014 at 04:48:18PM +0200, Hans Verkuil wrote:
>> This patch series adds support for configuration stores to the control
>> framework. This allows you to store control values for a particular
>> configuration (up to VIDEO_MAX_FRAME configuration stores are currently
>> supported). When you queue a new buffer you can supply the store ID and
>> the driver will apply all controls for that configuration store.
>>
>> When you set a new value for a configuration store then you can choose
>> whether this is 'fire and forget', i.e. after the driver applies the
>> control value for that store it won't be applied again until a new value
>> is set. Or you can set the value every time that configuration store is
>> applied.
> 
> This does work for video device nodes but not for sub-device nodes which
> have no buffer queues.

The subdevices may not have buffer queues, but the high-level media driver
will know when a subdevice has to apply a specific configuration store and
can tell the subdev to do so. That's the way I expect it to work.

> Also if you think of using just a value from the
> closest video buffer queue, that doesn't work either since there could be
> more than one of those.

Good point. One solution might be to allow for a larger range of config
store IDs (i.e., more than just 1-32, where 32 is the current maximum number
of buffers). That way different buffer queues can use unique config store
IDs. This does make the internal data structures a bit more complex, but it's
not a big deal.

> 
> Most of the time the controls that need to be applied on per-frame basis are
> present in embedded systems with complex media pipelines where most of the
> controls are present on sub-device nodes.
> 
> In other words this approach alone is not sufficient to bind control related
> configurations to individual frames. For preparing and applying
> configurations it is applicable.
> 
> Thinking about the Android camera API v3, controls are a part of the picture
> only: capture requests contain buffer sets as well. I think the concept
> makes sense also outside Android. Let's discuss this further at the Media
> summit.

Let's do that.

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: [PATCH v2 14/14] [media] s5p-mfc: Don't change the image size to smaller than the request.

2014-10-09 Thread Nicolas Dufresne 


Le 2014-10-09 06:06, Kamil Debski a écrit :

I think the documentation does not specify how TRY_FMT/S_FMT should adjust
the parameters. Maybe it would a good idea to add some flagS that determine
the behaviour?
A flag could be a good option, maybe we should take a minute and discuss 
this next week.


cheers,
Nicolas
--
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: technisat-usb2: i2c-error

2014-10-09 Thread Patrick Boettcher 
Hi Jan,

On Tue, 07 Oct 2014 19:27:07 +0200 JPT  wrote:
> 01:14:52 VDR fails to start because there is no recording device.
> 
> I was able to get things running by unloading the modules and loading
> them again. After that I started VDR.
> 
> What exactly do the i2c-errors mean? Find attached a
> "grep i2c-error syslog*"

I can't tell you exactly what happens in the device, but I can tell you
that I have the same problem with my device on my PC sometimes. 

In addition to this I2c-failures from time to time the box is quite
sensitive regarding: repowering, replugging and host-rebooting. This is
a USB-device-firmware problem which makes the device crash and all
subsequent USB-transfers are failed. Reloading the module or replugging
the device will make it work again.

I lost contact with Technisat some time ago and wouldn't be able easily
to get the information (and I doubt they have a solution for this
problem - up to them to prove me wrong).

How many days without interruption did you use the device?

I was following quietly you're discussion with Antti. Has someone taken
care of the your changes regarding the transfer-size?

I think it should included.

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

[PATCH] [media] ir-hix5hd2: fix build on c6x arch

2014-10-09 Thread Mauro Carvalho Chehab 
While not all archs have readl_relaxed, we need to add a hack at the
driver to allow it to COMPILE_TEST on all archs:

drivers/media/rc/ir-hix5hd2.c: In function ‘hix5hd2_ir_config’:
drivers/media/rc/ir-hix5hd2.c:100:2: error: implicit declaration of 
function ‘readl_relaxed’ [-Werror=implicit-function-declaration]

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
index c555ca2aed0e..08bbd4f508cd 100644
--- a/drivers/media/rc/ir-hix5hd2.c
+++ b/drivers/media/rc/ir-hix5hd2.c
@@ -20,6 +20,9 @@
 #ifndef writel_relaxed
 # define writel_relaxed writel
 #endif
+#ifndef readl_relaxed
+# define readl_relaxed readl
+#endif
 
 #define IR_ENABLE  0x00
 #define IR_CONFIG  0x04
-- 
1.9.3

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

randconfig build error with next-20141009, in drivers/media/v4l2-core/videobuf2-core.c

2014-10-09 Thread Jim Davis 
Building with the attached random configuration file,

drivers/built-in.o: In function `vb2_fop_mmap':
(.text+0x30256b): undefined reference to `video_devdata'
drivers/built-in.o: In function `vb2_ioctl_expbuf':
(.text+0x3025b9): undefined reference to `video_devdata'
drivers/built-in.o: In function `vb2_ioctl_streamoff':
(.text+0x302639): undefined reference to `video_devdata'
drivers/built-in.o: In function `vb2_ioctl_streamon':
(.text+0x3026b9): undefined reference to `video_devdata'
drivers/built-in.o: In function `vb2_ioctl_dqbuf':
(.text+0x303094): undefined reference to `video_devdata'
drivers/built-in.o:(.text+0x3031f1): more undefined references to
`video_devdata' follow
drivers/built-in.o: In function `vb2_thread':
videobuf2-core.c:(.text+0x30396e): undefined reference to `v4l2_get_timestamp'
drivers/built-in.o: In function `vb2_ioctl_qbuf':
(.text+0x303aba): undefined reference to `video_devdata'
drivers/built-in.o: In function `vb2_ioctl_prepare_buf':
(.text+0x303c43): undefined reference to `video_devdata'
drivers/built-in.o: In function `vb2_ioctl_create_bufs':
(.text+0x3045e8): undefined reference to `video_devdata'
drivers/built-in.o: In function `vb2_ioctl_reqbufs':
(.text+0x304cb9): undefined reference to `video_devdata'
drivers/built-in.o: In function `_vb2_fop_release':
(.text+0x305067): undefined reference to `video_devdata'
drivers/built-in.o: In function `_vb2_fop_release':
(.text+0x305117): undefined reference to `v4l2_fh_release'
drivers/built-in.o: In function `vb2_fop_release':
(.text+0x305148): undefined reference to `video_devdata'
drivers/built-in.o: In function `__vb2_perform_fileio':
videobuf2-core.c:(.text+0x3059bb): undefined reference to `v4l2_get_timestamp'
drivers/built-in.o: In function `vb2_fop_write':
(.text+0x305b07): undefined reference to `video_devdata'
drivers/built-in.o: In function `vb2_fop_read':
(.text+0x305cae): undefined reference to `video_devdata'
drivers/built-in.o: In function `vb2_poll':
(.text+0x305e11): undefined reference to `video_devdata'
drivers/built-in.o: In function `vb2_poll':
(.text+0x305e6d): undefined reference to `v4l2_event_pending'
drivers/built-in.o: In function `vb2_fop_poll':
(.text+0x3063f9): undefined reference to `video_devdata'
make: *** [vmlinux] Error 1
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 3.17.0 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
# CONFIG_ZONE_DMA32 is not set
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_COMPILE_TEST=y
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SWAP is not set
# CONFIG_SYSVIPC is not set
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_FHANDLE=y
CONFIG_USELIB=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TI

[GIT PULL for v3.18-rc1] media updates

2014-10-09 Thread Mauro Carvalho Chehab 
Hi Linus,

Please pull from:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v3.18-rc1

For the media patches for v3.18-rc1:

- new IR driver: hix5hd2-ir

- the virtual test driver (vivi) was replaced by vivid, with has
  an almost complete set of features to emulate most v4l2 devices
  and properly test all sorts of userspace apps;

- the as102 driver had several bugs fixed and was properly split
  into a frontend and a core driver. With that, it got promoted from
  staging into mainstream;

- one new CI driver got added for CIMaX SP2/SP2HF (sp2 driver);

- one new frontend driver for Toshiba ISDB-T/ISDB-S demod (tc90522);

- one new PCI driver for ISDB-T/ISDB-S (pt3 driver);

- saa7134 driver got support for go7007-based devices;

- added a new PCI driver for Techwell 68xx chipsets (tw68);

- a new platform driver was added (coda);

- new tuner drivers: mxl301rf and qm1d1c0042;

- a new DVB USB driver was added for DVBSky S860 & similar devices;

- Added a new SDR driver (hackrf);

- usbtv got audio support;

- several platform drivers are now compiled with COMPILE_TEST;

- a series of compiler fixup patches, making sparse/spatch happier
  with the media stuff and removing several warnings, especially
  on those platform drivers that didn't use to compile on x86;

- Support for several new modern devices got added;

- lots of other fixes, improvements and cleanups.

Thanks!
Mauro

-


The following changes since commit bfe01a5ba2490f299e1d2d5508cbbbadd897bbe9:

  Linux 3.17 (2014-10-05 12:23:04 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v3.18-rc1

for you to fetch changes up to a66d05d504a24894a8fdf11e4569752f313e5764:

  Merge branch 'patchwork' into v4l_for_linus (2014-10-09 14:00:54 -0300)



media updates for v3.18-rc1


Akihiro Tsukada (4):
  [media] mxl301rf: add driver for MaxLinear MxL301RF OFDM tuner
  [media] qm1d1c0042: add driver for Sharp QM1D1C0042 ISDB-S tuner
  [media] tc90522: add driver for Toshiba TC90522 quad demodulator
  [media] pt3: add support for Earthsoft PT3 ISDB-S/T receiver card

Alexey Khoroshilov (2):
  [media] mceusb: fix usbdev leak
  [media] imon: fix usbdev leaks

Amber Thrall (1):
  [media] Media: USB: usbtv: Fixed all coding style issues in usbtv source 
files

Andreas Ruprecht (1):
  [media] drivers: media: pci: Makefile: Remove duplicate subdirectory from 
obj-y

Andrey Utkin (1):
  [media] drivers/media/dvb-frontends/stv0900_sw.c: Fix break placement

Andy Shevchenko (1):
  [media] hdpvr: reduce memory footprint when debugging

Antonio Ospite (2):
  [media] trivial: drivers/media/usb/gspca/gspca.c: fix the indentation of 
a comment
  [media] trivial: drivers/media/usb/gspca/gspca.h: indent with TABs, not 
spaces

Antti Palosaari (72):
  [media] dvb-usb-v2: remove dvb_usb_device NULL check
  [media] msi2500: remove unneeded local pointer on msi2500_isoc_init()
  [media] m88ts2022: fix 32bit overflow on filter calc
  [media] m88ts2022: fix coding style issues
  [media] m88ds3103: change .set_voltage() implementation
  [media] m88ds3103: fix coding style issues
  [media] m88ts2022: rename device state (priv => dev)
  [media] m88ts2022: clean up logging
  [media] m88ts2022: convert to RegMap I2C API
  [media] m88ts2022: change parameter type of m88ts2022_cmd
  [media] airspy: fix error handling on start streaming
  [media] airspy: coding style issues
  [media] airspy: logging changes
  [media] airspy: remove unneeded spinlock irq flags initialization
  [media] airspy: enhance sample rate debug calculation precision
  [media] msi2500: logging changes
  [media] msi001: logging changes
  [media] msi2500: remove unneeded spinlock irq flags initialization
  [media] e4000: logging changes
  [media] rtl2832_sdr: remove unneeded spinlock irq flags initialization
  [media] rtl2832_sdr: enhance sample rate debug calculation precision
  [media] rtl2832_sdr: logging changes
  [media] tda18212: add support for slave chip version
  [media] af9033: provide dyn0_clk clock source
  [media] af9035: enable AF9033 demod clock source for IT9135
  [media] it913x: fix tuner sleep power leak
  [media] it913x: avoid division by zero on error case
  [media] it913x: fix IT9135 AX sleep
  [media] af9035: remove AVerMedia eeprom override
  [media] af9035: make checkpatch.pl happy
  [media] af9033: make checkpatch.pl happy
  [media] it913x: make checkpatch.pl happy
  [media] it913x: rename tuner_it913x => it913x
  [media] it913x: convert to I2C driver
  [media] it913x: change reg read/write routines more common
  [media] it913x: rename 'state' to 'dev'
  [media] it

[GIT PULL for v3.18-rc1] edac updates

2014-10-09 Thread Mauro Carvalho Chehab 
Hi Linus,

Please pull from:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac 
tags/edac/v3.18-rc1

For some EDAC patches. Nothing really exiting here: just one bug fix at
sb_edac, and some changes to allow other drivers to use some shared PCI
addresses.

Regards,
Mauro

The following changes since commit c91662cb18f00f225c74816353f222b6997131ca:

  Merge tag 'edac_for_3.18' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp (2014-10-07 20:54:50 -0400)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-edac 
tags/edac/v3.18-rc1

for you to fetch changes up to d0585cd815faef50ce3d12cbe173438eb4d81eb8:

  sb_edac: Claim a different PCI device (2014-10-08 17:04:16 -0300)


edac updates for v3.18-rc1


Andy Lutomirski (2):
  Move Intel SNB device ids from sb_edac to pci_ids.h
  sb_edac: Claim a different PCI device

Seth Jennings (1):
  sb_edac: avoid INTERNAL ERROR message in EDAC with unspecified channel

 drivers/edac/sb_edac.c  | 40 +++-
 include/linux/pci_ids.h | 15 +++
 2 files changed, 22 insertions(+), 33 deletions(-)

--
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/RFC 0/1] Libv4l: Add a plugin for the Exynos4 camera

2014-10-09 Thread Gregor Jasny 
Hi,

On 08/10/14 10:46, Jacek Anaszewski wrote:
> This patch adds a plugin for the Exynos4 camera. I wanted to split
> at least the parser part to the separate module but encountered
> some problems with autotools configuration and therefore I'd like
> to ask for an instruction on how to adjust the Makefile.am files
> to achieve this.

I was the one who authored the v4l-utils build system. It looks a little
bit messy because of all the supported configurations and toolchain
capabilities.

Feel free to ask if you have any questions.

Thanks,
Gregor
--
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 4/4] v4l-utils/dvbv5-scan: add support for ISDB-S scanning

2014-10-09 Thread Akihiro TSUKADA 
On 2014年10月09日 01:04, Mauro Carvalho Chehab wrote:
>> @@ -251,6 +251,16 @@ static int run_scan(struct arguments *args,
>>  if (dvb_retrieve_entry_prop(entry, DTV_POLARIZATION, &pol))
>>  pol = POLARIZATION_OFF;
>>  
>> +if (parms->current_sys == SYS_ISDBS) {
>> +uint32_t tsid = 0;
>> +
>> +dvb_store_entry_prop(entry, DTV_POLARIZATION, 
>> POLARIZATION_R);
>> +
>> +dvb_retrieve_entry_prop(entry, DTV_STREAM_ID, &tsid);
>> +if (!dvb_new_ts_is_needed(dvb_file->first_entry, entry,
>> +  freq, shift, tsid))
>> +continue;
> 
> This is likely needed for DVB-T2 and DVB-S2 too.

Should we compare channel entries by (freq, stream_id, polarization) triplet
instead of by the current (freq, polarization) or (freq, stream_id)?

>> @@ -258,6 +268,10 @@ static int run_scan(struct arguments *args,
>>  count++;
>>  dvb_log("Scanning frequency #%d %d", count, freq);
>>  
>> +if (!args->lnb_name && entry->lnb &&
>> +(!parms->lnb || strcasecmp(entry->lnb, parms->lnb->alias)))
> 
> Shouldn't it be: !strcasecmp(entry->lnb, parms->lnb->alias)? Or maybe just
> remove this test.
I want to update parms->lnb (which was set from the prev entry)
only if it differs from entry->lnb (current one),
and don't want to linear-search all LNB types for every entries,
as lots of entries are expected to have the same LNB types.
--
akihiro 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] v4l-utils:libdvbv5,dvb: add basic support for ISDB-S

2014-10-09 Thread Akihiro TSUKADA 
Hi, Mauro,
thanks for the review.

I'll update the patch soon.
And I wrote some comments and questions as a reply to
your each review mail.

On 2014年10月09日 01:22, Mauro Carvalho Chehab wrote:

> Yeah, it will likely require a table just like the one we've added
> for EN 300 468 specific charset with the euro sign.
> 
> There are some patches for charset decoding like this one:
> 
> http://marc.info/?l=mplayer-dev-eng&m=125642040004816

I already looked over other examples in some Japan local patches
to the applications like mplayer,gstreamer, mythtv...,
( https://github.com/0p1pp1?tab=repositories
  https://github.com/takaakis62/mythtv_isdb )
so I'm going to reuse those code.

regards,
akihiro
--
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 resend] [media] rc-core: fix protocol_change regression in ir_raw_event_register

2014-10-09 Thread Tomas Melin 
IR reciever using nuvoton-cir and lirc was not working anymore after
upgrade from kernel 3.16 to 3.17-rcX.
Bisected regression to commit da6e162d6a4607362f8478c715c797d84d449f8b
("[media] rc-core: simplify sysfs code").

The regression comes from adding function change_protocol in
ir-raw.c. During registration, ir_raw_event_register enables all protocols
by default. Later, rc_register_device also tests dev->change_protocol and
changes the enabled protocols based on rc_map type. However, rc_map type
only defines a single specific protocol, so in the case of a more generic
driver, this disables all protocols but the one defined by the map.

Changed back to original behaviour by removing empty function
change_protocol in ir-raw.c. Instead only calling change_protocol for
drivers that actually have the function set up.

Signed-off-by: Tomas Melin 
---
 drivers/media/rc/rc-ir-raw.c |7 ---
 drivers/media/rc/rc-main.c   |   19 ---
 2 files changed, 8 insertions(+), 18 deletions(-)

diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index e8fff2a..a118539 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -240,12 +240,6 @@ ir_raw_get_allowed_protocols(void)
return protocols;
 }
 
-static int change_protocol(struct rc_dev *dev, u64 *rc_type)
-{
-   /* the caller will update dev->enabled_protocols */
-   return 0;
-}
-
 /*
  * Used to (un)register raw event clients
  */
@@ -263,7 +257,6 @@ int ir_raw_event_register(struct rc_dev *dev)
 
dev->raw->dev = dev;
dev->enabled_protocols = ~0;
-   dev->change_protocol = change_protocol;
rc = kfifo_alloc(&dev->raw->kfifo,
 sizeof(struct ir_raw_event) * MAX_IR_EVENT_SIZE,
 GFP_KERNEL);
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index a7991c7..633c682 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1001,11 +1001,6 @@ static ssize_t store_protocols(struct device *device,
set_filter = dev->s_wakeup_filter;
}
 
-   if (!change_protocol) {
-   IR_dprintk(1, "Protocol switching not supported\n");
-   return -EINVAL;
-   }
-
mutex_lock(&dev->lock);
 
old_protocols = *current_protocols;
@@ -1013,12 +1008,14 @@ static ssize_t store_protocols(struct device *device,
rc = parse_protocol_change(&new_protocols, buf);
if (rc < 0)
goto out;
-
-   rc = change_protocol(dev, &new_protocols);
-   if (rc < 0) {
-   IR_dprintk(1, "Error setting protocols to 0x%llx\n",
-  (long long)new_protocols);
-   goto out;
+   /* Only if protocol change set up in driver */
+   if (change_protocol) {
+   rc = change_protocol(dev, &new_protocols);
+   if (rc < 0) {
+   IR_dprintk(1, "Error setting protocols to 0x%llx\n",
+  (long long)new_protocols);
+   goto out;
+   }
}
 
if (new_protocols == old_protocols) {
-- 
1.7.10.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: [PATCH 4/4] v4l-utils/dvbv5-scan: add support for ISDB-S scanning

2014-10-09 Thread Mauro Carvalho Chehab 
Em Fri, 10 Oct 2014 03:11:32 +0900
Akihiro TSUKADA  escreveu:

> On 2014年10月09日 01:04, Mauro Carvalho Chehab wrote:
> >> @@ -251,6 +251,16 @@ static int run_scan(struct arguments *args,
> >>if (dvb_retrieve_entry_prop(entry, DTV_POLARIZATION, &pol))
> >>pol = POLARIZATION_OFF;
> >>  
> >> +  if (parms->current_sys == SYS_ISDBS) {
> >> +  uint32_t tsid = 0;
> >> +
> >> +  dvb_store_entry_prop(entry, DTV_POLARIZATION, 
> >> POLARIZATION_R);
> >> +
> >> +  dvb_retrieve_entry_prop(entry, DTV_STREAM_ID, &tsid);
> >> +  if (!dvb_new_ts_is_needed(dvb_file->first_entry, entry,
> >> +freq, shift, tsid))
> >> +  continue;
> > 
> > This is likely needed for DVB-T2 and DVB-S2 too.
> 
> Should we compare channel entries by (freq, stream_id, polarization) triplet
> instead of by the current (freq, polarization) or (freq, stream_id)?

For DVB-S2, it should likely  be (freq, stream_id, polarization) triplet
(tests needed).

For DVB-T2, (freq, stream_id) pair should work;

For ISDB-S, you likely need the (freq, stream_id, polarization) triplet
too, as you may have two polarizations there, right?

> >> @@ -258,6 +268,10 @@ static int run_scan(struct arguments *args,
> >>count++;
> >>dvb_log("Scanning frequency #%d %d", count, freq);
> >>  
> >> +  if (!args->lnb_name && entry->lnb &&
> >> +  (!parms->lnb || strcasecmp(entry->lnb, parms->lnb->alias)))
> > 
> > Shouldn't it be: !strcasecmp(entry->lnb, parms->lnb->alias)? Or maybe just
> > remove this test.
> I want to update parms->lnb (which was set from the prev entry)
> only if it differs from entry->lnb (current one),
> and don't want to linear-search all LNB types for every entries,
> as lots of entries are expected to have the same LNB types.

Ah, ok. Please add a comment then.

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

Re: omap3isp Device Tree support status

2014-10-09 Thread Alaganraj Sandhanam 
Hi Sakari,

On Wednesday 08 October 2014 05:03 PM, Sakari Ailus wrote:
> Hi Alaganjar,
> 
> On Tue, Oct 07, 2014 at 02:37:37AM +0530, Alaganraj Sandhanam wrote:
>> Hi Sakari,
>>
>> Thanks for the patches.
>> On Monday 29 September 2014 03:43 AM, Sakari Ailus wrote:
>>> Hi,
>>>
>>> I managed to find some time for debugging my original omap3isp DT support
>>> patchset (which includes smiapp DT support as well), and found a few small
>>> but important bugs.
>>>
>>> The status is now that images can be captured using the Nokia N9 camera, in
>>> which the sensor is connected to the CSI-2 interface. Laurent confirmed that
>>> the parallel interface worked for him (Beagleboard, mt9p031 sensor on
>>> Leopard imaging's li-5m03 board).
>> Good news!
>>>
>>> These patches (on top of the smiapp patches I recently sent for review which
>>> are in much better shape) are still experimental and not ready for review. I
>>> continue to clean them up and post them to the list when that is done. For
>>> now they can be found here:
>>>
>>> http://git.linuxtv.org/cgit.cgi/sailus/media_tree.git/log/?h=rm696-043-dt>
>>>
>> I couldn't clone the repo, getting "remote corrupt" error.
>>
>> $ git remote -v
>> media-sakari git://linuxtv.org/sailus/media_tree.git (fetch)
>> media-sakari git://linuxtv.org/sailus/media_tree.git (push)
>> origin   git://linuxtv.org/media_tree.git (fetch)
>> origin   git://linuxtv.org/media_tree.git (push)
>> sakari   git://vihersipuli.retiisi.org.uk/~sailus/linux.git (fetch)
>> sakari   git://vihersipuli.retiisi.org.uk/~sailus/linux.git (push)
>>
>> $ git fetch media-sakari
>> warning: cannot parse SRV response: Message too long
>> remote: error: Could not read 5ea878796f0a1d9649fe43a6a09df53d3915c0ef
>> remote: fatal: revision walk setup failed
>> remote: aborting due to possible repository corruption on the remote side.
>> fatal: protocol error: bad pack header
> 
> I'm not sure what this could be related. Can you fetch from other trees,
> e.g. your origin remote? Do you get the same error from the remote on
> vihersipuli, and by using http instead?
> 
I'm able to fetch from "origin" and "vihersipuli" remotes.
problem with only "git://linuxtv.org/sailus/media_tree.git" remote.

Thanks&Regards
Alaganraj
--
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] br-sp-SaoPaulo: Remove an invalid channel

2014-10-09 Thread Mauro Carvalho Chehab 
Channel 12 is currently not valid for ISDB-T in Brazil.

Also, due to an error FREQUENCY ended by not being filled here.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/isdb-t/br-sp-SaoPaulo b/isdb-t/br-sp-SaoPaulo
index 2f4d8d77662b..215e596caf2a 100644
--- a/isdb-t/br-sp-SaoPaulo
+++ b/isdb-t/br-sp-SaoPaulo
@@ -1,35 +1,6 @@
 # Channel table for S??o Paulo - SP - Brazil
 # Source: http://portalbsd.com.br/novo/terrestres_channels.php?channels=1
 
-# Physical channel 12
-[TV Mackenzie]
-   DELIVERY_SYSTEM = ISDBT
-   BANDWIDTH_HZ = 600
-   FREQUENCY = 
-   INVERSION = AUTO
-   GUARD_INTERVAL = AUTO
-   TRANSMISSION_MODE = AUTO
-   INVERSION = AUTO
-   GUARD_INTERVAL = AUTO
-   TRANSMISSION_MODE = AUTO
-   ISDBT_LAYER_ENABLED = 7
-   ISDBT_SOUND_BROADCASTING = 0
-   ISDBT_SB_SUBCHANNEL_ID = 0
-   ISDBT_SB_SEGMENT_IDX = 0
-   ISDBT_SB_SEGMENT_COUNT = 0
-   ISDBT_LAYERA_FEC = AUTO
-   ISDBT_LAYERA_MODULATION = QAM/AUTO
-   ISDBT_LAYERA_SEGMENT_COUNT = 0
-   ISDBT_LAYERA_TIME_INTERLEAVING = 0
-   ISDBT_LAYERB_FEC = AUTO
-   ISDBT_LAYERB_MODULATION = QAM/AUTO
-   ISDBT_LAYERB_SEGMENT_COUNT = 0
-   ISDBT_LAYERB_TIME_INTERLEAVING = 0
-   ISDBT_LAYERC_FEC = AUTO
-   ISDBT_LAYERC_MODULATION = QAM/AUTO
-   ISDBT_LAYERC_SEGMENT_COUNT = 0
-   ISDBT_LAYERC_TIME_INTERLEAVING = 0
-
 # Physical channel 15
 [Mega TV]
DELIVERY_SYSTEM = ISDBT
-- 
1.9.3

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

v4l2-compliance revision vs Kernel version

2014-10-09 Thread Benoit Parrot 
Hi,

Can someone point me toward a mapping of v4l2-compliance release vs kernel 
version?

I am currently working with a 3.14 kernel and would like to find the matching 
v4l2-compliance version.
I am  using git://linuxtv.org/v4l-utils.git commit id:
3719cef libdvbv5: reimplement the logic that gets a full section

But on 3.14 running that version against vivi.ko shows a few failures and a 
bunch of "Not Supported".

Thanks,
Benoit
--
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: v4l2-compliance revision vs Kernel version

2014-10-09 Thread Hans Verkuil 

Hi Benoit,

On 10/09/2014 11:45 PM, Benoit Parrot wrote:

Hi,

Can someone point me toward a mapping of v4l2-compliance release vs kernel 
version?


There isn't any. It's trial and error, I'm afraid. The primary use-case of 
v4l2-compliance is
testing drivers in the bleeding-edge media_tree.git repo.



I am currently working with a 3.14 kernel and would like to find the matching 
v4l2-compliance version.
I am  using git://linuxtv.org/v4l-utils.git commit id:
3719cef libdvbv5: reimplement the logic that gets a full section

But on 3.14 running that version against vivi.ko shows a few failures and a bunch of 
"Not Supported".


"Not Supported" is not an error. It just means that the driver doesn't support 
that ioctl, so
no compliance tests for that ioctl are done.

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: v4l2-compliance revision vs Kernel version

2014-10-09 Thread Benoit Parrot 
Hi Hans,

Hans Verkuil  wrote on Fri [2014-Oct-10 00:03:01 +0200]:
> Hi Benoit,
> 
> On 10/09/2014 11:45 PM, Benoit Parrot wrote:
> >Hi,
> >
> >Can someone point me toward a mapping of v4l2-compliance release vs kernel 
> >version?
> 
> There isn't any. It's trial and error, I'm afraid. The primary use-case of 
> v4l2-compliance is
> testing drivers in the bleeding-edge media_tree.git repo.

Thanks for the quick reply.
I had a feeling that was going to be the case, but had to check.
> 
> >
> >I am currently working with a 3.14 kernel and would like to find the 
> >matching v4l2-compliance version.
> >I am  using git://linuxtv.org/v4l-utils.git commit id:
> >3719cef libdvbv5: reimplement the logic that gets a full section
> >
> >But on 3.14 running that version against vivi.ko shows a few failures and a 
> >bunch of "Not Supported".
> 
> "Not Supported" is not an error. It just means that the driver doesn't 
> support that ioctl, so
> no compliance tests for that ioctl are done.

Yeah I know but i am getting those even for simple stuff like:

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK (Not Supported)
test read/write: OK
test MMAP: OK (Not Supported)
test USERPTR: OK (Not Supported)
test DMABUF: OK (Not Supported)

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

cron job: media_tree daily build: WARNINGS

2014-10-09 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 Oct 10 04:00:27 CEST 2014
git branch: test
git hash:   cf3167cf1e969b17671a4d3d956d22718a8ceb85
gcc version:i686-linux-gcc (GCC) 4.9.1
sparse version: v0.5.0-20-g7abd8a7
host hardware:  x86_64
host os:3.17-0.slh.1-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.32.27-i686: WARNINGS
linux-2.6.33.7-i686: WARNINGS
linux-2.6.34.7-i686: WARNINGS
linux-2.6.35.9-i686: WARNINGS
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: OK
linux-3.11.1-i686: WARNINGS
linux-3.12.23-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: OK
linux-3.16-i686: OK
linux-3.17-i686: OK
linux-2.6.32.27-x86_64: WARNINGS
linux-2.6.33.7-x86_64: WARNINGS
linux-2.6.34.7-x86_64: WARNINGS
linux-2.6.35.9-x86_64: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: WARNINGS
linux-3.12.23-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16-x86_64: WARNINGS
linux-3.17-x86_64: WARNINGS
apps: OK
spec-git: OK
sparse: WARNINGS

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 Media Infrastructure API 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 v2] [media] videobuf-dma-contig: set vm_pgoff to be zero to pass the sanity check in vm_iomap_memory().

2014-10-09 Thread Fancy Fang 
When user requests V4L2_MEMORY_MMAP type buffers, the videobuf-core
will assign the corresponding offset to the 'boff' field of the
videobuf_buffer for each requested buffer sequentially. Later, user
may call mmap() to map one or all of the buffers with the 'offset'
parameter which is equal to its 'boff' value. Obviously, the 'offset'
value is only used to find the matched buffer instead of to be the
real offset from the buffer's physical start address as used by
vm_iomap_memory(). So, in some case that if the offset is not zero,
vm_iomap_memory() will fail.

Signed-off-by: Fancy Fang 
Reviewed-by: Marek Szyprowski 
Reviewed-by: Hans Verkuil 
---
 drivers/media/v4l2-core/videobuf-dma-contig.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c 
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index bf80f0f..e02353e 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -305,6 +305,15 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
/* Try to remap memory */
size = vma->vm_end - vma->vm_start;
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+
+   /* the "vm_pgoff" is just used in v4l2 to find the
+* corresponding buffer data structure which is allocated
+* earlier and it does not mean the offset from the physical
+* buffer start address as usual. So set it to 0 to pass
+* the sanity check in vm_iomap_memory().
+*/
+   vma->vm_pgoff = 0;
+
retval = vm_iomap_memory(vma, mem->dma_handle, size);
if (retval) {
dev_err(q->dev, "mmap: remap failed with error %d. ",
-- 
1.9.1

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

GrabBee-HD

2014-10-09 Thread Dave Kimble 

I have just bought an HDMI to USB-2.0 grabber called "GrabBee-HD".
http://www.greada.com/grabbeex-hd.html
Motherboard photo: http://www.davekimble.org.au/computers/GrabBee-HD.jpg
Inside it has chips labelled "Sigma PL330B-CPE3" and "iTE IT6604E".
Note that it compresses the video with H.264 .

I knew it probably wouldn't have drivers for Linux, but it does have 
Windows drivers on CD,
so since I run Ubuntu-VirtualBox-WinXP I thought it might well work one 
way or another.


On Ubuntu 14.04, the USB device is picked up:
$ lsusb -v -d 0658:1100

Bus 001 Device 007: ID 0658:1100 Sigma Designs, Inc.
Couldn't open device, some information will be missing
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x0658 Sigma Designs, Inc.
  idProduct  0x1100
  bcdDevice0.00
  iManufacturer   1
  iProduct2
  iSerial 3
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   46
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  4
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   4
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0
  bInterfaceProtocol  0
  iInterface  4
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   3
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04  EP 4 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   3
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   3
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   3


but it is not recognised as a video capture device by VLC.
/dev/dvb/ , /dev/v4l/ , /dev/video0 do not exist.

So I fired up VB-WinXP and installed the Windows drivers and software, 
and restarted.
Then plugged in the device, which should connect the device to the 
driver, but it didn't.
Starting the Grabbee-HD software gives "No video capture device is 
connected!"

Then I realised the USB device has to be passed through the VB interface,
VB-Manager > USB > Add > "no devices available".

So because Ubuntu doesn't properly recognise the device, it can't pass 
it on to VB and XP.


Is there any chance of getting this going on Ubuntu 14.04 natively?


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

[PATCH] [media] ir-hix5hd2 fix build warning

2014-10-09 Thread Zhangfei Gao 
Change CONFIG_PM to CONFIG_PM_SLEEP to solve
warning: 'hix5hd2_ir_suspend' & 'hix5hd2_ir_resume' defined but not used

Signed-off-by: Zhangfei Gao 
---
 drivers/media/rc/ir-hix5hd2.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/ir-hix5hd2.c b/drivers/media/rc/ir-hix5hd2.c
index c555ca2aed0e..455d1b53c9db 100644
--- a/drivers/media/rc/ir-hix5hd2.c
+++ b/drivers/media/rc/ir-hix5hd2.c
@@ -294,7 +294,7 @@ static int hix5hd2_ir_remove(struct platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
 static int hix5hd2_ir_suspend(struct device *dev)
 {
struct hix5hd2_ir_priv *priv = dev_get_drvdata(dev);
-- 
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