The function ub960_rxport_read is being called and afterwards ret is
being checked for any failures, however ret is not being assigned to
the return of the function call. Fix this by assigning ret to the
return of the call which appears to be missing.
Fixes: afe267f2d3 ("media: i2c: add DS90UB960 driver")
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Move request_irq() to probe(), in order to avoid requesting IRQ during
device start which happens frequently. As this function is in probe(), it
is better to replace it with its devm variant for managing the resource
efficiently.
While at it, drop the IRQF_SHARED flag as currently there is a single user
for this IRQ.
Suggested-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
If cci_read() fails, 'st' is set to 0 in cci_read(), so we return success,
instead of the expected error code.
Fix it and return the expected error.
Fixes: 9a6d7f2ba2 ("media: i2c: st-vgxy61: Convert to CCI register access helpers")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add support for Raspberry Pi CFE. The CFE is a hardware block that
contains:
- MIPI D-PHY
- MIPI CSI-2 receiver
- Front End ISP (FE)
The driver has been upported from the Raspberry Pi kernel commit
88a681df9623 ("ARM: dts: bcm2712-rpi: Add i2c<n>_pins labels").
Co-developed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add two meta formats for PiSP FE: V4L2_META_FMT_RPI_FE_CFG and
V4L2_META_FMT_RPI_FE_STATS. The former is used to provide configuration
for the FE and the latter is used to read the statistics from the FE.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Some R-Car SoCs are capable of capturing RAW10. Extend the format
enumeration, validation and setup to expose and configure for this
format if the particular device supports it.
The VIN is usually capable of converting from most media bus formats to
a range of different pixel formats. However if the input media bus
format is a RAW10 format this is not possible so the corresponding pixel
output format is forced.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The ISP Channel Selector IP is the same for all current Gen4 devices.
This was not known when adding support for V3U and V4H and a single SoC
specific compatible was used.
Before adding more SoC specific bindings for V4M add a family compatible
fallback for Gen4. That way the driver only needs to be updated once for
Gen4, and we still have the option to fix any problems in the driver if
any testable differences between the SoCs are found.
There are already DTS files using the V3U and V4H compatibles which
needs to be updated to not produce a warning for DTS checks. The driver
also needs to kept the compatible values to be backward compatible , but
for new Gen4 SoCs such as V4M we can avoid this.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The MAX96724 is almost identical to the MAX96712 and can be supported by
the same driver, add support for it.
For the staging driver which only supports patter generation the big
difference is that the datasheet (rev 4) for MAX96724 do not describe
the DEBUG_EXTRA register, which is at offset 0x0009 on MAX96712. It's
not clear if this register is removed or moved to a different offset.
What is known is writing to register 0x0009 have no effect on MAX96724.
This makes it impossible to increase the test pattern clock frequency
from 25 MHz to 75Mhz on MAX96724. To be able to get a stable test
pattern the DPLL frequency have to be increase instead to compensate for
this. The frequency selected is found by experimentation as the MAX96724
datasheet is much sparser then what's available for MAX96712.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The DEBUG_EXTRA register is not part of soon to be added MAX96724
device. To make it easier to understand the differences when reading the
code prepare for the addition by creating named defines for the
register.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Prepare for supporting MAX96724 by moving the soon device specific link
frequency setting into information structure. This struct will be
extended to carry more differences between the two devices supported.
While at it remove trailing comma in device table, no entries will be
appended after the sentinel.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This check is incorrect and checks the wrong register. Furthermore there
is no documented shared device id register for MAX96712. There might be
overlap with the soon to be added MAX96724 device which do document such
a register.
However as the check was merely a precaution and to check during
development that the driver could talk to the device there is no harm in
removing it all together. A correct and more sophisticated check can be
added later if there ever is a need to differentiate between different
versions of a device.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The MAX96712 and MAX96724 are both quad GMSL2 to CSI-2 deserializers and
are in parts similar, but not identical. The most obvious difference is
on the CSI-2 side where the MAX96712 have 4 PHYs and support D-PHY with
1x4, 2x2 and 4x2 lanes where the MAX96724 only have 2 PHYs and supports
D-PHY with 2x4 or 4x2 lanes.
The register layout overlap in part but there are differences and holes.
Most of the differences are related to the different number of CSI-2
PHYs, but there are other capability differences between the two.
Add a specific compatible for MAX96724 to the max96712 bindings. The
bindings do not yet support validating all DT properties to limit it the
each devices capabilities. However to allow for this in future a
specific compatible for the two different devices are needed.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The V4M is the second Gen4 device that is enabled in the rcar-csi2
driver. There is much overlap with the already supported V4H device. The
registers that where new on Gen4 and where added with the V4H prefix are
retained and only new registers unique to the V4M are added with the new
V4M prefix. This follows the style for when V4H was added which had an
overlap with Gen3 registers.
The V4M CSI-2 receiver supports D-PHY mode only, either in 1-, 2- or
4-lane configuration. The datasheets do not document lane swapping and
is left out for now.
While the V4M only supports D-PHY the configuration for it is added in
such a way that it can be reused for V4H which supports both C-PHY and
D-PHY. No known SoC exists to test the D-PHY configuration on V4H so
it's not wired-up.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Prepare for V4M support by moving the PHTW write helpers to the generic
write helpers. This is needed as adding V4M support will involve
interact with the PHTW register from code that are logically grouped
with similar code in such a way that forward declarations of these
helpers would otherwise be needed.
The functions are moved verbatim.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The structure mapping a configuration information to a particular mpbs
setting needs to be extended with more information to support future
SoCs. Before it is extended reduce code duplication by creating a helper
to lookup information from an array of mbps setting, the lookup code
has already been copied to two speared locations.
While at it rename the structure to make it clear it contains
information related to a mbps setting, not just a single register value.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Most of the registers used on the R-Car V4M CSI-2 IP are shared with the
devices already supported by the rcar-csi2 driver. Two registers which
function and layout are the same are however found on different offsets.
Prepare for adding support for R-Car V4M by storing the offset to these
two registers offsets in the device information structured. This way the
code, which is shared between the devices, can be reused when V4M
support is added.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The helper to write an array of code and data values to the PHY Test
Interface Write Register (PHTW) register uses the case where both code
and data are zero as an exit condition. This prevents writing data = 0
and code = 0 to the register.
Up until now this has been OK as no such combination where needed, and
it was a convenient exit condition. In future writing data = 0 and code
= 0 to the PHTW register will be needed.
Avoid using an exit condition when writing an array of PHTW values and
instead pass the length of the array to the helper. This allows any
combination of code and data to be written.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The return of function imgu_css_grid_end_calc is void.
To ensure code clarity and prevent potential errors, it's advisable
to employ the ';' as a statement separator, except when ',' are
intentionally used for specific purposes.
Signed-off-by: Shen Lichuan <shenlichuan@vivo.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently, the V4L2 subdevice is also created when the device is not
available/connected. From userspace perspective, there is no visible
difference between a working and not-working subdevice (except when
trying it out).
This commit adds a simple preparation step, which includes an
availability check, before the subdev is initialized.
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As we don't know the mode during probe(), it doesn't make sense to
update the sensors' registers with assumptions. As imx290_set_ctrl(),
which is responsible for the happening communication, already ensures that
there is no communication with a suspended sensor, put the sensor to
suspend before calling it.
To clarify the dependency of the PM runtime to the link of the subdev
and the imx290 instance, put the block together.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This register is not described in the public available imx290 datasheet.
Additionally, a read returns '0x07d0' for an imx327lqr and also for an
imx462, which means it cannot be used to distinguish between those two
imx290 derivatives.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This commit corrects spelling errors in comments within
the media/i2c directory found by codespell to enhance clarity
and maintainability of the code.
This change does not affect the functionality.
Signed-off-by: Yu Jiaoliang <yujiaoliang@vivo.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Controls can be exposed to userspace via a v4l-subdevX device, and
userspace has to be able to subscribe to control events so that it is
notified when the control changes value.
Add missing HAS_EVENTS support: flag and .(un)subscribe_event().
Signed-off-by: Tommaso Merciai <tomm.merciai@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Controls can be exposed to userspace via a v4l-subdevX device, and
userspace has to be able to subscribe to control events so that it is
notified when the control changes value.
Add missing HAS_EVENTS support: flag and .(un)subscribe_event().
Signed-off-by: Tommaso Merciai <tomm.merciai@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
By adding support for the V4L2_FMTDESC_FLAG_ENUM_ALL flag into the driver
we allow userspace applications to discover all possible
pixel formats of the hardware block. This way userspace can decide
which decoder to use given the supported pixel formats.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Since the V4L2_FMTDESC_FLAG_ENUM_ALL flag mostly targets stateless
decoder pixel-format enumeration, update visl test driver to use it.
When V4L2_FMTDESC_FLAG_ENUM_ALL flag is set let the driver returns
one more pixel format.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
When the index is ORed with V4L2_FMTDESC_FLAG_ENUM_ALL the
driver clears the flag and enumerate all the possible formats,
ignoring any limitations from the current configuration.
Drivers which do not support this flag yet always return an EINVAL.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
[hverkuil: improved doc when the new flag is not supported by the driver]
On Qualcomm SM8250 SoC there are two sets of regulators, and each of
both sets is specific to six CSIPHY IPs. At the moment there is no
proper split of two "combined" regulators with quite arbitrary selected
names in the driver or platform CAMSS device tree node, however for sake
of clarity and better hardware description it makes sense to move the
currently existing regulator resources from all CSID subdevices to all
CSIPHY subdevices.
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
This change allows to properly assign and manage supply regulator
resources by CSIPHY subdevices of CAMSS, this is needed to fine tune
description of supply regulators on newer platforms, conversion of
old platforms to the new scheme is also anticipated.
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Tested-by: Depeng Shao <quic_depengs@quicinc.com> # SM8550
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
New SoCs have CSID devices inside of a shared "wrapper" i.e. a set of regs
which is responsible for manging the muxes of the CSID to various other
blocks throughout CAMSS.
Not every SoC has this top-level muxing layer so make it optional depending
on whether its declared as a resource or not.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
There is a chance to meet runtime issues during configuration of CAMSS
power domains, because on the error path dev_pm_domain_detach() is
unexpectedly called with NULL or error pointer.
One of the simplest ways to reproduce the problem is to probe CAMSS
driver before registration of CAMSS power domains, for instance if
a platform CAMCC driver is simply not built.
Warning backtrace example:
Unable to handle kernel NULL pointer dereference at virtual address 00000000000001a2
<snip>
pc : dev_pm_domain_detach+0x8/0x48
lr : camss_probe+0x374/0x9c0
<snip>
Call trace:
dev_pm_domain_detach+0x8/0x48
platform_probe+0x70/0xf0
really_probe+0xc4/0x2a8
__driver_probe_device+0x80/0x140
driver_probe_device+0x48/0x170
__device_attach_driver+0xc0/0x148
bus_for_each_drv+0x88/0xf0
__device_attach+0xb0/0x1c0
device_initial_probe+0x1c/0x30
bus_probe_device+0xb4/0xc0
deferred_probe_work_func+0x90/0xd0
process_one_work+0x164/0x3e0
worker_thread+0x310/0x420
kthread+0x120/0x130
ret_from_fork+0x10/0x20
Fixes: 23aa4f0cd3 ("media: qcom: camss: Move VFE power-domain specifics into vfe.c")
Cc: <stable@vger.kernel.org>
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
KASAN reported a null-ptr-deref issue when executing the following
command:
# echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)
RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020]
RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809
RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010
RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6
R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790
R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001
FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ts2020_probe+0xad/0xe10 [ts2020]
i2c_device_probe+0x421/0xb40
really_probe+0x266/0x850
...
The cause of the problem is that when using sysfs to dynamically register
an i2c device, there is no platform data, but the probe process of ts2020
needs to use platform data, resulting in a null pointer being accessed.
Solve this problem by adding checks to platform data.
Fixes: dc245a5f9b ("[media] ts2020: implement I2C client bindings")
Cc: <stable@vger.kernel.org>
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
The buffer in the loop should be released under the exception path,
otherwise there may be a memory leak here.
To mitigate this, free the buffer when allegro_alloc_buffer fails.
Fixes: f20387dfd0 ("media: allegro: add Allegro DVT video IP core driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
This driver is now enabled for compile-testing on architectures
that may not have I/O port access:
drivers/media/cec/platform/seco/seco-cec.c: In function 'smb_word_op.constprop.isra':
include/asm-generic/io.h:542:14: error: call to '_inb' declared with attribute error: inb()) requires CONFIG_HAS_IOPORT
Add a Kconfig dependency again.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
