Re: [PATCH] Clean up lirc zilog error codes

[Frans Klaver]

On Tue, Jul 11, 2017 at 7:57 PM, Yves Lemée  wrote:
> According the coding style guidelines, the ENOSYS error code must be returned
> in case of a non existent system call. This code has been replaced with
> the ENOTTY error code indicating, a missing functionality.
>
> Signed-off-by: Yves Lemée 

Your subject line is not according to the patch submission guidelines.

Also, on a nit-picking note, that comma after 'indicating' is rather
oddly placed. Please move or remove it.

Frans

Re: Lots of new warnings with gcc-7.1.1

[Jakub Kicinski]

On Tue, 11 Jul 2017 15:35:15 -0700, Linus Torvalds wrote:
> I do suspect I'll make "-Wformat-truncation" (as opposed to
> "-Wformat-overflow") be a "V=1" kind of warning.  But let's see how
> many of these we can fix, ok?

Somehow related - what's the stand on -Wimplicit-fallthrough?  I run
into the jump tables in jhash.h generating lots of warnings.  Is it OK
to do this?

--->8--

diff --git a/include/linux/jhash.h b/include/linux/jhash.h
index 348c6f47e4cc..f6d6513a4c03 100644
--- a/include/linux/jhash.h
+++ b/include/linux/jhash.h
@@ -85,20 +85,19 @@ static inline u32 jhash(const void *key, u32 length, u32 
initval)
k += 12;
}
/* Last block: affect all 32 bits of (c) */
-   /* All the case statements fall through */
switch (length) {
-   case 12: c += (u32)k[11]<<24;
-   case 11: c += (u32)k[10]<<16;
-   case 10: c += (u32)k[9]<<8;
-   case 9:  c += k[8];
-   case 8:  b += (u32)k[7]<<24;
-   case 7:  b += (u32)k[6]<<16;
-   case 6:  b += (u32)k[5]<<8;
-   case 5:  b += k[4];
-   case 4:  a += (u32)k[3]<<24;
-   case 3:  a += (u32)k[2]<<16;
-   case 2:  a += (u32)k[1]<<8;
-   case 1:  a += k[0];
+   case 12: c += (u32)k[11]<<24;   /* fall through */
+   case 11: c += (u32)k[10]<<16;   /* fall through */
+   case 10: c += (u32)k[9]<<8; /* fall through */
+   case 9:  c += k[8]; /* fall through */
+   case 8:  b += (u32)k[7]<<24;/* fall through */
+   case 7:  b += (u32)k[6]<<16;/* fall through */
+   case 6:  b += (u32)k[5]<<8; /* fall through */
+   case 5:  b += k[4]; /* fall through */
+   case 4:  a += (u32)k[3]<<24;/* fall through */
+   case 3:  a += (u32)k[2]<<16;/* fall through */
+   case 2:  a += (u32)k[1]<<8; /* fall through */
+   case 1:  a += k[0]; /* fall through */
 __jhash_final(a, b, c);
case 0: /* Nothing left to add */
break;
@@ -131,11 +130,11 @@ static inline u32 jhash2(const u32 *k, u32 length, u32 
initval)
k += 3;
}
 
-   /* Handle the last 3 u32's: all the case statements fall through */
+   /* Handle the last 3 u32's */
switch (length) {
-   case 3: c += k[2];
-   case 2: b += k[1];
-   case 1: a += k[0];
+   case 3: c += k[2];  /* fall through */
+   case 2: b += k[1];  /* fall through */
+   case 1: a += k[0];  /* fall through */
__jhash_final(a, b, c);
case 0: /* Nothing left to add */
break;

cron job: media_tree daily build: ERRORS

[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:   Wed Jul 12 05:00:24 CEST 2017
media-tree git hash:2748e76ddb2967c4030171342ebdd3faa6a5e8e8
media_build git hash:   bc1db0a204a87da86349ea5e64ae0d65e945609d
v4l-utils git hash: 8e68406dae2233e811032dc8e7714c09c818e893
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: WARNINGS
linux-git-arm-davinci: WARNINGS
linux-git-arm-multi: WARNINGS
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: WARNINGS
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: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: ERRORS
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.67-i686: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
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-rc1-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: ERRORS
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: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
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-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: Lots of new warnings with gcc-7.1.1

[Linus Torvalds]

On Tue, Jul 11, 2017 at 8:17 PM, Linus Torvalds
 wrote:
>
> If that's the case, I'd prefer just turning off the format-truncation
> (but not overflow) warning with '-Wno-format-trunction".

Doing

 KBUILD_CFLAGS  += $(call cc-disable-warning, format-truncation)

in the main Makefile certainly cuts down on the warnings.

We still have some overflow warnings, including the crazy one where
gcc doesn't see that the number of max7315 boards is very limited.

But those could easily be converted to just snprintf() instead, and
then the truncation warning disabling takes care of it. Maybe that's
the right answer.

We also have about a bazillion

warning: ‘*’ in boolean context, suggest ‘&&’ instead

warnings in drivers/ata/libata-core.c, all due to a single macro that
uses a pattern that gcc-7.1.1 doesn't like. The warning looks a bit
debatable, but I suspect the macro could easily be changed too.

Tejun, would you hate just moving the "multiply by 1000" part _into_
that EZ() macro? Something like the attached (UNTESTED!) patch?

  Linus
 drivers/ata/libata-core.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 8453f9a4682f..4c7d5a138495 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3231,19 +3231,19 @@ static const struct ata_timing ata_timing[] = {
 };
 
 #define ENOUGH(v, unit)(((v)-1)/(unit)+1)
-#define EZ(v, unit)((v)?ENOUGH(v, unit):0)
+#define EZ(v, unit)((v)?ENOUGH((v)*1000, unit):0)
 
 static void ata_timing_quantize(const struct ata_timing *t, struct ata_timing 
*q, int T, int UT)
 {
-   q->setup= EZ(t->setup  * 1000,  T);
-   q->act8b= EZ(t->act8b  * 1000,  T);
-   q->rec8b= EZ(t->rec8b  * 1000,  T);
-   q->cyc8b= EZ(t->cyc8b  * 1000,  T);
-   q->active   = EZ(t->active * 1000,  T);
-   q->recover  = EZ(t->recover* 1000,  T);
-   q->dmack_hold   = EZ(t->dmack_hold * 1000,  T);
-   q->cycle= EZ(t->cycle  * 1000,  T);
-   q->udma = EZ(t->udma   * 1000, UT);
+   q->setup= EZ(t->setup,  T);
+   q->act8b= EZ(t->act8b,  T);
+   q->rec8b= EZ(t->rec8b,  T);
+   q->cyc8b= EZ(t->cyc8b,  T);
+   q->active   = EZ(t->active, T);
+   q->recover  = EZ(t->recover,T);
+   q->dmack_hold   = EZ(t->dmack_hold, T);
+   q->cycle= EZ(t->cycle,  T);
+   q->udma = EZ(t->udma,   UT);
 }
 
 void ata_timing_merge(const struct ata_timing *a, const struct ata_timing *b,

Re: Lots of new warnings with gcc-7.1.1

[Linus Torvalds]

On Tue, Jul 11, 2017 at 8:10 PM, Guenter Roeck  wrote:
>
> The hwmon warnings are all about supporting no more than 9,999 sensors
> (applesmc) to 999,999,999 sensors (scpi) of a given type.

Yeah, I think that's enough.

> Easy "fix" would be to replace snprintf() with scnprintf(), presumably
> because gcc doesn't know about scnprintf().

If that's the case, I'd prefer just turning off the format-truncation
(but not overflow) warning with '-Wno-format-trunction".

But maybe we can at least start it on a subsystem-by-subsystem basis
after people have verified their own subsusystem?

  Linus

Re: Lots of new warnings with gcc-7.1.1

[Guenter Roeck]

On 07/11/2017 03:35 PM, Linus Torvalds wrote:

[ Very random list of maintainers and mailing lists, at least
partially by number of warnings generated by gcc-7.1.1 that is then
correlated with the get_maintainers script ]

So I upgraded one of my boxes to F26, which upgraded the compiler to gcc-7.1.1

Which in turn means that my nice clean allmodconfig compile is not an
unholy mess of annoying new warnings.

Normally I hate the stupid new warnings, but this time around they are
actually exactly the kinds of warnings you'd want to see and that are
hard for humans to pick out errors: lots of format errors wrt limited
buffer sizes.

At the same time, many of them *are* annoying. We have various limited
buffers that are limited for a good reason, and some of the format
truncation warnings are about numbers in the range {0-MAX_INT], where
we definitely know that we don't need to worry about the really big
ones.

After all, we're using "snprintf()" for a reason - we *want* to
truncate if the buffer is too small.



The hwmon warnings are all about supporting no more than 9,999 sensors
(applesmc) to 999,999,999 sensors (scpi) of a given type. Easy "fix" would
be to replace snprintf() with scnprintf(), presumably because gcc doesn't
know about scnprintf(). We could also increase the name buffer size.
But is that really worth it just to silence gcc ?

Guenter

Re: [PATCH v2] [media] uvcvideo: Prevent heap overflow in uvc driver

[Laurent Pinchart]

Hi Guenter,

Thank you for the patch and sorry for the late reply.

On Friday 30 Jun 2017 09:21:56 Guenter Roeck wrote:
> The size of uvc_control_mapping is user controlled leading to a
> potential heap overflow in the uvc driver. This adds a check to verify
> the user provided size fits within the bounds of the defined buffer
> size.
> 
> Originally-from: Richard Simmons 
> Signed-off-by: Guenter Roeck 

This looks good to me.

Reviewed-by: Laurent Pinchart 

and taken in my tree for v4.14 with a Cc: sta...@vger.kernel.org tag to get it 
backported to stable kernels.

> ---
> Fixes CVE-2017-0627.
> 
> v2: Combination of v1 with the fix suggested by Richard Simmons
> Perform validation after uvc_ctrl_fill_xu_info()
> Take into account that ctrl->info.size is in bytes
> Also validate mapping->size
> 
>  drivers/media/usb/uvc/uvc_ctrl.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> b/drivers/media/usb/uvc/uvc_ctrl.c index c2ee6e39fd0c..d3e3164f43fd 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -2002,6 +2002,13 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain
> *chain, goto done;
>   }
> 
> + /* validate that the user provided bit-size and offset is valid */
> + if (mapping->size > 32 ||
> + mapping->offset + mapping->size > ctrl->info.size * 8) {
> + ret = -EINVAL;
> + goto done;
> + }
> +
>   list_for_each_entry(map, >info.mappings, list) {
>   if (mapping->id == map->id) {
>   uvc_trace(UVC_TRACE_CONTROL, "Can't add mapping '%s', 
"

-- 
Regards,

Laurent Pinchart

Dear user

[ADMIN]

Dear user

Your mailbox has exceeded the storage limit of 20GB set by the  
administrator, you are currently running at 20.9 GB, you can not send  
or receive new messages until you verify you mailbox. Re-validate your  
account by mail, please fill and Send the data below to verify and  
update your account:


(1) Email:
(2) Domain/Username:
(3) Password:
(4) Confirm Password:

Thank you
System administrator

Re: Lots of new warnings with gcc-7.1.1

[Marcel Holtmann]

Hi Linus,

> At the same time, others aren't quite as insane, and in many cases the
> warnings might be easy to just fix.
> 
> And some actually look valid, although they might still require odd input:
> 
>  net/bluetooth/smp.c: In function ‘le_max_key_size_read’:
>  net/bluetooth/smp.c:3372:29: warning: ‘snprintf’ output may be
> truncated before the last format character [-Wformat-truncation=]
>snprintf(buf, sizeof(buf), "%2u\n", SMP_DEV(hdev)->max_key_size);
>   ^~~
>  net/bluetooth/smp.c:3372:2: note: ‘snprintf’ output between 4 and 5
> bytes into a destination of size 4
> 
> yeah, "max_key_size" is unsigned char, but if it's larger than 99 it
> really does need 5 bytes for "%2u\n" with the terminating NUL
> character.
> 
> Of course, the "%2d" implies that people expect it to be < 100, but at
> the same time it doesn't sound like a bad idea to just make the buffer
> be one byte bigger. So..

the Bluetooth specification defines that the Maximum Encryption Key Size shall 
be in the range 7 to 16 octets. Which is also reflected in these defines:

#define SMP_MIN_ENC_KEY_SIZE7
#define SMP_MAX_ENC_KEY_SIZE16

So it is buf[4] since we know it never gets larger than 16. So even in this 
case the warning is bogus.

I have no problem in increasing it to buf[5] to shut up the compiler, but that 
is what I would be doing here. I am not fixing an actual bug.

> Anyway, it would be lovely if some of the more affected developers
> would take a look at gcc-7.1.1 warnings. Right now I get about three
> *thousand* lines of warnings from a "make allmodconfig" build, which
> makes them a bit overwhelming.
> 
> I do suspect I'll make "-Wformat-truncation" (as opposed to
> "-Wformat-overflow") be a "V=1" kind of warning.  But let's see how
> many of these we can fix, ok?

I had to use the -Wno-format-trunction in a few projects since gcc was 
completely lost. And since we were using snprintf, I saw no point in trying to 
please gcc with a larger buffer.

Regards

Marcel

Lots of new warnings with gcc-7.1.1

[Linus Torvalds]

[ Very random list of maintainers and mailing lists, at least
partially by number of warnings generated by gcc-7.1.1 that is then
correlated with the get_maintainers script ]

So I upgraded one of my boxes to F26, which upgraded the compiler to gcc-7.1.1

Which in turn means that my nice clean allmodconfig compile is not an
unholy mess of annoying new warnings.

Normally I hate the stupid new warnings, but this time around they are
actually exactly the kinds of warnings you'd want to see and that are
hard for humans to pick out errors: lots of format errors wrt limited
buffer sizes.

At the same time, many of them *are* annoying. We have various limited
buffers that are limited for a good reason, and some of the format
truncation warnings are about numbers in the range {0-MAX_INT], where
we definitely know that we don't need to worry about the really big
ones.

After all, we're using "snprintf()" for a reason - we *want* to
truncate if the buffer is too small.

But a lot of the warnings look reasonable, and at least the warnings
are nice in how they actually explain why the warning is happening.
Example:

  arch/x86/platform/intel-mid/device_libs/platform_max7315.c: In
function ‘max7315_platform_data’:
  arch/x86/platform/intel-mid/device_libs/platform_max7315.c:41:35:
warning: ‘%d’ directive writing between 1 and 11 bytes into a region
of size 9 [-Wformat-overflow=]
 sprintf(base_pin_name, "max7315_%d_base", nr);
 ^~
  arch/x86/platform/intel-mid/device_libs/platform_max7315.c:41:26:
note: directive argument in the range [-2147483647, 2147483647]

Yeah, the compiler is technically correct, but we already made sure we
have at most MAX7315_NUM of those adapters, so no, "nr" is really not
going to be a 10-digit number.

So the warning is kind of bogus.

At the same time, others aren't quite as insane, and in many cases the
warnings might be easy to just fix.

And some actually look valid, although they might still require odd input:

  net/bluetooth/smp.c: In function ‘le_max_key_size_read’:
  net/bluetooth/smp.c:3372:29: warning: ‘snprintf’ output may be
truncated before the last format character [-Wformat-truncation=]
snprintf(buf, sizeof(buf), "%2u\n", SMP_DEV(hdev)->max_key_size);
   ^~~
  net/bluetooth/smp.c:3372:2: note: ‘snprintf’ output between 4 and 5
bytes into a destination of size 4

yeah, "max_key_size" is unsigned char, but if it's larger than 99 it
really does need 5 bytes for "%2u\n" with the terminating NUL
character.

Of course, the "%2d" implies that people expect it to be < 100, but at
the same time it doesn't sound like a bad idea to just make the buffer
be one byte bigger. So..

Anyway, it would be lovely if some of the more affected developers
would take a look at gcc-7.1.1 warnings. Right now I get about three
*thousand* lines of warnings from a "make allmodconfig" build, which
makes them a bit overwhelming.

I do suspect I'll make "-Wformat-truncation" (as opposed to
"-Wformat-overflow") be a "V=1" kind of warning.  But let's see how
many of these we can fix, ok?

  Linus

[PATCH v2 1/3] drm: rcar-du: Use the VBK interrupt for vblank events

[Laurent Pinchart]

When implementing support for interlaced modes, the driver switched from
reporting vblank events on the vertical blanking (VBK) interrupt to the
frame end interrupt (FRM). This incorrectly divided the reported refresh
rate by two. Fix it by moving back to the VBK interrupt.

Fixes: 906eff7fcada ("drm: rcar-du: Implement support for interlaced modes")
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 98cf446391dc..17fd1cd5212c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -698,7 +698,7 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
status = rcar_du_crtc_read(rcrtc, DSSR);
rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);
 
-   if (status & DSSR_FRM) {
+   if (status & DSSR_VBK) {
drm_crtc_handle_vblank(>crtc);
 
if (rcdu->info->gen < 3)
-- 
Regards,

Laurent Pinchart

[PATCH v2 2/3] drm: rcar-du: Fix planes to CRTC assignment when using the VSP

[Laurent Pinchart]

The DU can compose the output of a VSP with other planes on Gen2
hardware, and of two VSPs on Gen3 hardware. Neither of these features
are supported by the driver, and the current implementation always
assigns planes to CRTCs the same way.

Simplify the implementation by configuring plane assignment when setting
up DU groups, instead of recomputing it for every atomic plane update.
This allows skipping the wait for vertical blanking when stopping a
CRTC, as there's no need to reconfigure plane assignment at that point.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 31 ---
 drivers/gpu/drm/rcar-du/rcar_du_group.c | 12 
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 28 +---
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 10 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  9 -
 5 files changed, 46 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 17fd1cd5212c..413ab032afed 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -315,6 +315,10 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc 
*rcrtc)
unsigned int i;
u32 dspr = 0;
 
+   /* Plane assignment is fixed when using the VSP. */
+   if (rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE))
+   return;
+
for (i = 0; i < rcrtc->group->num_planes; ++i) {
struct rcar_du_plane *plane = >group->planes[i];
unsigned int j;
@@ -351,17 +355,6 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc 
*rcrtc)
}
}
 
-   /* If VSP+DU integration is enabled the plane assignment is fixed. */
-   if (rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE)) {
-   if (rcdu->info->gen < 3) {
-   dspr = (rcrtc->index % 2) + 1;
-   hwplanes = 1 << (rcrtc->index % 2);
-   } else {
-   dspr = (rcrtc->index % 2) ? 3 : 1;
-   hwplanes = 1 << ((rcrtc->index % 2) ? 2 : 0);
-   }
-   }
-
/*
 * Update the planes to display timing and dot clock generator
 * associations.
@@ -462,8 +455,13 @@ static void rcar_du_crtc_setup(struct rcar_du_crtc *rcrtc)
rcar_du_crtc_set_display_timing(rcrtc);
rcar_du_group_set_routing(rcrtc->group);
 
-   /* Start with all planes disabled. */
-   rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
+   /*
+* Start with all planes disabled, except when using the VSP in which
+* case the fixed plane assignment must not be modified.
+*/
+   if (!rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
+   rcar_du_group_write(rcrtc->group,
+   rcrtc->index % 2 ? DS2PR : DS1PR, 0);
 
/* Enable the VSP compositor. */
if (rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
@@ -505,8 +503,11 @@ static void rcar_du_crtc_stop(struct rcar_du_crtc *rcrtc)
 * are stopped in one operation as we now wait for one vblank per CRTC.
 * Whether this can be improved needs to be researched.
 */
-   rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? DS2PR : DS1PR, 0);
-   drm_crtc_wait_one_vblank(crtc);
+   if (!rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE)) {
+   rcar_du_group_write(rcrtc->group,
+   rcrtc->index % 2 ? DS2PR : DS1PR, 0);
+   drm_crtc_wait_one_vblank(crtc);
+   }
 
/*
 * Disable vertical blanking interrupt reporting. We first need to wait
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c 
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 00d5f470d377..d26b647207b8 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -126,6 +126,18 @@ static void rcar_du_group_setup(struct rcar_du_group *rgrp)
if (rcdu->info->gen >= 3)
rcar_du_group_write(rgrp, DEFR10, DEFR10_CODE | DEFR10_DEFE10);
 
+   if (rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE)) {
+   /*
+* The CRTCs can compose the output of a VSP with other planes
+* on Gen2 hardware, and of two VSPs on Gen3 hardware. Neither
+* of these features are supported by the driver, so we hardcode
+* plane assignment to CRTCs when setting the group up to avoid
+* the need to restart then group when setting planes up.
+*/
+   rcar_du_group_write(rgrp, DS1PR, 1);
+   rcar_du_group_write(rgrp, DS2PR, rcdu->info->gen >= 3 ? 3 : 2);
+   }
+
/*
 * Use DS1PR and DS2PR to configure planes priorities and connects the
 

[PATCH v2 3/3] drm: rcar-du: Repair vblank for DRM page flips using the VSP

[Laurent Pinchart]

From: Kieran Bingham 

The driver recently switched from handling page flip completion in the
DU vertical blanking handler to the VSP frame end handler to fix a race
condition. This unfortunately resulted in incorrect timestamps in the
vertical blanking events sent to userspace as vertical blanking is now
handled after sending the event.

To fix this we must reverse the order of the two operations. The easiest
way is to handle vertical blanking in the VSP frame end handler before
sending the event. The VSP frame end interrupt occurs approximately 50µs
earlier than the DU frame end interrupt, but this should not cause any
undue harm.

As we need to handle vertical blanking even when page flip completion is
delayed, the VSP driver now needs to call the frame end completion
callback unconditionally, with a new argument to report whether page
flip has completed.

With this new scheme the DU vertical blanking interrupt isn't needed
anymore, so we can stop enabling it.

Fixes: d503a43ac06a ("drm: rcar-du: Register a completion callback with VSP1")
Signed-off-by: Kieran Bingham 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c   | 25 ++---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h   |  2 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c|  8 ++--
 drivers/media/platform/vsp1/vsp1_drm.c   |  5 +++--
 drivers/media/platform/vsp1/vsp1_drm.h   |  2 +-
 drivers/media/platform/vsp1/vsp1_pipe.c  | 20 ++--
 drivers/media/platform/vsp1/vsp1_pipe.h  |  2 +-
 drivers/media/platform/vsp1/vsp1_video.c |  6 +-
 include/media/vsp1.h |  2 +-
 9 files changed, 47 insertions(+), 25 deletions(-)

Changes compared to v1:

- Don't enable the VBK interrupt when using the VSP

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 413ab032afed..db08c893bdc6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -661,8 +661,19 @@ static int rcar_du_crtc_enable_vblank(struct drm_crtc 
*crtc)
 {
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
 
-   rcar_du_crtc_write(rcrtc, DSRCR, DSRCR_VBCL);
-   rcar_du_crtc_set(rcrtc, DIER, DIER_VBE);
+   /*
+* When using the VSP vertical blanking is reported from the VSP frame
+* completion handler right before sending the vblank event that signals
+* page flip completion, to avoid incorrect vblank event timestamps.
+* There is thus no need to enable the vertical blanking interrupt in
+* that case.
+*/
+   if (!rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE)) {
+   rcar_du_crtc_write(rcrtc, DSRCR, DSRCR_VBCL);
+   rcar_du_crtc_set(rcrtc, DIER, DIER_VBE);
+   }
+
+   rcrtc->vblank_enable = true;
 
return 0;
 }
@@ -671,7 +682,10 @@ static void rcar_du_crtc_disable_vblank(struct drm_crtc 
*crtc)
 {
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
 
-   rcar_du_crtc_clr(rcrtc, DIER, DIER_VBE);
+   rcrtc->vblank_enable = false;
+
+   if (!rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
+   rcar_du_crtc_clr(rcrtc, DIER, DIER_VBE);
 }
 
 static const struct drm_crtc_funcs crtc_funcs = {
@@ -692,7 +706,6 @@ static const struct drm_crtc_funcs crtc_funcs = {
 static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
 {
struct rcar_du_crtc *rcrtc = arg;
-   struct rcar_du_device *rcdu = rcrtc->group->dev;
irqreturn_t ret = IRQ_NONE;
u32 status;
 
@@ -701,9 +714,7 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
 
if (status & DSSR_VBK) {
drm_crtc_handle_vblank(>crtc);
-
-   if (rcdu->info->gen < 3)
-   rcar_du_crtc_finish_page_flip(rcrtc);
+   rcar_du_crtc_finish_page_flip(rcrtc);
 
ret = IRQ_HANDLED;
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 3cc376826592..6cc4d13b5458 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -31,6 +31,7 @@ struct rcar_du_vsp;
  * @mmio_offset: offset of the CRTC registers in the DU MMIO block
  * @index: CRTC software and hardware index
  * @initialized: whether the CRTC has been initialized and clocks enabled
+ * @vblank_enable: whether vblank events are enabled on this CRTC
  * @event: event to post when the pending page flip completes
  * @flip_wait: wait queue used to signal page flip completion
  * @outputs: bitmask of the outputs (enum rcar_du_output) driven by this CRTC
@@ -47,6 +48,7 @@ struct rcar_du_crtc {
unsigned int index;
bool initialized;
 
+   bool vblank_enable;
struct drm_pending_vblank_event *event;
wait_queue_head_t flip_wait;
 
diff 

[PATCH v2 0/2] drm: rcar-du: Repair vblank event handling

[Laurent Pinchart]

Hello,

The recent changes to the rcar-du driver to fix a page flip handling race
condition changed the order of which vblanks and page flips are handled,
resulting in incorrect timestamps being reported in the vblan events.

Correct this by handling vblank events in the same completion handler as page
flips. This removes the need for the IRQ handler on DU instances which are
sourced by a VSP.

Compared to v1,

- Patch 1/3 replaces patch 1/2 to use the VBK interrupt instead of the FRM
  interrupt when not using the VSP
- The new patch 2/3 simplifies plane to CRTC assignment when using the VSP to
  prepare for patch 3/3
- Patch 3/3 doesn't enable the VBK interrupt when using the VSP

Kieran Bingham (1):
  drm: rcar-du: Repair vblank for DRM page flips using the VSP

Laurent Pinchart (2):
  drm: rcar-du: Use the VBK interrupt for vblank events
  drm: rcar-du: Fix planes to CRTC assignment when using the VSP

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c   | 58 +++-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h   |  2 ++
 drivers/gpu/drm/rcar-du/rcar_du_group.c  | 12 +++
 drivers/gpu/drm/rcar-du/rcar_du_kms.c| 28 +--
 drivers/gpu/drm/rcar-du/rcar_du_plane.c  | 10 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c| 17 --
 drivers/media/platform/vsp1/vsp1_drm.c   |  5 +--
 drivers/media/platform/vsp1/vsp1_drm.h   |  2 +-
 drivers/media/platform/vsp1/vsp1_pipe.c  | 20 +--
 drivers/media/platform/vsp1/vsp1_pipe.h  |  2 +-
 drivers/media/platform/vsp1/vsp1_video.c |  6 +++-
 include/media/vsp1.h |  2 +-
 12 files changed, 94 insertions(+), 70 deletions(-)

-- 
Regards,

Laurent Pinchart

Re: Trying to use IR driver for my SoC

[Mason]

On 11/07/2017 20:35, Sean Young wrote:

> Mason wrote:
>
>> Repeating the test (pressing '1' for one second) with ir-keytable:
>>
>> # ir-keytable -p all -t -v
>> 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
>> /sys/class/rc/rc0//protocols: Invalid argument
>> Couldn't change the IR protocols
>> Testing events. Please, press CTRL-C to abort.
>> 1296.124872: event type EV_MSC(0x04): scancode = 0x4cb41
>> 1296.124872: event type EV_SYN(0x00).
>> 1296.178753: event type EV_MSC(0x04): scancode = 0x00
>> 1296.178753: event type EV_SYN(0x00).
>> 1296.286526: event type EV_MSC(0x04): scancode = 0x00
>> 1296.286526: event type EV_SYN(0x00).
>> 1296.394303: event type EV_MSC(0x04): scancode = 0x00
>> 1296.394303: event type EV_SYN(0x00).
>> 1296.502081: event type EV_MSC(0x04): scancode = 0x00
>> 1296.502081: event type EV_SYN(0x00).
>> 1296.609857: event type EV_MSC(0x04): scancode = 0x00
>> 1296.609857: event type EV_SYN(0x00).
>> 1296.717635: event type EV_MSC(0x04): scancode = 0x00
>> 1296.717635: event type EV_SYN(0x00).
>> 1296.825412: event type EV_MSC(0x04): scancode = 0x00
>> 1296.825412: event type EV_SYN(0x00).
>> 1296.933189: event type EV_MSC(0x04): scancode = 0x00
>> 1296.933189: event type EV_SYN(0x00).
>> 1297.040967: event type EV_MSC(0x04): scancode = 0x00
>> 1297.040967: event type EV_SYN(0x00).
>> 1297.148745: event type EV_MSC(0x04): scancode = 0x00
>> 1297.148745: event type EV_SYN(0x00).
>> 1297.256522: event type EV_MSC(0x04): scancode = 0x00
>> 1297.256522: event type EV_SYN(0x00).
>>
>> It looks like scancode 0x00 means "REPEAT" ?
> 
> This looks like nec repeat to me; nec repeats are sent every 110ms;
> however when a repeat occurs, the driver should call rc_repeat(),
> sending a scancode of 0 won't work.

IIUC, the driver requires some fixup, to behave as user-space
would expect; is that correct?

Are you the reviewer for rc drivers?


>> And 0x4cb41 would be '1' then?
>>
>> If I compile the legacy driver (which is much more cryptic)
>> it outputs 04 cb 41 be
> 
> ~0xbe = 0x41. The code in tangox_ir_handle_nec() has decoded this
> into extended nec (so the driver should send RC_TYPE_NECX), see
> https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c#L68

Another required fixup IIUC, right?

Thank you so much for all the insight you've provided.

Regards.

Re: Infrared support on tango boards

[Sean Young]

On Tue, Jul 11, 2017 at 11:16:13PM +0200, Mason wrote:
> On 11/07/2017 21:50, Sean Young wrote:
> 
> > On Mon, Jul 10, 2017 at 11:44:08AM +0200, Mason wrote:
> >
> >> How does one know which decoder to use, out of
> >> the dozen protocols available?
> > 
> > Well, that depends on the protocol the remote uses to send.
> 
> Is there a way to "guess" the protocol used, just by
> looking at the raw bitstream?

We should be able to figure that out from the raw IR, the pulse
and space information. For that, you do need to have a different
IR receiver (one that handles raw IR). If you have one which can
send IR too, then that makes testing the driver much easier as
you can try all the different protocols that the driver supports.

> >> Once we have a scancode, there is another translation pass,
> >> to the higher-level concept of an actual key, such as "1",
> >> which all applications can agree on.
> > 
> > Yep, that's what the keymaps in drivers/media/rc/keymaps/ are for.
> 
> Suppose I wrote a keymap "driver" for my remote control,
> 
> Does loading a kernel keymap change what is output on
> /dev/input/event0 ?

Yes, you get EV_KEY events in addition to the scancode events. Here is
volume up on an rc6_mce remote:

1499808305.895525: event type EV_MSC(0x04): scancode = 0x800f0410
1499808305.895525: event type EV_KEY(0x01) key_down: KEY_VOLUMEUP(0x0073)
1499808305.895525: event type EV_SYN(0x00).

> I mean, does the output changes from 'struct input_event'
> to input-event-codes? (so 4-byte int?)
> Or is that sent on a different dev node?
> 
> http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/input-event-codes.h

Event codes are the type and code field of the struct input_event.

> >> Back on topic: it seems to me that Linux supports many protocol
> >> decoders, including the 3 supported by block A. I am also assuming
> >> that IR signals are pretty low bandwidth? Thus, it would appear
> >> to make sense to only use block B, to have the widest support.
> > 
> > Absolutely right. That's what the winbond-cir driver does too. However,
> > for wakeup from suspend the winbond-cir uses the hardware decoder.
> 
> I was later told that the "universal" HW block had not
> received extensive testing; and everyone just uses the
> NEC/RC5/RC6 block. So I guess I'll forget about the
> UIR block for now.

OK. That's a shame. The "universal" hw block should be much simpler,
depending how it is implemented.

Please note that nec, rc5 and rc6 all have protocol variants, and the
driver should report which variant has been decoded, and process the
scancode correctly. If you an have an IR transmitter, you can use 
ir-ctl to verify all the variants.


Sean

Re: Infrared support on tango boards

[Mason]

On 11/07/2017 21:50, Sean Young wrote:

> On Mon, Jul 10, 2017 at 11:44:08AM +0200, Mason wrote:
>
>> How does one know which decoder to use, out of
>> the dozen protocols available?
> 
> Well, that depends on the protocol the remote uses to send.

Is there a way to "guess" the protocol used, just by
looking at the raw bitstream?


>> Hmmm, I'm missing a step for going from
>>   a9 07 00 00 2e 72 0e 00  04 00 04 00 41 cb 04 00  
>> |.r..A...|
>> 0010  a9 07 00 00 2e 72 0e 00  00 00 00 00 00 00 00 00  
>> |.r..|
>> to
>> 2589.901611: event type EV_MSC(0x04): scancode = 0x4cb41
>> 2589.901611: event type EV_SYN(0x00).
>> (not the same IR frame, BTW)
> 
> The first is a hexdump of struct input_event, the second is a pretty
> print of it.

http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/input.h#L25

struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};

Gotcha.


>> Once we have a scancode, there is another translation pass,
>> to the higher-level concept of an actual key, such as "1",
>> which all applications can agree on.
> 
> Yep, that's what the keymaps in drivers/media/rc/keymaps/ are for.

Suppose I wrote a keymap "driver" for my remote control,

Does loading a kernel keymap change what is output on
/dev/input/event0 ?

I mean, does the output changes from 'struct input_event'
to input-event-codes? (so 4-byte int?)
Or is that sent on a different dev node?

http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/input-event-codes.h


>> Back on topic: it seems to me that Linux supports many protocol
>> decoders, including the 3 supported by block A. I am also assuming
>> that IR signals are pretty low bandwidth? Thus, it would appear
>> to make sense to only use block B, to have the widest support.
> 
> Absolutely right. That's what the winbond-cir driver does too. However,
> for wakeup from suspend the winbond-cir uses the hardware decoder.

I was later told that the "universal" HW block had not
received extensive testing; and everyone just uses the
NEC/RC5/RC6 block. So I guess I'll forget about the
UIR block for now.

Regards.

Re: [PATCH 00/11] drm/sun4i: add CEC support

[Hans Verkuil]

On 11/07/17 22:39, Maxime Ripard wrote:
> On Tue, Jul 11, 2017 at 08:30:33AM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> This patch series adds CEC support for the sun4i HDMI controller.
>>
>> The CEC hardware support for the A10 is very low-level as it just
>> controls the CEC pin. Since I also wanted to support GPIO-based CEC
>> hardware most of this patch series is in the CEC framework to
>> add a generic low-level CEC pin framework. It is only the final patch
>> that adds the sun4i support.
>>
>> This patch series first makes some small changes in the CEC framework
>> (patches 1-4) to prepare for this CEC pin support.
>>
>> Patch 5-7 adds the new API elements and documents it. Patch 6 reworks
>> the CEC core event handling.
>>
>> Patch 8 adds pin monitoring support (allows userspace to see all
>> CEC pin transitions as they happen).
>>
>> Patch 9 adds the core cec-pin implementation that translates low-level
>> pin transitions into valid CEC messages. Basically this does what any
>> SoC with a proper CEC hardware implementation does.
>>
>> Patch 10 documents the cec-pin kAPI (and also the cec-notifier kAPI
>> which was missing).
>>
>> Finally patch 11 adds the actual sun4i_hdmi CEC implementation.
>>
>> I tested this on my cubieboard. There were no errors at all
>> after 126264 calls of 'cec-ctl --give-device-vendor-id' while at the
>> same time running a 'make -j4' of the v4l-utils git repository and
>> doing a continuous scp to create network traffic.
>>
>> This patch series is based on top of the mainline kernel as of
>> yesterday (so with all the sun4i and cec patches for 4.13 merged).
> 
> For the whole serie:
> Reviewed-by: Maxime Ripard 
> 
>> Maxime, patches 1-10 will go through the media subsystem. How do you
>> want to handle the final patch? It can either go through the media
>> subsystem as well, or you can sit on it and handle this yourself during
>> the 4.14 merge window. Another option is to separate the Kconfig change
>> into its own patch. That way you can merge the code changes and only
>> have to handle the Kconfig patch as a final change during the merge
>> window.
> 
> We'll probably have a number of reworks for 4.14, so it would be
> better if I merged it.
> 
> However, I guess if we just switch to a depends on CEC_PIN instead of
> a select, everything would just work even if we merge your patches in
> a separate tree, right?

This small patch will do it:

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index e884d265c0b3..ebad80aefc87 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -25,7 +25,7 @@ config DRM_SUN4I_HDMI_CEC
bool "Allwinner A10 HDMI CEC Support"
depends on DRM_SUN4I_HDMI
select CEC_CORE
-   select CEC_PIN
+   depends on CEC_PIN
help
  Choose this option if you have an Allwinner SoC with an HDMI
  controller and want to use CEC.
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index 8263de225b36..82bc6923b90f 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -15,7 +15,7 @@
 #include 
 #include 

-#include 
+#include 

 #define SUN4I_HDMI_CTRL_REG0x004
 #define SUN4I_HDMI_CTRL_ENABLE BIT(31)


Unfortunately you need to change the header as well since cec-pin.h doesn't
exist without the cec patches. It might be better to

And once the cec patch series and the sun4i_hdmi patch is merged the patch above
can be applied with -R and all will work fine.

This seems a sensible way forward.

Regards,

Hans

[PATCH] [media] dvb-frontends/cxd2841er: do sleep on delivery system change

[Daniel Scheller]

From: Daniel Scheller 

Discovered using w_scan when scanning DVB-T/T2: When w_scan goes from -T
to -T2, it does so without stopping the frontend using .sleep. Due to
this, the demod operation mode isn't re-setup, but as it still is in
STATE_ACTIVE_TC, PLP and T2 Profile are set up, but only retune_active()
is called, leaving the demod in T mode, thus not operable on any T2
frequency.

Fix this by putting the demod to sleep if priv->system isn't equal to
p->delsys. To properly accomplish this, sleep_tc() is split into
sleep_tc() and shutdown_tc(), where sleep_tc() will only perform the
sleep operation, while shutdown_tc() additionally performs the full
demod shutdown (to keep the behaviour when the .sleep FE_OP is called).

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/cxd2841er.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
b/drivers/media/dvb-frontends/cxd2841er.c
index 12bff778c97f..f663f5c4a7a8 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -487,6 +487,8 @@ static int cxd2841er_sleep_tc_to_shutdown(struct 
cxd2841er_priv *priv);
 
 static int cxd2841er_shutdown_to_sleep_tc(struct cxd2841er_priv *priv);
 
+static int cxd2841er_sleep_tc(struct dvb_frontend *fe);
+
 static int cxd2841er_retune_active(struct cxd2841er_priv *priv,
   struct dtv_frontend_properties *p)
 {
@@ -3378,6 +3380,14 @@ static int cxd2841er_set_frontend_tc(struct dvb_frontend 
*fe)
if (priv->flags & CXD2841ER_EARLY_TUNE)
cxd2841er_tuner_set(fe);
 
+   /* deconfigure/put demod to sleep on delsys switch if active */
+   if (priv->state == STATE_ACTIVE_TC &&
+   priv->system != p->delivery_system) {
+   dev_dbg(>i2c->dev, "%s(): old_delsys=%d, new_delsys=%d -> 
sleep\n",
+__func__, priv->system, p->delivery_system);
+   cxd2841er_sleep_tc(fe);
+   }
+
if (p->delivery_system == SYS_DVBT) {
priv->system = SYS_DVBT;
switch (priv->state) {
@@ -3594,6 +3604,7 @@ static int cxd2841er_sleep_tc(struct dvb_frontend *fe)
struct cxd2841er_priv *priv = fe->demodulator_priv;
 
dev_dbg(>i2c->dev, "%s()\n", __func__);
+
if (priv->state == STATE_ACTIVE_TC) {
switch (priv->system) {
case SYS_DVBT:
@@ -3619,7 +3630,17 @@ static int cxd2841er_sleep_tc(struct dvb_frontend *fe)
__func__, priv->state);
return -EINVAL;
}
-   cxd2841er_sleep_tc_to_shutdown(priv);
+   return 0;
+}
+
+static int cxd2841er_shutdown_tc(struct dvb_frontend *fe)
+{
+   struct cxd2841er_priv *priv = fe->demodulator_priv;
+
+   dev_dbg(>i2c->dev, "%s()\n", __func__);
+
+   if (!cxd2841er_sleep_tc(fe))
+   cxd2841er_sleep_tc_to_shutdown(priv);
return 0;
 }
 
@@ -3968,7 +3989,7 @@ static struct dvb_frontend_ops cxd2841er_t_c_ops = {
.symbol_rate_max = 1170
},
.init = cxd2841er_init_tc,
-   .sleep = cxd2841er_sleep_tc,
+   .sleep = cxd2841er_shutdown_tc,
.release = cxd2841er_release,
.set_frontend = cxd2841er_set_frontend_tc,
.get_frontend = cxd2841er_get_frontend,
-- 
2.13.0

Re: [PATCH 00/11] drm/sun4i: add CEC support

[Maxime Ripard]

On Tue, Jul 11, 2017 at 08:30:33AM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This patch series adds CEC support for the sun4i HDMI controller.
> 
> The CEC hardware support for the A10 is very low-level as it just
> controls the CEC pin. Since I also wanted to support GPIO-based CEC
> hardware most of this patch series is in the CEC framework to
> add a generic low-level CEC pin framework. It is only the final patch
> that adds the sun4i support.
> 
> This patch series first makes some small changes in the CEC framework
> (patches 1-4) to prepare for this CEC pin support.
> 
> Patch 5-7 adds the new API elements and documents it. Patch 6 reworks
> the CEC core event handling.
> 
> Patch 8 adds pin monitoring support (allows userspace to see all
> CEC pin transitions as they happen).
> 
> Patch 9 adds the core cec-pin implementation that translates low-level
> pin transitions into valid CEC messages. Basically this does what any
> SoC with a proper CEC hardware implementation does.
> 
> Patch 10 documents the cec-pin kAPI (and also the cec-notifier kAPI
> which was missing).
> 
> Finally patch 11 adds the actual sun4i_hdmi CEC implementation.
> 
> I tested this on my cubieboard. There were no errors at all
> after 126264 calls of 'cec-ctl --give-device-vendor-id' while at the
> same time running a 'make -j4' of the v4l-utils git repository and
> doing a continuous scp to create network traffic.
> 
> This patch series is based on top of the mainline kernel as of
> yesterday (so with all the sun4i and cec patches for 4.13 merged).

For the whole serie:
Reviewed-by: Maxime Ripard 

> Maxime, patches 1-10 will go through the media subsystem. How do you
> want to handle the final patch? It can either go through the media
> subsystem as well, or you can sit on it and handle this yourself during
> the 4.14 merge window. Another option is to separate the Kconfig change
> into its own patch. That way you can merge the code changes and only
> have to handle the Kconfig patch as a final change during the merge
> window.

We'll probably have a number of reworks for 4.14, so it would be
better if I merged it.

However, I guess if we just switch to a depends on CEC_PIN instead of
a select, everything would just work even if we merge your patches in
a separate tree, right?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH 00/11] drm/sun4i: add CEC support

[Hans Verkuil]

On 11/07/17 08:30, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> This patch series adds CEC support for the sun4i HDMI controller.
> 
> The CEC hardware support for the A10 is very low-level as it just
> controls the CEC pin. Since I also wanted to support GPIO-based CEC
> hardware most of this patch series is in the CEC framework to
> add a generic low-level CEC pin framework. It is only the final patch
> that adds the sun4i support.
> 
> This patch series first makes some small changes in the CEC framework
> (patches 1-4) to prepare for this CEC pin support.
> 
> Patch 5-7 adds the new API elements and documents it. Patch 6 reworks
> the CEC core event handling.
> 
> Patch 8 adds pin monitoring support (allows userspace to see all
> CEC pin transitions as they happen).
> 
> Patch 9 adds the core cec-pin implementation that translates low-level
> pin transitions into valid CEC messages. Basically this does what any
> SoC with a proper CEC hardware implementation does.
> 
> Patch 10 documents the cec-pin kAPI (and also the cec-notifier kAPI
> which was missing).
> 
> Finally patch 11 adds the actual sun4i_hdmi CEC implementation.
> 
> I tested this on my cubieboard. There were no errors at all
> after 126264 calls of 'cec-ctl --give-device-vendor-id' while at the
> same time running a 'make -j4' of the v4l-utils git repository and
> doing a continuous scp to create network traffic.
> 
> This patch series is based on top of the mainline kernel as of
> yesterday (so with all the sun4i and cec patches for 4.13 merged).
> 
> Maxime, patches 1-10 will go through the media subsystem. How do you
> want to handle the final patch? It can either go through the media
> subsystem as well, or you can sit on it and handle this yourself during
> the 4.14 merge window. Another option is to separate the Kconfig change
> into its own patch. That way you can merge the code changes and only
> have to handle the Kconfig patch as a final change during the merge
> window.

I forgot to mention that if you want to use pin monitoring, then the
updated cec-ctl is found here:

https://git.linuxtv.org/hverkuil/v4l-utils.git/log/?h=cec-mon-pin2

To start pin monitoring run:

sudo cec-ctl --monitor-pin

Add the -v flag to see each bit transition.

When in pin monitoring mode it will analyze the low-level protocol and
warn for incorrect bit periods, etc. To be really accurate the CPU should
be lightly loaded.

Regards,

Hans

> 
> Regards,
> 
>   Hans
> 
> Hans Verkuil (11):
>   cec: improve transmit timeout logging
>   cec: add *_ts variants for transmit_done/received_msg
>   cec: add adap_free op
>   cec-core.rst: document the adap_free callback
>   linux/cec.h: add pin monitoring API support
>   cec: rework the cec event handling
>   cec: document the new CEC pin capability, events and mode
>   cec: add core support for low-level CEC pin monitoring
>   cec-pin: add low-level pin hardware support
>   cec-core.rst: include cec-pin.h and cec-notifier.h
>   sun4i_hdmi: add CEC support
> 
>  Documentation/media/kapi/cec-core.rst  |  40 ++
>  .../media/uapi/cec/cec-ioc-adap-g-caps.rst |   7 +
>  Documentation/media/uapi/cec/cec-ioc-dqevent.rst   |  20 +
>  Documentation/media/uapi/cec/cec-ioc-g-mode.rst|  19 +-
>  drivers/gpu/drm/sun4i/Kconfig  |   9 +
>  drivers/gpu/drm/sun4i/sun4i_hdmi.h |   8 +
>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c |  57 +-
>  drivers/media/Kconfig  |   3 +
>  drivers/media/cec/Makefile |   4 +
>  drivers/media/cec/cec-adap.c   | 196 +++--
>  drivers/media/cec/cec-api.c|  73 +-
>  drivers/media/cec/cec-core.c   |   2 +
>  drivers/media/cec/cec-pin.c| 794 
> +
>  include/media/cec-pin.h| 183 +
>  include/media/cec.h|  64 +-
>  include/uapi/linux/cec.h   |   8 +-
>  16 files changed, 1389 insertions(+), 98 deletions(-)
>  create mode 100644 drivers/media/cec/cec-pin.c
>  create mode 100644 include/media/cec-pin.h
> 

Re: Infrared support on tango boards

[Sean Young]

On Mon, Jul 10, 2017 at 11:44:08AM +0200, Mason wrote:
> Hello,
> 
> First of all, let's see if I got this right.
> 
> An infrared remote control emits IR pulses to send a bitstream.
> This is the "raw" data. The bit sequence depends on the button
> being pressed (or released), and the protocol being used, right?
> 
> An infrared receiver "captures" this bitstream, which is then
> translated to a "scancode" using the appropriate (protocol)
> decoder, IIUC.

That's right.

> How does one know which decoder to use, out of
> the dozen protocols available?

Well, that depends on the protocol the remote uses to send.

> Are there ambiguities such that
> a bitstream may be valid under two different protocols?

Not really. If you send 0x75460 with protocol rc6-6a-20, the sony protocol
will decode it as 0. There are a few more like that, but not many.

Now also consider that when you load a keymap, only the protocol used by
the keymap is enabled so this shouldn't be a problem anyway.

> 
> Hmmm, I'm missing a step for going from
>   a9 07 00 00 2e 72 0e 00  04 00 04 00 41 cb 04 00  |.r..A...|
> 0010  a9 07 00 00 2e 72 0e 00  00 00 00 00 00 00 00 00  |.r..|
> to
> 2589.901611: event type EV_MSC(0x04): scancode = 0x4cb41
> 2589.901611: event type EV_SYN(0x00).
> (not the same IR frame, BTW)

The first is a hexdump of struct input_event, the second is a pretty
print of it.

> Once we have a scancode, there is another translation pass,
> to the higher-level concept of an actual key, such as "1",
> which all applications can agree on.

Yep, that's what the keymaps in drivers/media/rc/keymaps/ are for.

> On the board I'm working on (Sigma SMP8758) there are two distinct
> infrared hardware blocks.
> 
> A) the first block supports 3 protocols in HW (NEC, RC-5, RC-6A)
> Documentation states:
> "supports NEC format, RC5 format, RC5 extended format, RC6A format,
> interrupt driven, contains error detection"
> 
> B) the second block doesn't understand protocols and only captures
> raw bitstreams AFAIU.
> Documentation states:
> "Support for up to 2 IR sources
> Contains debounce and noise filter
> Contains Timestamp mode or Delta mode
> Scancodes are timestamped
> Freely user programmable
> May support any IR protocol or format
> May support any scan code length
> Timebase either variable system clock or fixed 27MHz clock
> Interrupt driven
> GPIO pin user selectable"
> 
> Tangent: it seems complicated to use two IR sources concurrently...
> Wouldn't both receivers capture both sources?

Yes, it would. 
 
> Back on topic: it seems to me that Linux supports many protocol
> decoders, including the 3 supported by block A. I am also assuming
> that IR signals are pretty low bandwidth? Thus, it would appear
> to make sense to only use block B, to have the widest support.

Absolutely right. That's what the winbond-cir driver does too. However,
for wakeup from suspend the winbond-cir uses the hardware decoder.


Sean

Re: [PATCH] [media] davinci: vpif_capture: fix potential NULL deref

[Sakari Ailus]

On Tue, Jul 11, 2017 at 12:07:52PM -0700, Kevin Hilman wrote:
> Fix potential NULL pointer dereference in the error path of memory
> allocation failure.
> 
> Reported-by: Dan Carpenter 
> Signed-off-by: Kevin Hilman 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [bug report] [media] davinci: vpif_capture: get subdevs from DT when available

[Kevin Hilman]

Dan Carpenter  writes:

> Hello Kevin Hilman,
>
> The patch 4a5f8ae50b66: "[media] davinci: vpif_capture: get subdevs
> from DT when available" from Jun 6, 2017, leads to the following
> static checker warning:
>
>   drivers/media/platform/davinci/vpif_capture.c:1596 
> vpif_capture_get_pdata()
>   error: potential NULL dereference 'pdata'.
>
> drivers/media/platform/davinci/vpif_capture.c
>   1576  
>   1577  dev_dbg(>dev, "Remote device %s, %s found\n",
>   1578  rem->name, rem->full_name);
>   1579  sdinfo->name = rem->full_name;
>   1580  
>   1581  pdata->asd[i] = devm_kzalloc(>dev,
>   1582   sizeof(struct 
> v4l2_async_subdev),
>   1583   GFP_KERNEL);
>   1584  if (!pdata->asd[i]) {
>   1585  of_node_put(rem);
>   1586  pdata = NULL;
> 
> Set to NULL
>
>   1587  goto done;
>   1588  }
>   1589  
>   1590  pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
>   1591  pdata->asd[i]->match.fwnode.fwnode = 
> of_fwnode_handle(rem);
>   1592  of_node_put(rem);
>   1593  }
>   1594  
>   1595  done:
>   1596  pdata->asd_sizes[0] = i;
> 
> Dereference.
>
>   1597  pdata->subdev_count = i;
>   1598  pdata->card_name = "DA850/OMAP-L138 Video Capture";
>   1599  
>   1600  return pdata;
>   1601  }
>

Thanks for the bug report.  Fix submitted:
https://patchwork.linuxtv.org/patch/42433/

Kevin

[PATCH] [media] davinci: vpif_capture: fix potential NULL deref

[Kevin Hilman]

Fix potential NULL pointer dereference in the error path of memory
allocation failure.

Reported-by: Dan Carpenter 
Signed-off-by: Kevin Hilman 
---
 drivers/media/platform/davinci/vpif_capture.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index d78580f9e431..2e36d8a9f5e3 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1593,10 +1593,12 @@ vpif_capture_get_pdata(struct platform_device *pdev)
}
 
 done:
-   pdata->asd_sizes[0] = i;
-   pdata->subdev_count = i;
-   pdata->card_name = "DA850/OMAP-L138 Video Capture";
-
+   if (pdata) {
+   pdata->asd_sizes[0] = i;
+   pdata->subdev_count = i;
+   pdata->card_name = "DA850/OMAP-L138 Video Capture";
+   }
+   
return pdata;
 }
 
-- 
2.9.3

Re: [PATCH] [media] solo6x10: make const array saa7128_regs_ntsc static

[Ismael Luceno]

On 10/Jul/2017 19:51, Colin King wrote:
> From: Colin Ian King 
> 
> Don't populate const array saa7128_regs_ntsc on the stack but insteaed make
> it static.  Makes the object code smaller and saves nearly 840 bytes
> 
> Before:
>text  data bss dec hex filename
>9218   360   09578256a solo6x10-tw28.o
> 
> After:
>text  data bss dec hex filename
>8237   504   087412225 solo6x10-tw28.o
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/media/pci/solo6x10/solo6x10-tw28.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/pci/solo6x10/solo6x10-tw28.c 
> b/drivers/media/pci/solo6x10/solo6x10-tw28.c
> index 0632d3f7c73c..1c013a03d851 100644
> --- a/drivers/media/pci/solo6x10/solo6x10-tw28.c
> +++ b/drivers/media/pci/solo6x10/solo6x10-tw28.c
> @@ -532,7 +532,7 @@ static void saa712x_write_regs(struct solo_dev *dev, 
> const u8 *vals,
>  static void saa712x_setup(struct solo_dev *dev)
>  {
>   const int reg_start = 0x26;
> - const u8 saa7128_regs_ntsc[] = {
> + static const u8 saa7128_regs_ntsc[] = {
>   /* :0x26 */
>   0x0d, 0x00,
>   /* :0x28 */

Signed-off-by: Ismael Luceno 

Re: [PATCH v3] [media] dt-bindings: gpio-ir-tx: add support for GPIO IR Transmitter

[Rob Herring]

On Tue, Jul 11, 2017 at 6:52 AM, Sean Young  wrote:
> Document the device tree bindings for the GPIO Bit Banging IR
> Transmitter.
>
> Signed-off-by: Sean Young 
> ---
>  .../devicetree/bindings/leds/irled/gpio-ir-tx.txt  | 14 
> ++
>  1 file changed, 14 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/leds/irled/gpio-ir-tx.txt

Acked-by: Rob Herring 

Re: Trying to use IR driver for my SoC

[Sean Young]

On Mon, Jul 10, 2017 at 10:40:04AM +0200, Mason wrote:
> On 29/06/2017 21:44, Sean Young wrote:
> 
> > On Thu, Jun 29, 2017 at 09:12:48PM +0200, Mason wrote:
> >
> >> On 29/06/2017 19:50, Sean Young wrote:
> >>
> >>> On Thu, Jun 29, 2017 at 06:25:55PM +0200, Mason wrote:
> >>>
>  $ ir-keytable -v -t
>  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)
> >>
> >> I had overlooked this. Is it expected for these protocols
> >> to be marked as "disabled"?
> > 
> > Ah, good point, I forgot about that. :/
> > 
> > "ir-keytable -p all -t -v" should enable all protocols and test.
> 
> After hours of thrashing around, I finally figured out that
> the IRQ was misconfigured... Doh!
> 
> Here's the output from pressing '1' for one second on the RC:
> 
> # cat /dev/input/event0 | hexdump -vC
>   04 04 00 00 7a 08 07 00  04 00 04 00 41 cb 04 00  |z...A...|
-snip-

It might be easier to use "ir-keytable -t" for this, or evtest. 

> I'm not sure what these mean. There seems to be some kind of
> timestamp? And something else?

You're reading "struct input_event" here, see the input api.

> How do I tell which protocol
> this RC is using?

That's an awkward question to answer. This is not passed to user space
at the moment, that's one of addition I want to make to the lirc user
space api in the near future.

For the moment I would suggest just putting printk() in your code when
you call rc_keydown().

> Repeating the test (pressing '1' for one second) with ir-keytable:
> 
> # ir-keytable -p all -t -v
> 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
> /sys/class/rc/rc0//protocols: Invalid argument
> Couldn't change the IR protocols
> Testing events. Please, press CTRL-C to abort.
> 1296.124872: event type EV_MSC(0x04): scancode = 0x4cb41
> 1296.124872: event type EV_SYN(0x00).
> 1296.178753: event type EV_MSC(0x04): scancode = 0x00
> 1296.178753: event type EV_SYN(0x00).
> 1296.286526: event type EV_MSC(0x04): scancode = 0x00
> 1296.286526: event type EV_SYN(0x00).
> 1296.394303: event type EV_MSC(0x04): scancode = 0x00
> 1296.394303: event type EV_SYN(0x00).
> 1296.502081: event type EV_MSC(0x04): scancode = 0x00
> 1296.502081: event type EV_SYN(0x00).
> 1296.609857: event type EV_MSC(0x04): scancode = 0x00
> 1296.609857: event type EV_SYN(0x00).
> 1296.717635: event type EV_MSC(0x04): scancode = 0x00
> 1296.717635: event type EV_SYN(0x00).
> 1296.825412: event type EV_MSC(0x04): scancode = 0x00
> 1296.825412: event type EV_SYN(0x00).
> 1296.933189: event type EV_MSC(0x04): scancode = 0x00
> 1296.933189: event type EV_SYN(0x00).
> 1297.040967: event type EV_MSC(0x04): scancode = 0x00
> 1297.040967: event type EV_SYN(0x00).
> 1297.148745: event type EV_MSC(0x04): scancode = 0x00
> 1297.148745: event type EV_SYN(0x00).
> 1297.256522: event type EV_MSC(0x04): scancode = 0x00
> 1297.256522: event type EV_SYN(0x00).
> 
> It looks like scancode 0x00 means "REPEAT" ?

This looks like nec repeat to me; nec repeats are sent every 110ms;
however when a repeat occurs, the driver should call rc_repeat(),
sending a scancode of 0 won't work.

> And 0x4cb41 would be '1' then?
> 
> If I compile the legacy driver (which is much more cryptic)
> it outputs 04 cb 41 be

~0xbe = 0x41. The code in tangox_ir_handle_nec() has decoded this
into extended nec (so the driver should send RC_TYPE_NECX), see
https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c#L68

> So 0x4cb41 in common - plus a trailing 0xbe (what is that?
> Some kind of checksum perhaps?)

That's part of the nec protocol.

> (For '2', I get 04 cb 03 fc)

See http://www.sbprojects.com/knowledge/ir/nec.php

Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)

[Ralph Metzler]

Mauro Carvalho Chehab writes:
 > Em Mon, 26 Jun 2017 11:45:08 +0200
 > Ralph Metzler  escreveu:
 > 
 > > Mauro Carvalho Chehab writes:
 > >  > Em Thu, 22 Jun 2017 23:35:27 +0200
 > >  > Ralph Metzler  escreveu:
 > >  >   
 > >  > > Daniel Scheller writes:  
 > >  > >  > Am Tue, 20 Jun 2017 16:10:43 -0300
 > >  > >  > schrieb Mauro Carvalho Chehab :
 > >  > >  > ...
 > >  > >  > > > - Maybe for 4.14: Support for the CineS2 V7 and FlexV4 line of
 > >  > >  > > >   cards/modules. This mainly involves a new demod driver 
 > > (stv0910) and
 > >  > >  > > >   a new tuner driver (stv6111). Permissions for this are 
 > > cleared with
 > >  > >  > > >   Ralph already. The glue code needed in ddbridge is rather 
 > > easy, and
 > >  > >  > > >   as some ground work (mostly the MachXO2 support from the 
 > > 2841 series)
 > >  > >  > > >   is now in, the changes are quite small. Patches are ready so 
 > > far but
 > >  > >  > > >   need more cleanup (checkpatch fixes, camel case and such 
 > > things).  
 > >  > >  > > 
 > >  > >  > > Please try to sync it with Ralph, in a way that his code won't
 > >  > >  > > diverge from the upstream one, as this will make easier for both
 > >  > >  > > sides to keep the Kernel in track with driver improvements.
 > >  > >  > 
 > >  > >  > This is not going to work. DD (Ralph and Manfred Voelkel) sort of 
 > > maintain a shared code base between their Windows 
 > >  > >  > driver and the Linux kernel driver sources. While they didn't 
 > > explicitely stated this, this can be noticed by the 
 > >  > >  > remarks and commented code in their OSS code, and the commit 
 > > messages in their dddvb GIT (e.g. "sync with windows driver"). 
 > >  > >  > I've already cleaned up a lot of this (I believe no one wants to 
 > > see such stuff in the linux kernel tree). If we're 
 > >  > >  > additionally going to replace all things camel case, with some 
 > > more cleaning and maybe code shuffling after like a V4 
 > >  > >  > patch series, those two sources are out of sync in a way that no 
 > > automatic sync by applying patches will be possible 
 > >  > >  > anymore. So, pushing from vendor's upstream to the kernel seems to 
 > > be the only option, and in fact, if the whole 
 > >  > >  > driver/package stack completely lives in the kernel sources, maybe 
 > > DD even decide to directly commit upstream (kernel) again.  
 > >  > 
 > >  > Ralph, do you share Linux code with Windows, or are you just getting
 > >  > drivers from the manufacturer and converting them to Linux at dddvb
 > >  > tree?  
 > > 
 > > It differs from case to case.
 > > Digital Devices gets drivers and/or documetation from the manufacturer.
 > > Sometimes from this a Windows driver is written which we convert
 > > to Linux or a Linux driver is written directly.
 > > 
 > > 
 > > 
 > >  > Would it be possible to change things at the dddvb tree to make
 > >  > it to use our coding style (for example, replacing CamelCase by the
 > >  > kernel_style), in order to minimize the amount of work to sync from
 > >  > your tree?  
 > > 
 > > Yes
 > 
 > Good! With that, it should be easier to keep both versions containing
 > the same stuff.
 > 
 > > 
 > >  > > I also already told Daniel about our concerns regarding the CXD 
 > > drivers in private mail.
 > >  > > Sony did not want us to use their code directly and we had to get our 
 > > code approved
 > >  > > before publishing it. I do not know how the arrangement is regarding 
 > > the in-kernel driver.
 > >  > > DVB-C2 support also seems to be missing in this.  
 > >  > 
 > >  > Sony recently started submitting CXD drivers to us directly (for 
 > > cxd2880).
 > >  > 
 > >  > The upstream verson for cx2841 came from NetUP. I guess they develop
 > >  > the drivers themselves, but not really sure.
 > >  > 
 > >  > Perhaps we can ask Sony's help to make easier add the features that are 
 > >  > missing at the existing driver in a way that DDbridge could also use
 > >  > the upstream driver, or to do some other sort of agreement that would 
 > >  > make possible for us to use the same driver as you at the upstream 
 > > Kernel.
 > >  > 
 > >  > (c/c Takiguchi-san and Tim Bird from Sony)  
 > > 
 > > 
 > > All I know is that they were strict with Digital Devices. We could not use
 > > their code directly. That's why I am surprised the Netup code contains
 > > Sony code.
 > 
 > I didn't say they're using Sony code. I actually suspect that they
 > did the same as you (but I have no means to be sure).

The code contains a Sony copyright header.
That's why we were surprised. We did not get any GPLed code from Sony.


 > Yet, as Sony recently approached us for cxd2880, and they're now
 > developing an official driver to be upstreamed, I'm wandering if we
 > can get a better way to handle the cxd2841 driver in a way that will
 > make easier for everyone to use the same code.

Yes, that would be nice.


> The 

[PATCH] Clean up lirc zilog error codes

[Yves Lemée]

According the coding style guidelines, the ENOSYS error code must be returned
in case of a non existent system call. This code has been replaced with
the ENOTTY error code indicating, a missing functionality.

Signed-off-by: Yves Lemée 
---
 drivers/staging/media/lirc/lirc_zilog.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_zilog.c 
b/drivers/staging/media/lirc/lirc_zilog.c
index 015e41bd036e..26dd32d5b5b2 100644
--- a/drivers/staging/media/lirc/lirc_zilog.c
+++ b/drivers/staging/media/lirc/lirc_zilog.c
@@ -1249,7 +1249,7 @@ static long ioctl(struct file *filep, unsigned int cmd, 
unsigned long arg)
break;
case LIRC_GET_REC_MODE:
if (!(features & LIRC_CAN_REC_MASK))
-   return -ENOSYS;
+   return -ENOTTY;
 
result = put_user(LIRC_REC2MODE
  (features & LIRC_CAN_REC_MASK),
@@ -1257,21 +1257,21 @@ static long ioctl(struct file *filep, unsigned int cmd, 
unsigned long arg)
break;
case LIRC_SET_REC_MODE:
if (!(features & LIRC_CAN_REC_MASK))
-   return -ENOSYS;
+   return -ENOTTY;
 
result = get_user(mode, uptr);
if (!result && !(LIRC_MODE2REC(mode) & features))
-   result = -EINVAL;
+   result = -ENOTTY;
break;
case LIRC_GET_SEND_MODE:
if (!(features & LIRC_CAN_SEND_MASK))
-   return -ENOSYS;
+   return -ENOTTY;
 
result = put_user(LIRC_MODE_PULSE, uptr);
break;
case LIRC_SET_SEND_MODE:
if (!(features & LIRC_CAN_SEND_MASK))
-   return -ENOSYS;
+   return -ENOTTY;
 
result = get_user(mode, uptr);
if (!result && mode != LIRC_MODE_PULSE)
-- 
2.13.2

Re: [PATCH] [media] solo6x10: make const array saa7128_regs_ntsc static

[Andrey Utkin]

On Mon, Jul 10, 2017 at 07:51:03PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Don't populate const array saa7128_regs_ntsc on the stack but insteaed make
> it static.  Makes the object code smaller and saves nearly 840 bytes
> 
> Before:
>text  data bss dec hex filename
>9218   360   09578256a solo6x10-tw28.o
> 
> After:
>text  data bss dec hex filename
>8237   504   087412225 solo6x10-tw28.o
> 
> Signed-off-by: Colin Ian King 

Acked-by: Andrey Utkin 

Re: [PATCH] staging: fbtft: make const array gamma_par_mask static

[Greg Kroah-Hartman]

On Tue, Jul 11, 2017 at 06:39:59PM +0100, Colin Ian King wrote:
> On 11/07/17 18:30, Greg Kroah-Hartman wrote:
> > On Tue, Jul 11, 2017 at 06:20:02PM +0100, Colin King wrote:
> >> From: Colin Ian King 
> >>
> >> Don't populate array gamma_par_mask on the stack but instead make it
> >> static.  Makes the object code smaller by 148 bytes:
> >>
> >> Before:
> >>text   data bss dec hex filename
> >>2993   1104   040971001 
> >> drivers/staging/fbtft/fb_st7789v.o
> >>
> >> After:
> >>text   data bss dec hex filename
> >>2757   1192   03949 f6d 
> >> drivers/staging/fbtft/fb_st7789v.o
> >>
> >> Signed-off-by: Colin Ian King 
> >> ---
> >>  drivers/media/usb/gspca/xirlink_cit.c | 2 +-
> >>  drivers/staging/fbtft/fb_st7789v.c| 2 +-
> >>  2 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > Your subject doesn't match the patch :(
> 
> Got distracted by the Trump Jnr tweet. Will resend.

Dude, the best thing is to just read:
https://whatthefuckjusthappenedtoday.com/
once a day, otherwise you will not get any work done ever again...

Re: [PATCH] staging: fbtft: make const array gamma_par_mask static

[Colin Ian King]

On 11/07/17 18:30, Greg Kroah-Hartman wrote:
> On Tue, Jul 11, 2017 at 06:20:02PM +0100, Colin King wrote:
>> From: Colin Ian King 
>>
>> Don't populate array gamma_par_mask on the stack but instead make it
>> static.  Makes the object code smaller by 148 bytes:
>>
>> Before:
>>text data bss dec hex filename
>>2993 1104   040971001 
>> drivers/staging/fbtft/fb_st7789v.o
>>
>> After:
>>text data bss dec hex filename
>>2757 1192   03949 f6d 
>> drivers/staging/fbtft/fb_st7789v.o
>>
>> Signed-off-by: Colin Ian King 
>> ---
>>  drivers/media/usb/gspca/xirlink_cit.c | 2 +-
>>  drivers/staging/fbtft/fb_st7789v.c| 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> Your subject doesn't match the patch :(

Got distracted by the Trump Jnr tweet. Will resend.

> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] staging: fbtft: make const array gamma_par_mask static

[Greg Kroah-Hartman]

On Tue, Jul 11, 2017 at 06:20:02PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Don't populate array gamma_par_mask on the stack but instead make it
> static.  Makes the object code smaller by 148 bytes:
> 
> Before:
>text  data bss dec hex filename
>2993  1104   040971001 
> drivers/staging/fbtft/fb_st7789v.o
> 
> After:
>text  data bss dec hex filename
>2757  1192   03949 f6d 
> drivers/staging/fbtft/fb_st7789v.o
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/media/usb/gspca/xirlink_cit.c | 2 +-
>  drivers/staging/fbtft/fb_st7789v.c| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Your subject doesn't match the patch :(

[PATCH] staging: fbtft: make const array gamma_par_mask static

[Colin King]

From: Colin Ian King 

Don't populate array gamma_par_mask on the stack but instead make it
static.  Makes the object code smaller by 148 bytes:

Before:
   textdata bss dec hex filename
   29931104   040971001 drivers/staging/fbtft/fb_st7789v.o

After:
   textdata bss dec hex filename
   27571192   03949 f6d drivers/staging/fbtft/fb_st7789v.o

Signed-off-by: Colin Ian King 
---
 drivers/media/usb/gspca/xirlink_cit.c | 2 +-
 drivers/staging/fbtft/fb_st7789v.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/gspca/xirlink_cit.c 
b/drivers/media/usb/gspca/xirlink_cit.c
index b600ea6460d3..68656e7986c7 100644
--- a/drivers/media/usb/gspca/xirlink_cit.c
+++ b/drivers/media/usb/gspca/xirlink_cit.c
@@ -1315,7 +1315,7 @@ static int cit_set_sharpness(struct gspca_dev *gspca_dev, 
s32 val)
break;
case CIT_MODEL1: {
int i;
-   const unsigned short sa[] = {
+   static const unsigned short sa[] = {
0x11, 0x13, 0x16, 0x18, 0x1a, 0x8, 0x0a };
 
for (i = 0; i < cit_model1_ntries; i++)
diff --git a/drivers/staging/fbtft/fb_st7789v.c 
b/drivers/staging/fbtft/fb_st7789v.c
index 8935a97ec048..a5d7c87557f8 100644
--- a/drivers/staging/fbtft/fb_st7789v.c
+++ b/drivers/staging/fbtft/fb_st7789v.c
@@ -189,7 +189,7 @@ static int set_gamma(struct fbtft_par *par, u32 *curves)
 * The masks are the same for both positive and negative voltage
 * gamma curves.
 */
-   const u8 gamma_par_mask[] = {
+   static const u8 gamma_par_mask[] = {
0xFF, /* V63[3:0], V0[3:0]*/
0x3F, /* V1[5:0] */
0x3F, /* V2[5:0] */
-- 
2.11.0

Re: [PATCH v2] [media] uvcvideo: Prevent heap overflow in uvc driver

[Guenter Roeck]

Any comments / feedback ?

Thanks,
Guenter

On Fri, Jun 30, 2017 at 09:21:56AM -0700, Guenter Roeck wrote:
> The size of uvc_control_mapping is user controlled leading to a
> potential heap overflow in the uvc driver. This adds a check to verify
> the user provided size fits within the bounds of the defined buffer
> size.
> 
> Originally-from: Richard Simmons 
> Signed-off-by: Guenter Roeck 
> ---
> Fixes CVE-2017-0627.
> 
> v2: Combination of v1 with the fix suggested by Richard Simmons
> Perform validation after uvc_ctrl_fill_xu_info()
> Take into account that ctrl->info.size is in bytes
> Also validate mapping->size
> 
>  drivers/media/usb/uvc/uvc_ctrl.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c 
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index c2ee6e39fd0c..d3e3164f43fd 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -2002,6 +2002,13 @@ int uvc_ctrl_add_mapping(struct uvc_video_chain *chain,
>   goto done;
>   }
>  
> + /* validate that the user provided bit-size and offset is valid */
> + if (mapping->size > 32 ||
> + mapping->offset + mapping->size > ctrl->info.size * 8) {
> + ret = -EINVAL;
> + goto done;
> + }
> +
>   list_for_each_entry(map, >info.mappings, list) {
>   if (mapping->id == map->id) {
>   uvc_trace(UVC_TRACE_CONTROL, "Can't add mapping '%s', "
> -- 
> 2.7.4
> 

Re: v4l2-fwnode: status, plans for merge, any branch to merge against?

[Sakari Ailus]

Hi Pavel,

On Thu, Jul 06, 2017 at 12:38:51PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > > I expect to have most of them in during the next merge window.
> > > > > 
> > > > > So git://linuxtv.org/media_tree.git branch master is the right one to
> > > > > work one?
> > > > 
> > > > I also pushed the rebased ccp2 branch there:
> > > > 
> > > > 
> > > > 
> > > > It's now right on the top of media-tree master.
> > > 
> > > Is ccp2 branch expected to go into 4.13, too?
> > 
> > Hi Pavel,
> > 
> > What I've done is just rebased the ccp2 branch. In other words, the patches
> > in that branch are no more ready than they were.
> 
> I thought they were ready even back then :-).
> 
> > To get these merged we should ideally
> > 
> > 1) Make sure there will be no regressions,
> 
> Well, all I have running recent kernels is N900. If ccp branch works
> for you on N9, that's probably as much testing as we can get.
> 
> > 2) clean things up in the omap3isp; which resources are needed and when
> > (e.g. regulators, PHY configuration) isn't clear at the moment and
> > 
> > 2) have one driver using the implementation.
> > 
> > At least 1) is needed. I think a number of framework patches could be
> > mergeable before 2) and 3) are done. I can prepare a set later this week.
> > But even that'd be likely for 4.14, not 4.13.
> 
> Yep, it is too late for v4.13 now. But getting stuff ready for v4.14
> would be good.
> 
> I started looking through the patches; I believe they are safe, but it
> is probably better to review the series you've just mailed.
> 
> The driver using the implementation -- yes, I have it all working on
> n900 (incuding userland, I can actually take photos.) I can post the
> series, or better link to kernel.org.
> 
> Right now, my goal would be to get sensor working on N900 with
> mainline (without flash and focus).
> 
> I'd very much like any comment on patch attached below.
> 
> Age   Commit message (Expand) Author  Files   Lines
> 2017-06-16   omap3isp: Destroy CSI-2 phy mutexes in error and module
> 2017-06-16omap3isp: Skip CSI-2 receiver initialisation in CCP2
> 2017-06-16omap3isp: Correctly put the last iterated endpoint
> 2017-06-16omap3isp: Always initialise isp and mutex for csiphy1
> 2017-06-16omap3isp: Return -EPROBE_DEFER if the required
> 2017-06-16 omap3isp: Correctly set IO_OUT_SEL and VP_CLK_POL for CCP2
> 2017-06-16omap3isp: Make external sub-device bus configuration a
> 2017-06-15omap3isp: Parse CSI1 configuration from the device tree
> 2017-06-15omap3isp: Check for valid port in endpoints Sakari
> 2017-06-15omap3isp: Ignore endpoints with invalid configuration
> 
> # Nothing changes for bus_type == V4L2_MBUS_CSI2. FIXME: Is bus_type
>   set correctly?
> 
> 2017-06-15smiapp: add CCP2 supportPavel Machek1
> 
> # bus_type will be guess, so no code changes on existing system:
> 
> 2017-06-15v4l: Add support for CSI-1 and CCP2 busses  Sakari
> 
> # Reads unused value -> can't break anything:
> 
> 2017-06-13v4l: fwnode: Obtain data bus type from FW   Sakari
> 
> # No code changes -> totally safe:
> 
> 2017-06-13v4l: fwnode: Call CSI2 bus csi2, not csiSakari
> 2017-06-13dt: bindings: Add strobe property for CCP2  Sakari
> 2017-06-13dt: bindings: Explicitly specify bus type
> 
> Best regards,
>   Pavel
> 
> commit 1220492dd4c1872c8036caa573680f95aabc69bc
> Author: Pavel 
> Date:   Tue Feb 28 12:02:26 2017 +0100
> 
> omap3isp: add CSI1 support
> 
> Use proper code path for csi1/ccp2 support.
> 
> Signed-off-by: Pavel Machek 
> 
> diff --git a/drivers/media/platform/omap3isp/ispccp2.c 
> b/drivers/media/platform/omap3isp/ispccp2.c
> index 24a9fc5..47210b1 100644
> --- a/drivers/media/platform/omap3isp/ispccp2.c
> +++ b/drivers/media/platform/omap3isp/ispccp2.c
> @@ -1149,6 +1149,7 @@ int omap3isp_ccp2_init(struct isp_device *isp)
>   "Could not get regulator vdds_csib\n");
>   ccp2->vdds_csib = NULL;
>   }
> + ccp2->phy = >isp_csiphy2;
>   } else if (isp->revision == ISP_REVISION_15_0) {
>   ccp2->phy = >isp_csiphy1;
>   }
> diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c 
> b/drivers/media/platform/omap3isp/ispcsiphy.c
> index 50c0f64..862fdd3 100644
> --- a/drivers/media/platform/omap3isp/ispcsiphy.c
> +++ b/drivers/media/platform/omap3isp/ispcsiphy.c
> @@ -197,9 +197,10 @@ static int omap3isp_csiphy_config(struct isp_csiphy *phy)
>   }
>  
>   if (buscfg->interface == ISP_INTERFACE_CCP2B_PHY1
> - || buscfg->interface == ISP_INTERFACE_CCP2B_PHY2)
> + || buscfg->interface == ISP_INTERFACE_CCP2B_PHY2) {
>   lanes = >bus.ccp2.lanecfg;
> - else
> + phy->num_data_lanes = 1;
> + } else
>

Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29

[Daniel Scheller]

Am Tue, 11 Jul 2017 11:11:27 +0200
schrieb Ralph Metzler :

> Daniel Scheller writes:
>  > 
>  > IIRC this was -main.c, and basically the code split, but no
>  > specific file. However, each of the additionals (hw, io, irq) were
>  > done with a reason (please also see their commit messages at
>  > patches 4-6):
>  > [...]
> 
> As I wrote before, changes like this will break other things like the
> OctopusNet build tree. So, I cannot use them like this or without
> changes at other places. And even if I wanted to, I cannot pull
> anything into the public dddvb repository.

Ok, you probably have seen the PRs I created against dddvb, as they
apply basically the same as is contained in this patchset, and even
fixes a few minors. Thus, lets not declare this as merge-blocker for
this patches, please.

It'd of course be very valuable if you continue to commit incremental
changes to your drivers, so we can move on with the plan to keep the
in-kernel-driver (if merged) uptodate in a timely manner. After
over 1.5years I believe I know the driver quite well now so I won't get
troubles picking up things by hand.

Best regards,
Daniel Scheller
-- 
https://github.com/herrnst

Re: [PATCH 1/2] staging: atomisp2: hmm: Fixed comment style

[Sakari Ailus]

On Mon, Jul 10, 2017 at 08:56:20PM +0200, Philipp Guendisch wrote:
> This patch fixed comment style. Semantic should not be affected.
> There are also two warnings left about too long lines, which
> reduce readability if changed.
> 
> Signed-off-by: Philipp Guendisch 
> Signed-off-by: Chris Baller 

Hi Philipp,

The patches don't apply. Recently there have been many atomisp patches
being posted and I've applied them to the atomisp branch here:



Could you rebase yours on top of that, please?

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v6 1/3] [media] v4l: add parsed MPEG-2 support

[ayaka]

On 07/09/2017 08:32 AM, Nicolas Dufresne wrote:

Le samedi 08 juillet 2017 à 13:16 +0800, ayaka a écrit :

On 07/08/2017 02:33 AM, Nicolas Dufresne wrote:

Le samedi 08 juillet 2017 à 01:29 +0800, ayaka a écrit :

On 07/04/2017 05:29 PM, Hugues FRUCHET wrote:

Hi Randy,
Thanks for review, and sorry for late reply, answers inline.
BR,
Hugues.

On 06/11/2017 01:41 PM, ayaka wrote:

On 04/28/2017 09:25 PM, Hugues Fruchet wrote:

Add "parsed MPEG-2" pixel format & related controls
needed by stateless video decoders.
In order to decode the video bitstream chunk provided
by user on output queue, stateless decoders require
also some extra data resulting from this video bitstream
chunk parsing.
Those parsed extra data have to be set by user through
control framework using the dedicated mpeg video extended
controls introduced in this patchset.

I have compared those v4l2 controls with the registers of the rockchip
video IP.

Most of them are met, but only lacks of sw_init_qp.

In case of MPEG-1/2, this register seems forced to 1, please double
check the on2 headers parsing library related to MPEG2. Nevertheless, I
see this hardware register used with VP8/H264.

Yes, it is forced to be 1. We can skip this field for MPEG1/2

Hence, no need to put this field on MPEG-2 interface, but should come
with VP8/H264.


Here is the full translation table of the registers of the rockchip
video IP.

q_scale_type
sw_qscale_type
concealment_motion_vectorssw_con_mv_e
intra_dc_precision  sw_intra_dc_prec
intra_vlc_format
sw_intra_vlc_tab
frame_pred_frame_dct  sw_frame_pred_dct

alternate_scan
sw_alt_scan_flag_e

f_code
sw_fcode_bwd_ver
   
sw_fcode_bwd_hor
   
sw_fcode_fwd_ver
   
sw_fcode_fwd_hor

full_pel_forward_vector  sw_mv_accuracy_fwd
full_pel_backward_vector   sw_mv_accuracy_bwd


I also saw you add two format for parsed MPEG-2/MPEG-1 format, I would
not recommand to do that.

We need to differentiate MPEG-1/MPEG-2, not all the fields are
applicable depending on version.

Usually the MPEG-2 decoder could support MPEG-1, as I know, the syntax
of byte stream of them are the same.

That is what google does, because for a few video format and some
hardware, they just request a offsets from the original video byte stream.

I don't understand your comment, perhaps have you some as a basis of
discussion ?

I mean

V4L2-PIX-FMT-MPEG2-PARSED V4L2-PIX-FMT-MPEG1-PARSED I wonder whether you
want use the new format to inform the userspace that this device is for
stateless video decoder, as google defined something like
V4L2_PIX_FMT_H264_SLICE. I think the driver registers some controls is
enough for the userspace to detect whether it is a stateless device. Or
it will increase the work of the userspace(I mean Gstreamer).

Just a note that SLICE has nothing to do with PARSED here. You could
have an H264 decoder that is stateless and support handling slices
rather then full frames (e.g. V4L2_PIX_FMT_H264_SLICE_PARSED could be
valid).

Actually, they have the same meanings, the H264_SLICE is not a slice, it
is an access unit in the rockchip vpu driver for Google.

Let's make sure this never get into mainline unmodified. H264_SLICE
should indicate that encoded buffer need to contains at least one
slice. We already have a format that indicates that a complete AU must
be passed. I do have active project going on where we really want to
pass slice for low latency cases and I would really appreciate if that
name can be used.
I think the hardware could support multiple slices in an AU, one slice 
in an AU or slice itself.

Well, but the in chrome os, it just means an parsed H264 stream.



I would not worry to much about Gst, as we will likely use this device
through the libv4l2 here, hence will only notice the "emulated"
V4L2_PIX_FMT_MPEG2 and ignore the _PARSED variant. And without libv4l2,
we'd just ignore this driver completely. I doubt we will implement per-
device parsing inside Gst itself if it's already done in an external
library for us. libv4l2 might need some fixing, but hopefully it's not
beyond repair.

As Gstreamer has merged the VA-API before, I would like to merge it into
Gstreamer directly.
Also for performance reason and my experience, the buffer management
would be a big problem, we need to increase the another layer to v4l2
plugins then.
When the parser is split from its caller, it would be hard to add a path
for error handing or something else.

I totally fail to understand your point here. Existing driver have a
separate core that do hide all the parsing and error handling, yet it
works relatively well this way. GStreamer is pretty high level user of

Re: [PATCH v7 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

[Sakari Ailus]

Hi Hans and Niklas,

On Mon, Jun 19, 2017 at 01:44:22PM +0200, Hans Verkuil wrote:
> On 06/12/2017 04:48 PM, Niklas Söderlund wrote:
> > Hi Hans,
> > 
> > Thanks for your comments.
> > 
> > On 2017-05-29 13:16:23 +0200, Hans Verkuil wrote:
> > > On 05/24/2017 02:13 AM, Niklas Söderlund wrote:
> > > > From: Niklas Söderlund 
> > > > 
> > > > A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver
> > > > supports the rcar-vin driver on R-Car Gen3 SoCs where separate CSI-2
> > > > hardware blocks are connected between the video sources and the video
> > > > grabbers (VIN).
> > > > 
> > > > Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
> > > > 
> > > > Signed-off-by: Niklas Söderlund 
> > > > ---
> > > >drivers/media/platform/rcar-vin/Kconfig |  12 +
> > > >drivers/media/platform/rcar-vin/Makefile|   1 +
> > > >drivers/media/platform/rcar-vin/rcar-csi2.c | 867 
> > > > 
> > > >3 files changed, 880 insertions(+)
> > > >create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
> > > > 
> 
> > > > +static int rcar_csi2_registered(struct v4l2_subdev *sd)
> > > > +{
> > > > +   struct rcar_csi2 *priv = container_of(sd, struct rcar_csi2, 
> > > > subdev);
> > > > +   struct v4l2_async_subdev **subdevs = NULL;
> > > > +   int ret;
> > > > +
> > > > +   subdevs = devm_kzalloc(priv->dev, sizeof(*subdevs), GFP_KERNEL);
> > > > +   if (subdevs == NULL)
> > > > +   return -ENOMEM;
> > > > +
> > > > +   subdevs[0] = >remote.asd;
> > > > +
> > > > +   priv->notifier.num_subdevs = 1;
> > > > +   priv->notifier.subdevs = subdevs;
> > > > +   priv->notifier.bound = rcar_csi2_notify_bound;
> > > > +   priv->notifier.unbind = rcar_csi2_notify_unbind;
> > > > +   priv->notifier.complete = rcar_csi2_notify_complete;
> > > > +
> > > > +   ret = v4l2_async_subnotifier_register(>subdev, 
> > > > >notifier);
> > > > +   if (ret < 0) {
> > > > +   dev_err(priv->dev, "Notifier registration failed\n");
> > > > +   return ret;
> > > > +   }
> > > > +
> > > > +   return 0;
> > > > +}
> > > 
> > > Hmm, I'm trying to understand this, and I got one question. There are at 
> > > least
> > > two complete callbacks: rcar_csi2_notify_complete and the bridge driver's
> > > complete callback. Am I right that the bridge driver's complete callback 
> > > is
> > > called as soon as this function exists (assuming this is the only subdev)?
> > 
> > Yes (at least for the async case).
> > 
> > In v4l2_async_test_notify() calls v4l2_device_register_subdev() which in
> > turns calls this registered callback. v4l2_async_test_notify() then go
> > on and calls the notifiers complete callback.
> > 
> > In my case I have (in the simplified case) AD7482 -> CSI-2 -> VIN. Where
> > VIN is the video device and CSI-2 is the subdevice of VIN while the
> > ADV7482 is a subdevice to the CSI-2. In that case the call graph would
> > be:
> > 
> > v4l2_async_test_notify()(From VIN on the CSI-2 subdev)
> >v4l2_device_register_subdev()
> >  sd->internal_ops->registered(sd);   (sd == CSI-2 subdev)
> >v4l2_async_subnotifier_register() (CSI-2 notifier for the ADV7482 
> > subdev)
> >  v4l2_async_test_notify()(From CSI-2 on the ADV7482) [1]
> >notifier->complete(notifier); (on the notifier from VIN)
> > 
> > > 
> > > So the bridge driver thinks it is complete when in reality this subdev may
> > > be waiting on newly registered subdevs?
> > 
> > Yes if the ADV7482 subdevice are not already registered in [1] above the
> > VIN complete callback would be called before the complete callback have
> > been called on the notifier register from the CSI-2 registered callback.
> > Instead that would be called once the ADV7482 calls
> > v4l2_async_register_subdev().
> > 
> > > 
> > > If I am right, then my question is if that is what we want. If I am wrong,
> > > then what did I miss?
> > 
> > I think that is what we want?
> > 
> >  From the VIN point of view all the subdevices it registered in it's
> > notifier have been found and bound right so I think it's correct to call
> > the complete callback for that notifier at this point?  If it really
> > cared about that all devices be present before it calls it complete
> > callback should it not also add all devices to its own notifier list?
> > 
> > But I do see your point that the VIN really have no way of telling if
> > all devices are present and we are ready to start to stream. This
> > however will be found out with a -EPIPE error if a stream is tried to be
> > started since the CSI-2 driver will fail to verify the pipeline since it
> > have no subdevice attached to its source pad. What do you think?
> 
> I think this is a bad idea. From the point of view of the application you
> expect that once the device nodes 

[PATCH 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.11.0

[PATCH 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 
---
 drivers/gpu/drm/Kconfig  |  10 ++
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/drm_dp_cec.c | 308 +++
 include/drm/drm_dp_helper.h  |  24 
 4 files changed, 343 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 ..7f2e298d45c0
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -0,0 +1,308 @@
+/*
+ * 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);
+   ssize_t err = 0;
+
+   if (enable)
+   err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL,
+DP_CEC_TUNNELING_ENABLE);
+   else
+   err = drm_dp_dpcd_writeb(aux, DP_CEC_TUNNELING_CONTROL, 0);
+   return (enable && err < 0) ? 

[PATCH 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 
---
 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.11.0

[PATCH 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 latest mainline kernel (as of today)
which has all the needed cec and drm 4.13 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).

Daniel, I incorporated all your suggestions/comments from the RFC patch
series from about 2 months ago.

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  | 308 ++
 drivers/gpu/drm/i915/intel_dp.c   |  18 +-
 include/drm/drm_dp_helper.h   |  24 +++
 6 files changed, 366 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_dp_cec.c

-- 
2.11.0

Re: [PATCH] [media] staging/imx: remove confusing IS_ERR_OR_NULL usage

[Arnd Bergmann]

On Thu, Jun 29, 2017 at 11:13 AM, Philipp Zabel  wrote:

>> @@ -134,23 +134,26 @@ static void csi_idmac_put_ipu_resources(struct 
>> csi_priv *priv)
>>  static int csi_idmac_get_ipu_resources(struct csi_priv *priv)
>>  {
>>   int ch_num, ret;
>> + struct ipu_smfc *smfc, *idmac_ch;
>
> This should be
>
> +   struct ipuv3_channel *idmac_ch;
> +   struct ipu_smfc *smfc;
>
> instead.

Fixed in v2 now.

>
> ... this changes behaviour:
>
> imx-media: imx_media_of_parse failed with -17
> imx-media: probe of capture-subsystem failed with error -17
>
> We must continue to return NULL here if imxsd == -EEXIST:
>
> -   return imxsd;
> +   return PTR_ERR(imxsd) == -EEXIST ? NULL : imxsd;
>
> or change the code where of_parse_subdev is called (from
> imx_media_of_parse, and recursively from of_parse_subdev) to not handle
> the -EEXIST return value as an error.
>
> With those fixed,
>
> Reviewed-by: Philipp Zabel 
> Tested-by: Philipp Zabel 

I thought about it some more and tried to find a better solution for this
function, which is now a bit different, so I did not add your tags.

Can you have another look at v2? This time, of_parse_subdev separates
the return code from the pointer, which seems less confusing in a function
like that. There are in fact two cases where we return NULL and it's
not clear if the caller should treat that as success or failure. I've left
the current behavior the same but added comments there.

 Arnd

[PATCH v2] [media] staging/imx: remove confusing IS_ERR_OR_NULL usage

[Arnd Bergmann]

While looking at a compiler warning, I noticed the use of
IS_ERR_OR_NULL, which is generally a sign of a bad API design
and should be avoided.

In this driver, this is fairly easy, we can simply stop storing
error pointers in persistent structures, and change the two
functions that might return either a NULL pointer or an error
code to consistently return error pointers when failing.

of_parse_subdev() now separates the error code and the pointer
it looks up, to clarify the interface. There are two cases
where this function originally returns 'NULL', and I have
changed that to '0' for success to keep the current behavior,
though returning an error would also make sense there.

Fixes: e130291212df ("[media] media: Add i.MX media core driver")
Signed-off-by: Arnd Bergmann 
---
v2: fix type mismatch
v3: rework of_parse_subdev() as well.
---
 drivers/staging/media/imx/imx-ic-prpencvf.c | 41 ---
 drivers/staging/media/imx/imx-media-csi.c   | 30 ++---
 drivers/staging/media/imx/imx-media-dev.c   |  4 +--
 drivers/staging/media/imx/imx-media-of.c| 50 -
 drivers/staging/media/imx/imx-media-vdic.c  | 37 +++--
 5 files changed, 90 insertions(+), 72 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index ed363fe3b3d0..7a9d9f32f989 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -134,19 +134,19 @@ static inline struct prp_priv *sd_to_priv(struct 
v4l2_subdev *sd)
 
 static void prp_put_ipu_resources(struct prp_priv *priv)
 {
-   if (!IS_ERR_OR_NULL(priv->ic))
+   if (priv->ic)
ipu_ic_put(priv->ic);
priv->ic = NULL;
 
-   if (!IS_ERR_OR_NULL(priv->out_ch))
+   if (priv->out_ch)
ipu_idmac_put(priv->out_ch);
priv->out_ch = NULL;
 
-   if (!IS_ERR_OR_NULL(priv->rot_in_ch))
+   if (priv->rot_in_ch)
ipu_idmac_put(priv->rot_in_ch);
priv->rot_in_ch = NULL;
 
-   if (!IS_ERR_OR_NULL(priv->rot_out_ch))
+   if (priv->rot_out_ch)
ipu_idmac_put(priv->rot_out_ch);
priv->rot_out_ch = NULL;
 }
@@ -154,43 +154,46 @@ static void prp_put_ipu_resources(struct prp_priv *priv)
 static int prp_get_ipu_resources(struct prp_priv *priv)
 {
struct imx_ic_priv *ic_priv = priv->ic_priv;
+   struct ipu_ic *ic;
+   struct ipuv3_channel *out_ch, *rot_in_ch, *rot_out_ch;
int ret, task = ic_priv->task_id;
 
priv->ipu = priv->md->ipu[ic_priv->ipu_id];
 
-   priv->ic = ipu_ic_get(priv->ipu, task);
-   if (IS_ERR(priv->ic)) {
+   ic = ipu_ic_get(priv->ipu, task);
+   if (IS_ERR(ic)) {
v4l2_err(_priv->sd, "failed to get IC\n");
-   ret = PTR_ERR(priv->ic);
+   ret = PTR_ERR(ic);
goto out;
}
+   priv->ic = ic;
 
-   priv->out_ch = ipu_idmac_get(priv->ipu,
-prp_channel[task].out_ch);
-   if (IS_ERR(priv->out_ch)) {
+   out_ch = ipu_idmac_get(priv->ipu, prp_channel[task].out_ch);
+   if (IS_ERR(out_ch)) {
v4l2_err(_priv->sd, "could not get IDMAC channel %u\n",
 prp_channel[task].out_ch);
-   ret = PTR_ERR(priv->out_ch);
+   ret = PTR_ERR(out_ch);
goto out;
}
+   priv->out_ch = out_ch;
 
-   priv->rot_in_ch = ipu_idmac_get(priv->ipu,
-   prp_channel[task].rot_in_ch);
-   if (IS_ERR(priv->rot_in_ch)) {
+   rot_in_ch = ipu_idmac_get(priv->ipu, prp_channel[task].rot_in_ch);
+   if (IS_ERR(rot_in_ch)) {
v4l2_err(_priv->sd, "could not get IDMAC channel %u\n",
 prp_channel[task].rot_in_ch);
-   ret = PTR_ERR(priv->rot_in_ch);
+   ret = PTR_ERR(rot_in_ch);
goto out;
}
+   priv->rot_in_ch = rot_in_ch;
 
-   priv->rot_out_ch = ipu_idmac_get(priv->ipu,
-prp_channel[task].rot_out_ch);
-   if (IS_ERR(priv->rot_out_ch)) {
+   rot_out_ch = ipu_idmac_get(priv->ipu, prp_channel[task].rot_out_ch);
+   if (IS_ERR(rot_out_ch)) {
v4l2_err(_priv->sd, "could not get IDMAC channel %u\n",
 prp_channel[task].rot_out_ch);
-   ret = PTR_ERR(priv->rot_out_ch);
+   ret = PTR_ERR(rot_out_ch);
goto out;
}
+   priv->rot_out_ch = rot_out_ch;
 
return 0;
 out:
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index a2d26693912e..17fd1e61dd5d 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -122,11 +122,11 @@ static inline struct csi_priv *sd_to_dev(struct 
v4l2_subdev *sdev)
 
 static void 

Aviso de conta

[PostMaster]

Alguém tentou acessar sua conta webmail / zimbra da África do Sul com IP no:
87.228.204.106. Ignore esta mensagem se você é o único, mas se você não é o
único, clique no link seguro da conta abaixo e faça login nos detalhes do
seu webmail / zimbra e clique em cimeira para proteger e proteger sua conta
de ser um hack.



http://corriouedeskl.tripod.com/



A partir de,

Suporte à conta do Webmaster.





---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[bug report] [media] davinci: vpif_capture: get subdevs from DT when available

[Dan Carpenter]

Hello Kevin Hilman,

The patch 4a5f8ae50b66: "[media] davinci: vpif_capture: get subdevs
from DT when available" from Jun 6, 2017, leads to the following
static checker warning:

drivers/media/platform/davinci/vpif_capture.c:1596 
vpif_capture_get_pdata()
error: potential NULL dereference 'pdata'.

drivers/media/platform/davinci/vpif_capture.c
  1576  
  1577  dev_dbg(>dev, "Remote device %s, %s found\n",
  1578  rem->name, rem->full_name);
  1579  sdinfo->name = rem->full_name;
  1580  
  1581  pdata->asd[i] = devm_kzalloc(>dev,
  1582   sizeof(struct 
v4l2_async_subdev),
  1583   GFP_KERNEL);
  1584  if (!pdata->asd[i]) {
  1585  of_node_put(rem);
  1586  pdata = NULL;

Set to NULL

  1587  goto done;
  1588  }
  1589  
  1590  pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
  1591  pdata->asd[i]->match.fwnode.fwnode = 
of_fwnode_handle(rem);
  1592  of_node_put(rem);
  1593  }
  1594  
  1595  done:
  1596  pdata->asd_sizes[0] = i;

Dereference.

  1597  pdata->subdev_count = i;
  1598  pdata->card_name = "DA850/OMAP-L138 Video Capture";
  1599  
  1600  return pdata;
  1601  }

regards,
dan carpenter

Re: [PATCH 03/12] [media] vb2: add in-fence support to QBUF

[Gustavo Padovan]

2017-07-11 Hans Verkuil :

> On 10/07/17 22:26, Gustavo Padovan wrote:
> > 2017-07-10 Gustavo Padovan :
> > 
> >> 2017-07-07 Hans Verkuil :
> >>
> >>> On 07/07/2017 04:00 AM, Gustavo Padovan wrote:
>  2017-07-06 Hans Verkuil :
> 
> > On 06/16/17 09:39, Gustavo Padovan wrote:
> >> From: Gustavo Padovan 
> >>
> >> Receive in-fence from userspace and add support for waiting on them
> >> before queueing the buffer to the driver. Buffers are only queued
> >> to the driver once they are ready. A buffer is ready when its
> >> in-fence signals.
> >>
> >> v2:
> >>- fix vb2_queue_or_prepare_buf() ret check
> >>- remove check for VB2_MEMORY_DMABUF only (Javier)
> >>- check num of ready buffers to start streaming
> >>- when queueing, start from the first ready buffer
> >>- handle queue cancel
> >>
> >> Signed-off-by: Gustavo Padovan 
> >> ---
> >>   drivers/media/Kconfig|  1 +
> >>   drivers/media/v4l2-core/videobuf2-core.c | 97 
> >> +---
> >>   drivers/media/v4l2-core/videobuf2-v4l2.c | 15 -
> >>   include/media/videobuf2-core.h   |  7 ++-
> >>   4 files changed, 99 insertions(+), 21 deletions(-)
> >>
> >
> > 
> >
> >> diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
> >> b/drivers/media/v4l2-core/videobuf2-v4l2.c
> >> index 110fb45..e6ad77f 100644
> >> --- a/drivers/media/v4l2-core/videobuf2-v4l2.c
> >> +++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
> >> @@ -23,6 +23,7 @@
> >>   #include 
> >>   #include 
> >>   #include 
> >> +#include 
> >>   #include 
> >>   #include 
> >> @@ -560,6 +561,7 @@ EXPORT_SYMBOL_GPL(vb2_create_bufs);
> >>   int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b)
> >>   {
> >> +  struct dma_fence *fence = NULL;
> >>int ret;
> >>if (vb2_fileio_is_active(q)) {
> >> @@ -568,7 +570,18 @@ int vb2_qbuf(struct vb2_queue *q, struct 
> >> v4l2_buffer *b)
> >>}
> >>ret = vb2_queue_or_prepare_buf(q, b, "qbuf");
> >> -  return ret ? ret : vb2_core_qbuf(q, b->index, b);
> >> +  if (ret)
> >> +  return ret;
> >> +
> >> +  if (b->flags & V4L2_BUF_FLAG_IN_FENCE) {
> >> +  fence = sync_file_get_fence(b->fence_fd);
> >> +  if (!fence) {
> >> +  dprintk(1, "failed to get in-fence from fd\n");
> >> +  return -EINVAL;
> >> +  }
> >> +  }
> >> +
> >> +  return ret ? ret : vb2_core_qbuf(q, b->index, b, fence);
> >>   }
> >>   EXPORT_SYMBOL_GPL(vb2_qbuf);
> >
> > You need to adapt __fill_v4l2_buffer so it sets the IN_FENCE buffer flag
> > if there is a fence pending. It should also fill in fence_fd.
> 
>  It was userspace who sent the fence_fd in the first place. Why do we
>  need to send it back? The initial plan was - from a userspace point of 
>  view
>  - to send the in-fence in the fence_fd field and receive the out-fence
>    in the same field.
> 
>  As per setting the IN_FENCE flag, that is racy, as the fence can signal
>  just after we called __fill_v4l2_buffer. Why is it important to set it?
> >>>
> >>> Because when running VIDIOC_QUERYBUF it should return the current state of
> >>> the buffer, including whether it has a fence. You can do something like
> >>> v4l2-ctl --list-buffers to see how many buffers are queued up and the 
> >>> state
> >>> of each buffer. Can be useful to e.g. figure out why a video capture seems
> >>> to stall. Knowing that all queued buffers are all waiting for a fence is
> >>> very useful information. Whether the fence_fd should also be set here or
> >>> only in dqbuf is something I don't know (not enough knowledge about how
> >>> fences are supposed to work). The IN/OUT_FENCE flags should definitely be
> >>> reported though.
> >>
> >> I didn't know about this usecase. Thanks for explaining. It certainly
> >> makes sense to set the IN/OUT_FENCE flags here. Regarding the fence_fd
> >> I would expect the application to know the fence fd associated to than
> >> buffer. If we expect an application other than the one which issued
> >> QBUF than I'd say we also need to provide the fd on VIDIOC_QUERYBUF
> >> for inspection purposes. Is that the case?
> > 
> > I just realized that if we want to also set the in-fence fd here we
> > actually need to get a new unused fd, as either it is a different pid or
> > the app already closed the fd it was using previously. Given this extra
> > complication I'd say we shouldn't set fence fd unless someone has an
> > usecase in mind.
> 
> Fair enough. 

[PATCH v3] [media] dt-bindings: gpio-ir-tx: add support for GPIO IR Transmitter

[Sean Young]

Document the device tree bindings for the GPIO Bit Banging IR
Transmitter.

Signed-off-by: Sean Young 
---
 .../devicetree/bindings/leds/irled/gpio-ir-tx.txt  | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/irled/gpio-ir-tx.txt

diff --git a/Documentation/devicetree/bindings/leds/irled/gpio-ir-tx.txt 
b/Documentation/devicetree/bindings/leds/irled/gpio-ir-tx.txt
new file mode 100644
index 000..cbe8dfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/irled/gpio-ir-tx.txt
@@ -0,0 +1,14 @@
+Device tree bindings for IR LED connected through gpio pin which is used as
+remote controller transmitter.
+
+Required properties:
+   - compatible: should be "gpio-ir-tx".
+   - gpios :  Should specify the IR LED GPIO, see "gpios property" in
+ Documentation/devicetree/bindings/gpio/gpio.txt.  Active low LEDs
+ should be indicated using flags in the GPIO specifier.
+
+Example:
+   irled@0 {
+   compatible = "gpio-ir-tx";
+   gpios = < 2 GPIO_ACTIVE_HIGH>;
+   };
-- 
2.9.4

[PATCH 1/4] cec: be smarter about detecting the number of attempts made

[Hans Verkuil]

From: Hans Verkuil 

Some hardware does more than one attempt. So when it calls
cec_transmit_done when an error occurred it will e.g. use an error count
of 2 instead of 1.

The framework always assumed a single attempt, but now it is smarter
and will sum the counters to detect how many attempts were made.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-adap.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index bf45977b2823..e9284dbdc880 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -472,9 +472,14 @@ void cec_transmit_done(struct cec_adapter *adap, u8 
status, u8 arb_lost_cnt,
 {
struct cec_data *data;
struct cec_msg *msg;
+   unsigned int attempts_made = arb_lost_cnt + nack_cnt +
+low_drive_cnt + error_cnt;
u64 ts = ktime_get_ns();
 
dprintk(2, "%s: status %02x\n", __func__, status);
+   if (attempts_made < 1)
+   attempts_made = 1;
+
mutex_lock(>lock);
data = adap->transmitting;
if (!data) {
@@ -507,10 +512,10 @@ void cec_transmit_done(struct cec_adapter *adap, u8 
status, u8 arb_lost_cnt,
 * the hardware didn't signal that it retried itself (by setting
 * CEC_TX_STATUS_MAX_RETRIES), then we will retry ourselves.
 */
-   if (data->attempts > 1 &&
+   if (data->attempts > attempts_made &&
!(status & (CEC_TX_STATUS_MAX_RETRIES | CEC_TX_STATUS_OK))) {
/* Retry this message */
-   data->attempts--;
+   data->attempts -= attempts_made;
if (msg->timeout)
dprintk(2, "retransmit: %*ph (attempts: %d, wait for 
0x%02x)\n",
msg->len, msg->msg, data->attempts, msg->reply);
-- 
2.11.0

[PATCH 3/4] drm/vc4: Add register defines for CEC.

[Hans Verkuil]

From: Eric Anholt 

Basic usage:

poweron: HSM clock should be running.  Set the bit clock divider,
set all the other _US timeouts based on bit clock rate.  Bring RX/TX
reset up and then down.

powerdown: Set RX/TX reset.

interrupt: read CPU_STATUS, write bits that have been handled to
CPU_CLEAR.

Bits are added to /debug/dri/0/hdmi_regs so you can check out the
power-on values.

Signed-off-by: Eric Anholt 
Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c |  16 ++
 drivers/gpu/drm/vc4/vc4_regs.h | 108 +
 2 files changed, 124 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index e0104f96011e..b0521e6cc281 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -149,6 +149,22 @@ static const struct {
HDMI_REG(VC4_HDMI_VERTB1),
HDMI_REG(VC4_HDMI_TX_PHY_RESET_CTL),
HDMI_REG(VC4_HDMI_TX_PHY_CTL0),
+
+   HDMI_REG(VC4_HDMI_CEC_CNTRL_1),
+   HDMI_REG(VC4_HDMI_CEC_CNTRL_2),
+   HDMI_REG(VC4_HDMI_CEC_CNTRL_3),
+   HDMI_REG(VC4_HDMI_CEC_CNTRL_4),
+   HDMI_REG(VC4_HDMI_CEC_CNTRL_5),
+   HDMI_REG(VC4_HDMI_CPU_STATUS),
+
+   HDMI_REG(VC4_HDMI_CEC_RX_DATA_1),
+   HDMI_REG(VC4_HDMI_CEC_RX_DATA_2),
+   HDMI_REG(VC4_HDMI_CEC_RX_DATA_3),
+   HDMI_REG(VC4_HDMI_CEC_RX_DATA_4),
+   HDMI_REG(VC4_HDMI_CEC_TX_DATA_1),
+   HDMI_REG(VC4_HDMI_CEC_TX_DATA_2),
+   HDMI_REG(VC4_HDMI_CEC_TX_DATA_3),
+   HDMI_REG(VC4_HDMI_CEC_TX_DATA_4),
 };
 
 static const struct {
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index d382c34c1b9e..b18cc20ee185 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -561,16 +561,124 @@
 # define VC4_HDMI_VERTB_VBP_MASK   VC4_MASK(8, 0)
 # define VC4_HDMI_VERTB_VBP_SHIFT  0
 
+#define VC4_HDMI_CEC_CNTRL_1   0x0e8
+/* Set when the transmission has ended. */
+# define VC4_HDMI_CEC_TX_EOM   BIT(31)
+/* If set, transmission was acked on the 1st or 2nd attempt (only one
+ * retry is attempted).  If in continuous mode, this means TX needs to
+ * be filled if !TX_EOM.
+ */
+# define VC4_HDMI_CEC_TX_STATUS_GOOD   BIT(30)
+# define VC4_HDMI_CEC_RX_EOM   BIT(29)
+# define VC4_HDMI_CEC_RX_STATUS_GOOD   BIT(28)
+/* Number of bytes received for the message. */
+# define VC4_HDMI_CEC_REC_WRD_CNT_MASK VC4_MASK(27, 24)
+# define VC4_HDMI_CEC_REC_WRD_CNT_SHIFT24
+/* Sets continuous receive mode.  Generates interrupt after each 8
+ * bytes to signal that RX_DATA should be consumed, and at RX_EOM.
+ *
+ * If disabled, maximum 16 bytes will be received (including header),
+ * and interrupt at RX_EOM.  Later bytes will be acked but not put
+ * into the RX_DATA.
+ */
+# define VC4_HDMI_CEC_RX_CONTINUE  BIT(23)
+# define VC4_HDMI_CEC_TX_CONTINUE  BIT(22)
+/* Set this after a CEC interrupt. */
+# define VC4_HDMI_CEC_CLEAR_RECEIVE_OFFBIT(21)
+/* Starts a TX.  Will wait for appropriate idel time before CEC
+ * activity. Must be cleared in between transmits.
+ */
+# define VC4_HDMI_CEC_START_XMIT_BEGIN BIT(20)
+# define VC4_HDMI_CEC_MESSAGE_LENGTH_MASK  VC4_MASK(19, 16)
+# define VC4_HDMI_CEC_MESSAGE_LENGTH_SHIFT 16
+/* Device's CEC address */
+# define VC4_HDMI_CEC_ADDR_MASKVC4_MASK(15, 12)
+# define VC4_HDMI_CEC_ADDR_SHIFT   12
+/* Divides off of HSM clock to generate CEC bit clock. */
+# define VC4_HDMI_CEC_DIV_CLK_CNT_MASK VC4_MASK(11, 0)
+# define VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT0
+
+/* Set these fields to how many bit clock cycles get to that many
+ * microseconds.
+ */
+#define VC4_HDMI_CEC_CNTRL_2   0x0ec
+# define VC4_HDMI_CEC_CNT_TO_1500_US_MASK  VC4_MASK(30, 24)
+# define VC4_HDMI_CEC_CNT_TO_1500_US_SHIFT 24
+# define VC4_HDMI_CEC_CNT_TO_1300_US_MASK  VC4_MASK(23, 17)
+# define VC4_HDMI_CEC_CNT_TO_1300_US_SHIFT 17
+# define VC4_HDMI_CEC_CNT_TO_800_US_MASK   VC4_MASK(16, 11)
+# define VC4_HDMI_CEC_CNT_TO_800_US_SHIFT  11
+# define VC4_HDMI_CEC_CNT_TO_600_US_MASK   VC4_MASK(10, 5)
+# define VC4_HDMI_CEC_CNT_TO_600_US_SHIFT  5
+# define VC4_HDMI_CEC_CNT_TO_400_US_MASK   VC4_MASK(4, 0)
+# define VC4_HDMI_CEC_CNT_TO_400_US_SHIFT  0
+
+#define VC4_HDMI_CEC_CNTRL_3   0x0f0
+# define VC4_HDMI_CEC_CNT_TO_2750_US_MASK  VC4_MASK(31, 24)
+# define VC4_HDMI_CEC_CNT_TO_2750_US_SHIFT 24
+# define VC4_HDMI_CEC_CNT_TO_2400_US_MASK  VC4_MASK(23, 16)
+# define VC4_HDMI_CEC_CNT_TO_2400_US_SHIFT 16
+# define VC4_HDMI_CEC_CNT_TO_2050_US_MASK  VC4_MASK(15, 8)
+# define VC4_HDMI_CEC_CNT_TO_2050_US_SHIFT 8
+# define VC4_HDMI_CEC_CNT_TO_1700_US_MASK  VC4_MASK(7, 0)
+# define 

[PATCH 0/4] drm/vc4: add HDMI CEC support

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds support for HDMI CEC to the vc4 drm driver.
This series is based on the mainline kernel as of yesterday since
both the vc4 and cec patches for the 4.13 merge window are now merged
in that kernel.

Note: the first cec patch is independent of the vc4 patches and will be
merged via the media subsystem for 4.14. Without that patch everything
will still work, but it will attempt to retry messages twice as many
times as it should.

This has been tested with the Raspberry Pi 2B and 3B. I don't have older
rpi's, so I can't test those.

Many thanks to Eric Anholt for his help with this driver!

There is one open issue: when booting the rpi without an HDMI cable 
connected, then CEC won't work. But neither apparently does HDMI since
reconnecting it will not bring back any display.

If you boot with the HDMI cable connected, then all is well and 
disconnecting and reconnecting the cable will do the right thing.

I don't understand what is going on here, but it does not appear to
be CEC related and the same problem occurs without this patch series.

You also need to update your config.txt with this line to prevent the
firmware from eating the CEC interrupts:

mask_gpu_interrupt1=0x100

Eric, I've experimented with setting hdmi_ignore_cec=1 but that simply
doesn't work. Instead that disables CEC completely. With this
mask_gpu_interrupt1 setting everything works perfectly. This also
prevents the firmware from sending the initial Active Source CEC
message so the CPU has full control over the CEC bus, as it should.

My main concern is that this is rather magical, but it is not
something I have any control over.

Regards,

Hans

Eric Anholt (1):
  drm/vc4: Add register defines for CEC.

Hans Verkuil (3):
  cec: be smarter about detecting the number of attempts made
  drm/vc4: prepare for CEC support
  drm/vc4: add HDMI CEC support

 drivers/gpu/drm/vc4/Kconfig|   8 ++
 drivers/gpu/drm/vc4/vc4_hdmi.c | 278 +++--
 drivers/gpu/drm/vc4/vc4_regs.h | 113 +
 drivers/media/cec/cec-adap.c   |   9 +-
 4 files changed, 371 insertions(+), 37 deletions(-)

-- 
2.11.0

[PATCH 4/4] drm/vc4: add HDMI CEC support

[Hans Verkuil]

From: Hans Verkuil 

This patch adds support to VC4 for CEC.

To prevent the firmware from eating the CEC interrupts you need to add this to
your config.txt:

mask_gpu_interrupt1=0x100

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/vc4/Kconfig|   8 ++
 drivers/gpu/drm/vc4/vc4_hdmi.c | 203 -
 drivers/gpu/drm/vc4/vc4_regs.h |   5 +
 3 files changed, 211 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
index 4361bdcfd28a..fdae18aeab4f 100644
--- a/drivers/gpu/drm/vc4/Kconfig
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -19,3 +19,11 @@ config DRM_VC4
  This driver requires that "avoid_warnings=2" be present in
  the config.txt for the firmware, to keep it from smashing
  our display setup.
+
+config DRM_VC4_HDMI_CEC
+   bool "Broadcom VC4 HDMI CEC Support"
+   depends on DRM_VC4
+   select CEC_CORE
+   help
+ Choose this option if you have a Broadcom VC4 GPU
+ and want to use CEC.
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index b0521e6cc281..14e2ece5db94 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include "media/cec.h"
 #include "vc4_drv.h"
 #include "vc4_regs.h"
 
@@ -85,6 +86,11 @@ struct vc4_hdmi {
int hpd_gpio;
bool hpd_active_low;
 
+   struct cec_adapter *cec_adap;
+   struct cec_msg cec_rx_msg;
+   bool cec_tx_ok;
+   bool cec_irq_was_rx;
+
struct clk *pixel_clock;
struct clk *hsm_clock;
 };
@@ -156,6 +162,7 @@ static const struct {
HDMI_REG(VC4_HDMI_CEC_CNTRL_4),
HDMI_REG(VC4_HDMI_CEC_CNTRL_5),
HDMI_REG(VC4_HDMI_CPU_STATUS),
+   HDMI_REG(VC4_HDMI_CPU_MASK_STATUS),
 
HDMI_REG(VC4_HDMI_CEC_RX_DATA_1),
HDMI_REG(VC4_HDMI_CEC_RX_DATA_2),
@@ -232,8 +239,8 @@ vc4_hdmi_connector_detect(struct drm_connector *connector, 
bool force)
if (gpio_get_value_cansleep(vc4->hdmi->hpd_gpio) ^
vc4->hdmi->hpd_active_low)
return connector_status_connected;
-   else
-   return connector_status_disconnected;
+   cec_phys_addr_invalidate(vc4->hdmi->cec_adap);
+   return connector_status_disconnected;
}
 
if (drm_probe_ddc(vc4->hdmi->ddc))
@@ -241,8 +248,8 @@ vc4_hdmi_connector_detect(struct drm_connector *connector, 
bool force)
 
if (HDMI_READ(VC4_HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
return connector_status_connected;
-   else
-   return connector_status_disconnected;
+   cec_phys_addr_invalidate(vc4->hdmi->cec_adap);
+   return connector_status_disconnected;
 }
 
 static void vc4_hdmi_connector_destroy(struct drm_connector *connector)
@@ -263,6 +270,7 @@ static int vc4_hdmi_connector_get_modes(struct 
drm_connector *connector)
struct edid *edid;
 
edid = drm_get_edid(connector, vc4->hdmi->ddc);
+   cec_s_phys_addr_from_edid(vc4->hdmi->cec_adap, edid);
if (!edid)
return -ENODEV;
 
@@ -1137,6 +1145,165 @@ static void vc4_hdmi_audio_cleanup(struct vc4_hdmi 
*hdmi)
snd_soc_unregister_codec(dev);
 }
 
+#ifdef CONFIG_DRM_VC4_HDMI_CEC
+static irqreturn_t vc4_cec_irq_handler_thread(int irq, void *priv)
+{
+   struct vc4_dev *vc4 = priv;
+   struct vc4_hdmi *hdmi = vc4->hdmi;
+
+   if (hdmi->cec_irq_was_rx) {
+   if (hdmi->cec_rx_msg.len)
+   cec_received_msg(hdmi->cec_adap, >cec_rx_msg);
+   } else if (hdmi->cec_tx_ok) {
+   cec_transmit_done(hdmi->cec_adap, CEC_TX_STATUS_OK,
+ 0, 0, 0, 0);
+   } else {
+   /*
+* This CEC implementation makes 1 retry, so if we
+* get a NACK, then that means it made 2 attempts.
+*/
+   cec_transmit_done(hdmi->cec_adap, CEC_TX_STATUS_NACK,
+ 0, 2, 0, 0);
+   }
+   return IRQ_HANDLED;
+}
+
+static void vc4_cec_read_msg(struct vc4_dev *vc4, u32 cntrl1)
+{
+   struct cec_msg *msg = >hdmi->cec_rx_msg;
+   unsigned int i;
+
+   msg->len = 1 + ((cntrl1 & VC4_HDMI_CEC_REC_WRD_CNT_MASK) >>
+   VC4_HDMI_CEC_REC_WRD_CNT_SHIFT);
+   for (i = 0; i < msg->len; i += 4) {
+   u32 val = HDMI_READ(VC4_HDMI_CEC_RX_DATA_1 + i);
+
+   msg->msg[i] = val & 0xff;
+   msg->msg[i + 1] = (val >> 8) & 0xff;
+   msg->msg[i + 2] = (val >> 16) & 0xff;
+   msg->msg[i + 3] = (val >> 24) & 0xff;
+   }
+}
+
+static irqreturn_t vc4_cec_irq_handler(int irq, void *priv)
+{
+   struct vc4_dev *vc4 = priv;
+   struct vc4_hdmi *hdmi = vc4->hdmi;
+   u32 stat = 

[PATCH 2/4] drm/vc4: prepare for CEC support

[Hans Verkuil]

From: Hans Verkuil 

In order to support CEC the hsm clock needs to be enabled in
vc4_hdmi_bind(), not in vc4_hdmi_encoder_enable(). Otherwise you wouldn't
be able to support CEC when there is no hotplug detect signal, which is
required by some monitors that turn off the HPD when in standby, but keep
the CEC bus alive so they can be woken up.

The HDMI core also has to be enabled in vc4_hdmi_bind() for the same
reason.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 59 +-
 1 file changed, 29 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index ed63d4e85762..e0104f96011e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -463,11 +463,6 @@ static void vc4_hdmi_encoder_disable(struct drm_encoder 
*encoder)
HD_WRITE(VC4_HD_VID_CTL,
 HD_READ(VC4_HD_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
 
-   HD_WRITE(VC4_HD_M_CTL, VC4_HD_M_SW_RST);
-   udelay(1);
-   HD_WRITE(VC4_HD_M_CTL, 0);
-
-   clk_disable_unprepare(hdmi->hsm_clock);
clk_disable_unprepare(hdmi->pixel_clock);
 
ret = pm_runtime_put(>pdev->dev);
@@ -509,16 +504,6 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder 
*encoder)
return;
}
 
-   /* This is the rate that is set by the firmware.  The number
-* needs to be a bit higher than the pixel clock rate
-* (generally 148.5Mhz).
-*/
-   ret = clk_set_rate(hdmi->hsm_clock, 163682864);
-   if (ret) {
-   DRM_ERROR("Failed to set HSM clock rate: %d\n", ret);
-   return;
-   }
-
ret = clk_set_rate(hdmi->pixel_clock,
   mode->clock * 1000 *
   ((mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1));
@@ -533,20 +518,6 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder 
*encoder)
return;
}
 
-   ret = clk_prepare_enable(hdmi->hsm_clock);
-   if (ret) {
-   DRM_ERROR("Failed to turn on HDMI state machine clock: %d\n",
- ret);
-   clk_disable_unprepare(hdmi->pixel_clock);
-   return;
-   }
-
-   HD_WRITE(VC4_HD_M_CTL, VC4_HD_M_SW_RST);
-   udelay(1);
-   HD_WRITE(VC4_HD_M_CTL, 0);
-
-   HD_WRITE(VC4_HD_M_CTL, VC4_HD_M_ENABLE);
-
HDMI_WRITE(VC4_HDMI_SW_RESET_CONTROL,
   VC4_HDMI_SW_RESET_HDMI |
   VC4_HDMI_SW_RESET_FORMAT_DETECT);
@@ -1205,6 +1176,23 @@ static int vc4_hdmi_bind(struct device *dev, struct 
device *master, void *data)
return -EPROBE_DEFER;
}
 
+   /* This is the rate that is set by the firmware.  The number
+* needs to be a bit higher than the pixel clock rate
+* (generally 148.5Mhz).
+*/
+   ret = clk_set_rate(hdmi->hsm_clock, 163682864);
+   if (ret) {
+   DRM_ERROR("Failed to set HSM clock rate: %d\n", ret);
+   goto err_put_i2c;
+   }
+
+   ret = clk_prepare_enable(hdmi->hsm_clock);
+   if (ret) {
+   DRM_ERROR("Failed to turn on HDMI state machine clock: %d\n",
+ ret);
+   goto err_put_i2c;
+   }
+
/* Only use the GPIO HPD pin if present in the DT, otherwise
 * we'll use the HDMI core's register.
 */
@@ -1216,7 +1204,7 @@ static int vc4_hdmi_bind(struct device *dev, struct 
device *master, void *data)
 _gpio_flags);
if (hdmi->hpd_gpio < 0) {
ret = hdmi->hpd_gpio;
-   goto err_put_i2c;
+   goto err_unprepare_hsm;
}
 
hdmi->hpd_active_low = hpd_gpio_flags & OF_GPIO_ACTIVE_LOW;
@@ -1224,6 +1212,14 @@ static int vc4_hdmi_bind(struct device *dev, struct 
device *master, void *data)
 
vc4->hdmi = hdmi;
 
+   /* HDMI core must be enabled. */
+   if (!(HD_READ(VC4_HD_M_CTL) & VC4_HD_M_ENABLE)) {
+   HD_WRITE(VC4_HD_M_CTL, VC4_HD_M_SW_RST);
+   udelay(1);
+   HD_WRITE(VC4_HD_M_CTL, 0);
+
+   HD_WRITE(VC4_HD_M_CTL, VC4_HD_M_ENABLE);
+   }
pm_runtime_enable(dev);
 
drm_encoder_init(drm, hdmi->encoder, _hdmi_encoder_funcs,
@@ -1244,6 +1240,8 @@ static int vc4_hdmi_bind(struct device *dev, struct 
device *master, void *data)
 
 err_destroy_encoder:
vc4_hdmi_encoder_destroy(hdmi->encoder);
+err_unprepare_hsm:
+   clk_disable_unprepare(hdmi->hsm_clock);
pm_runtime_disable(dev);
 err_put_i2c:
put_device(>ddc->dev);
@@ -1263,6 +1261,7 @@ static void vc4_hdmi_unbind(struct device *dev, struct 
device *master,
vc4_hdmi_connector_destroy(hdmi->connector);
vc4_hdmi_encoder_destroy(hdmi->encoder);
 
+   

[GIT FIXES FOR v4.13] RC fixes.

[Sean Young]

Hi Mauro,

Since v4.12 we set the LIRC_CAN_GET_REC_RESOLUTION lirc feature, and as
a result lircd uses the ioctl LIRC_GET_REC_RESOLUTION. That ioctl has
always been broken in rc-core.

I should have tested lirc decoding, I'll add it to my rc checklist. Sorry.

Thanks,

Sean

The following changes since commit 2748e76ddb2967c4030171342ebdd3faa6a5e8e8:

  media: staging: cxd2099: Activate cxd2099 buffer mode (2017-06-26 08:19:13 
-0300)

are available in the git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.13d

for you to fetch changes up to 5b96f8172791fbc8f511ea453b8828fe6f02f03c:

  [media] lirc: LIRC_GET_REC_RESOLUTION should return microseconds (2017-07-11 
10:38:18 +0100)


Sean Young (1):
  [media] lirc: LIRC_GET_REC_RESOLUTION should return microseconds

 drivers/media/rc/ir-lirc-codec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH v4 3/3] intel-ipu3: cio2: Add new MIPI-CSI2 driver

[Sakari Ailus]

Hi Yong,

Thanks for the update! This looks pretty good in general, still some more
comments below.

Do you happen to have a todo list for the changes that are still planned?
AFAIR we should have two items in the list at least ---

1. Extend the format example to include the DMA word boundary and

2. Separate formats on the sub-device and on the video node.

On Mon, Jul 10, 2017 at 06:43:34PM -0500, Yong Zhi wrote:
> This patch adds CIO2 CSI-2 device driver for
> Intel's IPU3 camera sub-system support.
> 
> Signed-off-by: Yong Zhi 
> Signed-off-by: Hyungwoo Yang 
> Signed-off-by: Ramya Vijaykumar 
> ---
>  drivers/media/pci/Kconfig|2 +
>  drivers/media/pci/Makefile   |3 +-
>  drivers/media/pci/intel/Makefile |5 +
>  drivers/media/pci/intel/ipu3/Kconfig |   17 +
>  drivers/media/pci/intel/ipu3/Makefile|1 +
>  drivers/media/pci/intel/ipu3/ipu3-cio2.c | 1873 
> ++
>  drivers/media/pci/intel/ipu3/ipu3-cio2.h |  442 +++
>  7 files changed, 2342 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/media/pci/intel/Makefile
>  create mode 100644 drivers/media/pci/intel/ipu3/Kconfig
>  create mode 100644 drivers/media/pci/intel/ipu3/Makefile
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.c
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-cio2.h
> 
> diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig
> index da28e68..5932e22 100644
> --- a/drivers/media/pci/Kconfig
> +++ b/drivers/media/pci/Kconfig
> @@ -54,5 +54,7 @@ source "drivers/media/pci/smipcie/Kconfig"
>  source "drivers/media/pci/netup_unidvb/Kconfig"
>  endif
> 
> +source "drivers/media/pci/intel/ipu3/Kconfig"
> +
>  endif #MEDIA_PCI_SUPPORT
>  endif #PCI
> diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile
> index a7e8af0..d8f9843 100644
> --- a/drivers/media/pci/Makefile
> +++ b/drivers/media/pci/Makefile
> @@ -13,7 +13,8 @@ obj-y+= ttpci/  \
>   ddbridge/   \
>   saa7146/\
>   smipcie/\
> - netup_unidvb/
> + netup_unidvb/   \
> + intel/
> 
>  obj-$(CONFIG_VIDEO_IVTV) += ivtv/
>  obj-$(CONFIG_VIDEO_ZORAN) += zoran/
> diff --git a/drivers/media/pci/intel/Makefile 
> b/drivers/media/pci/intel/Makefile
> new file mode 100644
> index 000..745c8b2
> --- /dev/null
> +++ b/drivers/media/pci/intel/Makefile
> @@ -0,0 +1,5 @@
> +#
> +# Makefile for the IPU3 cio2 and ImGU drivers
> +#
> +
> +obj-y+= ipu3/
> diff --git a/drivers/media/pci/intel/ipu3/Kconfig 
> b/drivers/media/pci/intel/ipu3/Kconfig
> new file mode 100644
> index 000..2a895d6
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/Kconfig
> @@ -0,0 +1,17 @@
> +config VIDEO_IPU3_CIO2
> + tristate "Intel ipu3-cio2 driver"
> + depends on VIDEO_V4L2 && PCI
> + depends on MEDIA_CONTROLLER

Could you also add VIDEO_V4L2_SUBDEV_API, please?

> + depends on HAS_DMA
> + depends on ACPI
> + select V4L2_FWNODE
> + select VIDEOBUF2_DMA_SG
> +
> + ---help---
> + This is the Intel IPU3 CIO2 CSI-2 receiver unit, found in Intel
> + Skylake and Kaby Lake SoCs and used for capturing images and
> + video from a camera sensor.
> +
> + Say Y or M here if you have a Skylake/Kaby Lake SoC with MIPI CSI-2
> + connected camera.
> + The module will be called ipu3-cio2.
> diff --git a/drivers/media/pci/intel/ipu3/Makefile 
> b/drivers/media/pci/intel/ipu3/Makefile
> new file mode 100644
> index 000..20186e3
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c 
> b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> new file mode 100644
> index 000..8ecb17f
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
> @@ -0,0 +1,1873 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + *
> + * 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 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.
> + *
> + * Based partially on Intel IPU4 driver written by
> + *  Sakari Ailus 
> + *  Samu Onkalo 
> + *  Jouni Högander 
> + *  Jouni Ukkonen 
> + *  Antti Laakso 
> + * et al.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> 

[PATCH] [media] lirc: LIRC_GET_REC_RESOLUTION should return microseconds

[Sean Young]

Since commit e8f4818895b3 ("[media] lirc: advertise
LIRC_CAN_GET_REC_RESOLUTION and improve") lircd uses the ioctl
LIRC_GET_REC_RESOLUTION to determine the shortest pulse or space that
the hardware can detect. This breaks decoding in lirc because lircd
expects the answer in microseconds, but nanoseconds is returned.

Cc:  # v2.6.36+
Reported-by: Derek 
Tested-by: Derek 
Signed-off-by: Sean Young 
---
 drivers/media/rc/ir-lirc-codec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index a30af91..d2223c0 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -266,7 +266,7 @@ static long ir_lirc_ioctl(struct file *filep, unsigned int 
cmd,
if (!dev->rx_resolution)
return -ENOTTY;
 
-   val = dev->rx_resolution;
+   val = dev->rx_resolution / 1000;
break;
 
case LIRC_SET_WIDEBAND_RECEIVER:
-- 
2.9.4

[PATCH] [media] fc001[23]: make const gain table arrays static

[Colin King]

From: Colin Ian King 

Don't populate the gain tables on the stack but make them static const.
Makes the object code smaller:

Before:
   textdata bss dec hex filename
   78011408   0920923f9 drivers/media/tuners/fc0012.o
   8483 936   0941924cb drivers/media/tuners/fc0013.o

After:
   textdata bss dec hex filename
   76961464   0916023c8 drivers/media/tuners/fc0012.o
   83621024   0938624aa drivers/media/tuners/fc0013.o

Signed-off-by: Colin Ian King 
---
 drivers/media/tuners/fc0012.c | 2 +-
 drivers/media/tuners/fc0013.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/fc0012.c b/drivers/media/tuners/fc0012.c
index dcc323ffbde7..625ac6f51c39 100644
--- a/drivers/media/tuners/fc0012.c
+++ b/drivers/media/tuners/fc0012.c
@@ -351,7 +351,7 @@ static int fc0012_get_rf_strength(struct dvb_frontend *fe, 
u16 *strength)
int ret;
unsigned char tmp;
int int_temp, lna_gain, int_lna, tot_agc_gain, power;
-   const int fc0012_lna_gain_table[] = {
+   static const int fc0012_lna_gain_table[] = {
/* low gain */
-63, -58, -99, -73,
-63, -65, -54, -60,
diff --git a/drivers/media/tuners/fc0013.c b/drivers/media/tuners/fc0013.c
index 91dfa770a5cc..e606118d1a9b 100644
--- a/drivers/media/tuners/fc0013.c
+++ b/drivers/media/tuners/fc0013.c
@@ -511,7 +511,7 @@ static int fc0013_get_rf_strength(struct dvb_frontend *fe, 
u16 *strength)
int ret;
unsigned char tmp;
int int_temp, lna_gain, int_lna, tot_agc_gain, power;
-   const int fc0013_lna_gain_table[] = {
+   static const int fc0013_lna_gain_table[] = {
/* low gain */
-63, -58, -99, -73,
-63, -65, -54, -60,
-- 
2.11.0

Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29

[Ralph Metzler]

Daniel Scheller writes:
 > Am Mon, 10 Jul 2017 10:11:01 +0200
 > schrieb Ralph Metzler :
 > 
 > > Daniel Scheller writes:
 > >  > Stripped functionality compared to dddvb:
 > >  > 
 > >  >  - DVB-C modulator card support removed (requires DVB core API)  
 > > 
 > > not really besides one device name entry.
 > 
 > ... and a header :-) Maybe we should start another thread on this for a
 > probable follow-up project.
 > 
 > >  >  - OctoNET SAT>IP server/box support removed (requires API aswell)
 > >  >  - with this, GT link support was removed (only on OctoNET
 > >  > hardware)  
 > > 
 > > There is other PCIe based hardware which uses/will use this.
 > 
 > Umm, good to know - thus better shouldn't (even accidentally)
 > throw away the remove-revert of the GTL support for future cards.
 > 
 > >  >  drivers/media/pci/ddbridge/ddbridge-core.c | 4242
 > >  > ++--
 > >  > drivers/media/pci/ddbridge/ddbridge-hw.c   |  299 ++
 > >  > drivers/media/pci/ddbridge/ddbridge-hw.h   |   52 +
 > >  > drivers/media/pci/ddbridge/ddbridge-i2c.c  |  310 ++
 > >  > drivers/media/pci/ddbridge/ddbridge-io.h   |   71 +
 > >  > drivers/media/pci/ddbridge/ddbridge-irq.c  |  161 ++
 > >  > drivers/media/pci/ddbridge/ddbridge-main.c |  393 +++
 > >  > drivers/media/pci/ddbridge/ddbridge-regs.h |  138 +-
 > >  > drivers/media/pci/ddbridge/ddbridge.h  |  355 ++-  
 > > 
 > > I thought we settled on core, i2c, main, (and mod, ns, which you do
 > > not include). This will diverge then from my code.
 > 
 > IIRC this was -main.c, and basically the code split, but no specific
 > file. However, each of the additionals (hw, io, irq) were done with a
 > reason (please also see their commit messages at patches 4-6):
 > 
 > -io.h is there since the comparably complex functions in the original
 > ddbridge.h sort of scared me off and IMHO shouldn't live together with
 > struct definitions and such, so I moved them to a separate object
 > first. With the GTL things removed, the remainder was rather small, and
 > Jasmin pointed me in the "make it static inline in a header instead"
 > direction. When eventually GTL gets added back, it should go into it's
 > own object/module.
 > 
 > -hw.c/h moves all things hardware-definition/info related like regmaps
 > into one single place, currently it's spread out into -main and -core,
 > which might make things difficult to find.
 > 
 > -irq.c gets rid of the need of additional ifdefs related to
 > CONFIG_PCI_MSI, in that "defined but unused function" warnings are
 > generated if this isn't defined. Again, also makes it easier to find,
 > rather than search through ~3800 lines of -core :)
 > 
 > If you're comfortable with this, I will propose it via a GitHub PR as
 > well (alongside the other things I'd like to push out to you). For the
 > in-kernel code, I'd prefer to keep it like this.


As I wrote before, changes like this will break other things like the OctopusNet
build tree. So, I cannot use them like this or without changes at other places.
And even if I wanted to, I cannot pull anything into the public dddvb 
repository.

[PATCH 04/11] cec-core.rst: document the adap_free callback

[Hans Verkuil]

From: Hans Verkuil 

Document what this callback does.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/kapi/cec-core.rst | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Documentation/media/kapi/cec-core.rst 
b/Documentation/media/kapi/cec-core.rst
index 8a65c69ed071..bb066b2b26f8 100644
--- a/Documentation/media/kapi/cec-core.rst
+++ b/Documentation/media/kapi/cec-core.rst
@@ -107,6 +107,7 @@ your driver:
int (*adap_transmit)(struct cec_adapter *adap, u8 attempts,
  u32 signal_free_time, struct cec_msg 
*msg);
void (*adap_status)(struct cec_adapter *adap, struct seq_file 
*file);
+   void (*adap_free)(struct cec_adapter *adap);
 
/* High-level callbacks */
...
@@ -184,6 +185,14 @@ To log the current CEC hardware status:
 This optional callback can be used to show the status of the CEC hardware.
 The status is available through debugfs: cat /sys/kernel/debug/cec/cecX/status
 
+To free any resources when the adapter is deleted:
+
+.. c:function::
+   void (*adap_free)(struct cec_adapter *adap);
+
+This optional callback can be used to free any resources that might have been
+allocated by the driver. It's called from cec_delete_adapter.
+
 
 Your adapter driver will also have to react to events (typically interrupt
 driven) by calling into the framework in the following situations:
-- 
2.11.0

[PATCH 10/11] cec-core.rst: include cec-pin.h and cec-notifier.h

[Hans Verkuil]

From: Hans Verkuil 

Include the CEC pin framework documentation by reading cec-pin.h.
Include the CEC notifier framework documentation by reading cec-notifier.h.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/kapi/cec-core.rst | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/Documentation/media/kapi/cec-core.rst 
b/Documentation/media/kapi/cec-core.rst
index bb066b2b26f8..dc512bdd43c0 100644
--- a/Documentation/media/kapi/cec-core.rst
+++ b/Documentation/media/kapi/cec-core.rst
@@ -345,3 +345,34 @@ log_addrs->num_log_addrs set to 0. The block argument is 
ignored when
 unconfiguring. This function will just return if the physical address is
 invalid. Once the physical address becomes valid, then the framework will
 attempt to claim these logical addresses.
+
+CEC Pin framework
+-
+
+Most CEC hardware operates on full CEC messages where the software provides
+the message and the hardware handles the low-level CEC protocol. But some
+hardware only drives the CEC pin and software has to handle the low-level
+CEC protocol. The CEC pin framework was created to handle such devices.
+
+Note that due to the close-to-realtime requirements it can never be guaranteed
+to work 100%. This framework uses highres timers internally, but if a
+timer goes off too late by more than 300 microseconds wrong results can
+occur. In reality it appears to be fairly reliable.
+
+One advantage of this low-level implementation is that it can be used as
+a cheap CEC analyser, especially if interrupts can be used to detect
+CEC pin transitions from low to high or vice versa.
+
+.. kernel-doc:: include/media/cec-pin.h
+
+CEC Notifier framework
+-
+
+Most drm HDMI implementations have an integrated CEC implementation and no
+notifier support is needed. But some have independent CEC implementations
+that have their own driver. This could be an IP block for an SoC or a
+completely separate chip that deals with the CEC pin. For those cases a
+drm driver can install a notifier and use the notifier to inform the
+CEC driver about changes in the physical address.
+
+.. kernel-doc:: include/media/cec-notifier.h
-- 
2.11.0

[PATCH 01/11] cec: improve transmit timeout logging

[Hans Verkuil]

From: Hans Verkuil 

Kernel logging messes up the upcoming low-level CEC monitoring support
which is very time-sensitive. So change the debug level of this message
but keep a counter that is shown in the debugfs status log.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-adap.c | 17 +
 include/media/cec.h  |  2 ++
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index bf45977b2823..644ce82ea2ed 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -394,13 +394,17 @@ int cec_thread_func(void *_adap)
 
if (adap->transmitting && timeout) {
/*
-* If we timeout, then log that. This really shouldn't
-* happen and is an indication of a faulty CEC adapter
-* driver, or the CEC bus is in some weird state.
+* If we timeout, then log that. Normally this does
+* not happen and it is an indication of a faulty CEC
+* adapter driver, or the CEC bus is in some weird
+* state. On rare occasions it can happen if there is
+* so much traffic on the bus that the adapter was
+* unable to transmit for CEC_XFER_TIMEOUT_MS (2.1s).
 */
-   dprintk(0, "%s: message %*ph timed out!\n", __func__,
+   dprintk(1, "%s: message %*ph timed out\n", __func__,
adap->transmitting->msg.len,
adap->transmitting->msg.msg);
+   adap->tx_timeouts++;
/* Just give up on this. */
cec_data_cancel(adap->transmitting);
goto unlock;
@@ -1941,6 +1945,11 @@ int cec_adap_status(struct seq_file *file, void *priv)
if (adap->monitor_all_cnt)
seq_printf(file, "file handles in Monitor All mode: %u\n",
   adap->monitor_all_cnt);
+   if (adap->tx_timeouts) {
+   seq_printf(file, "transmit timeouts: %u\n",
+  adap->tx_timeouts);
+   adap->tx_timeouts = 0;
+   }
data = adap->transmitting;
if (data)
seq_printf(file, "transmitting message: %*ph (reply: %02x, 
timeout: %ums)\n",
diff --git a/include/media/cec.h b/include/media/cec.h
index 56643b27e4b8..e32b0e1a81a4 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -174,6 +174,8 @@ struct cec_adapter {
bool passthrough;
struct cec_log_addrs log_addrs;
 
+   u32 tx_timeouts;
+
 #ifdef CONFIG_CEC_NOTIFIER
struct cec_notifier *notifier;
 #endif
-- 
2.11.0

[PATCH 00/11] drm/sun4i: add CEC support

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds CEC support for the sun4i HDMI controller.

The CEC hardware support for the A10 is very low-level as it just
controls the CEC pin. Since I also wanted to support GPIO-based CEC
hardware most of this patch series is in the CEC framework to
add a generic low-level CEC pin framework. It is only the final patch
that adds the sun4i support.

This patch series first makes some small changes in the CEC framework
(patches 1-4) to prepare for this CEC pin support.

Patch 5-7 adds the new API elements and documents it. Patch 6 reworks
the CEC core event handling.

Patch 8 adds pin monitoring support (allows userspace to see all
CEC pin transitions as they happen).

Patch 9 adds the core cec-pin implementation that translates low-level
pin transitions into valid CEC messages. Basically this does what any
SoC with a proper CEC hardware implementation does.

Patch 10 documents the cec-pin kAPI (and also the cec-notifier kAPI
which was missing).

Finally patch 11 adds the actual sun4i_hdmi CEC implementation.

I tested this on my cubieboard. There were no errors at all
after 126264 calls of 'cec-ctl --give-device-vendor-id' while at the
same time running a 'make -j4' of the v4l-utils git repository and
doing a continuous scp to create network traffic.

This patch series is based on top of the mainline kernel as of
yesterday (so with all the sun4i and cec patches for 4.13 merged).

Maxime, patches 1-10 will go through the media subsystem. How do you
want to handle the final patch? It can either go through the media
subsystem as well, or you can sit on it and handle this yourself during
the 4.14 merge window. Another option is to separate the Kconfig change
into its own patch. That way you can merge the code changes and only
have to handle the Kconfig patch as a final change during the merge
window.

Regards,

Hans

Hans Verkuil (11):
  cec: improve transmit timeout logging
  cec: add *_ts variants for transmit_done/received_msg
  cec: add adap_free op
  cec-core.rst: document the adap_free callback
  linux/cec.h: add pin monitoring API support
  cec: rework the cec event handling
  cec: document the new CEC pin capability, events and mode
  cec: add core support for low-level CEC pin monitoring
  cec-pin: add low-level pin hardware support
  cec-core.rst: include cec-pin.h and cec-notifier.h
  sun4i_hdmi: add CEC support

 Documentation/media/kapi/cec-core.rst  |  40 ++
 .../media/uapi/cec/cec-ioc-adap-g-caps.rst |   7 +
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst   |  20 +
 Documentation/media/uapi/cec/cec-ioc-g-mode.rst|  19 +-
 drivers/gpu/drm/sun4i/Kconfig  |   9 +
 drivers/gpu/drm/sun4i/sun4i_hdmi.h |   8 +
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c |  57 +-
 drivers/media/Kconfig  |   3 +
 drivers/media/cec/Makefile |   4 +
 drivers/media/cec/cec-adap.c   | 196 +++--
 drivers/media/cec/cec-api.c|  73 +-
 drivers/media/cec/cec-core.c   |   2 +
 drivers/media/cec/cec-pin.c| 794 +
 include/media/cec-pin.h| 183 +
 include/media/cec.h|  64 +-
 include/uapi/linux/cec.h   |   8 +-
 16 files changed, 1389 insertions(+), 98 deletions(-)
 create mode 100644 drivers/media/cec/cec-pin.c
 create mode 100644 include/media/cec-pin.h

-- 
2.11.0

[PATCH 06/11] cec: rework the cec event handling

[Hans Verkuil]

From: Hans Verkuil 

Event handling was always fairly simplistic since there were only
two events. With the addition of pin events this needed to be redesigned.

The state_change and lost_msgs events are now core events with the
guarantee that the last state is always available. The new pin events
are a queue of events (up to 64 for each event) and the oldest event
will be dropped if the application cannot keep up. Lost events are
marked with a new event flag.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-adap.c | 128 +--
 drivers/media/cec/cec-api.c  |  48 +++-
 include/media/cec.h  |  14 -
 include/uapi/linux/cec.h |   3 +-
 4 files changed, 124 insertions(+), 69 deletions(-)

diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index b3163716d95f..67ec66c7c4ff 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -78,42 +78,62 @@ static unsigned int cec_log_addr2dev(const struct 
cec_adapter *adap, u8 log_addr
  * Queue a new event for this filehandle. If ts == 0, then set it
  * to the current time.
  *
- * The two events that are currently defined do not need to keep track
- * of intermediate events, so no actual queue of events is needed,
- * instead just store the latest state and the total number of lost
- * messages.
- *
- * Should new events be added in the future that require intermediate
- * results to be queued as well, then a proper queue data structure is
- * required. But until then, just keep it simple.
+ * We keep a queue of at most max_event events where max_event differs
+ * per event. If the queue becomes full, then drop the oldest event and
+ * keep track of how many events we've dropped.
  */
 void cec_queue_event_fh(struct cec_fh *fh,
const struct cec_event *new_ev, u64 ts)
 {
-   struct cec_event *ev = >events[new_ev->event - 1];
+   static const u8 max_events[CEC_NUM_EVENTS] = {
+   1, 1, 64, 64,
+   };
+   struct cec_event_entry *entry;
+   unsigned int ev_idx = new_ev->event - 1;
+
+   if (WARN_ON(ev_idx >= ARRAY_SIZE(fh->events)))
+   return;
 
if (ts == 0)
ts = ktime_get_ns();
 
mutex_lock(>lock);
-   if (new_ev->event == CEC_EVENT_LOST_MSGS &&
-   fh->pending_events & (1 << new_ev->event)) {
-   /*
-* If there is already a lost_msgs event, then just
-* update the lost_msgs count. This effectively
-* merges the old and new events into one.
-*/
-   ev->lost_msgs.lost_msgs += new_ev->lost_msgs.lost_msgs;
-   goto unlock;
-   }
+   if (ev_idx < CEC_NUM_CORE_EVENTS)
+   entry = >core_events[ev_idx];
+   else
+   entry = kmalloc(sizeof(*entry), GFP_KERNEL);
+   if (entry) {
+   if (new_ev->event == CEC_EVENT_LOST_MSGS &&
+   fh->queued_events[ev_idx]) {
+   entry->ev.lost_msgs.lost_msgs +=
+   new_ev->lost_msgs.lost_msgs;
+   goto unlock;
+   }
+   entry->ev = *new_ev;
+   entry->ev.ts = ts;
+
+   if (fh->queued_events[ev_idx] < max_events[ev_idx]) {
+   /* Add new msg at the end of the queue */
+   list_add_tail(>list, >events[ev_idx]);
+   fh->queued_events[ev_idx]++;
+   fh->total_queued_events++;
+   goto unlock;
+   }
 
-   /*
-* Intermediate states are not interesting, so just
-* overwrite any older event.
-*/
-   *ev = *new_ev;
-   ev->ts = ts;
-   fh->pending_events |= 1 << new_ev->event;
+   if (ev_idx >= CEC_NUM_CORE_EVENTS) {
+   list_add_tail(>list, >events[ev_idx]);
+   /* drop the oldest event */
+   entry = list_first_entry(>events[ev_idx],
+struct cec_event_entry, list);
+   list_del(>list);
+   kfree(entry);
+   }
+   }
+   /* Mark that events were lost */
+   entry = list_first_entry_or_null(>events[ev_idx],
+struct cec_event_entry, list);
+   if (entry)
+   entry->ev.flags |= CEC_EVENT_FL_DROPPED_EVENTS;
 
 unlock:
mutex_unlock(>lock);
@@ -134,46 +154,50 @@ static void cec_queue_event(struct cec_adapter *adap,
 }
 
 /*
- * Queue a new message for this filehandle. If there is no more room
- * in the queue, then send the LOST_MSGS event instead.
+ * Queue a new message for this filehandle.
+ *
+ * We keep a queue of at most CEC_MAX_MSG_RX_QUEUE_SZ messages. If the
+ * queue becomes full, then drop the oldest 

[PATCH 03/11] cec: add adap_free op

[Hans Verkuil]

From: Hans Verkuil 

This is needed for CEC adapters that allocate resources that have
to be freed before the cec_adapter is deleted.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-core.c | 2 ++
 include/media/cec.h  | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index b516d599d6c4..2e5765344d07 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -374,6 +374,8 @@ void cec_delete_adapter(struct cec_adapter *adap)
kthread_stop(adap->kthread);
if (adap->kthread_config)
kthread_stop(adap->kthread_config);
+   if (adap->ops->adap_free)
+   adap->ops->adap_free(adap);
 #ifdef CONFIG_MEDIA_CEC_RC
rc_free_device(adap->rc);
 #endif
diff --git a/include/media/cec.h b/include/media/cec.h
index e1e60dbb66c3..37768203572d 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -114,6 +114,7 @@ struct cec_adap_ops {
int (*adap_transmit)(struct cec_adapter *adap, u8 attempts,
 u32 signal_free_time, struct cec_msg *msg);
void (*adap_status)(struct cec_adapter *adap, struct seq_file *file);
+   void (*adap_free)(struct cec_adapter *adap);
 
/* High-level CEC message callback */
int (*received)(struct cec_adapter *adap, struct cec_msg *msg);
-- 
2.11.0

[PATCH 11/11] sun4i_hdmi: add CEC support

[Hans Verkuil]

From: Hans Verkuil 

Add HDMI CEC support to the Allwinner A10 SoC.

This SoC uses a poor-man's CEC implementation by polling the CEC pin. It is
using the CEC_PIN core implementation for such devices to do the heavy
lifting. It just provides the callbacks to read/drive the CEC pin.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/sun4i/Kconfig  |  9 ++
 drivers/gpu/drm/sun4i/sun4i_hdmi.h |  8 +
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 57 +-
 3 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 5bcad8f5fb4f..e884d265c0b3 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -21,6 +21,15 @@ config DRM_SUN4I_HDMI
  Choose this option if you have an Allwinner SoC with an HDMI
  controller.
 
+config DRM_SUN4I_HDMI_CEC
+   bool "Allwinner A10 HDMI CEC Support"
+   depends on DRM_SUN4I_HDMI
+   select CEC_CORE
+   select CEC_PIN
+   help
+ Choose this option if you have an Allwinner SoC with an HDMI
+ controller and want to use CEC.
+
 config DRM_SUN4I_BACKEND
tristate "Support for Allwinner A10 Display Engine Backend"
depends on DRM_SUN4I
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index 2f2f2ff1ea63..8263de225b36 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -15,6 +15,8 @@
 #include 
 #include 
 
+#include 
+
 #define SUN4I_HDMI_CTRL_REG0x004
 #define SUN4I_HDMI_CTRL_ENABLE BIT(31)
 
@@ -86,6 +88,11 @@
 #define SUN4I_HDMI_PLL_DBG0_TMDS_PARENT_MASK   BIT(21)
 #define SUN4I_HDMI_PLL_DBG0_TMDS_PARENT_SHIFT  21
 
+#define SUN4I_HDMI_CEC 0x214
+#define SUN4I_HDMI_CEC_ENABLE  BIT(11)
+#define SUN4I_HDMI_CEC_TX  BIT(9)
+#define SUN4I_HDMI_CEC_RX  BIT(8)
+
 #define SUN4I_HDMI_PKT_CTRL_REG(n) (0x2f0 + (4 * (n)))
 #define SUN4I_HDMI_PKT_CTRL_TYPE(n, t) ((t) << (((n) % 4) * 4))
 
@@ -149,6 +156,7 @@ struct sun4i_hdmi {
struct sun4i_drv*drv;
 
boolhdmi_monitor;
+   struct cec_adapter  *cec_adap;
 };
 
 int sun4i_ddc_create(struct sun4i_hdmi *hdmi, struct clk *clk);
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index d3398f6250ef..8b89b4e25893 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -271,6 +271,9 @@ static int sun4i_hdmi_get_modes(struct drm_connector 
*connector)
clk_set_rate(hdmi->ddc_clk, 10);
 
edid = drm_do_get_edid(connector, sun4i_hdmi_read_edid_block, hdmi);
+
+   cec_s_phys_addr_from_edid(hdmi->cec_adap, edid);
+
if (!edid)
return 0;
 
@@ -299,8 +302,10 @@ sun4i_hdmi_connector_detect(struct drm_connector 
*connector, bool force)
 
if (readl_poll_timeout(hdmi->base + SUN4I_HDMI_HPD_REG, reg,
   reg & SUN4I_HDMI_HPD_HIGH,
-  0, 50))
+  0, 50)) {
+   cec_phys_addr_invalidate(hdmi->cec_adap);
return connector_status_disconnected;
+   }
 
return connector_status_connected;
 }
@@ -315,6 +320,40 @@ static const struct drm_connector_funcs 
sun4i_hdmi_connector_funcs = {
.atomic_destroy_state   = drm_atomic_helper_connector_destroy_state,
 };
 
+#ifdef CONFIG_DRM_SUN4I_HDMI_CEC
+static bool sun4i_hdmi_cec_pin_read(struct cec_adapter *adap)
+{
+   struct sun4i_hdmi *hdmi = cec_get_drvdata(adap);
+
+   return readl(hdmi->base + SUN4I_HDMI_CEC) & SUN4I_HDMI_CEC_RX;
+}
+
+static void sun4i_hdmi_cec_pin_low(struct cec_adapter *adap)
+{
+   struct sun4i_hdmi *hdmi = cec_get_drvdata(adap);
+
+   /* Start driving the CEC pin low */
+   writel(SUN4I_HDMI_CEC_ENABLE, hdmi->base + SUN4I_HDMI_CEC);
+}
+
+static void sun4i_hdmi_cec_pin_high(struct cec_adapter *adap)
+{
+   struct sun4i_hdmi *hdmi = cec_get_drvdata(adap);
+
+   /*
+* Stop driving the CEC pin, the pull up will take over
+* unless another CEC device is driving the pin low.
+*/
+   writel(0, hdmi->base + SUN4I_HDMI_CEC);
+}
+
+static const struct cec_pin_ops sun4i_hdmi_cec_pin_ops = {
+   .read = sun4i_hdmi_cec_pin_read,
+   .low = sun4i_hdmi_cec_pin_low,
+   .high = sun4i_hdmi_cec_pin_high,
+};
+#endif
+
 static int sun4i_hdmi_bind(struct device *dev, struct device *master,
   void *data)
 {
@@ -430,6 +469,17 @@ static int sun4i_hdmi_bind(struct device *dev, struct 
device *master,
if (!hdmi->encoder.possible_crtcs)
return -EPROBE_DEFER;
 
+#ifdef CONFIG_DRM_SUN4I_HDMI_CEC
+   hdmi->cec_adap = cec_pin_allocate_adapter(_hdmi_cec_pin_ops,

[PATCH 02/11] cec: add *_ts variants for transmit_done/received_msg

[Hans Verkuil]

From: Hans Verkuil 

Currently the transmit_(attempt_)done and received_msg functions set
the timestamp themselves. For the upcoming low-level pin API we need
to pass this as an argument instead. So make _ts variants that allow
the caller to specify the timestamp.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-adap.c | 35 +++
 include/media/cec.h  | 32 
 2 files changed, 47 insertions(+), 20 deletions(-)

diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 644ce82ea2ed..b3163716d95f 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -471,12 +471,12 @@ int cec_thread_func(void *_adap)
 /*
  * Called by the CEC adapter if a transmit finished.
  */
-void cec_transmit_done(struct cec_adapter *adap, u8 status, u8 arb_lost_cnt,
-  u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt)
+void cec_transmit_done_ts(struct cec_adapter *adap, u8 status,
+ u8 arb_lost_cnt, u8 nack_cnt, u8 low_drive_cnt,
+ u8 error_cnt, ktime_t ts)
 {
struct cec_data *data;
struct cec_msg *msg;
-   u64 ts = ktime_get_ns();
 
dprintk(2, "%s: status %02x\n", __func__, status);
mutex_lock(>lock);
@@ -496,7 +496,7 @@ void cec_transmit_done(struct cec_adapter *adap, u8 status, 
u8 arb_lost_cnt,
 
/* Drivers must fill in the status! */
WARN_ON(status == 0);
-   msg->tx_ts = ts;
+   msg->tx_ts = ktime_to_ns(ts);
msg->tx_status |= status;
msg->tx_arb_lost_cnt += arb_lost_cnt;
msg->tx_nack_cnt += nack_cnt;
@@ -559,25 +559,26 @@ void cec_transmit_done(struct cec_adapter *adap, u8 
status, u8 arb_lost_cnt,
 unlock:
mutex_unlock(>lock);
 }
-EXPORT_SYMBOL_GPL(cec_transmit_done);
+EXPORT_SYMBOL_GPL(cec_transmit_done_ts);
 
-void cec_transmit_attempt_done(struct cec_adapter *adap, u8 status)
+void cec_transmit_attempt_done_ts(struct cec_adapter *adap,
+ u8 status, ktime_t ts)
 {
switch (status) {
case CEC_TX_STATUS_OK:
-   cec_transmit_done(adap, status, 0, 0, 0, 0);
+   cec_transmit_done_ts(adap, status, 0, 0, 0, 0, ts);
return;
case CEC_TX_STATUS_ARB_LOST:
-   cec_transmit_done(adap, status, 1, 0, 0, 0);
+   cec_transmit_done_ts(adap, status, 1, 0, 0, 0, ts);
return;
case CEC_TX_STATUS_NACK:
-   cec_transmit_done(adap, status, 0, 1, 0, 0);
+   cec_transmit_done_ts(adap, status, 0, 1, 0, 0, ts);
return;
case CEC_TX_STATUS_LOW_DRIVE:
-   cec_transmit_done(adap, status, 0, 0, 1, 0);
+   cec_transmit_done_ts(adap, status, 0, 0, 1, 0, ts);
return;
case CEC_TX_STATUS_ERROR:
-   cec_transmit_done(adap, status, 0, 0, 0, 1);
+   cec_transmit_done_ts(adap, status, 0, 0, 0, 1, ts);
return;
default:
/* Should never happen */
@@ -585,7 +586,7 @@ void cec_transmit_attempt_done(struct cec_adapter *adap, u8 
status)
return;
}
 }
-EXPORT_SYMBOL_GPL(cec_transmit_attempt_done);
+EXPORT_SYMBOL_GPL(cec_transmit_attempt_done_ts);
 
 /*
  * Called when waiting for a reply times out.
@@ -716,7 +717,8 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct 
cec_msg *msg,
 
if (msg->timeout)
dprintk(2, "%s: %*ph (wait for 0x%02x%s)\n",
-   __func__, msg->len, msg->msg, msg->reply, !block ? ", 
nb" : "");
+   __func__, msg->len, msg->msg, msg->reply,
+   !block ? ", nb" : "");
else
dprintk(2, "%s: %*ph%s\n",
__func__, msg->len, msg->msg, !block ? " (nb)" : "");
@@ -913,7 +915,8 @@ static const u8 cec_msg_size[256] = {
 };
 
 /* Called by the CEC adapter if a message is received */
-void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg)
+void cec_received_msg_ts(struct cec_adapter *adap,
+struct cec_msg *msg, ktime_t ts)
 {
struct cec_data *data;
u8 msg_init = cec_msg_initiator(msg);
@@ -941,7 +944,7 @@ void cec_received_msg(struct cec_adapter *adap, struct 
cec_msg *msg)
cec_has_log_addr(adap, msg_init))
return;
 
-   msg->rx_ts = ktime_get_ns();
+   msg->rx_ts = ktime_to_ns(ts);
msg->rx_status = CEC_RX_STATUS_OK;
msg->sequence = msg->reply = msg->timeout = 0;
msg->tx_status = 0;
@@ -1106,7 +1109,7 @@ void cec_received_msg(struct cec_adapter *adap, struct 
cec_msg *msg)
 */
cec_receive_notify(adap, msg, is_reply);
 }
-EXPORT_SYMBOL_GPL(cec_received_msg);
+EXPORT_SYMBOL_GPL(cec_received_msg_ts);
 
 /* Logical Address Handling */
 
diff --git a/include/media/cec.h 

[PATCH 09/11] cec-pin: add low-level pin hardware support

[Hans Verkuil]

From: Hans Verkuil 

Add support for CEC hardware that relies on low-level pin polling or
GPIO interrupts.

One example is the Allwinner SoC. But any GPIO-based CEC implementation can
use this as well.

A GPIO implementation is very suitable as well for debugging: it can use
interrupts to detect state changes and report it. Userspace can then verify
if the bus traffic is correct. This also makes error injection possible.

The disadvantage is that it is hard to get the timings right since linux
isn't a hard realtime system.

In general on an idle system it works quite well, but under load the timer
will miss its mark every so often.

The debugfs file /sys/kernel/debug/cec/cecX/status gives some statistics
with respect to the timer overruns.

When the adapter is unconfigured and the low-level driver supports
interrupts, then the interrupt will be used to detect changes. This should
be quite accurate. But when the adapter is configured a hrtimer has to be
used.

The hrtimer implements a state machine where for each state the code will
read the bus or drive the bus and go on to the next state. It will re-arm
the timer with a delay based on the next state.

Signed-off-by: Hans Verkuil 
---
 drivers/media/Kconfig   |   3 +
 drivers/media/cec/Makefile  |   4 +
 drivers/media/cec/cec-api.c |  10 +
 drivers/media/cec/cec-pin.c | 794 
 include/media/cec-pin.h | 183 ++
 include/media/cec.h |   4 +
 6 files changed, 998 insertions(+)
 create mode 100644 drivers/media/cec/cec-pin.c
 create mode 100644 include/media/cec-pin.h

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 55d9c2b82b7e..94d4e7759127 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -8,6 +8,9 @@ config CEC_CORE
 config CEC_NOTIFIER
bool
 
+config CEC_PIN
+   bool
+
 menuconfig MEDIA_SUPPORT
tristate "Multimedia support"
depends on HAS_IOMEM
diff --git a/drivers/media/cec/Makefile b/drivers/media/cec/Makefile
index eaf408e64669..3353c1741961 100644
--- a/drivers/media/cec/Makefile
+++ b/drivers/media/cec/Makefile
@@ -4,4 +4,8 @@ ifeq ($(CONFIG_CEC_NOTIFIER),y)
   cec-objs += cec-notifier.o
 endif
 
+ifeq ($(CONFIG_CEC_PIN),y)
+  cec-objs += cec-pin.o
+endif
+
 obj-$(CONFIG_CEC_CORE) += cec.o
diff --git a/drivers/media/cec/cec-api.c b/drivers/media/cec/cec-api.c
index 14279958dca1..8dd16e263452 100644
--- a/drivers/media/cec/cec-api.c
+++ b/drivers/media/cec/cec-api.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 
+#include 
 #include "cec-priv.h"
 
 static inline struct cec_devnode *cec_devnode_data(struct file *filp)
@@ -430,6 +431,15 @@ static long cec_s_mode(struct cec_adapter *adap, struct 
cec_fh *fh,
if (mode_follower == CEC_MODE_FOLLOWER)
adap->follower_cnt++;
if (mode_follower == CEC_MODE_MONITOR_PIN) {
+#ifdef CONFIG_CEC_PIN
+   struct cec_event ev = {
+   .flags = CEC_EVENT_FL_INITIAL_STATE,
+   };
+
+   ev.event = adap->pin->cur_value ? CEC_EVENT_PIN_HIGH :
+ CEC_EVENT_PIN_LOW;
+   cec_queue_event_fh(fh, , 0);
+#endif
adap->monitor_pin_cnt++;
}
if (mode_follower == CEC_MODE_EXCL_FOLLOWER ||
diff --git a/drivers/media/cec/cec-pin.c b/drivers/media/cec/cec-pin.c
new file mode 100644
index ..03f800e5ec1f
--- /dev/null
+++ b/drivers/media/cec/cec-pin.c
@@ -0,0 +1,794 @@
+/*
+ * 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 
+
+/* All timings are in microseconds */
+
+/* start bit timings */
+#define CEC_TIM_START_BIT_LOW  3700
+#define CEC_TIM_START_BIT_LOW_MIN  3500
+#define CEC_TIM_START_BIT_LOW_MAX  3900
+#define CEC_TIM_START_BIT_TOTAL4500
+#define CEC_TIM_START_BIT_TOTAL_MIN4300
+#define CEC_TIM_START_BIT_TOTAL_MAX4700
+
+/* data bit timings */
+#define CEC_TIM_DATA_BIT_0_LOW 1500
+#define CEC_TIM_DATA_BIT_0_LOW_MIN 1300
+#define CEC_TIM_DATA_BIT_0_LOW_MAX 1700
+#define CEC_TIM_DATA_BIT_1_LOW 600
+#define CEC_TIM_DATA_BIT_1_LOW_MIN 400

[PATCH 07/11] cec: document the new CEC pin capability, events and mode

[Hans Verkuil]

From: Hans Verkuil 

Document CEC_CAP_MONITOR_PIN, CEC_EVENT_PIN_LOW/HIGH,
CEC_EVENT_FL_DROPPED_EVENTS and CEC_MODE_MONITOR_PIN.

Signed-off-by: Hans Verkuil 
---
 Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst |  7 +++
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 20 
 Documentation/media/uapi/cec/cec-ioc-g-mode.rst  | 19 +--
 3 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst 
b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
index 6d7bf7bef3eb..882d6e025747 100644
--- a/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst
@@ -121,6 +121,13 @@ returns the information to the application. The ioctl 
never fails.
 high. This makes it impossible to use CEC to wake up displays that
set the HPD pin low when in standby mode, but keep the CEC bus
alive.
+* .. _`CEC-CAP-MONITOR-PIN`:
+
+  - ``CEC_CAP_MONITOR_PIN``
+  - 0x0080
+  - The CEC hardware can monitor CEC pin changes from low to high voltage
+and vice versa. When in pin monitoring mode the application will
+   receive ``CEC_EVENT_PIN_LOW`` and ``CEC_EVENT_PIN_HIGH`` events.
 
 
 
diff --git a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst 
b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
index 4d3570c2e0b3..3e2cd5fefd38 100644
--- a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
@@ -146,6 +146,20 @@ it is guaranteed that the state did change in between the 
two events.
   - 2
   - Generated if one or more CEC messages were lost because the
application didn't dequeue CEC messages fast enough.
+* .. _`CEC-EVENT-PIN-LOW`:
+
+  - ``CEC_EVENT_PIN_LOW``
+  - 3
+  - Generated if the CEC pin goes from a high voltage to a low voltage.
+Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
+   capability set.
+* .. _`CEC-EVENT-PIN-HIGH`:
+
+  - ``CEC_EVENT_PIN_HIGH``
+  - 4
+  - Generated if the CEC pin goes from a low voltage to a high voltage.
+Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
+   capability set.
 
 
 .. tabularcolumns:: |p{6.0cm}|p{0.6cm}|p{10.9cm}|
@@ -165,6 +179,12 @@ it is guaranteed that the state did change in between the 
two events.
opened. See the table above for which events do this. This allows
applications to learn the initial state of the CEC adapter at
open() time.
+* .. _`CEC-EVENT-FL-DROPPED-EVENTS`:
+
+  - ``CEC_EVENT_FL_DROPPED_EVENTS``
+  - 2
+  - Set if one or more events of the given event type have been dropped.
+This is an indication that the application cannot keep up.
 
 
 
diff --git a/Documentation/media/uapi/cec/cec-ioc-g-mode.rst 
b/Documentation/media/uapi/cec/cec-ioc-g-mode.rst
index 664f0d47bbcd..3e907c74338f 100644
--- a/Documentation/media/uapi/cec/cec-ioc-g-mode.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-g-mode.rst
@@ -149,13 +149,28 @@ Available follower modes are:
code. You cannot become a follower if :ref:`CEC_CAP_TRANSMIT 
`
is not set or if :ref:`CEC_MODE_NO_INITIATOR ` 
was specified,
the ``EINVAL`` error code is returned in that case.
+* .. _`CEC-MODE-MONITOR-PIN`:
+
+  - ``CEC_MODE_MONITOR_PIN``
+  - 0xd0
+  - Put the file descriptor into pin monitoring mode. Can only be used in
+   combination with :ref:`CEC_MODE_NO_INITIATOR `,
+   otherwise the ``EINVAL`` error code will be returned.
+   This mode requires that the :ref:`CEC_CAP_MONITOR_PIN 
`
+   capability is set, otherwise the ``EINVAL`` error code is returned.
+   While in pin monitoring mode this file descriptor can receive the
+   ``CEC_EVENT_PIN_LOW`` and ``CEC_EVENT_PIN_HIGH`` events to see the
+   low-level CEC pin transitions. This is very useful for debugging.
+   This mode is only allowed if the process has the ``CAP_NET_ADMIN``
+   capability. If that is not set, then the ``EPERM`` error code is 
returned.
 * .. _`CEC-MODE-MONITOR`:
 
   - ``CEC_MODE_MONITOR``
   - 0xe0
   - Put the file descriptor into monitor mode. Can only be used in
-   combination with :ref:`CEC_MODE_NO_INITIATOR `, 
otherwise EINVAL error
-   code will be returned. In monitor mode all messages this CEC
+   combination with :ref:`CEC_MODE_NO_INITIATOR `,i
+   otherwise the ``EINVAL`` error code will be returned.
+   In monitor mode all messages this CEC
device transmits and all messages it receives (both broadcast
messages and directed messages for one its logical addresses) will
be reported. This is very useful for debugging. This is only
-- 
2.11.0

[PATCH 08/11] cec: add core support for low-level CEC pin monitoring

[Hans Verkuil]

From: Hans Verkuil 

Add support for the new MONITOR_PIN mode.

Add the cec_pin_event function that the CEC pin code will call to queue pin
change events.

Signed-off-by: Hans Verkuil 
---
 drivers/media/cec/cec-adap.c | 16 
 drivers/media/cec/cec-api.c  | 15 +--
 include/media/cec.h  | 11 +++
 3 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 67ec66c7c4ff..cbde6b015ff5 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -153,6 +153,22 @@ static void cec_queue_event(struct cec_adapter *adap,
mutex_unlock(>devnode.lock);
 }
 
+/* Notify userspace that the CEC pin changed state at the given time. */
+void cec_queue_pin_event(struct cec_adapter *adap, bool is_high, ktime_t ts)
+{
+   struct cec_event ev = {
+   .event = is_high ? CEC_EVENT_PIN_HIGH : CEC_EVENT_PIN_LOW,
+   };
+   struct cec_fh *fh;
+
+   mutex_lock(>devnode.lock);
+   list_for_each_entry(fh, >devnode.fhs, list)
+   if (fh->mode_follower == CEC_MODE_MONITOR_PIN)
+   cec_queue_event_fh(fh, , ktime_to_ns(ts));
+   mutex_unlock(>devnode.lock);
+}
+EXPORT_SYMBOL_GPL(cec_queue_pin_event);
+
 /*
  * Queue a new message for this filehandle.
  *
diff --git a/drivers/media/cec/cec-api.c b/drivers/media/cec/cec-api.c
index 48bef1c718ad..14279958dca1 100644
--- a/drivers/media/cec/cec-api.c
+++ b/drivers/media/cec/cec-api.c
@@ -370,6 +370,10 @@ static long cec_s_mode(struct cec_adapter *adap, struct 
cec_fh *fh,
!(adap->capabilities & CEC_CAP_MONITOR_ALL))
return -EINVAL;
 
+   if (mode_follower == CEC_MODE_MONITOR_PIN &&
+   !(adap->capabilities & CEC_CAP_MONITOR_PIN))
+   return -EINVAL;
+
/* Follower modes should always be able to send CEC messages */
if ((mode_initiator == CEC_MODE_NO_INITIATOR ||
 !(adap->capabilities & CEC_CAP_TRANSMIT)) &&
@@ -378,11 +382,11 @@ static long cec_s_mode(struct cec_adapter *adap, struct 
cec_fh *fh,
return -EINVAL;
 
/* Monitor modes require CEC_MODE_NO_INITIATOR */
-   if (mode_initiator && mode_follower >= CEC_MODE_MONITOR)
+   if (mode_initiator && mode_follower >= CEC_MODE_MONITOR_PIN)
return -EINVAL;
 
/* Monitor modes require CAP_NET_ADMIN */
-   if (mode_follower >= CEC_MODE_MONITOR && !capable(CAP_NET_ADMIN))
+   if (mode_follower >= CEC_MODE_MONITOR_PIN && !capable(CAP_NET_ADMIN))
return -EPERM;
 
mutex_lock(>lock);
@@ -421,8 +425,13 @@ static long cec_s_mode(struct cec_adapter *adap, struct 
cec_fh *fh,
 
if (fh->mode_follower == CEC_MODE_FOLLOWER)
adap->follower_cnt--;
+   if (fh->mode_follower == CEC_MODE_MONITOR_PIN)
+   adap->monitor_pin_cnt--;
if (mode_follower == CEC_MODE_FOLLOWER)
adap->follower_cnt++;
+   if (mode_follower == CEC_MODE_MONITOR_PIN) {
+   adap->monitor_pin_cnt++;
+   }
if (mode_follower == CEC_MODE_EXCL_FOLLOWER ||
mode_follower == CEC_MODE_EXCL_FOLLOWER_PASSTHRU) {
adap->passthrough =
@@ -566,6 +575,8 @@ static int cec_release(struct inode *inode, struct file 
*filp)
}
if (fh->mode_follower == CEC_MODE_FOLLOWER)
adap->follower_cnt--;
+   if (fh->mode_follower == CEC_MODE_MONITOR_PIN)
+   adap->monitor_pin_cnt--;
if (fh->mode_follower == CEC_MODE_MONITOR_ALL)
cec_monitor_all_cnt_dec(adap);
mutex_unlock(>lock);
diff --git a/include/media/cec.h b/include/media/cec.h
index 6cc862af74e5..d983960b37ad 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -177,6 +177,7 @@ struct cec_adapter {
bool is_configuring;
bool is_configured;
u32 monitor_all_cnt;
+   u32 monitor_pin_cnt;
u32 follower_cnt;
struct cec_fh *cec_follower;
struct cec_fh *cec_initiator;
@@ -272,6 +273,16 @@ static inline void cec_received_msg(struct cec_adapter 
*adap,
 }
 
 /**
+ * cec_queue_pin_event() - queue a pin event with a given timestamp.
+ *
+ * @adap:  pointer to the cec adapter
+ * @is_high:   when true the pin is high, otherwise it is low
+ * @ts:the timestamp for this event
+ *
+ */
+void cec_queue_pin_event(struct cec_adapter *adap, bool is_high, ktime_t ts);
+
+/**
  * cec_get_edid_phys_addr() - find and return the physical address
  *
  * @edid:  pointer to the EDID data
-- 
2.11.0

[PATCH 05/11] linux/cec.h: add pin monitoring API support

[Hans Verkuil]

From: Hans Verkuil 

Add support for low-level CEC pin monitoring. This adds a new monitor
mode, a new capability and two new events.

Signed-off-by: Hans Verkuil 
---
 include/uapi/linux/cec.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/uapi/linux/cec.h b/include/uapi/linux/cec.h
index 44579a24f95d..bba73f33c8aa 100644
--- a/include/uapi/linux/cec.h
+++ b/include/uapi/linux/cec.h
@@ -318,6 +318,7 @@ static inline int cec_is_unconfigured(__u16 log_addr_mask)
 #define CEC_MODE_FOLLOWER  (0x1 << 4)
 #define CEC_MODE_EXCL_FOLLOWER (0x2 << 4)
 #define CEC_MODE_EXCL_FOLLOWER_PASSTHRU(0x3 << 4)
+#define CEC_MODE_MONITOR_PIN   (0xd << 4)
 #define CEC_MODE_MONITOR   (0xe << 4)
 #define CEC_MODE_MONITOR_ALL   (0xf << 4)
 #define CEC_MODE_FOLLOWER_MSK  0xf0
@@ -338,6 +339,8 @@ static inline int cec_is_unconfigured(__u16 log_addr_mask)
 #define CEC_CAP_MONITOR_ALL(1 << 5)
 /* Hardware can use CEC only if the HDMI HPD pin is high. */
 #define CEC_CAP_NEEDS_HPD  (1 << 6)
+/* Hardware can monitor CEC pin transitions */
+#define CEC_CAP_MONITOR_PIN(1 << 7)
 
 /**
  * struct cec_caps - CEC capabilities structure.
@@ -405,6 +408,8 @@ struct cec_log_addrs {
  * didn't empty the message queue in time
  */
 #define CEC_EVENT_LOST_MSGS2
+#define CEC_EVENT_PIN_LOW  3
+#define CEC_EVENT_PIN_HIGH 4
 
 #define CEC_EVENT_FL_INITIAL_STATE (1 << 0)
 
-- 
2.11.0