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:   Mon Mar 12 05:00:11 CET 2018
media-tree git hash:e68854a2588a923b31eebce348f8020374843f8e
media_build git hash:   2a1900fddab68c7686e6b146ff91e02b32675fae
v4l-utils git hash: 14ce03c18ef67aa7a3d5781f015be855fd43839c
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: v0.5.0-3994-g45eb2282
smatch version: v0.5.0-3994-g45eb2282
host hardware:  x86_64
host os:4.14.0-3-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: WARNINGS
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: ERRORS
linux-2.6.36.4-x86_64: ERRORS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.98-i686: ERRORS
linux-3.2.98-x86_64: ERRORS
linux-3.3.8-i686: ERRORS
linux-3.3.8-x86_64: ERRORS
linux-3.4.27-i686: ERRORS
linux-3.4.27-x86_64: ERRORS
linux-3.5.7-i686: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.53-i686: WARNINGS
linux-3.16.53-x86_64: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.93-i686: WARNINGS
linux-3.18.93-x86_64: WARNINGS
linux-3.19-i686: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.49-i686: WARNINGS
linux-4.1.49-x86_64: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.115-i686: OK
linux-4.4.115-x86_64: OK
linux-4.5.7-i686: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-i686: OK
linux-4.7.5-x86_64: WARNINGS
linux-4.8-i686: OK
linux-4.8-x86_64: WARNINGS
linux-4.9.80-i686: OK
linux-4.9.80-x86_64: OK
linux-4.10.14-i686: OK
linux-4.10.14-x86_64: WARNINGS
linux-4.11-i686: OK
linux-4.11-x86_64: WARNINGS
linux-4.12.1-i686: OK
linux-4.12.1-x86_64: WARNINGS
linux-4.13-i686: OK
linux-4.13-x86_64: OK
linux-4.14.17-i686: OK
linux-4.14.17-x86_64: OK
linux-4.15.2-i686: WARNINGS
linux-4.15.2-x86_64: WARNINGS
linux-4.16-rc1-i686: WARNINGS
linux-4.16-rc1-x86_64: WARNINGS
apps: WARNINGS
spec-git: OK
sparse: WARNINGS
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

[Nick French]

On Sun, Mar 11, 2018 at 11:24:38PM +, Ian Armstrong wrote:
> On Sat, 10 Mar 2018 16:57:41 +
> "French, Nicholas A."  wrote:
> 
> > > > No what if the framebuffer driver is just requested as a
> > > > secondary step after firmware loading?  
> > >
> > > Its a possibility. The decoder firmware gets loaded at the
> > > beginning of the decoder memory range and we know its length, so
> > > its possible to ioremap_nocache enough room for the firmware only
> > > on init and then ioremap the remaining non-firmware decoder memory
> > > areas appropriately after the firmware load succeeds...  
> > 
> > I looked in more detail, and this would be "hard" due to the way the
> > rest of the decoder offsets are determined by either making firmware
> > calls or scanning the decoder memory range for magic bytes and other
> > mess.
> 
> The buffers used for yuv output are fixed. They are located both before
> and after the framebuffer. Their offset is fixed at 'base_addr +
> IVTV_DECODER_OFFSET + yuv_offset[]'. The yuv offsets can be found in
> 'ivtv-yuv.c'. The buffers are 622080 bytes in length.
> 
> The range would be from 'base_addr + 0x0100 + 0x00029000' to
> 'base_addr + 0x0100 + 0x00748200 + 0x97dff'. This is larger than
> required, but will catch the framebuffer and should not cause any
> problems. If you wanted to render direct to the yuv buffers, you would
> probably want this region included anyway (not that the current driver
> supports that).

Am I correct that you are talking about the possibility of re-ioremap()-ing
the 'yuv-fb-yuv' area *after* loading the firmware, not of mapping ranges
correctly on the first go-around?

Because unless my math is letting me down, the decoder firmware is already
loaded from 'base_addr + 0x0100 + 0x0' to 'base_addr + 0x0100 + 0x3'
which overlaps the beginning of the yuv range.

- Nick

[PATCH v6-1,15/17] arm64: dts: rockchip: add isp0 node for rk3399

[Shunqian Zheng]

rk3399 have two ISP, but we havn't test isp1, so just add isp0 at present.

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

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 2605118..5729786 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1614,6 +1614,24 @@
status = "disabled";
};
 
+   isp0: isp0@ff91 {
+   compatible = "rockchip,rk3399-cif-isp";
+   reg = <0x0 0xff91 0x0 0x4000>;
+   interrupts = ;
+   clocks = < SCLK_ISP0>,
+< ACLK_ISP0>, < ACLK_ISP0_WRAPPER>,
+< HCLK_ISP0>, < HCLK_ISP0_WRAPPER>;
+   clock-names = "clk_isp",
+ "aclk_isp", "aclk_isp_wrap",
+ "hclk_isp", "hclk_isp_wrap";
+   assigned-clocks = < SCLK_ISP0>, < ACLK_ISP0>;
+   assigned-clock-rates = <5>, <4>;
+
+   power-domains = < RK3399_PD_ISP0>;
+   iommus = <_mmu>;
+   status = "disabled";
+   };
+
isp0_mmu: iommu@ff914000 {
compatible = "rockchip,iommu";
reg = <0x0 0xff914000 0x0 0x100>, <0x0 0xff915000 0x0 0x100>;
-- 
1.9.1

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

[Ian Armstrong]

On Sat, 10 Mar 2018 16:57:41 +
"French, Nicholas A."  wrote:

> > > No what if the framebuffer driver is just requested as a
> > > secondary step after firmware loading?  
> >
> > Its a possibility. The decoder firmware gets loaded at the
> > beginning of the decoder memory range and we know its length, so
> > its possible to ioremap_nocache enough room for the firmware only
> > on init and then ioremap the remaining non-firmware decoder memory
> > areas appropriately after the firmware load succeeds...  
> 
> I looked in more detail, and this would be "hard" due to the way the
> rest of the decoder offsets are determined by either making firmware
> calls or scanning the decoder memory range for magic bytes and other
> mess.

The buffers used for yuv output are fixed. They are located both before
and after the framebuffer. Their offset is fixed at 'base_addr +
IVTV_DECODER_OFFSET + yuv_offset[]'. The yuv offsets can be found in
'ivtv-yuv.c'. The buffers are 622080 bytes in length.

The range would be from 'base_addr + 0x0100 + 0x00029000' to
'base_addr + 0x0100 + 0x00748200 + 0x97dff'. This is larger than
required, but will catch the framebuffer and should not cause any
problems. If you wanted to render direct to the yuv buffers, you would
probably want this region included anyway (not that the current driver
supports that).

-- 
Ian

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

[Nick French]

On Sun, Mar 11, 2018 at 01:19:03PM -0700, Andy Lutomirski wrote:
> From memory, I see two potentially reasonable real fixes. One is to find a 
> way to punch a hole in an ioremap.
> So you’d find the framebuffer, remove it from theproblematic mapping, and 
> then make a new mapping. 
> The second is to change the mapping type in place. 

For the changing-in-place method, is there already an exported API that exposes 
change_page_attr_set without first
calling reserve_memtype? I can't seem to find one.

> Or maybe you could just iounmap the whole thing after firmware is loaded and 
> the framebuffer is found and then
> redo the mapping right. 

I guess this would require a lock so that the ivtv-driver proper wasn't 
accessing the decoder's mapped memory 
during ivtvfb's iounmap-ioremap window. And a way to notify ivtv-driver proper 
if things go wrong? I think this method
would be very awkward because its not even memory owned by ivtvfb itself.

- Nick

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

[Andy Lutomirski]

> On Mar 11, 2018, at 12:51 PM, Nick French  wrote:
> 
> On Sat, Mar 10, 2018 at 10:20:23AM -0800, Andy Lutomirski wrote:
 Perhaps the easy answer is to change the fatal is-pat-enabled check to just
 a warning like "you have PAT enabled, so wc is disabled for the 
 framebuffer.
 if you want wc, use the nopat parameter"?
>>> 
>>> I like this idea more and more. I haven't experience any problems running
>>> with PAT-enabled and no write-combining on the framebuffer. Any objections?
>>> 
>> 
>> None from me.
>> 
>> However, since you have the hardware, you could see if you can use the
>> change_page_attr machinery to change the memory type on the framebuffer once
>> you figure out where it is.
> 
> I am certainly willing to try this, but my understanding of the goal of the
> changes that disabled ivtvfb originally is that it was trying to hide the
> architecture-specific memory management from the driver.

Not really. The goal was to eliminate all code that touches MTRRs on PAT 
systems. So mtrr_add got unexported and the arch_phys are legacy hints that do 
nothing on modern machines. 

> 
> Wouldn't (figuring out a way to) expose x86/mm/pageattr internals to the
> driver be doing the opposite? (or maybe I misunderstand your suggestion)

It doesn’t conflict at all.  Obviously the code should be tidy. 

From memory, I see two potentially reasonable real fixes. One is to find a way 
to punch a hole in an ioremap. So you’d find the framebuffer, remove it from 
theproblematic mapping, and then make a new mapping. The second is to change 
the mapping type in place. 

Or maybe you could just iounmap the whole thing after firmware is loaded and 
the framebuffer is found and then redo the mapping right. 

Re: [PATCH 5/5] media: MAINTAINERS: Add entry for Aptina MT9T112

[Sakari Ailus]

Hi Jacopo,

On Fri, Mar 02, 2018 at 05:35:41PM +0100, Jacopo Mondi wrote:
> Add entry for Aptina/Micron MT9T112 camera sensor. The driver is
> currently orphaned.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  MAINTAINERS | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 91ed6ad..1d8be25 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9385,6 +9385,13 @@ S: Maintained
>  F:   drivers/media/i2c/mt9t001.c
>  F:   include/media/i2c/mt9t001.h
>  
> +MT9T112 APTINA CAMERA SENSOR
> +L:   linux-media@vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +S:   Orphan

I don't like adding a driver which is in orphaned state to begin with.

Would you like to maintain it? :-)

> +F:   drivers/media/i2c/mt9t112.c
> +F:   include/media/i2c/mt9t112.h
> +
>  MT9V032 APTINA CAMERA SENSOR
>  M:   Laurent Pinchart 
>  L:   linux-media@vger.kernel.org

-- 
Regards,

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

Re: ivtv: use arch_phys_wc_add() and require PAT disabled

[Nick French]

On Sat, Mar 10, 2018 at 10:20:23AM -0800, Andy Lutomirski wrote:
>>> Perhaps the easy answer is to change the fatal is-pat-enabled check to just
>>> a warning like "you have PAT enabled, so wc is disabled for the framebuffer.
>>> if you want wc, use the nopat parameter"?
>>
>> I like this idea more and more. I haven't experience any problems running
>> with PAT-enabled and no write-combining on the framebuffer. Any objections?
>>
>
> None from me.
>
> However, since you have the hardware, you could see if you can use the
> change_page_attr machinery to change the memory type on the framebuffer once
> you figure out where it is.

I am certainly willing to try this, but my understanding of the goal of the
changes that disabled ivtvfb originally is that it was trying to hide the
architecture-specific memory management from the driver.

Wouldn't (figuring out a way to) expose x86/mm/pageattr internals to the
driver be doing the opposite? (or maybe I misunderstand your suggestion)

- Nick

Re: [RFCv4,19/21] media: vim2m: add request support

[Dmitry Osipenko]

Hello,

On 07.03.2018 19:37, Paul Kocialkowski wrote:
> Hi,
> 
> First off, I'd like to take the occasion to say thank-you for your work.
> This is a major piece of plumbing that is required for me to add support
> for the Allwinner CedarX VPU hardware in upstream Linux. Other drivers,
> such as tegra-vde (that was recently merged in staging) are also badly
> in need of this API.

Certainly it would be good to have a common UAPI. Yet I haven't got my hands on
trying to implement the V4L interface for the tegra-vde driver, but I've taken a
look at Cedrus driver and for now I've one question:

Would it be possible (or maybe already is) to have a single IOCTL that takes
input/output buffers with codec parameters, processes the request(s) and returns
to userspace when everything is done? Having 5 context switches for a single
frame decode (like Cedrus VAAPI driver does) looks like a bit of overhead.

> I have a few comments based on my experience integrating this request
> API with the Cedrus VPU driver (and the associated libva backend), that
> also concern the vim2m driver.
> 
> On Tue, 2018-02-20 at 13:44 +0900, Alexandre Courbot wrote:
>> Set the necessary ops for supporting requests in vim2m.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/media/platform/Kconfig |  1 +
>>  drivers/media/platform/vim2m.c | 75
>> ++
>>  2 files changed, 76 insertions(+)
>>
>> diff --git a/drivers/media/platform/Kconfig
>> b/drivers/media/platform/Kconfig
>> index 614fbef08ddc..09be0b5f9afe 100644
>> --- a/drivers/media/platform/Kconfig
>> +++ b/drivers/media/platform/Kconfig
> 
> [...]
> 
>> +static int vim2m_request_submit(struct media_request *req,
>> +struct media_request_entity_data
>> *_data)
>> +{
>> +struct v4l2_request_entity_data *data;
>> +
>> +data = to_v4l2_entity_data(_data);
> 
> We need to call v4l2_m2m_try_schedule here so that m2m scheduling can
> happen when only 2 buffers were queued and no other action was taken
> from usespace. In that scenario, m2m scheduling currently doesn't
> happen.
> 
> However, this requires access to the m2m context, which is not easy to
> get from req or _data. I'm not sure that some container_of magic would
> even do the trick here.
> 
>> +return vb2_request_submit(data);
> 
> vb2_request_submit does not lock the associated request mutex although
> it accesses the associated queued buffers list, which I believe this
> mutex is supposed to protect.
> 
> We could either wrap this call with media_request_lock(req) and
> media_request_unlock(req) or have the lock in the function itself, which
> would require passing it the req pointer.
> 
> The latter would probably be safer for future use of the function.
> 
>> +}
>> +
>> +static const struct media_request_entity_ops vim2m_request_entity_ops
>> = {
>> +.data_alloc = vim2m_entity_data_alloc,
>> +.data_free  = v4l2_request_entity_data_free,
>> +.submit = vim2m_request_submit,
>> +};
>> +
>>  /*
>>   * File operations
>>   */
>> @@ -900,6 +967,9 @@ static int vim2m_open(struct file *file)
>>  ctx->dev = dev;
>>  hdl = >hdl;
>>  v4l2_ctrl_handler_init(hdl, 4);
>> +v4l2_request_entity_init(>req_entity,
>> _request_entity_ops,
>> + >dev->vfd);
>> +ctx->fh.entity = >req_entity.base;
>>  v4l2_ctrl_new_std(hdl, _ctrl_ops, V4L2_CID_HFLIP, 0, 1,
>> 1, 0);
>>  v4l2_ctrl_new_std(hdl, _ctrl_ops, V4L2_CID_VFLIP, 0, 1,
>> 1, 0);
>>  v4l2_ctrl_new_custom(hdl, _ctrl_trans_time_msec, NULL);
>> @@ -999,6 +1069,9 @@ static int vim2m_probe(struct platform_device
>> *pdev)
>>  if (!dev)
>>  return -ENOMEM;
>>  
>> +v4l2_request_mgr_init(>req_mgr, >vfd,
>> +  _request_ops);
>> +
>>  spin_lock_init(>irqlock);
>>  
>>  ret = v4l2_device_register(>dev, >v4l2_dev);
>> @@ -1012,6 +1085,7 @@ static int vim2m_probe(struct platform_device
>> *pdev)
>>  vfd = >vfd;
>>  vfd->lock = >dev_mutex;
>>  vfd->v4l2_dev = >v4l2_dev;
>> +vfd->req_mgr = >req_mgr.base;
>>  
>>  ret = video_register_device(vfd, VFL_TYPE_GRABBER, 0);
>>  if (ret) {
>> @@ -1054,6 +1128,7 @@ static int vim2m_remove(struct platform_device
>> *pdev)
>>  del_timer_sync(>timer);
>>  video_unregister_device(>vfd);
>>  v4l2_device_unregister(>v4l2_dev);
>> +v4l2_request_mgr_free(>req_mgr);
>>  
>>  return 0;
>>  }
> 


-- 
Dmitry

[PATCH v2] media: ivtv: add parameter to enable ivtvfb on x86 PAT systems

[Nick French]

ivtvfb was previously disabled for x86 PAT-enabled systems
by commit 1bf1735b4780 ("x86/mm/pat, drivers/media/ivtv:
Use arch_phys_wc_add() and require PAT disabled") as a
workaround to abstract MTRR code away from device drivers.

The driver is not easily upgradable to the PAT-aware
ioremap_wc() API since the firmware hides the address
ranges that should be marked write-combined from the driver.
However, since a write-combined cache on the framebuffer
is only a performance enhancement not a requirement for
the framebuffer to function, completely disabling the driver
in this configuration is not necessary.

Add force_pat module parameter and a corresponding kernel
configuration parameter to optionally force initialization
on PAT-enabled x86 systems with a warning about the lack of
write-combined caching, and document the reasons the driver
cannot be easily updated to support wc caching on all systems.

Signed-off-by: Nick French 
---
Changes in v2:
 - Add wording to Kconfig parameter to memorialize the reasoning
   this driver cannot easily be upgraded to use ioremap_wc()

 drivers/media/pci/ivtv/Kconfig  | 23 ---
 drivers/media/pci/ivtv/ivtvfb.c | 19 +--
 2 files changed, 37 insertions(+), 5 deletions(-)

diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index c72cbbd2d40c..e5ebf7ca145c 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -70,8 +70,25 @@ config VIDEO_FB_IVTV
  This is used in the Hauppauge PVR-350 card. There is a driver
  homepage at .
 
- In order to use this module, you will need to boot with PAT disabled
- on x86 systems, using the nopat kernel parameter.
-
  To compile this driver as a module, choose M here: the
  module will be called ivtvfb.
+
+config VIDEO_FB_IVTV_FORCE_PAT
+   bool "force cx23415 frambuffer init with x86 PAT enabled"
+   depends on VIDEO_FB_IVTV && X86_PAT
+   default n
+   ---help---
+ With PAT enabled, the cx23415 framebuffer driver does not
+ utilize write-combined caching on the framebuffer memory.
+ For this reason, the driver will by default disable itself
+ when initializied on a kernel with PAT enabled (i.e. not
+ using the nopat kernel parameter).
+
+ The driver is not easily upgradable to the PAT-aware
+ ioremap_wc() API since the firmware hides the address
+ ranges that should be marked write-combined from the driver.
+
+ With this setting enabled, the framebuffer will initialize on
+ PAT-enabled systems but the framebuffer memory will be uncached.
+
+ If unsure, say N.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 621b2f613d81..5df74721aa19 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -55,6 +55,7 @@
 /* card parameters */
 static int ivtvfb_card_id = -1;
 static int ivtvfb_debug = 0;
+static bool ivtvfb_force_pat = IS_ENABLED(CONFIG_VIDEO_FB_IVTV_FORCE_PAT);
 static bool osd_laced;
 static int osd_depth;
 static int osd_upper;
@@ -64,6 +65,7 @@ static int osd_xres;
 
 module_param(ivtvfb_card_id, int, 0444);
 module_param_named(debug,ivtvfb_debug, int, 0644);
+module_param_named(force_pat, ivtvfb_force_pat, bool, 0644);
 module_param(osd_laced, bool, 0444);
 module_param(osd_depth, int, 0444);
 module_param(osd_upper, int, 0444);
@@ -79,6 +81,9 @@ MODULE_PARM_DESC(debug,
 "Debug level (bitmask). Default: errors only\n"
 "\t\t\t(debug = 3 gives full debugging)");
 
+MODULE_PARM_DESC(force_pat,
+"Force initialization on x86 PAT-enabled systems (bool).\n");
+
 /* Why upper, left, xres, yres, depth, laced ? To match terminology used
by fbset.
Why start at 1 for left & upper coordinate ? Because X doesn't allow 0 */
@@ -1169,8 +1174,18 @@ static int ivtvfb_init_card(struct ivtv *itv)
 
 #ifdef CONFIG_X86_64
if (pat_enabled()) {
-   pr_warn("ivtvfb needs PAT disabled, boot with nopat kernel 
parameter\n");
-   return -ENODEV;
+   if (ivtvfb_force_pat) {
+   pr_info("PAT is enabled. Write-combined framebuffer "
+   "caching will be disabled. To enable caching, "
+   "boot with nopat kernel parameter\n");
+   } else {
+   pr_warn("ivtvfb needs PAT disabled for write-combined "
+   "framebuffer caching. Boot with nopat kernel "
+   "parameter to use caching, or use the "
+   "force_pat module parameter to run with "
+   "caching disabled\n");
+   return -ENODEV;
+   }
}
 #endif
 
-- 
2.13.6

RE: [PATCH v7] media: imx258: Add imx258 camera sensor driver

[Yeh, Andy]

Dear all,

Please kindly check this v7.
I noticed many incorrect line breaks again in this mail which was not identical 
to the original patch. Not sure how it was resulted.
Such as 
-- Add one more resolution for 1048x780, used for VGA streaming "\n" since v6:
-- improved i2c read/write function to support writing 2 registers

+/* Mode : resolution and related config */ "\n" struct imx258_mode {

Therefore please help check the patch on the list, which is with correct line 
break.
https://patchwork.linuxtv.org/patch/47869/

Sorry to bring you inconvenience.


Regards, Andy

-Original Message-
From: Yeh, Andy 
Sent: Monday, March 12, 2018 12:02 AM
To: linux-media@vger.kernel.org; tf...@chromium.org
Cc: sakari.ai...@linux.intel.com; Yeh, Andy ; Chen, JasonX 
Z ; Chiang, AlanX ; Lai, Jim 

Subject: [PATCH v7] media: imx258: Add imx258 camera sensor driver

Add a V4L2 sub-device driver for the Sony IMX258 image sensor.
This is a camera sensor using the I2C bus for control and the
CSI-2 bus for data.

Signed-off-by: Jason Chen 
Signed-off-by: Alan Chiang 
---
since v2:
-- Update the streaming function to remove SW_STANDBY in the beginning.
-- Adjust the delay time from 1ms to 12ms before set stream-on register.
since v3:
-- fix the sd.entity to make code be compiled on the mainline kernel.
since v4:
-- Enabled AG, DG, and Exposure time control correctly.
since v5:
-- Sensor vendor provided a new setting to fix different CLK issue
-- Add one more resolution for 1048x780, used for VGA streaming since v6:
-- improved i2c read/write function to support writing 2 registers
-- modified i2c reg read/write function with a more portable way
-- utilized v4l2_find_nearest_size instead of the local find_best_fit function
-- defined an enum for the link freq entries for explicit indexing

 MAINTAINERS|7 +
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/imx258.c | 1299 
 4 files changed, 1318 insertions(+)
 create mode 100644 drivers/media/i2c/imx258.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a339bb5..9f75510 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12646,6 +12646,13 @@ S: Maintained
 F: drivers/ssb/
 F: include/linux/ssb/
 
+SONY IMX258 SENSOR DRIVER
+M: Sakari Ailus 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/imx258.c
+
 SONY IMX274 SENSOR DRIVER
 M: Leon Luo 
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 
fd01842..bcd4bf1 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -565,6 +565,17 @@ config VIDEO_APTINA_PLL  config VIDEO_SMIAPP_PLL
tristate
 
+config VIDEO_IMX258
+   tristate "Sony IMX258 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the Sony
+ IMX258 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx258.
+
 config VIDEO_IMX274
tristate "Sony IMX274 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API diff --git 
a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 
1b62639..4bf7d00 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -94,6 +94,7 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
 obj-$(CONFIG_VIDEO_ML86V7667)  += ml86v7667.o
 obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
 obj-$(CONFIG_VIDEO_TC358743)   += tc358743.o
+obj-$(CONFIG_VIDEO_IMX258) += imx258.o
 obj-$(CONFIG_VIDEO_IMX274) += imx274.o
 
 obj-$(CONFIG_SDR_MAX2175) += max2175.o
diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c new file 
mode 100644 index 000..6e695f1
--- /dev/null
+++ b/drivers/media/i2c/imx258.c
@@ -0,0 +1,1299 @@
+// Copyright (C) 2018 Intel Corporation // SPDX-License-Identifier: 
+GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IMX258_REG_VALUE_08BIT 1
+#define IMX258_REG_VALUE_16BIT 2
+
+#define IMX258_REG_MODE_SELECT 0x0100
+#define IMX258_MODE_STANDBY0x00
+#define IMX258_MODE_STREAMING  0x01
+
+/* Chip ID */
+#define IMX258_REG_CHIP_ID 0x0016
+#define IMX258_CHIP_ID 0x0258
+
+/* V_TIMING internal */
+#define IMX258_REG_VTS 0x0340
+#define IMX258_VTS_30FPS   0x0c98
+#define IMX258_VTS_MAX 0x
+
+/*Frame Length Line*/
+#define IMX258_FLL_MIN 0x08a6
+#define IMX258_FLL_MAX 0x
+#define 

RE: [PATCH v6] media: imx258: Add imx258 camera sensor driver

[Yeh, Andy]

Okay. All comments are addressed in v7.  
(https://patchwork.linuxtv.org/patch/47869/)

Thanks for all the comments and suggestions.

Regards, Andy

-Original Message-
From: Tomasz Figa [mailto:tf...@chromium.org] 
Sent: Friday, March 2, 2018 11:44 PM
To: Yeh, Andy 
Cc: Linux Media Mailing List ; Sakari Ailus 
; Chen, JasonX Z ; 
Chiang, AlanX 
Subject: Re: [PATCH v6] media: imx258: Add imx258 camera sensor driver

Hi Andy,

Thanks for the patch. Let me post some comments inline.

On Fri, Mar 2, 2018 at 11:55 PM, Andy Yeh  wrote:
> Add a V4L2 sub-device driver for the Sony IMX258 image sensor.
> This is a camera sensor using the I2C bus for control and the
> CSI-2 bus for data.
>
> Signed-off-by: Jason Chen 
> Signed-off-by: Alan Chiang 
> ---
> since v2:
> -- Update the streaming function to remove SW_STANDBY in the beginning.
> -- Adjust the delay time from 1ms to 12ms before set stream-on register.
> since v3:
> -- fix the sd.entity to make code be compiled on the mainline kernel.
> since v4:
> -- Enabled AG, DG, and Exposure time control correctly.
> since v5:
> -- Sensor vendor provided a new setting to fix different CLK issue
> -- Add one more resolution for 1048x780, used for VGA streaming

[PATCH v7] media: imx258: Add imx258 camera sensor driver

[Andy Yeh]

Add a V4L2 sub-device driver for the Sony IMX258 image sensor.
This is a camera sensor using the I2C bus for control and the
CSI-2 bus for data.

Signed-off-by: Jason Chen 
Signed-off-by: Alan Chiang 
---
since v2:
-- Update the streaming function to remove SW_STANDBY in the beginning.
-- Adjust the delay time from 1ms to 12ms before set stream-on register.
since v3:
-- fix the sd.entity to make code be compiled on the mainline kernel.
since v4:
-- Enabled AG, DG, and Exposure time control correctly.
since v5:
-- Sensor vendor provided a new setting to fix different CLK issue
-- Add one more resolution for 1048x780, used for VGA streaming
since v6:
-- improved i2c read/write function to support writing 2 registers
-- modified i2c reg read/write function with a more portable way
-- utilized v4l2_find_nearest_size instead of the local find_best_fit function
-- defined an enum for the link freq entries for explicit indexing

 MAINTAINERS|7 +
 drivers/media/i2c/Kconfig  |   11 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/imx258.c | 1299 
 4 files changed, 1318 insertions(+)
 create mode 100644 drivers/media/i2c/imx258.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a339bb5..9f75510 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12646,6 +12646,13 @@ S: Maintained
 F: drivers/ssb/
 F: include/linux/ssb/
 
+SONY IMX258 SENSOR DRIVER
+M: Sakari Ailus 
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/imx258.c
+
 SONY IMX274 SENSOR DRIVER
 M: Leon Luo 
 L: linux-media@vger.kernel.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index fd01842..bcd4bf1 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -565,6 +565,17 @@ config VIDEO_APTINA_PLL
 config VIDEO_SMIAPP_PLL
tristate
 
+config VIDEO_IMX258
+   tristate "Sony IMX258 sensor support"
+   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the Sony
+ IMX258 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called imx258.
+
 config VIDEO_IMX274
tristate "Sony IMX274 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 1b62639..4bf7d00 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -94,6 +94,7 @@ obj-$(CONFIG_VIDEO_IR_I2C)  += ir-kbd-i2c.o
 obj-$(CONFIG_VIDEO_ML86V7667)  += ml86v7667.o
 obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
 obj-$(CONFIG_VIDEO_TC358743)   += tc358743.o
+obj-$(CONFIG_VIDEO_IMX258) += imx258.o
 obj-$(CONFIG_VIDEO_IMX274) += imx274.o
 
 obj-$(CONFIG_SDR_MAX2175) += max2175.o
diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
new file mode 100644
index 000..6e695f1
--- /dev/null
+++ b/drivers/media/i2c/imx258.c
@@ -0,0 +1,1299 @@
+// Copyright (C) 2018 Intel Corporation
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IMX258_REG_VALUE_08BIT 1
+#define IMX258_REG_VALUE_16BIT 2
+
+#define IMX258_REG_MODE_SELECT 0x0100
+#define IMX258_MODE_STANDBY0x00
+#define IMX258_MODE_STREAMING  0x01
+
+/* Chip ID */
+#define IMX258_REG_CHIP_ID 0x0016
+#define IMX258_CHIP_ID 0x0258
+
+/* V_TIMING internal */
+#define IMX258_REG_VTS 0x0340
+#define IMX258_VTS_30FPS   0x0c98
+#define IMX258_VTS_MAX 0x
+
+/*Frame Length Line*/
+#define IMX258_FLL_MIN 0x08a6
+#define IMX258_FLL_MAX 0x
+#define IMX258_FLL_STEP1
+#define IMX258_FLL_DEFAULT 0x0c98
+
+/* HBLANK control - read only */
+#define IMX258_PPL_DEFAULT 5352
+
+/* Exposure control */
+#define IMX258_REG_EXPOSURE0x0202
+#define IMX258_EXPOSURE_MIN4
+#define IMX258_EXPOSURE_STEP   1
+#define IMX258_EXPOSURE_DEFAULT0x640
+#define IMX258_EXPOSURE_MAX65535
+
+/* Analog gain control */
+#define IMX258_REG_ANALOG_GAIN 0x0204
+#define IMX258_ANA_GAIN_MIN0
+#define IMX258_ANA_GAIN_MAX0x1fff
+#define IMX258_ANA_GAIN_STEP   1
+#define IMX258_ANA_GAIN_DEFAULT0x0
+
+/* Digital gain control */
+#define IMX258_REG_GR_DIGITAL_GAIN 0x020e
+#define IMX258_REG_R_DIGITAL_GAIN  0x0210
+#define IMX258_REG_B_DIGITAL_GAIN  0x0212
+#define IMX258_REG_GB_DIGITAL_GAIN 0x0214
+#define IMX258_DGTL_GAIN_MIN   0
+#define IMX258_DGTL_GAIN_MAX   

[PATCH] media: ov5640: add missing output pixel format setting

[Akinobu Mita]

The output pixel format changed by set_fmt() pad operation is not
correctly applied.  It is intended to be restored by calling
ov5640_set_framefmt() when the video stream is started.

However, when the device is powered on by s_power subdev operation before
the video stream is started, the current output mode setting is restored
by ov5640_restore_mode() that also clears pending_mode_change flag in
ov5640_set_mode().  So ov5640_set_framefmt() isn't called as intended and
the output pixel format is not restored.

This change adds the missing output pixel format setting in the
ov5640_restore_mode() that is called when the device is powered on.

Cc: Steve Longerbeam 
Cc: Hugues Fruchet 
Cc: Sakari Ailus 
Cc: Mauro Carvalho Chehab 
Signed-off-by: Akinobu Mita 
---
 drivers/media/i2c/ov5640.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index e2dd352..4eecc91 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -1633,6 +1633,9 @@ static int ov5640_set_mode(struct ov5640_dev *sensor,
return 0;
 }
 
+static int ov5640_set_framefmt(struct ov5640_dev *sensor,
+  struct v4l2_mbus_framefmt *format);
+
 /* restore the last set video mode after chip power-on */
 static int ov5640_restore_mode(struct ov5640_dev *sensor)
 {
@@ -1644,7 +1647,11 @@ static int ov5640_restore_mode(struct ov5640_dev *sensor)
return ret;
 
/* now restore the last capture mode */
-   return ov5640_set_mode(sensor, _mode_init_data);
+   ret = ov5640_set_mode(sensor, _mode_init_data);
+   if (ret < 0)
+   return ret;
+
+   return ov5640_set_framefmt(sensor, >fmt);
 }
 
 static void ov5640_power(struct ov5640_dev *sensor, bool enable)
-- 
2.7.4

Re: [PATCH] media: rc: meson-ir: add timeout on idle

[Sean Young]

Hi Matthias,

On Sat, Mar 10, 2018 at 06:38:28PM +0100, Matthias Reichl wrote:
> On Sat, Mar 10, 2018 at 11:27:45AM +, Sean Young wrote:
> > So if the timeout is below N then you will never get a space of N or larger;
> > the largest space I know of in an IR message is 40ms in the sanyo protocol:
> > 
> > https://www.sbprojects.net/knowledge/ir/sharp.php
> > 
> > So if timeout is set to less than 40ms, we would have trouble decoding the
> > sharp protocol.
> > 
> > The space between nec repeats is a little less than 100ms. I'm trying to
> > remember what would could go wrong if the space between them would be
> > timeouts instead. Mauro do you remember? I can imagine some IR hardware
> > (e.g. winbond) queuing up IR after generating a timeout, thus delaying
> > delivering IR to the kernel and we ending up generating a key up.
> > 
> > The problem with a higher timeout is that the trailing space (=timeout)
> > is sometimes needed for decoding, and decoding of the last message is
> > delayed until the timeout is received. That means the keyup message is
> > delayed until that time, making keys a bit "sticky" and more likely to
> > generate repeats. I'm pretty sure that is needed for rc-5 and nec.
> 
> Another issue with high timeouts is the response to very short button
> presses where the remote only transmits a single scancode. It then
> takes signal transmission time plus timeout, so roughly a quarter
> of a second on meson-ir and ite-cir with 200ms timeout, until the
> scancode is decoded and the keydown event is generated.
> 
> On longer button presses this is less of an issue as we get the
> space signal when the first pulse of the repeated scancode is
> received. So the delay between button press and keydown is determined
> by the remote scancode repeat interval and with typically ~110ms
> on nec/rc-5 a lot lower.
> 
> This affects both "quick fingers" using a standard remote and
> users of programmable remotes like the Logitech Harmony where
> the number of scancodes transmitted on a short press can be
> configured. With a single scancode transmission we run into
> the long keydown delay, 2 scancodes is fine, and at 3 or 4 we
> start running into the key repeat issue.
> 
> We received several reports from users that their remote felt
> "sluggish" when we switched from the downstream "amremote" driver
> (which IIRC decoded the nec protocol in hardware) to meson-ir.
> 
> Lowering the timeout to 125ms or even significantly lower
> (depending on what the protocol and IR receiver permits)
> removes this "sluggishness", users report that their remote
> is more "responsive".

That makes complete sense. I'm actually keen to get this lowered, since
this makes it possible to lower the repeat period per-protocol, see
commit d57ea877af38 which had to be reverted (the ite driver will
need fixing up as well before this can happen).

Lowering to below 125ms does increase the risk of regressions, so I
am weary of that. Do you think there is benefit in doing this?

Thanks

Sean

Re: cron job: media_tree daily build: ERRORS

[Jasmin J.]

Hi!

Sorry, my fault!
Will fix that soon.

BR,
   Jasmin

On 03/11/2018 05:36 AM, Hans Verkuil wrote:
> 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: Sun Mar 11 05:00:11 CET 2018
> media-tree git hash:  e68854a2588a923b31eebce348f8020374843f8e
> media_build git hash: 8b244766d710a8687ae6156abde9d6f377a168ad
> v4l-utils git hash:   14ce03c18ef67aa7a3d5781f015be855fd43839c
> gcc version:  i686-linux-gcc (GCC) 7.3.0
> sparse version:   v0.5.0-3994-g45eb2282
> smatch version:   v0.5.0-3994-g45eb2282
> host hardware:x86_64
> host os:  4.14.0-3-amd64
> 
> linux-git-arm-at91: OK
> linux-git-arm-davinci: OK
> linux-git-arm-multi: WARNINGS
> linux-git-arm-pxa: OK
> linux-git-arm-stm32: OK
> linux-git-arm64: OK
> linux-git-blackfin-bf561: OK
> linux-git-i686: OK
> linux-git-m32r: OK
> linux-git-mips: OK
> linux-git-powerpc64: OK
> linux-git-sh: OK
> linux-git-x86_64: OK
> linux-2.6.36.4-i686: ERRORS
> linux-2.6.36.4-x86_64: ERRORS
> linux-2.6.37.6-i686: ERRORS
> linux-2.6.37.6-x86_64: ERRORS
> linux-2.6.38.8-i686: ERRORS
> linux-2.6.38.8-x86_64: ERRORS
> linux-2.6.39.4-i686: ERRORS
> linux-2.6.39.4-x86_64: ERRORS
> linux-3.0.60-i686: ERRORS
> linux-3.0.60-x86_64: ERRORS
> linux-3.1.10-i686: ERRORS
> linux-3.1.10-x86_64: ERRORS
> linux-3.2.98-i686: ERRORS
> linux-3.2.98-x86_64: ERRORS
> linux-3.3.8-i686: ERRORS
> linux-3.3.8-x86_64: ERRORS
> linux-3.4.27-i686: ERRORS
> linux-3.4.27-x86_64: ERRORS
> linux-3.5.7-i686: WARNINGS
> linux-3.5.7-x86_64: WARNINGS
> linux-3.6.11-i686: WARNINGS
> linux-3.6.11-x86_64: WARNINGS
> linux-3.7.4-i686: WARNINGS
> linux-3.7.4-x86_64: WARNINGS
> linux-3.8-i686: WARNINGS
> linux-3.8-x86_64: WARNINGS
> linux-3.9.2-i686: ERRORS
> linux-3.9.2-x86_64: ERRORS
> linux-3.10.1-i686: ERRORS
> linux-3.10.1-x86_64: ERRORS
> linux-3.11.1-i686: ERRORS
> linux-3.11.1-x86_64: ERRORS
> linux-3.12.67-i686: ERRORS
> linux-3.12.67-x86_64: ERRORS
> linux-3.13.11-i686: ERRORS
> linux-3.13.11-x86_64: ERRORS
> linux-3.14.9-i686: ERRORS
> linux-3.14.9-x86_64: ERRORS
> linux-3.15.2-i686: ERRORS
> linux-3.15.2-x86_64: ERRORS
> linux-3.16.53-i686: ERRORS
> linux-3.16.53-x86_64: ERRORS
> linux-3.17.8-i686: ERRORS
> linux-3.17.8-x86_64: ERRORS
> linux-3.18.93-i686: ERRORS
> linux-3.18.93-x86_64: ERRORS
> linux-3.19-i686: ERRORS
> linux-3.19-x86_64: ERRORS
> linux-4.0.9-i686: ERRORS
> linux-4.0.9-x86_64: ERRORS
> linux-4.1.49-i686: ERRORS
> linux-4.1.49-x86_64: ERRORS
> linux-4.2.8-i686: ERRORS
> linux-4.2.8-x86_64: ERRORS
> linux-4.3.6-i686: ERRORS
> linux-4.3.6-x86_64: ERRORS
> linux-4.4.115-i686: ERRORS
> linux-4.4.115-x86_64: ERRORS
> linux-4.5.7-i686: ERRORS
> linux-4.5.7-x86_64: ERRORS
> linux-4.6.7-i686: ERRORS
> linux-4.6.7-x86_64: ERRORS
> linux-4.7.5-i686: ERRORS
> linux-4.7.5-x86_64: ERRORS
> linux-4.8-i686: ERRORS
> linux-4.8-x86_64: ERRORS
> linux-4.9.80-i686: ERRORS
> linux-4.9.80-x86_64: ERRORS
> linux-4.10.14-i686: ERRORS
> linux-4.10.14-x86_64: ERRORS
> linux-4.11-i686: ERRORS
> linux-4.11-x86_64: ERRORS
> linux-4.12.1-i686: ERRORS
> linux-4.12.1-x86_64: ERRORS
> linux-4.13-i686: ERRORS
> linux-4.13-x86_64: ERRORS
> linux-4.14.17-i686: ERRORS
> linux-4.14.17-x86_64: ERRORS
> linux-4.15.2-i686: ERRORS
> linux-4.15.2-x86_64: ERRORS
> linux-4.16-rc1-i686: ERRORS
> linux-4.16-rc1-x86_64: ERRORS
> apps: WARNINGS
> spec-git: OK
> sparse: WARNINGS
> smatch: OK
> 
> Detailed results are available here:
> 
> http://www.xs4all.nl/~hverkuil/logs/Sunday.log
> 
> Full logs are available here:
> 
> http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2
> 
> The Media Infrastructure API from this daily build is here:
> 
> http://www.xs4all.nl/~hverkuil/spec/index.html
> 

[PATCH] [media] mceusb: add IR learning support features (IR carrier frequency measurement and wide-band/short range receiver)

[A Sun]

Windows Media Center IR transceivers include two IR receivers;
wide-band/short-range and narrow-band/long-range. The short-range
(5cm distance) receiver is for IR learning and has IR carrier
frequency measuring ability.

Add mceusb driver support to select the short range IR receiver
and enable pass through of its IR carrier frequency measurements.

RC and LIRC already support these mceusb driver additions.

Test platform:

Linux raspberrypi 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l 
GNU/Linux
mceusb 1-1.2:1.0: Registered Pinnacle Systems PCTV Remote USB with mce emulator 
interface version 1
mceusb 1-1.2:1.0: 2 tx ports (0x0 cabled) and 2 rx sensors (0x1 active)

Sony TV remote control

ir-ctl from v4l-utils

pi@raspberrypi:~ $ ir-ctl -V
IR raw version 1.12.3
pi@raspberrypi:~ $ ir-ctl -w -m -d /dev/lirc0 -r
...
pulse 600
space 600
pulse 1250
space 550
pulse 650
space 600
pulse 550
space 600
pulse 600
space 600
pulse 650
carrier 38803
space 16777215
^C
pi@raspberrypi:~ $ exit

Signed-off-by: A Sun 
---
 drivers/media/rc/mceusb.c | 90 ++-
 1 file changed, 82 insertions(+), 8 deletions(-)

diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index a9187b0b4..8bbb0f2da 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -42,7 +42,7 @@
 #include 
 #include 
 
-#define DRIVER_VERSION "1.93"
+#define DRIVER_VERSION "1.94"
 #define DRIVER_AUTHOR  "Jarod Wilson "
 #define DRIVER_DESC"Windows Media Center Ed. eHome Infrared Transceiver " \
"device driver"
@@ -427,6 +427,7 @@ struct mceusb_dev {
struct rc_dev *rc;
 
/* optional features we can enable */
+   bool carrier_report_enabled;
bool learning_enabled;
 
/* core device bits */
@@ -475,6 +476,9 @@ struct mceusb_dev {
u8 txports_cabled;  /* bitmask of transmitters with cable */
u8 rxports_active;  /* bitmask of active receive sensors */
 
+   /* receiver carrier frequency detection support */
+   u32 pulse_tunit;/* IR pulse "on" cumulative time units */
+
/*
 * support for async error handler mceusb_deferred_kevent()
 * where usb_clear_halt(), usb_reset_configuration(),
@@ -956,12 +960,60 @@ static int mceusb_set_tx_carrier(struct rc_dev *dev, u32 
carrier)
 }
 
 /*
+ * Select or deselect the 2nd receiver port.
+ * Second receiver is learning mode, wide-band, short-range receiver.
+ * Only one receiver (long or short range) may be active at a time.
+ */
+static int mceusb_set_rx_wideband(struct rc_dev *dev, int enable)
+{
+   struct mceusb_dev *ir = dev->priv;
+   unsigned char cmdbuf[3] = { MCE_CMD_PORT_IR,
+   MCE_CMD_SETIRRXPORTEN, 0x00 };
+
+   if (enable != 0 && enable != 1)
+   return -EINVAL;
+
+   /*
+* cmdbuf[2] is receiver port number
+* port 1 is long range receiver
+* port 2 is short range receiver
+*/
+   cmdbuf[2] = enable + 1;
+   dev_dbg(ir->dev, "select %s-range receive sensor",
+   enable ? "short" : "long");
+   mce_async_out(ir, cmdbuf, sizeof(cmdbuf));
+
+   return 0;
+}
+
+/*
+ * Enable/disable receiver carrier frequency pass through reporting.
+ * Frequency measurement only works with the short-range receiver.
+ * The long-range receiver always reports no carrier frequency
+ * (MCE_RSP_EQIRRXCFCNT, 0, 0) so we always ignore its report.
+ */
+static int mceusb_set_rx_carrier_report(struct rc_dev *dev, int enable)
+{
+   struct mceusb_dev *ir = dev->priv;
+
+   if (enable != 0 && enable != 1)
+   return -EINVAL;
+
+   dev_dbg(ir->dev, "%s short-range receiver carrier reporting",
+   enable ? "enable" : "disable");
+   ir->carrier_report_enabled = (enable == 1);
+
+   return 0;
+}
+
+/*
  * We don't do anything but print debug spew for many of the command bits
  * we receive from the hardware, but some of them are useful information
  * we want to store so that we can use them.
  */
 static void mceusb_handle_command(struct mceusb_dev *ir, int index)
 {
+   DEFINE_IR_RAW_EVENT(rawir);
u8 hi = ir->buf_in[index + 1] & 0xff;
u8 lo = ir->buf_in[index + 2] & 0xff;
 
@@ -980,6 +1032,18 @@ static void mceusb_handle_command(struct mceusb_dev *ir, 
int index)
ir->num_txports = hi;
ir->num_rxports = lo;
break;
+   case MCE_RSP_EQIRRXCFCNT:
+   if (ir->carrier_report_enabled && ir->learning_enabled
+   && ir->pulse_tunit > 0) {
+   init_ir_raw_event();
+   rawir.carrier_report = 1;
+   rawir.carrier = (100u / MCE_TIME_UNIT) *
+   (hi << 8 | lo) / ir->pulse_tunit;
+   dev_dbg(ir->dev, "RX carrier frequency %u Hz (pulse