Commit Graph

12 Commits

Author SHA1 Message Date
Ezequiel Garcia
016baa59bf media: Kconfig: Don't expose the Request API option
The Request API isn't meant to be chosen by users,
but instead should be selected by drivers that want
to support it.

Hantro and Cedrus are already selecting the right options,
so only the test drivers need to be fixed.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-16 10:36:11 +02:00
Guillaume Tucker
ffb2e0082c media: Kconfig: include test_drivers with MEDIA_TEST_SUPPORT
Include test_drivers/Kconfig when MEDIA_TEST_SUPPORT is enabled rather
than MEDIA_PLATFORM_SUPPORT.  Test drivers should not depend on
platform drivers to be enabled.

Reported-by: "kernelci.org bot" <bot@kernelci.org>
Fixes: 4b32216adb ("media: split test drivers from platform directory")
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-15 15:46:10 +02:00
Mauro Carvalho Chehab
e671ed99f8 media: vimc: fix kernel-doc markups
There are several markups there that doesn't follow the
specs. Fields should be like:

	@foo:

with a collon at the end. Also, continuation lines should
be aligned.

Failing to do that would cause kernel-doc to parse it wrong.
Some of the troubles will even cause warnings:

	$ ./scripts/kernel-doc -none drivers/media/test_drivers/vimc/vimc-common.h
	drivers/media/test_drivers/vimc/vimc-common.h:59: error: Cannot parse struct or union!
	drivers/media/test_drivers/vimc/vimc-common.h:77: warning: Function parameter or member 'bpp' not described in 'vimc_pix_map'
	drivers/media/test_drivers/vimc/vimc-common.h:120: warning: Function parameter or member 'pipe_cfg' not described in 'vimc_device'
	drivers/media/test_drivers/vimc/vimc-common.h:120: warning: Function parameter or member 'ent_devs' not described in 'vimc_device'
	drivers/media/test_drivers/vimc/vimc-common.h:120: warning: Function parameter or member 'mdev' not described in 'vimc_device'
	drivers/media/test_drivers/vimc/vimc-common.h:120: warning: Function parameter or member 'v4l2_dev' not described in 'vimc_device'
	drivers/media/test_drivers/vimc/vimc-common.h:137: warning: Function parameter or member 'add' not described in 'vimc_ent_type'
	drivers/media/test_drivers/vimc/vimc-common.h:137: warning: Function parameter or member 'unregister' not described in 'vimc_ent_type'
	drivers/media/test_drivers/vimc/vimc-common.h:137: warning: Function parameter or member 'release' not described in 'vimc_ent_type'
	drivers/media/test_drivers/vimc/vimc-common.h:150: warning: Function parameter or member 'name' not described in 'vimc_ent_config'
	drivers/media/test_drivers/vimc/vimc-common.h:150: warning: Function parameter or member 'type' not described in 'vimc_ent_config'
	drivers/media/test_drivers/vimc/vimc-common.h:197: warning: bad line:                 flags of the pads

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14 12:14:43 +02:00
Ezequiel Garcia
9d3bf4cd9f media: vim2m: Remove unneeded buffer lock
This spinlock is used solely to call v4l2_m2m_buf_done().

Since buffers are obtained only after being removed
from the ready queue, there's no concurrent access, and
so no need for synchronization.

Remove the spinlock to make sure no one copies this pattern.

Some archaeology shows this is a small leftover from ancient code.
This driver (then called m2m_testdev) used the videobuf1 framework;
commit d80ee38cd8 ("[media] v4l: mem2mem: port m2m_testdev to vb2")
converted it to videobuf2. The spinlock was then no longer needed,
and this simply went unnoticed.

Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14 12:06:23 +02:00
Dafna Hirschfeld
e472d6a259 media: vimc: add vimc_ent_type struct for the callbacks of entities
Since each vimc entity type is defined by the
callbacks implementation, it is a good idea to
add a struct to hold these callbacks.

Each vimc entity then declare its type in the file for
the entity.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14 12:05:30 +02:00
Dafna Hirschfeld
5aa0d0964b media: vimc: fix issues in documentation in vimc-common.h
There are some missing and extra fields and typos in
structs documentations in vimc-common.h. Fix it.

[mchehab+huawei@kernel.org: add a missing ':' after @bayer field]
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14 12:04:41 +02:00
Dafna Hirschfeld
967534cb49 media: vimc: keep the error value when adding an entity fails
Currently when the 'add' callback of an entity fails, a
NULL is returned. This hides the error code of the failure
and always returns -EINVAL.

Replace return NULL with return ERR_PTR(ret) to improve debugging.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14 12:02:46 +02:00
Dafna Hirschfeld
7a040cf303 media: vimc: handle error in vimc_add_subdevs
In case the 'add' callback of an entity fails,
then all other entities should unregister and released.
This should be done inside vimc_add_subdevs so that
the function handles its own failure.

In order to call vimc_unregister_subdevs and vimc_release_subdevs from
vimc_add_subdevs, the order of the function should change.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14 12:01:43 +02:00
Dafna Hirschfeld
4ce4646c23 media: vimc: remove the function vimc_unregister
The function vimc_unregister is called only from
one place in the code and has only 3 lines so it
has no justification.

Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14 12:01:04 +02:00
Mauro Carvalho Chehab
32a363d0b0 media: Kconfig files: use select for V4L2 subdevs and MC
There are lots of drivers that only work when the media controller
and/or the V4L2 subdev APIs are present.

Right now, someone need to first enable those APIs before
using those drivers.

Well, ideally, drivers, should, instead *optionally*
depend on it, in order for PC camera drivers to be able to use
them, but nowadays most drivers are UVC cameras, with don't
require a sensor driver.

So, be it.

Let's instead make them select the MEDIA_CONTROLLER and the
SUBDEV API, in order to make easier for people to be able
of enabling them.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14 10:29:05 +02:00
Mauro Carvalho Chehab
6268b35139 media: Kconfig: fix selection for test drivers
There are some long-time mistakes related to build test
drivers, with regards to depends on/select. Also, as we
now want to build any test driver without needing to
enable anything else, change the logic in order to properly
filter them.

Please notice that the PCI skeleton is somewhat an
exception, as it requires to select *both* SAMPLES and
MEDIA_TEST_SUPPORT. I almost changed it to be either one,
but decided to keep it as-is, as this is something that
we don't really need to be included on any distribution.

The only reason for someone to build it is for COMPILE_TEST
purposes.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14 10:29:05 +02:00
Mauro Carvalho Chehab
4b32216adb media: split test drivers from platform directory
When the first test device was added (vivi.c), there were just
one file. I was too lazy on that time to create a separate
directory just for it, so I kept it together with platform.

Now, we have vivid, vicodec, vim2m and vimc. Also, a new
virtual driver has been prepared to support DVB API.

So, it is time to solve this mess, by placing test stuff
on a separate directory.

It should be noticed that we also have some skeleton drivers
(for V4L and for DVB). For now, we'll keep them separate,
as they're not really test drivers, but instead, just
examples. The DVB frontend ones will likely be part of a new DVB
test driver. By that time, it should make sense to move them
here as well.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-04-14 10:29:04 +02:00