Re: [PATCH] [media] cx231xx: Initial support Evromedia USB Full Hybrid Full HD

[Oleh Kravchenko]

On 11.01.17 02:16, Antti Palosaari wrote:
> On 01/10/2017 11:41 PM, Oleh Kravchenko wrote:
>> This patch provide only digital support.
>>
>> The device is based on Si2168 30-demodulator,
>> Si2158-20 tuner and CX23102-11Z chipset;
>> USB id: 1b80:d3b2.
>>
>> Status:
>> - DVB-T2 works fine;
>> - Composite and SVideo works fine;
>> - Analog not implemented.
>>
>> Signed-off-by: Oleh Kravchenko 
>> Tested-by: Oleh Kravchenko 
>> ---
>>  drivers/media/usb/cx231xx/Kconfig |  1 +
>>  drivers/media/usb/cx231xx/cx231xx-cards.c | 29 +
>>  drivers/media/usb/cx231xx/cx231xx-dvb.c   | 71 
>> +++
>>  drivers/media/usb/cx231xx/cx231xx-i2c.c   | 37 
>>  drivers/media/usb/cx231xx/cx231xx.h   |  1 +
>>  5 files changed, 139 insertions(+)
>>
>> diff --git a/drivers/media/usb/cx231xx/Kconfig 
>> b/drivers/media/usb/cx231xx/Kconfig
>> index 0cced3e..58de80b 100644
>> --- a/drivers/media/usb/cx231xx/Kconfig
>> +++ b/drivers/media/usb/cx231xx/Kconfig
>> @@ -50,6 +50,7 @@ config VIDEO_CX231XX_DVB
>>  select DVB_LGDT3306A if MEDIA_SUBDRV_AUTOSELECT
>>  select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
>>  select DVB_SI2165 if MEDIA_SUBDRV_AUTOSELECT
>> +select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
>>  select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT
>>
>>  ---help---
>> diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
>> b/drivers/media/usb/cx231xx/cx231xx-cards.c
>> index 36bc254..f730fdb 100644
>> --- a/drivers/media/usb/cx231xx/cx231xx-cards.c
>> +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
>> @@ -841,6 +841,33 @@ struct cx231xx_board cx231xx_boards[] = {
>>  .gpio = NULL,
>>  } },
>>  },
>> +[CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD] = {
>> +.name = "Evromedia USB Full Hybrid Full HD",
>> +.tuner_type = TUNER_ABSENT,
>> +.demod_addr = 0x64, /* 0xc8 >> 1 */
>> +.demod_i2c_master = I2C_1_MUX_3,
>> +.has_dvb = 1,
>> +.ir_i2c_master = I2C_0,
>> +.norm = V4L2_STD_PAL,
>> +.output_mode = OUT_MODE_VIP11,
>> +.tuner_addr = 0x60, /* 0xc0 >> 1 */
> 
> Looks good. I looked the existing file and all the other entries were also 
> using correct 7-bit addresses.
> 
>> +.tuner_i2c_master = I2C_2,
>> +.input = {{
>> +.type = CX231XX_VMUX_TELEVISION,
>> +.vmux = 0,
>> +.amux = CX231XX_AMUX_VIDEO,
>> +}, {
>> +.type = CX231XX_VMUX_COMPOSITE1,
>> +.vmux = CX231XX_VIN_2_1,
>> +.amux = CX231XX_AMUX_LINE_IN,
>> +}, {
>> +.type = CX231XX_VMUX_SVIDEO,
>> +.vmux = CX231XX_VIN_1_1 |
>> +(CX231XX_VIN_1_2 << 8) |
>> +CX25840_SVIDEO_ON,
>> +.amux = CX231XX_AMUX_LINE_IN,
>> +} },
>> +},
>>  };
>>  const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
>>
>> @@ -908,6 +935,8 @@ struct usb_device_id cx231xx_id_table[] = {
>>   .driver_info = CX231XX_BOARD_OTG102},
>>  {USB_DEVICE(USB_VID_TERRATEC, 0x00a6),
>>   .driver_info = CX231XX_BOARD_TERRATEC_GRABBY},
>> +{USB_DEVICE(0x1b80, 0xd3b2),
>> +.driver_info = CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD},
>>  {},
>>  };
>>
>> diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
>> b/drivers/media/usb/cx231xx/cx231xx-dvb.c
>> index 1417515..ecd3528 100644
>> --- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
>> +++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
>> @@ -33,6 +33,7 @@
>>  #include "s5h1411.h"
>>  #include "lgdt3305.h"
>>  #include "si2165.h"
>> +#include "si2168.h"
>>  #include "mb86a20s.h"
>>  #include "si2157.h"
>>  #include "lgdt3306a.h"
>> @@ -949,6 +950,76 @@ static int dvb_init(struct cx231xx *dev)
>> _tda18271_config);
>>  break;
>>
>> +case CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD:
>> +{
>> +struct si2157_config si2157_config = {};
>> +struct si2168_config si2168_config = {};
>> +struct i2c_board_info info = {};
> 
> Personally I don't like initializing variables to zero at the declaration, 
> but it was Hans who asked to do it.
> 
>> +struct i2c_client *client;
>> +struct i2c_adapter *adapter;
>> +
>> +/* attach demodulator chip */
>> +si2168_config.ts_mode = SI2168_TS_SERIAL; /* from *.inf file */
>> +si2168_config.fe = >dvb->frontend;
>> +si2168_config.i2c_adapter = 
>> +si2168_config.ts_clock_inv = true;
>> +
>> +strlcpy(info.type, "si2168", sizeof(info.type));
>> +info.addr = dev->board.demod_addr;
>> +info.platform_data = _config;
>> +
>> +request_module(info.type);
>> +client = i2c_new_device(demod_i2c, );
>> +
>> +if (client == NULL || client->dev.driver == NULL) {
>> +result = -ENODEV;
>> +goto out_free;
>> +}
>> +
>> +if 

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 Jan 11 05:00:18 CET 2017
media-tree git hash:40eca140c404505c09773d1c6685d818cb55ab1a
media_build git hash:   3c6ce4ff75f19adf45869e34b376c5b9dee4d50a
v4l-utils git hash: 8770ca14b8a9cb6b56b98a9d1246a272699c8474
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.8.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.67-i686: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10-rc3-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: OK
linux-3.12.67-x86_64: OK
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: OK
linux-4.9-x86_64: OK
linux-4.10-rc3-x86_64: OK
apps: WARNINGS
spec-git: ERRORS
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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6] [media] vimc: Virtual Media Controller core, capture and sensor

[Helen Koike]

Hi Laurent,

On 2017-01-10 04:54 PM, Laurent Pinchart wrote:

Hi Helen,

(CC'ing Sakari as there's a question specifically for him)

Thank you for the patch, and so sorry for the late review.

On Sunday 04 Sep 2016 17:02:18 Helen Koike wrote:

From: Helen Fornazier 

First version of the Virtual Media Controller.
Add a simple version of the core of the driver, the capture and
sensor nodes in the topology, generating a grey image in a hardcoded
format.

Signed-off-by: Helen Koike 


I've reviewed the whole patch but haven't had time to test it. I've also
skipped the items marked as TODO or FIXME as they're obviously not ready yet
:-) Overall this looks good to me, all the issues are minor.


---

Patch based in media/master tree, and available here:
https://github.com/helen-fornazier/opw-staging/tree/vimc/devel/vpu

Changes since v5:
- Fix message "Entity type for entity Sensor A was not initialized!"
  by initializing the sensor entity.function after the calling
  v4l2_subded_init
- populate device_caps in vimc_cap_create instead of in
  vimc_cap_querycap
- Fix typo in vimc-core.c s/de/the

Changes since v4:
- coding style fixes
- remove BUG_ON
- change copyright to 2016
- depens on VIDEO_V4L2_SUBDEV_API instead of select
- remove assignement of V4L2_CAP_DEVICE_CAPS
- s/vimc_cap_g_fmt_vid_cap/vimc_cap_fmt_vid_cap
- fix vimc_cap_queue_setup declaration type
- remove wrong buffer size check and add it in vimc_cap_buffer_prepare
- vimc_cap_create: remove unecessary check if v4l2_dev or v4l2_dev->dev is
null - vimc_cap_create: only allow a single pad
- vimc_sen_create: only allow source pads, remove unecessary source pads
checks in vimc_thread_sen

Changes since v3: fix rmmod crash and built-in compile
- Re-order unregister calls in vimc_device_unregister function (remove
rmmod issue)
- Call media_device_unregister_entity in vimc_raw_destroy
- Add depends on VIDEO_DEV && VIDEO_V4L2 and select VIDEOBUF2_VMALLOC
- Check *nplanes in queue_setup (this remove v4l2-compliance fail)
- Include  in vimc-sensor.c
- Move include of  from vimc-core.c to vimc-core.h
- Generate 60 frames per sec instead of 1 in the sensor

Changes since v2: update with current media master tree
- Add struct media_pipeline in vimc_cap_device
- Use vb2_v4l2_buffer instead of vb2_buffer
- Typos
- Remove usage of entity->type and use entity->function instead
- Remove fmt argument from queue setup
- Use ktime_get_ns instead of v4l2_get_timestamp
- Iterate over link's list using list_for_each_entry
- Use media_device_{init, cleanup}
- Use entity->use_count to keep track of entities instead of the old
entity->id
- Replace media_entity_init by media_entity_pads_init
---
 drivers/media/platform/Kconfig |   2 +
 drivers/media/platform/Makefile|   1 +
 drivers/media/platform/vimc/Kconfig|   7 +
 drivers/media/platform/vimc/Makefile   |   3 +
 drivers/media/platform/vimc/vimc-capture.c | 553 ++
 drivers/media/platform/vimc/vimc-capture.h |  28 ++
 drivers/media/platform/vimc/vimc-core.c| 600 ++
 drivers/media/platform/vimc/vimc-core.h|  57 +++
 drivers/media/platform/vimc/vimc-sensor.c  | 279 ++
 drivers/media/platform/vimc/vimc-sensor.h  |  28 ++
 10 files changed, 1558 insertions(+)
 create mode 100644 drivers/media/platform/vimc/Kconfig
 create mode 100644 drivers/media/platform/vimc/Makefile
 create mode 100644 drivers/media/platform/vimc/vimc-capture.c
 create mode 100644 drivers/media/platform/vimc/vimc-capture.h
 create mode 100644 drivers/media/platform/vimc/vimc-core.c
 create mode 100644 drivers/media/platform/vimc/vimc-core.h
 create mode 100644 drivers/media/platform/vimc/vimc-sensor.c
 create mode 100644 drivers/media/platform/vimc/vimc-sensor.h


[snip]


diff --git a/drivers/media/platform/vimc/vimc-capture.c
b/drivers/media/platform/vimc/vimc-capture.c new file mode 100644
index 000..b7636cf
--- /dev/null
+++ b/drivers/media/platform/vimc/vimc-capture.c


[snip]


+static void vimc_cap_return_all_buffers(struct vimc_cap_device *vcap,
+   enum vb2_buffer_state state)
+{
+   struct vimc_cap_buffer *vbuf, *node;
+
+   spin_lock(>qlock);
+
+   list_for_each_entry_safe(vbuf, node, >buf_list, list) {
+   vb2_buffer_done(>vb2.vb2_buf, state);
+   list_del(>list);


It shouldn't matter given that you protect this with a spinlock, but moving
the list_del() above makes the code flow follow a safer order.


+   }
+
+   spin_unlock(>qlock);
+}
+
+static int vimc_cap_pipeline_s_stream(struct vimc_cap_device *vcap, int
enable)
+{
+   int ret;
+   struct media_pad *pad;
+   struct media_entity *entity;
+   struct v4l2_subdev *sd;
+
+   /* Start the stream in the subdevice direct connected */
+   entity = >vdev.entity;
+   pad = media_entity_remote_pad(>pads[0]);
+
+   /* If we are 

Re: kill off pci_enable_msi_{exact,range}

[David Miller]

From: Christoph Hellwig 
Date: Mon,  9 Jan 2017 21:37:37 +0100

> I had hope that we could kill these old interfaces of for 4.10-rc,
> but as of today Linus tree still has two users:
> 
>  (1) the cobalt media driver, for which I sent a patch long time ago,
>  it got missed in the merge window.
>  (2) the new xgbe driver was merged in 4.10-rc but used the old interfaces
>  anyway
> 
> This series resend the patch for (1) and adds a new one for (2), as well
> as having the final removal patch behind it.  Maybe we should just queue
> up all three together in the PCI tree for 4.11?

Feel free to toss this into the PCI tree.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [media] cx231xx: Initial support Evromedia USB Full Hybrid Full HD

[Antti Palosaari]

On 01/10/2017 11:41 PM, Oleh Kravchenko wrote:

This patch provide only digital support.

The device is based on Si2168 30-demodulator,
Si2158-20 tuner and CX23102-11Z chipset;
USB id: 1b80:d3b2.

Status:
- DVB-T2 works fine;
- Composite and SVideo works fine;
- Analog not implemented.

Signed-off-by: Oleh Kravchenko 
Tested-by: Oleh Kravchenko 
---
 drivers/media/usb/cx231xx/Kconfig |  1 +
 drivers/media/usb/cx231xx/cx231xx-cards.c | 29 +
 drivers/media/usb/cx231xx/cx231xx-dvb.c   | 71 +++
 drivers/media/usb/cx231xx/cx231xx-i2c.c   | 37 
 drivers/media/usb/cx231xx/cx231xx.h   |  1 +
 5 files changed, 139 insertions(+)

diff --git a/drivers/media/usb/cx231xx/Kconfig 
b/drivers/media/usb/cx231xx/Kconfig
index 0cced3e..58de80b 100644
--- a/drivers/media/usb/cx231xx/Kconfig
+++ b/drivers/media/usb/cx231xx/Kconfig
@@ -50,6 +50,7 @@ config VIDEO_CX231XX_DVB
select DVB_LGDT3306A if MEDIA_SUBDRV_AUTOSELECT
select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
select DVB_SI2165 if MEDIA_SUBDRV_AUTOSELECT
+   select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT

---help---
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index 36bc254..f730fdb 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -841,6 +841,33 @@ struct cx231xx_board cx231xx_boards[] = {
.gpio = NULL,
} },
},
+   [CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD] = {
+   .name = "Evromedia USB Full Hybrid Full HD",
+   .tuner_type = TUNER_ABSENT,
+   .demod_addr = 0x64, /* 0xc8 >> 1 */
+   .demod_i2c_master = I2C_1_MUX_3,
+   .has_dvb = 1,
+   .ir_i2c_master = I2C_0,
+   .norm = V4L2_STD_PAL,
+   .output_mode = OUT_MODE_VIP11,
+   .tuner_addr = 0x60, /* 0xc0 >> 1 */


Looks good. I looked the existing file and all the other entries were 
also using correct 7-bit addresses.



+   .tuner_i2c_master = I2C_2,
+   .input = {{
+   .type = CX231XX_VMUX_TELEVISION,
+   .vmux = 0,
+   .amux = CX231XX_AMUX_VIDEO,
+   }, {
+   .type = CX231XX_VMUX_COMPOSITE1,
+   .vmux = CX231XX_VIN_2_1,
+   .amux = CX231XX_AMUX_LINE_IN,
+   }, {
+   .type = CX231XX_VMUX_SVIDEO,
+   .vmux = CX231XX_VIN_1_1 |
+   (CX231XX_VIN_1_2 << 8) |
+   CX25840_SVIDEO_ON,
+   .amux = CX231XX_AMUX_LINE_IN,
+   } },
+   },
 };
 const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);

@@ -908,6 +935,8 @@ struct usb_device_id cx231xx_id_table[] = {
 .driver_info = CX231XX_BOARD_OTG102},
{USB_DEVICE(USB_VID_TERRATEC, 0x00a6),
 .driver_info = CX231XX_BOARD_TERRATEC_GRABBY},
+   {USB_DEVICE(0x1b80, 0xd3b2),
+   .driver_info = CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD},
{},
 };

diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 1417515..ecd3528 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -33,6 +33,7 @@
 #include "s5h1411.h"
 #include "lgdt3305.h"
 #include "si2165.h"
+#include "si2168.h"
 #include "mb86a20s.h"
 #include "si2157.h"
 #include "lgdt3306a.h"
@@ -949,6 +950,76 @@ static int dvb_init(struct cx231xx *dev)
   _tda18271_config);
break;

+   case CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD:
+   {
+   struct si2157_config si2157_config = {};
+   struct si2168_config si2168_config = {};
+   struct i2c_board_info info = {};


Personally I don't like initializing variables to zero at the 
declaration, but it was Hans who asked to do it.



+   struct i2c_client *client;
+   struct i2c_adapter *adapter;
+
+   /* attach demodulator chip */
+   si2168_config.ts_mode = SI2168_TS_SERIAL; /* from *.inf file */
+   si2168_config.fe = >dvb->frontend;
+   si2168_config.i2c_adapter = 
+   si2168_config.ts_clock_inv = true;
+
+   strlcpy(info.type, "si2168", sizeof(info.type));
+   info.addr = dev->board.demod_addr;
+   info.platform_data = _config;
+
+   request_module(info.type);
+   client = i2c_new_device(demod_i2c, );
+
+   if (client == NULL || client->dev.driver == NULL) {
+   result = -ENODEV;
+   goto out_free;
+   }
+

Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support

[Steve Longerbeam]

On 01/09/2017 04:15 PM, Steve Longerbeam wrote:

Hi Philipp,


On 01/09/2017 11:43 AM, Philipp Zabel wrote:




One is the amount and organization of subdevices/media entities visible
to userspace. The SMFCs should not be user controllable subdevices, but
can be implicitly enabled when a CSI is directly linked to a camif.


I agree the SMFC could be folded into the CSI, but I see at least one
issue.

From the dot graph you'll see that the PRPVF entity can receive directly
from the CSI, or indirectly via the SMFC. If the SMFC entity were folded
into the CSI entity, there would have to be a "direct to PRPVF" output 
pad

and a "indirect via SMFC" output pad and I'm not sure how that info would
be conveyed to the user. With a SMFC entity those pipelines are explicit.


In summary here, unless you have strong objection I'd prefer to keep a
distinct SMFC entity. It makes the pipelines more clear to the user, and it
better models the IPU internals.




Also I'm not convinced the 1:1 mapping of IC task to subdevices is the
best choice. It is true that the three tasks can be enabled separately,
but to my understanding, the PRP ENC and PRP VF tasks share a single
input channel. Shouldn't this be a single PRP subdevice with one input
and two (VF, ENC) outputs?


Since the VDIC sends its motion compensated frames to the PRP VF task,
I've created the PRPVF entity solely for motion compensated de-interlace
support. I don't really see any other use for the PRPVF task except for
motion compensated de-interlace.

So really, the PRPVF entity is a combination of the VDIC and PRPVF 
subunits.


So looking at link_setup() in imx-csi.c, you'll see that when the CSI 
is linked

to PRPVF entity, it is actually sending to IPU_CSI_DEST_VDIC.

But if we were to create a VDIC entity, I can see how we could then
have a single PRP entity. Then if the PRP entity is receiving from the 
VDIC,

the PRP VF task would be activated.

Another advantage of creating a distinct VDIC entity is that frames could
potentially be routed directly from the VDIC to camif, for 
motion-compensated
frame capture only with no scaling/CSC. I think that would be IDMAC 
channel
5, we've tried to get that pipeline to work in the past without 
success. That's
mainly why I decided not to attempt it and instead fold VDIC into 
PRPVF entity.





Here also, I'd prefer to keep distinct PRPENC and PRPVF entities. You 
are correct

that PRPENC and PRPVF do share an input channel (the CSIs). But the PRPVF
has an additional input channel from the VDIC, and since my PRPVF entity 
roles

up the VDIC internally, it is actually receiving from the VDIC channel.

So unless you think we should have a distinct VDIC entity, I would like 
to keep this

the way it is.

Steve

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

Re: [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

[Andi Shyti]

Hi Sean,

>include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': 
> unknown attribute
> >> drivers/media/rc/mtk-cir.c:215:41: sparse: too many arguments for function 
> >> devm_rc_allocate_device
>drivers/media/rc/mtk-cir.c: In function 'mtk_ir_probe':
>drivers/media/rc/mtk-cir.c:215:11: error: too many arguments to function 
> 'devm_rc_allocate_device'
>  ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
>   ^~~
>In file included from drivers/media/rc/mtk-cir.c:22:0:
>include/media/rc-core.h:213:16: note: declared here
> struct rc_dev *devm_rc_allocate_device(struct device *dev);
>^~~
> 
> vim +/devm_rc_allocate_device +215 drivers/media/rc/mtk-cir.c
> 
>209ir->base = devm_ioremap_resource(dev, res);
>210if (IS_ERR(ir->base)) {
>211dev_err(dev, "failed to map registers\n");
>212return PTR_ERR(ir->base);
>213}
>214
>  > 215ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);

this error comes because the patches I pointed out have not been
applied yet. I guess you can ignore them as long as you tested
yours on top those patches.

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

[PATCH] [media] cx231xx: Initial support Evromedia USB Full Hybrid Full HD

[Oleh Kravchenko]

This patch provide only digital support.

The device is based on Si2168 30-demodulator,
Si2158-20 tuner and CX23102-11Z chipset;
USB id: 1b80:d3b2.

Status:
- DVB-T2 works fine;
- Composite and SVideo works fine;
- Analog not implemented.

Signed-off-by: Oleh Kravchenko 
Tested-by: Oleh Kravchenko 
---
 drivers/media/usb/cx231xx/Kconfig |  1 +
 drivers/media/usb/cx231xx/cx231xx-cards.c | 29 +
 drivers/media/usb/cx231xx/cx231xx-dvb.c   | 71 +++
 drivers/media/usb/cx231xx/cx231xx-i2c.c   | 37 
 drivers/media/usb/cx231xx/cx231xx.h   |  1 +
 5 files changed, 139 insertions(+)

diff --git a/drivers/media/usb/cx231xx/Kconfig 
b/drivers/media/usb/cx231xx/Kconfig
index 0cced3e..58de80b 100644
--- a/drivers/media/usb/cx231xx/Kconfig
+++ b/drivers/media/usb/cx231xx/Kconfig
@@ -50,6 +50,7 @@ config VIDEO_CX231XX_DVB
select DVB_LGDT3306A if MEDIA_SUBDRV_AUTOSELECT
select DVB_TDA18271C2DD if MEDIA_SUBDRV_AUTOSELECT
select DVB_SI2165 if MEDIA_SUBDRV_AUTOSELECT
+   select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT
 
---help---
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c 
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index 36bc254..f730fdb 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -841,6 +841,33 @@ struct cx231xx_board cx231xx_boards[] = {
.gpio = NULL,
} },
},
+   [CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD] = {
+   .name = "Evromedia USB Full Hybrid Full HD",
+   .tuner_type = TUNER_ABSENT,
+   .demod_addr = 0x64, /* 0xc8 >> 1 */
+   .demod_i2c_master = I2C_1_MUX_3,
+   .has_dvb = 1,
+   .ir_i2c_master = I2C_0,
+   .norm = V4L2_STD_PAL,
+   .output_mode = OUT_MODE_VIP11,
+   .tuner_addr = 0x60, /* 0xc0 >> 1 */
+   .tuner_i2c_master = I2C_2,
+   .input = {{
+   .type = CX231XX_VMUX_TELEVISION,
+   .vmux = 0,
+   .amux = CX231XX_AMUX_VIDEO,
+   }, {
+   .type = CX231XX_VMUX_COMPOSITE1,
+   .vmux = CX231XX_VIN_2_1,
+   .amux = CX231XX_AMUX_LINE_IN,
+   }, {
+   .type = CX231XX_VMUX_SVIDEO,
+   .vmux = CX231XX_VIN_1_1 |
+   (CX231XX_VIN_1_2 << 8) |
+   CX25840_SVIDEO_ON,
+   .amux = CX231XX_AMUX_LINE_IN,
+   } },
+   },
 };
 const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
 
@@ -908,6 +935,8 @@ struct usb_device_id cx231xx_id_table[] = {
 .driver_info = CX231XX_BOARD_OTG102},
{USB_DEVICE(USB_VID_TERRATEC, 0x00a6),
 .driver_info = CX231XX_BOARD_TERRATEC_GRABBY},
+   {USB_DEVICE(0x1b80, 0xd3b2),
+   .driver_info = CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD},
{},
 };
 
diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 1417515..ecd3528 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -33,6 +33,7 @@
 #include "s5h1411.h"
 #include "lgdt3305.h"
 #include "si2165.h"
+#include "si2168.h"
 #include "mb86a20s.h"
 #include "si2157.h"
 #include "lgdt3306a.h"
@@ -949,6 +950,76 @@ static int dvb_init(struct cx231xx *dev)
   _tda18271_config);
break;
 
+   case CX231XX_BOARD_EVROMEDIA_FULL_HYBRID_FULLHD:
+   {
+   struct si2157_config si2157_config = {};
+   struct si2168_config si2168_config = {};
+   struct i2c_board_info info = {};
+   struct i2c_client *client;
+   struct i2c_adapter *adapter;
+
+   /* attach demodulator chip */
+   si2168_config.ts_mode = SI2168_TS_SERIAL; /* from *.inf file */
+   si2168_config.fe = >dvb->frontend;
+   si2168_config.i2c_adapter = 
+   si2168_config.ts_clock_inv = true;
+
+   strlcpy(info.type, "si2168", sizeof(info.type));
+   info.addr = dev->board.demod_addr;
+   info.platform_data = _config;
+
+   request_module(info.type);
+   client = i2c_new_device(demod_i2c, );
+
+   if (client == NULL || client->dev.driver == NULL) {
+   result = -ENODEV;
+   goto out_free;
+   }
+
+   if (!try_module_get(client->dev.driver->owner)) {
+   i2c_unregister_device(client);
+   result = -ENODEV;
+   goto out_free;
+   }
+
+   dvb->i2c_client_demod = client;
+

Re: [PATCH v6] [media] vimc: Virtual Media Controller core, capture and sensor

[Laurent Pinchart]

Hi Helen,

(CC'ing Sakari as there's a question specifically for him)

Thank you for the patch, and so sorry for the late review. 

On Sunday 04 Sep 2016 17:02:18 Helen Koike wrote:
> From: Helen Fornazier 
> 
> First version of the Virtual Media Controller.
> Add a simple version of the core of the driver, the capture and
> sensor nodes in the topology, generating a grey image in a hardcoded
> format.
> 
> Signed-off-by: Helen Koike 

I've reviewed the whole patch but haven't had time to test it. I've also 
skipped the items marked as TODO or FIXME as they're obviously not ready yet 
:-) Overall this looks good to me, all the issues are minor.

> ---
> 
> Patch based in media/master tree, and available here:
> https://github.com/helen-fornazier/opw-staging/tree/vimc/devel/vpu
> 
> Changes since v5:
> - Fix message "Entity type for entity Sensor A was not initialized!"
>   by initializing the sensor entity.function after the calling
>   v4l2_subded_init
> - populate device_caps in vimc_cap_create instead of in
>   vimc_cap_querycap
> - Fix typo in vimc-core.c s/de/the
> 
> Changes since v4:
> - coding style fixes
> - remove BUG_ON
> - change copyright to 2016
> - depens on VIDEO_V4L2_SUBDEV_API instead of select
> - remove assignement of V4L2_CAP_DEVICE_CAPS
> - s/vimc_cap_g_fmt_vid_cap/vimc_cap_fmt_vid_cap
> - fix vimc_cap_queue_setup declaration type
> - remove wrong buffer size check and add it in vimc_cap_buffer_prepare
> - vimc_cap_create: remove unecessary check if v4l2_dev or v4l2_dev->dev is
> null - vimc_cap_create: only allow a single pad
> - vimc_sen_create: only allow source pads, remove unecessary source pads
> checks in vimc_thread_sen
> 
> Changes since v3: fix rmmod crash and built-in compile
> - Re-order unregister calls in vimc_device_unregister function (remove
> rmmod issue)
> - Call media_device_unregister_entity in vimc_raw_destroy
> - Add depends on VIDEO_DEV && VIDEO_V4L2 and select VIDEOBUF2_VMALLOC
> - Check *nplanes in queue_setup (this remove v4l2-compliance fail)
> - Include  in vimc-sensor.c
> - Move include of  from vimc-core.c to vimc-core.h
> - Generate 60 frames per sec instead of 1 in the sensor
> 
> Changes since v2: update with current media master tree
> - Add struct media_pipeline in vimc_cap_device
> - Use vb2_v4l2_buffer instead of vb2_buffer
> - Typos
> - Remove usage of entity->type and use entity->function instead
> - Remove fmt argument from queue setup
> - Use ktime_get_ns instead of v4l2_get_timestamp
> - Iterate over link's list using list_for_each_entry
> - Use media_device_{init, cleanup}
> - Use entity->use_count to keep track of entities instead of the old
> entity->id
> - Replace media_entity_init by media_entity_pads_init
> ---
>  drivers/media/platform/Kconfig |   2 +
>  drivers/media/platform/Makefile|   1 +
>  drivers/media/platform/vimc/Kconfig|   7 +
>  drivers/media/platform/vimc/Makefile   |   3 +
>  drivers/media/platform/vimc/vimc-capture.c | 553 ++
>  drivers/media/platform/vimc/vimc-capture.h |  28 ++
>  drivers/media/platform/vimc/vimc-core.c| 600 ++
>  drivers/media/platform/vimc/vimc-core.h|  57 +++
>  drivers/media/platform/vimc/vimc-sensor.c  | 279 ++
>  drivers/media/platform/vimc/vimc-sensor.h  |  28 ++
>  10 files changed, 1558 insertions(+)
>  create mode 100644 drivers/media/platform/vimc/Kconfig
>  create mode 100644 drivers/media/platform/vimc/Makefile
>  create mode 100644 drivers/media/platform/vimc/vimc-capture.c
>  create mode 100644 drivers/media/platform/vimc/vimc-capture.h
>  create mode 100644 drivers/media/platform/vimc/vimc-core.c
>  create mode 100644 drivers/media/platform/vimc/vimc-core.h
>  create mode 100644 drivers/media/platform/vimc/vimc-sensor.c
>  create mode 100644 drivers/media/platform/vimc/vimc-sensor.h

[snip]

> diff --git a/drivers/media/platform/vimc/vimc-capture.c
> b/drivers/media/platform/vimc/vimc-capture.c new file mode 100644
> index 000..b7636cf
> --- /dev/null
> +++ b/drivers/media/platform/vimc/vimc-capture.c

[snip]

> +static void vimc_cap_return_all_buffers(struct vimc_cap_device *vcap,
> + enum vb2_buffer_state state)
> +{
> + struct vimc_cap_buffer *vbuf, *node;
> +
> + spin_lock(>qlock);
> +
> + list_for_each_entry_safe(vbuf, node, >buf_list, list) {
> + vb2_buffer_done(>vb2.vb2_buf, state);
> + list_del(>list);

It shouldn't matter given that you protect this with a spinlock, but moving 
the list_del() above makes the code flow follow a safer order.

> + }
> +
> + spin_unlock(>qlock);
> +}
> +
> +static int vimc_cap_pipeline_s_stream(struct vimc_cap_device *vcap, int
> enable)
> +{
> + int ret;
> + struct media_pad *pad;
> + struct media_entity *entity;
> + struct v4l2_subdev *sd;
> +
> + /* Start the stream in the subdevice 

Re: [PATCH 2/3] xgbe: switch to pci_irq_alloc_vectors

[Tom Lendacky]

On 1/9/2017 2:37 PM, Christoph Hellwig wrote:
> The newly added xgbe drivers uses the deprecated pci_enable_msi_exact
> and pci_enable_msix_range interfaces.  Switch it to use
> pci_irq_alloc_vectors instead.

I was just working on switching over to this API with some additional
changes / simplification.  I'm ok with using this patch so that you get
the API removal accomplished.  Going through the PCI tree just means
it will probably be easier for me to hold off on the additional changes
I wanted to make until later.

Acked-by: Tom Lendacky 

> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/net/ethernet/amd/xgbe/xgbe-pci.c | 47 
> +---
>  drivers/net/ethernet/amd/xgbe/xgbe.h |  1 -
>  2 files changed, 19 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-pci.c 
> b/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
> index e76b7f6..be2690e 100644
> --- a/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
> +++ b/drivers/net/ethernet/amd/xgbe/xgbe-pci.c
> @@ -133,12 +133,13 @@ static int xgbe_config_msi(struct xgbe_prv_data *pdata)
>pdata->tx_ring_count);
>   msi_count = roundup_pow_of_two(msi_count);
>  
> - ret = pci_enable_msi_exact(pdata->pcidev, msi_count);
> + ret = pci_alloc_irq_vectors(pdata->pcidev, msi_count, msi_count,
> + PCI_IRQ_MSI);
>   if (ret < 0) {
>   dev_info(pdata->dev, "MSI request for %u interrupts failed\n",
>msi_count);
>  
> - ret = pci_enable_msi(pdata->pcidev);
> + ret = pci_alloc_irq_vectors(pdata->pcidev, 1, 1, PCI_IRQ_MSI);
>   if (ret < 0) {
>   dev_info(pdata->dev, "MSI enablement failed\n");
>   return ret;
> @@ -149,25 +150,26 @@ static int xgbe_config_msi(struct xgbe_prv_data *pdata)
>  
>   pdata->irq_count = msi_count;
>  
> - pdata->dev_irq = pdata->pcidev->irq;
> + pdata->dev_irq = pci_irq_vector(pdata->pcidev, 0);
>  
>   if (msi_count > 1) {
> - pdata->ecc_irq = pdata->pcidev->irq + 1;
> - pdata->i2c_irq = pdata->pcidev->irq + 2;
> - pdata->an_irq = pdata->pcidev->irq + 3;
> + pdata->ecc_irq = pci_irq_vector(pdata->pcidev, 1);
> + pdata->i2c_irq = pci_irq_vector(pdata->pcidev, 2);
> + pdata->an_irq = pci_irq_vector(pdata->pcidev, 3);
>  
>   for (i = XGBE_MSIX_BASE_COUNT, j = 0;
>(i < msi_count) && (j < XGBE_MAX_DMA_CHANNELS);
>i++, j++)
> - pdata->channel_irq[j] = pdata->pcidev->irq + i;
> + pdata->channel_irq[j] =
> + pci_irq_vector(pdata->pcidev, i);
>   pdata->channel_irq_count = j;
>  
>   pdata->per_channel_irq = 1;
>   pdata->channel_irq_mode = XGBE_IRQ_MODE_LEVEL;
>   } else {
> - pdata->ecc_irq = pdata->pcidev->irq;
> - pdata->i2c_irq = pdata->pcidev->irq;
> - pdata->an_irq = pdata->pcidev->irq;
> + pdata->ecc_irq = pci_irq_vector(pdata->pcidev, 0);
> + pdata->i2c_irq = pci_irq_vector(pdata->pcidev, 0);
> + pdata->an_irq = pci_irq_vector(pdata->pcidev, 0);
>   }
>  
>   if (netif_msg_probe(pdata))
> @@ -186,33 +188,22 @@ static int xgbe_config_msix(struct xgbe_prv_data *pdata)
>   msix_count += max(pdata->rx_ring_count,
> pdata->tx_ring_count);
>  
> - pdata->msix_entries = devm_kcalloc(pdata->dev, msix_count,
> -sizeof(struct msix_entry),
> -GFP_KERNEL);
> - if (!pdata->msix_entries)
> - return -ENOMEM;
> -
> - for (i = 0; i < msix_count; i++)
> - pdata->msix_entries[i].entry = i;
> -
> - ret = pci_enable_msix_range(pdata->pcidev, pdata->msix_entries,
> - XGBE_MSIX_MIN_COUNT, msix_count);
> + ret = pci_alloc_irq_vectors(pdata->pcidev, XGBE_MSIX_MIN_COUNT,
> + msix_count, PCI_IRQ_MSIX);
>   if (ret < 0) {
>   dev_info(pdata->dev, "MSI-X enablement failed\n");
> - devm_kfree(pdata->dev, pdata->msix_entries);
> - pdata->msix_entries = NULL;
>   return ret;
>   }
>  
>   pdata->irq_count = ret;
>  
> - pdata->dev_irq = pdata->msix_entries[0].vector;
> - pdata->ecc_irq = pdata->msix_entries[1].vector;
> - pdata->i2c_irq = pdata->msix_entries[2].vector;
> - pdata->an_irq = pdata->msix_entries[3].vector;
> + pdata->dev_irq = pci_irq_vector(pdata->pcidev, 0);
> + pdata->ecc_irq = pci_irq_vector(pdata->pcidev, 1);
> + pdata->i2c_irq = pci_irq_vector(pdata->pcidev, 2);
> + pdata->an_irq = pci_irq_vector(pdata->pcidev, 3);
>  
>   for (i = XGBE_MSIX_BASE_COUNT, j = 0; i < ret; i++, j++)
> -

Re: [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

[Sean Young]

Hi Sean,

The driver is looking very good, we are looking at minor details now.

On Tue, Jan 10, 2017 at 09:59:49PM +0800, Sean Wang wrote:
> On Tue, 2017-01-10 at 11:09 +, Sean Young wrote:
> 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#define MTK_IR_DEV KBUILD_MODNAME
> > 
> > You could remove this #define and just use KBUILD_MODNAME
> 
> I preferred to use MTK_IR_DEV internally that helps
> renaming in the future if necessary.

ok.

> >  
> > > +
> > > +/* Register to enable PWM and IR */
> > > +#define MTK_CONFIG_HIGH_REG   0x0c
> > > +/* Enable IR pulse width detection */
> > > +#define MTK_PWM_EN BIT(13)
> > > +/* Enable IR hardware function */
> > > +#define MTK_IR_EN  BIT(0)
> > > +
> > > +/* Register to setting sample period */
> > > +#define MTK_CONFIG_LOW_REG0x10
> > > +/* Field to set sample period */
> > > +#define CHK_PERIOD DIV_ROUND_CLOSEST(MTK_IR_SAMPLE,  \
> > > + MTK_IR_CLK_PERIOD)
> > > +#define MTK_CHK_PERIOD(((CHK_PERIOD) << 8) & (GENMASK(20, 
> > > 8)))
> > > +#define MTK_CHK_PERIOD_MASK(GENMASK(20, 8))
> > > +
> > > +/* Register to clear state of state machine */
> > > +#define MTK_IRCLR_REG 0x20
> > > +/* Bit to restart IR receiving */
> > > +#define MTK_IRCLR  BIT(0)
> > > +
> > > +/* Register containing pulse width data */
> > > +#define MTK_CHKDATA_REG(i)(0x88 + 4 * (i))
> > > +#define MTK_WIDTH_MASK (GENMASK(7, 0))
> > > +
> > > +/* Register to enable IR interrupt */
> > > +#define MTK_IRINT_EN_REG  0xcc
> > > +/* Bit to enable interrupt */
> > > +#define MTK_IRINT_EN   BIT(0)
> > > +
> > > +/* Register to ack IR interrupt */
> > > +#define MTK_IRINT_CLR_REG 0xd0
> > > +/* Bit to clear interrupt status */
> > > +#define MTK_IRINT_CLR  BIT(0)
> > > +
> > > +/* Maximum count of samples */
> > > +#define MTK_MAX_SAMPLES0xff
> > > +/* Indicate the end of IR message */
> > > +#define MTK_IR_END(v, p)   ((v) == MTK_MAX_SAMPLES && (p) == 0)
> > > +/* Number of registers to record the pulse width */
> > > +#define MTK_CHKDATA_SZ 17
> > > +/* Source clock frequency */
> > > +#define MTK_IR_BASE_CLK27300
> > > +/* Frequency after IR internal divider */
> > > +#define MTK_IR_CLK_FREQ(MTK_IR_BASE_CLK / 4)
> 
> > > +static irqreturn_t mtk_ir_irq(int irqno, void *dev_id)
> > > +{
> > > + struct mtk_ir *ir = dev_id;
> > > + u8  wid = 0;
> > > + u32 i, j, val;
> > > + DEFINE_IR_RAW_EVENT(rawir);
> > > +
> > > + mtk_irq_disable(ir, MTK_IRINT_EN);
> > 
> > The kernel guarantees that calls to the interrupt handler are serialised,
> > no need to disable the interrupt in the handler.
> 
> agreed. I will save the mtk irq disable/enable and retest again.
> 
> 
> > > +
> > > + /* Reset decoder state machine */
> > > + ir_raw_event_reset(ir->rc);
> > 
> > Not needed.
> 
> 
> two reasons I added the line here
> 
> 1) 
> I thought it is possible the decoder goes to the
> middle state when getting the data not belonged
> to the protocol. If so, that would cause the decoding
> fails in the next time receiving the valid protocol data.

The last IR event submitted will always be a long space, that's enough
to reset the decoders. Adding a ir_raw_event_reset() will do this
more explicitly, rather than their state machines resetting themselves
through the trailing space.

> 2) 
> the mtk hardware register always contains the start of 
> IR message. So force to sync the state between 
> HW and ir-core.
> 
> 
> 
> > > +
> > > + /* First message must be pulse */
> > > + rawir.pulse = false;
> > 
> > pulse = true?
> 
> becasue of rawir.pulse = !rawir.pulse does as below
> so the initial value is set as false.

Ah, sorry, of course. :)

> > > +
> > > + /* Handle all pulse and space IR controller captures */
> > > + for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
> > > + val = mtk_r32(ir, MTK_CHKDATA_REG(i));
> > > + dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
> > > +
> > > + for (j = 0 ; j < 4 ; j++) {
> > > + wid = (val & (MTK_WIDTH_MASK << j * 8)) >> j * 8;
> > > + rawir.pulse = !rawir.pulse;
> > > + rawir.duration = wid * (MTK_IR_SAMPLE + 1);
> > > + ir_raw_event_store_with_filter(ir->rc, );
> > > + }
> > 
> > In v1 you would break out of the loop if the ir message was shorter, but
> > now you are always passing on 68 pulses and spaces. Is that right?
> 
> as I asked in the previous mail list as below i copied from it, so i
> made some changes ...
> 
> "
> > I had another question. I found multiple and same IR messages being
> > received when using SONY remote controller. Should driver needs to
> > report each message or only 

Re: [media] uvcvideo: support for contiguous DMA buffers

[Vincent ABRIOU]

On 01/10/2017 03:41 PM, Laurent Pinchart wrote:
> On Tuesday 10 Jan 2017 08:55:16 Vincent ABRIOU wrote:
>> On 01/09/2017 05:59 PM, Laurent Pinchart wrote:
>>> On Monday 09 Jan 2017 15:49:00 Vincent ABRIOU wrote:
 On 01/09/2017 04:37 PM, Laurent Pinchart wrote:
> Hi Vincent,
>
> Thank you for the patch.
>
> On Monday 03 Oct 2016 13:27:16 Vincent Abriou wrote:
>> Allow uvcvideo compatible devices to allocate their output buffers
>> using contiguous DMA buffers.
>
> Why do you need this ? If it's for buffer sharing with a device that
> requires dma-contig, can't you allocate the buffers on the other device
> and import them on the UVC side ?

 Hi Laurent,

 I need this using Gstreamer simple pipeline to connect an usb webcam
 (v4l2src) with a display (waylandsink) activating the zero copy path.

 The waylandsink plugin does not have any contiguous memory pool to
 allocate contiguous buffer. So it is up to the upstream element, here
 v4l2src, to provide such contiguous buffers.
>>>
>>> Isn't that a gstreamer issue ?
>>
>> It is not a gstreamer issue. It is the way it has been decided to work.
>> Waylandsink accept DMABUF contiguous buffer but it does not have its own
>> buffer pool.
>
> But why do you put the blame on the kernel when you decide to take the wrong
> decision in userspace ? :-)
>

I don't blame the kernel... I improve it :)

>> Add the "allocators" module parameter option to let uvcvideo use the
>> dma-contig instead of vmalloc.
>>
>> Signed-off-by: Vincent Abriou 
>> ---
>>
>>  Documentation/media/v4l-drivers/uvcvideo.rst | 12 
>>  drivers/media/usb/uvc/Kconfig|  2 ++
>>  drivers/media/usb/uvc/uvc_driver.c   |  3 ++-
>>  drivers/media/usb/uvc/uvc_queue.c| 23 ---
>>  drivers/media/usb/uvc/uvcvideo.h |  4 ++--
>>  5 files changed, 38 insertions(+), 6 deletions(-)
>--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [media] uvcvideo: support for contiguous DMA buffers

[Laurent Pinchart]

On Tuesday 10 Jan 2017 08:55:16 Vincent ABRIOU wrote:
> On 01/09/2017 05:59 PM, Laurent Pinchart wrote:
> > On Monday 09 Jan 2017 15:49:00 Vincent ABRIOU wrote:
> >> On 01/09/2017 04:37 PM, Laurent Pinchart wrote:
> >>> Hi Vincent,
> >>> 
> >>> Thank you for the patch.
> >>> 
> >>> On Monday 03 Oct 2016 13:27:16 Vincent Abriou wrote:
>  Allow uvcvideo compatible devices to allocate their output buffers
>  using contiguous DMA buffers.
> >>> 
> >>> Why do you need this ? If it's for buffer sharing with a device that
> >>> requires dma-contig, can't you allocate the buffers on the other device
> >>> and import them on the UVC side ?
> >> 
> >> Hi Laurent,
> >> 
> >> I need this using Gstreamer simple pipeline to connect an usb webcam
> >> (v4l2src) with a display (waylandsink) activating the zero copy path.
> >> 
> >> The waylandsink plugin does not have any contiguous memory pool to
> >> allocate contiguous buffer. So it is up to the upstream element, here
> >> v4l2src, to provide such contiguous buffers.
> > 
> > Isn't that a gstreamer issue ?
> 
> It is not a gstreamer issue. It is the way it has been decided to work.
> Waylandsink accept DMABUF contiguous buffer but it does not have its own
> buffer pool.

But why do you put the blame on the kernel when you decide to take the wrong 
decision in userspace ? :-)

>  Add the "allocators" module parameter option to let uvcvideo use the
>  dma-contig instead of vmalloc.
>  
>  Signed-off-by: Vincent Abriou 
>  ---
>  
>   Documentation/media/v4l-drivers/uvcvideo.rst | 12 
>   drivers/media/usb/uvc/Kconfig|  2 ++
>   drivers/media/usb/uvc/uvc_driver.c   |  3 ++-
>   drivers/media/usb/uvc/uvc_queue.c| 23 ---
>   drivers/media/usb/uvc/uvcvideo.h |  4 ++--
>   5 files changed, 38 insertions(+), 6 deletions(-)

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

[Sean Wang]

On Tue, 2017-01-10 at 11:09 +, Sean Young wrote:

> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define MTK_IR_DEV KBUILD_MODNAME
> 
> You could remove this #define and just use KBUILD_MODNAME

I preferred to use MTK_IR_DEV internally that helps
renaming in the future if necessary.
>  
> > +
> > +/* Register to enable PWM and IR */
> > +#define MTK_CONFIG_HIGH_REG   0x0c
> > +/* Enable IR pulse width detection */
> > +#define MTK_PWM_EN   BIT(13)
> > +/* Enable IR hardware function */
> > +#define MTK_IR_ENBIT(0)
> > +
> > +/* Register to setting sample period */
> > +#define MTK_CONFIG_LOW_REG0x10
> > +/* Field to set sample period */
> > +#define CHK_PERIOD   DIV_ROUND_CLOSEST(MTK_IR_SAMPLE,  \
> > +   MTK_IR_CLK_PERIOD)
> > +#define MTK_CHK_PERIOD(((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
> > +#define MTK_CHK_PERIOD_MASK  (GENMASK(20, 8))
> > +
> > +/* Register to clear state of state machine */
> > +#define MTK_IRCLR_REG 0x20
> > +/* Bit to restart IR receiving */
> > +#define MTK_IRCLRBIT(0)
> > +
> > +/* Register containing pulse width data */
> > +#define MTK_CHKDATA_REG(i)(0x88 + 4 * (i))
> > +#define MTK_WIDTH_MASK   (GENMASK(7, 0))
> > +
> > +/* Register to enable IR interrupt */
> > +#define MTK_IRINT_EN_REG  0xcc
> > +/* Bit to enable interrupt */
> > +#define MTK_IRINT_EN BIT(0)
> > +
> > +/* Register to ack IR interrupt */
> > +#define MTK_IRINT_CLR_REG 0xd0
> > +/* Bit to clear interrupt status */
> > +#define MTK_IRINT_CLRBIT(0)
> > +
> > +/* Maximum count of samples */
> > +#define MTK_MAX_SAMPLES  0xff
> > +/* Indicate the end of IR message */
> > +#define MTK_IR_END(v, p) ((v) == MTK_MAX_SAMPLES && (p) == 0)
> > +/* Number of registers to record the pulse width */
> > +#define MTK_CHKDATA_SZ   17
> > +/* Source clock frequency */
> > +#define MTK_IR_BASE_CLK  27300
> > +/* Frequency after IR internal divider */
> > +#define MTK_IR_CLK_FREQ  (MTK_IR_BASE_CLK / 4)

> > +static irqreturn_t mtk_ir_irq(int irqno, void *dev_id)
> > +{
> > +   struct mtk_ir *ir = dev_id;
> > +   u8  wid = 0;
> > +   u32 i, j, val;
> > +   DEFINE_IR_RAW_EVENT(rawir);
> > +
> > +   mtk_irq_disable(ir, MTK_IRINT_EN);
> 
> The kernel guarantees that calls to the interrupt handler are serialised,
> no need to disable the interrupt in the handler.

agreed. I will save the mtk irq disable/enable and retest again.


> > +
> > +   /* Reset decoder state machine */
> > +   ir_raw_event_reset(ir->rc);
> 
> Not needed.


two reasons I added the line here

1) 
I thought it is possible the decoder goes to the
middle state when getting the data not belonged
to the protocol. If so, that would cause the decoding
fails in the next time receiving the valid protocol data.

2) 
the mtk hardware register always contains the start of 
IR message. So force to sync the state between 
HW and ir-core.



> > +
> > +   /* First message must be pulse */
> > +   rawir.pulse = false;
> 
> pulse = true?

becasue of rawir.pulse = !rawir.pulse does as below
so the initial value is set as false.

> > +
> > +   /* Handle all pulse and space IR controller captures */
> > +   for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
> > +   val = mtk_r32(ir, MTK_CHKDATA_REG(i));
> > +   dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
> > +
> > +   for (j = 0 ; j < 4 ; j++) {
> > +   wid = (val & (MTK_WIDTH_MASK << j * 8)) >> j * 8;
> > +   rawir.pulse = !rawir.pulse;
> > +   rawir.duration = wid * (MTK_IR_SAMPLE + 1);
> > +   ir_raw_event_store_with_filter(ir->rc, );
> > +   }
> 
> In v1 you would break out of the loop if the ir message was shorter, but
> now you are always passing on 68 pulses and spaces. Is that right?

as I asked in the previous mail list as below i copied from it, so i
made some changes ...

"
> I had another question. I found multiple and same IR messages being
> received when using SONY remote controller. Should driver needs to
> report each message or only one of these to the upper layer ?

In general the driver shouldn't try to change any IR message, this
should be done in rc-core if necessary.

rc-core should handle this correctly. If the same key is received twice
within IR_KEYPRESS_TIMEOUT (250ms) then it not reported to the input
layer.


for example:
the 68 pulse/spaces might contains 2.x IR messages when I
pressed one key on SONY remote control. 

the v1 proposed is passing only one IR message into ir-core ; 
the v2 done is passing all IR messages even including the last
incomplete message into ir-core. 

But 

Re: [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

[kbuild test robot]

Hi Sean,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.10-rc3 next-20170110]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/Documentation-devicetree-Add-document-bindings-for-mtk-cir/20170110-193357
base:   git://linuxtv.org/media_tree.git master
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
   drivers/media/rc/mtk-cir.c:215:41: sparse: too many arguments for function 
devm_rc_allocate_device
   drivers/media/rc/mtk-cir.c: In function 'mtk_ir_probe':
>> drivers/media/rc/mtk-cir.c:215:11: error: too many arguments to function 
>> 'devm_rc_allocate_device'
 ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
  ^~~
   In file included from drivers/media/rc/mtk-cir.c:22:0:
   include/media/rc-core.h:213:16: note: declared here
struct rc_dev *devm_rc_allocate_device(struct device *dev);
   ^~~

sparse warnings: (new ones prefixed by >>)

   include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': 
unknown attribute
>> drivers/media/rc/mtk-cir.c:215:41: sparse: too many arguments for function 
>> devm_rc_allocate_device
   drivers/media/rc/mtk-cir.c: In function 'mtk_ir_probe':
   drivers/media/rc/mtk-cir.c:215:11: error: too many arguments to function 
'devm_rc_allocate_device'
 ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
  ^~~
   In file included from drivers/media/rc/mtk-cir.c:22:0:
   include/media/rc-core.h:213:16: note: declared here
struct rc_dev *devm_rc_allocate_device(struct device *dev);
   ^~~

vim +/devm_rc_allocate_device +215 drivers/media/rc/mtk-cir.c

   209  ir->base = devm_ioremap_resource(dev, res);
   210  if (IS_ERR(ir->base)) {
   211  dev_err(dev, "failed to map registers\n");
   212  return PTR_ERR(ir->base);
   213  }
   214  
 > 215  ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
   216  if (!ir->rc) {
   217  dev_err(dev, "failed to allocate device\n");
   218  return -ENOMEM;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v4 8/9] media: venus: hfi: add Venus HFI files

[Stanimir Varbanov]

Hi Hans,

On 01/09/2017 03:04 PM, Hans Verkuil wrote:
> On 12/05/2016 01:20 PM, Stanimir Varbanov wrote:
>> Hi Hans,
>>
>> On 12/05/2016 02:05 PM, Hans Verkuil wrote:
>>> On 12/01/2016 10:03 AM, Stanimir Varbanov wrote:
 Here is the implementation of Venus video accelerator low-level
 functionality. It contanins code which setup the registers and
 startup uthe processor, allocate and manipulates with the shared
 memory used for sending commands and receiving messages.

 Signed-off-by: Stanimir Varbanov 
 ---
  drivers/media/platform/qcom/venus/hfi_venus.c| 1508 
 ++
  drivers/media/platform/qcom/venus/hfi_venus.h|   23 +
  drivers/media/platform/qcom/venus/hfi_venus_io.h |   98 ++
  3 files changed, 1629 insertions(+)
  create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.c
  create mode 100644 drivers/media/platform/qcom/venus/hfi_venus.h
  create mode 100644 drivers/media/platform/qcom/venus/hfi_venus_io.h

 diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c 
 b/drivers/media/platform/qcom/venus/hfi_venus.c
 new file mode 100644
 index ..f004a9a80d85
 --- /dev/null
 +++ b/drivers/media/platform/qcom/venus/hfi_venus.c
 @@ -0,0 +1,1508 @@
 +static int venus_tzbsp_set_video_state(enum tzbsp_video_state state)
 +{
 +  return qcom_scm_video_set_state(state, 0);
>>>
>>> This functions doesn't seem to exist. Is there a prerequisite patch series 
>>> that
>>> introduces this function?
>>
>> yes, the patchset [1] is under review.
>>
> 
> What is the status of this patchset?

It is under discussion, still. I will send a new version of patches soon.

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

[GIT PULL v2 FOR v4.10] CEC fix and update cec documentation

[Hans Verkuil]

Two cec documentation updates and one CEC framework fix.

Regards,

Hans

The following changes since commit 40eca140c404505c09773d1c6685d818cb55ab1a:

  [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200)

are available in the git repository at:

  git://linuxtv.org/hverkuil/media_tree.git for-v4.10f

for you to fetch changes up to 65d3b33b9adcc96f48246f6bb1d9ab14ccca70bf:

  cec: fix wrong last_la determination (2017-01-10 12:54:15 +0100)


Hans Verkuil (3):
  cec rst: remove "This API is not yet finalized" notice
  cec-intro.rst: mention the v4l-utils package and CEC utilities
  cec: fix wrong last_la determination

 Documentation/media/uapi/cec/cec-func-close.rst   |  5 -
 Documentation/media/uapi/cec/cec-func-ioctl.rst   |  5 -
 Documentation/media/uapi/cec/cec-func-open.rst|  5 -
 Documentation/media/uapi/cec/cec-func-poll.rst|  5 -
 Documentation/media/uapi/cec/cec-intro.rst| 17 
-
 Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst  |  5 -
 Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst |  5 -
 Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst |  5 -
 Documentation/media/uapi/cec/cec-ioc-dqevent.rst  |  5 -
 Documentation/media/uapi/cec/cec-ioc-g-mode.rst   |  5 -
 Documentation/media/uapi/cec/cec-ioc-receive.rst  |  5 -
 drivers/media/cec/cec-adap.c  |  2 +-
 12 files changed, 13 insertions(+), 56 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH for v4.10] cec: fix wrong last_la determination

[Hans Verkuil]

Due to an incorrect condition the last_la used for the initial attempt at
claiming a logical address could be wrong.

The last_la wasn't converted to a mask when ANDing with type2mask, so that
test was broken.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index ebb5e391b800..87a6b65ed3af 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -1206,7 +1206,7 @@ static int cec_config_thread_func(void *arg)
las->log_addr[i] = CEC_LOG_ADDR_INVALID;
if (last_la == CEC_LOG_ADDR_INVALID ||
last_la == CEC_LOG_ADDR_UNREGISTERED ||
-   !(last_la & type2mask[type]))
+   !((1 << last_la) & type2mask[type]))
last_la = la_list[0];

err = cec_config_log_addr(adap, i, last_la);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/10] media: camss: Add files which handle the video device nodes

[Todor Tomov]

Hi Laurent, Hans,

On 12/05/2016 05:25 PM, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Monday 05 Dec 2016 16:02:55 Hans Verkuil wrote:
>> On 12/05/2016 03:45 PM, Laurent Pinchart wrote:
>>> On Monday 05 Dec 2016 14:44:55 Hans Verkuil wrote:
 On 11/25/2016 03:57 PM, Todor Tomov wrote:
> These files handle the video device nodes of the camss driver.
>
> Signed-off-by: Todor Tomov 
> ---
>
>  drivers/media/platform/qcom/camss-8x16/video.c | 597 +
>  drivers/media/platform/qcom/camss-8x16/video.h |  67 +++
>  2 files changed, 664 insertions(+)
>  create mode 100644 drivers/media/platform/qcom/camss-8x16/video.c
>  create mode 100644 drivers/media/platform/qcom/camss-8x16/video.h
>>>
>>> [snip]
>>>
> +int msm_video_register(struct camss_video *video, struct v4l2_device
> *v4l2_dev,
> +const char *name)
> +{
> + struct media_pad *pad = >pad;
> + struct video_device *vdev;
> + struct vb2_queue *q;
> + int ret;
> +
> + vdev = video_device_alloc();
> + if (vdev == NULL) {
> + dev_err(v4l2_dev->dev, "Failed to allocate video
> device\n");
> + return -ENOMEM;
> + }
> +
> + video->vdev = vdev;
> +
> + q = >vb2_q;
> + q->drv_priv = video;
> + q->mem_ops = _dma_contig_memops;
> + q->ops = _video_vb2_q_ops;
> + q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> + q->io_modes = VB2_MMAP;

 Add modes VB2_DMABUF and VB2_READ. These are for free, so why not?
 Especially DMABUF is of course very desirable to have.
>>>
>>> I certainly agree with VB2_DMABUF, but I wouldn't expose VB2_READ. read()
>>> for this kind of device is inefficient and we should encourage userspace
>>> application to move away from it (and certainly make it very clear that
>>> new applications should not use read() with this device).
>>
>> VB2_READ is very nice when debugging (no need to program a stream I/O
>> application first)
> 
> There's at least v4l2-ctl and yavta that can (and should) be used for 
> debugging ;-)
> 
>> and useful when you want to pipe the video.
> 
> Except that you lose frame boundaries. It's really a poor man's solution that 
> should never be used in any "real" application. I'd rather add an option to 
> v4l2-ctl to output the video stream to stdout (and/or stderr).
> 
>> Nobody uses read() in 'regular' applications since it is obviously
>> inefficient, but I don't see that as a reason not to offer VB2_READ.
>>
>> I don't think this is something anyone will ever abuse,
> 
> Famous last words ;-)
> 
>> and it is a nice feature to have (and for free as well).
> 

Thank you for the discussion over this. Both of you have reasonable arguments
about the read i/o.
I'd say that you cannot always save a person from himself. I'll add VB2_READ.

-- 
Best regards,
Todor Tomov
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/10] media: camss: Add files which handle the video device nodes

[Todor Tomov]

Hi Hans,

Thank you for the extensive review.

On 12/05/2016 03:44 PM, Hans Verkuil wrote:
> A few comments below:
> 
> On 11/25/2016 03:57 PM, Todor Tomov wrote:
>> These files handle the video device nodes of the camss driver.
>>
>> Signed-off-by: Todor Tomov 
>> ---
>>  drivers/media/platform/qcom/camss-8x16/video.c | 597 
>> +
>>  drivers/media/platform/qcom/camss-8x16/video.h |  67 +++
>>  2 files changed, 664 insertions(+)
>>  create mode 100644 drivers/media/platform/qcom/camss-8x16/video.c
>>  create mode 100644 drivers/media/platform/qcom/camss-8x16/video.h
>>
>> diff --git a/drivers/media/platform/qcom/camss-8x16/video.c 
>> b/drivers/media/platform/qcom/camss-8x16/video.c
>> new file mode 100644
>> index 000..0bf8ea9
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/camss-8x16/video.c
>> @@ -0,0 +1,597 @@
> 
> 
> 
>> +static int video_start_streaming(struct vb2_queue *q, unsigned int count)
>> +{
>> +struct camss_video *video = vb2_get_drv_priv(q);
>> +struct video_device *vdev = video->vdev;
>> +struct media_entity *entity;
>> +struct media_pad *pad;
>> +struct v4l2_subdev *subdev;
>> +int ret;
>> +
>> +ret = media_entity_pipeline_start(>entity, >pipe);
>> +if (ret < 0)
>> +return ret;
>> +
>> +ret = video_check_format(video);
>> +if (ret < 0)
>> +goto error;
>> +
>> +entity = >entity;
>> +while (1) {
>> +pad = >pads[0];
>> +if (!(pad->flags & MEDIA_PAD_FL_SINK))
>> +break;
>> +
>> +pad = media_entity_remote_pad(pad);
>> +if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
>> +break;
>> +
>> +entity = pad->entity;
>> +subdev = media_entity_to_v4l2_subdev(entity);
>> +
>> +ret = v4l2_subdev_call(subdev, video, s_stream, 1);
>> +if (ret < 0 && ret != -ENOIOCTLCMD)
>> +goto error;
>> +}
>> +
>> +return 0;
>> +
>> +error:
>> +media_entity_pipeline_stop(>entity);
>> +
> 
> On error all queued buffers must be returned with state VB2_STATE_QUEUED.
> 
> Basically the same as 'camss_video_call(video, flush_buffers);', just with
> a different state.

Ok, I'll add this.

> 
>> +return ret;
>> +}
> 
> 
> 
>> +static int video_querycap(struct file *file, void *fh,
>> +  struct v4l2_capability *cap)
>> +{
>> +strlcpy(cap->driver, "qcom-camss", sizeof(cap->driver));
>> +strlcpy(cap->card, "Qualcomm Camera Subsystem", sizeof(cap->card));
>> +strlcpy(cap->bus_info, "platform:qcom-camss", sizeof(cap->bus_info));
>> +cap->capabilities = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
>> +V4L2_CAP_DEVICE_CAPS;
>> +cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
> 
> Don't set capabilities and device_caps here. Instead fill in the struct 
> video_device
> device_caps field and the v4l2 core will take care of cap->capabilities and
> cap->device_caps.

Ok.

> 
>> +
>> +return 0;
>> +}
>> +
>> +static int video_enum_fmt(struct file *file, void *fh, struct v4l2_fmtdesc 
>> *f)
>> +{
>> +struct camss_video *video = video_drvdata(file);
>> +struct v4l2_format format;
>> +int ret;
>> +
>> +if (f->type != video->type)
>> +return -EINVAL;
>> +
>> +if (f->index)
>> +return -EINVAL;
>> +
>> +ret = video_get_subdev_format(video, );
>> +if (ret < 0)
>> +return ret;
>> +
>> +f->pixelformat = format.fmt.pix.pixelformat;
>> +
>> +return 0;
>> +}
>> +
>> +static int video_g_fmt(struct file *file, void *fh, struct v4l2_format *f)
>> +{
>> +struct camss_video *video = video_drvdata(file);
>> +
>> +if (f->type != video->type)
>> +return -EINVAL;
>> +
>> +*f = video->active_fmt;
>> +
>> +return 0;
>> +}
>> +
>> +static int video_s_fmt(struct file *file, void *fh, struct v4l2_format *f)
>> +{
>> +struct camss_video *video = video_drvdata(file);
>> +int ret;
>> +
>> +if (f->type != video->type)
>> +return -EINVAL;
>> +
>> +ret = video_get_subdev_format(video, f);
>> +if (ret < 0)
>> +return ret;
>> +
>> +video->active_fmt = *f;
>> +
>> +return 0;
>> +}
>> +
>> +static int video_try_fmt(struct file *file, void *fh, struct v4l2_format *f)
>> +{
>> +struct camss_video *video = video_drvdata(file);
>> +
>> +if (f->type != video->type)
>> +return -EINVAL;
>> +
>> +return video_get_subdev_format(video, f);
>> +}
>> +
>> +static int video_enum_input(struct file *file, void *fh,
>> +struct v4l2_input *input)
>> +{
>> +if (input->index > 0)
>> +return -EINVAL;
>> +
>> +strlcpy(input->name, "camera", sizeof(input->name));
>> +input->type = V4L2_INPUT_TYPE_CAMERA;
>> +
>> +return 0;
>> +}
>> +
>> +static int 

Re: [PATCH v2] [media] vivid: support for contiguous DMA buffers

[Vincent ABRIOU]

On 01/09/2017 04:10 PM, Hans Verkuil wrote:
> On 09/12/2016 10:47 AM, Vincent Abriou wrote:
>> It allows to simulate the behavior of hardware with such limitations or
>> to connect vivid to real hardware with such limitations.
>>
>> Add the "allocators" module parameter option to let vivid use the
>> dma-contig instead of vmalloc.
>>
>> Signed-off-by: Philipp Zabel 
>> Signed-off-by: Hans Verkuil 
>> Signed-off-by: Vincent Abriou 
>>
>> Cc: Philipp Zabel 
>> Cc: Hans Verkuil 
>> ---
>>  Documentation/media/v4l-drivers/vivid.rst |  8 
>>  drivers/media/platform/vivid/Kconfig  |  2 ++
>>  drivers/media/platform/vivid/vivid-core.c | 32 
>> ++-
>>  3 files changed, 37 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/media/v4l-drivers/vivid.rst 
>> b/Documentation/media/v4l-drivers/vivid.rst
>> index c8cf371..3e44b22 100644
>> --- a/Documentation/media/v4l-drivers/vivid.rst
>> +++ b/Documentation/media/v4l-drivers/vivid.rst
>> @@ -263,6 +263,14 @@ all configurable using the following module options:
>>  removed. Unless overridden by ccs_cap_mode and/or ccs_out_mode the
>>  will default to enabling crop, compose and scaling.
>>
>> +- allocators:
>> +
>> +memory allocator selection, default is 0. It specifies the way buffers
>> +will be allocated.
>> +
>> +- 0: vmalloc
>> +- 1: dma-contig
>
> Could you add support for dma-sg as well? I think that would be fairly 
> trivial (unless
> I missed something).
>
> Once that's added (or it's clear dma-sg won't work for some reason), then 
> I'll merge this.
>
> Regards,
>
>   Hans
>

Hi Hans,

What is the difference between a vmalloc allocation exported in DMABUF 
that will populate the sg and dma-sg allocation?

BR
Vincent

>> +
>>  Taken together, all these module options allow you to precisely customize
>>  the driver behavior and test your application with all sorts of 
>> permutations.
>>  It is also very suitable to emulate hardware that is not yet available, e.g.
>> diff --git a/drivers/media/platform/vivid/Kconfig 
>> b/drivers/media/platform/vivid/Kconfig
>> index 8e6918c..2e238a1 100644
>> --- a/drivers/media/platform/vivid/Kconfig
>> +++ b/drivers/media/platform/vivid/Kconfig
>> @@ -1,6 +1,7 @@
>>  config VIDEO_VIVID
>>  tristate "Virtual Video Test Driver"
>>  depends on VIDEO_DEV && VIDEO_V4L2 && !SPARC32 && !SPARC64 && FB
>> +depends on HAS_DMA
>>  select FONT_SUPPORT
>>  select FONT_8x16
>>  select FB_CFB_FILLRECT
>> @@ -8,6 +9,7 @@ config VIDEO_VIVID
>>  select FB_CFB_IMAGEBLIT
>>  select MEDIA_CEC_EDID
>>  select VIDEOBUF2_VMALLOC
>> +select VIDEOBUF2_DMA_CONTIG
>>  select VIDEO_V4L2_TPG
>>  default n
>>  ---help---
>> diff --git a/drivers/media/platform/vivid/vivid-core.c 
>> b/drivers/media/platform/vivid/vivid-core.c
>> index 741460a..02e1909 100644
>> --- a/drivers/media/platform/vivid/vivid-core.c
>> +++ b/drivers/media/platform/vivid/vivid-core.c
>> @@ -30,6 +30,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -151,6 +152,12 @@ static bool no_error_inj;
>>  module_param(no_error_inj, bool, 0444);
>>  MODULE_PARM_DESC(no_error_inj, " if set disable the error injecting 
>> controls");
>>
>> +static unsigned int allocators[VIVID_MAX_DEVS] = { [0 ... (VIVID_MAX_DEVS - 
>> 1)] = 0 };
>> +module_param_array(allocators, uint, NULL, 0444);
>> +MODULE_PARM_DESC(allocators, " memory allocator selection, default is 0.\n"
>> + "\t\t0 == vmalloc\n"
>> + "\t\t1 == dma-contig");
>> +
>>  static struct vivid_dev *vivid_devs[VIVID_MAX_DEVS];
>>
>>  const struct v4l2_rect vivid_min_rect = {
>> @@ -636,6 +643,10 @@ static int vivid_create_instance(struct platform_device 
>> *pdev, int inst)
>>  {
>>  static const struct v4l2_dv_timings def_dv_timings =
>>  V4L2_DV_BT_CEA_1280X720P60;
>> +static const struct vb2_mem_ops * const vivid_mem_ops[2] = {
>> +_vmalloc_memops,
>> +_dma_contig_memops,
>> +};
>>  unsigned in_type_counter[4] = { 0, 0, 0, 0 };
>>  unsigned out_type_counter[4] = { 0, 0, 0, 0 };
>>  int ccs_cap = ccs_cap_mode[inst];
>> @@ -646,6 +657,7 @@ static int vivid_create_instance(struct platform_device 
>> *pdev, int inst)
>>  struct video_device *vfd;
>>  struct vb2_queue *q;
>>  unsigned node_type = node_types[inst];
>> +unsigned int allocator = allocators[inst];
>>  v4l2_std_id tvnorms_cap = 0, tvnorms_out = 0;
>>  int ret;
>>  int i;
>> @@ -1036,6 +1048,11 @@ static int vivid_create_instance(struct 
>> platform_device *pdev, int inst)
>>  if (!dev->cec_workqueue)
>>  goto unreg_dev;
>>
>> +if (allocator == 1)
>> +

Re: [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

[Sean Young]

Hi Sean

Some more review comments. 

On Tue, Jan 10, 2017 at 05:13:51PM +0800, sean.w...@mediatek.com wrote:
> From: Sean Wang 
> 
> This patch adds driver for IR controller on MT7623 SoC.
> and should also work on similar Mediatek SoC. Currently
> testing successfully on NEC and SONY remote controller
> only but it should work on others (lirc, rc-5 and rc-6).
> 
> Signed-off-by: Sean Wang 
> Reviewed-by: Sean Young 
> ---
>  drivers/media/rc/Kconfig   |  11 ++
>  drivers/media/rc/Makefile  |   1 +
>  drivers/media/rc/mtk-cir.c | 326 
> +
>  3 files changed, 338 insertions(+)
>  create mode 100644 drivers/media/rc/mtk-cir.c
> 
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 629e8ca..9228479 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -235,6 +235,17 @@ config IR_MESON
>  To compile this driver as a module, choose M here: the
>  module will be called meson-ir.
>  
> +config IR_MTK
> + tristate "Mediatek IR remote receiver"
> + depends on RC_CORE
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + ---help---
> +Say Y if you want to use the IR remote receiver available
> +on Mediatek SoCs.
> +
> +To compile this driver as a module, choose M here: the
> +module will be called mtk-cir.
> +
>  config IR_NUVOTON
>   tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
>   depends on PNP
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 3a984ee..a78570b 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -38,3 +38,4 @@ obj-$(CONFIG_RC_ST) += st_rc.o
>  obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
>  obj-$(CONFIG_IR_IMG) += img-ir/
>  obj-$(CONFIG_IR_SERIAL) += serial_ir.o
> +obj-$(CONFIG_IR_MTK) += mtk-cir.o
> diff --git a/drivers/media/rc/mtk-cir.c b/drivers/media/rc/mtk-cir.c
> new file mode 100644
> index 000..f752f63
> --- /dev/null
> +++ b/drivers/media/rc/mtk-cir.c
> @@ -0,0 +1,326 @@
> +/*
> + * Driver for Mediatek IR Receiver Controller
> + *
> + * Copyright (C) 2017 Sean Wang 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MTK_IR_DEV KBUILD_MODNAME

You could remove this #define and just use KBUILD_MODNAME 
> +
> +/* Register to enable PWM and IR */
> +#define MTK_CONFIG_HIGH_REG   0x0c
> +/* Enable IR pulse width detection */
> +#define MTK_PWM_EN BIT(13)
> +/* Enable IR hardware function */
> +#define MTK_IR_EN  BIT(0)
> +
> +/* Register to setting sample period */
> +#define MTK_CONFIG_LOW_REG0x10
> +/* Field to set sample period */
> +#define CHK_PERIOD DIV_ROUND_CLOSEST(MTK_IR_SAMPLE,  \
> + MTK_IR_CLK_PERIOD)
> +#define MTK_CHK_PERIOD(((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
> +#define MTK_CHK_PERIOD_MASK(GENMASK(20, 8))
> +
> +/* Register to clear state of state machine */
> +#define MTK_IRCLR_REG 0x20
> +/* Bit to restart IR receiving */
> +#define MTK_IRCLR  BIT(0)
> +
> +/* Register containing pulse width data */
> +#define MTK_CHKDATA_REG(i)(0x88 + 4 * (i))
> +#define MTK_WIDTH_MASK (GENMASK(7, 0))
> +
> +/* Register to enable IR interrupt */
> +#define MTK_IRINT_EN_REG  0xcc
> +/* Bit to enable interrupt */
> +#define MTK_IRINT_EN   BIT(0)
> +
> +/* Register to ack IR interrupt */
> +#define MTK_IRINT_CLR_REG 0xd0
> +/* Bit to clear interrupt status */
> +#define MTK_IRINT_CLR  BIT(0)
> +
> +/* Maximum count of samples */
> +#define MTK_MAX_SAMPLES0xff
> +/* Indicate the end of IR message */
> +#define MTK_IR_END(v, p)   ((v) == MTK_MAX_SAMPLES && (p) == 0)
> +/* Number of registers to record the pulse width */
> +#define MTK_CHKDATA_SZ 17
> +/* Source clock frequency */
> +#define MTK_IR_BASE_CLK27300
> +/* Frequency after IR internal divider */
> +#define MTK_IR_CLK_FREQ(MTK_IR_BASE_CLK / 4)
> +/* Period for MTK_IR_CLK in ns*/
> +#define MTK_IR_CLK_PERIOD  DIV_ROUND_CLOSEST(10ul,  \
> + MTK_IR_CLK_FREQ)
> +/* Sample period in ns */
> +#define MTK_IR_SAMPLE  

Re: [PATCH 0/6] R-Car DU: Fix IOMMU operation when connected to VSP

[Geert Uytterhoeven]

Hi Laurent,

On Fri, Aug 19, 2016 at 10:39 AM, Laurent Pinchart
 wrote:
> This patch series fixes the rcar-du-drm driver to support VSP plane sources
> with an IOMMU. It is available for convenience at
>
> git://linuxtv.org/pinchartl/media.git iommu/devel/du

Dropped from renesas-drivers, as this branch is based on a very old tree
(v4.8-rc2), and many (but not all!) commits have found their way upstream.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

[Ramesh Shanmugasundaram]

Hi Laurent,

> > >>> On Wednesday 21 Dec 2016 08:10:37 Ramesh Shanmugasundaram wrote:
> >  Add binding documentation for Renesas R-Car Digital Radio
> >  Interface
> >  (DRIF) controller.
> > 
> >  Signed-off-by: Ramesh Shanmugasundaram
> >   ---
> > 
> >   .../devicetree/bindings/media/renesas,drif.txt | 202
> +
> >   1 file changed, 202 insertions(+)  create mode 100644
> > 
> >  Documentation/devicetree/bindings/media/renesas,drif.txt
> > 
> >  diff --git
> >  a/Documentation/devicetree/bindings/media/renesas,drif.txt
> >  b/Documentation/devicetree/bindings/media/renesas,drif.txt new
> >  file mode 100644 index 000..1f3feaf
> >  --- /dev/null
> >  +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> > 
> >  +Optional properties of an internal channel when:
> >  + - It is the only enabled channel of the bond (or)
> >  + - If it acts as primary among enabled bonds
> >  +
> >  +- renesas,syncmd   : sync mode
> >  +  0 (Frame start sync pulse mode. 1-bit
> >  +width
> >  pulse
> >  + indicates start of a frame)
> >  +  1 (L/R sync or I2S mode) (default)
> >  +- renesas,lsb-first: empty property indicates lsb bit is
> received
> >  first.
> >  +  When not defined msb bit is received first
> >  +(default)
> >  +- renesas,syncac-active: Indicates sync signal polarity, 0/1 for
> >  low/high
> >
> > Shouldn't this be 'renesas,sync-active' instead of syncac-active?
> >
> > I'm not sure if syncac is intended or if it is a typo.
> >
> >  +  respectively. The default is 1 (active high)
> >  +- renesas,dtdl : delay between sync signal and start of
> >  reception.
> >  +  The possible values are represented in 0.5
> clock
> >  +  cycle units and the range is 0 to 4. The
> default
> >  +  value is 2 (i.e.) 1 clock cycle delay.
> >  +- renesas,syncdl   : delay between end of reception and sync
> >  signal edge.
> >  +  The possible values are represented in 0.5
> clock
> >  +  cycle units and the range is 0 to 4 & 6.
> >  + The
> >  default
> >  +  value is 0 (i.e.) no delay.
> > >>>
> > >>> Most of these properties are pretty similar to the video bus
> > >>> properties defined at the endpoint level in
> > >>> Documentation/devicetree/bindings/media/video-interfaces.txt. I
> > >>> believe it would make sense to use OF graph and try to standardize
> > >>> these properties similarly.
> >
> > Other than sync-active, is there really anything else that is similar?
> > And even the sync-active isn't a good fit since here there is only one
> > sync signal instead of two for video (h and vsync).
> 
> That's why I said similar, not identical :-) My point is that, if we
> consider that we could connect multiple sources to the DRIF, using OF
> graph would make sense, and the above properties should then be defined
> per endpoint.

Thanks for the clarifications. I have some questions.

- Assuming two devices are interfaced with DRIF and they are represented using 
two endpoints, the control signal related properties of DRIF might still need 
to be same for both endpoints? For e.g. syncac-active cannot be different in 
both endpoints?

- I suppose "lsb-first", "dtdl" & "syncdl" may be defined per endpoint. 
However, h/w manual says same register values needs to be programmed for both 
the internal channels of a channel. Same with "syncmd" property.

We could still define them as per endpoint property with a note that they need 
to be same. But I am not sure if that is what you intended?

 If we define them per endpoint we should then also try
> standardize the ones that are not really Renesas-specific (that's at least
> syncac-active).

OK. I will call it "sync-active".

 For the syncmd and lsb-first properties, it could also
> make sense to query them from the connected subdev at runtime, as they're
> similar in purpose to formats and media bus configuration (struct
> v4l2_mbus_config).

May I know in bit more detail about what you had in mind? Please correct me if 
my understanding is wrong here but when I looked at the code

1) mbus_config is part of subdev_video_ops only. I assume we don't want to 
support this as part of tuner subdev. The next closest is pad_ops with "struct 
v4l2_mbus_framefmt" but it is fully video specific config unless I come up with 
new MEDIA_BUS_FMT_ in media-bus-format.h and use the code field? For e.g.

#define MEDIA_BUS_FMT_SDR_I2S_PADHI_BE   0x7001
#define MEDIA_BUS_FMT_SDR_I2S_PADHI_LE   0x7002

2) The framework does 

[PATCH v2 1/2] Documentation: devicetree: Add document bindings for mtk-cir

[sean.wang]

From: Sean Wang 

This patch adds documentation for devicetree bindings for
Mediatek consumer IR controller.

Signed-off-by: Sean Wang 
---
 .../devicetree/bindings/media/mtk-cir.txt  | 24 ++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt

diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt 
b/Documentation/devicetree/bindings/media/mtk-cir.txt
new file mode 100644
index 000..3850cbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
@@ -0,0 +1,24 @@
+Device-Tree bindings for Mediatek consumer IR controller found in
+Mediatek SoC family
+
+Required properties:
+- compatible   : "mediatek,mt7623-cir"
+- clocks   : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names  : should contain "clk" entries;
+- interrupts   : should contain IR IRQ number;
+- reg  : should contain IO map address for IR.
+
+Optional properties:
+- linux,rc-map-name : Remote control map name.
+
+Example:
+
+cir: cir@10013000 {
+   compatible = "mediatek,mt7623-cir";
+   reg = <0 0x10013000 0 0x1000>;
+   interrupts = ;
+   clocks = < CLK_INFRA_IRRX>;
+   clock-names = "clk";
+   linux,rc-map-name = "rc-rc6-mce";
+};
-- 
2.7.4

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

[PATCH v2 0/2] media: rc: add support for IR receiver on MT7623 SoC

[sean.wang]

From: Sean Wang 

This patchset introduces consumer IR (CIR) support on MT7623 SoC 
that also works on other similar SoCs and implements raw mode for
more compatibility with different protocols. The driver simply
reports the duration of pulses and spaces to rc-core logic to
decode.

Changes since v1:
- change compatible string from "mediatek,mt7623-ir" into 
"mediatek,mt7623-cir"
- use KBUILD_MODNAME to provide consistent device name used in driver.
- remove unused fields in struct mtk_ir.
- use synchronize_irq to give protection between IRQ handler and 
remove handler.
- use devm_rc_allocate_device based on Andi Shyti's work.
- simplify error handling patch with devm_rc_register_device and 
devm_rc_allocate_device.
- remove unused spinlock.
- add comments about hardware limitation and related workarounds.
- enhance the caculation of sampling period for easiler assigned specific 
value.
- refine git description.
- fix IR message handling between IR hardware and rc-core.

Sean Wang (2):
  Documentation: devicetree: Add document bindings for mtk-cir
  media: rc: add driver for IR remote receiver on MT7623 SoC

 .../devicetree/bindings/media/mtk-cir.txt  |  24 ++
 drivers/media/rc/Kconfig   |  11 +
 drivers/media/rc/Makefile  |   1 +
 drivers/media/rc/mtk-cir.c | 326 +
 4 files changed, 362 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
 create mode 100644 drivers/media/rc/mtk-cir.c

-- 
2.7.4

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

[PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC

[sean.wang]

From: Sean Wang 

This patch adds driver for IR controller on MT7623 SoC.
and should also work on similar Mediatek SoC. Currently
testing successfully on NEC and SONY remote controller
only but it should work on others (lirc, rc-5 and rc-6).

Signed-off-by: Sean Wang 
Reviewed-by: Sean Young 
---
 drivers/media/rc/Kconfig   |  11 ++
 drivers/media/rc/Makefile  |   1 +
 drivers/media/rc/mtk-cir.c | 326 +
 3 files changed, 338 insertions(+)
 create mode 100644 drivers/media/rc/mtk-cir.c

diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 629e8ca..9228479 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -235,6 +235,17 @@ config IR_MESON
   To compile this driver as a module, choose M here: the
   module will be called meson-ir.
 
+config IR_MTK
+   tristate "Mediatek IR remote receiver"
+   depends on RC_CORE
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   ---help---
+  Say Y if you want to use the IR remote receiver available
+  on Mediatek SoCs.
+
+  To compile this driver as a module, choose M here: the
+  module will be called mtk-cir.
+
 config IR_NUVOTON
tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
depends on PNP
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 3a984ee..a78570b 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_RC_ST) += st_rc.o
 obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
 obj-$(CONFIG_IR_IMG) += img-ir/
 obj-$(CONFIG_IR_SERIAL) += serial_ir.o
+obj-$(CONFIG_IR_MTK) += mtk-cir.o
diff --git a/drivers/media/rc/mtk-cir.c b/drivers/media/rc/mtk-cir.c
new file mode 100644
index 000..f752f63
--- /dev/null
+++ b/drivers/media/rc/mtk-cir.c
@@ -0,0 +1,326 @@
+/*
+ * Driver for Mediatek IR Receiver Controller
+ *
+ * Copyright (C) 2017 Sean Wang 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MTK_IR_DEV KBUILD_MODNAME
+
+/* Register to enable PWM and IR */
+#define MTK_CONFIG_HIGH_REG   0x0c
+/* Enable IR pulse width detection */
+#define MTK_PWM_EN   BIT(13)
+/* Enable IR hardware function */
+#define MTK_IR_ENBIT(0)
+
+/* Register to setting sample period */
+#define MTK_CONFIG_LOW_REG0x10
+/* Field to set sample period */
+#define CHK_PERIOD   DIV_ROUND_CLOSEST(MTK_IR_SAMPLE,  \
+   MTK_IR_CLK_PERIOD)
+#define MTK_CHK_PERIOD(((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
+#define MTK_CHK_PERIOD_MASK  (GENMASK(20, 8))
+
+/* Register to clear state of state machine */
+#define MTK_IRCLR_REG 0x20
+/* Bit to restart IR receiving */
+#define MTK_IRCLRBIT(0)
+
+/* Register containing pulse width data */
+#define MTK_CHKDATA_REG(i)(0x88 + 4 * (i))
+#define MTK_WIDTH_MASK   (GENMASK(7, 0))
+
+/* Register to enable IR interrupt */
+#define MTK_IRINT_EN_REG  0xcc
+/* Bit to enable interrupt */
+#define MTK_IRINT_EN BIT(0)
+
+/* Register to ack IR interrupt */
+#define MTK_IRINT_CLR_REG 0xd0
+/* Bit to clear interrupt status */
+#define MTK_IRINT_CLRBIT(0)
+
+/* Maximum count of samples */
+#define MTK_MAX_SAMPLES  0xff
+/* Indicate the end of IR message */
+#define MTK_IR_END(v, p) ((v) == MTK_MAX_SAMPLES && (p) == 0)
+/* Number of registers to record the pulse width */
+#define MTK_CHKDATA_SZ   17
+/* Source clock frequency */
+#define MTK_IR_BASE_CLK  27300
+/* Frequency after IR internal divider */
+#define MTK_IR_CLK_FREQ  (MTK_IR_BASE_CLK / 4)
+/* Period for MTK_IR_CLK in ns*/
+#define MTK_IR_CLK_PERIODDIV_ROUND_CLOSEST(10ul,  \
+   MTK_IR_CLK_FREQ)
+/* Sample period in ns */
+#define MTK_IR_SAMPLE(MTK_IR_CLK_PERIOD * 0xc00)
+
+/* struct mtk_ir - This is the main datasructure for holding the state
+ * of the driver
+ * @dev:   The device pointer
+ * @rc:The rc instrance
+ * @irq:   The IRQ that we are using
+ * @base:  The mapped register i/o base
+ * @clk:   The clock that we are using
+ */
+struct 

Re: [media] uvcvideo: support for contiguous DMA buffers

[Vincent ABRIOU]

Hi Laurent,

On 01/09/2017 05:59 PM, Laurent Pinchart wrote:
> Hi Vincent,
>
> (CC'ing Nicolas)
>
> On Monday 09 Jan 2017 15:49:00 Vincent ABRIOU wrote:
>> On 01/09/2017 04:37 PM, Laurent Pinchart wrote:
>>> Hi Vincent,
>>>
>>> Thank you for the patch.
>>>
>>> On Monday 03 Oct 2016 13:27:16 Vincent Abriou wrote:
 Allow uvcvideo compatible devices to allocate their output buffers using
 contiguous DMA buffers.
>>>
>>> Why do you need this ? If it's for buffer sharing with a device that
>>> requires dma-contig, can't you allocate the buffers on the other device
>>> and import them on the UVC side ?
>>
>> Hi Laurent,
>>
>> I need this using Gstreamer simple pipeline to connect an usb webcam
>> (v4l2src) with a display (waylandsink) activating the zero copy path.
>>
>> The waylandsink plugin does not have any contiguous memory pool to
>> allocate contiguous buffer. So it is up to the upstream element, here
>> v4l2src, to provide such contiguous buffers.
>
> Isn't that a gstreamer issue ?
>

It is not a gstreamer issue. It is the way it has been decided to work.
Waylandsink accept DMABUF contiguous buffer but it does not have its own 
buffer pool.

Vincent

 Add the "allocators" module parameter option to let uvcvideo use the
 dma-contig instead of vmalloc.

 Signed-off-by: Vincent Abriou 
 ---

  Documentation/media/v4l-drivers/uvcvideo.rst | 12 
  drivers/media/usb/uvc/Kconfig|  2 ++
  drivers/media/usb/uvc/uvc_driver.c   |  3 ++-
  drivers/media/usb/uvc/uvc_queue.c| 23 ++---
  drivers/media/usb/uvc/uvcvideo.h |  4 ++--
  5 files changed, 38 insertions(+), 6 deletions(-)
>--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html