TT USB CT2-4650 CI with new product id

Hello. i just bought a new CT2-4650 dvb usb device for use with dvb-t2. i picked this since it was supposed to be already working with the built in drivers in the kernel, but that is not the case. as far as i can tell it is the module dvb-usb-dvbsky that is supposed to be loaded for this

[PATCH v2 2/8] i2c-mux: move select and deselect ops to i2c_mux_core

From: Peter Rosin The mux select and deselect ops are common to the mux most of the time, so store the ops in the mux core. Change the select and deselect op to work in terms of the mux core instead of the child adapter. No driver uses the child adapter anyway, and if it is

[PATCH v2 0/8] i2c mux cleanup and locking update

From: Peter Rosin Hi! I have a pair of boards with this i2c topology: GPIO ---| -- BAT1 | v / I2C -+--B---+ MUX | \ EEPROM -- BAT2 (B

Re: [PATCH v2 3/8] i2c-mux: move the slave side adapter management to i2c_mux_core

Hi Peter, [auto build test ERROR on wsa/i2c/for-next] [also build test ERROR on v4.4-rc8 next-20160105] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Peter-Rosin/i2c-mux-cleanup-and-locking

[PATCH v2 5/8] i2c-mux: pinctrl: get rid of the driver private struct device pointer

From: Peter Rosin There is a copy of the device pointer in the mux core. Signed-off-by: Peter Rosin --- drivers/i2c/muxes/i2c-mux-pinctrl.c | 23 --- 1 file changed, 8 insertions(+), 15 deletions(-) diff --git

[PATCH v2 6/8] i2c: allow adapter drivers to override the adapter locking

From: Peter Rosin Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and unlock_bus ops in the adapter. These funcs/ops take an additional flags argument that indicates for what purpose the adapter is locked. There are two flags, I2C_LOCK_ADAPTER and

[PATCH v2 3/8] i2c-mux: move the slave side adapter management to i2c_mux_core

From: Peter Rosin All muxes have slave side adapters, many have some arbitrary number of them. Handle this in the mux core, so that drivers are simplified. Add i2c_mux_reserve_adapter that can be used when it is known in advance how many child adapters that is to be added. This

Re: [PATCH] media: i2c: ov2659: speedup probe if no device connected

On Mon, Dec 21, 2015 at 1:54 PM, Grygorii Strashko wrote: > The ov2659 driver performs device detection and initialization in the > following way: > - send reset command REG_SOFTWARE_RESET > - load array of predefined register's setting (~150 values) > - read device

Re: [PATCH] media: use unsigned for pad index

On Fri, Dec 11, 2015 at 2:26 PM, Mauro Carvalho Chehab wrote: > The pad index is unsigned. Replace the occurences of it where > pertinent. > > Suggested-by: Laurent Pinchart > Signed-off-by: Mauro Carvalho Chehab

Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance

On 01/05/2016 07:57 AM, Peter Rosin wrote: From: Peter Rosin The initial core mux structure starts off small with only the parent adapter pointer, which all muxes have, and a priv pointer for mux driver private data. Add i2c_mux_alloc function to unify the creation of a mux.

Re: [PATCH][davinci] ccdc_update_raw_params() frees the wrong thing

On Sun, Dec 13, 2015 at 12:32 AM, Al Viro wrote: > Passing a physical address to free_pages() is a bad idea. > config_params->fault_pxl.fpc_table_addr is set to virt_to_phys() > of __get_free_pages() return value; what we should pass to free_pages() > is its

[PATCH v2 7/8] i2c: muxes always lock the parent adapter

From: Peter Rosin Instead of checking for i2c parent adapters for every lock/unlock, simply override the locking for muxes to always lock/unlock the parent adapter directly. Signed-off-by: Peter Rosin --- drivers/i2c/i2c-core.c | 21 +++--

[PATCH v2 8/8] i2c-mux: relax locking of the top i2c adapter during i2c controlled muxing

From: Peter Rosin With a i2c topology like the following GPIO ---| -- BAT1 | v / I2C -+--+ MUX | \ EEPROM -- BAT2 there is a locking

[PATCH v2 1/8] i2c-mux: add common core data for every mux instance

From: Peter Rosin The initial core mux structure starts off small with only the parent adapter pointer, which all muxes have, and a priv pointer for mux driver private data. Add i2c_mux_alloc function to unify the creation of a mux. Where appropriate, pass around the mux core

[PATCH] [media] sh_mobile_ceu_camera: use soc_camera_from_vb2q

Use soc_camera_from_vb2q() instead of open-coding it. Signed-off-by: Geliang Tang --- drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git

Re: [PATCH v2 3/8] i2c-mux: move the slave side adapter management to i2c_mux_core

-05 17:49, kbuild test robot wrote: > Hi Peter, > > [auto build test ERROR on wsa/i2c/for-next] > [also build test ERROR on v4.4-rc8 next-20160105] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: > https

Re: [PATCH v2 1/8] i2c-mux: add common core data for every mux instance

Hi Guenter, [BTW, if anyone feels spammed by this series, please drop me a note] On 2016-01-05 17:42, Guenter Roeck wrote: > On 01/05/2016 07:57 AM, Peter Rosin wrote: >> From: Peter Rosin >> >> The initial core mux structure starts off small with only the parent >> adapter

Re: [PATCH v2 0/8] i2c mux cleanup and locking update

Hi Wolfram, On 2016-01-05 19:48, Wolfram Sang wrote: > Peter, > >> PS. needs a bunch of testing, I do not have access to all the involved hw > > First of all, thanks for diving into this topic and the huge effort you > apparently have put into it. Yeah, I started with dipping just the toes,

Re: [PATCH v2 0/8] i2c mux cleanup and locking update

Peter, > PS. needs a bunch of testing, I do not have access to all the involved hw First of all, thanks for diving into this topic and the huge effort you apparently have put into it. It is obviously a quite intrusive series, so it needs careful review. TBH, I can't really tell when I have the

cron job: media_tree daily build: OK

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: Wed Jan 6 04:00:19 CET 2016 git branch: test git hash: 768acf46e1320d6c41ed1b7c4952bab41c1cde79 gcc

Re: [PATCH] si2168: use i2c controlled mux interface

Hi Antti, On 2016-01-06 06:42, Antti Palosaari wrote: > Recent i2c mux locking update offers support for i2c controlled i2c > muxes. Use it and get the rid of homemade hackish i2c adapter > locking code. That looks good on a first glance, and I'm sure it felt good to get rid of the locking

[PATCH] si2168: use i2c controlled mux interface

Recent i2c mux locking update offers support for i2c controlled i2c muxes. Use it and get the rid of homemade hackish i2c adapter locking code. Cc: Peter Rosin Cc: Peter Rosin Signed-off-by: Antti Palosaari ---

Re: [PATCH v2 3/8] i2c-mux: move the slave side adapter management to i2c_mux_core

Ouch, this got lost in the shuffle, don't bother testing without it. It will be included in v3. [the reason is that my test hw relies on vendor patches, and I have to rebase before sending. I.e., I can only compile-test the stuff I'm actually sending out. Inconvenient.] diff --git

Re: per-frame camera metadata (again)

On Fri, 1 Jan 2016, Guennadi Liakhovetski wrote: > Hi Laurent, > > On Sun, 27 Dec 2015, Laurent Pinchart wrote: > > > Hi Guennadi, > > > > On Thursday 24 December 2015 11:42:49 Guennadi Liakhovetski wrote: > > > Hi Laurent, > > > > > > Let me put this at the top: So far it looks like we

Multiple open and read of vivi device

Hello, Does anyone knows why vivi is limited to one open ? Is there some way to patch it for multiple opens and reading ? Regards, Ran -- 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

Re: Multiple open and read of vivi device

Le mardi 05 janvier 2016 à 23:18 +0200, Ran Shalit a écrit : > Does anyone knows why vivi is limited to one open ? > Is there some way to patch it for multiple opens and reading ? This is not fully exact. You can open vivid device multiple times. Though you can only have one instance streaming at

Re: TT USB CT2-4650 CI with new product id

On 2016-01-05 11:24, Torbjorn Jansson wrote: Hello. i just bought a new CT2-4650 dvb usb device for use with dvb-t2. i picked this since it was supposed to be already working with the built in drivers in the kernel, but that is not the case. as far as i can tell it is the module dvb-usb-dvbsky