The prediction weight parameters are only required under
certain conditions, which depend on slice header parameters.

As specified in section 7.3.3 Slice header syntax, the prediction
weight table is present if:

((weighted_pred_flag && (slice_type == P || slice_type == SP)) || \
(weighted_bipred_idc == 1 && slice_type == B))

Given its size, it makes sense to move this table to its control,
so applications can avoid passing it if the slice doesn't specify it.

Before this change struct v4l2_ctrl_h264_slice_params was 960 bytes.
With this change, it's 188 bytes and struct v4l2_ctrl_h264_pred_weight
is 772 bytes.
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Tested-by: NJonas Karlman <jonas@kwiboo.se>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Commit 0b0393d5 ("media: uapi: h264: clarify
expected scaling_list_4x4/8x8 order") improved the
documentation on H264 scaling lists order.

This commit improves the documentation by clarifying
that the lists themselves are expected in raster scan order.
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Tested-by: NJonas Karlman <jonas@kwiboo.se>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

When dealing with interlaced frames, reference lists must tell if
each particular reference is meant for top or bottom field. This info
is currently not provided at all in the H264 related controls.

Change reference lists to hold a structure, which specifies
an index into the DPB array and the field/frame specification
for the picture.

Currently the only user of these lists is Cedrus which is just compile
fixed here. Actual usage of will come in a following commit.
Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Tested-by: NJonas Karlman <jonas@kwiboo.se>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

The unit of exposure value is different from other OmniVision sensors,
driver will divide by 2 before set register, the exposure range exposed
by v4l2 ctrl to user should be same as others, so the calculation for
the maximum exposure value in current driver need be fixed.
Signed-off-by: NBingbu Cao <bingbu.cao@intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

While we have had some example drivers, there has been up to date no
formal documentation on how camera sensor drivers should be written; what
are the practices, why, and where they apply.
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Make use of SCCB APIs for regmap operations.
Remove i2c_check_functionality as devm_regmap_init_sccb
does it for us.
Signed-off-by: NRaag Jadav <raagjadav@gmail.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

1) the numerator and/or denominator might be 0, in that case
   fall back to the default frame interval. This is per the spec
   and this caused a v4l2-compliance failure.

2) the updated frame interval wasn't returned in the s_frame_interval
   subdev op.
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: NLuca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

clang static analysis reports this error

m5mols_core.c:767:4: warning: Called function pointer
  is null (null dereference) [core.CallAndMessage]
    info->set_power(&client->dev, 0);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In other places, the set_power ptr is checked.
So add a check.

Fixes: bc125106 ("[media] Add support for M-5MOLS 8 Mega Pixel camera ISP")
Signed-off-by: NTom Rix <trix@redhat.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Currently the error return from the call to max9286_read is masked
with 0xf0 so the following check for a negative error return is
never true.  Fix this by checking for an error first, then masking
the return value for subsequent conflink_mask checking.

Addresses-Coverity: ("Logically dead code")

Fixes: 66d8c9d2 ("media: i2c: Add MAX9286 driver")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NKieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.
Signed-off-by: NAlexander A. Klimov <grandmaster@al2klimov.de>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Although the code is correct and doing the right thing, the clock diagram
showed the wrong register for the bit divider, which had me doubting the
understanding of the tree. Fix this to avoid doubts in the future.
Signed-off-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com>
Fixes: aa288248 ("media: ov5640: Adjust the clock based on the expected rate")
Acked-by: NJacopo Mondi <jacopo@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Fix improper line breaks and format all example yavta and media-ctl
commands as code blocks to improve readability.
Signed-off-by: NJordan Hand <jorhand@linux.microsoft.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Since the current maintainer email address bounces back, replace
the entry and make myself and Dave Stevenson maintainers of the driver.
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Acked-by: NDave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Document the optional clock-noncontinuous endpoint property that
allows enabling MIPI CSI-2 non-continuous clock operations.
Signed-off-by: NJacopo Mondi <jacopo@jmondi.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Document in dt-schema bindings for the ov5647 sensor the optional
'pwdn-gpios' property.
Signed-off-by: NJacopo Mondi <jacopo@jmondi.org>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Convert the ov5647 image sensor bindings to DT schema and add
the file entry to MAINTAINERS.
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NJacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

This fixes a multiline comment style warning as found by checkpatch.pl.
Signed-off-by: NRahul Gottipati <rahul.blr97@gmail.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Fix the typo in email address of Tianshu Qiu and correct the name.
Reported-by: NBjorn Helgaas <helgaas@kernel.org>
Signed-off-by: NTianshu Qiu <tian.shu.qiu@intel.com>
Signed-off-by: NBingbu Cao <bingbu.cao@intel.com>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

The OTP data was not ready after registered as nvmem device, it is
risky as the nvmem read may happen once the device exists, this patch
get the OTP data ready before registering the nvmem device. OTP data
missing should not break the normal camera sensor probe, so use a
warning instead of an error message.
Signed-off-by: NBingbu Cao <bingbu.cao@intel.com>
Signed-off-by: NQingwu Zhang <qingwu.zhang@intel.com>
Suggested-by: NSergey Senozhatsky <senozhatsky@chromium.org>
Reviewed-by: NSergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: NSakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

When calling debugfs functions, there is no need to ever check the
return value.  The function can work or not, but the code logic should
never do something different based on this.
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

The parallel port nodes should be numbered 1 and 2, not 0 and 1
for A and B respectively.  The driver has always implemented 1
and 2 and the in-tree Goni DTS uses 1 as port A as well.  Update
the documentation to match this behaviour.
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

vidioc_streamoff can be called multiple times from userspace, but we
should only call media_pipeline_stop when we're actually setup.

This became more noticeable after commit 2a2599c6 ("[media] media:
entity: Catch unbalanced media_pipeline_stop calls") was merged as it
added a WARN for unbalanced calls to media_pipeline_stop.
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

This is no longer used since the conversion to DT
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

This is a no-op as it is never set and is a remnant from non-DT days
that can be safely removed.
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

On some devices, there may be multiple camera sensors attached
to the same port.  Make sure we probe all of them, not just the
first one.
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Instead of keeping a local copy of how many sensors we've probed
(which may not even properly represent the number of sensors
probed if we have a port without a sensor), use the global
num_sensors counter that has the actual number used.

This will also make it easier to add support for multiple sensors
being connected to the same port.
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Commit ee7160e5 ("[media] s5p-fimc: Add support for JPEG capture")
added support for JPEG capture, but missed setting a register when the
parallel port was used rather than the CSIS device.
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Commit bae45003 ("[media] exynos4-is: Add missing entity function
initialization") tried to suppress the warnings such as

s5p-fimc-md camera: Entity type for entity FIMC.0 was not initialized!

However, this missed setting for the subdev.  Set it now to avoid the
ugly warnings on boot.
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

Not all devices use the CSIS device, some may use the FIMC directly in
which case the CSIS device isn't registered.  This leads to a nullptr
exception when starting the stream as the CSIS device is always
referenced.  Instead, if getting the CSIS device fails, try getting the
FIMC directly to check if we are using the subdev API
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

On FIMC variants which don't have writeback channel, there is no need to
access system registers. This patch makes the driver request sysreg
regmap conditionally depending on whether writeback is supported.
Signed-off-by: NTomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

The S5PV210 platform only supports device tree based booting
where the FIMC variant data is parsed directly from
the device tree, hence the now unused static data can be removed.
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Reviewed-by: NSylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

When the post-processor is enabled, the driver allocates
"shadow buffers" which are used for the decoder core,
and exposes the post-processed buffers to userspace.

For this reason, extra motion vector space has to
be allocated on the shadow buffers, which the driver
wasn't doing. Fix it.

This fix should address artifacts on high profile bitstreams.

Fixes: 8c2d66b0 ("media: hantro: Support color conversion via post-processing")
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

If the bitstream and the application are incorrectly configuring
the reference pictures, the hardware will need to fallback
to using some other reference picture.

When the post-processor is enabled, the fallback buffer
should be a shadow buffer (postproc.dec_q), and not a
CAPTURE queue buffer, since the latter is post-processed
and not really the output of the decoder core.

Fixes: 8c2d66b0 ("media: hantro: Support color conversion via post-processing")
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

list_for_each_entry is able to handle an empty list.
The only effect of avoiding the loop is not initializing the
index variable.
Drop list_empty tests in cases where these variables are not
used.

Note that list_for_each_entry is defined in terms of list_first_entry,
which indicates that it should not be used on an empty list.  But in
list_for_each_entry, the element obtained by list_first_entry is not
really accessed, only the address of its list_head field is compared
to the address of the list head, so the list_first_entry is safe.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

<smpl>
@@
expression x,e;
iterator name list_for_each_entry;
statement S;
identifier i;
@@

-if (!(list_empty(x))) {
   list_for_each_entry(i,x,...) S
- }
 ... when != i
? i = e
</smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>

list_for_each_safe is able to handle an empty list.
The only effect of avoiding the loop is not initializing the
index variable.
Drop list_empty tests in cases where these variables are not
used.

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

<smpl>
@@
expression x,e;
iterator name list_for_each_safe;
statement S;
identifier i,j;
@@

-if (!(list_empty(x))) {
   list_for_each_safe(i,j,x) S
- }
 ... when != i
     when != j
(
  i = e;
|
? j = e;
)
</smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>