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 workar
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
---
drivers/media/dvb-frontends/si2168.c | 61
1 f
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 versio
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 a/drivers/i2c/i
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
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 http://vge
--
On 2016-01-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]
>
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, but
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 pointer, which all mu
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 b
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
> ---
> drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 2 +-
> drivers/stagi
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 phys_to_virt(). ccdc_close() d
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 version REG_SC_CHIP_ID_H/REG
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
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.
Where appropriate
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 avoids reallocati
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 I2C_LOCK_SEGMENT, but they
From: Peter Rosin
The dev pointer is readily available in the mux core struct, no point in
keeping multiple copies around.
The patch also fixes a bug in rtl2832, which attached its mux slave
adapter to the device owning the mux parent adapter instead of
attaching it to its own device.
Signed-of
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 a/drivers/i2c/muxes/i2c-mux-pinctrl.c
b/drivers/i2c/muxes/i2c-
From: Peter Rosin
Hi!
I have a pair of boards with this i2c topology:
GPIO ---| -- BAT1
| v /
I2C -+--B---+ MUX
| \
EEPROM -- BAT2
(B denotes the bound
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 needed in a future mu
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 +++--
drivers/i2c/i2c-mux.c | 27 ++
From: Peter Rosin
With a i2c topology like the following
GPIO ---| -- BAT1
| v /
I2C -+--+ MUX
| \
EEPROM -- BAT2
there is a locking problem with the GPIO c
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 structure instead
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 a/drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c
b/drivers/me
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
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 conver
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 devi
28 matches
Mail list logo
