date:20120920

The mx1_camera driver has been broken for a few release cycles since
commit 6bd0812 (dmaengine: imx-dma: merge old dma-v1.c with imx-dma.c).
It seems there is no one even compile tested it since then, as doing
so will end up with the following error.

  CC  drivers/media/platform/soc_camera/mx1_camera.o
In file included from drivers/media/platform/soc_camera/mx1_camera.c:44:0:
arch/arm/mach-imx/include/mach/dma-mx1-mx2.h:8:25: fatal error: mach/dma-v1.h: 
No such file or directory

It seems there is no one being interested in bringing it back to
work [1] so far.  Let's mark it BROKEN.

[1] https://lkml.org/lkml/2012/2/9/171

Signed-off-by: Shawn Guo 
---
 drivers/media/platform/soc_camera/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/soc_camera/Kconfig 
b/drivers/media/platform/soc_camera/Kconfig
index 9afe1e7..cb6791e 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -19,6 +19,7 @@ config MX1_VIDEO
 
 config VIDEO_MX1
tristate "i.MX1/i.MXL CMOS Sensor Interface driver"
+   depends on BROKEN
depends on VIDEO_DEV && ARCH_MX1 && SOC_CAMERA
select FIQ
select VIDEOBUF_DMA_CONTIG
-- 
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: [PATCH 1/3] Add a core driver for SI476x MFD

2012-09-20 Thread andrey.smir...@convergeddevices.net

On 09/13/2012 11:44 PM, Hans Verkuil wrote:
> Hi Andrey!
>
> Thanks for posting this driver. One request for the future: please split this
> patch up in smaller pieces: one for each c source for example. That makes it
> easier to review.

Will do for next version.

> +
> +/**
> + * __core_send_command() - sends a command to si476x and waits its
> + * response
> + * @core:si476x_device structure for the device we are
> + *communicating with
> + * @command:  command id
> + * @args: command arguments we are sending
> + * @argn: actual size of @args
> + * @response: buffer to place the expected response from the device
> + * @respn:actual size of @response
> + * @usecs:amount of time to wait before reading the response (in
> + *usecs)
> + *
> + * Function returns 0 on succsess and negative error code on
> + * failure
> + */
> +static int __core_send_command(struct si476x_core *core,
> + const u8 command,
> + const u8 args[],
> + const int argn,
> + u8 resp[],
> + const int respn,
> + const int usecs)
> +{
> + struct i2c_client *client = core->client;
> + int err;
> + u8  data[CMD_MAX_ARGS_COUNT + 1];
> +
> + if (argn > CMD_MAX_ARGS_COUNT) {
> + err = -ENOMEM;
> + goto exit;
> Why goto exit? There is no clean up after the exit label, so just return
> immediately. Ditto for all the other goto exit's in this function.

To have only just on point of exit from the function that's just
personal coding style preference.
There are no technical reasons behind that, I can change that.

>
>> +}
>> +
>> +if (!client->adapter) {
>> +err = -ENODEV;
>> +goto exit;
>> +}
>> +
>> +/* First send the command and its arguments */
>> +data[0] = command;
>> +memcpy(&data[1], args, argn);
>> +DBG_BUFFER(&client->dev, "Command:\n", data, argn + 1);
>> +
>> +err = si476x_i2c_xfer(core, SI476X_I2C_SEND, (char *) data, argn + 1);
>> +if (err != argn + 1) {
>> +dev_err(&core->client->dev,
>> +"Error while sending command 0x%02x\n",
>> +command);
>> +err = (err >= 0) ? -EIO : err;
>> +goto exit;
>> +}
>> +/* Set CTS to zero only after the command is send to avoid
>> + * possible racing conditions when working in polling mode */
>> +atomic_set(&core->cts, 0);
>> +
>> +if (!wait_event_timeout(core->command,
>> +atomic_read(&core->cts),
>> +usecs_to_jiffies(usecs) + 1))
>> +dev_warn(&core->client->dev,
>> + "(%s) [CMD 0x%02x] Device took too much time to 
>> answer.\n",
>> + __func__, command);
>> +
>> +/*
>> +  When working in polling mode, for some reason the tuner will
>> +  report CTS bit as being set in the first status byte read,
>> +  but all the consequtive ones will return zros until the
>> +  tuner is actually completed the POWER_UP command. To
>> +  workaround that we wait for second CTS to be reported
>> + */
>> +if (unlikely(!core->client->irq && command == CMD_POWER_UP)) {
>> +if (!wait_event_timeout(core->command,
>> +atomic_read(&core->cts),
>> +usecs_to_jiffies(usecs) + 1))
>> +dev_warn(&core->client->dev,
>> + "(%s) Power up took too much time.\n",
>> + __func__);
>> +}
>> +
>> +/* Then get the response */
>> +err = si476x_i2c_xfer(core, SI476X_I2C_RECV, resp, respn);
>> +if (err != respn) {
>> +dev_err(&core->client->dev,
>> +"Error while reading response for command 0x%02x\n",
>> +command);
>> +err = (err >= 0) ? -EIO : err;
>> +goto exit;
>> +}
>> +DBG_BUFFER(&client->dev, "Response:\n", resp, respn);
>> +
>> +err = 0;
>> +
>> +if (resp[0] & SI476X_ERR) {
>> +dev_err(&core->client->dev, "Chip set error flag\n");
>> +err = si476x_core_parse_and_nag_about_error(core);
>> +goto exit;
>> +}
>> +
>> +if (!(resp[0] & SI476X_CTS))
>> +err = -EBUSY;
>> +exit:
>> +return err;
>> +}
>> +
>> +#define CORE_SEND_COMMAND(core, cmd, args, resp, timeout)   \
>> +__core_send_command(core, cmd, args,\
>> +ARRAY_SIZE(args),   \
>> +resp, ARRAY_SIZE(resp), \
>> +timeout)
>> +
>> +
>> +static int __cmd_tune_seek_freq(struct si476x_core *core,
>> +uint8_t cmd,
>> +

[PATCH] rtl28xxu: [0413:6680] DigitalNow Quad DVB-T Receiver

It is 4 x RTL2832U + 4 x FC0012 in one PCIe board.
Of course there is a PCIe USB host controller too.

Big thanks for Darryl Bond reporting and testing that!

Cc: Darryl Bond 
Signed-off-by: Antti Palosaari 
---
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 70c2df1..f62cfba 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1342,6 +1342,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
&rtl2832u_props, "Trekstor DVB-T Stick Terres 2.0", NULL) },
{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1101,
&rtl2832u_props, "Dexatek DK DVB-T Dongle", NULL) },
+   { DVB_USB_DEVICE(USB_VID_LEADTEK, 0x6680,
+   &rtl2832u_props, "DigitalNow Quad DVB-T Receiver", NULL) },
{ }
 };
 MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
-- 
1.7.11.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 v4] of: Add videomode helper

2012-09-20 Thread Laurent Pinchart

Hi,

(CC'ing the linux-media mailing list, as video modes are of interest there as 
well)

On Wednesday 19 September 2012 12:19:22 Tomi Valkeinen wrote:
> On Wed, 2012-09-19 at 10:20 +0200, Steffen Trumtrar wrote:
> > This patch adds a helper function for parsing videomodes from the
> > devicetree. The videomode can be either converted to a struct
> > drm_display_mode or a struct fb_videomode.
> > 
> > Signed-off-by: Sascha Hauer 
> > Signed-off-by: Steffen Trumtrar 
> > ---
> > 
> > Hi!
> > 
> > changes since v3:
> > - print error messages
> > - free alloced memory
> > - general cleanup
> > 
> > Regards
> > Steffen
> > 
> >  .../devicetree/bindings/video/displaymode  |   74 +
> >  drivers/of/Kconfig |5 +
> >  drivers/of/Makefile|1 +
> >  drivers/of/of_videomode.c  |  283 +++
> >  include/linux/of_videomode.h   |   56 
> >  5 files changed, 419 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/video/displaymode
> >  create mode 100644 drivers/of/of_videomode.c
> >  create mode 100644 include/linux/of_videomode.h
> > 
> > diff --git a/Documentation/devicetree/bindings/video/displaymode
> > b/Documentation/devicetree/bindings/video/displaymode new file mode
> > 100644
> > index 000..990ca52
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/video/displaymode
> > @@ -0,0 +1,74 @@
> > +videomode bindings
> > +==
> > +
> > +Required properties:
> > + - hactive, vactive: Display resolution
> > + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing
> > parameters
> > +   in pixels
> > +   vfront-porch, vback-porch, vsync-len: Vertical display timing
> > parameters in
> > +   lines
> > + - clock: displayclock in Hz
> > +
> > +Optional properties:
> > + - width-mm, height-mm: Display dimensions in mm
> > + - hsync-active-high (bool): Hsync pulse is active high
> > + - vsync-active-high (bool): Vsync pulse is active high
> > + - interlaced (bool): This is an interlaced mode
> > + - doublescan (bool): This is a doublescan mode
> > +
> > +There are different ways of describing a display mode. The devicetree
> > representation
> > +corresponds to the one commonly found in datasheets for displays.
> > +The description of the display and its mode is split in two parts: first
> > the display
> > +properties like size in mm and (optionally) multiple subnodes with the
> > supported modes.
> > +
> > +Example:
> > +
> > +   display@0 {
> > +   width-mm = <800>;
> > +   height-mm = <480>;
> > +   modes {
> > +   mode0: mode@0 {
> > +   /* 1920x1080p24 */
> > +   clock = <5200>;
> > +   hactive = <1920>;
> > +   vactive = <1080>;
> > +   hfront-porch = <25>;
> > +   hback-porch = <25>;
> > +   hsync-len = <25>;
> > +   vback-porch = <2>;
> > +   vfront-porch = <2>;
> > +   vsync-len = <2>;
> > +   hsync-active-high;
> > +   };
> > +   };
> > +   };
> > +
> > +Every property also supports the use of ranges, so the commonly used
> > datasheet +description with -tuples can be used.
> > +
> > +Example:
> > +
> > +   mode1: mode@1 {
> > +   /* 1920x1080p24 */
> > +   clock = <14850>;
> > +   hactive = <1920>;
> > +   vactive = <1080>;
> > +   hsync-len = <0 44 60>;
> > +   hfront-porch = <80 88 95>;
> > +   hback-porch = <100 148 160>;
> > +   vfront-porch = <0 4 6>;
> > +   vback-porch = <0 36 50>;
> > +   vsync-len = <0 5 6>;
> > +   };
> > +
> > +The videomode can be linked to a connector via phandles. The connector
> > has to
> > +support the display- and default-mode-property to link to and select a
> > mode.
> > +
> > +Example:
> > +
> > +   hdmi@0012 {
> > +   status = "okay";
> > +   display = <&benq>;
> > +   default-mode = <&mode1>;
> > +   };
> > +
> > diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> > index dfba3e6..a3acaa3 100644
> > --- a/drivers/of/Kconfig
> > +++ b/drivers/of/Kconfig
> > @@ -83,4 +83,9 @@ config OF_MTD
> > 
> > depends on MTD
> > def_bool y
> > 
> > +config OF_VIDEOMODE
> > +   def_bool y
> > +   help
> > + helper to parse videomodes from the devicetree
> > +
> > 
> >  endmenu # OF
> > 
> > diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> > index e027f44..80e6db3 100644
> > --- a/drivers/of/Makefile
> > +++ b/drivers/of/Makefile
> > @@ -11,3 +11,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
> > 
> >  obj-$(CONFIG_OF_PCI)   += of_pci.o
> >  obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o
> >  obj-$(CONFIG_OF_MTD)   += of_m

RE: [media-workshop] [ANNOUNCE] media workshop in November

2012-09-20 Thread Alain VOLMAT

Hi Mauro,

I'd like to attend this one (couldn't attend the one last month in San-Diego).
That would be me and possibly another member (Silvano Vigna) also.

Amount various parts we have in our LinuxDVB/V4L2 model that need discussion 
with you, we would particularly like to discuss about a TSMux (a Mux rather 
than a demux) device within LinuxTV.

Can you confirm the possibility of our attendance?

Regards,

Alain

> -Original Message-
> From: media-workshop-boun...@linuxtv.org 
> [mailto:media-workshop-boun...@linuxtv.org] On
> Behalf Of Mauro Carvalho Chehab
> Sent: mercredi 19 septembre 2012 10:21
> To: media-works...@linuxtv.org; Linux Media Mailing List
> Subject: Re: [media-workshop] [ANNOUNCE] media workshop in November
> 
> Em 19-09-2012 05:11, Mauro Carvalho Chehab escreveu:
> > Dear developers,
> >
> > We're feeling the need for one more media workshop this year.
> >
> > As there will be already several developers going to LinuxCon Europe
> > and Embedded Linux Conference Europe, we'll be co-locating the
> > workshop together with those two events.
> >
> > As there will be several developers speaking about the media subsystem
> > at both LinuxCon and ELCE, we decided to take just one day (September,
> > 8th)
> 
> Sorry, I meant November, 8th.
> 
> > for the media workshop (while we expect that we'll likely have some
> > other discussions during the week).
> >
> > In order to finish the arrangements, I need to know who will be
> > attending, and also we need to receive the theme proposals. Please
> > estimate how long do you think that it would be needed for the
> > proposed theme presentation and discussions.
> >
> > I have a theme proposal already:
> >
> > How to improve the patch submission workflow for media patches - 2 
> > hours.
> >
> > So, please confirm your intention to be there and propose the themes
> > of your interests to media-works...@linuxtv.org mailing list.
> >
> > Thanks!
> > Mauro
> >
> >
> >
> >
> > ___
> > media-workshop mailing list
> > media-works...@linuxtv.org
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
> >
> 
> 
> ___
> media-workshop mailing list
> media-works...@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop
--
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] Timestamps and V4L2

2012-09-20 Thread Rémi Denis-Courmont

Le jeudi 20 septembre 2012 23:21:22, Sakari Ailus a écrit :
> The problem
> ===
> 
> The V4L2 has long used realtime timestamps (such as
> clock_gettime(CLOCK_REALTIME, ...)) to stamp the video buffers before
> handing them over to the user. This has been found problematic in
> associating the video buffers with data from other sources: realtime clock
> may jump around due to daylight saving time, for example, and ALSA
> (audio-video synchronisation is a common use case) user space API does not
> provide the user with realtime timestamps, but instead uses monotonic time
> (i.e. clock_gettime(CLOCK_MONOTONIC, ...)).
> 
> This is especially an issue in embedded systems where video recording is a
> common use case. Drivers typically used in such systems have silently
> switched to use monotonic timestamps. While against the spec, this is
> necessary for those systems to operate properly.
> 
> In general, realtime timestamps are seen of little use in other than
> debugging purposes, but monotonic timestamps are fine for that as well.
> It's still possible that an application I'm not aware of uses them in a
> peculiar way that would be adversely affected by changing to monotonic
> timestamps. Nevertheless, we're not supposed to break the API (or ABI).

You cannot break something that never worked. Aside from debugging, the main 
use of timestamp is to synchronize the video signal with something else and/or 
to detect drift (which is more or less the same thing anyway).

The current timestamp infos are _not_ usable. gstreamer has some fuzzy logic 
to try to figure out what it really means. VLC just ignores it and generates 
its own imprecise timestamp.

> It'd be also very important for the application to know what kind of
> timestamps are provided by the device.

I would rather expect the HAL to convert the timestamp to something standard 
than have the application deal with an ever expanding list of types of 
timestamp that need to be supported.

In other words, either V4L2 converts the timestamp to a type set by the 
application, or there is only one type of timestamp at all (CLOCK_MONOTONIC).
Anything else *will* fail.

> Requirements, wishes and constraints
> 
> 
> Now that it seems to be about the time to fix these issues, it's worth
> looking a little bit to the future to anticipate the coming changes to be
> able to accommodate them better later on.
> 
> - The new default should be monotonic. As the monotonic timestamps are seen
> to be the most useful, they should be made the default.

> - timeval vs. timespec.
> (...)

> - Users should know what kind of timestamps the device produces. This
> includes existing and future kernels. What should be considered are
> uninformed porting drivers back and forth across kernel versions and
> out-of-date kernel header files.
> 
> - Device-dependent timestamps. Some devices such as the uvcvideo ones
> produce device-dependent timestamps for synchronising video and audio, both
> produced by the same physical hardware device. For uvcvideo these
> timestamps are unsigned 32-bit integers.
> 
> - There's also another clock, Linux-specific raw monotonic clock (as in
> clock_gettime(CLOCK_RAW_MONOTONIC, ...)) that could be better in some use
> cases than the regular monotonic clock. The difference is that the raw
> monotonic clock is free from the NTP adjustments. It would be nice for the
> user to be able to choose the clock used for timestamps. This is especially
> important for device-dependent timestamps: not all applications can be
> expected to be able to use them.

Then you need to create a new VIODIC_S_CLOCK control. If the control fails, 
then the application knows that it cannot trust the timestamp. So there is no 
need for a version number neither a flag.

This does seem overkill though. You'll need to keep a clockid_t for each open 
V4L2 file handle.

> - The field adjacent to timestamp, timecode, is 128 bits wide, and not used
> by a single driver. This field could be re-used.
> 
> 
> Possible solutions
> ==
> 
> Not all of the solutions below that have been proposed are mutually
> exclusive. That's also what's making the choice difficult: the ultimate
> solution to the issue of timestamping may involve several of these --- or
> possibly something better that's not on the list.
> 
> 
> Use of timespec
> ---
> 
> If we can conclude timespec will always fit into the size of timeval (or
> timecode) we could use timespec instead. The solution should still make
> the use of timespec explicit to the user space. This seems to conflict with
> the idea of making monotonic timestamps the default: the default can't be
> anything incompatible with timeval, and at the same time it's the most
> important that the monotonic timestamps are timespec.

That is totally irrelevant. If the application knows what type of timestamp is 
used, it knows whether to use timespec or timeval, presumably timespec. If th

[GIT PULL FOR 3.7] SMIA++ fixes and improvements

2012-09-20 Thread Sakari Ailus

Hi Mauro,

This patch contains three fixes for the SMIA++ driver and one patch that
provides additional module identification information through sysfs --- the
non-volatile memory contents are already provided through sysfs.

The following changes since commit 780d61704cf62a51c06c0ca8210d0282591e00b2:

  [media] gspca_pac7302: extend register documentation (2012-09-13 17:54:49 
-0300)

are available in the git repository at:
  ssh://linuxtv.org/git/sailus/media_tree.git smiapp-for-3.7

Sachin Kamat (2):
  smiapp: Use devm_* functions in smiapp-core.c file
  smiapp: Remove unused function

Sakari Ailus (2):
  smiapp: Use highest bits-per-pixel for sensor internal format
  smiapp: Provide module identification information through sysfs

 drivers/media/i2c/smiapp/smiapp-core.c  |   81 ---
 drivers/media/i2c/smiapp/smiapp-quirk.c |   20 
 2 files changed, 42 insertions(+), 59 deletions(-)

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

[RFC] Timestamps and V4L2

2012-09-20 Thread Sakari Ailus

Hi all,


This RFC intends to summarise and further the recent discussion on
linux-media regarding the proposed changes of timestamping V4L2 buffers.


The problem
===

The V4L2 has long used realtime timestamps (such as
clock_gettime(CLOCK_REALTIME, ...)) to stamp the video buffers before
handing them over to the user. This has been found problematic in
associating the video buffers with data from other sources: realtime clock
may jump around due to daylight saving time, for example, and ALSA
(audio-video synchronisation is a common use case) user space API does not
provide the user with realtime timestamps, but instead uses monotonic time
(i.e. clock_gettime(CLOCK_MONOTONIC, ...)).

This is especially an issue in embedded systems where video recording is a
common use case. Drivers typically used in such systems have silently
switched to use monotonic timestamps. While against the spec, this is
necessary for those systems to operate properly.

In general, realtime timestamps are seen of little use in other than
debugging purposes, but monotonic timestamps are fine for that as well. It's
still possible that an application I'm not aware of uses them in a peculiar
way that would be adversely affected by changing to monotonic timestamps.
Nevertheless, we're not supposed to break the API (or ABI). It'd be also
very important for the application to know what kind of timestamps are
provided by the device.


Requirements, wishes and constraints


Now that it seems to be about the time to fix these issues, it's worth
looking a little bit to the future to anticipate the coming changes to be
able to accommodate them better later on.

- The new default should be monotonic. As the monotonic timestamps are seen
to be the most useful, they should be made the default.

- timeval vs. timespec. The two structs can be used to store timestamp
information. They are not compatible with each other. It's a little bit
uncertain what's the case with all the architectures but it looks like the
timespec fits into the space of timeval in all cases. If timespec is
considered to be used somewhere the compatibility must be ensured. Timespec
is better than timeval since timespec has more precision and it's the same
struct that's used everywhere else in the V4L2 API: timespec does not need
conversion to timespec in the user space.

struct timespec {
__kernel_time_t tv_sec; /* seconds */
longtv_nsec;/* nanoseconds */
};

struct timeval {
__kernel_time_t tv_sec; /* seconds */
__kernel_suseconds_ttv_usec;/* microseconds */
};

To be able to use timespec, the user would have to most likely explicitly
choose to do that.

- Users should know what kind of timestamps the device produces. This
includes existing and future kernels. What should be considered are
uninformed porting drivers back and forth across kernel versions and
out-of-date kernel header files.

- Device-dependent timestamps. Some devices such as the uvcvideo ones
produce device-dependent timestamps for synchronising video and audio, both
produced by the same physical hardware device. For uvcvideo these timestamps
are unsigned 32-bit integers.

- There's also another clock, Linux-specific raw monotonic clock (as in
clock_gettime(CLOCK_RAW_MONOTONIC, ...)) that could be better in some use
cases than the regular monotonic clock. The difference is that the raw
monotonic clock is free from the NTP adjustments. It would be nice for the
user to be able to choose the clock used for timestamps. This is especially
important for device-dependent timestamps: not all applications can be
expected to be able to use them.

- The field adjacent to timestamp, timecode, is 128 bits wide, and not used
by a single driver. This field could be re-used.


Possible solutions
==

Not all of the solutions below that have been proposed are mutually
exclusive. That's also what's making the choice difficult: the ultimate
solution to the issue of timestamping may involve several of these --- or
possibly something better that's not on the list.


Use of timespec
---

If we can conclude timespec will always fit into the size of timeval (or
timecode) we could use timespec instead. The solution should still make
the use of timespec explicit to the user space. This seems to conflict with
the idea of making monotonic timestamps the default: the default can't be
anything incompatible with timeval, and at the same time it's the most
important that the monotonic timestamps are timespec.


Kernel version as indicator of timestamp


Conversion of drivers to use monotonic timestamp is trivial, so the
conversion could be done once and for all drivers. The kernel version could
be used to indicate the type of the timestamp.

If this approach is taken care must be taken when new drivers are
integrated: developers s

Re: [PATCH] Support for Asus MyCinema U3100Mini Plus


On 09/20/2012 10:28 PM, Oliver Schinagl wrote:

On 20-09-12 21:15, Antti Palosaari wrote:

On 09/20/2012 09:57 PM, oli...@schinagl.nl wrote:

From: Oliver Schinagl 

This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly.

Scanning using dvbscan works without problems, Locking onto a channel
using tzap also works fine. Only playback using tzap -r + mplayer was
tested and was fully functional.

It uses the af9035 USB Bridge chip, with an af9033 demodulator. The
tuner
used is the FCI FC2580.

Signed-off-by: Oliver Schinagl 


Acked-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 

It is OK. Mauro, please merge to the master.

I do hope that it won't be a problem as I based it on your
remotes/origin/for_v3.7-13


@Oliver, you didn't fixed FC2580 useless braces as I requested.
Anyway, I will sent another patch to fix it later. Action not required.

Ah, I did comment on that change in my reply on your comments; a
re-paste from that:

Checkpatch did not trigger on this. Which makes sense. Kernel
CodingStyle is in very strong favor of K&R and from what I know from
K&R, K&R strongly discourage not using braces as it is very likely to
introduce bugs. Wikipedia has a small mention of this, then again
wikipedia is wikipedia.


I am quite sure it says braces are not allowed for if () when it is 
single line.



I will take it out of you really want it out, but with checkpatch not
even complaining, I would think this as an improvement. :D


Seems like you are correct, it does not detect it from the patch for 
reason or the other. Maybe you could sent patch to fix checkpatch.pl :)


But it seems to find it when asked to check file correctness.

Anyway, my eyes seems to be again more careful than checkpatch ;-)

[crope@localhost linux]$ git show --format=email | ./scripts/checkpatch.pl -
total: 0 errors, 0 warnings, 141 lines checked

Your patch has no obvious style problems and is ready for submission.
[crope@localhost linux]$ ./scripts/checkpatch.pl --file 
drivers/media/tuners/fc2580.c

WARNING: braces {} are not necessary for single statement blocks
#501: FILE: media/tuners/fc2580.c:501:
+   if ((chip_id != 0x56) && (chip_id != 0x5a)) {
+   goto err;
+   }

total: 0 errors, 1 warnings, 525 lines checked

drivers/media/tuners/fc2580.c has style problems, please review.

If any of these errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[crope@localhost linux]$

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: [PATCH] Support for Asus MyCinema U3100Mini Plus

2012-09-20 Thread Oliver Schinagl


On 20-09-12 21:15, Antti Palosaari wrote:

On 09/20/2012 09:57 PM, oli...@schinagl.nl wrote:

From: Oliver Schinagl 

This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly.

Scanning using dvbscan works without problems, Locking onto a channel
using tzap also works fine. Only playback using tzap -r + mplayer was
tested and was fully functional.

It uses the af9035 USB Bridge chip, with an af9033 demodulator. The 
tuner

used is the FCI FC2580.

Signed-off-by: Oliver Schinagl 


Acked-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 

It is OK. Mauro, please merge to the master.
I do hope that it won't be a problem as I based it on your 
remotes/origin/for_v3.7-13


@Oliver, you didn't fixed FC2580 useless braces as I requested. 
Anyway, I will sent another patch to fix it later. Action not required.
Ah, I did comment on that change in my reply on your comments; a 
re-paste from that:


Checkpatch did not trigger on this. Which makes sense. Kernel 
CodingStyle is in very strong favor of K&R and from what I know from 
K&R, K&R strongly discourage not using braces as it is very likely to 
introduce bugs. Wikipedia has a small mention of this, then again 
wikipedia is wikipedia.


I will take it out of you really want it out, but with checkpatch not 
even complaining, I would think this as an improvement. :D






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: [PATCH] Support for Asus MyCinema U3100Mini Plus

2012-09-20 Thread Devin Heitmueller

On Thu, Sep 20, 2012 at 2:54 PM, Oliver Schinagl
 wrote:
> dvbscan and dvbv5-scan does constantly say 'tuning failed' but it does say
> that on my terratec too. It does work fine however, so probably a bug in
> driver/tool unrelated to this patch.

Just to be clear, the message "tuning failed" is expected behavior
(albeit very misleading).  Basically it means that the tuning attempt
was performed but it failed to get a frequency lock on that channel.
This is very common in cases where you're scanning a range of
frequencies where many of them will not actually achieve a signal
lock.

I would really like to change that message to something more clear,
especially since you're certainly not the first one to think it
indicated there was a problem.  Suggestions/patches welcome.

Devin

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

Re: [PATCH] Support for Asus MyCinema U3100Mini Plus


On 09/20/2012 09:57 PM, oli...@schinagl.nl wrote:

From: Oliver Schinagl 

This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly.

Scanning using dvbscan works without problems, Locking onto a channel
using tzap also works fine. Only playback using tzap -r + mplayer was
tested and was fully functional.

It uses the af9035 USB Bridge chip, with an af9033 demodulator. The tuner
used is the FCI FC2580.

Signed-off-by: Oliver Schinagl 


Acked-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 

It is OK. Mauro, please merge to the master.

@Oliver, you didn't fixed FC2580 useless braces as I requested. Anyway, 
I will sent another patch to fix it later. Action not required.


regards
Antti



---
  drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
  drivers/media/dvb-frontends/af9033.c  |  4 
  drivers/media/dvb-frontends/af9033.h  |  1 +
  drivers/media/dvb-frontends/af9033_priv.h | 37 +++
  drivers/media/tuners/fc2580.c |  3 ++-
  drivers/media/usb/dvb-usb-v2/Kconfig  |  1 +
  drivers/media/usb/dvb-usb-v2/af9035.c | 27 ++
  drivers/media/usb/dvb-usb-v2/af9035.h |  1 +
  8 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index d572307..58e0220 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -329,6 +329,7 @@
  #define USB_PID_ASUS_U30000x171f
  #define USB_PID_ASUS_U3000H   0x1736
  #define USB_PID_ASUS_U31000x173f
+#define USB_PID_ASUS_U3100MINI_PLUS0x1779
  #define USB_PID_YUAN_EC372S   0x1edc
  #define USB_PID_YUAN_STK7700PH0x1f08
  #define USB_PID_YUAN_PD378S   0x2edc
diff --git a/drivers/media/dvb-frontends/af9033.c 
b/drivers/media/dvb-frontends/af9033.c
index 0979ada..b40f5a0 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -314,6 +314,10 @@ static int af9033_init(struct dvb_frontend *fe)
len = ARRAY_SIZE(tuner_init_tda18218);
init = tuner_init_tda18218;
break;
+   case AF9033_TUNER_FC2580:
+   len = ARRAY_SIZE(tuner_init_fc2580);
+   init = tuner_init_fc2580;
+   break;
default:
dev_dbg(&state->i2c->dev, "%s: unsupported tuner ID=%d\n",
__func__, state->cfg.tuner);
diff --git a/drivers/media/dvb-frontends/af9033.h 
b/drivers/media/dvb-frontends/af9033.h
index 288622b..bfa4313 100644
--- a/drivers/media/dvb-frontends/af9033.h
+++ b/drivers/media/dvb-frontends/af9033.h
@@ -42,6 +42,7 @@ struct af9033_config {
  #define AF9033_TUNER_FC0011  0x28 /* Fitipower FC0011 */
  #define AF9033_TUNER_MXL5007T0xa0 /* MaxLinear MxL5007T */
  #define AF9033_TUNER_TDA182180xa1 /* NXP TDA 18218HN */
+#define AF9033_TUNER_FC2580  0x32 /* FCI FC2580 */
u8 tuner;

/*
diff --git a/drivers/media/dvb-frontends/af9033_priv.h 
b/drivers/media/dvb-frontends/af9033_priv.h
index 0b783b9..34dddcd 100644
--- a/drivers/media/dvb-frontends/af9033_priv.h
+++ b/drivers/media/dvb-frontends/af9033_priv.h
@@ -466,5 +466,42 @@ static const struct reg_val tuner_init_tda18218[] = {
{0x80f1e6, 0x00},
  };

+/* FCI FC2580 tuner init */
+static const struct reg_val tuner_init_fc2580[] = {
+   { 0x800046, 0x32 },
+   { 0x800057, 0x01 },
+   { 0x800058, 0x00 },
+   { 0x80005f, 0x00 },
+   { 0x800060, 0x00 },
+   { 0x800071, 0x05 },
+   { 0x800072, 0x02 },
+   { 0x800074, 0x01 },
+   { 0x800079, 0x01 },
+   { 0x800093, 0x00 },
+   { 0x800094, 0x00 },
+   { 0x800095, 0x00 },
+   { 0x800096, 0x05 },
+   { 0x8000b3, 0x01 },
+   { 0x8000c3, 0x01 },
+   { 0x8000c4, 0x00 },
+   { 0x80f007, 0x00 },
+   { 0x80f00c, 0x19 },
+   { 0x80f00d, 0x1A },
+   { 0x80f00e, 0x00 },
+   { 0x80f00f, 0x02 },
+   { 0x80f010, 0x00 },
+   { 0x80f011, 0x02 },
+   { 0x80f012, 0x00 },
+   { 0x80f013, 0x02 },
+   { 0x80f014, 0x00 },
+   { 0x80f015, 0x02 },
+   { 0x80f01f, 0x96 },
+   { 0x80f020, 0x00 },
+   { 0x80f029, 0x96 },
+   { 0x80f02a, 0x00 },
+   { 0x80f077, 0x01 },
+   { 0x80f1e6, 0x01 },
+};
+
  #endif /* AF9033_PRIV_H */

diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
index afc0491..51bc39c 100644
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -498,8 +498,9 @@ struct dvb_frontend *fc2580_attach(struct dvb_frontend *fe,

dev_dbg(&priv->i2c->dev, "%s: chip_id=%02x\n", __func__, chip_id);

-   if (chip_id != 0x56)
+   if ((chip_id != 0x56) && (chip_id != 0x5a)) {

cron job: media_tree daily build: ERRORS

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 Sep 20 19:00:22 CEST 2012
git hash:4313902ebe33155209472215c62d2f29d117be29
gcc version:  i686-linux-gcc (GCC) 4.7.1
host hardware:x86_64
host os:  3.4.07-marune

linux-git-arm-eabi-davinci: WARNINGS
linux-git-arm-eabi-exynos: OK
linux-git-arm-eabi-omap: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: OK
linux-git-sh: ERRORS
linux-git-x86_64: 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: ERRORS
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
linux-3.4-x86_64: WARNINGS
linux-3.5-x86_64: WARNINGS
linux-3.6-rc2-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: ERRORS
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-3.4-i686: WARNINGS
linux-3.5-i686: WARNINGS
linux-3.6-rc2-i686: 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: [PATCH] Support for Asus MyCinema U3100Mini Plus

2012-09-20 Thread Oliver Schinagl


On 19-09-12 23:36, Antti Palosaari wrote:
This is review, please fix those minor findings mentioned and resend 
fixed patch!

Will do!


On 09/19/2012 09:44 PM, oli...@schinagl.nl wrote:

From: Oliver Schinagl 

This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly.

Scanning using dvbscan works without problems, Locking onto a channel
using tzap also works fine. Only playback using tzap -r + mplayer was
tested and was fully functional.

It uses the af9035 USB Bridge chip, with an af9033 demodulator. The 
tuner

used is the FCI FC2580.

Signed-off-by: Oliver Schinagl 
---
  drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
  drivers/media/dvb-frontends/af9033.c  |  4 
  drivers/media/dvb-frontends/af9033.h  |  1 +
  drivers/media/dvb-frontends/af9033_priv.h | 38 
+++

  drivers/media/tuners/fc2580.c |  3 ++-
  drivers/media/usb/dvb-usb-v2/Kconfig  |  1 +
  drivers/media/usb/dvb-usb-v2/af9035.c | 27 ++
  drivers/media/usb/dvb-usb-v2/af9035.h |  1 +
  8 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h

index d572307..58e0220 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -329,6 +329,7 @@
  #define USB_PID_ASUS_U30000x171f
  #define USB_PID_ASUS_U3000H0x1736
  #define USB_PID_ASUS_U31000x173f
+#define USB_PID_ASUS_U3100MINI_PLUS0x1779
  #define USB_PID_YUAN_EC372S0x1edc
  #define USB_PID_YUAN_STK7700PH0x1f08
  #define USB_PID_YUAN_PD378S0x2edc
diff --git a/drivers/media/dvb-frontends/af9033.c 
b/drivers/media/dvb-frontends/af9033.c

index 0979ada..b40f5a0 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -314,6 +314,10 @@ static int af9033_init(struct dvb_frontend *fe)
  len = ARRAY_SIZE(tuner_init_tda18218);
  init = tuner_init_tda18218;
  break;
+case AF9033_TUNER_FC2580:
+len = ARRAY_SIZE(tuner_init_fc2580);
+init = tuner_init_fc2580;
+break;
  default:
  dev_dbg(&state->i2c->dev, "%s: unsupported tuner ID=%d\n",
  __func__, state->cfg.tuner);
diff --git a/drivers/media/dvb-frontends/af9033.h 
b/drivers/media/dvb-frontends/af9033.h
index 288622b..739137e 100644 This is review, please fix those minor 
findings mentioned an

--- a/drivers/media/dvb-frontends/af9033.h
+++ b/drivers/media/dvb-frontends/af9033.h
@@ -42,6 +42,7 @@ struct af9033_config {
  #define AF9033_TUNER_FC0011  0x28 /* Fitipower FC0011 */
  #define AF9033_TUNER_MXL5007T0xa0 /* MaxLinear MxL5007T */
  #define AF9033_TUNER_TDA182180xa1 /* NXP TDA 18218HN */
+#define AF9033_TUNER_FC2580  0x32 /* FIC FC2580 */


typo in name
It took me atleast 5 minutes to realize I wrote FCI as FIC. I corrected 
all instances.



  u8 tuner;

  /*
diff --git a/drivers/media/dvb-frontends/af9033_priv.h 
b/drivers/media/dvb-frontends/af9033_priv.h

index 0b783b9..d2c9ae6 100644
--- a/drivers/media/dvb-frontends/af9033_priv.h
+++ b/drivers/media/dvb-frontends/af9033_priv.h
@@ -466,5 +466,43 @@ static const struct reg_val 
tuner_init_tda18218[] = {

  {0x80f1e6, 0x00},
  };

+/* FIC FC2580 tuner init
+   AF9033_TUNER_FC2580  = 0x32 */
+static const struct reg_val tuner_init_fc2580[] = {
+{ 0x800046, AF9033_TUNER_FC2580 },


Personally I don't like that define here. It causes some extra work 
last time I looked USB sniffs as *just* that field is the field you 
are first looking for. I am going to change it anyway, feel free to 
leave if you wish, it is not error, thus I am not going to say you 
must change it.
I was actually going to ask if it is 100% guaranteed to always be the 
tuner identifier here. If that is the case, for all tuners, I don't see 
the harm, especially with comment above. But I have removed it as per 
request, and also since I  doubt one can always guarantee that all 
tuners have the tunerid there.



+{ 0x800057, 0x01 },
+{ 0x800058, 0x00 },
+{ 0x80005f, 0x00 },
+{ 0x800060, 0x00 },
+{ 0x800071, 0x05 },
+{ 0x800072, 0x02 },
+{ 0x800074, 0x01 },
+{ 0x800079, 0x01 },
+{ 0x800093, 0x00 },
+{ 0x800094, 0x00 },
+{ 0x800095, 0x00 },
+{ 0x800096, 0x05 },
+{ 0x8000b3, 0x01 },
+{ 0x8000c3, 0x01 },
+{ 0x8000c4, 0x00 },
+{ 0x80f007, 0x00 },
+{ 0x80f00c, 0x19 },
+{ 0x80f00d, 0x1A },
+{ 0x80f00e, 0x00 },
+{ 0x80f00f, 0x02 },
+{ 0x80f010, 0x00 },
+{ 0x80f011, 0x02 },
+{ 0x80f012, 0x00 },
+{ 0x80f013, 0x02 },
+{ 0x80f014, 0x00 },
+{ 0x80f015, 0x02 },
+{ 0x80f01f, 0x96 },
+{ 0x80f020, 0x00 },
+{ 0x80f029, 0x96 },
+{ 0x80f02a, 0x00 },
+{ 0x80f077, 0x01 },
+{ 0x80f1e6, 0x01 },
+};
+

[PATCH] Support for Asus MyCinema U3100Mini Plus

2012-09-20 Thread oliver

From: Oliver Schinagl 

This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly.

Scanning using dvbscan works without problems, Locking onto a channel
using tzap also works fine. Only playback using tzap -r + mplayer was
tested and was fully functional.

It uses the af9035 USB Bridge chip, with an af9033 demodulator. The tuner
used is the FCI FC2580.

Signed-off-by: Oliver Schinagl 
---
 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/af9033.c  |  4 
 drivers/media/dvb-frontends/af9033.h  |  1 +
 drivers/media/dvb-frontends/af9033_priv.h | 37 +++
 drivers/media/tuners/fc2580.c |  3 ++-
 drivers/media/usb/dvb-usb-v2/Kconfig  |  1 +
 drivers/media/usb/dvb-usb-v2/af9035.c | 27 ++
 drivers/media/usb/dvb-usb-v2/af9035.h |  1 +
 8 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index d572307..58e0220 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -329,6 +329,7 @@
 #define USB_PID_ASUS_U3000 0x171f
 #define USB_PID_ASUS_U3000H0x1736
 #define USB_PID_ASUS_U3100 0x173f
+#define USB_PID_ASUS_U3100MINI_PLUS0x1779
 #define USB_PID_YUAN_EC372S0x1edc
 #define USB_PID_YUAN_STK7700PH 0x1f08
 #define USB_PID_YUAN_PD378S0x2edc
diff --git a/drivers/media/dvb-frontends/af9033.c 
b/drivers/media/dvb-frontends/af9033.c
index 0979ada..b40f5a0 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -314,6 +314,10 @@ static int af9033_init(struct dvb_frontend *fe)
len = ARRAY_SIZE(tuner_init_tda18218);
init = tuner_init_tda18218;
break;
+   case AF9033_TUNER_FC2580:
+   len = ARRAY_SIZE(tuner_init_fc2580);
+   init = tuner_init_fc2580;
+   break;
default:
dev_dbg(&state->i2c->dev, "%s: unsupported tuner ID=%d\n",
__func__, state->cfg.tuner);
diff --git a/drivers/media/dvb-frontends/af9033.h 
b/drivers/media/dvb-frontends/af9033.h
index 288622b..bfa4313 100644
--- a/drivers/media/dvb-frontends/af9033.h
+++ b/drivers/media/dvb-frontends/af9033.h
@@ -42,6 +42,7 @@ struct af9033_config {
 #define AF9033_TUNER_FC0011  0x28 /* Fitipower FC0011 */
 #define AF9033_TUNER_MXL5007T0xa0 /* MaxLinear MxL5007T */
 #define AF9033_TUNER_TDA182180xa1 /* NXP TDA 18218HN */
+#define AF9033_TUNER_FC2580  0x32 /* FCI FC2580 */
u8 tuner;
 
/*
diff --git a/drivers/media/dvb-frontends/af9033_priv.h 
b/drivers/media/dvb-frontends/af9033_priv.h
index 0b783b9..34dddcd 100644
--- a/drivers/media/dvb-frontends/af9033_priv.h
+++ b/drivers/media/dvb-frontends/af9033_priv.h
@@ -466,5 +466,42 @@ static const struct reg_val tuner_init_tda18218[] = {
{0x80f1e6, 0x00},
 };
 
+/* FCI FC2580 tuner init */
+static const struct reg_val tuner_init_fc2580[] = {
+   { 0x800046, 0x32 },
+   { 0x800057, 0x01 },
+   { 0x800058, 0x00 },
+   { 0x80005f, 0x00 },
+   { 0x800060, 0x00 },
+   { 0x800071, 0x05 },
+   { 0x800072, 0x02 },
+   { 0x800074, 0x01 },
+   { 0x800079, 0x01 },
+   { 0x800093, 0x00 },
+   { 0x800094, 0x00 },
+   { 0x800095, 0x00 },
+   { 0x800096, 0x05 },
+   { 0x8000b3, 0x01 },
+   { 0x8000c3, 0x01 },
+   { 0x8000c4, 0x00 },
+   { 0x80f007, 0x00 },
+   { 0x80f00c, 0x19 },
+   { 0x80f00d, 0x1A },
+   { 0x80f00e, 0x00 },
+   { 0x80f00f, 0x02 },
+   { 0x80f010, 0x00 },
+   { 0x80f011, 0x02 },
+   { 0x80f012, 0x00 },
+   { 0x80f013, 0x02 },
+   { 0x80f014, 0x00 },
+   { 0x80f015, 0x02 },
+   { 0x80f01f, 0x96 },
+   { 0x80f020, 0x00 },
+   { 0x80f029, 0x96 },
+   { 0x80f02a, 0x00 },
+   { 0x80f077, 0x01 },
+   { 0x80f1e6, 0x01 },
+};
+
 #endif /* AF9033_PRIV_H */
 
diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
index afc0491..51bc39c 100644
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -498,8 +498,9 @@ struct dvb_frontend *fc2580_attach(struct dvb_frontend *fe,
 
dev_dbg(&priv->i2c->dev, "%s: chip_id=%02x\n", __func__, chip_id);
 
-   if (chip_id != 0x56)
+   if ((chip_id != 0x56) && (chip_id != 0x5a)) {
goto err;
+   }
 
dev_info(&priv->i2c->dev,
"%s: FCI FC2580 successfully identified\n",
diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig 
b/drivers/media/usb/dvb-usb-v2/Kconfig
index e09930c..834bfec 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++ b/drivers/media/usb/dvb-usb-v2/Kconfig
@

Re: [PATCH] Support for Asus MyCinema U3100Mini Plus

2012-09-20 Thread Oliver Schinagl


On 19-09-12 22:52, Devin Heitmueller wrote:

On Wed, Sep 19, 2012 at 2:44 PM,   wrote:

From: Oliver Schinagl 

This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly.

Scanning using dvbscan works without problems, Locking onto a channel
using tzap also works fine. Only playback using tzap -r + mplayer was
tested and was fully functional.

Hi Oliver,

The previous thread suggested that this driver didn't work with
dvbv5-scan and w_scan.  Is that still the case?  If so, do we really
want a "half working" driver upstream?  Seems like this is more likely
to cause support headaches than the device not being supported at all
(since users will "think" it's supported but it's actually broken in
some pretty common use cases).

After working in antti's changes.
dvbscan: works
dvbv5-scan: works
w_scan -X: works
w_scan -x: works
tzap: works (only tested the 3 available FTA channels)
dvbv5-zap: couldn't figure out how to work it :) It says: Usage: 
dvbv5-zap [OPTION...]  but probably means ? 
I tried several combinations, with both a regular channels.conf file and 
a dvb_channels.conf file. I will play more with it when I find some 
extra time.


dvbscan and dvbv5-scan does constantly say 'tuning failed' but it does 
say that on my terratec too. It does work fine however, so probably a 
bug in driver/tool unrelated to this patch.


Or perhaps I'm mistaken and the issues have been addressed and now it
works with all the common applications.

Devin



--
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: tda18271 driver power consumption

2012-09-20 Thread Michael Krufky

On Thu, Sep 20, 2012 at 1:47 PM, Michael Krufky  wrote:
> On Mon, Aug 6, 2012 at 3:13 PM, Antti Palosaari  wrote:
>> On 08/06/2012 09:57 PM, Michael Krufky wrote:
>>>
>>> On Mon, Aug 6, 2012 at 2:35 PM, Devin Heitmueller
>>>  wrote:

 On Mon, Aug 6, 2012 at 2:19 PM, Antti Palosaari  wrote:
>
> You should understand from DVB driver model:
> * attach() called only once when driver is loaded
> * init() called to wake-up device
> * sleep() called to sleep device
>
> What I would like to say is that there is very big risk to shoot own leg
> when doing some initialization on attach(). For example resuming from
> the
> suspend could cause device reset and if you rely some settings that are
> done
> during attach() you will likely fail as Kernel / USB-host controller has
> reset your device.
>
> See reset_resume from Kernel documentation:
> Documentation/usb/power-management.txt


 Be forewarned:  there is a very high likelihood that this patch will
 cause regressions on hybrid devices due to known race conditions
 related to dvb_frontend sleeping the tuner asynchronously on close.
 This is a hybrid tuner, and unless code is specifically added to the
 bridge or tuner driver, going from digital to analog mode too quickly
 will cause the tuner to be shutdown while it's actively in analog
 mode.

 (I discovered this the hard way when working on problems MythTV users
 reported against the HVR-950q).

 Description of race:

 1.  User opens DVB frontend tunes
 2.  User closes DVB frontend
 3.  User *immediately* opens V4L device using same tuner
 4.  User performs tuning request for analog
 5.  DVB frontend issues sleep() call to tuner, causing analog tuning to
 fail.

 This class of problem isn't seen on DVB only devices or those that
 have dedicated digital tuners not shared for analog usage.  And in
 some cases it isn't noticed because a delay between closing the DVB
 device and opening the analog devices causes the sleep() call to
 happen before the analog tune (in which case you don't hit the race).

 I'm certainly not against improved power management, but it will
 require the race conditions to be fixed first in order to avoid
 regressions.

 Devin

 --
 Devin J. Heitmueller - Kernel Labs
 http://www.kernellabs.com
>>>
>>>
>>> Devin's right.  I'm sorry, please *don't* merge the patch, Mauro.
>>> Antti, you should just call sleep from your driver after attach(), as
>>> I had previously suggested.  We can revisit this some time in the
>>> future after we can be sure that these race conditions wont occur.
>>
>>
>> OK, maybe it is safer then. I have no any hybrid hardware to test...
>>
>> Anyhow, I wonder how many years it will take to resolve that V4L2/DVB API
>> hybrid usage pŕoblem. I ran thinking that recently when looked how to
>> implement DVB SDR for V4L2 API... I could guess problem will not disappear
>> near future even analog TV disappears, because there is surely coming new
>> nasty features which spreads over both V4L2 and DVB APIs.
>
> Guys,
>
> Please take another look at this branch and test if possible -- I
> pushed an additional patch that takes Devin's concerns into account.
> After applying these patches, the tda18271 driver will behave as it
> always has, but it will sleep the tuner after attaching the first
> instance.  If there is only one instance, then this works exactly as
> Antti desires.  If there are more instances, then the tuner will only
> be woken up again during attach if the tda18271_need_cal_on_startup()
> returns non-zero.  The driver does not attempt to re-sleep the
> hardware again during successive attach() calls.
>
> I have not tested this yet myself, but I believe it resolves the
> matter -- please comment.
>
> Regards,
>
> Mike Krufky

...in case the URL got lost:


The following changes since commit 0c7d5a6da75caecc677be1fda207b7578936770d:

  Linux 3.5-rc5 (2012-07-03 22:57:41 +0300)

are available in the git repository at:

  git://linuxtv.org/mkrufky/tuners tda18271

for you to fetch changes up to 4e46c5d1bbb920165fecfe7de18b2c01d9787230:

  tda18271: make 'low-power standby mode after attach' multi-instance
safe (2012-09-20 13:34:29 -0400)


Michael Krufky (2):
  tda18271: enter low-power standby mode at the end of tda18271_attach()
  tda18271: make 'low-power standby mode after attach' multi-instance safe

 drivers/media/common/tuners/tda18271-fe.c |4 
 1 file changed, 4 insertions(+)

Best regards,

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

Re: tda18271 driver power consumption

2012-09-20 Thread Michael Krufky

On Mon, Aug 6, 2012 at 3:13 PM, Antti Palosaari  wrote:
> On 08/06/2012 09:57 PM, Michael Krufky wrote:
>>
>> On Mon, Aug 6, 2012 at 2:35 PM, Devin Heitmueller
>>  wrote:
>>>
>>> On Mon, Aug 6, 2012 at 2:19 PM, Antti Palosaari  wrote:

 You should understand from DVB driver model:
 * attach() called only once when driver is loaded
 * init() called to wake-up device
 * sleep() called to sleep device

 What I would like to say is that there is very big risk to shoot own leg
 when doing some initialization on attach(). For example resuming from
 the
 suspend could cause device reset and if you rely some settings that are
 done
 during attach() you will likely fail as Kernel / USB-host controller has
 reset your device.

 See reset_resume from Kernel documentation:
 Documentation/usb/power-management.txt
>>>
>>>
>>> Be forewarned:  there is a very high likelihood that this patch will
>>> cause regressions on hybrid devices due to known race conditions
>>> related to dvb_frontend sleeping the tuner asynchronously on close.
>>> This is a hybrid tuner, and unless code is specifically added to the
>>> bridge or tuner driver, going from digital to analog mode too quickly
>>> will cause the tuner to be shutdown while it's actively in analog
>>> mode.
>>>
>>> (I discovered this the hard way when working on problems MythTV users
>>> reported against the HVR-950q).
>>>
>>> Description of race:
>>>
>>> 1.  User opens DVB frontend tunes
>>> 2.  User closes DVB frontend
>>> 3.  User *immediately* opens V4L device using same tuner
>>> 4.  User performs tuning request for analog
>>> 5.  DVB frontend issues sleep() call to tuner, causing analog tuning to
>>> fail.
>>>
>>> This class of problem isn't seen on DVB only devices or those that
>>> have dedicated digital tuners not shared for analog usage.  And in
>>> some cases it isn't noticed because a delay between closing the DVB
>>> device and opening the analog devices causes the sleep() call to
>>> happen before the analog tune (in which case you don't hit the race).
>>>
>>> I'm certainly not against improved power management, but it will
>>> require the race conditions to be fixed first in order to avoid
>>> regressions.
>>>
>>> Devin
>>>
>>> --
>>> Devin J. Heitmueller - Kernel Labs
>>> http://www.kernellabs.com
>>
>>
>> Devin's right.  I'm sorry, please *don't* merge the patch, Mauro.
>> Antti, you should just call sleep from your driver after attach(), as
>> I had previously suggested.  We can revisit this some time in the
>> future after we can be sure that these race conditions wont occur.
>
>
> OK, maybe it is safer then. I have no any hybrid hardware to test...
>
> Anyhow, I wonder how many years it will take to resolve that V4L2/DVB API
> hybrid usage pŕoblem. I ran thinking that recently when looked how to
> implement DVB SDR for V4L2 API... I could guess problem will not disappear
> near future even analog TV disappears, because there is surely coming new
> nasty features which spreads over both V4L2 and DVB APIs.

Guys,

Please take another look at this branch and test if possible -- I
pushed an additional patch that takes Devin's concerns into account.
After applying these patches, the tda18271 driver will behave as it
always has, but it will sleep the tuner after attaching the first
instance.  If there is only one instance, then this works exactly as
Antti desires.  If there are more instances, then the tuner will only
be woken up again during attach if the tda18271_need_cal_on_startup()
returns non-zero.  The driver does not attempt to re-sleep the
hardware again during successive attach() calls.

I have not tested this yet myself, but I believe it resolves the
matter -- please comment.

Regards,

Mike Krufky
--
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] em28xx: PCTV 520e workaround for DRX-K fw loading

This is hack to make device working again.
Looks like we need to wait DRX-K fw loading is ready until tuner
is attached as tuner is behind demod I2C bus.

For some reason it still crash when device is re-plugged without
module unloading...

Signed-off-by: Antti Palosaari 
---
 drivers/media/usb/em28xx/em28xx-dvb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 5b7f2b3..4e46fef 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1128,6 +1128,9 @@ static int em28xx_dvb_init(struct em28xx *dev)
dvb->fe[0] = dvb_attach(drxk_attach, &pctv_520e_drxk,
&dev->i2c_adap);
 
+   /* FIXME: wait demod fw is loaded, up and running */
+   msleep(2000);
+
if (dvb->fe[0]) {
/* attach tuner */
if (!dvb_attach(tda18271_attach, dvb->fe[0], 0x60,
-- 
1.7.11.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 v2 00/34] i.MX multi-platform support

2012-09-20 Thread Arnd Bergmann

On Thursday 20 September 2012, Shawn Guo wrote:
> 
> On Thu, Sep 20, 2012 at 07:39:34AM +, Arnd Bergmann wrote:
> > The first five branches are scheduled to go through the arm-soc tree, so
> > I'm fine with that. For the sound/for-3.7 branch, I'd like to know when
> > to expect that hitting mainline. If it always gets in very early during the
> > merge window, it's probably ok to put the imx/multi-platform patches into
> > the same branch as the other ones in arm-soc and wait for the sound stuff
> > to hit mainline first, otherwise I'd suggest we start a second
> > next/multiplatform-2 branch for imx and send the first part early on
> > but then wait with the second batch before sound gets in.
> > 
> It seems that we will have to go with next/multiplatform-2.  I just
> tried to merge the series with linux-next together, and got some
> non-trivial conflicts with media and mtd tree.  I might have to rebase
> my series on top of these trees to sort out those conflicts.  That said,
> I will have several dependencies outside arm-soc tree, and have to pend
> my series until all those trees get merged into mainline.

Ok, fair enough. I think we can put it in arm-soc/for-next as a staging
branch anyway to give it some exposure to linux-next, and then we can
decide whether a rebase is necessary before sending it to Linus.

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

Re: [PATCH v2 00/34] i.MX multi-platform support

On Thu, Sep 20, 2012 at 07:39:34AM +, Arnd Bergmann wrote:
> The first five branches are scheduled to go through the arm-soc tree, so
> I'm fine with that. For the sound/for-3.7 branch, I'd like to know when
> to expect that hitting mainline. If it always gets in very early during the
> merge window, it's probably ok to put the imx/multi-platform patches into
> the same branch as the other ones in arm-soc and wait for the sound stuff
> to hit mainline first, otherwise I'd suggest we start a second
> next/multiplatform-2 branch for imx and send the first part early on
> but then wait with the second batch before sound gets in.
> 
It seems that we will have to go with next/multiplatform-2.  I just
tried to merge the series with linux-next together, and got some
non-trivial conflicts with media and mtd tree.  I might have to rebase
my series on top of these trees to sort out those conflicts.  That said,
I will have several dependencies outside arm-soc tree, and have to pend
my series until all those trees get merged into mainline.

Shawn
--
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 11/34] media: mx1_camera: remove the driver

On Thu, Sep 20, 2012 at 09:56:34AM -0300, Mauro Carvalho Chehab wrote:
> It is better to mark it as BROKEN for the next Kernel, and then to
> move it to staging, before dropping a broken driver. That gives people
> some time to fix it, if someone has interests on fixing the issues.
> 
Ok.  The driver has already been broken, and the patch marking it BROKEN
does not necessarily need to be in this series.  I will drop the patch
from this series and send a separate patch based on media tree for that.

> >  drivers/media/video/Kconfig |   12 -
> >  drivers/media/video/Makefile|1 -
> >  drivers/media/video/mx1_camera.c|  889 
> > ---
> 
> Btw, this conflicts with the tree renaming patches already at -staging, as
> this driver location is elsewhere.
> 
mx1_camera.c is not a concern any more.  However the series touches
mx2_camera.c and mx3_camera.c as well.  I just tested to merge the
series with linux-next.  Strangely, git does not detect the renaming
for automatically merging changes.

Do you have a stable branch for media patches that I can pull as
dependency?

Shawn
--
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 00/34] i.MX multi-platform support

On Thu, Sep 20, 2012 at 08:47:10AM -0400, Mark Brown wrote:
> On Thu, Sep 20, 2012 at 07:52:15PM +0800, Shawn Guo wrote:
> > On Thu, Sep 20, 2012 at 07:41:50AM -0400, Mark Brown wrote:
> 
> > > It's usually pretty early but Takashi will be on holiday this time so
> > > I'm not sure if things might be different (he was going to send the pull
> > > request from holiday).  I also didn't guarantee that it'll be stable
> > > yet, can someone please tell me what the depenency is here?
> 
> > We need the patch to have all imx drivers mach/* inclusion free,
> > so that we can enable multi-platform support for imx, which is the
> > whole point of the series.
> 
> That doesn't answer the question.  What is the dependency - what is it
> about this patch that something else depends on?  Your cover letters
> just say you'd like to do this but don't mention dependencies at all and
> when I asked the question last night you said the same thing.  I've not
> seen the rest of the series...
> 
Ah, right.  You did get copied on the whole series.  So the whole point
of patch "ASoC: mx27vis: retrieve gpio numbers from platform_data" is
to get rid of inclusion mach/iomux-mx27.h.  This has to be done before
we enable multi-platform support for imx, since mach/* has to be removed
completely for multi-platform build.

> > If your for-3.7 is not stable anyway, I guess the easiest the way
> 
> It probably *is* stable but I'm not enthused about people pulling
> unsigned tags.  I might rebase, though - I'm going to finalise the tree
> in the next few days.
> 
> > to do it might be you drop the patch "ASoC: mx27vis: retrieve gpio
> > numbers from platform_data" from your tree and I have it be part of
> > the series to go via arm-soc tree as a whole.  (This is the original
> > plan that I mentioned in v1 cover letter)
> 
> You just mentioned it as a preference (you said it's something you'd
> like to do), please if you're doing this sort of cross tree thing be
> explicit about what the inter-tree relationships are.  If things need to
> go in via the same tree say so explicitly (and ideally say way this is).
> 
Ok, my bad.

> The main reason I applied it straight away was that Javier mentioned
> that it was a bug fix and it's near the merge window and these random
> ARM cleanup serieses never seem to go in quickly.

The series is planned for 3.7 merge window.  Is it still possible for
you to drop the patch from your tree to ease the process?  Or I will
hold my pull-request to arm-soc until you tell me you have your tree
finalized.

Shawn
--
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: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.

2012-09-20 Thread Laurent Pinchart

Hi Hans,

On Thursday 20 September 2012 08:38:26 Hans Verkuil wrote:
> On Wed September 19 2012 20:46:19 Laurent Pinchart wrote:
> > On Thursday 13 September 2012 12:40:07 Hans Verkuil wrote:
> > > On Thu 13 September 2012 03:24:53 Laurent Pinchart wrote:
> > > > On Friday 07 September 2012 15:29:05 Hans Verkuil wrote:
> > > > > From: Hans Verkuil 
> > > > > 
> > > > > During the 2012 Media Workshop it was decided that bus_info as
> > > > > returned by VIDIOC_QUERYCAP can no longer be empty. It should be a
> > > > > unique identifier, and empty strings are obviously not unique.
> > > > > 
> > > > > Signed-off-by: Hans Verkuil 
> > > > > ---
> > > > > 
> > > > >  Documentation/DocBook/media/v4l/vidioc-querycap.xml |   14 ++--
> > > > >  1 file changed, 10 insertions(+), 4 deletions(-)
> > > > > 
> > > > > diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
> > > > > b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index
> > > > > f33dd74..d5b1248 100644
> > > > > --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
> > > > > +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
> > > > > @@ -90,11 +90,17 @@ ambiguities.
> > > > > 
> > > > >   __u8
> > > > >   bus_info[32]
> > > > >   Location of the device in the system, a
> > > > > 
> > > > > -NUL-terminated ASCII string. For example: "PCI Slot 4". This
> > > > > +NUL-terminated ASCII string. For example: "PCI::05:06.0". This
> > > > > 
> > > > >  information is intended for users, to distinguish multiple
> > > > > 
> > > > > -identical devices. If no such information is available the field
> > > > > may
> > > > > -simply count the devices controlled by the driver, or contain the
> > > > > -empty string (bus_info[0] = 0).
> > > > > +identical devices. If no such information is available the field
> > > > > must
> > > > > +simply count the devices controlled by the driver ("vivi-000"). The
> > > > > bus_info
> > > > > +must start with "PCI:" for PCI boards, "PCIe:" for PCI Express
> > > > > boards,
> > > > > +"usb-" for USB devices, "I2C:" for i2c devices, "ISA:" for ISA
> > > > > devices and
> > > > > +"parport" for parallel port devices.
> > > > 
> > > > What about being a bit more precise than that ? We could specify what
> > > > API drivers must use to fill the bus_info field. For instance, for USB
> > > > devices, usb_make_path() is currently used by most drivers (which, by
> > > > the way, doesn't return a string that starts with "USB:").
> > > 
> > > I thought about that, but should that be defined in the spec? I'm not
> > > sure if that's the right place.
> > 
> > On the other hand, if we don't specify the format of the bus_info field
> > precisely, it will only be usable as an opaque identifier to userspace.
> > What do we want to do with bus_info ? Telling otherwise identical devices
> > apart is a must, but do we want to provide more information to userspace
> > ? If the field had been longer a sysfs path might have been a good idea,
> > but it won't fit.
>
> Well, we can use the bus_info to find a device in sysfs. E.g. for the ivtv
> card I get bus_info "PCI::0b:01.0" and the same device is found here in
> sysfs:
> 
> /sys/bus/pci/devices/:0b:01.0

For PCI (and probably PCIe) devices we're probably safe.

> We can try to document the relationship between bus_info and sysfs here and
> that would define bus_info exactly.

That sounds good to me.

> I don't quite see how a usb bus_info maps to sysfs, however. Do you know?

It's a bit more difficult. usb_make_path() uses

snprintf(buf, size, "usb-%s-%s", dev->bus->bus_name, dev->devpath);

to create the path. dev->bus->bus_name is the physical USB host controller 
name, and devpath the USB device path relative to that controller. For 
instance my UVC webcam produces

usb-:00:1d.0-1.4

:00:1d.0 refers to the PCI USB host controller, but doesn't mention that 
it's a PCI device. If I'm not mistaken, 1.4 refers to port 4 on root hub 1.

Knowing that the USB host controller is a PCI device, I can get the USB host 
controller number:

$ ls -d /sys/bus/pci/devices/:00:1d.0/usb[0-9]
/sys/bus/pci/devices/:00:1d.0/usb2

and then go the to USB device itself:

$ ls -d /sys/bus/usb/devices/2-1.4
/sys/bus/usb/devices/2-1.4

That's a bit hackish though.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 11/34] media: mx1_camera: remove the driver

2012-09-20 Thread Mauro Carvalho Chehab

Em 20-09-2012 03:45, Shawn Guo escreveu:
> The mx1_camera driver has been broken for a few release cycles since
> commit 6bd0812 (dmaengine: imx-dma: merge old dma-v1.c with imx-dma.c).
> It seems there is no one even compile tested it since then, as doing
> so will end up with the following error.
> 
>   CC  drivers/media/video/mx1_camera.o
> In file included from drivers/media/video/mx1_camera.c:44:0:
> arch/arm/mach-imx/include/mach/dma-mx1-mx2.h:8:25: fatal error: 
> mach/dma-v1.h: No such file or directory
> 
> It looks that all the related folks have known the breakage [1], but
> no one shows the interest to bring it back to work.  Thus it becomes
> a piece of unmaintained code, so let's remove it.


It is better to mark it as BROKEN for the next Kernel, and then to
move it to staging, before dropping a broken driver. That gives people
some time to fix it, if someone has interests on fixing the issues.

> 
> [1] https://lkml.org/lkml/2012/2/9/171
> 
> Signed-off-by: Shawn Guo 
> Cc: Paulius Zaleckas 
> Cc: Guennadi Liakhovetski 
> Cc: Mauro Carvalho Chehab 
> Cc: linux-media@vger.kernel.org
> ---
>  arch/arm/mach-imx/Makefile  |3 -
>  arch/arm/mach-imx/clk-imx1.c|1 -
>  arch/arm/mach-imx/devices/Kconfig   |3 -
>  arch/arm/mach-imx/devices/Makefile  |1 -
>  arch/arm/mach-imx/devices/devices-common.h  |   10 -
>  arch/arm/mach-imx/devices/platform-mx1-camera.c |   42 --
>  arch/arm/mach-imx/mx1-camera-fiq-ksym.c |   18 -
>  arch/arm/mach-imx/mx1-camera-fiq.S  |   35 -

>  drivers/media/video/Kconfig |   12 -
>  drivers/media/video/Makefile|1 -
>  drivers/media/video/mx1_camera.c|  889 
> ---

Btw, this conflicts with the tree renaming patches already at -staging, as
this driver location is elsewhere.

Regards,
Mauro

>  include/linux/platform_data/camera-mx1.h|   35 -
>  12 files changed, 1050 deletions(-)
>  delete mode 100644 arch/arm/mach-imx/devices/platform-mx1-camera.c
>  delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq-ksym.c
>  delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq.S
>  delete mode 100644 drivers/media/video/mx1_camera.c
>  delete mode 100644 include/linux/platform_data/camera-mx1.h
> 
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index fe47b71..538d0ee 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -35,9 +35,6 @@ obj-y += ssi-fiq.o
>  obj-y += ssi-fiq-ksym.o
>  endif
>  
> -# Support for CMOS sensor interface
> -obj-$(CONFIG_MX1_VIDEO) += mx1-camera-fiq.o mx1-camera-fiq-ksym.o
> -
>  # i.MX1 based machines
>  obj-$(CONFIG_ARCH_MX1ADS) += mach-mx1ads.o
>  obj-$(CONFIG_MACH_SCB9328) += mach-scb9328.o
> diff --git a/arch/arm/mach-imx/clk-imx1.c b/arch/arm/mach-imx/clk-imx1.c
> index b5f90cc..ebfffd2 100644
> --- a/arch/arm/mach-imx/clk-imx1.c
> +++ b/arch/arm/mach-imx/clk-imx1.c
> @@ -84,7 +84,6 @@ int __init mx1_clocks_init(unsigned long fref)
>   i, PTR_ERR(clk[i]));
>  
>   clk_register_clkdev(clk[dma_gate], "ahb", "imx-dma");
> - clk_register_clkdev(clk[csi_gate], NULL, "mx1-camera.0");
>   clk_register_clkdev(clk[mma_gate], "mma", NULL);
>   clk_register_clkdev(clk[usbd_gate], NULL, "imx_udc.0");
>   clk_register_clkdev(clk[per1], "per", "imx-gpt.0");
> diff --git a/arch/arm/mach-imx/devices/Kconfig 
> b/arch/arm/mach-imx/devices/Kconfig
> index cb3e3ee..09d796e 100644
> --- a/arch/arm/mach-imx/devices/Kconfig
> +++ b/arch/arm/mach-imx/devices/Kconfig
> @@ -46,9 +46,6 @@ config IMX_HAVE_PLATFORM_IMX_UDC
>  config IMX_HAVE_PLATFORM_IPU_CORE
>   bool
>  
> -config IMX_HAVE_PLATFORM_MX1_CAMERA
> - bool
> -
>  config IMX_HAVE_PLATFORM_MX2_CAMERA
>   bool
>  
> diff --git a/arch/arm/mach-imx/devices/Makefile 
> b/arch/arm/mach-imx/devices/Makefile
> index ff22ed1..3cfdc37 100644
> --- a/arch/arm/mach-imx/devices/Makefile
> +++ b/arch/arm/mach-imx/devices/Makefile
> @@ -17,7 +17,6 @@ obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_SSI) += 
> platform-imx-ssi.o
>  obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_UART) += platform-imx-uart.o
>  obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_UDC) += platform-imx_udc.o
>  obj-$(CONFIG_IMX_HAVE_PLATFORM_IPU_CORE) += platform-ipu-core.o
> -obj-$(CONFIG_IMX_HAVE_PLATFORM_MX1_CAMERA) += platform-mx1-camera.o
>  obj-$(CONFIG_IMX_HAVE_PLATFORM_MX2_CAMERA) += platform-mx2-camera.o
>  obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_EHCI) += platform-mxc-ehci.o
>  obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_MMC) += platform-mxc-mmc.o
> diff --git a/arch/arm/mach-imx/devices/devices-common.h 
> b/arch/arm/mach-imx/devices/devices-common.h
> index 9e3e3d8..34419b2 100644
> --- a/arch/arm/mach-imx/devices/devices-common.h
> +++ b/arch/arm/mach-imx/devices/devices-common.h
> @@ -199,16 +199,6 @@ struct platform_device *__init imx_add_mx3_sdc_fb(
>   const struct imx_ipu_core_data *da

Re: [PATCH v2 00/34] i.MX multi-platform support

2012-09-20 Thread Mark Brown

On Thu, Sep 20, 2012 at 07:52:15PM +0800, Shawn Guo wrote:
> On Thu, Sep 20, 2012 at 07:41:50AM -0400, Mark Brown wrote:

> > It's usually pretty early but Takashi will be on holiday this time so
> > I'm not sure if things might be different (he was going to send the pull
> > request from holiday).  I also didn't guarantee that it'll be stable
> > yet, can someone please tell me what the depenency is here?

> We need the patch to have all imx drivers mach/* inclusion free,
> so that we can enable multi-platform support for imx, which is the
> whole point of the series.

That doesn't answer the question.  What is the dependency - what is it
about this patch that something else depends on?  Your cover letters
just say you'd like to do this but don't mention dependencies at all and
when I asked the question last night you said the same thing.  I've not
seen the rest of the series...

> If your for-3.7 is not stable anyway, I guess the easiest the way

It probably *is* stable but I'm not enthused about people pulling
unsigned tags.  I might rebase, though - I'm going to finalise the tree
in the next few days.

> to do it might be you drop the patch "ASoC: mx27vis: retrieve gpio
> numbers from platform_data" from your tree and I have it be part of
> the series to go via arm-soc tree as a whole.  (This is the original
> plan that I mentioned in v1 cover letter)

You just mentioned it as a preference (you said it's something you'd
like to do), please if you're doing this sort of cross tree thing be
explicit about what the inter-tree relationships are.  If things need to
go in via the same tree say so explicitly (and ideally say way this is).

The main reason I applied it straight away was that Javier mentioned
that it was a bug fix and it's near the merge window and these random
ARM cleanup serieses never seem to go in quickly.
--
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

[RFCv2 PATCH 10/14] vpif_capture: fix cleanup code.

From: Hans Verkuil 

The cleanup sequence was incorrect and could cause a kernel oops.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/davinci/vpif_capture.c |   41 -
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index 98423b5..5f81e0f 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -2060,7 +2060,8 @@ static __init int vpif_probe(struct platform_device *pdev)
 {
struct vpif_subdev_info *subdevdata;
struct vpif_capture_config *config;
-   int i, j, k, m, q, err;
+   int i, j, k, err;
+   int res_idx = 0;
struct i2c_adapter *i2c_adap;
struct channel_obj *ch;
struct common_obj *common;
@@ -2083,18 +2084,18 @@ static __init int vpif_probe(struct platform_device 
*pdev)
return err;
}
 
-   k = 0;
-   while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) {
+   while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, res_idx))) {
for (i = res->start; i <= res->end; i++) {
if (request_irq(i, vpif_channel_isr, IRQF_SHARED,
"VPIF_Capture",
-   (void *)(&vpif_obj.dev[k]->channel_id))) {
+   (void 
*)(&vpif_obj.dev[res_idx]->channel_id))) {
err = -EBUSY;
-   i--;
+   for (j = 0; j < i; j++)
+   free_irq(j, (void 
*)(&vpif_obj.dev[res_idx]->channel_id));
goto vpif_int_err;
}
}
-   k++;
+   res_idx++;
}
 
for (i = 0; i < VPIF_CAPTURE_MAX_DEVICES; i++) {
@@ -2108,7 +2109,7 @@ static __init int vpif_probe(struct platform_device *pdev)
video_device_release(ch->video_dev);
}
err = -ENOMEM;
-   goto vpif_dev_alloc_err;
+   goto vpif_int_err;
}
 
/* Initialize field of video device */
@@ -2148,7 +2149,7 @@ static __init int vpif_probe(struct platform_device *pdev)
if (vpif_obj.sd == NULL) {
vpif_err("unable to allocate memory for subdevice pointers\n");
err = -ENOMEM;
-   goto vpif_dev_alloc_err;
+   goto vpif_sd_error;
}
 
for (i = 0; i < subdev_count; i++) {
@@ -2197,21 +2198,19 @@ probe_subdev_out:
/* free sub devices memory */
kfree(vpif_obj.sd);
 
-vpif_dev_alloc_err:
-   k = VPIF_CAPTURE_MAX_DEVICES-1;
-   res = platform_get_resource(pdev, IORESOURCE_IRQ, k);
-   i = res->end;
-
-vpif_int_err:
-   for (q = k; q >= 0; q--) {
-   for (m = i; m >= (int)res->start; m--)
-   free_irq(m, (void *)(&vpif_obj.dev[q]->channel_id));
-
-   res = platform_get_resource(pdev, IORESOURCE_IRQ, q-1);
-   if (res)
-   i = res->end;
+vpif_sd_error:
+   for (i = 0; i < VPIF_CAPTURE_MAX_DEVICES; i++) {
+   ch = vpif_obj.dev[i];
+   /* Note: does nothing if ch->video_dev == NULL */
+   video_device_release(ch->video_dev);
}
+vpif_int_err:
v4l2_device_unregister(&vpif_obj.v4l2_dev);
+   for (i = 0; i < res_idx; i++) {
+   res = platform_get_resource(pdev, IORESOURCE_IRQ, i);
+   for (j = res->start; j <= res->end; j++)
+   free_irq(j, (void *)(&vpif_obj.dev[i]->channel_id));
+   }
return err;
 }
 
-- 
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

[RFCv2 PATCH 01/14] vpif_capture: remove unused data structure.

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/davinci/vpif_capture.h |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_capture.h 
b/drivers/media/platform/davinci/vpif_capture.h
index e4b54be..0a3904c 100644
--- a/drivers/media/platform/davinci/vpif_capture.h
+++ b/drivers/media/platform/davinci/vpif_capture.h
@@ -159,10 +159,6 @@ struct config_vpif_params {
u32 video_limit[VPIF_CAPTURE_NUM_CHANNELS];
u8 max_device_type;
 };
-/* Struct which keeps track of the line numbers for the sliced vbi service */
-struct vpif_service_line {
-   u16 service_id;
-   u16 service_line[2];
-};
+
 #endif /* End of __KERNEL__ */
 #endif /* VPIF_CAPTURE_H */
-- 
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

[RFCv2 PATCH 04/14] vpif_display: move output_id to channel_obj.

From: Hans Verkuil 

The output index does not belong to video_obj, it belongs to
channel_obj. Also rename to output_idx to be consistent with
the input_idx name used in vpif_capture.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/davinci/vpif_display.c |   17 ++---
 drivers/media/platform/davinci/vpif_display.h |2 +-
 2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_display.c 
b/drivers/media/platform/davinci/vpif_display.c
index 2c06778..f394599 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1231,7 +1231,6 @@ static int vpif_s_output(struct file *file, void *priv, 
unsigned int i)
 {
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh->channel;
-   struct video_obj *vid_ch = &ch->video;
struct common_obj *common = &ch->common[VPIF_VIDEO_INDEX];
int ret = 0;
 
@@ -1246,7 +1245,7 @@ static int vpif_s_output(struct file *file, void *priv, 
unsigned int i)
if (ret < 0)
vpif_err("Failed to set output standard\n");
 
-   vid_ch->output_id = i;
+   ch->output_idx = i;
return ret;
 }
 
@@ -1254,9 +1253,8 @@ static int vpif_g_output(struct file *file, void *priv, 
unsigned int *i)
 {
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh->channel;
-   struct video_obj *vid_ch = &ch->video;
 
-   *i = vid_ch->output_id;
+   *i = ch->output_idx;
 
return 0;
 }
@@ -1291,9 +1289,8 @@ vpif_enum_dv_timings(struct file *file, void *priv,
 {
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh->channel;
-   struct video_obj *vid_ch = &ch->video;
 
-   return v4l2_subdev_call(vpif_obj.sd[vid_ch->output_id],
+   return v4l2_subdev_call(vpif_obj.sd[ch->output_idx],
video, enum_dv_timings, timings);
 }
 
@@ -1320,7 +1317,7 @@ static int vpif_s_dv_timings(struct file *file, void 
*priv,
}
 
/* Configure subdevice timings, if any */
-   ret = v4l2_subdev_call(vpif_obj.sd[vid_ch->output_id],
+   ret = v4l2_subdev_call(vpif_obj.sd[ch->output_idx],
video, s_dv_timings, timings);
if (ret == -ENOIOCTLCMD) {
vpif_dbg(2, debug, "Custom DV timings not supported by "
@@ -1451,9 +1448,8 @@ static int vpif_dbg_g_register(struct file *file, void 
*priv,
struct v4l2_dbg_register *reg){
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh->channel;
-   struct video_obj *vid_ch = &ch->video;
 
-   return v4l2_subdev_call(vpif_obj.sd[vid_ch->output_id], core,
+   return v4l2_subdev_call(vpif_obj.sd[ch->output_idx], core,
g_register, reg);
 }
 
@@ -1470,9 +1466,8 @@ static int vpif_dbg_s_register(struct file *file, void 
*priv,
struct v4l2_dbg_register *reg){
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh->channel;
-   struct video_obj *vid_ch = &ch->video;
 
-   return v4l2_subdev_call(vpif_obj.sd[vid_ch->output_id], core,
+   return v4l2_subdev_call(vpif_obj.sd[ch->output_idx], core,
s_register, reg);
 }
 #endif
diff --git a/drivers/media/platform/davinci/vpif_display.h 
b/drivers/media/platform/davinci/vpif_display.h
index 8654002..805704c 100644
--- a/drivers/media/platform/davinci/vpif_display.h
+++ b/drivers/media/platform/davinci/vpif_display.h
@@ -62,7 +62,6 @@ struct video_obj {
v4l2_std_id stdid;  /* Currently selected or default
 * standard */
struct v4l2_dv_timings dv_timings;
-   u32 output_id;  /* Current output id */
 };
 
 struct vpif_disp_buffer {
@@ -125,6 +124,7 @@ struct channel_obj {
 * which is being displayed */
u8 initialized; /* flag to indicate whether
 * encoder is initialized */
+   u32 output_idx; /* Current output index */
 
enum vpif_channel_id channel_id;/* Identifies channel */
struct vpif_params vpifparams;
-- 
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

[RFCv2 PATCH 05/14] vpif_capture: remove unnecessary can_route flag.

From: Hans Verkuil 

Calling a subdev op that isn't implemented will just return -ENOIOCTLCMD
No need to have a flag for that.

Signed-off-by: Hans Verkuil 
---
 arch/arm/mach-davinci/board-da850-evm.c   |2 --
 arch/arm/mach-davinci/board-dm646x-evm.c  |2 --
 drivers/media/platform/davinci/vpif_capture.c |   18 --
 include/media/davinci/vpif_types.h|1 -
 4 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index d0954a2..d92e0ab 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1209,7 +1209,6 @@ static struct vpif_subdev_info 
da850_vpif_capture_sdev_info[] = {
},
.input = INPUT_CVBS_VI2B,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
-   .can_route = 1,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol  = 1,
@@ -1225,7 +1224,6 @@ static struct vpif_subdev_info 
da850_vpif_capture_sdev_info[] = {
},
.input = INPUT_SVIDEO_VI2C_VI1C,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
-   .can_route = 1,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol  = 1,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c 
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 958679a..a0be63b 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -603,7 +603,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
},
.input = INPUT_CVBS_VI2B,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
-   .can_route = 1,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
@@ -619,7 +618,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
},
.input = INPUT_SVIDEO_VI2C_VI1C,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
-   .can_route = 1,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index 4233554..81ad6a2 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1502,15 +1502,13 @@ static int vpif_s_input(struct file *file, void *priv, 
unsigned int index)
}
}
 
-   if (subdev_info->can_route) {
-   input = subdev_info->input;
-   output = subdev_info->output;
-   ret = v4l2_subdev_call(vpif_obj.sd[sd_index], video, s_routing,
-   input, output, 0);
-   if (ret < 0) {
-   vpif_dbg(1, debug, "Failed to set input\n");
-   return ret;
-   }
+   input = subdev_info->input;
+   output = subdev_info->output;
+   ret = v4l2_subdev_call(vpif_obj.sd[sd_index], video, s_routing,
+   input, output, 0);
+   if (ret < 0 && ret != -ENOIOCTLCMD) {
+   vpif_dbg(1, debug, "Failed to set input\n");
+   return ret;
}
ch->input_idx = index;
ch->curr_subdev_info = subdev_info;
@@ -1520,7 +1518,7 @@ static int vpif_s_input(struct file *file, void *priv, 
unsigned int index)
 
/* update tvnorms from the sub device input info */
ch->video_dev->tvnorms = chan_cfg->inputs[index].input.std;
-   return ret;
+   return 0;
 }
 
 /**
diff --git a/include/media/davinci/vpif_types.h 
b/include/media/davinci/vpif_types.h
index d8f6ab1..1fe46a5 100644
--- a/include/media/davinci/vpif_types.h
+++ b/include/media/davinci/vpif_types.h
@@ -39,7 +39,6 @@ struct vpif_subdev_info {
struct i2c_board_info board_info;
u32 input;
u32 output;
-   unsigned can_route:1;
struct vpif_interface vpif_if;
 };
 
-- 
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

[RFCv2 PATCH 08/14] vpif_display: first init subdevs, then register device nodes.

From: Hans Verkuil 

When device nodes are registered they must be ready for use
immediately, so make sure the subdevs are loaded first.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/davinci/vpif_display.c |   59 -
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_display.c 
b/drivers/media/platform/davinci/vpif_display.c
index f394599..e71c88f 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1689,6 +1689,32 @@ static __init int vpif_probe(struct platform_device 
*pdev)
}
}
 
+   i2c_adap = i2c_get_adapter(1);
+   config = pdev->dev.platform_data;
+   subdev_count = config->subdev_count;
+   subdevdata = config->subdevinfo;
+   vpif_obj.sd = kzalloc(sizeof(struct v4l2_subdev *) * subdev_count,
+   GFP_KERNEL);
+   if (vpif_obj.sd == NULL) {
+   vpif_err("unable to allocate memory for subdevice pointers\n");
+   err = -ENOMEM;
+   goto vpif_int_err;
+   }
+
+   for (i = 0; i < subdev_count; i++) {
+   vpif_obj.sd[i] = v4l2_i2c_new_subdev_board(&vpif_obj.v4l2_dev,
+   i2c_adap,
+   &subdevdata[i].board_info,
+   NULL);
+   if (!vpif_obj.sd[i]) {
+   vpif_err("Error registering v4l2 subdevice\n");
+   goto probe_subdev_out;
+   }
+
+   if (vpif_obj.sd[i])
+   vpif_obj.sd[i]->grp_id = 1 << i;
+   }
+
for (j = 0; j < VPIF_DISPLAY_MAX_DEVICES; j++) {
ch = vpif_obj.dev[j];
/* Initialize field of the channel objects */
@@ -1724,6 +1750,7 @@ static __init int vpif_probe(struct platform_device *pdev)
ch->common[VPIF_VIDEO_INDEX].fmt.type =
V4L2_BUF_TYPE_VIDEO_OUTPUT;
ch->video_dev->lock = &common->lock;
+   video_set_drvdata(ch->video_dev, ch);
 
/* register video device */
vpif_dbg(1, debug, "channel=%x,channel->video_dev=%x\n",
@@ -1733,42 +1760,12 @@ static __init int vpif_probe(struct platform_device 
*pdev)
  VFL_TYPE_GRABBER, (j ? 3 : 2));
if (err < 0)
goto probe_out;
-
-   video_set_drvdata(ch->video_dev, ch);
-   }
-
-   i2c_adap = i2c_get_adapter(1);
-   config = pdev->dev.platform_data;
-   subdev_count = config->subdev_count;
-   subdevdata = config->subdevinfo;
-   vpif_obj.sd = kzalloc(sizeof(struct v4l2_subdev *) * subdev_count,
-   GFP_KERNEL);
-   if (vpif_obj.sd == NULL) {
-   vpif_err("unable to allocate memory for subdevice pointers\n");
-   err = -ENOMEM;
-   goto probe_out;
-   }
-
-   for (i = 0; i < subdev_count; i++) {
-   vpif_obj.sd[i] = v4l2_i2c_new_subdev_board(&vpif_obj.v4l2_dev,
-   i2c_adap,
-   &subdevdata[i].board_info,
-   NULL);
-   if (!vpif_obj.sd[i]) {
-   vpif_err("Error registering v4l2 subdevice\n");
-   goto probe_subdev_out;
-   }
-
-   if (vpif_obj.sd[i])
-   vpif_obj.sd[i]->grp_id = 1 << i;
}
 
v4l2_info(&vpif_obj.v4l2_dev,
" VPIF display driver initialized\n");
return 0;
 
-probe_subdev_out:
-   kfree(vpif_obj.sd);
 probe_out:
for (k = 0; k < j; k++) {
ch = vpif_obj.dev[k];
@@ -1776,6 +1773,8 @@ probe_out:
video_device_release(ch->video_dev);
ch->video_dev = NULL;
}
+probe_subdev_out:
+   kfree(vpif_obj.sd);
 vpif_int_err:
v4l2_device_unregister(&vpif_obj.v4l2_dev);
vpif_err("VPIF IRQ request failed\n");
-- 
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

[RFCv2 PATCH 09/14] vpif_display: fix cleanup code.

From: Hans Verkuil 

The cleanup sequence was incorrect and could cause a kernel oops.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/davinci/vpif_display.c |   30 +++--
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_display.c 
b/drivers/media/platform/davinci/vpif_display.c
index e71c88f..66b4b32 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1607,7 +1607,8 @@ static __init int vpif_probe(struct platform_device *pdev)
 {
struct vpif_subdev_info *subdevdata;
struct vpif_display_config *config;
-   int i, j = 0, k, q, m, err = 0;
+   int i, j = 0, k, err = 0;
+   int res_idx = 0;
struct i2c_adapter *i2c_adap;
struct common_obj *common;
struct channel_obj *ch;
@@ -1630,21 +1631,21 @@ static __init int vpif_probe(struct platform_device 
*pdev)
return err;
}
 
-   k = 0;
-   while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) {
+   while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, res_idx))) {
for (i = res->start; i <= res->end; i++) {
if (request_irq(i, vpif_channel_isr, IRQF_SHARED,
"VPIF_Display",
-   (void *)(&vpif_obj.dev[k]->channel_id))) {
+   (void 
*)(&vpif_obj.dev[res_idx]->channel_id))) {
err = -EBUSY;
+   for (j = 0; j < i; j++)
+   free_irq(j, (void 
*)(&vpif_obj.dev[res_idx]->channel_id));
goto vpif_int_err;
}
}
-   k++;
+   res_idx++;
}
 
for (i = 0; i < VPIF_DISPLAY_MAX_DEVICES; i++) {
-
/* Get the pointer to the channel object */
ch = vpif_obj.dev[i];
 
@@ -1698,7 +1699,7 @@ static __init int vpif_probe(struct platform_device *pdev)
if (vpif_obj.sd == NULL) {
vpif_err("unable to allocate memory for subdevice pointers\n");
err = -ENOMEM;
-   goto vpif_int_err;
+   goto vpif_sd_error;
}
 
for (i = 0; i < subdev_count; i++) {
@@ -1775,14 +1776,19 @@ probe_out:
}
 probe_subdev_out:
kfree(vpif_obj.sd);
+vpif_sd_error:
+   for (i = 0; i < VPIF_DISPLAY_MAX_DEVICES; i++) {
+   ch = vpif_obj.dev[i];
+   /* Note: does nothing if ch->video_dev == NULL */
+   video_device_release(ch->video_dev);
+   }
 vpif_int_err:
v4l2_device_unregister(&vpif_obj.v4l2_dev);
vpif_err("VPIF IRQ request failed\n");
-   for (q = k; k >= 0; k--) {
-   for (m = i; m >= res->start; m--)
-   free_irq(m, (void *)(&vpif_obj.dev[k]->channel_id));
-   res = platform_get_resource(pdev, IORESOURCE_IRQ, k-1);
-   m = res->end;
+   for (i = 0; i < res_idx; i++) {
+   res = platform_get_resource(pdev, IORESOURCE_IRQ, i);
+   for (j = res->start; j <= res->end; j++)
+   free_irq(j, (void *)(&vpif_obj.dev[i]->channel_id));
}
 
return err;
-- 
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

[RFCv2 PATCH 12/14] vpif_display: use a v4l2_subdev pointer to call a subdev.

From: Hans Verkuil 

This makes it easier to have outputs without subdevs.
This needs more work. The way the outputs are configured should be identical
to how inputs are configured.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/davinci/vpif_display.c |   17 +
 drivers/media/platform/davinci/vpif_display.h |1 +
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_display.c 
b/drivers/media/platform/davinci/vpif_display.c
index 66b4b32..8d1ce09 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1246,6 +1246,8 @@ static int vpif_s_output(struct file *file, void *priv, 
unsigned int i)
vpif_err("Failed to set output standard\n");
 
ch->output_idx = i;
+   if (vpif_obj.sd[i])
+   ch->sd = vpif_obj.sd[i];
return ret;
 }
 
@@ -1317,14 +1319,13 @@ static int vpif_s_dv_timings(struct file *file, void 
*priv,
}
 
/* Configure subdevice timings, if any */
-   ret = v4l2_subdev_call(vpif_obj.sd[ch->output_idx],
-   video, s_dv_timings, timings);
+   ret = v4l2_subdev_call(ch->sd, video, s_dv_timings, timings);
if (ret == -ENOIOCTLCMD) {
vpif_dbg(2, debug, "Custom DV timings not supported by "
"subdevice\n");
-   return -EINVAL;
+   return -ENODATA;
}
-   if (ret < 0) {
+   if (ret < 0 && ret != -ENODEV) {
vpif_dbg(2, debug, "Error setting custom DV timings\n");
return ret;
}
@@ -1449,8 +1450,7 @@ static int vpif_dbg_g_register(struct file *file, void 
*priv,
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh->channel;
 
-   return v4l2_subdev_call(vpif_obj.sd[ch->output_idx], core,
-   g_register, reg);
+   return v4l2_subdev_call(ch->sd, core, g_register, reg);
 }
 
 /*
@@ -1467,8 +1467,7 @@ static int vpif_dbg_s_register(struct file *file, void 
*priv,
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh->channel;
 
-   return v4l2_subdev_call(vpif_obj.sd[ch->output_idx], core,
-   s_register, reg);
+   return v4l2_subdev_call(ch->sd, core, s_register, reg);
 }
 #endif
 
@@ -1737,6 +1736,8 @@ static __init int vpif_probe(struct platform_device *pdev)
 
}
ch->initialized = 0;
+   if (subdev_count)
+   ch->sd = vpif_obj.sd[0];
ch->channel_id = j;
if (j < 2)
ch->common[VPIF_VIDEO_INDEX].numbuffers =
diff --git a/drivers/media/platform/davinci/vpif_display.h 
b/drivers/media/platform/davinci/vpif_display.h
index 805704c..dca2a8c0 100644
--- a/drivers/media/platform/davinci/vpif_display.h
+++ b/drivers/media/platform/davinci/vpif_display.h
@@ -125,6 +125,7 @@ struct channel_obj {
u8 initialized; /* flag to indicate whether
 * encoder is initialized */
u32 output_idx; /* Current output index */
+   struct v4l2_subdev *sd; /* Current output subdev (may be NULL) 
*/
 
enum vpif_channel_id channel_id;/* Identifies channel */
struct vpif_params vpifparams;
-- 
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

[RFCv2 PATCH 11/14] vpif_capture: separate subdev from input.

From: Hans Verkuil 

vpif_capture relied on a 1-1 mapping of input and subdev. This is not
necessarily the case. Separate the two. So there is a list of subdevs
and a list of inputs. Each input refers to a subdev and has routing
information. An input does not have to have a subdev.

The initial input for each channel is set to the fist input.

Currently missing is support for associating multiple subdevs with
an input.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/davinci/vpif_capture.c |  239 -
 drivers/media/platform/davinci/vpif_capture.h |6 +-
 2 files changed, 113 insertions(+), 132 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index 5f81e0f..f97eb0b 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -864,13 +864,11 @@ static unsigned int vpif_poll(struct file *filep, 
poll_table * wait)
  */
 static int vpif_open(struct file *filep)
 {
-   struct vpif_capture_config *config = vpif_dev->platform_data;
struct video_device *vdev = video_devdata(filep);
struct common_obj *common;
struct video_obj *vid_ch;
struct channel_obj *ch;
struct vpif_fh *fh;
-   int i;
 
vpif_dbg(2, debug, "vpif_open\n");
 
@@ -879,24 +877,6 @@ static int vpif_open(struct file *filep)
vid_ch = &ch->video;
common = &ch->common[VPIF_VIDEO_INDEX];
 
-   if (NULL == ch->curr_subdev_info) {
-   /**
-* search through the sub device to see a registered
-* sub device and make it as current sub device
-*/
-   for (i = 0; i < config->subdev_count; i++) {
-   if (vpif_obj.sd[i]) {
-   /* the sub device is registered */
-   ch->curr_subdev_info = &config->subdev_info[i];
-   break;
-   }
-   }
-   if (i == config->subdev_count) {
-   vpif_err("No sub device registered\n");
-   return -ENOENT;
-   }
-   }
-
/* Allocate memory for the file handle object */
fh = kzalloc(sizeof(struct vpif_fh), GFP_KERNEL);
if (NULL == fh) {
@@ -1174,10 +1154,9 @@ static int vpif_streamon(struct file *file, void *priv,
return ret;
 
/* Enable streamon on the sub device */
-   ret = v4l2_subdev_call(vpif_obj.sd[ch->curr_sd_index], video,
-   s_stream, 1);
+   ret = v4l2_subdev_call(ch->sd, video, s_stream, 1);
 
-   if (ret && (ret != -ENOIOCTLCMD)) {
+   if (ret && ret != -ENOIOCTLCMD && ret != -ENODEV) {
vpif_dbg(1, debug, "stream on failed in subdev\n");
return ret;
}
@@ -1237,73 +1216,105 @@ static int vpif_streamoff(struct file *file, void 
*priv,
 
common->started = 0;
 
-   ret = v4l2_subdev_call(vpif_obj.sd[ch->curr_sd_index], video,
-   s_stream, 0);
+   ret = v4l2_subdev_call(ch->sd, video, s_stream, 0);
 
-   if (ret && (ret != -ENOIOCTLCMD))
+   if (ret && ret != -ENOIOCTLCMD && ret != -ENODEV)
vpif_dbg(1, debug, "stream off failed in subdev\n");
 
return vb2_streamoff(&common->buffer_queue, buftype);
 }
 
 /**
- * vpif_map_sub_device_to_input() - Maps sub device to input
- * @ch - ptr to channel
- * @config - ptr to capture configuration
+ * vpif_input_to_subdev() - Maps input to sub device
+ * @vpif_cfg - global config ptr
+ * @chan_cfg - channel config ptr
  * @input_index - Given input index from application
- * @sub_device_index - index into sd table
  *
  * lookup the sub device information for a given input index.
  * we report all the inputs to application. inputs table also
  * has sub device name for the each input
  */
-static struct vpif_subdev_info *vpif_map_sub_device_to_input(
-   struct channel_obj *ch,
-   struct vpif_capture_config *vpif_cfg,
-   int input_index,
-   int *sub_device_index)
+static int vpif_input_to_subdev(
+   struct vpif_capture_config *vpif_cfg,
+   struct vpif_capture_chan_config *chan_cfg,
+   int input_index)
 {
-   struct vpif_capture_chan_config *chan_cfg;
-   struct vpif_subdev_info *subdev_info = NULL;
-   const char *subdev_name = NULL;
+   struct vpif_subdev_info *subdev_info;
+   const char *subdev_name;
int i;
 
-   vpif_dbg(2, debug, "vpif_map_sub_device_to_input\n");
-
-   chan_cfg = &vpif_cfg->chan_config[ch->channel_id];
+   vpif_dbg(2, debug, "vpif_input_to_subdev\n");
 
-   /**
-* search through the inputs to find the sub device supporting
-* the input
-*/
-

[RFCv2 PATCH 13/14] davinci: move struct vpif_interface to chan_cfg.

From: Hans Verkuil 

struct vpif_interface is channel specific, not subdev specific.
Move it to the channel config.

Signed-off-by: Hans Verkuil 
---
 arch/arm/mach-davinci/board-da850-evm.c   |   24 
 arch/arm/mach-davinci/board-dm646x-evm.c  |   24 
 drivers/media/platform/davinci/vpif_capture.c |2 +-
 include/media/davinci/vpif_types.h|2 +-
 4 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 514d4d4..3081ea4 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1211,12 +1211,6 @@ static struct vpif_subdev_info 
da850_vpif_capture_sdev_info[] = {
I2C_BOARD_INFO("tvp5146", 0x5d),
.platform_data = &tvp5146_pdata,
},
-   .vpif_if = {
-   .if_type = VPIF_IF_BT656,
-   .hd_pol  = 1,
-   .vd_pol  = 1,
-   .fid_pol = 0,
-   },
},
{
.name = TVP5147_CH1,
@@ -1224,12 +1218,6 @@ static struct vpif_subdev_info 
da850_vpif_capture_sdev_info[] = {
I2C_BOARD_INFO("tvp5146", 0x5c),
.platform_data = &tvp5146_pdata,
},
-   .vpif_if = {
-   .if_type = VPIF_IF_BT656,
-   .hd_pol  = 1,
-   .vd_pol  = 1,
-   .fid_pol = 0,
-   },
},
 };
 
@@ -1239,10 +1227,22 @@ static struct vpif_capture_config 
da850_vpif_capture_config = {
.chan_config[0] = {
.inputs = da850_ch0_inputs,
.input_count = ARRAY_SIZE(da850_ch0_inputs),
+   .vpif_if = {
+   .if_type = VPIF_IF_BT656,
+   .hd_pol  = 1,
+   .vd_pol  = 1,
+   .fid_pol = 0,
+   },
},
.chan_config[1] = {
.inputs = da850_ch1_inputs,
.input_count = ARRAY_SIZE(da850_ch1_inputs),
+   .vpif_if = {
+   .if_type = VPIF_IF_BT656,
+   .hd_pol  = 1,
+   .vd_pol  = 1,
+   .fid_pol = 0,
+   },
},
.card_name = "DA850/OMAP-L138 Video Capture",
 };
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c 
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 0daec7e..ad249c7 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -601,12 +601,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
I2C_BOARD_INFO("tvp5146", 0x5d),
.platform_data = &tvp5146_pdata,
},
-   .vpif_if = {
-   .if_type = VPIF_IF_BT656,
-   .hd_pol = 1,
-   .vd_pol = 1,
-   .fid_pol = 0,
-   },
},
{
.name   = TVP5147_CH1,
@@ -614,12 +608,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
I2C_BOARD_INFO("tvp5146", 0x5c),
.platform_data = &tvp5146_pdata,
},
-   .vpif_if = {
-   .if_type = VPIF_IF_BT656,
-   .hd_pol = 1,
-   .vd_pol = 1,
-   .fid_pol = 0,
-   },
},
 };
 
@@ -659,10 +647,22 @@ static struct vpif_capture_config dm646x_vpif_capture_cfg 
= {
.chan_config[0] = {
.inputs = dm6467_ch0_inputs,
.input_count = ARRAY_SIZE(dm6467_ch0_inputs),
+   .vpif_if = {
+   .if_type = VPIF_IF_BT656,
+   .hd_pol = 1,
+   .vd_pol = 1,
+   .fid_pol = 0,
+   },
},
.chan_config[1] = {
.inputs = dm6467_ch1_inputs,
.input_count = ARRAY_SIZE(dm6467_ch1_inputs),
+   .vpif_if = {
+   .if_type = VPIF_IF_BT656,
+   .hd_pol = 1,
+   .vd_pol = 1,
+   .fid_pol = 0,
+   },
},
 };
 
diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index f97eb0b..482 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1310,7 +1310,7 @@ static int vpif_set_input(
ch->input_idx = index;
ch->sd = sd;
/* copy interface parameters to vpif */
-   ch->vpifparams.iface = subdev_info->vpif_if;
+   ch->vpifparams.iface = chan_cfg->vpif_if;
 
/* update tvnorms from the sub device input info

[RFCv2 PATCH 02/14] vpif_display: remove unused data structures.

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/davinci/vpif_display.h |   15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_display.h 
b/drivers/media/platform/davinci/vpif_display.h
index 19c7976..8654002 100644
--- a/drivers/media/platform/davinci/vpif_display.h
+++ b/drivers/media/platform/davinci/vpif_display.h
@@ -65,12 +65,6 @@ struct video_obj {
u32 output_id;  /* Current output id */
 };
 
-struct vbi_obj {
-   int num_services;
-   struct vpif_vbi_params vbiparams;   /* vpif parameters for the raw
-* vbi data */
-};
-
 struct vpif_disp_buffer {
struct vb2_buffer vb;
struct list_head list;
@@ -136,7 +130,6 @@ struct channel_obj {
struct vpif_params vpifparams;
struct common_obj common[VPIF_NUMOBJECTS];
struct video_obj video;
-   struct vbi_obj vbi;
 };
 
 /* File handle structure */
@@ -168,12 +161,4 @@ struct config_vpif_params {
u8 min_numbuffers;
 };
 
-/* Struct which keeps track of the line numbers for the sliced vbi service */
-struct vpif_service_line {
-   u16 service_id;
-   u16 service_line[2];
-   u16 enc_service_id;
-   u8 bytestowrite;
-};
-
 #endif /* DAVINCIHD_DISPLAY_H */
-- 
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

[RFCv2 PATCH 06/14] vpif_capture: move routing info from subdev to input.

From: Hans Verkuil 

Routing information is a property of the input, not of the subdev.
One subdev may provide multiple inputs, each with its own routing
information.

Signed-off-by: Hans Verkuil 
---
 arch/arm/mach-davinci/board-da850-evm.c   |8 
 arch/arm/mach-davinci/board-dm646x-evm.c  |8 
 drivers/media/platform/davinci/vpif_capture.c |7 +--
 include/media/davinci/vpif_types.h|4 ++--
 4 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index d92e0ab..514d4d4 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1184,6 +1184,8 @@ static const struct vpif_input da850_ch0_inputs[] = {
.type  = V4L2_INPUT_TYPE_CAMERA,
.std   = TVP514X_STD_ALL,
},
+   .input_route = INPUT_CVBS_VI2B,
+   .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.subdev_name = TVP5147_CH0,
},
 };
@@ -1196,6 +1198,8 @@ static const struct vpif_input da850_ch1_inputs[] = {
.type  = V4L2_INPUT_TYPE_CAMERA,
.std   = TVP514X_STD_ALL,
},
+   .input_route = INPUT_SVIDEO_VI2C_VI1C,
+   .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.subdev_name = TVP5147_CH1,
},
 };
@@ -1207,8 +1211,6 @@ static struct vpif_subdev_info 
da850_vpif_capture_sdev_info[] = {
I2C_BOARD_INFO("tvp5146", 0x5d),
.platform_data = &tvp5146_pdata,
},
-   .input = INPUT_CVBS_VI2B,
-   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol  = 1,
@@ -1222,8 +1224,6 @@ static struct vpif_subdev_info 
da850_vpif_capture_sdev_info[] = {
I2C_BOARD_INFO("tvp5146", 0x5c),
.platform_data = &tvp5146_pdata,
},
-   .input = INPUT_SVIDEO_VI2C_VI1C,
-   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol  = 1,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c 
b/arch/arm/mach-davinci/board-dm646x-evm.c
index a0be63b..0daec7e 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -601,8 +601,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
I2C_BOARD_INFO("tvp5146", 0x5d),
.platform_data = &tvp5146_pdata,
},
-   .input = INPUT_CVBS_VI2B,
-   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
@@ -616,8 +614,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
I2C_BOARD_INFO("tvp5146", 0x5c),
.platform_data = &tvp5146_pdata,
},
-   .input = INPUT_SVIDEO_VI2C_VI1C,
-   .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
@@ -636,6 +632,8 @@ static const struct vpif_input dm6467_ch0_inputs[] = {
.std = TVP514X_STD_ALL,
},
.subdev_name = TVP5147_CH0,
+   .input_route = INPUT_CVBS_VI2B,
+   .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
},
 };
 
@@ -648,6 +646,8 @@ static const struct vpif_input dm6467_ch1_inputs[] = {
.std = TVP514X_STD_ALL,
},
.subdev_name = TVP5147_CH1,
+   .input_route = INPUT_SVIDEO_VI2C_VI1C,
+   .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
},
 };
 
diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index 81ad6a2..e40eacd1 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1464,6 +1464,9 @@ static int vpif_s_input(struct file *file, void *priv, 
unsigned int index)
 
chan_cfg = &config->chan_config[ch->channel_id];
 
+   if (index >= chan_cfg->input_count)
+   return -EINVAL;
+
if (common->started) {
vpif_err("Streaming in progress\n");
return -EBUSY;
@@ -1502,8 +1505,8 @@ static int vpif_s_input(struct file *file, void *priv, 
unsigned int index)
}
}
 
-   input = subdev_info->input;
-   output = subdev_info->output;
+   input = chan_cfg->inputs[index].input_route;
+   output = chan_cfg->inputs[index].output_route;
ret =

[RFCv2 PATCH 03/14] vpif_capture: move input_idx to channel_obj.

From: Hans Verkuil 

input_idx does not belong to video_obj. Move it where it belongs.
Also remove the bogus code in the open() function that suddenly
changes the input to 0 for no reason.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/davinci/vpif_capture.c |9 ++---
 drivers/media/platform/davinci/vpif_capture.h |4 ++--
 2 files changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index 78edd01..4233554 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -888,8 +888,6 @@ static int vpif_open(struct file *filep)
if (vpif_obj.sd[i]) {
/* the sub device is registered */
ch->curr_subdev_info = &config->subdev_info[i];
-   /* make first input as the current input */
-   vid_ch->input_idx = 0;
break;
}
}
@@ -1442,10 +1440,8 @@ static int vpif_g_input(struct file *file, void *priv, 
unsigned int *index)
 {
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh->channel;
-   struct video_obj *vid_ch = &ch->video;
-
-   *index = vid_ch->input_idx;
 
+   *index = ch->input_idx;
return 0;
 }
 
@@ -1462,7 +1458,6 @@ static int vpif_s_input(struct file *file, void *priv, 
unsigned int index)
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh->channel;
struct common_obj *common = &ch->common[VPIF_VIDEO_INDEX];
-   struct video_obj *vid_ch = &ch->video;
struct vpif_subdev_info *subdev_info;
int ret = 0, sd_index = 0;
u32 input = 0, output = 0;
@@ -1517,7 +1512,7 @@ static int vpif_s_input(struct file *file, void *priv, 
unsigned int index)
return ret;
}
}
-   vid_ch->input_idx = index;
+   ch->input_idx = index;
ch->curr_subdev_info = subdev_info;
ch->curr_sd_index = sd_index;
/* copy interface parameters to vpif */
diff --git a/drivers/media/platform/davinci/vpif_capture.h 
b/drivers/media/platform/davinci/vpif_capture.h
index 0a3904c..a284667 100644
--- a/drivers/media/platform/davinci/vpif_capture.h
+++ b/drivers/media/platform/davinci/vpif_capture.h
@@ -54,8 +54,6 @@ struct video_obj {
/* Currently selected or default standard */
v4l2_std_id stdid;
struct v4l2_dv_timings dv_timings;
-   /* This is to track the last input that is passed to application */
-   u32 input_idx;
 };
 
 struct vpif_cap_buffer {
@@ -121,6 +119,8 @@ struct channel_obj {
enum vpif_channel_id channel_id;
/* index into sd table */
int curr_sd_index;
+   /* Current input */
+   u32 input_idx;
/* ptr to current sub device information */
struct vpif_subdev_info *curr_subdev_info;
/* vpif configuration params */
-- 
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

[RFCv2 PATCH 14/14] tvp514x: s_routing should just change routing, not try to detect a signal.

From: Hans Verkuil 

The s_routing function should not try to detect a signal. It is a really
bad idea to try to detect a valid video signal and return an error if
you can't. Changing input should do just that and nothing more.

Also don't power on the ADCs on s_routing, instead do that on querystd.

Signed-off-by: Hans Verkuil 
---
 drivers/media/i2c/tvp514x.c |   77 ---
 1 file changed, 6 insertions(+), 71 deletions(-)

diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index 1f3943b..d5e1021 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -519,6 +519,12 @@ static int tvp514x_querystd(struct v4l2_subdev *sd, 
v4l2_std_id *std_id)
 
*std_id = V4L2_STD_UNKNOWN;
 
+   /* To query the standard the TVP514x must power on the ADCs. */
+   if (!decoder->streaming) {
+   tvp514x_s_stream(sd, 1);
+   msleep(LOCK_RETRY_DELAY);
+   }
+
/* query the current standard */
current_std = tvp514x_query_current_std(sd);
if (current_std == STD_INVALID)
@@ -625,25 +631,12 @@ static int tvp514x_s_routing(struct v4l2_subdev *sd,
int err;
enum tvp514x_input input_sel;
enum tvp514x_output output_sel;
-   u8 sync_lock_status, lock_mask;
-   int try_count = LOCK_RETRY_COUNT;
 
if ((input >= INPUT_INVALID) ||
(output >= OUTPUT_INVALID))
/* Index out of bound */
return -EINVAL;
 
-   /*
-* For the sequence streamon -> streamoff and again s_input
-* it fails to lock the signal, since streamoff puts TVP514x
-* into power off state which leads to failure in sub-sequent s_input.
-*
-* So power up the TVP514x device here, since it is important to lock
-* the signal at this stage.
-*/
-   if (!decoder->streaming)
-   tvp514x_s_stream(sd, 1);
-
input_sel = input;
output_sel = output;
 
@@ -660,64 +653,6 @@ static int tvp514x_s_routing(struct v4l2_subdev *sd,
 
decoder->tvp514x_regs[REG_INPUT_SEL].val = input_sel;
decoder->tvp514x_regs[REG_OUTPUT_FORMATTER1].val = output_sel;
-
-   /* Clear status */
-   msleep(LOCK_RETRY_DELAY);
-   err =
-   tvp514x_write_reg(sd, REG_CLEAR_LOST_LOCK, 0x01);
-   if (err)
-   return err;
-
-   switch (input_sel) {
-   case INPUT_CVBS_VI1A:
-   case INPUT_CVBS_VI1B:
-   case INPUT_CVBS_VI1C:
-   case INPUT_CVBS_VI2A:
-   case INPUT_CVBS_VI2B:
-   case INPUT_CVBS_VI2C:
-   case INPUT_CVBS_VI3A:
-   case INPUT_CVBS_VI3B:
-   case INPUT_CVBS_VI3C:
-   case INPUT_CVBS_VI4A:
-   lock_mask = STATUS_CLR_SUBCAR_LOCK_BIT |
-   STATUS_HORZ_SYNC_LOCK_BIT |
-   STATUS_VIRT_SYNC_LOCK_BIT;
-   break;
-
-   case INPUT_SVIDEO_VI2A_VI1A:
-   case INPUT_SVIDEO_VI2B_VI1B:
-   case INPUT_SVIDEO_VI2C_VI1C:
-   case INPUT_SVIDEO_VI2A_VI3A:
-   case INPUT_SVIDEO_VI2B_VI3B:
-   case INPUT_SVIDEO_VI2C_VI3C:
-   case INPUT_SVIDEO_VI4A_VI1A:
-   case INPUT_SVIDEO_VI4A_VI1B:
-   case INPUT_SVIDEO_VI4A_VI1C:
-   case INPUT_SVIDEO_VI4A_VI3A:
-   case INPUT_SVIDEO_VI4A_VI3B:
-   case INPUT_SVIDEO_VI4A_VI3C:
-   lock_mask = STATUS_HORZ_SYNC_LOCK_BIT |
-   STATUS_VIRT_SYNC_LOCK_BIT;
-   break;
-   /* Need to add other interfaces*/
-   default:
-   return -EINVAL;
-   }
-
-   while (try_count-- > 0) {
-   /* Allow decoder to sync up with new input */
-   msleep(LOCK_RETRY_DELAY);
-
-   sync_lock_status = tvp514x_read_reg(sd,
-   REG_STATUS1);
-   if (lock_mask == (sync_lock_status & lock_mask))
-   /* Input detected */
-   break;
-   }
-
-   if (try_count < 0)
-   return -EINVAL;
-
decoder->input = input;
decoder->output = output;
 
-- 
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

[RFCv2 PATCH 07/14] vpif_capture: first init subdevs, then register device nodes.

From: Hans Verkuil 

When device nodes are registered they must be ready for use
immediately, so make sure the subdevs are loaded first.

Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/davinci/vpif_capture.c |   47 +++--
 1 file changed, 20 insertions(+), 27 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index e40eacd1..98423b5 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -2139,24 +2139,6 @@ static __init int vpif_probe(struct platform_device 
*pdev)
}
}
 
-   for (j = 0; j < VPIF_CAPTURE_MAX_DEVICES; j++) {
-   ch = vpif_obj.dev[j];
-   ch->channel_id = j;
-   common = &(ch->common[VPIF_VIDEO_INDEX]);
-   spin_lock_init(&common->irqlock);
-   mutex_init(&common->lock);
-   ch->video_dev->lock = &common->lock;
-   /* Initialize prio member of channel object */
-   v4l2_prio_init(&ch->prio);
-   err = video_register_device(ch->video_dev,
-   VFL_TYPE_GRABBER, (j ? 1 : 0));
-   if (err)
-   goto probe_out;
-
-   video_set_drvdata(ch->video_dev, ch);
-
-   }
-
i2c_adap = i2c_get_adapter(1);
config = pdev->dev.platform_data;
 
@@ -2166,7 +2148,7 @@ static __init int vpif_probe(struct platform_device *pdev)
if (vpif_obj.sd == NULL) {
vpif_err("unable to allocate memory for subdevice pointers\n");
err = -ENOMEM;
-   goto probe_out;
+   goto vpif_dev_alloc_err;
}
 
for (i = 0; i < subdev_count; i++) {
@@ -2183,19 +2165,27 @@ static __init int vpif_probe(struct platform_device 
*pdev)
}
v4l2_info(&vpif_obj.v4l2_dev, "registered sub device %s\n",
  subdevdata->name);
-
-   if (vpif_obj.sd[i])
-   vpif_obj.sd[i]->grp_id = 1 << i;
}
 
+   for (j = 0; j < VPIF_CAPTURE_MAX_DEVICES; j++) {
+   ch = vpif_obj.dev[j];
+   ch->channel_id = j;
+   common = &(ch->common[VPIF_VIDEO_INDEX]);
+   spin_lock_init(&common->irqlock);
+   mutex_init(&common->lock);
+   ch->video_dev->lock = &common->lock;
+   /* Initialize prio member of channel object */
+   v4l2_prio_init(&ch->prio);
+   video_set_drvdata(ch->video_dev, ch);
+
+   err = video_register_device(ch->video_dev,
+   VFL_TYPE_GRABBER, (j ? 1 : 0));
+   if (err)
+   goto probe_out;
+   }
v4l2_info(&vpif_obj.v4l2_dev, "VPIF capture driver initialized\n");
return 0;
 
-probe_subdev_out:
-   /* free sub devices memory */
-   kfree(vpif_obj.sd);
-
-   j = VPIF_CAPTURE_MAX_DEVICES;
 probe_out:
for (k = 0; k < j; k++) {
/* Get the pointer to the channel object */
@@ -2203,6 +2193,9 @@ probe_out:
/* Unregister video device */
video_unregister_device(ch->video_dev);
}
+probe_subdev_out:
+   /* free sub devices memory */
+   kfree(vpif_obj.sd);
 
 vpif_dev_alloc_err:
k = VPIF_CAPTURE_MAX_DEVICES-1;
-- 
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

[RFCv2 PATCH 00/14] davinci: clean up input/output/subdev config

Hi Prabhakar,

This is the second patch series for a vpif driver cleanup.

The first version can be found here:

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

Changes since RFCv1:

- rebased to a newer git repo:

http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git/shortlog/refs/heads/da850_vpif_machine

- fixed probe() cleanup code in both display and capture that was seriously
broken.

- fixed a broken s_routing implementation in the tvp514x driver: if there
is no incoming video signal, then s_routing would return EINVAL and
leave the driver with an inconsistent internal state. This has always
been a problem, but with this patch series it suddenly became really
noticable. s_routing shouldn't try to wait for a valid signal, that's
not what s_routing should do.

This patch series does some driver cleanup and reorganizes the config
structs that are used to set up subdevices.

The current driver associates an input or output with a subdev, but multiple
inputs may use the same subdev and some inputs may not use a subdev at all
(this is the case for our hardware).

Several other things were also configured in the wrong structure. For
example the vpif_interface struct is really part of the channel config
and has nothing to do with the subdev.

What is missing here is that the output doesn't have the same flexibility
as the input when it comes to configuration. It would be good if someone
can pick this up as a follow-up since it's unlikely I'll be working on
that.

What would also be nice is that by leaving the inputs or outputs for the
second channel empty (NULL) in the configuration you can disable the second
video node, e.g. trying to use it will always result in ENODEV or something.

This patch series will at least make things more flexible.

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 4/4] gspca_pac7302: add support for green balance adjustment

2012-09-20 Thread Frank Schäfer

Hi,

Am 20.09.2012 11:08, schrieb Hans de Goede:
> Hi,
>
 Hans, it seems like you didn't pick up these patches up yet...
 Is there anything wrong with them ?
>>>
>>> I've somehow completely missed them. Can you resend the entire set
>>> please?
>>
>> No problem, but I can't do that before weekend (I'm currently not at
>> home).
>> I've sent these 4 patches on last Sunday (16. Sept) evening.
>> Maybe you can pick them up from patchwork ?
>> http://patchwork.linuxtv.org/patch/14433/
>
> Ah yes, patchwork, that will work. Unfortunately that only solves the
> me having missed the patches problem.
>
> First of all thanks for working on this! I'm afraid you've managed to
> find
> one of the weak spots in the v4l2 API, namely how we deal with RGB gains.

It seems like this is one of my talents... :(

>
> Many webcams have RGB gains, but we don't have standard CID-s for these,
> instead we've Blue and Red Balance. This has grown historically
> because of
> the bttv cards which actually have Blue and Red balance controls in
> hardware,
> rather then the usual RGB gain triplet. Various gspca drivers cope
> with this
> in different ways.
>
> If you look at the pac7302 driver before your latest 4 patches it has
> a Red and Blue balance control controlling the Red and Blue gain, and a
> Whitebalance control, which is not White balance at all, but simply
> controls the green gain...

Ok, so if I understand you right, red+green+blue balance = white balance.
And because we already have defined red, blue and whitebalance controls
for historical reasons, we don't need green balance ?
Maybe that matches physics, but I don't think it's a sane approach for a
user interface...


>
> And as said other drivers have similar (albeit usually different) hacks.
>
> At a minimum I would like you to rework your patches to:
> 1) Not add the new Green balance, and instead modify the existing
> whitebalance
> to control the new green gain you've found. Keeping things as broken as
> they are, but not worse; and

I prefer waiting for the results of the discussion you are proposing
further down.

> 2) Try to use both the page 0 reg 0x01 - 0x03 and page 0 reg 0xc5 - 0xc7
> at the same time to get a wider ranged control. Maybe 0xc5 - 0xc7 are
> simply the most significant bits of a wider ranged gain ?

I don't think so. The windows driver does not use them.
It even doesn't use the full range of registers 0x01-0x03.
Of course, I have expermiented with the full range and it works, but it
doesn't make much sense to use it.

Experimenting with the device to determine the meaing of unknown
registerts, you will notice, that there are several registert which
affect RGB.
But that doesn't mean that they are suitable for a user control...

> Note that if you cannot control them both from a single control in such
> a way that you get a smooth control range, then lets just fix
> 0xc5 - 0xc7 at a value of 2 for all 3 and be done with it, but at least
> we should try :)

There is no need to fix registers 0xc5 and 0xc7.
The Windows driver sets them to 1, which is exactly the value we are
currently using as default value with the blue and red value controls.

>
> As said the above is the minimum, what I would really like is a
> discussion
> on linux-media about adding proper RGB gain controls for all the cameras
> which have these.
>
> Note this brings with itself the question should we export such lowlevel
> controls at all ? In some drivers the per color gains are simply all
> kept at the same level and controlled as part of the master gain control,
> giving it a wider and/or more fine grained range, leading to better
> autogain
> behavior. Given how our sw autowhitebalance works (and that that works
> reasonable well), their is not much added value in exporting them
> separately,
> while they do tend to improve the standard gain control when used as part
> of it ...

I would say, let the drivers decide how to do things. It also depends on
the hardware design.

Regards,
Frank

>
> So what we really need is a plan how to deal with these controls, and
> then
> send an RFC for this to the list.
>
> 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 00/34] i.MX multi-platform support

On Thu, Sep 20, 2012 at 07:41:50AM -0400, Mark Brown wrote:
> It's usually pretty early but Takashi will be on holiday this time so
> I'm not sure if things might be different (he was going to send the pull
> request from holiday).  I also didn't guarantee that it'll be stable
> yet, can someone please tell me what the depenency is here?

We need the patch to have all imx drivers mach/* inclusion free,
so that we can enable multi-platform support for imx, which is the
whole point of the series.

If your for-3.7 is not stable anyway, I guess the easiest the way
to do it might be you drop the patch "ASoC: mx27vis: retrieve gpio
numbers from platform_data" from your tree and I have it be part of
the series to go via arm-soc tree as a whole.  (This is the original
plan that I mentioned in v1 cover letter)

Shawn
--
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 00/34] i.MX multi-platform support

2012-09-20 Thread Mark Brown

On Thu, Sep 20, 2012 at 07:39:34AM +, Arnd Bergmann wrote:

> The first five branches are scheduled to go through the arm-soc tree, so
> I'm fine with that. For the sound/for-3.7 branch, I'd like to know when
> to expect that hitting mainline. If it always gets in very early during the
> merge window, it's probably ok to put the imx/multi-platform patches into
> the same branch as the other ones in arm-soc and wait for the sound stuff
> to hit mainline first, otherwise I'd suggest we start a second
> next/multiplatform-2 branch for imx and send the first part early on
> but then wait with the second batch before sound gets in.

It's usually pretty early but Takashi will be on holiday this time so
I'm not sure if things might be different (he was going to send the pull
request from holiday).  I also didn't guarantee that it'll be stable
yet, can someone please tell me what the depenency is here?
--
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: [PATCHv3 2/9] ir-rx51: Handle signals properly

2012-09-20 Thread David Härdeman

On Tue, 4 Sep 2012 13:43:56 +0100, Sean Young  wrote:
> This interface is much better but it's also an ABI change. How should
this
> be handled? Should rc-core expose it's own /dev/rc[0-9] device with its
> own ioctls?

That was the plan yes. I've posted a patchbomb in the past to the
linux-media mailing list which implements a rc specific chardev with an
ioctl/read/write based API.

Since the entire patchset is a bit much to digest and merging of patches
has been slow lately, I'm trying to drip-feed the patches. The lirc TX
rework was part of that process. It basically lays the groundwork for later
patches.

//David

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

Re: [PATCH] media: sh-vou: fix compilation breakage

On Thu 20 September 2012 08:58:48 Guennadi Liakhovetski wrote:
> A recent commit
> 
> commit f135a8a224294fa0f60ec1b8bc120813b7cfc804
> Author: Hans Verkuil 
> Date:   Sun Jun 24 06:33:26 2012 -0300
> 
> [media] sh_vou: remove V4L2_FL_LOCK_ALL_FOPS
> 
> broke compilation of sh_vou.c:
> 
> drivers/media/platform/sh_vou.c: In function 'sh_vou_mmap':
> drivers/media/platform/sh_vou.c:1227: error: 'vdev' undeclared (first use in 
> this function)
> drivers/media/platform/sh_vou.c:1227: error: (Each undeclared identifier is 
> reported only once
> drivers/media/platform/sh_vou.c:1227: error: for each function it appears in.)
> drivers/media/platform/sh_vou.c: In function 'sh_vou_poll':
> drivers/media/platform/sh_vou.c:1242: error: 'vdev' undeclared (first use in 
> this function)
> make[2]: *** [drivers/media/platform/sh_vou.o] Error 1
> 
> Add missing variable definitions.
> 
> Signed-off-by: Guennadi Liakhovetski 

Acked-by: Hans Verkuil 

I've added the sh arch to the daily build as well. So the next time the daily
build should catch such errors.

Regards,

Hans

> ---
> 
> This is a fix for 3.7
> 
>  drivers/media/platform/sh_vou.c |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/media/platform/sh_vou.c b/drivers/media/platform/sh_vou.c
> index 9f62fd8..7f8b792 100644
> --- a/drivers/media/platform/sh_vou.c
> +++ b/drivers/media/platform/sh_vou.c
> @@ -1224,6 +1224,7 @@ static int sh_vou_release(struct file *file)
>  
>  static int sh_vou_mmap(struct file *file, struct vm_area_struct *vma)
>  {
> + struct video_device *vdev = video_devdata(file);
>   struct sh_vou_device *vou_dev = video_get_drvdata(vdev);
>   struct sh_vou_file *vou_file = file->private_data;
>   int ret;
> @@ -1239,6 +1240,7 @@ static int sh_vou_mmap(struct file *file, struct 
> vm_area_struct *vma)
>  
>  static unsigned int sh_vou_poll(struct file *file, poll_table *wait)
>  {
> + struct video_device *vdev = video_devdata(file);
>   struct sh_vou_device *vou_dev = video_get_drvdata(vdev);
>   struct sh_vou_file *vou_file = file->private_data;
>   unsigned int res;
> 
--
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] gspca_pac7302: add support for green balance adjustment

2012-09-20 Thread Hans de Goede


Hi,

On 09/19/2012 10:54 PM, Frank Schäfer wrote:

Am 19.09.2012 22:34, schrieb Hans de Goede:





Hans, it seems like you didn't pick up these patches up yet...
Is there anything wrong with them ?


I've somehow completely missed them. Can you resend the entire set
please?


No problem, but I can't do that before weekend (I'm currently not at home).
I've sent these 4 patches on last Sunday (16. Sept) evening.
Maybe you can pick them up from patchwork ?
http://patchwork.linuxtv.org/patch/14433/


Ah yes, patchwork, that will work. Unfortunately that only solves the
me having missed the patches problem.

First of all thanks for working on this! I'm afraid you've managed to find
one of the weak spots in the v4l2 API, namely how we deal with RGB gains.

Many webcams have RGB gains, but we don't have standard CID-s for these,
instead we've Blue and Red Balance. This has grown historically because of
the bttv cards which actually have Blue and Red balance controls in hardware,
rather then the usual RGB gain triplet. Various gspca drivers cope with this
in different ways.

If you look at the pac7302 driver before your latest 4 patches it has
a Red and Blue balance control controlling the Red and Blue gain, and a
Whitebalance control, which is not White balance at all, but simply
controls the green gain...

And as said other drivers have similar (albeit usually different) hacks.

At a minimum I would like you to rework your patches to:
1) Not add the new Green balance, and instead modify the existing whitebalance
to control the new green gain you've found. Keeping things as broken as
they are, but not worse; and
2) Try to use both the page 0 reg 0x01 - 0x03 and page 0 reg 0xc5 - 0xc7
at the same time to get a wider ranged control. Maybe 0xc5 - 0xc7 are
simply the most significant bits of a wider ranged gain ?
Note that if you cannot control them both from a single control in such
a way that you get a smooth control range, then lets just fix
0xc5 - 0xc7 at a value of 2 for all 3 and be done with it, but at least
we should try :)

As said the above is the minimum, what I would really like is a discussion
on linux-media about adding proper RGB gain controls for all the cameras
which have these.

Note this brings with itself the question should we export such lowlevel
controls at all ? In some drivers the per color gains are simply all
kept at the same level and controlled as part of the master gain control,
giving it a wider and/or more fine grained range, leading to better autogain
behavior. Given how our sw autowhitebalance works (and that that works
reasonable well), their is not much added value in exporting them separately,
while they do tend to improve the standard gain control when used as part
of it ...

So what we really need is a plan how to deal with these controls, and then
send an RFC for this to the list.

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: [GIT PULL v2] Initial i.MX5/CODA7 support for the CODA driver

2012-09-20 Thread Sylwester Nawrocki

On 09/20/2012 10:03 AM, Richard Zhao wrote:
> On Thu, Sep 20, 2012 at 09:10:46AM +0200, javier Martin wrote:
>> Hi Richard,
>>
>> On 20 September 2012 05:32, Richard Zhao  wrote:
>>> why is it a request-pull?
>>
>> After 5 version of Philipp's patches we have agreed they are good
>> enough to be merged; they don't break anything related to the old
>> codadx6 while provide support for the new coda7:
>> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/53627
>>
>> The pull request is a way to tell Mauro this is ready to be merged in
>> his linux-media tree and making things easier for him.
> I know the meaning. I just feel strange. Pull request is normally sent
> by maintainer to up level maintainer who agreed to receive pull request.

There is really high volume of various kind of patches on linux-media
mailing lists. Even with those pull requests it becomes hard for Mauro
to respond and merge patches in timely manner. There is even a discussion 
related to this scheduled for media workshop during ELCE/LinuxCon. I think 
the rules may differ slightly across kernel subsystems, hence I find nothing 
unusual in using pull requests, especially by sub-subsystem maintainers or
developers.

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

Re: [GIT PULL v2] Initial i.MX5/CODA7 support for the CODA driver

2012-09-20 Thread javier Martin

On 20 September 2012 10:03, Richard Zhao  wrote:
> On Thu, Sep 20, 2012 at 09:10:46AM +0200, javier Martin wrote:
>> Hi Richard,
>>
>> On 20 September 2012 05:32, Richard Zhao  wrote:
>> > why is it a request-pull?
>>
>> After 5 version of Philipp's patches we have agreed they are good
>> enough to be merged; they don't break anything related to the old
>> codadx6 while provide support for the new coda7:
>> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/53627
>>
>> The pull request is a way to tell Mauro this is ready to be merged in
>> his linux-media tree and making things easier for him.
> I know the meaning. I just feel strange. Pull request is normally sent
> by maintainer to up level maintainer who agreed to receive pull request.

This was discussed some time ago here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/078862.html

Regards.
-- 
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL v2] Initial i.MX5/CODA7 support for the CODA driver

2012-09-20 Thread Richard Zhao

On Thu, Sep 20, 2012 at 09:10:46AM +0200, javier Martin wrote:
> Hi Richard,
> 
> On 20 September 2012 05:32, Richard Zhao  wrote:
> > why is it a request-pull?
> 
> After 5 version of Philipp's patches we have agreed they are good
> enough to be merged; they don't break anything related to the old
> codadx6 while provide support for the new coda7:
> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/53627
> 
> The pull request is a way to tell Mauro this is ready to be merged in
> his linux-media tree and making things easier for him.
I know the meaning. I just feel strange. Pull request is normally sent
by maintainer to up level maintainer who agreed to receive pull request.

Thanks
Richard
> 
> Regards.
> -- 
> Javier Martin
> Vista Silicon S.L.
> CDTUC - FASE C - Oficina S-345
> Avda de los Castros s/n
> 39005- Santander. Cantabria. Spain
> +34 942 25 32 60
> www.vista-silicon.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

Fwd: [PATCH] [1/5] dvb-apps - update scan file DVB-S 5E

I do not know why mailing list filter caches my first mails. But here they are 
without the explanations
--- util/scan/dvb-s/Sirius-5.0E.old	2012-09-20 08:18:48.548053688 +0200
+++ util/scan/dvb-s/Sirius-5.0E	2012-09-20 08:27:49.279133255 +0200
@@ -1,9 +1,6 @@
 # Sirius 5.0E
 # freq pol sr fec
-S 11215000 V 000 1/2
-S 11227000 H 23145000 3/4
-S 11247000 V 23145000 3/4
-S 1142 H 23145000 3/4
+S2 11264000 V 3000 3/4 AUTO 8PSK
 S 11727000 H 2750 5/6
 S 11747000 V 2750 3/4
 S 11766000 H 2750 3/4
@@ -27,36 +24,29 @@
 S 12111000 H 2750 5/6
 S 1213 V 2750 3/4
 S 12149000 H 2750 3/4
-S 12169000 V 2750 3/4
-S 12188000 H 2750 7/8
-S 12207000 V 2750 3/4
+S2 12169000 V 2750 3/4 AUTO 8PSK
+S2 12188000 H 2750 3/4 AUTO 8PSK
+S2 12207000 V 3000 3/4 AUTO 8PSK
 S 12226000 H 2554 7/8
 S 12245000 V 2750 3/4
 S 12265000 H 2750 3/4
 S 12284000 V 2750 3/4
 S 12303000 H 25547000 7/8
-S 12322000 V 2750 3/4
-S 12341000 H 2750 3/4
-S 1236 V 2750 7/8
+S 12322000 V 2750 7/8
+S2 12341000 H 2750 3/4 AUTO 8PSK
+S 1236 V 2750 3/4
 S 12379000 H 2750 3/4
-S 12399000 V 2750 2/3
+S2 12399000 V 2750 3/4 AUTO 8PSK
 S 12418000 H 2750 3/4
-S 12437000 V 2750 2/3
-S 12456000 H 2750 3/4
+S2 12437000 V 2750 3/4 AUTO 8PSK
+S2 12456000 H 2750 3/4 AUTO 8PSK
 S 12476000 V 2750 3/4
 S 12608000 H 2750 3/4
 S 12637000 H 14465000 3/4
-S 12668000 V 000 1/2
 S 12672000 H 330 3/4
-S 12674000 V 1000 3/4
-S 12678000 V 1000 5/6
-S 1268 H 9404000 3/4
-S 12685000 V 000 3/4
-S 1269 H 333 3/4
+S2 12682000 V 000 2/3 AUTO 8PSK
+S 12687000 V 6667000 5/6
 S 12693000 V 000 5/6
-S 12701000 H 6111000 3/4
-S 12715000 H 333 3/4
-S 12718000 V 2350 3/4
-S 12724000 H 1772000 3/4
-S 12728000 V 1972 3/4
-S 12737000 V 615 3/4
+S 12703000 V 2963000 3/4
+S 12718000 V 296 7/8
+S2 12728000 V 148 9/10 AUTO 8PSK

[PATCH] [5/5] dvb-apps - update scan file DVB-S 28.5E

Eutelsat--- /dev/null	2012-09-20 10:05:33.314437212 +0200
+++ util/scan/dvb-s/Eutelsat28A-28.5E	2012-09-20 09:23:16.483702298 +0200
@@ -0,0 +1,32 @@
+# Eutelsat 28.5E
+# freq pol sr fec
+S 11222000 H 2750 2/3
+S 11224000 V 2750 2/3
+S 11259000 V 2750 2/3
+S 11261000 H 2750 2/3
+S 11307000 H 2750 2/3
+S 11307000 V 2750 2/3
+S 11343000 V 2750 2/3
+S 11344000 H 2750 2/3
+S 11389000 H 2750 2/3
+S 1139 V 2750 2/3
+S 11426000 H 2750 2/3
+S 11426000 V 2750 2/3
+S 11469000 H 2750 2/3
+S 11488000 V 2750 2/3
+S 11508000 H 2750 2/3
+S 11527000 V 2750 2/3
+S 11546000 H 2750 2/3
+S 11565000 V 2750 2/3
+S 11585000 H 2750 2/3
+S 11604000 V 2750 2/3
+S 11623000 H 2750 2/3
+S 11661500 H 2750 2/3
+S 11681000 V 2750 2/3
+S 12524000 V 2750 2/3
+S 1256 H 2750 2/3
+S 1256 V 2750 2/3
+S 12607000 V 2750 2/3
+S 12607000 H 2750 2/3
+S 12643000 H 2750 2/3
+S 12643000 V 2750 2/3

[PATCH] [4/5] dvb-apps - update scan file DVB-S 28.5E

Eurobird--- util/scan/dvb-s/Eurobird1-28.5E	2012-09-19 11:52:55.0 +0200
+++ /dev/null	2012-09-20 10:05:33.314437212 +0200
@@ -1,5 +0,0 @@
-# Eurobird 28.5E SDT info service transponder
-# freq pol sr fec
-S 11623000 H 2750 2/3
-S 11224000 V 2750 2/3
-S 11527000 V 2750 2/3

[PATCH] [3/5] dvb-apps - update scan file DVB-S 9E

Eutelsat 9E--- util/scan/dvb-s/Eutelsat9-9.0E.old	2012-09-20 08:47:47.246366647 +0200
+++ util/scan/dvb-s/Eutelsat9-9.0E	2012-09-20 08:57:30.217456457 +0200
@@ -1,16 +1,33 @@
 # Eurobird 9.0E
 # freq pol sr fec
-S 11727000 V 2750 5/6
+S 11727000 V 2750 3/4
 S 11747000 H 2750 3/4
-S 11766000 V 2750 5/6
-S 11785000 H 2750 3/4
-S 11804000 V 2750 3/4
+S 11766000 V 2750 3/4
+S2 11785000 H 2750 2/3 AUTO 8PSK
 S 11823000 H 2750 3/4
 S 11843000 V 2750 3/4
-S 11881000 V 2670 3/4
-S 11919000 V 2750 5/6
+S2 11862000 H 2750 2/3 AUTO 8PSK
+S2 11881000 V 2750 2/3 AUTO 8PSK
+S2 1190 H 2750 2/3 AUTO 8PSK
+S 11919000 V 2750 3/4
 S 11938000 H 2750 3/4
+S2 11958000 V 2750 2/3 AUTO 8PSK
 S 11977000 H 2750 3/4
 S 11996000 V 2750 3/4
-S 12054000 H 2750 3/4
-S 12092000 H 2750 3/4
+S2 12015000 H 2750 2/3 AUTO 8PSK
+S2 12034000 V 2750 3/4 AUTO 8PSK
+S2 12054000 H 2750 2/3 AUTO 8PSK
+S2 12073000 V 2750 3/4 AUTO 8PSK
+S2 12111000 V 2750 3/5 AUTO 8PSK
+S 1213 H 2750 3/4
+S2 12149000 V 2750 2/3 AUTO 8PSK
+S2 12226000 V 2750 2/3 AUTO 8PSK
+S2 12245000 H 2750 3/4 AUTO 8PSK
+S2 12265000 V 2750 2/3 AUTO 8PSK
+S2 12284000 H 2750 2/3 AUTO 8PSK
+S 12322000 H 2750 3/4
+S 12341000 V 2750 3/4
+S2 1236 H 2750 2/3 AUTO 8PSK
+S2 12399000 H 2750 2/3 AUTO 8PSK
+S 12418000 V 2750 3/4
+S2 12437000 H 2750 2/3 AUTO 8PSK

[PATCH] [2/5] dvb-apps - update scan file DVB-S 7E

Eutelsat 7E. As I see not available at all in the directory--- /dev/null	2012-09-20 10:05:33.314437212 +0200
+++ util/scan/dvb-s/Eutelsat7A-7.0E	2012-09-20 08:45:37.163331706 +0200
@@ -0,0 +1,28 @@
+# Eutelsat7A-7.0E
+# freq pol sr fec
+S 10721000 H 2200 3/4
+S 10721000 V 2750 3/4
+S 10762000 V 3000 3/4
+S 10804000 H 2990 3/4
+S2 10845000 H 3000 5/6 AUTO QPSK
+S 10845000 V 3000 3/4
+S2 10886000 H 3000 5/6 AUTO QPSK
+S2 10886000 V 3000 5/6 AUTO QPSK
+S 10928000 H 3000 3/4
+S2 10928000 V 3000 5/6 AUTO QPSK
+S 11186000 V 2893000 5/6
+S 11189000 V 2018000 5/6
+S 11221000 H 2750 3/4
+S 11445500 V 2005 3/4
+S 11471000 H 3000 3/4
+S 11492000 V 3000 3/4
+S 11513000 H 2990 3/4
+S 11534000 V 3000 3/4
+S 11554000 H 3000 3/4
+S 11575000 V 3000 3/4
+S 11596000 H 3000 3/4
+S 11617000 V 3000 3/4
+S 11637000 H 3000 3/4
+S 11678000 H 3000 3/4
+S2 1252 H 6144000 3/4 AUTO 8PSK
+S2 12531000 V 1852000 2/3 AUTO 8PSK

[PATCH] [1/5] dvb-apps - update scan file DVB-S 5E