Re: [BUG] atomisp_ov2680 not initializing correctly

2017-12-19 Thread Kristian Beilke
On 12/19/2017 09:37 PM, Andy Shevchenko wrote:
> On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
>> Cc Alan and Andy.
>>
>> On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote:
>>> Dear all,
>>>
>>> I am trying to get the cameras in a Lenovo IdeaPad Miix 320 (Atom
>>> x5-Z8350 BayTrail) to work. The front camera is an ov2680. With
>>> kernel
>>> 4.14.4 and 4.15rc3 I see the following dmesg output:
> 
> It seems I forgot to send the rest of the patches I did while ago
> against AtomISP code.
> 
> It includes switch to normal DMI matching instead of the crap we have
> there right now.
> 
> WRT to the messages below it seems we have no platform data for that
> device. It needs to be added.
> 
> In any case, I have no firmware to test BayTrail hardware I have (MRD7).

My mistake here, meant to write CherryTrail, but that probably does not
make a difference for the next steps.

> The driver claims it needs:
> 
> Firmware file: shisp_2400b0_v21.bin
> Version string: irci_stable_candrpv_0415_20150521_0458
> 
> What I have is:
> 
> Version string: irci_stable_candrpv_0415_20150423_1753
> SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6  shisp_2400b0_v21.bin

From what I read here:
https://www.spinics.net/lists/linux-media/msg116382.html
They are supposedly compatible.

For CherryTrail I need shisp_2401a0_v21.bin it seems.

>>> [   21.469907] ov2680: module is from the staging directory, the
>>> quality
>>>  is unknown, you have been warned.
>>> [   21.492774] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp
>>> module
>>> subdev data.PMIC ID 1
>>> [   21.492891] acpi OVTI2680:00: Failed to find gmin variable
>>> OVTI2680:00_CamClk
>>> [   21.492974] acpi OVTI2680:00: Failed to find gmin variable
>>> OVTI2680:00_ClkSrc
>>> [   21.493090] acpi OVTI2680:00: Failed to find gmin variable
>>> OVTI2680:00_CsiPort
>>> [   21.493209] acpi OVTI2680:00: Failed to find gmin variable
>>> OVTI2680:00_CsiLanes
>>> [   21.493511] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P8SX
>>> not
>>> found, using dummy regulator
>>> [   21.493550] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V2P8SX
>>> not
>>> found, using dummy regulator
>>> [   21.493569] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P2A
>>> not
>>> found, using dummy regulator
>>> [   21.493585] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply
>>> VPROG4B
>>> not found, using dummy regulator
>>> [   21.568134] ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes:
>>> 1
>>> order: 0002
>>> [   21.568257] ov2680 i2c-OVTI2680:00: read from offset 0x300a error
>>> -121
>>> [   21.568265] ov2680 i2c-OVTI2680:00: sensor_id_high = 0x
>>> [   21.568269] ov2680 i2c-OVTI2680:00: ov2680_detect err s_config.
>>> [   21.568291] ov2680 i2c-OVTI2680:00: sensor power-gating failed
>>>
>>> Afterwards I do not get a camera device.
>>>
>>> Am I missing some firmware or dependency?
> 
> See above.
> 
>>>  Can I somehow help to improve
>>> the driver?
> 
> Yes, definitely, but first of all we need to find at least one device
> and corresponding firmware where it actually works.
> 
> For me it doesn't generate any interrupt (after huge hacking to make
> that firmware loaded and settings / platform data applied).

I guess I will apply your patches, add the firmware and see what happens.
Finding one device and firmware where it works? What do you have in
mind? Android?



smime.p7s
Description: S/MIME Cryptographic Signature


cron job: media_tree daily build: ERRORS

2017-12-19 Thread 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 Dec 20 05:00:17 CET 2017
media-tree git hash:ae49432810c5cca2143afc1445edad6582c9f270
media_build git hash:   7199b00cdae29c6f914a89ad996fcb9a133e9deb
v4l-utils git hash: 6049ea8bd64f9d78ef87ef0c2b3dc9b5de1ca4a1
gcc version:i686-linux-gcc (GCC) 7.1.0
sparse version: v0.5.0-3911-g6f737e1f
smatch version: v0.5.0-3911-g6f737e1f
host hardware:  x86_64
host os:4.13.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: ERRORS
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-blackfin-bf561: ERRORS
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: ERRORS
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: ERRORS
linux-3.8-i686: ERRORS
linux-3.9.2-i686: ERRORS
linux-3.10.1-i686: ERRORS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: ERRORS
linux-3.14.9-i686: ERRORS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: ERRORS
linux-3.18.7-i686: ERRORS
linux-3.19-i686: ERRORS
linux-4.0.9-i686: ERRORS
linux-4.1.33-i686: ERRORS
linux-4.2.8-i686: ERRORS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: OK
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: OK
linux-4.7.5-i686: OK
linux-4.8-i686: OK
linux-4.9.26-i686: OK
linux-4.10.14-i686: OK
linux-4.11-i686: OK
linux-4.12.1-i686: OK
linux-4.13-i686: OK
linux-4.14-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: ERRORS
linux-3.8-x86_64: ERRORS
linux-3.9.2-x86_64: ERRORS
linux-3.10.1-x86_64: ERRORS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: ERRORS
linux-3.14.9-x86_64: ERRORS
linux-3.15.2-x86_64: ERRORS
linux-3.16.7-x86_64: ERRORS
linux-3.17.8-x86_64: ERRORS
linux-3.18.7-x86_64: ERRORS
linux-3.19-x86_64: ERRORS
linux-4.0.9-x86_64: ERRORS
linux-4.1.33-x86_64: ERRORS
linux-4.2.8-x86_64: ERRORS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9.26-x86_64: WARNINGS
linux-4.10.14-x86_64: WARNINGS
linux-4.11-x86_64: WARNINGS
linux-4.12.1-x86_64: WARNINGS
linux-4.13-x86_64: OK
linux-4.14-x86_64: OK
apps: OK
spec-git: OK
smatch: OK

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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


Re: [PATCH v1 05/10] staging: atomisp: Remove non-ACPI leftovers

2017-12-19 Thread Dan Carpenter
On Tue, Dec 19, 2017 at 10:59:52PM +0200, Andy Shevchenko wrote:
> @@ -1147,10 +1145,8 @@ static int gc2235_probe(struct i2c_client *client)
>   if (ret)
>   gc2235_remove(client);

This error handling is probably wrong...

>  
> - if (ACPI_HANDLE(>dev))
> - ret = atomisp_register_i2c_module(>sd, gcpdev, RAW_CAMERA);
> + return atomisp_register_i2c_module(>sd, gcpdev, RAW_CAMERA);

In the end this should look something like:

ret = atomisp_register_i2c_module(>sd, gcpdev, RAW_CAMERA);
if (ret)
goto err_free_something;

return 0;

>  
> - return ret;
>  out_free:
>   v4l2_device_unregister_subdev(>sd);
>   kfree(dev);

regards,
dan carpenter



RE: [PATCH v4 07/12] [media] cxd2880: Add top level of the driver

2017-12-19 Thread Takiguchi, Yasunari
Hi, Mauro

> > +
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": %s: " fmt, __func__
> 
> Same comments as on other patches: use SPDX and dev_foo() for printing
> messages.

About printing messages pr_fmt, I also replied a comment to [PATCH v4 02/12] 
[media] cxd2880-spi: Add support for CXD2880 SPI interface.
Please refer to the comment.

Thanks,
Takiguchi


RE: [PATCH v4 06/12] [media] cxd2880: Add integration layer for the driver

2017-12-19 Thread Takiguchi, Yasunari
Hi, Mauro.

> >
> > These functions monitor the driver and watch for task completion.
> > This is part of the Sony CXD2880 DVB-T2/T tuner + demodulator driver.
> 
> If I understand well, the goal here is to have thread that would be waking
> up from time to time, right? Just use the infrastructure that the Kernel
> has for it, like a kthread, or timer_setup() & friends.
> 
> Take a look at include/linux/timer.h, and just use what's already defined.

This code is initialize process.
Therefore, it is executed only once and it will not execute other processing at 
the same time.
We think that the current implementation is enough.
What do you think?
furthermore, we will modify this code by using ktime_foo().

Thanks,
Takiguchi


RE: [PATCH v4 05/12] [media] cxd2880: Add tuner part of the driver

2017-12-19 Thread Takiguchi, Yasunari
Hi, Mauro


> > +   ret = tnr_dmd->io->read_regs(tnr_dmd->io,
> > +CXD2880_IO_TGT_SYS,
> > +0x10, data, 1);
> > +   if (ret)
> > +   return ret;
> > +   if ((data[0] & 0x01) == 0x00)
> > +   return -EBUSY;
> 
> I don't know anything about this hardware, but it sounds weird to return
> -EBUSY here, except if the hardware reached a permanent busy condition,
> and would require some sort of reset to work again.
> 
> As this is in the middle of lots of things, I *suspect* that this is
> not the case.
> 
> If I'm right, and this is just a transitory solution that could happen
> for a limited amount of time, e. g. if what's there at data[0] is a flag
> saying that the device didn't finish the last operation yet, maybe the
> best would be to do something like:
> 
>   for (i = 0; i < 10; i++) {
>   ret = tnr_dmd->io->read_regs(tnr_dmd->io,
>CXD2880_IO_TGT_SYS,
>0x10, data, 1);
>   if (ret)
>   return ret;
>   if (data[0] & 0x01)
>   break;
>   msleep(10);
>   }
>   if (!(data[0] & 0x01))
>   return -EBUSY;
> 
> > +
> > +   ret = cxd2880_io_write_multi_regs(tnr_dmd->io,
> > + CXD2880_IO_TGT_SYS,
> > + rf_init1_seq5,
> > + ARRAY_SIZE(rf_init1_seq5));
> > +   if (ret)
> > +   return ret;
> > +
> > +   usleep_range(1000, 2000);
> > +
> > +   ret = tnr_dmd->io->write_reg(tnr_dmd->io,
> > +CXD2880_IO_TGT_SYS,
> > +0x00, 0x0a);
> > +   if (ret)
> > +   return ret;
> > +   ret = tnr_dmd->io->read_regs(tnr_dmd->io,
> > +CXD2880_IO_TGT_SYS,
> > +0x11, data, 1);
> > +   if (ret)
> > +   return ret;
> > +   if ((data[0] & 0x01) == 0x00)
> > +   return -EBUSY;
> 
> Same here and on similar places.

As the hardware specification, It is abnormal if certain register doesn't 
become 1 even if sleep time passes.
Perhaps it should not be return EBUSY.
We will reconsider error code.

Thanks,
Takiguchi


RE: [PATCH v4 02/12] [media] cxd2880-spi: Add support for CXD2880 SPI interface

2017-12-19 Thread Takiguchi, Yasunari
Hi, Mauro.

> > +
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": %s: " fmt, __func__
> 
> It would be better to use dev_foo() debug macros instead of
> pr_foo() ones.

I got comment for this previous version patch as below
--
The best would be to se dev_err() & friends for printing messages, 
as they print the device's name as filled at struct device.
If you don't use, please add a define that will print the name at the logs, 
like:

  #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

either at the begining of the driver or at some header file.

Btw, I'm noticing that you're also using dev_err() on other places of the code. 
Please standardize. OK, on a few places, you may still need to use pr_err(), 
if you need to print a message before initializing struct device, but I suspect 
that you can init
--

You pointed out here before. Because dev_foo () and pr_foo () were mixed.
We standardize with pr_foo() because the logs is outputted before getting the 
device structure.
Is it better to use dev_foo() where we can use it?


> > +static int cxd2880_stop_feed(struct dvb_demux_feed *feed) {
> > +   int i = 0;
> > +   int ret;
> > +   struct dvb_demux *demux = NULL;
> > +   struct cxd2880_dvb_spi *dvb_spi = NULL;
> > +
> > +   if (!feed) {
> > +   pr_err("invalid arg\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   demux = feed->demux;
> > +   if (!demux) {
> > +   pr_err("feed->demux is NULL\n");
> > +   return -EINVAL;
> > +   }
> > +   dvb_spi = demux->priv;
> > +
> > +   if (!dvb_spi->feed_count) {
> > +   pr_err("no feed is started\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (feed->pid == 0x2000) {
> > +   /*
> > +* Special PID case.
> > +* Number of 0x2000 feed request was stored
> > +* in dvb_spi->all_pid_feed_count.
> > +*/
> > +   if (dvb_spi->all_pid_feed_count <= 0) {
> > +   pr_err("PID %d not found.\n", feed->pid);
> > +   return -EINVAL;
> > +   }
> > +   dvb_spi->all_pid_feed_count--;
> > +   } else {
> > +   struct cxd2880_pid_filter_config cfgtmp;
> > +
> > +   cfgtmp = dvb_spi->filter_config;
> > +
> > +   for (i = 0; i < CXD2880_MAX_FILTER_SIZE; i++) {
> > +   if (feed->pid == cfgtmp.pid_config[i].pid &&
> > +   cfgtmp.pid_config[i].is_enable != 0) {
> > +   cfgtmp.pid_config[i].is_enable = 0;
> > +   cfgtmp.pid_config[i].pid = 0;
> > +   pr_debug("removed PID %d from #%d\n",
> > +feed->pid, i);
> > +   break;
> > +   }
> > +   }
> > +   dvb_spi->filter_config = cfgtmp;
> > +
> > +   if (i == CXD2880_MAX_FILTER_SIZE) {
> > +   pr_err("PID %d not found\n", feed->pid);
> > +   return -EINVAL;
> > +   }
> > +   }
> > +
> > +   ret = cxd2880_update_pid_filter(dvb_spi,
> > +   _spi->filter_config,
> > +   dvb_spi->all_pid_feed_count >
> 0);
> > +   dvb_spi->feed_count--;
> > +
> > +   if (dvb_spi->feed_count == 0) {
> > +   int ret_stop = 0;
> > +
> > +   ret_stop =
> kthread_stop(dvb_spi->cxd2880_ts_read_thread);
> > +   if (ret_stop) {
> > +   pr_err("'kthread_stop failed. (%d)\n",
> ret_stop);
> > +   ret = ret_stop;
> > +   }
> > +   kfree(dvb_spi->ts_buf);
> > +   dvb_spi->ts_buf = NULL;
> > +   }
> > +
> > +   pr_debug("stop feed ok.(count %d)\n", dvb_spi->feed_count);
> > +
> > +   return ret;
> > +}
> 
> I have the feeling that I've seen the code above before at the dvb core.
> Any reason why don't use the already-existing code at dvb_demux.c &
> friends?

The CXD2880 HW PID filter is used to decrease the amount of TS data transferred 
via limited bit rate SPI interface.

Thanks,
Takiguchi


Waiting For Your Urgent Replay.........

2017-12-19 Thread Mr.Akram Mohamed
My Dear,

How are you together with your family? I hope all is well. Considering
the fact, I did not know you in person or even have seen you before
but due to the true revelation that I should share this lucrative
opportunity with you, I have no choice other than to contact you. So,
kindly consider this message essential and confidential.

first and foremost I have to introduce myself to you I am Mr.Akram
Mohamed, from Burkina Faso in west Africa, the Audit and Account
Manager BANK OF AFRICA (BOA) in Ouagadougou Burkina Faso west Africa.

I had the intent to contact you over transfer of fund worth the sum of
Six million two hundred thousand u.s dollars. (Us$6.2m) for the
betterment of our life, I agree that 40% of the total amount will be
for you and 60% for me.

I need your urgent response on assurance of trust that you will not
deny my share when once the fund is transfer to your personal bank
account.

Your urgently responses is needed through this email
address:mrakram.m...@gmail.com reply with your information as I stated
it bellow once I receive your information I will give you more details
as application and how you will apply to our bank on how to transfer
the fund into your bank account.

(1) Full names:

(2) private phone number:

(3) occupation:

Make sure you keep this transaction as top secret and make it
confidential till we receive the fund into your bank account that you
will provide to our bank. Don't disclose it to anybody, because the
secret of this transaction is as well as the success of it.

I look forward to hear from you call me immediately as soon as you
receive this message or email me urgent.

In sincerity,
Mr.Akram Mohamed


Congratulation Again

2017-12-19 Thread Friedrich Mayrhofer

This is the second time i am sending you this mail.

I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for 
more details.

Regards.
Friedrich Mayrhofer


[PATCH v1 07/10] staging: atomisp: Remove redundant PCI code

2017-12-19 Thread Andy Shevchenko
There is no need to keep a reference to PCI root bridge.

Signed-off-by: Andy Shevchenko 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h | 1 -
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 8 
 2 files changed, 9 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
index 52a6f8002048..dc476a3dd271 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_internal.h
@@ -227,7 +227,6 @@ struct atomisp_device {
struct media_device media_dev;
struct atomisp_platform_data *pdata;
void *mmu_l1_base;
-   struct pci_dev *pci_root;
const struct firmware *firmware;
 
struct pm_qos_request pm_qos;
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 7a9efc6847ca..548e00e7d67b 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -1210,11 +1210,6 @@ static int atomisp_pci_probe(struct pci_dev *dev,
isp->pdev = dev;
isp->dev = >dev;
isp->sw_contex.power_state = ATOM_ISP_POWER_UP;
-   isp->pci_root = pci_get_bus_and_slot(0, 0);
-   if (!isp->pci_root) {
-   dev_err(>dev, "Unable to find PCI host\n");
-   return -ENODEV;
-   }
isp->saved_regs.ispmmadr = start;
 
rt_mutex_init(>mutex);
@@ -1494,7 +1489,6 @@ static int atomisp_pci_probe(struct pci_dev *dev,
/* Address later when we worry about the ...field chips */
if (IS_ENABLED(CONFIG_PM) && atomisp_mrfld_power_down(isp))
dev_err(>dev, "Failed to switch off ISP\n");
-   pci_dev_put(isp->pci_root);
return err;
 }
 
@@ -1515,8 +1509,6 @@ static void atomisp_pci_remove(struct pci_dev *dev)
pm_qos_remove_request(>pm_qos);
 
atomisp_msi_irq_uninit(isp, dev);
-   pci_dev_put(isp->pci_root);
-
atomisp_unregister_entities(isp);
 
destroy_workqueue(isp->wdt_work_queue);
-- 
2.15.1



[PATCH v1 01/10] staging: atomisp: Don't leak GPIO resources if clk_get() failed

2017-12-19 Thread Andy Shevchenko
In case devm_clk_get() call fails the previously requested GPIOs are
left requested.

Fix this by moving GPIO request code after devm_clk_get() call.

Signed-off-by: Andy Shevchenko 
---
 .../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index bf9f34b7ad72..a5d0dd88a8bc 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -322,8 +322,6 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
VLV2_CLK_PLL_19P2MHZ);
gmin_subdevs[i].csi_port = gmin_get_var_int(dev, "CsiPort", 0);
gmin_subdevs[i].csi_lanes = gmin_get_var_int(dev, "CsiLanes", 1);
-   gmin_subdevs[i].gpio0 = gpiod_get_index(dev, NULL, 0, GPIOD_OUT_LOW);
-   gmin_subdevs[i].gpio1 = gpiod_get_index(dev, NULL, 1, GPIOD_OUT_LOW);
 
/* get PMC clock with clock framework */
snprintf(gmin_pmc_clk_name,
@@ -356,9 +354,11 @@ static struct gmin_subdev *gmin_subdev_add(struct 
v4l2_subdev *subdev)
if (!ret)
clk_disable_unprepare(gmin_subdevs[i].pmc_clk);
 
+   gmin_subdevs[i].gpio0 = gpiod_get_index(dev, NULL, 0, GPIOD_OUT_LOW);
if (IS_ERR(gmin_subdevs[i].gpio0))
gmin_subdevs[i].gpio0 = NULL;
 
+   gmin_subdevs[i].gpio1 = gpiod_get_index(dev, NULL, 1, GPIOD_OUT_LOW);
if (IS_ERR(gmin_subdevs[i].gpio1))
gmin_subdevs[i].gpio1 = NULL;
 
-- 
2.15.1



[PATCH v1 08/10] staging: atomisp: Unexport local function

2017-12-19 Thread Andy Shevchenko
There is no need to export function which is only used once in
the same module where it's defined.

Signed-off-by: Andy Shevchenko 
---
 drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h  | 1 -
 .../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c | 5 ++---
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h 
b/drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h
index 7e3ca12dd4e9..c52c56a17e17 100644
--- a/drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h
+++ b/drivers/staging/media/atomisp/include/linux/atomisp_gmin_platform.h
@@ -23,7 +23,6 @@ int atomisp_register_i2c_module(struct v4l2_subdev *subdev,
 struct v4l2_subdev *atomisp_gmin_find_subdev(struct i2c_adapter *adapter,
 struct i2c_board_info *board_info);
 int atomisp_gmin_remove_subdev(struct v4l2_subdev *sd);
-int gmin_get_config_var(struct device *dev, const char *var, char *out, size_t 
*out_len);
 int gmin_get_var_int(struct device *dev, const char *var, int def);
 int camera_sensor_csi(struct v4l2_subdev *sd, u32 port,
   u32 lanes, u32 format, u32 bayer_order, int flag);
diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 8dcec0e780a1..0f859bb714bf 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -608,8 +608,8 @@ EXPORT_SYMBOL_GPL(atomisp_gmin_register_vcm_control);
  * argument should be a device with an ACPI companion, as all
  * configuration is based on firmware ID.
  */
-int gmin_get_config_var(struct device *dev, const char *var, char *out,
-   size_t *out_len)
+static int gmin_get_config_var(struct device *dev, const char *var,
+  char *out, size_t *out_len)
 {
char var8[CFG_VAR_NAME_MAX];
efi_char16_t var16[CFG_VAR_NAME_MAX];
@@ -691,7 +691,6 @@ int gmin_get_config_var(struct device *dev, const char 
*var, char *out,
 
return ret;
 }
-EXPORT_SYMBOL_GPL(gmin_get_config_var);
 
 int gmin_get_var_int(struct device *dev, const char *var, int def)
 {
-- 
2.15.1



[PATCH v1 09/10] staging: atomisp: Use standard DMI match table

2017-12-19 Thread Andy Shevchenko
The traditional pattern is to use DMI matching table and provide a
corresponding driver_data in it.

Convert driver to use DMI matching table.

Signed-off-by: Andy Shevchenko 
---
 .../platform/intel-mid/atomisp_gmin_platform.c | 109 +
 1 file changed, 70 insertions(+), 39 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 0f859bb714bf..8408a58ed764 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -209,7 +209,7 @@ struct gmin_cfg_var {
const char *name, *val;
 };
 
-static const struct gmin_cfg_var ffrd8_vars[] = {
+static struct gmin_cfg_var ffrd8_vars[] = {
{ "INTCF1B:00_ImxId","0x134" },
{ "INTCF1B:00_CsiPort",  "1" },
{ "INTCF1B:00_CsiLanes", "4" },
@@ -220,14 +220,14 @@ static const struct gmin_cfg_var ffrd8_vars[] = {
 /* Cribbed from MCG defaults in the mt9m114 driver, not actually verified
  * vs. T100 hardware
  */
-static const struct gmin_cfg_var t100_vars[] = {
+static struct gmin_cfg_var t100_vars[] = {
{ "INT33F0:00_CsiPort",  "0" },
{ "INT33F0:00_CsiLanes", "1" },
{ "INT33F0:00_CamClk",   "1" },
{},
 };
 
-static const struct gmin_cfg_var mrd7_vars[] = {
+static struct gmin_cfg_var mrd7_vars[] = {
{"INT33F8:00_CamType", "1"},
{"INT33F8:00_CsiPort", "1"},
{"INT33F8:00_CsiLanes", "2"},
@@ -243,7 +243,7 @@ static const struct gmin_cfg_var mrd7_vars[] = {
{},
 };
 
-static const struct gmin_cfg_var ecs7_vars[] = {
+static struct gmin_cfg_var ecs7_vars[] = {
{"INT33BE:00_CsiPort", "1"},
{"INT33BE:00_CsiLanes", "2"},
{"INT33BE:00_CsiFmt", "13"},
@@ -258,8 +258,7 @@ static const struct gmin_cfg_var ecs7_vars[] = {
{},
 };
 
-
-static const struct gmin_cfg_var i8880_vars[] = {
+static struct gmin_cfg_var i8880_vars[] = {
{"XXOV2680:00_CsiPort", "1"},
{"XXOV2680:00_CsiLanes", "1"},
{"XXOV2680:00_CamClk", "0"},
@@ -269,18 +268,45 @@ static const struct gmin_cfg_var i8880_vars[] = {
{},
 };
 
-static const struct {
-   const char *dmi_board_name;
-   const struct gmin_cfg_var *vars;
-} hard_vars[] = {
-   { "BYT-T FFD8", ffrd8_vars },
-   { "T100TA", t100_vars },
-   { "MRD7", mrd7_vars },
-   { "ST70408", ecs7_vars },
-   { "VTA0803", i8880_vars },
+static const struct dmi_system_id gmin_vars[] = {
+   {
+   .ident = "BYT-T FFD8",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
+   },
+   .driver_data = ffrd8_vars,
+   },
+   {
+   .ident = "T100TA",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "T100TA"),
+   },
+   .driver_data = t100_vars,
+   },
+   {
+   .ident = "MRD7",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "MRD7"),
+   },
+   .driver_data = mrd7_vars,
+   },
+   {
+   .ident = "ST70408",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "ST70408"),
+   },
+   .driver_data = ecs7_vars,
+   },
+   {
+   .ident = "VTA0803",
+   .matches = {
+   DMI_MATCH(DMI_BOARD_NAME, "VTA0803"),
+   },
+   .driver_data = i8880_vars,
+   },
+   {}
 };
 
-
 #define GMIN_CFG_VAR_EFI_GUID EFI_GUID(0xecb54cd9, 0xe5ae, 0x4fdc, \
   0xa9, 0x71, 0xe8, 0x77, \
   0x75, 0x60, 0x68, 0xf7)
@@ -604,6 +630,29 @@ int atomisp_gmin_register_vcm_control(struct 
camera_vcm_control *vcmCtrl)
 }
 EXPORT_SYMBOL_GPL(atomisp_gmin_register_vcm_control);
 
+static int gmin_get_hardcoded_var(struct gmin_cfg_var *varlist,
+ const char *var8, char *out, size_t *out_len)
+{
+   struct gmin_cfg_var *gv;
+
+   for (gv = varlist; gv->name; gv++) {
+   size_t vl;
+
+   if (strcmp(var8, gv->name))
+   continue;
+
+   vl = strlen(gv->val);
+   if (vl > *out_len - 1)
+   return -ENOSPC;
+
+   strcpy(out, gv->val);
+   *out_len = vl;
+   return 0;
+   }
+
+   return -EINVAL;
+}
+
 /* Retrieves a device-specific configuration variable.  The dev
  * argument should be a device with an ACPI companion, as all
  * configuration is based on firmware ID.
@@ -614,7 +663,8 @@ static int gmin_get_config_var(struct device *dev, const 
char *var,
char var8[CFG_VAR_NAME_MAX];
efi_char16_t 

[PATCH v1 04/10] staging: atomisp: Disable custom format for now

2017-12-19 Thread Andy Shevchenko
Custom video format 'M101' is not supported in upstream and as a result
user will get ugly warning:

 Unknown pixelformat 0x3130314d
 [ cut here ]
 WARNING: CPU: 3 PID: 1574 at drivers/media/v4l2-core/v4l2-ioctl.c:1291 
v4l_enum_fmt+0xcf1/0x13a0 [videodev]

Signed-off-by: Andy Shevchenko 
---
 drivers/staging/media/atomisp/include/linux/atomisp.h   | 2 ++
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c  | 5 -
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c | 2 ++
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/include/linux/atomisp.h 
b/drivers/staging/media/atomisp/include/linux/atomisp.h
index 15fa5679bae7..ebe193ba3871 100644
--- a/drivers/staging/media/atomisp/include/linux/atomisp.h
+++ b/drivers/staging/media/atomisp/include/linux/atomisp.h
@@ -68,7 +68,9 @@
 #define V4L2_MBUS_FMT_CUSTOM_RGB32 0x800a
 
 /* Custom media bus format for M10MO RAW capture */
+#if 0
 #define V4L2_MBUS_FMT_CUSTOM_M10MO_RAW 0x800b
+#endif
 
 /* Configuration used by Bayer noise reduction and YCC noise reduction */
 struct atomisp_nr_config {
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
index 339b5d31e1f1..5c84dd63778e 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_ioctl.c
@@ -501,7 +501,9 @@ const struct atomisp_format_bridge atomisp_output_fmts[] = {
.mbus_code = MEDIA_BUS_FMT_JPEG_1X8,
.sh_fmt = CSS_FRAME_FORMAT_BINARY_8,
.description = "JPEG"
-   }, {
+   },
+#if 0
+   {
/* This is a custom format being used by M10MO to send the RAW data */
.pixelformat = V4L2_PIX_FMT_CUSTOM_M10MO_RAW,
.depth = 8,
@@ -509,6 +511,7 @@ const struct atomisp_format_bridge atomisp_output_fmts[] = {
.sh_fmt = CSS_FRAME_FORMAT_BINARY_8,
.description = "Custom RAW for M10MO"
},
+#endif
 };
 
 const struct atomisp_format_bridge *atomisp_get_format_bridge(
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
index 70b53988553c..f3e18d627b0a 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_subdev.c
@@ -48,7 +48,9 @@ const struct atomisp_in_fmt_conv atomisp_in_fmt_conv[] = {
{ V4L2_MBUS_FMT_CUSTOM_NV12, 12, 12, CSS_FRAME_FORMAT_NV12, 0, 
CSS_FRAME_FORMAT_NV12 },
{ V4L2_MBUS_FMT_CUSTOM_NV21, 12, 12, CSS_FRAME_FORMAT_NV21, 0, 
CSS_FRAME_FORMAT_NV21 },
{ V4L2_MBUS_FMT_CUSTOM_YUV420, 12, 12, 
ATOMISP_INPUT_FORMAT_YUV420_8_LEGACY, 0, IA_CSS_STREAM_FORMAT_YUV420_8_LEGACY },
+#if 0
{ V4L2_MBUS_FMT_CUSTOM_M10MO_RAW, 8, 8, CSS_FRAME_FORMAT_BINARY_8, 0, 
IA_CSS_STREAM_FORMAT_BINARY_8 },
+#endif
/* no valid V4L2 MBUS code for metadata format, so leave it 0. */
{ 0, 0, 0, ATOMISP_INPUT_FORMAT_EMBEDDED, 0, 
IA_CSS_STREAM_FORMAT_EMBEDDED },
{}
-- 
2.15.1



[PATCH v1 10/10] staging: atomisp: Fix DMI matching entry for MRD7

2017-12-19 Thread Andy Shevchenko
MRD7 board has in particular

Base Board Information
Manufacturer: Intel Corp.
Product Name: TABLET
Version: MRD 7

Fix the DMI matching entry for it.

Signed-off-by: Andy Shevchenko 
---
 .../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c   | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 8408a58ed764..d8b7183db252 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -286,7 +286,8 @@ static const struct dmi_system_id gmin_vars[] = {
{
.ident = "MRD7",
.matches = {
-   DMI_MATCH(DMI_BOARD_NAME, "MRD7"),
+   DMI_MATCH(DMI_BOARD_NAME, "TABLET"),
+   DMI_MATCH(DMI_BOARD_VERSION, "MRD 7"),
},
.driver_data = mrd7_vars,
},
-- 
2.15.1



[PATCH v1 03/10] staging: atomisp: lm3554: Fix control values

2017-12-19 Thread Andy Shevchenko
Driver fails to initialize due to insane settings in the
control init array.

Fix this by moving to sanity.

Signed-off-by: Andy Shevchenko 
---
 drivers/staging/media/atomisp/i2c/atomisp-lm3554.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c 
b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
index 4fd9f538ac95..974b6ff50c7a 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
@@ -562,10 +562,10 @@ static const struct v4l2_ctrl_config lm3554_controls[] = {
{
 .ops = _ops,
 .id = V4L2_CID_FLASH_STATUS,
-.type = V4L2_CTRL_TYPE_BOOLEAN,
+.type = V4L2_CTRL_TYPE_INTEGER,
 .name = "Flash Status",
-.min = 0,
-.max = 100,
+.min = ATOMISP_FLASH_STATUS_OK,
+.max = ATOMISP_FLASH_STATUS_TIMEOUT,
 .step = 1,
 .def = ATOMISP_FLASH_STATUS_OK,
 .flags = 0,
@@ -574,10 +574,10 @@ static const struct v4l2_ctrl_config lm3554_controls[] = {
{
 .ops = _ops,
 .id = V4L2_CID_FLASH_STATUS_REGISTER,
-.type = V4L2_CTRL_TYPE_BOOLEAN,
+.type = V4L2_CTRL_TYPE_INTEGER,
 .name = "Flash Status Register",
 .min = 0,
-.max = 100,
+.max = 255,
 .step = 1,
 .def = 0,
 .flags = 0,
-- 
2.15.1



[PATCH v1 05/10] staging: atomisp: Remove non-ACPI leftovers

2017-12-19 Thread Andy Shevchenko
Since all drivers are solely requiring ACPI enumeration, there is no
need to additionally check for legacy platform data or ACPI handle.

Remove leftovers from the sensors and platform code.

Signed-off-by: Andy Shevchenko 
---
 drivers/staging/media/atomisp/i2c/atomisp-gc0310.c | 10 ++---
 drivers/staging/media/atomisp/i2c/atomisp-gc2235.c |  8 +---
 drivers/staging/media/atomisp/i2c/atomisp-lm3554.c | 28 --
 .../staging/media/atomisp/i2c/atomisp-mt9m114.c|  8 ++--
 drivers/staging/media/atomisp/i2c/atomisp-ov2680.c | 10 ++---
 drivers/staging/media/atomisp/i2c/atomisp-ov2722.c | 17 ++---
 .../media/atomisp/i2c/ov5693/atomisp-ov5693.c  | 12 ++
 drivers/staging/media/atomisp/i2c/ov8858.c | 43 +++---
 .../platform/intel-mid/atomisp_gmin_platform.c |  6 +--
 9 files changed, 49 insertions(+), 93 deletions(-)

diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c 
b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
index e70d8afcc229..61b7598469eb 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-gc0310.c
@@ -1370,13 +1370,9 @@ static int gc0310_probe(struct i2c_client *client)
dev->fmt_idx = 0;
v4l2_i2c_subdev_init(&(dev->sd), client, _ops);
 
-   if (ACPI_COMPANION(>dev))
-   pdata = gmin_camera_platform_data(>sd,
- ATOMISP_INPUT_FORMAT_RAW_8,
- atomisp_bayer_order_grbg);
-   else
-   pdata = client->dev.platform_data;
-
+   pdata = gmin_camera_platform_data(>sd,
+ ATOMISP_INPUT_FORMAT_RAW_8,
+ atomisp_bayer_order_grbg);
if (!pdata) {
ret = -EINVAL;
goto out_free;
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c 
b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
index 85da5fe24033..d8de46da64ae 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-gc2235.c
@@ -1108,9 +1108,7 @@ static int gc2235_probe(struct i2c_client *client)
dev->fmt_idx = 0;
v4l2_i2c_subdev_init(&(dev->sd), client, _ops);
 
-   gcpdev = client->dev.platform_data;
-   if (ACPI_COMPANION(>dev))
-   gcpdev = gmin_camera_platform_data(>sd,
+   gcpdev = gmin_camera_platform_data(>sd,
   ATOMISP_INPUT_FORMAT_RAW_10,
   atomisp_bayer_order_grbg);
 
@@ -1147,10 +1145,8 @@ static int gc2235_probe(struct i2c_client *client)
if (ret)
gc2235_remove(client);
 
-   if (ACPI_HANDLE(>dev))
-   ret = atomisp_register_i2c_module(>sd, gcpdev, RAW_CAMERA);
+   return atomisp_register_i2c_module(>sd, gcpdev, RAW_CAMERA);
 
-   return ret;
 out_free:
v4l2_device_unregister_subdev(>sd);
kfree(dev);
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c 
b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
index 974b6ff50c7a..7098bf317f16 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-lm3554.c
@@ -824,22 +824,15 @@ static void *lm3554_platform_data_func(struct i2c_client 
*client)
 {
static struct lm3554_platform_data platform_data;
 
-   if (ACPI_COMPANION(>dev)) {
-   platform_data.gpio_reset =
-   desc_to_gpio(gpiod_get_index(&(client->dev),
+   platform_data.gpio_reset =
+   desc_to_gpio(gpiod_get_index(>dev,
 NULL, 2, GPIOD_OUT_LOW));
-   platform_data.gpio_strobe =
-   desc_to_gpio(gpiod_get_index(&(client->dev),
+   platform_data.gpio_strobe =
+   desc_to_gpio(gpiod_get_index(>dev,
 NULL, 0, GPIOD_OUT_LOW));
-   platform_data.gpio_torch =
-   desc_to_gpio(gpiod_get_index(&(client->dev),
+   platform_data.gpio_torch =
+   desc_to_gpio(gpiod_get_index(>dev,
 NULL, 1, GPIOD_OUT_LOW));
-   } else {
-   platform_data.gpio_reset = -1;
-   platform_data.gpio_strobe = -1;
-   platform_data.gpio_torch = -1;
-   }
-
dev_info(>dev, "camera pdata: lm3554: reset: %d strobe %d torch 
%d\n",
platform_data.gpio_reset, platform_data.gpio_strobe,
platform_data.gpio_torch);
@@ -868,10 +861,7 @@ static int lm3554_probe(struct i2c_client *client)
if (!flash)
return -ENOMEM;
 
-   flash->pdata = client->dev.platform_data;
-
-   if (!flash->pdata || ACPI_COMPANION(>dev))
-   flash->pdata = 

[PATCH v1 02/10] staging: atomisp: Remove duplicate NULL-check

2017-12-19 Thread Andy Shevchenko
GPIO framework checks for NULL pointer when gpiod_set_value() is called.

Signed-off-by: Andy Shevchenko 
---
 .../staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index a5d0dd88a8bc..8fb5147531a5 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -394,7 +394,7 @@ static int gmin_gpio0_ctrl(struct v4l2_subdev *subdev, int 
on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
 
-   if (gs && gs->gpio0) {
+   if (gs) {
gpiod_set_value(gs->gpio0, on);
return 0;
}
@@ -405,7 +405,7 @@ static int gmin_gpio1_ctrl(struct v4l2_subdev *subdev, int 
on)
 {
struct gmin_subdev *gs = find_gmin_subdev(subdev);
 
-   if (gs && gs->gpio1) {
+   if (gs) {
gpiod_set_value(gs->gpio1, on);
return 0;
}
-- 
2.15.1



[PATCH v1 06/10] staging: atomisp: Switch to use struct device_driver directly

2017-12-19 Thread Andy Shevchenko
In a preparation of split PCI glue driver from core part, convert
the driver to use more generic struct device_driver.

Signed-off-by: Andy Shevchenko 
---
 .../staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c  | 17 -
 .../staging/media/atomisp/pci/atomisp2/atomisp_drvfs.h  |  5 ++---
 .../staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c   |  4 +---
 3 files changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
index 7129b88456cb..ceedb82b6beb 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
@@ -15,9 +15,9 @@
  *
  */
 
+#include 
 #include 
 #include 
-#include 
 
 #include "atomisp_compat.h"
 #include "atomisp_internal.h"
@@ -33,7 +33,7 @@
  *bit 2: memory statistic
 */
 struct _iunit_debug {
-   struct pci_driver   *drv;
+   struct device_driver*drv;
struct atomisp_device   *isp;
unsigned intdbglvl;
unsigned intdbgfun;
@@ -164,26 +164,25 @@ static const struct driver_attribute iunit_drvfs_attrs[] 
= {
__ATTR(dbgopt, 0644, iunit_dbgopt_show, iunit_dbgopt_store),
 };
 
-static int iunit_drvfs_create_files(struct pci_driver *drv)
+static int iunit_drvfs_create_files(struct device_driver *drv)
 {
int i, ret = 0;
 
for (i = 0; i < ARRAY_SIZE(iunit_drvfs_attrs); i++)
-   ret |= driver_create_file(&(drv->driver),
-   _drvfs_attrs[i]);
+   ret |= driver_create_file(drv, _drvfs_attrs[i]);
 
return ret;
 }
 
-static void iunit_drvfs_remove_files(struct pci_driver *drv)
+static void iunit_drvfs_remove_files(struct device_driver *drv)
 {
int i;
 
for (i = 0; i < ARRAY_SIZE(iunit_drvfs_attrs); i++)
-   driver_remove_file(&(drv->driver), _drvfs_attrs[i]);
+   driver_remove_file(drv, _drvfs_attrs[i]);
 }
 
-int atomisp_drvfs_init(struct pci_driver *drv, struct atomisp_device *isp)
+int atomisp_drvfs_init(struct device_driver *drv, struct atomisp_device *isp)
 {
int ret;
 
@@ -193,7 +192,7 @@ int atomisp_drvfs_init(struct pci_driver *drv, struct 
atomisp_device *isp)
ret = iunit_drvfs_create_files(iunit_debug.drv);
if (ret) {
dev_err(atomisp_dev, "drvfs_create_files error: %d\n", ret);
-   iunit_drvfs_remove_files(drv);
+   iunit_drvfs_remove_files(iunit_debug.drv);
}
 
return ret;
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.h 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.h
index b91bfef21639..7c99240d107a 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.h
@@ -18,8 +18,7 @@
 #ifndef__ATOMISP_DRVFS_H__
 #define__ATOMISP_DRVFS_H__
 
-extern int atomisp_drvfs_init(struct pci_driver *drv, struct atomisp_device
-   *isp);
-extern void atomisp_drvfs_exit(void);
+int atomisp_drvfs_init(struct device_driver *drv, struct atomisp_device *isp);
+void atomisp_drvfs_exit(void);
 
 #endif /* __ATOMISP_DRVFS_H__ */
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 3c260f8b52e2..7a9efc6847ca 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -1152,8 +1152,6 @@ static int init_atomisp_wdts(struct atomisp_device *isp)
return err;
 }
 
-static struct pci_driver atomisp_pci_driver;
-
 #define ATOM_ISP_PCI_BAR   0
 
 static int atomisp_pci_probe(struct pci_dev *dev,
@@ -1451,7 +1449,7 @@ static int atomisp_pci_probe(struct pci_dev *dev,
isp->firmware = NULL;
isp->css_env.isp_css_fw.data = NULL;
 
-   atomisp_drvfs_init(_pci_driver, isp);
+   atomisp_drvfs_init(>driver->driver, isp);
 
return 0;
 
-- 
2.15.1



Re: [BUG] atomisp_ov2680 not initializing correctly

2017-12-19 Thread Andy Shevchenko
On Tue, 2017-12-19 at 14:00 +0200, Sakari Ailus wrote:
> Cc Alan and Andy.
> 
> On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote:
> > Dear all,
> > 
> > I am trying to get the cameras in a Lenovo IdeaPad Miix 320 (Atom
> > x5-Z8350 BayTrail) to work. The front camera is an ov2680. With
> > kernel
> > 4.14.4 and 4.15rc3 I see the following dmesg output:

It seems I forgot to send the rest of the patches I did while ago
against AtomISP code.

It includes switch to normal DMI matching instead of the crap we have
there right now.

WRT to the messages below it seems we have no platform data for that
device. It needs to be added.

In any case, I have no firmware to test BayTrail hardware I have (MRD7).

The driver claims it needs:

Firmware file: shisp_2400b0_v21.bin
Version string: irci_stable_candrpv_0415_20150521_0458

What I have is:

Version string: irci_stable_candrpv_0415_20150423_1753
SHA1: 548d26a9b5daedbeb59a46ea1da69757d92cd4d6  shisp_2400b0_v21.bin

> > [   21.469907] ov2680: module is from the staging directory, the
> > quality
> >  is unknown, you have been warned.
> > [   21.492774] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp
> > module
> > subdev data.PMIC ID 1
> > [   21.492891] acpi OVTI2680:00: Failed to find gmin variable
> > OVTI2680:00_CamClk
> > [   21.492974] acpi OVTI2680:00: Failed to find gmin variable
> > OVTI2680:00_ClkSrc
> > [   21.493090] acpi OVTI2680:00: Failed to find gmin variable
> > OVTI2680:00_CsiPort
> > [   21.493209] acpi OVTI2680:00: Failed to find gmin variable
> > OVTI2680:00_CsiLanes
> > [   21.493511] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P8SX
> > not
> > found, using dummy regulator
> > [   21.493550] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V2P8SX
> > not
> > found, using dummy regulator
> > [   21.493569] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P2A
> > not
> > found, using dummy regulator
> > [   21.493585] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply
> > VPROG4B
> > not found, using dummy regulator
> > [   21.568134] ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes:
> > 1
> > order: 0002
> > [   21.568257] ov2680 i2c-OVTI2680:00: read from offset 0x300a error
> > -121
> > [   21.568265] ov2680 i2c-OVTI2680:00: sensor_id_high = 0x
> > [   21.568269] ov2680 i2c-OVTI2680:00: ov2680_detect err s_config.
> > [   21.568291] ov2680 i2c-OVTI2680:00: sensor power-gating failed
> > 
> > Afterwards I do not get a camera device.
> > 
> > Am I missing some firmware or dependency?

See above.

> >  Can I somehow help to improve
> > the driver?

Yes, definitely, but first of all we need to find at least one device
and corresponding firmware where it actually works.

For me it doesn't generate any interrupt (after huge hacking to make
that firmware loaded and settings / platform data applied).

-- 
Andy Shevchenko 
Intel Finland Oy


Re: [-next PATCH 0/4] sysfs and DEVICE_ATTR_

2017-12-19 Thread Corey Minyard

On 12/19/2017 12:15 PM, Joe Perches wrote:

  drivers/char/ipmi/ipmi_msghandler.c| 17 +++---


For ipmi:

Acked-by: Corey Minyard 



Re: [PATCH 2/8] media: v4l2-ioctl.h: convert debug into an enum of bits

2017-12-19 Thread Mauro Carvalho Chehab
Em Tue, 19 Dec 2017 19:17:12 +0200
Laurent Pinchart  escreveu:

> Hi Mauro,
> 
> On Tuesday, 19 December 2017 17:37:58 EET Mauro Carvalho Chehab wrote:
> > Em Tue, 19 Dec 2017 16:12:35 +0200 Sakari Ailus escreveu:  
> > > On Tue, Dec 19, 2017 at 04:02:02PM +0200, Laurent Pinchart wrote:  
> > >> And furthermore using enum types in the uAPI is a bad idea as the enum
> > >> size is architecture-dependent. That's why we use integer types in
> > >> structures used as ioctl arguments.  
> > > 
> > > I guess we have an argeement on that, enums are a no-go for uAPI, for
> > > reasons not related to the topic at hand.  
> > 
> > Huh? We're not talking about uAPI. This is kAPI. Using enums there is OK.  
> 
> Sure, there's no disagreement about that. 

> The point was that, as both uAPI and  kAPI should be documented,

No disagreement here...

> and we can't use enums for uAPI, 

Err... we actually do use enums on uAPI... videodev2.h is full of it.
What we can't do is to use enums on ioctls. So, all such enums are
replaced by u32 at the ioctl calls.

Ok, this is not elegant (and it happened for historic reasons - we're
now avoiding it at all costs), but that's the way it is.

The fact is - for uAPI - we have enums and defines, and both are
documented.

> we need a way to document non-enum types,

We have already a way to document all uAPI data structures, including
enums and defines.

> which we could then use to document the kAPI the same way.

Let's not mix subjects. This patch series is all about kAPI.

Specifically, we're talking about this change:

-/* Just log the ioctl name + error code */
-#define V4L2_DEV_DEBUG_IOCTL   0x01
-/* Log the ioctl name arguments + error code */
-#define V4L2_DEV_DEBUG_IOCTL_ARG   0x02
-/* Log the file operations open, release, mmap and get_unmapped_area */
-#define V4L2_DEV_DEBUG_FOP 0x04
-/* Log the read and write file operations and the VIDIOC_(D)QBUF ioctls */
-#define V4L2_DEV_DEBUG_STREAMING   0x08
+/**
+ * enum v4l2_debug_bits - Device debug bits to be used with the video
+ * device debug attribute
+ *
+ * @V4L2_DEBUG_IOCTL:  Just log the ioctl name + error code.
+ * @V4L2_DEBUG_IOCTL_ARG:  Log the ioctl name arguments + error code.
+ * @V4L2_DEBUG_FOP:Log the file operations and open, release,
+ * mmap and get_unmapped_area syscalls.
+ * @V4L2_DEBUG_STREAMING:  Log the read and write syscalls and
+ * :c:ref:`VIDIOC_[Q|DQ]BUF ` ioctls.
+ * @V4L2_DEBUG_POLL:   Log poll syscalls.
+ */
+enum v4l2_debug_bits {
+   V4L2_DEBUG_IOCTL= 0,
+   V4L2_DEBUG_IOCTL_ARG= 1,
+   V4L2_DEBUG_FOP  = 2,
+   V4L2_DEBUG_STREAMING= 3,
+   V4L2_DEBUG_POLL = 4,
+};

I agree with the principle of having a way to document #defines and
static data that belongs to kAPI and drivers. So, from my side, if
someone pops up and propose a way to document #defines to linux-doc,
manages to get such proposal accepted and submit patches implementing it, 
I'm fine.

There are things like:

include/media/cec.h:#define CEC_NUM_CORE_EVENTS 2
include/media/cec.h:#define CEC_MAX_MSG_RX_QUEUE_SZ (18 * 3)
include/media/cec.h:#define CEC_MAX_MSG_TX_QUEUE_SZ (18 * 1)
include/media/rc-core.h:#define IR_DEFAULT_TIMEOUT  MS_TO_NS(125)
include/media/rc-core.h:#define IR_MAX_DURATION 5   /* 500 
ms */
include/media/v4l2-clk.h:#define V4L2_CLK_NAME_SIZE 64
...

that currently can't be documented, and do belong to "#define" namespace,
as those are true macros that create an alias for a magic number.

Those should *never* be converted to enums. The fact that they can't right
now be documented shouldn't be used as an excuse to conver to enums: they're
just magic numbers that can be used on a countless number of random places
that may or may not be related.

However, I do believe that, grouping namespace for values with the
same meaning do belong to enums. After all, those values are bound
together for life, as they're meant to be used at the same places.
A define is a very poor and lazy way to define, and sometimes induce
to mistakes, as, from time to time, I see values on defines that belongs
to an specific field being used on some other one.

>From documentation PoV, they also play nicer when grouped together,
as a common comment that applies to all such values are grouped
together.

In the specific case of this patch, all those V4L2_DEV_DEBUG_* bits
(or V4L2_DEV_DEBUG_* values - before this patchset) are meant to be
used only when enabling or disabling V4L2 core debug messages.

Grouping them into the same "enum" namespace makes all sense.
They should have grouped together since the beginning. That's all
my fault, as, when I added this logic[1], I just took the lazy way.

[1] Back on 2006, where there were just 2 debug values

commit 

Re: [-next PATCH 0/4] sysfs and DEVICE_ATTR_

2017-12-19 Thread Jani Nikula
On Tue, 19 Dec 2017, Joe Perches  wrote:
>  drivers/gpu/drm/i915/i915_sysfs.c  | 12 ++--

For i915,

Acked-by: Jani Nikula 


-- 
Jani Nikula, Intel Open Source Technology Center


Re: [PATCH] media: imx: allow to build with COMPILE_TEST

2017-12-19 Thread Steve Longerbeam



On 12/19/2017 03:42 AM, Philipp Zabel wrote:

Allow building this driver for other platforms under COMPILE_TEST.

Suggested-by: Mauro Carvalho Chehab 
Signed-off-by: Philipp Zabel 


Acked-by: Steve Longerbeam 


---
  drivers/staging/media/imx/Kconfig | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/imx/Kconfig 
b/drivers/staging/media/imx/Kconfig
index 2be921cd0d55a..59b380cc6d223 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers/staging/media/imx/Kconfig
@@ -1,6 +1,7 @@
  config VIDEO_IMX_MEDIA
tristate "i.MX5/6 V4L2 media core driver"
-   depends on MEDIA_CONTROLLER && VIDEO_V4L2 && ARCH_MXC && IMX_IPUV3_CORE
+   depends on ARCH_MXC || COMPILE_TEST
+   depends on MEDIA_CONTROLLER && VIDEO_V4L2 && IMX_IPUV3_CORE
depends on VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE




RE: [PATCH v2 3/8] media: v4l2-async: simplify v4l2_async_subdev structure

2017-12-19 Thread Hyun Kwon
Hi Mauro,

Thanks for the patch.

> -Original Message-
> From: Mauro Carvalho Chehab [mailto:mche...@smtp.s-opensource.com]
> On Behalf Of Mauro Carvalho Chehab
> Sent: Tuesday, December 19, 2017 3:18 AM
> To: Linux Media Mailing List 
> Cc: Mauro Carvalho Chehab ; Mauro
> Carvalho Chehab ; Lad, Prabhakar
> ; Songjun Wu
> ; Nicolas Ferre
> ; Alexandre Belloni  electrons.com>; Ludovic Desroches ;
> Kyungmin Park ; Sylwester Nawrocki
> ; Kukjin Kim ; Krzysztof
> Kozlowski ; Todor Tomov ;
> Niklas Söderlund ; Ramesh
> Shanmugasundaram ;
> Guennadi Liakhovetski ; Maxime Coquelin
> ; Alexandre Torgue
> ; Benoit Parrot ; Hyun Kwon
> ; Laurent Pinchart
> ; Michal Simek
> ; Steve Longerbeam ;
> Philipp Zabel ; Greg Kroah-Hartman
> ; Hans Verkuil ; Petr
> Cvek ; Sakari Ailus ; Julia Lawall
> ; Arnd Bergmann ; Hugues Fruchet
> ; Gustavo A. R. Silva
> ; Sebastian Reichel ; Tomasz
> Figa ; linux-arm-ker...@lists.infradead.org; linux-
> samsung-...@vger.kernel.org; linux-renesas-...@vger.kernel.org;
> de...@driverdev.osuosl.org
> Subject: [PATCH v2 3/8] media: v4l2-async: simplify v4l2_async_subdev
> structure
> 
> The V4L2_ASYNC_MATCH_FWNODE match criteria requires just one
> struct to be filled (struct fwnode_handle). The
> V4L2_ASYNC_MATCH_DEVNAME
> match criteria requires just a device name.
> 
> So, it doesn't make sense to enclose those into structs,
> as the criteria can go directly into the union.
> 
> That makes easier to document it, as we don't need to document
> weird senseless structs.
> 
> At drivers, this makes even clearer about the match criteria.
> 
> Acked-by: Sylwester Nawrocki 
> Acked-by: Benoit Parrot 
> Acked-by: Alexandre Belloni 
> Acked-by: Sakari Ailus 
> Acked-by: Philipp Zabel 
> Signed-off-by: Mauro Carvalho Chehab 

For xilinx-vipp.c, please add,

Acked-by: Hyun Kwon 

Thanks,
-hyun

> ---
>  drivers/media/platform/am437x/am437x-vpfe.c|  6 +++---
>  drivers/media/platform/atmel/atmel-isc.c   |  2 +-
>  drivers/media/platform/atmel/atmel-isi.c   |  2 +-
>  drivers/media/platform/davinci/vpif_capture.c  |  4 ++--
>  drivers/media/platform/exynos4-is/media-dev.c  |  4 ++--
>  drivers/media/platform/pxa_camera.c|  2 +-
>  drivers/media/platform/qcom/camss-8x16/camss.c |  2 +-
>  drivers/media/platform/rcar-vin/rcar-core.c|  2 +-
>  drivers/media/platform/rcar_drif.c |  4 ++--
>  drivers/media/platform/soc_camera/soc_camera.c |  2 +-
>  drivers/media/platform/stm32/stm32-dcmi.c  |  2 +-
>  drivers/media/platform/ti-vpe/cal.c|  2 +-
>  drivers/media/platform/xilinx/xilinx-vipp.c|  2 +-
>  drivers/media/v4l2-core/v4l2-async.c   | 16 
>  drivers/media/v4l2-core/v4l2-fwnode.c  | 10 +-
>  drivers/staging/media/imx/imx-media-dev.c  |  4 ++--
>  include/media/v4l2-async.h |  8 ++--
>  17 files changed, 35 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/media/platform/am437x/am437x-vpfe.c
> b/drivers/media/platform/am437x/am437x-vpfe.c
> index 0997c640191d..601ae6487617 100644
> --- a/drivers/media/platform/am437x/am437x-vpfe.c
> +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> @@ -2304,8 +2304,8 @@ vpfe_async_bound(struct v4l2_async_notifier
> *notifier,
>   vpfe_dbg(1, vpfe, "vpfe_async_bound\n");
> 
>   for (i = 0; i < ARRAY_SIZE(vpfe->cfg->asd); i++) {
> - if (vpfe->cfg->asd[i]->match.fwnode.fwnode ==
> - asd[i].match.fwnode.fwnode) {
> + if (vpfe->cfg->asd[i]->match.fwnode ==
> + asd[i].match.fwnode) {
>   sdinfo = >cfg->sub_devs[i];
>   vpfe->sd[i] = subdev;
>   vpfe->sd[i]->grp_id = sdinfo->grp_id;
> @@ -2510,7 +2510,7 @@ vpfe_get_pdata(struct platform_device *pdev)
>   }
> 
>   pdata->asd[i]->match_type =
> V4L2_ASYNC_MATCH_FWNODE;
> - pdata->asd[i]->match.fwnode.fwnode =
> 

[-next PATCH 0/4] sysfs and DEVICE_ATTR_

2017-12-19 Thread Joe Perches
Joe Perches (4):
  sysfs.h: Use octal permissions
  treewide: Use DEVICE_ATTR_RW
  treewide: Use DEVICE_ATTR_RO
  treewide: Use DEVICE_ATTR_WO

 arch/arm/mach-pxa/sharpsl_pm.c |  4 +-
 arch/s390/kernel/smp.c |  2 +-
 arch/s390/kernel/topology.c|  3 +-
 arch/sh/drivers/push-switch.c  |  2 +-
 arch/tile/kernel/sysfs.c   | 12 ++--
 arch/x86/kernel/cpu/microcode/core.c   |  2 +-
 drivers/acpi/device_sysfs.c|  6 +-
 drivers/char/ipmi/ipmi_msghandler.c| 17 +++---
 drivers/gpu/drm/i915/i915_sysfs.c  | 12 ++--
 drivers/input/touchscreen/elants_i2c.c |  2 +-
 drivers/net/ethernet/ibm/ibmvnic.c |  2 +-
 drivers/net/wimax/i2400m/sysfs.c   |  3 +-
 drivers/nvme/host/core.c   | 10 ++--
 drivers/platform/x86/compal-laptop.c   | 18 ++
 drivers/s390/cio/css.c |  8 +--
 drivers/s390/cio/device.c  | 10 ++--
 drivers/s390/crypto/ap_card.c  |  2 +-
 drivers/scsi/hpsa.c| 10 ++--
 drivers/scsi/lpfc/lpfc_attr.c  | 64 --
 .../staging/media/atomisp/pci/atomisp2/hmm/hmm.c   |  8 +--
 drivers/thermal/thermal_sysfs.c| 17 +++---
 drivers/tty/serial/sh-sci.c|  2 +-
 drivers/usb/host/xhci-dbgcap.c |  2 +-
 drivers/usb/phy/phy-tahvo.c|  2 +-
 drivers/video/fbdev/auo_k190x.c|  4 +-
 drivers/video/fbdev/w100fb.c   |  4 +-
 include/linux/sysfs.h  | 14 ++---
 lib/test_firmware.c| 14 ++---
 lib/test_kmod.c| 14 ++---
 sound/soc/omap/mcbsp.c |  4 +-
 sound/soc/soc-core.c   |  2 +-
 sound/soc/soc-dapm.c   |  2 +-
 32 files changed, 120 insertions(+), 158 deletions(-)

-- 
2.15.0



[-next PATCH 3/4] treewide: Use DEVICE_ATTR_RO

2017-12-19 Thread Joe Perches
Convert DEVICE_ATTR uses to DEVICE_ATTR_RO where possible.

Done with perl script:

$ git grep -w --name-only DEVICE_ATTR | \
  xargs perl -i -e 'local $/; while (<>) { 
s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IRUGO\s*|\s*0444\s*)\)?\s*,\s*\1_show\s*,\s*NULL\s*\)/DEVICE_ATTR_RO(\1)/g;
 print;}'

Signed-off-by: Joe Perches 
---
 arch/arm/mach-pxa/sharpsl_pm.c   |  4 ++--
 arch/sh/drivers/push-switch.c|  2 +-
 arch/tile/kernel/sysfs.c | 10 +-
 drivers/acpi/device_sysfs.c  |  6 +++---
 drivers/char/ipmi/ipmi_msghandler.c  | 17 -
 drivers/gpu/drm/i915/i915_sysfs.c|  6 +++---
 drivers/nvme/host/core.c | 10 +-
 drivers/s390/cio/css.c   |  8 
 drivers/s390/cio/device.c|  8 
 drivers/s390/crypto/ap_card.c|  2 +-
 drivers/scsi/hpsa.c  | 10 +-
 drivers/scsi/lpfc/lpfc_attr.c| 18 --
 drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c |  8 
 drivers/thermal/thermal_sysfs.c  |  6 +++---
 sound/soc/soc-core.c |  2 +-
 sound/soc/soc-dapm.c |  2 +-
 16 files changed, 58 insertions(+), 61 deletions(-)

diff --git a/arch/arm/mach-pxa/sharpsl_pm.c b/arch/arm/mach-pxa/sharpsl_pm.c
index 398ba9ba2632..ef9fd9b759cb 100644
--- a/arch/arm/mach-pxa/sharpsl_pm.c
+++ b/arch/arm/mach-pxa/sharpsl_pm.c
@@ -802,8 +802,8 @@ static ssize_t battery_voltage_show(struct device *dev, 
struct device_attribute
return sprintf(buf, "%d\n", sharpsl_pm.battstat.mainbat_voltage);
 }
 
-static DEVICE_ATTR(battery_percentage, 0444, battery_percentage_show, NULL);
-static DEVICE_ATTR(battery_voltage, 0444, battery_voltage_show, NULL);
+static DEVICE_ATTR_RO(battery_percentage);
+static DEVICE_ATTR_RO(battery_voltage);
 
 extern void (*apm_get_power_status)(struct apm_power_info *);
 
diff --git a/arch/sh/drivers/push-switch.c b/arch/sh/drivers/push-switch.c
index a17181160233..762bc5619910 100644
--- a/arch/sh/drivers/push-switch.c
+++ b/arch/sh/drivers/push-switch.c
@@ -24,7 +24,7 @@ static ssize_t switch_show(struct device *dev,
struct push_switch_platform_info *psw_info = dev->platform_data;
return sprintf(buf, "%s\n", psw_info->name);
 }
-static DEVICE_ATTR(switch, S_IRUGO, switch_show, NULL);
+static DEVICE_ATTR_RO(switch);
 
 static void switch_timer(struct timer_list *t)
 {
diff --git a/arch/tile/kernel/sysfs.c b/arch/tile/kernel/sysfs.c
index af5024f0fb5a..b09456a3d77a 100644
--- a/arch/tile/kernel/sysfs.c
+++ b/arch/tile/kernel/sysfs.c
@@ -38,7 +38,7 @@ static ssize_t chip_width_show(struct device *dev,
 {
return sprintf(page, "%u\n", smp_width);
 }
-static DEVICE_ATTR(chip_width, 0444, chip_width_show, NULL);
+static DEVICE_ATTR_RO(chip_width);
 
 static ssize_t chip_height_show(struct device *dev,
struct device_attribute *attr,
@@ -46,7 +46,7 @@ static ssize_t chip_height_show(struct device *dev,
 {
return sprintf(page, "%u\n", smp_height);
 }
-static DEVICE_ATTR(chip_height, 0444, chip_height_show, NULL);
+static DEVICE_ATTR_RO(chip_height);
 
 static ssize_t chip_serial_show(struct device *dev,
struct device_attribute *attr,
@@ -54,7 +54,7 @@ static ssize_t chip_serial_show(struct device *dev,
 {
return get_hv_confstr(page, HV_CONFSTR_CHIP_SERIAL_NUM);
 }
-static DEVICE_ATTR(chip_serial, 0444, chip_serial_show, NULL);
+static DEVICE_ATTR_RO(chip_serial);
 
 static ssize_t chip_revision_show(struct device *dev,
  struct device_attribute *attr,
@@ -62,7 +62,7 @@ static ssize_t chip_revision_show(struct device *dev,
 {
return get_hv_confstr(page, HV_CONFSTR_CHIP_REV);
 }
-static DEVICE_ATTR(chip_revision, 0444, chip_revision_show, NULL);
+static DEVICE_ATTR_RO(chip_revision);
 
 
 static ssize_t type_show(struct device *dev,
@@ -71,7 +71,7 @@ static ssize_t type_show(struct device *dev,
 {
return sprintf(page, "tilera\n");
 }
-static DEVICE_ATTR(type, 0444, type_show, NULL);
+static DEVICE_ATTR_RO(type);
 
 #define HV_CONF_ATTR(name, conf)   \
static ssize_t name ## _show(struct device *dev,\
diff --git a/drivers/acpi/device_sysfs.c b/drivers/acpi/device_sysfs.c
index a041689e5701..545e91420cde 100644
--- a/drivers/acpi/device_sysfs.c
+++ b/drivers/acpi/device_sysfs.c
@@ -357,7 +357,7 @@ static ssize_t real_power_state_show(struct device *dev,
return sprintf(buf, "%s\n", acpi_power_state_string(state));
 }
 
-static DEVICE_ATTR(real_power_state, 0444, real_power_state_show, NULL);
+static DEVICE_ATTR_RO(real_power_state);
 
 static ssize_t 

Re: [PATCH v5 4/6] media: i2c: Add TDA1997x HDMI receiver driver

2017-12-19 Thread Hans Verkuil
On 19/12/17 18:01, Tim Harvey wrote:
> On Tue, Dec 19, 2017 at 3:12 AM, Hans Verkuil  wrote:
>> On 16/12/17 19:00, Tim Harvey wrote:
>>> +
>>> +static int tda1997x_fill_format(struct tda1997x_state *state,
>>> + struct v4l2_mbus_framefmt *format)
>>> +{
>>> + const struct v4l2_bt_timings *bt;
>>> + struct v4l2_hdmi_colorimetry c;
>>> +
>>> + v4l_dbg(1, debug, state->client, "%s\n", __func__);
>>> +
>>> + if (!state->detected_timings)
>>> + return -EINVAL;
>>> + bt = >detected_timings->bt;
>>> + memset(format, 0, sizeof(*format));
>>> + c = v4l2_hdmi_rx_colorimetry(>avi_infoframe, NULL, bt->height);
>>> + format->width = bt->width;
>>> + format->height = bt->height;
>>> + format->field = (bt->interlaced) ?
>>> + V4L2_FIELD_ALTERNATE : V4L2_FIELD_NONE;
>>> + format->colorspace = c.colorspace;
>>> + format->ycbcr_enc = c.ycbcr_enc;
>>> + format->quantization = c.quantization;
>>> + format->xfer_func = c.xfer_func;
>>
>> This is wrong. v4l2_hdmi_rx_colorimetry returns what arrives on the HDMI 
>> link,
>> that's not the same as is output towards the SoC. You need to take 
>> limited/full
>> range conversions and 601/709 conversions into account since that's what ends
>> up in memory.
>>
>> Also note: you are still parsing the colorimetry information from 
>> avi_infoframe
>> in the infoframe parse function. There is no need to do that, just call
>> v4l2_hdmi_rx_colorimetry and let that function parse and interpret all this.
>>
>> Otherwise we still have two places that try to interpret that information.
> 
> Hans,
> 
> Ok so v4l2_hdmi_rx_colorimetry() handles parsing the source avi
> infoframe and deals with enforcing the detailed rules and returns
> 'v4l2' enums:
> 
> tda1997x_parse_infoframe(...)
> ...
> case HDMI_INFOFRAME_TYPE_AVI:
> state->avi_infoframe = frame.avi; /* hold on to avi
> infoframe for later use in logging etc */
> /* parse avi infoframe colorimetry data for v4l2
> colorspace/ycbcr_encoding/quantization/xfer_func */
> state->hdmi_colorimetry = v4l2_hdmi_rx_colorimetry(,
> NULL,
> state->timings.bt.height);
> 
> Also here I still need to override the quant range passed from the
> source avi infoframe per the user control (if not auto) and set per
> vic if default:
> 
> /* Quantization Range */
> switch (state->rgb_quantization_range) {
> case V4L2_DV_RGB_RANGE_AUTO:
> state->range = frame.avi.quantization_range;
> break;
> case V4L2_DV_RGB_RANGE_LIMITED:
> state->range = HDMI_QUANTIZATION_RANGE_LIMITED;
> break;
> case V4L2_DV_RGB_RANGE_FULL:
> state->range = HDMI_QUANTIZATION_RANGE_FULL;
> break;
> }
> if (state->range == HDMI_QUANTIZATION_RANGE_DEFAULT) {
> if (frame.avi.video_code <= 1)
> state->range = HDMI_QUANTIZATION_RANGE_FULL;
> else
> state->range = 
> HDMI_QUANTIZATION_RANGE_LIMITED;
> }

No, the vic check is already done in v4l2_hdmi_rx_colorimetry.

Call v4l2_hdmi_rx_colorimetry first, then:

/* If ycbcr_enc is V4L2_YCBCR_ENC_DEFAULT, then we receive RGB */
if (c.ycbcr_enc == V4L2_YCBCR_ENC_DEFAULT)
switch (state->rgb_quantization_range) {
case V4L2_DV_RGB_RANGE_LIMITED:
c.quantization = V4L2_QUANTIZATION_FULL_RANGE;
break;
case V4L2_DV_RGB_RANGE_FULL:
c.quantization = V4L2_QUANTIZATION_LIM_RANGE;
break;
}

(c is of type struct v4l2_hdmi_colorimetry)

> 
> 
> Then tda1997x_fill_format() then needs to fill in details of what's on
> the bus so I should be filling in only width/height/field/colorspace
> and use colorspace based on my csc conversion chosen output
> (V4L2_COLORSPACE_SRGB|V4L2_COLORSPACE_SMPTE170M|V4L2_COLORSPACE_REC709)
> and I don't need to set ycbcr_enc/quantization/xfer_func.

You don't touch the colorspace and xfer_func fields. The simple matrix
csc can only change quantization range and/or ycbcr encoding.

It doesn't change the underlying colorspace ('chromaticities') or the
used transfer function.

In practice if the output is RGB then ycbcr_enc should be set to
V4L2_YCBCR_ENC_DEFAULT and quantization to FULL_RANGE. For YUV output you
set ycbcr_enc to V4L2_YCBCR_ENC_601 or 709 and quantization to LIM_RANGE.

Regards,

Hans

> 
> does this sound right?
> 
> Thanks,
> 
> Tim
> 



Re: [PATCH 2/8] media: v4l2-ioctl.h: convert debug into an enum of bits

2017-12-19 Thread Laurent Pinchart
Hi Mauro,

On Tuesday, 19 December 2017 17:37:58 EET Mauro Carvalho Chehab wrote:
> Em Tue, 19 Dec 2017 16:12:35 +0200 Sakari Ailus escreveu:
> > On Tue, Dec 19, 2017 at 04:02:02PM +0200, Laurent Pinchart wrote:
> >> And furthermore using enum types in the uAPI is a bad idea as the enum
> >> size is architecture-dependent. That's why we use integer types in
> >> structures used as ioctl arguments.
> > 
> > I guess we have an argeement on that, enums are a no-go for uAPI, for
> > reasons not related to the topic at hand.
> 
> Huh? We're not talking about uAPI. This is kAPI. Using enums there is OK.

Sure, there's no disagreement about that. The point was that, as both uAPI and 
kAPI should be documented, and we can't use enums for uAPI, we need a way to 
document non-enum types, which we could then use to document the kAPI the same 
way.

-- 
Regards,

Laurent Pinchart



Re: [PATCH v5 4/6] media: i2c: Add TDA1997x HDMI receiver driver

2017-12-19 Thread Tim Harvey
On Tue, Dec 19, 2017 at 3:12 AM, Hans Verkuil  wrote:
> On 16/12/17 19:00, Tim Harvey wrote:
>> +
>> +static int tda1997x_fill_format(struct tda1997x_state *state,
>> + struct v4l2_mbus_framefmt *format)
>> +{
>> + const struct v4l2_bt_timings *bt;
>> + struct v4l2_hdmi_colorimetry c;
>> +
>> + v4l_dbg(1, debug, state->client, "%s\n", __func__);
>> +
>> + if (!state->detected_timings)
>> + return -EINVAL;
>> + bt = >detected_timings->bt;
>> + memset(format, 0, sizeof(*format));
>> + c = v4l2_hdmi_rx_colorimetry(>avi_infoframe, NULL, bt->height);
>> + format->width = bt->width;
>> + format->height = bt->height;
>> + format->field = (bt->interlaced) ?
>> + V4L2_FIELD_ALTERNATE : V4L2_FIELD_NONE;
>> + format->colorspace = c.colorspace;
>> + format->ycbcr_enc = c.ycbcr_enc;
>> + format->quantization = c.quantization;
>> + format->xfer_func = c.xfer_func;
>
> This is wrong. v4l2_hdmi_rx_colorimetry returns what arrives on the HDMI link,
> that's not the same as is output towards the SoC. You need to take 
> limited/full
> range conversions and 601/709 conversions into account since that's what ends
> up in memory.
>
> Also note: you are still parsing the colorimetry information from 
> avi_infoframe
> in the infoframe parse function. There is no need to do that, just call
> v4l2_hdmi_rx_colorimetry and let that function parse and interpret all this.
>
> Otherwise we still have two places that try to interpret that information.

Hans,

Ok so v4l2_hdmi_rx_colorimetry() handles parsing the source avi
infoframe and deals with enforcing the detailed rules and returns
'v4l2' enums:

tda1997x_parse_infoframe(...)
...
case HDMI_INFOFRAME_TYPE_AVI:
state->avi_infoframe = frame.avi; /* hold on to avi
infoframe for later use in logging etc */
/* parse avi infoframe colorimetry data for v4l2
colorspace/ycbcr_encoding/quantization/xfer_func */
state->hdmi_colorimetry = v4l2_hdmi_rx_colorimetry(,
NULL,
state->timings.bt.height);

Also here I still need to override the quant range passed from the
source avi infoframe per the user control (if not auto) and set per
vic if default:

/* Quantization Range */
switch (state->rgb_quantization_range) {
case V4L2_DV_RGB_RANGE_AUTO:
state->range = frame.avi.quantization_range;
break;
case V4L2_DV_RGB_RANGE_LIMITED:
state->range = HDMI_QUANTIZATION_RANGE_LIMITED;
break;
case V4L2_DV_RGB_RANGE_FULL:
state->range = HDMI_QUANTIZATION_RANGE_FULL;
break;
}
if (state->range == HDMI_QUANTIZATION_RANGE_DEFAULT) {
if (frame.avi.video_code <= 1)
state->range = HDMI_QUANTIZATION_RANGE_FULL;
else
state->range = HDMI_QUANTIZATION_RANGE_LIMITED;
}


Then tda1997x_fill_format() then needs to fill in details of what's on
the bus so I should be filling in only width/height/field/colorspace
and use colorspace based on my csc conversion chosen output
(V4L2_COLORSPACE_SRGB|V4L2_COLORSPACE_SMPTE170M|V4L2_COLORSPACE_REC709)
and I don't need to set ycbcr_enc/quantization/xfer_func.

does this sound right?

Thanks,

Tim


[PATCH][next] media: lirc: don't kfree the uninitialized pointer txbuf

2017-12-19 Thread Colin King
From: Colin Ian King 

The current error exit path if ir_raw_encode_scancode fails is via the
label out_kfree which kfree's an uninitialized pointer txbuf. Fix this
by exiting via a new exit path that does not kfree txbuf.  Also exit
via this new exit path for a failed allocation of txbuf to avoid a
redundant kfree on a NULL pointer (to save a bunch of CPU cycles).

Detected by: CoverityScan, CID#1463070 ("Uninitialized pointer read")

Fixes: f81a8158d4fb ("media: lirc: release lock before sleep")
Signed-off-by: Colin Ian King 
---
 drivers/media/rc/lirc_dev.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index fae42f120aa4..62afa4493aea 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -295,14 +295,14 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, 
const char __user *buf,
ret = ir_raw_encode_scancode(scan.rc_proto, scan.scancode,
 raw, LIRCBUF_SIZE);
if (ret < 0)
-   goto out_kfree;
+   goto out_kfree_raw;
 
count = ret;
 
txbuf = kmalloc_array(count, sizeof(unsigned int), GFP_KERNEL);
if (!txbuf) {
ret = -ENOMEM;
-   goto out_kfree;
+   goto out_kfree_raw;
}
 
for (i = 0; i < count; i++)
@@ -366,6 +366,7 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, const 
char __user *buf,
return n;
 out_kfree:
kfree(txbuf);
+out_kfree_raw:
kfree(raw);
 out_unlock:
mutex_unlock(>lock);
-- 
2.14.1



[PATCH] media: atomisp: convert default struct values to use compound-literals with designated initializers.

2017-12-19 Thread Jeremy Sowden
The CSS API uses a lot of nested anonymous structs defined in object
macros to assign default values to its data-structures.  These have been
changed to use compound-literals and designated initializers to make
them more comprehensible and less fragile.

The compound-literals can also be used in assignment, which means we can
get rid of some temporary variables whose only purpose is to be
initialized by one of these anonymous structs and then serve as the
rvalue in an assignment expression.

A lot of the members of the default struct values used by the CSS API
were explicitly initialized to zero values.  Designated initializers
have allowed these members, and in some case whole default struct
values, to be removed.

Signed-off-by: Jeremy Sowden 
---
 .../hive_isp_css_common/input_formatter_global.h   |  16 ---
 .../pci/atomisp2/css2400/ia_css_frame_public.h |  29 ++
 .../atomisp/pci/atomisp2/css2400/ia_css_pipe.h | 113 -
 .../pci/atomisp2/css2400/ia_css_pipe_public.h  | 108 +++-
 .../atomisp/pci/atomisp2/css2400/ia_css_types.h|  64 +++-
 .../isp/kernels/s3a/s3a_1.0/ia_css_s3a_types.h |  50 +
 .../kernels/sdis/common/ia_css_sdis_common_types.h |  31 ++
 .../isp/kernels/sdis/sdis_1.0/ia_css_sdis.host.c   |   3 +-
 .../runtime/binary/interface/ia_css_binary.h   |  88 ++--
 .../atomisp2/css2400/runtime/binary/src/binary.c   |   3 +-
 .../isp_param/interface/ia_css_isp_param_types.h   |  10 --
 .../runtime/pipeline/interface/ia_css_pipeline.h   |  24 ++---
 .../css2400/runtime/pipeline/src/pipeline.c|   7 +-
 .../media/atomisp/pci/atomisp2/css2400/sh_css.c|  31 ++
 .../atomisp/pci/atomisp2/css2400/sh_css_legacy.h   |  11 --
 .../atomisp/pci/atomisp2/css2400/sh_css_metrics.h  |  21 
 16 files changed, 116 insertions(+), 493 deletions(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/input_formatter_global.h
 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/input_formatter_global.h
index 5654d911db65..7558f4964313 100644
--- 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/input_formatter_global.h
+++ 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/hive_isp_css_common/input_formatter_global.h
@@ -107,22 +107,6 @@ struct input_formatter_cfg_s {
uint32_tblock_no_reqs;
 };
 
-#define DEFAULT_IF_CONFIG \
-{ \
-   0,  /* start_line */\
-   0,  /* start_column */\
-   0,  /* left_padding */\
-   0,  /* cropped_height */\
-   0,  /* cropped_width */\
-   0,  /* deinterleaving */\
-   0,  /*.buf_vecs */\
-   0,  /* buf_start_index */\
-   0,  /* buf_increment */\
-   0,  /* buf_eol_offset */\
-   false,  /* is_yuv420_format */\
-   false   /* block_no_reqs */\
-}
-
 extern const hrt_address HIVE_IF_SRST_ADDRESS[N_INPUT_FORMATTER_ID];
 extern const hrt_data HIVE_IF_SRST_MASK[N_INPUT_FORMATTER_ID];
 extern const uint8_t HIVE_IF_SWITCH_CODE[N_INPUT_FORMATTER_ID];
diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_frame_public.h 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_frame_public.h
index ba7a076c3afa..0beb7347a4f3 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_frame_public.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/ia_css_frame_public.h
@@ -121,15 +121,9 @@ struct ia_css_frame_info {
 };
 
 #define IA_CSS_BINARY_DEFAULT_FRAME_INFO \
-{ \
-   {0,  /* width */ \
-0}, /* height */ \
-   0,   /* padded_width */ \
-   IA_CSS_FRAME_FORMAT_NUM, /* format */ \
-   0,   /* raw_bit_depth */ \
-   IA_CSS_BAYER_ORDER_NUM,  /* raw_bayer_order */ \
-   {0,   /*start col */ \
-0},   /*start line */ \
+(struct ia_css_frame_info) { \
+   .format = IA_CSS_FRAME_FORMAT_NUM,  \
+   .raw_bayer_order= IA_CSS_BAYER_ORDER_NUM, \
 }
 
 /**
@@ -190,18 +184,11 @@ struct ia_css_frame {
 };
 
 #define DEFAULT_FRAME \
-{ \
-   IA_CSS_BINARY_DEFAULT_FRAME_INFO,   /* info */ \
-   0,  /* data */ \
-   0,  /* data_bytes */ \
-   SH_CSS_INVALID_QUEUE_ID,/* dynamic_data_index */ \
-   IA_CSS_BUFFER_TYPE_INVALID, /* buf_type */ \
-   IA_CSS_FRAME_FLASH_STATE_NONE,  /* flash_state */ \
-   0,  /* exp_id */ \
-   0,  /* isp_config_id */ \
-   false,  /* valid */ \
-   false,  /* contiguous  */ \
-   { 0 }   

Re: [PATCH V3 1/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_reset

2017-12-19 Thread Fabien DESSENNE
Hi,


It's almost good!

You have to fix these checkpatch Warning/Check:

WARNING: Block comments use a trailing */ on a separate line
#36: FILE: drivers/media/platform/sti/bdisp/bdisp-hw.c:383:
+     * needing any delays */

CHECK: Alignment should match open parenthesis
#38: FILE: drivers/media/platform/sti/bdisp/bdisp-hw.c:385:
+    if (readl_poll_timeout_atomic(bdisp->regs + BLT_STA1, tmp,
+        (tmp & BLT_STA1_IDLE), POLL_RST_DELAY_MS,


 From kernel documentation in the "Posting patches" chapter:

"You should always run patches through scripts/checkpatch.pl and address 
the complaints it comes up with."

And, please use the --strict option

Thanks for your understanding.

BR

Fabien

On 19/12/17 14:57, Jia-Ju Bai wrote:
> The driver may sleep under a spinlock.
> The function call path is:
> bdisp_device_run (acquire the spinlock)
>bdisp_hw_reset
>  msleep --> may sleep
>
> To fix it, readl_poll_timeout_atomic is used to replace msleep.
>
> This bug is found by my static analysis tool(DSAC) and
> checked by my code review.
>
> Signed-off-by: Jia-Ju Bai 
> ---
>   drivers/media/platform/sti/bdisp/bdisp-hw.c |   23 ---
>   1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/platform/sti/bdisp/bdisp-hw.c 
> b/drivers/media/platform/sti/bdisp/bdisp-hw.c
> index b7892f3..b63d9c9 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp-hw.c
> +++ b/drivers/media/platform/sti/bdisp/bdisp-hw.c
> @@ -4,7 +4,7 @@
>* License terms:  GNU General Public License (GPL), version 2
>*/
>   
> -#include 
> +#include 
>   
>   #include "bdisp.h"
>   #include "bdisp-filter.h"
> @@ -15,7 +15,7 @@
>   
>   /* Reset & boot poll config */
>   #define POLL_RST_MAX50
> -#define POLL_RST_DELAY_MS   20
> +#define POLL_RST_DELAY_US   2
>   
>   enum bdisp_target_plan {
>   BDISP_RGB,
> @@ -366,7 +366,7 @@ struct bdisp_filter_addr {
>*/
>   int bdisp_hw_reset(struct bdisp_dev *bdisp)
>   {
> - unsigned int i;
> + u32 tmp;
>   
>   dev_dbg(bdisp->dev, "%s\n", __func__);
>   
> @@ -378,16 +378,17 @@ int bdisp_hw_reset(struct bdisp_dev *bdisp)
>  bdisp->regs + BLT_CTL);
>   writel(0, bdisp->regs + BLT_CTL);
>   
> - /* Wait for reset done */
> - for (i = 0; i < POLL_RST_MAX; i++) {
> - if (readl(bdisp->regs + BLT_STA1) & BLT_STA1_IDLE)
> - break;
> - msleep(POLL_RST_DELAY_MS);
> - }
> - if (i == POLL_RST_MAX)
> + /* Wait for reset done.
> +  * Despite the large timeout, most of the time the reset happens without
> +  * needing any delays */

shall be

+* needing any delays

+*/

> + if (readl_poll_timeout_atomic(bdisp->regs + BLT_STA1, tmp,
> + (tmp & BLT_STA1_IDLE), POLL_RST_DELAY_US,
> + POLL_RST_DELAY_US * POLL_RST_MAX)) {

shall be:

+   if (readl_poll_timeout_atomic(bdisp->regs + BLT_STA1, tmp,
+ tmp & BLT_STA1_IDLE, POLL_RST_DELAY_US,
+ POLL_RST_DELAY_US * POLL_RST_MAX)) {

>   dev_err(bdisp->dev, "Reset timeout\n");
> + return -EAGAIN;
> + }
>   
> - return (i == POLL_RST_MAX) ? -EAGAIN : 0;
> + return 0;
>   }
>   
>   /**


Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver

2017-12-19 Thread Sakari Ailus
On Tue, Dec 19, 2017 at 12:31:46PM -0200, Fabio Estevam wrote:
> On Tue, Dec 19, 2017 at 11:43 AM, Sakari Ailus  wrote:
> 
> > Both seem to exist. See e.g. c3a3d1d6b8b363a02234e5564692db3647f183e6 .
> 
> This patch fixes .h files to use /* SPDX style comment, which is the
> recommendation.
> 
> .c files should use // SPDX style.

Agreed. I reverted the changes.

Thanks.

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


Re: [PATCH] media: ov9650: support VIDIOC_DBG_G/S_REGISTER ioctls

2017-12-19 Thread Sakari Ailus
Hi Akinobu,

On Wed, Dec 20, 2017 at 12:39:51AM +0900, Akinobu Mita wrote:
> Hi Sakari,
> 
> 2017-12-19 19:35 GMT+09:00 Sakari Ailus :
> > Hi Akinobu,
> >
> > On Thu, Dec 14, 2017 at 01:00:49AM +0900, Akinobu Mita wrote:
> >> This adds support VIDIOC_DBG_G/S_REGISTER ioctls.
> >>
> >> There are many device control registers contained in the OV9650.  So
> >> this helps debugging the lower level issues by getting and setting the
> >> registers.
> >>
> >> Cc: Sylwester Nawrocki 
> >> Cc: Sakari Ailus 
> >> Cc: Mauro Carvalho Chehab 
> >> Signed-off-by: Akinobu Mita 
> >
> > Just wondering --- doesn't the I涎 user space interface offer essentially
> > the same functionality?
> 
> You are right.  I thought /dev/i2c-X interface is not allowed for the
> i2c device that is currently in use by a driver.  But I found that
> there is I2C_SLAVE_FORCE ioctl to bypass the check and the i2cget and
> i2cset with '-f' option use I2C_SLAVE_FORCE ioctls.
> 
> So I can live without the proposed patch.

Thanks for checking. It's indeed better to use an existing interface.

There's also debugfs. That might be even better but it requires driver code
to make use of it. Anyway non-I²C devices can use it, too.

I'll mark the patch as rejected.

-- 
Kind regards,

Sakari Ailus
sakari.ai...@linux.intel.com


Re: [PATCH] media: ov9650: support VIDIOC_DBG_G/S_REGISTER ioctls

2017-12-19 Thread Hans Verkuil
On 19/12/17 16:39, Akinobu Mita wrote:
> Hi Sakari,
> 
> 2017-12-19 19:35 GMT+09:00 Sakari Ailus :
>> Hi Akinobu,
>>
>> On Thu, Dec 14, 2017 at 01:00:49AM +0900, Akinobu Mita wrote:
>>> This adds support VIDIOC_DBG_G/S_REGISTER ioctls.
>>>
>>> There are many device control registers contained in the OV9650.  So
>>> this helps debugging the lower level issues by getting and setting the
>>> registers.
>>>
>>> Cc: Sylwester Nawrocki 
>>> Cc: Sakari Ailus 
>>> Cc: Mauro Carvalho Chehab 
>>> Signed-off-by: Akinobu Mita 
>>
>> Just wondering --- doesn't the I涎 user space interface offer essentially
>> the same functionality?
> 
> You are right.  I thought /dev/i2c-X interface is not allowed for the
> i2c device that is currently in use by a driver.  But I found that
> there is I2C_SLAVE_FORCE ioctl to bypass the check and the i2cget and
> i2cset with '-f' option use I2C_SLAVE_FORCE ioctls.
> 
> So I can live without the proposed patch.

Sakari, there are lots of drivers that use this. There is nothing wrong with
it and it is easier to use than the i2c interface (although that's my opinion).
It certainly is more consistent with other drivers.

It is also possible to use registernames instead of addresses if the necessary
patch is applied to v4l2-dbg.

Anyway:

Acked-by: Hans Verkuil 

Regards,

Hans

> 
>> See: Documentation/i2c/dev-interface
>>
>> Cc Hans.
>>
>>> ---
>>>  drivers/media/i2c/ov9650.c | 36 
>>>  1 file changed, 36 insertions(+)
>>>
>>> diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
>>> index 69433e1..c6462cf 100644
>>> --- a/drivers/media/i2c/ov9650.c
>>> +++ b/drivers/media/i2c/ov9650.c
>>> @@ -1374,6 +1374,38 @@ static int ov965x_open(struct v4l2_subdev *sd, 
>>> struct v4l2_subdev_fh *fh)
>>>   return 0;
>>>  }
>>>
>>> +#ifdef CONFIG_VIDEO_ADV_DEBUG
>>> +
>>> +static int ov965x_g_register(struct v4l2_subdev *sd,
>>> +  struct v4l2_dbg_register *reg)
>>> +{
>>> + struct i2c_client *client = v4l2_get_subdevdata(sd);
>>> + u8 val = 0;
>>> + int ret;
>>> +
>>> + if (reg->reg > 0xff)
>>> + return -EINVAL;
>>> +
>>> + ret = ov965x_read(client, reg->reg, );
>>> + reg->val = val;
>>> + reg->size = 1;
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +static int ov965x_s_register(struct v4l2_subdev *sd,
>>> +  const struct v4l2_dbg_register *reg)
>>> +{
>>> + struct i2c_client *client = v4l2_get_subdevdata(sd);
>>> +
>>> + if (reg->reg > 0xff || reg->val > 0xff)
>>> + return -EINVAL;
>>> +
>>> + return ov965x_write(client, reg->reg, reg->val);
>>> +}
>>> +
>>> +#endif
>>> +
>>>  static const struct v4l2_subdev_pad_ops ov965x_pad_ops = {
>>>   .enum_mbus_code = ov965x_enum_mbus_code,
>>>   .enum_frame_size = ov965x_enum_frame_sizes,
>>> @@ -1397,6 +1429,10 @@ static const struct v4l2_subdev_core_ops 
>>> ov965x_core_ops = {
>>>   .log_status = v4l2_ctrl_subdev_log_status,
>>>   .subscribe_event = v4l2_ctrl_subdev_subscribe_event,
>>>   .unsubscribe_event = v4l2_event_subdev_unsubscribe,
>>> +#ifdef CONFIG_VIDEO_ADV_DEBUG
>>> + .g_register = ov965x_g_register,
>>> + .s_register = ov965x_s_register,
>>> +#endif
>>>  };
>>>
>>>  static const struct v4l2_subdev_ops ov965x_subdev_ops = {
>>> --
>>> 2.7.4
>>>
>>
>> --
>> Sakari Ailus
>> e-mail: sakari.ai...@iki.fi



Re: [PATCH] media: add operation to get configuration of "the other side" of the link

2017-12-19 Thread Sakari Ailus
Hi Pavel,

On Mon, Feb 06, 2017 at 10:37:48AM +0100, Pavel Machek wrote:
> 
> Normally, link configuration can be determined at probe time... but
> Nokia N900 has two cameras, and can switch between them at runtime, so
> that mechanism is not suitable here.
> 
> Add a hook that tells us link configuration.
> 
> Signed-off-by: Pavel Machek 
> 
> diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
> index cf778c5..74148b9 100644
> --- a/include/media/v4l2-subdev.h
> +++ b/include/media/v4l2-subdev.h
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* generic v4l2_device notify callback notification values */
>  #define V4L2_SUBDEV_IR_RX_NOTIFY _IOW('v', 0, u32)
> @@ -383,6 +384,8 @@ struct v4l2_mbus_frame_desc {
>   * @s_rx_buffer: set a host allocated memory buffer for the subdev. The 
> subdev
>   *   can adjust @size to a lower value and must not write more data to the
>   *   buffer starting at @data than the original value of @size.
> + *
> + * @g_endpoint_config: get link configuration required by this device.
>   */
>  struct v4l2_subdev_video_ops {
>   int (*s_routing)(struct v4l2_subdev *sd, u32 input, u32 output, u32 
> config);
> @@ -415,6 +418,8 @@ struct v4l2_subdev_video_ops {
>const struct v4l2_mbus_config *cfg);
>   int (*s_rx_buffer)(struct v4l2_subdev *sd, void *buf,
>  unsigned int *size);
> + int (*g_endpoint_config)(struct v4l2_subdev *sd,
> + struct v4l2_of_endpoint *cfg);
>  };
>  
>  /**
> 
> 
> 
> 

I think Laurent has a board that has a similar issue.

I'd like to address such issues in conjunction with the CSI-2 virtual
channel and data type support, with the patches in the vc branch here:



V4L2 OF (or fwnode) endpoint alone doesn't contain all the related
information, and it'd be nice if the solution was indeed independent of OF
(or fwnode).

Niklas has been working on more driver support for this so we're getting
closer to having these merged.

-- 
Kind regards,

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


Re: [PATCH] media: ov9650: support VIDIOC_DBG_G/S_REGISTER ioctls

2017-12-19 Thread Akinobu Mita
Hi Sakari,

2017-12-19 19:35 GMT+09:00 Sakari Ailus :
> Hi Akinobu,
>
> On Thu, Dec 14, 2017 at 01:00:49AM +0900, Akinobu Mita wrote:
>> This adds support VIDIOC_DBG_G/S_REGISTER ioctls.
>>
>> There are many device control registers contained in the OV9650.  So
>> this helps debugging the lower level issues by getting and setting the
>> registers.
>>
>> Cc: Sylwester Nawrocki 
>> Cc: Sakari Ailus 
>> Cc: Mauro Carvalho Chehab 
>> Signed-off-by: Akinobu Mita 
>
> Just wondering --- doesn't the I涎 user space interface offer essentially
> the same functionality?

You are right.  I thought /dev/i2c-X interface is not allowed for the
i2c device that is currently in use by a driver.  But I found that
there is I2C_SLAVE_FORCE ioctl to bypass the check and the i2cget and
i2cset with '-f' option use I2C_SLAVE_FORCE ioctls.

So I can live without the proposed patch.

> See: Documentation/i2c/dev-interface
>
> Cc Hans.
>
>> ---
>>  drivers/media/i2c/ov9650.c | 36 
>>  1 file changed, 36 insertions(+)
>>
>> diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
>> index 69433e1..c6462cf 100644
>> --- a/drivers/media/i2c/ov9650.c
>> +++ b/drivers/media/i2c/ov9650.c
>> @@ -1374,6 +1374,38 @@ static int ov965x_open(struct v4l2_subdev *sd, struct 
>> v4l2_subdev_fh *fh)
>>   return 0;
>>  }
>>
>> +#ifdef CONFIG_VIDEO_ADV_DEBUG
>> +
>> +static int ov965x_g_register(struct v4l2_subdev *sd,
>> +  struct v4l2_dbg_register *reg)
>> +{
>> + struct i2c_client *client = v4l2_get_subdevdata(sd);
>> + u8 val = 0;
>> + int ret;
>> +
>> + if (reg->reg > 0xff)
>> + return -EINVAL;
>> +
>> + ret = ov965x_read(client, reg->reg, );
>> + reg->val = val;
>> + reg->size = 1;
>> +
>> + return ret;
>> +}
>> +
>> +static int ov965x_s_register(struct v4l2_subdev *sd,
>> +  const struct v4l2_dbg_register *reg)
>> +{
>> + struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> + if (reg->reg > 0xff || reg->val > 0xff)
>> + return -EINVAL;
>> +
>> + return ov965x_write(client, reg->reg, reg->val);
>> +}
>> +
>> +#endif
>> +
>>  static const struct v4l2_subdev_pad_ops ov965x_pad_ops = {
>>   .enum_mbus_code = ov965x_enum_mbus_code,
>>   .enum_frame_size = ov965x_enum_frame_sizes,
>> @@ -1397,6 +1429,10 @@ static const struct v4l2_subdev_core_ops 
>> ov965x_core_ops = {
>>   .log_status = v4l2_ctrl_subdev_log_status,
>>   .subscribe_event = v4l2_ctrl_subdev_subscribe_event,
>>   .unsubscribe_event = v4l2_event_subdev_unsubscribe,
>> +#ifdef CONFIG_VIDEO_ADV_DEBUG
>> + .g_register = ov965x_g_register,
>> + .s_register = ov965x_s_register,
>> +#endif
>>  };
>>
>>  static const struct v4l2_subdev_ops ov965x_subdev_ops = {
>> --
>> 2.7.4
>>
>
> --
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi


Re: [PATCH 2/8] media: v4l2-ioctl.h: convert debug into an enum of bits

2017-12-19 Thread Mauro Carvalho Chehab
Em Tue, 19 Dec 2017 16:12:35 +0200
Sakari Ailus  escreveu:

> Hi Laurent,
> 
> On Tue, Dec 19, 2017 at 04:02:02PM +0200, Laurent Pinchart wrote:
> > And furthermore using enum types in the uAPI is a bad idea as the enum size 
> > is 
> > architecture-dependent. That's why we use integer types in structures used 
> > as 
> > ioctl arguments.  
> 
> I guess we have an argeement on that, enums are a no-go for uAPI, for
> reasons not related to the topic at hand.

Huh? We're not talking about uAPI. This is kAPI. Using enums there is OK.

Thanks,
Mauro


Re: [PATCH 2/8] media: v4l2-ioctl.h: convert debug into an enum of bits

2017-12-19 Thread Mauro Carvalho Chehab
Em Tue, 19 Dec 2017 16:05:46 +0200
Laurent Pinchart  escreveu:

> On Tuesday, 19 December 2017 16:02:02 EET Laurent Pinchart wrote:
> > On Tuesday, 19 December 2017 13:39:27 EET Sakari Ailus wrote:  
> > > Hi Mauro,
> > > 
> > > On Mon, Dec 18, 2017 at 05:53:56PM -0200, Mauro Carvalho Chehab wrote:  
> > > > The V4L2_DEV_DEBUG_IOCTL macros actually define a bitmask,
> > > > but without using Kernel's modern standards. Also,
> > > > documentation looks akward.
> > > > 
> > > > So, convert them into an enum with valid bits, adding
> > > > the correspoinding kernel-doc documentation for it.  
> > > 
> > > The pattern of using bits for flags is a well established one and I
> > > wouldn't deviate from that by requiring the use of the BIT() macro. There
> > > are no benefits that I can see from here but the approach brings
> > > additional
> > > risks: misuse of the flags and mimicing the same risky pattern.
> > > 
> > > I'd also like to echo Laurent's concern that code is being changed in odd
> > > ways and not for itself, but due to deficiencies in documentation tools.
> > > 
> > > I believe the tooling has to be improved to address this properly. That
> > > only needs to done once, compared to changing all flag definitions to
> > > enums.  
> > 
> > That's my main concern too. We really must not sacrifice code readability or
> > writing ease in order to work around limitations of the documentation
> > system. For this reason I'm strongly opposed to patches 2 and 5 in this
> > series.  
> 
> And I forgot to mention patch 8/8. Let's drop those three and improve the 
> documentation system instead.

Are you volunteering yourself to write the kernel-doc patches? :-)

Thanks,
Mauro


[GIT PULL for 4.16] An ordinary pile of atomisp cleanups and fixes

2017-12-19 Thread Sakari Ailus
Hi Mauro,

Here's the regular pile of atomisp cleanups and some fixes, too.

Please pull.


The following changes since commit 8ea636dcecfa7b05d60309a50beabc5317a845bf:

  media: ir-spi: add SPDX identifier (2017-12-18 15:22:50 -0500)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git atomisp

for you to fetch changes up to 6a0ed1a9cf6a0679772688aaf1bfec2ccd22fd47:

  staging: atomisp2: replace DEVICE_ATTR with DEVICE_ATTR_RO (2017-12-19 
14:15:12 +0200)


Aishwarya Pant (1):
  staging: atomisp2: replace DEVICE_ATTR with DEVICE_ATTR_RO

Arnd Bergmann (1):
  staging: atomisp: convert timestamps to ktime_t

Jeremy Sowden (2):
  media: staging: atomisp: fix for sparse "using plain integer as NULL 
pointer" warnings.
  media: staging: atomisp: fixes for "symbol was not declared. Should it be 
static?" sparse warnings.

Riccardo Schirone (4):
  staging: add missing blank line after declarations in atomisp-ov5693
  staging: improve comments usage in atomisp-ov5693
  staging: improves comparisons readability in atomisp-ov5693
  staging: fix indentation in atomisp-ov5693

Sergiy Redko (1):
  Staging: media: atomisp: made function static

Sinan Kaya (1):
  atomisp: deprecate pci_get_bus_and_slot()

 drivers/staging/media/atomisp/i2c/ov2680.h |  1 -
 .../media/atomisp/i2c/ov5693/atomisp-ov5693.c  | 82 ++
 drivers/staging/media/atomisp/i2c/ov5693/ov5693.h  |  2 +-
 .../media/atomisp/pci/atomisp2/atomisp_v4l2.c  |  2 +-
 .../isp/kernels/eed1_8/ia_css_eed1_8.host.c| 24 +++
 .../css2400/runtime/debug/src/ia_css_debug.c   |  1 +
 .../isp_param/interface/ia_css_isp_param_types.h   |  2 +-
 .../staging/media/atomisp/pci/atomisp2/hmm/hmm.c   |  8 +--
 8 files changed, 72 insertions(+), 50 deletions(-)

-- 
Kind regards,

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


Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver

2017-12-19 Thread Fabio Estevam
On Tue, Dec 19, 2017 at 11:43 AM, Sakari Ailus  wrote:

> Both seem to exist. See e.g. c3a3d1d6b8b363a02234e5564692db3647f183e6 .

This patch fixes .h files to use /* SPDX style comment, which is the
recommendation.

.c files should use // SPDX style.


[GIT PULL for 4.16] Remove as3645a V4L2 driver

2017-12-19 Thread Sakari Ailus
Hi Mauro,

This set removes the as3645a V4L2 LED flash driver. The LED flash class
driver offering V4L2 API already exists, and should be used instead.

Please pull.


The following changes since commit 8ea636dcecfa7b05d60309a50beabc5317a845bf:

  media: ir-spi: add SPDX identifier (2017-12-18 15:22:50 -0500)

are available in the git repository at:

  ssh://linuxtv.org/git/sailus/media_tree.git as3645a-v4l2-remove

for you to fetch changes up to 09eb6ec7ad9f7301a12457369dd1373999d38aea:

  media: i2c: as3645a: Remove driver (2017-12-19 16:21:58 +0200)


Sakari Ailus (1):
  media: i2c: as3645a: Remove driver

 MAINTAINERS |   8 -
 drivers/media/i2c/Kconfig   |   8 -
 drivers/media/i2c/Makefile  |   1 -
 drivers/media/i2c/as3645a.c | 880 
 include/media/i2c/as3645a.h |  66 
 5 files changed, 963 deletions(-)
 delete mode 100644 drivers/media/i2c/as3645a.c
 delete mode 100644 include/media/i2c/as3645a.h

-- 
Kind regards,

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


Re: [PATCH 2/8] media: v4l2-ioctl.h: convert debug into an enum of bits

2017-12-19 Thread Sakari Ailus
Hi Laurent,

On Tue, Dec 19, 2017 at 04:02:02PM +0200, Laurent Pinchart wrote:
> And furthermore using enum types in the uAPI is a bad idea as the enum size 
> is 
> architecture-dependent. That's why we use integer types in structures used as 
> ioctl arguments.

I guess we have an argeement on that, enums are a no-go for uAPI, for
reasons not related to the topic at hand.

-- 
Sakari Ailus
sakari.ai...@linux.intel.com


Re: [PATCH 2/8] media: v4l2-ioctl.h: convert debug into an enum of bits

2017-12-19 Thread Laurent Pinchart
On Tuesday, 19 December 2017 16:02:02 EET Laurent Pinchart wrote:
> On Tuesday, 19 December 2017 13:39:27 EET Sakari Ailus wrote:
> > Hi Mauro,
> > 
> > On Mon, Dec 18, 2017 at 05:53:56PM -0200, Mauro Carvalho Chehab wrote:
> > > The V4L2_DEV_DEBUG_IOCTL macros actually define a bitmask,
> > > but without using Kernel's modern standards. Also,
> > > documentation looks akward.
> > > 
> > > So, convert them into an enum with valid bits, adding
> > > the correspoinding kernel-doc documentation for it.
> > 
> > The pattern of using bits for flags is a well established one and I
> > wouldn't deviate from that by requiring the use of the BIT() macro. There
> > are no benefits that I can see from here but the approach brings
> > additional
> > risks: misuse of the flags and mimicing the same risky pattern.
> > 
> > I'd also like to echo Laurent's concern that code is being changed in odd
> > ways and not for itself, but due to deficiencies in documentation tools.
> > 
> > I believe the tooling has to be improved to address this properly. That
> > only needs to done once, compared to changing all flag definitions to
> > enums.
> 
> That's my main concern too. We really must not sacrifice code readability or
> writing ease in order to work around limitations of the documentation
> system. For this reason I'm strongly opposed to patches 2 and 5 in this
> series.

And I forgot to mention patch 8/8. Let's drop those three and improve the 
documentation system instead.

> > Another point I want to make is that the uAPI definitions cannot be
> > changed: enums are thus an option in kAPI only.
> 
> And furthermore using enum types in the uAPI is a bad idea as the enum size
> is architecture-dependent. That's why we use integer types in structures
> used as ioctl arguments.
> 
> > Improved KernelDoc tools would thus also allow improving uAPI macro
> > documentation --- which is more important anyway.

-- 
Regards,

Laurent Pinchart



[linux-next:master 5319/5462] drivers/media/rc/lirc_dev.c:368:2: warning: 'txbuf' may be used uninitialized in this function

2017-12-19 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git 
master
head:   a5791b188fb25ff731d01d1c463b01a99c58f930
commit: d60ea519eb2fbee045ca18a26bd37d5949ac4f87 [5319/5462] Merge 
remote-tracking branch 'v4l-dvb/master'
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout d60ea519eb2fbee045ca18a26bd37d5949ac4f87
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/media/rc/lirc_dev.c: In function 'ir_lirc_transmit_ir':
>> drivers/media/rc/lirc_dev.c:368:2: warning: 'txbuf' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 kfree(txbuf);
 ^~~~

vim +/txbuf +368 drivers/media/rc/lirc_dev.c

74c839b2f drivers/media/rc/lirc_dev.c Sean Young  2017-01-30  228  
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  229  
static ssize_t ir_lirc_transmit_ir(struct file *file, const char __user *buf,
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  230   
   size_t n, loff_t *ppos)
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  231  {
7e45d660e drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  232   
struct lirc_fh *fh = file->private_data;
7e45d660e drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  233   
struct rc_dev *dev = fh->rc;
a74b2bff5 drivers/media/rc/lirc_dev.c Sean Young  2017-12-13  234   
unsigned int *txbuf;
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  235   
struct ir_raw_event *raw = NULL;
4957133fe drivers/media/rc/lirc_dev.c Sean Young  2017-11-04  236   
ssize_t ret;
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  237   
size_t count;
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  238   
ktime_t start;
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  239   
s64 towait;
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  240   
unsigned int duration = 0; /* signal duration in us */
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  241   
int i;
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  242  
4957133fe drivers/media/rc/lirc_dev.c Sean Young  2017-11-04  243   
ret = mutex_lock_interruptible(>lock);
4957133fe drivers/media/rc/lirc_dev.c Sean Young  2017-11-04  244   
if (ret)
4957133fe drivers/media/rc/lirc_dev.c Sean Young  2017-11-04  245   
return ret;
4a62a5ab5 drivers/media/IR/lirc_dev.c Jarod Wilson2010-07-03  246  
4957133fe drivers/media/rc/lirc_dev.c Sean Young  2017-11-04  247   
if (!dev->registered) {
4957133fe drivers/media/rc/lirc_dev.c Sean Young  2017-11-04  248   
ret = -ENODEV;
a74b2bff5 drivers/media/rc/lirc_dev.c Sean Young  2017-12-13  249   
goto out_unlock;
4a62a5ab5 drivers/media/IR/lirc_dev.c Jarod Wilson2010-07-03  250   
}
4a62a5ab5 drivers/media/IR/lirc_dev.c Jarod Wilson2010-07-03  251  
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  252   
start = ktime_get();
4a62a5ab5 drivers/media/IR/lirc_dev.c Jarod Wilson2010-07-03  253  
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  254   
if (!dev->tx_ir) {
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  255   
ret = -EINVAL;
a74b2bff5 drivers/media/rc/lirc_dev.c Sean Young  2017-12-13  256   
goto out_unlock;
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  257   
}
4a62a5ab5 drivers/media/IR/lirc_dev.c Jarod Wilson2010-07-03  258  
7e45d660e drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  259   
if (fh->send_mode == LIRC_MODE_SCANCODE) {
42e0442f8 drivers/media/rc/lirc_dev.c Sean Young  2017-11-02  260   
struct lirc_scancode scan;
3381b779a drivers/media/rc/lirc_dev.c David Härdeman  2017-06-30  261  
4957133fe drivers/media/rc/lirc_dev.c Sean Young  2017-11-04  262   
if (n != sizeof(scan)) {
4957133fe drivers/media/rc/lirc_dev.c Sean Young  2017-11-04  263   
ret = -EINVAL;
a74b2bff5 drivers/media/rc/lirc_dev.c Sean Young  2017-12-13  264   
goto out_unlock;
3381b779a drivers/media/rc/lirc_dev.c David Härdeman  2017-06-30  265   
}
3381b779a drivers/media/rc/lirc_dev.c David Härdeman  2017-06-30  266  
4957133fe 

Re: [PATCH 2/8] media: v4l2-ioctl.h: convert debug into an enum of bits

2017-12-19 Thread Laurent Pinchart
On Tuesday, 19 December 2017 13:39:27 EET Sakari Ailus wrote:
> Hi Mauro,
> 
> On Mon, Dec 18, 2017 at 05:53:56PM -0200, Mauro Carvalho Chehab wrote:
> > The V4L2_DEV_DEBUG_IOCTL macros actually define a bitmask,
> > but without using Kernel's modern standards. Also,
> > documentation looks akward.
> > 
> > So, convert them into an enum with valid bits, adding
> > the correspoinding kernel-doc documentation for it.
> 
> The pattern of using bits for flags is a well established one and I
> wouldn't deviate from that by requiring the use of the BIT() macro. There
> are no benefits that I can see from here but the approach brings additional
> risks: misuse of the flags and mimicing the same risky pattern.
> 
> I'd also like to echo Laurent's concern that code is being changed in odd
> ways and not for itself, but due to deficiencies in documentation tools.
> 
> I believe the tooling has to be improved to address this properly. That
> only needs to done once, compared to changing all flag definitions to
> enums.

That's my main concern too. We really must not sacrifice code readability or 
writing ease in order to work around limitations of the documentation system. 
For this reason I'm strongly opposed to patches 2 and 5 in this series.

> Another point I want to make is that the uAPI definitions cannot be
> changed: enums are thus an option in kAPI only.

And furthermore using enum types in the uAPI is a bad idea as the enum size is 
architecture-dependent. That's why we use integer types in structures used as 
ioctl arguments.

> Improved KernelDoc tools would thus also allow improving uAPI macro
> documentation --- which is more important anyway.

-- 
Regards,

Laurent Pinchart



Re: [PATCH V2 1/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_reset

2017-12-19 Thread Jia-Ju Bai


On 2017/12/19 18:43, Fabien DESSENNE wrote:

Hi,


On 16/12/17 12:54, Jia-Ju Bai wrote:

The driver may sleep under a spinlock.
The function call path is:
bdisp_device_run (acquire the spinlock)
bdisp_hw_reset
  msleep --> may sleep

To fix it, readl_poll_timeout_atomic is used to replace msleep.

This bug is found by my static analysis tool(DSAC) and
checked by my code review.

Signed-off-by: Jia-Ju Bai 
---
   drivers/media/platform/sti/bdisp/bdisp-hw.c |   16 
   1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/sti/bdisp/bdisp-hw.c 
b/drivers/media/platform/sti/bdisp/bdisp-hw.c
index b7892f3..e94a371 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-hw.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-hw.c
@@ -5,6 +5,7 @@
*/
   
   #include 

This delay.h include is no more needed, remove it.


+#include 
   
   #include "bdisp.h"

   #include "bdisp-filter.h"
@@ -366,7 +367,7 @@ struct bdisp_filter_addr {
*/
   int bdisp_hw_reset(struct bdisp_dev *bdisp)
   {
-   unsigned int i;
+   u32 tmp;
   
   	dev_dbg(bdisp->dev, "%s\n", __func__);
   
@@ -379,15 +380,14 @@ int bdisp_hw_reset(struct bdisp_dev *bdisp)

writel(0, bdisp->regs + BLT_CTL);
   
   	/* Wait for reset done */

-   for (i = 0; i < POLL_RST_MAX; i++) {
-   if (readl(bdisp->regs + BLT_STA1) & BLT_STA1_IDLE)
-   break;
-   msleep(POLL_RST_DELAY_MS);
-   }
-   if (i == POLL_RST_MAX)

As recommended by Mauro, please add this comment:
Despite the large timeout, most of the time the reset happens without
needing any delays


+   if (readl_poll_timeout_atomic(bdisp->regs + BLT_STA1, tmp,
+   (tmp & BLT_STA1_IDLE), POLL_RST_DELAY_MS,
+   POLL_RST_DELAY_MS * POLL_RST_MAX)) {

read_poll_timeout expects US timings, not MS.


dev_err(bdisp->dev, "Reset timeout\n");
+   return -EAGAIN;
+   }
   
-	return (i == POLL_RST_MAX) ? -EAGAIN : 0;

+   return 0;
   }
   
   /**


Hi,

Okay, I have submitted a new patch according to your advice :)


Thanks,
Jia-Ju Bai


[PATCH V3 1/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_reset

2017-12-19 Thread Jia-Ju Bai
The driver may sleep under a spinlock.
The function call path is:
bdisp_device_run (acquire the spinlock)
  bdisp_hw_reset
msleep --> may sleep

To fix it, readl_poll_timeout_atomic is used to replace msleep.

This bug is found by my static analysis tool(DSAC) and
checked by my code review.

Signed-off-by: Jia-Ju Bai 
---
 drivers/media/platform/sti/bdisp/bdisp-hw.c |   23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/sti/bdisp/bdisp-hw.c 
b/drivers/media/platform/sti/bdisp/bdisp-hw.c
index b7892f3..b63d9c9 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-hw.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-hw.c
@@ -4,7 +4,7 @@
  * License terms:  GNU General Public License (GPL), version 2
  */
 
-#include 
+#include 
 
 #include "bdisp.h"
 #include "bdisp-filter.h"
@@ -15,7 +15,7 @@
 
 /* Reset & boot poll config */
 #define POLL_RST_MAX50
-#define POLL_RST_DELAY_MS   20
+#define POLL_RST_DELAY_US   2
 
 enum bdisp_target_plan {
BDISP_RGB,
@@ -366,7 +366,7 @@ struct bdisp_filter_addr {
  */
 int bdisp_hw_reset(struct bdisp_dev *bdisp)
 {
-   unsigned int i;
+   u32 tmp;
 
dev_dbg(bdisp->dev, "%s\n", __func__);
 
@@ -378,16 +378,17 @@ int bdisp_hw_reset(struct bdisp_dev *bdisp)
   bdisp->regs + BLT_CTL);
writel(0, bdisp->regs + BLT_CTL);
 
-   /* Wait for reset done */
-   for (i = 0; i < POLL_RST_MAX; i++) {
-   if (readl(bdisp->regs + BLT_STA1) & BLT_STA1_IDLE)
-   break;
-   msleep(POLL_RST_DELAY_MS);
-   }
-   if (i == POLL_RST_MAX)
+   /* Wait for reset done.
+* Despite the large timeout, most of the time the reset happens without
+* needing any delays */
+   if (readl_poll_timeout_atomic(bdisp->regs + BLT_STA1, tmp,
+   (tmp & BLT_STA1_IDLE), POLL_RST_DELAY_US,
+   POLL_RST_DELAY_US * POLL_RST_MAX)) {
dev_err(bdisp->dev, "Reset timeout\n");
+   return -EAGAIN;
+   }
 
-   return (i == POLL_RST_MAX) ? -EAGAIN : 0;
+   return 0;
 }
 
 /**
-- 
1.7.9.5



Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

2017-12-19 Thread Laurent Pinchart
Hi Sakari,

On Tuesday, 19 December 2017 15:28:55 EET Sakari Ailus wrote:
> On Tue, Dec 19, 2017 at 03:07:41PM +0200, Laurent Pinchart wrote:
> > On Tuesday, 19 December 2017 13:57:42 EET jacopo mondi wrote:

[snip]

> >> Ok, actually parse_dt() and parse_platform_data() behaves differently.
> >> The former returns error if no subdevices are connected to CEU, the
> >> latter returns 0. That's wrong.
> >> 
> >> I wonder what's the correct behavior here. Other mainline drivers I
> >> looked into (pxa_camera and atmel-isc) behaves differently from each
> >> other, so I guess this is up to each platform to decide.
> > 
> > No, what it means is that we've failed to standardize it, not that it
> > shouldn't be standardized :-)
> > 
> >> Also, the CEU can accept one single input (and I made it clear
> >> in DT bindings documentation saying it accepts a single endpoint,
> >> while I'm parsing all the available ones in driver, I will fix this)
> >> but as it happens on Migo-R, there could be HW hacks to share the input
> >> lines between multiple subdevices. Should I accept it from dts as well?
> >> 
> >> So:
> >> 1) Should we fail to probe if no subdevices are connected?
> > 
> > While the CEU itself would be fully functional without a subdev, in
> > practice it would be of no use. I would thus fail probing.
> > 
> >> 2) Should we accept more than 1 subdevice from dts as it happens right
> >> now for platform data?
> > 
> > We need to support multiple connected devices, as some of the boards
> > require that. What I'm not sure about is whether the multiplexer on the
> > Migo-R board should be modeled as a subdevice. We could in theory connect
> > multiple sensors to the CEU input signals without any multiplexer as long
> > as all but one are in reset with their outputs in a high impedance state.
> > As that wouldn' require a multiplexer we would need to support multiple
> > endpoints in the CEU port. We could then support Migo-R the same way,
> > making the multiplexer transparent.
> > 
> > Sakari, what would you do here ?
> 
> We do have:
> 
> drivers/media/platform/video-mux.c
> 
> What is not addressed right now are the CSI-2 bus parameters, if the mux is
> just a passive switch. This could be done using the frame descriptors.

We're talking about a parallel bus here so that shouldn't be a problem.

Our issue is that the same GPIO controls both the switch and the power down 
signal of one of the sensors. The hardware has been designed to be as 
transparent as possible, but that creates issues as Linux doesn't support 
share GPIOs.

-- 
Regards,

Laurent Pinchart



Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver

2017-12-19 Thread Sakari Ailus
On Tue, Dec 19, 2017 at 11:19:06AM -0200, Fabio Estevam wrote:
> Hi Sakari,
> 
> On Tue, Dec 19, 2017 at 11:05 AM, Sakari Ailus  wrote:
> 
> > I guess it depends on who do you ask and when. Looking at what has been
> > recently merged to media tree master, the latter is preferred.
> 
> Just did 'git grep SPDX drivers/media'
> 
> and it consistently shows // SPDX style for C files.

Both seem to exist. See e.g. c3a3d1d6b8b363a02234e5564692db3647f183e6 .

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


Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

2017-12-19 Thread Sakari Ailus
Heippa!

On Tue, Dec 19, 2017 at 03:07:41PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
> 
> (CC'ing Sakari)
> 
> On Tuesday, 19 December 2017 13:57:42 EET jacopo mondi wrote:
> > On Mon, Dec 11, 2017 at 06:15:23PM +0200, Laurent Pinchart wrote:
> > > Hi Jacopo,
> > > 
> > > Thank you for the patch.
> > > 
> > > [snip]
> > > 
> > >> +static int ceu_sensor_bound(struct v4l2_async_notifier *notifier,
> > >> +struct v4l2_subdev *v4l2_sd,
> > >> +struct v4l2_async_subdev *asd)
> > >> +{
> > >> +struct v4l2_device *v4l2_dev = notifier->v4l2_dev;
> > >> +struct ceu_device *ceudev = v4l2_to_ceu(v4l2_dev);
> > >> +struct ceu_subdev *ceu_sd = to_ceu_subdev(asd);
> > >> +
> > >> +if (video_is_registered(>vdev)) {
> > >> +v4l2_err(>v4l2_dev,
> > >> + "Video device registered before this 
> > >> sub-device.\n");
> > >> +return -EBUSY;
> > > 
> > > Can this happen ?
> > > 
> > >> +}
> > >> +
> > >> +/* Assign subdevices in the order they appear */
> > >> +ceu_sd->v4l2_sd = v4l2_sd;
> > >> +ceudev->num_sd++;
> > >> +
> > >> +return 0;
> > >> +}
> > >> +
> > > > +static int ceu_sensor_complete(struct v4l2_async_notifier *notifier)
> > > > +{
> > > > +   struct v4l2_device *v4l2_dev = notifier->v4l2_dev;
> > > > +   struct ceu_device *ceudev = v4l2_to_ceu(v4l2_dev);
> > > > +   struct video_device *vdev = >vdev;
> > > > +   struct vb2_queue *q = >vb2_vq;
> > > > +   struct v4l2_subdev *v4l2_sd;
> > > > +   int ret;
> > > > +
> > > > +   /* Initialize vb2 queue */
> > > > +   q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
> > > > +   q->io_modes = VB2_MMAP | VB2_USERPTR;
> > > 
> > > No dmabuf ?
> > > 
> > > > +   q->drv_priv = ceudev;
> > > > +   q->ops  = _videobuf_ops;
> > > > +   q->mem_ops  = _dma_contig_memops;
> > > > +   q->buf_struct_size  = sizeof(struct ceu_buffer);
> > > > +   q->timestamp_flags  = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> > > > +   q->lock = >mlock;
> > > > +   q->dev  = ceudev->v4l2_dev.dev;
> > > 
> > > [snip]
> > > 
> > > > +static int ceu_probe(struct platform_device *pdev)
> > > > +{
> > > > +   struct device *dev = >dev;
> > > > +   struct ceu_device *ceudev;
> > > > +   struct resource *res;
> > > > +   void __iomem *base;
> > > > +   unsigned int irq;
> > > > +   int num_sd;
> > > > +   int ret;
> > > > +
> > > > +   ceudev = kzalloc(sizeof(*ceudev), GFP_KERNEL);
> > > 
> > > The memory is freed in ceu_vdev_release() as expected, but that will only
> > > work if the video device is registered. If the subdevs are never bound,
> > > the ceudev memory will be leaked if you unbind the CEU device from its
> > > driver. In my opinion this calls for registering the video device at
> > > probe time (although Hans disagrees).
> > > 
> > > > +   if (!ceudev)
> > > > +   return -ENOMEM;
> > > > +
> > > > +   platform_set_drvdata(pdev, ceudev);
> > > > +   dev_set_drvdata(dev, ceudev);
> > > 
> > > You don't need the second line, platform_set_drvdata() is a wrapper around
> > > dev_set_drvdata().
> > > 
> > > > +   ceudev->dev = dev;
> > > > +
> > > > +   INIT_LIST_HEAD(>capture);
> > > > +   spin_lock_init(>lock);
> > > > +   mutex_init(>mlock);
> > > > +
> > > > +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > +   if (IS_ERR(res))
> > > > +   return PTR_ERR(res);
> > > 
> > > No need for error handling here, devm_ioremap_resource() will check the
> > > res
> > > pointer.
> > > 
> > > > +   base = devm_ioremap_resource(dev, res);
> > > 
> > > You can assign ceudev->base directly and remove the base local variable.
> > > 
> > > > +   if (IS_ERR(base))
> > > > +   return PTR_ERR(base);
> > > > +   ceudev->base = base;
> > > > +
> > > > +   ret = platform_get_irq(pdev, 0);
> > > > +   if (ret < 0) {
> > > > +   dev_err(dev, "failed to get irq: %d\n", ret);
> > > > +   return ret;
> > > > +   }
> > > > +   irq = ret;
> > > > +
> > > > +   ret = devm_request_irq(dev, irq, ceu_irq,
> > > > +  0, dev_name(dev), ceudev);
> > > > +   if (ret) {
> > > > +   dev_err(>dev, "Unable to register CEU 
> > > > interrupt.\n");
> > > > +   return ret;
> > > > +   }
> > > > +
> > > > +   pm_suspend_ignore_children(dev, true);
> > > > +   pm_runtime_enable(dev);
> > > > +
> > > > +   ret = v4l2_device_register(dev, >v4l2_dev);
> > > > +   if (ret)
> > > > +   goto error_pm_disable;
> > > > +
> > > > +   if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> > > > +   num_sd = ceu_parse_dt(ceudev);
> > > > 

Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver

2017-12-19 Thread Fabio Estevam
Hi Sakari,

On Tue, Dec 19, 2017 at 11:05 AM, Sakari Ailus  wrote:

> I guess it depends on who do you ask and when. Looking at what has been
> recently merged to media tree master, the latter is preferred.

Just did 'git grep SPDX drivers/media'

and it consistently shows // SPDX style for C files.


Re: [PATCH/RFC 1/4] drm: Add colorkey properties

2017-12-19 Thread Laurent Pinchart
Hi Neil,

On Tuesday, 19 December 2017 11:00:28 EET Neil Armstrong wrote:
> On 17/12/2017 01:17, Laurent Pinchart wrote:
> > Color keying is the action of replacing pixels matching a given color
> > (or range of colors) with transparent pixels in an overlay when
> > performing blitting. Depending on the hardware capabilities, the
> > matching pixel can either become fully transparent, or gain a
> > programmable alpha value.
> > 
> > Color keying is found in a large number of devices whose capabilities
> > often differ, but they still have enough common features in range to
> > standardize color key properties. This commit adds four properties
> > related to color keying named colorkey.min, colorkey.max, colorkey.alpha
> > and colorkey.mode. Additional properties can be defined by drivers to
> > expose device-specific features.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  drivers/gpu/drm/drm_atomic.c |  16 +++
> >  drivers/gpu/drm/drm_blend.c  | 108 ++
> >  include/drm/drm_blend.h  |   4 ++
> >  include/drm/drm_plane.h  |  28 ++-
> >  4 files changed, 155 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index 37445d50816a..4f57ec25e04d 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -756,6 +756,14 @@ static int drm_atomic_plane_set_property(struct

[snip]

> > +int drm_plane_create_colorkey_properties(struct drm_plane *plane,
> > +const struct drm_prop_enum_list *modes,
> > +unsigned int num_modes, bool replace)
> > +{
> > +#define CREATE_COLORKEY_PROP(plane, name, type, args...) ({
> >\
> > +   prop = drm_property_create_##type(plane->dev, 0, "colorkey." #name,
\
> > + args);   \
> > +   if (prop) {\
> > +   drm_object_attach_property(>base, prop, 0); \
> > +   plane->colorkey.name##_property = prop;\
> > +   }  \
> > +   prop;  \
> > +})
> > +
> > +   struct drm_property *prop;
> > +
> > +   /*
> > +* A minimum of two modes are required, with the first mode must named
> > +* "disabled".
> > +*/
> > +   if (!modes || num_modes == 0 || strcmp(modes[0].name, "disabled"))
> > +   return -EINVAL;
> > +
> > +   prop = CREATE_COLORKEY_PROP(plane, mode, enum, modes, num_modes);
> > +   if (!prop)
> > +   return -ENOMEM;
> > +
> > +   prop = CREATE_COLORKEY_PROP(plane, min, range, 0, U64_MAX);
> > +   if (!prop)
> > +   return -ENOMEM;
> > +
> > +   prop = CREATE_COLORKEY_PROP(plane, max, range, 0, U64_MAX);
> > +   if (!prop)
> > +   return -ENOMEM;
> > +
> > +   if (replace) {
> > +   prop = CREATE_COLORKEY_PROP(plane, value, range, 0, U64_MAX);
> > +   if (!prop)
> > +   return -ENOMEM;
> > +   }
> 
> #undef CREATE_COLORKEY_PROP ?

That's a good idea, I'll fix it in the next version.

> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(drm_plane_create_colorkey_properties);

[snip]

> Apart from that,
> 
> Reviewed-by: Neil Armstrong 

-- 
Regards,

Laurent Pinchart



Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver

2017-12-19 Thread Sakari Ailus
On Tue, Dec 19, 2017 at 10:50:44AM -0200, Fabio Estevam wrote:
> Hi Sakari,
> 
> On Tue, Dec 19, 2017 at 7:22 AM, Sakari Ailus  wrote:
> > On Mon, Dec 11, 2017 at 09:31:46AM +0800, Wenyou Yang wrote:
> >> The ov7740 (color) image sensor is a high performance VGA CMOS
> >> image snesor, which supports for output formats: RAW RGB and YUV
> >> and image sizes: VGA, and QVGA, CIF and any size smaller.
> >>
> >> Signed-off-by: Songjun Wu 
> >> Signed-off-by: Wenyou Yang 
> >
> > Applied with this diff:
> >
> > diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
> > index 0308ba437bbb..041a77039d70 100644
> > --- a/drivers/media/i2c/ov7740.c
> > +++ b/drivers/media/i2c/ov7740.c
> > @@ -1,5 +1,7 @@
> > -// SPDX-License-Identifier: GPL-2.0
> > -// Copyright (c) 2017 Microchip Corporation.
> > +/*
> > + * SPDX-License-Identifier: GPL-2.0
> > + * Copyright (c) 2017 Microchip Corporation.
> > + */
> 
> The original version is the recommended format for the SPDX identifier.

I guess it depends on who do you ask and when. Looking at what has been
recently merged to media tree master, the latter is preferred.

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


Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

2017-12-19 Thread Laurent Pinchart
Hi Jacopo,

(CC'ing Sakari)

On Tuesday, 19 December 2017 13:57:42 EET jacopo mondi wrote:
> On Mon, Dec 11, 2017 at 06:15:23PM +0200, Laurent Pinchart wrote:
> > Hi Jacopo,
> > 
> > Thank you for the patch.
> > 
> > [snip]
> > 
> >> +static int ceu_sensor_bound(struct v4l2_async_notifier *notifier,
> >> +  struct v4l2_subdev *v4l2_sd,
> >> +  struct v4l2_async_subdev *asd)
> >> +{
> >> +  struct v4l2_device *v4l2_dev = notifier->v4l2_dev;
> >> +  struct ceu_device *ceudev = v4l2_to_ceu(v4l2_dev);
> >> +  struct ceu_subdev *ceu_sd = to_ceu_subdev(asd);
> >> +
> >> +  if (video_is_registered(>vdev)) {
> >> +  v4l2_err(>v4l2_dev,
> >> +   "Video device registered before this sub-device.\n");
> >> +  return -EBUSY;
> > 
> > Can this happen ?
> > 
> >> +  }
> >> +
> >> +  /* Assign subdevices in the order they appear */
> >> +  ceu_sd->v4l2_sd = v4l2_sd;
> >> +  ceudev->num_sd++;
> >> +
> >> +  return 0;
> >> +}
> >> +
> > > +static int ceu_sensor_complete(struct v4l2_async_notifier *notifier)
> > > +{
> > > + struct v4l2_device *v4l2_dev = notifier->v4l2_dev;
> > > + struct ceu_device *ceudev = v4l2_to_ceu(v4l2_dev);
> > > + struct video_device *vdev = >vdev;
> > > + struct vb2_queue *q = >vb2_vq;
> > > + struct v4l2_subdev *v4l2_sd;
> > > + int ret;
> > > +
> > > + /* Initialize vb2 queue */
> > > + q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
> > > + q->io_modes = VB2_MMAP | VB2_USERPTR;
> > 
> > No dmabuf ?
> > 
> > > + q->drv_priv = ceudev;
> > > + q->ops  = _videobuf_ops;
> > > + q->mem_ops  = _dma_contig_memops;
> > > + q->buf_struct_size  = sizeof(struct ceu_buffer);
> > > + q->timestamp_flags  = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> > > + q->lock = >mlock;
> > > + q->dev  = ceudev->v4l2_dev.dev;
> > 
> > [snip]
> > 
> > > +static int ceu_probe(struct platform_device *pdev)
> > > +{
> > > + struct device *dev = >dev;
> > > + struct ceu_device *ceudev;
> > > + struct resource *res;
> > > + void __iomem *base;
> > > + unsigned int irq;
> > > + int num_sd;
> > > + int ret;
> > > +
> > > + ceudev = kzalloc(sizeof(*ceudev), GFP_KERNEL);
> > 
> > The memory is freed in ceu_vdev_release() as expected, but that will only
> > work if the video device is registered. If the subdevs are never bound,
> > the ceudev memory will be leaked if you unbind the CEU device from its
> > driver. In my opinion this calls for registering the video device at
> > probe time (although Hans disagrees).
> > 
> > > + if (!ceudev)
> > > + return -ENOMEM;
> > > +
> > > + platform_set_drvdata(pdev, ceudev);
> > > + dev_set_drvdata(dev, ceudev);
> > 
> > You don't need the second line, platform_set_drvdata() is a wrapper around
> > dev_set_drvdata().
> > 
> > > + ceudev->dev = dev;
> > > +
> > > + INIT_LIST_HEAD(>capture);
> > > + spin_lock_init(>lock);
> > > + mutex_init(>mlock);
> > > +
> > > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > + if (IS_ERR(res))
> > > + return PTR_ERR(res);
> > 
> > No need for error handling here, devm_ioremap_resource() will check the
> > res
> > pointer.
> > 
> > > + base = devm_ioremap_resource(dev, res);
> > 
> > You can assign ceudev->base directly and remove the base local variable.
> > 
> > > + if (IS_ERR(base))
> > > + return PTR_ERR(base);
> > > + ceudev->base = base;
> > > +
> > > + ret = platform_get_irq(pdev, 0);
> > > + if (ret < 0) {
> > > + dev_err(dev, "failed to get irq: %d\n", ret);
> > > + return ret;
> > > + }
> > > + irq = ret;
> > > +
> > > + ret = devm_request_irq(dev, irq, ceu_irq,
> > > +0, dev_name(dev), ceudev);
> > > + if (ret) {
> > > + dev_err(>dev, "Unable to register CEU interrupt.\n");
> > > + return ret;
> > > + }
> > > +
> > > + pm_suspend_ignore_children(dev, true);
> > > + pm_runtime_enable(dev);
> > > +
> > > + ret = v4l2_device_register(dev, >v4l2_dev);
> > > + if (ret)
> > > + goto error_pm_disable;
> > > +
> > > + if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> > > + num_sd = ceu_parse_dt(ceudev);
> > > + } else if (dev->platform_data) {
> > > + num_sd = ceu_parse_platform_data(ceudev, dev->platform_data);
> > > + } else {
> > > + dev_err(dev, "CEU platform data not set and no OF support\n");
> > > + ret = -EINVAL;
> > > + goto error_v4l2_unregister;
> > > + }
> > > +
> > > + if (num_sd < 0) {
> > > + ret = num_sd;
> > > + goto error_v4l2_unregister;
> > > + } else if (num_sd == 0)
> > > + return 0;
> > 
> > You need braces around the second statement too.
> 
> Ok, actually parse_dt() and parse_platform_data() behaves differently.
> The former returns error if no subdevices are connected to CEU, the
> latter returns 0. That's wrong.
> 
> I wonder what's the correct behavior here. Other mainline drivers I
> looked into 

Re: [trivial PATCH] treewide: Align function definition open/close braces

2017-12-19 Thread Mauro Carvalho Chehab
Em Sun, 17 Dec 2017 16:28:44 -0800
Joe Perches  escreveu:

> Some functions definitions have either the initial open brace and/or
> the closing brace outside of column 1.
> 
> Move those braces to column 1.
> 
> This allows various function analyzers like gnu complexity to work
> properly for these modified functions.
> 
> Miscellanea:
> 
> o Remove extra trailing ; and blank line from xfs_agf_verify
> 
> Signed-off-by: Joe Perches 

For the media patch:

Acked-by: Mauro Carvalho Chehab 

> ---
> git diff -w shows no difference other than the above 'Miscellanea'
> 
> (this is against -next, but it applies against Linus' tree
>  with a couple offsets)
> 
>  arch/x86/include/asm/atomic64_32.h   |  2 +-
>  drivers/acpi/custom_method.c |  2 +-
>  drivers/acpi/fan.c   |  2 +-
>  drivers/gpu/drm/amd/display/dc/core/dc.c |  2 +-
>  drivers/media/i2c/msp3400-kthreads.c |  2 +-
>  drivers/message/fusion/mptsas.c  |  2 +-
>  drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c |  2 +-
>  drivers/net/wireless/ath/ath9k/xmit.c|  2 +-
>  drivers/platform/x86/eeepc-laptop.c  |  2 +-
>  drivers/rtc/rtc-ab-b5ze-s3.c |  2 +-
>  drivers/scsi/dpt_i2o.c   |  2 +-
>  drivers/scsi/sym53c8xx_2/sym_glue.c  |  2 +-
>  fs/locks.c   |  2 +-
>  fs/ocfs2/stack_user.c|  2 +-
>  fs/xfs/libxfs/xfs_alloc.c|  5 ++---
>  fs/xfs/xfs_export.c  |  2 +-
>  kernel/audit.c   |  6 +++---
>  kernel/trace/trace_printk.c  |  4 ++--
>  lib/raid6/sse2.c | 14 +++---
>  sound/soc/fsl/fsl_dma.c  |  2 +-
>  20 files changed, 30 insertions(+), 31 deletions(-)
> 
> diff --git a/arch/x86/include/asm/atomic64_32.h 
> b/arch/x86/include/asm/atomic64_32.h
> index 97c46b8169b7..d4d4883080fa 100644
> --- a/arch/x86/include/asm/atomic64_32.h
> +++ b/arch/x86/include/asm/atomic64_32.h
> @@ -122,7 +122,7 @@ static inline long long atomic64_read(const atomic64_t *v)
>   long long r;
>   alternative_atomic64(read, "=" (r), "c" (v) : "memory");
>   return r;
> - }
> +}
>  
>  /**
>   * atomic64_add_return - add and return
> diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
> index c68e72414a67..e967c1173ba3 100644
> --- a/drivers/acpi/custom_method.c
> +++ b/drivers/acpi/custom_method.c
> @@ -94,7 +94,7 @@ static void __exit acpi_custom_method_exit(void)
>  {
>   if (cm_dentry)
>   debugfs_remove(cm_dentry);
> - }
> +}
>  
>  module_init(acpi_custom_method_init);
>  module_exit(acpi_custom_method_exit);
> diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
> index 6cf4988206f2..3563103590c6 100644
> --- a/drivers/acpi/fan.c
> +++ b/drivers/acpi/fan.c
> @@ -219,7 +219,7 @@ fan_set_cur_state(struct thermal_cooling_device *cdev, 
> unsigned long state)
>   return fan_set_state_acpi4(device, state);
>   else
>   return fan_set_state(device, state);
> - }
> +}
>  
>  static const struct thermal_cooling_device_ops fan_cooling_ops = {
>   .get_max_state = fan_get_max_state,
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index d1488d5ee028..1e0d1e7c5324 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -461,7 +461,7 @@ static void disable_dangling_plane(struct dc *dc, struct 
> dc_state *context)
>   
> **/
>  
>  struct dc *dc_create(const struct dc_init_data *init_params)
> - {
> +{
>   struct dc *dc = kzalloc(sizeof(*dc), GFP_KERNEL);
>   unsigned int full_pipe_count;
>  
> diff --git a/drivers/media/i2c/msp3400-kthreads.c 
> b/drivers/media/i2c/msp3400-kthreads.c
> index 4dd01e9f553b..dc6cb8d475b3 100644
> --- a/drivers/media/i2c/msp3400-kthreads.c
> +++ b/drivers/media/i2c/msp3400-kthreads.c
> @@ -885,7 +885,7 @@ static int msp34xxg_modus(struct i2c_client *client)
>  }
>  
>  static void msp34xxg_set_source(struct i2c_client *client, u16 reg, int in)
> - {
> +{
>   struct msp_state *state = to_state(i2c_get_clientdata(client));
>   int source, matrix;
>  
> diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
> index 345f6035599e..69a62d23514b 100644
> --- a/drivers/message/fusion/mptsas.c
> +++ b/drivers/message/fusion/mptsas.c
> @@ -2968,7 +2968,7 @@ mptsas_exp_repmanufacture_info(MPT_ADAPTER *ioc,
>   mutex_unlock(>sas_mgmt.mutex);
>  out:
>   return ret;
> - }
> +}
>  
>  static void
>  

Re: [PATCH v4 6/6] [media] cxusb: add analog mode support for Medion MD95700

2017-12-19 Thread Mauro Carvalho Chehab
Em Sun, 17 Dec 2017 19:47:25 +0100
"Maciej S. Szmigiero"  escreveu:

> This patch adds support for analog part of Medion 95700 in the cxusb
> driver.
> 
> What works:
> * Video capture at various sizes with sequential fields,
> * Input switching (TV Tuner, Composite, S-Video),
> * TV and radio tuning,
> * Video standard switching and auto detection,
> * Radio mode switching (stereo / mono),
> * Unplugging while capturing,
> * DVB / analog coexistence,
> * Raw BT.656 stream support.
> 
> What does not work yet:
> * Audio,
> * VBI,
> * Picture controls.

Patches 1 to 5 look OK to me (although checkpatch do a few complains).

This one, however, require some adjustments.

I'd like to also have Hans eyes on it, as he's doing a lot more V4L2
new driver reviews than me nowadays.

> 
> Signed-off-by: Maciej S. Szmigiero 
> ---
>  drivers/media/usb/dvb-usb/Kconfig|8 +-
>  drivers/media/usb/dvb-usb/Makefile   |2 +-
>  drivers/media/usb/dvb-usb/cxusb-analog.c | 1923 
> ++
>  drivers/media/usb/dvb-usb/cxusb.c|3 +-
>  drivers/media/usb/dvb-usb/cxusb.h|  114 +-
>  5 files changed, 2031 insertions(+), 19 deletions(-)
>  create mode 100644 drivers/media/usb/dvb-usb/cxusb-analog.c
> 
> diff --git a/drivers/media/usb/dvb-usb/Kconfig 
> b/drivers/media/usb/dvb-usb/Kconfig
> index 2651ae277347..85ac8b3c0e5f 100644
> --- a/drivers/media/usb/dvb-usb/Kconfig
> +++ b/drivers/media/usb/dvb-usb/Kconfig
> @@ -120,7 +120,9 @@ config DVB_USB_UMT_010
>  
>  config DVB_USB_CXUSB
>   tristate "Conexant USB2.0 hybrid reference design support"
> - depends on DVB_USB
> + depends on DVB_USB && VIDEO_V4L2
> + select VIDEO_CX25840
> + select VIDEOBUF2_VMALLOC


But here, instead of requiring V4L2, the best would be to add another
Kconfig var (DVB_USB_CXUSB_V4L2), enabling the analog part only
if such config option is selected.

>   select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
>   select DVB_CX22702 if MEDIA_SUBDRV_AUTOSELECT
>   select DVB_LGDT330X if MEDIA_SUBDRV_AUTOSELECT
> @@ -138,8 +140,8 @@ config DVB_USB_CXUSB
>   select MEDIA_TUNER_SI2157 if MEDIA_SUBDRV_AUTOSELECT
>   help
> Say Y here to support the Conexant USB2.0 hybrid reference design.
> -   Currently, only DVB and ATSC modes are supported, analog mode
> -   shall be added in the future. Devices that require this module:
> +   DVB and ATSC modes are supported, with basic analog mode support
> +   for Medion MD95700. Devices that require this module:
>  
> Medion MD95700 hybrid USB2.0 device.
> DViCO FusionHDTV (Bluebird) USB2.0 devices
> diff --git a/drivers/media/usb/dvb-usb/Makefile 
> b/drivers/media/usb/dvb-usb/Makefile
> index 16de1e4f36a4..61e32aacfef6 100644
> --- a/drivers/media/usb/dvb-usb/Makefile
> +++ b/drivers/media/usb/dvb-usb/Makefile
> @@ -41,7 +41,7 @@ obj-$(CONFIG_DVB_USB_M920X) += dvb-usb-m920x.o
>  dvb-usb-digitv-objs := digitv.o
>  obj-$(CONFIG_DVB_USB_DIGITV) += dvb-usb-digitv.o
>  
> -dvb-usb-cxusb-objs := cxusb.o
> +dvb-usb-cxusb-objs := cxusb.o cxusb-analog.o
>  obj-$(CONFIG_DVB_USB_CXUSB) += dvb-usb-cxusb.o
>  
>  dvb-usb-ttusb2-objs := ttusb2.o
> diff --git a/drivers/media/usb/dvb-usb/cxusb-analog.c 
> b/drivers/media/usb/dvb-usb/cxusb-analog.c
> new file mode 100644
> index ..de345cb42e23
> --- /dev/null
> +++ b/drivers/media/usb/dvb-usb/cxusb-analog.c
> @@ -0,0 +1,1923 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/* DVB USB compliant linux driver for Conexant USB reference design -

That actually violates Kernel coding style, as /* should be on an
empty line :-)

We're currently preferring to have C-99 comments on the header.
So, please change the header comment to use //.

> + * (analog part).
> + *
> + * Copyright (C) 2011, 2017 Maciej S. Szmigiero (m...@maciej.szmigiero.name)
> + *
> + * TODO:
> + *  * audio support,
> + *  * finish radio support (requires audio of course),
> + *  * VBI support,
> + *  * controls support
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "cxusb.h"
> +
> +static int cxusb_medion_v_queue_setup(struct vb2_queue *q,
> +   unsigned int *num_buffers,
> +   unsigned int *num_planes,
> +   unsigned int sizes[],
> +   struct device *alloc_devs[])
> +{
> + struct dvb_usb_device *dvbdev = vb2_get_drv_priv(q);
> + struct cxusb_medion_dev *cxdev = dvbdev->priv;
> + unsigned int size = cxdev->raw_mode ?
> + CXUSB_VIDEO_MAX_FRAME_SIZE :
> + cxdev->width * cxdev->height * 2;
> +
> + if (*num_planes > 0) {
> + if (*num_planes != 1)
> + return -EINVAL;
> +
> + if 

Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver

2017-12-19 Thread Fabio Estevam
Hi Sakari,

On Tue, Dec 19, 2017 at 7:22 AM, Sakari Ailus  wrote:
> On Mon, Dec 11, 2017 at 09:31:46AM +0800, Wenyou Yang wrote:
>> The ov7740 (color) image sensor is a high performance VGA CMOS
>> image snesor, which supports for output formats: RAW RGB and YUV
>> and image sizes: VGA, and QVGA, CIF and any size smaller.
>>
>> Signed-off-by: Songjun Wu 
>> Signed-off-by: Wenyou Yang 
>
> Applied with this diff:
>
> diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
> index 0308ba437bbb..041a77039d70 100644
> --- a/drivers/media/i2c/ov7740.c
> +++ b/drivers/media/i2c/ov7740.c
> @@ -1,5 +1,7 @@
> -// SPDX-License-Identifier: GPL-2.0
> -// Copyright (c) 2017 Microchip Corporation.
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + * Copyright (c) 2017 Microchip Corporation.
> + */

The original version is the recommended format for the SPDX identifier.


Re: iMX6q/coda encoder failures with ffmpeg/gstreamer m2m encoders

2017-12-19 Thread Neil Armstrong
On 19/12/2017 12:17, Philipp Zabel wrote:
> Hi Neil,
> 
> On Tue, 2017-11-21 at 10:50 +0100, Neil Armstrong wrote:
>> Hi,
>>
>> I'm trying to make the coda960 h.264 encoder work on an i.MX6q SoC with 
>> Linux 4.14 and the 3.1.1 firmware.
>>
>> # dmesg | grep coda
>> [4.846574] coda 204.vpu: Direct firmware load for vpu_fw_imx6q.bin 
>> failed with error -2
>> [4.901351] coda 204.vpu: Using fallback firmware vpu/vpu_fw_imx6q.bin
>> [4.916039] coda 204.vpu: Firmware code revision: 46072
>> [4.921641] coda 204.vpu: Initialized CODA960.
>> [4.926589] coda 204.vpu: Firmware version: 3.1.1
>> [4.932223] coda 204.vpu: codec registered as /dev/video[8-9]
>>
>> Using gstreamer-plugins-good and the m2m v4l2 encoder, I have :
>>
>> # gst-launch-1.0 videotestsrc num-buffers=1000 pattern=snow ! video/x-raw, 
>> framerate=30/1, width=1280, height=720 ! v4l2h264enc ! h264parse ! mp4mux ! 
>> filesink location=/dev/null
>> Setting pipeline to PAUSED ...
>> Pipeline is PREROLLING ...
>> Redistribute latency...
>> [ 1569.473717] coda 204.vpu: coda_s_fmt queue busy
>> ERROR: from element /GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0: Device 
>> '/dev/video8' is busy
>> Additional debug info:
>> ../../../gst-plugins-good-1.12.3/sys/v4l2/gstv4l2object.c(3609): 
>> gst_v4l2_object_set_format_full (): 
>> /GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0:
>> Call to S_FMT failed for YU12 @ 1280x720: Device or resource busy
>> ERROR: pipeline doesn't want to preroll.
>> Setting pipeline to NULL ...
>> Freeing pipeline ...
> 
> The coda driver does not allow S_FMT anymore, as soon as the buffers are
> allocated with REQBUFS:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=791338
> 
> regards
> Philipp
> 

Thanks Philipp,

It solves the gstreamer encoding.

Neil


Re: [PATCH 0/2] Support Physical Layer Scrambling

2017-12-19 Thread Mauro Carvalho Chehab
Em Sun, 17 Dec 2017 14:50:37 +0100
Ralph Metzler  escreveu:

> Athanasios Oikonomou writes:
>  > A new property DTV_SCRAMBLING_SEQUENCE_INDEX introduced to control
>  > the gold sequence that several demods support.
>  > 
>  > Also the DVB API was increased in order userspace to be aware of the
>  > changes.
>  > 
>  > The stv090x driver was changed to make use of the new property.
>  > 
>  > Those commits based on discussion previously made on the mailling list.
>  > https://www.mail-archive.com/linux-media@vger.kernel.org/msg122600.html
>  > 
>  > I would like to thanks Ralph Metzler (r...@metzlerbros.de) for the
>  > great help and ideas he provide me in order create those patches.
>  > 
>  > Athanasios Oikonomou (2):
>  >   media: dvb_frontend: add physical layer scrambling support
>  >   media: stv090x: add physical layer scrambling support
>  > 
>  >  .../media/uapi/dvb/fe_property_parameters.rst  | 18 
> ++
>  >  .../uapi/dvb/frontend-property-satellite-systems.rst   |  2 ++
>  >  drivers/media/dvb-core/dvb_frontend.c  | 12 
>  >  drivers/media/dvb-core/dvb_frontend.h  |  5 +
>  >  drivers/media/dvb-frontends/stv090x.c  | 16 
> 
>  >  include/uapi/linux/dvb/frontend.h  |  5 -
>  >  include/uapi/linux/dvb/version.h   |  2 +-
>  >  7 files changed, 58 insertions(+), 2 deletions(-)
>  > 
>  > -- 
>  > 2.1.4  
> 
> Acked-by: Ralph Metzler 

I'm applying both patches.

> We had some thoughts about having a:
> 
> #define NO_SCRAMBLING_CODE (~0U)
> 
> But DVB-S2 is always scrambling (with default index 0) and other delivery 
> systems can ignore this
> property. Or do you think it is needed?
> 
> 
> One could add a define for AUTO or AUTO_S2X for the standard 7 indices to be 
> tested
> in DVB-S2X. But either dvb_frontend.c or the demod driver would have to 
> support this in software.
> I don't think there is a demod which supports this in hardware yet?

I think that, once we have a hardware capable of auto-detecting the gold
sequence, then a NO_SCRAMBLING_CODE (or AUTO_GOLD_SEQUENCE) could make
sense.

For now, I don't think any demod currently supports it.

Thanks,
Mauro


Re: [PATCH v4 3/3] media: atomisp: delete empty default struct values.

2017-12-19 Thread Sakari Ailus
On Sat, Dec 02, 2017 at 10:12:01PM +, Jeremy Sowden wrote:
> Removing zero-valued struct-members left a number of the default
> struct-values empty.  These values have now been removed.
> 
> Signed-off-by: Jeremy Sowden 

This one should be squashed as well.

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


Re: [PATCH v4 1/3] media: atomisp: convert default struct values to use compound-literals with designated initializers.

2017-12-19 Thread Sakari Ailus
Hi Jeremy,

On Sat, Dec 02, 2017 at 10:11:59PM +, Jeremy Sowden wrote:
> The CSS API uses a lot of nested anonymous structs defined in object
> macros to assign default values to its data-structures.  These have been
> changed to use compound-literals and designated initializers to make
> them more comprehensible and less fragile.
> 
> The compound-literals can also be used in assignment, which means we can
> get rid of some temporary variables whose only purpose is to be
> initialized by one of these anonymous structs and then serve as the
> rvalue in an assignment expression.
> 
> Signed-off-by: Jeremy Sowden 

I don't think it's useful to change the struct definition macros only to
remove a large number of assigned fields in the next patch. How about
merging the two patches?

Please also start a new thread when re-posting a set.

Thanks.

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


Re: [BUG] atomisp_ov2680 not initializing correctly

2017-12-19 Thread Sakari Ailus
Cc Alan and Andy.

On Sat, Dec 16, 2017 at 04:50:04PM +0100, Kristian Beilke wrote:
> Dear all,
> 
> I am trying to get the cameras in a Lenovo IdeaPad Miix 320 (Atom
> x5-Z8350 BayTrail) to work. The front camera is an ov2680. With kernel
> 4.14.4 and 4.15rc3 I see the following dmesg output:
> 
> 
> [   21.469907] ov2680: module is from the staging directory, the quality
>  is unknown, you have been warned.
> [   21.492774] ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module
> subdev data.PMIC ID 1
> [   21.492891] acpi OVTI2680:00: Failed to find gmin variable
> OVTI2680:00_CamClk
> [   21.492974] acpi OVTI2680:00: Failed to find gmin variable
> OVTI2680:00_ClkSrc
> [   21.493090] acpi OVTI2680:00: Failed to find gmin variable
> OVTI2680:00_CsiPort
> [   21.493209] acpi OVTI2680:00: Failed to find gmin variable
> OVTI2680:00_CsiLanes
> [   21.493511] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P8SX not
> found, using dummy regulator
> [   21.493550] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V2P8SX not
> found, using dummy regulator
> [   21.493569] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply V1P2A not
> found, using dummy regulator
> [   21.493585] ov2680 i2c-OVTI2680:00: i2c-OVTI2680:00 supply VPROG4B
> not found, using dummy regulator
> [   21.568134] ov2680 i2c-OVTI2680:00: camera pdata: port: 0 lanes: 1
> order: 0002
> [   21.568257] ov2680 i2c-OVTI2680:00: read from offset 0x300a error -121
> [   21.568265] ov2680 i2c-OVTI2680:00: sensor_id_high = 0x
> [   21.568269] ov2680 i2c-OVTI2680:00: ov2680_detect err s_config.
> [   21.568291] ov2680 i2c-OVTI2680:00: sensor power-gating failed
> 
> Afterwards I do not get a camera device.
> 
> Am I missing some firmware or dependency? Can I somehow help to improve
> the driver?
> 
> Regards
> 
> Kristian
> 



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


Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

2017-12-19 Thread jacopo mondi
Hi Laurent,
   a few more details on subdevice management

On Mon, Dec 11, 2017 at 06:15:23PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> Thank you for the patch.
>
> [snip]
>
> > +static int ceu_sensor_bound(struct v4l2_async_notifier *notifier,
> > +   struct v4l2_subdev *v4l2_sd,
> > +   struct v4l2_async_subdev *asd)
> > +{
> > +   struct v4l2_device *v4l2_dev = notifier->v4l2_dev;
> > +   struct ceu_device *ceudev = v4l2_to_ceu(v4l2_dev);
> > +   struct ceu_subdev *ceu_sd = to_ceu_subdev(asd);
> > +
> > +   if (video_is_registered(>vdev)) {
> > +   v4l2_err(>v4l2_dev,
> > +"Video device registered before this sub-device.\n");
> > +   return -EBUSY;
>
> Can this happen ?
>
> > +   }
> > +
> > +   /* Assign subdevices in the order they appear */
> > +   ceu_sd->v4l2_sd = v4l2_sd;
> > +   ceudev->num_sd++;
> > +
> > +   return 0;
> > +}
> > +
> > +static int ceu_sensor_complete(struct v4l2_async_notifier *notifier)
> > +{
> > +   struct v4l2_device *v4l2_dev = notifier->v4l2_dev;
> > +   struct ceu_device *ceudev = v4l2_to_ceu(v4l2_dev);
> > +   struct video_device *vdev = >vdev;
> > +   struct vb2_queue *q = >vb2_vq;
> > +   struct v4l2_subdev *v4l2_sd;
> > +   int ret;
> > +
> > +   /* Initialize vb2 queue */
> > +   q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
> > +   q->io_modes = VB2_MMAP | VB2_USERPTR;
>
> No dmabuf ?
>
> > +   q->drv_priv = ceudev;
> > +   q->ops  = _videobuf_ops;
> > +   q->mem_ops  = _dma_contig_memops;
> > +   q->buf_struct_size  = sizeof(struct ceu_buffer);
> > +   q->timestamp_flags  = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> > +   q->lock = >mlock;
> > +   q->dev  = ceudev->v4l2_dev.dev;
>
> [snip]
>
> > +static int ceu_probe(struct platform_device *pdev)
> > +{
> > +   struct device *dev = >dev;
> > +   struct ceu_device *ceudev;
> > +   struct resource *res;
> > +   void __iomem *base;
> > +   unsigned int irq;
> > +   int num_sd;
> > +   int ret;
> > +
> > +   ceudev = kzalloc(sizeof(*ceudev), GFP_KERNEL);
>
> The memory is freed in ceu_vdev_release() as expected, but that will only work
> if the video device is registered. If the subdevs are never bound, the ceudev
> memory will be leaked if you unbind the CEU device from its driver. In my
> opinion this calls for registering the video device at probe time (although
> Hans disagrees).
>
> > +   if (!ceudev)
> > +   return -ENOMEM;
> > +
> > +   platform_set_drvdata(pdev, ceudev);
> > +   dev_set_drvdata(dev, ceudev);
>
> You don't need the second line, platform_set_drvdata() is a wrapper around
> dev_set_drvdata().
>
> > +   ceudev->dev = dev;
> > +
> > +   INIT_LIST_HEAD(>capture);
> > +   spin_lock_init(>lock);
> > +   mutex_init(>mlock);
> > +
> > +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +   if (IS_ERR(res))
> > +   return PTR_ERR(res);
>
> No need for error handling here, devm_ioremap_resource() will check the res
> pointer.
>
> > +   base = devm_ioremap_resource(dev, res);
>
> You can assign ceudev->base directly and remove the base local variable.
>
> > +   if (IS_ERR(base))
> > +   return PTR_ERR(base);
> > +   ceudev->base = base;
> > +
> > +   ret = platform_get_irq(pdev, 0);
> > +   if (ret < 0) {
> > +   dev_err(dev, "failed to get irq: %d\n", ret);
> > +   return ret;
> > +   }
> > +   irq = ret;
> > +
> > +   ret = devm_request_irq(dev, irq, ceu_irq,
> > +  0, dev_name(dev), ceudev);
> > +   if (ret) {
> > +   dev_err(>dev, "Unable to register CEU interrupt.\n");
> > +   return ret;
> > +   }
> > +
> > +   pm_suspend_ignore_children(dev, true);
> > +   pm_runtime_enable(dev);
> > +
> > +   ret = v4l2_device_register(dev, >v4l2_dev);
> > +   if (ret)
> > +   goto error_pm_disable;
> > +
> > +   if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> > +   num_sd = ceu_parse_dt(ceudev);
> > +   } else if (dev->platform_data) {
> > +   num_sd = ceu_parse_platform_data(ceudev, dev->platform_data);
> > +   } else {
> > +   dev_err(dev, "CEU platform data not set and no OF support\n");
> > +   ret = -EINVAL;
> > +   goto error_v4l2_unregister;
> > +   }
> > +
> > +   if (num_sd < 0) {
> > +   ret = num_sd;
> > +   goto error_v4l2_unregister;
> > +   } else if (num_sd == 0)
> > +   return 0;
>
> You need braces around the second statement too.

Ok, actually parse_dt() and parse_platform_data() behaves differently.
The former returns error if no subdevices are connected to CEU, the
latter returns 0. That's wrong.

I wonder what's the correct behavior here. Other mainline drivers I
looked into (pxa_camera and atmel-isc) behaves differently from each
other, so I guess this is up to each platform to decide.

Also, the CEU can accept one single input (and I made it clear
in DT 

Re: [PATCH 15/24] media: v4l2-subdev: get rid of __V4L2_SUBDEV_MK_GET_TRY() macro

2017-12-19 Thread Sakari Ailus
On Tue, Dec 19, 2017 at 09:03:55AM -0200, Mauro Carvalho Chehab wrote:
> [PATCH] media: v4l2-subdev: get rid of __V4L2_SUBDEV_MK_GET_TRY() macro
> 
> The __V4L2_SUBDEV_MK_GET_TRY() macro is used to define
> 3 functions that have the same arguments. The code of those
> functions is simple enough to just declare them, de-obfuscating
> the code.
> 
> While here, replace BUG_ON() by WARN_ON() as there's no reason
> why to panic the Kernel if this fails.
> 
> Signed-off-by: Mauro Carvalho Chehab 

Thanks!

Acked-by: Sakari Ailus 

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


RE: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver

2017-12-19 Thread Wenyou.Yang
Hi Sakari,

> -Original Message-
> From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
> Sent: 2017年12月19日 17:23
> To: Wenyou Yang - A41535 
> Cc: Mauro Carvalho Chehab ; Rob Herring
> ; Mark Rutland ; linux-
> ker...@vger.kernel.org; Nicolas Ferre - M43238 ;
> devicet...@vger.kernel.org; Jonathan Corbet ; Hans Verkuil
> ; linux-arm-ker...@lists.infradead.org; Linux Media 
> Mailing List
> ; Songjun Wu 
> Subject: Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver
> 
> On Mon, Dec 11, 2017 at 09:31:46AM +0800, Wenyou Yang wrote:
> > The ov7740 (color) image sensor is a high performance VGA CMOS image
> > snesor, which supports for output formats: RAW RGB and YUV and image
> > sizes: VGA, and QVGA, CIF and any size smaller.
> >
> > Signed-off-by: Songjun Wu 
> > Signed-off-by: Wenyou Yang 
> 
> Applied with this diff:

Thank you very much.

> 
> diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c index
> 0308ba437bbb..041a77039d70 100644
> --- a/drivers/media/i2c/ov7740.c
> +++ b/drivers/media/i2c/ov7740.c
> @@ -1,5 +1,7 @@
> -// SPDX-License-Identifier: GPL-2.0
> -// Copyright (c) 2017 Microchip Corporation.
> +/*
> + * SPDX-License-Identifier: GPL-2.0
> + * Copyright (c) 2017 Microchip Corporation.
> + */
> 
>  #include 
>  #include 
> 
> --
> Sakari Ailus
> e-mail: sakari.ai...@iki.fi


Best Regards,
Wenyou Yang


Re: [PATCH v2 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

2017-12-19 Thread Sakari Ailus
Hi Yong,

On Thu, Jul 27, 2017 at 01:01:36PM +0800, Yong Deng wrote:
> Add binding documentation for Allwinner V3s CSI.
> 
> Signed-off-by: Yong Deng 

DT bindings should precede the driver.

> ---
>  .../devicetree/bindings/media/sun6i-csi.txt| 49 
> ++
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt 
> b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> new file mode 100644
> index 000..f8d83f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> @@ -0,0 +1,49 @@
> +Allwinner V3s Camera Sensor Interface
> +--
> +
> +Required properties:
> +  - compatible: value must be "allwinner,sun8i-v3s-csi"

What are sun6i and sun8i? Is this device first present in sun6i SoCs,
whereas you have only defined bindings for sun8i?

> +  - reg: base address and size of the memory-mapped region.
> +  - interrupts: interrupt associated to this IP
> +  - clocks: phandles to the clocks feeding the CSI
> +* ahb: the CSI interface clock
> +* mod: the CSI module clock
> +* ram: the CSI DRAM clock
> +  - clock-names: the clock names mentioned above
> +  - resets: phandles to the reset line driving the CSI
> +
> +- ports: A ports node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.

Please document mandatory and optional endpoint properties relevant for the
hardware.

> +
> +Example:
> +
> + csi1: csi@01cb4000 {
> + compatible = "allwinner,sun8i-v3s-csi";
> + reg = <0x01cb4000 0x1000>;
> + interrupts = ;
> + clocks = < CLK_BUS_CSI>,
> +  < CLK_CSI1_SCLK>,
> +  < CLK_DRAM_CSI>;
> + clock-names = "ahb", "mod", "ram";
> + resets = < RST_BUS_CSI>;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* Parallel bus endpoint */
> + csi1_ep: endpoint {
> + remote-endpoint = <_ep>;
> + bus-width = <16>;
> + data-shift = <0>;
> +
> + /* If hsync-active/vsync-active are missing,
> +embedded BT.656 sync is used */
> + hsync-active = <0>; /* Active low */
> + vsync-active = <0>; /* Active low */
> + data-active = <1>;  /* Active high */
> + pclk-sample = <1>;  /* Rising */
> + };
> + };
> + };
> +

-- 
Kind regards,

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


Re: [PATCH v5 4/6] media: i2c: Add TDA1997x HDMI receiver driver

2017-12-19 Thread Philippe Ombredanne
Tim,

On Tue, Dec 19, 2017 at 12:12 PM, Hans Verkuil  wrote:
> On 16/12/17 19:00, Tim Harvey wrote:
>> Add support for the TDA1997x HDMI receivers.
>>
>> Cc: Hans Verkuil 
>> Signed-off-by: Tim Harvey 



>> --- /dev/null
>> +++ b/drivers/media/i2c/tda1997x.c
>> @@ -0,0 +1,3520 @@
>> +/*
>> + * Copyright (C) 2017 Gateworks Corporation
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */

Would you mind using the new SPDX tags documented in Thomas patch set
[1] rather than this fine but longer legalese?  Thank you!

[1] https://lkml.org/lkml/2017/12/4/934

--
Cordially
Philippe Ombredanne


Re: [PATCH v2 5/8] media: v4l2-mediabus: convert flags to enums and document them

2017-12-19 Thread Philipp Zabel
On Tue, 2017-12-19 at 09:18 -0200, Mauro Carvalho Chehab wrote:
> There is a mess with media bus flags: there are two sets of
> flags, one used by parallel and ITU-R BT.656 outputs,
> and another one for CSI2.
> 
> Depending on the type, the same bit has different meanings.
> 
> That's very confusing, and counter-intuitive. So, split them
> into two sets of flags, inside an enum.
> 
> This way, it becomes clearer that there are two separate sets
> of flags. It also makes easier if CSI1, CSP, CSI3, etc. would
> need a different set of flags.
> 
> As a side effect, enums can be documented via kernel-docs,
> so there will be an improvement at flags documentation.
> 
> Unfortunately, soc_camera and pxa_camera do a mess with
> the flags, using either one set of flags without proper
> checks about the type. That could be fixed, but, as both drivers
> are obsolete and in the process of cleanings, I opted to just
> keep the behavior, using an unsigned int inside those two
> drivers.
> 
> Acked-by: Hans Verkuil 
> Signed-off-by: Mauro Carvalho Chehab 

For imx-media,
Acked-by: Philipp Zabel 

thanks
Philipp


Re: [PATCH v2 3/3] media: MAINTAINERS: add entries for Allwinner V3s CSI

2017-12-19 Thread Sakari Ailus
On Thu, Jul 27, 2017 at 01:01:37PM +0800, Yong Deng wrote:
> Signed-off-by: Yong Deng 
> ---
>  MAINTAINERS | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9826a91..b91fa27 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3686,6 +3686,14 @@ M: Jaya Kumar 
>  S:   Maintained
>  F:   sound/pci/cs5535audio/
>  
> +CSI DRIVERS FOR ALLWINNER V3s
> +M:   Yong Deng 
> +L:   linux-media@vger.kernel.org
> +T:   git git://linuxtv.org/media_tree.git
> +S:   Maintained
> +F:   drivers/media/platform/sun6i-csi/
> +F:   Documentation/devicetree/bindings/media/sun6i-csi.txt
> +
>  CW1200 WLAN driver
>  M:   Solomon Peachy 
>  S:   Maintained

Please squash to the driver patch. Thanks.

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


Re: [PATCH] media: imx: allow to build with COMPILE_TEST

2017-12-19 Thread Philipp Zabel
On Tue, 2017-12-19 at 12:42 +0100, Philipp Zabel wrote:
> Allow building this driver for other platforms under COMPILE_TEST.
>
> Suggested-by: Mauro Carvalho Chehab 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/staging/media/imx/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/media/imx/Kconfig 
> b/drivers/staging/media/imx/Kconfig
> index 2be921cd0d55a..59b380cc6d223 100644
> --- a/drivers/staging/media/imx/Kconfig
> +++ b/drivers/staging/media/imx/Kconfig
> @@ -1,6 +1,7 @@
>  config VIDEO_IMX_MEDIA
>   tristate "i.MX5/6 V4L2 media core driver"
> - depends on MEDIA_CONTROLLER && VIDEO_V4L2 && ARCH_MXC && IMX_IPUV3_CORE
> + depends on ARCH_MXC || COMPILE_TEST
> + depends on MEDIA_CONTROLLER && VIDEO_V4L2 && IMX_IPUV3_CORE
>   depends on VIDEO_V4L2_SUBDEV_API
>   select VIDEOBUF2_DMA_CONTIG
>   select V4L2_FWNODE

Currently IMX_IPUV3_CORE is not buildable under COMPILE_TEST either,
I'll fix that separately.

regards
Philipp


[PATCH] media: s5c73m3-core: fix logic on a timeout condition

2017-12-19 Thread Mauro Carvalho Chehab
As warned by smatch:
drivers/media/i2c/s5c73m3/s5c73m3-core.c:268 s5c73m3_check_status() 
error: uninitialized symbol 'status'.

if s5c73m3_check_status() is called too late, time_is_after_jiffies(end)
will return 0, causing the while to abort before reading status.

The current code will do the wrong thing here, as it will still
check if status != value. The right fix here is to change
the logic to ensure that it will always read the status.

Suggested-by: Andrzej Hajda 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/i2c/s5c73m3/s5c73m3-core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c 
b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
index cdc4f2392ef9..ce196b60f917 100644
--- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c
+++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c
@@ -248,17 +248,17 @@ static int s5c73m3_check_status(struct s5c73m3 *state, 
unsigned int value)
 {
unsigned long start = jiffies;
unsigned long end = start + msecs_to_jiffies(2000);
-   int ret = 0;
+   int ret;
u16 status;
int count = 0;
 
-   while (time_is_after_jiffies(end)) {
+   do {
ret = s5c73m3_read(state, REG_STATUS, );
if (ret < 0 || status == value)
break;
usleep_range(500, 1000);
++count;
-   }
+   } while (time_is_after_jiffies(end));
 
if (count > 0)
v4l2_dbg(1, s5c73m3_dbg, >sensor_sd,
-- 
2.14.3



[PATCH] media: imx: allow to build with COMPILE_TEST

2017-12-19 Thread Philipp Zabel
Allow building this driver for other platforms under COMPILE_TEST.

Suggested-by: Mauro Carvalho Chehab 
Signed-off-by: Philipp Zabel 
---
 drivers/staging/media/imx/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/imx/Kconfig 
b/drivers/staging/media/imx/Kconfig
index 2be921cd0d55a..59b380cc6d223 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers/staging/media/imx/Kconfig
@@ -1,6 +1,7 @@
 config VIDEO_IMX_MEDIA
tristate "i.MX5/6 V4L2 media core driver"
-   depends on MEDIA_CONTROLLER && VIDEO_V4L2 && ARCH_MXC && IMX_IPUV3_CORE
+   depends on ARCH_MXC || COMPILE_TEST
+   depends on MEDIA_CONTROLLER && VIDEO_V4L2 && IMX_IPUV3_CORE
depends on VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
-- 
2.11.0



Re: [PATCH 2/8] media: v4l2-ioctl.h: convert debug into an enum of bits

2017-12-19 Thread Sakari Ailus
Hi Mauro,

On Mon, Dec 18, 2017 at 05:53:56PM -0200, Mauro Carvalho Chehab wrote:
> The V4L2_DEV_DEBUG_IOCTL macros actually define a bitmask,
> but without using Kernel's modern standards. Also,
> documentation looks akward.
> 
> So, convert them into an enum with valid bits, adding
> the correspoinding kernel-doc documentation for it.

The pattern of using bits for flags is a well established one and I
wouldn't deviate from that by requiring the use of the BIT() macro. There
are no benefits that I can see from here but the approach brings additional
risks: misuse of the flags and mimicing the same risky pattern.

I'd also like to echo Laurent's concern that code is being changed in odd
ways and not for itself, but due to deficiencies in documentation tools.

I believe the tooling has to be improved to address this properly. That
only needs to done once, compared to changing all flag definitions to
enums.

Another point I want to make is that the uAPI definitions cannot be
changed: enums are thus an option in kAPI only. Improved KernelDoc tools
would thus also allow improving uAPI macro documentation --- which is more
important anyway.

-- 
Kind regards,

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


[PATCH v2 1/8] media: v4l2-device.h: document helper macros

2017-12-19 Thread Mauro Carvalho Chehab
There are several macros that aren't documented using kernel-docs
markups.

Document them.

While here, add cross-references to structs on this file.

Acked-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-device.h | 246 +---
 1 file changed, 211 insertions(+), 35 deletions(-)

diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h
index 8ffa94009d1a..448616b392f3 100644
--- a/include/media/v4l2-device.h
+++ b/include/media/v4l2-device.h
@@ -38,7 +38,7 @@ struct v4l2_ctrl_handler;
  * @lock: lock this struct; can be used by the driver as well
  * if this struct is embedded into a larger struct.
  * @name: unique device name, by default the driver name + bus ID
- * @notify: notify callback called by some sub-devices.
+ * @notify: notify operation called by some sub-devices.
  * @ctrl_handler: The control handler. May be %NULL.
  * @prio: Device's priority state
  * @ref: Keep track of the references to this struct.
@@ -56,7 +56,6 @@ struct v4l2_ctrl_handler;
  *#) @dev->driver_data points to this struct.
  *#) @dev might be %NULL if there is no parent device
  */
-
 struct v4l2_device {
struct device *dev;
 #if defined(CONFIG_MEDIA_CONTROLLER)
@@ -166,7 +165,7 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev);
  * v4l2_device_register_subdev - Registers a subdev with a v4l2 device.
  *
  * @v4l2_dev: pointer to struct _device
- * @sd: pointer to struct _subdev
+ * @sd: pointer to  v4l2_subdev
  *
  * While registered, the subdev module is marked as in-use.
  *
@@ -179,7 +178,7 @@ int __must_check v4l2_device_register_subdev(struct 
v4l2_device *v4l2_dev,
 /**
  * v4l2_device_unregister_subdev - Unregisters a subdev with a v4l2 device.
  *
- * @sd: pointer to struct _subdev
+ * @sd: pointer to  v4l2_subdev
  *
  * .. note ::
  *
@@ -201,7 +200,7 @@ v4l2_device_register_subdev_nodes(struct v4l2_device 
*v4l2_dev);
 /**
  * v4l2_subdev_notify - Sends a notification to v4l2_device.
  *
- * @sd: pointer to struct _subdev
+ * @sd: pointer to  v4l2_subdev
  * @notification: type of notification. Please notice that the notification
  * type is driver-specific.
  * @arg: arguments for the notification. Those are specific to each
@@ -214,13 +213,43 @@ static inline void v4l2_subdev_notify(struct v4l2_subdev 
*sd,
sd->v4l2_dev->notify(sd, notification, arg);
 }
 
-/* Iterate over all subdevs. */
+/* Helper macros to iterate over all subdevs. */
+
+/**
+ * v4l2_device_for_each_subdev - Helper macro that interates over all
+ * sub-devices of a given _device.
+ *
+ * @sd: pointer that will be filled by the macro with all
+ *  v4l2_subdev pointer used as an iterator by the loop.
+ * @v4l2_dev:  v4l2_device owning the sub-devices to iterate over.
+ *
+ * This macro iterates over all sub-devices owned by the @v4l2_dev device.
+ * It acts as a for loop iterator and executes the next statement with
+ * the @sd variable pointing to each sub-device in turn.
+ */
 #define v4l2_device_for_each_subdev(sd, v4l2_dev)  \
list_for_each_entry(sd, &(v4l2_dev)->subdevs, list)
 
-/* Call the specified callback for all subdevs matching the condition.
-   Ignore any errors. Note that you cannot add or delete a subdev
-   while walking the subdevs list. */
+/**
+ * __v4l2_device_call_subdevs_p - Calls the specified operation for
+ * all subdevs matching the condition.
+ *
+ * @v4l2_dev:  v4l2_device owning the sub-devices to iterate over.
+ * @sd: pointer that will be filled by the macro with all
+ *  v4l2_subdev pointer used as an iterator by the loop.
+ * @cond: condition to be match
+ * @o: name of the element at  v4l2_subdev_ops that contains @f.
+ * Each element there groups a set of operations functions.
+ * @f: operation function that will be called if @cond matches.
+ * The operation functions are defined in groups, according to
+ * each element at  v4l2_subdev_ops.
+ * @args...: arguments for @f.
+ *
+ * Ignore any errors.
+ *
+ * Note: subdevs cannot be added or deleted while walking
+ * the subdevs list.
+ */
 #define __v4l2_device_call_subdevs_p(v4l2_dev, sd, cond, o, f, args...)
\
do {\
list_for_each_entry((sd), &(v4l2_dev)->subdevs, list)   \
@@ -228,6 +257,24 @@ static inline void v4l2_subdev_notify(struct v4l2_subdev 
*sd,
(sd)->ops->o->f((sd) , ##args); \
} while (0)
 
+/**
+ * __v4l2_device_call_subdevs - Calls the specified operation for
+ * all subdevs matching the condition.
+ *
+ * @v4l2_dev:  v4l2_device owning the sub-devices to iterate over.
+ * @cond: condition to be match
+ * @o: name of the element at  v4l2_subdev_ops that contains @f.
+ * Each element there groups a set of operations functions.
+ * @f: operation function 

[PATCH v2 6/8] media: v4l2-subdev: get rid of __V4L2_SUBDEV_MK_GET_TRY() macro

2017-12-19 Thread Mauro Carvalho Chehab
The __V4L2_SUBDEV_MK_GET_TRY() macro is used to define
3 functions that have the same arguments. The code of those
functions is simple enough to just declare them, de-obfuscating
the code.

While here, replace BUG_ON() by WARN_ON() as there's no reason
why to panic the Kernel if this fails.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-subdev.h | 40 
 1 file changed, 28 insertions(+), 12 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 71b8ff4b2e0e..443e5e019006 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -896,19 +896,35 @@ struct v4l2_subdev_fh {
container_of(fh, struct v4l2_subdev_fh, vfh)
 
 #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
-#define __V4L2_SUBDEV_MK_GET_TRY(rtype, fun_name, field_name)  \
-   static inline struct rtype *\
-   fun_name(struct v4l2_subdev *sd,\
-struct v4l2_subdev_pad_config *cfg,\
-unsigned int pad)  \
-   {   \
-   BUG_ON(pad >= sd->entity.num_pads); \
-   return [pad].field_name;\
-   }
+static inline struct v4l2_mbus_framefmt
+*v4l2_subdev_get_try_format(struct v4l2_subdev *sd,
+   struct v4l2_subdev_pad_config *cfg,
+   unsigned int pad)
+{
+   if (WARN_ON(pad >= sd->entity.num_pads))
+   pad = 0;
+   return [pad].try_fmt;
+}
 
-__V4L2_SUBDEV_MK_GET_TRY(v4l2_mbus_framefmt, v4l2_subdev_get_try_format, 
try_fmt)
-__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, v4l2_subdev_get_try_crop, try_crop)
-__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, v4l2_subdev_get_try_compose, try_compose)
+static inline struct v4l2_rect
+*v4l2_subdev_get_try_crop(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ unsigned int pad)
+{
+   if (WARN_ON(pad >= sd->entity.num_pads))
+   pad = 0;
+   return [pad].try_crop;
+}
+
+static inline struct v4l2_rect
+*v4l2_subdev_get_try_compose(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg,
+unsigned int pad)
+{
+   if (WARN_ON(pad >= sd->entity.num_pads))
+   pad = 0;
+   return [pad].try_compose;
+}
 #endif
 
 extern const struct v4l2_file_operations v4l2_subdev_fops;
-- 
2.14.3



[PATCH v2 5/8] media: v4l2-mediabus: convert flags to enums and document them

2017-12-19 Thread Mauro Carvalho Chehab
There is a mess with media bus flags: there are two sets of
flags, one used by parallel and ITU-R BT.656 outputs,
and another one for CSI2.

Depending on the type, the same bit has different meanings.

That's very confusing, and counter-intuitive. So, split them
into two sets of flags, inside an enum.

This way, it becomes clearer that there are two separate sets
of flags. It also makes easier if CSI1, CSP, CSI3, etc. would
need a different set of flags.

As a side effect, enums can be documented via kernel-docs,
so there will be an improvement at flags documentation.

Unfortunately, soc_camera and pxa_camera do a mess with
the flags, using either one set of flags without proper
checks about the type. That could be fixed, but, as both drivers
are obsolete and in the process of cleanings, I opted to just
keep the behavior, using an unsigned int inside those two
drivers.

Acked-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/i2c/adv7180.c|  10 +-
 drivers/media/i2c/ml86v7667.c  |   5 +-
 drivers/media/i2c/mt9m111.c|   8 +-
 drivers/media/i2c/ov6650.c |  19 +--
 drivers/media/i2c/soc_camera/imx074.c  |   6 +-
 drivers/media/i2c/soc_camera/mt9m001.c |  10 +-
 drivers/media/i2c/soc_camera/mt9t031.c |  11 +-
 drivers/media/i2c/soc_camera/mt9t112.c |  11 +-
 drivers/media/i2c/soc_camera/mt9v022.c |  16 ++-
 drivers/media/i2c/soc_camera/ov5642.c  |   5 +-
 drivers/media/i2c/soc_camera/ov772x.c  |  10 +-
 drivers/media/i2c/soc_camera/ov9640.c  |  10 +-
 drivers/media/i2c/soc_camera/ov9740.c  |  10 +-
 drivers/media/i2c/soc_camera/rj54n1cb0c.c  |  12 +-
 drivers/media/i2c/soc_camera/tw9910.c  |  13 +-
 drivers/media/i2c/tc358743.c   |  10 +-
 drivers/media/i2c/tvp5150.c|   6 +-
 drivers/media/platform/pxa_camera.c|   8 +-
 drivers/media/platform/rcar-vin/rcar-core.c|   4 +-
 drivers/media/platform/rcar-vin/rcar-dma.c |   4 +-
 .../platform/soc_camera/sh_mobile_ceu_camera.c |   2 +-
 drivers/media/platform/soc_camera/soc_camera.c |   3 +-
 .../platform/soc_camera/soc_camera_platform.c  |   2 +-
 drivers/media/platform/soc_camera/soc_mediabus.c   |   2 +-
 drivers/media/v4l2-core/v4l2-fwnode.c  |   5 +-
 drivers/staging/media/imx/imx-media-csi.c  |   7 +-
 include/media/v4l2-fwnode.h|   4 +-
 include/media/v4l2-mediabus.h  | 145 ++---
 28 files changed, 222 insertions(+), 136 deletions(-)

diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 25d24a3f10a7..4bf25a72ef4f 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -743,16 +743,16 @@ static int adv7180_g_mbus_config(struct v4l2_subdev *sd,
 
if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
cfg->type = V4L2_MBUS_CSI2;
-   cfg->flags = V4L2_MBUS_CSI2_1_LANE |
-   V4L2_MBUS_CSI2_CHANNEL_0 |
-   V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
+   cfg->csi2_flags = V4L2_MBUS_CSI2_1_LANE
+ | V4L2_MBUS_CSI2_CHANNEL_0
+ | V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
} else {
/*
 * The ADV7180 sensor supports BT.601/656 output modes.
 * The BT.656 is default and not yet configurable by s/w.
 */
-   cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING |
-V4L2_MBUS_DATA_ACTIVE_HIGH;
+   cfg->pb_flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING
+   | V4L2_MBUS_DATA_ACTIVE_HIGH;
cfg->type = V4L2_MBUS_BT656;
}
 
diff --git a/drivers/media/i2c/ml86v7667.c b/drivers/media/i2c/ml86v7667.c
index 57ef901edb06..a25114d0c31f 100644
--- a/drivers/media/i2c/ml86v7667.c
+++ b/drivers/media/i2c/ml86v7667.c
@@ -226,8 +226,9 @@ static int ml86v7667_fill_fmt(struct v4l2_subdev *sd,
 static int ml86v7667_g_mbus_config(struct v4l2_subdev *sd,
   struct v4l2_mbus_config *cfg)
 {
-   cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING |
-V4L2_MBUS_DATA_ACTIVE_HIGH;
+   cfg->pb_flags = V4L2_MBUS_MASTER
+   | V4L2_MBUS_PCLK_SAMPLE_RISING
+   | V4L2_MBUS_DATA_ACTIVE_HIGH;
cfg->type = V4L2_MBUS_BT656;
 
return 0;
diff --git a/drivers/media/i2c/mt9m111.c b/drivers/media/i2c/mt9m111.c
index b1665d97e0fd..d9698b535080 100644
--- a/drivers/media/i2c/mt9m111.c
+++ b/drivers/media/i2c/mt9m111.c
@@ -857,9 +857,11 @@ static int 

[PATCH v2 8/8] media: v4l2-subdev: use kernel-doc markups to document subdev flags

2017-12-19 Thread Mauro Carvalho Chehab
Right now, those are documented together with the subdev struct,
instead of together with the definitions.

Convert the definitions to an enum, use BIT() macros and document
it at its right place.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-subdev.h | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index c8c827553042..473ddb1b2d39 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -18,6 +18,7 @@
 #define _V4L2_SUBDEV_H
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -772,14 +773,23 @@ struct v4l2_subdev_internal_ops {
 
 #define V4L2_SUBDEV_NAME_SIZE 32
 
-/* Set this flag if this subdev is a i2c device. */
-#define V4L2_SUBDEV_FL_IS_I2C  (1U << 0)
-/* Set this flag if this subdev is a spi device. */
-#define V4L2_SUBDEV_FL_IS_SPI  (1U << 1)
-/* Set this flag if this subdev needs a device node. */
-#define V4L2_SUBDEV_FL_HAS_DEVNODE (1U << 2)
-/* Set this flag if this subdev generates events. */
-#define V4L2_SUBDEV_FL_HAS_EVENTS  (1U << 3)
+/**
+ * enum v4l2_subdev_flags - flags used to describe a sub-device
+ * at  v4l2_subdev.
+ *
+ * @V4L2_SUBDEV_FL_IS_I2C: set this flag if this subdev is an I2C device;
+ * @V4L2_SUBDEV_FL_IS_SPI: set this flag if this subdev is a SPI device;
+ * @V4L2_SUBDEV_FL_HAS_DEVNODE: set this flag if this subdev needs
+ * a device node;
+ * @V4L2_SUBDEV_FL_HAS_EVENTS: set this flag if this subdev
+ *generates events.
+ */
+enum v4l2_subdev_flags {
+   V4L2_SUBDEV_FL_IS_I2C   = BIT(0),
+   V4L2_SUBDEV_FL_IS_SPI   = BIT(1),
+   V4L2_SUBDEV_FL_HAS_DEVNODE  = BIT(2),
+   V4L2_SUBDEV_FL_HAS_EVENTS   = BIT(3),
+};
 
 struct regulator_bulk_data;
 
@@ -805,13 +815,7 @@ struct v4l2_subdev_platform_data {
  * @owner: The owner is the same as the driver's  device owner.
  * @owner_v4l2_dev: true if the >owner matches the owner of @v4l2_dev->dev
  * owner. Initialized by v4l2_device_register_subdev().
- * @flags: subdev flags. Can be:
- *   %V4L2_SUBDEV_FL_IS_I2C - Set this flag if this subdev is a i2c device;
- *   %V4L2_SUBDEV_FL_IS_SPI - Set this flag if this subdev is a spi device;
- *   %V4L2_SUBDEV_FL_HAS_DEVNODE - Set this flag if this subdev needs a
- *   device node;
- *   %V4L2_SUBDEV_FL_HAS_EVENTS -  Set this flag if this subdev generates
- *   events.
+ * @flags: subdev flags, as defined by  v4l2_subdev_flags.
  *
  * @v4l2_dev: pointer to struct _device
  * @ops: pointer to struct _subdev_ops
-- 
2.14.3



[PATCH v2 2/8] media: v4l2-ioctl.h: convert debug into an enum of bits

2017-12-19 Thread Mauro Carvalho Chehab
The V4L2_DEV_DEBUG_IOCTL macros actually define a bitmask,
but without using Kernel's modern standards. Also,
documentation looks akward.

So, convert them into an enum with valid bits, adding
the correspoinding kernel-doc documentation for it.

In order to avoid possible conflicts, rename them from
V4L2_DEV_DEBUG_foo to V4L2_DEBUG_foo.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/v4l2-dev.c   | 18 +-
 drivers/media/v4l2-core/v4l2-ioctl.c |  7 ---
 include/media/v4l2-ioctl.h   | 33 +++--
 3 files changed, 32 insertions(+), 26 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index d5e0e536ef04..ab876ddaa707 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -307,8 +307,8 @@ static ssize_t v4l2_read(struct file *filp, char __user 
*buf,
return -EINVAL;
if (video_is_registered(vdev))
ret = vdev->fops->read(filp, buf, sz, off);
-   if ((vdev->dev_debug & V4L2_DEV_DEBUG_FOP) &&
-   (vdev->dev_debug & V4L2_DEV_DEBUG_STREAMING))
+   if ((vdev->dev_debug & BIT(V4L2_DEBUG_FOP)) &&
+   (vdev->dev_debug & BIT(V4L2_DEBUG_STREAMING)))
printk(KERN_DEBUG "%s: read: %zd (%d)\n",
video_device_node_name(vdev), sz, ret);
return ret;
@@ -324,8 +324,8 @@ static ssize_t v4l2_write(struct file *filp, const char 
__user *buf,
return -EINVAL;
if (video_is_registered(vdev))
ret = vdev->fops->write(filp, buf, sz, off);
-   if ((vdev->dev_debug & V4L2_DEV_DEBUG_FOP) &&
-   (vdev->dev_debug & V4L2_DEV_DEBUG_STREAMING))
+   if ((vdev->dev_debug & BIT(V4L2_DEBUG_FOP)) &&
+   (vdev->dev_debug & BIT(V4L2_DEBUG_STREAMING)))
printk(KERN_DEBUG "%s: write: %zd (%d)\n",
video_device_node_name(vdev), sz, ret);
return ret;
@@ -340,7 +340,7 @@ static unsigned int v4l2_poll(struct file *filp, struct 
poll_table_struct *poll)
return DEFAULT_POLLMASK;
if (video_is_registered(vdev))
res = vdev->fops->poll(filp, poll);
-   if (vdev->dev_debug & V4L2_DEV_DEBUG_POLL)
+   if (vdev->dev_debug & BIT(V4L2_DEBUG_POLL))
printk(KERN_DEBUG "%s: poll: %08x\n",
video_device_node_name(vdev), res);
return res;
@@ -381,7 +381,7 @@ static unsigned long v4l2_get_unmapped_area(struct file 
*filp,
if (!video_is_registered(vdev))
return -ENODEV;
ret = vdev->fops->get_unmapped_area(filp, addr, len, pgoff, flags);
-   if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
+   if (vdev->dev_debug & BIT(V4L2_DEBUG_FOP))
printk(KERN_DEBUG "%s: get_unmapped_area (%d)\n",
video_device_node_name(vdev), ret);
return ret;
@@ -397,7 +397,7 @@ static int v4l2_mmap(struct file *filp, struct 
vm_area_struct *vm)
return -ENODEV;
if (video_is_registered(vdev))
ret = vdev->fops->mmap(filp, vm);
-   if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
+   if (vdev->dev_debug & BIT(V4L2_DEBUG_FOP))
printk(KERN_DEBUG "%s: mmap (%d)\n",
video_device_node_name(vdev), ret);
return ret;
@@ -427,7 +427,7 @@ static int v4l2_open(struct inode *inode, struct file *filp)
ret = -ENODEV;
}
 
-   if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
+   if (vdev->dev_debug & BIT(V4L2_DEBUG_FOP))
printk(KERN_DEBUG "%s: open (%d)\n",
video_device_node_name(vdev), ret);
/* decrease the refcount in case of an error */
@@ -444,7 +444,7 @@ static int v4l2_release(struct inode *inode, struct file 
*filp)
 
if (vdev->fops->release)
ret = vdev->fops->release(filp);
-   if (vdev->dev_debug & V4L2_DEV_DEBUG_FOP)
+   if (vdev->dev_debug & BIT(V4L2_DEBUG_FOP))
printk(KERN_DEBUG "%s: release\n",
video_device_node_name(vdev));
 
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 79614992ee21..cdd1e9470dbe 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2760,15 +2760,16 @@ static long __video_do_ioctl(struct file *file,
}
 
 done:
-   if (dev_debug & (V4L2_DEV_DEBUG_IOCTL | V4L2_DEV_DEBUG_IOCTL_ARG)) {
-   if (!(dev_debug & V4L2_DEV_DEBUG_STREAMING) &&
+   if (dev_debug & (BIT(V4L2_DEBUG_IOCTL)
+| BIT(V4L2_DEBUG_IOCTL_ARG))) {
+   if (!(dev_debug & BIT(V4L2_DEBUG_STREAMING)) &&
(cmd == VIDIOC_QBUF || cmd == VIDIOC_DQBUF))
return ret;
 
v4l_printk_ioctl(video_device_node_name(vfd), cmd);

[PATCH v2 0/8] Some V4L2 documentation pending patches

2017-12-19 Thread Mauro Carvalho Chehab
This series contain the patches of a /17 and a /24 series
of documentation that required non-trivial changes.

-

v2: 
 - added acks on patch 3/8
 - added a missing fixup on patch 5/8, for staging/media/imx
 - on patch 6/8, use pad=0 when WARN_ON() if pad is out of range

Mauro Carvalho Chehab (8):
  media: v4l2-device.h: document helper macros
  media: v4l2-ioctl.h: convert debug into an enum of bits
  media: v4l2-async: simplify v4l2_async_subdev structure
  media: v4l2-async: better describe match union at async match struct
  media: v4l2-mediabus: convert flags to enums and document them
  media: v4l2-subdev: get rid of __V4L2_SUBDEV_MK_GET_TRY() macro
  media: v4l2-subdev: document remaining undocumented functions
  media: v4l2-subdev: use kernel-doc markups to document subdev flags

 drivers/media/i2c/adv7180.c|  10 +-
 drivers/media/i2c/ml86v7667.c  |   5 +-
 drivers/media/i2c/mt9m111.c|   8 +-
 drivers/media/i2c/ov6650.c |  19 +-
 drivers/media/i2c/soc_camera/imx074.c  |   6 +-
 drivers/media/i2c/soc_camera/mt9m001.c |  10 +-
 drivers/media/i2c/soc_camera/mt9t031.c |  11 +-
 drivers/media/i2c/soc_camera/mt9t112.c |  11 +-
 drivers/media/i2c/soc_camera/mt9v022.c |  16 +-
 drivers/media/i2c/soc_camera/ov5642.c  |   5 +-
 drivers/media/i2c/soc_camera/ov772x.c  |  10 +-
 drivers/media/i2c/soc_camera/ov9640.c  |  10 +-
 drivers/media/i2c/soc_camera/ov9740.c  |  10 +-
 drivers/media/i2c/soc_camera/rj54n1cb0c.c  |  12 +-
 drivers/media/i2c/soc_camera/tw9910.c  |  13 +-
 drivers/media/i2c/tc358743.c   |  10 +-
 drivers/media/i2c/tvp5150.c|   6 +-
 drivers/media/platform/am437x/am437x-vpfe.c|   6 +-
 drivers/media/platform/atmel/atmel-isc.c   |   2 +-
 drivers/media/platform/atmel/atmel-isi.c   |   2 +-
 drivers/media/platform/davinci/vpif_capture.c  |   4 +-
 drivers/media/platform/exynos4-is/media-dev.c  |   4 +-
 drivers/media/platform/pxa_camera.c|  10 +-
 drivers/media/platform/qcom/camss-8x16/camss.c |   2 +-
 drivers/media/platform/rcar-vin/rcar-core.c|   6 +-
 drivers/media/platform/rcar-vin/rcar-dma.c |   4 +-
 drivers/media/platform/rcar_drif.c |   4 +-
 .../platform/soc_camera/sh_mobile_ceu_camera.c |   2 +-
 drivers/media/platform/soc_camera/soc_camera.c |   5 +-
 .../platform/soc_camera/soc_camera_platform.c  |   2 +-
 drivers/media/platform/soc_camera/soc_mediabus.c   |   2 +-
 drivers/media/platform/stm32/stm32-dcmi.c  |   2 +-
 drivers/media/platform/ti-vpe/cal.c|   2 +-
 drivers/media/platform/xilinx/xilinx-vipp.c|   2 +-
 drivers/media/v4l2-core/v4l2-async.c   |  16 +-
 drivers/media/v4l2-core/v4l2-dev.c |  18 +-
 drivers/media/v4l2-core/v4l2-fwnode.c  |  15 +-
 drivers/media/v4l2-core/v4l2-ioctl.c   |   7 +-
 drivers/staging/media/imx/imx-media-csi.c  |   7 +-
 drivers/staging/media/imx/imx-media-dev.c  |   4 +-
 include/media/v4l2-async.h |  33 ++-
 include/media/v4l2-device.h| 246 ++---
 include/media/v4l2-fwnode.h|   4 +-
 include/media/v4l2-ioctl.h |  33 +--
 include/media/v4l2-mediabus.h  | 145 
 include/media/v4l2-subdev.h| 143 +---
 46 files changed, 636 insertions(+), 268 deletions(-)

-- 
2.14.3




[PATCH v2 7/8] media: v4l2-subdev: document remaining undocumented functions

2017-12-19 Thread Mauro Carvalho Chehab
There are several undocumented v4l2-subdev functions that are
part of kAPI. Document them.

Acked-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-subdev.h | 69 +
 1 file changed, 64 insertions(+), 5 deletions(-)

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 443e5e019006..c8c827553042 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -867,6 +867,13 @@ struct v4l2_subdev {
struct v4l2_subdev_platform_data *pdata;
 };
 
+
+/**
+ * media_entity_to_v4l2_subdev - Returns a  v4l2_subdev from
+ * the  media_entity embedded in it.
+ *
+ * @ent: pointer to  media_entity.
+ */
 #define media_entity_to_v4l2_subdev(ent)   \
 ({ \
typeof(ent) __me_sd_ent = (ent);\
@@ -876,14 +883,20 @@ struct v4l2_subdev {
NULL;   \
 })
 
+/**
+ * vdev_to_v4l2_subdev - Returns a  v4l2_subdev from
+ * the  video_device embedded on it.
+ *
+ * @vdev: pointer to  video_device
+ */
 #define vdev_to_v4l2_subdev(vdev) \
((struct v4l2_subdev *)video_get_drvdata(vdev))
 
 /**
  * struct v4l2_subdev_fh - Used for storing subdev information per file handle
  *
- * @vfh: pointer to struct v4l2_fh
- * @pad: pointer to v4l2_subdev_pad_config
+ * @vfh: pointer to  v4l2_fh
+ * @pad: pointer to  v4l2_subdev_pad_config
  */
 struct v4l2_subdev_fh {
struct v4l2_fh vfh;
@@ -892,10 +905,25 @@ struct v4l2_subdev_fh {
 #endif
 };
 
+/**
+ * to_v4l2_subdev_fh - Returns a  v4l2_subdev_fh from
+ * the  v4l2_fh embedded on it.
+ *
+ * @fh: pointer to  v4l2_fh
+ */
 #define to_v4l2_subdev_fh(fh)  \
container_of(fh, struct v4l2_subdev_fh, vfh)
 
 #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
+
+/**
+ * v4l2_subdev_get_try_format - ancillary routine to call
+ *  v4l2_subdev_pad_config->try_fmt
+ *
+ * @sd: pointer to  v4l2_subdev
+ * @cfg: pointer to  v4l2_subdev_pad_config array.
+ * @pad: index of the pad in the @cfg array.
+ */
 static inline struct v4l2_mbus_framefmt
 *v4l2_subdev_get_try_format(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
@@ -906,6 +934,14 @@ static inline struct v4l2_mbus_framefmt
return [pad].try_fmt;
 }
 
+/**
+ * v4l2_subdev_get_try_crop - ancillary routine to call
+ *  v4l2_subdev_pad_config->try_crop
+ *
+ * @sd: pointer to  v4l2_subdev
+ * @cfg: pointer to  v4l2_subdev_pad_config array.
+ * @pad: index of the pad in the @cfg array.
+ */
 static inline struct v4l2_rect
 *v4l2_subdev_get_try_crop(struct v4l2_subdev *sd,
  struct v4l2_subdev_pad_config *cfg,
@@ -916,6 +952,14 @@ static inline struct v4l2_rect
return [pad].try_crop;
 }
 
+/**
+ * v4l2_subdev_get_try_crop - ancillary routine to call
+ *  v4l2_subdev_pad_config->try_compose
+ *
+ * @sd: pointer to  v4l2_subdev
+ * @cfg: pointer to  v4l2_subdev_pad_config array.
+ * @pad: index of the pad in the @cfg array.
+ */
 static inline struct v4l2_rect
 *v4l2_subdev_get_try_compose(struct v4l2_subdev *sd,
 struct v4l2_subdev_pad_config *cfg,
@@ -1032,9 +1076,16 @@ void v4l2_subdev_free_pad_config(struct 
v4l2_subdev_pad_config *cfg);
 void v4l2_subdev_init(struct v4l2_subdev *sd,
  const struct v4l2_subdev_ops *ops);
 
-/*
- * Call an ops of a v4l2_subdev, doing the right checks against
- * NULL pointers.
+/**
+ * v4l2_subdev_call - call an operation of a v4l2_subdev.
+ *
+ * @sd: pointer to the  v4l2_subdev
+ * @o: name of the element at  v4l2_subdev_ops that contains @f.
+ * Each element there groups a set of callbacks functions.
+ * @f: callback function that will be called if @cond matches.
+ * The callback functions are defined in groups, according to
+ * each element at  v4l2_subdev_ops.
+ * @args...: arguments for @f.
  *
  * Example: err = v4l2_subdev_call(sd, video, s_std, norm);
  */
@@ -1050,6 +1101,14 @@ void v4l2_subdev_init(struct v4l2_subdev *sd,
__result;   \
})
 
+/**
+ * v4l2_subdev_has_op - Checks if a subdev defines a certain operation.
+ *
+ * @sd: pointer to the  v4l2_subdev
+ * @o: The group of callback functions in  v4l2_subdev_ops
+ * which @f is a part of.
+ * @f: callback function to be checked for its existence.
+ */
 #define v4l2_subdev_has_op(sd, o, f) \
((sd)->ops->o && (sd)->ops->o->f)
 
-- 
2.14.3



Re: iMX6q/coda encoder failures with ffmpeg/gstreamer m2m encoders

2017-12-19 Thread Philipp Zabel
Hi Neil,

On Tue, 2017-11-21 at 10:50 +0100, Neil Armstrong wrote:
> Hi,
> 
> I'm trying to make the coda960 h.264 encoder work on an i.MX6q SoC with Linux 
> 4.14 and the 3.1.1 firmware.
> 
> # dmesg | grep coda
> [4.846574] coda 204.vpu: Direct firmware load for vpu_fw_imx6q.bin 
> failed with error -2
> [4.901351] coda 204.vpu: Using fallback firmware vpu/vpu_fw_imx6q.bin
> [4.916039] coda 204.vpu: Firmware code revision: 46072
> [4.921641] coda 204.vpu: Initialized CODA960.
> [4.926589] coda 204.vpu: Firmware version: 3.1.1
> [4.932223] coda 204.vpu: codec registered as /dev/video[8-9]
> 
> Using gstreamer-plugins-good and the m2m v4l2 encoder, I have :
> 
> # gst-launch-1.0 videotestsrc num-buffers=1000 pattern=snow ! video/x-raw, 
> framerate=30/1, width=1280, height=720 ! v4l2h264enc ! h264parse ! mp4mux ! 
> filesink location=/dev/null
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> Redistribute latency...
> [ 1569.473717] coda 204.vpu: coda_s_fmt queue busy
> ERROR: from element /GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0: Device 
> '/dev/video8' is busy
> Additional debug info:
> ../../../gst-plugins-good-1.12.3/sys/v4l2/gstv4l2object.c(3609): 
> gst_v4l2_object_set_format_full (): 
> /GstPipeline:pipeline0/v4l2h264enc:v4l2h264enc0:
> Call to S_FMT failed for YU12 @ 1280x720: Device or resource busy
> ERROR: pipeline doesn't want to preroll.
> Setting pipeline to NULL ...
> Freeing pipeline ...

The coda driver does not allow S_FMT anymore, as soon as the buffers are
allocated with REQBUFS:

https://bugzilla.gnome.org/show_bug.cgi?id=791338

regards
Philipp


[PATCH v2 4/8] media: v4l2-async: better describe match union at async match struct

2017-12-19 Thread Mauro Carvalho Chehab
Now that kernel-doc handles nested unions, better document the
match union at struct v4l2_async_subdev.

Acked-by: Sakari Ailus 
Signed-off-by: Mauro Carvalho Chehab 
---
 include/media/v4l2-async.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/include/media/v4l2-async.h b/include/media/v4l2-async.h
index a010af5134b2..96e19246b934 100644
--- a/include/media/v4l2-async.h
+++ b/include/media/v4l2-async.h
@@ -48,6 +48,31 @@ enum v4l2_async_match_type {
  *
  * @match_type:type of match that will be used
  * @match: union of per-bus type matching data sets
+ * @match.fwnode:
+ * pointer to  fwnode_handle to be matched.
+ * Used if @match_type is %V4L2_ASYNC_MATCH_FWNODE.
+ * @match.device_name:
+ * string containing the device name to be matched.
+ * Used if @match_type is %V4L2_ASYNC_MATCH_DEVNAME.
+ * @match.i2c: embedded struct with I2C parameters to be matched.
+ * Both @match.i2c.adapter_id and @match.i2c.address
+ * should be matched.
+ * Used if @match_type is %V4L2_ASYNC_MATCH_I2C.
+ * @match.i2c.adapter_id:
+ * I2C adapter ID to be matched.
+ * Used if @match_type is %V4L2_ASYNC_MATCH_I2C.
+ * @match.i2c.address:
+ * I2C address to be matched.
+ * Used if @match_type is %V4L2_ASYNC_MATCH_I2C.
+ * @match.custom:
+ * Driver-specific match criteria.
+ * Used if @match_type is %V4L2_ASYNC_MATCH_CUSTOM.
+ * @match.custom.match:
+ * Driver-specific match function to be used if
+ * %V4L2_ASYNC_MATCH_CUSTOM.
+ * @match.custom.priv:
+ * Driver-specific private struct with match parameters
+ * to be used if %V4L2_ASYNC_MATCH_CUSTOM.
  * @list:  used to link struct v4l2_async_subdev objects, waiting to be
  * probed, to a notifier->waiting list
  *
-- 
2.14.3



[PATCH v2 3/8] media: v4l2-async: simplify v4l2_async_subdev structure

2017-12-19 Thread Mauro Carvalho Chehab
The V4L2_ASYNC_MATCH_FWNODE match criteria requires just one
struct to be filled (struct fwnode_handle). The V4L2_ASYNC_MATCH_DEVNAME
match criteria requires just a device name.

So, it doesn't make sense to enclose those into structs,
as the criteria can go directly into the union.

That makes easier to document it, as we don't need to document
weird senseless structs.

At drivers, this makes even clearer about the match criteria.

Acked-by: Sylwester Nawrocki 
Acked-by: Benoit Parrot 
Acked-by: Alexandre Belloni 
Acked-by: Sakari Ailus 
Acked-by: Philipp Zabel 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/am437x/am437x-vpfe.c|  6 +++---
 drivers/media/platform/atmel/atmel-isc.c   |  2 +-
 drivers/media/platform/atmel/atmel-isi.c   |  2 +-
 drivers/media/platform/davinci/vpif_capture.c  |  4 ++--
 drivers/media/platform/exynos4-is/media-dev.c  |  4 ++--
 drivers/media/platform/pxa_camera.c|  2 +-
 drivers/media/platform/qcom/camss-8x16/camss.c |  2 +-
 drivers/media/platform/rcar-vin/rcar-core.c|  2 +-
 drivers/media/platform/rcar_drif.c |  4 ++--
 drivers/media/platform/soc_camera/soc_camera.c |  2 +-
 drivers/media/platform/stm32/stm32-dcmi.c  |  2 +-
 drivers/media/platform/ti-vpe/cal.c|  2 +-
 drivers/media/platform/xilinx/xilinx-vipp.c|  2 +-
 drivers/media/v4l2-core/v4l2-async.c   | 16 
 drivers/media/v4l2-core/v4l2-fwnode.c  | 10 +-
 drivers/staging/media/imx/imx-media-dev.c  |  4 ++--
 include/media/v4l2-async.h |  8 ++--
 17 files changed, 35 insertions(+), 39 deletions(-)

diff --git a/drivers/media/platform/am437x/am437x-vpfe.c 
b/drivers/media/platform/am437x/am437x-vpfe.c
index 0997c640191d..601ae6487617 100644
--- a/drivers/media/platform/am437x/am437x-vpfe.c
+++ b/drivers/media/platform/am437x/am437x-vpfe.c
@@ -2304,8 +2304,8 @@ vpfe_async_bound(struct v4l2_async_notifier *notifier,
vpfe_dbg(1, vpfe, "vpfe_async_bound\n");
 
for (i = 0; i < ARRAY_SIZE(vpfe->cfg->asd); i++) {
-   if (vpfe->cfg->asd[i]->match.fwnode.fwnode ==
-   asd[i].match.fwnode.fwnode) {
+   if (vpfe->cfg->asd[i]->match.fwnode ==
+   asd[i].match.fwnode) {
sdinfo = >cfg->sub_devs[i];
vpfe->sd[i] = subdev;
vpfe->sd[i]->grp_id = sdinfo->grp_id;
@@ -2510,7 +2510,7 @@ vpfe_get_pdata(struct platform_device *pdev)
}
 
pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
-   pdata->asd[i]->match.fwnode.fwnode = of_fwnode_handle(rem);
+   pdata->asd[i]->match.fwnode = of_fwnode_handle(rem);
of_node_put(rem);
}
 
diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 0c2635647f69..34676409ca08 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -2088,7 +2088,7 @@ static int isc_parse_dt(struct device *dev, struct 
isc_device *isc)
subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
 
subdev_entity->asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
-   subdev_entity->asd->match.fwnode.fwnode =
+   subdev_entity->asd->match.fwnode =
of_fwnode_handle(rem);
list_add_tail(_entity->list, >subdev_entities);
}
diff --git a/drivers/media/platform/atmel/atmel-isi.c 
b/drivers/media/platform/atmel/atmel-isi.c
index e900995143a3..9958918e2449 100644
--- a/drivers/media/platform/atmel/atmel-isi.c
+++ b/drivers/media/platform/atmel/atmel-isi.c
@@ -1128,7 +1128,7 @@ static int isi_graph_parse(struct atmel_isi *isi, struct 
device_node *node)
/* Remote node to connect */
isi->entity.node = remote;
isi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
-   isi->entity.asd.match.fwnode.fwnode = of_fwnode_handle(remote);
+   isi->entity.asd.match.fwnode = of_fwnode_handle(remote);
return 0;
}
 }
diff --git a/drivers/media/platform/davinci/vpif_capture.c 
b/drivers/media/platform/davinci/vpif_capture.c
index e45916f69def..e1c273c8b9a6 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -1390,7 +1390,7 @@ static int vpif_async_bound(struct v4l2_async_notifier 
*notifier,
 
for (i = 0; i < vpif_obj.config->asd_sizes[0]; i++) {
struct v4l2_async_subdev *_asd = vpif_obj.config->asd[i];
-   const struct fwnode_handle *fwnode = _asd->match.fwnode.fwnode;
+   const struct fwnode_handle *fwnode = _asd->match.fwnode;
 

Re: [PATCH v5 4/6] media: i2c: Add TDA1997x HDMI receiver driver

2017-12-19 Thread Hans Verkuil
On 16/12/17 19:00, Tim Harvey wrote:
> Add support for the TDA1997x HDMI receivers.
> 
> Cc: Hans Verkuil 
> Signed-off-by: Tim Harvey 
> ---
> v5:
>  - uppercase string constants
>  - use v4l2_hdmi_rx_coloriemtry to fill format
>  - fix V4L2_CID_DV_RX_RGB_RANGE
>  - fix interlaced mode format
> 
> v4:
>  - move include/dt-bindings/media/tda1997x.h to bindings patch
>  - fix typos
>  - fix default quant range for VGA
>  - fix quant range handling and conv matrix
>  - add additional standards and capabilities to timings_cap
> 
> v3:
>  - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros
>  - fixed missing break
>  - use only hdmi_infoframe_log for infoframe logging
>  - simplify tda1997x_s_stream error handling
>  - add delayed work proc to handle hotplug enable/disable
>  - fix set_edid (disable HPD before writing, enable after)
>  - remove enabling edid by default
>  - initialize timings
>  - take quant range into account in colorspace conversion
>  - remove vendor/product tracking (we provide this in log_status via 
> infoframes)
>  - add v4l_controls
>  - add more detail to log_status
>  - calculate vhref generator timings
>  - timing detection fixes (rounding errors, hswidth errors)
>  - rename configure_input/configure_conv functions
> 
> v2:
>  - implement dv timings enum/cap
>  - remove deprecated g_mbus_config op
>  - fix dv_query_timings
>  - add EDID get/set handling
>  - remove max-pixel-rate support
>  - add audio codec DAI support
>  - change audio bindings
> ---
>  drivers/media/i2c/Kconfig|9 +
>  drivers/media/i2c/Makefile   |1 +
>  drivers/media/i2c/tda1997x.c | 3520 
> ++
>  include/media/i2c/tda1997x.h |   53 +
>  4 files changed, 3583 insertions(+)
>  create mode 100644 drivers/media/i2c/tda1997x.c
>  create mode 100644 include/media/i2c/tda1997x.h
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 3c6d642..abf24b9 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -56,6 +56,15 @@ config VIDEO_TDA9840
> To compile this driver as a module, choose M here: the
> module will be called tda9840.
>  
> +config VIDEO_TDA1997X
> + tristate "NXP TDA1997x HDMI receiver"
> + depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
> + ---help---
> +   V4L2 subdevice driver for the NXP TDA1997x HDMI receivers.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called tda1997x.
> +
>  config VIDEO_TEA6415C
>   tristate "Philips TEA6415C audio processor"
>   depends on I2C
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 548a9ef..adfcae9 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o
>  obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o
>  obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o
>  obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o
> +obj-$(CONFIG_VIDEO_TDA1997X) += tda1997x.o
>  obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o
>  obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o
>  obj-$(CONFIG_VIDEO_SAA7110) += saa7110.o
> diff --git a/drivers/media/i2c/tda1997x.c b/drivers/media/i2c/tda1997x.c
> new file mode 100644
> index 000..aea970f
> --- /dev/null
> +++ b/drivers/media/i2c/tda1997x.c
> @@ -0,0 +1,3520 @@
> +/*
> + * Copyright (C) 2017 Gateworks Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +/* debug level */
> +static int debug;
> +module_param(debug, int, 0644);
> +MODULE_PARM_DESC(debug, "debug level (0-2)");
> +
> +/* Page 0x00 - General Control */
> +#define REG_VERSION  0x
> +#define REG_INPUT_SEL0x0001
> +#define REG_SVC_MODE 0x0002
> +#define REG_HPD_MAN_CTRL 0x0003
> +#define REG_RT_MAN_CTRL  0x0004
> +#define REG_STANDBY_SOFT_RST 0x000A
> +#define REG_HDMI_SOFT_RST0x000B
> +#define REG_HDMI_INFO_RST0x000C
> +#define REG_INT_FLG_CLR_TOP  0x000E
> +#define REG_INT_FLG_CLR_SUS  0x000F
> +#define REG_INT_FLG_CLR_DDC  0x0010
> +#define REG_INT_FLG_CLR_RATE 0x0011
> +#define REG_INT_FLG_CLR_MODE 0x0012
> +#define REG_INT_FLG_CLR_INFO 0x0013
> +#define REG_INT_FLG_CLR_AUDIO0x0014
> +#define REG_INT_FLG_CLR_HDCP 0x0015
> +#define REG_INT_FLG_CLR_AFE  0x0016
> +#define REG_INT_MASK_TOP 0x0017
> +#define REG_INT_MASK_SUS 0x0018
> +#define 

Re: [PATCH 5/8] media: v4l2-mediabus: convert flags to enums and document them

2017-12-19 Thread Mauro Carvalho Chehab
Em Tue, 19 Dec 2017 10:30:15 +0100
Philipp Zabel  escreveu:

> Hi Mauro,
> 
> On Mon, 2017-12-18 at 17:53 -0200, Mauro Carvalho Chehab wrote:
> > There is a mess with media bus flags: there are two sets of
> > flags, one used by parallel and ITU-R BT.656 outputs,
> > and another one for CSI2.
> > 
> > Depending on the type, the same bit has different meanings.
> > 
> > That's very confusing, and counter-intuitive. So, split them
> > into two sets of flags, inside an enum.
> > 
> > This way, it becomes clearer that there are two separate sets
> > of flags. It also makes easier if CSI1, CSP, CSI3, etc. would
> > need a different set of flags.
> > 
> > As a side effect, enums can be documented via kernel-docs,
> > so there will be an improvement at flags documentation.
> > 
> > Unfortunately, soc_camera and pxa_camera do a mess with
> > the flags, using either one set of flags without proper
> > checks about the type. That could be fixed, but, as both drivers
> > are obsolete and in the process of cleanings, I opted to just
> > keep the behavior, using an unsigned int inside those two
> > drivers.
> > 
> > Acked-by: Hans Verkuil 
> > Signed-off-by: Mauro Carvalho Chehab   
> 
> If I am not mistaken this is missing a conversion of
> drivers/staging/media/imx/imx-media-csi.c:
> 
> 8<
> diff --git a/drivers/staging/media/imx/imx-media-csi.c 
> b/drivers/staging/media/imx/imx-media-csi.c
> index eb7be5093a9d5..b1daac3a537d9 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -636,9 +636,10 @@ static int csi_setup(struct csi_priv *priv)
>  
>   /* compose mbus_config from the upstream endpoint */
>   mbus_cfg.type = priv->upstream_ep.bus_type;
> - mbus_cfg.flags = (priv->upstream_ep.bus_type == V4L2_MBUS_CSI2) ?
> - priv->upstream_ep.bus.mipi_csi2.flags :
> - priv->upstream_ep.bus.parallel.flags;
> + if (priv->upstream_ep.bus_type == V4L2_MBUS_CSI2)
> + mbus_cfg.csi2_flags = priv->upstream_ep.bus.mipi_csi2.flags;
> + else
> + mbus_cfg.pb_flags = priv->upstream_ep.bus.parallel.flags;
>  
>   /*
>    * we need to pass input frame to CSI interface, but


Oh, thanks for noticing! I really hate having drivers that don't
build with COMPILE_TEST, as that makes a lot harder to check if
something broke.


Thanks,
Mauro


Re: [PATCH 15/24] media: v4l2-subdev: get rid of __V4L2_SUBDEV_MK_GET_TRY() macro

2017-12-19 Thread Mauro Carvalho Chehab
Em Tue, 19 Dec 2017 10:24:51 +0200
Sakari Ailus  escreveu:

> On Mon, Dec 18, 2017 at 05:27:04PM -0200, Mauro Carvalho Chehab wrote:
> > Em Mon, 9 Oct 2017 23:23:56 +0300
> > Sakari Ailus  escreveu:
> >   
> > > Hi Mauro,
> > > 
> > > On Mon, Oct 09, 2017 at 07:19:21AM -0300, Mauro Carvalho Chehab wrote:  
> > > > The __V4L2_SUBDEV_MK_GET_TRY() macro is used to define
> > > > 3 functions that have the same arguments. The code of those
> > > > functions is simple enough to just declare them, de-obfuscating
> > > > the code.
> > > > 
> > > > While here, replace BUG_ON() by WARN_ON() as there's no reason
> > > > why to panic the Kernel if this fails.  
> > > 
> > > BUG_ON() might actually be a better idea as this will lead to memory
> > > corruption. I presume it's not been hit often.  
> > 
> > Well, let's then change the code to:
> > 
> > if (WARN_ON(pad >= sd->entity.num_pads)) 
> > return -EINVAL;
> > 
> > This way, it won't try to use an invalid value. As those are default
> > handlers for ioctls, userspace should be able to handle it.  
> 
> Another approach would be to return the entry for a valid pad. Few if any
> drivers perform error handling on the value returned for the simple reason
> that they know how many pads their own entities have.

Well, they should check for errors on returned values :-)

Anyway, I guess that using pad=0 as a way to avoid Kernel crashes
is not a bad idea.

Patch enclosed. It replaces patch 6/8.

Thanks,
Mauro

[PATCH] media: v4l2-subdev: get rid of __V4L2_SUBDEV_MK_GET_TRY() macro

The __V4L2_SUBDEV_MK_GET_TRY() macro is used to define
3 functions that have the same arguments. The code of those
functions is simple enough to just declare them, de-obfuscating
the code.

While here, replace BUG_ON() by WARN_ON() as there's no reason
why to panic the Kernel if this fails.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 71b8ff4b2e0e..443e5e019006 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -896,19 +896,35 @@ struct v4l2_subdev_fh {
container_of(fh, struct v4l2_subdev_fh, vfh)
 
 #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
-#define __V4L2_SUBDEV_MK_GET_TRY(rtype, fun_name, field_name)  \
-   static inline struct rtype *\
-   fun_name(struct v4l2_subdev *sd,\
-struct v4l2_subdev_pad_config *cfg,\
-unsigned int pad)  \
-   {   \
-   BUG_ON(pad >= sd->entity.num_pads); \
-   return [pad].field_name;\
-   }
+static inline struct v4l2_mbus_framefmt
+*v4l2_subdev_get_try_format(struct v4l2_subdev *sd,
+   struct v4l2_subdev_pad_config *cfg,
+   unsigned int pad)
+{
+   if (WARN_ON(pad >= sd->entity.num_pads))
+   pad = 0;
+   return [pad].try_fmt;
+}
+
+static inline struct v4l2_rect
+*v4l2_subdev_get_try_crop(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ unsigned int pad)
+{
+   if (WARN_ON(pad >= sd->entity.num_pads))
+   pad = 0;
+   return [pad].try_crop;
+}
 
-__V4L2_SUBDEV_MK_GET_TRY(v4l2_mbus_framefmt, v4l2_subdev_get_try_format, 
try_fmt)
-__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, v4l2_subdev_get_try_crop, try_crop)
-__V4L2_SUBDEV_MK_GET_TRY(v4l2_rect, v4l2_subdev_get_try_compose, try_compose)
+static inline struct v4l2_rect
+*v4l2_subdev_get_try_compose(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg,
+unsigned int pad)
+{
+   if (WARN_ON(pad >= sd->entity.num_pads))
+   pad = 0;
+   return [pad].try_compose;
+}
 #endif
 
 extern const struct v4l2_file_operations v4l2_subdev_fops;


Re: [PATCH 09/45] drivers: media: remove duplicate includes

2017-12-19 Thread Sakari Ailus
On Sun, Dec 10, 2017 at 11:03:29PM +0530, Pravin Shedge wrote:
> On Thu, Dec 7, 2017 at 7:05 PM, Sakari Ailus  wrote:
> > Hi Pravin,
> >
> > On Wed, Dec 06, 2017 at 10:22:02PM +0530, Pravin Shedge wrote:
> >> These duplicate includes have been found with scripts/checkincludes.pl but
> >> they have been removed manually to avoid removing false positives.
> >>
> >> Signed-off-by: Pravin Shedge 
> >
> > While at it, how about ordering the headers alphabetically as well? Having
> > such a large number of headers there unordered may well be the reason why
> > they're included more than once...
> >
> > --
> > Sakari Ailus
> > e-mail: sakari.ai...@iki.fi
> 
> 
> Hi Sakari,
> 
> Sorry for the late reply.
> 
> Ordering the header files alphabetically helps to avoid problems such
> as inclusion of duplicate header files.
> My personal preference is to go from local to global, each subsection
> in alphabetical order.
> Ideally, all header files should be self-contained, and inclusion
> order should not matter.
> Simple reordering the headers should not break build.
> 
> Reordering header files aways helpful for big projects like Linux-Kernel.
> But this requires changes tree wide and modifies lots of files.
> Such change requires huge audience to be participated in discussion &
> take a final call.

Hmm. I'm not quite sure what do you mean. You're already changing the three
files, there's no need to arrange others at the same time.

> 
> With this patch I just handled inclusion of header file multiple times
> to avoid code duplication after preprocessing.
> 
> Thanks & Regards,
>PraviN

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


Re: [PATCH V2 1/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_reset

2017-12-19 Thread Fabien DESSENNE
Hi,


On 16/12/17 12:54, Jia-Ju Bai wrote:
> The driver may sleep under a spinlock.
> The function call path is:
> bdisp_device_run (acquire the spinlock)
>bdisp_hw_reset
>  msleep --> may sleep
>
> To fix it, readl_poll_timeout_atomic is used to replace msleep.
>
> This bug is found by my static analysis tool(DSAC) and
> checked by my code review.
>
> Signed-off-by: Jia-Ju Bai 
> ---
>   drivers/media/platform/sti/bdisp/bdisp-hw.c |   16 
>   1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/platform/sti/bdisp/bdisp-hw.c 
> b/drivers/media/platform/sti/bdisp/bdisp-hw.c
> index b7892f3..e94a371 100644
> --- a/drivers/media/platform/sti/bdisp/bdisp-hw.c
> +++ b/drivers/media/platform/sti/bdisp/bdisp-hw.c
> @@ -5,6 +5,7 @@
>*/
>   
>   #include 

This delay.h include is no more needed, remove it.

> +#include 
>   
>   #include "bdisp.h"
>   #include "bdisp-filter.h"
> @@ -366,7 +367,7 @@ struct bdisp_filter_addr {
>*/
>   int bdisp_hw_reset(struct bdisp_dev *bdisp)
>   {
> - unsigned int i;
> + u32 tmp;
>   
>   dev_dbg(bdisp->dev, "%s\n", __func__);
>   
> @@ -379,15 +380,14 @@ int bdisp_hw_reset(struct bdisp_dev *bdisp)
>   writel(0, bdisp->regs + BLT_CTL);
>   
>   /* Wait for reset done */
> - for (i = 0; i < POLL_RST_MAX; i++) {
> - if (readl(bdisp->regs + BLT_STA1) & BLT_STA1_IDLE)
> - break;
> - msleep(POLL_RST_DELAY_MS);
> - }
> - if (i == POLL_RST_MAX)

As recommended by Mauro, please add this comment:
Despite the large timeout, most of the time the reset happens without 
needing any delays

> + if (readl_poll_timeout_atomic(bdisp->regs + BLT_STA1, tmp,
> + (tmp & BLT_STA1_IDLE), POLL_RST_DELAY_MS,
> + POLL_RST_DELAY_MS * POLL_RST_MAX)) {

read_poll_timeout expects US timings, not MS.

>   dev_err(bdisp->dev, "Reset timeout\n");
> + return -EAGAIN;
> + }
>   
> - return (i == POLL_RST_MAX) ? -EAGAIN : 0;
> + return 0;
>   }
>   
>   /**


Re: [PATCH for 4.15] omapdrm/dss/hdmi4_cec: fix interrupt handling

2017-12-19 Thread Tomi Valkeinen

On 04/12/17 15:32, Hans Verkuil wrote:

The omap4 CEC hardware cannot tell a Nack from a Low Drive from an
Arbitration Lost error, so just report a Nack, which is almost
certainly the reason for the error anyway.

This also simplifies the implementation. The only three interrupts
that need to be enabled are:

Transmit Buffer Full/Empty Change event: triggered when the
transmit finished successfully and cleared the buffer.

Receiver FIFO Not Empty event: triggered when a message was received.

Frame Retransmit Count Exceeded event: triggered when a transmit
failed repeatedly, usually due to the message being Nacked. Other
reasons are possible (Low Drive, Arbitration Lost) but there is no
way to know. If this happens the TX buffer needs to be cleared
manually.

While testing various error conditions I noticed that the hardware
can receive messages up to 18 bytes in total, which exceeds the legal
maximum of 16. This could cause a buffer overflow, so we check for
this and constrain the size to 16 bytes.

The old incorrect interrupt handler could cause the CEC framework to
enter into a bad state because it mis-detected the "Start Bit Irregularity
event" as an ARB_LOST transmit error when it actually is a receive error
which should be ignored.

Signed-off-by: Hans Verkuil 
Reported-by: Henrik Austad 
Tested-by: Henrik Austad 
Tested-by: Hans Verkuil 
---
  drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 46 +++--
  1 file changed, 9 insertions(+), 37 deletions(-)


Thanks, I have picked up this patch.

 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


Re: [linux-sunxi] [PATCH v3 1/3] media: V3s: Add support for Allwinner CSI.

2017-12-19 Thread Chen-Yu Tsai
On Mon, Nov 13, 2017 at 3:30 PM, Yong Deng  wrote:
> Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> and CSI1 is used for parallel interface. This is not documented in
> datasheet but by testing and guess.
>
> This patch implement a v4l2 framework driver for it.
>
> Currently, the driver only support the parallel interface. MIPI-CSI2,
> ISP's support are not included in this patch.
>
> Signed-off-by: Yong Deng 
> ---
>  drivers/media/platform/Kconfig |   1 +
>  drivers/media/platform/Makefile|   2 +
>  drivers/media/platform/sunxi/sun6i-csi/Kconfig |   9 +
>  drivers/media/platform/sunxi/sun6i-csi/Makefile|   3 +
>  drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 918 
> +
>  drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 146 
>  .../media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h | 203 +
>  .../media/platform/sunxi/sun6i-csi/sun6i_video.c   | 722 
>  .../media/platform/sunxi/sun6i-csi/sun6i_video.h   |  61 ++
>  9 files changed, 2065 insertions(+)
>  create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Kconfig
>  create mode 100644 drivers/media/platform/sunxi/sun6i-csi/Makefile
>  create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
>  create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h
>  create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi_reg.h
>  create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
>  create mode 100644 drivers/media/platform/sunxi/sun6i-csi/sun6i_video.h
>

[...]

> diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c 
> b/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c
> new file mode 100644
> index 000..0cebcbd
> --- /dev/null
> +++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c

[...]

> +/* 
> -
> + * Media Operations
> + */
> +static int sun6i_video_formats_init(struct sun6i_video *video)
> +{
> +   struct v4l2_subdev_mbus_code_enum mbus_code = { 0 };
> +   struct sun6i_csi *csi = video->csi;
> +   struct v4l2_format format;
> +   struct v4l2_subdev *subdev;
> +   u32 pad;
> +   const u32 *pixformats;
> +   int pixformat_count = 0;
> +   u32 subdev_codes[32]; /* subdev format codes, 32 should be enough */
> +   int codes_count = 0;
> +   int num_fmts = 0;
> +   int i, j;
> +
> +   subdev = sun6i_video_remote_subdev(video, );
> +   if (subdev == NULL)
> +   return -ENXIO;
> +
> +   /* Get supported pixformats of CSI */
> +   pixformat_count = sun6i_csi_get_supported_pixformats(csi, 
> );
> +   if (pixformat_count <= 0)
> +   return -ENXIO;
> +
> +   /* Get subdev formats codes */
> +   mbus_code.pad = pad;
> +   mbus_code.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> +   while (!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL,
> +_code)) {
> +   if (codes_count >= ARRAY_SIZE(subdev_codes)) {
> +   dev_warn(video->csi->dev,
> +"subdev_codes array is full!\n");
> +   break;
> +   }
> +   subdev_codes[codes_count] = mbus_code.code;
> +   codes_count++;
> +   mbus_code.index++;
> +   }
> +
> +   if (!codes_count)
> +   return -ENXIO;
> +
> +   /* Get supported formats count */
> +   for (i = 0; i < codes_count; i++) {
> +   for (j = 0; j < pixformat_count; j++) {
> +   if (!sun6i_csi_is_format_support(csi, pixformats[j],
> +   mbus_code.code)) {

Bug here. You are testing against mbus_code.code, which would be whatever
was leftover from the previous section. Instead you should be testing
against subdev_codes[i], the list you just built.

Without it, it won't get past this part of the code if the last enumerated
media bus format isn't supported.

> +   continue;
> +   }
> +   num_fmts++;
> +   }
> +   }
> +
> +   if (!num_fmts)
> +   return -ENXIO;
> +
> +   video->num_formats = num_fmts;
> +   video->formats = devm_kcalloc(video->csi->dev, num_fmts,
> +   sizeof(struct sun6i_csi_format), GFP_KERNEL);
> +   if (!video->formats)
> +   return -ENOMEM;
> +
> +   /* Get supported formats */
> +   num_fmts = 0;
> +   for (i = 0; i < codes_count; i++) {
> +   for (j = 0; j < pixformat_count; j++) {
> +   if (!sun6i_csi_is_format_support(csi, pixformats[j],
> +   mbus_code.code)) {

Same here.

This gets me past the enumeration part of things...

> +   

Re: [PATCH] media: ov9650: support VIDIOC_DBG_G/S_REGISTER ioctls

2017-12-19 Thread Sakari Ailus
Hi Akinobu,

On Thu, Dec 14, 2017 at 01:00:49AM +0900, Akinobu Mita wrote:
> This adds support VIDIOC_DBG_G/S_REGISTER ioctls.
> 
> There are many device control registers contained in the OV9650.  So
> this helps debugging the lower level issues by getting and setting the
> registers.
> 
> Cc: Sylwester Nawrocki 
> Cc: Sakari Ailus 
> Cc: Mauro Carvalho Chehab 
> Signed-off-by: Akinobu Mita 

Just wondering --- doesn't the I²C user space interface offer essentially
the same functionality?

See: Documentation/i2c/dev-interface

Cc Hans.

> ---
>  drivers/media/i2c/ov9650.c | 36 
>  1 file changed, 36 insertions(+)
> 
> diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
> index 69433e1..c6462cf 100644
> --- a/drivers/media/i2c/ov9650.c
> +++ b/drivers/media/i2c/ov9650.c
> @@ -1374,6 +1374,38 @@ static int ov965x_open(struct v4l2_subdev *sd, struct 
> v4l2_subdev_fh *fh)
>   return 0;
>  }
>  
> +#ifdef CONFIG_VIDEO_ADV_DEBUG
> +
> +static int ov965x_g_register(struct v4l2_subdev *sd,
> +  struct v4l2_dbg_register *reg)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> + u8 val = 0;
> + int ret;
> +
> + if (reg->reg > 0xff)
> + return -EINVAL;
> +
> + ret = ov965x_read(client, reg->reg, );
> + reg->val = val;
> + reg->size = 1;
> +
> + return ret;
> +}
> +
> +static int ov965x_s_register(struct v4l2_subdev *sd,
> +  const struct v4l2_dbg_register *reg)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(sd);
> +
> + if (reg->reg > 0xff || reg->val > 0xff)
> + return -EINVAL;
> +
> + return ov965x_write(client, reg->reg, reg->val);
> +}
> +
> +#endif
> +
>  static const struct v4l2_subdev_pad_ops ov965x_pad_ops = {
>   .enum_mbus_code = ov965x_enum_mbus_code,
>   .enum_frame_size = ov965x_enum_frame_sizes,
> @@ -1397,6 +1429,10 @@ static const struct v4l2_subdev_core_ops 
> ov965x_core_ops = {
>   .log_status = v4l2_ctrl_subdev_log_status,
>   .subscribe_event = v4l2_ctrl_subdev_subscribe_event,
>   .unsubscribe_event = v4l2_event_subdev_unsubscribe,
> +#ifdef CONFIG_VIDEO_ADV_DEBUG
> + .g_register = ov965x_g_register,
> + .s_register = ov965x_s_register,
> +#endif
>  };
>  
>  static const struct v4l2_subdev_ops ov965x_subdev_ops = {
> -- 
> 2.7.4
> 

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


Re: [PATCH v3 3/5] media: dt-bindings: ov5640: add support of DVP parallel interface

2017-12-19 Thread Hugues FRUCHET
Thanks Sakari,

I'll push a patchset based on this discussion.

Best regards,
Hugues.

On 12/19/2017 11:08 AM, Sakari Ailus wrote:
> Hi Hugues,
> 
> On Mon, Dec 18, 2017 at 10:24:40AM +, Hugues FRUCHET wrote:
>> Hi Sakari,
>>
>> On 12/13/2017 08:47 PM, Sakari Ailus wrote:
>>> Hi Hugues,
>>>
>>> Hugues FRUCHET wrote:
 Hi Sakari,

 On 12/07/2017 02:59 PM, Sakari Ailus wrote:
> Hi Hugues,
>
> On Thu, Dec 07, 2017 at 01:40:51PM +0100, Hugues Fruchet wrote:
>> Add bindings for OV5640 DVP parallel interface support.
>>
>> Signed-off-by: Hugues Fruchet 
>> ---
>> .../devicetree/bindings/media/i2c/ov5640.txt   | 27 
>> --
>> 1 file changed, 25 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt 
>> b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
>> index 540b36c..04e2a91 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
>> +++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
>> @@ -1,4 +1,4 @@
>> -* Omnivision OV5640 MIPI CSI-2 sensor
>> +* Omnivision OV5640 MIPI CSI-2 / parallel sensor
>> 
>> Required Properties:
>> - compatible: should be "ovti,ov5640"
>> @@ -18,7 +18,11 @@ The device node must contain one 'port' child node 
>> for its digital output
>> video port, in accordance with the video interface bindings defined 
>> in
>> Documentation/devicetree/bindings/media/video-interfaces.txt.
>> 
>> -Example:
>> +Parallel or CSI mode is selected according to optional endpoint 
>> properties.
>> +Without properties (or bus properties), parallel mode is selected.
>> +Specifying any CSI properties such as lanes will enable CSI mode.
>
> These bindings never documented what which endpoint properties were 
> needed.

 Ok I will add a section related to endpoint properties for both CSI and
 parallel.

>
> Beyond that, the sensor supports two CSI-2 lanes. You should explicitly
> specify that, in other words, you'll need "data-lanes" property. Could you
> add that?
 Ok I will add it to required endpoint property in case of CSI mode.
 I will change commit header to reflect changes on parallel but also CSI
 documentation.

>
> Long time ago when the video-interfaces.txt and the V4L2 OF framework were
> written, the bus type selection was made implicit and only later on
> explicit. This is still reflected in how the bus type gets set between
> CSI-2 D-PHY, parallel and Bt.656.
>
 I'm a little bit confused, must I explicitly add as required property
 "bus-type=0" (autodetect) for both cases ? Or must I require
 "bus-type=1" for CSI and "bus-type=3" for parallel ?
>>>
>>> Yes, the confusion will stay for some time to come in some way. :-)
>>>
>>> What I wanted to say that the original decision to make this implicit
>>> from the bindings wasn't great --- we have here the device that does
>>> both parallel and CSI-2 D-PHY.
>>>
>>> But due to data-lanes, you can rely on implicit bus type selection
>>> working. So no bus-type is needed.
>>>
>>
>> OK, got it now:
>> - "bus-type=0" (autodetect) => V4L2_MBUS_PARALLEL or V4L2_MBUS_BT656 or
>> V4L2_MBUS_CSI2 depending on properties
>> - "bus-type=1" => MIPI CSI-2 C-PHY
>> - "bus-type=2" => MIPI CSI1
>> - "bus-type=3" => CCP2
>>
>> /**
>>* enum v4l2_mbus_type - media bus type
>>* @V4L2_MBUS_PARALLEL:parallel interface with hsync and vsync
>>* @V4L2_MBUS_BT656:   parallel interface with embedded 
>> synchronisation, can
>>* also be used for BT.1120
>>* @V4L2_MBUS_CSI1:MIPI CSI-1 serial interface
>>* @V4L2_MBUS_CCP2:CCP2 (Compact Camera Port 2)
>>* @V4L2_MBUS_CSI2:MIPI CSI-2 serial interface
>>*/
>> enum v4l2_mbus_type {
>>  V4L2_MBUS_PARALLEL,
>>  V4L2_MBUS_BT656,
>>  V4L2_MBUS_CSI1,
>>  V4L2_MBUS_CCP2,
>>  V4L2_MBUS_CSI2,
>> };
>>
>> This explain my confusion on CSI-2 CPHY and CCP2 below...
>>


 Talking bindings, I feel that it could be of great help to document also
 the polarity of control signals (hsync/vsync/pclk), they are currently
 set by ov5640 init sequence and not configurable.
 Moreover, should some checks be added in probe sequence to verify that
 the defined control signals polarity are aligned with default ones from
 init sequence ?
>>>
>>> Yes, that's a very good idea. It should have been there all along.
>>>


 Here is a proposal:

 "
 The device node must contain one 'port' child node for its digital
 output video port with a single 'endpoint' subnode, in accordance
 with the video interface bindings defined in
 Documentation/devicetree/bindings/media/video-interfaces.txt.

 OV5640 can be 

RE: [PATCH v2 2/4] dt-bindings: media: rcar_vin: add device tree support for r8a774[35]

2017-12-19 Thread Fabrizio Castro
Hello Mauro,

does this patch look ok to you?

Thanks,
Fab

> Subject: [PATCH v2 2/4] dt-bindings: media: rcar_vin: add device tree support 
> for r8a774[35]
>
> Add compatible strings for r8a7743 and r8a7745. No driver change
> is needed as "renesas,rcar-gen2-vin" will activate the right code.
> However, it is good practice to document compatible strings for the
> specific SoC as this allows SoC specific changes to the driver if
> needed, in addition to document SoC support and therefore allow
> checkpatch.pl to validate compatible string values.
>
> Signed-off-by: Fabrizio Castro 
> Reviewed-by: Biju Das 
> ---
> v1->v2:
> * Fixed double "change" in changelog
>
>  Documentation/devicetree/bindings/media/rcar_vin.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
> b/Documentation/devicetree/bindings/media/rcar_vin.txt
> index 98931f5..ff9697e 100644
> --- a/Documentation/devicetree/bindings/media/rcar_vin.txt
> +++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
> @@ -6,6 +6,8 @@ family of devices. The current blocks are always slaves and 
> suppot one input
>  channel which can be either RGB, YUYV or BT656.
>
>   - compatible: Must be one or more of the following
> +   - "renesas,vin-r8a7743" for the R8A7743 device
> +   - "renesas,vin-r8a7745" for the R8A7745 device
> - "renesas,vin-r8a7778" for the R8A7778 device
> - "renesas,vin-r8a7779" for the R8A7779 device
> - "renesas,vin-r8a7790" for the R8A7790 device
> @@ -14,7 +16,8 @@ channel which can be either RGB, YUYV or BT656.
> - "renesas,vin-r8a7793" for the R8A7793 device
> - "renesas,vin-r8a7794" for the R8A7794 device
> - "renesas,vin-r8a7795" for the R8A7795 device
> -   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 compatible device.
> +   - "renesas,rcar-gen2-vin" for a generic R-Car Gen2 or RZ/G1 compatible
> + device.
> - "renesas,rcar-gen3-vin" for a generic R-Car Gen3 compatible device.
>
> When compatible with the generic version nodes must list the
> --
> 2.7.4



[https://www2.renesas.eu/media/email/unicef_2017.jpg]

This Christmas, instead of sending out cards, Renesas Electronics Europe have 
decided to support Unicef with a donation. For further details click 
here to find out about the valuable work they do, 
helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a 
prosperous New Year.



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.


Re: [PATCH v3 3/5] media: dt-bindings: ov5640: add support of DVP parallel interface

2017-12-19 Thread Sakari Ailus
Hi Hugues,

On Mon, Dec 18, 2017 at 10:24:40AM +, Hugues FRUCHET wrote:
> Hi Sakari,
> 
> On 12/13/2017 08:47 PM, Sakari Ailus wrote:
> > Hi Hugues,
> > 
> > Hugues FRUCHET wrote:
> >> Hi Sakari,
> >>
> >> On 12/07/2017 02:59 PM, Sakari Ailus wrote:
> >>> Hi Hugues,
> >>>
> >>> On Thu, Dec 07, 2017 at 01:40:51PM +0100, Hugues Fruchet wrote:
>  Add bindings for OV5640 DVP parallel interface support.
> 
>  Signed-off-by: Hugues Fruchet 
>  ---
> .../devicetree/bindings/media/i2c/ov5640.txt   | 27 
>  --
> 1 file changed, 25 insertions(+), 2 deletions(-)
> 
>  diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt 
>  b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
>  index 540b36c..04e2a91 100644
>  --- a/Documentation/devicetree/bindings/media/i2c/ov5640.txt
>  +++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
>  @@ -1,4 +1,4 @@
>  -* Omnivision OV5640 MIPI CSI-2 sensor
>  +* Omnivision OV5640 MIPI CSI-2 / parallel sensor
> 
> Required Properties:
> - compatible: should be "ovti,ov5640"
>  @@ -18,7 +18,11 @@ The device node must contain one 'port' child node 
>  for its digital output
> video port, in accordance with the video interface bindings defined in
> Documentation/devicetree/bindings/media/video-interfaces.txt.
> 
>  -Example:
>  +Parallel or CSI mode is selected according to optional endpoint 
>  properties.
>  +Without properties (or bus properties), parallel mode is selected.
>  +Specifying any CSI properties such as lanes will enable CSI mode.
> >>>
> >>> These bindings never documented what which endpoint properties were 
> >>> needed.
> >>
> >> Ok I will add a section related to endpoint properties for both CSI and
> >> parallel.
> >>
> >>>
> >>> Beyond that, the sensor supports two CSI-2 lanes. You should explicitly
> >>> specify that, in other words, you'll need "data-lanes" property. Could you
> >>> add that?
> >> Ok I will add it to required endpoint property in case of CSI mode.
> >> I will change commit header to reflect changes on parallel but also CSI
> >> documentation.
> >>
> >>>
> >>> Long time ago when the video-interfaces.txt and the V4L2 OF framework were
> >>> written, the bus type selection was made implicit and only later on
> >>> explicit. This is still reflected in how the bus type gets set between
> >>> CSI-2 D-PHY, parallel and Bt.656.
> >>>
> >> I'm a little bit confused, must I explicitly add as required property
> >> "bus-type=0" (autodetect) for both cases ? Or must I require
> >> "bus-type=1" for CSI and "bus-type=3" for parallel ?
> > 
> > Yes, the confusion will stay for some time to come in some way. :-)
> > 
> > What I wanted to say that the original decision to make this implicit
> > from the bindings wasn't great --- we have here the device that does
> > both parallel and CSI-2 D-PHY.
> > 
> > But due to data-lanes, you can rely on implicit bus type selection
> > working. So no bus-type is needed.
> > 
> 
> OK, got it now:
> - "bus-type=0" (autodetect) => V4L2_MBUS_PARALLEL or V4L2_MBUS_BT656 or 
> V4L2_MBUS_CSI2 depending on properties
> - "bus-type=1" => MIPI CSI-2 C-PHY
> - "bus-type=2" => MIPI CSI1
> - "bus-type=3" => CCP2
> 
> /**
>   * enum v4l2_mbus_type - media bus type
>   * @V4L2_MBUS_PARALLEL:  parallel interface with hsync and vsync
>   * @V4L2_MBUS_BT656: parallel interface with embedded synchronisation, can
>   *   also be used for BT.1120
>   * @V4L2_MBUS_CSI1:  MIPI CSI-1 serial interface
>   * @V4L2_MBUS_CCP2:  CCP2 (Compact Camera Port 2)
>   * @V4L2_MBUS_CSI2:  MIPI CSI-2 serial interface
>   */
> enum v4l2_mbus_type {
>   V4L2_MBUS_PARALLEL,
>   V4L2_MBUS_BT656,
>   V4L2_MBUS_CSI1,
>   V4L2_MBUS_CCP2,
>   V4L2_MBUS_CSI2,
> };
> 
> This explain my confusion on CSI-2 CPHY and CCP2 below...
> 
> >>
> >>
> >> Talking bindings, I feel that it could be of great help to document also
> >> the polarity of control signals (hsync/vsync/pclk), they are currently
> >> set by ov5640 init sequence and not configurable.
> >> Moreover, should some checks be added in probe sequence to verify that
> >> the defined control signals polarity are aligned with default ones from
> >> init sequence ?
> > 
> > Yes, that's a very good idea. It should have been there all along.
> > 
> >>
> >>
> >> Here is a proposal:
> >>
> >> "
> >> The device node must contain one 'port' child node for its digital
> >> output video port with a single 'endpoint' subnode, in accordance
> >> with the video interface bindings defined in
> >> Documentation/devicetree/bindings/media/video-interfaces.txt.
> >>
> >> OV5640 can be connected to a MIPI CSI bus or a parallel bus endpoint:
> > 
> > CSI-2, please.
> > 
> OK
> 
> >>
> >> Endpoint node required properties for CSI connection are:
> >> - remote-endpoint: a phandle to 

Re: [PATCH 1/2] bdisp: Fix a possible sleep-in-atomic bug in bdisp_hw_reset

2017-12-19 Thread Mauro Carvalho Chehab
Em Tue, 19 Dec 2017 09:01:41 +
Fabien DESSENNE  escreveu:

> On 16/12/17 15:14, Mauro Carvalho Chehab wrote:
> > Em Sat, 16 Dec 2017 19:53:55 +0800
> > Jia-Ju Bai  escreveu:
> >  
> >> Hi,
> >>
> >> On 2017/12/15 22:51, Fabien DESSENNE wrote:  
> >>> Hi
> >>>
> >>> On 12/12/17 14:47, Jia-Ju Bai wrote:  
>  The driver may sleep under a spinlock.
>  The function call path is:
>  bdisp_device_run (acquire the spinlock)
>   bdisp_hw_reset
> msleep --> may sleep
> 
>  To fix it, msleep is replaced with mdelay.  
> >>> May I suggest you to use readl_poll_timeout_atomic (instead of the whole
> >>> "for" block): this fixes the problem and simplifies the code?  
> >> Okay, I have submitted a patch according to your advice.
> >> You can have a look :)  
> > This can still be usind mdelay() to wait for a long time.
> >
> > It doesn't seem wise to do that, as it could cause system
> > contention. Couldn't this be reworked in a way to avoid
> > having the spin locked while sleeping?
> >
> > Once we had a similar issue on Siano, and it was solved by this
> >
> > commit 3cdadc50bbe8f04c1231c8af614cafd7ddd622bf
> > Author: Richard Zidlicky 
> > Date:   Tue Aug 24 09:52:36 2010 -0300
> >
> >  V4L/DVB: dvb: fix smscore_getbuffer() logic
> >  
> >  Drivers shouldn't sleep while holding a spinlock. A previous workaround
> >  were to release the spinlock before callinc schedule().
> >  
> >  This patch uses a different approach: it just waits for the
> >  siano hardware to answer.
> >  
> >  Signed-off-by: Richard Zidlicky 
> >  Cc: sta...@kernel.org
> >  Signed-off-by: Mauro Carvalho Chehab 
> >
> > The code as changed to use wait_event() at the kthread that was
> > waiting for data to arrive. Only when the data is ready, the
> > code with the spin lock is called.
> >
> > It made the driver a way more stable, and didn't add any penalties
> > of needing to do long delays on a non-interruptible code.
> >
> > Thanks,
> > Mauro  
> I have checked what was done there but I cannot see a simple way to do 
> the same in bdisp where the context is a bit different (the lock is 
> taken out in the central device_run, not locally in hw_reset) without 
> taking the risk to have unexpected side effects
> 
> Moreover, the bdisp_hw_reset() function called from bdisp_device_run is 
> not expected to last for a long time. The "one second" delay we are 
> talking about is a very large timeout protection. From my past 
> observations, the reset is applied instantly and we even never reach the 
> msleep() call (not saying it never happens).
> 
> For those two reasons, using readl_poll_timeout_atomic() seems to be the 
> best option.

OK. The best is then to document it at the source code, for others
to be aware, while reviewing the code, that, despite the large timeout, 
most of the time the reset happens without needing any delays.

Thanks,
Mauro


Re: [PATCH 5/8] media: v4l2-mediabus: convert flags to enums and document them

2017-12-19 Thread Philipp Zabel
Hi Mauro,

On Mon, 2017-12-18 at 17:53 -0200, Mauro Carvalho Chehab wrote:
> There is a mess with media bus flags: there are two sets of
> flags, one used by parallel and ITU-R BT.656 outputs,
> and another one for CSI2.
> 
> Depending on the type, the same bit has different meanings.
> 
> That's very confusing, and counter-intuitive. So, split them
> into two sets of flags, inside an enum.
> 
> This way, it becomes clearer that there are two separate sets
> of flags. It also makes easier if CSI1, CSP, CSI3, etc. would
> need a different set of flags.
> 
> As a side effect, enums can be documented via kernel-docs,
> so there will be an improvement at flags documentation.
> 
> Unfortunately, soc_camera and pxa_camera do a mess with
> the flags, using either one set of flags without proper
> checks about the type. That could be fixed, but, as both drivers
> are obsolete and in the process of cleanings, I opted to just
> keep the behavior, using an unsigned int inside those two
> drivers.
> 
> Acked-by: Hans Verkuil 
> Signed-off-by: Mauro Carvalho Chehab 

If I am not mistaken this is missing a conversion of
drivers/staging/media/imx/imx-media-csi.c:

8<
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index eb7be5093a9d5..b1daac3a537d9 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -636,9 +636,10 @@ static int csi_setup(struct csi_priv *priv)
 
    /* compose mbus_config from the upstream endpoint */
    mbus_cfg.type = priv->upstream_ep.bus_type;
-   mbus_cfg.flags = (priv->upstream_ep.bus_type == V4L2_MBUS_CSI2) ?
-   priv->upstream_ep.bus.mipi_csi2.flags :
-   priv->upstream_ep.bus.parallel.flags;
+   if (priv->upstream_ep.bus_type == V4L2_MBUS_CSI2)
+   mbus_cfg.csi2_flags = priv->upstream_ep.bus.mipi_csi2.flags;
+   else
+   mbus_cfg.pb_flags = priv->upstream_ep.bus.parallel.flags;
 
/*
 * we need to pass input frame to CSI interface, but
>8

regards
Philipp

> ---
>  drivers/media/i2c/adv7180.c|  10 +-
>  drivers/media/i2c/ml86v7667.c  |   5 +-
>  drivers/media/i2c/mt9m111.c|   8 +-
>  drivers/media/i2c/ov6650.c |  19 +--
>  drivers/media/i2c/soc_camera/imx074.c  |   6 +-
>  drivers/media/i2c/soc_camera/mt9m001.c |  10 +-
>  drivers/media/i2c/soc_camera/mt9t031.c |  11 +-
>  drivers/media/i2c/soc_camera/mt9t112.c |  11 +-
>  drivers/media/i2c/soc_camera/mt9v022.c |  16 ++-
>  drivers/media/i2c/soc_camera/ov5642.c  |   5 +-
>  drivers/media/i2c/soc_camera/ov772x.c  |  10 +-
>  drivers/media/i2c/soc_camera/ov9640.c  |  10 +-
>  drivers/media/i2c/soc_camera/ov9740.c  |  10 +-
>  drivers/media/i2c/soc_camera/rj54n1cb0c.c  |  12 +-
>  drivers/media/i2c/soc_camera/tw9910.c  |  13 +-
>  drivers/media/i2c/tc358743.c   |  10 +-
>  drivers/media/i2c/tvp5150.c|   6 +-
>  drivers/media/platform/pxa_camera.c|   8 +-
>  drivers/media/platform/rcar-vin/rcar-core.c|   4 +-
>  drivers/media/platform/rcar-vin/rcar-dma.c |   4 +-
>  .../platform/soc_camera/sh_mobile_ceu_camera.c |   2 +-
>  drivers/media/platform/soc_camera/soc_camera.c |   3 +-
>  .../platform/soc_camera/soc_camera_platform.c  |   2 +-
>  drivers/media/platform/soc_camera/soc_mediabus.c   |   2 +-
>  drivers/media/v4l2-core/v4l2-fwnode.c  |   5 +-
>  include/media/v4l2-fwnode.h|   4 +-
>  include/media/v4l2-mediabus.h  | 145 
> ++---
>  27 files changed, 218 insertions(+), 133 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
> index 25d24a3f10a7..4bf25a72ef4f 100644
> --- a/drivers/media/i2c/adv7180.c
> +++ b/drivers/media/i2c/adv7180.c
> @@ -743,16 +743,16 @@ static int adv7180_g_mbus_config(struct v4l2_subdev *sd,
>  
>   if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
>   cfg->type = V4L2_MBUS_CSI2;
> - cfg->flags = V4L2_MBUS_CSI2_1_LANE |
> - V4L2_MBUS_CSI2_CHANNEL_0 |
> - V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
> + cfg->csi2_flags = V4L2_MBUS_CSI2_1_LANE
> +   | V4L2_MBUS_CSI2_CHANNEL_0
> +   | V4L2_MBUS_CSI2_CONTINUOUS_CLOCK;
>   } else {
>   /*
>* The ADV7180 sensor supports BT.601/656 output modes.
>* The BT.656 is default and not yet configurable by s/w.
>*/
> - cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING |
> - 

Re: [PATCH v9 2/2] media: i2c: Add the ov7740 image sensor driver

2017-12-19 Thread Sakari Ailus
On Mon, Dec 11, 2017 at 09:31:46AM +0800, Wenyou Yang wrote:
> The ov7740 (color) image sensor is a high performance VGA CMOS
> image snesor, which supports for output formats: RAW RGB and YUV
> and image sizes: VGA, and QVGA, CIF and any size smaller.
> 
> Signed-off-by: Songjun Wu 
> Signed-off-by: Wenyou Yang 

Applied with this diff:

diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
index 0308ba437bbb..041a77039d70 100644
--- a/drivers/media/i2c/ov7740.c
+++ b/drivers/media/i2c/ov7740.c
@@ -1,5 +1,7 @@
-// SPDX-License-Identifier: GPL-2.0
-// Copyright (c) 2017 Microchip Corporation.
+/*
+ * SPDX-License-Identifier: GPL-2.0
+ * Copyright (c) 2017 Microchip Corporation.
+ */
 
 #include 
 #include 

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


Re: [PATCH 3/8] media: v4l2-async: simplify v4l2_async_subdev structure

2017-12-19 Thread Philipp Zabel
On Mon, 2017-12-18 at 17:53 -0200, Mauro Carvalho Chehab wrote:
> The V4L2_ASYNC_MATCH_FWNODE match criteria requires just one
> struct to be filled (struct fwnode_handle). The V4L2_ASYNC_MATCH_DEVNAME
> match criteria requires just a device name.
> 
> So, it doesn't make sense to enclose those into structs,
> as the criteria can go directly into the union.
> 
> That makes easier to document it, as we don't need to document
> weird senseless structs.
> 
> At drivers, this makes even clearer about the match criteria.
> 
> Acked-by: Sylwester Nawrocki 
> Signed-off-by: Mauro Carvalho Chehab 

Thanks, this does improve readability in the drivers. For imx-media,

Acked-by: Philipp Zabel 

regards
Philipp

> ---
>  drivers/media/platform/am437x/am437x-vpfe.c|  6 +++---
>  drivers/media/platform/atmel/atmel-isc.c   |  2 +-
>  drivers/media/platform/atmel/atmel-isi.c   |  2 +-
>  drivers/media/platform/davinci/vpif_capture.c  |  4 ++--
>  drivers/media/platform/exynos4-is/media-dev.c  |  4 ++--
>  drivers/media/platform/pxa_camera.c|  2 +-
>  drivers/media/platform/qcom/camss-8x16/camss.c |  2 +-
>  drivers/media/platform/rcar-vin/rcar-core.c|  2 +-
>  drivers/media/platform/rcar_drif.c |  4 ++--
>  drivers/media/platform/soc_camera/soc_camera.c |  2 +-
>  drivers/media/platform/stm32/stm32-dcmi.c  |  2 +-
>  drivers/media/platform/ti-vpe/cal.c|  2 +-
>  drivers/media/platform/xilinx/xilinx-vipp.c|  2 +-
>  drivers/media/v4l2-core/v4l2-async.c   | 16 
>  drivers/media/v4l2-core/v4l2-fwnode.c  | 10 +-
>  drivers/staging/media/imx/imx-media-dev.c  |  4 ++--
>  include/media/v4l2-async.h |  8 ++--
>  17 files changed, 35 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/media/platform/am437x/am437x-vpfe.c 
> b/drivers/media/platform/am437x/am437x-vpfe.c
> index 0997c640191d..601ae6487617 100644
> --- a/drivers/media/platform/am437x/am437x-vpfe.c
> +++ b/drivers/media/platform/am437x/am437x-vpfe.c
> @@ -2304,8 +2304,8 @@ vpfe_async_bound(struct v4l2_async_notifier *notifier,
>   vpfe_dbg(1, vpfe, "vpfe_async_bound\n");
>  
>   for (i = 0; i < ARRAY_SIZE(vpfe->cfg->asd); i++) {
> - if (vpfe->cfg->asd[i]->match.fwnode.fwnode ==
> - asd[i].match.fwnode.fwnode) {
> + if (vpfe->cfg->asd[i]->match.fwnode ==
> + asd[i].match.fwnode) {
>   sdinfo = >cfg->sub_devs[i];
>   vpfe->sd[i] = subdev;
>   vpfe->sd[i]->grp_id = sdinfo->grp_id;
> @@ -2510,7 +2510,7 @@ vpfe_get_pdata(struct platform_device *pdev)
>   }
>  
>   pdata->asd[i]->match_type = V4L2_ASYNC_MATCH_FWNODE;
> - pdata->asd[i]->match.fwnode.fwnode = of_fwnode_handle(rem);
> + pdata->asd[i]->match.fwnode = of_fwnode_handle(rem);
>   of_node_put(rem);
>   }
>  
> diff --git a/drivers/media/platform/atmel/atmel-isc.c 
> b/drivers/media/platform/atmel/atmel-isc.c
> index 0c2635647f69..34676409ca08 100644
> --- a/drivers/media/platform/atmel/atmel-isc.c
> +++ b/drivers/media/platform/atmel/atmel-isc.c
> @@ -2088,7 +2088,7 @@ static int isc_parse_dt(struct device *dev, struct 
> isc_device *isc)
>   subdev_entity->pfe_cfg0 |= ISC_PFE_CFG0_PPOL_LOW;
>  
>   subdev_entity->asd->match_type = V4L2_ASYNC_MATCH_FWNODE;
> - subdev_entity->asd->match.fwnode.fwnode =
> + subdev_entity->asd->match.fwnode =
>   of_fwnode_handle(rem);
>   list_add_tail(_entity->list, >subdev_entities);
>   }
> diff --git a/drivers/media/platform/atmel/atmel-isi.c 
> b/drivers/media/platform/atmel/atmel-isi.c
> index e900995143a3..9958918e2449 100644
> --- a/drivers/media/platform/atmel/atmel-isi.c
> +++ b/drivers/media/platform/atmel/atmel-isi.c
> @@ -1128,7 +1128,7 @@ static int isi_graph_parse(struct atmel_isi *isi, 
> struct device_node *node)
>   /* Remote node to connect */
>   isi->entity.node = remote;
>   isi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
> - isi->entity.asd.match.fwnode.fwnode = of_fwnode_handle(remote);
> + isi->entity.asd.match.fwnode = of_fwnode_handle(remote);
>   return 0;
>   }
>  }
> diff --git a/drivers/media/platform/davinci/vpif_capture.c 
> b/drivers/media/platform/davinci/vpif_capture.c
> index e45916f69def..e1c273c8b9a6 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -1390,7 +1390,7 @@ static int vpif_async_bound(struct v4l2_async_notifier 
> *notifier,
>  
>   for (i = 0; i < vpif_obj.config->asd_sizes[0]; i++) {
>   struct v4l2_async_subdev *_asd = vpif_obj.config->asd[i];
> - const struct fwnode_handle 

  1   2   >