cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

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

Results of the daily build of media_tree:

date:   Tue Sep 12 05:00:15 CEST 2017
media-tree git hash:1efdf1776e2253b77413c997bed862410e4b6aaf
media_build git hash:   bbd9f669f0da6705fe44aff89281c0d6e7bfd73e
v4l-utils git hash: 7f937d31ac2af7416c60cd5ff7b5153c85e23d3a
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.12.0-164

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

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

Re: [PATCH 0/2] staging: atomisp: activate ATOMISP2401 support

[Alan Cox]

On Mon, 11 Sep 2017 20:49:27 +0200
Vincent Hervieux  wrote:

> Currently atomisp module supports Intel's Baytrail SoC and contains
> some compilation switches to support Intel's Cherrytrail SoC instead.
> The patchset aims to :
> - 1/2: activate ATOMISP2400 or ATOMISP2401 from the menu.
> - 2/2: fix compilation errors for ATOMISP2401.
> I'm not so confident with patch 2/2, as it is only working around the non 
> declared functions by using the 2400 path. As I couln't find any 
> declaration/definition for the ISP2401 missing functions...So any help would 
> be appreciated.
> Also patch 2/2 doesn't correct any cosmetic changes reported by checkpatch.pl 
> as explained in TODO step 6.

Please don't. Right now we know what work is to be done and tested.

Alan

[PATCH V2] build: Added missing functions nsecs_to_jiffies(64)

[Jasmin J.]

From: Jasmin Jessich 

Several modules expect the functions nsecs_to_jiffies64 and
nsecs_to_jiffies to be available when they get loaded. For Kernels prior
to 3.16, this symbol is not exported in time.c .
Copied the functions to compat.h, so that they get already resolved during
compilation. Define also a macro with a name conversion, because the
mentioned functions are defined as extern in include/linux/jiffies.h,
which gives an error when they are re-defined as static.

Signed-off-by: Jasmin Jessich 
---
 v4l/compat.h | 40 
 1 file changed, 40 insertions(+)

diff --git a/v4l/compat.h b/v4l/compat.h
index bfc9c51..58dcb88 100644
--- a/v4l/compat.h
+++ b/v4l/compat.h
@@ -2119,4 +2119,44 @@ static inline int pm_runtime_get_if_in_use(struct device 
*dev)
.subvendor = (subvend), .subdevice = (subdev)
 #endif
 
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 16, 0)
+
+#include 
+
+/*
+ * copied from kernel/time/time.c
+ */
+static inline u64 nsecs_to_jiffies64_static(u64 n)
+{
+#if (NSEC_PER_SEC % HZ) == 0
+/* Common case, HZ = 100, 128, 200, 250, 256, 500, 512, 1000 etc. */
+return div_u64(n, NSEC_PER_SEC / HZ);
+#elif (HZ % 512) == 0
+/* overflow after 292 years if HZ = 1024 */
+return div_u64(n * HZ / 512, NSEC_PER_SEC / 512);
+#else
+/*
+ * Generic case - optimized for cases where HZ is a multiple of 3.
+ * overflow after 64.99 years, exact for HZ = 60, 72, 90, 120 etc.
+ */
+return div_u64(n * 9, (9ull * NSEC_PER_SEC + HZ / 2) / HZ);
+#endif
+}
+
+static inline unsigned long nsecs_to_jiffies_static(u64 n)
+{
+return (unsigned long)nsecs_to_jiffies64_static(n);
+}
+
+/*
+ * linux/jiffies.h defines nsecs_to_jiffies64 and nsecs_to_jiffies
+ * as externals. To get rid of the compiler error, we redefine the
+ * functions to the static variant just defined above.
+ */
+#define nsecs_to_jiffies64(_n) nsecs_to_jiffies64_static(_n)
+#define nsecs_to_jiffies(_n) nsecs_to_jiffies_static(_n)
+
+#endif
+
 #endif /*  _COMPAT_H */
-- 
2.7.4

Re: [PATCH] media: i2c: adv748x: Map v4l2_std_id to the internal reg value

[Simon Yuan]

On Tuesday, 12 September 2017 10:26:53 NZST Kieran Bingham wrote:
> From: Simon Yuan 
> 
> The video standard was not mapped to the corresponding value of the
> internal video standard in adv748x_afe_querystd, causing the wrong
> video standard to be selected.
> 
> Fixes: 3e89586a64df ("media: i2c: adv748x: add adv748x driver")
> Signed-off-by: Simon Yuan 
> [Kieran: Obtain the std from the afe->curr_norm]
> Signed-off-by: Kieran Bingham 
> 
> ---
> Simon,
> 
> I've added your implicit Signed-off-by tag as part of resubmitting this
> patch. Please confirm your agreement to this!
> 
>  drivers/media/i2c/adv748x/adv748x-afe.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c
> b/drivers/media/i2c/adv748x/adv748x-afe.c index 134d981d69d3..5188178588c9
> 100644
> --- a/drivers/media/i2c/adv748x/adv748x-afe.c
> +++ b/drivers/media/i2c/adv748x/adv748x-afe.c
> @@ -217,6 +217,7 @@ static int adv748x_afe_querystd(struct v4l2_subdev *sd,
> v4l2_std_id *std) {
>   struct adv748x_afe *afe = adv748x_sd_to_afe(sd);
>   struct adv748x_state *state = adv748x_afe_to_state(afe);
> + int afe_std;
>   int ret;
> 
>   mutex_lock(>mutex);
> @@ -235,8 +236,12 @@ static int adv748x_afe_querystd(struct v4l2_subdev *sd,
> v4l2_std_id *std) /* Read detected standard */
>   ret = adv748x_afe_status(afe, NULL, std);
> 
> + afe_std = adv748x_afe_std(afe->curr_norm);
> + if (afe_std < 0)
> + goto unlock;
> +
>   /* Restore original state */
> - adv748x_afe_set_video_standard(state, afe->curr_norm);
> + adv748x_afe_set_video_standard(state, afe_std);
> 
>  unlock:
>   mutex_unlock(>mutex);

Hi Kieran,

No problem from me, please go ahead.

Best regards,
Simon

[PATCH] media: i2c: adv748x: Map v4l2_std_id to the internal reg value

[Kieran Bingham]

From: Simon Yuan 

The video standard was not mapped to the corresponding value of the
internal video standard in adv748x_afe_querystd, causing the wrong
video standard to be selected.

Fixes: 3e89586a64df ("media: i2c: adv748x: add adv748x driver")
Signed-off-by: Simon Yuan 
[Kieran: Obtain the std from the afe->curr_norm]
Signed-off-by: Kieran Bingham 

---
Simon,

I've added your implicit Signed-off-by tag as part of resubmitting this
patch. Please confirm your agreement to this!

 drivers/media/i2c/adv748x/adv748x-afe.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c 
b/drivers/media/i2c/adv748x/adv748x-afe.c
index 134d981d69d3..5188178588c9 100644
--- a/drivers/media/i2c/adv748x/adv748x-afe.c
+++ b/drivers/media/i2c/adv748x/adv748x-afe.c
@@ -217,6 +217,7 @@ static int adv748x_afe_querystd(struct v4l2_subdev *sd, 
v4l2_std_id *std)
 {
struct adv748x_afe *afe = adv748x_sd_to_afe(sd);
struct adv748x_state *state = adv748x_afe_to_state(afe);
+   int afe_std;
int ret;
 
mutex_lock(>mutex);
@@ -235,8 +236,12 @@ static int adv748x_afe_querystd(struct v4l2_subdev *sd, 
v4l2_std_id *std)
/* Read detected standard */
ret = adv748x_afe_status(afe, NULL, std);
 
+   afe_std = adv748x_afe_std(afe->curr_norm);
+   if (afe_std < 0)
+   goto unlock;
+
/* Restore original state */
-   adv748x_afe_set_video_standard(state, afe->curr_norm);
+   adv748x_afe_set_video_standard(state, afe_std);
 
 unlock:
mutex_unlock(>mutex);
-- 
2.7.4

Re: [PATCH v2 6/8] v4l: vsp1: Adapt entities to configure into a body

[Kieran Bingham]

Hi Laurent,

On 17/08/17 18:58, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Monday 14 Aug 2017 16:13:29 Kieran Bingham wrote:
>> Currently the entities store their configurations into a display list.
>> Adapt this such that the code can be configured into a body fragment
>> directly, allowing greater flexibility and control of the content.
>>
>> All users of vsp1_dl_list_write() are removed in this process, thus it
>> too is removed.
>>
>> A helper, vsp1_dl_list_body() is provided to access the internal body0
>> from the display list.
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/media/platform/vsp1/vsp1_bru.c| 22 ++--
>>  drivers/media/platform/vsp1/vsp1_clu.c| 22 ++--
>>  drivers/media/platform/vsp1/vsp1_dl.c | 12 ++-
>>  drivers/media/platform/vsp1/vsp1_dl.h |  2 +-
>>  drivers/media/platform/vsp1/vsp1_drm.c| 14 +---
>>  drivers/media/platform/vsp1/vsp1_entity.c | 16 -
>>  drivers/media/platform/vsp1/vsp1_entity.h | 12 ---
>>  drivers/media/platform/vsp1/vsp1_hgo.c| 16 -
>>  drivers/media/platform/vsp1/vsp1_hgt.c| 18 +-
>>  drivers/media/platform/vsp1/vsp1_hsit.c   | 10 +++---
>>  drivers/media/platform/vsp1/vsp1_lif.c| 13 +++
>>  drivers/media/platform/vsp1/vsp1_lut.c| 21 ++--
>>  drivers/media/platform/vsp1/vsp1_pipe.c   |  4 +-
>>  drivers/media/platform/vsp1/vsp1_pipe.h   |  3 +-
>>  drivers/media/platform/vsp1/vsp1_rpf.c| 43 +++-
>>  drivers/media/platform/vsp1/vsp1_sru.c| 14 
>>  drivers/media/platform/vsp1/vsp1_uds.c| 24 +++--
>>  drivers/media/platform/vsp1/vsp1_uds.h|  2 +-
>>  drivers/media/platform/vsp1/vsp1_video.c  | 11 --
>>  drivers/media/platform/vsp1/vsp1_wpf.c| 42 ---
>>  20 files changed, 168 insertions(+), 153 deletions(-)
> 
> This is quite intrusive, and it bothers me slightly that we need to pass both 
> the DL and the DLB to the configure function in order to add fragments to the 
> DL in the CLU and LUT modules. Wouldn't it be simpler to add a pointer to the 
> current body in the DL structure, and modify vsp1_dl_list_write() to write to 
> the current fragment ?
> 

No doubt about it, 168+, 153- is certainly intrusive.

Yes, now I'm looking back at this, I think this does look like this part is not
quite the right approach.

Which otherwise stalls the series until I have time to reconsider. I will likely
repost the work I have done on the earlier patches, including the
's/fragment/body/g' changes and ready myself for a v4 which will contain the
heavier reworks.

--
Kieran

Re: [PATCH v2 5/8] v4l: vsp1: Refactor display list configure operations

[Kieran Bingham]

Hi Laurent,

On 17/08/17 19:13, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Monday 14 Aug 2017 16:13:28 Kieran Bingham wrote:
>> The entities provide a single .configure operation which configures the
>> object into the target display list, based on the vsp1_entity_params
>> selection.
>>
>> This restricts us to a single function prototype for both static
>> configuration (the pre-stream INIT stage) and the dynamic runtime stages
>> for both each frame - and each partition therein.
>>
>> Split the configure function into two parts, '.prepare()' and
>> '.configure()', merging both the VSP1_ENTITY_PARAMS_RUNTIME and
>> VSP1_ENTITY_PARAMS_PARTITION stages into a single call through the
>> .configure(). The configuration for individual partitions is handled by
>> passing the partition number to the configure call, and processing any
>> runtime stage actions on the first partition only.
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/media/platform/vsp1/vsp1_bru.c|  12 +-
>>  drivers/media/platform/vsp1/vsp1_clu.c|  43 +--
>>  drivers/media/platform/vsp1/vsp1_drm.c|  11 +-
>>  drivers/media/platform/vsp1/vsp1_entity.c |  15 +-
>>  drivers/media/platform/vsp1/vsp1_entity.h |  27 +--
>>  drivers/media/platform/vsp1/vsp1_hgo.c|  12 +-
>>  drivers/media/platform/vsp1/vsp1_hgt.c|  12 +-
>>  drivers/media/platform/vsp1/vsp1_hsit.c   |  12 +-
>>  drivers/media/platform/vsp1/vsp1_lif.c|  12 +-
>>  drivers/media/platform/vsp1/vsp1_lut.c|  24 +-
>>  drivers/media/platform/vsp1/vsp1_rpf.c| 162 ++---
>>  drivers/media/platform/vsp1/vsp1_sru.c|  12 +-
>>  drivers/media/platform/vsp1/vsp1_uds.c|  55 ++--
>>  drivers/media/platform/vsp1/vsp1_video.c  |  24 +--
>>  drivers/media/platform/vsp1/vsp1_wpf.c| 297 ---
>>  15 files changed, 359 insertions(+), 371 deletions(-)
> 
> [snip]
> 
>> diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
>> b/drivers/media/platform/vsp1/vsp1_clu.c index 175717018e11..5f65ce3ad97f
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_clu.c
>> +++ b/drivers/media/platform/vsp1/vsp1_clu.c
>> @@ -213,37 +213,37 @@ static const struct v4l2_subdev_ops clu_ops = {
>>  /* 
>>   * VSP1 Entity Operations
>>   */
>> +static void clu_prepare(struct vsp1_entity *entity,
>> +struct vsp1_pipeline *pipe,
>> +struct vsp1_dl_list *dl)
>> +{
>> +struct vsp1_clu *clu = to_clu(>subdev);
>> +
>> +/*
>> + * The format can't be changed during streaming, only verify it
>> + * at setup time and store the information internally for future
>> + * runtime configuration calls.
>> + */
> 
> I know you're just moving the comment around, but let's fix it at the same 
> time. There's no verification here (and no "setup time" either). I'd write it 
> as
> 
>   /*
>* The format can't be changed during streaming. Cache it internally
>* for future runtime configuration calls.
>*/

I think I'm ok with that and I've updated the patch - but I'm not sure we are
really caching the 'format' here, as much as the yuv_mode ...

I'll ponder ...

> 
>> +struct v4l2_mbus_framefmt *format;
>> +
>> +format = vsp1_entity_get_pad_format(>entity,
>> +clu->entity.config,
>> +CLU_PAD_SINK);
>> +clu->yuv_mode = format->code == MEDIA_BUS_FMT_AYUV8_1X32;
>> +}
> 
> [snip]
> 
>> diff --git a/drivers/media/platform/vsp1/vsp1_entity.h
>> b/drivers/media/platform/vsp1/vsp1_entity.h index
>> 408602ebeb97..2f33e343ccc6 100644
>> --- a/drivers/media/platform/vsp1/vsp1_entity.h
>> +++ b/drivers/media/platform/vsp1/vsp1_entity.h
> 
> [snip]
> 
>> @@ -80,8 +68,10 @@ struct vsp1_route {
>>  /**
>>   * struct vsp1_entity_operations - Entity operations
>>   * @destroy:Destroy the entity.
>> - * @configure:  Setup the hardware based on the entity state
>> (pipeline, formats,
>> - *  selection rectangles, ...)
>> + * @prepare:Setup the initial hardware parameters for the stream
>> (pipeline,
>> + *  formats)
>> + * @configure:  Configure the runtime parameters for each partition
>> (rectangles,
>> + *  buffer addresses, ...)
> 
> Now moving to the bikeshedding territory, I'm not sure if prepare and 
> configure are the best names for those operations. I'd like to also point out 
> that we could go one step further by caching the partition-related parameters 
> too, in which case we would need a third operation (or possibly passing the 
> partition number to the prepare operation). While I won't mind if you 
> implement this now, the issue could also be addressed later, but I'd like the 
> operations to already support that use case to avoid yet another painful 
> rename patch.

Ok, understood - but I think I'll have to 

Re: [PATCH v2 8/8] v4l: vsp1: Reduce display list body size

[Kieran Bingham]

On 17/08/17 17:11, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Monday 14 Aug 2017 16:13:31 Kieran Bingham wrote:
>> The display list originally allocated a body of 256 entries to store all
>> of the register lists required for each frame.
>>
>> This has now been separated into fragments for constant stream setup, and
>> runtime updates.
>>
>> Empirical testing shows that the body0 now uses a maximum of 41
>> registers for each frame, for both DRM and Video API pipelines thus a
>> rounded 64 entries provides a suitable allocation.
> 
> Didn't you mention in patch 7/8 that one of the fragments uses exactly 64 
> entries ? Which one is it, and is there a risk it could use more ? 

No, that referred to the fragments(bodies) which had been attached. This change
refers only to the body0 allocation which has a maximum of 41 entries written.

The fragment and partition allocations which reach 64 entries, are allocated
with room for 128 currently...

< yes, this can be revisited >

>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/media/platform/vsp1/vsp1_dl.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
>> b/drivers/media/platform/vsp1/vsp1_dl.c index 176a258146ac..b3f5eb2f9a4f
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_dl.c
>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
>> @@ -21,7 +21,7 @@
>>  #include "vsp1.h"
>>  #include "vsp1_dl.h"
>>
>> -#define VSP1_DL_NUM_ENTRIES 256
>> +#define VSP1_DL_NUM_ENTRIES 64

This now only defines the size of the body0 which is the defacto list of entries
in a display list.

This too could / should be removed at somepoint I believe, leaving allocations
only where they are needed.
>>  #define VSP1_DLH_INT_ENABLE (1 << 1)
>>  #define VSP1_DLH_AUTO_START (1 << 0)
> 

Re: IR driver support for tango platforms

[Sean Young]

Hi Mason,

On Mon, Sep 11, 2017 at 04:37:42PM +0200, Mason wrote:
> Hello Sean,
> 
> After a long hiatus, I can now work again on the IR driver support
> for tango platforms. I'm still using this driver:
> 
> https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c
> 
> There are two nits I'd like to discuss.
> 
> A) When I hold a key on the RC, ir-keytable reports scancode = 0x00
> instead of the scancode for the repeated key.
> 
> # ir-keytable -t -v
> [   70.561432] show_protocols: allowed - 0x4204, enabled - 0x0
> Found device /sys/class/rc/rc0/
> Input sysfs node is /sys/class/rc/rc0/input0/
> Event sysfs node is /sys/class/rc/rc0/input0/event0/
> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
> Parsing uevent /sys/class/rc/rc0/uevent
> /sys/class/rc/rc0/uevent uevent NAME=rc-empty
> input device is /dev/input/event0
> /sys/class/rc/rc0/protocols protocol rc-5 (disabled)
> /sys/class/rc/rc0/protocols protocol nec (disabled)
> /sys/class/rc/rc0/protocols protocol rc-6 (disabled)
> Opening /dev/input/event0
> Input Protocol version: 0x00010001
> Testing events. Please, press CTRL-C to abort.
> [  227.977324] rc_keydown: keycode=0
> 227.980533: event type EV_MSC(0x04): scancode = 0x4cb41
> 227.980533: event type EV_SYN(0x00).
> 228.031069: event type EV_MSC(0x04): scancode = 0x00
> 228.031069: event type EV_SYN(0x00).
> 228.138834: event type EV_MSC(0x04): scancode = 0x00
> 228.138834: event type EV_SYN(0x00).
> 228.246603: event type EV_MSC(0x04): scancode = 0x00
> 228.246603: event type EV_SYN(0x00).
> 228.354373: event type EV_MSC(0x04): scancode = 0x00
> 228.354373: event type EV_SYN(0x00).
> 228.462143: event type EV_MSC(0x04): scancode = 0x00
> 228.462143: event type EV_SYN(0x00).
> 228.569913: event type EV_MSC(0x04): scancode = 0x00
> 228.569913: event type EV_SYN(0x00).
> 
> This behavior is caused by ir_do_keydown() not recording the keypress
> when keycode == KEY_RESERVED

That's interesting. I think happens. First, scancode 0x4cb1 is received
using extended nec; the scancode is reported via rc_keydown() by the
driver; no keycode is matched. so dev->last_scancode is not set.

Next a nec repeat is received; this is reported via rc_repeat(). This
function reports the last_scancode. Which is set to 0, since it was
never set to anything.

Note that this behaviour changed since commit 265a2988d202 ("media:
rc-core: consistent use of rc_repeat()"). Since then, the scancode is only
reported on rc_repeat() if the scancode translated to a key.

> If I apply the following patch, then the repeated scancode works
> as I would expect.
> 
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -687,6 +687,10 @@ void rc_keydown(struct rc_dev *dev, enum rc_type 
> protocol, u32 scancode, u8 togg
> unsigned long flags;
> u32 keycode = rc_g_keycode_from_table(dev, scancode);
> +   printk("%s: keycode=%x\n", __func__, keycode);
> +   if (keycode == KEY_RESERVED)
> +   keycode = KEY_UNKNOWN;
> +
> spin_lock_irqsave(>keylock, flags);
> ir_do_keydown(dev, protocol, scancode, keycode, toggle);
> 
> 
> # ir-keytable -t -v
> [   68.192161] show_protocols: allowed - 0x4204, enabled - 0x0
> Found device /sys/class/rc/rc0/
> Input sysfs node is /sys/class/rc/rc0/input0/
> Event sysfs node is /sys/class/rc/rc0/input0/event0/
> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
> Parsing uevent /sys/class/rc/rc0/uevent
> /sys/class/rc/rc0/uevent uevent NAME=rc-empty
> input device is /dev/input/event0
> /sys/class/rc/rc0/protocols protocol rc-5 (disabled)
> /sys/class/rc/rc0/protocols protocol nec (disabled)
> /sys/class/rc/rc0/protocols protocol rc-6 (disabled)
> Opening /dev/input/event0
> Input Protocol version: 0x00010001
> Testing events. Please, press CTRL-C to abort.
> [   92.739308] rc_keydown: keycode=0
> [   92.742650] tango-ir: key down event, key 0x00f0, protocol 0x0009, 
> scancode 0x0004cb41
> 92.749621: event type EV_MSC(0x04): scancode = 0x4cb41
> 92.749621: event type EV_SYN(0x00).
> 92.792201: event type EV_MSC(0x04): scancode = 0x4cb41
> 92.792201: event type EV_SYN(0x00).
> 92.899966: event type EV_MSC(0x04): scancode = 0x4cb41
> 92.899966: event type EV_SYN(0x00).
> 93.007734: event type EV_MSC(0x04): scancode = 0x4cb41
> 93.007734: event type EV_SYN(0x00).
> 93.115501: event type EV_MSC(0x04): scancode = 0x4cb41
> 93.115501: event type EV_SYN(0x00).
> 93.223269: event type EV_MSC(0x04): scancode = 0x4cb41
> 93.223269: event type EV_SYN(0x00).
> 93.331039: event type EV_MSC(0x04): scancode = 0x4cb41
> 93.331039: event type EV_SYN(0x00).
> [  

Re: [PATCH v9 18/24] as3645a: Switch to fwnode property API

[Jacek Anaszewski]

Hi Sakari,

On 09/09/2017 11:36 PM, Sakari Ailus wrote:
> Hi Jacek,
> 
> On Sat, Sep 09, 2017 at 09:06:41PM +0200, Jacek Anaszewski wrote:
>> Hi Sakari,
>>
>> I've come across this patch only by a chance. I believe that merging
>> leds-as3645a.c patches via media tree is not going to be a persistent
>> pattern. At least we haven't agreed on that, and in any case I should
>> have a possibility to give my ack for this patch.
> 
> Correct. The reason the previous patches went through linux-media was
> because these patches dependend on other patches only in linux-media at the
> time. This is no longer the case (the three as3645a patches I'd like to get
> in as fixes are another matter but let's discuss that separately).
> 
>>
>> Would you mind also adding linux-leds list on cc when touching areas
>> related to LED/flash devices?
> 
> I added this patch to this version of the set and missed cc'ing it to
> linux-leds. I think I'll send it there separately once the 17th patch (ACPI
> support) has been reviewed. The two are loosely related to the rest of the
> patches in the set but there's no hard dependency.

Right, they are loosely related, but cross-posting anything having "LED"
in its contents to linux-leds list would be understandable if not
desirable :-) Just to keep LED people in sync.

-- 
Best regards,
Jacek Anaszewski

Re: [PATCH 1/2] staging: atomisp: add menu entries to choose between ATOMISP_2400 and ATOMISP_2401.

[Dan Carpenter]

No changelog.  No Signed-off-by line.  Without reading too carefully, or
trying to do a build, it looks like we're activating the menu items and
then fixing the build.  It should be the other way around so that we
don't break git bisect.  People are always doing randconfig and the
autobuilders detect breakage really quick.

On Mon, Sep 11, 2017 at 08:50:26PM +0200, Vincent Hervieux wrote:
> @@ -347,8 +347,16 @@ DEFINES := -DHRT_HW -DHRT_ISP_CSS_CUSTOM_HOST 
> -DHRT_USE_VIR_ADDRS -D__HOST__
>  #DEFINES += -DPUNIT_CAMERA_BUSY
>  #DEFINES += -DUSE_KMEM_CACHE
>  
> +ifeq ($(CONFIG_VIDEO_ATOMISP_ISP2400),y)
> +# Merrifield, Baytrail
>  DEFINES += -DATOMISP_POSTFIX=\"css2400b0_v21\" -DISP2400B0
>  DEFINES += -DSYSTEM_hive_isp_css_2400_system -DISP2400
> +endif
> +ifeq ($(CONFIG_VIDEO_ATOMISP_ISP2401),y)
> +# Anniedale (Merrifield+ / Moorefield), Cherrytrail
> +DEFINES += -DATOMISP_POSTFIX=\"css2401a0_v21\" -DISP2401A0
> +DEFINES += -DSYSTEM_hive_isp_css_2400_system -DISP2401 
> -DISP2401_NEW_INPUT_SYSTEM

These defines are a bit ugly.  Eventually we will want to get rid of
these.

regards,
dan carpenter

Re: [PATCH 2/2] staging: atomisp: fix compilation errors in case of ISP2401.

[Dan Carpenter]

We always need a changelog.  And actually this seems a bit involved so
there is stuff to explain.

On Mon, Sep 11, 2017 at 08:51:15PM +0200, Vincent Hervieux wrote:
> Signed-off-by: Vincent Hervieux 
> ---
>  .../media/atomisp/pci/atomisp2/atomisp_cmd.c   |  5 ++---
>  .../media/atomisp/pci/atomisp2/atomisp_v4l2.c  |  6 +-
>  .../pci/atomisp2/css2400/ia_css_acc_types.h|  1 +
>  .../css2400/runtime/debug/src/ia_css_debug.c   |  3 ---
>  .../media/atomisp/pci/atomisp2/css2400/sh_css.c| 24 
> ++
>  .../atomisp/pci/atomisp2/css2400/sh_css_params.c   |  8 +---
>  6 files changed, 20 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
> b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> index f48bf451c1f5..d79a3cfb834d 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
> @@ -1045,9 +1045,8 @@ void atomisp_buf_done(struct atomisp_sub_device *asd, 
> int error,
>   asd->re_trigger_capture = false;
>   dev_dbg(isp->dev, "Trigger capture again for 
> new buffer. err=%d\n",
>   err);
> - } else {
> - asd->re_trigger_capture = true;
> - }
> + } else {
> + asd->re_trigger_capture = true;
>  #endif
>   }
>   break;
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
> b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
> index 663aa916e3ca..1e61f66437d2 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
> @@ -1602,4 +1602,8 @@ module_exit(atomisp_exit);
>  MODULE_AUTHOR("Wen Wang ");
>  MODULE_AUTHOR("Xiaolin Zhang ");
>  MODULE_LICENSE("GPL");
> -MODULE_DESCRIPTION("Intel ATOM Platform ISP Driver");
> +#if defined(ISP2400) || defined(ISP2400B0)
> +MODULE_DESCRIPTION("Intel ATOM Platform ISP Driver 2400");
> +#elif defined(ISP2401)
> +MODULE_DESCRIPTION("Intel ATOM Platform ISP Driver 2401");
> +#endif
> diff --git 
> a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_acc_types.h 
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_acc_types.h
> index a2a1873aca83..3bcbd0fa0637 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_acc_types.h
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_acc_types.h
> @@ -222,6 +222,7 @@ struct ia_css_binary_info {
>   uint8_t luma_only;
>   uint8_t input_yuv;
>   uint8_t input_raw;
> + uint8_t lace_stats;
>  #endif
>   uint8_t reduced_pipe;
>   uint8_t vf_veceven;
> diff --git 
> a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c
>  
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c
> index 0fa7cb2423d8..6f6e30cb7550 100644
> --- 
> a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c
> +++ 
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c
> @@ -49,9 +49,6 @@
>  #include "assert_support.h"
>  #include "print_support.h"
>  #include "string_support.h"
> -#ifdef ISP2401
> -#include "ia_css_system_ctrl.h"
> -#endif
>  
>  #include "fifo_monitor.h"
>  
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c 
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
> index e882b5596813..1d2e56e74e01 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
> @@ -1496,7 +1496,7 @@ sh_css_invalidate_shading_tables(struct ia_css_stream 
> *stream)
>   "sh_css_invalidate_shading_tables() leave: return_void\n");
>  }
>  
> -#ifndef ISP2401
> +#if 1 /* was ndef ISP2401 but this function is used by ISP2401 on line 1758 
> */

Just delete the #if.  (I haven't looked at the code).  These comments
should probably be in the changelog.  You probably want to break this
patch up into several patches and add a little changelog for each
explaining what's going on.

Extra curly brace.  Bad indenting.  Add a missing struct member.
Delete references to header file that doesn't exist.  Delete defines.

regards,
dan carpenter

Re: [PATCHv4 3/5] dt-bindings: document the CEC GPIO bindings

[Linus Walleij]

On Thu, Aug 31, 2017 at 1:01 PM, Hans Verkuil  wrote:

> +   cec-gpio = < 7 GPIO_OPEN_DRAIN>;

Actually if you want to be 100% specific:

cec-gpio = < 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;

(Parens are needed.)

But I'm not very picky about that, active high is implicit.

Yours,
Linus Walleij

Re: [PATCH] [media] v4l: vsp1: Use generic node name

[Rob Herring]

On Wed, Aug 30, 2017 at 11:57:31AM +0200, Geert Uytterhoeven wrote:
> Use the preferred generic node name in the example.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/devicetree/bindings/media/renesas,vsp1.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

Rob

Re: [PATCH v2 2/8] v4l: vsp1: Provide a fragment pool

[Kieran Bingham]

Hi Laurent,

Thanks for your review,

On 17/08/17 13:13, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Monday 14 Aug 2017 16:13:25 Kieran Bingham wrote:
>> Each display list allocates a body to store register values in a dma
>> accessible buffer from a dma_alloc_wc() allocation. Each of these
>> results in an entry in the TLB, and a large number of display list
>> allocations adds pressure to this resource.
>>
>> Reduce TLB pressure on the IPMMUs by allocating multiple display list
>> bodies in a single allocation, and providing these to the display list
>> through a 'fragment pool'. A pool can be allocated by the display list
>> manager or entities which require their own body allocations.
>>
>> Signed-off-by: Kieran Bingham 
>>
>> ---
>> v2:
>>  - assign dlb->dma correctly
>> ---
>>  drivers/media/platform/vsp1/vsp1_dl.c | 129 +++-
>>  drivers/media/platform/vsp1/vsp1_dl.h |   8 ++-
>>  2 files changed, 137 insertions(+)
>>
>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
>> b/drivers/media/platform/vsp1/vsp1_dl.c index cb4625ae13c2..aab9dd6ec0eb
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_dl.c
>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
>> @@ -45,6 +45,8 @@ struct vsp1_dl_entry {
>>  /**
>>   * struct vsp1_dl_body - Display list body
>>   * @list: entry in the display list list of bodies
>> + * @free: entry in the pool free body list
>> + * @pool: pool to which this body belongs
>>   * @vsp1: the VSP1 device
>>   * @entries: array of entries
>>   * @dma: DMA address of the entries
>> @@ -54,6 +56,9 @@ struct vsp1_dl_entry {
>>   */
>>  struct vsp1_dl_body {
>>  struct list_head list;
>> +struct list_head free;
>> +
>> +struct vsp1_dl_fragment_pool *pool;
>>  struct vsp1_device *vsp1;
>>
>>  struct vsp1_dl_entry *entries;
>> @@ -65,6 +70,30 @@ struct vsp1_dl_body {
>>  };
>>
>>  /**
>> + * struct vsp1_dl_fragment_pool - display list body/fragment pool
>> + * @dma: DMA address of the entries
>> + * @size: size of the full DMA memory pool in bytes
>> + * @mem: CPU memory pointer for the pool
>> + * @bodies: Array of DLB structures for the pool
>> + * @free: List of free DLB entries
>> + * @lock: Protects the pool and free list
>> + * @vsp1: the VSP1 device
>> + */
>> +struct vsp1_dl_fragment_pool {
>> +/* DMA allocation */
>> +dma_addr_t dma;
>> +size_t size;
>> +void *mem;
>> +
>> +/* Body management */
>> +struct vsp1_dl_body *bodies;
>> +struct list_head free;
>> +spinlock_t lock;
>> +
>> +struct vsp1_device *vsp1;
>> +};
>> +
>> +/**
>>   * struct vsp1_dl_list - Display list
>>   * @list: entry in the display list manager lists
>>   * @dlm: the display list manager
>> @@ -104,6 +133,7 @@ enum vsp1_dl_mode {
>>   * @active: list currently being processed (loaded) by hardware
>>   * @queued: list queued to the hardware (written to the DL registers)
>>   * @pending: list waiting to be queued to the hardware
>> + * @pool: fragment pool for the display list bodies
>>   * @gc_work: fragments garbage collector work struct
>>   * @gc_fragments: array of display list fragments waiting to be freed
>>   */
>> @@ -119,6 +149,8 @@ struct vsp1_dl_manager {
>>  struct vsp1_dl_list *queued;
>>  struct vsp1_dl_list *pending;
>>
>> +struct vsp1_dl_fragment_pool *pool;
>> +
>>  struct work_struct gc_work;
>>  struct list_head gc_fragments;
>>  };
>> @@ -128,6 +160,103 @@ struct vsp1_dl_manager {
>>   */
>>
>>  /*
>> + * Fragment pool's reduce the pressure on the iommu TLB by allocating a
>> single
>> + * large area of DMA memory and allocating it as a pool of fragment bodies
>> + */
> 
> Could you document non-static function using kerneldoc ? Parameters to this 
> function would benefit from some documentation. I'd also like to see the 
> fragment get/put functions documented, as you remove existing kerneldoc for 
> the alloc/free existing functions in patch 3/8.

Ah yes of course.

>> +struct vsp1_dl_fragment_pool *
>> +vsp1_dl_fragment_pool_alloc(struct vsp1_device *vsp1, unsigned int qty,
> 
> I think I would name this function vsp1_dl_fragment_pool_create(), as it does 
> more than just allocating memory. Similarly I'd call the free function 
> vsp1_dl_fragment_pool_destroy().

That sounds reasonable. Done.

> qty is a bit vague, I'd rename it to num_fragments.

Ok with me.

> 
>> +unsigned int num_entries, size_t extra_size)
>> +{
>> +struct vsp1_dl_fragment_pool *pool;
>> +size_t dlb_size;
>> +unsigned int i;
>> +
>> +pool = kzalloc(sizeof(*pool), GFP_KERNEL);
>> +if (!pool)
>> +return NULL;
>> +
>> +pool->vsp1 = vsp1;
>> +
>> +dlb_size = num_entries * sizeof(struct vsp1_dl_entry) + extra_size;
> 
> extra_size is only used by vsp1_dlm_create(), to allocate extra memory for 
> the 
> display list header. We need one header per display list, not per display 
> list 
> 

Re: [PATCH v2 3/8] v4l: vsp1: Convert display lists to use new fragment pool

[Kieran Bingham]

Hi Laurent,

Thanks for the review

On 17/08/17 13:13, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Monday 14 Aug 2017 16:13:26 Kieran Bingham wrote:
>> Adapt the dl->body0 object to use an object from the fragment pool.
>> This greatly reduces the pressure on the TLB for IPMMU use cases, as
>> all of the lists use a single allocation for the main body.
>>
>> The CLU and LUT objects pre-allocate a pool containing two bodies,
>> allowing a userspace update before the hardware has committed a previous
>> set of tables.
> 
> I think you'll need three bodies, one for the DL queued to the hardware, one 
> for the pending DL and one for the new DL needed when you update the LUT/CLU. 
> Given that the VSP test suite hasn't caught this problem, we also need a new 
> test :-)
> 
>> Fragments are no longer 'freed' in interrupt context, but instead
>> released back to their respective pools.  This allows us to remove the
>> garbage collector in the DLM.
>>
>> Signed-off-by: Kieran Bingham 
>>
>> ---
>> v2:
>>  - Use dl->body0->max_entries to determine header offset, instead of the
>>global constant VSP1_DL_NUM_ENTRIES which is incorrect.
>>  - squash updates for LUT, CLU, and fragment cleanup into single patch.
>>(Not fully bisectable when separated)
>> ---
>>  drivers/media/platform/vsp1/vsp1_clu.c |  22 ++-
>>  drivers/media/platform/vsp1/vsp1_clu.h |   1 +-
>>  drivers/media/platform/vsp1/vsp1_dl.c  | 223 +-
>>  drivers/media/platform/vsp1/vsp1_dl.h  |   3 +-
>>  drivers/media/platform/vsp1/vsp1_lut.c |  23 ++-
>>  drivers/media/platform/vsp1/vsp1_lut.h |   1 +-
>>  6 files changed, 90 insertions(+), 183 deletions(-)
> 
> This is a nice diffstat, but only if you add kerneldoc for the new functions 
> introduced in patch 2/8, otherwise the overall documentation diffstat looks 
> bad :-)
> 
>> diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
>> b/drivers/media/platform/vsp1/vsp1_clu.c index f2fb26e5ab4e..52c523625e2f
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_clu.c
>> +++ b/drivers/media/platform/vsp1/vsp1_clu.c
> 
> [snip]
> 
>> @@ -288,6 +298,12 @@ struct vsp1_clu *vsp1_clu_create(struct vsp1_device
>> *vsp1) if (ret < 0)
>>  return ERR_PTR(ret);
>>
>> +/* Allocate a fragment pool */
> 
> The comment would be more useful if you explained why you need to allocate a 
> pool here. Same comment for the LUT.

Done

> 
>> +clu->pool = vsp1_dl_fragment_pool_alloc(clu->entity.vsp1, 2,
>> +CLU_SIZE + 1, 0);
>> +if (!clu->pool)
>> +return ERR_PTR(-ENOMEM);
>> +
>>  /* Initialize the control handler. */
>>  v4l2_ctrl_handler_init(>ctrls, 2);
>>  v4l2_ctrl_new_custom(>ctrls, _table_control, NULL);
> 
> [snip]
> 
>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
>> b/drivers/media/platform/vsp1/vsp1_dl.c index aab9dd6ec0eb..6ffdc3549283
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_dl.c
>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> 
> [snip]
> 
> 
>> @@ -379,41 +289,39 @@ static struct vsp1_dl_list *vsp1_dl_list_alloc(struct
>> vsp1_dl_manager *dlm) INIT_LIST_HEAD(>fragments);
>>  dl->dlm = dlm;
>>
>> -/*
>> - * Initialize the display list body and allocate DMA memory for the 
> body
>> - * and the optional header. Both are allocated together to avoid 
> memory
>> - * fragmentation, with the header located right after the body in
>> - * memory.
>> - */
>> -header_size = dlm->mode == VSP1_DL_MODE_HEADER
>> -? ALIGN(sizeof(struct vsp1_dl_header), 8)
>> -: 0;
>> -
>> -ret = vsp1_dl_body_init(dlm->vsp1, >body0, VSP1_DL_NUM_ENTRIES,
>> -header_size);
>> -if (ret < 0) {
>> -kfree(dl);
>> +/* Retrieve a body from our DLM body pool */
>> +dl->body0 = vsp1_dl_fragment_get(pool);
>> +if (!dl->body0)
>>  return NULL;
>> -}
>> -
>>  if (dlm->mode == VSP1_DL_MODE_HEADER) {
>> -size_t header_offset = VSP1_DL_NUM_ENTRIES
>> - * sizeof(*dl->body0.entries);
>> +size_t header_offset = dl->body0->max_entries
>> + * sizeof(*dl->body0->entries);
>>
>> -dl->header = ((void *)dl->body0.entries) + header_offset;
>> -dl->dma = dl->body0.dma + header_offset;
>> +dl->header = ((void *)dl->body0->entries) + header_offset;
>> +dl->dma = dl->body0->dma + header_offset;
>>
>>  memset(dl->header, 0, sizeof(*dl->header));
>> -dl->header->lists[0].addr = dl->body0.dma;
>> +dl->header->lists[0].addr = dl->body0->dma;
>>  }
>>
>>  return dl;
>>  }
>>
>> +static void vsp1_dl_list_fragments_free(struct vsp1_dl_list *dl)
> 
> This function doesn't free fragments put puts them back to the free list. I'd 
> call it 

Re: A patch for a bug in adv748x

[Simon Yuan]

On Tuesday, 12 September 2017 07:00:33 NZST Kieran Bingham wrote:
> Hi Simon,
> 
> On 11/09/17 05:30, Simon Yuan wrote:
> > Hi Niklas,
> > 
> > How are you doing? I've picked you as my contact since I met you earlier
> > this year at ELC2017. Not sure if you still remember, but we had a very
> > brief chat about the status of the adv748x driver.
> 
> I'll let Niklas reply to this bit :D
> 
> > Anyway, the real reason for this email is due to a bug I found in the
> > driver while integrating it into our product. I've attached a patch which
> > should be self explanatory. If you are the wrong person to contact, feel
> > free to forward this email to the right person, or let me know who I
> > should contact.
> Thanks for trying out the driver!
> 
> You're right, I think you have indeed found a bug - but I'm not certain the
> fix is correct...
> 
> Comment inline on the patch below...
> 
> > I've also made significant changes to the driver in order to satisfy our
> > video path requirements. We need to be able to dynamically switch between
> > HDMI/ composite input connected to TXA.
> > 
> > Is there a plan to make the current driver more flexible? The way I worked
> > around the current limitations is by introducing a media_entity for each
> > connector (e.g. HDMI and 18 types of analog input) physically connected to
> > the video decoder, and dynamically change the internal routing based on
> > the user selected connector linked to CP/SDP.
> 
> We did try to design the driver such that we could extend the flexibility
> later, but have pushed the driver upstream as the current version.
> 
> I hope to add CEC, and hotplug support later ... but I don't know when that
> work will be scheduled yet. - Of course - I'm happy to review patches :D
> > I'm not entirely satisfied with my workaround, so I won't embarrass myself
> > by sending a patch for the modified routing scheme.
> 
> I would be interested in seeing your implementation, feel free to send off
> lists if you prefer :D - I won't judge!
> 
> Regards
> 
> Kieran
> 
> > From 35eea62811d15c096341221c02abab3daadb9a19 Mon Sep 17 00:00:00 2001
> > From: Simon Yuan 
> > Date: Mon, 11 Sep 2017 16:07:40 +1200
> > Subject: [PATCH] media: i2c: adv748x: Map v4l2_std_id to the internal reg
> > 
> >  value
> > 
> > The video standard was not mapped to the corresponding value of the
> > internal video standard in adv748x_afe_querystd, causing the wrong
> > video standard to be selected.
> > ---
> > 
> >  drivers/media/i2c/adv748x/adv748x-afe.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c
> > b/drivers/media/i2c/adv748x/adv748x-afe.c index
> > b33ccfc08708..9692e9ea2b70 100644
> > --- a/drivers/media/i2c/adv748x/adv748x-afe.c
> > +++ b/drivers/media/i2c/adv748x/adv748x-afe.c
> > @@ -217,6 +217,7 @@ static int adv748x_afe_querystd(struct v4l2_subdev
> > *sd, v4l2_std_id *std)> 
> >  {
> >  
> > struct adv748x_afe *afe = adv748x_sd_to_afe(sd);
> > struct adv748x_state *state = adv748x_afe_to_state(afe);
> > 
> > +   int afe_std;
> > 
> > int ret;
> > 
> > mutex_lock(>mutex);
> > 
> > @@ -235,8 +236,12 @@ static int adv748x_afe_querystd(struct v4l2_subdev
> > *sd, v4l2_std_id *std)> 
> > /* Read detected standard */
> > ret = adv748x_afe_status(afe, NULL, std);
> > 
> > +   afe_std = adv748x_afe_std(std);
> 
> I think this should get the afe_std for the afe->curr_norm. This function
> should leave the hardware in the configured state (not the detected state).
> 
> If you agree, I'll update the patch and send to the mailinglists for
> integration.
> > +   if (afe_std < 0)
> > +   goto unlock;
> > +
> > 
> > /* Restore original state */
> > 
> > -   adv748x_afe_set_video_standard(state, afe->curr_norm);
> > +   adv748x_afe_set_video_standard(state, afe_std);
> > 
> >  unlock:
> > mutex_unlock(>mutex);
> > 
> > Best regards,
> > Simon

Hi Kieran,

You are correct, I wasn't thinking straight. I've indeed introduced a bug 
within a bug :)

You are more than welcome to modify the patch and send it off for integration.

As for my implementation of the internal routing, I can certainly send it to 
you later once the implementation matures a bit.

Best regards,
Simon

Re: [media] s5p-mfc: Delete an error message for a failed memory allocation in s5p_mfc_probe()

[SF Markus Elfring]

> Could you make the commit summary shorter, to keep it
> below 70 characters [1]? With that changed feel free to add
> 
> Acked-by: Sylwester Nawrocki 
…
> [1] Documentation/process/submitting-patches.rst

Will it be sufficient that a patch committer will adjust
the summary phrase a bit?

Regards,
Markus

Re: [media] s5p-mfc: Adjust a null pointer check in four functions

[SF Markus Elfring]

>> Date: Fri, 8 Sep 2017 22:37:00 +0200
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
> 
> Can you resend with that 4 lines removed?

* Do you care to preserve an information like the author date?

* Would you like to support special characters in the commit message?


> Are you using git send-email for sending patches?

Not so far.

Regards,
Markus

Re: A patch for a bug in adv748x

[Kieran Bingham]

Hi Simon,

On 11/09/17 05:30, Simon Yuan wrote:
> Hi Niklas,
>
> How are you doing? I've picked you as my contact since I met you earlier this
> year at ELC2017. Not sure if you still remember, but we had a very brief chat
> about the status of the adv748x driver.

I'll let Niklas reply to this bit :D


> Anyway, the real reason for this email is due to a bug I found in the driver
> while integrating it into our product. I've attached a patch which should be
> self explanatory. If you are the wrong person to contact, feel free to forward
> this email to the right person, or let me know who I should contact.


Thanks for trying out the driver!

You're right, I think you have indeed found a bug - but I'm not certain the fix
is correct...

Comment inline on the patch below...


> I've also made significant changes to the driver in order to satisfy our video
> path requirements. We need to be able to dynamically switch between HDMI/
> composite input connected to TXA.
>
> Is there a plan to make the current driver more flexible? The way I worked
> around the current limitations is by introducing a media_entity for each
> connector (e.g. HDMI and 18 types of analog input) physically connected to the
> video decoder, and dynamically change the internal routing based on the user
> selected connector linked to CP/SDP.

We did try to design the driver such that we could extend the flexibility later,
but have pushed the driver upstream as the current version.

I hope to add CEC, and hotplug support later ... but I don't know when that work
will be scheduled yet. - Of course - I'm happy to review patches :D

> I'm not entirely satisfied with my workaround, so I won't embarrass myself by
> sending a patch for the modified routing scheme.

I would be interested in seeing your implementation, feel free to send off lists
if you prefer :D - I won't judge!

Regards

Kieran




> From 35eea62811d15c096341221c02abab3daadb9a19 Mon Sep 17 00:00:00 2001
> From: Simon Yuan 
> Date: Mon, 11 Sep 2017 16:07:40 +1200
> Subject: [PATCH] media: i2c: adv748x: Map v4l2_std_id to the internal reg
>  value
> 
> The video standard was not mapped to the corresponding value of the
> internal video standard in adv748x_afe_querystd, causing the wrong
> video standard to be selected.
> ---
>  drivers/media/i2c/adv748x/adv748x-afe.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-afe.c 
> b/drivers/media/i2c/adv748x/adv748x-afe.c
> index b33ccfc08708..9692e9ea2b70 100644
> --- a/drivers/media/i2c/adv748x/adv748x-afe.c
> +++ b/drivers/media/i2c/adv748x/adv748x-afe.c
> @@ -217,6 +217,7 @@ static int adv748x_afe_querystd(struct v4l2_subdev *sd, 
> v4l2_std_id *std)
>  {
>   struct adv748x_afe *afe = adv748x_sd_to_afe(sd);
>   struct adv748x_state *state = adv748x_afe_to_state(afe);
> + int afe_std;
>   int ret;
>  
>   mutex_lock(>mutex);
> @@ -235,8 +236,12 @@ static int adv748x_afe_querystd(struct v4l2_subdev *sd, 
> v4l2_std_id *std)
>   /* Read detected standard */
>   ret = adv748x_afe_status(afe, NULL, std);
>  
> + afe_std = adv748x_afe_std(std);

I think this should get the afe_std for the afe->curr_norm. This function should
leave the hardware in the configured state (not the detected state).

If you agree, I'll update the patch and send to the mailinglists for 
integration.

> + if (afe_std < 0)
> + goto unlock;
> +
>   /* Restore original state */
> - adv748x_afe_set_video_standard(state, afe->curr_norm);
> + adv748x_afe_set_video_standard(state, afe_std);
>  
>  unlock:
>   mutex_unlock(>mutex);
> -- 
> 2.14.1



> Best regards,
> Simon
> 

[PATCH 2/2] staging: atomisp: fix compilation errors in case of ISP2401.

[Vincent Hervieux]

Signed-off-by: Vincent Hervieux 
---
 .../media/atomisp/pci/atomisp2/atomisp_cmd.c   |  5 ++---
 .../media/atomisp/pci/atomisp2/atomisp_v4l2.c  |  6 +-
 .../pci/atomisp2/css2400/ia_css_acc_types.h|  1 +
 .../css2400/runtime/debug/src/ia_css_debug.c   |  3 ---
 .../media/atomisp/pci/atomisp2/css2400/sh_css.c| 24 ++
 .../atomisp/pci/atomisp2/css2400/sh_css_params.c   |  8 +---
 6 files changed, 20 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index f48bf451c1f5..d79a3cfb834d 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -1045,9 +1045,8 @@ void atomisp_buf_done(struct atomisp_sub_device *asd, int 
error,
asd->re_trigger_capture = false;
dev_dbg(isp->dev, "Trigger capture again for 
new buffer. err=%d\n",
err);
-   } else {
-   asd->re_trigger_capture = true;
-   }
+   } else {
+   asd->re_trigger_capture = true;
 #endif
}
break;
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 663aa916e3ca..1e61f66437d2 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -1602,4 +1602,8 @@ module_exit(atomisp_exit);
 MODULE_AUTHOR("Wen Wang ");
 MODULE_AUTHOR("Xiaolin Zhang ");
 MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("Intel ATOM Platform ISP Driver");
+#if defined(ISP2400) || defined(ISP2400B0)
+MODULE_DESCRIPTION("Intel ATOM Platform ISP Driver 2400");
+#elif defined(ISP2401)
+MODULE_DESCRIPTION("Intel ATOM Platform ISP Driver 2401");
+#endif
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_acc_types.h 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_acc_types.h
index a2a1873aca83..3bcbd0fa0637 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_acc_types.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_acc_types.h
@@ -222,6 +222,7 @@ struct ia_css_binary_info {
uint8_t luma_only;
uint8_t input_yuv;
uint8_t input_raw;
+   uint8_t lace_stats;
 #endif
uint8_t reduced_pipe;
uint8_t vf_veceven;
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c
index 0fa7cb2423d8..6f6e30cb7550 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/runtime/debug/src/ia_css_debug.c
@@ -49,9 +49,6 @@
 #include "assert_support.h"
 #include "print_support.h"
 #include "string_support.h"
-#ifdef ISP2401
-#include "ia_css_system_ctrl.h"
-#endif
 
 #include "fifo_monitor.h"
 
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
index e882b5596813..1d2e56e74e01 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
@@ -1496,7 +1496,7 @@ sh_css_invalidate_shading_tables(struct ia_css_stream 
*stream)
"sh_css_invalidate_shading_tables() leave: return_void\n");
 }
 
-#ifndef ISP2401
+#if 1 /* was ndef ISP2401 but this function is used by ISP2401 on line 1758 */
 static void
 enable_interrupts(enum ia_css_irq_type irq_type)
 {
@@ -1709,7 +1709,7 @@ ia_css_init(const struct ia_css_env *env,
enable = gpio_reg_load(GPIO0_ID, _gpio_block_reg_do_e)
| GPIO_FLASH_PIN_MASK;
sh_css_mmu_set_page_table_base_index(mmu_l1_base);
-#ifndef ISP2401
+#if 1 /* was ndef ISP2401 but ia_css_save_mmu_base_addr is not declared */
my_css_save.mmu_base = mmu_l1_base;
 #else
ia_css_save_mmu_base_addr(mmu_l1_base);
@@ -1726,7 +1726,7 @@ ia_css_init(const struct ia_css_env *env,
return err;
}
 
-#ifndef ISP2401
+#if 1 /* was ndef ISP2401 but ia_css_save_restore_data_init is not declared */
IA_CSS_LOG("init: %d", my_css_save_initialized);
 #else
ia_css_save_restore_data_init();
@@ -1750,7 +1750,7 @@ ia_css_init(const struct ia_css_env *env,
 
 #endif
my_css.irq_type = irq_type;
-#ifndef ISP2401
+#if 1 /* was ndef ISP2401 but ia_css_save_irq_type is not declared */
my_css_save.irq_type = irq_type;
 #else

[PATCH 1/2] staging: atomisp: add menu entries to choose between ATOMISP_2400 and ATOMISP_2401.

[Vincent Hervieux]

---
 drivers/staging/media/atomisp/pci/Kconfig  | 23 ++
 .../staging/media/atomisp/pci/atomisp2/Makefile| 10 +-
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/Kconfig 
b/drivers/staging/media/atomisp/pci/Kconfig
index a72421431c7a..e3e00ade1d38 100644
--- a/drivers/staging/media/atomisp/pci/Kconfig
+++ b/drivers/staging/media/atomisp/pci/Kconfig
@@ -11,3 +11,26 @@ config VIDEO_ATOMISP
   camera imaging subsystem.
   To compile this driver as a module, choose M here: the
   module will be called atomisp
+
+choice
+prompt "Intel Atom Image Signal Processor Driver Type"
+depends on VIDEO_ATOMISP
+default VIDEO_ATOMISP_ISP2400
+help
+  Intel Atom Image Signal Processor Driver actually doesn't support
+  dynamically all SoC.
+  So need to choose at compilation time which SoC it can support.
+  Please refer to staging TODO for more details.
+
+config VIDEO_ATOMISP_ISP2400
+bool "ISP2400"
+help
+  Atom ISP for Merrifield, Baytrail SoC.
+
+config VIDEO_ATOMISP_ISP2401
+bool "ISP2401"
+help
+  Atom ISP for Anniedale (Merrifield+ / Moorefield), Cherrytrail SoC.
+
+endchoice
+
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/Makefile 
b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
index 2bd98f0667ec..27ac23c0c18d 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/Makefile
+++ b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
@@ -155,7 +155,7 @@ atomisp-objs += \
hmm/hmm_dynamic_pool.o \
hrt/hive_isp_css_mm_hrt.o \
atomisp_v4l2.o
-   
+
 # These will be needed when clean merge CHT support nicely into the driver
 # Keep them here handy for when we get to that point
 #
@@ -347,8 +347,16 @@ DEFINES := -DHRT_HW -DHRT_ISP_CSS_CUSTOM_HOST 
-DHRT_USE_VIR_ADDRS -D__HOST__
 #DEFINES += -DPUNIT_CAMERA_BUSY
 #DEFINES += -DUSE_KMEM_CACHE
 
+ifeq ($(CONFIG_VIDEO_ATOMISP_ISP2400),y)
+# Merrifield, Baytrail
 DEFINES += -DATOMISP_POSTFIX=\"css2400b0_v21\" -DISP2400B0
 DEFINES += -DSYSTEM_hive_isp_css_2400_system -DISP2400
+endif
+ifeq ($(CONFIG_VIDEO_ATOMISP_ISP2401),y)
+# Anniedale (Merrifield+ / Moorefield), Cherrytrail
+DEFINES += -DATOMISP_POSTFIX=\"css2401a0_v21\" -DISP2401A0
+DEFINES += -DSYSTEM_hive_isp_css_2400_system -DISP2401 
-DISP2401_NEW_INPUT_SYSTEM
+endif
 
 ccflags-y += $(INCLUDES) $(DEFINES) -fno-common
 
-- 
2.11.0

[PATCH 0/2] staging: atomisp: activate ATOMISP2401 support

[Vincent Hervieux]

Currently atomisp module supports Intel's Baytrail SoC and contains
some compilation switches to support Intel's Cherrytrail SoC instead.
The patchset aims to :
- 1/2: activate ATOMISP2400 or ATOMISP2401 from the menu.
- 2/2: fix compilation errors for ATOMISP2401.
I'm not so confident with patch 2/2, as it is only working around the non 
declared functions by using the 2400 path. As I couln't find any 
declaration/definition for the ISP2401 missing functions...So any help would be 
appreciated.
Also patch 2/2 doesn't correct any cosmetic changes reported by checkpatch.pl 
as explained in TODO step 6.

Vincent Hervieux (2):
  staging: atomisp: add menu entries to choose between ATOMISP_2400 and
ATOMISP_2401.
  staging: atomisp: fix compilation errors in case of ISP2401.

 drivers/staging/media/atomisp/pci/Kconfig  | 23 +
 .../staging/media/atomisp/pci/atomisp2/Makefile| 10 -
 .../media/atomisp/pci/atomisp2/atomisp_cmd.c   |  5 ++---
 .../media/atomisp/pci/atomisp2/atomisp_v4l2.c  |  6 +-
 .../pci/atomisp2/css2400/ia_css_acc_types.h|  1 +
 .../css2400/runtime/debug/src/ia_css_debug.c   |  3 ---
 .../media/atomisp/pci/atomisp2/css2400/sh_css.c| 24 ++
 .../atomisp/pci/atomisp2/css2400/sh_css_params.c   |  8 +---
 8 files changed, 52 insertions(+), 28 deletions(-)

-- 
2.11.0

Re: [PATCH] staging: atomisp: add a driver for ov5648 camera sensor

[Devid Antonio Filoni]

On Mon, Sep 11, 2017 at 05:55:29PM +0300, Sakari Ailus wrote:
> Hi Devid,
> 
> Please see my comments below.
> 
> Andy: please look for "INT5648".

Hi Sakari,
I'm replying below to your comments. I'll work on a v2 patch as soon as we get
more comments.

About "INT5648", I extracted it from the DSDT of my Lenovo Miix 310, take a look
at https://pastebin.com/ExHWYr8g .

> 
> On Sun, Sep 10, 2017 at 02:23:07PM +0200, Devid Antonio Floni wrote:
> > The ov5680 5-megapixel camera sensor from OmniVision supports up to 
> > 2592x1944
> > resolution and MIPI CSI-2 interface. Output format is raw sRGB/Bayer with
> > 10 bits per colour (SGRBG10_1X10).
> > 
> > This patch is a port of ov5680 driver from following

Sorry, there is a typo here, the driver is for ov5648 (not ov5680).

> > 01org/ProductionKernelQuilts patches:
> > - 0004-ov2680-ov5648-Fork-lift-source-from-CTS.patch
> > - 0005-ov2680-ov5648-gminification.patch
> > - 0006-ov5648-Focus-support.patch
> > - 0007-Fix-resolution-issues-on-rear-camera.patch
> > - 0008-ov2680-ov5648-Enabled-the-set_exposure-functions.patch
> > - 0010-IRDA-cameras-mode-list-cleanup-unification.patch
> > - 0012-ov5648-Add-1296x972-binned-mode.patch
> > - 0014-ov5648-Adapt-to-Atomisp2-Gmin-VCM-framework.patch
> > - 0015-dw9714-Gmin-Atomisp-specific-VCM-driver.patch
> > - 0017-ov5648-Fix-deadlock-on-I2C-error.patch
> > - 0018-gc2155-Fix-deadlock-on-error.patch
> > - 0019-ov5648-Add-1280x960-binned-mode.patch
> > - 0020-ov5648-Make-1280x960-as-default-video-resolution.patch
> > - 0021-MALATA-Fix-testCameraToSurfaceTextureMetadata-CTS.patch
> > - 0023-OV5648-Added-5MP-video-resolution.patch
> > 
> > New changes introduced during the port:
> > - Rename entity types to entity functions
> > - Replace v4l2_subdev_fh by v4l2_subdev_pad_config
> > - Make use of media_bus_format enum
> > - Rename media_entity_init function to media_entity_pads_init
> > - Replace try_mbus_fmt by set_fmt
> > - Replace s_mbus_fmt by set_fmt
> > - Replace g_mbus_fmt by get_fmt
> > - Use s_ctrl/g_volatile_ctrl instead of ctrl core ops
> > - Update gmin platform API path
> > - Update and constify acpi_device_id
> > - Fix some checkpatch errors and warnings
> > - Remove FSF's mailing address from the sample GPL notice
> > 
> > I was not able to properly test this patch on my Lenovo Miix 310 due to 
> > other
> > issues with atomisp, the output is the same as ov2680 driver which is very 
> > similar.
> 
> Has this been somehow tested?

Nope. As far as I know my Lenovo Miix 310 and NextBook Flexx 10.1 use this 
camera sensor
however the driver doesn't work on both systems due to other issues in atomisp 
driver itself.
As I think this driver is identical to ov2680 I decided to send this patch, I 
also have a
patch for hm2056 camera sensor however I'm still not sending it as I'm not 
properly sure
about it.
Please note: my Lenovo Miix 310 has an ov2680 camera, this is how I know that 
ov2680 doesn't
work too (same errors). Let me know if this patch cannot be committed until 
atomisp is fixed.
Please take a look at https://bugzilla.kernel.org/show_bug.cgi?id=195877 for 
more infos.

> 
> > 
> > Signed-off-by: Devid Antonio Floni 
> > ---
> >  drivers/staging/media/atomisp/i2c/Kconfig  |   11 +
> >  drivers/staging/media/atomisp/i2c/Makefile |1 +
> >  drivers/staging/media/atomisp/i2c/ov5648.c | 1867 
> > 
> >  drivers/staging/media/atomisp/i2c/ov5648.h |  835 +
> >  4 files changed, 2714 insertions(+)
> >  create mode 100644 drivers/staging/media/atomisp/i2c/ov5648.c
> >  create mode 100644 drivers/staging/media/atomisp/i2c/ov5648.h
> > 
> > diff --git a/drivers/staging/media/atomisp/i2c/Kconfig 
> > b/drivers/staging/media/atomisp/i2c/Kconfig
> > index b80d29d..8ed2cf4 100644
> > --- a/drivers/staging/media/atomisp/i2c/Kconfig
> > +++ b/drivers/staging/media/atomisp/i2c/Kconfig
> > @@ -89,6 +89,17 @@ config VIDEO_OV2680
> >  
> >   It currently only works with the atomisp driver.
> >  
> > +config VIDEO_OV5648
> 
> It'd be good to have ATOMISP in the option as well (the others don't have
> it, I think I'll submit a patch) so that these won't collide with the real
> V4L2 subdev drivers. E.g. VIDEO_ATOMISP_OV5648.

Ok, this makes sense to me too.

> 
> > +   tristate "Omnivision OV5648 sensor support"
> > +   depends on I2C && VIDEO_V4L2
> > +   ---help---
> > + This is a Video4Linux2 sensor-level driver for the Omnivision
> > + OV5648 raw camera.
> > +
> > + ov5648 is a 5M raw sensor.
> > +
> > + It currently only works with the atomisp driver.
> > +
> 
> While it's nice to see a new sensor driver, it'd be even better if the
> atomisp driver was modified to work with V4L2 sub-device sensor drivers
> e.g. under drivers/media/i2c.
> 
> I'm not saying no to adding this specific driver as such though, this is
> staging... I wonder what others think.

The same can be done on other atomisp drivers as far as I 

[PATCH V2] media: v4l2-pci-skeleton: Fix error handling path in 'skeleton_probe()'

[Christophe JAILLET]

If this memory allocation fails, we must release some resources, as
already done in the code below and above.

Signed-off-by: Christophe JAILLET 
---
v2: linux-media@vger.kernel.org added in cc
---
 samples/v4l/v4l2-pci-skeleton.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/samples/v4l/v4l2-pci-skeleton.c b/samples/v4l/v4l2-pci-skeleton.c
index 483e9bca9444..f520e3aef9c6 100644
--- a/samples/v4l/v4l2-pci-skeleton.c
+++ b/samples/v4l/v4l2-pci-skeleton.c
@@ -772,8 +772,10 @@ static int skeleton_probe(struct pci_dev *pdev, const 
struct pci_device_id *ent)
 
/* Allocate a new instance */
skel = devm_kzalloc(>dev, sizeof(struct skeleton), GFP_KERNEL);
-   if (!skel)
-   return -ENOMEM;
+   if (!skel) {
+   ret = -ENOMEM;
+   goto disable_pci;
+   }
 
/* Allocate the interrupt */
ret = devm_request_irq(>dev, pdev->irq,
-- 
2.11.0

Re: [PATCH] Staging: atomisp: fix alloc_cast.cocci warnings

[Sakari Ailus]

Hi Branislav,

On Thu, Sep 07, 2017 at 06:26:42PM +0200, Branislav Radocaj wrote:
> Remove casting the values returned by memory allocation functions
> like kmalloc, kzalloc, kmem_cache_alloc, kmem_cache_zalloc etc.
> 
> Semantic patch information:
> This makes an effort to find cases of casting of values returned by
> kmalloc, kzalloc, kcalloc, kmem_cache_alloc, kmem_cache_zalloc,
> kmem_cache_alloc_node, kmalloc_node and kzalloc_node and removes
> the casting as it is not required. The result in the patch case may
> need some reformatting.
> 
> Generated by: scripts/coccinelle/api/alloc/alloc_cast.cocci
> 
> Signed-off-by: Branislav Radocaj 
> ---
>  drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c 
> b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> index eecd8cf71951..56765d6a0498 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
> @@ -133,7 +133,7 @@ sh_css_load_blob_info(const char *fw, const struct 
> ia_css_fw_info *bi, struct ia
>   char *namebuffer;
>   int namelength = (int)strlen(name);
>  
> - namebuffer = (char *) kmalloc(namelength + 1, GFP_KERNEL);
> + namebuffer = kmalloc(namelength + 1, GFP_KERNEL);

This chunk no longer applies, I'm applying the one that does. The kmalloc
has been replaced by kstrdup.

>   if (namebuffer == NULL)
>   return IA_CSS_ERR_CANNOT_ALLOCATE_MEMORY;
>  
> @@ -149,7 +149,7 @@ sh_css_load_blob_info(const char *fw, const struct 
> ia_css_fw_info *bi, struct ia
>   size_t configstruct_size = sizeof(struct 
> ia_css_config_memory_offsets);
>   size_t statestruct_size = sizeof(struct 
> ia_css_state_memory_offsets);
>  
> - char *parambuf = (char *)kmalloc(paramstruct_size + 
> configstruct_size + statestruct_size,
> + char *parambuf = kmalloc(paramstruct_size + configstruct_size + 
> statestruct_size,
>   GFP_KERNEL);
>   if (parambuf == NULL)
>   return IA_CSS_ERR_CANNOT_ALLOCATE_MEMORY;

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH] staging: atomisp: add a driver for ov5648 camera sensor

[Sakari Ailus]

Hi Devid,

Please see my comments below.

Andy: please look for "INT5648".

On Sun, Sep 10, 2017 at 02:23:07PM +0200, Devid Antonio Floni wrote:
> The ov5680 5-megapixel camera sensor from OmniVision supports up to 2592x1944
> resolution and MIPI CSI-2 interface. Output format is raw sRGB/Bayer with
> 10 bits per colour (SGRBG10_1X10).
> 
> This patch is a port of ov5680 driver from following
> 01org/ProductionKernelQuilts patches:
> - 0004-ov2680-ov5648-Fork-lift-source-from-CTS.patch
> - 0005-ov2680-ov5648-gminification.patch
> - 0006-ov5648-Focus-support.patch
> - 0007-Fix-resolution-issues-on-rear-camera.patch
> - 0008-ov2680-ov5648-Enabled-the-set_exposure-functions.patch
> - 0010-IRDA-cameras-mode-list-cleanup-unification.patch
> - 0012-ov5648-Add-1296x972-binned-mode.patch
> - 0014-ov5648-Adapt-to-Atomisp2-Gmin-VCM-framework.patch
> - 0015-dw9714-Gmin-Atomisp-specific-VCM-driver.patch
> - 0017-ov5648-Fix-deadlock-on-I2C-error.patch
> - 0018-gc2155-Fix-deadlock-on-error.patch
> - 0019-ov5648-Add-1280x960-binned-mode.patch
> - 0020-ov5648-Make-1280x960-as-default-video-resolution.patch
> - 0021-MALATA-Fix-testCameraToSurfaceTextureMetadata-CTS.patch
> - 0023-OV5648-Added-5MP-video-resolution.patch
> 
> New changes introduced during the port:
> - Rename entity types to entity functions
> - Replace v4l2_subdev_fh by v4l2_subdev_pad_config
> - Make use of media_bus_format enum
> - Rename media_entity_init function to media_entity_pads_init
> - Replace try_mbus_fmt by set_fmt
> - Replace s_mbus_fmt by set_fmt
> - Replace g_mbus_fmt by get_fmt
> - Use s_ctrl/g_volatile_ctrl instead of ctrl core ops
> - Update gmin platform API path
> - Update and constify acpi_device_id
> - Fix some checkpatch errors and warnings
> - Remove FSF's mailing address from the sample GPL notice
> 
> I was not able to properly test this patch on my Lenovo Miix 310 due to other
> issues with atomisp, the output is the same as ov2680 driver which is very 
> similar.

Has this been somehow tested?

> 
> Signed-off-by: Devid Antonio Floni 
> ---
>  drivers/staging/media/atomisp/i2c/Kconfig  |   11 +
>  drivers/staging/media/atomisp/i2c/Makefile |1 +
>  drivers/staging/media/atomisp/i2c/ov5648.c | 1867 
> 
>  drivers/staging/media/atomisp/i2c/ov5648.h |  835 +
>  4 files changed, 2714 insertions(+)
>  create mode 100644 drivers/staging/media/atomisp/i2c/ov5648.c
>  create mode 100644 drivers/staging/media/atomisp/i2c/ov5648.h
> 
> diff --git a/drivers/staging/media/atomisp/i2c/Kconfig 
> b/drivers/staging/media/atomisp/i2c/Kconfig
> index b80d29d..8ed2cf4 100644
> --- a/drivers/staging/media/atomisp/i2c/Kconfig
> +++ b/drivers/staging/media/atomisp/i2c/Kconfig
> @@ -89,6 +89,17 @@ config VIDEO_OV2680
>  
>   It currently only works with the atomisp driver.
>  
> +config VIDEO_OV5648

It'd be good to have ATOMISP in the option as well (the others don't have
it, I think I'll submit a patch) so that these won't collide with the real
V4L2 subdev drivers. E.g. VIDEO_ATOMISP_OV5648.

> +   tristate "Omnivision OV5648 sensor support"
> +   depends on I2C && VIDEO_V4L2
> +   ---help---
> + This is a Video4Linux2 sensor-level driver for the Omnivision
> + OV5648 raw camera.
> +
> + ov5648 is a 5M raw sensor.
> +
> + It currently only works with the atomisp driver.
> +

While it's nice to see a new sensor driver, it'd be even better if the
atomisp driver was modified to work with V4L2 sub-device sensor drivers
e.g. under drivers/media/i2c.

I'm not saying no to adding this specific driver as such though, this is
staging... I wonder what others think.

>  #
>  # Kconfig for flash drivers
>  #
> diff --git a/drivers/staging/media/atomisp/i2c/Makefile 
> b/drivers/staging/media/atomisp/i2c/Makefile
> index be13fab..26195d7 100644
> --- a/drivers/staging/media/atomisp/i2c/Makefile
> +++ b/drivers/staging/media/atomisp/i2c/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_VIDEO_MT9M114)+= mt9m114.o
>  obj-$(CONFIG_VIDEO_GC2235) += gc2235.o
>  obj-$(CONFIG_VIDEO_OV2722) += ov2722.o
>  obj-$(CONFIG_VIDEO_OV2680) += ov2680.o
> +obj-$(CONFIG_VIDEO_OV5648) += ov5648.o
>  obj-$(CONFIG_VIDEO_GC0310) += gc0310.o
>  
>  obj-$(CONFIG_VIDEO_MSRLIST_HELPER) += libmsrlisthelper.o
> diff --git a/drivers/staging/media/atomisp/i2c/ov5648.c 
> b/drivers/staging/media/atomisp/i2c/ov5648.c
> new file mode 100644
> index 000..4815a19
> --- /dev/null
> +++ b/drivers/staging/media/atomisp/i2c/ov5648.c
> @@ -0,0 +1,1867 @@
> +/*
> + * Support for OmniVision OV5648 5M camera sensor.
> + * Based on OmniVision OV2722 driver.
> + *
> + * Copyright (c) 2013 Intel Corporation. All Rights Reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the 

IR driver support for tango platforms

[Mason]

Hello Sean,

After a long hiatus, I can now work again on the IR driver support
for tango platforms. I'm still using this driver:

https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c

There are two nits I'd like to discuss.

A) When I hold a key on the RC, ir-keytable reports scancode = 0x00
instead of the scancode for the repeated key.

# ir-keytable -t -v
[   70.561432] show_protocols: allowed - 0x4204, enabled - 0x0
Found device /sys/class/rc/rc0/
Input sysfs node is /sys/class/rc/rc0/input0/
Event sysfs node is /sys/class/rc/rc0/input0/event0/
Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
/sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
/sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
/sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
Parsing uevent /sys/class/rc/rc0/uevent
/sys/class/rc/rc0/uevent uevent NAME=rc-empty
input device is /dev/input/event0
/sys/class/rc/rc0/protocols protocol rc-5 (disabled)
/sys/class/rc/rc0/protocols protocol nec (disabled)
/sys/class/rc/rc0/protocols protocol rc-6 (disabled)
Opening /dev/input/event0
Input Protocol version: 0x00010001
Testing events. Please, press CTRL-C to abort.
[  227.977324] rc_keydown: keycode=0
227.980533: event type EV_MSC(0x04): scancode = 0x4cb41
227.980533: event type EV_SYN(0x00).
228.031069: event type EV_MSC(0x04): scancode = 0x00
228.031069: event type EV_SYN(0x00).
228.138834: event type EV_MSC(0x04): scancode = 0x00
228.138834: event type EV_SYN(0x00).
228.246603: event type EV_MSC(0x04): scancode = 0x00
228.246603: event type EV_SYN(0x00).
228.354373: event type EV_MSC(0x04): scancode = 0x00
228.354373: event type EV_SYN(0x00).
228.462143: event type EV_MSC(0x04): scancode = 0x00
228.462143: event type EV_SYN(0x00).
228.569913: event type EV_MSC(0x04): scancode = 0x00
228.569913: event type EV_SYN(0x00).

This behavior is caused by ir_do_keydown() not recording the keypress
when keycode == KEY_RESERVED

If I apply the following patch, then the repeated scancode works
as I would expect.

--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -687,6 +687,10 @@ void rc_keydown(struct rc_dev *dev, enum rc_type protocol, 
u32 scancode, u8 togg
unsigned long flags;
u32 keycode = rc_g_keycode_from_table(dev, scancode);
 
+   printk("%s: keycode=%x\n", __func__, keycode);

+   if (keycode == KEY_RESERVED)
+   keycode = KEY_UNKNOWN;
+
spin_lock_irqsave(>keylock, flags);
ir_do_keydown(dev, protocol, scancode, keycode, toggle);
 



# ir-keytable -t -v
[   68.192161] show_protocols: allowed - 0x4204, enabled - 0x0
Found device /sys/class/rc/rc0/
Input sysfs node is /sys/class/rc/rc0/input0/
Event sysfs node is /sys/class/rc/rc0/input0/event0/
Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
/sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
/sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
/sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
Parsing uevent /sys/class/rc/rc0/uevent
/sys/class/rc/rc0/uevent uevent NAME=rc-empty
input device is /dev/input/event0
/sys/class/rc/rc0/protocols protocol rc-5 (disabled)
/sys/class/rc/rc0/protocols protocol nec (disabled)
/sys/class/rc/rc0/protocols protocol rc-6 (disabled)
Opening /dev/input/event0
Input Protocol version: 0x00010001
Testing events. Please, press CTRL-C to abort.
[   92.739308] rc_keydown: keycode=0
[   92.742650] tango-ir: key down event, key 0x00f0, protocol 0x0009, scancode 
0x0004cb41
92.749621: event type EV_MSC(0x04): scancode = 0x4cb41
92.749621: event type EV_SYN(0x00).
92.792201: event type EV_MSC(0x04): scancode = 0x4cb41
92.792201: event type EV_SYN(0x00).
92.899966: event type EV_MSC(0x04): scancode = 0x4cb41
92.899966: event type EV_SYN(0x00).
93.007734: event type EV_MSC(0x04): scancode = 0x4cb41
93.007734: event type EV_SYN(0x00).
93.115501: event type EV_MSC(0x04): scancode = 0x4cb41
93.115501: event type EV_SYN(0x00).
93.223269: event type EV_MSC(0x04): scancode = 0x4cb41
93.223269: event type EV_SYN(0x00).
93.331039: event type EV_MSC(0x04): scancode = 0x4cb41
93.331039: event type EV_SYN(0x00).
[   93.600995] keyup key 0x00f0


I'm confused. Does this mean a keymap is mandatory?
I thought it was possible to handle the "scancode to keycode"
stepin user-space?


B) Currently, the driver doesn't seem to allow selective protocol
enabling/disabling. It just silently enables all protocols at init.

It would seem useful to add support for that, so that the HW
doesn't fire spurious RC5 interrupts for NEC events.

What do you think?

Regards.


Archives of previous threads:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg114854.html
https://www.mail-archive.com/linux-media@vger.kernel.org/msg115316.html

Re: [PATCH v10 19/24] v4l: fwnode: Add convenience function for parsing common external refs

[Sakari Ailus]

On Mon, Sep 11, 2017 at 01:17:46PM +0200, Pavel Machek wrote:
> On Mon 2017-09-11 11:00:03, Sakari Ailus wrote:
> > Add v4l2_fwnode_parse_reference_sensor_common for parsing common
> > sensor properties that refer to adjacent devices such as flash or lens
> > driver chips.
> > 
> > As this is an association only, there's little a regular driver needs to
> > know about these devices as such.
> > 
> > Signed-off-by: Sakari Ailus 
> > Acked-by: Hans Verkuil 
> > ---
> >  drivers/media/v4l2-core/v4l2-fwnode.c | 35 
> > +++
> >  include/media/v4l2-fwnode.h   | 13 +
> >  2 files changed, 48 insertions(+)
> > 
> >  
> > +/**
> > + * v4l2_fwnode_reference_parse_sensor_common - parse common references on
> > + *sensors for async sub-devices
> > + * @dev: the device node the properties of which are parsed for references
> > + * @notifier: the async notifier where the async subdevs will be added
> > + *
> > + * Return: 0 on success
> > + *-ENOMEM if memory allocation failed
> > + *-EINVAL if property parsing failed
> > + */
> 
> Returns: would sound more correct to me, but it seems kernel is split
> on that.

I think in V4L2 there are roughly as many of each instances. I'll keep it
as it is.

> 
> Acked-by: Pavel Machek 

Thanks!

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v10 18/24] v4l: fwnode: Add a helper function to obtain device / interger references

[Sakari Ailus]

On Mon, Sep 11, 2017 at 03:34:16PM +0200, Hans Verkuil wrote:
> > +   u32 val;
> > +
> > +   fwnode_for_each_child_node(fwnode, child) {
> > +   if (fwnode_property_read_u32(child, *props, 
> > ))
> > +   continue;
> > +
> > +   if (val == *args)
> > +   break;
> 
>  I'm lost. This really needs comments and perhaps even an DT or ACPI 
>  example
>  so you can see what exactly it is we're doing here.
> >>>
> >>> I'll add comments to the code. A good example will be ACPI documentation
> >>> for LEDs, see 17th patch in v9. That will go through the linux-pm tree so
> >>> it won't be available in the same tree for a while.
> >>
> >> Ideally an ACPI and an equivalent DT example would be nice to have, but I 
> >> might
> >> be asking too much. I'm not that familiar with ACPI, so for me a DT example
> >> is easier.
> > 
> > This won't be useful on DT although you could technically use it. In DT you
> > can directly refer to any node but on ACPI you can just refer to devices,
> > hence this.
> 
> So this function will effectively only be used with acpi? That should be
> documented. I think that explains some of my confusion since I was trying
> to map this code to a device tree, without much success.

I'll add to the documentation of the function:

 * While it is technically possible to use this function on DT, it is only
 * meaningful on ACPI. On Device tree you can refer to any node in the tree but
 * on ACPI the references are limited to devices.

> 
> > Would you be happy with the leds.txt example? I think it's a good example
> > as it's directly related to this.
> 
> Yes, that will work.

I'll add a separate patch that I'll post later on. The ACPI documentation
should get merged first.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH] build: Added missing functions nsecs_to_jiffies(64)

[Hans Verkuil]

On 09/11/2017 12:23 AM, Jasmin J. wrote:
> From: Jasmin Jessich 
> 
> Several modules expect the functions nsecs_to_jiffies64 and
> nsecs_to_jiffies to be available when they get loaded. For Kernels prior
> to 3.16, this symbol is not exported in time.c .
> Copied the functions to compat.h, so that they get already resolved during
> compilation. Define also a macro with a name conversion, because the
> mentioned functions are defined as extern in include/linux/jiffies.h,
> which gives an error when the are re-defined as static.
> 
> Signed-off-by: Jasmin Jessich 
> ---
>  v4l/compat.h | 37 +
>  1 file changed, 37 insertions(+)
> 
> diff --git a/v4l/compat.h b/v4l/compat.h
> index 7a49551..3dedf26 100644
> --- a/v4l/compat.h
> +++ b/v4l/compat.h
> @@ -2118,4 +2118,41 @@ static inline int pm_runtime_get_if_in_use(struct 
> device *dev)
>   .subvendor = (subvend), .subdevice = (subdev)
>  #endif
>  
> +
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 16, 0)
> +/*
> + * copied from kernel/time/time.c
> + */
> +static inline u64 nsecs_to_jiffies64_static(u64 n)
> +{
> +#if (NSEC_PER_SEC % HZ) == 0
> +/* Common case, HZ = 100, 128, 200, 250, 256, 500, 512, 1000 etc. */
> +return div_u64(n, NSEC_PER_SEC / HZ);
> +#elif (HZ % 512) == 0
> +/* overflow after 292 years if HZ = 1024 */
> +return div_u64(n * HZ / 512, NSEC_PER_SEC / 512);
> +#else
> +/*
> + * Generic case - optimized for cases where HZ is a multiple of 3.
> + * overflow after 64.99 years, exact for HZ = 60, 72, 90, 120 etc.
> + */
> +return div_u64(n * 9, (9ull * NSEC_PER_SEC + HZ / 2) / HZ);
> +#endif
> +}
> +
> +static inline unsigned long nsecs_to_jiffies_static(u64 n)
> +{
> +return (unsigned long)nsecs_to_jiffies64_static(n);
> +}
> +
> +/*
> + * linux/jiffies.h defines nsecs_to_jiffies64 and nsecs_to_jiffies
> + * as externals. To get rid of the compiler error, we redefine the
> + * functions to the static variant just defined above.
> + */
> +#define nsecs_to_jiffies64(_n) nsecs_to_jiffies64_static(_n)
> +#define nsecs_to_jiffies(_n) nsecs_to_jiffies_static(_n)

For this to work reliably I think you should include jiffies.h before these
defines. If the defines come before the header is included I would expect
that the extern functions then become extern nsecs_to_jiffies64_static and
you will have the same problem again.

It is probably included already via another header, but it doesn't hurt to
be safe.

Looks good otherwise.

Regards,

Hans

> +
> +#endif
> +
>  #endif /*  _COMPAT_H */
> 

[GIT PULL FOR v4.15] Various fixes

[Hans Verkuil]

Hi Mauro,

A bunch of small things all over the place.

Please note the "media: fix media Kconfig help syntax issues" patch: double
check that drivers/media/pci/netup_unidvb/Kconfig is OK.

Regards,

Hans

The following changes since commit 1efdf1776e2253b77413c997bed862410e4b6aaf:

  media: leds: as3645a: add V4L2_FLASH_LED_CLASS dependency (2017-09-05 
16:32:45 -0400)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.15b

for you to fetch changes up to 4730ba1fe2ef5074ce9465bfb9da99c8bc8cd832:

  cec.h: initialize *parent and *port in cec_phys_addr_validate (2017-09-11 
15:36:14 +0200)


Geert Uytterhoeven (1):
  media: platform: VIDEO_QCOM_CAMSS should depend on HAS_DMA

Hans Verkuil (3):
  cobalt: do not register subdev nodes
  media: fix media Kconfig help syntax issues
  cec.h: initialize *parent and *port in cec_phys_addr_validate

Markus Elfring (3):
  DaVinci-VPBE-Display: Delete an error message for a failed memory 
allocation in init_vpbe_layer()
  DaVinci-VPBE-Display: Improve a size determination in two functions
  DaVinci-VPBE-Display: Adjust 12 checks for null pointers

Ricardo Ribalda Delgado (1):
  v4l-ioctl: Fix typo on v4l_print_frmsizeenum

 drivers/media/dvb-frontends/Kconfig   |  6 +++---
 drivers/media/pci/b2c2/Kconfig|  4 ++--
 drivers/media/pci/cobalt/cobalt-driver.c  |  3 ---
 drivers/media/pci/netup_unidvb/Kconfig| 12 ++--
 drivers/media/platform/Kconfig|  2 +-
 drivers/media/platform/davinci/vpbe_display.c | 37 
+++--
 drivers/media/platform/exynos4-is/Kconfig |  2 +-
 drivers/media/radio/wl128x/Kconfig| 10 +-
 drivers/media/usb/b2c2/Kconfig|  6 +++---
 drivers/media/usb/gspca/Kconfig   | 16 
 drivers/media/usb/pvrusb2/Kconfig |  1 -
 drivers/media/v4l2-core/v4l2-ioctl.c  |  9 ++---
 include/media/cec.h   |  4 
 13 files changed, 54 insertions(+), 58 deletions(-)

Re: [PATCH v3 01/15] [media] v4l: Document explicit synchronization behaviour

[Hans Verkuil]

On 09/11/2017 03:34 PM, Gustavo Padovan wrote:
> 2017-09-11 Hans Verkuil :
> 
>> On 09/11/2017 03:18 PM, Gustavo Padovan wrote:
>>> 2017-09-11 Hans Verkuil :
>>>
 On 09/11/2017 12:50 PM, Hans Verkuil wrote:
> On 09/07/2017 08:42 PM, Gustavo Padovan wrote:
>> From: Gustavo Padovan 
>>
>> Add section to VIDIOC_QBUF about it
>>
>> v2:
>>  - mention that fences are files (Hans)
>>  - rework for the new API
>>
>> Signed-off-by: Gustavo Padovan 
>> ---
>>  Documentation/media/uapi/v4l/vidioc-qbuf.rst | 31 
>> 
>>  1 file changed, 31 insertions(+)
>>
>> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
>> b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>> index 1f3612637200..fae0b1431672 100644
>> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>> @@ -117,6 +117,37 @@ immediately with an ``EAGAIN`` error code when no 
>> buffer is available.
>>  The struct :c:type:`v4l2_buffer` structure is specified in
>>  :ref:`buffer`.
>>  
>> +Explicit Synchronization
>> +
>> +
>> +Explicit Synchronization allows us to control the synchronization of
>> +shared buffers from userspace by passing fences to the kernel and/or
>> +receiving them from it. Fences passed to the kernel are named in-fences 
>> and
>> +the kernel should wait them to signal before using the buffer, i.e., 
>> queueing
>
> wait them -> wait on them
>
> (do you wait 'on' a fence or 'for' a fence? I think it's 'on' but I'm not 
> 100% sure)
>
>> +it to the driver. On the other side, the kernel can create out-fences 
>> for the
>> +buffers it queues to the drivers, out-fences signal when the driver is
>
> Start a new sentence here: ...drivers. Out-fences...
>
>> +finished with buffer, that is the buffer is ready. The fence are 
>> represented
>
> s/that is/i.e/
>
> s/The fence/The fences/
>
>> +by file and passed as file descriptor to userspace.
>
> s/by file/as a file/
> s/as file/as a file/
>
>> +
>> +The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` 
>> ioctl
>> +using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer
>> +flags and the `fence_fd` field. If an in-fence needs to be passed to 
>> the kernel,
>> +`fence_fd` should be set to the fence file descriptor number and the
>> +``V4L2_BUF_FLAG_IN_FENCE`` should be set as well. Failure to set both 
>> will
>
> s/Failure to set both/Setting one but not the other/
>
>> +cause ``VIDIOC_QBUF`` to return with error.
>> +
>> +To get a out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag 
>> should
>> +be set to notify it that the next queued buffer should have a fence 
>> attached to
>> +it. That means the out-fence may not be associated with the buffer in 
>> the
>> +current ``VIDIOC_QBUF`` ioctl call because the ordering in which 
>> videobuf2 core
>> +queues the buffers to the drivers can't be guaranteed. To become aware 
>> of the
>> +of the next queued buffer and the out-fence attached to it the
>> +``V4L2_EVENT_BUF_QUEUED`` event should be used. It will trigger an event
>> +for every buffer queued to the V4L2 driver.
>
> This makes no sense.
>
> Setting this flag means IMHO that when *this* buffer is queued up to the 
> driver,
> then it should send the BUF_QUEUED event with an out fence.
>
> I.e. it signals that userspace wants to have the out-fence. The 
> requirement w.r.t.
> ordering is that the BUF_QUEUED events have to be in order, but that is 
> something
> that the driver can ensure in the case it is doing internal re-ordering.
>
> This requirement is something that needs to be documented here, BTW.
>
> Anyway, the flag shouldn't refer to some 'next buffer', since that's very 
> confusing.

 Just ignore this comment. I assume v4 will implement it like this.
>>>
>>> What approach do you mean by "like this". I'm confused now. :)
>>>
>>> In fact, I was in doubt between these two different approaches here.
>>> Should the flag mean *this* or the *next* buffer? The buffers can still
>>> be reordered at the videobuf2 level, because they might be waiting on
>>> in-fences and the fences may signal out of order. Then I went for the
>>> *next* buffer approach because we don't know that buffer for sure.
>>> But now thinking on this again we shouldn't have problems with the 
>>> *this* buffer approach also.
>>
>> It should mean *this* buffer. It's really weird to set this flag for one
>> buffer, only for it to mean 'next' buffer.
>>
>> Keep it simple: the flag just 

Re: [PATCH v10 18/24] v4l: fwnode: Add a helper function to obtain device / interger references

[Hans Verkuil]

On 09/11/2017 03:27 PM, Sakari Ailus wrote:
> Hi Hans,
> 
> On Mon, Sep 11, 2017 at 02:38:23PM +0200, Hans Verkuil wrote:
>> On 09/11/2017 02:28 PM, Sakari Ailus wrote:
>>> Hi Hans,
>>>
>>> Thanks for the review.
>>>
>>> On Mon, Sep 11, 2017 at 11:38:58AM +0200, Hans Verkuil wrote:
 Typo in subject: interger -> integer

 On 09/11/2017 10:00 AM, Sakari Ailus wrote:
> v4l2_fwnode_reference_parse_int_prop() will find an fwnode such that under
> the device's own fwnode, 

 Sorry, you lost me here. Which device are we talking about?
>>>
>>> The fwnode related a struct device, in other words what dev_fwnode(dev)
>>> gives you. This is either struct device.fwnode or struct
>>> device.of_node.fwnode, depending on which firmware interface was used to
>>> create the device.
>>>
>>> I'll add a note of this.
>>>

> it will follow child fwnodes with the given
> property -- value pair and return the resulting fwnode.

 property-value pair (easier readable that way).

 You only describe v4l2_fwnode_reference_parse_int_prop(), not
 v4l2_fwnode_reference_parse_int_props().
>>>
>>> Yes, I think I changed the naming but forgot to update the commit. I'll do
>>> that now.
>>>

>
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/v4l2-core/v4l2-fwnode.c | 93 
> +++
>  1 file changed, 93 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> b/drivers/media/v4l2-core/v4l2-fwnode.c
> index 4821c4989119..56eee5bbd3b5 100644
> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> @@ -496,6 +496,99 @@ static int v4l2_fwnode_reference_parse(
>   return ret;
>  }
>  
> +static struct fwnode_handle *v4l2_fwnode_reference_get_int_prop(
> + struct fwnode_handle *fwnode, const char *prop, unsigned int index,
> + const char **props, unsigned int nprops)

 Need comments describing what this does.
>>>
>>> Yes. I'll also rename it (get -> read) for consistency with the async
>>> changes.
>>
>> Which async changes? Since the fwnode_handle that's returned is refcounted
>> I wonder if 'get' isn't the right name in this case.
> 
> Right. True. I'll leave that as-is then.
> 
>>
>>>

> +{
> + struct fwnode_reference_args fwnode_args;
> + unsigned int *args = fwnode_args.args;
> + struct fwnode_handle *child;
> + int ret;
> +
> + ret = fwnode_property_get_reference_args(fwnode, prop, NULL, nprops,
> +  index, _args);
> + if (ret)
> + return ERR_PTR(ret == -EINVAL ? -ENOENT : ret);

 Why map EINVAL to ENOENT? Needs a comment, either here or in the function 
 description.
>>>
>>> fwnode_property_get_reference_args() returns currently a little bit
>>> different error codes in ACPI / DT. This is worth documenting there and
>>> fixing as well.
>>>

> +
> + for (fwnode = fwnode_args.fwnode;
> +  nprops; nprops--, fwnode = child, props++, args++) {

 I think you cram too much in this for-loop: fwnode, nprops, fwnode, props, 
 args...
 It's hard to parse.
>>>
>>> Hmm. I'm not sure if that really helps; the function is just handling each
>>> entry in the array and related array pointers are changed accordingly. The
>>> fwnode = child assignment is there to move to the child node. I.e. what you
>>> need for handling the loop itself.
>>>
>>> I can change this though if you think it really makes a difference for
>>> better.
>>
>> I think so, yes. I noticed you like complex for-loops :-)
> 
> I don't really see a difference. The loop increment will just move at the
> end of the block inside the loop.
> 
>>
>>>

 I would make this a 'while (nprops)' and write out all the other 
 assignments,
 increments and decrements.

> + u32 val;
> +
> + fwnode_for_each_child_node(fwnode, child) {
> + if (fwnode_property_read_u32(child, *props, ))
> + continue;
> +
> + if (val == *args)
> + break;

 I'm lost. This really needs comments and perhaps even an DT or ACPI example
 so you can see what exactly it is we're doing here.
>>>
>>> I'll add comments to the code. A good example will be ACPI documentation
>>> for LEDs, see 17th patch in v9. That will go through the linux-pm tree so
>>> it won't be available in the same tree for a while.
>>
>> Ideally an ACPI and an equivalent DT example would be nice to have, but I 
>> might
>> be asking too much. I'm not that familiar with ACPI, so for me a DT example
>> is easier.
> 
> This won't be useful on DT although you could technically use it. In DT you
> can directly refer to any node but on ACPI you can just refer to devices,
> hence this.

So this function will effectively 

Re: [PATCH v3 01/15] [media] v4l: Document explicit synchronization behaviour

[Gustavo Padovan]

2017-09-11 Hans Verkuil :

> On 09/11/2017 03:18 PM, Gustavo Padovan wrote:
> > 2017-09-11 Hans Verkuil :
> > 
> >> On 09/11/2017 12:50 PM, Hans Verkuil wrote:
> >>> On 09/07/2017 08:42 PM, Gustavo Padovan wrote:
>  From: Gustavo Padovan 
> 
>  Add section to VIDIOC_QBUF about it
> 
>  v2:
>   - mention that fences are files (Hans)
>   - rework for the new API
> 
>  Signed-off-by: Gustavo Padovan 
>  ---
>   Documentation/media/uapi/v4l/vidioc-qbuf.rst | 31 
>  
>   1 file changed, 31 insertions(+)
> 
>  diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
>  b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>  index 1f3612637200..fae0b1431672 100644
>  --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>  +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>  @@ -117,6 +117,37 @@ immediately with an ``EAGAIN`` error code when no 
>  buffer is available.
>   The struct :c:type:`v4l2_buffer` structure is specified in
>   :ref:`buffer`.
>   
>  +Explicit Synchronization
>  +
>  +
>  +Explicit Synchronization allows us to control the synchronization of
>  +shared buffers from userspace by passing fences to the kernel and/or
>  +receiving them from it. Fences passed to the kernel are named in-fences 
>  and
>  +the kernel should wait them to signal before using the buffer, i.e., 
>  queueing
> >>>
> >>> wait them -> wait on them
> >>>
> >>> (do you wait 'on' a fence or 'for' a fence? I think it's 'on' but I'm not 
> >>> 100% sure)
> >>>
>  +it to the driver. On the other side, the kernel can create out-fences 
>  for the
>  +buffers it queues to the drivers, out-fences signal when the driver is
> >>>
> >>> Start a new sentence here: ...drivers. Out-fences...
> >>>
>  +finished with buffer, that is the buffer is ready. The fence are 
>  represented
> >>>
> >>> s/that is/i.e/
> >>>
> >>> s/The fence/The fences/
> >>>
>  +by file and passed as file descriptor to userspace.
> >>>
> >>> s/by file/as a file/
> >>> s/as file/as a file/
> >>>
>  +
>  +The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` 
>  ioctl
>  +using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer
>  +flags and the `fence_fd` field. If an in-fence needs to be passed to 
>  the kernel,
>  +`fence_fd` should be set to the fence file descriptor number and the
>  +``V4L2_BUF_FLAG_IN_FENCE`` should be set as well. Failure to set both 
>  will
> >>>
> >>> s/Failure to set both/Setting one but not the other/
> >>>
>  +cause ``VIDIOC_QBUF`` to return with error.
>  +
>  +To get a out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag 
>  should
>  +be set to notify it that the next queued buffer should have a fence 
>  attached to
>  +it. That means the out-fence may not be associated with the buffer in 
>  the
>  +current ``VIDIOC_QBUF`` ioctl call because the ordering in which 
>  videobuf2 core
>  +queues the buffers to the drivers can't be guaranteed. To become aware 
>  of the
>  +of the next queued buffer and the out-fence attached to it the
>  +``V4L2_EVENT_BUF_QUEUED`` event should be used. It will trigger an event
>  +for every buffer queued to the V4L2 driver.
> >>>
> >>> This makes no sense.
> >>>
> >>> Setting this flag means IMHO that when *this* buffer is queued up to the 
> >>> driver,
> >>> then it should send the BUF_QUEUED event with an out fence.
> >>>
> >>> I.e. it signals that userspace wants to have the out-fence. The 
> >>> requirement w.r.t.
> >>> ordering is that the BUF_QUEUED events have to be in order, but that is 
> >>> something
> >>> that the driver can ensure in the case it is doing internal re-ordering.
> >>>
> >>> This requirement is something that needs to be documented here, BTW.
> >>>
> >>> Anyway, the flag shouldn't refer to some 'next buffer', since that's very 
> >>> confusing.
> >>
> >> Just ignore this comment. I assume v4 will implement it like this.
> > 
> > What approach do you mean by "like this". I'm confused now. :)
> > 
> > In fact, I was in doubt between these two different approaches here.
> > Should the flag mean *this* or the *next* buffer? The buffers can still
> > be reordered at the videobuf2 level, because they might be waiting on
> > in-fences and the fences may signal out of order. Then I went for the
> > *next* buffer approach because we don't know that buffer for sure.
> > But now thinking on this again we shouldn't have problems with the 
> > *this* buffer approach also.
> 
> It should mean *this* buffer. It's really weird to set this flag for one
> buffer, only for it to mean 'next' buffer.
> 
> Keep it simple: the flag just means: send me the output fence fd for this
> buffer 

Re: [PATCH 3/3] [media] DaVinci-VPBE-Display: Adjust 12 checks for null pointers

[Lad, Prabhakar]

On Fri, Sep 8, 2017 at 1:33 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Fri, 8 Sep 2017 14:00:20 +0200
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> The script “checkpatch.pl” pointed information out like the following.
>
> Comparison to NULL could be written …
>
> Thus fix the affected source code places.
>
> Signed-off-by: Markus Elfring 

Acked-by: Lad, Prabhakar 

Cheers,
--Prabhakar Lad

Re: [PATCH v10 18/24] v4l: fwnode: Add a helper function to obtain device / interger references

[Sakari Ailus]

Hi Hans,

On Mon, Sep 11, 2017 at 02:38:23PM +0200, Hans Verkuil wrote:
> On 09/11/2017 02:28 PM, Sakari Ailus wrote:
> > Hi Hans,
> > 
> > Thanks for the review.
> > 
> > On Mon, Sep 11, 2017 at 11:38:58AM +0200, Hans Verkuil wrote:
> >> Typo in subject: interger -> integer
> >>
> >> On 09/11/2017 10:00 AM, Sakari Ailus wrote:
> >>> v4l2_fwnode_reference_parse_int_prop() will find an fwnode such that under
> >>> the device's own fwnode, 
> >>
> >> Sorry, you lost me here. Which device are we talking about?
> > 
> > The fwnode related a struct device, in other words what dev_fwnode(dev)
> > gives you. This is either struct device.fwnode or struct
> > device.of_node.fwnode, depending on which firmware interface was used to
> > create the device.
> > 
> > I'll add a note of this.
> > 
> >>
> >>> it will follow child fwnodes with the given
> >>> property -- value pair and return the resulting fwnode.
> >>
> >> property-value pair (easier readable that way).
> >>
> >> You only describe v4l2_fwnode_reference_parse_int_prop(), not
> >> v4l2_fwnode_reference_parse_int_props().
> > 
> > Yes, I think I changed the naming but forgot to update the commit. I'll do
> > that now.
> > 
> >>
> >>>
> >>> Signed-off-by: Sakari Ailus 
> >>> ---
> >>>  drivers/media/v4l2-core/v4l2-fwnode.c | 93 
> >>> +++
> >>>  1 file changed, 93 insertions(+)
> >>>
> >>> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> >>> b/drivers/media/v4l2-core/v4l2-fwnode.c
> >>> index 4821c4989119..56eee5bbd3b5 100644
> >>> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> >>> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> >>> @@ -496,6 +496,99 @@ static int v4l2_fwnode_reference_parse(
> >>>   return ret;
> >>>  }
> >>>  
> >>> +static struct fwnode_handle *v4l2_fwnode_reference_get_int_prop(
> >>> + struct fwnode_handle *fwnode, const char *prop, unsigned int index,
> >>> + const char **props, unsigned int nprops)
> >>
> >> Need comments describing what this does.
> > 
> > Yes. I'll also rename it (get -> read) for consistency with the async
> > changes.
> 
> Which async changes? Since the fwnode_handle that's returned is refcounted
> I wonder if 'get' isn't the right name in this case.

Right. True. I'll leave that as-is then.

> 
> > 
> >>
> >>> +{
> >>> + struct fwnode_reference_args fwnode_args;
> >>> + unsigned int *args = fwnode_args.args;
> >>> + struct fwnode_handle *child;
> >>> + int ret;
> >>> +
> >>> + ret = fwnode_property_get_reference_args(fwnode, prop, NULL, nprops,
> >>> +  index, _args);
> >>> + if (ret)
> >>> + return ERR_PTR(ret == -EINVAL ? -ENOENT : ret);
> >>
> >> Why map EINVAL to ENOENT? Needs a comment, either here or in the function 
> >> description.
> > 
> > fwnode_property_get_reference_args() returns currently a little bit
> > different error codes in ACPI / DT. This is worth documenting there and
> > fixing as well.
> > 
> >>
> >>> +
> >>> + for (fwnode = fwnode_args.fwnode;
> >>> +  nprops; nprops--, fwnode = child, props++, args++) {
> >>
> >> I think you cram too much in this for-loop: fwnode, nprops, fwnode, props, 
> >> args...
> >> It's hard to parse.
> > 
> > Hmm. I'm not sure if that really helps; the function is just handling each
> > entry in the array and related array pointers are changed accordingly. The
> > fwnode = child assignment is there to move to the child node. I.e. what you
> > need for handling the loop itself.
> > 
> > I can change this though if you think it really makes a difference for
> > better.
> 
> I think so, yes. I noticed you like complex for-loops :-)

I don't really see a difference. The loop increment will just move at the
end of the block inside the loop.

> 
> > 
> >>
> >> I would make this a 'while (nprops)' and write out all the other 
> >> assignments,
> >> increments and decrements.
> >>
> >>> + u32 val;
> >>> +
> >>> + fwnode_for_each_child_node(fwnode, child) {
> >>> + if (fwnode_property_read_u32(child, *props, ))
> >>> + continue;
> >>> +
> >>> + if (val == *args)
> >>> + break;
> >>
> >> I'm lost. This really needs comments and perhaps even an DT or ACPI example
> >> so you can see what exactly it is we're doing here.
> > 
> > I'll add comments to the code. A good example will be ACPI documentation
> > for LEDs, see 17th patch in v9. That will go through the linux-pm tree so
> > it won't be available in the same tree for a while.
> 
> Ideally an ACPI and an equivalent DT example would be nice to have, but I 
> might
> be asking too much. I'm not that familiar with ACPI, so for me a DT example
> is easier.

This won't be useful on DT although you could technically use it. In DT you
can directly refer to any node but on ACPI you can just refer to devices,
hence this.

Would you be happy with the leds.txt example? I think it's a good example
as it's directly related 

Re: [PATCH v3 01/15] [media] v4l: Document explicit synchronization behaviour

[Hans Verkuil]

On 09/11/2017 03:18 PM, Gustavo Padovan wrote:
> 2017-09-11 Hans Verkuil :
> 
>> On 09/11/2017 12:50 PM, Hans Verkuil wrote:
>>> On 09/07/2017 08:42 PM, Gustavo Padovan wrote:
 From: Gustavo Padovan 

 Add section to VIDIOC_QBUF about it

 v2:
- mention that fences are files (Hans)
- rework for the new API

 Signed-off-by: Gustavo Padovan 
 ---
  Documentation/media/uapi/v4l/vidioc-qbuf.rst | 31 
 
  1 file changed, 31 insertions(+)

 diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
 b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
 index 1f3612637200..fae0b1431672 100644
 --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
 +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
 @@ -117,6 +117,37 @@ immediately with an ``EAGAIN`` error code when no 
 buffer is available.
  The struct :c:type:`v4l2_buffer` structure is specified in
  :ref:`buffer`.
  
 +Explicit Synchronization
 +
 +
 +Explicit Synchronization allows us to control the synchronization of
 +shared buffers from userspace by passing fences to the kernel and/or
 +receiving them from it. Fences passed to the kernel are named in-fences 
 and
 +the kernel should wait them to signal before using the buffer, i.e., 
 queueing
>>>
>>> wait them -> wait on them
>>>
>>> (do you wait 'on' a fence or 'for' a fence? I think it's 'on' but I'm not 
>>> 100% sure)
>>>
 +it to the driver. On the other side, the kernel can create out-fences for 
 the
 +buffers it queues to the drivers, out-fences signal when the driver is
>>>
>>> Start a new sentence here: ...drivers. Out-fences...
>>>
 +finished with buffer, that is the buffer is ready. The fence are 
 represented
>>>
>>> s/that is/i.e/
>>>
>>> s/The fence/The fences/
>>>
 +by file and passed as file descriptor to userspace.
>>>
>>> s/by file/as a file/
>>> s/as file/as a file/
>>>
 +
 +The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` ioctl
 +using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer
 +flags and the `fence_fd` field. If an in-fence needs to be passed to the 
 kernel,
 +`fence_fd` should be set to the fence file descriptor number and the
 +``V4L2_BUF_FLAG_IN_FENCE`` should be set as well. Failure to set both will
>>>
>>> s/Failure to set both/Setting one but not the other/
>>>
 +cause ``VIDIOC_QBUF`` to return with error.
 +
 +To get a out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag 
 should
 +be set to notify it that the next queued buffer should have a fence 
 attached to
 +it. That means the out-fence may not be associated with the buffer in the
 +current ``VIDIOC_QBUF`` ioctl call because the ordering in which 
 videobuf2 core
 +queues the buffers to the drivers can't be guaranteed. To become aware of 
 the
 +of the next queued buffer and the out-fence attached to it the
 +``V4L2_EVENT_BUF_QUEUED`` event should be used. It will trigger an event
 +for every buffer queued to the V4L2 driver.
>>>
>>> This makes no sense.
>>>
>>> Setting this flag means IMHO that when *this* buffer is queued up to the 
>>> driver,
>>> then it should send the BUF_QUEUED event with an out fence.
>>>
>>> I.e. it signals that userspace wants to have the out-fence. The requirement 
>>> w.r.t.
>>> ordering is that the BUF_QUEUED events have to be in order, but that is 
>>> something
>>> that the driver can ensure in the case it is doing internal re-ordering.
>>>
>>> This requirement is something that needs to be documented here, BTW.
>>>
>>> Anyway, the flag shouldn't refer to some 'next buffer', since that's very 
>>> confusing.
>>
>> Just ignore this comment. I assume v4 will implement it like this.
> 
> What approach do you mean by "like this". I'm confused now. :)
> 
> In fact, I was in doubt between these two different approaches here.
> Should the flag mean *this* or the *next* buffer? The buffers can still
> be reordered at the videobuf2 level, because they might be waiting on
> in-fences and the fences may signal out of order. Then I went for the
> *next* buffer approach because we don't know that buffer for sure.
> But now thinking on this again we shouldn't have problems with the 
> *this* buffer approach also.

It should mean *this* buffer. It's really weird to set this flag for one
buffer, only for it to mean 'next' buffer.

Keep it simple: the flag just means: send me the output fence fd for this
buffer once you have it. If it is not set, then no BUF_QUEUE event is sent.

Actually, it could mean one of two things: either if it is not set, then no
BUF_QUEUE event is sent, or if it is not set, then the fd in the BUF_QUEUE
event is -1.

I'm leaning towards the first. I can't see any use-case for sending that

Re: [PATCH 2/3] [media] DaVinci-VPBE-Display: Improve a size determination in two functions

[Lad, Prabhakar]

On Fri, Sep 8, 2017 at 1:32 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Fri, 8 Sep 2017 10:50:32 +0200
>
> Replace the specification of data structures by pointer dereferences
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
>
> Signed-off-by: Markus Elfring 

Acked-by: Lad, Prabhakar 

Cheers,
--Prabhakar Lad

Re: [PATCH 1/3] [media] DaVinci-VPBE-Display: Delete an error message for a failed memory allocation in init_vpbe_layer()

[Lad, Prabhakar]

On Fri, Sep 8, 2017 at 1:31 PM, SF Markus Elfring
 wrote:
>
> From: Markus Elfring 
> Date: Thu, 7 Sep 2017 22:37:16 +0200
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring 

Acked-by: Lad, Prabhakar 

Cheers,
--Prabhakar Lad

[PATCH] et8ek8: Add support for flash and lens devices

[Pavel Machek]

Parse async sub-devices by using
v4l2_subdev_fwnode_reference_parse_sensor_common().

These types devices aren't directly related to the sensor, but are
nevertheless handled by the et8ek8 driver due to the relationship of these
component to the main part of the camera module --- the sensor.

Signed-off-by: Pavel Machek 

---

This enables me to do autofocus on n900.

Depends on Sakari's series, so best solution would be to append it there.

Thanks,
Pavel

diff --git a/drivers/media/i2c/et8ek8/et8ek8_driver.c 
b/drivers/media/i2c/et8ek8/et8ek8_driver.c
index c14f0fd..cd1f15f 100644
--- a/drivers/media/i2c/et8ek8/et8ek8_driver.c
+++ b/drivers/media/i2c/et8ek8/et8ek8_driver.c
@@ -34,10 +34,12 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "et8ek8_reg.h"
 
@@ -46,6 +48,7 @@
 #define ET8EK8_MAX_MSG 8
 
 struct et8ek8_sensor {
+   struct v4l2_async_notifier notifier;
struct v4l2_subdev subdev;
struct media_pad pad;
struct v4l2_mbus_framefmt format;
@@ -1446,6 +1449,11 @@ static int et8ek8_probe(struct i2c_client *client,
sensor->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
sensor->subdev.internal_ops = _internal_ops;
 
+   ret = v4l2_fwnode_reference_parse_sensor_common(
+   >dev, >notifier);
+   if (ret < 0 && ret != -ENOENT)
+   goto err_release;
+
sensor->pad.flags = MEDIA_PAD_FL_SOURCE;
ret = media_entity_pads_init(>subdev.entity, 1, >pad);
if (ret < 0) {
@@ -1453,18 +1461,27 @@ static int et8ek8_probe(struct i2c_client *client,
goto err_mutex;
}
 
+   ret = v4l2_async_subdev_notifier_register(>subdev,
+ >notifier);
+   if (ret)
+   goto err_entity;
+
ret = v4l2_async_register_subdev(>subdev);
if (ret < 0)
-   goto err_entity;
+   goto err_async;
 
dev_dbg(dev, "initialized!\n");
 
return 0;
 
+err_async:
+   v4l2_async_notifier_unregister(>notifier);
 err_entity:
media_entity_cleanup(>subdev.entity);
 err_mutex:
mutex_destroy(>power_lock);
+err_release:
+   v4l2_async_notifier_release(>notifier);
return ret;
 }
 
@@ -1480,6 +1497,8 @@ static int __exit et8ek8_remove(struct i2c_client *client)
}
 
v4l2_device_unregister_subdev(>subdev);
+   v4l2_async_notifier_unregister(>notifier);
+   v4l2_async_notifier_release(>notifier);
device_remove_file(>dev, _attr_priv_mem);
v4l2_ctrl_handler_free(>ctrl_handler);
v4l2_async_unregister_subdev(>subdev);

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v3 01/15] [media] v4l: Document explicit synchronization behaviour

[Gustavo Padovan]

2017-09-11 Hans Verkuil :

> On 09/11/2017 12:50 PM, Hans Verkuil wrote:
> > On 09/07/2017 08:42 PM, Gustavo Padovan wrote:
> >> From: Gustavo Padovan 
> >>
> >> Add section to VIDIOC_QBUF about it
> >>
> >> v2:
> >>- mention that fences are files (Hans)
> >>- rework for the new API
> >>
> >> Signed-off-by: Gustavo Padovan 
> >> ---
> >>  Documentation/media/uapi/v4l/vidioc-qbuf.rst | 31 
> >> 
> >>  1 file changed, 31 insertions(+)
> >>
> >> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
> >> b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >> index 1f3612637200..fae0b1431672 100644
> >> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> >> @@ -117,6 +117,37 @@ immediately with an ``EAGAIN`` error code when no 
> >> buffer is available.
> >>  The struct :c:type:`v4l2_buffer` structure is specified in
> >>  :ref:`buffer`.
> >>  
> >> +Explicit Synchronization
> >> +
> >> +
> >> +Explicit Synchronization allows us to control the synchronization of
> >> +shared buffers from userspace by passing fences to the kernel and/or
> >> +receiving them from it. Fences passed to the kernel are named in-fences 
> >> and
> >> +the kernel should wait them to signal before using the buffer, i.e., 
> >> queueing
> > 
> > wait them -> wait on them
> > 
> > (do you wait 'on' a fence or 'for' a fence? I think it's 'on' but I'm not 
> > 100% sure)
> > 
> >> +it to the driver. On the other side, the kernel can create out-fences for 
> >> the
> >> +buffers it queues to the drivers, out-fences signal when the driver is
> > 
> > Start a new sentence here: ...drivers. Out-fences...
> > 
> >> +finished with buffer, that is the buffer is ready. The fence are 
> >> represented
> > 
> > s/that is/i.e/
> > 
> > s/The fence/The fences/
> > 
> >> +by file and passed as file descriptor to userspace.
> > 
> > s/by file/as a file/
> > s/as file/as a file/
> > 
> >> +
> >> +The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` ioctl
> >> +using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer
> >> +flags and the `fence_fd` field. If an in-fence needs to be passed to the 
> >> kernel,
> >> +`fence_fd` should be set to the fence file descriptor number and the
> >> +``V4L2_BUF_FLAG_IN_FENCE`` should be set as well. Failure to set both will
> > 
> > s/Failure to set both/Setting one but not the other/
> > 
> >> +cause ``VIDIOC_QBUF`` to return with error.
> >> +
> >> +To get a out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag 
> >> should
> >> +be set to notify it that the next queued buffer should have a fence 
> >> attached to
> >> +it. That means the out-fence may not be associated with the buffer in the
> >> +current ``VIDIOC_QBUF`` ioctl call because the ordering in which 
> >> videobuf2 core
> >> +queues the buffers to the drivers can't be guaranteed. To become aware of 
> >> the
> >> +of the next queued buffer and the out-fence attached to it the
> >> +``V4L2_EVENT_BUF_QUEUED`` event should be used. It will trigger an event
> >> +for every buffer queued to the V4L2 driver.
> > 
> > This makes no sense.
> > 
> > Setting this flag means IMHO that when *this* buffer is queued up to the 
> > driver,
> > then it should send the BUF_QUEUED event with an out fence.
> > 
> > I.e. it signals that userspace wants to have the out-fence. The requirement 
> > w.r.t.
> > ordering is that the BUF_QUEUED events have to be in order, but that is 
> > something
> > that the driver can ensure in the case it is doing internal re-ordering.
> > 
> > This requirement is something that needs to be documented here, BTW.
> > 
> > Anyway, the flag shouldn't refer to some 'next buffer', since that's very 
> > confusing.
> 
> Just ignore this comment. I assume v4 will implement it like this.

What approach do you mean by "like this". I'm confused now. :)

In fact, I was in doubt between these two different approaches here.
Should the flag mean *this* or the *next* buffer? The buffers can still
be reordered at the videobuf2 level, because they might be waiting on
in-fences and the fences may signal out of order. Then I went for the
*next* buffer approach because we don't know that buffer for sure.
But now thinking on this again we shouldn't have problems with the 
*this* buffer approach also.

> 
> Regards,
> 
>   Hans
> 
> > 
> >> +
> >> +At streamoff the out-fences will either signal normally if the drivers 
> >> wait
> > 
> > s/drivers wait/driver waits/
> > 
> >> +for the operations on the buffers to finish or signal with error if the
> >> +driver cancel the pending operations.
> > 
> > s/cancel/cancels/
> > 
> > Thinking with my evil hat on:
> > 
> > What happens if the application dequeues the buffer (VIDIOC_DQBUF) before
> > dequeuing the BUF_QUEUED event? Or if the application doesn't call 
> > VIDIOC_DQEVENT
> > at all? Should any 

[GIT PULL FOR v4.15] tc358743: add CEC support

[Hans Verkuil]

Add CEC support to the tc358743 HDMI-to-CSI bridge.

Tested with my Raspberry Pi 2B and an Auvidea B100 adapter.

Regards,

Hans

The following changes since commit 1efdf1776e2253b77413c997bed862410e4b6aaf:

  media: leds: as3645a: add V4L2_FLASH_LED_CLASS dependency (2017-09-05 
16:32:45 -0400)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git tc358743

for you to fetch changes up to e7d5ffedee135e9bf63268f3fb259c2777ffe8c1:

  tc358743: add CEC support (2017-09-11 15:01:46 +0200)


Hans Verkuil (2):
  tc358743_regs.h: add CEC registers
  tc358743: add CEC support

 drivers/media/i2c/Kconfig |   8 +++
 drivers/media/i2c/tc358743.c  | 205 
++---
 drivers/media/i2c/tc358743_regs.h |  94 +-
 3 files changed, 299 insertions(+), 8 deletions(-)

Re: [PATCH v10 18/24] v4l: fwnode: Add a helper function to obtain device / interger references

[Hans Verkuil]

On 09/11/2017 02:28 PM, Sakari Ailus wrote:
> Hi Hans,
> 
> Thanks for the review.
> 
> On Mon, Sep 11, 2017 at 11:38:58AM +0200, Hans Verkuil wrote:
>> Typo in subject: interger -> integer
>>
>> On 09/11/2017 10:00 AM, Sakari Ailus wrote:
>>> v4l2_fwnode_reference_parse_int_prop() will find an fwnode such that under
>>> the device's own fwnode, 
>>
>> Sorry, you lost me here. Which device are we talking about?
> 
> The fwnode related a struct device, in other words what dev_fwnode(dev)
> gives you. This is either struct device.fwnode or struct
> device.of_node.fwnode, depending on which firmware interface was used to
> create the device.
> 
> I'll add a note of this.
> 
>>
>>> it will follow child fwnodes with the given
>>> property -- value pair and return the resulting fwnode.
>>
>> property-value pair (easier readable that way).
>>
>> You only describe v4l2_fwnode_reference_parse_int_prop(), not
>> v4l2_fwnode_reference_parse_int_props().
> 
> Yes, I think I changed the naming but forgot to update the commit. I'll do
> that now.
> 
>>
>>>
>>> Signed-off-by: Sakari Ailus 
>>> ---
>>>  drivers/media/v4l2-core/v4l2-fwnode.c | 93 
>>> +++
>>>  1 file changed, 93 insertions(+)
>>>
>>> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
>>> b/drivers/media/v4l2-core/v4l2-fwnode.c
>>> index 4821c4989119..56eee5bbd3b5 100644
>>> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
>>> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
>>> @@ -496,6 +496,99 @@ static int v4l2_fwnode_reference_parse(
>>> return ret;
>>>  }
>>>  
>>> +static struct fwnode_handle *v4l2_fwnode_reference_get_int_prop(
>>> +   struct fwnode_handle *fwnode, const char *prop, unsigned int index,
>>> +   const char **props, unsigned int nprops)
>>
>> Need comments describing what this does.
> 
> Yes. I'll also rename it (get -> read) for consistency with the async
> changes.

Which async changes? Since the fwnode_handle that's returned is refcounted
I wonder if 'get' isn't the right name in this case.

> 
>>
>>> +{
>>> +   struct fwnode_reference_args fwnode_args;
>>> +   unsigned int *args = fwnode_args.args;
>>> +   struct fwnode_handle *child;
>>> +   int ret;
>>> +
>>> +   ret = fwnode_property_get_reference_args(fwnode, prop, NULL, nprops,
>>> +index, _args);
>>> +   if (ret)
>>> +   return ERR_PTR(ret == -EINVAL ? -ENOENT : ret);
>>
>> Why map EINVAL to ENOENT? Needs a comment, either here or in the function 
>> description.
> 
> fwnode_property_get_reference_args() returns currently a little bit
> different error codes in ACPI / DT. This is worth documenting there and
> fixing as well.
> 
>>
>>> +
>>> +   for (fwnode = fwnode_args.fwnode;
>>> +nprops; nprops--, fwnode = child, props++, args++) {
>>
>> I think you cram too much in this for-loop: fwnode, nprops, fwnode, props, 
>> args...
>> It's hard to parse.
> 
> Hmm. I'm not sure if that really helps; the function is just handling each
> entry in the array and related array pointers are changed accordingly. The
> fwnode = child assignment is there to move to the child node. I.e. what you
> need for handling the loop itself.
> 
> I can change this though if you think it really makes a difference for
> better.

I think so, yes. I noticed you like complex for-loops :-)

> 
>>
>> I would make this a 'while (nprops)' and write out all the other assignments,
>> increments and decrements.
>>
>>> +   u32 val;
>>> +
>>> +   fwnode_for_each_child_node(fwnode, child) {
>>> +   if (fwnode_property_read_u32(child, *props, ))
>>> +   continue;
>>> +
>>> +   if (val == *args)
>>> +   break;
>>
>> I'm lost. This really needs comments and perhaps even an DT or ACPI example
>> so you can see what exactly it is we're doing here.
> 
> I'll add comments to the code. A good example will be ACPI documentation
> for LEDs, see 17th patch in v9. That will go through the linux-pm tree so
> it won't be available in the same tree for a while.

Ideally an ACPI and an equivalent DT example would be nice to have, but I might
be asking too much. I'm not that familiar with ACPI, so for me a DT example
is easier.

> 
>>
>>> +   }
>>> +
>>> +   fwnode_handle_put(fwnode);
>>> +
>>> +   if (!child) {
>>> +   fwnode = ERR_PTR(-ENOENT);
>>> +   break;
>>> +   }
>>> +   }
>>> +
>>> +   return fwnode;
>>> +}
>>> +
>>> +static int v4l2_fwnode_reference_parse_int_props(
>>> +   struct device *dev, struct v4l2_async_notifier *notifier,
>>> +   const char *prop, const char **props, unsigned int nprops)
>>
>> Needs comments describing what this does.
> 
> Will add.
> 
>>
>>> +{
>>> +   struct fwnode_handle *fwnode;
>>> +   unsigned int index = 0;
>>> +   int ret;
>>> +
>>> +   while (!IS_ERR((fwnode = v4l2_fwnode_reference_get_int_prop(
>>> + 

[PATCH] media: platform: VIDEO_QCOM_CAMSS should depend on HAS_DMA

[Geert Uytterhoeven]

If NO_DMA=y:

warning: (TOUCHSCREEN_SUR40 && VIDEO_TW68 && VIDEO_CX23885 && VIDEO_CX25821 
&& VIDEO_CX88 && VIDEO_SAA7134 && VIDEO_COBALT && VIDEO_QCOM_CAMSS) selects 
VIDEOBUF2_DMA_SG which has unmet direct dependencies (MEDIA_SUPPORT && HAS_DMA)

and

ERROR: "bad_dma_ops" [drivers/media/v4l2-core/videobuf2-dma-sg.ko] 
undefined!
ERROR: "bad_dma_ops" [drivers/media/platform/qcom/camss-8x16/qcom-camss.ko] 
undefined!

VIDEO_QCOM_CAMSS selects VIDEOBUF2_DMA_SG, which bypasses its dependency
on HAS_DMA.  Make VIDEO_QCOM_CAMSS depend on HAS_DMA to fix this.

Fixes: f5c074947f56533c ("media: camss: Enable building")
Signed-off-by: Geert Uytterhoeven 
---
 drivers/media/platform/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7e7cc49b86740009..3c4f7fa7b9d8ea06 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -112,7 +112,7 @@ config VIDEO_PXA27x
 
 config VIDEO_QCOM_CAMSS
tristate "Qualcomm 8x16 V4L2 Camera Subsystem driver"
-   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && HAS_DMA
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
select VIDEOBUF2_DMA_SG
select V4L2_FWNODE
-- 
2.7.4

[PATCHv4 2/4] ARM: tegra: add CEC support to tegra124.dtsi

[Hans Verkuil]

From: Hans Verkuil 

Add support for the Tegra CEC IP to tegra124.dtsi and enable it on the
Jetson TK1.

Signed-off-by: Hans Verkuil 
---
 arch/arm/boot/dts/tegra124-jetson-tk1.dts |  4 
 arch/arm/boot/dts/tegra124.dtsi   | 12 +++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts 
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 7bacb2954f58..7f56de6890c3 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -67,6 +67,10 @@
};
};
 
+   cec@70015000 {
+   status = "okay";
+   };
+
gpu@0,5700 {
/*
 * Node left disabled on purpose - the bootloader will enable
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 1b10b14a6abd..1a21e527fb6e 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -123,7 +123,7 @@
nvidia,head = <1>;
};
 
-   hdmi@5428 {
+   hdmi: hdmi@5428 {
compatible = "nvidia,tegra124-hdmi";
reg = <0x0 0x5428 0x0 0x0004>;
interrupts = ;
@@ -851,6 +851,16 @@
status = "disabled";
};
 
+   cec@70015000 {
+   compatible = "nvidia,tegra124-cec";
+   reg = <0x0 0x70015000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_car TEGRA124_CLK_CEC>;
+   clock-names = "cec";
+   hdmi-phandle = <>;
+   status = "disabled";
+   };
+
soctherm: thermal-sensor@700e2000 {
compatible = "nvidia,tegra124-soctherm";
reg = <0x0 0x700e2000 0x0 0x600 /* SOC_THERM reg_base */
-- 
2.14.1

[PATCHv4 0/4] tegra-cec: add Tegra HDMI CEC support

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds support for the Tegra CEC functionality.

This v4 has been rebased to the latest 4.14 pre-rc1 mainline.

Please review! Other than for the bindings that are now Acked I have not
received any feedback.

The first patch documents the CEC bindings, the second adds support
for this to tegra124.dtsi and enables it for the Jetson TK1.

The third patch adds the CEC driver itself and the final patch adds
the cec notifier support to the drm/tegra driver in order to notify
the CEC driver whenever the physical address changes.

I expect that the dts changes apply as well to the Tegra X1/X2 and possibly
other Tegra SoCs, but I can only test this with my Jetson TK1 board.

The dt-bindings and the tegra-cec driver would go in through the media
subsystem, the drm/tegra part through the drm subsystem and the dts
changes through (I guess) the linux-tegra developers. Luckily they are
all independent of one another.

To test this you need the CEC utilities from git://linuxtv.org/v4l-utils.git.

To build this:

git clone git://linuxtv.org/v4l-utils.git
cd v4l-utils
./bootstrap.sh; ./configure
make
sudo make install # optional, you really only need utils/cec*

To test:

cec-ctl --playback # configure as playback device
cec-ctl -S # detect all connected CEC devices

See here for the public CEC API:

https://hverkuil.home.xs4all.nl/spec/uapi/cec/cec-api.html

Regards,

Hans

Changes since v3:

- Use the new CEC_CAP_DEFAULTS define
- Use IS_ERR(cec->adap) instead of IS_ERR_OR_NULL(cec->adap)
  (cec_allocate_adapter never returns a NULL pointer)
- Drop the device_init_wakeup: wakeup is not (yet) supported by
  the CEC framework and I have never tested it.

Hans Verkuil (4):
  dt-bindings: document the tegra CEC bindings
  ARM: tegra: add CEC support to tegra124.dtsi
  tegra-cec: add Tegra HDMI CEC driver
  drm/tegra: add cec-notifier support

 .../devicetree/bindings/media/tegra-cec.txt|  27 ++
 MAINTAINERS|   8 +
 arch/arm/boot/dts/tegra124-jetson-tk1.dts  |   4 +
 arch/arm/boot/dts/tegra124.dtsi|  12 +-
 drivers/gpu/drm/tegra/Kconfig  |   1 +
 drivers/gpu/drm/tegra/drm.h|   3 +
 drivers/gpu/drm/tegra/hdmi.c   |   9 +
 drivers/gpu/drm/tegra/output.c |   6 +
 drivers/media/platform/Kconfig |  11 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/tegra-cec/Makefile  |   1 +
 drivers/media/platform/tegra-cec/tegra_cec.c   | 501 +
 drivers/media/platform/tegra-cec/tegra_cec.h   | 127 ++
 13 files changed, 711 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt
 create mode 100644 drivers/media/platform/tegra-cec/Makefile
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.c
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.h

-- 
2.14.1

[PATCHv4 1/4] dt-bindings: document the tegra CEC bindings

[Hans Verkuil]

From: Hans Verkuil 

This documents the binding for the Tegra CEC module.

Signed-off-by: Hans Verkuil 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/tegra-cec.txt| 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/tegra-cec.txt

diff --git a/Documentation/devicetree/bindings/media/tegra-cec.txt 
b/Documentation/devicetree/bindings/media/tegra-cec.txt
new file mode 100644
index ..c503f06f3b84
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/tegra-cec.txt
@@ -0,0 +1,27 @@
+* Tegra HDMI CEC hardware
+
+The HDMI CEC module is present in Tegra SoCs and its purpose is to
+handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+  - compatible : value should be one of the following:
+   "nvidia,tegra114-cec"
+   "nvidia,tegra124-cec"
+   "nvidia,tegra210-cec"
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+  - interrupts : HDMI CEC interrupt number to the CPU.
+  - clocks : from common clock binding: handle to HDMI CEC clock.
+  - clock-names : from common clock binding: must contain "cec",
+ corresponding to the entry in the clocks property.
+  - hdmi-phandle : phandle to the HDMI controller, see also cec.txt.
+
+Example:
+
+cec@70015000 {
+   compatible = "nvidia,tegra124-cec";
+   reg = <0x0 0x70015000 0x0 0x1000>;
+   interrupts = ;
+   clocks = <_car TEGRA124_CLK_CEC>;
+   clock-names = "cec";
+};
-- 
2.14.1

[PATCHv4 4/4] drm/tegra: add cec-notifier support

[Hans Verkuil]

From: Hans Verkuil 

In order to support CEC the HDMI driver has to inform the CEC driver
whenever the physical address changes. So when the EDID is read the
CEC driver has to be informed and whenever the hotplug detect goes
away.

This is done through the cec-notifier framework.

The link between the HDMI driver and the CEC driver is done through
the hdmi_phandle in the tegra-cec node in the device tree.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/tegra/Kconfig  | 1 +
 drivers/gpu/drm/tegra/drm.h| 3 +++
 drivers/gpu/drm/tegra/hdmi.c   | 9 +
 drivers/gpu/drm/tegra/output.c | 6 ++
 4 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 2db29d67193d..c882918c2024 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -8,6 +8,7 @@ config DRM_TEGRA
select DRM_PANEL
select TEGRA_HOST1X
select IOMMU_IOVA if IOMMU_SUPPORT
+   select CEC_CORE if CEC_NOTIFIER
help
  Choose this option if you have an NVIDIA Tegra SoC.
 
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 6d6da01282f3..c0a18b60caf1 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -212,6 +212,8 @@ int tegra_dc_state_setup_clock(struct tegra_dc *dc,
   struct clk *clk, unsigned long pclk,
   unsigned int div);
 
+struct cec_notifier;
+
 struct tegra_output {
struct device_node *of_node;
struct device *dev;
@@ -219,6 +221,7 @@ struct tegra_output {
struct drm_panel *panel;
struct i2c_adapter *ddc;
const struct edid *edid;
+   struct cec_notifier *notifier;
unsigned int hpd_irq;
int hpd_gpio;
enum of_gpio_flags hpd_gpio_flags;
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index cda0491ed6bf..fbf14e1efd0e 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -21,6 +21,8 @@
 
 #include 
 
+#include 
+
 #include "hdmi.h"
 #include "drm.h"
 #include "dc.h"
@@ -1720,6 +1722,10 @@ static int tegra_hdmi_probe(struct platform_device *pdev)
return PTR_ERR(hdmi->vdd);
}
 
+   hdmi->output.notifier = cec_notifier_get(>dev);
+   if (hdmi->output.notifier == NULL)
+   return -ENOMEM;
+
hdmi->output.dev = >dev;
 
err = tegra_output_probe(>output);
@@ -1778,6 +1784,9 @@ static int tegra_hdmi_remove(struct platform_device *pdev)
 
tegra_output_remove(>output);
 
+   if (hdmi->output.notifier)
+   cec_notifier_put(hdmi->output.notifier);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 595d1ec3e02e..57c052521a44 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -11,6 +11,8 @@
 #include 
 #include "drm.h"
 
+#include 
+
 int tegra_output_connector_get_modes(struct drm_connector *connector)
 {
struct tegra_output *output = connector_to_output(connector);
@@ -33,6 +35,7 @@ int tegra_output_connector_get_modes(struct drm_connector 
*connector)
edid = drm_get_edid(connector, output->ddc);
 
drm_mode_connector_update_edid_property(connector, edid);
+   cec_notifier_set_phys_addr_from_edid(output->notifier, edid);
 
if (edid) {
err = drm_add_edid_modes(connector, edid);
@@ -68,6 +71,9 @@ tegra_output_connector_detect(struct drm_connector 
*connector, bool force)
status = connector_status_connected;
}
 
+   if (status != connector_status_connected)
+   cec_notifier_phys_addr_invalidate(output->notifier);
+
return status;
 }
 
-- 
2.14.1

[PATCHv4 3/4] tegra-cec: add Tegra HDMI CEC driver

[Hans Verkuil]

From: Hans Verkuil 

This driver adds support for the Tegra CEC IP. It is based on the
NVIDIA drivers/misc/tegra-cec driver in their 3.10 kernel.

This has been converted to the CEC framework and cleaned up.

Tested with my Jetson TK1 board. It has also been tested with the
Tegra X1 in an embedded product.

Note of warning for the Tegra X2: this SoC supports two HDMI outputs,
but only one CEC adapter and the CEC bus is shared between the
two outputs. This is a design mistake and the CEC adapter can
control only one HDMI output. Never hook up both HDMI outputs
to the CEC bus in a hardware design: this is illegal as per the
CEC specification.

The CEC bus can be shared between multiple inputs and zero or one
outputs, but not between multiple outputs.

Signed-off-by: Hans Verkuil 
---
 MAINTAINERS  |   8 +
 drivers/media/platform/Kconfig   |  11 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/tegra-cec/Makefile|   1 +
 drivers/media/platform/tegra-cec/tegra_cec.c | 501 +++
 drivers/media/platform/tegra-cec/tegra_cec.h | 127 +++
 6 files changed, 650 insertions(+)
 create mode 100644 drivers/media/platform/tegra-cec/Makefile
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.c
 create mode 100644 drivers/media/platform/tegra-cec/tegra_cec.h

diff --git a/MAINTAINERS b/MAINTAINERS
index eb930ebecfcb..dd40c1f335a8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1923,6 +1923,14 @@ M:   Lennert Buytenhek 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 
+ARM/TEGRA HDMI CEC SUBSYSTEM SUPPORT
+M: Hans Verkuil 
+L: linux-te...@vger.kernel.org
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/platform/tegra-cec/
+F: Documentation/devicetree/bindings/media/tegra-cec.txt
+
 ARM/TETON BGA MACHINE SUPPORT
 M: "Mark F. Brown" 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7e7cc49b8674..ec218fcf3886 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -589,6 +589,17 @@ config VIDEO_STM32_HDMI_CEC
  CEC bus is present in the HDMI connector and enables communication
  between compatible devices.
 
+config VIDEO_TEGRA_HDMI_CEC
+   tristate "Tegra HDMI CEC driver"
+   depends on ARCH_TEGRA || COMPILE_TEST
+   select CEC_CORE
+   select CEC_NOTIFIER
+   ---help---
+ This is a driver for the Tegra HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 endif #CEC_PLATFORM_DRIVERS
 
 menuconfig SDR_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c1ef946bf032..e31faaa852f3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -46,6 +46,8 @@ obj-$(CONFIG_VIDEO_STI_HDMI_CEC)  += sti/cec/
 
 obj-$(CONFIG_VIDEO_STI_DELTA)  += sti/delta/
 
+obj-$(CONFIG_VIDEO_TEGRA_HDMI_CEC) += tegra-cec/
+
 obj-y  += stm32/
 
 obj-y   += blackfin/
diff --git a/drivers/media/platform/tegra-cec/Makefile 
b/drivers/media/platform/tegra-cec/Makefile
new file mode 100644
index ..f3d81127589f
--- /dev/null
+++ b/drivers/media/platform/tegra-cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_TEGRA_HDMI_CEC) += tegra_cec.o
diff --git a/drivers/media/platform/tegra-cec/tegra_cec.c 
b/drivers/media/platform/tegra-cec/tegra_cec.c
new file mode 100644
index ..b53743f555e8
--- /dev/null
+++ b/drivers/media/platform/tegra-cec/tegra_cec.c
@@ -0,0 +1,501 @@
+/*
+ * Tegra CEC implementation
+ *
+ * The original 3.10 CEC driver using a custom API:
+ *
+ * Copyright (c) 2012-2015, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Conversion to the CEC framework and to the mainline kernel:
+ *
+ * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 

Re: [PATCH v10 18/24] v4l: fwnode: Add a helper function to obtain device / interger references

[Sakari Ailus]

Hi Hans,

Thanks for the review.

On Mon, Sep 11, 2017 at 11:38:58AM +0200, Hans Verkuil wrote:
> Typo in subject: interger -> integer
> 
> On 09/11/2017 10:00 AM, Sakari Ailus wrote:
> > v4l2_fwnode_reference_parse_int_prop() will find an fwnode such that under
> > the device's own fwnode, 
> 
> Sorry, you lost me here. Which device are we talking about?

The fwnode related a struct device, in other words what dev_fwnode(dev)
gives you. This is either struct device.fwnode or struct
device.of_node.fwnode, depending on which firmware interface was used to
create the device.

I'll add a note of this.

> 
> > it will follow child fwnodes with the given
> > property -- value pair and return the resulting fwnode.
> 
> property-value pair (easier readable that way).
> 
> You only describe v4l2_fwnode_reference_parse_int_prop(), not
> v4l2_fwnode_reference_parse_int_props().

Yes, I think I changed the naming but forgot to update the commit. I'll do
that now.

> 
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  drivers/media/v4l2-core/v4l2-fwnode.c | 93 
> > +++
> >  1 file changed, 93 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> > b/drivers/media/v4l2-core/v4l2-fwnode.c
> > index 4821c4989119..56eee5bbd3b5 100644
> > --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> > +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> > @@ -496,6 +496,99 @@ static int v4l2_fwnode_reference_parse(
> > return ret;
> >  }
> >  
> > +static struct fwnode_handle *v4l2_fwnode_reference_get_int_prop(
> > +   struct fwnode_handle *fwnode, const char *prop, unsigned int index,
> > +   const char **props, unsigned int nprops)
> 
> Need comments describing what this does.

Yes. I'll also rename it (get -> read) for consistency with the async
changes.

> 
> > +{
> > +   struct fwnode_reference_args fwnode_args;
> > +   unsigned int *args = fwnode_args.args;
> > +   struct fwnode_handle *child;
> > +   int ret;
> > +
> > +   ret = fwnode_property_get_reference_args(fwnode, prop, NULL, nprops,
> > +index, _args);
> > +   if (ret)
> > +   return ERR_PTR(ret == -EINVAL ? -ENOENT : ret);
> 
> Why map EINVAL to ENOENT? Needs a comment, either here or in the function 
> description.

fwnode_property_get_reference_args() returns currently a little bit
different error codes in ACPI / DT. This is worth documenting there and
fixing as well.

> 
> > +
> > +   for (fwnode = fwnode_args.fwnode;
> > +nprops; nprops--, fwnode = child, props++, args++) {
> 
> I think you cram too much in this for-loop: fwnode, nprops, fwnode, props, 
> args...
> It's hard to parse.

Hmm. I'm not sure if that really helps; the function is just handling each
entry in the array and related array pointers are changed accordingly. The
fwnode = child assignment is there to move to the child node. I.e. what you
need for handling the loop itself.

I can change this though if you think it really makes a difference for
better.

> 
> I would make this a 'while (nprops)' and write out all the other assignments,
> increments and decrements.
> 
> > +   u32 val;
> > +
> > +   fwnode_for_each_child_node(fwnode, child) {
> > +   if (fwnode_property_read_u32(child, *props, ))
> > +   continue;
> > +
> > +   if (val == *args)
> > +   break;
> 
> I'm lost. This really needs comments and perhaps even an DT or ACPI example
> so you can see what exactly it is we're doing here.

I'll add comments to the code. A good example will be ACPI documentation
for LEDs, see 17th patch in v9. That will go through the linux-pm tree so
it won't be available in the same tree for a while.

> 
> > +   }
> > +
> > +   fwnode_handle_put(fwnode);
> > +
> > +   if (!child) {
> > +   fwnode = ERR_PTR(-ENOENT);
> > +   break;
> > +   }
> > +   }
> > +
> > +   return fwnode;
> > +}
> > +
> > +static int v4l2_fwnode_reference_parse_int_props(
> > +   struct device *dev, struct v4l2_async_notifier *notifier,
> > +   const char *prop, const char **props, unsigned int nprops)
> 
> Needs comments describing what this does.

Will add.

> 
> > +{
> > +   struct fwnode_handle *fwnode;
> > +   unsigned int index = 0;
> > +   int ret;
> > +
> > +   while (!IS_ERR((fwnode = v4l2_fwnode_reference_get_int_prop(
> > +   dev_fwnode(dev), prop, index, props,
> > +   nprops {
> > +   fwnode_handle_put(fwnode);
> > +   index++;
> > +   }
> > +
> > +   if (PTR_ERR(fwnode) != -ENOENT)
> > +   return PTR_ERR(fwnode);
> 
> Missing 'if (index == 0)'?

Yes, will add.

> 
> > +
> > +   ret = v4l2_async_notifier_realloc(notifier,
> > + notifier->num_subdevs + index);
> > +   if (ret)
> > +   return -ENOMEM;
> > +
> > +   

[PATCHv3 1/3] drm: add support for DisplayPort CEC-Tunneling-over-AUX

[Hans Verkuil]

From: Hans Verkuil 

This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.

Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is created, it may not actually work.

Signed-off-by: Hans Verkuil 
Tested-by: Carlos Santa 
---
 drivers/gpu/drm/Kconfig  |  10 ++
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/drm_dp_cec.c | 301 +++
 include/drm/drm_dp_helper.h  |  24 
 4 files changed, 336 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_dp_cec.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 83cb2a88c204..1f2708df5c4e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -120,6 +120,16 @@ config DRM_LOAD_EDID_FIRMWARE
  default case is N. Details and instructions how to build your own
  EDID data are given in Documentation/EDID/HOWTO.txt.
 
+config DRM_DP_CEC
+   bool "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
+   select CEC_CORE
+   help
+ Choose this option if you want to enable HDMI CEC support for
+ DisplayPort/USB-C to HDMI adapters.
+
+ Note: not all adapters support this feature, and even for those
+ that do support this they often do not hook up the CEC pin.
+
 config DRM_TTM
tristate
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 24a066e1841c..c6552c62049e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -40,6 +40,7 @@ drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += 
drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
 drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o
+drm_kms_helper-$(CONFIG_DRM_DP_CEC) += drm_dp_cec.o
 
 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
 obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
new file mode 100644
index ..b831bb72c932
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -0,0 +1,301 @@
+/*
+ * DisplayPort CEC-Tunneling-over-AUX support
+ *
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Unfortunately it turns out that we have a chicken-and-egg situation
+ * here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
+ * have a converter chip that supports CEC-Tunneling-over-AUX (usually the
+ * Parade PS176), but they do not wire up the CEC pin, thus making CEC
+ * useless.
+ *
+ * Sadly there is no way for this driver to know this. What happens is
+ * that a /dev/cecX device is created that is isolated and unable to see
+ * any of the other CEC devices. Quite literally the CEC wire is cut
+ * (or in this case, never connected in the first place).
+ *
+ * I suspect that the reason so few adapters support this is that this
+ * tunneling protocol was never supported by any OS. So there was no
+ * easy way of testing it, and no incentive to correctly wire up the
+ * CEC pin.
+ *
+ * Hopefully by creating this driver it will be easier for vendors to
+ * finally fix their adapters and test the CEC functionality.
+ *
+ * I keep a list of known working adapters here:
+ *
+ * https://hverkuil.home.xs4all.nl/cec-status.txt
+ *
+ * Please mail me (hverk...@xs4all.nl) if you find an adapter that works
+ * and is not yet listed there.
+ */
+
+/**
+ * DOC: dp cec helpers
+ *
+ * These functions take care of supporting the CEC-Tunneling-over-AUX
+ * feature of DisplayPort-to-HDMI adapters.
+ */
+
+static int drm_dp_cec_adap_enable(struct cec_adapter *adap, bool enable)
+{
+   struct drm_dp_aux *aux = cec_get_drvdata(adap);
+   u32 val = enable ? DP_CEC_TUNNELING_ENABLE : 0;
+   ssize_t err = 0;
+
+   err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, val);
+   return (enable && err < 0) ? err : 0;
+}
+
+static int drm_dp_cec_adap_log_addr(struct cec_adapter 

[PATCHv3 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
feature. This patch series is based on the current pre-4.14-rc1 mainline
which has all the needed cec 4.14 patches merged.

This patch series has been tested with my NUC7i5BNK and a Samsung USB-C to 
HDMI adapter.

Please note this comment at the start of drm_dp_cec.c:

--
Unfortunately it turns out that we have a chicken-and-egg situation
here. Quite a few active (mini-)DP-to-HDMI or USB-C-to-HDMI adapters
have a converter chip that supports CEC-Tunneling-over-AUX (usually the
Parade PS176), but they do not wire up the CEC pin, thus making CEC
useless.

Sadly there is no way for this driver to know this. What happens is 
that a /dev/cecX device is created that is isolated and unable to see
any of the other CEC devices. Quite literally the CEC wire is cut
(or in this case, never connected in the first place).

I suspect that the reason so few adapters support this is that this
tunneling protocol was never supported by any OS. So there was no 
easy way of testing it, and no incentive to correctly wire up the
CEC pin.

Hopefully by creating this driver it will be easier for vendors to 
finally fix their adapters and test the CEC functionality.

I keep a list of known working adapters here:

https://hverkuil.home.xs4all.nl/cec-status.txt

Please mail me (hverk...@xs4all.nl) if you find an adapter that works
and is not yet listed there.
--

I really hope that this work will provide an incentive for vendors to
finally connect the CEC pin. It's a shame that there are so few adapters
that work (I found only two USB-C to HDMI adapters that work, and no
(mini-)DP to HDMI adapters at all).

Note that a colleague who actually knows his way around a soldering iron
modified an UpTab DisplayPort-to-HDMI adapter for me, hooking up the CEC
pin. And after that change it worked. I also received confirmation that
this really is a chicken-and-egg situation: it is because there is no CEC
support for this feature in any OS that they do not hook up the CEC pin.

So hopefully if this gets merged there will be an incentive for vendors
to make adapters where this actually works. It is a very nice feature
for HTPC boxes.

I've added Imre and Ville. It would be great if this can go in for 4.15.

Changes since v2:

- Use the new CEC_CAP_DEFAULTS define
- Replace 'if (!IS_ERR_OR_NULL(aux->cec_adap)) {' in 
drm_dp_cec_configure_adapter()
  by just 'if (aux->cec_adap) {'.

Changes since v1:

- Incorporated Sean's review comments in patch 1/3.

Regards,

Hans

Hans Verkuil (3):
  drm: add support for DisplayPort CEC-Tunneling-over-AUX
  drm-kms-helpers.rst: document the DP CEC helpers
  drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

 Documentation/gpu/drm-kms-helpers.rst |   9 +
 drivers/gpu/drm/Kconfig   |  10 ++
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/drm_dp_cec.c  | 301 ++
 drivers/gpu/drm/i915/intel_dp.c   |  18 +-
 include/drm/drm_dp_helper.h   |  24 +++
 6 files changed, 359 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_dp_cec.c

-- 
2.14.1

[PATCHv3 3/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

[Hans Verkuil]

From: Hans Verkuil 

Implement support for this DisplayPort feature.

The cec device is created whenever it detects an adapter that
has this feature. It is only removed when a new adapter is connected
that does not support this. If a new adapter is connected that has
different properties than the previous one, then the old cec device is
unregistered and a new one is registered to replace the old one.

Signed-off-by: Hans Verkuil 
Tested-by: Carlos Santa 
---
 drivers/gpu/drm/i915/intel_dp.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 64fa774c855b..fdb853d2c458 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1449,6 +1450,7 @@ static void intel_aux_reg_init(struct intel_dp *intel_dp)
 static void
 intel_dp_aux_fini(struct intel_dp *intel_dp)
 {
+   cec_unregister_adapter(intel_dp->aux.cec_adap);
kfree(intel_dp->aux.name);
 }
 
@@ -4587,6 +4589,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
intel_connector->detect_edid = edid;
 
intel_dp->has_audio = drm_detect_monitor_audio(edid);
+   cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
 }
 
 static void
@@ -4596,6 +4599,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
 
kfree(intel_connector->detect_edid);
intel_connector->detect_edid = NULL;
+   cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
 
intel_dp->has_audio = false;
 }
@@ -4616,13 +4620,17 @@ intel_dp_long_pulse(struct intel_connector 
*intel_connector)
intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
 
/* Can't disconnect eDP, but you can close the lid... */
-   if (is_edp(intel_dp))
+   if (is_edp(intel_dp)) {
status = edp_detect(intel_dp);
-   else if (intel_digital_port_connected(to_i915(dev),
- dp_to_dig_port(intel_dp)))
+   } else if (intel_digital_port_connected(to_i915(dev),
+   dp_to_dig_port(intel_dp))) {
status = intel_dp_detect_dpcd(intel_dp);
-   else
+   if (status == connector_status_connected)
+   drm_dp_cec_configure_adapter(_dp->aux,
+intel_dp->aux.name, dev->dev);
+   } else {
status = connector_status_disconnected;
+   }
 
if (status == connector_status_disconnected) {
memset(_dp->compliance, 0, sizeof(intel_dp->compliance));
@@ -5011,6 +5019,8 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
 
intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
 
+   drm_dp_cec_irq(_dp->aux);
+
if (intel_dp->is_mst) {
if (intel_dp_check_mst_status(intel_dp) == -EINVAL) {
/*
-- 
2.14.1

[PATCHv3 2/3] drm-kms-helpers.rst: document the DP CEC helpers

[Hans Verkuil]

From: Hans Verkuil 

Document the Display Port CEC helper functions.

Signed-off-by: Hans Verkuil 
---
 Documentation/gpu/drm-kms-helpers.rst | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index 7c5e2549a58a..0d2fa879edd1 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -175,6 +175,15 @@ Display Port Helper Functions Reference
 .. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c
:export:
 
+Display Port CEC Helper Functions Reference
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c
+   :doc: dp cec helpers
+
+.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c
+   :export:
+
 Display Port Dual Mode Adaptor Helper Functions Reference
 =
 
-- 
2.14.1

Re: [PATCH v10 19/24] v4l: fwnode: Add convenience function for parsing common external refs

[Pavel Machek]

On Mon 2017-09-11 11:00:03, Sakari Ailus wrote:
> Add v4l2_fwnode_parse_reference_sensor_common for parsing common
> sensor properties that refer to adjacent devices such as flash or lens
> driver chips.
> 
> As this is an association only, there's little a regular driver needs to
> know about these devices as such.
> 
> Signed-off-by: Sakari Ailus 
> Acked-by: Hans Verkuil 
> ---
>  drivers/media/v4l2-core/v4l2-fwnode.c | 35 
> +++
>  include/media/v4l2-fwnode.h   | 13 +
>  2 files changed, 48 insertions(+)
> 
>  
> +/**
> + * v4l2_fwnode_reference_parse_sensor_common - parse common references on
> + *  sensors for async sub-devices
> + * @dev: the device node the properties of which are parsed for references
> + * @notifier: the async notifier where the async subdevs will be added
> + *
> + * Return: 0 on success
> + *  -ENOMEM if memory allocation failed
> + *  -EINVAL if property parsing failed
> + */

Returns: would sound more correct to me, but it seems kernel is split
on that.

Acked-by: Pavel Machek 
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v10 24/24] arm: dts: omap3: N9/N950: Add flash references to the camera

[Pavel Machek]

On Mon 2017-09-11 11:00:08, Sakari Ailus wrote:
> Add flash and indicator LED phandles to the sensor node.
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Pavel Machek 


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v10 20/24] dt: bindings: smiapp: Document lens-focus and flash properties

[Pavel Machek]

On Mon 2017-09-11 11:00:04, Sakari Ailus wrote:
> Document optional lens-focus and flash properties for the smiapp
driver.

Acked-by: Pavel Machek 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

[Christian König]

Am 11.09.2017 um 12:01 schrieb Chris Wilson:

[SNIP]

Yeah, but that is illegal with a fence objects.

When anybody allocates fences this way it breaks at least
reservation_object_get_fences_rcu(),
reservation_object_wait_timeout_rcu() and
reservation_object_test_signaled_single().

Many, many months ago I sent patches to fix them all.


Found those after a bit a searching. Yeah, those patches where proposed 
more than a year ago, but never pushed upstream.


Not sure if we really should go this way. dma_fence objects are shared 
between drivers and since we can't judge if it's the correct fence based 
on a criteria in the object (only the read counter which is outside) all 
drivers need to be correct for this.


I would rather go the way and change dma_fence_release() to wrap 
fence->ops->release into call_rcu() to keep the whole RCU handling 
outside of the individual drivers.


Regards,
Christian.

Re: [PATCH v10 19/24] v4l: fwnode: Add convenience function for parsing common external refs

[Sakari Ailus]

On Mon, Sep 11, 2017 at 11:47:11AM +0200, Hans Verkuil wrote:
> On 09/11/2017 10:00 AM, Sakari Ailus wrote:
> > Add v4l2_fwnode_parse_reference_sensor_common for parsing common
> > sensor properties that refer to adjacent devices such as flash or lens
> > driver chips.
> > 
> > As this is an association only, there's little a regular driver needs to
> > know about these devices as such.
> > 
> > Signed-off-by: Sakari Ailus 
> > Acked-by: Hans Verkuil 
> > ---
> >  drivers/media/v4l2-core/v4l2-fwnode.c | 35 
> > +++
> >  include/media/v4l2-fwnode.h   | 13 +
> >  2 files changed, 48 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> > b/drivers/media/v4l2-core/v4l2-fwnode.c
> > index 56eee5bbd3b5..b9e60a0e8f86 100644
> > --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> > +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> > @@ -589,6 +589,41 @@ static int v4l2_fwnode_reference_parse_int_props(
> > return ret;
> >  }
> >  
> > +int v4l2_fwnode_reference_parse_sensor_common(
> > +   struct device *dev, struct v4l2_async_notifier *notifier)
> > +{
> > +   static const char *led_props[] = { "led" };
> > +   static const struct {
> > +   const char *name;
> > +   const char **props;
> > +   unsigned int nprops;
> > +   } props[] = {
> > +   { "flash-leds", led_props, ARRAY_SIZE(led_props) },
> > +   { "lens-focus", NULL, 0 },
> > +   };
> > +   unsigned int i;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(props); i++) {
> > +   int ret;
> > +
> > +   if (props[i].props && is_acpi_node(dev_fwnode(dev)))
> > +   ret = v4l2_fwnode_reference_parse_int_props(
> > +   dev, notifier, props[i].name,
> > +   props[i].props, props[i].nprops);
> > +   else
> > +   ret = v4l2_fwnode_reference_parse(
> > +   dev, notifier, props[i].name);
> > +   if (ret) {
> > +   dev_warn(dev, "parsing property \"%s\" failed (%d)\n",
> > +props[i].name, ret);
> > +   return ret;
> > +   }
> > +   }
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(v4l2_fwnode_reference_parse_sensor_common);
> > +
> >  MODULE_LICENSE("GPL");
> >  MODULE_AUTHOR("Sakari Ailus ");
> >  MODULE_AUTHOR("Sylwester Nawrocki ");
> > diff --git a/include/media/v4l2-fwnode.h b/include/media/v4l2-fwnode.h
> > index 3819a73c3c8a..bcec1ce101dc 100644
> > --- a/include/media/v4l2-fwnode.h
> > +++ b/include/media/v4l2-fwnode.h
> > @@ -257,4 +257,17 @@ int v4l2_async_notifier_parse_fwnode_endpoints(
> >   struct v4l2_fwnode_endpoint *vep,
> >   struct v4l2_async_subdev *asd));
> >  
> > +/**
> > + * v4l2_fwnode_reference_parse_sensor_common - parse common references on
> > + *sensors for async sub-devices
> > + * @dev: the device node the properties of which are parsed for references
> > + * @notifier: the async notifier where the async subdevs will be added
> > + *
> 
> I think you should add a note that if this function returns 0 the
> caller should remember to call v4l2_async_notifier_release. That is not
> immediately obvious.

I'll add that, plus a note to v4l2_async_notifier_release() as well.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v3 02/15] [media] vb2: add explicit fence user API

[Hans Verkuil]

On 09/11/2017 12:55 PM, Hans Verkuil wrote:
> On 09/07/2017 08:42 PM, Gustavo Padovan wrote:
>> From: Gustavo Padovan 
>>
>> Turn the reserved2 field into fence_fd that we will use to send
>> an in-fence to the kernel and return an out-fence from the kernel to
>> userspace.
>>
>> Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
>> when sending a fence to the kernel to be waited on, and
>> V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.
>>
>> v2: add documentation
>>
>> Signed-off-by: Gustavo Padovan 
>> ---
>>  Documentation/media/uapi/v4l/buffer.rst   | 19 +++
>>  drivers/media/usb/cpia2/cpia2_v4l.c   |  2 +-
>>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  4 ++--
>>  drivers/media/v4l2-core/videobuf2-v4l2.c  |  2 +-
>>  include/uapi/linux/videodev2.h|  4 +++-
>>  5 files changed, 26 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
>> b/Documentation/media/uapi/v4l/buffer.rst
>> index ae6ee73f151c..664507ad06c6 100644
>> --- a/Documentation/media/uapi/v4l/buffer.rst
>> +++ b/Documentation/media/uapi/v4l/buffer.rst
>> @@ -648,6 +648,25 @@ Buffer Flags
>>- Start Of Exposure. The buffer timestamp has been taken when the
>>  exposure of the frame has begun. This is only valid for the
>>  ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
>> +* .. _`V4L2-BUF-FLAG-IN-FENCE`:
>> +
>> +  - ``V4L2_BUF_FLAG_IN_FENCE``
>> +  - 0x0020
>> +  - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
>> +won't be queued to the driver until the fence signals.
>> +
>> +* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
>> +
>> +  - ``V4L2_BUF_FLAG_OUT_FENCE``
>> +  - 0x0040
>> +  - Request a fence for the next buffer to be queued to V4L2 driver.
>> +The fence received back through the ``fence_fd`` field  doesn't
>> +necessarily relate to the current buffer in the
>> +:ref:`VIDIOC_QBUF ` ioctl. Although, most of the time
>> +the fence will relate to the current buffer it can't be guaranteed.
>> +So to tell userspace which buffer is associated to the out_fence,
>> +one should listen for the ``V4L2_EVENT_BUF_QUEUED`` event that
>> +provide the id of the buffer when it is queued to the V4L2 driver.
> 
> As mentioned in the previous patch, this flag should just signal that 
> userspace
> wants to receive a BUF_QUEUED event with the out-fence for this buffer. It's 
> up
> to the driver to ensure the correct ordering of the events.

I'll wait for v4 before continuing my review.

Hans

> 
> I'm missing documentation for the new fence_fd field.
> 
> It should mention that fence_fd is ignored if the IN_FENCE isn't set. 
> Applications
> will set fence_fd (aka reserved2) to 0, which should be fine as long as 
> IN_FENCE
> isn't set.
> 
>>  
>>  
>>  
>> diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
>> b/drivers/media/usb/cpia2/cpia2_v4l.c
>> index 3dedd83f0b19..6cde686bf44c 100644
>> --- a/drivers/media/usb/cpia2/cpia2_v4l.c
>> +++ b/drivers/media/usb/cpia2/cpia2_v4l.c
>> @@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, 
>> struct v4l2_buffer *buf)
>>  buf->sequence = cam->buffers[buf->index].seq;
>>  buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
>>  buf->length = cam->frame_size;
>> -buf->reserved2 = 0;
>> +buf->fence_fd = -1;
>>  buf->reserved = 0;
>>  memset(>timecode, 0, sizeof(buf->timecode));
>>  
>> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
>> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> index 821f2aa299ae..d624fb5df130 100644
>> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>> @@ -370,7 +370,7 @@ struct v4l2_buffer32 {
>>  __s32   fd;
>>  } m;
>>  __u32   length;
>> -__u32   reserved2;
>> +__s32   fence_fd;
>>  __u32   reserved;
>>  };
>>  
>> @@ -533,8 +533,8 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, 
>> struct v4l2_buffer32 __user
>>  put_user(kp->timestamp.tv_usec, >timestamp.tv_usec) ||
>>  copy_to_user(>timecode, >timecode, sizeof(struct 
>> v4l2_timecode)) ||
>>  put_user(kp->sequence, >sequence) ||
>> -put_user(kp->reserved2, >reserved2) ||
>>  put_user(kp->reserved, >reserved) ||
>> +put_user(kp->fence_fd, >fence_fd) ||
> 
> Could you move this up one line? It's easier to parse this diff if it is clear
> that fence_fd replaced reserved2.
> 
>>  put_user(kp->length, >length))
>>  return -EFAULT;
>>  
>> diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
>> b/drivers/media/v4l2-core/videobuf2-v4l2.c
>> index 0c0669976bdc..110fb45fef6f 100644
>> --- 

Re: [PATCH v3 01/15] [media] v4l: Document explicit synchronization behaviour

[Hans Verkuil]

On 09/11/2017 12:50 PM, Hans Verkuil wrote:
> On 09/07/2017 08:42 PM, Gustavo Padovan wrote:
>> From: Gustavo Padovan 
>>
>> Add section to VIDIOC_QBUF about it
>>
>> v2:
>>  - mention that fences are files (Hans)
>>  - rework for the new API
>>
>> Signed-off-by: Gustavo Padovan 
>> ---
>>  Documentation/media/uapi/v4l/vidioc-qbuf.rst | 31 
>> 
>>  1 file changed, 31 insertions(+)
>>
>> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
>> b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>> index 1f3612637200..fae0b1431672 100644
>> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
>> @@ -117,6 +117,37 @@ immediately with an ``EAGAIN`` error code when no 
>> buffer is available.
>>  The struct :c:type:`v4l2_buffer` structure is specified in
>>  :ref:`buffer`.
>>  
>> +Explicit Synchronization
>> +
>> +
>> +Explicit Synchronization allows us to control the synchronization of
>> +shared buffers from userspace by passing fences to the kernel and/or
>> +receiving them from it. Fences passed to the kernel are named in-fences and
>> +the kernel should wait them to signal before using the buffer, i.e., 
>> queueing
> 
> wait them -> wait on them
> 
> (do you wait 'on' a fence or 'for' a fence? I think it's 'on' but I'm not 
> 100% sure)
> 
>> +it to the driver. On the other side, the kernel can create out-fences for 
>> the
>> +buffers it queues to the drivers, out-fences signal when the driver is
> 
> Start a new sentence here: ...drivers. Out-fences...
> 
>> +finished with buffer, that is the buffer is ready. The fence are represented
> 
> s/that is/i.e/
> 
> s/The fence/The fences/
> 
>> +by file and passed as file descriptor to userspace.
> 
> s/by file/as a file/
> s/as file/as a file/
> 
>> +
>> +The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` ioctl
>> +using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer
>> +flags and the `fence_fd` field. If an in-fence needs to be passed to the 
>> kernel,
>> +`fence_fd` should be set to the fence file descriptor number and the
>> +``V4L2_BUF_FLAG_IN_FENCE`` should be set as well. Failure to set both will
> 
> s/Failure to set both/Setting one but not the other/
> 
>> +cause ``VIDIOC_QBUF`` to return with error.
>> +
>> +To get a out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag 
>> should
>> +be set to notify it that the next queued buffer should have a fence 
>> attached to
>> +it. That means the out-fence may not be associated with the buffer in the
>> +current ``VIDIOC_QBUF`` ioctl call because the ordering in which videobuf2 
>> core
>> +queues the buffers to the drivers can't be guaranteed. To become aware of 
>> the
>> +of the next queued buffer and the out-fence attached to it the
>> +``V4L2_EVENT_BUF_QUEUED`` event should be used. It will trigger an event
>> +for every buffer queued to the V4L2 driver.
> 
> This makes no sense.
> 
> Setting this flag means IMHO that when *this* buffer is queued up to the 
> driver,
> then it should send the BUF_QUEUED event with an out fence.
> 
> I.e. it signals that userspace wants to have the out-fence. The requirement 
> w.r.t.
> ordering is that the BUF_QUEUED events have to be in order, but that is 
> something
> that the driver can ensure in the case it is doing internal re-ordering.
> 
> This requirement is something that needs to be documented here, BTW.
> 
> Anyway, the flag shouldn't refer to some 'next buffer', since that's very 
> confusing.

Just ignore this comment. I assume v4 will implement it like this.

Regards,

Hans

> 
>> +
>> +At streamoff the out-fences will either signal normally if the drivers wait
> 
> s/drivers wait/driver waits/
> 
>> +for the operations on the buffers to finish or signal with error if the
>> +driver cancel the pending operations.
> 
> s/cancel/cancels/
> 
> Thinking with my evil hat on:
> 
> What happens if the application dequeues the buffer (VIDIOC_DQBUF) before
> dequeuing the BUF_QUEUED event? Or if the application doesn't call 
> VIDIOC_DQEVENT
> at all? Should any pending BUF_QUEUED event with an out fence be removed from 
> the
> event queue if the application calls DQBUF on the corresponding buffer?
> 
> Regards,
> 
>   Hans
> 
>>  
>>  Return Value
>>  
>>
> 

Re: [PATCH v3 02/15] [media] vb2: add explicit fence user API

[Hans Verkuil]

On 09/07/2017 08:42 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Turn the reserved2 field into fence_fd that we will use to send
> an in-fence to the kernel and return an out-fence from the kernel to
> userspace.
> 
> Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used
> when sending a fence to the kernel to be waited on, and
> V4L2_BUF_FLAG_OUT_FENCE, to ask the kernel to give back an out-fence.
> 
> v2: add documentation
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  Documentation/media/uapi/v4l/buffer.rst   | 19 +++
>  drivers/media/usb/cpia2/cpia2_v4l.c   |  2 +-
>  drivers/media/v4l2-core/v4l2-compat-ioctl32.c |  4 ++--
>  drivers/media/v4l2-core/videobuf2-v4l2.c  |  2 +-
>  include/uapi/linux/videodev2.h|  4 +++-
>  5 files changed, 26 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/media/uapi/v4l/buffer.rst 
> b/Documentation/media/uapi/v4l/buffer.rst
> index ae6ee73f151c..664507ad06c6 100644
> --- a/Documentation/media/uapi/v4l/buffer.rst
> +++ b/Documentation/media/uapi/v4l/buffer.rst
> @@ -648,6 +648,25 @@ Buffer Flags
>- Start Of Exposure. The buffer timestamp has been taken when the
>   exposure of the frame has begun. This is only valid for the
>   ``V4L2_BUF_TYPE_VIDEO_CAPTURE`` buffer type.
> +* .. _`V4L2-BUF-FLAG-IN-FENCE`:
> +
> +  - ``V4L2_BUF_FLAG_IN_FENCE``
> +  - 0x0020
> +  - Ask V4L2 to wait on fence passed in ``fence_fd`` field. The buffer
> + won't be queued to the driver until the fence signals.
> +
> +* .. _`V4L2-BUF-FLAG-OUT-FENCE`:
> +
> +  - ``V4L2_BUF_FLAG_OUT_FENCE``
> +  - 0x0040
> +  - Request a fence for the next buffer to be queued to V4L2 driver.
> + The fence received back through the ``fence_fd`` field  doesn't
> + necessarily relate to the current buffer in the
> + :ref:`VIDIOC_QBUF ` ioctl. Although, most of the time
> + the fence will relate to the current buffer it can't be guaranteed.
> + So to tell userspace which buffer is associated to the out_fence,
> + one should listen for the ``V4L2_EVENT_BUF_QUEUED`` event that
> + provide the id of the buffer when it is queued to the V4L2 driver.

As mentioned in the previous patch, this flag should just signal that userspace
wants to receive a BUF_QUEUED event with the out-fence for this buffer. It's up
to the driver to ensure the correct ordering of the events.

I'm missing documentation for the new fence_fd field.

It should mention that fence_fd is ignored if the IN_FENCE isn't set. 
Applications
will set fence_fd (aka reserved2) to 0, which should be fine as long as IN_FENCE
isn't set.

>  
>  
>  
> diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c 
> b/drivers/media/usb/cpia2/cpia2_v4l.c
> index 3dedd83f0b19..6cde686bf44c 100644
> --- a/drivers/media/usb/cpia2/cpia2_v4l.c
> +++ b/drivers/media/usb/cpia2/cpia2_v4l.c
> @@ -948,7 +948,7 @@ static int cpia2_dqbuf(struct file *file, void *fh, 
> struct v4l2_buffer *buf)
>   buf->sequence = cam->buffers[buf->index].seq;
>   buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
>   buf->length = cam->frame_size;
> - buf->reserved2 = 0;
> + buf->fence_fd = -1;
>   buf->reserved = 0;
>   memset(>timecode, 0, sizeof(buf->timecode));
>  
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index 821f2aa299ae..d624fb5df130 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -370,7 +370,7 @@ struct v4l2_buffer32 {
>   __s32   fd;
>   } m;
>   __u32   length;
> - __u32   reserved2;
> + __s32   fence_fd;
>   __u32   reserved;
>  };
>  
> @@ -533,8 +533,8 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, 
> struct v4l2_buffer32 __user
>   put_user(kp->timestamp.tv_usec, >timestamp.tv_usec) ||
>   copy_to_user(>timecode, >timecode, sizeof(struct 
> v4l2_timecode)) ||
>   put_user(kp->sequence, >sequence) ||
> - put_user(kp->reserved2, >reserved2) ||
>   put_user(kp->reserved, >reserved) ||
> + put_user(kp->fence_fd, >fence_fd) ||

Could you move this up one line? It's easier to parse this diff if it is clear
that fence_fd replaced reserved2.

>   put_user(kp->length, >length))
>   return -EFAULT;
>  
> diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> b/drivers/media/v4l2-core/videobuf2-v4l2.c
> index 0c0669976bdc..110fb45fef6f 100644
> --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> @@ -203,7 +203,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
> void *pb)
>   b->timestamp = 

Re: [PATCH v7] rockchip/rga: v4l2 m2m support

[Jacob Chen]

Hi Hans,

2017-08-25 20:09 GMT+08:00 Hans Verkuil :
> Hi Jacob,
>
> As promised, some more (small) review comments below.
>
> On 03/08/17 07:23, Jacob Chen wrote:
>> Rockchip RGA is a separate 2D raster graphic acceleration unit. It
>> accelerates 2D graphics operations, such as point/line drawing, image
>> scaling, rotation, BitBLT, alpha blending and image blur/sharpness
>>
>> The drvier is mostly based on s5p-g2d v4l2 m2m driver
>
> driver
>
>> And supports various operations from the rendering pipeline.
>>  - copy
>>  - fast solid color fill
>>  - rotation
>>  - flip
>>  - alpha blending
>>
>> The code in rga-hw.c is used to configure regs according to operations
>> The code in rga-buf.c is used to create private mmu table for RGA.
>>
>> changes in V7:
>> - fix some warning reported by "checkpatch --strict"
>>
>> Signed-off-by: Jacob Chen 
>> ---
>>  drivers/media/platform/Kconfig|   11 +
>>  drivers/media/platform/Makefile   |2 +
>>  drivers/media/platform/rockchip-rga/Makefile  |3 +
>>  drivers/media/platform/rockchip-rga/rga-buf.c |  155 
>>  drivers/media/platform/rockchip-rga/rga-hw.c  |  670 
>>  drivers/media/platform/rockchip-rga/rga-hw.h  |  437 +++
>>  drivers/media/platform/rockchip-rga/rga.c | 1026 
>> +
>>  drivers/media/platform/rockchip-rga/rga.h |  110 +++
>>  8 files changed, 2414 insertions(+)
>>  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
>>  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
>>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
>>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
>>  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
>>  create mode 100644 drivers/media/platform/rockchip-rga/rga.h
>>
>> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
>> index 041cb80a..d0d1a21 100644
>> --- a/drivers/media/platform/Kconfig
>> +++ b/drivers/media/platform/Kconfig
>> @@ -427,6 +427,17 @@ config VIDEO_RENESAS_VSP1
>> To compile this driver as a module, choose M here: the module
>> will be called vsp1.
>>
>> +config VIDEO_ROCKCHIP_RGA
>> + tristate "Rockchip Raster 2d Grapphic Acceleration Unit"
>> + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
>> + depends on ARCH_ROCKCHIP || COMPILE_TEST
>> + select VIDEOBUF2_DMA_SG
>> + select V4L2_MEM2MEM_DEV
>> + default n
>> + ---help---
>> +   This is a v4l2 driver for Rockchip SOC RGA2
>> +   2d graphics accelerator.
>> +
>>  config VIDEO_TI_VPE
>>   tristate "TI VPE (Video Processing Engine) driver"
>>   depends on VIDEO_DEV && VIDEO_V4L2
>> diff --git a/drivers/media/platform/Makefile 
>> b/drivers/media/platform/Makefile
>> index 63303d6..baf83060 100644
>> --- a/drivers/media/platform/Makefile
>> +++ b/drivers/media/platform/Makefile
>> @@ -57,6 +57,8 @@ obj-$(CONFIG_VIDEO_RENESAS_FDP1)+= rcar_fdp1.o
>>  obj-$(CONFIG_VIDEO_RENESAS_JPU)  += rcar_jpu.o
>>  obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/
>>
>> +obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga/
>> +
>>  obj-y+= omap/
>>
>>  obj-$(CONFIG_VIDEO_AM437X_VPFE)  += am437x/
>> diff --git a/drivers/media/platform/rockchip-rga/Makefile 
>> b/drivers/media/platform/rockchip-rga/Makefile
>> new file mode 100644
>> index 000..92fe254
>> --- /dev/null
>> +++ b/drivers/media/platform/rockchip-rga/Makefile
>> @@ -0,0 +1,3 @@
>> +rockchip-rga-objs := rga.o rga-hw.o rga-buf.o
>> +
>> +obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga.o
>> diff --git a/drivers/media/platform/rockchip-rga/rga-buf.c 
>> b/drivers/media/platform/rockchip-rga/rga-buf.c
>> new file mode 100644
>> index 000..6a9fd2c
>> --- /dev/null
>> +++ b/drivers/media/platform/rockchip-rga/rga-buf.c
>> @@ -0,0 +1,155 @@
>> +/*
>> + * Copyright (C) 2017 Fuzhou Rockchip Electronics Co.Ltd
>> + * Author: Jacob Chen 
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * 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 
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "rga-hw.h"
>> +#include "rga.h"
>> +
>> +static int
>> +rga_queue_setup(struct vb2_queue *vq,
>> + unsigned int *nbuffers, unsigned int *nplanes,
>> + unsigned int sizes[], struct device *alloc_devs[])
>> +{
>> + struct rga_ctx *ctx = vb2_get_drv_priv(vq);
>> + struct rga_frame *f = rga_get_frame(ctx, vq->type);
>> 

Re: [PATCH v3 01/15] [media] v4l: Document explicit synchronization behaviour

[Hans Verkuil]

On 09/07/2017 08:42 PM, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> Add section to VIDIOC_QBUF about it
> 
> v2:
>   - mention that fences are files (Hans)
>   - rework for the new API
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  Documentation/media/uapi/v4l/vidioc-qbuf.rst | 31 
> 
>  1 file changed, 31 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/vidioc-qbuf.rst 
> b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> index 1f3612637200..fae0b1431672 100644
> --- a/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-qbuf.rst
> @@ -117,6 +117,37 @@ immediately with an ``EAGAIN`` error code when no buffer 
> is available.
>  The struct :c:type:`v4l2_buffer` structure is specified in
>  :ref:`buffer`.
>  
> +Explicit Synchronization
> +
> +
> +Explicit Synchronization allows us to control the synchronization of
> +shared buffers from userspace by passing fences to the kernel and/or
> +receiving them from it. Fences passed to the kernel are named in-fences and
> +the kernel should wait them to signal before using the buffer, i.e., queueing

wait them -> wait on them

(do you wait 'on' a fence or 'for' a fence? I think it's 'on' but I'm not 100% 
sure)

> +it to the driver. On the other side, the kernel can create out-fences for the
> +buffers it queues to the drivers, out-fences signal when the driver is

Start a new sentence here: ...drivers. Out-fences...

> +finished with buffer, that is the buffer is ready. The fence are represented

s/that is/i.e/

s/The fence/The fences/

> +by file and passed as file descriptor to userspace.

s/by file/as a file/
s/as file/as a file/

> +
> +The in-fences are communicated to the kernel at the ``VIDIOC_QBUF`` ioctl
> +using the ``V4L2_BUF_FLAG_IN_FENCE`` buffer
> +flags and the `fence_fd` field. If an in-fence needs to be passed to the 
> kernel,
> +`fence_fd` should be set to the fence file descriptor number and the
> +``V4L2_BUF_FLAG_IN_FENCE`` should be set as well. Failure to set both will

s/Failure to set both/Setting one but not the other/

> +cause ``VIDIOC_QBUF`` to return with error.
> +
> +To get a out-fence back from V4L2 the ``V4L2_BUF_FLAG_OUT_FENCE`` flag should
> +be set to notify it that the next queued buffer should have a fence attached 
> to
> +it. That means the out-fence may not be associated with the buffer in the
> +current ``VIDIOC_QBUF`` ioctl call because the ordering in which videobuf2 
> core
> +queues the buffers to the drivers can't be guaranteed. To become aware of the
> +of the next queued buffer and the out-fence attached to it the
> +``V4L2_EVENT_BUF_QUEUED`` event should be used. It will trigger an event
> +for every buffer queued to the V4L2 driver.

This makes no sense.

Setting this flag means IMHO that when *this* buffer is queued up to the driver,
then it should send the BUF_QUEUED event with an out fence.

I.e. it signals that userspace wants to have the out-fence. The requirement 
w.r.t.
ordering is that the BUF_QUEUED events have to be in order, but that is 
something
that the driver can ensure in the case it is doing internal re-ordering.

This requirement is something that needs to be documented here, BTW.

Anyway, the flag shouldn't refer to some 'next buffer', since that's very 
confusing.

> +
> +At streamoff the out-fences will either signal normally if the drivers wait

s/drivers wait/driver waits/

> +for the operations on the buffers to finish or signal with error if the
> +driver cancel the pending operations.

s/cancel/cancels/

Thinking with my evil hat on:

What happens if the application dequeues the buffer (VIDIOC_DQBUF) before
dequeuing the BUF_QUEUED event? Or if the application doesn't call 
VIDIOC_DQEVENT
at all? Should any pending BUF_QUEUED event with an out fence be removed from 
the
event queue if the application calls DQBUF on the corresponding buffer?

Regards,

Hans

>  
>  Return Value
>  
> 

Re: [PATCH v8 0/4] Add Rockchip RGA V4l2 support

[Jacob Chen]

Hi Hans,

v4l2-compliance result:

v4l2-compliance SHA   : not available

Driver Info:
Driver name   : rockchip-rga
Card type : rockchip-rga
Bus info  : platform:rga
Driver version: 4.13.0
Capabilities  : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 7 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
fail: v4l2-test-formats.cpp(779):
fmt_cap.g_colorspace() != col
test VIDIOC_S_FMT: FAIL
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
fail: v4l2-test-formats.cpp(1273): doioctl(node,
VIDIOC_G_SELECTION, ) != EI
NVAL
test Cropping: OK (Not Supported)
fail: v4l2-test-formats.cpp(1273): doioctl(node,
VIDIOC_G_SELECTION, ) != EI
NVAL
test Composing: FAIL
test Scaling: OK

Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK

Test input 0:


Total: 43, Succeeded: 41, Failed: 2, Warnings: 0
root@linaro-alip:~#

[PATCH v8 1/4] rockchip/rga: v4l2 m2m support

[Jacob Chen]

Rockchip RGA is a separate 2D raster graphic acceleration unit. It
accelerates 2D graphics operations, such as point/line drawing, image
scaling, rotation, BitBLT, alpha blending and image blur/sharpness

The drvier is mostly based on s5p-g2d v4l2 m2m driver
And supports various operations from the rendering pipeline.
 - copy
 - fast solid color fill
 - rotation
 - flip

unsupported features:
 - alpha blending

The code in rga-hw.c is used to configure regs according to operations
The code in rga-buf.c is used to create private mmu table for RGA.

changes in V7:
- fix some warning reported by "checkpatch --strict"

Signed-off-by: Jacob Chen 
---
 drivers/media/platform/Kconfig|   11 +
 drivers/media/platform/Makefile   |2 +
 drivers/media/platform/rockchip-rga/Makefile  |3 +
 drivers/media/platform/rockchip-rga/rga-buf.c |  156 
 drivers/media/platform/rockchip-rga/rga-hw.c  |  435 +++
 drivers/media/platform/rockchip-rga/rga-hw.h  |  437 +++
 drivers/media/platform/rockchip-rga/rga.c | 1035 +
 drivers/media/platform/rockchip-rga/rga.h |  110 +++
 8 files changed, 2189 insertions(+)
 create mode 100644 drivers/media/platform/rockchip-rga/Makefile
 create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
 create mode 100644 drivers/media/platform/rockchip-rga/rga.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7e7cc49..9b79350 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -458,6 +458,17 @@ config VIDEO_RENESAS_VSP1
  To compile this driver as a module, choose M here: the module
  will be called vsp1.
 
+config VIDEO_ROCKCHIP_RGA
+   tristate "Rockchip Raster 2d Grapphic Acceleration Unit"
+   depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
+   depends on ARCH_ROCKCHIP || COMPILE_TEST
+   select VIDEOBUF2_DMA_SG
+   select V4L2_MEM2MEM_DEV
+   default n
+   ---help---
+ This is a v4l2 driver for Rockchip SOC RGA2
+ 2d graphics accelerator.
+
 config VIDEO_TI_VPE
tristate "TI VPE (Video Processing Engine) driver"
depends on VIDEO_DEV && VIDEO_V4L2
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c1ef946..06039c3 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -62,6 +62,8 @@ obj-$(CONFIG_VIDEO_RENESAS_FDP1)  += rcar_fdp1.o
 obj-$(CONFIG_VIDEO_RENESAS_JPU)+= rcar_jpu.o
 obj-$(CONFIG_VIDEO_RENESAS_VSP1)   += vsp1/
 
+obj-$(CONFIG_VIDEO_ROCKCHIP_RGA)   += rockchip-rga/
+
 obj-y  += omap/
 
 obj-$(CONFIG_VIDEO_AM437X_VPFE)+= am437x/
diff --git a/drivers/media/platform/rockchip-rga/Makefile 
b/drivers/media/platform/rockchip-rga/Makefile
new file mode 100644
index 000..92fe254
--- /dev/null
+++ b/drivers/media/platform/rockchip-rga/Makefile
@@ -0,0 +1,3 @@
+rockchip-rga-objs := rga.o rga-hw.o rga-buf.o
+
+obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip-rga.o
diff --git a/drivers/media/platform/rockchip-rga/rga-buf.c 
b/drivers/media/platform/rockchip-rga/rga-buf.c
new file mode 100644
index 000..373c36f
--- /dev/null
+++ b/drivers/media/platform/rockchip-rga/rga-buf.c
@@ -0,0 +1,156 @@
+/*
+ * Copyright (C) 2017 Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Jacob Chen 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rga-hw.h"
+#include "rga.h"
+
+static int
+rga_queue_setup(struct vb2_queue *vq,
+   unsigned int *nbuffers, unsigned int *nplanes,
+   unsigned int sizes[], struct device *alloc_devs[])
+{
+   struct rga_ctx *ctx = vb2_get_drv_priv(vq);
+   struct rga_frame *f = rga_get_frame(ctx, vq->type);
+
+   if (IS_ERR(f))
+   return PTR_ERR(f);
+
+   if (*nplanes)
+   return sizes[0] < f->size ? -EINVAL : 0;
+
+   sizes[0] = f->size;
+   *nplanes = 1;
+
+   return 0;
+}
+
+static int rga_buf_prepare(struct vb2_buffer *vb)
+{
+   struct rga_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
+   struct rga_frame *f = rga_get_frame(ctx, vb->vb2_queue->type);
+
+   if (IS_ERR(f))
+   return PTR_ERR(f);
+
+   vb2_set_plane_payload(vb, 

[PATCH v8 0/4] Add Rockchip RGA V4l2 support

[Jacob Chen]

This patch series add a v4l2 m2m drvier for rockchip RGA direct rendering based 
2d graphics acceleration module.

Recently I tried to add protduff support for gstreamer on rockchip platform, 
and i found that API 
were not very suitable for my purpose. 
It shouldn't go upstream until we can figure out what people need, 

change in V8:
- remove protduff things

change in V6,V7:
- correct warning in checkpatch.pl

change in V5:
- v4l2-compliance: handle invalid pxielformat 
- v4l2-compliance: add subscribe_event
- add colorspace support

change in V4:
- document the controls.
- change according to Hans's comments

change in V3:
- rename the controls.
- add pm_runtime support.
- enable node by default.
- correct spelling in documents.

change in V2:
- generalize the controls.
- map buffers (10-50 us) in every cmd-run rather than in buffer-import to avoid 
get_free_pages failed on
actively used systems.
- remove status in dt-bindings examples.


Jacob Chen (4):
  rockchip/rga: v4l2 m2m support
  ARM: dts: rockchip: add RGA device node for RK3288
  arm64: dts: rockchip: add RGA device node for RK3399
  dt-bindings: Document the Rockchip RGA bindings

 .../devicetree/bindings/media/rockchip-rga.txt |   33 +
 arch/arm/boot/dts/rk3288.dtsi  |   11 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   |   11 +
 drivers/media/platform/Kconfig |   11 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/rockchip-rga/Makefile   |3 +
 drivers/media/platform/rockchip-rga/rga-buf.c  |  156 +++
 drivers/media/platform/rockchip-rga/rga-hw.c   |  435 
 drivers/media/platform/rockchip-rga/rga-hw.h   |  437 +
 drivers/media/platform/rockchip-rga/rga.c  | 1035 
 drivers/media/platform/rockchip-rga/rga.h  |  110 +++
 11 files changed, 2244 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt
 create mode 100644 drivers/media/platform/rockchip-rga/Makefile
 create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
 create mode 100644 drivers/media/platform/rockchip-rga/rga.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga.h

-- 
2.7.4

[PATCH v8 2/4] ARM: dts: rockchip: add RGA device node for RK3288

[Jacob Chen]

This patch add the RGA dt config of rk3288 SoC.

Signed-off-by: Jacob Chen 
Signed-off-by: Yakir Yang 
---
 arch/arm/boot/dts/rk3288.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 595d395..ca6c63a 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -953,6 +953,17 @@
status = "okay";
};
 
+   rga: rga@ff92 {
+   compatible = "rockchip,rk3288-rga";
+   reg = <0xff92 0x180>;
+   interrupts = ;
+   clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA>;
+   clock-names = "aclk", "hclk", "sclk";
+   power-domains = < RK3288_PD_VIO>;
+   resets = < SRST_RGA_CORE>, < SRST_RGA_AXI>, < 
SRST_RGA_AHB>;
+   reset-names = "core", "axi", "ahb";
+   };
+
vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
reg = <0xff93 0x19c>;
-- 
2.7.4

[PATCH v8 3/4] arm64: dts: rockchip: add RGA device node for RK3399

[Jacob Chen]

This patch add the RGA dt config of RK3399 SoC.

Signed-off-by: Jacob Chen 
Signed-off-by: Yakir Yang 
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 5b78ce1..fa15770 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1153,6 +1153,17 @@
status = "disabled";
};
 
+   rga: rga@ff68 {
+   compatible = "rockchip,rk3399-rga";
+   reg = <0x0 0xff68 0x0 0x1>;
+   interrupts = ;
+   clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA_CORE>;
+   clock-names = "aclk", "hclk", "sclk";
+   resets = < SRST_RGA_CORE>, < SRST_A_RGA>, < 
SRST_H_RGA>;
+   reset-names = "core", "axi", "ahb";
+   power-domains = < RK3399_PD_RGA>;
+   };
+
efuse0: efuse@ff69 {
compatible = "rockchip,rk3399-efuse";
reg = <0x0 0xff69 0x0 0x80>;
-- 
2.7.4

[PATCH v8 4/4] dt-bindings: Document the Rockchip RGA bindings

[Jacob Chen]

Add DT bindings documentation for Rockchip RGA

Signed-off-by: Jacob Chen 
Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/media/rockchip-rga.txt | 33 ++
 1 file changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt

diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.txt 
b/Documentation/devicetree/bindings/media/rockchip-rga.txt
new file mode 100644
index 000..fd5276a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-rga.txt
@@ -0,0 +1,33 @@
+device-tree bindings for rockchip 2D raster graphic acceleration controller 
(RGA)
+
+RGA is a standalone 2D raster graphic acceleration unit. It accelerates 2D
+graphics operations, such as point/line drawing, image scaling, rotation,
+BitBLT, alpha blending and image blur/sharpness.
+
+Required properties:
+- compatible: value should be one of the following
+   "rockchip,rk3288-rga";
+   "rockchip,rk3399-rga";
+
+- interrupts: RGA interrupt specifier.
+
+- clocks: phandle to RGA sclk/hclk/aclk clocks
+
+- clock-names: should be "aclk", "hclk" and "sclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: should be "core", "axi" and "ahb"
+
+Example:
+SoC-specific DT entry:
+   rga: rga@ff68 {
+   compatible = "rockchip,rk3399-rga";
+   reg = <0xff68 0x1>;
+   interrupts = ;
+   clocks = < ACLK_RGA>, < HCLK_RGA>, < SCLK_RGA_CORE>;
+   clock-names = "aclk", "hclk", "sclk";
+
+   resets = < SRST_RGA_CORE>, < SRST_A_RGA>, < 
SRST_H_RGA>;
+   reset-names = "core, "axi", "ahb";
+   };
-- 
2.7.4

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

[Chris Wilson]

Quoting Christian König (2017-09-11 10:57:57)
> Am 11.09.2017 um 11:23 schrieb Chris Wilson:
> > Quoting Christian König (2017-09-11 10:06:50)
> >> Am 11.09.2017 um 10:59 schrieb Chris Wilson:
> >>> Quoting Christian König (2017-09-11 09:50:40)
>  Sorry for the delayed response, but your mail somehow ended up in the
>  Spam folder.
> 
>  Am 04.09.2017 um 15:40 schrieb Chris Wilson:
> > Quoting Christian König (2017-09-04 14:27:33)
> >> From: Christian König 
> >>
> >> The logic is buggy and unnecessary complex. When dma_fence_get_rcu() 
> >> fails to
> >> acquire a reference it doesn't necessary mean that there is no fence 
> >> at all.
> >>
> >> It usually mean that the fence was replaced by a new one and in this 
> >> situation
> >> we certainly want to have the new one as result and *NOT* NULL.
> > Which is not guaranteed by the code you wrote either.
> >
> > The point of the comment is that the mb is only inside the successful
> > kref_atomic_inc_unless_zero, and that only after that mb do you know
> > whether or not you have the current fence.
> >
> > You can argue that you want to replace the
> > if (!dma_fence_get_rcu())
> > return NULL
> > with
> > if (!dma_fence_get_rcu()
> > continue;
> > but it would be incorrect to say that by simply ignoring the
> > post-condition check that you do have the right fence.
>  You are completely missing the point here.
> 
>  It is irrelevant if you have the current fence or not when you return.
>  You can only guarantee that it is the current fence when you take a look
>  and that is exactly what we want to avoid.
> 
>  So the existing code is complete nonsense. Instead what we need to
>  guarantee is that we return *ANY* fence which we can grab a reference 
>  for.
> >>> Not quite. We can grab a reference on a fence that was already freed and
> >>> reused between the rcu_dereference() and dma_fence_get_rcu().
> >> Reusing a memory structure before the RCU grace period is completed is
> >> illegal, otherwise the whole RCU approach won't work.
> > RCU only protects that the pointer remains valid. If you use
> > SLAB_TYPESAFE_BY_RCU, it is possible to reuse the pointer within a grace
> > period. It does happen and that is the point the comment is trying to
> > make.
> 
> Yeah, but that is illegal with a fence objects.
> 
> When anybody allocates fences this way it breaks at least 
> reservation_object_get_fences_rcu(), 
> reservation_object_wait_timeout_rcu() and 
> reservation_object_test_signaled_single().

Many, many months ago I sent patches to fix them all.
-Chris

Re: [PATCH v10 17/24] v4l: fwnode: Add a helper function for parsing generic references

[Sakari Ailus]

Hi Hans,

Thanks for the review!

On Mon, Sep 11, 2017 at 11:14:03AM +0200, Hans Verkuil wrote:
> On 09/11/2017 10:00 AM, Sakari Ailus wrote:
> > Add function v4l2_fwnode_reference_count() for counting external
> > references and v4l2_fwnode_reference_parse() for parsing them as async
> > sub-devices.
> > 
> > This can be done on e.g. flash or lens async sub-devices that are not part
> > of but are associated with a sensor.
> > 
> > struct v4l2_async_notifier.max_subdevs field is added to contain the
> > maximum number of sub-devices in a notifier to reflect the memory
> > allocated for the subdevs array.
> 
> This paragraph appears to be out-of-date.

Will remove.

> 
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  drivers/media/v4l2-core/v4l2-fwnode.c | 47 
> > +++
> >  1 file changed, 47 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> > b/drivers/media/v4l2-core/v4l2-fwnode.c
> > index d978f2d714ca..4821c4989119 100644
> > --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> > +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> > @@ -449,6 +449,53 @@ int v4l2_async_notifier_parse_fwnode_endpoints(
> >  }
> >  EXPORT_SYMBOL_GPL(v4l2_async_notifier_parse_fwnode_endpoints);
> >  
> > +static int v4l2_fwnode_reference_parse(
> > +   struct device *dev, struct v4l2_async_notifier *notifier,
> > +   const char *prop)
> > +{
> > +   struct fwnode_reference_args args;
> > +   unsigned int index = 0;
> > +   int ret;
> > +
> > +   for (; !fwnode_property_get_reference_args(
> > +dev_fwnode(dev), prop, NULL, 0, index, ); index++)
> > +   fwnode_handle_put(args.fwnode);
> > +
> 
> If nothing is found (i.e. index == 0), shouldn't you just return here?

You could. yes. It would actually simplify the code, I could just return
-ENOENT here.

> 
> > +   ret = v4l2_async_notifier_realloc(notifier,
> > + notifier->num_subdevs + index);
> > +   if (ret)
> > +   return -ENOMEM;
> > +
> > +   for (ret = -ENOENT, index = 0;
> 
> There is no reason for the 'ret = -ENOENT' to be in the for(), just set it 
> before
> the 'for' statement.
> 
> > +!fwnode_property_get_reference_args(
> > +dev_fwnode(dev), prop, NULL, 0, index, );
> > +index++) {
> > +   struct v4l2_async_subdev *asd;
> > +
> > +   if (WARN_ON(notifier->num_subdevs >= notifier->max_subdevs)) {
> > +   ret = -EINVAL;
> > +   goto error;
> > +   }
> > +
> > +   asd = kzalloc(sizeof(*asd), GFP_KERNEL);
> > +   if (!asd) {
> > +   ret = -ENOMEM;
> > +   goto error;
> > +   }
> > +
> > +   notifier->subdevs[notifier->num_subdevs] = asd;
> > +   asd->match.fwnode.fwnode = args.fwnode;
> > +   asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
> > +   notifier->num_subdevs++;
> > +   }
> 
> If the loop doesn't find anything, then it still returns 0, not -ENOENT.
> So why set ret to ENOENT? Something weird going on here.

:-)

I think -ENOENT would make sense indeed if there are no entries found.

> 
> I think you should also add a comment explaining this function.

Yes. I had that in the header when it was exported, I'll add the same
comments here.

> 
> > +
> > +   return 0;
> > +
> > +error:
> > +   fwnode_handle_put(args.fwnode);
> > +   return ret;
> > +}
> > +
> >  MODULE_LICENSE("GPL");
> >  MODULE_AUTHOR("Sakari Ailus ");
> >  MODULE_AUTHOR("Sylwester Nawrocki ");
> > 
> 

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

[Christian König]

Am 11.09.2017 um 11:23 schrieb Chris Wilson:

Quoting Christian König (2017-09-11 10:06:50)

Am 11.09.2017 um 10:59 schrieb Chris Wilson:

Quoting Christian König (2017-09-11 09:50:40)

Sorry for the delayed response, but your mail somehow ended up in the
Spam folder.

Am 04.09.2017 um 15:40 schrieb Chris Wilson:

Quoting Christian König (2017-09-04 14:27:33)

From: Christian König 

The logic is buggy and unnecessary complex. When dma_fence_get_rcu() fails to
acquire a reference it doesn't necessary mean that there is no fence at all.

It usually mean that the fence was replaced by a new one and in this situation
we certainly want to have the new one as result and *NOT* NULL.

Which is not guaranteed by the code you wrote either.

The point of the comment is that the mb is only inside the successful
kref_atomic_inc_unless_zero, and that only after that mb do you know
whether or not you have the current fence.

You can argue that you want to replace the
if (!dma_fence_get_rcu())
return NULL
with
if (!dma_fence_get_rcu()
continue;
but it would be incorrect to say that by simply ignoring the
post-condition check that you do have the right fence.

You are completely missing the point here.

It is irrelevant if you have the current fence or not when you return.
You can only guarantee that it is the current fence when you take a look
and that is exactly what we want to avoid.

So the existing code is complete nonsense. Instead what we need to
guarantee is that we return *ANY* fence which we can grab a reference for.

Not quite. We can grab a reference on a fence that was already freed and
reused between the rcu_dereference() and dma_fence_get_rcu().

Reusing a memory structure before the RCU grace period is completed is
illegal, otherwise the whole RCU approach won't work.

RCU only protects that the pointer remains valid. If you use
SLAB_TYPESAFE_BY_RCU, it is possible to reuse the pointer within a grace
period. It does happen and that is the point the comment is trying to
make.


Yeah, but that is illegal with a fence objects.

When anybody allocates fences this way it breaks at least 
reservation_object_get_fences_rcu(), 
reservation_object_wait_timeout_rcu() and 
reservation_object_test_signaled_single().


Cause all of them rely on dma_fence_get() to return NULL when the fence 
isn't valid any more to restart the operation.


When dma_fence_get_rcu() returns a reallocated fence the operation 
wouldn't correctly restart and the end result most likely not be correct 
at all.


Using SLAB_TYPESAFE_BY_RCU is only valid if you can ensure that you have 
the right object using a second criteria and that is not the case with 
fences.


Regards,
Christian.

Re: [PATCH v10 24/24] arm: dts: omap3: N9/N950: Add flash references to the camera

[Hans Verkuil]

On 09/11/2017 10:00 AM, Sakari Ailus wrote:
> Add flash and indicator LED phandles to the sensor node.
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

Regards,

Hans


> ---
>  arch/arm/boot/dts/omap3-n9.dts   | 1 +
>  arch/arm/boot/dts/omap3-n950-n9.dtsi | 4 ++--
>  arch/arm/boot/dts/omap3-n950.dts | 1 +
>  3 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
> index b9e58c536afd..39e35f8b8206 100644
> --- a/arch/arm/boot/dts/omap3-n9.dts
> +++ b/arch/arm/boot/dts/omap3-n9.dts
> @@ -26,6 +26,7 @@
>   clocks = < 0>;
>   clock-frequency = <960>;
>   nokia,nvm-size = <(16 * 64)>;
> + flash-leds = <_flash _indicator>;
>   port {
>   smia_1_1: endpoint {
>   link-frequencies = /bits/ 64 <19920 
> 21000 49920>;
> diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi 
> b/arch/arm/boot/dts/omap3-n950-n9.dtsi
> index 1b0bd72945f2..12fbb3da5fce 100644
> --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
> +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
> @@ -271,14 +271,14 @@
>   #size-cells = <0>;
>   reg = <0x30>;
>   compatible = "ams,as3645a";
> - flash@0 {
> + as3645a_flash: flash@0 {
>   reg = <0x0>;
>   flash-timeout-us = <15>;
>   flash-max-microamp = <32>;
>   led-max-microamp = <6>;
>   ams,input-max-microamp = <175>;
>   };
> - indicator@1 {
> + as3645a_indicator: indicator@1 {
>   reg = <0x1>;
>   led-max-microamp = <1>;
>   };
> diff --git a/arch/arm/boot/dts/omap3-n950.dts 
> b/arch/arm/boot/dts/omap3-n950.dts
> index 646601a3ebd8..c354a1ed1e70 100644
> --- a/arch/arm/boot/dts/omap3-n950.dts
> +++ b/arch/arm/boot/dts/omap3-n950.dts
> @@ -60,6 +60,7 @@
>   clocks = < 0>;
>   clock-frequency = <960>;
>   nokia,nvm-size = <(16 * 64)>;
> + flash-leds = <_flash _indicator>;
>   port {
>   smia_1_1: endpoint {
>   link-frequencies = /bits/ 64 <21000 
> 33360 39840>;
> 

Re: [PATCH v10 23/24] ov13858: Add support for flash and lens devices

[Hans Verkuil]

On 09/11/2017 10:00 AM, Sakari Ailus wrote:
> Parse async sub-devices by using
> v4l2_subdev_fwnode_reference_parse_sensor_common().
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

Regards,

Hans


> ---
>  drivers/media/i2c/ov13858.c | 26 +++---
>  1 file changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c
> index af7af0d14c69..0d60defc7492 100644
> --- a/drivers/media/i2c/ov13858.c
> +++ b/drivers/media/i2c/ov13858.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define OV13858_REG_VALUE_08BIT  1
>  #define OV13858_REG_VALUE_16BIT  2
> @@ -1028,6 +1029,7 @@ static const struct ov13858_mode supported_modes[] = {
>  struct ov13858 {
>   struct v4l2_subdev sd;
>   struct media_pad pad;
> + struct v4l2_async_notifier notifier;
>  
>   struct v4l2_ctrl_handler ctrl_handler;
>   /* V4L2 Controls */
> @@ -1715,6 +1717,11 @@ static int ov13858_probe(struct i2c_client *client,
>   if (!ov13858)
>   return -ENOMEM;
>  
> + ret = v4l2_fwnode_reference_parse_sensor_common(
> + >dev, >notifier);
> + if (ret < 0)
> + return ret;
> +
>   /* Initialize subdev */
>   v4l2_i2c_subdev_init(>sd, client, _subdev_ops);
>  
> @@ -1722,7 +1729,7 @@ static int ov13858_probe(struct i2c_client *client,
>   ret = ov13858_identify_module(ov13858);
>   if (ret) {
>   dev_err(>dev, "failed to find sensor: %d\n", ret);
> - return ret;
> + goto error_notifier_release;
>   }
>  
>   /* Set default mode to max resolution */
> @@ -1730,7 +1737,7 @@ static int ov13858_probe(struct i2c_client *client,
>  
>   ret = ov13858_init_controls(ov13858);
>   if (ret)
> - return ret;
> + goto error_notifier_release;
>  
>   /* Initialize subdev */
>   ov13858->sd.internal_ops = _internal_ops;
> @@ -1746,9 +1753,14 @@ static int ov13858_probe(struct i2c_client *client,
>   goto error_handler_free;
>   }
>  
> + ret = v4l2_async_subdev_notifier_register(>sd,
> +   >notifier);
> + if (ret)
> + goto error_media_entity;
> +
>   ret = v4l2_async_register_subdev(>sd);
>   if (ret < 0)
> - goto error_media_entity;
> + goto error_notifier_unregister;
>  
>   /*
>* Device is already turned on by i2c-core with ACPI domain PM.
> @@ -1761,11 +1773,17 @@ static int ov13858_probe(struct i2c_client *client,
>  
>   return 0;
>  
> +error_notifier_unregister:
> + v4l2_async_notifier_unregister(>notifier);
> +
>  error_media_entity:
>   media_entity_cleanup(>sd.entity);
>  
>  error_handler_free:
>   ov13858_free_controls(ov13858);
> +
> +error_notifier_release:
> + v4l2_async_notifier_release(>notifier);
>   dev_err(>dev, "%s failed:%d\n", __func__, ret);
>  
>   return ret;
> @@ -1777,6 +1795,8 @@ static int ov13858_remove(struct i2c_client *client)
>   struct ov13858 *ov13858 = to_ov13858(sd);
>  
>   v4l2_async_unregister_subdev(sd);
> + v4l2_async_notifier_unregister(>notifier);
> + v4l2_async_notifier_release(>notifier);
>   media_entity_cleanup(>entity);
>   ov13858_free_controls(ov13858);
>  
> 

Re: [PATCH v10 22/24] ov5670: Add support for flash and lens devices

[Hans Verkuil]

On 09/11/2017 10:00 AM, Sakari Ailus wrote:
> Parse async sub-devices by using
> v4l2_subdev_fwnode_reference_parse_sensor_common().
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

Regards,

Hans


> ---
>  drivers/media/i2c/ov5670.c | 33 +
>  1 file changed, 25 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/i2c/ov5670.c b/drivers/media/i2c/ov5670.c
> index 6f7a1d6d2200..25970307dd75 100644
> --- a/drivers/media/i2c/ov5670.c
> +++ b/drivers/media/i2c/ov5670.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define OV5670_REG_CHIP_ID   0x300a
>  #define OV5670_CHIP_ID   0x005670
> @@ -1807,6 +1808,7 @@ static const struct ov5670_mode supported_modes[] = {
>  struct ov5670 {
>   struct v4l2_subdev sd;
>   struct media_pad pad;
> + struct v4l2_async_notifier notifier;
>  
>   struct v4l2_ctrl_handler ctrl_handler;
>   /* V4L2 Controls */
> @@ -2473,11 +2475,13 @@ static int ov5670_probe(struct i2c_client *client)
>   return -EINVAL;
>  
>   ov5670 = devm_kzalloc(>dev, sizeof(*ov5670), GFP_KERNEL);
> - if (!ov5670) {
> - ret = -ENOMEM;
> - err_msg = "devm_kzalloc() error";
> - goto error_print;
> - }
> + if (!ov5670)
> + return -ENOMEM;
> +
> + ret = v4l2_fwnode_reference_parse_sensor_common(
> + >dev, >notifier);
> + if (ret < 0)
> + return ret;
>  
>   /* Initialize subdev */
>   v4l2_i2c_subdev_init(>sd, client, _subdev_ops);
> @@ -2486,7 +2490,7 @@ static int ov5670_probe(struct i2c_client *client)
>   ret = ov5670_identify_module(ov5670);
>   if (ret) {
>   err_msg = "ov5670_identify_module() error";
> - goto error_print;
> + goto error_release_notifier;
>   }
>  
>   mutex_init(>mutex);
> @@ -2513,11 +2517,18 @@ static int ov5670_probe(struct i2c_client *client)
>   goto error_handler_free;
>   }
>  
> + ret = v4l2_async_subdev_notifier_register(>sd,
> +   >notifier);
> + if (ret) {
> + err_msg = "can't register async notifier";
> + goto error_entity_cleanup;
> + }
> +
>   /* Async register for subdev */
>   ret = v4l2_async_register_subdev(>sd);
>   if (ret < 0) {
>   err_msg = "v4l2_async_register_subdev() error";
> - goto error_entity_cleanup;
> + goto error_unregister_notifier;
>   }
>  
>   ov5670->streaming = false;
> @@ -2533,6 +2544,9 @@ static int ov5670_probe(struct i2c_client *client)
>  
>   return 0;
>  
> +error_unregister_notifier:
> + v4l2_async_notifier_unregister(>notifier);
> +
>  error_entity_cleanup:
>   media_entity_cleanup(>sd.entity);
>  
> @@ -2542,7 +2556,8 @@ static int ov5670_probe(struct i2c_client *client)
>  error_mutex_destroy:
>   mutex_destroy(>mutex);
>  
> -error_print:
> +error_release_notifier:
> + v4l2_async_notifier_release(>notifier);
>   dev_err(>dev, "%s: %s %d\n", __func__, err_msg, ret);
>  
>   return ret;
> @@ -2554,6 +2569,8 @@ static int ov5670_remove(struct i2c_client *client)
>   struct ov5670 *ov5670 = to_ov5670(sd);
>  
>   v4l2_async_unregister_subdev(sd);
> + v4l2_async_notifier_unregister(>notifier);
> + v4l2_async_notifier_release(>notifier);
>   media_entity_cleanup(>entity);
>   v4l2_ctrl_handler_free(sd->ctrl_handler);
>   mutex_destroy(>mutex);
> 

Re: [PATCH v10 21/24] smiapp: Add support for flash and lens devices

[Hans Verkuil]

On 09/11/2017 10:00 AM, Sakari Ailus wrote:
> Parse async sub-devices by using
> v4l2_subdev_fwnode_reference_parse_sensor_common().
> 
> These types devices aren't directly related to the sensor, but are
> nevertheless handled by the smiapp driver due to the relationship of these
> component to the main part of the camera module --- the sensor.
> 
> This does not yet address providing the user space with information on how
> to associate the sensor or lens devices but the kernel now has the
> necessary information to do that.
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  drivers/media/i2c/smiapp/smiapp-core.c | 38 
> +++---
>  drivers/media/i2c/smiapp/smiapp.h  |  4 +++-
>  2 files changed, 33 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/i2c/smiapp/smiapp-core.c 
> b/drivers/media/i2c/smiapp/smiapp-core.c
> index 700f433261d0..a65a839135d2 100644
> --- a/drivers/media/i2c/smiapp/smiapp-core.c
> +++ b/drivers/media/i2c/smiapp/smiapp-core.c
> @@ -31,7 +31,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  
> @@ -2887,17 +2887,24 @@ static int smiapp_probe(struct i2c_client *client,
>   v4l2_i2c_subdev_init(>src->sd, client, _ops);
>   sensor->src->sd.internal_ops = _internal_src_ops;
>  
> + rval = v4l2_fwnode_reference_parse_sensor_common(
> + >dev, >notifier);
> + if (rval < 0)
> + return rval;
> +
>   sensor->vana = devm_regulator_get(>dev, "vana");
>   if (IS_ERR(sensor->vana)) {
>   dev_err(>dev, "could not get regulator for vana\n");
> - return PTR_ERR(sensor->vana);
> + rval = PTR_ERR(sensor->vana);
> + goto out_release_async_notifier;
>   }
>  
>   sensor->ext_clk = devm_clk_get(>dev, NULL);
>   if (IS_ERR(sensor->ext_clk)) {
>   dev_err(>dev, "could not get clock (%ld)\n",
>   PTR_ERR(sensor->ext_clk));
> - return -EPROBE_DEFER;
> + rval = -EPROBE_DEFER;
> + goto out_release_async_notifier;
>   }
>  
>   rval = clk_set_rate(sensor->ext_clk, sensor->hwcfg->ext_clk);
> @@ -2905,17 +2912,19 @@ static int smiapp_probe(struct i2c_client *client,
>   dev_err(>dev,
>   "unable to set clock freq to %u\n",
>   sensor->hwcfg->ext_clk);
> - return rval;
> + goto out_release_async_notifier;
>   }
>  
>   sensor->xshutdown = devm_gpiod_get_optional(>dev, "xshutdown",
>   GPIOD_OUT_LOW);
> - if (IS_ERR(sensor->xshutdown))
> - return PTR_ERR(sensor->xshutdown);
> + if (IS_ERR(sensor->xshutdown)) {
> + rval = PTR_ERR(sensor->xshutdown);
> + goto out_release_async_notifier;
> + }
>  
>   rval = smiapp_power_on(>dev);
>   if (rval < 0)
> - return rval;
> + goto out_release_async_notifier;
>  
>   rval = smiapp_identify_module(sensor);
>   if (rval) {
> @@ -3092,9 +3101,14 @@ static int smiapp_probe(struct i2c_client *client,
>   if (rval < 0)
>   goto out_media_entity_cleanup;
>  
> + rval = v4l2_async_subdev_notifier_register(>src->sd,
> +>notifier);
> + if (rval)
> + goto out_media_entity_cleanup;
> +
>   rval = v4l2_async_register_subdev(>src->sd);
>   if (rval < 0)
> - goto out_media_entity_cleanup;
> + goto out_unregister_async_notifier;
>  
>   pm_runtime_set_active(>dev);
>   pm_runtime_get_noresume(>dev);
> @@ -3105,6 +3119,9 @@ static int smiapp_probe(struct i2c_client *client,
>  
>   return 0;
>  
> +out_unregister_async_notifier:
> + v4l2_async_notifier_unregister(>notifier);
> +
>  out_media_entity_cleanup:
>   media_entity_cleanup(>src->sd.entity);
>  
> @@ -3114,6 +3131,9 @@ static int smiapp_probe(struct i2c_client *client,
>  out_power_off:
>   smiapp_power_off(>dev);
>  
> +out_release_async_notifier:
> + v4l2_async_notifier_release(>notifier);
> +
>   return rval;
>  }
>  
> @@ -3124,6 +3144,8 @@ static int smiapp_remove(struct i2c_client *client)
>   unsigned int i;
>  
>   v4l2_async_unregister_subdev(subdev);
> + v4l2_async_notifier_unregister(>notifier);
> + v4l2_async_notifier_release(>notifier);
>  
>   pm_runtime_disable(>dev);
>   if (!pm_runtime_status_suspended(>dev))
> diff --git a/drivers/media/i2c/smiapp/smiapp.h 
> b/drivers/media/i2c/smiapp/smiapp.h
> index f74d695018b9..be92cb5713f4 100644
> --- a/drivers/media/i2c/smiapp/smiapp.h
> +++ b/drivers/media/i2c/smiapp/smiapp.h
> @@ -20,9 +20,10 @@
>  #define __SMIAPP_PRIV_H_
>  
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
> -#include 
>  
>  #include 

Re: [PATCH v10 19/24] v4l: fwnode: Add convenience function for parsing common external refs

[Hans Verkuil]

On 09/11/2017 10:00 AM, Sakari Ailus wrote:
> Add v4l2_fwnode_parse_reference_sensor_common for parsing common
> sensor properties that refer to adjacent devices such as flash or lens
> driver chips.
> 
> As this is an association only, there's little a regular driver needs to
> know about these devices as such.
> 
> Signed-off-by: Sakari Ailus 
> Acked-by: Hans Verkuil 
> ---
>  drivers/media/v4l2-core/v4l2-fwnode.c | 35 
> +++
>  include/media/v4l2-fwnode.h   | 13 +
>  2 files changed, 48 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> b/drivers/media/v4l2-core/v4l2-fwnode.c
> index 56eee5bbd3b5..b9e60a0e8f86 100644
> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> @@ -589,6 +589,41 @@ static int v4l2_fwnode_reference_parse_int_props(
>   return ret;
>  }
>  
> +int v4l2_fwnode_reference_parse_sensor_common(
> + struct device *dev, struct v4l2_async_notifier *notifier)
> +{
> + static const char *led_props[] = { "led" };
> + static const struct {
> + const char *name;
> + const char **props;
> + unsigned int nprops;
> + } props[] = {
> + { "flash-leds", led_props, ARRAY_SIZE(led_props) },
> + { "lens-focus", NULL, 0 },
> + };
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(props); i++) {
> + int ret;
> +
> + if (props[i].props && is_acpi_node(dev_fwnode(dev)))
> + ret = v4l2_fwnode_reference_parse_int_props(
> + dev, notifier, props[i].name,
> + props[i].props, props[i].nprops);
> + else
> + ret = v4l2_fwnode_reference_parse(
> + dev, notifier, props[i].name);
> + if (ret) {
> + dev_warn(dev, "parsing property \"%s\" failed (%d)\n",
> +  props[i].name, ret);
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_fwnode_reference_parse_sensor_common);
> +
>  MODULE_LICENSE("GPL");
>  MODULE_AUTHOR("Sakari Ailus ");
>  MODULE_AUTHOR("Sylwester Nawrocki ");
> diff --git a/include/media/v4l2-fwnode.h b/include/media/v4l2-fwnode.h
> index 3819a73c3c8a..bcec1ce101dc 100644
> --- a/include/media/v4l2-fwnode.h
> +++ b/include/media/v4l2-fwnode.h
> @@ -257,4 +257,17 @@ int v4l2_async_notifier_parse_fwnode_endpoints(
> struct v4l2_fwnode_endpoint *vep,
> struct v4l2_async_subdev *asd));
>  
> +/**
> + * v4l2_fwnode_reference_parse_sensor_common - parse common references on
> + *  sensors for async sub-devices
> + * @dev: the device node the properties of which are parsed for references
> + * @notifier: the async notifier where the async subdevs will be added
> + *

I think you should add a note that if this function returns 0 the
caller should remember to call v4l2_async_notifier_release. That is not
immediately obvious.

Regards,

Hans

> + * Return: 0 on success
> + *  -ENOMEM if memory allocation failed
> + *  -EINVAL if property parsing failed
> + */
> +int v4l2_fwnode_reference_parse_sensor_common(
> + struct device *dev, struct v4l2_async_notifier *notifier);
> +
>  #endif /* _V4L2_FWNODE_H */
> 

Re: [PATCH v10 20/24] dt: bindings: smiapp: Document lens-focus and flash properties

[Hans Verkuil]

On 09/11/2017 10:00 AM, Sakari Ailus wrote:
> Document optional lens-focus and flash properties for the smiapp driver.
> 
> Signed-off-by: Sakari Ailus 

Acked-by: Hans Verkuil 

Regards,

Hans

> ---
>  Documentation/devicetree/bindings/media/i2c/nokia,smia.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt 
> b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
> index 855e1faf73e2..33f10a94c381 100644
> --- a/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
> @@ -27,6 +27,8 @@ Optional properties
>  - nokia,nvm-size: The size of the NVM, in bytes. If the size is not given,
>the NVM contents will not be read.
>  - reset-gpios: XSHUTDOWN GPIO
> +- flash-leds: See ../video-interfaces.txt
> +- lens-focus: See ../video-interfaces.txt
>  
>  
>  Endpoint node mandatory properties
> 

Re: [PATCH v10 18/24] v4l: fwnode: Add a helper function to obtain device / interger references

[Hans Verkuil]

Typo in subject: interger -> integer

On 09/11/2017 10:00 AM, Sakari Ailus wrote:
> v4l2_fwnode_reference_parse_int_prop() will find an fwnode such that under
> the device's own fwnode, 

Sorry, you lost me here. Which device are we talking about?

> it will follow child fwnodes with the given
> property -- value pair and return the resulting fwnode.

property-value pair (easier readable that way).

You only describe v4l2_fwnode_reference_parse_int_prop(), not
v4l2_fwnode_reference_parse_int_props().

> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/v4l2-core/v4l2-fwnode.c | 93 
> +++
>  1 file changed, 93 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> b/drivers/media/v4l2-core/v4l2-fwnode.c
> index 4821c4989119..56eee5bbd3b5 100644
> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> @@ -496,6 +496,99 @@ static int v4l2_fwnode_reference_parse(
>   return ret;
>  }
>  
> +static struct fwnode_handle *v4l2_fwnode_reference_get_int_prop(
> + struct fwnode_handle *fwnode, const char *prop, unsigned int index,
> + const char **props, unsigned int nprops)

Need comments describing what this does.

> +{
> + struct fwnode_reference_args fwnode_args;
> + unsigned int *args = fwnode_args.args;
> + struct fwnode_handle *child;
> + int ret;
> +
> + ret = fwnode_property_get_reference_args(fwnode, prop, NULL, nprops,
> +  index, _args);
> + if (ret)
> + return ERR_PTR(ret == -EINVAL ? -ENOENT : ret);

Why map EINVAL to ENOENT? Needs a comment, either here or in the function 
description.

> +
> + for (fwnode = fwnode_args.fwnode;
> +  nprops; nprops--, fwnode = child, props++, args++) {

I think you cram too much in this for-loop: fwnode, nprops, fwnode, props, 
args...
It's hard to parse.

I would make this a 'while (nprops)' and write out all the other assignments,
increments and decrements.

> + u32 val;
> +
> + fwnode_for_each_child_node(fwnode, child) {
> + if (fwnode_property_read_u32(child, *props, ))
> + continue;
> +
> + if (val == *args)
> + break;

I'm lost. This really needs comments and perhaps even an DT or ACPI example
so you can see what exactly it is we're doing here.

> + }
> +
> + fwnode_handle_put(fwnode);
> +
> + if (!child) {
> + fwnode = ERR_PTR(-ENOENT);
> + break;
> + }
> + }
> +
> + return fwnode;
> +}
> +
> +static int v4l2_fwnode_reference_parse_int_props(
> + struct device *dev, struct v4l2_async_notifier *notifier,
> + const char *prop, const char **props, unsigned int nprops)

Needs comments describing what this does.

> +{
> + struct fwnode_handle *fwnode;
> + unsigned int index = 0;
> + int ret;
> +
> + while (!IS_ERR((fwnode = v4l2_fwnode_reference_get_int_prop(
> + dev_fwnode(dev), prop, index, props,
> + nprops {
> + fwnode_handle_put(fwnode);
> + index++;
> + }
> +
> + if (PTR_ERR(fwnode) != -ENOENT)
> + return PTR_ERR(fwnode);

Missing 'if (index == 0)'?

> +
> + ret = v4l2_async_notifier_realloc(notifier,
> +   notifier->num_subdevs + index);
> + if (ret)
> + return -ENOMEM;
> +
> + for (index = 0; !IS_ERR((fwnode = v4l2_fwnode_reference_get_int_prop(
> +  dev_fwnode(dev), prop, index, props,
> +  nprops))); ) {

I'd add 'index++' in this for-loop. It's weird that it is missing.

> + struct v4l2_async_subdev *asd;
> +
> + if (WARN_ON(notifier->num_subdevs >= notifier->max_subdevs)) {
> + ret = -EINVAL;
> + goto error;
> + }
> +
> + asd = kzalloc(sizeof(struct v4l2_async_subdev), GFP_KERNEL);
> + if (!asd) {
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + notifier->subdevs[notifier->num_subdevs] = asd;
> + asd->match.fwnode.fwnode = fwnode;
> + asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
> + notifier->num_subdevs++;
> +
> + fwnode_handle_put(fwnode);
> +
> + index++;
> + }
> +
> + return PTR_ERR(fwnode) == -ENOENT ? 0 : PTR_ERR(fwnode);
> +
> +error:
> + fwnode_handle_put(fwnode);
> + return ret;
> +}
> +
>  MODULE_LICENSE("GPL");
>  MODULE_AUTHOR("Sakari Ailus ");
>  MODULE_AUTHOR("Sylwester Nawrocki ");
> 

Regards,

Hans

Re: [PATCH v3 4/6] [media] exynos-gsc: Add hardware rotation limits

[Sylwester Nawrocki]

On 09/08/2017 08:02 AM, Hoegeun Kwon wrote:

The hardware rotation limits of gsc depends on SOC (Exynos
5250/5420/5433). Distinguish them and add them to the driver data.

Signed-off-by: Hoegeun Kwon 
---
  drivers/media/platform/exynos-gsc/gsc-core.c | 96 
  1 file changed, 83 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/exynos-gsc/gsc-core.c 
b/drivers/media/platform/exynos-gsc/gsc-core.c
index 4380150..8f8636e 100644
--- a/drivers/media/platform/exynos-gsc/gsc-core.c
+++ b/drivers/media/platform/exynos-gsc/gsc-core.c
@@ -943,7 +943,37 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
return IRQ_HANDLED;
  }
  
-static struct gsc_pix_max gsc_v_100_max = {

+static struct gsc_pix_max gsc_v_5250_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2016,
+   .real_rot_en_h  = 2016,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5420_max = {
+   .org_scaler_bypass_w= 8192,
+   .org_scaler_bypass_h= 8192,
+   .org_scaler_input_w = 4800,
+   .org_scaler_input_h = 3344,
+   .real_rot_dis_w = 4800,
+   .real_rot_dis_h = 3344,
+   .real_rot_en_w  = 2048,
+   .real_rot_en_h  = 2048,
+   .target_rot_dis_w   = 4800,
+   .target_rot_dis_h   = 3344,
+   .target_rot_en_w= 2016,
+   .target_rot_en_h= 2016,
+};
+
+static struct gsc_pix_max gsc_v_5433_max = {
.org_scaler_bypass_w= 8192,
.org_scaler_bypass_h= 8192,
.org_scaler_input_w = 4800,
@@ -979,8 +1009,8 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.target_h   = 2,  /* yuv420 : 2, others : 1 */
  };
  
-static struct gsc_variant gsc_v_100_variant = {

-   .pix_max= _v_100_max,
+static struct gsc_variant gsc_v_5250_variant = {
+   .pix_max= _v_5250_max,
.pix_min= _v_100_min,
.pix_align  = _v_100_align,
.in_buf_cnt = 32,
@@ -992,12 +1022,48 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
.local_sc_down  = 2,
  };
  
-static struct gsc_driverdata gsc_v_100_drvdata = {

+static struct gsc_variant gsc_v_5420_variant = {
+   .pix_max= _v_5420_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_variant gsc_v_5433_variant = {
+   .pix_max= _v_5433_max,
+   .pix_min= _v_100_min,
+   .pix_align  = _v_100_align,
+   .in_buf_cnt = 32,
+   .out_buf_cnt= 32,
+   .sc_up_max  = 8,
+   .sc_down_max= 16,
+   .poly_sc_down_max   = 4,
+   .pre_sc_down_max= 4,
+   .local_sc_down  = 2,
+};
+
+static struct gsc_driverdata gsc_v_5250_drvdata = {
.variant = {
-   [0] = _v_100_variant,
-   [1] = _v_100_variant,
-   [2] = _v_100_variant,
-   [3] = _v_100_variant,
+   [0] = _v_5250_variant,
+   [1] = _v_5250_variant,
+   [2] = _v_5250_variant,
+   [3] = _v_5250_variant,
+   },
+   .num_entities = 4,
+   .clk_names = { "gscl" },
+   .num_clocks = 1,
+};
+
+static struct gsc_driverdata gsc_v_5420_drvdata = {
+   .variant = {
+   [0] = _v_5420_variant,
+   [1] = _v_5420_variant,
},
.num_entities = 4,
.clk_names = { "gscl" },
@@ -1006,9 +1072,9 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
  
  static struct gsc_driverdata gsc_5433_drvdata = {

.variant = {
-   [0] = _v_100_variant,
-   [1] = _v_100_variant,
-   [2] = _v_100_variant,
+   [0] = _v_5433_variant,
+   [1] = _v_5433_variant,
+   [2] = _v_5433_variant,
},
.num_entities = 3,
.clk_names = { "pclk", "aclk", "aclk_xiu", "aclk_gsclbend" },
@@ -1017,8 +1083,12 @@ static irqreturn_t gsc_irq_handler(int irq, void *priv)
  
  static const struct of_device_id exynos_gsc_match[] = {

{
-   .compatible = "samsung,exynos5-gsc",
-   .data = 

Re: [PATCH v10 14/24] v4l: async: Allow binding notifiers to sub-devices

[Sakari Ailus]

Hi Hans,

Thanks for the review!

On Mon, Sep 11, 2017 at 10:57:16AM +0200, Hans Verkuil wrote:
> On 09/11/2017 09:59 AM, Sakari Ailus wrote:
> > Registering a notifier has required the knowledge of struct v4l2_device
> > for the reason that sub-devices generally are registered to the
> > v4l2_device (as well as the media device, also available through
> > v4l2_device).
> > 
> > This information is not available for sub-device drivers at probe time.
> > 
> > What this patch does is that it allows registering notifiers without
> > having v4l2_device around. Instead the sub-device pointer is stored in the
> > notifier. Once the sub-device of the driver that registered the notifier
> > is registered, the notifier will gain the knowledge of the v4l2_device,
> > and the binding of async sub-devices from the sub-device driver's notifier
> > may proceed.
> > 
> > The root notifier's complete callback is only called when all sub-device
> > notifiers are completed.
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  drivers/media/v4l2-core/v4l2-async.c | 217 
> > ++-
> >  include/media/v4l2-async.h   |  16 ++-
> >  2 files changed, 202 insertions(+), 31 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> > b/drivers/media/v4l2-core/v4l2-async.c
> > index 9ebc2e079d03..6f788b2e922a 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > @@ -53,6 +53,10 @@ static int v4l2_async_notifier_call_complete(struct 
> > v4l2_async_notifier *n)
> > return n->ops->complete(n);
> >  }
> >  
> > +static int v4l2_async_match_notify(struct v4l2_async_notifier *notifier,
> > +  struct v4l2_subdev *sd,
> > +  struct v4l2_async_subdev *asd);
> > +
> >  static bool match_i2c(struct v4l2_subdev *sd, struct v4l2_async_subdev 
> > *asd)
> >  {
> >  #if IS_ENABLED(CONFIG_I2C)
> > @@ -124,14 +128,128 @@ static struct v4l2_async_subdev 
> > *v4l2_async_find_match(
> > return NULL;
> >  }
> >  
> > +/* Get the sub-device notifier registered by a sub-device driver. */
> > +static struct v4l2_async_notifier *v4l2_async_get_subdev_notifier(
> 
> I prefer to call this v4l2_async_find_subdev_notifier(). 'get' suggests
> a getter function, but this actually has to find it. I think this may have
> confused me during an earlier review of this code. The comment also needs
> updating: "Find the sub-device...".

Yes, makes sense. Get also suggests that there would be reference counting
which is not the case here.

I made the corresponding change to v4l2_async_notifier_find_v4l2_dev() as
well.

> 
> > +   struct v4l2_subdev *sd)
> > +{
> > +   struct v4l2_async_notifier *n;
> > +
> > +   list_for_each_entry(n, _list, list)
> > +   if (n->sd == sd)
> > +   return n;
> > +
> > +   return NULL;
> > +}
> > +
> > +/* Return true if all sub-device notifiers are complete, false otherwise. 
> > */
> > +static bool v4l2_async_subdev_notifiers_complete(
> > +   struct v4l2_async_notifier *notifier)
> > +{
> > +   struct v4l2_subdev *sd;
> > +
> > +   if (!list_empty(>waiting))
> > +   return false;
> > +
> > +   list_for_each_entry(sd, >done, async_list) {
> > +   struct v4l2_async_notifier *subdev_notifier =
> > +   v4l2_async_get_subdev_notifier(sd);
> 
> Would it make sense to add a 'struct v4l2_async_notifier *subdev_notifier'
> field to struct v4l2_subdev? It's set when a subdev registers a notifier.
> 
> That way you can just use sd->subdev_notifier here.
> 
> I wonder if v4l2_async_get_subdev_notifier() is needed at all if you do
> this.

I thought of that, but ended up keeping the information in the notifier. As
the information is already available elsewhere, I didn't end up adding a
new field for the purpose. This is certainly not performance critical
either.

> 
> > +
> > +   if (!subdev_notifier)
> > +   continue;
> > +
> > +   if (!v4l2_async_subdev_notifiers_complete(subdev_notifier))
> > +   return false;
> > +   }
> > +
> > +   return true;
> > +}
> > +
> > +/* Get v4l2_device related to the notifier if one can be found. */
> > +static struct v4l2_device *v4l2_async_notifier_get_v4l2_dev(
> > +   struct v4l2_async_notifier *notifier)
> > +{
> > +   while (notifier->parent)
> > +   notifier = notifier->parent;
> > +
> > +   return notifier->v4l2_dev;
> > +}
> > +
> > +/* Test all async sub-devices in a notifier for a match. */
> > +static int v4l2_async_notifier_try_all_subdevs(
> > +   struct v4l2_async_notifier *notifier)
> > +{
> > +   struct v4l2_subdev *sd;
> > +
> > +   if (!v4l2_async_notifier_get_v4l2_dev(notifier))
> > +   return 0;
> > +
> > +again:
> > +   list_for_each_entry(sd, _list, async_list) {
> > +   struct v4l2_async_subdev *asd;
> > +   int ret;
> > +
> > +   asd = 

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

[Chris Wilson]

Quoting Christian König (2017-09-11 10:06:50)
> Am 11.09.2017 um 10:59 schrieb Chris Wilson:
> > Quoting Christian König (2017-09-11 09:50:40)
> >> Sorry for the delayed response, but your mail somehow ended up in the
> >> Spam folder.
> >>
> >> Am 04.09.2017 um 15:40 schrieb Chris Wilson:
> >>> Quoting Christian König (2017-09-04 14:27:33)
>  From: Christian König 
> 
>  The logic is buggy and unnecessary complex. When dma_fence_get_rcu() 
>  fails to
>  acquire a reference it doesn't necessary mean that there is no fence at 
>  all.
> 
>  It usually mean that the fence was replaced by a new one and in this 
>  situation
>  we certainly want to have the new one as result and *NOT* NULL.
> >>> Which is not guaranteed by the code you wrote either.
> >>>
> >>> The point of the comment is that the mb is only inside the successful
> >>> kref_atomic_inc_unless_zero, and that only after that mb do you know
> >>> whether or not you have the current fence.
> >>>
> >>> You can argue that you want to replace the
> >>>if (!dma_fence_get_rcu())
> >>>return NULL
> >>> with
> >>>if (!dma_fence_get_rcu()
> >>>continue;
> >>> but it would be incorrect to say that by simply ignoring the
> >>> post-condition check that you do have the right fence.
> >> You are completely missing the point here.
> >>
> >> It is irrelevant if you have the current fence or not when you return.
> >> You can only guarantee that it is the current fence when you take a look
> >> and that is exactly what we want to avoid.
> >>
> >> So the existing code is complete nonsense. Instead what we need to
> >> guarantee is that we return *ANY* fence which we can grab a reference for.
> > Not quite. We can grab a reference on a fence that was already freed and
> > reused between the rcu_dereference() and dma_fence_get_rcu().
> 
> Reusing a memory structure before the RCU grace period is completed is 
> illegal, otherwise the whole RCU approach won't work.

RCU only protects that the pointer remains valid. If you use
SLAB_TYPESAFE_BY_RCU, it is possible to reuse the pointer within a grace
period. It does happen and that is the point the comment is trying to
make.
-Chris

Re: [PATCH 3/3] [media] s5p-mfc: Adjust a null pointer check in four functions

[Sylwester Nawrocki]

On 09/08/2017 10:53 PM, SF Markus Elfring wrote:

From: Markus Elfring 



Date: Fri, 8 Sep 2017 22:37:00 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


Can you resend with that 4 lines removed? Are you using git send-email
for sending patches?

--
Thanks,
Sylwester

Re: [PATCH 2/3] [media] s5p-mfc: Improve a size determination in s5p_mfc_alloc_memdev()

[Sylwester Nawrocki]

On 09/08/2017 10:52 PM, SF Markus Elfring wrote:

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring


Acked-by: Sylwester Nawrocki 

Re: [PATCH 1/3] [media] s5p-mfc: Delete an error message for a failed memory allocation in s5p_mfc_probe()

[Sylwester Nawrocki]

On 09/08/2017 10:51 PM, SF Markus Elfring wrote:

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring


Could you make the commit summary shorter, to keep it below 70
characters [1]? With that changed feel free to add

Acked-by: Sylwester Nawrocki 

--
Regards,
Sylwester

[1] Documentation/process/submitting-patches.rst

Re: [PATCH v10 17/24] v4l: fwnode: Add a helper function for parsing generic references

[Hans Verkuil]

On 09/11/2017 10:00 AM, Sakari Ailus wrote:
> Add function v4l2_fwnode_reference_count() for counting external
> references and v4l2_fwnode_reference_parse() for parsing them as async
> sub-devices.
> 
> This can be done on e.g. flash or lens async sub-devices that are not part
> of but are associated with a sensor.
> 
> struct v4l2_async_notifier.max_subdevs field is added to contain the
> maximum number of sub-devices in a notifier to reflect the memory
> allocated for the subdevs array.

This paragraph appears to be out-of-date.

> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/v4l2-core/v4l2-fwnode.c | 47 
> +++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c 
> b/drivers/media/v4l2-core/v4l2-fwnode.c
> index d978f2d714ca..4821c4989119 100644
> --- a/drivers/media/v4l2-core/v4l2-fwnode.c
> +++ b/drivers/media/v4l2-core/v4l2-fwnode.c
> @@ -449,6 +449,53 @@ int v4l2_async_notifier_parse_fwnode_endpoints(
>  }
>  EXPORT_SYMBOL_GPL(v4l2_async_notifier_parse_fwnode_endpoints);
>  
> +static int v4l2_fwnode_reference_parse(
> + struct device *dev, struct v4l2_async_notifier *notifier,
> + const char *prop)
> +{
> + struct fwnode_reference_args args;
> + unsigned int index = 0;
> + int ret;
> +
> + for (; !fwnode_property_get_reference_args(
> +  dev_fwnode(dev), prop, NULL, 0, index, ); index++)
> + fwnode_handle_put(args.fwnode);
> +

If nothing is found (i.e. index == 0), shouldn't you just return here?

> + ret = v4l2_async_notifier_realloc(notifier,
> +   notifier->num_subdevs + index);
> + if (ret)
> + return -ENOMEM;
> +
> + for (ret = -ENOENT, index = 0;

There is no reason for the 'ret = -ENOENT' to be in the for(), just set it 
before
the 'for' statement.

> +  !fwnode_property_get_reference_args(
> +  dev_fwnode(dev), prop, NULL, 0, index, );
> +  index++) {
> + struct v4l2_async_subdev *asd;
> +
> + if (WARN_ON(notifier->num_subdevs >= notifier->max_subdevs)) {
> + ret = -EINVAL;
> + goto error;
> + }
> +
> + asd = kzalloc(sizeof(*asd), GFP_KERNEL);
> + if (!asd) {
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + notifier->subdevs[notifier->num_subdevs] = asd;
> + asd->match.fwnode.fwnode = args.fwnode;
> + asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
> + notifier->num_subdevs++;
> + }

If the loop doesn't find anything, then it still returns 0, not -ENOENT.
So why set ret to ENOENT? Something weird going on here.

I think you should also add a comment explaining this function.

> +
> + return 0;
> +
> +error:
> + fwnode_handle_put(args.fwnode);
> + return ret;
> +}
> +
>  MODULE_LICENSE("GPL");
>  MODULE_AUTHOR("Sakari Ailus ");
>  MODULE_AUTHOR("Sylwester Nawrocki ");
> 

Regards,

Hans

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

[Christian König]

Am 11.09.2017 um 10:59 schrieb Chris Wilson:

Quoting Christian König (2017-09-11 09:50:40)

Sorry for the delayed response, but your mail somehow ended up in the
Spam folder.

Am 04.09.2017 um 15:40 schrieb Chris Wilson:

Quoting Christian König (2017-09-04 14:27:33)

From: Christian König 

The logic is buggy and unnecessary complex. When dma_fence_get_rcu() fails to
acquire a reference it doesn't necessary mean that there is no fence at all.

It usually mean that the fence was replaced by a new one and in this situation
we certainly want to have the new one as result and *NOT* NULL.

Which is not guaranteed by the code you wrote either.

The point of the comment is that the mb is only inside the successful
kref_atomic_inc_unless_zero, and that only after that mb do you know
whether or not you have the current fence.

You can argue that you want to replace the
   if (!dma_fence_get_rcu())
   return NULL
with
   if (!dma_fence_get_rcu()
   continue;
but it would be incorrect to say that by simply ignoring the
post-condition check that you do have the right fence.

You are completely missing the point here.

It is irrelevant if you have the current fence or not when you return.
You can only guarantee that it is the current fence when you take a look
and that is exactly what we want to avoid.

So the existing code is complete nonsense. Instead what we need to
guarantee is that we return *ANY* fence which we can grab a reference for.

Not quite. We can grab a reference on a fence that was already freed and
reused between the rcu_dereference() and dma_fence_get_rcu().


Reusing a memory structure before the RCU grace period is completed is 
illegal, otherwise the whole RCU approach won't work.


So that case can't happen.

Regards,
Christian.


-Chris

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

[Chris Wilson]

Quoting Christian König (2017-09-11 09:50:40)
> Sorry for the delayed response, but your mail somehow ended up in the 
> Spam folder.
> 
> Am 04.09.2017 um 15:40 schrieb Chris Wilson:
> > Quoting Christian König (2017-09-04 14:27:33)
> >> From: Christian König 
> >>
> >> The logic is buggy and unnecessary complex. When dma_fence_get_rcu() fails 
> >> to
> >> acquire a reference it doesn't necessary mean that there is no fence at 
> >> all.
> >>
> >> It usually mean that the fence was replaced by a new one and in this 
> >> situation
> >> we certainly want to have the new one as result and *NOT* NULL.
> > Which is not guaranteed by the code you wrote either.
> >
> > The point of the comment is that the mb is only inside the successful
> > kref_atomic_inc_unless_zero, and that only after that mb do you know
> > whether or not you have the current fence.
> >
> > You can argue that you want to replace the
> >   if (!dma_fence_get_rcu())
> >   return NULL
> > with
> >   if (!dma_fence_get_rcu()
> >   continue;
> > but it would be incorrect to say that by simply ignoring the
> > post-condition check that you do have the right fence.
> 
> You are completely missing the point here.
> 
> It is irrelevant if you have the current fence or not when you return. 
> You can only guarantee that it is the current fence when you take a look 
> and that is exactly what we want to avoid.
> 
> So the existing code is complete nonsense. Instead what we need to 
> guarantee is that we return *ANY* fence which we can grab a reference for.

Not quite. We can grab a reference on a fence that was already freed and
reused between the rcu_dereference() and dma_fence_get_rcu().
-Chris

Re: [PATCH v10 14/24] v4l: async: Allow binding notifiers to sub-devices

[Hans Verkuil]

On 09/11/2017 09:59 AM, Sakari Ailus wrote:
> Registering a notifier has required the knowledge of struct v4l2_device
> for the reason that sub-devices generally are registered to the
> v4l2_device (as well as the media device, also available through
> v4l2_device).
> 
> This information is not available for sub-device drivers at probe time.
> 
> What this patch does is that it allows registering notifiers without
> having v4l2_device around. Instead the sub-device pointer is stored in the
> notifier. Once the sub-device of the driver that registered the notifier
> is registered, the notifier will gain the knowledge of the v4l2_device,
> and the binding of async sub-devices from the sub-device driver's notifier
> may proceed.
> 
> The root notifier's complete callback is only called when all sub-device
> notifiers are completed.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/v4l2-core/v4l2-async.c | 217 
> ++-
>  include/media/v4l2-async.h   |  16 ++-
>  2 files changed, 202 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index 9ebc2e079d03..6f788b2e922a 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -53,6 +53,10 @@ static int v4l2_async_notifier_call_complete(struct 
> v4l2_async_notifier *n)
>   return n->ops->complete(n);
>  }
>  
> +static int v4l2_async_match_notify(struct v4l2_async_notifier *notifier,
> +struct v4l2_subdev *sd,
> +struct v4l2_async_subdev *asd);
> +
>  static bool match_i2c(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
>  {
>  #if IS_ENABLED(CONFIG_I2C)
> @@ -124,14 +128,128 @@ static struct v4l2_async_subdev *v4l2_async_find_match(
>   return NULL;
>  }
>  
> +/* Get the sub-device notifier registered by a sub-device driver. */
> +static struct v4l2_async_notifier *v4l2_async_get_subdev_notifier(

I prefer to call this v4l2_async_find_subdev_notifier(). 'get' suggests
a getter function, but this actually has to find it. I think this may have
confused me during an earlier review of this code. The comment also needs
updating: "Find the sub-device...".

> + struct v4l2_subdev *sd)
> +{
> + struct v4l2_async_notifier *n;
> +
> + list_for_each_entry(n, _list, list)
> + if (n->sd == sd)
> + return n;
> +
> + return NULL;
> +}
> +
> +/* Return true if all sub-device notifiers are complete, false otherwise. */
> +static bool v4l2_async_subdev_notifiers_complete(
> + struct v4l2_async_notifier *notifier)
> +{
> + struct v4l2_subdev *sd;
> +
> + if (!list_empty(>waiting))
> + return false;
> +
> + list_for_each_entry(sd, >done, async_list) {
> + struct v4l2_async_notifier *subdev_notifier =
> + v4l2_async_get_subdev_notifier(sd);

Would it make sense to add a 'struct v4l2_async_notifier *subdev_notifier'
field to struct v4l2_subdev? It's set when a subdev registers a notifier.

That way you can just use sd->subdev_notifier here.

I wonder if v4l2_async_get_subdev_notifier() is needed at all if you do
this.

> +
> + if (!subdev_notifier)
> + continue;
> +
> + if (!v4l2_async_subdev_notifiers_complete(subdev_notifier))
> + return false;
> + }
> +
> + return true;
> +}
> +
> +/* Get v4l2_device related to the notifier if one can be found. */
> +static struct v4l2_device *v4l2_async_notifier_get_v4l2_dev(
> + struct v4l2_async_notifier *notifier)
> +{
> + while (notifier->parent)
> + notifier = notifier->parent;
> +
> + return notifier->v4l2_dev;
> +}
> +
> +/* Test all async sub-devices in a notifier for a match. */
> +static int v4l2_async_notifier_try_all_subdevs(
> + struct v4l2_async_notifier *notifier)
> +{
> + struct v4l2_subdev *sd;
> +
> + if (!v4l2_async_notifier_get_v4l2_dev(notifier))
> + return 0;
> +
> +again:
> + list_for_each_entry(sd, _list, async_list) {
> + struct v4l2_async_subdev *asd;
> + int ret;
> +
> + asd = v4l2_async_find_match(notifier, sd);
> + if (!asd)
> + continue;
> +
> + ret = v4l2_async_match_notify(notifier, sd, asd);
> + if (ret < 0)
> + return ret;
> +
> + /*
> +  * v4l2_async_match_notify() may lead to registering a
> +  * new notifier and thus changing the async subdevs
> +  * list. In order to proceed safely from here, restart
> +  * parsing the list from the beginning.
> +  */
> + goto again;
> + }
> +
> + return 0;
> +}
> +
> +/* Try completing a notifier. */
> +static int v4l2_async_notifier_try_complete(
> + struct 

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

[Christian König]

Sorry for the delayed response, but your mail somehow ended up in the 
Spam folder.


Am 04.09.2017 um 15:40 schrieb Chris Wilson:

Quoting Christian König (2017-09-04 14:27:33)

From: Christian König 

The logic is buggy and unnecessary complex. When dma_fence_get_rcu() fails to
acquire a reference it doesn't necessary mean that there is no fence at all.

It usually mean that the fence was replaced by a new one and in this situation
we certainly want to have the new one as result and *NOT* NULL.

Which is not guaranteed by the code you wrote either.

The point of the comment is that the mb is only inside the successful
kref_atomic_inc_unless_zero, and that only after that mb do you know
whether or not you have the current fence.

You can argue that you want to replace the
if (!dma_fence_get_rcu())
return NULL
with
if (!dma_fence_get_rcu()
continue;
but it would be incorrect to say that by simply ignoring the
post-condition check that you do have the right fence.


You are completely missing the point here.

It is irrelevant if you have the current fence or not when you return. 
You can only guarantee that it is the current fence when you take a look 
and that is exactly what we want to avoid.


So the existing code is complete nonsense. Instead what we need to 
guarantee is that we return *ANY* fence which we can grab a reference for.


See the usual life of a fence* variable looks like this:
1. assigning pointer to fence A;
2. assigning pointer to fence B;
3. assigning pointer to fence C;


When dma_fence_get_rcu_safe() is called between step #1 and step #2 for 
example it is perfectly valid to just return either fence A or fence B.


But it is invalid to return NULL because that suggests that we don't 
need to sync at all.


Regards,
Christian.

Re: [PATCH v9 00/23] Unified fwnode endpoint parser, async sub-device notifier support, N9 flash DTS

[Sakari Ailus]

On Sat, Sep 09, 2017 at 11:34:13AM +0200, Pavel Machek wrote:
> On Fri 2017-09-08 16:25:07, Sakari Ailus wrote:
> > On Fri, Sep 08, 2017 at 04:11:51PM +0300, Sakari Ailus wrote:
> > > With this, the as3645a driver successfully registers a sub-device to the
> > > media device created by the omap3isp driver. The kernel also has the
> > > information it's related to the sensor driven by the smiapp driver but we
> > > don't have a way to expose that information yet.
> > 
> > The patches are also available here:
> > 
> > 
> 
> I merged the series on top of v4.14-rc0, and it does not break
> anything. So:
> 
> Tested-by: Pavel Machek 

Thanks!

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v9 13/24] v4l: async: Allow async notifier register call succeed with no subdevs

[Sakari Ailus]

On Mon, Sep 11, 2017 at 10:05:40AM +0200, Hans Verkuil wrote:
> On 09/08/2017 03:18 PM, Sakari Ailus wrote:
> > The information on how many async sub-devices would be bindable to a
> > notifier is typically dependent on information from platform firmware and
> > it's not driver's business to be aware of that.
> > 
> > Many V4L2 main drivers are perfectly usable (and useful) without async
> > sub-devices and so if there aren't any around, just proceed call the
> > notifier's complete callback immediately without registering the notifier
> > itself.
> > 
> > If a driver needs to check whether there are async sub-devices available,
> > it can be done by inspecting the notifier's num_subdevs field which tells
> > the number of async sub-devices.
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  drivers/media/v4l2-core/v4l2-async.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> > b/drivers/media/v4l2-core/v4l2-async.c
> > index 7b396ff4302b..9ebc2e079d03 100644
> > --- a/drivers/media/v4l2-core/v4l2-async.c
> > +++ b/drivers/media/v4l2-core/v4l2-async.c
> > @@ -170,10 +170,12 @@ int v4l2_async_notifier_register(struct v4l2_device 
> > *v4l2_dev,
> > struct v4l2_async_subdev *asd;
> > int i;
> >  
> > -   if (!v4l2_dev || !notifier->num_subdevs ||
> > -   notifier->num_subdevs > V4L2_MAX_SUBDEVS)
> > +   if (!v4l2_dev || notifier->num_subdevs > V4L2_MAX_SUBDEVS)
> > return -EINVAL;
> >  
> > +   if (!notifier->num_subdevs)
> > +   return v4l2_async_notifier_call_complete(notifier);
> > +
> 
> I would move this 'if' down to after the next three lines...
> 
> > notifier->v4l2_dev = v4l2_dev;
> > INIT_LIST_HEAD(>waiting);
> > INIT_LIST_HEAD(>done);
> > 
> 
> ...that way the notifier struct is properly initialized. Just in case anyone
> ever looks at these three fields.

Makes sense. Fixed.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v9 13/24] v4l: async: Allow async notifier register call succeed with no subdevs

[Hans Verkuil]

On 09/08/2017 03:18 PM, Sakari Ailus wrote:
> The information on how many async sub-devices would be bindable to a
> notifier is typically dependent on information from platform firmware and
> it's not driver's business to be aware of that.
> 
> Many V4L2 main drivers are perfectly usable (and useful) without async
> sub-devices and so if there aren't any around, just proceed call the
> notifier's complete callback immediately without registering the notifier
> itself.
> 
> If a driver needs to check whether there are async sub-devices available,
> it can be done by inspecting the notifier's num_subdevs field which tells
> the number of async sub-devices.
> 
> Signed-off-by: Sakari Ailus 
> ---
>  drivers/media/v4l2-core/v4l2-async.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> b/drivers/media/v4l2-core/v4l2-async.c
> index 7b396ff4302b..9ebc2e079d03 100644
> --- a/drivers/media/v4l2-core/v4l2-async.c
> +++ b/drivers/media/v4l2-core/v4l2-async.c
> @@ -170,10 +170,12 @@ int v4l2_async_notifier_register(struct v4l2_device 
> *v4l2_dev,
>   struct v4l2_async_subdev *asd;
>   int i;
>  
> - if (!v4l2_dev || !notifier->num_subdevs ||
> - notifier->num_subdevs > V4L2_MAX_SUBDEVS)
> + if (!v4l2_dev || notifier->num_subdevs > V4L2_MAX_SUBDEVS)
>   return -EINVAL;
>  
> + if (!notifier->num_subdevs)
> + return v4l2_async_notifier_call_complete(notifier);
> +

I would move this 'if' down to after the next three lines...

>   notifier->v4l2_dev = v4l2_dev;
>   INIT_LIST_HEAD(>waiting);
>   INIT_LIST_HEAD(>done);
> 

...that way the notifier struct is properly initialized. Just in case anyone
ever looks at these three fields.

Regards,

Hans

[PATCH v10 00/24] Unified fwnode endpoint parser, async sub-device notifier support, N9 flash DTS

[Sakari Ailus]

Hi folks,

We have a large influx of new, unmerged, drivers that are now parsing
fwnode endpoints and each one of them is doing this a little bit
differently. The needs are still exactly the same for the graph data
structure is device independent. This is still a non-trivial task and the
majority of the driver implementations are buggy, just buggy in different
ways.

Facilitate parsing endpoints by adding a convenience function for parsing
the endpoints, and make the omap3isp and rcar-vin drivers use them as an
example.

To show where we're getting with this, I've added support for async
sub-device notifier support that is notifiers that can be registered by
sub-device drivers as well as V4L2 fwnode improvements to make use of them
and the DTS changes for the Nokia N9. Some of these patches I've posted
previously in this set here:



Since that, the complete callback of the master notifier registering the
V4L2 device is only called once all sub-notifiers have been completed as
well. This way the device node creation can be postponed until all devices
have been successfully initialised.

With this, the as3645a driver successfully registers a sub-device to the
media device created by the omap3isp driver. The kernel also has the
information it's related to the sensor driven by the smiapp driver but we
don't have a way to expose that information yet.

since v9:

- Drop "as3645a: Switch to fwnode property API" and "ACPI: Document how to
  refer to LEDs from remote nodes" patches. They're better off separately
  from this set.

- Address property documentation redundancy in smiapp DT binding
  documentation.

- Add patches "ov5670: Add support for flash and lens devices" and
  "ov13858: Add support for flash and lens devices".

since v8:

- Improve terminology for notifiers. Instead of master / subdev, we
  have root, parent and subdev notifiers.

- Renamed "flash" property as "flash-leds". There are many, and currently
  we make assumptions in a lot of places (e.g. LED bindings) that these
  are LEDs. While we don't have any other types of flashes supported right
  now (e.g. Xenon), it's safer to assume we might have them in the future.

- Use ENOTCONN instead of EPERM to tell from driver's callback function
  that an endpoint is to be skipped but not handled as an error.

- Avoid accessing notifier's subdevs array as well as num_subdevs field
  from rcar-vin driver.

- Add a patch "v4l: async: Allow async notifier register call succeed with no
  subdevs", which allows, well, what the subject says.

- Move checks for subdev / v4l2_dev from __v4l2_async_notifier_register()
  to v4l2_async_notifier_register() and
  v4l2_async_subdev_notifier_register().

- Don't initialise notifier->list. There was no need to do so, as this is
  the entry added to the list and not used otherwise. I.e. regarding this,
  the state before this patchset is restored.

- Clean up error handling in v4l2_async_notifier_fwnode_parse_endpoint().

- WARN_ON() in v4l2_async_notifier_parse_fwnode_endpoints() if the
  asd_struct_size is smaller than size of struct v4l2_async_subdev.

- Make v4l2_fwnode_reference_parse() static as there should be no need to
  use it outside the V4L2 fwnode framework. Also, remove the callback
  function as well as other arguments that always have the same value in
  current usage. (This can be changed later on if needed without affecting
  drivers.)

- Add the patch "v4l: fwnode: Add a helper function to obtain device /
  interger references", which allows similar use than
  v4l2_fwnode_reference_parse() but is more useful on ACPI based systems
  --- on ACPI, you can only refer to device nodes (corresponding struct
  deice in Linux), not to data extension nodes under the devices.

- Improve v4l2_fwnode_reference_parse_sensor_common() to work on ACPI
  based systems.

- Add patch "ACPI: Document how to refer to LEDs from remote nodes" to
  document using and referring to LEDs on ACPI.

- Rebase the set on AS3645A fixes I just sent ("AS3645A fixes")

- In v4l2_fwnode_reference_parse_sensor_common(), tell if parsing a
  property failed.

- Improved documentation for v4l2_async_notifier_parse_fwnode_endpoints().

- Fix v4l2_async_notifier_try_all_subdevs(); it is allowed that the list
  entry being iterated over is deleted but no other changes to the list
  are allowed. This could be the case if a sub-device driver's notifier
  binds a sub-device. Restart the loop whenever a match is found.

- Add patch "as3645a: Switch to fwnode property API" which also adds ACPI
  support.

since v7:

- Added three more patches:

v4l: async: Remove re-probing support
v4l: async: Use more intuitive names for internal functions
dt: bindings: smiapp: Document lens-focus and flash properties

  The last one was already sent previously after the rest of the patchset.

- Removed re-probing support. This is hard to support and only useful in
  special 

[PATCH v10 04/24] v4l: async: Add V4L2 async documentation to the documentation build

[Sakari Ailus]

The V4L2 async wasn't part of the documentation build. Fix this.

Signed-off-by: Sakari Ailus 
Reviewed-by: Niklas Söderlund 
Acked-by: Hans Verkuil 
Reviewed-by: Laurent Pinchart 
---
 Documentation/media/kapi/v4l2-async.rst | 3 +++
 Documentation/media/kapi/v4l2-core.rst  | 1 +
 2 files changed, 4 insertions(+)
 create mode 100644 Documentation/media/kapi/v4l2-async.rst

diff --git a/Documentation/media/kapi/v4l2-async.rst 
b/Documentation/media/kapi/v4l2-async.rst
new file mode 100644
index ..523ff9eb09a0
--- /dev/null
+++ b/Documentation/media/kapi/v4l2-async.rst
@@ -0,0 +1,3 @@
+V4L2 async kAPI
+^^^
+.. kernel-doc:: include/media/v4l2-async.h
diff --git a/Documentation/media/kapi/v4l2-core.rst 
b/Documentation/media/kapi/v4l2-core.rst
index c7434f38fd9c..5cf292037a48 100644
--- a/Documentation/media/kapi/v4l2-core.rst
+++ b/Documentation/media/kapi/v4l2-core.rst
@@ -19,6 +19,7 @@ Video4Linux devices
 v4l2-mc
 v4l2-mediabus
 v4l2-mem2mem
+v4l2-async
 v4l2-fwnode
 v4l2-rect
 v4l2-tuner
-- 
2.11.0

[PATCH v10 12/24] v4l: async: Register sub-devices before calling bound callback

[Sakari Ailus]

Register the sub-device before calling the notifier's bound callback.
Doing this the other way around is problematic as the struct v4l2_device
has not assigned for the sub-device yet and may be required by the bound
callback.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-async.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index c34f93593b41..7b396ff4302b 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -130,13 +130,13 @@ static int v4l2_async_match_notify(struct 
v4l2_async_notifier *notifier,
 {
int ret;
 
-   ret = v4l2_async_notifier_call_bound(notifier, sd, asd);
+   ret = v4l2_device_register_subdev(notifier->v4l2_dev, sd);
if (ret < 0)
return ret;
 
-   ret = v4l2_device_register_subdev(notifier->v4l2_dev, sd);
+   ret = v4l2_async_notifier_call_bound(notifier, sd, asd);
if (ret < 0) {
-   v4l2_async_notifier_call_unbind(notifier, sd, asd);
+   v4l2_device_unregister_subdev(sd);
return ret;
}
 
-- 
2.11.0

[PATCH v10 13/24] v4l: async: Allow async notifier register call succeed with no subdevs

[Sakari Ailus]

The information on how many async sub-devices would be bindable to a
notifier is typically dependent on information from platform firmware and
it's not driver's business to be aware of that.

Many V4L2 main drivers are perfectly usable (and useful) without async
sub-devices and so if there aren't any around, just proceed call the
notifier's complete callback immediately without registering the notifier
itself.

If a driver needs to check whether there are async sub-devices available,
it can be done by inspecting the notifier's num_subdevs field which tells
the number of async sub-devices.

Signed-off-by: Sakari Ailus 
---
 drivers/media/v4l2-core/v4l2-async.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index 7b396ff4302b..9ebc2e079d03 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -170,10 +170,12 @@ int v4l2_async_notifier_register(struct v4l2_device 
*v4l2_dev,
struct v4l2_async_subdev *asd;
int i;
 
-   if (!v4l2_dev || !notifier->num_subdevs ||
-   notifier->num_subdevs > V4L2_MAX_SUBDEVS)
+   if (!v4l2_dev || notifier->num_subdevs > V4L2_MAX_SUBDEVS)
return -EINVAL;
 
+   if (!notifier->num_subdevs)
+   return v4l2_async_notifier_call_complete(notifier);
+
notifier->v4l2_dev = v4l2_dev;
INIT_LIST_HEAD(>waiting);
INIT_LIST_HEAD(>done);
-- 
2.11.0

[PATCH v10 07/24] rcar-vin: Use generic parser for parsing fwnode endpoints

[Sakari Ailus]

Instead of using driver implementation, use
v4l2_async_notifier_parse_fwnode_endpoints() to parse the fwnode endpoints
of the device.

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 112 +---
 drivers/media/platform/rcar-vin/rcar-dma.c  |  10 +--
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  14 ++--
 drivers/media/platform/rcar-vin/rcar-vin.h  |   4 +-
 4 files changed, 48 insertions(+), 92 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 142de447..62b4a94f9a39 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include "rcar-vin.h"
@@ -77,14 +78,14 @@ static int rvin_digital_notify_complete(struct 
v4l2_async_notifier *notifier)
int ret;
 
/* Verify subdevices mbus format */
-   if (!rvin_mbus_supported(>digital)) {
+   if (!rvin_mbus_supported(vin->digital)) {
vin_err(vin, "Unsupported media bus format for %s\n",
-   vin->digital.subdev->name);
+   vin->digital->subdev->name);
return -EINVAL;
}
 
vin_dbg(vin, "Found media bus format for %s: %d\n",
-   vin->digital.subdev->name, vin->digital.code);
+   vin->digital->subdev->name, vin->digital->code);
 
ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
if (ret < 0) {
@@ -103,7 +104,7 @@ static void rvin_digital_notify_unbind(struct 
v4l2_async_notifier *notifier,
 
vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
rvin_v4l2_remove(vin);
-   vin->digital.subdev = NULL;
+   vin->digital->subdev = NULL;
 }
 
 static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,
@@ -120,117 +121,70 @@ static int rvin_digital_notify_bound(struct 
v4l2_async_notifier *notifier,
ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
if (ret < 0)
return ret;
-   vin->digital.source_pad = ret;
+   vin->digital->source_pad = ret;
 
ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
-   vin->digital.sink_pad = ret < 0 ? 0 : ret;
+   vin->digital->sink_pad = ret < 0 ? 0 : ret;
 
-   vin->digital.subdev = subdev;
+   vin->digital->subdev = subdev;
 
vin_dbg(vin, "bound subdev %s source pad: %u sink pad: %u\n",
-   subdev->name, vin->digital.source_pad,
-   vin->digital.sink_pad);
+   subdev->name, vin->digital->source_pad,
+   vin->digital->sink_pad);
 
return 0;
 }
 
-static int rvin_digitial_parse_v4l2(struct rvin_dev *vin,
-   struct device_node *ep,
-   struct v4l2_mbus_config *mbus_cfg)
+static int rvin_digital_parse_v4l2(struct device *dev,
+  struct v4l2_fwnode_endpoint *vep,
+  struct v4l2_async_subdev *asd)
 {
-   struct v4l2_fwnode_endpoint v4l2_ep;
-   int ret;
+   struct rvin_dev *vin = dev_get_drvdata(dev);
+   struct rvin_graph_entity *rvge =
+   container_of(asd, struct rvin_graph_entity, asd);
 
-   ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), _ep);
-   if (ret) {
-   vin_err(vin, "Could not parse v4l2 endpoint\n");
-   return -EINVAL;
-   }
+   if (vep->base.port || vep->base.id)
+   return -ENOTCONN;
 
-   mbus_cfg->type = v4l2_ep.bus_type;
+   rvge->mbus_cfg.type = vep->bus_type;
 
-   switch (mbus_cfg->type) {
+   switch (rvge->mbus_cfg.type) {
case V4L2_MBUS_PARALLEL:
vin_dbg(vin, "Found PARALLEL media bus\n");
-   mbus_cfg->flags = v4l2_ep.bus.parallel.flags;
+   rvge->mbus_cfg.flags = vep->bus.parallel.flags;
break;
case V4L2_MBUS_BT656:
vin_dbg(vin, "Found BT656 media bus\n");
-   mbus_cfg->flags = 0;
+   rvge->mbus_cfg.flags = 0;
break;
default:
vin_err(vin, "Unknown media bus type\n");
return -EINVAL;
}
 
-   return 0;
-}
-
-static int rvin_digital_graph_parse(struct rvin_dev *vin)
-{
-   struct device_node *ep, *np;
-   int ret;
-
-   vin->digital.asd.match.fwnode.fwnode = NULL;
-   vin->digital.subdev = NULL;
-
-   /*
-* Port 0 id 0 is local digital input, try to get it.
-* Not all instances can or will have this, that is OK
-*/
-   ep = of_graph_get_endpoint_by_regs(vin->dev->of_node, 0, 0);
-   if (!ep)
-   return 0;
-
-   np = of_graph_get_remote_port_parent(ep);
-   if (!np) {
-   vin_err(vin, "No remote parent