date:20161208

Re: [PATCH v4l-utils v7 4/7] mediactl: Add media_device creation helpers

2016-12-08 Thread Jacek Anaszewski

Hhi Sakari,

On 12/09/2016 12:05 AM, Sakari Ailus wrote:

Hi Jacek,

On Thu, Dec 08, 2016 at 11:04:20PM +0100, Jacek Anaszewski wrote:

Hi Sakari,

On 11/24/2016 01:17 PM, Sakari Ailus wrote:

Hi Jacek,

Thanks for the patchset.

On Wed, Oct 12, 2016 at 04:35:19PM +0200, Jacek Anaszewski wrote:

Add helper functions that allow for easy instantiation of media_device
object basing on whether the media device contains v4l2 subdev with
given file descriptor.

Doesn't this work with video nodes as well? That's what you seem to be using
it for later on. And I think that's actually more useful.

The existing implementation uses udev to look up devices. Could you use
libudev device enumeration API to find the media devices, and fall back to
sysfs if udev doesn't work? There seems to be a reasonable-looking example
here:

http://stackoverflow.com/questions/25361042/how-to-list-usb-mass-storage-devices-programatically-using-libudev-in-linux>

Actually I am calling media_get_devname_udev() at first and falling back
to sysfs similarly as it is accomplished in media_enum_entities().
Is there any specific reason for which I should use libudev device
enumeration API in media_device_new_by_subdev_fd()?

Yes. You rely on the API udev provides; the sysfs implementation is just a
fallback in case udev isn't available in the system. I guess it'd mostly
work but, for instance, you assume sysfs is found under /sys. The sysfs
itself isn't one of the most stable APIs either. Udev is a simply better
option when it's there.

Thanks for clarifying that. I'll check the libudev device enumeration
API then.

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

Re: uvcvideo logging kernel warnings on device disconnect

2016-12-08 Thread Greg KH

On Fri, Dec 09, 2016 at 01:09:21AM +0200, Laurent Pinchart wrote:
> Hi Dave,
> 
> (CC'ing LKML and Greg KH)
> 
> On Thursday 08 Dec 2016 12:31:55 Dave Stevenson wrote:
> > Hi All.
> > 
> > I'm working with a USB webcam which has been seen to spontaneously
> > disconnect when in use. That's a separate issue, but when it does it
> > throws a load of warnings into the kernel log if there is a file handle
> > on the device open at the time, even if not streaming.
> > 
> > I've reproduced this with a generic Logitech C270 webcam on:
> > - Ubuntu 16.04 (kernel 4.4.0-51) vanilla, and with the latest media tree
> > from linuxtv.org
> > - Ubuntu 14.04 (kernel 4.4.0-42) vanilla
> > - an old 3.10.x tree on an embedded device.
> > 
> > To reproduce:
> > - connect USB webcam.
> > - run a simple app that opens /dev/videoX, sleeps for a while, and then
> > closes the handle.
> > - disconnect the webcam whilst the app is running.
> > - read kernel logs - observe warnings. We get the disconnect logged as
> > it occurs, but the warnings all occur when the file descriptor is
> > closed. (A copy of the logs from my Ubuntu 14.04 machine are below).
> > 
> > I can fully appreciate that the open file descriptor is holding
> > references to a now invalid device, but is there a way to avoid them? Or
> > do we really not care and have to put up with the log noise when doing
> > such silly things?
> 
> This is a known problem, caused by the driver core trying to remove the same 
> sysfs attributes group twice.

Ick, not good.

> The group is first removed when the USB device is disconnected. The input 
> device and media device created by the uvcvideo driver are children of the 
> USB 
> interface device, which is deleted from the system when the camera is 
> unplugged. Due to the parent-child relationship, all sysfs attribute groups 
> of 
> the children are removed.

Wait, why is the USB device being removed from sysfs at this point,
didn't the input and media subsystems grab a reference to it so that it
does not disappear just yet?

> Then, when the device node is closed, the media device and input device are 
> unregistered, causing the corresponding devices to be deleted too. The driver 
> core tries to remove the sysfs attributes groups related to those devices, 
> and 
> issues a warning as they have been removed already.
> 
> I'm not sure how to fix that, any hint from LKML would be appreciated.

Properly grab a reference to the USB device?  :)

If that's already happening, please let me know and I'll see what needs
to be done, but I think that should solve the issue for you.

thanks,

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

cron job: media_tree daily build: ERRORS

2016-12-08 Thread Hans Verkuil

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Fri Dec  9 05:00:17 CET 2016
media-tree git hash:365fe4e0ce218dc5ad10df17b150a366b6015499
media_build git hash:   1606032398b1d79149c1507be2029e1a00d8dff0
v4l-utils git hash: 188e604d57bec065078ff772c802b93ddb6def4b
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.8.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.67-i686: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-rc5-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: OK
linux-3.12.67-x86_64: OK
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: OK
linux-4.9-rc5-x86_64: OK
apps: WARNINGS
spec-git: OK
smatch: ERRORS
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.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 2/2] uvcvideo: Document Intel SR300 Depth camera INZI format

2016-12-08 Thread Daniel Johnson

> In addition to my previous comments, wouldn't it make more sense to create a
> multiplanar format for this instead of bundling the two separate images into a
> single plane ?

Unfortunately that would break userspace at this point as multiple
libraries are already depending on a patch that implements the INZI
format in this way. I first released a work in progress patch in March
of 2015. It was integrated into a Robot Operating System module
shortly after that, and Intel has included it in librealsense since
January, and also in the firmware for their new Joule module. Since
people using this have mostly had to patch their own kernel to use it
that might not be a deal breaker. I had initially held back on
upstreaming it because I was trying to work out some details of the
image formats. Two depth formats seemed the same, and I was trying to
figure out what was different enough about them to justify having two
formats. I've never had access to any intel documentation beyond what
is public on their website, and many details are missing.

For reference I got an early RealSense camera when only windows was
supported, and figured out some rudimentary support for Linux over a
year before intel released their own support. A manager hiring for
Intel's open source library told me over the phone that they were in
fact using my blog posts to help them develop it so it wasn't
surprising that the patch they distributed with the library included
my comments. It was surprising that they didn't mention me as the
author of the patch.

I could rebase my original patch on the current development kernel and
submit it if that helps. I can reformat the useful bits from my blog
posts as documentation on how 3d cameras work. I wrote a C hotplug
utility to let the kernel know about non standard camera controls. I
also have a partially finished kernel driver for the SR300, and F200
cameras for things like retrieving the calibration to turn depth
images into point clouds, putting the camera into firmware update
mode, etc that intel's library does with libusb. I think there should
be a standard v4l2 api for 3d cameras because as it is now userspace
programs have to be written differently for each vendor. Really all
they need are some calibration matrices, and distortion coefficients.
Precise time synchronization between /dev/videoX nodes would also be
really helpful. These two things would be helpful for other cameras as
well for things like stitching 360 degree video.

Here are links to my blog series.
http://solsticlipse.com/2015/01/09/intel-real-sense-camera-on-linux.html
http://solsticlipse.com/2015/02/10/intel-real-sense-on-linux-part-2-3d-camera-controls.html
http://solsticlipse.com/2015/03/31/intel-real-sense-3d-on-linux-macos.html
http://solsticlipse.com/2016/09/26/long-road-to-ubiquitous-3d-cameras.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] dvb-usb-cxusb: Geniatech Mygica T230C support.

2016-12-08 Thread CrazyCat

Updated Geniatech DVB-T/T2 stick support.

Signed-off-by: CrazyCat 
---
 drivers/media/usb/dvb-usb/cxusb.c | 136 ++
 1 file changed, 136 insertions(+)

diff --git a/drivers/media/usb/dvb-usb/cxusb.c 
b/drivers/media/usb/dvb-usb/cxusb.c
index 3edc30d..4bf4c68 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -1439,6 +1439,82 @@ static int cxusb_mygica_t230_frontend_attach(struct 
dvb_usb_adapter *adap)
return 0;
 }
 
+static int cxusb_mygica_t230c_frontend_attach(struct dvb_usb_adapter *adap)
+{
+   struct dvb_usb_device *d = adap->dev;
+   struct cxusb_state *st = d->priv;
+   struct i2c_adapter *adapter;
+   struct i2c_client *client_demod;
+   struct i2c_client *client_tuner;
+   struct i2c_board_info info;
+   struct si2168_config si2168_config;
+   struct si2157_config si2157_config;
+
+   /* Select required USB configuration */
+   if (usb_set_interface(d->udev, 0, 0) < 0)
+   err("set interface failed");
+
+   /* Unblock all USB pipes */
+   usb_clear_halt(d->udev,
+   usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint));
+   usb_clear_halt(d->udev,
+   usb_rcvbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint));
+   usb_clear_halt(d->udev,
+   usb_rcvbulkpipe(d->udev, 
d->props.adapter[0].fe[0].stream.endpoint));
+
+   /* attach frontend */
+   memset(&si2168_config, 0, sizeof(si2168_config));
+   si2168_config.i2c_adapter = &adapter;
+   si2168_config.fe = &adap->fe_adap[0].fe;
+   si2168_config.ts_mode = SI2168_TS_PARALLEL;
+   si2168_config.ts_clock_inv = 1;
+   memset(&info, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2168", I2C_NAME_SIZE);
+   info.addr = 0x64;
+   info.platform_data = &si2168_config;
+   request_module(info.type);
+   client_demod = i2c_new_device(&d->i2c_adap, &info);
+   if (client_demod == NULL || client_demod->dev.driver == NULL)
+   return -ENODEV;
+
+   if (!try_module_get(client_demod->dev.driver->owner)) {
+   i2c_unregister_device(client_demod);
+   return -ENODEV;
+   }
+
+   /* attach tuner */
+   memset(&si2157_config, 0, sizeof(si2157_config));
+   si2157_config.fe = adap->fe_adap[0].fe;
+   memset(&info, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2141", I2C_NAME_SIZE);
+   info.addr = 0x60;
+   info.platform_data = &si2157_config;
+   request_module("si2157");
+   client_tuner = i2c_new_device(adapter, &info);
+   if (client_tuner == NULL || client_tuner->dev.driver == NULL) {
+   module_put(client_demod->dev.driver->owner);
+   i2c_unregister_device(client_demod);
+   return -ENODEV;
+   }
+   if (!try_module_get(client_tuner->dev.driver->owner)) {
+   i2c_unregister_device(client_tuner);
+   module_put(client_demod->dev.driver->owner);
+   i2c_unregister_device(client_demod);
+   return -ENODEV;
+   }
+
+   st->i2c_client_demod = client_demod;
+   st->i2c_client_tuner = client_tuner;
+
+   /* hook fe: need to resync the slave fifo when signal locks. */
+   mutex_init(&st->stream_mutex);
+   st->last_lock = 0;
+   st->fe_read_status = adap->fe_adap[0].fe->ops.read_status;
+   adap->fe_adap[0].fe->ops.read_status = cxusb_read_status;
+
+   return 0;
+}
+
 /*
  * DViCO has shipped two devices with the same USB ID, but only one of them
  * needs a firmware download.  Check the device class details to see if they
@@ -1521,6 +1597,7 @@ static int bluebird_patch_dvico_firmware_download(struct 
usb_device *udev,
 static struct dvb_usb_device_properties cxusb_d680_dmb_properties;
 static struct dvb_usb_device_properties cxusb_mygica_d689_properties;
 static struct dvb_usb_device_properties cxusb_mygica_t230_properties;
+static struct dvb_usb_device_properties cxusb_mygica_t230c_properties;
 
 static int cxusb_probe(struct usb_interface *intf,
   const struct usb_device_id *id)
@@ -1553,6 +1630,8 @@ static int cxusb_probe(struct usb_interface *intf,
 THIS_MODULE, NULL, adapter_nr) ||
0 == dvb_usb_device_init(intf, &cxusb_mygica_t230_properties,
 THIS_MODULE, NULL, adapter_nr) ||
+   0 == dvb_usb_device_init(intf, &cxusb_mygica_t230c_properties,
+THIS_MODULE, NULL, adapter_nr) ||
0)
return 0;
 
@@ -1604,6 +1683,7 @@ enum cxusb_table_index {
CONEXANT_D680_DMB,
MYGICA_D689,
MYGICA_T230,
+   MYGICA_T230C,
NR__cxusb_table_index
 };
 
@@ -1671,6 +1751,9 @@ enum cxusb_table_index {
[MYGICA_T230] = {
USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230)

[PATCH 1/4] dvb-usb-cxusb: New RC map for Geniatech Mygica T230.

2016-12-08 Thread CrazyCat

Updated RC map for Geniatech DVB-T/T2 sticks.

Signed-off-by: CrazyCat 
---
 drivers/media/usb/dvb-usb/cxusb.c | 42 +--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/cxusb.c 
b/drivers/media/usb/dvb-usb/cxusb.c
index 9b8771e..3edc30d 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -653,6 +653,44 @@ static int cxusb_d680_dmb_rc_query(struct dvb_usb_device 
*d, u32 *event,
{ 0x0025, KEY_POWER },
 };
 
+static struct rc_map_table rc_map_t230_table[] = {
+   { 0x, KEY_0 },
+   { 0x0001, KEY_1 },
+   { 0x0002, KEY_2 },
+   { 0x0003, KEY_3 },
+   { 0x0004, KEY_4 },
+   { 0x0005, KEY_5 },
+   { 0x0006, KEY_6 },
+   { 0x0007, KEY_7 },
+   { 0x0008, KEY_8 },
+   { 0x0009, KEY_9 },
+   { 0x000a, KEY_MUTE },
+   { 0x000b, KEY_STOP },   /* Stop */
+   { 0x000c, KEY_POWER2 }, /* Turn on/off application */
+   { 0x000d, KEY_OK }, /* OK */
+   { 0x000e, KEY_CAMERA }, /* Snapshot */
+   { 0x000f, KEY_ZOOM },   /* Full Screen/Restore */
+   { 0x0010, KEY_RIGHT },  /* Right arrow */
+   { 0x0011, KEY_LEFT },   /* Left arrow */
+   { 0x0012, KEY_CHANNELUP },
+   { 0x0013, KEY_CHANNELDOWN },
+   { 0x0014, KEY_SHUFFLE },
+   { 0x0016, KEY_PAUSE },
+   { 0x0017, KEY_PLAY },   /* Play */
+   { 0x001e, KEY_TIME },   /* Time Shift */
+   { 0x001f, KEY_RECORD },
+   { 0x0020, KEY_UP },
+   { 0x0021, KEY_DOWN },
+   { 0x0025, KEY_POWER },  /* Turn off computer */
+   { 0x0026, KEY_REWIND }, /* FR << */
+   { 0x0027, KEY_FASTFORWARD },/* FF >> */
+   { 0x0029, KEY_ESC },
+   { 0x002b, KEY_VOLUMEUP },
+   { 0x002c, KEY_VOLUMEDOWN },
+   { 0x002d, KEY_CHANNEL },/* CH Surfing */
+   { 0x0038, KEY_VIDEO },  /* TV/AV/S-Video/YPbPr */
+};
+
 static int cxusb_dee1601_demod_init(struct dvb_frontend* fe)
 {
static u8 clock_config []  = { CLOCK_CTL,  0x38, 0x28 };
@@ -2317,8 +2355,8 @@ struct dvb_usb_device_properties 
cxusb_bluebird_dualdig4_rev2_properties = {
 
.rc.legacy = {
.rc_interval  = 100,
-   .rc_map_table = rc_map_d680_dmb_table,
-   .rc_map_size  = ARRAY_SIZE(rc_map_d680_dmb_table),
+   .rc_map_table = rc_map_t230_table,
+   .rc_map_size  = ARRAY_SIZE(rc_map_t230_table),
.rc_query = cxusb_d680_dmb_rc_query,
},
 
-- 
1.9.1


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

[PATCH 2/4] si2168: Si2168-D60 support.

2016-12-08 Thread CrazyCat

Support for new demod version.

Signed-off-by: CrazyCat 
---
 drivers/media/dvb-frontends/si2168.c  | 4 
 drivers/media/dvb-frontends/si2168_priv.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 20b4a65..28f3bbe 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -674,6 +674,9 @@ static int si2168_probe(struct i2c_client *client,
case SI2168_CHIP_ID_B40:
dev->firmware_name = SI2168_B40_FIRMWARE;
break;
+   case SI2168_CHIP_ID_D60:
+   dev->firmware_name = SI2168_D60_FIRMWARE;
+   break;
default:
dev_dbg(&client->dev, "unknown chip version Si21%d-%c%c%c\n",
cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
@@ -761,3 +764,4 @@ static int si2168_remove(struct i2c_client *client)
 MODULE_FIRMWARE(SI2168_A20_FIRMWARE);
 MODULE_FIRMWARE(SI2168_A30_FIRMWARE);
 MODULE_FIRMWARE(SI2168_B40_FIRMWARE);
+MODULE_FIRMWARE(SI2168_D60_FIRMWARE);
diff --git a/drivers/media/dvb-frontends/si2168_priv.h 
b/drivers/media/dvb-frontends/si2168_priv.h
index 7843ccb..4baa95b 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -25,6 +25,7 @@
 #define SI2168_A20_FIRMWARE "dvb-demod-si2168-a20-01.fw"
 #define SI2168_A30_FIRMWARE "dvb-demod-si2168-a30-01.fw"
 #define SI2168_B40_FIRMWARE "dvb-demod-si2168-b40-01.fw"
+#define SI2168_D60_FIRMWARE "dvb-demod-si2168-d60-01.fw"
 #define SI2168_B40_FIRMWARE_FALLBACK "dvb-demod-si2168-02.fw"
 
 /* state struct */
@@ -37,6 +38,7 @@ struct si2168_dev {
#define SI2168_CHIP_ID_A20 ('A' << 24 | 68 << 16 | '2' << 8 | '0' << 0)
#define SI2168_CHIP_ID_A30 ('A' << 24 | 68 << 16 | '3' << 8 | '0' << 0)
#define SI2168_CHIP_ID_B40 ('B' << 24 | 68 << 16 | '4' << 8 | '0' << 0)
+   #define SI2168_CHIP_ID_D60 ('D' << 24 | 68 << 16 | '6' << 8 | '0' << 0)
unsigned int chip_id;
unsigned int version;
const char *firmware_name;
-- 
1.9.1


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

Re: [PATCH v6 0/5] davinci: VPIF: add DT support

2016-12-08 Thread Kevin Hilman

Hi Javier,

Javier Martinez Canillas  writes:

> On Wed, Dec 7, 2016 at 3:30 PM, Kevin Hilman  wrote:
>> Prepare the groundwork for adding DT support for davinci VPIF drivers.
>> This series does some fixups/cleanups and then adds the DT binding and
>> DT compatible string matching for DT probing.
>>
>> The controversial part from previous versions around async subdev
>> parsing, and specifically hard-coding the input/output routing of
>> subdevs, has been left out of this series.  That part can be done as a
>> follow-on step after agreement has been reached on the path forward.
>
> I had a similar need for another board (OMAP3 IGEPv2), that has a
> TVP5151 video decoder (that also supports 2 composite or 1 s-video
> signal) attached to the OMAP3 ISP.
>
> I posted some RFC patches [0] to define the input signals in the DT,
> and AFAICT Laurent and Hans were not against the approach but just had
> some comments on the DT binding.
>
> Basically they wanted the ports to be directly in the tvp5150 node
> instead of under a connectors sub-node [1] and to just be called just
> a (input / output) port instead of a connector [2].
>
> Unfortunately I was busy with other tasks so I couldn't res-pin the
> patches, but I think you could have something similar in the DT
> binding for your case and it shouldn't be hard to parse the ports /
> endpoints in the driver to get that information from DT and setup the
> input and output pins.

Thanks for pointing that out.  I did see this in Hans' reply to one of
my earlier versions.  Indeed I think this could be useful in solving my
problem.

>> With is version, platforms can still use the VPIF capture/display
>> drivers, but must provide platform_data for the subdevs and subdev
>> routing.
>>
>
> I guess DT backward compatibility isn't a big issue on this platform,
> since support for the platform is quite recently and after all someone
> who wants to use the vpif with current DT will need platform data and
> pdata-quirks anyways.

That's correct.

> So I agree with you that the input / output signals lookup from DT
> could be done as a follow-up.

Thanks. I'll happily add the input/output signals once they're agreed
upon.  In the mean time, at least we can have a usable video capture on
this platform, and it's at least a step in the right direction for DT
support.

Thanks for the review,

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

[PATCH 3/4] si2157: Si2141/2151 tuner support.

2016-12-08 Thread CrazyCat

Support for new tuner version.

Signed-off-by: CrazyCat 
---
 drivers/media/tuners/si2157.c  | 71 ++
 drivers/media/tuners/si2157_priv.h |  2 ++
 2 files changed, 67 insertions(+), 6 deletions(-)

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 57b2508..69fd21e 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -1,5 +1,5 @@
 /*
- * Silicon Labs Si2146/2147/2148/2157/2158 silicon tuner driver
+ * Silicon Labs Si2141/2146/2147/2148/2151/2157/2158 silicon tuner driver
  *
  * Copyright (C) 2014 Antti Palosaari 
  *
@@ -84,7 +84,7 @@ static int si2157_init(struct dvb_frontend *fe)
struct si2157_cmd cmd;
const struct firmware *fw;
const char *fw_name;
-   unsigned int uitmp, chip_id;
+   unsigned int uitmp, chip_id, count;
 
dev_dbg(&client->dev, "\n");
 
@@ -102,14 +102,46 @@ static int si2157_init(struct dvb_frontend *fe)
if (uitmp == dev->if_frequency / 1000)
goto warm;
 
+   if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   count = 0;
+   do {
+   if (count > 10)
+   goto err;
+
+   /* reset */
+   memcpy(cmd.args, "\xc0\x05\x00\x00", 4);
+   cmd.wlen = 4;
+   cmd.rlen = 1;
+   ret = si2157_cmd_execute(client, &cmd);
+   if (ret)
+   goto err;
+
+   memcpy(cmd.args, 
"\xc0\x00\x0d\x0e\x00\x01\x01\x01\x01\x03", 10);
+   cmd.wlen = 10;
+   cmd.rlen = 1;
+   ret = si2157_cmd_execute(client, &cmd);
+   if (ret)
+   goto err;
+   count++;
+   } while (cmd.args[0] == 0xfe);
+   dev_info(&client->dev, "Si2141/2151 reset attempts %d\n", 
count);
+   }
+
/* power up */
-   if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
+   switch (dev->chiptype) {
+   case SI2157_CHIPTYPE_SI2146:
memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
cmd.wlen = 9;
-   } else {
+   break;
+   case SI2157_CHIPTYPE_SI2141:
+   memcpy(cmd.args, "\xc0\x08\x01\x02\x00\x08\x01", 7);
+   cmd.wlen = 7;
+   break;
+   default:
memcpy(cmd.args, 
"\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01", 15);
cmd.wlen = 15;
}
+
cmd.rlen = 1;
ret = si2157_cmd_execute(client, &cmd);
if (ret)
@@ -131,6 +163,8 @@ static int si2157_init(struct dvb_frontend *fe)
#define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
#define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
#define SI2146_A10 ('A' << 24 | 46 << 16 | '1' << 8 | '0' << 0)
+   #define SI2141_A10 ('A' << 24 | 41 << 16 | '1' << 8 | '0' << 0)
+   #define SI2151_A10 ('A' << 24 | 51 << 16 | '1' << 8 | '0' << 0)
 
switch (chip_id) {
case SI2158_A20:
@@ -142,6 +176,10 @@ static int si2157_init(struct dvb_frontend *fe)
case SI2146_A10:
fw_name = NULL;
break;
+   case SI2141_A10:
+   case SI2151_A10:
+   fw_name = SI2141_A10_FIRMWARE;
+   break;
default:
dev_err(&client->dev, "unknown chip version Si21%d-%c%c%c\n",
cmd.args[2], cmd.args[1],
@@ -214,6 +252,23 @@ static int si2157_init(struct dvb_frontend *fe)
 
dev_info(&client->dev, "firmware version: %c.%c.%d\n",
cmd.args[6], cmd.args[7], cmd.args[8]);
+
+   if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   /* set clock */
+   memcpy(cmd.args, "\xc0\x00\x0d", 3);
+   cmd.wlen = 3;
+   cmd.rlen = 1;
+   ret = si2157_cmd_execute(client, &cmd);
+   if (ret)
+   goto err;
+   /* setup PIN */
+   memcpy(cmd.args, "\x12\x80\x80\x85\x00\x81\x00", 7);
+   cmd.wlen = 7;
+   cmd.rlen = 7;
+   ret = si2157_cmd_execute(client, &cmd);
+   if (ret)
+   goto err;
+   }
 warm:
/* init statistics in order signal app which are supported */
c->strength.len = 1;
@@ -471,7 +526,8 @@ static int si2157_probe(struct i2c_client *client,
 #endif
 
dev_info(&client->dev, "Silicon Labs %s successfully attached\n",
-   dev->chiptype == SI2157_CHIPTYPE_SI2146 ?
+   dev->chiptype == SI2157_CHIPTYPE_SI2141 ?
+   "Si2141/2151" : dev->chiptype == SI2157_CHIPTYPE_SI2146 
?
"Si2146" : "Si2147/2148/2157/2158");
 
retur

Re: [PATCH v6 3/3] sound/usb: Use Media Controller API to share media resources

2016-12-08 Thread Sakari Ailus

Hi Shuah,

On Thu, Dec 08, 2016 at 07:46:03AM -0700, Shuah Khan wrote:
> Hi Sakari,
> 
> On 12/07/2016 03:27 PM, Sakari Ailus wrote:
> > Hi Shuah,
> > 
> > On Wed, Dec 07, 2016 at 01:03:59PM -0700, Shuah Khan wrote:
> >> Hi Sakari,
> >>
> >> On 12/07/2016 03:52 AM, Sakari Ailus wrote:
> >>> Hi Shuah,
> >>>
> >>> On Mon, Dec 05, 2016 at 05:38:23PM -0700, Shuah Khan wrote:
>  On 12/05/2016 04:21 PM, Laurent Pinchart wrote:
> > Hi Shuah,
> >
> > On Monday 05 Dec 2016 15:44:30 Shuah Khan wrote:
> >> On 11/30/2016 03:01 PM, Shuah Khan wrote:
> >>> Change ALSA driver to use Media Controller API to share media 
> >>> resources
> >>> with DVB, and V4L2 drivers on a AU0828 media device.
> >>>
> >>> Media Controller specific initialization is done after sound card is
> >>> registered. ALSA creates Media interface and entity function graph
> >>> nodes for Control, Mixer, PCM Playback, and PCM Capture devices.
> >>>
> >>> snd_usb_hw_params() will call Media Controller enable source handler
> >>> interface to request the media resource. If resource request is 
> >>> granted,
> >>> it will release it from snd_usb_hw_free(). If resource is busy, 
> >>> -EBUSY is
> >>> returned.
> >>>
> >>> Media specific cleanup is done in usb_audio_disconnect().
> >>>
> >>> Signed-off-by: Shuah Khan 
> >>
> >> Hi Takashi,
> >>
> >> If you are good with this patch, could you please Ack it, so Mauro
> >> can pull it into media tree with the other two patches in this series,
> >> when he is ready to do so.
> >
> > I *really* want to address the concerns raised by Sakari before pulling 
> > more 
> > code that makes fixing the race conditions more difficult. Please, 
> > let's all 
> > work on fixing the core code to build a stable base on which we can 
> > build 
> > additional features. V4L2 and MC need teamwork, it's time to give the 
> > subsystem the love it deserves.
> >
> 
>  Hi Laurent,
> 
>  The issue Sakari brought up is specific to using devm for video_device in
>  omap3 and vsp1. I tried reproducing the problem on two different drivers
>  and couldn't on Linux 4.9-rc7.
> 
>  After sharing that with Sakari, I suggested to Sakari to pull up his 
>  patch
>  that removes the devm usage and see if he still needs all the patches in 
>  his
>  patch series. He didn't back to me on that. I also requested him to 
>  rebase on
> >>>
> >>> Just to see what remains, I made a small hack to test this with omap3isp 
> >>> by
> >>> just replacing the devm_() functions by their plain counterparts. The 
> >>> memory
> >>> is thus never released, for there is no really a proper moment to release 
> >>> it
> >>> --- something which the patchset resolves. The result is here:
> >>>
> >>> http://www.retiisi.org.uk/v4l2/tmp/media-ref-dmesg.txt>
> >>
> >> Did you test this on 4.9-rc7 without any of your other patches? If you
> >> haven't could you please run this test with just the removing devm usage
> >> from omap3isp?
> >>
> >> It would be good to get a baseline on the current with just the not using
> >> devm first and then see what needs fixing.
> >>
> >> Also, could you please send me the complete dmesg.
> > 
> > Updated from v4.9-rc6 to rc7 and with increased CONFIG_LOG_BUF_SHIFT. The
> > diff and dmesg are here:
> > 
> > http://www.retiisi.org.uk/v4l2/tmp/media-ref-diff2.txt>
> > http://www.retiisi.org.uk/v4l2/tmp/media-ref-dmesg2.txt>
> > 
> 
> Does unbind work on this even without streaming? Could you suppress

It's been working as long as I remember. There are caveats though --- the
clock to the sensor is provided by the ISP, so obviously things will not
work until the sensor is rebound as well. That is unrelated to the media
framework though; just FYI.

> debug messages and run unbind without streaming. It might fail. Let
> me know if what you see with just unbind on this driver.

I don't think disabling debug messages makes a difference but sure I can
provide you a log on that. But that'll be tomorrow.

> 
> I unearthed an old Gumstix Overo that was hiding in my hardware stash
> and I am setting it up to test.

Is it supported in mainline? I have a Nokia N9...

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

[GIT PULL v2 FOR v4.11] Remove FSF postal address

2016-12-08 Thread Sakari Ailus

Hi Mauro,

This pull request contains a single patch, one that removes the FSF postal
address from the headers in source code files. The patch is rebased from
what I posted for review. The changes since that are done to the commit
message as you requested. It now looks like this:

8<
commit 50937f09e90bce1dbba67fdffd79d8c2a525edfe
Author: Sakari Ailus 
Date:   Fri Oct 28 14:31:20 2016 +0300

media: Drop FSF's postal address from the source code files

Drop the FSF's postal address from the source code files that typically
contain mostly the license text. Of the 628 removed instances, 578 are
outdated.

The patch has been created with the following command without manual edits:

git grep -l "675 Mass Ave\|59 Temple Place\|51 Franklin St" -- \
drivers/media/ include/media|while read i; do i=$i perl -e '
open(F,"< $ENV{i}");
$a=join("", );
$a =~ s/[ \t]*\*\n.*You should.*\n.*along with.*\n.*(\n.*USA.*$)?\n//m
&& $a =~ s/(^.*)Or, (point your browser to) /$1To obtain the license, 
$2\n$1/m;
close(F);
open(F, "> $ENV{i}");
print F $a;
close(F);'; done

Signed-off-by: Sakari Ailus 
8<

Please pull.


The following changes since commit 365fe4e0ce218dc5ad10df17b150a366b6015499:

  [media] mn88472: fix chip id check on probe (2016-12-01 12:47:22 -0200)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git fsf-address

for you to fetch changes up to 50937f09e90bce1dbba67fdffd79d8c2a525edfe:

  media: Drop FSF's postal address from the source code files (2016-12-09 
00:09:51 +0200)


Sakari Ailus (1):
  media: Drop FSF's postal address from the source code files

 drivers/media/common/b2c2/flexcop.c| 4 
 drivers/media/common/cx2341x.c | 4 
 drivers/media/common/siano/sms-cards.c | 4 
 drivers/media/common/siano/sms-cards.h | 4 
 drivers/media/common/siano/smscoreapi.c| 4 
 drivers/media/common/tveeprom.c| 4 
 drivers/media/dvb-core/demux.h | 4 
 drivers/media/dvb-core/dmxdev.c| 4 
 drivers/media/dvb-core/dmxdev.h| 4 
 drivers/media/dvb-core/dvb_ca_en50221.c| 7 ++-
 drivers/media/dvb-core/dvb_demux.c | 4 
 drivers/media/dvb-core/dvb_demux.h | 4 
 drivers/media/dvb-core/dvb_frontend.c  | 7 ++-
 drivers/media/dvb-core/dvb_math.c  | 4 
 drivers/media/dvb-core/dvb_math.h  | 4 
 drivers/media/dvb-core/dvb_net.c   | 7 ++-
 drivers/media/dvb-core/dvb_net.h   | 4 
 drivers/media/dvb-core/dvb_ringbuffer.c| 4 
 drivers/media/dvb-core/dvbdev.c| 4 
 drivers/media/dvb-core/dvbdev.h| 4 
 drivers/media/dvb-frontends/af9013.c   | 4 
 drivers/media/dvb-frontends/af9013.h   | 4 
 drivers/media/dvb-frontends/af9013_priv.h  | 4 
 drivers/media/dvb-frontends/atbm8830.c | 4 
 drivers/media/dvb-frontends/atbm8830.h | 4 
 drivers/media/dvb-frontends/atbm8830_priv.h| 4 
 drivers/media/dvb-frontends/au8522_decoder.c   | 5 -
 drivers/media/dvb-frontends/bcm3510.h  | 4 
 drivers/media/dvb-frontends/bcm3510_priv.h | 4 
 drivers/media/dvb-frontends/bsbe1-d01a.h   | 7 ++-
 drivers/media/dvb-frontends/bsbe1.h| 7 ++-
 drivers/media/dvb-frontends/bsru6.h| 7 ++-
 drivers/media/dvb-frontends/cx24113.c  | 4 
 drivers/media/dvb-frontends/cx24113.h  | 4 
 drivers/media/dvb-frontends/cx24123.c  | 4 
 drivers/media/dvb-frontends/dib0070.c  | 4 
 drivers/media/dvb-frontends/dib0090.c  | 4 
 drivers/media/dvb-frontends/drx39xyj/drx39xxj.h| 4 
 drivers/media/dvb-frontends/drxd.h | 8 ++--
 drivers/media/dvb-frontends/drxd_firm.c| 8 ++--
 drivers/media/dvb-frontends/drxd_firm.h| 8 ++--
 drivers/media/dvb-frontends/drxd_hard.c| 8 ++--
 drivers/media/dvb-frontends/drxd_map_firm.h| 8 ++--
 drivers/media/dvb-frontends/drxk_hard.c| 8 ++--
 drivers/media/dvb-frontends/dvb-pll.c  | 4 
 drivers/media/dvb-frontends/dvb_dummy_fe.c | 4 
 drivers/media/dvb-frontends/dvb_dummy_fe.h | 4 
 drivers/media/dvb-frontends/ec100.c| 4 
 drivers/media/dvb-frontends/ec100.h| 4 
 drivers/media/dvb-frontends/hd29l2.c   | 4 
 drivers/media/dvb

85 matches

Mail list logo