Re: [RFC] Create test script(s?) for regression testing

[Shuah Khan]

On 11/07/2018 12:10 PM, Mauro Carvalho Chehab wrote:
> Em Wed, 07 Nov 2018 12:06:55 +0200
> Laurent Pinchart  escreveu:
> 
>> Hi Hans,
>>
>> On Wednesday, 7 November 2018 10:05:12 EET Hans Verkuil wrote:
>>> On 11/06/2018 08:58 PM, Laurent Pinchart wrote:  
 On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote:  
> On 11/06/18 14:12, Laurent Pinchart wrote:  
>> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote:  
>>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote:  
 Hi all,

 After the media summit (heavy on test discussions) and the V4L2 event
 regression we just found it is clear we need to do a better job with
 testing.

 All the pieces are in place, so what is needed is to combine it and
 create a script that anyone of us as core developers can run to check
 for regressions. The same script can be run as part of the kernelci
 regression testing.  
>>>
>>> I'd say that *some* pieces are in place. Of course, the more there is,
>>> the better.
>>>
>>> The more there are tests, the more important it would be they're
>>> automated, preferrably without the developer having to run them on his/
>>> her own machine.  
>>
>> From my experience with testing, it's important to have both a core set
>> of tests (a.k.a. smoke tests) that can easily be run on developers'
>> machines, and extended tests that can be offloaded to a shared testing
>> infrastructure (but possibly also run locally if desired).  
>
> That was my idea as well for the longer term. First step is to do the
> basic smoke tests (i.e. run compliance tests, do some (limited) streaming
> test).
>
> There are more extensive (and longer running) tests that can be done, but
> that's something to look at later.
>   
 We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last
 one is IMHO not quite good enough yet for testing: it is not fully
 compliant to the upcoming stateful codec spec. Work for that is
 planned as part of an Outreachy project.

 My idea is to create a script that is maintained as part of v4l-utils
 that loads the drivers and runs v4l2-compliance and possibly other
 tests against the virtual drivers.  
> 
> (adding Shuah)
> 
> IMO, the best would be to have something like that as part of Kernel
> self test, as this could give a broader covering than just Kernel CI.
> 

I agree with the broader coverage benefit that comes with adding tests to 
kselftest.
It makes it easier for making changes to tests/tools coupled with kernel/driver
changes. Common TAP13 reporting can be taken advantage of without doing any 
additional
work in the tests if author chooses to do so.

Tests can be added such that they don't get run by default if there is a reason 
do so
and Kernel CI and other rings can invoke it as a special case if necessary.

There are very clear advantages to making these tests part of the kernel source 
tree.
We can discuss at the Kernel Summit next week if you are interested.

thanks,
-- Shuah

Re: [PATCH] media: rc: self test for IR encoders and decoders

[Shuah Khan]

On 10/16/2018 08:09 AM, Sean Young wrote:
> ir-loopback can transmit IR on one rc device and check the correct
> scancode and protocol is decoded on a different rc device. This can be
> used to check IR transmission between two rc devices. Using rc-loopback,
> we use it to check the IR encoders and decoders themselves.
> 
> No hardware is required for this test.
> 
> Signed-off-by: Sean Young 
> Cc: Shuah Khan 

Hi Sean,

This looks good. I will get this into the next release. It will show
up in linux-kselftest next after 4.20-rc1 comes out.

thanks,
-- Shuah

Re: [PATCH 2/2] media: rc: self test for IR encoders and decoders

[Shuah Khan]

Hi Sean,

Thanks for the patch. I just happened to see this when Mauro sent it to me.
Doesn't look like linux-ksefltest and I weren't on the patch?

On 07/17/2018 03:33 PM, Sean Young (by way of Mauro Carvalho Chehab 
) wrote:
> ir-loopback can transmit IR on one rc device and check the correct
> scancode and protocol is decoded on a different rc device. This can be
> used to check IR transmission between two rc devices. Using rc-loopback,
> we use it to check the IR encoders and decoders themselves.
> 
> Signed-off-by: Sean Young 
> ---
>  tools/testing/selftests/Makefile  |   1 +
>  tools/testing/selftests/ir/.gitignore |   1 +
>  tools/testing/selftests/ir/Makefile   |  19 ++
>  tools/testing/selftests/ir/config |  12 ++
>  tools/testing/selftests/ir/ir-loopback.c  | 209 ++
>  tools/testing/selftests/ir/ir-loopback.sh |  28 +++
>  6 files changed, 270 insertions(+)
>  create mode 100644 tools/testing/selftests/ir/.gitignore
>  create mode 100644 tools/testing/selftests/ir/Makefile
>  create mode 100644 tools/testing/selftests/ir/config
>  create mode 100644 tools/testing/selftests/ir/ir-loopback.c
>  create mode 100755 tools/testing/selftests/ir/ir-loopback.sh

Why not add to the existing media directory? ../selftests/media_tests?

> 
> diff --git a/tools/testing/selftests/Makefile 
> b/tools/testing/selftests/Makefile
> index f1fe492c8e17..995034ea5546 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -15,6 +15,7 @@ TARGETS += futex
>  TARGETS += gpio
>  TARGETS += intel_pstate
>  TARGETS += ipc
> +TARGETS += ir

Does this test depend on any hardware being present in the system?

>  TARGETS += kcmp
>  TARGETS += kvm
>  TARGETS += lib
> diff --git a/tools/testing/selftests/ir/.gitignore 
> b/tools/testing/selftests/ir/.gitignore
> new file mode 100644
> index ..87bf2989b678
> --- /dev/null
> +++ b/tools/testing/selftests/ir/.gitignore
> @@ -0,0 +1 @@
> +ir-loopback
> diff --git a/tools/testing/selftests/ir/Makefile 
> b/tools/testing/selftests/ir/Makefile
> new file mode 100644
> index ..501b464e56b5
> --- /dev/null
> +++ b/tools/testing/selftests/ir/Makefile
> @@ -0,0 +1,19 @@
> +# SPDX-License-Identifier: GPL-2.0
> +uname_M := $(shell uname -m 2>/dev/null || echo not)
> +ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/i386/)
> +ifeq ($(ARCH),i386)
> +ARCH := x86
> + CFLAGS := -DCONFIG_X86_32 -D__i386__
> +endif
> +ifeq ($(ARCH),x86_64)
> + ARCH := x86
> + CFLAGS := -DCONFIG_X86_64 -D__x86_64__
> +endif
> +
> +CFLAGS += -I../../../../usr/include/
> +
> +TEST_PROGS := ir-loopback.sh
> +
> +TEST_GEN_PROGS := ir-loopback

Looks like ir-loopback get run from ir-loopback.sh. TEST_GEN_PROGS_EXTENDED
is the right variable to use in this case.

TEST_GEN_PROGS_EXTENDED := ir-loopback

> +
> +include ../lib.mk
> diff --git a/tools/testing/selftests/ir/config 
> b/tools/testing/selftests/ir/config
> new file mode 100644
> index ..78e041e9319e
> --- /dev/null
> +++ b/tools/testing/selftests/ir/config
> @@ -0,0 +1,12 @@
> +CONFIG_RC_CORE=y
> +CONFIG_RC_LOOPBACK=y
> +CONFIG_IR_NEC_DECODER=m
> +CONFIG_IR_RC5_DECODER=m
> +CONFIG_IR_RC6_DECODER=m
> +CONFIG_IR_JVC_DECODER=m
> +CONFIG_IR_SONY_DECODER=m
> +CONFIG_IR_SANYO_DECODER=m
> +CONFIG_IR_SHARP_DECODER=m
> +CONFIG_IR_MCE_KBD_DECODER=m
> +CONFIG_IR_XMP_DECODER=m
> +CONFIG_IR_IMON_DECODER=m
> diff --git a/tools/testing/selftests/ir/ir-loopback.c 
> b/tools/testing/selftests/ir/ir-loopback.c
> new file mode 100644
> index ..95b6f0f2f1f5
> --- /dev/null
> +++ b/tools/testing/selftests/ir/ir-loopback.c
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// test ir decoder
> +//
> +// Copyright (C) 2018 Sean Young 
> +
> +// When sending LIRC_MODE_SCANCODE, the IR will be encoded. rc-loopback
> +// will send this IR to the receiver side, where we try to read the decoded
> +// IR. Decoding happens in a separate kernel thread, so we will need to
> +// wait until that is scheduled, hence we use poll to check for read
> +// readiness.
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define TEST_SCANCODES   10
> +#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +
> +static const struct {
> + enum rc_proto proto;
> + const char *name;
> + unsigned int mask;
> + const char *decoder;
> +} protocols[] = {
> + { RC_PROTO_RC5, "rc-5", 0x1f7f, "rc-5" },
> + { RC_PROTO_RC5X_20, "rc-5x-20", 0x1f7f3f, "rc-5" },
> + { RC_PROTO_RC5_SZ, "rc-5-sz", 0x2fff, "rc-5-sz" },
> + { RC_PROTO_JVC, "jvc", 0x, "jvc" },
> + { RC_PROTO_SONY12, "sony-12", 0x1f007f, "sony" },
> + { RC_PROTO_SONY15, "sony-15", 0xff007f, "sony" },
> + { RC_PROTO_SONY20, "sony-20", 0x1fff7f, "sony" },
> + { RC_PROTO_NEC, "nec", 0x, "nec" },
> + { 

Re: [RFC] Make entity to interface links immutable

[Shuah Khan]

Hi Mauro and Hans,

On 07/02/2018 03:41 AM, Mauro Carvalho Chehab wrote:
> Em Mon, 2 Jul 2018 10:18:37 +0200
> Hans Verkuil  escreveu:
> 
>> While working on v4l2-compliance I noticed that entity to interface links
>> have just the MEDIA_LNK_FL_ENABLED flag set.
>>
>> Shouldn't we also set the MEDIA_LNK_FL_IMMUTABLE? After all, you cannot 
>> change
>> an entity-interface link. It feels inconsistent not to have this flag.
> 
> It could make sense for non-hybrid devices, but this may not be true
> for hybrid ones. See below.
> 
>> I also propose that media_create_intf_link() drops the last flags argument:
>> it can set the link flags directly since they are always the same anyway.
> 
> When we came with this design, the idea is that an interface can be 
> disabled/enabled at runtime, if the entity it links can't be used,
> because the hardware is busy doing something else. 
> 
> That could happen with hybrid devices, where the analog part could
> be consuming resources that would be needed for the digital part.
> 
> Disabling the link at runtime has an advantage that it makes easier
> to check - as open() syscalls could just use it to return -EBUSY,
> instead of doing a complete graph analysis. Also, applications can
> test it directly, in order to have a hint if a device is ready for
> usage.
> 
> That was one of the approaches we considered at the design, but I
> don't remember if Shuah's patch series actually used it or not,
> as I don't look at her pending patches for a long time. I suspect
> she took a different approach.
> 
> Anyway, before touching it, I'd like to see her patches merged,
> and do some tests with real case scenarios before changing it.
> 

I have been sidetracked by USB over IP security vulnerability reports
and fixing them since last November. Sorry for not picking this work
back up.

I am back from a week of vacation and I will dig my patches and respond
with details in a couple of days.

thanks for your patience,
-- Shuah

[PATCH v2] media: v4l2-core: v4l2-mc: Add SPDX license identifier

[Shuah Khan]

Replace GPL license statement with SPDX GPL-2.0 license identifier.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
Changes since v1:
- Fixed SPDX comment format
- Fixed SPDX license text to eliminate change in license. It now
  reads GPL-2.0-or-later to maintain the original.

 drivers/media/v4l2-core/v4l2-mc.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-mc.c 
b/drivers/media/v4l2-core/v4l2-mc.c
index 303980b71aae..8b61ccf3df81 100644
--- a/drivers/media/v4l2-core/v4l2-mc.c
+++ b/drivers/media/v4l2-core/v4l2-mc.c
@@ -1,3 +1,5 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
 /*
  * Media Controller ancillary functions
  *
@@ -5,16 +7,6 @@
  * Copyright (C) 2016 Shuah Khan <shua...@osg.samsung.com>
  * Copyright (C) 2006-2010 Nokia Corporation
  * Copyright (c) 2016 Intel Corporation.
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
  */
 
 #include 
-- 
2.14.1

Re: [PATCH] media: v4l2-core: v4l2-mc: Add SPDX license identifier

[Shuah Khan]

On 01/11/2018 02:33 PM, Laurent Pinchart wrote:
> Hi Shuah,
> 
> On Thursday, 11 January 2018 22:44:08 EET Shuah Khan wrote:
>> On 01/11/2018 11:42 AM, Laurent Pinchart wrote:
>>> On Thursday, 11 January 2018 17:45:15 EET Shuah Khan wrote:
>>>> On 01/11/2018 05:55 AM, Laurent Pinchart wrote:
>>>>> On Wednesday, 10 January 2018 18:35:36 EET Shuah Khan wrote:
>>>>>> Replace GPL license statement with SPDX GPL-2.0 license identifier.
>>>>>>
>>>>>> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
>>>>>> ---
>>>>>>
>>>>>>  drivers/media/v4l2-core/v4l2-mc.c | 11 +--
>>>>>>  1 file changed, 1 insertion(+), 10 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/media/v4l2-core/v4l2-mc.c
>>>>>> b/drivers/media/v4l2-core/v4l2-mc.c index 303980b71aae..1297132acd4e
>>>>>> 100644
>>>>>> --- a/drivers/media/v4l2-core/v4l2-mc.c
>>>>>> +++ b/drivers/media/v4l2-core/v4l2-mc.c
>>>>>> @@ -1,3 +1,4 @@
>>>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>>>
>>>>> The header doesn't match the existing license.
>>>>
>>>> When I added the file, I must have cut and pasted the license statement
>>>> from another file. More on this below the deleted license lines.
>>>>
>>>>> Furthermore, unless I'm mistaken, the standard comment style for SPDX
>>>>> headers in the kernel is //, not /* ... */
>>>>
>>>> Looks like we have 3 conventions for SPDX comment style.
>>>> /* ... */ for headers and # ... for shell scripts and
>>>> // for .c files.
>>>>
>>>> I can update it it and send v2 provided we think the change is inline
>>>> with the original license.
>>>
>>> Personally I prefer the /* ... */ comment style, but I noticed that Greg
>>> used // in his large patch the adds SPDX license headers, so I think we
>>> should follow the established practice. I'll let you investigate to find
>>> what is preferred :)
>>
>> Yeah /*...*/ is my preferred as well. Hence  the autopilot change I made
>> in the first place. I redid a couple of patches already to follow the
>> // convention and I can do the same here.
>>
>>>>>>  /*
>>>>>>  
>>>>>>   * Media Controller ancillary functions
>>>>>>   *
>>>>>>
>>>>>> @@ -5,16 +6,6 @@
>>>>>>
>>>>>>   * Copyright (C) 2016 Shuah Khan <shua...@osg.samsung.com>
>>>>>>   * Copyright (C) 2006-2010 Nokia Corporation
>>>>>>   * Copyright (c) 2016 Intel Corporation.
>>>>>>
>>>>>> - *
>>>>>> - *  This program is free software; you can redistribute it and/or
>>>>>> modify
>>>>>> - *  it under the terms of the GNU General Public License as published
>>>>>> by
>>>>>> - *  the Free Software Foundation; either version 2 of the License, or
>>>>>> - *  (at your option) any later version.
>>>>
>>>> Are you concerned about the "or (at your option) any later version." part
>>>> that it doesn't match?
>>>
>>> Yes, that's my concern. I'm personally fine with GPL-2.0-only, but you'll
>>> have a hard time contacting all the other copyright holders if you want
>>> to relicense this. Good luck getting hold of the appropriate legal
>>> department at Nokia :-)
>>
>> Yeah. I don't think it is beneficial to continue this effort. I am going to
>> not pursue the patch at this file. Thanks for the review.
> 
> How about just using
> 
> // SPDX-License-Identifier: GPL-2.0-or-later
> 
> ? That is equivalent to the current license text.
> 

Hmm. Yes GPL-2.0-or-later would maintain the intent and doesn't change
the license. I can send v2 with that and see anybody objects to it.

thanks,
-- Shuah

Re: [PATCH] media: v4l2-core: v4l2-mc: Add SPDX license identifier

[Shuah Khan]

On 01/11/2018 11:42 AM, Laurent Pinchart wrote:
> Hi Shuah,
> 
> On Thursday, 11 January 2018 17:45:15 EET Shuah Khan wrote:
>> On 01/11/2018 05:55 AM, Laurent Pinchart wrote:
>>> On Wednesday, 10 January 2018 18:35:36 EET Shuah Khan wrote:
>>>> Replace GPL license statement with SPDX GPL-2.0 license identifier.
>>>>
>>>> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
>>>> ---
>>>>
>>>>  drivers/media/v4l2-core/v4l2-mc.c | 11 +--
>>>>  1 file changed, 1 insertion(+), 10 deletions(-)
>>>>
>>>> diff --git a/drivers/media/v4l2-core/v4l2-mc.c
>>>> b/drivers/media/v4l2-core/v4l2-mc.c index 303980b71aae..1297132acd4e
>>>> 100644
>>>> --- a/drivers/media/v4l2-core/v4l2-mc.c
>>>> +++ b/drivers/media/v4l2-core/v4l2-mc.c
>>>> @@ -1,3 +1,4 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>
>>> The header doesn't match the existing license.
>>
>> When I added the file, I must have cut and pasted the license statement
>> from another file. More on this below the deleted license lines.
>>
>>> Furthermore, unless I'm mistaken, the standard comment style for SPDX
>>> headers in the kernel is //, not /* ... */
>>
>> Looks like we have 3 conventions for SPDX comment style.
>> /* ... */ for headers and # ... for shell scripts and
>> // for .c files.
>>
>> I can update it it and send v2 provided we think the change is inline
>> with the original license.
> 
> Personally I prefer the /* ... */ comment style, but I noticed that Greg used 
> // in his large patch the adds SPDX license headers, so I think we should 
> follow the established practice. I'll let you investigate to find what is 
> preferred :)

Yeah /*...*/ is my preferred as well. Hence  the autopilot change I made
in the first place. I redid a couple of patches already to follow the
// convention and I can do the same here.

> 
>>>>  /*
>>>>  
>>>>   * Media Controller ancillary functions
>>>>   *
>>>>
>>>> @@ -5,16 +6,6 @@
>>>>
>>>>   * Copyright (C) 2016 Shuah Khan <shua...@osg.samsung.com>
>>>>   * Copyright (C) 2006-2010 Nokia Corporation
>>>>   * Copyright (c) 2016 Intel Corporation.
>>>>
>>>> - *
>>>> - *  This program is free software; you can redistribute it and/or modify
>>>> - *  it under the terms of the GNU General Public License as published by
>>>> - *  the Free Software Foundation; either version 2 of the License, or
>>>> - *  (at your option) any later version.
>>
>> Are you concerned about the "or (at your option) any later version." part
>> that it doesn't match?
> 
> Yes, that's my concern. I'm personally fine with GPL-2.0-only, but you'll 
> have 
> a hard time contacting all the other copyright holders if you want to 
> relicense this. Good luck getting hold of the appropriate legal department at 
> Nokia :-)

Yeah. I don't think it is beneficial to continue this effort. I am going to not
pursue the patch at this file. Thanks for the review.

thanks,
-- Shuah

Re: [PATCH] media: v4l2-core: v4l2-mc: Add SPDX license identifier

[Shuah Khan]

On 01/11/2018 05:55 AM, Laurent Pinchart wrote:
> Hi Shuah,
> 
> Thank you for the patch.
> 
> On Wednesday, 10 January 2018 18:35:36 EET Shuah Khan wrote:
>> Replace GPL license statement with SPDX GPL-2.0 license identifier.
>>
>> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
>> ---
>>  drivers/media/v4l2-core/v4l2-mc.c | 11 +--
>>  1 file changed, 1 insertion(+), 10 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-mc.c
>> b/drivers/media/v4l2-core/v4l2-mc.c index 303980b71aae..1297132acd4e 100644
>> --- a/drivers/media/v4l2-core/v4l2-mc.c
>> +++ b/drivers/media/v4l2-core/v4l2-mc.c
>> @@ -1,3 +1,4 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
> 
> The header doesn't match the existing license.

When I added the file, I must have cut and pasted the license statement
from another file. More on this below the deleted license lines.

> 
> Furthermore, unless I'm mistaken, the standard comment style for SPDX headers 
> in the kernel is //, not /* ... */

Looks like we have 3 conventions for SPDX comment style.
/* ... */ for headers and # ... for shell scripts and
// for .c files.

I can update it it and send v2 provided we think the change is inline
with the original license.

> 
>>  /*
>>   * Media Controller ancillary functions
>>   *
>> @@ -5,16 +6,6 @@
>>   * Copyright (C) 2016 Shuah Khan <shua...@osg.samsung.com>
>>   * Copyright (C) 2006-2010 Nokia Corporation
>>   * Copyright (c) 2016 Intel Corporation.
>> - *
>> - *  This program is free software; you can redistribute it and/or modify
>> - *  it under the terms of the GNU General Public License as published by
>> - *  the Free Software Foundation; either version 2 of the License, or
>> - *  (at your option) any later version.

Are you concerned about the "or (at your option) any later version." part
that it doesn't match?

>> - *
>> - *  This program is distributed in the hope that it will be useful,
>> - *  but WITHOUT ANY WARRANTY; without even the implied warranty of
>> - *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> - *  GNU General Public License for more details.
>>   */
>>
>>  #include 
> 

thanks,
-- Shuah

[PATCH] media: v4l2-core: v4l2-mc: Add SPDX license identifier

[Shuah Khan]

Replace GPL license statement with SPDX GPL-2.0 license identifier.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
 drivers/media/v4l2-core/v4l2-mc.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-mc.c 
b/drivers/media/v4l2-core/v4l2-mc.c
index 303980b71aae..1297132acd4e 100644
--- a/drivers/media/v4l2-core/v4l2-mc.c
+++ b/drivers/media/v4l2-core/v4l2-mc.c
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Media Controller ancillary functions
  *
@@ -5,16 +6,6 @@
  * Copyright (C) 2016 Shuah Khan <shua...@osg.samsung.com>
  * Copyright (C) 2006-2010 Nokia Corporation
  * Copyright (c) 2016 Intel Corporation.
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License as published by
- *  the Free Software Foundation; either version 2 of the License, or
- *  (at your option) any later version.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
  */
 
 #include 
-- 
2.14.1

Re: [PATCH v2 1/2] media: exynos-gsc: fix lockdep warning

[Shuah Khan]

On 11/07/2017 09:53 AM, Shuah Khan wrote:
> On 10/16/2017 09:18 AM, Hans Verkuil wrote:
>> On 10/16/2017 05:16 PM, Shuah Khan wrote:
>>> The driver mmap functions shouldn't take lock when calling vb2_mmap().
>>> Fix it to not take the lock.
>>>
>>> Reference: commit log for f035eb4e976ef5a059e30bc91cfd310ff030a7d3
>>> and e752577ed7bf55c81e10343fced8b378cda2b63b
>>>
>>> The following lockdep warning is fixed with this change.
>>>
>>> [ 1990.972058] ==
>>> [ 1990.978172] WARNING: possible circular locking dependency detected
>>> [ 1990.984327] 4.14.0-rc2-2-gfab205f-dirty #4 Not tainted
>>> [ 1990.989783] --
>>> [ 1990.995937] qtdemux0:sink/2765 is trying to acquire lock:
>>> [ 1991.001309]  (>lock){+.+.}, at: [] gsc_m2m_mmap+0x24/0x5c 
>>> [exynos_gsc]
>>> [ 1991.009108]
>>>but task is already holding lock:
>>> [ 1991.014913]  (>mmap_sem){}, at: [] 
>>> vm_mmap_pgoff+0x44/0xb8
>>> [ 1991.021932]
>>>which lock already depends on the new lock.
>>>
>>> [ 1991.030078]
>>>the existing dependency chain (in reverse order) is:
>>> [ 1991.037530]
>>>-> #1 (>mmap_sem){}:
>>> [ 1991.042913]__might_fault+0x80/0xb0
>>> [ 1991.047096]video_usercopy+0x1cc/0x510 [videodev]
>>> [ 1991.052297]v4l2_ioctl+0xa4/0xdc [videodev]
>>> [ 1991.057036]do_vfs_ioctl+0xa0/0xa18
>>> [ 1991.061102]SyS_ioctl+0x34/0x5c
>>> [ 1991.064834]ret_fast_syscall+0x0/0x28
>>> [ 1991.069072]
>>>-> #0 (>lock){+.+.}:
>>> [ 1991.074193]lock_acquire+0x6c/0x88
>>> [ 1991.078179]__mutex_lock+0x68/0xa34
>>> [ 1991.082247]mutex_lock_interruptible_nested+0x1c/0x24
>>> [ 1991.087888]gsc_m2m_mmap+0x24/0x5c [exynos_gsc]
>>> [ 1991.093029]v4l2_mmap+0x54/0x88 [videodev]
>>> [ 1991.097673]mmap_region+0x3a8/0x638
>>> [ 1991.101743]do_mmap+0x330/0x3a4
>>> [ 1991.105470]vm_mmap_pgoff+0x90/0xb8
>>> [ 1991.109542]SyS_mmap_pgoff+0x90/0xc0
>>> [ 1991.113702]ret_fast_syscall+0x0/0x28
>>> [ 1991.117945]
>>>other info that might help us debug this:
>>>
>>> [ 1991.125918]  Possible unsafe locking scenario:
>>>
>>> [ 1991.131810]CPU0CPU1
>>> [ 1991.136315]
>>> [ 1991.140821]   lock(>mmap_sem);
>>> [ 1991.144201]lock(>lock);
>>> [ 1991.149833]lock(>mmap_sem);
>>> [ 1991.155725]   lock(>lock);
>>> [ 1991.158845]
>>> *** DEADLOCK ***
>>>
>>> [ 1991.164740] 1 lock held by qtdemux0:sink/2765:
>>> [ 1991.169157]  #0:  (>mmap_sem){}, at: [] 
>>> vm_mmap_pgoff+0x44/0xb8
>>> [ 1991.176609]
>>>stack backtrace:
>>> [ 1991.180946] CPU: 2 PID: 2765 Comm: qtdemux0:sink Not tainted 
>>> 4.14.0-rc2-2-gfab205f-dirty #4
>>> [ 1991.189608] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>> [ 1991.195686] [] (unwind_backtrace) from [] 
>>> (show_stack+0x10/0x14)
>>> [ 1991.203393] [] (show_stack) from [] 
>>> (dump_stack+0x98/0xc4)
>>> [ 1991.210586] [] (dump_stack) from [] 
>>> (print_circular_bug+0x254/0x410)
>>> [ 1991.218644] [] (print_circular_bug) from [] 
>>> (check_prev_add+0x468/0x938)
>>> [ 1991.227049] [] (check_prev_add) from [] 
>>> (__lock_acquire+0x1314/0x14fc)
>>> [ 1991.235281] [] (__lock_acquire) from [] 
>>> (lock_acquire+0x6c/0x88)
>>> [ 1991.242993] [] (lock_acquire) from [] 
>>> (__mutex_lock+0x68/0xa34)
>>> [ 1991.250620] [] (__mutex_lock) from [] 
>>> (mutex_lock_interruptible_nested+0x1c/0x24)
>>> [ 1991.259812] [] (mutex_lock_interruptible_nested) from 
>>> [] (gsc_m2m_mmap+0x24/0x5c [exynos_gsc])
>>> [ 1991.270159] [] (gsc_m2m_mmap [exynos_gsc]) from [] 
>>> (v4l2_mmap+0x54/0x88 [videodev])
>>> [ 1991.279510] [] (v4l2_mmap [videodev]) from [] 
>>> (mmap_region+0x3a8/0x638)
>>> [ 1991.287792] [] (mmap_region) from [] 
>>> (do_mmap+0x330/0x3a4)
>>> [ 1991.294986] [] (do_mmap) from [] 
>>> (vm_mmap_pgoff+0x90/0xb8)
>>> [ 1991.302178] [] (vm_mmap_pgoff) from [] 
>>> (SyS_mmap_pgoff+0x90/0xc0)
>>> [ 1991.309977] [] (SyS_mmap_pgoff) from [] 
>>> (ret_fast_syscall+0x0/0x28)
>>>
>>> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
>>> Suggested-by: Hans Verkuil <hansv...@cisco.com>
>>> Acked-by: Marek Szyprowski <m.szyprow...@samsung.com>
>>
>> Acked-by: Hans Verkuil <hansv...@cisco.com>
>>
>> Regards,
>>
>>  Hans
> 
> Hi Mauro,
> 
> Are you planning to take this in for 4.15-rc1? This patch is applicable
> to stable as well.
> 
> thanks,
> -- Shuah
> 

Hi Mauro,

Doesn't look like this fox made it into 4.15-rc2 - do you plan to get this
into 4.15 at some point?

I am seeing this lockdep warning in 4.15-rc2

thanks,
-- Shuah

Re: [PATCH v2 1/2] media: exynos-gsc: fix lockdep warning

[Shuah Khan]

On 10/16/2017 09:18 AM, Hans Verkuil wrote:
> On 10/16/2017 05:16 PM, Shuah Khan wrote:
>> The driver mmap functions shouldn't take lock when calling vb2_mmap().
>> Fix it to not take the lock.
>>
>> Reference: commit log for f035eb4e976ef5a059e30bc91cfd310ff030a7d3
>> and e752577ed7bf55c81e10343fced8b378cda2b63b
>>
>> The following lockdep warning is fixed with this change.
>>
>> [ 1990.972058] ==
>> [ 1990.978172] WARNING: possible circular locking dependency detected
>> [ 1990.984327] 4.14.0-rc2-2-gfab205f-dirty #4 Not tainted
>> [ 1990.989783] --
>> [ 1990.995937] qtdemux0:sink/2765 is trying to acquire lock:
>> [ 1991.001309]  (>lock){+.+.}, at: [] gsc_m2m_mmap+0x24/0x5c 
>> [exynos_gsc]
>> [ 1991.009108]
>>but task is already holding lock:
>> [ 1991.014913]  (>mmap_sem){}, at: [] 
>> vm_mmap_pgoff+0x44/0xb8
>> [ 1991.021932]
>>which lock already depends on the new lock.
>>
>> [ 1991.030078]
>>the existing dependency chain (in reverse order) is:
>> [ 1991.037530]
>>-> #1 (>mmap_sem){}:
>> [ 1991.042913]__might_fault+0x80/0xb0
>> [ 1991.047096]video_usercopy+0x1cc/0x510 [videodev]
>> [ 1991.052297]v4l2_ioctl+0xa4/0xdc [videodev]
>> [ 1991.057036]do_vfs_ioctl+0xa0/0xa18
>> [ 1991.061102]SyS_ioctl+0x34/0x5c
>> [ 1991.064834]ret_fast_syscall+0x0/0x28
>> [ 1991.069072]
>>-> #0 (>lock){+.+.}:
>> [ 1991.074193]lock_acquire+0x6c/0x88
>> [ 1991.078179]__mutex_lock+0x68/0xa34
>> [ 1991.082247]mutex_lock_interruptible_nested+0x1c/0x24
>> [ 1991.087888]gsc_m2m_mmap+0x24/0x5c [exynos_gsc]
>> [ 1991.093029]v4l2_mmap+0x54/0x88 [videodev]
>> [ 1991.097673]mmap_region+0x3a8/0x638
>> [ 1991.101743]do_mmap+0x330/0x3a4
>> [ 1991.105470]vm_mmap_pgoff+0x90/0xb8
>> [ 1991.109542]SyS_mmap_pgoff+0x90/0xc0
>> [ 1991.113702]ret_fast_syscall+0x0/0x28
>> [ 1991.117945]
>>other info that might help us debug this:
>>
>> [ 1991.125918]  Possible unsafe locking scenario:
>>
>> [ 1991.131810]CPU0CPU1
>> [ 1991.136315]
>> [ 1991.140821]   lock(>mmap_sem);
>> [ 1991.144201]lock(>lock);
>> [ 1991.149833]lock(>mmap_sem);
>> [ 1991.155725]   lock(>lock);
>> [ 1991.158845]
>> *** DEADLOCK ***
>>
>> [ 1991.164740] 1 lock held by qtdemux0:sink/2765:
>> [ 1991.169157]  #0:  (>mmap_sem){}, at: [] 
>> vm_mmap_pgoff+0x44/0xb8
>> [ 1991.176609]
>>stack backtrace:
>> [ 1991.180946] CPU: 2 PID: 2765 Comm: qtdemux0:sink Not tainted 
>> 4.14.0-rc2-2-gfab205f-dirty #4
>> [ 1991.189608] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [ 1991.195686] [] (unwind_backtrace) from [] 
>> (show_stack+0x10/0x14)
>> [ 1991.203393] [] (show_stack) from [] 
>> (dump_stack+0x98/0xc4)
>> [ 1991.210586] [] (dump_stack) from [] 
>> (print_circular_bug+0x254/0x410)
>> [ 1991.218644] [] (print_circular_bug) from [] 
>> (check_prev_add+0x468/0x938)
>> [ 1991.227049] [] (check_prev_add) from [] 
>> (__lock_acquire+0x1314/0x14fc)
>> [ 1991.235281] [] (__lock_acquire) from [] 
>> (lock_acquire+0x6c/0x88)
>> [ 1991.242993] [] (lock_acquire) from [] 
>> (__mutex_lock+0x68/0xa34)
>> [ 1991.250620] [] (__mutex_lock) from [] 
>> (mutex_lock_interruptible_nested+0x1c/0x24)
>> [ 1991.259812] [] (mutex_lock_interruptible_nested) from 
>> [] (gsc_m2m_mmap+0x24/0x5c [exynos_gsc])
>> [ 1991.270159] [] (gsc_m2m_mmap [exynos_gsc]) from [] 
>> (v4l2_mmap+0x54/0x88 [videodev])
>> [ 1991.279510] [] (v4l2_mmap [videodev]) from [] 
>> (mmap_region+0x3a8/0x638)
>> [ 1991.287792] [] (mmap_region) from [] 
>> (do_mmap+0x330/0x3a4)
>> [ 1991.294986] [] (do_mmap) from [] 
>> (vm_mmap_pgoff+0x90/0xb8)
>> [ 1991.302178] [] (vm_mmap_pgoff) from [] 
>> (SyS_mmap_pgoff+0x90/0xc0)
>> [ 1991.309977] [] (SyS_mmap_pgoff) from [] 
>> (ret_fast_syscall+0x0/0x28)
>>
>> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
>> Suggested-by: Hans Verkuil <hansv...@cisco.com>
>> Acked-by: Marek Szyprowski <m.szyprow...@samsung.com>
> 
> Acked-by: Hans Verkuil <hansv...@cisco.com>
> 
> Regards,
> 
>   Hans

Hi Mauro,

Are you planning to take this in for 4.15-rc1? This patch is applicable
to stable as well.

thanks,
-- Shuah

[PATCH v2 2/2] media: s5p-mfc: fix lock confection - request_firmware() once and keep state

[Shuah Khan]

Driver calls request_firmware() whenever the device is opened for the
first time. As the device gets opened and closed, dev->num_inst == 1
is true several times. This is not necessary since the firmware is saved
in the fw_buf. s5p_mfc_load_firmware() copies the buffer returned by
the request_firmware() to dev->fw_buf.

fw_buf sticks around until it gets released from s5p_mfc_remove(), hence
there is no need to keep requesting firmware and copying it to fw_buf.

This might have been overlooked when changes are made to free fw_buf from
the device release interface s5p_mfc_release().

Fix s5p_mfc_load_firmware() to call request_firmware() once and keep state.
Change _probe() to load firmware once fw_buf has been allocated.

s5p_mfc_open() and it continues to call s5p_mfc_load_firmware() and init
hardware which is the step where firmware is written to the device.

This addresses the mfc_mutex contention due to repeated request_firmware()
calls from open() in the following circular locking warning:

[  552.194115] qtdemux0:sink/2710 is trying to acquire lock:
[  552.199488]  (>mfc_mutex){+.+.}, at: [] 
s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[  552.207459]
   but task is already holding lock:
[  552.213264]  (>mmap_sem){}, at: [] vm_mmap_pgoff+0x44/0xb8
[  552.220284]
   which lock already depends on the new lock.

[  552.228429]
   the existing dependency chain (in reverse order) is:
[  552.235881]
   -> #2 (>mmap_sem){}:
[  552.241259]__might_fault+0x80/0xb0
[  552.245331]filldir64+0xc0/0x2f8
[  552.249144]call_filldir+0xb0/0x14c
[  552.253214]ext4_readdir+0x768/0x90c
[  552.257374]iterate_dir+0x74/0x168
[  552.261360]SyS_getdents64+0x7c/0x1a0
[  552.265608]ret_fast_syscall+0x0/0x28
[  552.269850]
   -> #1 (>i_mutex_dir_key#2){}:
[  552.276180]down_read+0x48/0x90
[  552.279904]lookup_slow+0x74/0x178
[  552.283889]walk_component+0x1a4/0x2e4
[  552.288222]link_path_walk+0x174/0x4a0
[  552.292555]path_openat+0x68/0x944
[  552.296541]do_filp_open+0x60/0xc4
[  552.300528]file_open_name+0xe4/0x114
[  552.304772]filp_open+0x28/0x48
[  552.308499]kernel_read_file_from_path+0x30/0x78
[  552.313700]_request_firmware+0x3ec/0x78c
[  552.318291]request_firmware+0x3c/0x54
[  552.322642]s5p_mfc_load_firmware+0x54/0x150 [s5p_mfc]
[  552.328358]s5p_mfc_open+0x4e4/0x550 [s5p_mfc]
[  552.94]v4l2_open+0xa0/0x104 [videodev]
[  552.338137]chrdev_open+0xa4/0x18c
[  552.342121]do_dentry_open+0x208/0x310
[  552.346454]path_openat+0x28c/0x944
[  552.350526]do_filp_open+0x60/0xc4
[  552.354512]do_sys_open+0x118/0x1c8
[  552.358586]ret_fast_syscall+0x0/0x28
[  552.362830]
   -> #0 (>mfc_mutex){+.+.}:
   -> #0 (>mfc_mutex){+.+.}:
[  552.368379]lock_acquire+0x6c/0x88
[  552.372364]__mutex_lock+0x68/0xa34
[  552.376437]mutex_lock_interruptible_nested+0x1c/0x24
[  552.382086]s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[  552.386939]v4l2_mmap+0x54/0x88 [videodev]
[  552.391601]mmap_region+0x3a8/0x638
[  552.395673]do_mmap+0x330/0x3a4
[  552.399400]vm_mmap_pgoff+0x90/0xb8
[  552.403472]SyS_mmap_pgoff+0x90/0xc0
[  552.407632]ret_fast_syscall+0x0/0x28
[  552.411876]
   other info that might help us debug this:

[  552.419848] Chain exists of:
 >mfc_mutex --> >i_mutex_dir_key#2 --> >mmap_sem

[  552.431200]  Possible unsafe locking scenario:

[  552.437092]CPU0CPU1
[  552.441598]
[  552.446104]   lock(>mmap_sem);
[  552.449484]lock(>i_mutex_dir_key#2);
[  552.456329]lock(>mmap_sem);
[  552.46]   lock(>mfc_mutex);
[  552.465775]
*** DEADLOCK ***

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 6 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 3 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 5 +
 3 files changed, 14 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 5cf50b3..7b9a322 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1311,6 +1311,12 @@ static int s5p_mfc_probe(struct platform_device *pdev)
goto err_dma;
}
 
+   /*
+* Load fails if fs isn't mounted. Try loading anyway.
+* _open() will load it, it it fails now. Ignore failure.
+*/
+   s5p_mfc_load_firmware(dev);
+
mutex_init(>mfc_mutex);
init_waitqueue_head(>queue);
dev->hw_lock = 0;

[PATCH v2 1/2] media: s5p-mfc: remove firmware buf null check in s5p_mfc_load_firmware()

[Shuah Khan]

s5p_mfc_load_firmware() will not get called if fw_buf.virt allocation
fails. The allocation happens very early on in the probe routine and
probe fails if allocation fails.

There is no need to check if it is null in s5p_mfc_load_firmware().
Remove the check.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 69ef9c2..46c9d67 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -75,11 +75,6 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
release_firmware(fw_blob);
return -ENOMEM;
}
-   if (!dev->fw_buf.virt) {
-   mfc_err("MFC firmware is not allocated\n");
-   release_firmware(fw_blob);
-   return -EINVAL;
-   }
memcpy(dev->fw_buf.virt, fw_blob->data, fw_blob->size);
wmb();
release_firmware(fw_blob);
-- 
2.7.4

[PATCH v2 0/2] Fix s5p-mfc lock contention in request firmware paths

[Shuah Khan]

This patch series fixes inefficiencies and lock contention in the request
firmware paths.

Changes since v2:
- Addressed Andre's review comments. Removed fw_buf->virt null check
  as it is not needed. Removed handling s5p_mfc_load_firmware() from
  probe routine. Simply try loading in case it works.

Shuah Khan (2):
  media: s5p-mfc: remove firmware buf null check in
s5p_mfc_load_firmware()
  media: s5p-mfc: fix lock confection - request_firmware() once and keep
state

 drivers/media/platform/s5p-mfc/s5p_mfc.c|  6 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  3 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 10 +-
 3 files changed, 14 insertions(+), 5 deletions(-)

-- 
2.7.4

Re: [PATCH 2/2] media: s5p-mfc: fix lock confection - request_firmware() once and keep state

[Shuah Khan]

On 11/02/2017 06:43 PM, Marian Mihailescu wrote:
> I can confirm, with this patch, there is always error loading MFC in
> boot log, since FS is not mounted.
> 
> -Marian
> 

Please refrain from top posting to a kernel email threads. It is very difficult
to follow. Bottom post is the norm.

thanks,
-- Shuah 

Re: [PATCH 2/2] media: s5p-mfc: fix lock confection - request_firmware() once and keep state

[Shuah Khan]

On 11/02/2017 02:31 AM, Andrzej Hajda wrote:
> On 06.10.2017 23:30, Shuah Khan wrote:
>> Driver calls request_firmware() whenever the device is opened for the
>> first time. As the device gets opened and closed, dev->num_inst == 1
>> is true several times. This is not necessary since the firmware is saved
>> in the fw_buf. s5p_mfc_load_firmware() copies the buffer returned by
>> the request_firmware() to dev->fw_buf.
>>
>> fw_buf sticks around until it gets released from s5p_mfc_remove(), hence
>> there is no need to keep requesting firmware and copying it to fw_buf.
>>
>> This might have been overlooked when changes are made to free fw_buf from
>> the device release interface s5p_mfc_release().
>>
>> Fix s5p_mfc_load_firmware() to call request_firmware() once and keep state.
>> Change _probe() to load firmware once fw_buf has been allocated.
>>
>> s5p_mfc_open() and it continues to call s5p_mfc_load_firmware() and init
>> hardware which is the step where firmware is written to the device.
>>
>> This addresses the mfc_mutex contention due to repeated request_firmware()
>> calls from open() in the following circular locking warning:
>>
>> [  552.194115] qtdemux0:sink/2710 is trying to acquire lock:
>> [  552.199488]  (>mfc_mutex){+.+.}, at: [] 
>> s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
>> [  552.207459]
>>but task is already holding lock:
>> [  552.213264]  (>mmap_sem){}, at: [] 
>> vm_mmap_pgoff+0x44/0xb8
>> [  552.220284]
>>which lock already depends on the new lock.
>>
>> [  552.228429]
>>the existing dependency chain (in reverse order) is:
>> [  552.235881]
>>-> #2 (>mmap_sem){}:
>> [  552.241259]__might_fault+0x80/0xb0
>> [  552.245331]filldir64+0xc0/0x2f8
>> [  552.249144]call_filldir+0xb0/0x14c
>> [  552.253214]ext4_readdir+0x768/0x90c
>> [  552.257374]iterate_dir+0x74/0x168
>> [  552.261360]SyS_getdents64+0x7c/0x1a0
>> [  552.265608]ret_fast_syscall+0x0/0x28
>> [  552.269850]
>>-> #1 (>i_mutex_dir_key#2){}:
>> [  552.276180]down_read+0x48/0x90
>> [  552.279904]lookup_slow+0x74/0x178
>> [  552.283889]walk_component+0x1a4/0x2e4
>> [  552.288222]link_path_walk+0x174/0x4a0
>> [  552.292555]path_openat+0x68/0x944
>> [  552.296541]do_filp_open+0x60/0xc4
>> [  552.300528]file_open_name+0xe4/0x114
>> [  552.304772]filp_open+0x28/0x48
>> [  552.308499]kernel_read_file_from_path+0x30/0x78
>> [  552.313700]_request_firmware+0x3ec/0x78c
>> [  552.318291]request_firmware+0x3c/0x54
>> [  552.322642]s5p_mfc_load_firmware+0x54/0x150 [s5p_mfc]
>> [  552.328358]s5p_mfc_open+0x4e4/0x550 [s5p_mfc]
>> [  552.94]v4l2_open+0xa0/0x104 [videodev]
>> [  552.338137]chrdev_open+0xa4/0x18c
>> [  552.342121]do_dentry_open+0x208/0x310
>> [  552.346454]path_openat+0x28c/0x944
>> [  552.350526]do_filp_open+0x60/0xc4
>> [  552.354512]do_sys_open+0x118/0x1c8
>> [  552.358586]ret_fast_syscall+0x0/0x28
>> [  552.362830]
>>-> #0 (>mfc_mutex){+.+.}:
>>-> #0 (>mfc_mutex){+.+.}:
>> [  552.368379]lock_acquire+0x6c/0x88
>> [  552.372364]__mutex_lock+0x68/0xa34
>> [  552.376437]mutex_lock_interruptible_nested+0x1c/0x24
>> [  552.382086]s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
>> [  552.386939]v4l2_mmap+0x54/0x88 [videodev]
>> [  552.391601]mmap_region+0x3a8/0x638
>> [  552.395673]do_mmap+0x330/0x3a4
>> [  552.399400]vm_mmap_pgoff+0x90/0xb8
>> [  552.403472]SyS_mmap_pgoff+0x90/0xc0
>> [  552.407632]ret_fast_syscall+0x0/0x28
>> [  552.411876]
>>other info that might help us debug this:
>>
>> [  552.419848] Chain exists of:
>>  >mfc_mutex --> >i_mutex_dir_key#2 --> 
>> >mmap_sem
>>
>> [  552.431200]  Possible unsafe locking scenario:
>>
>> [  552.437092]CPU0CPU1
>> [  552.441598]
>> [  552.446104]   lock(>mmap_sem);
>> [  552.449484]lock(>i_mutex_dir_key#2);
>> [  552.456329]lock(>mmap_sem);
>> [  552.46]   lock(>mfc_mutex);
>> [  552.465775]
>>

Re: [PATCH 1/2] media: s5p-mfc: check for firmware allocation before requesting firmware

[Shuah Khan]

On 11/02/2017 02:12 AM, Andrzej Hajda wrote:
> Hi Shuah,
> 
> On 06.10.2017 23:30, Shuah Khan wrote:
>> Check if firmware is allocated before requesting firmware instead of
>> requesting firmware only to release it if firmware is not allocated.
>>
>> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
>> ---
>>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
>> b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
>> index 69ef9c2..f064a0d1 100644
>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
>> @@ -55,6 +55,11 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
>>   * into kernel. */
>>  mfc_debug_enter();
>>  
>> +if (!dev->fw_buf.virt) {
>> +mfc_err("MFC firmware is not allocated\n");
>> +return -EINVAL;
>> +}
>> +
>>  for (i = MFC_FW_MAX_VERSIONS - 1; i >= 0; i--) {
>>  if (!dev->variant->fw_name[i])
>>  continue;
>> @@ -75,11 +80,6 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
>>  release_firmware(fw_blob);
>>  return -ENOMEM;
>>  }
>> -if (!dev->fw_buf.virt) {
>> -mfc_err("MFC firmware is not allocated\n");
>> -release_firmware(fw_blob);
>> -return -EINVAL;
>> -}
> 
> Is there any scenario in which dev->fw_buf.virt is null and
> s5p_mfc_load_firmware is called?
> I suspect this check is not necessary at all.
> 

I don't believe so. Allocation is done in s5p_mfc_configure_dma_memory()
code path and if that fails it bails out of _probe. I can remove the check
all together.

thanks,
-- Shuah

Re: [PATCH 0/2] Fix s5p-mfc lock contention in request firmware paths

[Shuah Khan]

On 10/25/2017 04:28 PM, Marian Mihailescu wrote:
> Hi Shuah,
> 
> For MFC patch, you can delete the "dev" variable since it's not being
> used anymore and results in a compile warning.
> 
> - struct s5p_mfc_dev *dev = ctx->dev;
> 

Hi Marian,

This series doesn't have the unused warn problem. I fixed the problem
in media: s5p-mfc: fix lockdep warning patch that has the warning and
sent v2.


> On Thu, Oct 26, 2017 at 7:54 AM, Shuah Khan <shua...@osg.samsung.com> wrote:
>> On 10/06/2017 03:30 PM, Shuah Khan wrote:
>>> This patch series fixes inefficiencies and lock contention in the request
>>> firmware paths.
>>>
>>> Shuah Khan (2):
>>>   media: s5p-mfc: check for firmware allocation before requesting
>>> firmware
>>>   media: s5p-mfc: fix lock confection - request_firmware() once and keep
>>> state
>>>
>>>  drivers/media/platform/s5p-mfc/s5p_mfc.c|  4 
>>>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  3 +++
>>>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 15 ++-
>>>  3 files changed, 17 insertions(+), 5 deletions(-)
>>>
>>
>> Any feedback on this series?
>>

Still waiting for feedback on this series.

thanks,
-- Shuah

[PATCH v2] media: s5p-mfc: fix lockdep warning

[Shuah Khan]

The driver mmap functions shouldn't take lock when calling vb2_mmap().
Fix it to not take the lock. The following lockdep warning is fixed
with this change.

[ 2106.181412] ==
[ 2106.187563] WARNING: possible circular locking dependency detected
[ 2106.193718] 4.14.0-rc2-2-gfab205f-dirty #4 Not tainted
[ 2106.199175] --
[ 2106.205328] qtdemux0:sink/2614 is trying to acquire lock:
[ 2106.210701]  (>mfc_mutex){+.+.}, at: [] 
s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[ 2106.218672]
[ 2106.218672] but task is already holding lock:
[ 2106.224477]  (>mmap_sem){}, at: [] vm_mmap_pgoff+0x44/0xb8
[ 2106.231497]
[ 2106.231497] which lock already depends on the new lock.
[ 2106.231497]
[ 2106.239642]
[ 2106.239642] the existing dependency chain (in reverse order) is:
[ 2106.247095]
[ 2106.247095] -> #1 (>mmap_sem){}:
[ 2106.252473]__might_fault+0x80/0xb0
[ 2106.256567]video_usercopy+0x1cc/0x510 [videodev]
[ 2106.261845]v4l2_ioctl+0xa4/0xdc [videodev]
[ 2106.266596]do_vfs_ioctl+0xa0/0xa18
[ 2106.270667]SyS_ioctl+0x34/0x5c
[ 2106.274395]ret_fast_syscall+0x0/0x28
[ 2106.278637]
[ 2106.278637] -> #0 (>mfc_mutex){+.+.}:
[ 2106.284186]lock_acquire+0x6c/0x88
[ 2106.288173]__mutex_lock+0x68/0xa34
[ 2106.292244]mutex_lock_interruptible_nested+0x1c/0x24
[ 2106.297893]s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[ 2106.302747]v4l2_mmap+0x54/0x88 [videodev]
[ 2106.307409]mmap_region+0x3a8/0x638
[ 2106.311480]do_mmap+0x330/0x3a4
[ 2106.315207]vm_mmap_pgoff+0x90/0xb8
[ 2106.319279]SyS_mmap_pgoff+0x90/0xc0
[ 2106.323439]ret_fast_syscall+0x0/0x28
[ 2106.327683]
[ 2106.327683] other info that might help us debug this:
[ 2106.327683]
[ 2106.335656]  Possible unsafe locking scenario:
[ 2106.335656]
[ 2106.341548]CPU0CPU1
[ 2106.346053]
[ 2106.350559]   lock(>mmap_sem);
[ 2106.353939]lock(>mfc_mutex);
[ 2106.353939]lock(>mfc_mutex);
[ 2106.365897]   lock(>mfc_mutex);
[ 2106.369450]
[ 2106.369450]  *** DEADLOCK ***
[ 2106.369450]
[ 2106.375344] 1 lock held by qtdemux0:sink/2614:
[ 2106.379762]  #0:  (>mmap_sem){}, at: [] 
vm_mmap_pgoff+0x44/0xb8
[ 2106.387214]
[ 2106.387214] stack backtrace:
[ 2106.391550] CPU: 7 PID: 2614 Comm: qtdemux0:sink Not tainted 
4.14.0-rc2-2-gfab205f-dirty #4
[ 2106.400213] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 2106.406285] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[ 2106.413995] [] (show_stack) from [] 
(dump_stack+0x98/0xc4)
[ 2106.421187] [] (dump_stack) from [] 
(print_circular_bug+0x254/0x410)
[ 2106.429245] [] (print_circular_bug) from [] 
(check_prev_add+0x468/0x938)
[ 2106.437651] [] (check_prev_add) from [] 
(__lock_acquire+0x1314/0x14fc)
[ 2106.445883] [] (__lock_acquire) from [] 
(lock_acquire+0x6c/0x88)
[ 2106.453596] [] (lock_acquire) from [] 
(__mutex_lock+0x68/0xa34)
[ 2106.461221] [] (__mutex_lock) from [] 
(mutex_lock_interruptible_nested+0x1c/0x24)
[ 2106.470425] [] (mutex_lock_interruptible_nested) from [] 
(s5p_mfc_mmap+0x28/0xd4 [s5p_mfc])
[ 2106.480494] [] (s5p_mfc_mmap [s5p_mfc]) from [] 
(v4l2_mmap+0x54/0x88 [videodev])
[ 2106.489575] [] (v4l2_mmap [videodev]) from [] 
(mmap_region+0x3a8/0x638)
[ 2106.497875] [] (mmap_region) from [] 
(do_mmap+0x330/0x3a4)
[ 2106.505068] [] (do_mmap) from [] 
(vm_mmap_pgoff+0x90/0xb8)
[ 2106.512260] [] (vm_mmap_pgoff) from [] 
(SyS_mmap_pgoff+0x90/0xc0)
[ 2106.520059] [] (SyS_mmap_pgoff) from [] 
(ret_fast_syscall+0x0/0x28)

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
Suggested-by: Hans Verkuil <hansv...@cisco.com>
Acked-by: Marek Szyprowski <m.szyprow...@samsung.com>
Acked-by: Hans Verkuil <hansv...@cisco.com>
---

Changes since v1:
- Fixed unused warning. Added Han's Ack

 drivers/media/platform/s5p-mfc/s5p_mfc.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 4c253fb..3611016 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1043,12 +1043,9 @@ static unsigned int s5p_mfc_poll(struct file *file,
 static int s5p_mfc_mmap(struct file *file, struct vm_area_struct *vma)
 {
struct s5p_mfc_ctx *ctx = fh_to_ctx(file->private_data);
-   struct s5p_mfc_dev *dev = ctx->dev;
unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
int ret;
 
-   if (mutex_lock_interruptible(>mfc_mutex))
-   return -ERESTARTSYS;
if (offset < DST_QUEUE_OFF_BASE) {
mfc_debug(2, "mmaping source\n");
ret = vb2_mmap(>vq_src, vma);
@@ -1057,7 +1054,6 @@ static int

Re: [PATCH 0/2] Fix s5p-mfc lock contention in request firmware paths

[Shuah Khan]

On 10/25/2017 04:28 PM, Marian Mihailescu wrote:
> Hi Shuah,
> 
> For MFC patch, you can delete the "dev" variable since it's not being
> used anymore and results in a compile warning.
> 
> - struct s5p_mfc_dev *dev = ctx->dev;
> 
> Cheers,
> Marian

Oops. I thought I handled that. I will fix that and resend the patch.

thanks,
-- Shuah

Re: [PATCH 0/2] Fix s5p-mfc lock contention in request firmware paths

[Shuah Khan]

On 10/06/2017 03:30 PM, Shuah Khan wrote:
> This patch series fixes inefficiencies and lock contention in the request
> firmware paths.
> 
> Shuah Khan (2):
>   media: s5p-mfc: check for firmware allocation before requesting
> firmware
>   media: s5p-mfc: fix lock confection - request_firmware() once and keep
> state
> 
>  drivers/media/platform/s5p-mfc/s5p_mfc.c|  4 
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  3 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 15 ++-
>  3 files changed, 17 insertions(+), 5 deletions(-)
> 

Any feedback on this series?

thanks,
-- Shuah

Re: Exynos MFC issues on 4.14-rc4

[Shuah Khan]

On Mon, Oct 16, 2017 at 7:11 AM, Marek Szyprowski
 wrote:
> Hi Marian,
>
> On 2017-10-12 02:49, Marian Mihailescu wrote:
>>
>> I've been testing 4.14-rc4 on Odroid-XU4, and here's a kernel
>> complaint when running:
>>
>> gst-launch-1.0 filesrc location=bunny_trailer_1080p.mov ! parsebin !
>> v4l2video4dec capture-io-mode=dmabuf ! v4l2video6convert
>> output-io-mode=dmabuf-import capture-io-mode=dmabuf ! kmssink
>>
>> http://paste.debian.net/990353/
>
>
> This is rather harmless and it happens on v4.14-rcX, because LOCKDEP has
> been enabled by default in the exynos_defconfig. For more information
> see https://lkml.org/lkml/2017/10/13/974
>
>> PS: on kernel 4.9 patched with MFC & GSC updates (almost up to date
>> with 4.14 I think) there was no "Wrong buffer/video queue type (1)"
>> message either
>
>
> I will check it and let you know if this is something we should worry about.

I am seeing this messages. It appears to be harmless. However, it
would be good to look into this. It doesn't appear to cause any
problems for capture/output.

thanks,
-- Shuah

Re: [PATCH 0/2] fix lockdep warnings in s5p_mfc and exynos-gsc vb2 drivers

[Shuah Khan]

Hi Marek,

On 10/16/2017 06:48 AM, Marek Szyprowski wrote:
> Hi Shuah,
> 
> On 2017-10-14 01:13, Shuah Khan wrote:
>> Driver mmap functions shouldn't hold lock when calling vb2_mmap(). The
>> vb2_mmap() function has its own lock that it uses to protect the critical
>> section.
>>
>> Reference: commit log for f035eb4e976ef5a059e30bc91cfd310ff030a7d3
> 
> It would make sense to add the information about the reference commit to each
> commit message and also point to commit 
> e752577ed7bf55c81e10343fced8b378cda2b63b,
> as it is exactly the same case here. Anyway:

I think It does make sense to add the commit information to each commit message.
I can do that send v2.

> 
> Acked-by: Marek Szyprowski <m.szyprow...@samsung.com>

Thanks.

> 
> I wonder if makes sense to send those patches also to sta...@vget.kernel.org
> (maybe v4.3+, like the mentioned above commit, if they really apply?).

I don't believe they will apply as is. I can work back-porting once these get 
into
the mainline.

> 
>> Shuah Khan (2):
>>media: exynos-gsc: fix lockdep warning
>>media: s5p-mfc: fix lockdep warning
>>
>>   drivers/media/platform/exynos-gsc/gsc-m2m.c | 5 -
>>   drivers/media/platform/s5p-mfc/s5p_mfc.c| 3 ---
>>   2 files changed, 8 deletions(-)
>>
> 
> Best regards

thanks,
-- Shuah

[PATCH 0/2] fix lockdep warnings in s5p_mfc and exynos-gsc vb2 drivers

[Shuah Khan]

Driver mmap functions shouldn't hold lock when calling vb2_mmap(). The
vb2_mmap() function has its own lock that it uses to protect the critical
section.

Reference: commit log for f035eb4e976ef5a059e30bc91cfd310ff030a7d3

Shuah Khan (2):
  media: exynos-gsc: fix lockdep warning
  media: s5p-mfc: fix lockdep warning

 drivers/media/platform/exynos-gsc/gsc-m2m.c | 5 -
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 3 ---
 2 files changed, 8 deletions(-)

-- 
2.7.4

[PATCH 1/2] media: exynos-gsc: fix lockdep warning

[Shuah Khan]

The driver mmap functions shouldn't take lock when calling vb2_mmap().
Fix it to not take the lock. The following lockdep warning is fixed
with this change.

[ 1990.972058] ==
[ 1990.978172] WARNING: possible circular locking dependency detected
[ 1990.984327] 4.14.0-rc2-2-gfab205f-dirty #4 Not tainted
[ 1990.989783] --
[ 1990.995937] qtdemux0:sink/2765 is trying to acquire lock:
[ 1991.001309]  (>lock){+.+.}, at: [] gsc_m2m_mmap+0x24/0x5c 
[exynos_gsc]
[ 1991.009108]
   but task is already holding lock:
[ 1991.014913]  (>mmap_sem){}, at: [] vm_mmap_pgoff+0x44/0xb8
[ 1991.021932]
   which lock already depends on the new lock.

[ 1991.030078]
   the existing dependency chain (in reverse order) is:
[ 1991.037530]
   -> #1 (>mmap_sem){}:
[ 1991.042913]__might_fault+0x80/0xb0
[ 1991.047096]video_usercopy+0x1cc/0x510 [videodev]
[ 1991.052297]v4l2_ioctl+0xa4/0xdc [videodev]
[ 1991.057036]do_vfs_ioctl+0xa0/0xa18
[ 1991.061102]SyS_ioctl+0x34/0x5c
[ 1991.064834]ret_fast_syscall+0x0/0x28
[ 1991.069072]
   -> #0 (>lock){+.+.}:
[ 1991.074193]lock_acquire+0x6c/0x88
[ 1991.078179]__mutex_lock+0x68/0xa34
[ 1991.082247]mutex_lock_interruptible_nested+0x1c/0x24
[ 1991.087888]gsc_m2m_mmap+0x24/0x5c [exynos_gsc]
[ 1991.093029]v4l2_mmap+0x54/0x88 [videodev]
[ 1991.097673]mmap_region+0x3a8/0x638
[ 1991.101743]do_mmap+0x330/0x3a4
[ 1991.105470]vm_mmap_pgoff+0x90/0xb8
[ 1991.109542]SyS_mmap_pgoff+0x90/0xc0
[ 1991.113702]ret_fast_syscall+0x0/0x28
[ 1991.117945]
   other info that might help us debug this:

[ 1991.125918]  Possible unsafe locking scenario:

[ 1991.131810]CPU0CPU1
[ 1991.136315]
[ 1991.140821]   lock(>mmap_sem);
[ 1991.144201]lock(>lock);
[ 1991.149833]lock(>mmap_sem);
[ 1991.155725]   lock(>lock);
[ 1991.158845]
*** DEADLOCK ***

[ 1991.164740] 1 lock held by qtdemux0:sink/2765:
[ 1991.169157]  #0:  (>mmap_sem){}, at: [] 
vm_mmap_pgoff+0x44/0xb8
[ 1991.176609]
   stack backtrace:
[ 1991.180946] CPU: 2 PID: 2765 Comm: qtdemux0:sink Not tainted 
4.14.0-rc2-2-gfab205f-dirty #4
[ 1991.189608] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 1991.195686] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[ 1991.203393] [] (show_stack) from [] 
(dump_stack+0x98/0xc4)
[ 1991.210586] [] (dump_stack) from [] 
(print_circular_bug+0x254/0x410)
[ 1991.218644] [] (print_circular_bug) from [] 
(check_prev_add+0x468/0x938)
[ 1991.227049] [] (check_prev_add) from [] 
(__lock_acquire+0x1314/0x14fc)
[ 1991.235281] [] (__lock_acquire) from [] 
(lock_acquire+0x6c/0x88)
[ 1991.242993] [] (lock_acquire) from [] 
(__mutex_lock+0x68/0xa34)
[ 1991.250620] [] (__mutex_lock) from [] 
(mutex_lock_interruptible_nested+0x1c/0x24)
[ 1991.259812] [] (mutex_lock_interruptible_nested) from [] 
(gsc_m2m_mmap+0x24/0x5c [exynos_gsc])
[ 1991.270159] [] (gsc_m2m_mmap [exynos_gsc]) from [] 
(v4l2_mmap+0x54/0x88 [videodev])
[ 1991.279510] [] (v4l2_mmap [videodev]) from [] 
(mmap_region+0x3a8/0x638)
[ 1991.287792] [] (mmap_region) from [] 
(do_mmap+0x330/0x3a4)
[ 1991.294986] [] (do_mmap) from [] 
(vm_mmap_pgoff+0x90/0xb8)
[ 1991.302178] [] (vm_mmap_pgoff) from [] 
(SyS_mmap_pgoff+0x90/0xc0)
[ 1991.309977] [] (SyS_mmap_pgoff) from [] 
(ret_fast_syscall+0x0/0x28)

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
Suggested-by: Hans Verkuil <hansv...@cisco.com>
---
 drivers/media/platform/exynos-gsc/gsc-m2m.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-m2m.c 
b/drivers/media/platform/exynos-gsc/gsc-m2m.c
index 2a2994e..722d7c4 100644
--- a/drivers/media/platform/exynos-gsc/gsc-m2m.c
+++ b/drivers/media/platform/exynos-gsc/gsc-m2m.c
@@ -726,14 +726,9 @@ static unsigned int gsc_m2m_poll(struct file *file,
 static int gsc_m2m_mmap(struct file *file, struct vm_area_struct *vma)
 {
struct gsc_ctx *ctx = fh_to_ctx(file->private_data);
-   struct gsc_dev *gsc = ctx->gsc_dev;
int ret;
 
-   if (mutex_lock_interruptible(>lock))
-   return -ERESTARTSYS;
-
ret = v4l2_m2m_mmap(file, ctx->m2m_ctx, vma);
-   mutex_unlock(>lock);
 
return ret;
 }
-- 
2.7.4

[PATCH 2/2] media: s5p-mfc: fix lockdep warning

[Shuah Khan]

The driver mmap functions shouldn't take lock when calling vb2_mmap().
Fix it to not take the lock. The following lockdep warning is fixed
with this change.

[ 2106.181412] ==
[ 2106.187563] WARNING: possible circular locking dependency detected
[ 2106.193718] 4.14.0-rc2-2-gfab205f-dirty #4 Not tainted
[ 2106.199175] --
[ 2106.205328] qtdemux0:sink/2614 is trying to acquire lock:
[ 2106.210701]  (>mfc_mutex){+.+.}, at: [] 
s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[ 2106.218672]
[ 2106.218672] but task is already holding lock:
[ 2106.224477]  (>mmap_sem){}, at: [] vm_mmap_pgoff+0x44/0xb8
[ 2106.231497]
[ 2106.231497] which lock already depends on the new lock.
[ 2106.231497]
[ 2106.239642]
[ 2106.239642] the existing dependency chain (in reverse order) is:
[ 2106.247095]
[ 2106.247095] -> #1 (>mmap_sem){}:
[ 2106.252473]__might_fault+0x80/0xb0
[ 2106.256567]video_usercopy+0x1cc/0x510 [videodev]
[ 2106.261845]v4l2_ioctl+0xa4/0xdc [videodev]
[ 2106.266596]do_vfs_ioctl+0xa0/0xa18
[ 2106.270667]SyS_ioctl+0x34/0x5c
[ 2106.274395]ret_fast_syscall+0x0/0x28
[ 2106.278637]
[ 2106.278637] -> #0 (>mfc_mutex){+.+.}:
[ 2106.284186]lock_acquire+0x6c/0x88
[ 2106.288173]__mutex_lock+0x68/0xa34
[ 2106.292244]mutex_lock_interruptible_nested+0x1c/0x24
[ 2106.297893]s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[ 2106.302747]v4l2_mmap+0x54/0x88 [videodev]
[ 2106.307409]mmap_region+0x3a8/0x638
[ 2106.311480]do_mmap+0x330/0x3a4
[ 2106.315207]vm_mmap_pgoff+0x90/0xb8
[ 2106.319279]SyS_mmap_pgoff+0x90/0xc0
[ 2106.323439]ret_fast_syscall+0x0/0x28
[ 2106.327683]
[ 2106.327683] other info that might help us debug this:
[ 2106.327683]
[ 2106.335656]  Possible unsafe locking scenario:
[ 2106.335656]
[ 2106.341548]CPU0CPU1
[ 2106.346053]
[ 2106.350559]   lock(>mmap_sem);
[ 2106.353939]lock(>mfc_mutex);
[ 2106.353939]lock(>mfc_mutex);
[ 2106.365897]   lock(>mfc_mutex);
[ 2106.369450]
[ 2106.369450]  *** DEADLOCK ***
[ 2106.369450]
[ 2106.375344] 1 lock held by qtdemux0:sink/2614:
[ 2106.379762]  #0:  (>mmap_sem){}, at: [] 
vm_mmap_pgoff+0x44/0xb8
[ 2106.387214]
[ 2106.387214] stack backtrace:
[ 2106.391550] CPU: 7 PID: 2614 Comm: qtdemux0:sink Not tainted 
4.14.0-rc2-2-gfab205f-dirty #4
[ 2106.400213] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 2106.406285] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[ 2106.413995] [] (show_stack) from [] 
(dump_stack+0x98/0xc4)
[ 2106.421187] [] (dump_stack) from [] 
(print_circular_bug+0x254/0x410)
[ 2106.429245] [] (print_circular_bug) from [] 
(check_prev_add+0x468/0x938)
[ 2106.437651] [] (check_prev_add) from [] 
(__lock_acquire+0x1314/0x14fc)
[ 2106.445883] [] (__lock_acquire) from [] 
(lock_acquire+0x6c/0x88)
[ 2106.453596] [] (lock_acquire) from [] 
(__mutex_lock+0x68/0xa34)
[ 2106.461221] [] (__mutex_lock) from [] 
(mutex_lock_interruptible_nested+0x1c/0x24)
[ 2106.470425] [] (mutex_lock_interruptible_nested) from [] 
(s5p_mfc_mmap+0x28/0xd4 [s5p_mfc])
[ 2106.480494] [] (s5p_mfc_mmap [s5p_mfc]) from [] 
(v4l2_mmap+0x54/0x88 [videodev])
[ 2106.489575] [] (v4l2_mmap [videodev]) from [] 
(mmap_region+0x3a8/0x638)
[ 2106.497875] [] (mmap_region) from [] 
(do_mmap+0x330/0x3a4)
[ 2106.505068] [] (do_mmap) from [] 
(vm_mmap_pgoff+0x90/0xb8)
[ 2106.512260] [] (vm_mmap_pgoff) from [] 
(SyS_mmap_pgoff+0x90/0xc0)
[ 2106.520059] [] (SyS_mmap_pgoff) from [] 
(ret_fast_syscall+0x0/0x28)

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
Suggested-by: Hans Verkuil <hansv...@cisco.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 4c253fb..40c18b4 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1047,8 +1047,6 @@ static int s5p_mfc_mmap(struct file *file, struct 
vm_area_struct *vma)
unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
int ret;
 
-   if (mutex_lock_interruptible(>mfc_mutex))
-   return -ERESTARTSYS;
if (offset < DST_QUEUE_OFF_BASE) {
mfc_debug(2, "mmaping source\n");
ret = vb2_mmap(>vq_src, vma);
@@ -1057,7 +1055,6 @@ static int s5p_mfc_mmap(struct file *file, struct 
vm_area_struct *vma)
vma->vm_pgoff -= (DST_QUEUE_OFF_BASE >> PAGE_SHIFT);
ret = vb2_mmap(>vq_dst, vma);
}
-   mutex_unlock(>mfc_mutex);
return ret;
 }
 
-- 
2.7.4

Re: [ANN] Call for topics for the media mini-summit on Friday Oct 27 in Prague

[Shuah Khan]

On 10/13/2017 09:05 AM, Hans Verkuil wrote:
> On 10/13/17 16:43, Shuah Khan wrote:
>> Hi Hans,
>>
>> On 10/13/2017 01:36 AM, Hans Verkuil wrote:
>>> Hi Shuah,
>>>
>>> On 10/05/2017 03:53 PM, Shuah Khan wrote:
>>>> Hi Hans/Gustavo.
>>>>
>>>> On Wed, Oct 4, 2017 at 1:34 PM, Gustavo Padovan <gust...@padovan.org> 
>>>> wrote:
>>>>> Hi Hans,
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Sep 1, 2017 at 6:46 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> We are organizing a media mini-summit on Friday October 27 in Prague, 
>>>>>> co-located
>>>>>> with the ELCE conference:
>>>>>>
>>>>>> http://events.linuxfoundation.org/events/embedded-linux-conference-europe
>>>>>>
>>>>>> This is a call for topics to discuss during that mini-summit.
>>>>>>
>>>>>> Also, if you plan to attend, please let me know. It is open for all, but 
>>>>>> it is
>>>>>> nice if we know beforehand who we can expect.
>>>>>>
>>>>>> So if you have a topic that you want to discuss there, then just reply 
>>>>>> to this
>>>>>> post. If possible, please add a rough idea of how much time you think 
>>>>>> you will
>>>>>> need.
>>>>>>
>>>>>> I plan to make the agenda based on the received topics around 
>>>>>> mid-October.
>>>>>>
>>>>>
>>>>> I"m attending and I want to propose a discussion:
>>>>>
>>>>> Topic: V4L2 Explicit Syncronization
>>>>> Purpose: quick overview and discuss of the API/direction we are going
>>>>> with fences
>>>>> Duration: 20-30min
>>>>
>>>> I would have loved to attend the Media mini-summit. Unfortunately I
>>>> already made plans to leave Friday. In addition participating in the
>>>> V4L2 Explicit Syncronization discussion, it would have been good to
>>>> discuss:
>>>>
>>>> the my pending Media/Audio resource sharing patch series that is
>>>> dependent on Sakari's lifetime managemnet patch series.
>>>
>>> I heard you were trying to extend your stay to include the Friday. Let me
>>> know if you'll be able to attend this summit and I can add this topic to
>>> the list. If you can't join us on Friday, then we can discuss this on the
>>> Thursday: we should have enough time for that.
>>
>> It is turning out to be tough and way too expensive to change travel dates.
>> Thanks for putting this topic on the agenda for Thursday.
> 
> No problem. I'll post an updated agenda for the Thursday meeting next week.
> 
>>
>>>
>>>> I have been unable to get any discussion going on this topic on the
>>>> mailing list.
>>>
>>> I suspect that as long as the core life-time issues aren't solved nothing
>>> much will happen with this. It's like building a house on quicksand.
>>
>> Yes. We have to decide on going forward path to address these life-time
>> issues.
>>
>>>
>>> It wasn't obvious that the foundation was quicksand when you started, but
>>> the realization slowly dawned on us that there were more problems than we
>>> thought. Or at least, this is my understanding.
>>
>> Right. Not a surprise as we poke around more it became clear that the 
>> framework
>> is fragile.
>>
>> If I could add one more item for discussion for Thursday if time permits.
>>
>> Proposing lock contention in mmap and v4l2 ioctl paths
>>
>> I also have one more item for discussion. I am debugging a deadlock problem
>> while running gstreamer pipeline involving s5p_mfc and exynos-gsc drivers 
>> with
>> CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_PROVE_LOCKING are enabled.
>>
>> Lock contention (race condition) between v4l2_ioctl and drivers fops:mmap 
>> interface.
>>
>> v4l2_ioctl -> video_ioctl2 -> video_usercopy
>> vm_mmap_pgoff -> v4l2_mmap -> s5p_mfc_mmap
>>
>> driver mmap routine tries to hold the video device lock it already holds
>> and in the debug path mm->mmap_sem gets held
>>
>> I think this might be an issue with m2m drivers that hold the video device
>> lock from the mmap routines. This could be a manifesta

Re: [ANN] Call for topics for the media mini-summit on Friday Oct 27 in Prague

[Shuah Khan]

Hi Hans,

On 10/13/2017 01:36 AM, Hans Verkuil wrote:
> Hi Shuah,
> 
> On 10/05/2017 03:53 PM, Shuah Khan wrote:
>> Hi Hans/Gustavo.
>>
>> On Wed, Oct 4, 2017 at 1:34 PM, Gustavo Padovan <gust...@padovan.org> wrote:
>>> Hi Hans,
>>>
>>>
>>>
>>> On Fri, Sep 1, 2017 at 6:46 AM, Hans Verkuil <hverk...@xs4all.nl> wrote:
>>>> Hi all,
>>>>
>>>> We are organizing a media mini-summit on Friday October 27 in Prague, 
>>>> co-located
>>>> with the ELCE conference:
>>>>
>>>> http://events.linuxfoundation.org/events/embedded-linux-conference-europe
>>>>
>>>> This is a call for topics to discuss during that mini-summit.
>>>>
>>>> Also, if you plan to attend, please let me know. It is open for all, but 
>>>> it is
>>>> nice if we know beforehand who we can expect.
>>>>
>>>> So if you have a topic that you want to discuss there, then just reply to 
>>>> this
>>>> post. If possible, please add a rough idea of how much time you think you 
>>>> will
>>>> need.
>>>>
>>>> I plan to make the agenda based on the received topics around mid-October.
>>>>
>>>
>>> I"m attending and I want to propose a discussion:
>>>
>>> Topic: V4L2 Explicit Syncronization
>>> Purpose: quick overview and discuss of the API/direction we are going
>>> with fences
>>> Duration: 20-30min
>>
>> I would have loved to attend the Media mini-summit. Unfortunately I
>> already made plans to leave Friday. In addition participating in the
>> V4L2 Explicit Syncronization discussion, it would have been good to
>> discuss:
>>
>> the my pending Media/Audio resource sharing patch series that is
>> dependent on Sakari's lifetime managemnet patch series.
> 
> I heard you were trying to extend your stay to include the Friday. Let me
> know if you'll be able to attend this summit and I can add this topic to
> the list. If you can't join us on Friday, then we can discuss this on the
> Thursday: we should have enough time for that.

It is turning out to be tough and way too expensive to change travel dates.
Thanks for putting this topic on the agenda for Thursday.

> 
>> I have been unable to get any discussion going on this topic on the
>> mailing list.
> 
> I suspect that as long as the core life-time issues aren't solved nothing
> much will happen with this. It's like building a house on quicksand.

Yes. We have to decide on going forward path to address these life-time
issues.

> 
> It wasn't obvious that the foundation was quicksand when you started, but
> the realization slowly dawned on us that there were more problems than we
> thought. Or at least, this is my understanding.

Right. Not a surprise as we poke around more it became clear that the framework
is fragile.

If I could add one more item for discussion for Thursday if time permits.

Proposing lock contention in mmap and v4l2 ioctl paths

I also have one more item for discussion. I am debugging a deadlock problem
while running gstreamer pipeline involving s5p_mfc and exynos-gsc drivers with
CONFIG_DEBUG_ATOMIC_SLEEP and CONFIG_PROVE_LOCKING are enabled.

Lock contention (race condition) between v4l2_ioctl and drivers fops:mmap 
interface.

v4l2_ioctl -> video_ioctl2 -> video_usercopy
vm_mmap_pgoff -> v4l2_mmap -> s5p_mfc_mmap

driver mmap routine tries to hold the video device lock it already holds
and in the debug path mm->mmap_sem gets held

I think this might be an issue with m2m drivers that hold the video device
lock from the mmap routines. This could be a manifestation of remove
V4L2_FL_LOCK_ALL_FOPS work at least in the case of s5p_mfc.

It isn't consistent in the way drivers call v4l2_m2m_mmap(). Some drivers
hold a lock and others don't.

I am working on a couple of patches to fix this contention and we could
either discuss this on the mailing list and/or on Thursday.

thanks,
-- Shuah

[PATCH 1/2] media: s5p-mfc: check for firmware allocation before requesting firmware

[Shuah Khan]

Check if firmware is allocated before requesting firmware instead of
requesting firmware only to release it if firmware is not allocated.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 69ef9c2..f064a0d1 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -55,6 +55,11 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
 * into kernel. */
mfc_debug_enter();
 
+   if (!dev->fw_buf.virt) {
+   mfc_err("MFC firmware is not allocated\n");
+   return -EINVAL;
+   }
+
for (i = MFC_FW_MAX_VERSIONS - 1; i >= 0; i--) {
if (!dev->variant->fw_name[i])
continue;
@@ -75,11 +80,6 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
release_firmware(fw_blob);
return -ENOMEM;
}
-   if (!dev->fw_buf.virt) {
-   mfc_err("MFC firmware is not allocated\n");
-   release_firmware(fw_blob);
-   return -EINVAL;
-   }
memcpy(dev->fw_buf.virt, fw_blob->data, fw_blob->size);
wmb();
release_firmware(fw_blob);
-- 
2.7.4

[PATCH 0/2] Fix s5p-mfc lock contention in request firmware paths

[Shuah Khan]

This patch series fixes inefficiencies and lock contention in the request
firmware paths.

Shuah Khan (2):
  media: s5p-mfc: check for firmware allocation before requesting
firmware
  media: s5p-mfc: fix lock confection - request_firmware() once and keep
state

 drivers/media/platform/s5p-mfc/s5p_mfc.c|  4 
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  3 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 15 ++-
 3 files changed, 17 insertions(+), 5 deletions(-)

-- 
2.7.4

[PATCH 2/2] media: s5p-mfc: fix lock confection - request_firmware() once and keep state

[Shuah Khan]

Driver calls request_firmware() whenever the device is opened for the
first time. As the device gets opened and closed, dev->num_inst == 1
is true several times. This is not necessary since the firmware is saved
in the fw_buf. s5p_mfc_load_firmware() copies the buffer returned by
the request_firmware() to dev->fw_buf.

fw_buf sticks around until it gets released from s5p_mfc_remove(), hence
there is no need to keep requesting firmware and copying it to fw_buf.

This might have been overlooked when changes are made to free fw_buf from
the device release interface s5p_mfc_release().

Fix s5p_mfc_load_firmware() to call request_firmware() once and keep state.
Change _probe() to load firmware once fw_buf has been allocated.

s5p_mfc_open() and it continues to call s5p_mfc_load_firmware() and init
hardware which is the step where firmware is written to the device.

This addresses the mfc_mutex contention due to repeated request_firmware()
calls from open() in the following circular locking warning:

[  552.194115] qtdemux0:sink/2710 is trying to acquire lock:
[  552.199488]  (>mfc_mutex){+.+.}, at: [] 
s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[  552.207459]
   but task is already holding lock:
[  552.213264]  (>mmap_sem){}, at: [] vm_mmap_pgoff+0x44/0xb8
[  552.220284]
   which lock already depends on the new lock.

[  552.228429]
   the existing dependency chain (in reverse order) is:
[  552.235881]
   -> #2 (>mmap_sem){}:
[  552.241259]__might_fault+0x80/0xb0
[  552.245331]filldir64+0xc0/0x2f8
[  552.249144]call_filldir+0xb0/0x14c
[  552.253214]ext4_readdir+0x768/0x90c
[  552.257374]iterate_dir+0x74/0x168
[  552.261360]SyS_getdents64+0x7c/0x1a0
[  552.265608]ret_fast_syscall+0x0/0x28
[  552.269850]
   -> #1 (>i_mutex_dir_key#2){}:
[  552.276180]down_read+0x48/0x90
[  552.279904]lookup_slow+0x74/0x178
[  552.283889]walk_component+0x1a4/0x2e4
[  552.288222]link_path_walk+0x174/0x4a0
[  552.292555]path_openat+0x68/0x944
[  552.296541]do_filp_open+0x60/0xc4
[  552.300528]file_open_name+0xe4/0x114
[  552.304772]filp_open+0x28/0x48
[  552.308499]kernel_read_file_from_path+0x30/0x78
[  552.313700]_request_firmware+0x3ec/0x78c
[  552.318291]request_firmware+0x3c/0x54
[  552.322642]s5p_mfc_load_firmware+0x54/0x150 [s5p_mfc]
[  552.328358]s5p_mfc_open+0x4e4/0x550 [s5p_mfc]
[  552.94]v4l2_open+0xa0/0x104 [videodev]
[  552.338137]chrdev_open+0xa4/0x18c
[  552.342121]do_dentry_open+0x208/0x310
[  552.346454]path_openat+0x28c/0x944
[  552.350526]do_filp_open+0x60/0xc4
[  552.354512]do_sys_open+0x118/0x1c8
[  552.358586]ret_fast_syscall+0x0/0x28
[  552.362830]
   -> #0 (>mfc_mutex){+.+.}:
   -> #0 (>mfc_mutex){+.+.}:
[  552.368379]lock_acquire+0x6c/0x88
[  552.372364]__mutex_lock+0x68/0xa34
[  552.376437]mutex_lock_interruptible_nested+0x1c/0x24
[  552.382086]s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
[  552.386939]v4l2_mmap+0x54/0x88 [videodev]
[  552.391601]mmap_region+0x3a8/0x638
[  552.395673]do_mmap+0x330/0x3a4
[  552.399400]vm_mmap_pgoff+0x90/0xb8
[  552.403472]SyS_mmap_pgoff+0x90/0xc0
[  552.407632]ret_fast_syscall+0x0/0x28
[  552.411876]
   other info that might help us debug this:

[  552.419848] Chain exists of:
 >mfc_mutex --> >i_mutex_dir_key#2 --> >mmap_sem

[  552.431200]  Possible unsafe locking scenario:

[  552.437092]CPU0CPU1
[  552.441598]
[  552.446104]   lock(>mmap_sem);
[  552.449484]lock(>i_mutex_dir_key#2);
[  552.456329]lock(>mmap_sem);
[  552.46]   lock(>mfc_mutex);
[  552.465775]
*** DEADLOCK ***

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 4 
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 3 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 5 +
 3 files changed, 12 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 1afde50..4c253fb 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1315,6 +1315,10 @@ static int s5p_mfc_probe(struct platform_device *pdev)
goto err_dma;
}
 
+   ret = s5p_mfc_load_firmware(dev);
+   if (ret)
+   mfc_err("Failed to load FW - try loading from open()\n");
+
mutex_init(>mfc_mutex);
init_waitqueue_head(>queue);
dev->hw_lock = 0;
diff --git a/drivers/media/platform/s5p-mfc/s5

Re: [ANN] Call for topics for the media mini-summit on Friday Oct 27 in Prague

[Shuah Khan]

Hi Hans/Gustavo.

On Wed, Oct 4, 2017 at 1:34 PM, Gustavo Padovan  wrote:
> Hi Hans,
>
>
>
> On Fri, Sep 1, 2017 at 6:46 AM, Hans Verkuil  wrote:
>> Hi all,
>>
>> We are organizing a media mini-summit on Friday October 27 in Prague, 
>> co-located
>> with the ELCE conference:
>>
>> http://events.linuxfoundation.org/events/embedded-linux-conference-europe
>>
>> This is a call for topics to discuss during that mini-summit.
>>
>> Also, if you plan to attend, please let me know. It is open for all, but it 
>> is
>> nice if we know beforehand who we can expect.
>>
>> So if you have a topic that you want to discuss there, then just reply to 
>> this
>> post. If possible, please add a rough idea of how much time you think you 
>> will
>> need.
>>
>> I plan to make the agenda based on the received topics around mid-October.
>>
>
> I"m attending and I want to propose a discussion:
>
> Topic: V4L2 Explicit Syncronization
> Purpose: quick overview and discuss of the API/direction we are going
> with fences
> Duration: 20-30min

I would have loved to attend the Media mini-summit. Unfortunately I
already made plans to leave Friday. In addition participating in the
V4L2 Explicit Syncronization discussion, it would have been good to
discuss:

the my pending Media/Audio resource sharing patch series that is
dependent on Sakari's lifetime managemnet patch series.

I have been unable to get any discussion going on this topic on the
mailing list.

thanks,
-- Shuah

Re: [RFC 5/5] pm: remove kernel thread freezing

[Shuah Khan]

On Tue, Oct 3, 2017 at 3:00 PM, Jiri Kosina  wrote:
> On Tue, 3 Oct 2017, Pavel Machek wrote:
>
>> > Again, I agree that the (rare) kthreads that are actually "creating" new
>> > I/O have to be somehow frozen and require special care.
>>
>> Agreed. Was any effort made to identify those special kernel threads?
>
> I don't think there is any other way than just inspecting all the
> try_to_freeze() instances in the kernel, and understanding what that
> particular kthread is doing.
>
> I've cleaned up most of the low-hanging fruit already, where the
> try_to_freeze() was obviously completely pointless, but a lot more time
> needs to be invested into this.
>

There are about 36 drivers that call try_to_freeze() and half (18 ) of
those are media drivers. Maybe it is easier handle sub-system by
sub-system basis for a review of which one of these usages could be
removed. cc'ing Mauro and linux-media

thanks,
-- Shuah

Re: s5p-mfc - WARNING: possible circular locking dependency detected,[ 4.14.0-rc2

[Shuah Khan]

On 09/26/2017 02:10 PM, Shuah Khan wrote:
> When running gstreamer pipeline with s5p-mfc → exynos-gsc→ exynos-drm,
> I am seeing circular locking dependency detected warning in 4.14-rc2.
> This is a regression from 4.13. The pipeline does run to completion
> video streaming works. Are you aware of this problem, or would you
> like it to be bisected.

Okay more on this. It is not a regression from 4.13. CONFIG_PROVE_LOCKING
is enabled in exynos_defconfig in 4.14 and not on 4.13. It is an existing
problem that is now being reported with CONFIG_PROVE_LOCKING enabled.

> 
> gst-launch-1.0 filesrc location=/media/shuah_arm/GH3_MOV_HD.mp4 ! qtdemux ! 
> h264parse ! v4l2video4dec capture-io-mode=dmabuf ! v4l2video7convert 
> output-io-mode=dmabuf-import ! kmssink force-modesetting=true
> 
> [ 2134.994539] ==
> [ 2135.000661] WARNING: possible circular locking dependency detected
> [ 2135.006815] 4.14.0-rc2 #1 Not tainted
> [ 2135.010452] --
> [ 2135.016606] qtdemux0:sink/2700 is trying to acquire lock:
> [ 2135.021978]  (>mfc_mutex){+.+.}, at: [] 
> s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
> [ 2135.029950]
>but task is already holding lock:
> [ 2135.035755]  (>mmap_sem){}, at: [] 
> vm_mmap_pgoff+0x44/0xb8
> [ 2135.042774]
>which lock already depends on the new lock.
> 
> [ 2135.050920]
>the existing dependency chain (in reverse order) is:
> [ 2135.058372]
>-> #2 (>mmap_sem){}:
> [ 2135.063751]__might_fault+0x80/0xb0
> [ 2135.067822]filldir64+0xc0/0x2f8
> [ 2135.071635]call_filldir+0xb0/0x14c
> [ 2135.075705]ext4_readdir+0x768/0x90c
> [ 2135.079864]iterate_dir+0x74/0x168
> [ 2135.083851]SyS_getdents64+0x7c/0x1a0
> [ 2135.088099]ret_fast_syscall+0x0/0x28
> [ 2135.092340]
>-> #1 (>i_mutex_dir_key#2){}:
> [ 2135.098671]down_read+0x48/0x90
> [ 2135.102395]lookup_slow+0x74/0x178
> [ 2135.106380]walk_component+0x1a4/0x2e4
> [ 2135.110713]link_path_walk+0x174/0x4a0
> [ 2135.115045]path_openat+0x68/0x944
> [ 2135.119031]do_filp_open+0x60/0xc4
> [ 2135.123019]file_open_name+0xe4/0x114
> [ 2135.127263]filp_open+0x28/0x48
> [ 2135.130990]kernel_read_file_from_path+0x30/0x78
> [ 2135.136193]_request_firmware+0x3ec/0x78c
> [ 2135.140782]request_firmware+0x3c/0x54
> [ 2135.145133]s5p_mfc_load_firmware+0x44/0x140 [s5p_mfc]
> [ 2135.150848]s5p_mfc_open+0x2d4/0x4e0 [s5p_mfc]
> [ 2135.155892]v4l2_open+0xa0/0x104 [videodev]
> [ 2135.160627]chrdev_open+0xa4/0x18c
> [ 2135.164612]do_dentry_open+0x208/0x310
> [ 2135.168945]path_openat+0x28c/0x944
> [ 2135.173017]do_filp_open+0x60/0xc4
> [ 2135.177002]do_sys_open+0x118/0x1c8
> [ 2135.181076]ret_fast_syscall+0x0/0x28
> [ 2135.185320]
>-> #0 (>mfc_mutex){+.+.}:
> [ 2135.190871]lock_acquire+0x6c/0x88
> [ 2135.194855]__mutex_lock+0x68/0xa34
> [ 2135.198927]mutex_lock_interruptible_nested+0x1c/0x24
> [ 2135.204575]s5p_mfc_mmap+0x28/0xd4 [s5p_mfc]
> [ 2135.209430]v4l2_mmap+0x54/0x88 [videodev]
> [ 2135.214093]mmap_region+0x3a8/0x638
> [ 2135.218163]do_mmap+0x330/0x3a4
> [ 2135.221890]vm_mmap_pgoff+0x90/0xb8
> [ 2135.225962]SyS_mmap_pgoff+0x90/0xc0
> [ 2135.230122]ret_fast_syscall+0x0/0x28
> [ 2135.234366]
>other info that might help us debug this:
> 
> [ 2135.242339] Chain exists of:
>  >mfc_mutex --> >i_mutex_dir_key#2 --> 
> >mmap_sem
> 
> [ 2135.253690]  Possible unsafe locking scenario:
> 
> [ 2135.259583]CPU0CPU1
> [ 2135.264089]
> [ 2135.268594]   lock(>mmap_sem);
> [ 2135.271974]lock(>i_mutex_dir_key#2);
> [ 2135.278820]lock(>mmap_sem);
> [ 2135.284712]   lock(>mfc_mutex);
> [ 2135.288265]
> *** DEADLOCK ***
> 
> [ 2135.294159] 1 lock held by qtdemux0:sink/2700:
> [ 2135.298577]  #0:  (>mmap_sem){}, at: [] 
> vm_mmap_pgoff+0x44/0xb8
> [ 2135.306029]
>stack backtrace:
> [ 2135.310365] CPU: 7 PID: 2700 Comm: qtdemux0:sink Not tainted 4.14.0-rc2 #1
> [ 2135.317208] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [ 2135.323282] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
> [ 2135.330992] [] (show_stack) from [] 
> (dump_stack+0x98/0xc4)
&

s5p-mfc - WARNING: possible circular locking dependency detected,[ 4.14.0-rc2

[Shuah Khan]

(do_mmap+0x330/0x3a4)
[ 2135.422063] [] (do_mmap) from [] 
(vm_mmap_pgoff+0x90/0xb8)
[ 2135.429255] [] (vm_mmap_pgoff) from [] 
(SyS_mmap_pgoff+0x90/0xc0)
[ 2135.437054] [] (SyS_mmap_pgoff) from [] 
(ret_fast_syscall+0x0/0x28)


thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com

Re: [PATCH 18/25] media: dvb_frontend: get rid of dtv_get_property_dump()

[Shuah Khan]

On 09/20/2017 01:11 PM, Mauro Carvalho Chehab wrote:
> Simplify the get property handling and move it to the existing
> code at dtv_property_process_get() directly.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/dvb-core/dvb_frontend.c | 43 
> ++-
>  1 file changed, 12 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index b7094c7a405f..607eaf3db052 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -1107,36 +1107,6 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] 
> = {
>   _DTV_CMD(DTV_STAT_TOTAL_BLOCK_COUNT, 0, 0),
>  };
>  
> -static void dtv_get_property_dump(struct dvb_frontend *fe,
> -   struct dtv_property *tvp)
> -{
> - int i;
> -
> - if (tvp->cmd <= 0 || tvp->cmd > DTV_MAX_COMMAND) {
> - dev_warn(fe->dvb->device, "%s: GET tvp.cmd = 0x%08x undefined\n"
> - , __func__,
> - tvp->cmd);
> - return;
> - }
> -
> - dev_dbg(fe->dvb->device, "%s: GET tvp.cmd= 0x%08x (%s)\n", __func__,
> - tvp->cmd,
> - dtv_cmds[tvp->cmd].name);
> -
> - if (dtv_cmds[tvp->cmd].buffer) {
> - dev_dbg(fe->dvb->device, "%s: tvp.u.buffer.len = 0x%02x\n",
> - __func__, tvp->u.buffer.len);
> -
> - for(i = 0; i < tvp->u.buffer.len; i++)
> - dev_dbg(fe->dvb->device,
> - "%s: tvp.u.buffer.data[0x%02x] = 
> 0x%02x\n",
> - __func__, i, tvp->u.buffer.data[i]);
> - } else {
> - dev_dbg(fe->dvb->device, "%s: tvp.u.data = 0x%08x\n", __func__,
> - tvp->u.data);
> - }
> -}
> -
>  /* Synchronise the legacy tuning parameters into the cache, so that 
> demodulator
>   * drivers can use a single set_frontend tuning function, regardless of 
> whether
>   * it's being used for the legacy or new API, reducing code and complexity.
> @@ -1529,7 +1499,18 @@ static int dtv_property_process_get(struct 
> dvb_frontend *fe,
>   return -EINVAL;
>   }
>  
> - dtv_get_property_dump(fe, tvp);
> + if (!dtv_cmds[tvp->cmd].buffer)
> + dev_dbg(fe->dvb->device,
> + "%s: GET cmd 0x%08x (%s) = 0x%08x\n",
> + __func__, tvp->cmd, dtv_cmds[tvp->cmd].name,
> + tvp->u.data);
> + else
> + dev_dbg(fe->dvb->device,
> + "%s: GET cmd 0x%08x (%s) len %d: %*ph\n",
> + __func__,
> + tvp->cmd, dtv_cmds[tvp->cmd].name,
> + tvp->u.buffer.len,
> + tvp->u.buffer.len, tvp->u.buffer.data);
>  
>   return 0;
>  }
> 

Why not keep common dtv_property_dum(0 and make these enhancements to add
more information to the dump in a common routine so both get and set are
covered.

I think this change coupled with the change in 17/25 is moving away from
common simpler code to embedded debug code. I am not clear on the value
it adds.

thanks,
-- Shuah 

Re: [PATCH 17/25] media: dvb_frontend: dtv_property_process_set() cleanups

[Shuah Khan]

  c->layer[1].modulation = data;
>   break;
>   case DTV_ISDBT_LAYERB_SEGMENT_COUNT:
> - c->layer[1].segment_count = tvp->u.data;
> + c->layer[1].segment_count = data;
>   break;
>   case DTV_ISDBT_LAYERB_TIME_INTERLEAVING:
> - c->layer[1].interleaving = tvp->u.data;
> + c->layer[1].interleaving = data;
>   break;
>   case DTV_ISDBT_LAYERC_FEC:
> - c->layer[2].fec = tvp->u.data;
> + c->layer[2].fec = data;
>   break;
>   case DTV_ISDBT_LAYERC_MODULATION:
> - c->layer[2].modulation = tvp->u.data;
> + c->layer[2].modulation = data;
>   break;
>   case DTV_ISDBT_LAYERC_SEGMENT_COUNT:
> - c->layer[2].segment_count = tvp->u.data;
> + c->layer[2].segment_count = data;
>   break;
>   case DTV_ISDBT_LAYERC_TIME_INTERLEAVING:
> - c->layer[2].interleaving = tvp->u.data;
> + c->layer[2].interleaving = data;
>   break;
>  
>   /* Multistream support */
>   case DTV_STREAM_ID:
>   case DTV_DVBT2_PLP_ID_LEGACY:
> - c->stream_id = tvp->u.data;
> + c->stream_id = data;
>   break;
>  
>   /* ATSC-MH */
>   case DTV_ATSCMH_PARADE_ID:
> - fe->dtv_property_cache.atscmh_parade_id = tvp->u.data;
> + fe->dtv_property_cache.atscmh_parade_id = data;
>   break;
>   case DTV_ATSCMH_RS_FRAME_ENSEMBLE:
> - fe->dtv_property_cache.atscmh_rs_frame_ensemble = tvp->u.data;
> + fe->dtv_property_cache.atscmh_rs_frame_ensemble = data;
>   break;
>  
>   case DTV_LNA:
> - c->lna = tvp->u.data;
> + c->lna = data;
>   if (fe->ops.set_lna)
>   r = fe->ops.set_lna(fe);
>   if (r < 0)
> @@ -2137,7 +2154,9 @@ static int dvb_frontend_handle_ioctl(struct file *file,
>   return PTR_ERR(tvp);
>  
>   for (i = 0; i < tvps->num; i++) {
> - err = dtv_property_process_set(fe, tvp + i, file);
> + err = dtv_property_process_set(fe, file,
> + (tvp + i)->cmd,
> + (tvp + i)->u.data);
>   if (err < 0) {
>   kfree(tvp);
>   return err;
> 

The rest looks good. Once the other comments are addressed and/or explained.

Reviewed-by: Shuah Khan <shua...@osg.samsung.com>

thanks,
-- Shuah

Re: [PATCH 02/25] media: dvb_frontend: fix return values for FE_SET_PROPERTY

[Shuah Khan]

On 09/20/2017 01:11 PM, Mauro Carvalho Chehab wrote:
> There are several problems with regards to the return of
> FE_SET_PROPERTY. The original idea were to return per-property
> return codes via tvp->result field, and to return an updated
> set of values.
> 
> However, that never worked. What's actually implemented is:
> 
> - the FE_SET_PROPERTY implementation doesn't call .get_frontend
>   callback in order to get the actual parameters after return;
> 
> - the tvp->result field is only filled if there's no error.
>   So, it is always filled with zero;
> 
> - FE_SET_PROPERTY doesn't call memdup_user() nor any other
>   copy_to_user() function. So, any changes at the properies

Spelling - properties

Nit: to the properties

>   will be lost;
> 
> - FE_SET_PROPERTY is declared as a write-only ioctl (IOW).
> 
> While we could fix the above, it could cause regressions.
> 
> So, let's just assume what the code really does, updating
> the documentation accordingly and removing the logic that
> would update the discarded tvp->result.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

The rest looks good.

Reviewed-by: Shuah Khan <shua...@osg.samsung.com>

> ---
>  Documentation/media/uapi/dvb/fe-get-property.rst | 7 +--
>  drivers/media/dvb-core/dvb_frontend.c| 2 --
>  include/uapi/linux/dvb/frontend.h| 2 +-
>  3 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/media/uapi/dvb/fe-get-property.rst 
> b/Documentation/media/uapi/dvb/fe-get-property.rst
> index 948d2ba84f2c..b69741d9cedf 100644
> --- a/Documentation/media/uapi/dvb/fe-get-property.rst
> +++ b/Documentation/media/uapi/dvb/fe-get-property.rst
> @@ -48,8 +48,11 @@ depends on the delivery system and on the device:
>  
> -  This call requires read/write access to the device.
>  
> -   -  At return, the values are updated to reflect the actual parameters
> -  used.
> +.. note::
> +
> +   At return, the values aren't updated to reflect the actual
> +   parameters used. If the actual parameters are needed, an explicit
> +   call to ``FE_GET_PROPERTY`` is needed.
>  
>  -  ``FE_GET_PROPERTY:``
>  
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index 7dda5acea3f2..bd60a490ce0f 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -2142,7 +2142,6 @@ static int dvb_frontend_handle_ioctl(struct file *file,
>   kfree(tvp);
>   return err;
>   }
> - (tvp + i)->result = err;
>   }
>   kfree(tvp);
>   break;
> @@ -2187,7 +2186,6 @@ static int dvb_frontend_handle_ioctl(struct file *file,
>   kfree(tvp);
>   return err;
>   }
> - (tvp + i)->result = err;
>   }
>  
>   if (copy_to_user((void __user *)tvps->props, tvp,
> diff --git a/include/uapi/linux/dvb/frontend.h 
> b/include/uapi/linux/dvb/frontend.h
> index 861cacd5711f..6bc26f35217b 100644
> --- a/include/uapi/linux/dvb/frontend.h
> +++ b/include/uapi/linux/dvb/frontend.h
> @@ -830,7 +830,7 @@ struct dtv_fe_stats {
>   * @cmd: Digital TV command.
>   * @reserved:Not used.
>   * @u:   Union with the values for the command.
> - * @result:  Result of the command set (currently unused).
> + * @result:  Unused
>   *
>   * The @u union may have either one of the values below:
>   *
> 

thanks,
-- Shuah

Re: [PATCH 01/25] media: dvb_frontend: better document the -EPERM condition

[Shuah Khan]

On 09/20/2017 01:11 PM, Mauro Carvalho Chehab wrote:
> Two readonly ioctls can't be allowed if the frontend device
> is opened in read only mode. Explain why.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/dvb-core/dvb_frontend.c | 20 +---
>  1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index 01bd19fd4c57..7dda5acea3f2 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -1940,9 +1940,23 @@ static int dvb_frontend_ioctl(struct file *file, 
> unsigned int cmd, void *parg)
>   return -ENODEV;
>   }
>  
> - if ((file->f_flags & O_ACCMODE) == O_RDONLY &&
> - (_IOC_DIR(cmd) != _IOC_READ || cmd == FE_GET_EVENT ||
> -  cmd == FE_DISEQC_RECV_SLAVE_REPLY)) {
> + /*
> +  * If the frontend is opened in read-only mode, only the ioctls
> +  * that don't interfere at the tune logic should be accepted.

Nit:

with the tune logic

> +  * That allows an external application to monitor the DVB QoS and
> +  * statistics parameters.
> +  *> +* That matches all _IOR() ioctls, except for two special cases:
> +  *   - FE_GET_EVENT is part of the tuning logic on a DVB application;
> +  *   - FE_DISEQC_RECV_SLAVE_REPLY is part of DiSEqC 2.0
> +  * setup
> +  * So, those two ioctls should also return -EPERM, as otherwise
> +  * reading from them would interfere with a DVB tune application
> +  */
> + if ((file->f_flags & O_ACCMODE) == O_RDONLY
> + && (_IOC_DIR(cmd) != _IOC_READ
> + || cmd == FE_GET_EVENT
> + || cmd == FE_DISEQC_RECV_SLAVE_REPLY)) {
>   up(>sem);
>   return -EPERM;
>   }
> 

Same comment from your previous series. I started looking at
the old series and now the latest. Didn't realize the series
has been revised. :(

Looks good to me

Reviewed by: Shuah Khan <shua...@osg.samsung.com>

thanks,
-- Shuah

Re: [PATCH 5/6] media: dvb_frontend: better document the -EPERM condition

[Shuah Khan]

On 09/19/2017 07:42 AM, Mauro Carvalho Chehab wrote:
> Two readonly ioctls can't be allowed if the frontend device
> is opened in read only mode. Explain why.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/dvb-core/dvb_frontend.c | 20 +---
>  1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index d0a17d67ab1b..db3f8c597a24 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -1940,9 +1940,23 @@ static int dvb_frontend_ioctl(struct file *file, 
> unsigned int cmd, void *parg)
>   return -ENODEV;
>   }
>  
> - if ((file->f_flags & O_ACCMODE) == O_RDONLY &&
> - (_IOC_DIR(cmd) != _IOC_READ || cmd == FE_GET_EVENT ||
> -  cmd == FE_DISEQC_RECV_SLAVE_REPLY)) {
> + /*
> +  * If the frontend is opened in read-only mode, only the ioctls
> +  * that don't interfere at the tune logic should be accepted.

Nit:

with the tune logic

> +  * That allows an external application to monitor the DVB QoS and
> +  * statistics parameters.
> +  *
> +  * That matches all _IOR() ioctls, except for two special cases:
> +  *   - FE_GET_EVENT is part of the tuning logic on a DVB application;
> +  *   - FE_DISEQC_RECV_SLAVE_REPLY is part of DiSEqC 2.0
> +  * setup
> +  * So, those two ioctls should also return -EPERM, as otherwise
> +  * reading from them would interfere with a DVB tune application
> +  */
> + if ((file->f_flags & O_ACCMODE) == O_RDONLY
> + && (_IOC_DIR(cmd) != _IOC_READ
> + || cmd == FE_GET_EVENT
> +     || cmd == FE_DISEQC_RECV_SLAVE_REPLY)) {
>   up(>sem);
>   return -EPERM;
>   }
> 

Looks good to me

Reviewed by: Shuah Khan <shua...@osg.samsung.com>

thanks,
-- Shuah

Re: [PATCH 3/6] media: dvb_frontend: get rid of proprierty cache's state

[Shuah Khan]

On 09/19/2017 07:42 AM, Mauro Carvalho Chehab wrote:
> In the past, I guess the idea was to use state in order to
> allow an autofush logic. However, in the current code, it is
> used only for debug messages, on a poor man's solution, as
> there's already a debug message to indicate when the properties
> got flushed.
> 
> So, just get rid of it for good.

Okay now PATCH 2/3 makes sense. Looks good to me.

Reviewed-by: Shuah Khan <shua...@osg.samsung.com>

> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/dvb-core/dvb_frontend.c | 20 ++--
>  drivers/media/dvb-core/dvb_frontend.h |  5 -
>  2 files changed, 6 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index cbe697a094d2..d0a17d67ab1b 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -951,8 +951,6 @@ static int dvb_frontend_clear_cache(struct dvb_frontend 
> *fe)
>   memset(c, 0, offsetof(struct dtv_frontend_properties, strength));
>   c->delivery_system = delsys;
>  
> - c->state = DTV_CLEAR;
> -
>   dev_dbg(fe->dvb->device, "%s: Clearing cache for delivery system %d\n",
>   __func__, c->delivery_system);
>  
> @@ -1775,13 +1773,13 @@ static int dtv_property_process_set(struct 
> dvb_frontend *fe,
>   dvb_frontend_clear_cache(fe);
>   break;
>   case DTV_TUNE:
> - /* interpret the cache of data, build either a traditional 
> frontend
> -  * tunerequest so we can pass validation in the FE_SET_FRONTEND
> -  * ioctl.
> + /*
> +  * Use the cached Digital TV properties to tune the
> +  * frontend
>*/
> - c->state = tvp->cmd;
> - dev_dbg(fe->dvb->device, "%s: Finalised property cache\n",
> - __func__);
> + dev_dbg(fe->dvb->device,
> + "%s: Setting the frontend from property cache\n",
> + __func__);
>  
>   r = dtv_set_frontend(fe);
>   break;
> @@ -1930,7 +1928,6 @@ static int dvb_frontend_ioctl(struct file *file, 
> unsigned int cmd, void *parg)
>  {
>   struct dvb_device *dvbdev = file->private_data;
>   struct dvb_frontend *fe = dvbdev->priv;
> - struct dtv_frontend_properties *c = >dtv_property_cache;
>   struct dvb_frontend_private *fepriv = fe->frontend_priv;
>   int err;
>  
> @@ -1950,7 +1947,6 @@ static int dvb_frontend_ioctl(struct file *file, 
> unsigned int cmd, void *parg)
>   return -EPERM;
>   }
>  
> - c->state = DTV_UNDEFINED;
>   err = dvb_frontend_handle_ioctl(file, cmd, parg);
>  
>   up(>sem);
> @@ -2134,10 +2130,6 @@ static int dvb_frontend_handle_ioctl(struct file *file,
>   }
>   (tvp + i)->result = err;
>   }
> -
> - if (c->state == DTV_TUNE)
> - dev_dbg(fe->dvb->device, "%s: Property cache is full, 
> tuning\n", __func__);
> -
>   kfree(tvp);
>   break;
>   }
> diff --git a/drivers/media/dvb-core/dvb_frontend.h 
> b/drivers/media/dvb-core/dvb_frontend.h
> index 852b91ba49d2..1bdeb10f0d78 100644
> --- a/drivers/media/dvb-core/dvb_frontend.h
> +++ b/drivers/media/dvb-core/dvb_frontend.h
> @@ -620,11 +620,6 @@ struct dtv_frontend_properties {
>   struct dtv_fe_stats post_bit_count;
>   struct dtv_fe_stats block_error;
>   struct dtv_fe_stats block_count;
> -
> - /* private: */
> - /* Cache State */
> - u32 state;
> -
>  };
>  
>  #define DVB_FE_NO_EXIT  0
> 

thanks,
-- Shuah

Re: [PATCH 2/6] media: dvb_frontend: cleanup ioctl handling logic

[Shuah Khan]

ase FE_ENABLE_HIGH_LNB_VOLTAGE:
> - if (fe->ops.enable_high_lnb_voltage)
> - err = fe->ops.enable_high_lnb_voltage(fe, (long) parg);
> + case FE_READ_SNR:
> + if (fe->ops.read_snr) {
> + if (fepriv->thread)
> + err = fe->ops.read_snr(fe, (__u16 *) parg);
> + else
> + err = -EAGAIN;
> + }
> + break;
> +
> + case FE_READ_UNCORRECTED_BLOCKS:
> + if (fe->ops.read_ucblocks) {
> + if (fepriv->thread)
> + err = fe->ops.read_ucblocks(fe, (__u32 *) parg);
> + else
> + err = -EAGAIN;
> + }
> + break;
> +
> + /* DEPRECATED DVBv3 ioctls */
> +
> + case FE_GET_INFO: {
> + struct dvb_frontend_info* info = parg;
> +
> + memcpy(info, >ops.info, sizeof(struct dvb_frontend_info));
> + dvb_frontend_get_frequency_limits(fe, >frequency_min, 
> >frequency_max);
> +
> + /*
> +  * Associate the 4 delivery systems supported by DVBv3
> +  * API with their DVBv5 counterpart. For the other standards,
> +  * use the closest type, assuming that it would hopefully
> +  * work with a DVBv3 application.
> +  * It should be noticed that, on multi-frontend devices with
> +  * different types (terrestrial and cable, for example),
> +  * a pure DVBv3 application won't be able to use all delivery
> +  * systems. Yet, changing the DVBv5 cache to the other delivery
> +  * system should be enough for making it work.
> +  */
> + switch (dvbv3_type(c->delivery_system)) {
> + case DVBV3_QPSK:
> + info->type = FE_QPSK;
> + break;
> + case DVBV3_ATSC:
> + info->type = FE_ATSC;
> + break;
> + case DVBV3_QAM:
> + info->type = FE_QAM;
> + break;
> + case DVBV3_OFDM:
> + info->type = FE_OFDM;
> + break;
> + default:
> + dev_err(fe->dvb->device,
> + "%s: doesn't know how to handle a DVBv3 
> call to delivery system %i\n",
> + __func__, c->delivery_system);
> + fe->ops.info.type = FE_OFDM;
> + }
> + dev_dbg(fe->dvb->device, "%s: current delivery system on cache: 
> %d, V3 type: %d\n",
> +  __func__, c->delivery_system, 
> fe->ops.info.type);
> +
> + /* Set CAN_INVERSION_AUTO bit on in other than oneshot mode */
> + if (!(fepriv->tune_mode_flags & FE_TUNE_MODE_ONESHOT))
> + info->caps |= FE_CAN_INVERSION_AUTO;
> + err = 0;
>   break;
> + }
>  
>   case FE_SET_FRONTEND:
>   err = dvbv3_set_delivery_system(fe);
> @@ -2466,11 +2455,10 @@ static int dvb_frontend_ioctl_legacy(struct file 
> *file,
>   err = dtv_get_frontend(fe, , parg);
>   break;
>   }
> - case FE_SET_FRONTEND_TUNE_MODE:
> - fepriv->tune_mode_flags = (unsigned long) parg;
> - err = 0;
> - break;
> - }
> +
> + default:
> + return -ENOTSUPP;
> + } /* switch */
>  
>   return err;
>  }
> 

Rest looks okay to me. With c->state issue addressed and/or explained:

Reviewed-by: Shuah Khan <shua...@osg.samsung.com>

thanks,
-- Shuah

Re: [PATCH 1/6] media: dvb_frontend: cleanup dvb_frontend_ioctl_properties()

[Shuah Khan]

properties(struct file 
> *file,
>*/
>   if (fepriv->state != FESTATE_IDLE) {
>   err = dtv_get_frontend(fe, , NULL);
> - if (err < 0)
> - goto out;
> + if (err < 0) {
> + kfree(tvp);
> + return err;
> + }

Could avoid duplicate code keeping out logic perhaps? Is there a reason
for removing this?

>   }
>   for (i = 0; i < tvps->num; i++) {
>   err = dtv_property_process_get(fe, , tvp + i, 
> file);
> - if (err < 0)
> - goto out;
> + if (err < 0) {
> + kfree(tvp);
> + return err;
> + }
>   (tvp + i)->result = err;
>   }
>  
>   if (copy_to_user((void __user *)tvps->props, tvp,
>tvps->num * sizeof(struct dtv_property))) {
> - err = -EFAULT;
> - goto out;
> + kfree(tvp);
> + return -EFAULT;
>   }

Could avoid duplicate code keeping out logic perhaps? Is there a reason
for removing this?

> -
> - } else
> - err = -EOPNOTSUPP;
> -
> -out:
> - kfree(tvp);
> - return err;
> + kfree(tvp);
> + break;
> + }
> + default:
> + return -ENOTSUPP;
> + } /* switch */
> + return 0;
>  }
>  
>  static int dtv_set_frontend(struct dvb_frontend *fe)
> 

Reviewed-by: Shuah Khan <shua...@osg.samsung.com>

thanks,
-- Shuah

Re: [PATCH] dvb_frontend: initialize variable s with FE_NONE instead of 0

[Shuah Khan]

On 07/21/2017 10:01 AM, Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
> 
> In a previous commit, we added FE_NONE as an unknown fe_status.
> Initialize variable s to FE_NONE instead of the more opaque value 0.
> 
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>

The change looks good to me.
Reviewed-by: Shuah Khan <shua...@osg.samsung.com>

I think this patch should be part of a patch series that includes
the uAPI Documentation change, uAPI change, and the following
patch:

[PATCH][V2] dvb_frontend: ensure that inital front end status initialized

based on Mauro's review comments. Anyway, I will leave it to Mauro to
decide how he wants the patches split and if he is okay with uAPI change.

thanks,
-- Shuah

> ---
>  drivers/media/dvb-core/dvb_frontend.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index 18cc3bbc699c..114994ca0929 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -460,7 +460,7 @@ static int dvb_frontend_swzigzag_autotune(struct 
> dvb_frontend *fe, int check_wra
>  
>  static void dvb_frontend_swzigzag(struct dvb_frontend *fe)
>  {
> - enum fe_status s = 0;
> + enum fe_status s = FE_NONE;
>   int retval = 0;
>   struct dvb_frontend_private *fepriv = fe->frontend_priv;
>   struct dtv_frontend_properties *c = >dtv_property_cache, tmp;
> 

Re: [PATCH][V2] dvb_frontend: ensure that inital front end status initialized

[Shuah Khan]

On 07/20/2017 04:12 PM, Colin King wrote:
> From: Colin Ian King <colin.k...@canonical.com>
> 
> The fe_status variable s is not initialized meaning it can have any
> random garbage status.  This could be problematic if fe->ops.tune is
> false as s is not updated by the call to fe->ops.tune() and a
> subsequent check on the change status will using a garbage value.
> Fix this by adding FE_NONE to the enum fe_status and initializing
> s to this.
> 
> Detected by CoverityScan, CID#112887 ("Uninitialized scalar variable")
> 
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>

Reviewed-by: Shuah Khan <shua...@osg.samsung.com>


Looks good to me. Do you mind fixing dvb_frontend_swzigzag() as well.
It currently initializes enum fe_status s = 0; in a separate patch.

> ---
>  drivers/media/dvb-core/dvb_frontend.c | 2 +-
>  include/uapi/linux/dvb/frontend.h | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index e3fff8f64d37..18cc3bbc699c 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -631,7 +631,7 @@ static int dvb_frontend_thread(void *data)
>   struct dvb_frontend *fe = data;
>   struct dtv_frontend_properties *c = >dtv_property_cache;
>   struct dvb_frontend_private *fepriv = fe->frontend_priv;
> - enum fe_status s;
> + enum fe_status s = FE_NONE;
>   enum dvbfe_algo algo;
>   bool re_tune = false;
>   bool semheld = false;
> diff --git a/include/uapi/linux/dvb/frontend.h 
> b/include/uapi/linux/dvb/frontend.h
> index 00a20cd21ee2..afc3972b0879 100644
> --- a/include/uapi/linux/dvb/frontend.h
> +++ b/include/uapi/linux/dvb/frontend.h
> @@ -127,6 +127,7 @@ enum fe_sec_mini_cmd {
>   *   to reset DiSEqC, tone and parameters
>   */
>  enum fe_status {
> + FE_NONE = 0x00,
>   FE_HAS_SIGNAL   = 0x01,
>   FE_HAS_CARRIER  = 0x02,
>   FE_HAS_VITERBI  = 0x04,
> 

Re: [PATCH] [media] dvb_frontend: ensure that front end status is initialized

[Shuah Khan]

Hi Colin,

On 07/20/2017 09:29 AM, Colin King wrote:
> From: Colin Ian King 
> 
> The fe_status variable s is not initialized meaning it can have any
> random garbage status.  This could be problematic if fe->ops.tune is
> false as s is not updated by the call to fe->ops.tune() and a
> subsequent check on the change status will using a garbage value.
> Fix this by initializing s to zero.
> 
> Detected by CoverityScan, CID#112887 ("Uninitialized scalar variable")
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/media/dvb-core/dvb_frontend.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index e3fff8f64d37..e18ea1508a59 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -631,7 +631,7 @@ static int dvb_frontend_thread(void *data)
>   struct dvb_frontend *fe = data;
>   struct dtv_frontend_properties *c = >dtv_property_cache;
>   struct dvb_frontend_private *fepriv = fe->frontend_priv;
> - enum fe_status s;
> + enum fe_status s = 0;

0 isn't a valid value for enum fe_status. I think the right fix would be
to add FE_NONE to enum fe_status and then initialize s to that.

thanks,
-- Shuah


>   enum dvbfe_algo algo;
>   bool re_tune = false;
>   bool semheld = false;
> 

Re: [PATCH 09/12] [media] vivid: mark vivid queues as ordered

[Shuah Khan]

On 06/16/2017 01:39 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> To enable vivid to be used with explicit synchronization we need
> to mark its queues as ordered.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/media/platform/vivid/vivid-core.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/media/platform/vivid/vivid-core.c 
> b/drivers/media/platform/vivid/vivid-core.c
> index 8843170..c7bef90 100644
> --- a/drivers/media/platform/vivid/vivid-core.c
> +++ b/drivers/media/platform/vivid/vivid-core.c
> @@ -1063,6 +1063,7 @@ static int vivid_create_instance(struct platform_device 
> *pdev, int inst)
>   q->type = dev->multiplanar ? V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE 
> :
>   V4L2_BUF_TYPE_VIDEO_CAPTURE;
>   q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
> + q->ordered = 1;

How will the driver ensure ordered buffers? Are there more changes needed
in this driver?

>   q->drv_priv = dev;
>   q->buf_struct_size = sizeof(struct vivid_buffer);
>   q->ops = _vid_cap_qops;
> @@ -1083,6 +1084,7 @@ static int vivid_create_instance(struct platform_device 
> *pdev, int inst)
>   q->type = dev->multiplanar ? V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE :
>   V4L2_BUF_TYPE_VIDEO_OUTPUT;
>   q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_WRITE;
> + q->ordered = 1;
>   q->drv_priv = dev;
>   q->buf_struct_size = sizeof(struct vivid_buffer);
>   q->ops = _vid_out_qops;
> @@ -1103,6 +1105,7 @@ static int vivid_create_instance(struct platform_device 
> *pdev, int inst)
>   q->type = dev->has_raw_vbi_cap ? V4L2_BUF_TYPE_VBI_CAPTURE :
> V4L2_BUF_TYPE_SLICED_VBI_CAPTURE;
>   q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
> + q->ordered = 1;
>   q->drv_priv = dev;
>   q->buf_struct_size = sizeof(struct vivid_buffer);
>   q->ops = _vbi_cap_qops;
> @@ -1123,6 +1126,7 @@ static int vivid_create_instance(struct platform_device 
> *pdev, int inst)
>   q->type = dev->has_raw_vbi_out ? V4L2_BUF_TYPE_VBI_OUTPUT :
> V4L2_BUF_TYPE_SLICED_VBI_OUTPUT;
>   q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_WRITE;
> + q->ordered = 1;
>   q->drv_priv = dev;
>   q->buf_struct_size = sizeof(struct vivid_buffer);
>   q->ops = _vbi_out_qops;
> @@ -1142,6 +1146,7 @@ static int vivid_create_instance(struct platform_device 
> *pdev, int inst)
>   q = >vb_sdr_cap_q;
>   q->type = V4L2_BUF_TYPE_SDR_CAPTURE;
>   q->io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
> + q->ordered = 1;
>   q->drv_priv = dev;
>   q->buf_struct_size = sizeof(struct vivid_buffer);
>   q->ops = _sdr_cap_qops;
> 

thanks,
-- Shuah

Re: [PATCH 05/12] [media] vivid: assign the specific device to the vb2_queue->dev

[Shuah Khan]

On 06/16/2017 01:39 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Instead of assigning the global v4l2 device, assign the specific device.
> This was causing trouble when using using V4L2 events with vivid
> devices. The device's queue should be the same we opened in userspace.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/media/platform/vivid/vivid-core.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/vivid/vivid-core.c 
> b/drivers/media/platform/vivid/vivid-core.c
> index ef344b9..8843170 100644
> --- a/drivers/media/platform/vivid/vivid-core.c
> +++ b/drivers/media/platform/vivid/vivid-core.c
> @@ -1070,7 +1070,7 @@ static int vivid_create_instance(struct platform_device 
> *pdev, int inst)
>   q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>   q->min_buffers_needed = 2;
>   q->lock = >mutex;
> - q->dev = dev->v4l2_dev.dev;
> + q->dev = >vid_cap_dev.dev;

Does this work in all cases? My concern is that in some code paths
q->dev might be used to initiate release perhaps.

Fore example v4l2_dev.release is vivid_dev_release()
dev->v4l2_dev.release = vivid_dev_release;

vid_cap_dev release is video_device_release_empty

This is one difference, but there might be others and the code paths
that might depend on q->dev being the v4l2_dev.dev which is the global
dev.

> > ret = vb2_queue_init(q);
>   if (ret)
> @@ -1090,7 +1090,7 @@ static int vivid_create_instance(struct platform_device 
> *pdev, int inst)
>   q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>   q->min_buffers_needed = 2;
>   q->lock = >mutex;
> - q->dev = dev->v4l2_dev.dev;
> + q->dev = >vid_out_dev.dev;
>  
>   ret = vb2_queue_init(q);
>   if (ret)
> @@ -1110,7 +1110,7 @@ static int vivid_create_instance(struct platform_device 
> *pdev, int inst)
>   q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>   q->min_buffers_needed = 2;
>   q->lock = >mutex;
> - q->dev = dev->v4l2_dev.dev;
> + q->dev = >vbi_cap_dev.dev;
>  
>   ret = vb2_queue_init(q);
>   if (ret)
> @@ -1130,7 +1130,7 @@ static int vivid_create_instance(struct platform_device 
> *pdev, int inst)
>   q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>   q->min_buffers_needed = 2;
>   q->lock = >mutex;
> - q->dev = dev->v4l2_dev.dev;
> + q->dev = >vbi_out_dev.dev;
>  
>   ret = vb2_queue_init(q);
>   if (ret)
> @@ -1149,7 +1149,7 @@ static int vivid_create_instance(struct platform_device 
> *pdev, int inst)
>   q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>   q->min_buffers_needed = 8;
>   q->lock = >mutex;
> - q->dev = dev->v4l2_dev.dev;
> + q->dev = >sdr_cap_dev.dev;
>  
>   ret = vb2_queue_init(q);
>   if (ret)
> 

thanks,
-- Shuah

Re: [PATCH 04/12] [media] uvc: enable subscriptions to other events

[Shuah Khan]

On 06/16/2017 01:39 AM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Call v4l2_ctrl_subscribe_event to subscribe to more events supported by
> v4l.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/media/usb/uvc/uvc_v4l2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c 
> b/drivers/media/usb/uvc/uvc_v4l2.c
> index 3e7e283..dfa0ccd 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -1240,7 +1240,7 @@ static int uvc_ioctl_subscribe_event(struct v4l2_fh *fh,
>   case V4L2_EVENT_CTRL:
>   return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
>   default:
> - return -EINVAL;
> + return v4l2_ctrl_subscribe_event(fh, sub);

This looks incorrect. With this change driver will be subscribing to all
v4l2 events? Is this the intent?

>   }
>  }
>  
> 

thanks,
-- Shuah

Re: [RFC 00/10] V4L2 explicit synchronization support

[Shuah Khan]

On 06/09/2017 12:25 AM, Gustavo Padovan wrote:
> 2017-06-08 Shuah Khan <shuahk...@gmail.com>:
> 
>> Hi Gustavo,
>>
>> On Thu, Jun 8, 2017 at 2:17 PM, Mauro Carvalho Chehab
>> <mche...@osg.samsung.com> wrote:
>>> Hi Gustavo,
>>>
>>> Em Wed, 24 May 2017 21:31:01 -0300
>>> Gustavo Padovan <gust...@padovan.org> escreveu:
>>>
>>>> Hi all,
>>>>
>>>> I've been working on the v2 of this series, but I think I hit a blocker
>>>> when trying to cover the case where the driver asks to requeue the
>>>> buffer. It is related to the out-fence side.
>>>>
>>>> In the current implementation we return on QBUF an out-fence fd that is not
>>>> tied to any buffer, because we don't know the queueing order until the
>>>> buffer is queued to the driver. Then when the buffer is queued we use
>>>> the BUF_QUEUED event to notify userspace of the index of the buffer,
>>>> so now userspace knows the buffer associated to the out-fence fd
>>>> received earlier.
>>>>
>>>> Userspace goes ahead and send a DRM Atomic Request to the kernel to
>>>> display that buffer on the screen once the fence signals. If it is
>>>> a nonblocking request the fence waiting is past the check phase, thus
>>>> it isn't allowed to fail anymore.
>>>>
>>>> But now, what happens if the V4L2 driver calls buffer_done() asking
>>>> to requeue the buffer. That means the operation failed and can't
>>>> signal the fence, starving the DRM side.
>>>>
>>>> We need to fix that. The only way I can see is to guarantee ordering of
>>>> buffers when out-fences are used. Ordering is something that HAL3 needs
>>>> to so maybe there is more than one reason to do it like this. I'm not
>>>> a V4L2 expert, so I don't know all the consequences of such a change.
>>>>
>>>> Any other ideas?
>>>>
>>>> The current patchset is at:
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/padovan/linux.git/log/?h=v4l2-fences
>>
>> Do you plan to send the v2 out? I did a quick review and have a few comments.
>>
>> [media] vb2: split out queueing from vb_core_qbuf()
>>
>> It changes the sequence a bit.
>>
>> /* Fill buffer information for the userspace */
>>   if (pb)
>>   call_void_bufop(q, fill_user_buffer, vb, pb);
>>
>> With the changes - user information is filled before __enqueue_in_driver(vb);
> 
> Without my changes it also fills it before __enqueue_in_driver() when
> start_streaming wasn't called yet. So I don't think it really matters.

Right, with this change, it fills the buffer before __enqueue_in_driver()
when start_streaming is called. Is that an issue, I don't know for sure.
It might not be necessary perhaps if buffer is filled in the path when
stream is already called.

> 
>>
>> Anyway, it might be a good idea to send the v2 out for review and we can 
>> review
>> patches in detail. I am hoping to test your patch series on odroid-xu4
>> next week.
>> Could you please add me to the thread as well as include me when you send
>> v2 and subsequent versions.
> 
> I will send a v2 as soon as I can, but from Thursday next week until
> the 25th I'll be on vacation.

okay sounds good.

thanks,
-- Shuah

Re: [RFC 00/10] V4L2 explicit synchronization support

[Shuah Khan]

Hi Gustavo,

On Thu, Jun 8, 2017 at 2:17 PM, Mauro Carvalho Chehab
 wrote:
> Hi Gustavo,
>
> Em Wed, 24 May 2017 21:31:01 -0300
> Gustavo Padovan  escreveu:
>
>> Hi all,
>>
>> I've been working on the v2 of this series, but I think I hit a blocker
>> when trying to cover the case where the driver asks to requeue the
>> buffer. It is related to the out-fence side.
>>
>> In the current implementation we return on QBUF an out-fence fd that is not
>> tied to any buffer, because we don't know the queueing order until the
>> buffer is queued to the driver. Then when the buffer is queued we use
>> the BUF_QUEUED event to notify userspace of the index of the buffer,
>> so now userspace knows the buffer associated to the out-fence fd
>> received earlier.
>>
>> Userspace goes ahead and send a DRM Atomic Request to the kernel to
>> display that buffer on the screen once the fence signals. If it is
>> a nonblocking request the fence waiting is past the check phase, thus
>> it isn't allowed to fail anymore.
>>
>> But now, what happens if the V4L2 driver calls buffer_done() asking
>> to requeue the buffer. That means the operation failed and can't
>> signal the fence, starving the DRM side.
>>
>> We need to fix that. The only way I can see is to guarantee ordering of
>> buffers when out-fences are used. Ordering is something that HAL3 needs
>> to so maybe there is more than one reason to do it like this. I'm not
>> a V4L2 expert, so I don't know all the consequences of such a change.
>>
>> Any other ideas?
>>
>> The current patchset is at:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/padovan/linux.git/log/?h=v4l2-fences

Do you plan to send the v2 out? I did a quick review and have a few comments.

[media] vb2: split out queueing from vb_core_qbuf()

It changes the sequence a bit.

/* Fill buffer information for the userspace */
  if (pb)
  call_void_bufop(q, fill_user_buffer, vb, pb);

With the changes - user information is filled before __enqueue_in_driver(vb);

Anyway, it might be a good idea to send the v2 out for review and we can review
patches in detail. I am hoping to test your patch series on odroid-xu4
next week.
Could you please add me to the thread as well as include me when you send
v2 and subsequent versions.

thanks,
-- Shuah

Re: [PATCH 5/9] [media] s5p-jpeg: Add IOMMU support

[Shuah Khan]

On Fri, Jun 2, 2017 at 10:02 AM, Thierry Escande
 wrote:
> From: Tony K Nadackal 
>
> This patch adds support for IOMMU s5p-jpeg driver if the Exynos IOMMU
> and ARM DMA IOMMU configurations are supported. The address space is
> created with size limited to 256M and base address set to 0x2000.
>
> Signed-off-by: Tony K Nadackal 
> Signed-off-by: Thierry Escande 
> ---
>  drivers/media/platform/s5p-jpeg/jpeg-core.c | 77 
> +
>  1 file changed, 77 insertions(+)
>
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c 
> b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index 770a709..5569b99 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -28,6 +28,14 @@
>  #include 
>  #include 
>  #include 
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#endif
>
>  #include "jpeg-core.h"
>  #include "jpeg-hw-s5p.h"
> @@ -35,6 +43,10 @@
>  #include "jpeg-hw-exynos3250.h"
>  #include "jpeg-regs.h"
>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +static struct dma_iommu_mapping *mapping;
> +#endif
> +
>  static struct s5p_jpeg_fmt sjpeg_formats[] = {
> {
> .name   = "JPEG JFIF",
> @@ -956,6 +968,60 @@ static void exynos4_jpeg_parse_q_tbl(struct s5p_jpeg_ctx 
> *ctx)
> }
>  }
>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +static int jpeg_iommu_init(struct platform_device *pdev)
> +{
> +   struct device *dev = >dev;
> +   int err;
> +
> +   mapping = arm_iommu_create_mapping(_bus_type, 0x2000,
> +  SZ_512M);

Change log says 256M??

What happens when another driver uses the same start point?
exynos drm uses the same  looks like

EXYNOS_DEV_ADDR_START   0x2000

> +   if (IS_ERR(mapping)) {
> +   dev_err(dev, "IOMMU mapping failed\n");
> +   return PTR_ERR(mapping);
> +   }
> +
> +   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms), 
> GFP_KERNEL);
> +   if (!dev->dma_parms) {
> +   err = -ENOMEM;
> +   goto error_alloc;
> +   }
> +
> +   err = dma_set_max_seg_size(dev, 0xu);

You could use DMA_BIT_MASK(32) instead of 0xu

> +   if (err)
> +   goto error;
> +
> +   err = arm_iommu_attach_device(dev, mapping);
> +   if (err)
> +   goto error;
> +
> +   return 0;
> +
> +error:
> +   devm_kfree(dev, dev->dma_parms);
> +   dev->dma_parms = NULL;
> +
> +error_alloc:
> +   arm_iommu_release_mapping(mapping);
> +   mapping = NULL;
> +
> +   return err;
> +}
> +
> +static void jpeg_iommu_deinit(struct platform_device *pdev)
> +{
> +   struct device *dev = >dev;
> +
> +   if (mapping) {
> +   arm_iommu_detach_device(dev);
> +   devm_kfree(dev, dev->dma_parms);
> +   dev->dma_parms = NULL;
> +   arm_iommu_release_mapping(mapping);
> +   mapping = NULL;
> +   }
> +}
> +#endif
> +
>  /*
>   * 
> 
>   * Device file operations
> @@ -2816,6 +2882,13 @@ static int s5p_jpeg_probe(struct platform_device *pdev)
> spin_lock_init(>slock);
> jpeg->dev = >dev;
>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +   ret = jpeg_iommu_init(pdev);
> +   if (ret) {
> +   dev_err(>dev, "IOMMU Initialization failed\n");
> +   return ret;
> +   }
> +#endif

You might be able to avoid use of ifdefs if you define stubs for !defines case.

> /* memory-mapped registers */
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>
> @@ -2962,6 +3035,10 @@ static int s5p_jpeg_remove(struct platform_device 
> *pdev)
> clk_disable_unprepare(jpeg->clocks[i]);
> }
>
> +#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
> +   jpeg_iommu_deinit(pdev);
> +#endif
> +
> return 0;
>  }
>
> --
> 2.7.4
>

Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed

[Shuah Khan]

Hi Sailus/Mauro,

On 01/26/2017 02:10 AM, Mauro Carvalho Chehab wrote:
> Em Wed, 25 Jan 2017 13:02:31 +0200
> Sakari Ailus  escreveu:
> 
>> Hi Mauro,
>>
>> On Tue, Jan 24, 2017 at 08:49:02AM -0200, Mauro Carvalho Chehab wrote:
>>> Hi Sakari,
>>>
>>> Just returned this week from vacations. I'm reading my long e-mail backlog,
>>> starting from my main inbox...
>>>
>>> Em Mon, 2 Jan 2017 09:53:49 +0200
>>> Sakari Ailus  escreveu:
>>>   
 Hi Mauro,

 On Mon, Dec 19, 2016 at 07:46:55AM -0200, Mauro Carvalho Chehab wrote:  
> Em Fri, 16 Dec 2016 17:07:23 +0200
> Sakari Ailus  escreveu:
> 
>> Hi Hans,
> 
>>> chrdev_open in fs/char_dev.c increases the refcount on open() and 
>>> decreases it
>>> on release(). Thus ensuring that the cdev can never be removed while in 
>>> an
>>> ioctl.  
>>
>> It does, but it does not affect memory which is allocated separately of 
>> that.
>>
>> See this:
>>
>> 
>> 
>
> That sounds promising. If this bug issues other drivers than OMAP3,
> then indeed the core has a bug.
>
> I'll see if I can reproduce it here with some USB drivers later this 
> week.

 It's not a driver problem so yes, it is reproducible on other hardware.  
>>>
>>> Didn't have time to test it before entering into vacations.
>>>
>>> I guess I won't have any time this week to test those issues on
>>> my hardware, as I suspect that my patch queue is full. Also, we're
>>> approaching the next merge window. So, unfortunately, I won't have
>>> much time those days to do much testing. 
>>>
>>> Btw, Hans commented that you were planning to working on it this month.
>>>
>>> Do you have some news with regards to the media controller bind/unbind
>>> fixes?  
>>
>> I have a bunch of meeting notes to send from the Oslo meeting with Hans and
>> Laurent; I should have that ready by the end of the week. The RFC patchset
>> certainly needs changes based on that.
> 
> OK. I'll wait for your notes and the new patchset.

What is the status of this patch series? Did I miss RFC v4?

As you might remember, my resource sharing work for snd-usb-audio
and the shared media object API which is necessary for media
driver and snd-usb-audio to share the media device are pending
waiting for this RFC series to go from RFC to a version that can
be merged.

I would like to get the snd-usb-audio work done soon and target it
for an upcoming release in the near future!

Could you please send an update on the status on when the next RFC
version might be sent out.

thanks,
-- Shuah

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

[Shuah Khan]

Hi Russell, and Marek,

On 04/14/2017 03:46 AM, Russell King - ARM Linux wrote:
> On Fri, Apr 14, 2017 at 09:56:07AM +0200, Marek Szyprowski wrote:
 This would be however quite large task, especially taking into account
 all current users of DMA-buf framework...
>>> Yeah it will be a large task.
>>
>> Maybe once scatterlist are switched to pfns, changing dmabuf internal
>> memory representation to pfn array might be much easier.
> 
> Switching to a PFN array won't work either as we have no cross-arch
> way to translate PFNs to a DMA address and vice versa.  Yes, we have
> them in ARM, but they are an _implementation detail_ of ARM's
> DMA API support, they are not for use by drivers.
> 
> So, the very first problem that needs solving is this:
> 
>   How do we go from a coherent DMA allocation for device X to a set
>   of DMA addresses for device Y.
> 
> Essentially, we need a way of remapping the DMA buffer for use with
> another device, and returning a DMA address suitable for that device.
> This could well mean that we need to deal with setting up an IOMMU
> mapping.  My guess is that this needs to happen at the DMA coherent
> API level - the DMA coherent API needs to be augmented with support
> for this.  I'll call this "DMA coherent remap".
> 
> We then need to think about how to pass this through the dma-buf API.
> dma_map_sg() is done by the exporter, who should know what kind of
> memory is being exported.  The exporter can avoid calling dma_map_sg()
> if it knows in advance that it is exporting DMA coherent memory.
> Instead, the exporter can simply create a scatterlist with the DMA
> address and DMA length prepopulated with the results of the DMA
> coherent remap operation above.

As Russell pointed to armama-drm case, I looked at that closely.
armada-drm is creating sg_table and populating it with DMA-address in
its map_dma_buf ops and unmap_dma_buf ops handles the special case and
doesn't call dma_unmap_sg().

In the case of drm, gem_prime_map_dma_buf interfaces and the common
drm_gem_map_dma_buf() will need modification to not do dma_map_sg()
and create scatterlist with the DMA address and DMA length instead.
We have to get drm_gem_map_dma_buf() info. to have it not do dma_map_sg()
and create scatterlist.

Focusing on drm for now, looks like there are probably about 15 or so
map_dma_buf interfaces will need to handle coherent memory case.

> 
> What the scatterlist can't carry in this case is a set of valid
> struct page pointers, and an importer must not walk the scatterlist
> expecting to get at the virtual address parameters or struct page
> pointers.

Right - importers need handling to not walk the sg_list and handle
it differently. Is there a good example drm you can point me to for
this? aramda-drm seems to special case this in armada_gem_map_import()
if I am not mistaken.

> 
> On the mmap() side of things, remember that DMA coherent allocations
> may require special mapping into userspace, and which can only be
> mapped by the DMA coherent mmap support.  kmap etc will also need to
> be different.  So it probably makes sense for DMA coherent dma-buf
> exports to use a completely separate set of dma_buf_ops from the
> streaming version.
> 

I agree. It would make is easier and also limits the scope of changes.

> I think this is the easiest approach to solving the problem without
> needing massive driver changes all over the kernel.
> 

Anyway this is a quick note to say that I am looking into this and
haven't drooped it :)

thanks,
-- Shuah

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

[Shuah Khan]

On 04/14/2017 03:46 AM, Russell King - ARM Linux wrote:
> On Fri, Apr 14, 2017 at 09:56:07AM +0200, Marek Szyprowski wrote:
 This would be however quite large task, especially taking into account
 all current users of DMA-buf framework...
>>> Yeah it will be a large task.
>>
>> Maybe once scatterlist are switched to pfns, changing dmabuf internal
>> memory representation to pfn array might be much easier.
> 
> Switching to a PFN array won't work either as we have no cross-arch
> way to translate PFNs to a DMA address and vice versa.  Yes, we have
> them in ARM, but they are an _implementation detail_ of ARM's
> DMA API support, they are not for use by drivers.
> 
> So, the very first problem that needs solving is this:
> 
>   How do we go from a coherent DMA allocation for device X to a set
>   of DMA addresses for device Y.
> 
> Essentially, we need a way of remapping the DMA buffer for use with
> another device, and returning a DMA address suitable for that device.
> This could well mean that we need to deal with setting up an IOMMU
> mapping.  My guess is that this needs to happen at the DMA coherent
> API level - the DMA coherent API needs to be augmented with support
> for this.  I'll call this "DMA coherent remap".
> 
> We then need to think about how to pass this through the dma-buf API.
> dma_map_sg() is done by the exporter, who should know what kind of
> memory is being exported.  The exporter can avoid calling dma_map_sg()
> if it knows in advance that it is exporting DMA coherent memory.
> Instead, the exporter can simply create a scatterlist with the DMA
> address and DMA length prepopulated with the results of the DMA
> coherent remap operation above.

The only way to conclusively say that it is coming from coherent area
is at the time it is getting allocated in dma_alloc_from_coherent().
Since dma_alloc_attrs() will go on to find memory from other areas if
dma_alloc_from_coherent() doesn't allocate memory.

dma_get_sgtable_attrs() is what is used by the exporter to create the
sg_table. One way to do this cleanly without needing to check buffer
type flags would be to add a set of sg_table ops: get_sgtable,
map_sg, and unmap_sg. Sounds like sg_table interfaces need to be in
dma_buf_ops level. More below.

> 
> What the scatterlist can't carry in this case is a set of valid
> struct page pointers, and an importer must not walk the scatterlist
> expecting to get at the virtual address parameters or struct page
> pointers.
> 
> On the mmap() side of things, remember that DMA coherent allocations
> may require special mapping into userspace, and which can only be
> mapped by the DMA coherent mmap support.  kmap etc will also need to
> be different.  So it probably makes sense for DMA coherent dma-buf
> exports to use a completely separate set of dma_buf_ops from the
> streaming version.

How about adding get_sgtable, map_sg, unmap_sg to dma_buf_ops. The right
ops need to be installed based on buffer type. As I mentioned before, we
don't know which memory we got until dma_alloc_from_coherent() finds
memory in dev->mem area. So how about using the dma_check_dev_coherent()
to determine which ops we need. These could be set based on buffer type.
vb2_dc_get_dmabuf() can do that.

I think this will work.

thanks,
-- Shuah

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

[Shuah Khan]

On 04/06/2017 06:01 AM, Marek Szyprowski wrote:
> Hi Shuah,
> 
> On 2017-04-05 18:02, Shuah Khan wrote:
>> When coherent DMA memory without struct page is shared, importer
>> fails to find the page and runs into kernel page fault when it
>> tries to dmabuf_ops_attach/map_sg/map_page the invalid page found
>> in the sg_table. Please see www.spinics.net/lists/stable/msg164204.html
>> for more information on this problem.
>>
>> This solution allows coherent DMA memory without struct page to be
>> shared by providing a way for the exporter to tag the DMA buffer as
>> a special buffer without struct page association and passing the
>> information in sg_table to the importer. This information is used
>> in attach/map_sg to avoid cleaning D-cache and mapping.
>>
>> The details of the change are:
>>
>> Framework:
>> - Add a new dma_attrs field to struct scatterlist.
>> - Add a new DMA_ATTR_DEV_COHERENT_NOPAGE attribute to clearly identify
>>Coherent memory without struct page.
>> - Add a new dma_check_dev_coherent() interface to check if memory is
>>the device coherent area. There is no way to tell where the memory
>>returned by dma_alloc_attrs() came from.
>>
>> Exporter logic:
>> - Add logic to vb2_dc_alloc() to call dma_check_dev_coherent() and set
>>DMA_ATTR_DEV_COHERENT_NOPAGE based the results of the check. This is
>>done in the exporter context.
>> - Add logic to arm_dma_get_sgtable() to identify memory without struct
>>page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute. If this attr is
>>set, arm_dma_get_sgtable() will set page as the cpu_addr and update
>>dma_address and dma_attrs fields in struct scatterlist for this sgl.
>>This is done in exporter context when buffer is exported. With this
>>Note: This change is made on top of Russell King's patch that added
>>!pfn_valid(pfn) check to arm_dma_get_sgtable() to error out on invalid
>>pages. Coherent memory without struct page will trigger this error.
>>
>> Importer logic:
>> - Add logic to vb2_dc_dmabuf_ops_attach() to identify memory without
>>struct page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute when it copies
>>the sg_table from the exporter. It will copy dma_attrs and dma_address
>>fields. With this logic, dmabuf_ops_attach will no longer trip on an
>>invalid page.
>> - Add logic to arm_dma_map_sg() to avoid mapping the page when sg_table
>>has DMA_ATTR_DEV_COHERENT_NOPAGE buffer.
>> - Add logic to arm_dma_unmap_sg() to do nothing for sg entries with
>>DMA_ATTR_DEV_COHERENT_NOPAGE attribute.
>>
>> Without this change the following use-case that runs into kernel
>> pagefault when importer tries to attach the exported buffer.
>>
>> With this change it works: (what a relief after watching pagefaults for
>> weeks!!)
>>
>> gst-launch-1.0 filesrc location=~/GH3_MOV_HD.mp4 ! qtdemux ! h264parse ! 
>> v4l2video4dec capture-io-mode=dmabuf ! v4l2video7convert 
>> output-io-mode=dmabuf-import ! kmssink force-modesetting=true
>>
>> I am sending RFC patch to get feedback on the approach and see if I missed
>> anything.
> 
> Frankly, once You decided to hack around dma-buf and issues with coherent,
> carved out memory, it might be a bit better to find the ultimate solution
> instead of the another hack. Please note that it will still not allow to
> share a buffer allocated from carved-out memory and a device, which is
> behind IOMMU.

With your patch s5p-mfc patch series does address the problem for this
use-case for 4.12 onwards. However I am still concerned about prior
release and this pagefault is bad.

Invalid page test partially solves the problem. Would it helpful to
at least prevent the pagfault with a definitive test. Please see my
response to Russell. Let me know your thoughts on that.

> 
> I thought a bit about this and the current shape of dma-buf code.
> 
> IMHO the proper way of solving all those issues would be to replace
> dma-buf internal representation of the memory from struct scatter_list
> to pfn array. This would really solve the problem of buffers which
> cannot be properly represented by scatter lists/struct pages and would
> even allow sharing buffers between all kinds of devices. Scatter-lists
> are also quite over-engineered structures to represent a single buffer
> (pfn array is a bit more compact representation). Also there is a lots
> of buggy code which use scatter-list in a bit creative way (like
> assuming that each page maps to a single scatter list entry for
> example). The only missing piece, required for such change would be
> extending DMA-map

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

[Shuah Khan]

On 04/05/2017 05:14 PM, Russell King - ARM Linux wrote:
> On Wed, Apr 05, 2017 at 10:02:42AM -0600, Shuah Khan wrote:
>> When coherent DMA memory without struct page is shared, importer
>> fails to find the page and runs into kernel page fault when it
>> tries to dmabuf_ops_attach/map_sg/map_page the invalid page found
>> in the sg_table. Please see www.spinics.net/lists/stable/msg164204.html
>> for more information on this problem.
>>
>> This solution allows coherent DMA memory without struct page to be
>> shared by providing a way for the exporter to tag the DMA buffer as
>> a special buffer without struct page association and passing the
>> information in sg_table to the importer. This information is used
>> in attach/map_sg to avoid cleaning D-cache and mapping.
>>
>> The details of the change are:
>>
>> Framework:
>> - Add a new dma_attrs field to struct scatterlist.
>> - Add a new DMA_ATTR_DEV_COHERENT_NOPAGE attribute to clearly identify
>>   Coherent memory without struct page.
>> - Add a new dma_check_dev_coherent() interface to check if memory is
>>   the device coherent area. There is no way to tell where the memory
>>   returned by dma_alloc_attrs() came from.
>>
>> Exporter logic:
>> - Add logic to vb2_dc_alloc() to call dma_check_dev_coherent() and set
>>   DMA_ATTR_DEV_COHERENT_NOPAGE based the results of the check. This is
>>   done in the exporter context.
>> - Add logic to arm_dma_get_sgtable() to identify memory without struct
>>   page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute. If this attr is
>>   set, arm_dma_get_sgtable() will set page as the cpu_addr and update
>>   dma_address and dma_attrs fields in struct scatterlist for this sgl.
>>   This is done in exporter context when buffer is exported. With this
> 
> This sentence appears to just end...
> 
> I'm not convinced that coherent allocations should be setting the "page"
> of a scatterlist to anything that isn't a real struct page or NULL.  It
> is, after all, an error to look up the virtual address etc of the
> scatterlist entry or kmap it when it isn't backed by a struct page.
> 
> I'm actually already passing non-page backed memory through the DMA API
> in armada-drm, although not entirely correctly, and etnaviv handles it
> fine:
> 
> } else if (dobj->linear) {
> /* Single contiguous physical region - no struct page */
> if (sg_alloc_table(sgt, 1, GFP_KERNEL))
> goto free_sgt;
> sg_dma_address(sgt->sgl) = dobj->dev_addr;
> sg_dma_len(sgt->sgl) = dobj->obj.size;
> 
> This is not quite correct, as it assumes (which is safe for it currently)
> that the DMA address is the same on all devices.  On Dove, which is where
> this is used, that is the case, but it's not true elsewhere.  Also note
> that I'm avoid calling dma_map_sg() and dma_unmap_sg() - there's no iommus
> to be considered.

I see. That is not the case for the drivers involved in my use-case. exynos
has iommu and this s5p-mfc exporting buffers to exynos-gsc use-case does
work when iommu is enabled.

> 
> I'd suggest that this follows the same pattern - setting the DMA address
> (more appropriately for generic code) and the DMA length, while leaving
> the virtual address members NULL/0.  However, there's also the
> complication of setting up any IOMMUs that would be necessary.  I haven't
> looked at that, or how it could work.
> 
> I also think this should be documented in the dmabuf API that it can
> pass such scatterlists that are DMA-parameter only.
> 
> Lastly, I'd recommend that anything using this does _not_ provide
> functional kmap/kmap_atomic support for these - kmap and kmap_atomic
> are both out because there's no struct page anyway (and their use would
> probably oops the kernel in this scenario.)  I avoided mmap support in
> armada drm, but if there's a pressing reason and real use case for the
> importer to mmap() the buffers in userspace, it's something I could be
> convinced of.
> 
> What I'm quite certain of is that we do _not_ want to be passing
> coherent memory allocations into the streaming DMA API, not even with
> a special attribute.  The DMA API is about gaining coherent memory
> (shared ownership of the buffer), or mapping system memory to a
> specified device (which can imply unique ownership.)  Trying to mix
> the two together muddies the separation that we have there, and makes
> it harder to explain.  As can be seen from this patch, we'd end up
> needing to add this special DMA_ATTR_DEV_COHERENT_NOPAGE everywhere,
> which is added complexity on top of stuff that is not req

[PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

[Shuah Khan]

When coherent DMA memory without struct page is shared, importer
fails to find the page and runs into kernel page fault when it
tries to dmabuf_ops_attach/map_sg/map_page the invalid page found
in the sg_table. Please see www.spinics.net/lists/stable/msg164204.html
for more information on this problem.

This solution allows coherent DMA memory without struct page to be
shared by providing a way for the exporter to tag the DMA buffer as
a special buffer without struct page association and passing the
information in sg_table to the importer. This information is used
in attach/map_sg to avoid cleaning D-cache and mapping.

The details of the change are:

Framework:
- Add a new dma_attrs field to struct scatterlist.
- Add a new DMA_ATTR_DEV_COHERENT_NOPAGE attribute to clearly identify
  Coherent memory without struct page.
- Add a new dma_check_dev_coherent() interface to check if memory is
  the device coherent area. There is no way to tell where the memory
  returned by dma_alloc_attrs() came from.

Exporter logic:
- Add logic to vb2_dc_alloc() to call dma_check_dev_coherent() and set
  DMA_ATTR_DEV_COHERENT_NOPAGE based the results of the check. This is
  done in the exporter context.
- Add logic to arm_dma_get_sgtable() to identify memory without struct
  page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute. If this attr is
  set, arm_dma_get_sgtable() will set page as the cpu_addr and update
  dma_address and dma_attrs fields in struct scatterlist for this sgl.
  This is done in exporter context when buffer is exported. With this
  Note: This change is made on top of Russell King's patch that added
  !pfn_valid(pfn) check to arm_dma_get_sgtable() to error out on invalid
  pages. Coherent memory without struct page will trigger this error.

Importer logic:
- Add logic to vb2_dc_dmabuf_ops_attach() to identify memory without
  struct page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute when it copies
  the sg_table from the exporter. It will copy dma_attrs and dma_address
  fields. With this logic, dmabuf_ops_attach will no longer trip on an
  invalid page.
- Add logic to arm_dma_map_sg() to avoid mapping the page when sg_table
  has DMA_ATTR_DEV_COHERENT_NOPAGE buffer.
- Add logic to arm_dma_unmap_sg() to do nothing for sg entries with
  DMA_ATTR_DEV_COHERENT_NOPAGE attribute.

Without this change the following use-case that runs into kernel
pagefault when importer tries to attach the exported buffer.

With this change it works: (what a relief after watching pagefaults for
weeks!!)

gst-launch-1.0 filesrc location=~/GH3_MOV_HD.mp4 ! qtdemux ! h264parse ! 
v4l2video4dec capture-io-mode=dmabuf ! v4l2video7convert 
output-io-mode=dmabuf-import ! kmssink force-modesetting=true

I am sending RFC patch to get feedback on the approach and see if I missed
anything.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
 arch/arm/mm/dma-mapping.c  | 34 ++
 drivers/base/dma-coherent.c| 25 +++
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  6 +
 include/linux/dma-mapping.h|  8 ++
 include/linux/scatterlist.h|  1 +
 5 files changed, 69 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 63eabb0..75c6692 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -939,13 +939,28 @@ int arm_dma_get_sgtable(struct device *dev, struct 
sg_table *sgt,
 void *cpu_addr, dma_addr_t handle, size_t size,
 unsigned long attrs)
 {
-   struct page *page = pfn_to_page(dma_to_pfn(dev, handle));
+   unsigned long pfn = dma_to_pfn(dev, handle);
+   struct page *page;
int ret;
 
+   /* If the PFN is not valid, we do not have a struct page. */
+   if (!pfn_valid(pfn)) {
+   /* If memory is from per-device coherent area, use cpu_addr */
+   if (attrs & DMA_ATTR_DEV_COHERENT_NOPAGE)
+   page = cpu_addr;
+   else
+   return -ENXIO;
+   } else
+   page = pfn_to_page(pfn);
+
ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
if (unlikely(ret))
return ret;
 
+   if (attrs & DMA_ATTR_DEV_COHERENT_NOPAGE)
+   sgt->sgl->dma_address = handle;
+
+   sgt->sgl->dma_attrs = attrs;
sg_set_page(sgt->sgl, page, PAGE_ALIGN(size), 0);
return 0;
 }
@@ -1080,10 +1095,17 @@ int arm_dma_map_sg(struct device *dev, struct 
scatterlist *sg, int nents,
 #ifdef CONFIG_NEED_SG_DMA_LENGTH
s->dma_length = s->length;
 #endif
-   s->dma_address = ops->map_page(dev, sg_page(s), s->offset,
+   /*
+* there is no struct page for this DMA buffer.
+* s->dma_address is the handle
+*/
+   if (!(s->dma_attrs & DMA_ATTR_DEV_COHE

Re: [RFC 00/10] V4L2 explicit synchronization support

[Shuah Khan]

Hi Gustavo,

On Mon, Apr 3, 2017 at 1:46 PM, Javier Martinez Canillas
 wrote:
> Hello Mauro and Gustavo,
>
> On 04/03/2017 07:16 AM, Mauro Carvalho Chehab wrote:
>> Hi Gustavo,
>>
>> Em Mon, 13 Mar 2017 16:20:25 -0300
>> Gustavo Padovan  escreveu:
>>
>>> From: Gustavo Padovan 
>>>
>>> Hi,
>>>
>>> This RFC adds support for Explicit Synchronization of shared buffers in 
>>> V4L2.
>>> It uses the Sync File Framework[1] as vector to communicate the fences
>>> between kernel and userspace.
>>
>> Thanks for your work!
>>
>> I looked on your patchset, and I didn't notice anything really weird
>> there. So, instead on reviewing patch per patch, I prefer to discuss
>> about the requirements and API, as depending on it, the code base will
>> change a lot.
>>
>
> Agree that's better to first set on an uAPI and then implement based on that.

Yes. Agreeing on uAPI first would work well.

>
>> I'd like to do some tests with it on devices with mem2mem drivers.
>> My plan is to use an Exynos board for such thing, but I guess that
>> the DRM driver for it currently doesn't. I'm seeing internally if someone
>> could be sure that Exynos driver upstream will become ready for such
>> tests.
>>
>
> Not sure if you should try to do testing before agreeing on an uAPI and
> implementation.

Running some tests might give you a better feel for m2m - export buf - drm
cases without fences on exynos. This could help understand the performance
gains with fences.

>
>> Javier wrote some patches last year meant to implement implicit
>> fences support. What we noticed is that, while his mechanism worked
>> fine for pure capture and pure output devices, when we added a mem2mem
>> device, on a DMABUF+fences pipeline, e. g.:
>>
>>   sensor -> [m2m] -> DRM
>>
>> End everything using fences/DMABUF, the fences mechanism caused dead
>> locks on existing userspace apps.
>>
>> A m2m device has both capture and output devnodes. Both should be
>> queued/dequeued. The capture queue is synchronized internally at the
>> driver with the output buffer[1].
>>
>> [1] The names here are counter-intuitive: "capture" is a devnode
>> where userspace receives a video stream; "output" is a devnode where
>> userspace feeds a video stream.
>>
>> The problem is that adding implicit fences changed the behavior of
>> the ioctls, causing gstreamer to wait forever for buffers to be ready.
>>
>
> The problem was related to trying to make user-space unaware of the implicit
> fences support, and so it tried to QBUF a buffer that had already a pending
> fence. A workaround was to block the second QBUF ioctl if the buffer had a
> pending fence, but this caused the mentioned deadlock since GStreamer wasn't
> expecting the QBUF ioctl to block.
>
>> I suspect that, even with explicit fences, the behavior of Q/DQ
>> will be incompatible with the current behavior (or will require some
>> dirty hacks to make it identical).

One big difference between implicit and explicit is that use-space is aware
of fences in the case of explicit. Can that knowledge be helpful in avoiding
the the problems we have seen with explicit?

>>
>> So, IMHO, the best would be to use a new set of ioctls, when fences are
>> used (like VIDIOC_QFENCE/DQFENCE).
>>
>
> For explicit you can check if there's an input-fence so is different than
> implicit, but still I agree that it would be better to have specific ioctls.
>

It would be nice if we can avoid adding more ioctls. As I mentioned earlier,
user-space is aware that fences are in use. Can we key off of that and make
it a queue property to be used to change the user-space action for fence vs.
no fence case?



thanks,
-- Shuah

Re: [RFC v2 07/11] vb2: dma-contig: Remove redundant sgt_base field

[Shuah Khan]

On Thu, Dec 15, 2016 at 6:24 PM, Laurent Pinchart
 wrote:
> From: Sakari Ailus 
>
> The struct vb2_dc_buf contains two struct sg_table fields: sgt_base and
> dma_sgt. The former is used by DMA-BUF buffers whereas the latter is used
> by USERPTR.
>
> Unify the two, leaving dma_sgt.

I think this patch should be split in two.

1. Unifying dma_sgt and sgt_base

>
> MMAP buffers do not need cache flushing since they have been allocated
> using dma_alloc_coherent().

2. That uses vec to check for checking for no flush needed condition.

>
> Signed-off-by: Sakari Ailus 
> ---
> Changes since v1:
>
> - Test for MMAP or DMABUF type through the vec field instead of the now
>   gone vma field.

What is this gone vma field? Did I miss a patch in the series that
makes this change? This check that is changed used dma_sgt and
db_attach vma

These comments don't agree with the code change.

> - Move the vec field to a USERPTR section in struct vb2_dc_buf, where
>   the vma field was located.
> ---
>  drivers/media/v4l2-core/videobuf2-dma-contig.c | 25 +
>  1 file changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
> b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> index fb6a177be461..2a00d12ffee2 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -30,12 +30,13 @@ struct vb2_dc_buf {
> unsigned long   attrs;
> enum dma_data_direction dma_dir;
> struct sg_table *dma_sgt;
> -   struct frame_vector *vec;
>
> /* MMAP related */
> struct vb2_vmarea_handler   handler;
> atomic_trefcount;
> -   struct sg_table *sgt_base;
> +
> +   /* USERPTR related */
> +   struct frame_vector *vec;
>
> /* DMABUF related */
> struct dma_buf_attachment   *db_attach;
> @@ -95,7 +96,7 @@ static void vb2_dc_prepare(void *buf_priv)
> struct sg_table *sgt = buf->dma_sgt;
>
> /* DMABUF exporter will flush the cache for us */
> -   if (!sgt || buf->db_attach)
> +   if (!buf->vec)
> return;

With the unification dma_sgt is valid for MMAP buffers after vb2_dma_sg_alloc()
if dma_sgt is not null, sync happens - the patch description doesn't seem to be
in sync with the change.

I might be missing something. I think it would help if these two changes are
split since they are really separate changes.

thanks,
-- Shuah

>
> dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
> @@ -108,7 +109,7 @@ static void vb2_dc_finish(void *buf_priv)
> struct sg_table *sgt = buf->dma_sgt;
>
> /* DMABUF exporter will flush the cache for us */
> -   if (!sgt || buf->db_attach)
> +   if (!buf->vec)
> return;
>
> dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, 
> buf->dma_dir);
> @@ -125,9 +126,9 @@ static void vb2_dc_put(void *buf_priv)
> if (!atomic_dec_and_test(>refcount))
> return;
>
> -   if (buf->sgt_base) {
> -   sg_free_table(buf->sgt_base);
> -   kfree(buf->sgt_base);
> +   if (buf->dma_sgt) {
> +   sg_free_table(buf->dma_sgt);
> +   kfree(buf->dma_sgt);
> }
> dma_free_attrs(buf->dev, buf->size, buf->cookie, buf->dma_addr,
>buf->attrs);
> @@ -239,13 +240,13 @@ static int vb2_dc_dmabuf_ops_attach(struct dma_buf 
> *dbuf, struct device *dev,
> /* Copy the buf->base_sgt scatter list to the attachment, as we can't
>  * map the same scatter list to multiple attachments at the same time.
>  */
> -   ret = sg_alloc_table(sgt, buf->sgt_base->orig_nents, GFP_KERNEL);
> +   ret = sg_alloc_table(sgt, buf->dma_sgt->orig_nents, GFP_KERNEL);
> if (ret) {
> kfree(attach);
> return -ENOMEM;
> }
>
> -   rd = buf->sgt_base->sgl;
> +   rd = buf->dma_sgt->sgl;
> wr = sgt->sgl;
> for (i = 0; i < sgt->orig_nents; ++i) {
> sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
> @@ -396,10 +397,10 @@ static struct dma_buf *vb2_dc_get_dmabuf(void 
> *buf_priv, unsigned long flags)
> exp_info.flags = flags;
> exp_info.priv = buf;
>
> -   if (!buf->sgt_base)
> -   buf->sgt_base = vb2_dc_get_base_sgt(buf);
> +   if (!buf->dma_sgt)
> +   buf->dma_sgt = vb2_dc_get_base_sgt(buf);
>
> -   if (WARN_ON(!buf->sgt_base))
> +   if (WARN_ON(!buf->dma_sgt))
> return NULL;
>
> dbuf = dma_buf_export(_info);
> --
> Regards,
>
> Laurent Pinchart
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a 

Re: [RFC v2 05/11] v4l2-core: Don't sync cache for a buffer if so requested

[Shuah Khan]

On Thu, Dec 15, 2016 at 6:24 PM, Laurent Pinchart
 wrote:
> From: Samu Onkalo 
>
> The user may request to the driver (vb2) to skip the cache maintenance
> operations in case the buffer does not need cache synchronisation, e.g. in
> cases where the buffer is passed between hardware blocks without it being
> touched by the CPU.
>
> Also document that the prepare and finish vb2_mem_ops might not get called
> every time the buffer ownership changes between the kernel and the user
> space.
>
> Signed-off-by: Samu Onkalo 
> Signed-off-by: Sakari Ailus 
> ---
> Changes since v1:
>
> - Add a no_cache_sync argument to vb2 core prepare/qbuf/dqbuf functions
>   to get round the inability to access v4l2_buffer flags from vb2 core.

Hmm.. Is this necessary? Lots of changes to pass on single flag.
vb2_core_qbuf(), vb2_core_dqbuf(), and vb2_core_prepare_buf() all have
access to v4l2_buf - void *pb

Would it make it easeir and avoid adding a new parameter all these routines
if we add a vl42-common routine to return the true if
V4L2_BUF_FLAG_NO_CACHE_SYNC is set?

Something along the lines of v4l2_is_no_cache_sync_set()?

thanks,
-- Shuah

> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 101 
> +--
>  drivers/media/v4l2-core/videobuf2-v4l2.c |  14 -
>  include/media/videobuf2-core.h   |  23 ---
>  3 files changed, 97 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 15a83f338072..e5371ef213b0 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -189,6 +189,28 @@ static void __vb2_queue_cancel(struct vb2_queue *q);
>  static void __enqueue_in_driver(struct vb2_buffer *vb);
>
>  /**
> + * __mem_prepare_planes() - call finish mem op for all planes of the buffer
> + */
> +static void __mem_prepare_planes(struct vb2_buffer *vb)
> +{
> +   unsigned int plane;
> +
> +   for (plane = 0; plane < vb->num_planes; ++plane)
> +   call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
> +}
> +
> +/**
> + * __mem_finish_planes() - call finish mem op for all planes of the buffer
> + */
> +static void __mem_finish_planes(struct vb2_buffer *vb)
> +{
> +   unsigned int plane;
> +
> +   for (plane = 0; plane < vb->num_planes; ++plane)
> +   call_void_memop(vb, finish, vb->planes[plane].mem_priv);
> +}
> +
> +/**
>   * __vb2_buf_mem_alloc() - allocate video memory for the given buffer
>   */
>  static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
> @@ -953,20 +975,29 @@ EXPORT_SYMBOL_GPL(vb2_discard_done);
>  /**
>   * __prepare_mmap() - prepare an MMAP buffer
>   */
> -static int __prepare_mmap(struct vb2_buffer *vb, const void *pb)
> +static int __prepare_mmap(struct vb2_buffer *vb, const void *pb,
> + bool no_cache_sync)
>  {
> -   int ret = 0;
> +   int ret;
>
> -   if (pb)
> +   if (pb) {
> ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
>  vb, pb, vb->planes);
> -   return ret ? ret : call_vb_qop(vb, buf_prepare, vb);
> +   if (ret)
> +   return ret;
> +   }
> +
> +   if (!no_cache_sync)
> +   __mem_prepare_planes(vb);
> +
> +   return call_vb_qop(vb, buf_prepare, vb);
>  }
>
>  /**
>   * __prepare_userptr() - prepare a USERPTR buffer
>   */
> -static int __prepare_userptr(struct vb2_buffer *vb, const void *pb)
> +static int __prepare_userptr(struct vb2_buffer *vb, const void *pb,
> +bool no_cache_sync)
>  {
> struct vb2_plane planes[VB2_MAX_PLANES];
> struct vb2_queue *q = vb->vb2_queue;
> @@ -1056,6 +1087,11 @@ static int __prepare_userptr(struct vb2_buffer *vb, 
> const void *pb)
> dprintk(1, "buffer initialization failed\n");
> goto err;
> }
> +
> +   /* This is new buffer memory --- always synchronise cache. */
> +   __mem_prepare_planes(vb);
> +   } else if (!no_cache_sync) {
> +   __mem_prepare_planes(vb);
> }
>
> ret = call_vb_qop(vb, buf_prepare, vb);
> @@ -1083,7 +1119,8 @@ static int __prepare_userptr(struct vb2_buffer *vb, 
> const void *pb)
>  /**
>   * __prepare_dmabuf() - prepare a DMABUF buffer
>   */
> -static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb)
> +static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb,
> +   bool no_cache_sync)
>  {
> struct vb2_plane planes[VB2_MAX_PLANES];
> struct vb2_queue *q = vb->vb2_queue;
> @@ -1197,6 +1234,11 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, 
> const void *pb)
> dprintk(1, "buffer initialization failed\n");
>   

Re: [RFC v2 03/11] vb2: Move cache synchronisation from buffer done to dqbuf handler

[Shuah Khan]

On Thu, Dec 15, 2016 at 6:24 PM, Laurent Pinchart
 wrote:
> From: Sakari Ailus 
>
> The cache synchronisation may be a time consuming operation and thus not
> best performed in an interrupt which is a typical context for
> vb2_buffer_done() calls. This may consume up to tens of ms on some
> machines, depending on the buffer size.
>
> Signed-off-by: Sakari Ailus 
> ---
> Changes since v1:
>
> - Don't rename the 'i' loop counter to 'plane'
> ---
>  drivers/media/v4l2-core/videobuf2-core.c | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 8ba48703b189..15a83f338072 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -889,7 +889,6 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
> vb2_buffer_state state)
>  {
> struct vb2_queue *q = vb->vb2_queue;
> unsigned long flags;
> -   unsigned int plane;
>
> if (WARN_ON(vb->state != VB2_BUF_STATE_ACTIVE))
> return;
> @@ -910,10 +909,6 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
> vb2_buffer_state state)
> dprintk(4, "done processing on buffer %d, state: %d\n",
> vb->index, state);
>
> -   /* sync buffers */
> -   for (plane = 0; plane < vb->num_planes; ++plane)
> -   call_void_memop(vb, finish, vb->planes[plane].mem_priv);
> -
> spin_lock_irqsave(>done_lock, flags);
> if (state == VB2_BUF_STATE_QUEUED ||
> state == VB2_BUF_STATE_REQUEUEING) {
> @@ -1571,6 +1566,10 @@ static void __vb2_dqbuf(struct vb2_buffer *vb)
>
> vb->state = VB2_BUF_STATE_DEQUEUED;
>
> +   /* sync buffers */
> +   for (i = 0; i < vb->num_planes; ++i)
> +   call_void_memop(vb, finish, vb->planes[i].mem_priv);
> +

Does this compile?? Where is "i" defined? Looks like it needs to be added
back in.

-- Shuah

> /* unmap DMABUF buffer */
> if (q->memory == VB2_MEMORY_DMABUF)
> for (i = 0; i < vb->num_planes; ++i) {
> --
> 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 14/15] media: s5p-mfc: Use preallocated block allocator always for MFC v6+

[Shuah Khan]

On 02/27/2017 05:50 AM, Marek Szyprowski wrote:
> Hi Shuah,
> 
> On 2017-02-24 15:23, Shuah Khan wrote:
>> On Thu, Feb 23, 2017 at 11:26 PM, Marek Szyprowski
>> <m.szyprow...@samsung.com> wrote:
>>> On 2017-02-23 22:43, Shuah Khan wrote:
>>>> On Tue, Feb 14, 2017 at 12:52 AM, Marek Szyprowski
>>>> <m.szyprow...@samsung.com> wrote:
>>>>> It turned out that all versions of MFC v6+ hardware doesn't have a strict
>>>>> requirement for ALL buffers to be allocated on higher addresses than the
>>>>> firmware base like it was documented for MFC v5. This requirement is true
>>>>> only for the device and per-context buffers. All video data buffers can
>>>>> be
>>>>> allocated anywhere for all MFC v6+ versions. Basing on this fact, the
>>>>> special DMA configuration based on two reserved memory regions is not
>>>>> really needed for MFC v6+ devices, because the memory requirements for
>>>>> the
>>>>> firmware, device and per-context buffers can be fulfilled by the simple
>>>>> probe-time pre-allocated block allocator instroduced in previous patch.
>>>>>
>>>>> This patch enables support for such pre-allocated block based allocator
>>>>> always for MFC v6+ devices. Due to the limitations of the memory
>>>>> management
>>>>> subsystem the largest supported size of the pre-allocated buffer when no
>>>>> CMA (Contiguous Memory Allocator) is enabled is 4MiB.
>>>>>
>>>>> This patch also removes the requirement to provide two reserved memory
>>>>> regions for MFC v6+ devices in device tree. Now the driver is fully
>>>>> functional without them.
>>>>>
>>>>> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
>>>> Hi Marek,
>>>>
>>>> This patch breaks display manager. exynos_drm_gem_create() isn't happy.
>>>> dmesg and console are flooded with
>>>>
>>>> odroid login: [  209.170566] [drm:exynos_drm_gem_create] *ERROR* failed to
>>>> allo.
>>>> [  212.173222] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  215.354790] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  218.736464] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  221.837128] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  226.284827] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  229.242498] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  232.063150] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  235.73] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  239.472061] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  242.567465] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  246.500541] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  249.996018] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  253.837272] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  257.048782] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  260.084819] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  263.448611] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  266.271074] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  269.011558] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  272.039066] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  275.404938] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  278.339033] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  281.274751] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  284.641202] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>>>> buffer.
>>>> [  287.461039] [drm:exynos_drm_gem_create] *

Re: [PATCH 14/15] media: s5p-mfc: Use preallocated block allocator always for MFC v6+

[Shuah Khan]

Hi Marek,

On Thu, Feb 23, 2017 at 11:26 PM, Marek Szyprowski
<m.szyprow...@samsung.com> wrote:
> Hi Shuah
>
>
>
> On 2017-02-23 22:43, Shuah Khan wrote:
>>
>> On Tue, Feb 14, 2017 at 12:52 AM, Marek Szyprowski
>> <m.szyprow...@samsung.com> wrote:
>>>
>>> It turned out that all versions of MFC v6+ hardware doesn't have a strict
>>> requirement for ALL buffers to be allocated on higher addresses than the
>>> firmware base like it was documented for MFC v5. This requirement is true
>>> only for the device and per-context buffers. All video data buffers can
>>> be
>>> allocated anywhere for all MFC v6+ versions. Basing on this fact, the
>>> special DMA configuration based on two reserved memory regions is not
>>> really needed for MFC v6+ devices, because the memory requirements for
>>> the
>>> firmware, device and per-context buffers can be fulfilled by the simple
>>> probe-time pre-allocated block allocator instroduced in previous patch.
>>>
>>> This patch enables support for such pre-allocated block based allocator
>>> always for MFC v6+ devices. Due to the limitations of the memory
>>> management
>>> subsystem the largest supported size of the pre-allocated buffer when no
>>> CMA (Contiguous Memory Allocator) is enabled is 4MiB.
>>>
>>> This patch also removes the requirement to provide two reserved memory
>>> regions for MFC v6+ devices in device tree. Now the driver is fully
>>> functional without them.
>>>
>>> Signed-off-by: Marek Szyprowski <m.szyprow...@samsung.com>
>>
>> Hi Marek,
>>
>> This patch breaks display manager. exynos_drm_gem_create() isn't happy.
>> dmesg and console are flooded with
>>
>> odroid login: [  209.170566] [drm:exynos_drm_gem_create] *ERROR* failed to
>> allo.
>> [  212.173222] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  215.354790] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  218.736464] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  221.837128] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  226.284827] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  229.242498] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  232.063150] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  235.73] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  239.472061] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  242.567465] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  246.500541] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  249.996018] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  253.837272] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  257.048782] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  260.084819] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  263.448611] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  266.271074] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  269.011558] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  272.039066] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  275.404938] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  278.339033] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  281.274751] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  284.641202] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  287.461039] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  291.062011] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  294.746870] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>> [  298.246570] [drm:exynos_drm_gem_create] *ERROR* failed to allocate
>> buffer.
>>
>> I don't think this is an acceptable behavior. It is a regression.
>
>
> This is a really poor bug report... Could you elaborate a bit how to
> reproduce
> this? Could you provide your kernel config and information about test
> environment?

Yeah. I should have give you more information. My bad.

>
> I suspect that yo

Re: [PATCH 14/15] media: s5p-mfc: Use preallocated block allocator always for MFC v6+

[Shuah Khan]

On Tue, Feb 14, 2017 at 12:52 AM, Marek Szyprowski
 wrote:
> It turned out that all versions of MFC v6+ hardware doesn't have a strict
> requirement for ALL buffers to be allocated on higher addresses than the
> firmware base like it was documented for MFC v5. This requirement is true
> only for the device and per-context buffers. All video data buffers can be
> allocated anywhere for all MFC v6+ versions. Basing on this fact, the
> special DMA configuration based on two reserved memory regions is not
> really needed for MFC v6+ devices, because the memory requirements for the
> firmware, device and per-context buffers can be fulfilled by the simple
> probe-time pre-allocated block allocator instroduced in previous patch.
>
> This patch enables support for such pre-allocated block based allocator
> always for MFC v6+ devices. Due to the limitations of the memory management
> subsystem the largest supported size of the pre-allocated buffer when no
> CMA (Contiguous Memory Allocator) is enabled is 4MiB.
>
> This patch also removes the requirement to provide two reserved memory
> regions for MFC v6+ devices in device tree. Now the driver is fully
> functional without them.
>
> Signed-off-by: Marek Szyprowski 

Hi Marek,

This patch breaks display manager. exynos_drm_gem_create() isn't happy.
dmesg and console are flooded with

odroid login: [  209.170566] [drm:exynos_drm_gem_create] *ERROR* failed to allo.
[  212.173222] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  215.354790] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  218.736464] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  221.837128] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  226.284827] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  229.242498] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  232.063150] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  235.73] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  239.472061] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  242.567465] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  246.500541] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  249.996018] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  253.837272] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  257.048782] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  260.084819] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  263.448611] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  266.271074] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  269.011558] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  272.039066] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  275.404938] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  278.339033] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  281.274751] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  284.641202] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  287.461039] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  291.062011] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  294.746870] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.
[  298.246570] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer.

I don't think this is an acceptable behavior. It is a regression.

thanks,
-- Shuah

> ---
>  Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc.c| 9 ++---
>  2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
> b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> index 2c901286d818..d3404b5d4d17 100644
> --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
> +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> @@ -28,7 +28,7 @@ Optional properties:
>- memory-region : from reserved memory binding: phandles to two reserved
> memory regions, first is for "left" mfc memory bus interfaces,
> second if for the "right" mfc memory bus, used when no SYSMMU
> -   support is available
> +   support is available; used only by MFC v5 present in Exynos4 SoCs
>
>  Obsolete properties:
>- samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index 8fc6fe4ba087..36f0aec2a1b3 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1178,9 +1178,12 @@ static void s5p_mfc_unconfigure_2port_memory(struct 
> s5p_mfc_dev *mfc_dev)
>  static int 

Re: [PATCH v2 08/15] media: s5p-mfc: Move firmware allocation to DMA configure function

[Shuah Khan]

On Mon, Feb 20, 2017 at 6:38 AM, Marek Szyprowski
 wrote:
> To complete DMA memory configuration for MFC device, allocation of the
> firmware buffer is needed, because some parameters are dependant on its base
> address. Till now, this has been handled in the s5p_mfc_alloc_firmware()
> function. This patch moves that logic to s5p_mfc_configure_dma_memory() to
> keep DMA memory related operations in a single place. This way
> s5p_mfc_alloc_firmware() is simplified and does what it name says. The
> other consequence of this change is moving s5p_mfc_alloc_firmware() call
> from the s5p_mfc_probe() function to the s5p_mfc_configure_dma_memory().

Overall looks good. This patch makes subtle change in the dma and firwmare
initialization sequence. Might be okay, but wanted to call out just in case,

Before this change:
vb2_dma_contig_set_max_seg_size() is done for both iommu and non-iommu
case before s5p_mfc_alloc_firmware(). With this change setting
dma_contig max size happens after s5p_mfc_alloc_firmware(). From what
I can tell this might not be an issue.
vb2_dma_contig_clear_max_seg_size() still happens after
s5p_mfc_release_firmware(), so that part hasn't changed.

Do any of the dma_* calls made from s5p_mfc_alloc_firmware() and later
during the dma congiguration sequence depend on dmap_parms being
allocated? Doesn't looks like it from what I can tell, but safe to
ask.

thanks,
-- Shuah

>
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc.c  | 62 
> +--
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 31 --
>  2 files changed, 49 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index bc1aeb25ebeb..4403487a494a 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1110,6 +1110,11 @@ static struct device *s5p_mfc_alloc_memdev(struct 
> device *dev,
>  static int s5p_mfc_configure_dma_memory(struct s5p_mfc_dev *mfc_dev)
>  {
> struct device *dev = _dev->plat_dev->dev;
> +   void *bank2_virt;
> +   dma_addr_t bank2_dma_addr;
> +   unsigned long align_size = 1 << MFC_BASE_ALIGN_ORDER;
> +   struct s5p_mfc_priv_buf *fw_buf = _dev->fw_buf;
> +   int ret;
>
> /*
>  * When IOMMU is available, we cannot use the default configuration,
> @@ -1122,14 +1127,21 @@ static int s5p_mfc_configure_dma_memory(struct 
> s5p_mfc_dev *mfc_dev)
> if (exynos_is_iommu_available(dev)) {
> int ret = exynos_configure_iommu(dev, S5P_MFC_IOMMU_DMA_BASE,
>  S5P_MFC_IOMMU_DMA_SIZE);
> -   if (ret == 0) {
> -   mfc_dev->mem_dev[BANK1_CTX] =
> -   mfc_dev->mem_dev[BANK2_CTX] = dev;
> -   vb2_dma_contig_set_max_seg_size(dev,
> -   DMA_BIT_MASK(32));
> +   if (ret)
> +   return ret;
> +
> +   mfc_dev->mem_dev[BANK1_CTX] = mfc_dev->mem_dev[BANK2_CTX] = 
> dev;
> +   ret = s5p_mfc_alloc_firmware(mfc_dev);
> +   if (ret) {
> +   exynos_unconfigure_iommu(dev);
> +   return ret;
> }
>
> -   return ret;
> +   mfc_dev->dma_base[BANK1_CTX] = fw_buf->dma;
> +   mfc_dev->dma_base[BANK2_CTX] = fw_buf->dma;
> +   vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
> +
> +   return 0;
> }
>
> /*
> @@ -1147,6 +1159,35 @@ static int s5p_mfc_configure_dma_memory(struct 
> s5p_mfc_dev *mfc_dev)
> return -ENODEV;
> }
>
> +   /* Allocate memory for firmware and initialize both banks addresses */
> +   ret = s5p_mfc_alloc_firmware(mfc_dev);
> +   if (ret) {
> +   device_unregister(mfc_dev->mem_dev[BANK2_CTX]);
> +   device_unregister(mfc_dev->mem_dev[BANK1_CTX]);
> +   return ret;
> +   }
> +
> +   mfc_dev->dma_base[BANK1_CTX] = fw_buf->dma;
> +
> +   bank2_virt = dma_alloc_coherent(mfc_dev->mem_dev[BANK2_CTX], 
> align_size,
> +   _dma_addr, GFP_KERNEL);
> +   if (!bank2_virt) {
> +   mfc_err("Allocating bank2 base failed\n");
> +   s5p_mfc_release_firmware(mfc_dev);
> +   device_unregister(mfc_dev->mem_dev[BANK2_CTX]);
> +   device_unregister(mfc_dev->mem_dev[BANK1_CTX]);
> +   return -ENOMEM;
> +   }
> +
> +   /* Valid buffers passed to MFC encoder with LAST_FRAME command
> +* should not have address of bank2 - MFC will treat it as a null 
> frame.
> +* To avoid such situation we set bank2 address below the pool 
> address.
> +*/
> +   

Re: [PATCH v2 03/15] media: s5p-mfc: Replace mem_dev_* entries with an array

[Shuah Khan]

On Mon, Feb 20, 2017 at 6:38 AM, Marek Szyprowski
 wrote:
> Internal MFC driver device structure contains two pointers to devices used
> for DMA memory allocation: mem_dev_l and mem_dev_r. Replace them with the
> mem_dev[] array and use defines for accessing particular banks. This will
> help to simplify code in the next patches.

Hi Marek,

The change looks good to me. One comment thought that it would be
good to keep the left and right banks in the driver code to be in sync
with the DT nomenclature.

BANK_L_CTX instead of BANK1_CTX
BANK_R_CTX instead of BANK2_CTX

>
> Signed-off-by: Marek Szyprowski 
> Reviewed-by: Javier Martinez Canillas 
> Tested-by: Javier Martinez Canillas 
> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc.c| 31 +---
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 11 -
>  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 23 +-
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|  8 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 10 
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 32 
> ++---
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 15 ++--
>  7 files changed, 69 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index ad3d7377f40d..f7664910f12c 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1123,7 +1123,8 @@ static int s5p_mfc_configure_dma_memory(struct 
> s5p_mfc_dev *mfc_dev)
> int ret = exynos_configure_iommu(dev, S5P_MFC_IOMMU_DMA_BASE,
>  S5P_MFC_IOMMU_DMA_SIZE);
> if (ret == 0)
> -   mfc_dev->mem_dev_l = mfc_dev->mem_dev_r = dev;
> +   mfc_dev->mem_dev[BANK1_CTX] =
> +   mfc_dev->mem_dev[BANK2_CTX] = dev;
> return ret;
> }
>
> @@ -1131,14 +1132,14 @@ static int s5p_mfc_configure_dma_memory(struct 
> s5p_mfc_dev *mfc_dev)
>  * Create and initialize virtual devices for accessing
>  * reserved memory regions.
>  */
> -   mfc_dev->mem_dev_l = s5p_mfc_alloc_memdev(dev, "left",
> - MFC_BANK1_ALLOC_CTX);
> -   if (!mfc_dev->mem_dev_l)
> +   mfc_dev->mem_dev[BANK1_CTX] = s5p_mfc_alloc_memdev(dev, "left",
> +  BANK1_CTX);
> +   if (!mfc_dev->mem_dev[BANK1_CTX])
> return -ENODEV;
> -   mfc_dev->mem_dev_r = s5p_mfc_alloc_memdev(dev, "right",
> - MFC_BANK2_ALLOC_CTX);
> -   if (!mfc_dev->mem_dev_r) {
> -   device_unregister(mfc_dev->mem_dev_l);
> +   mfc_dev->mem_dev[BANK2_CTX] = s5p_mfc_alloc_memdev(dev, "right",
> +  BANK2_CTX);
> +   if (!mfc_dev->mem_dev[BANK2_CTX]) {
> +   device_unregister(mfc_dev->mem_dev[BANK1_CTX]);
> return -ENODEV;
> }
>
> @@ -1154,8 +1155,8 @@ static void s5p_mfc_unconfigure_dma_memory(struct 
> s5p_mfc_dev *mfc_dev)
> return;
> }
>
> -   device_unregister(mfc_dev->mem_dev_l);
> -   device_unregister(mfc_dev->mem_dev_r);
> +   device_unregister(mfc_dev->mem_dev[BANK1_CTX]);
> +   device_unregister(mfc_dev->mem_dev[BANK2_CTX]);
>  }
>
>  /* MFC probe function */
> @@ -1213,8 +1214,10 @@ static int s5p_mfc_probe(struct platform_device *pdev)
> goto err_dma;
> }
>
> -   vb2_dma_contig_set_max_seg_size(dev->mem_dev_l, DMA_BIT_MASK(32));
> -   vb2_dma_contig_set_max_seg_size(dev->mem_dev_r, DMA_BIT_MASK(32));
> +   vb2_dma_contig_set_max_seg_size(dev->mem_dev[BANK1_CTX],
> +   DMA_BIT_MASK(32));
> +   vb2_dma_contig_set_max_seg_size(dev->mem_dev[BANK2_CTX],
> +   DMA_BIT_MASK(32));
>
> mutex_init(>mfc_mutex);
> init_waitqueue_head(>queue);
> @@ -1348,8 +1351,8 @@ static int s5p_mfc_remove(struct platform_device *pdev)
> v4l2_device_unregister(>v4l2_dev);
> s5p_mfc_release_firmware(dev);
> s5p_mfc_unconfigure_dma_memory(dev);
> -   vb2_dma_contig_clear_max_seg_size(dev->mem_dev_l);
> -   vb2_dma_contig_clear_max_seg_size(dev->mem_dev_r);
> +   vb2_dma_contig_clear_max_seg_size(dev->mem_dev[BANK1_CTX]);
> +   vb2_dma_contig_clear_max_seg_size(dev->mem_dev[BANK2_CTX]);
>
> s5p_mfc_final_pm(dev);
> return 0;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index 2f1387a4c386..27d4c864e06e 100644
> --- 

[PATCH v2] media: s5p_mfc print buf pointer in hex constistently

[Shuah Khan]

Fix s5p_mfc_set_dec_frame_buffer_v6() to print buffer pointer in hex to be
consistent with the rest of the messages in the routine.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---

Fixed commit log. No code changes. Thanks for the catch.

 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index d6f207e..fc45980 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -497,7 +497,7 @@ static int s5p_mfc_set_dec_frame_buffer_v6(struct 
s5p_mfc_ctx *ctx)
}
}
 
-   mfc_debug(2, "Buf1: %zu, buf_size1: %d (frames %d)\n",
+   mfc_debug(2, "Buf1: %zx, buf_size1: %d (frames %d)\n",
buf_addr1, buf_size1, ctx->total_dpb_count);
if (buf_size1 < 0) {
mfc_debug(2, "Not enough memory has been allocated.\n");
-- 
2.7.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

[PATCH] media: fix s5p_mfc_set_dec_frame_buffer_v6() to print buf size in hex

[Shuah Khan]

Fix s5p_mfc_set_dec_frame_buffer_v6() to print buffer size in hex to be
consistent with the rest of the messages in the routine.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index d6f207e..fc45980 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -497,7 +497,7 @@ static int s5p_mfc_set_dec_frame_buffer_v6(struct 
s5p_mfc_ctx *ctx)
}
}
 
-   mfc_debug(2, "Buf1: %zu, buf_size1: %d (frames %d)\n",
+   mfc_debug(2, "Buf1: %zx, buf_size1: %d (frames %d)\n",
buf_addr1, buf_size1, ctx->total_dpb_count);
if (buf_size1 < 0) {
mfc_debug(2, "Not enough memory has been allocated.\n");
-- 
2.7.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

[PATCH] media: s5p_mfc - remove unneeded io_modes initialzation in s5p_mfc_open()

[Shuah Khan]

Remove unneeded io_modes initialzation in s5p_mfc_open(). It gets done
right below in vdev == dev->vfd_dec conditional.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index bb0a588..20beaa2 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -866,7 +866,6 @@ static int s5p_mfc_open(struct file *file)
/* Init videobuf2 queue for OUTPUT */
q = >vq_src;
q->type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
-   q->io_modes = VB2_MMAP;
q->drv_priv = >fh;
q->lock = >mfc_mutex;
if (vdev == dev->vfd_dec) {
-- 
2.7.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] [media] exynos-gsc: Avoid spamming the log on VIDIOC_TRY_FMT

[Shuah Khan]

On 01/24/2017 02:42 PM, Javier Martinez Canillas wrote:
> There isn't an ioctl to enum the supported field orders, so a user-space
> application can call VIDIOC_TRY_FMT using different field orders to know
> if one is supported. For example, GStreamer does this so during playback
> dozens of the following messages appear in the kernel log buffer:
> 
> [ 442.143393] Not supported field order(4)
> 
> Instead of printing this as an error, just keep it as debug information.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  drivers/media/platform/exynos-gsc/gsc-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
> b/drivers/media/platform/exynos-gsc/gsc-core.c
> index 8524fe15fa80..678b600f0500 100644
> --- a/drivers/media/platform/exynos-gsc/gsc-core.c
> +++ b/drivers/media/platform/exynos-gsc/gsc-core.c
> @@ -408,7 +408,7 @@ int gsc_try_fmt_mplane(struct gsc_ctx *ctx, struct 
> v4l2_format *f)
>   if (pix_mp->field == V4L2_FIELD_ANY)
>   pix_mp->field = V4L2_FIELD_NONE;
>   else if (pix_mp->field != V4L2_FIELD_NONE) {
> - pr_err("Not supported field order(%d)\n", pix_mp->field);
> + pr_debug("Not supported field order(%d)\n", pix_mp->field);

It make sense to leave it as an error, but print only once perhaps.
The down side to making this debug is that it becomes harder to
figure out when we run into this case.

thanks,
-- Shuah

>   return -EINVAL;
>   }
>  
> 

--
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: Media summit in Feb? - Was: Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed

[Shuah Khan]

On Tue, Dec 20, 2016 at 6:31 PM, Mauro Carvalho Chehab
 wrote:
> Em Mon, 19 Dec 2016 07:28:29 -0200
> Mauro Carvalho Chehab  escreveu:
>
>> Em Fri, 16 Dec 2016 15:45:10 +0100
>> Hans Verkuil  escreveu:
>>
>> > We really need a whiteboard for this :-(
>>
>> Well, we could schedule a media summit together with ELC NA.
>>
>> ELC will be in Feb, 21-23 in Portland.
>
> Btw, I'm pre reserving a room for us in Feb, 20, assuming that
> people can make it.
>

Hi Mauro,

I can make it.
>
> Thanks,
> Mauro

thanks,
-- Shuah
> --
> 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
--
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 v3 21/21] omap3isp: Don't rely on devm for memory resource management

[Shuah Khan]

On 12/16/2016 06:32 AM, Sakari Ailus wrote:
> Hi Laurent,
> 
> On Thu, Dec 15, 2016 at 01:23:50PM +0200, Laurent Pinchart wrote:
>>> @@ -1596,7 +1604,6 @@ static void isp_unregister_entities(struct isp_device
>>> *isp) omap3isp_stat_unregister_entities(>isp_af);
>>> omap3isp_stat_unregister_entities(>isp_hist);
>>>
>>> -   v4l2_device_unregister(>v4l2_dev);
>>
>> This isn't correct. The v4l2_device instance should be unregistered here, to 
>> make sure that the subdev nodes are unregistered too. And even if moving the 
>> function call was correct, it should be done in a separate patch as it's 
>> unrelated to $SUBJECT.
> 
> I think I tried to fix another problem here we haven't considered before,
> which is that v4l2_device_unregister() also unregisters the entities through
> media_device_unregister_entity(). This will set the media device of the
> graph objects NULL.
> 
> I'll see whether something could be done to that.
> 

Right That is what I was pointing out, when I said the cleanup routines are
done in the wrong place. Entity registration and unregistration are distributed
in nature. v4l2 register will register entities and unregister will unregister
its entities. dvb will do the same.

So essentially entities get added and removed when any of these drivers get
unbound. Please see the following I posted on

[RFC v3 00/21] Make use of kref in media device, grab references as needed

> v4l2-core registers and unregisters entities and so does dvb-core. So when a
> driver unregisters video and dvb, these entities get deleted. So we have a
> distributed mode of registering and unregistering entities. We also have
> ioctls (video, dvb, and media) accessing these entities. So where do we make
> changes to ensure entities stick around until all users exit?
>
> Ref-counting entities won't work if they are embedded - like in the case of
> struct video_device which embeds the media entity. When struct video goes
> away then entity will disappear. So we do have a complex lifetime model here
> that we need to figure out how to fix.

thanks,
-- Shuah
--
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/2] media: omap3isp fix media_entity_cleanup() after media device unregister

[Shuah Khan]

On 12/15/2016 03:32 PM, Laurent Pinchart wrote:
> Hello Shuah,
> 
> Thank you for the patch.
> 
> On Thursday 15 Dec 2016 12:40:07 Shuah Khan wrote:
>> During unbind isp_remove() media_entity_cleanup() after it unregisters the
> 
> I assume you meant "During unbind isp_remove() calls media_entity_cleanup()"
> 
>> media_device. Cleanup routine calls media_entity_cleanup() accessing subdev
>> entities that have been removed. This will cause problems during unbind.
> 
> What problems ? media_entity_cleanup() is a no-op. And regardless of that, 
> you 
> shouldn't remove the function call (unless the function is considered 
> deprecated, in which case it should be removed completely, and that should be 
> discussed beforehand) but move it to the appropriate place.

It is in the wrong place for one thing, It accesses entity after it
is removed. It could be moved to the right place or like you said,
remove media_entity_cleanup() interface as it does nothing and we
don't seem to have any concrete future plan for what it do.

> 
>> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
>> ---
>>  drivers/media/platform/omap3isp/ispccdc.c| 1 -
>>  drivers/media/platform/omap3isp/ispccp2.c| 1 -
>>  drivers/media/platform/omap3isp/ispcsi2.c| 1 -
>>  drivers/media/platform/omap3isp/isppreview.c | 1 -
>>  drivers/media/platform/omap3isp/ispresizer.c | 1 -
>>  drivers/media/platform/omap3isp/ispstat.c| 1 -
>>  drivers/media/platform/omap3isp/ispvideo.c   | 1 -
>>  7 files changed, 7 deletions(-)
>>
>> diff --git a/drivers/media/platform/omap3isp/ispccdc.c
>> b/drivers/media/platform/omap3isp/ispccdc.c index 882310e..6d27e48 100644
>> --- a/drivers/media/platform/omap3isp/ispccdc.c
>> +++ b/drivers/media/platform/omap3isp/ispccdc.c
>> @@ -2726,7 +2726,6 @@ void omap3isp_ccdc_cleanup(struct isp_device *isp)
>>  struct isp_ccdc_device *ccdc = >isp_ccdc;
>>
>>  omap3isp_video_cleanup(>video_out);
>> -media_entity_cleanup(>subdev.entity);
>>
>>  /* Free LSC requests. As the CCDC is stopped there's no active 
> request,
>>   * so only the pending request and the free queue need to be handled.
>> diff --git a/drivers/media/platform/omap3isp/ispccp2.c
>> b/drivers/media/platform/omap3isp/ispccp2.c index ca09523..4c1e7f0 100644
>> --- a/drivers/media/platform/omap3isp/ispccp2.c
>> +++ b/drivers/media/platform/omap3isp/ispccp2.c
>> @@ -1162,5 +1162,4 @@ void omap3isp_ccp2_cleanup(struct isp_device *isp)
>>  struct isp_ccp2_device *ccp2 = >isp_ccp2;
>>
>>  omap3isp_video_cleanup(>video_in);
>> -media_entity_cleanup(>subdev.entity);
>>  }
>> diff --git a/drivers/media/platform/omap3isp/ispcsi2.c
>> b/drivers/media/platform/omap3isp/ispcsi2.c index f75a1be..840756e 100644
>> --- a/drivers/media/platform/omap3isp/ispcsi2.c
>> +++ b/drivers/media/platform/omap3isp/ispcsi2.c
>> @@ -1318,5 +1318,4 @@ void omap3isp_csi2_cleanup(struct isp_device *isp)
>>  struct isp_csi2_device *csi2a = >isp_csi2a;
>>
>>  omap3isp_video_cleanup(>video_out);
>> -media_entity_cleanup(>subdev.entity);
>>  }
>> diff --git a/drivers/media/platform/omap3isp/isppreview.c
>> b/drivers/media/platform/omap3isp/isppreview.c index ac30a0f..a179dac
>> 100644
>> --- a/drivers/media/platform/omap3isp/isppreview.c
>> +++ b/drivers/media/platform/omap3isp/isppreview.c
>> @@ -2348,5 +2348,4 @@ void omap3isp_preview_cleanup(struct isp_device *isp)
>>  v4l2_ctrl_handler_free(>ctrls);
>>  omap3isp_video_cleanup(>video_in);
>>  omap3isp_video_cleanup(>video_out);
>> -media_entity_cleanup(>subdev.entity);
>>  }
>> diff --git a/drivers/media/platform/omap3isp/ispresizer.c
>> b/drivers/media/platform/omap3isp/ispresizer.c index 0b6a875..d22a54a
>> 100644
>> --- a/drivers/media/platform/omap3isp/ispresizer.c
>> +++ b/drivers/media/platform/omap3isp/ispresizer.c
>> @@ -1791,5 +1791,4 @@ void omap3isp_resizer_cleanup(struct isp_device *isp)
>>
>>  omap3isp_video_cleanup(>video_in);
>>  omap3isp_video_cleanup(>video_out);
>> -media_entity_cleanup(>subdev.entity);
>>  }
>> diff --git a/drivers/media/platform/omap3isp/ispstat.c
>> b/drivers/media/platform/omap3isp/ispstat.c index 1b9217d..47b8e43 100644
>> --- a/drivers/media/platform/omap3isp/ispstat.c
>> +++ b/drivers/media/platform/omap3isp/ispstat.c
>> @@ -1055,7 +1055,6 @@ int omap3isp_stat_init(struct ispstat *stat, const
>> char *name,
>>
>>  void omap3isp_stat_clea

Re: [PATCH 2/2] media: omap3isp change to devm for resources

[Shuah Khan]

On 12/15/2016 03:33 PM, Laurent Pinchart wrote:
> Hi Shuah,
> 
> Thank you for the patch.
> 
> Sakari has submitted a similar patch as part of his kref series. Please use 
> it 
> as a base point and rework it if you want to get it merged separately. I've 
> reviewed the patch and left quite a few comments that need to be addressed.
> 

I really don't mind if Sakari uses this patch as is and makes the changes
you requested and submits devm removal as an independent patch.

My intent behind sending this one is to help him out since I already did
this patch that is on top of 4.9-rc8 without any dependencies on Sakari's
RFC patch.

thanks,
-- Shuah

> On Thursday 15 Dec 2016 12:40:08 Shuah Khan wrote:
>> Using devm resources that have external dependencies such as a dev
>> for a file handler could result in devm resources getting released
>> durin unbind while an application has the file open holding pointer
>> to the devm resource. This results in use-after-free errors when the
>> application exits.
>>
>> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
>> ---
>>  drivers/media/platform/omap3isp/isp.c | 71 
>>  drivers/media/platform/omap3isp/ispccp2.c | 10 +++-
>>  drivers/media/platform/omap3isp/isph3a_aewb.c | 21 +---
>>  drivers/media/platform/omap3isp/isph3a_af.c   | 21 +---
>>  drivers/media/platform/omap3isp/isphist.c |  5 +-
>>  5 files changed, 92 insertions(+), 36 deletions(-)
> 

--
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 0/2] omap3 devm usage removal

[Shuah Khan]

This patch series contains two patches. The first one removes
calls to media_entity_cleanup() after  media device has been
unregistered. The second one removes devm usage.

Shuah Khan (2):
  media: omap3isp fix media_entity_cleanup() after media device
unregister
  media: omap3isp change to devm for resources

 drivers/media/platform/omap3isp/isp.c | 71 +++
 drivers/media/platform/omap3isp/ispccdc.c |  1 -
 drivers/media/platform/omap3isp/ispccp2.c | 11 +++--
 drivers/media/platform/omap3isp/ispcsi2.c |  1 -
 drivers/media/platform/omap3isp/isph3a_aewb.c | 21 +---
 drivers/media/platform/omap3isp/isph3a_af.c   | 21 +---
 drivers/media/platform/omap3isp/isphist.c |  5 +-
 drivers/media/platform/omap3isp/isppreview.c  |  1 -
 drivers/media/platform/omap3isp/ispresizer.c  |  1 -
 drivers/media/platform/omap3isp/ispstat.c |  1 -
 drivers/media/platform/omap3isp/ispvideo.c|  1 -
 11 files changed, 92 insertions(+), 43 deletions(-)

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

[PATCH 2/2] media: omap3isp change to devm for resources

[Shuah Khan]

Using devm resources that have external dependencies such as a dev
for a file handler could result in devm resources getting released
durin unbind while an application has the file open holding pointer
to the devm resource. This results in use-after-free errors when the
application exits.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
 drivers/media/platform/omap3isp/isp.c | 71 +++
 drivers/media/platform/omap3isp/ispccp2.c | 10 +++-
 drivers/media/platform/omap3isp/isph3a_aewb.c | 21 +---
 drivers/media/platform/omap3isp/isph3a_af.c   | 21 +---
 drivers/media/platform/omap3isp/isphist.c |  5 +-
 5 files changed, 92 insertions(+), 36 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 0321d84..a11c509 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -1374,7 +1374,7 @@ static int isp_get_clocks(struct isp_device *isp)
unsigned int i;
 
for (i = 0; i < ARRAY_SIZE(isp_clocks); ++i) {
-   clk = devm_clk_get(isp->dev, isp_clocks[i]);
+   clk = clk_get(isp->dev, isp_clocks[i]);
if (IS_ERR(clk)) {
dev_err(isp->dev, "clk_get %s failed\n", isp_clocks[i]);
return PTR_ERR(clk);
@@ -1386,6 +1386,14 @@ static int isp_get_clocks(struct isp_device *isp)
return 0;
 }
 
+static void isp_put_clocks(struct isp_device *isp)
+{
+   unsigned int i;
+
+   for (i = 0; i < ARRAY_SIZE(isp_clocks); ++i)
+   clk_put(isp->clock[i]);
+}
+
 /*
  * omap3isp_get - Acquire the ISP resource.
  *
@@ -2015,6 +2023,11 @@ static int isp_remove(struct platform_device *pdev)
 
media_entity_enum_cleanup(>crashed);
 
+   regulator_put(isp->isp_csiphy2.vdd);
+   regulator_put(isp->isp_csiphy1.vdd);
+
+   isp_put_clocks(isp);
+   kfree(isp);
return 0;
 }
 
@@ -2107,8 +2120,8 @@ static int isp_of_parse_nodes(struct device *dev,
 {
struct device_node *node = NULL;
 
-   notifier->subdevs = devm_kcalloc(
-   dev, ISP_MAX_SUBDEVS, sizeof(*notifier->subdevs), GFP_KERNEL);
+   notifier->subdevs = kcalloc(
+   ISP_MAX_SUBDEVS, sizeof(*notifier->subdevs), GFP_KERNEL);
if (!notifier->subdevs)
return -ENOMEM;
 
@@ -2116,11 +2129,9 @@ static int isp_of_parse_nodes(struct device *dev,
   (node = of_graph_get_next_endpoint(dev->of_node, node))) {
struct isp_async_subdev *isd;
 
-   isd = devm_kzalloc(dev, sizeof(*isd), GFP_KERNEL);
-   if (!isd) {
-   of_node_put(node);
+   isd = kzalloc(sizeof(*isd), GFP_KERNEL);
+   if (!isd)
return -ENOMEM;
-   }
 
notifier->subdevs[notifier->num_subdevs] = >asd;
 
@@ -2204,7 +2215,7 @@ static int isp_probe(struct platform_device *pdev)
int ret;
int i, m;
 
-   isp = devm_kzalloc(>dev, sizeof(*isp), GFP_KERNEL);
+   isp = kzalloc(sizeof(*isp), GFP_KERNEL);
if (!isp) {
dev_err(>dev, "could not allocate memory\n");
return -ENOMEM;
@@ -2213,21 +2224,23 @@ static int isp_probe(struct platform_device *pdev)
ret = of_property_read_u32(pdev->dev.of_node, "ti,phy-type",
   >phy_type);
if (ret)
-   return ret;
+   goto error_release_isp;
 
isp->syscon = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
  "syscon");
-   if (IS_ERR(isp->syscon))
-   return PTR_ERR(isp->syscon);
+   if (IS_ERR(isp->syscon)) {
+   ret = PTR_ERR(isp->syscon);
+   goto error_release_isp;
+   }
 
ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1,
 >syscon_offset);
if (ret)
-   return ret;
+   goto error_release_isp;
 
ret = isp_of_parse_nodes(>dev, >notifier);
if (ret < 0)
-   return ret;
+   goto error_release_isp;
 
isp->autoidle = autoidle;
 
@@ -2244,8 +2257,18 @@ static int isp_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, isp);
 
/* Regulators */
-   isp->isp_csiphy1.vdd = devm_regulator_get(>dev, "vdd-csiphy1");
-   isp->isp_csiphy2.vdd = devm_regulator_get(>dev, "vdd-csiphy2");
+   isp->isp_csiphy1.vdd = regulator_get(>dev, "vdd-csiphy1");
+   if (IS_ERR(isp->isp_csiphy1.vdd)) {
+   ret = PTR_ERR(isp->isp_csiphy1.vdd);
+   isp->isp_csip

[PATCH 1/2] media: omap3isp fix media_entity_cleanup() after media device unregister

[Shuah Khan]

During unbind isp_remove() media_entity_cleanup() after it unregisters the
media_device. Cleanup routine calls media_entity_cleanup() accessing subdev
entities that have been removed. This will cause problems during unbind.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
 drivers/media/platform/omap3isp/ispccdc.c| 1 -
 drivers/media/platform/omap3isp/ispccp2.c| 1 -
 drivers/media/platform/omap3isp/ispcsi2.c| 1 -
 drivers/media/platform/omap3isp/isppreview.c | 1 -
 drivers/media/platform/omap3isp/ispresizer.c | 1 -
 drivers/media/platform/omap3isp/ispstat.c| 1 -
 drivers/media/platform/omap3isp/ispvideo.c   | 1 -
 7 files changed, 7 deletions(-)

diff --git a/drivers/media/platform/omap3isp/ispccdc.c 
b/drivers/media/platform/omap3isp/ispccdc.c
index 882310e..6d27e48 100644
--- a/drivers/media/platform/omap3isp/ispccdc.c
+++ b/drivers/media/platform/omap3isp/ispccdc.c
@@ -2726,7 +2726,6 @@ void omap3isp_ccdc_cleanup(struct isp_device *isp)
struct isp_ccdc_device *ccdc = >isp_ccdc;
 
omap3isp_video_cleanup(>video_out);
-   media_entity_cleanup(>subdev.entity);
 
/* Free LSC requests. As the CCDC is stopped there's no active request,
 * so only the pending request and the free queue need to be handled.
diff --git a/drivers/media/platform/omap3isp/ispccp2.c 
b/drivers/media/platform/omap3isp/ispccp2.c
index ca09523..4c1e7f0 100644
--- a/drivers/media/platform/omap3isp/ispccp2.c
+++ b/drivers/media/platform/omap3isp/ispccp2.c
@@ -1162,5 +1162,4 @@ void omap3isp_ccp2_cleanup(struct isp_device *isp)
struct isp_ccp2_device *ccp2 = >isp_ccp2;
 
omap3isp_video_cleanup(>video_in);
-   media_entity_cleanup(>subdev.entity);
 }
diff --git a/drivers/media/platform/omap3isp/ispcsi2.c 
b/drivers/media/platform/omap3isp/ispcsi2.c
index f75a1be..840756e 100644
--- a/drivers/media/platform/omap3isp/ispcsi2.c
+++ b/drivers/media/platform/omap3isp/ispcsi2.c
@@ -1318,5 +1318,4 @@ void omap3isp_csi2_cleanup(struct isp_device *isp)
struct isp_csi2_device *csi2a = >isp_csi2a;
 
omap3isp_video_cleanup(>video_out);
-   media_entity_cleanup(>subdev.entity);
 }
diff --git a/drivers/media/platform/omap3isp/isppreview.c 
b/drivers/media/platform/omap3isp/isppreview.c
index ac30a0f..a179dac 100644
--- a/drivers/media/platform/omap3isp/isppreview.c
+++ b/drivers/media/platform/omap3isp/isppreview.c
@@ -2348,5 +2348,4 @@ void omap3isp_preview_cleanup(struct isp_device *isp)
v4l2_ctrl_handler_free(>ctrls);
omap3isp_video_cleanup(>video_in);
omap3isp_video_cleanup(>video_out);
-   media_entity_cleanup(>subdev.entity);
 }
diff --git a/drivers/media/platform/omap3isp/ispresizer.c 
b/drivers/media/platform/omap3isp/ispresizer.c
index 0b6a875..d22a54a 100644
--- a/drivers/media/platform/omap3isp/ispresizer.c
+++ b/drivers/media/platform/omap3isp/ispresizer.c
@@ -1791,5 +1791,4 @@ void omap3isp_resizer_cleanup(struct isp_device *isp)
 
omap3isp_video_cleanup(>video_in);
omap3isp_video_cleanup(>video_out);
-   media_entity_cleanup(>subdev.entity);
 }
diff --git a/drivers/media/platform/omap3isp/ispstat.c 
b/drivers/media/platform/omap3isp/ispstat.c
index 1b9217d..47b8e43 100644
--- a/drivers/media/platform/omap3isp/ispstat.c
+++ b/drivers/media/platform/omap3isp/ispstat.c
@@ -1055,7 +1055,6 @@ int omap3isp_stat_init(struct ispstat *stat, const char 
*name,
 
 void omap3isp_stat_cleanup(struct ispstat *stat)
 {
-   media_entity_cleanup(>subdev.entity);
mutex_destroy(>ioctl_lock);
isp_stat_bufs_free(stat);
kfree(stat->buf);
diff --git a/drivers/media/platform/omap3isp/ispvideo.c 
b/drivers/media/platform/omap3isp/ispvideo.c
index 7354469..6914035 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -1470,7 +1470,6 @@ int omap3isp_video_init(struct isp_video *video, const 
char *name)
 
 void omap3isp_video_cleanup(struct isp_video *video)
 {
-   media_entity_cleanup(>video.entity);
mutex_destroy(>queue_lock);
mutex_destroy(>stream_lock);
mutex_destroy(>mutex);
-- 
2.7.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: [RFC v3 21/21] omap3isp: Don't rely on devm for memory resource management

[Shuah Khan]

Hi Skarai,

On 12/15/2016 04:57 AM, Laurent Pinchart wrote:
> On Thursday 15 Dec 2016 13:45:25 Sakari Ailus wrote:
>> Hi Laurent,
>>
>> On 12/15/16 13:42, Laurent Pinchart wrote:
>>> You can split that part out. The devm_* removal is independent and could
>>> be moved to the beginning of the series.
>>
>> Where do you release the memory in that case? In driver's remove(), i.e.
>> this patch would simply move that code to isp_remove()?
> 
> Yes, the kfree() calls would be in isp_remove(). The patch will then be 
> faithful to its $SUBJECT, and moving to a release() handler should be done in 
> a separate patch.
> 

I have a patch that does that for you. I was playing with devm removal from
omap3. You are welcome to just use it. This also includes regulator puts in
proper places. I also included a patch that removes extra media_entity_cleanup()

I will send those in a bit

thanks,
-- Shuah



--
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 v3 00/21] Make use of kref in media device, grab references as needed

[Shuah Khan]

On 12/15/2016 10:25 AM, Mauro Carvalho Chehab wrote:
> Em Thu, 15 Dec 2016 10:09:53 -0700
> Shuah Khan <shua...@osg.samsung.com> escreveu:
> 
>> On 12/15/2016 09:28 AM, Hans Verkuil wrote:
>>> On 15/12/16 17:06, Shuah Khan wrote:  
> 
>>>
>>> I think this will work for interface entities, but for subdev entities this
>>> certainly won't work. Unbinding subdevs should be blocked (just set
>>> suppress_bind_attrs to true in all subdev drivers). Most top-level drivers
>>> have pointers to subdev data, so unbinding them will just fail horribly.
>>>   
>>
>> Yes that is an option. I did something similar for au0828 and snd_usb_audio
>> case, so the module that registers the media_device can't unbound until the
>> other driver. If au0828 registers media_device, it becomes the owner and if
>> it gets unbound ioctls will start to see problems.

Sorry I meant to say rmmod'ed not unbound. Unbound will work just fine. If the
modules that owns the media_devnode goes away, there will be problems with
cdev trying to load module when application closes the device file and exits.
In this case, Media Device Allocator API takes module reference, so its use
count goes up.

>>
>> What this means though is that drivers can't be unbound easily. But that is
>> a small price to pay compared to the problems we will see if a driver is
>> unbound when its entities are still in use. Also, unsetting bind_attrs has
>> to be done as well, otherwise we can never unbind any driver.
> 
> I don't think suppress_bind_attrs will work on USB drivers, as the
> device can be physically removed. 
> 

Yeah setting suppress_bind_attrs would cause problems. On one hand keeping
all entities until all references are gone sound like a good option, however
this would cause problems coordinating removal especially in the case of
embedded entities. Can this be done in a simpler way? The way I see it, we
have /dev/video, /dev/dvb, /dev/snd/* etc. that depend on /dev/media for
graph nodes. Any one of these devices could be open when any of the drivers
is unbound (physical removal is a simpler case).

Would it make sense to enforce that dependency. Can we tie /dev/media usecount
to /dev/video etc. usecount? In other words:

/dev/video is opened, then open /dev/media.
prevent entities being removed if /dev/media is open.

Would that help. The above could be done in a generic way possibly. Would it
help if /dev/media is kept open when streaming is active? That is just one
use-case, there might be others.

thanks,
-- Shuah


thanks,
-- Shuah

--
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 v3 00/21] Make use of kref in media device, grab references as needed

[Shuah Khan]

On 12/15/2016 09:28 AM, Hans Verkuil wrote:
> On 15/12/16 17:06, Shuah Khan wrote:
>> On 12/15/2016 08:26 AM, Hans Verkuil wrote:
>>> On 15/12/16 15:45, Shuah Khan wrote:
>>>> On 12/15/2016 07:03 AM, Hans Verkuil wrote:
>>>>> On 15/12/16 13:56, Laurent Pinchart wrote:
>>>>>> Hi Sakari,
>>>>>>
>>>>>> On Thursday 15 Dec 2016 13:30:41 Sakari Ailus wrote:
>>>>>>> On Tue, Dec 13, 2016 at 10:24:47AM -0200, Mauro Carvalho Chehab wrote:
>>>>>>>> Em Tue, 13 Dec 2016 12:53:05 +0200 Sakari Ailus escreveu:
>>>>>>>>> On Tue, Nov 29, 2016 at 09:13:05AM -0200, Mauro Carvalho Chehab wrote:
>>>>>>>>>> Hi Sakari,
>>>>>>>>>>
>>>>>>>>>> I answered you point to point below, but I suspect that you missed 
>>>>>>>>>> how
>>>>>>>>>> the current approach works. So, I decided to write a quick summary
>>>>>>>>>> here.
>>>>>>>>>>
>>>>>>>>>> The character devices /dev/media? are created via cdev, with relies 
>>>>>>>>>> on
>>>>>>>>>> a kobject per device, with has an embedded struct kref inside.
>>>>>>>>>>
>>>>>>>>>> Also, each kobj at /dev/media0, /dev/media1, ... is associated with a
>>>>>>>>>> struct device, when the code does:
>>>>>>>>>>   devnode->cdev.kobj.parent = >dev.kobj;
>>>>>>>>>>
>>>>>>>>>> before calling cdev_add().
>>>>>>>>>>
>>>>>>>>>> The current lifetime management is actually based on cdev's kobject's
>>>>>>>>>> refcount, provided by its embedded kref.
>>>>>>>>>>
>>>>>>>>>> The kref warrants that any data associated with /dev/media0 won't be
>>>>>>>>>> freed if there are any pending system call. In other words, when
>>>>>>>>>> cdev_del() is called, it will remove /dev/media0 from the filesystem,
>>>>>>>>>> and will call kobject_put().
>>>>>>>>>>
>>>>>>>>>> If the refcount is zero, it will call devnode->dev.release(). If the
>>>>>>>>>> kobject refcount is not zero, the data won't be freed.
>>>>>>>>>>
>>>>>>>>>> So, in the best case scenario, there's no opened file descriptors
>>>>>>>>>> by the time media device node is unregistered. So, it will free
>>>>>>>>>> everything.
>>>>>>>>>>
>>>>>>>>>> In the worse case scenario, e. g. when the driver is removed or
>>>>>>>>>> unbind while /dev/media0 has some opened file descriptor(s),
>>>>>>>>>> the cdev logic will do the proper lifetime management.
>>>>>>>>>>
>>>>>>>>>> On such case, /dev/media0 disappears from the file system, so another
>>>>>>>>>> open is not possible anymore. The data structures will remain
>>>>>>>>>> allocated until all associated file descriptors are not closed.
>>>>>>>>>>
>>>>>>>>>> When all file descriptors are closed, the data will be freed.
>>>>>>>>>>
>>>>>>>>>> On that time, it will call an optional dev.release() callback,
>>>>>>>>>> responsible to free any other data struct that the driver allocated.
>>>>>>>>>
>>>>>>>>> The patchset does not change this. It's not a question of the
>>>>>>>>> media_devnode struct either. That's not an issue.
>>>>>>>>>
>>>>>>>>> The issue is rather what else can be accessed through the media device
>>>>>>>>> and other interfaces. As IOCTLs are not serialised with device removal
>>>>>>>>> (which now releases much of the data structures)
>>>>>>>>
>>>>>>>> Huh? ioctls are serialized with struct device removal. The Driver core
>>>>>>>> warrants that.
>>>>>>&g

Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed

[Shuah Khan]

On 12/15/2016 08:26 AM, Hans Verkuil wrote:
> On 15/12/16 15:45, Shuah Khan wrote:
>> On 12/15/2016 07:03 AM, Hans Verkuil wrote:
>>> On 15/12/16 13:56, Laurent Pinchart wrote:
>>>> Hi Sakari,
>>>>
>>>> On Thursday 15 Dec 2016 13:30:41 Sakari Ailus wrote:
>>>>> On Tue, Dec 13, 2016 at 10:24:47AM -0200, Mauro Carvalho Chehab wrote:
>>>>>> Em Tue, 13 Dec 2016 12:53:05 +0200 Sakari Ailus escreveu:
>>>>>>> On Tue, Nov 29, 2016 at 09:13:05AM -0200, Mauro Carvalho Chehab wrote:
>>>>>>>> Hi Sakari,
>>>>>>>>
>>>>>>>> I answered you point to point below, but I suspect that you missed how
>>>>>>>> the current approach works. So, I decided to write a quick summary
>>>>>>>> here.
>>>>>>>>
>>>>>>>> The character devices /dev/media? are created via cdev, with relies on
>>>>>>>> a kobject per device, with has an embedded struct kref inside.
>>>>>>>>
>>>>>>>> Also, each kobj at /dev/media0, /dev/media1, ... is associated with a
>>>>>>>> struct device, when the code does:
>>>>>>>>   devnode->cdev.kobj.parent = >dev.kobj;
>>>>>>>>
>>>>>>>> before calling cdev_add().
>>>>>>>>
>>>>>>>> The current lifetime management is actually based on cdev's kobject's
>>>>>>>> refcount, provided by its embedded kref.
>>>>>>>>
>>>>>>>> The kref warrants that any data associated with /dev/media0 won't be
>>>>>>>> freed if there are any pending system call. In other words, when
>>>>>>>> cdev_del() is called, it will remove /dev/media0 from the filesystem,
>>>>>>>> and will call kobject_put().
>>>>>>>>
>>>>>>>> If the refcount is zero, it will call devnode->dev.release(). If the
>>>>>>>> kobject refcount is not zero, the data won't be freed.
>>>>>>>>
>>>>>>>> So, in the best case scenario, there's no opened file descriptors
>>>>>>>> by the time media device node is unregistered. So, it will free
>>>>>>>> everything.
>>>>>>>>
>>>>>>>> In the worse case scenario, e. g. when the driver is removed or
>>>>>>>> unbind while /dev/media0 has some opened file descriptor(s),
>>>>>>>> the cdev logic will do the proper lifetime management.
>>>>>>>>
>>>>>>>> On such case, /dev/media0 disappears from the file system, so another
>>>>>>>> open is not possible anymore. The data structures will remain
>>>>>>>> allocated until all associated file descriptors are not closed.
>>>>>>>>
>>>>>>>> When all file descriptors are closed, the data will be freed.
>>>>>>>>
>>>>>>>> On that time, it will call an optional dev.release() callback,
>>>>>>>> responsible to free any other data struct that the driver allocated.
>>>>>>>
>>>>>>> The patchset does not change this. It's not a question of the
>>>>>>> media_devnode struct either. That's not an issue.
>>>>>>>
>>>>>>> The issue is rather what else can be accessed through the media device
>>>>>>> and other interfaces. As IOCTLs are not serialised with device removal
>>>>>>> (which now releases much of the data structures)
>>>>>>
>>>>>> Huh? ioctls are serialized with struct device removal. The Driver core
>>>>>> warrants that.
>>>>>
>>>>> How?
>>>>>
>>>>> As far as I can tell, there's nothing in the way of an IOCTL being in
>>>>> progress on a character device which is registered by the driver for a
>>>>> hardware device which is being removed.
>>>>>
>>>>> vfs_ioctl() directly calls the unlocked_ioctl() file operation which is, 
>>>>> in
>>>>> case of MC, media_ioctl() in media-devnode.c. No mutexes (or other locks)
>>>>> are taken during that path, which I believe is by design.
>>>
>>> chrdev_open in fs/char_dev.c increases the refcount on op

Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed

[Shuah Khan]

On 12/15/2016 03:39 AM, Laurent Pinchart wrote:
> Hello,
> 
> On Tuesday 13 Dec 2016 15:23:53 Shuah Khan wrote:
>> On 12/13/2016 05:24 AM, Mauro Carvalho Chehab wrote:
>>> Em Tue, 13 Dec 2016 12:53:05 +0200 Sakari Ailus escreveu:
>>>> On Tue, Nov 29, 2016 at 09:13:05AM -0200, Mauro Carvalho Chehab wrote:
>>>>> Hi Sakari,
>>>>>
>>>>> I answered you point to point below, but I suspect that you missed how
>>>>> the current approach works. So, I decided to write a quick summary here.
>>>>>
>>>>> The character devices /dev/media? are created via cdev, with relies on a
>>>>> kobject per device, with has an embedded struct kref inside.
>>>>>
>>>>> Also, each kobj at /dev/media0, /dev/media1, ... is associated with a
>>>>>
>>>>> struct device, when the code does:
>>>>>   devnode->cdev.kobj.parent = >dev.kobj;
>>>>>
>>>>> before calling cdev_add().
>>>>>
>>>>> The current lifetime management is actually based on cdev's kobject's
>>>>> refcount, provided by its embedded kref.
>>>>>
>>>>> The kref warrants that any data associated with /dev/media0 won't be
>>>>> freed if there are any pending system call. In other words, when
>>>>> cdev_del() is called, it will remove /dev/media0 from the filesystem,
>>>>> and
>>>>> will call kobject_put().
>>>>>
>>>>> If the refcount is zero, it will call devnode->dev.release(). If the
>>>>> kobject refcount is not zero, the data won't be freed.
>>>>>
>>>>> So, in the best case scenario, there's no opened file descriptors
>>>>> by the time media device node is unregistered. So, it will free
>>>>> everything.
>>>>>
>>>>> In the worse case scenario, e. g. when the driver is removed or
>>>>> unbind while /dev/media0 has some opened file descriptor(s),
>>>>> the cdev logic will do the proper lifetime management.
>>>>>
>>>>> On such case, /dev/media0 disappears from the file system, so another
>>>>> open
>>>>> is not possible anymore. The data structures will remain allocated until
>>>>> all associated file descriptors are not closed.
>>>>>
>>>>> When all file descriptors are closed, the data will be freed.
>>>>>
>>>>> On that time, it will call an optional dev.release() callback,
>>>>> responsible to free any other data struct that the driver allocated.
>>>>
>>>> The patchset does not change this. It's not a question of the
>>>> media_devnode struct either. That's not an issue.
>>>>
>>>> The issue is rather what else can be accessed through the media device
>>>> and other interfaces. As IOCTLs are not serialised with device removal
>>>> (which now releases much of the data structures)
>>>
>>> Huh? ioctls are serialized with struct device removal. The Driver core
>>> warrants that.
> 
> Code references please.
>  
>>>> there's a high chance of accessing
>>>> released memory (or mutexes that have been already destroyed). An example
>>>> of that is here, stopping a running pipeline after unbinding the device.
>>>> What happens there is that the media device is released whilst it's in
>>>> use through the video device.
>>>>
>>>> <URL:http://www.retiisi.org.uk/v4l2/tmp/media-ref-dmesg2.txt>
>>>
>>> It is not clear from the logs what the driver tried to do, but
>>> that sounds like a driver's bug, with was not prepared to properly
>>> handle unbinds.
>>>
>>> The problem here is that isp_video_release() is called by V4L2
>>> release logic, and not by the MC one:
>>>
>>> static const struct v4l2_file_operations isp_video_fops = {
>>> .owner  = THIS_MODULE,
>>> .open   = isp_video_open,
>>> .release= isp_video_release,
>>> .poll   = vb2_fop_poll,
>>> .unlocked_ioctl = video_ioctl2,
>>> .mmap   = vb2_fop_mmap,
>>> };
>>>
>>> It seems that the driver's logic allows it to be called before or
>>> after destroying the MC.
>>
>> Right isp_video_release() will definitely be called after driver is
>> gone which means media device is gone and the de

Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed

[Shuah Khan]

On 12/15/2016 07:03 AM, Hans Verkuil wrote:
> On 15/12/16 13:56, Laurent Pinchart wrote:
>> Hi Sakari,
>>
>> On Thursday 15 Dec 2016 13:30:41 Sakari Ailus wrote:
>>> On Tue, Dec 13, 2016 at 10:24:47AM -0200, Mauro Carvalho Chehab wrote:
 Em Tue, 13 Dec 2016 12:53:05 +0200 Sakari Ailus escreveu:
> On Tue, Nov 29, 2016 at 09:13:05AM -0200, Mauro Carvalho Chehab wrote:
>> Hi Sakari,
>>
>> I answered you point to point below, but I suspect that you missed how
>> the current approach works. So, I decided to write a quick summary
>> here.
>>
>> The character devices /dev/media? are created via cdev, with relies on
>> a kobject per device, with has an embedded struct kref inside.
>>
>> Also, each kobj at /dev/media0, /dev/media1, ... is associated with a
>> struct device, when the code does:
>>   devnode->cdev.kobj.parent = >dev.kobj;
>>
>> before calling cdev_add().
>>
>> The current lifetime management is actually based on cdev's kobject's
>> refcount, provided by its embedded kref.
>>
>> The kref warrants that any data associated with /dev/media0 won't be
>> freed if there are any pending system call. In other words, when
>> cdev_del() is called, it will remove /dev/media0 from the filesystem,
>> and will call kobject_put().
>>
>> If the refcount is zero, it will call devnode->dev.release(). If the
>> kobject refcount is not zero, the data won't be freed.
>>
>> So, in the best case scenario, there's no opened file descriptors
>> by the time media device node is unregistered. So, it will free
>> everything.
>>
>> In the worse case scenario, e. g. when the driver is removed or
>> unbind while /dev/media0 has some opened file descriptor(s),
>> the cdev logic will do the proper lifetime management.
>>
>> On such case, /dev/media0 disappears from the file system, so another
>> open is not possible anymore. The data structures will remain
>> allocated until all associated file descriptors are not closed.
>>
>> When all file descriptors are closed, the data will be freed.
>>
>> On that time, it will call an optional dev.release() callback,
>> responsible to free any other data struct that the driver allocated.
>
> The patchset does not change this. It's not a question of the
> media_devnode struct either. That's not an issue.
>
> The issue is rather what else can be accessed through the media device
> and other interfaces. As IOCTLs are not serialised with device removal
> (which now releases much of the data structures)

 Huh? ioctls are serialized with struct device removal. The Driver core
 warrants that.
>>>
>>> How?
>>>
>>> As far as I can tell, there's nothing in the way of an IOCTL being in
>>> progress on a character device which is registered by the driver for a
>>> hardware device which is being removed.
>>>
>>> vfs_ioctl() directly calls the unlocked_ioctl() file operation which is, in
>>> case of MC, media_ioctl() in media-devnode.c. No mutexes (or other locks)
>>> are taken during that path, which I believe is by design.
> 
> chrdev_open in fs/char_dev.c increases the refcount on open() and decreases it
> on release(). Thus ensuring that the cdev can never be removed while in an
> ioctl.
> 
>>>
> there's a high chance of accessing
> released memory (or mutexes that have been already destroyed). An
> example of that is here, stopping a running pipeline after unbinding
> the device. What happens there is that the media device is released
> whilst it's in use through the video device.
>
> 

 It is not clear from the logs what the driver tried to do, but
 that sounds like a driver's bug, with was not prepared to properly
 handle unbinds.

 The problem here is that isp_video_release() is called by V4L2
 release logic, and not by the MC one:

 static const struct v4l2_file_operations isp_video_fops = {
   .owner  = THIS_MODULE,
   .open   = isp_video_open,
   .release= isp_video_release,
   .poll   = vb2_fop_poll,
   .unlocked_ioctl = video_ioctl2,
   .mmap   = vb2_fop_mmap,
 };

 It seems that the driver's logic allows it to be called before or
 after destroying the MC.

 Assuming that, if the OMAP3 driver is not used it works,
 it means that, if the isp_video_release() is called
 first, no errors will happen, but if MC is destroyed before
 V4L2 call to its .release() callback, as there's no logic at the
 driver that would detect it, isp_video_release() will be calling
 isp_video_streamoff(), with depends on the MC to work.

 On a first glance, I can see two ways of fixing it:

 1) to increment devnode's device kobject refcount 

Re: [RFC v3 00/21] Make use of kref in media device, grab references as needed

[Shuah Khan]

physical device for which a
>>>> driver would expose a device node or two to the user space.  
>>>
>>> No. The current approach uses the struct device associated with /dev/media0,
>>> created via cdev, to provide a refcount for the data associated with the
>>> character device.
>>>
>>> The struct device kobject refcount ensures that everything associated
>>> with it will only be freed after the refcount goes to zero.
>>>
>>> As I said before, if are there any cases where the refcount is going
>>> early to zero, it is just a matter of adding a few kobject_get() and
>>> kobject_put() to ensure that this won't happen early, if the driver is
>>> so broken that it is unable to do the right refcount.  
>>
>> That's correct, but it only applies to struct media_devnode. Nothing else.
>> Please see above.
> 
> Well, don't remove entities before stop using them.
> 
>>>>> We might do it different, but we need a strong reason to do it, as
>>>>> going away from the usual practice is dangerous.
>>>>
>>>> I think we already did that when we merged the original Media controller 
>>>> and
>>>> V4L2 sub-device patches...
>>>>   
>>>>> 
>>>>>> - The driver remains responsible for the memory of the video and 
>>>>>> sub-device
>>>>>>   nodes. However, now the Media controller provides a convenient 
>>>>>> callback to
>>>>>>   the driver to release any memory resources when the time has come to do
>>>>>>   so. This takes place just before the media device memory is released.  
>>>>>>   
>>>>>
>>>>> Drivers could use devnode->dev.release for that. Of course, if they
>>>>> override it, they should be calling media_devnode_release() on their
>>>>> internal release functions.
>>>>
>>>> That'd be really hackish. The drivers currently don't deal with
>>>> media_devnode directly now and I don't think they should be obliged to.  
>>>
>>> I'm not against adding a callback instead. However, that makes it lose
>>> flexibility, as the callback will either be called before of after
>>> freeing struct device.
>>>
>>> By overriding the dev.release callback, we have a finer control.
>>>
>>> If you don't see any case where we'll be freeing data after freeing
>>> struct device, then a callback would work.
>>>   
>>>>> 
>>>>>> - Drivers that do not strictly need to be removable require no changes. 
>>>>>> The
>>>>>>   benefits of this set become tangible for any driver by changing how the
>>>>>>   driver allocates memory for the data structures. Ideally at least
>>>>>>   drivers for hot-removable devices should be converted.
>>>>>
>>>>> Drivers should allow device removal and/or driver removal. If you're
>>>>> doing any change here, you need to touch *all* drivers to use the new 
>>>>> way.
>>>>
>>>> Let's first agree on what needs to be fixed and how, and then think about
>>>> converting the drivers. Buggy code has a tendency to continue to be buggy
>>>> unless it is fixed (or replaced).  
>>>
>>> True, but as I said, this series create buggy code when it ignored what
>>> was fixed already. Also, a patch series to be considered ready for
>>> upstream need to do the needed changes on all drivers it affects.
>>>   
>>>>>> In order to make the current drivers to behave well it is necessary to 
>>>>>> make
>>>>>> changes to how memory is allocated in the drivers. If you look at the 
>>>>>> sample
>>>>>> patches that are part of the set for the omap3isp driver, you'll find 
>>>>>> that
>>>>>> around 95% of the changes are related to removing the user of devm_() 
>>>>>> family
>>>>>> of functions instead of Media controller API changes. In this regard, the
>>>>>> approach taken here requires very little if any additional overhead.
>>>>>
>>>>> Well, send the patches that do the 95% of the changes first e. g. devm_()
>>>>> removal, and check if you aren't using any dev_foo() printk after
>>>>> unregister, and send such patch series, without RFC. Then test what's
>>&

Re: Omap3-isp isp_remove() access subdev.entity after media_device_cleanup()

[Shuah Khan]

On 12/12/2016 01:03 AM, Sakari Ailus wrote:
> Hi Shuah,
> 
> On Fri, Dec 09, 2016 at 09:52:44AM -0700, Shuah Khan wrote:
>> Hi Sakari,
>>
>> I am looking at omap3 isp_remove() closely and I think there are a few
>> issues there that could cause problems during unbind.
>>
>> isp_remove() tries to do media_entity_cleanup() after it unregisters
>> media_device
>>
>> isp_remove() calls isp_unregister_entities() followed by
>> isp_cleanup_modules() - cleanup routines call media_entity_cleanup()
>>
>> media_entity_cleanup() accesses csi2a->subdev.entity which should be gone
>> by now after media_device_unregister(). This is just one example. I think
>> all of these cleanup routines isp_cleanup_modules() call access 
>> subdev.entity.
>>
>> static void isp_cleanup_modules(struct isp_device *isp)
>> {
>> omap3isp_h3a_aewb_cleanup(isp);
>> omap3isp_h3a_af_cleanup(isp);
>> omap3isp_hist_cleanup(isp);
>> omap3isp_resizer_cleanup(isp);
>> omap3isp_preview_cleanup(isp);
>> omap3isp_ccdc_cleanup(isp);
>> omap3isp_ccp2_cleanup(isp);
>> omap3isp_csi2_cleanup(isp);
>> }
>>
>> This is all done after media_device_cleanup() which does
>> ida_destroy(>entity_internal_idx); and 
>> mutex_destroy(>graph_mutex);
> 
> Calling media_entity_cleanup() is not a source of the current problems in
> any way. The function is defined in media-entity.h and it does nothing:
> 
> static inline void media_entity_cleanup(struct media_entity *entity) {};

Perhaps. Please see what I said about accesses csi2a->subdev.entity which is
gone by now to call media_entity_cleanup(). Even though media_entity_cleanup()
doesn't do anything, just this access could result in problems during unbind.

> 
> We could later discuss when media_entity_cleanup() should be called though.
> The existing drivers do call it in their remove() handler.
> 
>> I think there are some paths during unbind - isp_remove() that are unsafe.
>> I am trying to build https://github.com/gumstix/linux/tree/master now and
>> if I can get it to boot - I can send you some logs.
> 
> Please do.
> 

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

Omap3-isp isp_remove() access subdev.entity after media_device_cleanup()

[Shuah Khan]

Hi Sakari,

I am looking at omap3 isp_remove() closely and I think there are a few
issues there that could cause problems during unbind.

isp_remove() tries to do media_entity_cleanup() after it unregisters
media_device

isp_remove() calls isp_unregister_entities() followed by
isp_cleanup_modules() - cleanup routines call media_entity_cleanup()

media_entity_cleanup() accesses csi2a->subdev.entity which should be gone
by now after media_device_unregister(). This is just one example. I think
all of these cleanup routines isp_cleanup_modules() call access subdev.entity.

static void isp_cleanup_modules(struct isp_device *isp)
{
omap3isp_h3a_aewb_cleanup(isp);
omap3isp_h3a_af_cleanup(isp);
omap3isp_hist_cleanup(isp);
omap3isp_resizer_cleanup(isp);
omap3isp_preview_cleanup(isp);
omap3isp_ccdc_cleanup(isp);
omap3isp_ccp2_cleanup(isp);
omap3isp_csi2_cleanup(isp);
}

This is all done after media_device_cleanup() which does
ida_destroy(>entity_internal_idx); and mutex_destroy(>graph_mutex);

I think there are some paths during unbind - isp_remove() that are unsafe.
I am trying to build https://github.com/gumstix/linux/tree/master now and
if I can get it to boot - I can send you some logs.

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.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 v6 3/3] sound/usb: Use Media Controller API to share media resources

[Shuah Khan]

On 12/09/2016 06:17 AM, Sakari Ailus wrote:
> Hi Shuah,
> 
> On Fri, Dec 09, 2016 at 01:44:07AM +0200, Sakari Ailus wrote:
>> 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 <shua...@osg.samsung.com>
>>>>>>>>>
>>>>>>>>> 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:
>>>>>>
>>>>>> <URL:http://www.retiisi.org.uk/v4l2/tmp/media-ref-dmesg.txt>
>>>>>
>>>>> Did you test t

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

[Shuah Khan]

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 <shua...@osg.samsung.com>
>>>>>>
>>>>>> 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:
>>>
>>> <URL: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:
> 
> <URL:http://www.retiisi.org.uk/v4l2/tmp/media-ref-diff2.txt>
> <URL:http://www.retiisi.org.uk/v4l2/tmp/media-ref-dmesg2.txt>
> 

Does unbind work on this even without streaming? Could you suppress
debug messages and run unbind without streaming. It might fail. Let
me know if what you see with just unbind on this driver.

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

thanks,
-- Shuah
--
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 3/3] sound/usb: Use Media Controller API to share media resources

[Shuah Khan]

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 <shua...@osg.samsung.com>
>>>>
>>>> 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:
> 
> <URL: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.

thanks,
-- Shuah

> 
> What happens there is that as part of the device unbinding, the graph
> objects are unregistered (by media_device_unregister()) while streaming is
> ongoing. Their parent media device pointers are set to NULL.
> 
> Then, when the user process exists, the streaming media pipeline is stopped.
> This requires parsing of the media graph, a job which will obviously fail
> miserably and immediately: the media device is obtained from the entity
> where graph traversal is expected to begin.
> 
> Two mutexes are also acquired but they've been already destroyed at that
> point (and the memory of which would also be released now without the hack
> to test this "without devm"). There's just a single warning on this though.
> 
>> top of media dev allocator because the allocator routines he has don't 
>> address
>> the shared media device need.
> 
> I do strongly prefer fixing the existing object lifetime issues in the
> framework before extending it and thus making the problem domain more
> complex than it is already.
> 
> What I mentioned as an example of this are the other callbacks to the media
> device: presumably they do suffer from the exactly same problems as the
> enable_source() and disable_source() ones.
> 
> As drivers do refer to other entities and controls they do expose also to
> the user space, we can't really even remove entities safely at the moment.
> We should have a solution to this as well, my patchset at the moment does
> not address this.
> 
> What we do need a sound basis for the framework rather than hastily wri

[PATCH v7 0/3] Media Device Allocator API

[Shuah Khan]

Media Device Allocator API to allows multiple drivers share a media device.
Using this API, drivers can allocate a media device with the shared struct
device as the key. Once the media device is allocated by a driver, other
drivers can get a reference to it. The media device is released when all
the references are released.

Patches 0001 and 0002 are rebased to 4.9-rc7. Patch 0003 for snd-usb-audio
is a rebase of the patch that was tested with the original Media Device
Allocator patch series.

snd-usb-audio patch includes the fixes found during 4.7-rc1 time in the
original snd-usb-audio patch.

Changes to patches in this series:
Changes to patch 0001 since v6:
- No changes
Changes to patch 0002 since v6:
- No changes
Changes to patch 0003 since v6:
- Addressed Takashi's review comments on patch v6

Depends on:
https://lkml.org/lkml/2016/11/29/1001

Changes to patch 0001 since v5: (comments from Mauro and Sakari)
- Removed struct device from media_device_instance. mdev.dev is used instead.
- Added documentation.

Changes to patch 0002:
- No changes since patch v2, applies cleanly on top of the following:
media: Protect enable_source and disable_source handler code paths
https://lkml.org/lkml/2016/11/29/1001
 
Changes to patch 0003:
- Changed to hold graph_mutex to check and call enable_source and
  disable_source handlers - to match au0828 doing the same in:
media: Protect enable_source and disable_source handler code paths 
https://lkml.org/lkml/2016/11/29/1001

Changes to patch 0001 since v4:
- Addressed Sakari's review comments with the exception of
  opting to not introduce media_device_usb_allocate() macro,
  and to not add a new routine to find media device instance
  to avoid a one line check.

Changes to patch 0001 since v3:
- Fixed undefined reference to `__media_device_usb_init compile error when
  CONFIG_USB is disabled.
- Fixed kernel paging error when accessing /dev/mediaX after rmmod of the
  module that owns the media_device. The fix bumps the reference count for
  the owner when second driver comes along to share the media_device. If
  au0828 owns the media_device, then snd_usb_audio will bump the refcount
  for au0828, so it won't get deleted and vice versa.

Changes to patch 0002 since v2:
- Updated media_device_delete() to pass in module name.

Changes to patch 0003 since the last version in 4.7-rc1:
- Included fixes to bugs found during testing. 
- Updated to use the Media Allocator API.

This patch series has been tested with au0828 and snd-usb-audio drivers.
Ran bind and unbind loop tests on each driver with mc_nextgen_test and
media_device_test app loop tests while checking lsmod and dmesg.

Please refer to tools/testing/selftests/media_tests/regression_test.txt
for testing done on this series.

Shuah Khan (3):
  media: Media Device Allocator API
  media: change au0828 to use Media Device Allocator API
  sound/usb: Use Media Controller API to share media resources

 Documentation/media/kapi/mc-core.rst   |  37 
 drivers/media/Makefile |   3 +-
 drivers/media/media-dev-allocator.c| 133 ++
 drivers/media/usb/au0828/au0828-core.c |  12 +-
 drivers/media/usb/au0828/au0828.h  |   1 +
 include/media/media-dev-allocator.h|  54 ++
 sound/usb/Kconfig  |   4 +
 sound/usb/Makefile |   2 +
 sound/usb/card.c   |  14 ++
 sound/usb/card.h   |   3 +
 sound/usb/media.c  | 321 +
 sound/usb/media.h  |  73 
 sound/usb/mixer.h  |   3 +
 sound/usb/pcm.c|  29 ++-
 sound/usb/quirks-table.h   |   1 +
 sound/usb/stream.c |   2 +
 sound/usb/usbaudio.h   |   6 +
 17 files changed, 684 insertions(+), 14 deletions(-)
 create mode 100644 drivers/media/media-dev-allocator.c
 create mode 100644 include/media/media-dev-allocator.h
 create mode 100644 sound/usb/media.c
 create mode 100644 sound/usb/media.h

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

[PATCH v7 1/3] media: Media Device Allocator API

[Shuah Khan]

Media Device Allocator API to allows multiple drivers share a media device.
Using this API, drivers can allocate a media device with the shared struct
device as the key. Once the media device is allocated by a driver, other
drivers can get a reference to it. The media device is released when all
the references are released.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
No changes since v6

 Documentation/media/kapi/mc-core.rst |  37 ++
 drivers/media/Makefile   |   3 +-
 drivers/media/media-dev-allocator.c  | 133 +++
 include/media/media-dev-allocator.h  |  54 ++
 4 files changed, 226 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/media-dev-allocator.c
 create mode 100644 include/media/media-dev-allocator.h

diff --git a/Documentation/media/kapi/mc-core.rst 
b/Documentation/media/kapi/mc-core.rst
index 1a738e5..4942cdd 100644
--- a/Documentation/media/kapi/mc-core.rst
+++ b/Documentation/media/kapi/mc-core.rst
@@ -257,8 +257,45 @@ Subsystems should facilitate link validation by providing 
subsystem specific
 helper functions to provide easy access for commonly needed information, and
 in the end provide a way to use driver-specific callbacks.
 
+Media Controller Device Allocator API
+^
+
+When media device belongs to more than one driver, the shared media device
+is allocated with the shared struct device as the key for look ups.
+
+Shared media device should stay in registered state until the last driver
+unregisters it. In addition, media device should be released when all the
+references are released. Each driver gets a reference to the media device
+during probe, when it allocates the media device. If media device is already
+allocated, allocate API bumps up the refcount and return the existing media
+device. Driver puts the reference back from its disconnect routine when it
+calls :c:func:`media_device_delete()`.
+
+Media device is unregistered and cleaned up from the kref put handler to
+ensure that the media device stays in registered state until the last driver
+unregisters the media device.
+
+**Driver Usage**
+
+Drivers should use the media-core routines to get register reference and
+call :c:func:`media_device_delete()` routine to make sure the shared media
+device delete is handled correctly.
+
+**driver probe:**
+Call :c:func:`media_device_usb_allocate()` to allocate or get a reference
+Call :c:func:`media_device_register()`, if media devnode isn't registered
+
+**driver disconnect:**
+Call :c:func:`media_device_delete()` to free the media_device. Free'ing is
+handled by the kref put handler.
+
+API Definitions
+^^^
+
 .. kernel-doc:: include/media/media-device.h
 
 .. kernel-doc:: include/media/media-devnode.h
 
 .. kernel-doc:: include/media/media-entity.h
+
+.. kernel-doc:: include/media/media-dev-allocator.h
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index 0deaa93..7c0701d 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -6,7 +6,8 @@ ifeq ($(CONFIG_MEDIA_CEC_EDID),y)
   obj-$(CONFIG_MEDIA_SUPPORT) += cec-edid.o
 endif
 
-media-objs := media-device.o media-devnode.o media-entity.o
+media-objs := media-device.o media-devnode.o media-entity.o \
+  media-dev-allocator.o
 
 #
 # I2C drivers should come before other drivers, otherwise they'll fail
diff --git a/drivers/media/media-dev-allocator.c 
b/drivers/media/media-dev-allocator.c
new file mode 100644
index 000..0ecf152
--- /dev/null
+++ b/drivers/media/media-dev-allocator.c
@@ -0,0 +1,133 @@
+/*
+ * media-dev-allocator.c - Media Controller Device Allocator API
+ *
+ * Copyright (c) 2016 Shuah Khan <shua...@osg.samsung.com>
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *
+ * This file is released under the GPLv2.
+ * Credits: Suggested by Laurent Pinchart <laurent.pinch...@ideasonboard.com>
+ */
+
+/*
+ * This file adds a global refcounted Media Controller Device Instance API.
+ * A system wide global media device list is managed and each media device
+ * includes a kref count. The last put on the media device releases the media
+ * device instance.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static LIST_HEAD(media_device_list);
+static DEFINE_MUTEX(media_device_lock);
+
+struct media_device_instance {
+   struct media_device mdev;
+   struct module *owner;
+   struct list_head list;
+   struct kref refcount;
+};
+
+static inline struct media_device_instance *
+to_media_device_instance(struct media_device *mdev)
+{
+   return container_of(mdev, struct media_device_instance, mdev);
+}
+
+static void media_device_instance_release(struct kref *kref)
+{
+   struct media_device_instance *mdi =
+   container_of(kref, struct media_device_instance, refcount);
+
+   dev_dbg(mdi->mdev.dev, "%s: mdev=%p\n", __func__, >mdev);

[PATCH v7 2/3] media: change au0828 to use Media Device Allocator API

[Shuah Khan]

Change au0828 to use Media Device Allocator API to allocate media device
with the parent usb struct device as the key, so it can be shared with the
snd_usb_audio driver.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
No changes since v6

 drivers/media/usb/au0828/au0828-core.c | 12 
 drivers/media/usb/au0828/au0828.h  |  1 +
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-core.c 
b/drivers/media/usb/au0828/au0828-core.c
index bfd6482..ff1928e 100644
--- a/drivers/media/usb/au0828/au0828-core.c
+++ b/drivers/media/usb/au0828/au0828-core.c
@@ -159,9 +159,7 @@ static void au0828_unregister_media_device(struct 
au0828_dev *dev)
dev->media_dev->disable_source = NULL;
mutex_unlock(>graph_mutex);
 
-   media_device_unregister(dev->media_dev);
-   media_device_cleanup(dev->media_dev);
-   kfree(dev->media_dev);
+   media_device_delete(dev->media_dev, KBUILD_MODNAME);
dev->media_dev = NULL;
 #endif
 }
@@ -214,14 +212,10 @@ static int au0828_media_device_init(struct au0828_dev 
*dev,
 #ifdef CONFIG_MEDIA_CONTROLLER
struct media_device *mdev;
 
-   mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
+   mdev = media_device_usb_allocate(udev, KBUILD_MODNAME);
if (!mdev)
return -ENOMEM;
 
-   /* check if media device is already initialized */
-   if (!mdev->dev)
-   media_device_usb_init(mdev, udev, udev->product);
-
dev->media_dev = mdev;
 #endif
return 0;
@@ -482,6 +476,8 @@ static int au0828_media_device_register(struct au0828_dev 
*dev,
/* register media device */
ret = media_device_register(dev->media_dev);
if (ret) {
+   media_device_delete(dev->media_dev, KBUILD_MODNAME);
+   dev->media_dev = NULL;
dev_err(>dev,
"Media Device Register Error: %d\n", ret);
return ret;
diff --git a/drivers/media/usb/au0828/au0828.h 
b/drivers/media/usb/au0828/au0828.h
index dd7b378..4bf1b0c 100644
--- a/drivers/media/usb/au0828/au0828.h
+++ b/drivers/media/usb/au0828/au0828.h
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* DVB */
 #include "demux.h"
-- 
2.7.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

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

[Shuah Khan]

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 <shua...@osg.samsung.com>
---
Changes to patch 0003 since v6:
- Addressed Takashi's review comments on patch v6

 sound/usb/Kconfig|   4 +
 sound/usb/Makefile   |   2 +
 sound/usb/card.c |  14 +++
 sound/usb/card.h |   3 +
 sound/usb/media.c| 321 +++
 sound/usb/media.h|  73 +++
 sound/usb/mixer.h|   3 +
 sound/usb/pcm.c  |  29 -
 sound/usb/quirks-table.h |   1 +
 sound/usb/stream.c   |   2 +
 sound/usb/usbaudio.h |   6 +
 11 files changed, 453 insertions(+), 5 deletions(-)
 create mode 100644 sound/usb/media.c
 create mode 100644 sound/usb/media.h

diff --git a/sound/usb/Kconfig b/sound/usb/Kconfig
index a452ad7..d14bf41 100644
--- a/sound/usb/Kconfig
+++ b/sound/usb/Kconfig
@@ -15,6 +15,7 @@ config SND_USB_AUDIO
select SND_RAWMIDI
select SND_PCM
select BITREVERSE
+   select SND_USB_AUDIO_USE_MEDIA_CONTROLLER if MEDIA_CONTROLLER && 
(MEDIA_SUPPORT=y || MEDIA_SUPPORT=SND_USB_AUDIO)
help
  Say Y here to include support for USB audio and USB MIDI
  devices.
@@ -22,6 +23,9 @@ config SND_USB_AUDIO
  To compile this driver as a module, choose M here: the module
  will be called snd-usb-audio.
 
+config SND_USB_AUDIO_USE_MEDIA_CONTROLLER
+   bool
+
 config SND_USB_UA101
tristate "Edirol UA-101/UA-1000 driver"
select SND_PCM
diff --git a/sound/usb/Makefile b/sound/usb/Makefile
index 2d2d122..8dca3c4 100644
--- a/sound/usb/Makefile
+++ b/sound/usb/Makefile
@@ -15,6 +15,8 @@ snd-usb-audio-objs := card.o \
quirks.o \
stream.o
 
+snd-usb-audio-$(CONFIG_SND_USB_AUDIO_USE_MEDIA_CONTROLLER) += media.o
+
 snd-usbmidi-lib-objs := midi.o
 
 # Toplevel Module Dependency
diff --git a/sound/usb/card.c b/sound/usb/card.c
index 2ddc034..570ff00 100644
--- a/sound/usb/card.c
+++ b/sound/usb/card.c
@@ -66,6 +66,7 @@
 #include "format.h"
 #include "power.h"
 #include "stream.h"
+#include "media.h"
 
 MODULE_AUTHOR("Takashi Iwai <ti...@suse.de>");
 MODULE_DESCRIPTION("USB Audio");
@@ -616,6 +617,11 @@ static int usb_audio_probe(struct usb_interface *intf,
if (err < 0)
goto __error;
 
+   if (quirk && quirk->media_device) {
+   /* don't want to fail when media_snd_device_create() fails */
+   media_snd_device_create(chip, intf);
+   }
+
usb_chip[chip->index] = chip;
chip->num_interfaces++;
usb_set_intfdata(intf, chip);
@@ -672,6 +678,14 @@ static void usb_audio_disconnect(struct usb_interface 
*intf)
list_for_each(p, >midi_list) {
snd_usbmidi_disconnect(p);
}
+   /*
+* Nice to check quirk && quirk->media_device and
+* then call media_snd_device_delete(). Don't have
+* access to quirk here. media_snd_device_delete()
+* acceses mixer_list
+*/
+   media_snd_device_delete(chip);
+
/* release mixer resources */
list_for_each_entry(mixer, >mixer_list, list) {
snd_usb_mixer_disconnect(mixer);
diff --git a/sound/usb/card.h b/sound/usb/card.h
index 111b0f0..6ef8e88 100644
--- a/sound/usb/card.h
+++ b/sound/usb/card.h
@@ -105,6 +105,8 @@ struct snd_usb_endpoint {
struct list_head list;
 };
 
+struct media_ctl;
+
 struct snd_usb_substream {
struct snd_usb_stream *stream;
struct usb_device *dev;
@@ -156,6 +158,7 @@ struct snd_usb_substream {
} dsd_dop;
 
bool trigger_tstamp_pending_update; /* trigger timestamp being updated 
from initial estimate */
+   struct media_ctl *media_ctl;
 };
 
 struct snd_usb_stream {
diff --git a/sound/usb/media.c b/sound/usb/media.c
new file mode 100644
index 000..0a8fc14
--- /dev/null
+++ b/sound/usb/media.c
@@ -0,0 +1,321 @@
+/*
+ * media.c - Media Controller specific ALSA driver code
+ *
+ * Copyright (c) 2016 Shuah Khan <shua...@osg.samsung.com>
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *
+ * This file is released under the GPLv2.
+ */
+
+/

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

[Shuah Khan]

Hi Takashi,

On 12/05/2016 11:50 PM, Takashi Iwai wrote:
> On Wed, 30 Nov 2016 23:01:16 +0100,
> Shuah Khan wrote:
>>
>> --- a/sound/usb/card.c
>> +++ b/sound/usb/card.c
> (snip)
>> @@ -616,6 +617,11 @@ static int usb_audio_probe(struct usb_interface *intf,
>>  if (err < 0)
>>  goto __error;
>>  
>> +if (quirk && quirk->media_device) {
>> +/* don't want to fail when media_snd_device_create() fails */
>> +media_snd_device_create(chip, intf);
> 
> Note that the usb-audio driver is probed for each usb interface, and
> there are multiple interfaces per device.  That is, usb_audio_probe()
> may be called multiple times per device, and at the second or the
> later calls, it appends the stuff onto the previously created card
> object.
> 
> So, you'd have to make this call also conditional (e.g. check
> chip->num_interfaces == 0, indicating the very first one), or allow to
> be called multiple times.
> 
> In the former case, it'd be better to split media_snd_device_create()
> and media_snd_mixer_init().  The *_device_create() needs to be called
> only once, while *_mixer_init() still has to be called for each time
> because the new mixer element may be added for each interface.
> 

Thanks for the catch. I am able to fix this in media_snd_device_create()
I made a change to do media_dev allocate only once. media_snd_mixer_init()
will get called every time media_snd_device_create() is called. This way
new mixers can be handled. media_snd_mixer_init() has logic to deal with
mixers that are already initialized. We are good here with the following
change:

@@ -272,6 +258,14 @@ int media_snd_device_create(struct snd_usb_audio *chip,
struct usb_device *usbdev = interface_to_usbdev(iface);
int ret;
 
+   /* usb-audio driver is probed for each usb interface, and
+* there are multiple interfaces per device. Avoid calling
+* media_device_usb_allocate() each time usb_audio_probe()
+* is called. Do it only once.
+*/
+   if (chip->media_dev)
+   goto snd_mixer_init;
+
mdev = media_device_usb_allocate(usbdev, KBUILD_MODNAME);
if (!mdev)
return -ENOMEM;
@@ -291,6 +285,7 @@ int media_snd_device_create(struct snd_usb_audio *chip,
/* save media device - avoid lookups */
chip->media_dev = mdev;
 
+snd_mixer_init:
/* Create media entities for mixer and control dev */
ret = media_snd_mixer_init(chip);
if (ret) {

> 
>> +}
>> +
>>  usb_chip[chip->index] = chip;
>>  chip->num_interfaces++;
>>  usb_set_intfdata(intf, chip);
>> @@ -672,6 +678,14 @@ static void usb_audio_disconnect(struct usb_interface 
>> *intf)
>>  list_for_each(p, >midi_list) {
>>  snd_usbmidi_disconnect(p);
>>  }
>> +/*
>> + * Nice to check quirk && quirk->media_device and
>> + * then call media_snd_device_delete(). Don't have
>> + * access to quirk here. media_snd_device_delete()
>> + * acceses mixer_list
>> + */
>> +media_snd_device_delete(chip);
> 
> ... meanwhile this is OK, as it's called only once.
> 
> (BTW, is it OK to call media_* stuff while the device is still in use?
>  The disconnect callback gets called for hot-unplug.)
> 

Yes. All of the media_* functions that get called during run-time check for
chip->media_dev or media_ctl and do nothing when these are null.

media_device itself will not be free'd until all reference are gone. When
usb_audio_disconnect() happens via unbind snd_usb_audio or physical remove,
media_dev sticks around until au0828 (media driver) goes away. There is
handling for any user apps. that have /dev/mediaX open.

Does this sound correct? Did I miss any of your concerns?

> 
>> --- /dev/null
>> +++ b/sound/usb/media.c
> (snip)
>> +void media_snd_stream_delete(struct snd_usb_substream *subs)
>> +{
>> +struct media_ctl *mctl = subs->media_ctl;
>> +
>> +if (mctl && mctl->media_dev) {
> 
> mctl->media_dev NULL check here is superfluous, as it's checked
> mctl->below.
> 

Done.

>> +struct media_device *mdev;
>> +
>> +mdev = mctl->media_dev;
>> +if (mdev && media_devnode_is_registered(mdev->devnode)) {
>> +media_devnode_remove(mctl->intf_devnode);
>> +media_device_unregister_entity(>media_entity);
>> +media_entity_cleanup(>media_entity);
>> +}
&g

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

[Shuah Khan]

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 <shua...@osg.samsung.com>
>>
>> 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
top of media dev allocator because the allocator routines he has don't address
the shared media device need.

He also didn't respond to my response regarding the reasons for choosing
graph_mutex to protect enable_source and disable_source handlers.

So I am not sure how to move forward at the moment without a concrete plan
for Sakari's RFC series. Sakari's patch series is still RFC and doesn't address
shared media_device and requires all drivers to change.

thanks,
-- Shuah
--
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 3/3] sound/usb: Use Media Controller API to share media resources

[Shuah Khan]

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 <shua...@osg.samsung.com>

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.

thanks,
-- Shuah

> ---
> Changes to patch 0003:
> - Changed to hold graph_mutex to check and call enable_source and
>   disable_source handlers - to match au0828 doing the same in:
> media: Protect enable_source and disable_source handler code paths 
> https://lkml.org/lkml/2016/11/29/1001
> 
>  sound/usb/Kconfig|   4 +
>  sound/usb/Makefile   |   2 +
>  sound/usb/card.c |  14 ++
>  sound/usb/card.h |   3 +
>  sound/usb/media.c| 326 
> +++
>  sound/usb/media.h|  73 +++
>  sound/usb/mixer.h|   3 +
>  sound/usb/pcm.c  |  28 +++-
>  sound/usb/quirks-table.h |   1 +
>  sound/usb/stream.c   |   2 +
>  sound/usb/usbaudio.h |   6 +
>  11 files changed, 457 insertions(+), 5 deletions(-)
>  create mode 100644 sound/usb/media.c
>  create mode 100644 sound/usb/media.h
> 
> diff --git a/sound/usb/Kconfig b/sound/usb/Kconfig
> index a452ad7..d14bf41 100644
> --- a/sound/usb/Kconfig
> +++ b/sound/usb/Kconfig
> @@ -15,6 +15,7 @@ config SND_USB_AUDIO
>   select SND_RAWMIDI
>   select SND_PCM
>   select BITREVERSE
> + select SND_USB_AUDIO_USE_MEDIA_CONTROLLER if MEDIA_CONTROLLER && 
> (MEDIA_SUPPORT=y || MEDIA_SUPPORT=SND_USB_AUDIO)
>   help
> Say Y here to include support for USB audio and USB MIDI
> devices.
> @@ -22,6 +23,9 @@ config SND_USB_AUDIO
> To compile this driver as a module, choose M here: the module
> will be called snd-usb-audio.
>  
> +config SND_USB_AUDIO_USE_MEDIA_CONTROLLER
> + bool
> +
>  config SND_USB_UA101
>   tristate "Edirol UA-101/UA-1000 driver"
>   select SND_PCM
> diff --git a/sound/usb/Makefile b/sound/usb/Makefile
> index 2d2d122..8dca3c4 100644
> --- a/sound/usb/Makefile
> +++ b/sound/usb/Makefile
> @@ -15,6 +15,8 @@ snd-usb-audio-objs :=   card.o \
>   quirks.o \
>   stream.o
>  
> +snd-usb-audio-$(CONFIG_SND_USB_AUDIO_USE_MEDIA_CONTROLLER) += media.o
> +
>  snd-usbmidi-lib-objs := midi.o
>  
>  # Toplevel Module Dependency
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> index 2ddc034..570ff00 100644
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -66,6 +66,7 @@
>  #include "format.h"
>  #include "power.h"
>  #include "stream.h"
> +#include "media.h"
>  
>  MODULE_AUTHOR("Takashi Iwai <ti...@suse.de>");
>  MODULE_DESCRIPTION("USB Audio");
> @@ -616,6 +617,11 @@ static int usb_audio_probe(struct usb_interface *intf,
>   if (err < 0)
>   goto __error;
>  
> + if (quirk && quirk->media_device) {
> + /* don't want to fail when media_snd_device_create() fails */
> + media_snd_device_create(chip, intf);
> + }
> +
>   usb_chip[chip->index] = chip;
>   chip->num_interfaces++;
>   usb_set_intfdata(intf, chip);
> @@ -672,6 +678,14 @@ static void usb_audio_disconnect(struct usb_interface 
> *intf)
>   list_for_each(p, >midi_list) {
>   snd_usbmidi_disconnect(p);
>   }
> + /*
> +  * Nice to check quirk && quirk->media_device and
> +  * then call media_snd_device_delete(). Don't have
> +  * access to quirk here. media_snd_device_delete()
> +  * acceses mixer_list
> +  */
> + media_snd_device_delete(chip);
> +
>   /* release mixer resources */
>   list_for_each_entry(mixer, >mixer_list, list) {
>   snd_usb_mixer_disconnect(mixer);
> diff --git a/sound/usb/card.h b/sound/us

Re: [PATCH 2/2] media: protect enable and disable source handler checks and calls

[Shuah Khan]

Hi Sakari,

On 12/01/2016 06:51 AM, Sakari Ailus wrote:
> Hi Shuah,
> 
> On Tue, Nov 29, 2016 at 10:41:51AM -0700, Shuah Khan wrote:
>> On 11/29/2016 02:22 AM, Sakari Ailus wrote:
>>> Hi Shuah,
>>>
>>> On Mon, Nov 28, 2016 at 07:15:14PM -0700, Shuah Khan wrote:
>>>> Protect enable and disable source handler checks and calls from dvb-core
>>>> and v4l2-core. Hold graph_mutex to check if enable and disable source
>>>> handlers are present and invoke them while holding the mutex. This change
>>>> ensures these handlers will not be removed while they are being checked
>>>> and invoked.
>>>>
>>>> au08282 enable and disable source handlers are changed to not hold the
>>>> graph_mutex.
>>>>
>>>> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
>>>> ---
>>>>  drivers/media/dvb-core/dvb_frontend.c  | 24 ++--
>>>>  drivers/media/usb/au0828/au0828-core.c | 17 +
>>>>  drivers/media/v4l2-core/v4l2-mc.c  | 26 ++
>>>>  3 files changed, 41 insertions(+), 26 deletions(-)
>>>>
>>>> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
>>>> b/drivers/media/dvb-core/dvb_frontend.c
>>>> index 01511e5..2f09c7e 100644
>>>> --- a/drivers/media/dvb-core/dvb_frontend.c
>>>> +++ b/drivers/media/dvb-core/dvb_frontend.c
>>>> @@ -2527,9 +2527,13 @@ static int dvb_frontend_open(struct inode *inode, 
>>>> struct file *file)
>>>>fepriv->voltage = -1;
>>>>  
>>>>  #ifdef CONFIG_MEDIA_CONTROLLER_DVB
>>>> -  if (fe->dvb->mdev && fe->dvb->mdev->enable_source) {
>>>> -  ret = fe->dvb->mdev->enable_source(dvbdev->entity,
>>>> +  if (fe->dvb->mdev) {
>>>> +  mutex_lock(>dvb->mdev->graph_mutex);
>>>> +  if (fe->dvb->mdev->enable_source)
>>>> +  ret = fe->dvb->mdev->enable_source(
>>>> + dvbdev->entity,
>>>>   >pipe);
>>>> +  mutex_unlock(>dvb->mdev->graph_mutex);
>>>
>>> You have to make sure the media device actually will stay aronud while it is
>>> being accessed. In this case, when dvb_frontend_open() runs, it will proceed
>>> to access the media device without knowing whether it's going to stay around
>>> or not. Without doing so, it may well be in the process of being removed by
>>> au0828_unregister_media_device() at the same time.
>>
>> Right. What this is trying to protect is just the check for enable_source
>> and disable handlers before calling them.
> 
> Yes, but that's not enough.
> 
> The other handlers in the ops structure must stay there as long as the media
> device does. So we need to make sure it does. One, perhaps the only way to
> do that could be to obtain a reference to the device that first set those
> callbacks.
> 
>>
>>>
>>> The approach I took in my patchset was that the device that requires the
>>> media device will acquire a reference to it, this way the media device will
>>> stick around as long as other data structures have references to it. The
>>> current set did not yet implement this to dvb devices but I can add that.
>>> Then there's no even a need for the frontend driver to acquire the graph
>>> lock just to call the enable_source() callback.
>>
>> Taking reference to media_device alone will not solve this problem of enable
>> and disable handlers going away. au0828_unregister_media_device() will clear
>> the handlers and then call media_device_unregister() and it also does
>> media_device_cleanup(). Your patch set and media dev allocator api I did 
>> solve
> 
> Then, that should be applied to all the other callbacks in the ops structure
> as well. Not only to the callbacks that the au0828 driver needs. All the
> callbacks are really need to stay unchanged as long as the device may be in
> use.

I agree with you that media_device should stick around until all the users go
away. That is what the Media Dev Allocator API patch series does. When the
media_device shared across two drivers, We are looking at two different 
lifetimes.

media_device lufetimes (starts when the first driver creates it)

These handlers (enable_source and disable_source) are tied to au02828
driver (brid

[PATCH v6 1/3] media: Media Device Allocator API

[Shuah Khan]

Media Device Allocator API to allows multiple drivers share a media device.
Using this API, drivers can allocate a media device with the shared struct
device as the key. Once the media device is allocated by a driver, other
drivers can get a reference to it. The media device is released when all
the references are released.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
Reviewed-by: Hans Verkuil <hans.verk...@cisco.com>
---
Changes to patch 0001 since v5: (comments from Mauro and Sakari)
- Removed struct device from media_device_instance. mdev.dev is used instead.
- Added documentation.

 Documentation/media/kapi/mc-core.rst |  37 ++
 drivers/media/Makefile   |   3 +-
 drivers/media/media-dev-allocator.c  | 133 +++
 include/media/media-dev-allocator.h  |  54 ++
 4 files changed, 226 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/media-dev-allocator.c
 create mode 100644 include/media/media-dev-allocator.h

diff --git a/Documentation/media/kapi/mc-core.rst 
b/Documentation/media/kapi/mc-core.rst
index 1a738e5..4942cdd 100644
--- a/Documentation/media/kapi/mc-core.rst
+++ b/Documentation/media/kapi/mc-core.rst
@@ -257,8 +257,45 @@ Subsystems should facilitate link validation by providing 
subsystem specific
 helper functions to provide easy access for commonly needed information, and
 in the end provide a way to use driver-specific callbacks.
 
+Media Controller Device Allocator API
+^
+
+When media device belongs to more than one driver, the shared media device
+is allocated with the shared struct device as the key for look ups.
+
+Shared media device should stay in registered state until the last driver
+unregisters it. In addition, media device should be released when all the
+references are released. Each driver gets a reference to the media device
+during probe, when it allocates the media device. If media device is already
+allocated, allocate API bumps up the refcount and return the existing media
+device. Driver puts the reference back from its disconnect routine when it
+calls :c:func:`media_device_delete()`.
+
+Media device is unregistered and cleaned up from the kref put handler to
+ensure that the media device stays in registered state until the last driver
+unregisters the media device.
+
+**Driver Usage**
+
+Drivers should use the media-core routines to get register reference and
+call :c:func:`media_device_delete()` routine to make sure the shared media
+device delete is handled correctly.
+
+**driver probe:**
+Call :c:func:`media_device_usb_allocate()` to allocate or get a reference
+Call :c:func:`media_device_register()`, if media devnode isn't registered
+
+**driver disconnect:**
+Call :c:func:`media_device_delete()` to free the media_device. Free'ing is
+handled by the kref put handler.
+
+API Definitions
+^^^
+
 .. kernel-doc:: include/media/media-device.h
 
 .. kernel-doc:: include/media/media-devnode.h
 
 .. kernel-doc:: include/media/media-entity.h
+
+.. kernel-doc:: include/media/media-dev-allocator.h
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index 0deaa93..7c0701d 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -6,7 +6,8 @@ ifeq ($(CONFIG_MEDIA_CEC_EDID),y)
   obj-$(CONFIG_MEDIA_SUPPORT) += cec-edid.o
 endif
 
-media-objs := media-device.o media-devnode.o media-entity.o
+media-objs := media-device.o media-devnode.o media-entity.o \
+  media-dev-allocator.o
 
 #
 # I2C drivers should come before other drivers, otherwise they'll fail
diff --git a/drivers/media/media-dev-allocator.c 
b/drivers/media/media-dev-allocator.c
new file mode 100644
index 000..0ecf152
--- /dev/null
+++ b/drivers/media/media-dev-allocator.c
@@ -0,0 +1,133 @@
+/*
+ * media-dev-allocator.c - Media Controller Device Allocator API
+ *
+ * Copyright (c) 2016 Shuah Khan <shua...@osg.samsung.com>
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *
+ * This file is released under the GPLv2.
+ * Credits: Suggested by Laurent Pinchart <laurent.pinch...@ideasonboard.com>
+ */
+
+/*
+ * This file adds a global refcounted Media Controller Device Instance API.
+ * A system wide global media device list is managed and each media device
+ * includes a kref count. The last put on the media device releases the media
+ * device instance.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static LIST_HEAD(media_device_list);
+static DEFINE_MUTEX(media_device_lock);
+
+struct media_device_instance {
+   struct media_device mdev;
+   struct module *owner;
+   struct list_head list;
+   struct kref refcount;
+};
+
+static inline struct media_device_instance *
+to_media_device_instance(struct media_device *mdev)
+{
+   return container_of(mdev, struct media_device_instance, mdev);
+}
+
+static void media_device_instance_release(struct kref *kref)
+{
+   struct me

[PATCH v6 2/3] media: change au0828 to use Media Device Allocator API

[Shuah Khan]

Change au0828 to use Media Device Allocator API to allocate media device
with the parent usb struct device as the key, so it can be shared with the
snd_usb_audio driver.

Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
---
Changes to patch 0002:
- No changes since patch v2, applies cleanly on top of the following:
media: Protect enable_source and disable_source handler code paths
https://lkml.org/lkml/2016/11/29/1001

 drivers/media/usb/au0828/au0828-core.c | 12 
 drivers/media/usb/au0828/au0828.h  |  1 +
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-core.c 
b/drivers/media/usb/au0828/au0828-core.c
index bfd6482..ff1928e 100644
--- a/drivers/media/usb/au0828/au0828-core.c
+++ b/drivers/media/usb/au0828/au0828-core.c
@@ -159,9 +159,7 @@ static void au0828_unregister_media_device(struct 
au0828_dev *dev)
dev->media_dev->disable_source = NULL;
mutex_unlock(>graph_mutex);
 
-   media_device_unregister(dev->media_dev);
-   media_device_cleanup(dev->media_dev);
-   kfree(dev->media_dev);
+   media_device_delete(dev->media_dev, KBUILD_MODNAME);
dev->media_dev = NULL;
 #endif
 }
@@ -214,14 +212,10 @@ static int au0828_media_device_init(struct au0828_dev 
*dev,
 #ifdef CONFIG_MEDIA_CONTROLLER
struct media_device *mdev;
 
-   mdev = kzalloc(sizeof(*mdev), GFP_KERNEL);
+   mdev = media_device_usb_allocate(udev, KBUILD_MODNAME);
if (!mdev)
return -ENOMEM;
 
-   /* check if media device is already initialized */
-   if (!mdev->dev)
-   media_device_usb_init(mdev, udev, udev->product);
-
dev->media_dev = mdev;
 #endif
return 0;
@@ -482,6 +476,8 @@ static int au0828_media_device_register(struct au0828_dev 
*dev,
/* register media device */
ret = media_device_register(dev->media_dev);
if (ret) {
+   media_device_delete(dev->media_dev, KBUILD_MODNAME);
+   dev->media_dev = NULL;
dev_err(>dev,
"Media Device Register Error: %d\n", ret);
return ret;
diff --git a/drivers/media/usb/au0828/au0828.h 
b/drivers/media/usb/au0828/au0828.h
index dd7b378..4bf1b0c 100644
--- a/drivers/media/usb/au0828/au0828.h
+++ b/drivers/media/usb/au0828/au0828.h
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* DVB */
 #include "demux.h"
-- 
2.7.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