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: Thu May 5 04:00:19 CEST 2016 git branch: test git hash: 68af062b5f38510dc96635314461c6bbe1dbf2fe gcc

Re: [PATCH v2 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

On 05/Mai/2016 00:14, Andrey Utkin wrote: > On Wed, May 04, 2016 at 01:21:20PM -0300, Ismael Luceno wrote: > > From: Andrey Utkin > > > > Such frame size is met in practice. Also report oversized frames. > > > > [ismael: Reworked warning and commit message] > >

[PATCH v2.1 5/5] media: Support variable size IOCTL arguments

Instead of checking for a strict size for the IOCTL arguments, place minimum and maximum limits. As an additional bonus, IOCTL handlers will be able to check whether the caller actually set (using the argument size) the field vs. assigning it to zero. Separate macro can be provided for that.

Re: [GIT PULL for v4.6-rc1] media updates

Hi On 2016-05-04, Mauro Carvalho Chehab wrote: > Em Wed, 4 May 2016 13:49:52 -0700 > Linus Torvalds escreveu: > > On Wed, May 4, 2016 at 12:28 PM, Stefan Lippers-Hollmann > > wrote: [...] > Stefan, > > Could you please test the enclosed patch? >

Re: [GIT PULL for v4.6-rc1] media updates

Em Wed, 4 May 2016 13:49:52 -0700 Linus Torvalds escreveu: > On Wed, May 4, 2016 at 12:28 PM, Stefan Lippers-Hollmann wrote: > > > > --- a/drivers/media/media-device.c > > +++ b/drivers/media/media-device.c > > @@ -875,7 +875,7 @@ void

Re: [GIT PULL for v4.6-rc1] media updates

Hi On 2016-05-04, Linus Torvalds wrote: > On Wed, May 4, 2016 at 12:28 PM, Stefan Lippers-Hollmann wrote: > > > > --- a/drivers/media/media-device.c > > +++ b/drivers/media/media-device.c > > @@ -875,7 +875,7 @@ void __media_device_usb_init(struct medi > >

Re: [PATCH v2 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

On Wed, May 04, 2016 at 01:21:20PM -0300, Ismael Luceno wrote: > From: Andrey Utkin > > Such frame size is met in practice. Also report oversized frames. > > [ismael: Reworked warning and commit message] > > Signed-off-by: Ismael Luceno I

Re: [GIT PULL for v4.6-rc1] media updates

On Wed, May 4, 2016 at 12:28 PM, Stefan Lippers-Hollmann wrote: > > --- a/drivers/media/media-device.c > +++ b/drivers/media/media-device.c > @@ -875,7 +875,7 @@ void __media_device_usb_init(struct medi > const char *board_name, >

Re: [PATCH v9 0/9] i2c mux cleanup and locking update

On Wed, May 04, 2016 at 10:15:26PM +0200, Peter Rosin wrote: > Hi! > > I have a pair of boards with this i2c topology: > >GPIO ---| -- BAT1 > | v / >I2C -+--B---+ MUX > | \ >

[PATCH v9 1/9] i2c: allow adapter drivers to override the adapter locking

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_ROOT_ADAPTER and I2C_LOCK_SEGMENT, but they are both

[PATCH v9 4/9] i2c-mux: document i2c muxes and elaborate on parent-/mux-locked muxes

Signed-off-by: Peter Rosin --- Documentation/i2c/i2c-topology | 370 + MAINTAINERS| 1 + 2 files changed, 371 insertions(+) create mode 100644 Documentation/i2c/i2c-topology diff --git

[PATCH v9 5/9] iio: imu: inv_mpu6050: change the i2c gate to be mux-locked

The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the unlocked i2c accesses and just use

[PATCH v9 2/9] i2c: muxes always lock the parent adapter

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

[PATCH v9 3/9] i2c-mux: relax locking of the top i2c adapter during mux-locked muxing

With a i2c topology like the following GPIO ---| -- BAT1 | v / I2C -+--+ MUX | \ EEPROM -- BAT2 there is a locking problem with the GPIO controller since it

[PATCH v9 9/9] [media] rtl2832: regmap is aware of lockdep, drop local locking hack

Tested-by: Antti Palosaari Reviewed-by: Antti Palosaari Signed-off-by: Peter Rosin --- drivers/media/dvb-frontends/rtl2832.c | 30 -- drivers/media/dvb-frontends/rtl2832_priv.h | 1 - 2 files changed, 31

[PATCH v9 7/9] [media] rtl2832: change the i2c gate to be mux-locked

The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the regmap overrides that makes the i2c accesses unlocked and

[PATCH v9 8/9] [media] rtl2832_sdr: get rid of empty regmap wrappers

Tested-by: Antti Palosaari Reviewed-by: Antti Palosaari Signed-off-by: Peter Rosin --- drivers/media/dvb-frontends/rtl2832_sdr.c | 302 +- 1 file changed, 132 insertions(+), 170 deletions(-) diff --git

[PATCH v9 6/9] [media] si2168: change the i2c gate to be mux-locked

From: Antti Palosaari The root i2c adapter lock is then no longer held by the i2c mux during accesses behind the i2c gate, and such accesses need to take that lock just like any other ordinary i2c accesses do. So, declare the i2c gate mux-locked, and zap the code that makes the

[PATCH v9 0/9] i2c mux cleanup and locking update

Hi! I have a pair of boards with this i2c topology: GPIO ---| -- BAT1 | v / I2C -+--B---+ MUX | \ EEPROM -- BAT2 (B denotes the boundary between the

[PATCH v3] media: fix use-after-free in cdev_put() when app exits after driver unbind

When driver unbinds while media_ioctl is in progress, cdev_put() fails with when app exits after driver unbinds. Add devnode struct device kobj as the cdev parent kobject. cdev_add() gets a reference to it and releases it in cdev_del() ensuring that the devnode is not deallocated as long as the

Re: [GIT PULL for v4.6-rc1] media updates

Hi On 2016-05-04, Linus Torvalds wrote: > On Tue, May 3, 2016 at 9:39 PM, Stefan Lippers-Hollmann wrote: > > > > Just as a cross-check, this (incomplete, but au0828, cx231xx and em28xx > > aren't needed/ loaded on my system) crude revert avoids the problem for > > me on

Re: [GIT PULL for v4.6-rc1] media updates

On Tue, May 3, 2016 at 9:39 PM, Stefan Lippers-Hollmann wrote: > > Just as a cross-check, this (incomplete, but au0828, cx231xx and em28xx > aren't needed/ loaded on my system) crude revert avoids the problem for > me on v4.6-rc6-113-g83858a7. Hmm. That just open-codes

Re: Kernel docs: muddying the waters a bit

Em Wed, 4 May 2016 10:59:36 -0600 Jonathan Corbet escreveu: > On Wed, 4 May 2016 13:50:35 -0300 > Mauro Carvalho Chehab wrote: > > > Em Wed, 4 May 2016 19:13:21 +0300 > > Jani Nikula escreveu: > > > I think we should go for

[PATCH v2 1/8] Input: atmel_mxt_ts - add support for T37 diagnostic data

Atmel maXTouch devices have a T37 object which can be used to read raw touch deltas from the device. This consists of an array of 16-bit integers, one for each node on the touchscreen matrix. Signed-off-by: Nick Dyer --- drivers/input/touchscreen/atmel_mxt_ts.c | 152

[PATCH v2 3/8] [media] v4l2-core: Add VFL_TYPE_TOUCH_SENSOR

Some touch controllers send out raw touch data in a similar way to a greyscale frame grabber. Add a new device type for these devices. Use a new device prefix v4l-touch for these devices, to stop generic capture software from treating them as webcams. Signed-off-by: Nick Dyer

[PATCH v2 8/8] Input: atmel_mxt_ts - add support for reference data

There are different datatypes available from a maXTouch chip. Add support to retrieve reference data as well. Signed-off-by: Nick Dyer --- drivers/input/touchscreen/atmel_mxt_ts.c | 66 +++- 1 file changed, 56 insertions(+), 10 deletions(-)

[PATCH v2 4/8] Input: atmel_mxt_ts - output diagnostic debug via v4l2 device

Register a video device to output T37 diagnostic data. Signed-off-by: Nick Dyer --- drivers/input/touchscreen/Kconfig| 2 + drivers/input/touchscreen/atmel_mxt_ts.c | 271 +++ 2 files changed, 273 insertions(+) diff --git

[PATCH v2 6/8] Input: atmel_mxt_ts - handle diagnostic data orientation

Invert the diagnostic data to match the orientation of the input device. Signed-off-by: Nick Dyer --- drivers/input/touchscreen/atmel_mxt_ts.c | 30 +++--- 1 file changed, 23 insertions(+), 7 deletions(-) diff --git

[PATCH v2 0/8] Input: atmel_mxt_ts - output raw touch diagnostic data via V4L

This is a series of patches to add diagnostic data support to the Atmel maXTouch driver. It's a rewrite of the previous implementation which output via debugfs: it now uses a V4L2 device in a similar way to the sur40 driver. There are significant performance advantages to putting this code into

[PATCH v2 5/8] Input: atmel_mxt_ts - read touchscreen size

The touchscreen may have a margin where not all the matrix is used. Read the parameters from T9 and T100 and take account of the difference. Note: this does not read the XORIGIN/YORIGIN fields so it assumes that the touchscreen starts at (0,0) Signed-off-by: Nick Dyer ---

[PATCH v2 7/8] Input: atmel_mxt_ts - add diagnostic data support for mXT1386

The mXT1386 family of chips have a different architecture which splits the diagnostic data into 3 columns. Signed-off-by: Nick Dyer --- drivers/input/touchscreen/atmel_mxt_ts.c | 29 ++--- 1 file changed, 26 insertions(+), 3 deletions(-) diff

[PATCH v2 2/8] [media] Add signed 16-bit pixel format

This will be used for output of raw touch data. Signed-off-by: Nick Dyer --- Documentation/DocBook/media/v4l/pixfmt-ys16.xml | 79 + Documentation/DocBook/media/v4l/pixfmt.xml | 1 + drivers/media/v4l2-core/v4l2-ioctl.c| 1 +

Re: Kernel docs: muddying the waters a bit

On Wed, 4 May 2016 13:50:35 -0300 Mauro Carvalho Chehab wrote: > Em Wed, 4 May 2016 19:13:21 +0300 > Jani Nikula escreveu: > > I think we should go for vanilla sphinx at first, to make the setup step > > as easy as possible for everyone. > >

Re: Kernel docs: muddying the waters a bit

Em Wed, 4 May 2016 19:13:21 +0300 Jani Nikula escreveu: > On Wed, 04 May 2016, Markus Heiser wrote: > > Correct my, if I'am wrong. I'am a bit unfamiliar with DOCPROC in > > particular with your "MARKDOWNREADY := gpu.xml" process. > > > > As I

Re: Kernel docs: muddying the waters a bit

Em Wed, 4 May 2016 08:57:13 -0600 Jonathan Corbet escreveu: > On Wed, 4 May 2016 16:18:27 +0200 > Daniel Vetter wrote: > > > > I'd really like to converge on the markup question, so that we can start > > > using all the cool stuff with impunity in gpu

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

> A question on best practices here... I already did a v8 (but only as > a branch) so I think this will be v9, bit that's a minor detail. The > real question is what I should do about patches 1-15 that are already > in next? Send them too? If not, should I send 16-24 with the same old > patch

Re: Kernel docs: muddying the waters a bit

On Wed, May 4, 2016 at 5:02 PM, Daniel Vetter wrote: > On Wed, May 04, 2016 at 08:57:13AM -0600, Jonathan Corbet wrote: >> On Wed, 4 May 2016 16:18:27 +0200 >> Daniel Vetter wrote: >> >> > > I'd really like to converge on the markup question, so that we

Re: [PATCH v2 4/5] media: Add flags to tell whether to take graph mutex for an IOCTL

Hi Shuah, Thanks for the review! On Wed, May 04, 2016 at 08:50:56AM -0600, Shuah Khan wrote: > On 05/04/2016 05:20 AM, Sakari Ailus wrote: > > New IOCTLs (especially for the request API) do not necessarily need the > > graph mutex acquired. Leave this up to the drivers. > > Sakari, > > Does

[PATCH v2 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

From: Andrey Utkin Such frame size is met in practice. Also report oversized frames. [ismael: Reworked warning and commit message] Signed-off-by: Ismael Luceno --- drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 7 +-- 1 file

[PATCH v2 2/2] solo6x10: Simplify solo_enum_ext_input

Additionally, now it specifies which channels it's showing. Signed-off-by: Ismael Luceno --- drivers/media/pci/solo6x10/solo6x10-v4l2.c | 34 ++ 1 file changed, 16 insertions(+), 18 deletions(-) diff --git

Re: Kernel docs: muddying the waters a bit

Em Wed, 4 May 2016 11:34:08 +0200 Markus Heiser escreveu: > Hi all, (hi Jonathan, please take note of my offer below) > > Am 03.05.2016 um 16:31 schrieb Daniel Vetter : > > > Hi all, > > > > So sounds like moving ahead with rst/sphinx is the

Re: Kernel docs: muddying the waters a bit

On Wed, 04 May 2016, Markus Heiser wrote: > Correct my, if I'am wrong. I'am a bit unfamiliar with DOCPROC in > particular with your "MARKDOWNREADY := gpu.xml" process. > > As I understood, you convert markdown to docbook within the kernel-doc > script using pandoc's

Re: [PATCH v2] Add GS driver (SPI video serializer family)

Le 04/05/2016 à 15:46, Hans Verkuil a écrit : >> Ok, but I should have difficulties to define correctly these standards. >> I worked on video stream in SMPTE-125M and I don't know if other SMPTE >> standards are based on the same characteristics. >> In addition to this, those standards are not

Re: Kernel docs: muddying the waters a bit

Am 04.05.2016 um 15:43 schrieb Daniel Vetter : > On Wed, May 04, 2016 at 02:40:29PM +0200, Markus Heiser wrote: >>> On Wed, 04 May 2016, Markus Heiser wrote: >>> I'd be *very* hesitant about adding the kind of things you do in >>> reformat_block_rst to

Re: [PATCH v2] Add GS driver (SPI video serializer family)

Le 04/05/2016 à 13:41, Hans Verkuil a écrit : > Hi Charles-Antoine, Hi, > On 04/28/2016 04:10 PM, Charles-Antoine Couret wrote: >> But this component family support CEA standards and other >> (SMPTE XXXM in fact). V4L2 seems oriented to manage CEA or >> VGA formats. So, I used timings structure

Re: Kernel docs: muddying the waters a bit

On Wed, 04 May 2016, Jonathan Corbet wrote: > The sphinx/rst approach does seem, to me, to be the right one, with the > existing DocBook structure remaining in place for those who want/need > it. I'm inclined toward my stuff as a base to work with, obviously :) But > it's hackish

Re: [PATCH 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

On 05/04/2016 04:22 PM, Andrey Utkin wrote: > On Wed, May 4, 2016 at 5:04 PM, Hans Verkuil wrote: >> BTW, looking at the MAINTAINERS file I see two email addresses for Andrey, >> neither of which is the fastmail.com address this email came from. > > Now I'm replying from

Re: [PATCH 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

On 04/May/2016 17:22, Andrey Utkin wrote: > On Wed, May 4, 2016 at 5:04 PM, Hans Verkuil wrote: > > BTW, looking at the MAINTAINERS file I see two email addresses for Andrey, > > neither of which is the fastmail.com address this email came from. > > Now I'm replying from

Re: Kernel docs: muddying the waters a bit

On Wed, 04 May 2016 16:41:50 +0300 Jani Nikula wrote: > On Wed, 04 May 2016, Markus Heiser wrote: > > In reST the directive might look like: > > > > - > > Device Instance and Driver Handling > > === > > > >

Re: Kernel docs: muddying the waters a bit

On Wed, May 04, 2016 at 08:57:13AM -0600, Jonathan Corbet wrote: > On Wed, 4 May 2016 16:18:27 +0200 > Daniel Vetter wrote: > > > > I'd really like to converge on the markup question, so that we can start > > > using all the cool stuff with impunity in gpu documentations.

Re: Kernel docs: muddying the waters a bit

On Wed, 4 May 2016 16:18:27 +0200 Daniel Vetter wrote: > > I'd really like to converge on the markup question, so that we can start > > using all the cool stuff with impunity in gpu documentations. > > Aside: If we decide this now I could send in a pull request for the

Re: [PATCH 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

On 04/May/2016 16:34, Andrey Utkin wrote: > On Sat, Apr 30, 2016 at 12:17:08AM -0300, Ismael Luceno wrote: > > Such frame size is met in practice. Also report oversized frames. > > > > Based on patches by Andrey Utkin . > > If it is based on my patches([1] [2]),

Re: [PATCH v2 4/5] media: Add flags to tell whether to take graph mutex for an IOCTL

On 05/04/2016 05:20 AM, Sakari Ailus wrote: > New IOCTLs (especially for the request API) do not necessarily need the > graph mutex acquired. Leave this up to the drivers. Sakari, Does this mean drivers have to hold the graph mutex as needed? My concern with this is that we will have graph_mutex

Re: [PATCH 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

On Wed, May 4, 2016 at 5:04 PM, Hans Verkuil wrote: > BTW, looking at the MAINTAINERS file I see two email addresses for Andrey, > neither of which is the fastmail.com address this email came from. Now I'm replying from corporate email. > Andrey, it might be a good idea to

Re: Kernel docs: muddying the waters a bit

On Wed, May 4, 2016 at 3:43 PM, Daniel Vetter wrote: > I'd really like to converge on the markup question, so that we can start > using all the cool stuff with impunity in gpu documentations. Aside: If we decide this now I could send in a pull request for the rst/sphinx

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

On 2016-05-03 23:39, Wolfram Sang wrote: >> Yes, they look like reasonable complaints. > > Thanks for fixing them. I just sent out my latest comments and when you > fix those and send V8, I'll apply that right away. I think we are safe > to fix the rest incrementally if needed. Note that I

Re: [PATCH 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

OK, I've dropped Ismael's patch from my pull request to Mauro until this is resolved. Who actually maintains this driver? I would say Andrey since he works for bluecherry. If Ismael is no longer affiliated (either officially or unofficially) with bluecherry, then his name should be removed.

[GIT PULL FOR v4.7] Various fixes

(Superseeds https://patchwork.linuxtv.org/patch/34178/, dropping Ismael's patch due to confused patch provenance) The following changes since commit 68af062b5f38510dc96635314461c6bbe1dbf2fe: Merge tag 'v4.6-rc6' into patchwork (2016-05-02 07:48:23 -0300) are available in the git repository

Re: [PATCH v2] Add GS driver (SPI video serializer family)

Hi Charles-Antoine, On 05/04/2016 03:27 PM, Charles-Antoine Couret wrote: > Le 04/05/2016 à 13:41, Hans Verkuil a écrit : >> Hi Charles-Antoine, > > Hi, > >> On 04/28/2016 04:10 PM, Charles-Antoine Couret wrote: >>> But this component family support CEA standards and other >>> (SMPTE XXXM in

Re: Kernel docs: muddying the waters a bit

On Wed, May 04, 2016 at 02:40:29PM +0200, Markus Heiser wrote: > > On Wed, 04 May 2016, Markus Heiser wrote: > > I'd be *very* hesitant about adding the kind of things you do in > > reformat_block_rst to kernel-doc. IMO the extraction from kernel-doc > > comments must

Re: Kernel docs: muddying the waters a bit

On Wed, 04 May 2016, Markus Heiser wrote: >> What do you mean by ".tmpl workflow"? > > Sorry for bad naming, I addressed the DOCPROC build process which builds > the .xml files from .tmpl files ... Yeah, I know more about this part than I care. I was just wondering

Re: [PATCH 1/2] solo6x10: Set FRAME_BUF_SIZE to 200KB

On Sat, Apr 30, 2016 at 12:17:08AM -0300, Ismael Luceno wrote: > Such frame size is met in practice. Also report oversized frames. > > Based on patches by Andrey Utkin . If it is based on my patches([1] [2]), then why you claim authorship and why you don't let

[PATCH v2.1 3/5] media: Refactor copying IOCTL arguments from and to user space

Refactor copying the IOCTL argument structs from the user space and back, in order to reduce code copied around and make the implementation more robust. As a result, the copying is done while not holding the graph mutex. Signed-off-by: Sakari Ailus --- since v2: -

[PATCH 1/3] media: Move media_device link_notify operation to an ops structure

From: Laurent Pinchart This will allow adding new operations without increasing the media_device structure size for drivers that don't implement any media device operation. Signed-off-by: Laurent Pinchart

Re: [PATCH 3/3] v4l: subdev: Call pad init_cfg operation when opening subdevs

On 05/04/2016 01:25 PM, Sakari Ailus wrote: > From: Laurent Pinchart > > The subdev core code currently rely on the subdev open handler to > initialize the file handle's pad configuration, even though subdevs now > have a pad operation dedicated for

Re: [PATCH 2/3] media: Add per-file-handle data support

On 05/04/2016 01:25 PM, Sakari Ailus wrote: > From: Laurent Pinchart > > The media devnode core associates devnodes with files by storing the > devnode pointer in the file structure private_data field. In order to > allow tracking of per-file-handle

Re: [PATCH 1/3] media: Move media_device link_notify operation to an ops structure

On 05/04/2016 02:26 PM, Sakari Ailus wrote: > From: Laurent Pinchart > > This will allow adding new operations without increasing the > media_device structure size for drivers that don't implement any media > device operation. > > Signed-off-by:

Re: Kernel docs: muddying the waters a bit

Hi Jani, Am 04.05.2016 um 11:58 schrieb Jani Nikula : > On Wed, 04 May 2016, Markus Heiser wrote: >> but I think this will not by very helpful, as long as you miss >> a similar ".tmpl" workflow for reST documents. >> >> I'am working on a reST

Re: [PATCH v2 5/5] media: Support variable size IOCTL arguments

Hi Sakari, On 05/04/2016 01:20 PM, Sakari Ailus wrote: > Instead of checking for a strict size for the IOCTL arguments, place > minimum and maximum limits. > > As an additional bonus, IOCTL handlers will be able to check whether the > caller actually set (using the argument size) the field vs.

Re: [PATCH v2 3/5] media: Refactor copying IOCTL arguments from and to user space

Hi Hans, On Wed, May 04, 2016 at 02:24:47PM +0200, Hans Verkuil wrote: > Hi Sakari, > > Thanks for working on this! > > I've got one comment: > > On 05/04/2016 01:20 PM, Sakari Ailus wrote: > > Refactor copying the IOCTL argument structs from the user space and back, > > in order to reduce

[PATCH 1/3] media: Move media_device link_notify operation to an ops structure

From: Laurent Pinchart This will allow adding new operations without increasing the media_device structure size for drivers that don't implement any media device operation. Signed-off-by: Laurent Pinchart

Re: [PATCH v2 3/5] media: Refactor copying IOCTL arguments from and to user space

Hi Sakari, Thanks for working on this! I've got one comment: On 05/04/2016 01:20 PM, Sakari Ailus wrote: > Refactor copying the IOCTL argument structs from the user space and back, > in order to reduce code copied around and make the implementation more > robust. > > As a result, the copying

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

Hi Peter, thanks for the detailed explanation! > So maybe there should be only one flag, e.g. I2C_LOCK_ROOT_ADAPTER? > I.e. perhaps leave the future for later? I think this makes the current code easier understandable at this point, but I'll leave the decision to you. I am fine with both. Maybe

Re: [PATCH 2/2] solo6x10: Simplify solo_enum_ext_input

On 05/04/2016 01:42 PM, Ismael Luceno wrote: > On 04/Mai/2016 10:02, Hans Verkuil wrote: >> Hi Ismael, >> >> On 04/30/2016 05:17 AM, Ismael Luceno wrote: >>> Additionally, now it specifies which channels it's showing. >>> >>> Signed-off-by: Ismael Luceno >>> --- >>>

Re: [PATCH 2/2] solo6x10: Simplify solo_enum_ext_input

On 04/Mai/2016 10:02, Hans Verkuil wrote: > Hi Ismael, > > On 04/30/2016 05:17 AM, Ismael Luceno wrote: > > Additionally, now it specifies which channels it's showing. > > > > Signed-off-by: Ismael Luceno > > --- > > drivers/media/pci/solo6x10/solo6x10-v4l2.c | 27

Re: [PATCH v2] Add GS driver (SPI video serializer family)

Hi Charles-Antoine, On 04/28/2016 04:10 PM, Charles-Antoine Couret wrote: > Hello, > Here my second patch version about GS serializer. > It should be easy to add support for GS1582 and GS1572. > I am not sure about V4L2 interfaces to set/get timings. > I tested with GS1662 component and v4l2-dbg

[PATCH 3/3] v4l: subdev: Call pad init_cfg operation when opening subdevs

From: Laurent Pinchart The subdev core code currently rely on the subdev open handler to initialize the file handle's pad configuration, even though subdevs now have a pad operation dedicated for that purpose. As a first step towards migration to

[PATCH 2/3] media: Add per-file-handle data support

From: Laurent Pinchart The media devnode core associates devnodes with files by storing the devnode pointer in the file structure private_data field. In order to allow tracking of per-file-handle data introduce a new media devnode file handle structure

[PATCH 0/3] Media device file handle support, prepare for requests

Hi everyone, These patches add support for media device file handle and make it more practical to have callback functions in the media device. Also pad init_cfg() operation is called at sub-device open. While not directly related to the request API, these will be needed, or are at least

[PATCH v2 1/5] media: Determine early whether an IOCTL is supported

Preparation for refactoring media IOCTL handling to unify common parts. Signed-off-by: Sakari Ailus --- drivers/media/media-device.c | 52 +--- 1 file changed, 49 insertions(+), 3 deletions(-) diff --git

[PATCH v2 4/5] media: Add flags to tell whether to take graph mutex for an IOCTL

New IOCTLs (especially for the request API) do not necessarily need the graph mutex acquired. Leave this up to the drivers. Signed-off-by: Sakari Ailus --- drivers/media/media-device.c | 47 ++-- 1 file changed, 28

[PATCH v2 2/5] media: Unify IOCTL handler calling

Each IOCTL handler can be listed in an array instead of using a large and cumbersome switch. Do that. Signed-off-by: Sakari Ailus --- drivers/media/media-device.c | 89 1 file changed, 23 insertions(+), 66 deletions(-)

[PATCH v2 3/5] media: Refactor copying IOCTL arguments from and to user space

Refactor copying the IOCTL argument structs from the user space and back, in order to reduce code copied around and make the implementation more robust. As a result, the copying is done while not holding the graph mutex. Signed-off-by: Sakari Ailus ---

[PATCH v2 0/5] Refactor media IOCTL handling, add variable length arguments

Hi everyone, I've updated my patchset for refactoring the media device IOCTL handling. The original set is here: The patches themselves have been reworked so I don't detail the changes in this set. What's noteworthy however is that

[PATCH v2 5/5] media: Support variable size IOCTL arguments

Instead of checking for a strict size for the IOCTL arguments, place minimum and maximum limits. As an additional bonus, IOCTL handlers will be able to check whether the caller actually set (using the argument size) the field vs. assigning it to zero. Separate macro can be provided for that.

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

Hi! On 2016-05-03 23:38, Wolfram Sang wrote: > On Wed, Apr 20, 2016 at 05:17:56PM +0200, Peter Rosin wrote: >> 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

Re: Kernel docs: muddying the waters a bit

On Wed, 04 May 2016, Markus Heiser wrote: > but I think this will not by very helpful, as long as you miss > a similar ".tmpl" workflow for reST documents. > > I'am working on a reST directive (named: "kernel-doc") to provide a > similar ".tmpl" workflow within plain

Re: Kernel docs: muddying the waters a bit

Hi all, (hi Jonathan, please take note of my offer below) Am 03.05.2016 um 16:31 schrieb Daniel Vetter : > Hi all, > > So sounds like moving ahead with rst/sphinx is the option that should > allow us to address everyone's concerns eventually? Of course the > first one

Re: [PATCH v10 0/8] Add MT8173 Video Encoder Driver and VPU Driver

Hi Hans, On Wed, 2016-05-04 at 10:25 +0200, Hans Verkuil wrote: > > On 05/04/2016 10:19 AM, tiffany lin wrote: > > Hi Hans, > > > > On Wed, 2016-05-04 at 09:32 +0200, Hans Verkuil wrote: > >> Hi Tiffany, > >> > >> On 05/03/2016 12:11 PM, Tiffany Lin wrote: > >>> == > >>>

[GIT PULL FOR v4.7] Various fixes

The following changes since commit 68af062b5f38510dc96635314461c6bbe1dbf2fe: Merge tag 'v4.6-rc6' into patchwork (2016-05-02 07:48:23 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.7d for you to fetch changes up to

[PATCH v4] media: vb2-dma-contig: configure DMA max segment size properly

This patch lets vb2-dma-contig memory allocator to configure DMA max segment size properly for the client device. Setting it is needed to let DMA-mapping subsystem to create a single, contiguous mapping in DMA address space. This is essential for all devices, which use dma-contig videobuf2 memory

Re: [PATCH v3] media: vb2-dma-contig: configure DMA max segment size properly

Hi Hans On 2016-05-04 10:32, Hans Verkuil wrote: Hi Marek, On 05/04/2016 10:28 AM, Marek Szyprowski wrote: Hi Hans, On 2016-05-04 10:22, Hans Verkuil wrote: Hi Marek, On 05/02/2016 12:59 PM, Marek Szyprowski wrote: This patch lets vb2-dma-contig memory allocator to configure DMA max

Re: [PATCH v3] media: vb2-dma-contig: configure DMA max segment size properly

Hi Marek, On 05/04/2016 10:28 AM, Marek Szyprowski wrote: > Hi Hans, > > > On 2016-05-04 10:22, Hans Verkuil wrote: >> Hi Marek, >> >> On 05/02/2016 12:59 PM, Marek Szyprowski wrote: >>> This patch lets vb2-dma-contig memory allocator to configure DMA max >>> segment size properly for the

Re: [PATCH v3] media: vb2-dma-contig: configure DMA max segment size properly

Hi Hans, On 2016-05-04 10:22, Hans Verkuil wrote: Hi Marek, On 05/02/2016 12:59 PM, Marek Szyprowski wrote: This patch lets vb2-dma-contig memory allocator to configure DMA max segment size properly for the client device. Setting it is needed to let DMA-mapping subsystem to create a single,

Re: [PATCH v10 0/8] Add MT8173 Video Encoder Driver and VPU Driver

On 05/04/2016 10:19 AM, tiffany lin wrote: > Hi Hans, > > On Wed, 2016-05-04 at 09:32 +0200, Hans Verkuil wrote: >> Hi Tiffany, >> >> On 05/03/2016 12:11 PM, Tiffany Lin wrote: >>> == >>> Introduction >>> == >>> >>> The purpose of this series is to add the driver for

Re: [PATCH v3] media: vb2-dma-contig: configure DMA max segment size properly

Hi Marek, On 05/02/2016 12:59 PM, Marek Szyprowski wrote: > This patch lets vb2-dma-contig memory allocator to configure DMA max > segment size properly for the client device. Setting it is needed to let > DMA-mapping subsystem to create a single, contiguous mapping in DMA > address space. This

Re: [PATCH v10 0/8] Add MT8173 Video Encoder Driver and VPU Driver

Hi Hans, On Wed, 2016-05-04 at 09:32 +0200, Hans Verkuil wrote: > Hi Tiffany, > > On 05/03/2016 12:11 PM, Tiffany Lin wrote: > > == > > Introduction > > == > > > > The purpose of this series is to add the driver for video codec hw embedded > > in the Mediatek's MT8173

Re: [PATCH 2/2] solo6x10: Simplify solo_enum_ext_input

Hi Ismael, On 04/30/2016 05:17 AM, Ismael Luceno wrote: > Additionally, now it specifies which channels it's showing. > > Signed-off-by: Ismael Luceno > --- > drivers/media/pci/solo6x10/solo6x10-v4l2.c | 27 +-- > 1 file changed, 9 insertions(+), 18

[GIT PULL FOR v4.7] Add support for MT8173 video encoder

>From the cover letter of the patch series (https://lkml.org/lkml/2016/5/3/279): The purpose of this series is to add the driver for video codec hw embedded in the Mediatek's MT8173 SoCs. Mediatek Video Codec is able to handle video encoding of in a range of formats. This patch series also

Re: [PATCH v10 0/8] Add MT8173 Video Encoder Driver and VPU Driver

Hi Tiffany, On 05/03/2016 12:11 PM, Tiffany Lin wrote: > == > Introduction > == > > The purpose of this series is to add the driver for video codec hw embedded > in the Mediatek's MT8173 SoCs. > Mediatek Video Codec is able to handle video encoding of in a range of >

  1   2   >