Hans de Goede [Sat, 4 Feb 2023 16:19:27 +0000 (16:19 +0000)]
media: atomisp: gc0310: Add exposure and gain controls
Add exposure and gain controls. This allows controlling
the exposure and gain through standard v4l2 IOCTLs.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Hans de Goede [Sat, 4 Feb 2023 16:01:50 +0000 (16:01 +0000)]
media: atomisp: gc0310: Drop custom ATOMISP_IOC_S_EXPOSURE support
Exposure and gain control should use standard v4l2 controls,
not a custom ioctl.
The next patch in this series will re-add support as standard controls,
this is split into 2 patches for easier reviewing.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Hans de Goede [Sat, 4 Feb 2023 15:41:28 +0000 (15:41 +0000)]
media: atomisp: gc0310: Remove read-only exposure control
The sensor does not have automatic exposure so the exposure cannot
change underneath us.
And the control is not marked volatile in it flags,
so the .g_volatile_ctrl callback will never get called.
Remove the current broken read-only (no s_ctrl implementation)
exposure ctrl, this will be replaced with a proper r/w exposure
control relying on the kernel caching the last set value
(so non volatile).
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Hans de Goede [Sat, 4 Feb 2023 15:39:23 +0000 (15:39 +0000)]
media: atomisp: gc0310: Remove non working flip-controls
The gc0310_[v|h]_flip() functions are empty stubs, remove
the non working controls.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The gc0310 uses 8 bit register addresses which makes it compatible
with the standard smbus access functions.
Drop the custom reg access helpers, replacing them with the smbus
access functions.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
enum gc0310_tok_type / the data_length read/write parameter
is always GC0310_8BIT, drop this.
Note for the register-lists the indentation is also fixed and
c++ style comments are converted to regular C-style /* */ comments.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Remove the complex optimization to send multiple registers in
one i2c-transfer. None of the other sensor drivers are doing this
and the reg-lists are only used once at stream-start time, so
this does not need to be highly optimized.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Hans de Goede [Sat, 4 Feb 2023 12:35:23 +0000 (12:35 +0000)]
media: atomisp: gc0310: Remove GC0310_TOK_*
Remove the ability to have special tokens in a reg-list,
GC0310_TOK_DELAY is not used and GC0310_TOK_TERM can be replaced
with ARRAY_SIZE, simplifying the code.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Hans de Goede [Sat, 4 Feb 2023 12:24:15 +0000 (12:24 +0000)]
media: atomisp: gc0310: Remove some unused structure definitions
Drop the unused struct gc0310_format and struct regval_list definitions.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Hans de Goede [Sun, 5 Feb 2023 15:05:39 +0000 (15:05 +0000)]
media: atomisp: ov2680: Error handling fixes
Fix 3 error handling issues:
1. In ov2680_s_stream(), when pm_runtime_get_sync() fails it will still
have incremented the pm-runtime reference count so we need to call
pm_runtime_put()
2. In ov2680_s_stream() sensor->is_streaming should always be set to false
when the sensor is powered-off even on i2c-communication errors.
3. In ov2680_probe(), call ov2680_remove() on ov2680_s_config() errors,
so that pm_runtime_disable() is properly called to disable the
runtime-pm which has been enabled before the ov2680_s_config() call.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Hans de Goede [Sat, 1 Apr 2023 13:25:20 +0000 (14:25 +0100)]
media: atomisp: ov2680: Use v4l2_get_acpi_sensor_info() for the GPIO lookups
Use the new v4l2_get_acpi_sensor_info() for the GPIO lookups,
this uses the special Intel _DSM method to get more info about
the GPIOs like their function and their polarity.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
ACPI nodes describing sensors on atomisp devices implement a
"79234640-9e10-4fea-a5c1-b5aa8b19756f" Device Specific Method (DSM)
to get info about the GPIOs.
Using this method is necessary to figure out which ACPI GPIO resource
is "reset" and which one is "powerdown" and this is also necessary to
figure out the correct polarity of the pins.
One example where this is necessary is the GC0310 sensor. The current
GC0310 code hardcodes reset as being active-low and power-down as being
active-high. This works on a number of devices such as the mpman
converter 9. But it is wrong for the Chuwi Vi8 CWI501 where the powerdown
pin is active-low.
Rather then adding DMI quirks for this, add a helper for this,
which can be shared between sensor-drivers. This new helper optionally
also returns a string identifying the exact sensor-module used, which
might be useful if any module specific behvior is necessary in the sensor
driver.
This uses the DSM directly on the sensor device's ACPI node. This is
different from later Intel hardware (IPU3 / IPU6) which has a separate
INT3472 node (with its own driver) with this info.
Since there is no separate ACPI node to which we can bind to register GPIO
lookups, this unfortunately means that all sensor drivers which may be used
on BYT or CHT hw need to call this new helper.
Note for now this function is being added to atomisp_gmin_platform.c,
but once things are ready to move atomisp over to using generic sensor
drivers this will need to become a generic v4l2 sensor helper. but this
will require upstream discussion first.
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Here is the original commit message from the aforementioned patch:
From 26fc9fe5030b63bc9dcf0b5f32981948911ca272 Mon Sep 17 00:00:00 2001
From: Lucas De Marchi <lucas.demarchi@intel.com>
Date: Fri, 7 Jul 2017 14:23:53 -0700
Subject: [PATCH] linux-yocto: Remove remaining instance of call to
trace_printk
It's not sufficient to leave trace_printk() out of "normal call chains" since
the way trace infrastructure works is that it will allocate the trace_printk
buffers if the symbol is there (by using a separate section for the function
and checking if __start_* and __stop_* symbols are different.
Therefore, even if the default value for the param tells the module to use
printk(), just the fact that it can be changed to trace_printk() means the
initialization code will be called.
The trace_printk() was replaced by pr_info() on commit 3d81099c75a6
("media: atomisp: Replace trace_printk by pr_info") for the upstreamed
atomisp, too. However, as the aforementioned commit message says, there
is still a remaining instance. This causes the "trace_printk() being
used" kernel warning message to still appear on the first driver load.
Based on the aforementioned patch, this patch removes the call to
ftrace_vprintk(). This removes that kernel warning.
In addition to this, this patch also removes the following now unused
things:
- now empty atomisp_css2_dbg_ftrace_print()
- trace_printk option from dbg_func kernel parameter
Hans de Goede [Tue, 21 Feb 2023 14:58:58 +0000 (14:58 +0000)]
media: atomisp: Remove continuous mode support
Continues mode is a special mode where 2 /dev/video devices can be active
at the same time. Either the video-preview + video nodes or the
viewfinder (for still capture) + capture nodes.
For the video-preview + video-recording case modern userspace will
use a single stream multiplexed by pipewire.
The still-capture case is extra special only starting the preview
stream and then relying on a custom ATOMISP_IOC_S_CONT_CAPTURE_CONFIG
ioctl to set things up followed by a second stream on to capture
the amount of configured still pictures. While running the sensor
at full resolution all the time. This case too is better handled
with dma-buf + GPU downscaling for the view-finder rather then all this
custom special code. Besises this the ioctl expects a bunch of special
non error checked conditions to be met otherwise things will crash/hang.
The continues mode also involves a special cases all over the code
getting in the way of further cleanups and simplifying the code to
using just 1 /dev/video# node. So lets remove it and the
related custom ATOMISP_IOC_S_CONT_CAPTURE_CONFIG ioctl.
Hans de Goede [Tue, 21 Feb 2023 14:58:57 +0000 (14:58 +0000)]
media: atomisp: Remove depth-mode support
Remove support for depth mode. This is a special mode where 2 streams
(from 2 different sensors) can be setup and then starting/stopping
1 will automatically also start/stop the other.
Like many of these special features I'm pretty sure that if the queue
setup is not done exactly right things will crash and there is no error
checking for this.
This seems to be for stereoscopic vision and the only known hw which
actually supports this is the Intel Aero board/SDK, all other 1000+
BYT/CHT models don't need this.
This false outside of the standard webcam use scenario which we are
trying to get working and this involves a bunch of hacks / special
exceptions all over the code, so lets remove this.
Laurent Pinchart [Wed, 25 Jan 2023 18:29:48 +0000 (18:29 +0000)]
media: i2c: Drop unused vs6624 camera sensor driver
The vs6624 camera sensor driver doesn't support DT and relies on
platform data. The last board files supplying platform data for that
device have been removed from the kernel in v4.17. The driver hasn't
been used since them. Drop it.
Laurent Pinchart [Wed, 25 Jan 2023 18:29:48 +0000 (18:29 +0000)]
media: i2c: Drop unused sr030pc30 camera sensor driver
The sr030pc30 camera sensor driver doesn't support DT and relies on
platform data. No board file has ever provided platform data for that
device. The driver has thus never been used in the mainline kernel since
its introduction in v2.6.37. Drop it.
Laurent Pinchart [Wed, 25 Jan 2023 18:29:48 +0000 (18:29 +0000)]
media: i2c: Drop unused s5k6aa camera sensor driver
The s5k6aa camera sensor driver doesn't support DT and relies on
platform data. The last board files supplying platform data for that
device have been removed from the kernel in v3.11. The driver hasn't
been used since them. Drop it.
Laurent Pinchart [Wed, 25 Jan 2023 18:29:48 +0000 (18:29 +0000)]
media: i2c: Drop unused noon010pc30 camera sensor driver
The noon010pc30 camera sensor driver doesn't support DT and relies on
platform data. The last board files supplying platform data for that
device have been removed from the kernel in v3.16. A device tree file
referencing the device has been added in v3.17, but without
corresponding DT bindings, and with DT support in the driver. The driver
thus hasn't been used since v316. Drop it.
Laurent Pinchart [Wed, 25 Jan 2023 18:29:48 +0000 (18:29 +0000)]
media: i2c: Drop unused mt9t001 camera sensor driver
The mt9t001 camera sensor driver doesn't support DT and relies on
platform data. No board file has ever provided platform data for that
device. The driver has thus never been used in the mainline kernel since
its introduction in v3.2. Drop it.
Laurent Pinchart [Wed, 25 Jan 2023 18:29:48 +0000 (18:29 +0000)]
media: i2c: Drop unused mt9m032 camera sensor driver
The mt9m032 camera sensor driver doesn't support DT and relies on
platform data. No board file has ever provided platform data for that
device. The driver has thus never been used in the mainline kernel since
its introduction in v3.4. Drop it.
Laurent Pinchart [Wed, 25 Jan 2023 18:29:48 +0000 (18:29 +0000)]
media: i2c: Drop unused m5mols camera sensor driver
The m5mols camera sensor driver doesn't support DT and relies on
platform data. The last board files supplying platform data for that
device have been removed from the kernel in v3.11. The driver hasn't
been used since them. Drop it.
Laurent Pinchart [Wed, 25 Jan 2023 18:29:48 +0000 (18:29 +0000)]
media: i2c: Drop unused ad9389b video encoder driver
The ad9389b video encoder driver doesn't support DT and relies on
platform data. No board file has ever provided platform data for that
device. The driver has thus never been used in the mainline kernel since
its introduction in v3.7. Drop it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Ming Qian [Wed, 22 Mar 2023 05:13:09 +0000 (05:13 +0000)]
media: Add ABGR64_12 video format
ABGR64_12 is a reversed RGB format with alpha channel last,
12 bits per component like ABGR32,
expanded to 16bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
Signed-off-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Ming Qian [Wed, 22 Mar 2023 05:13:08 +0000 (05:13 +0000)]
media: Add BGR48_12 video format
BGR48_12 is a reversed RGB format with 12 bits per component like BGR24,
expanded to 16bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
Signed-off-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Ming Qian [Wed, 22 Mar 2023 05:13:07 +0000 (05:13 +0000)]
media: Add YUV48_12 video format
YUV48_12 is a YUV format with 12-bits per component like YUV24,
expanded to 16bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
[hverkuil: replaced a . by ,]
Signed-off-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Ming Qian [Wed, 22 Mar 2023 05:13:06 +0000 (05:13 +0000)]
media: Add Y212 v4l2 format info
Y212 is a YUV format with 12-bits per component like YUYV,
expanded to 16bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
Add the missing v4l2 foramt info of Y212
Signed-off-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Ming Qian [Wed, 22 Mar 2023 05:13:05 +0000 (05:13 +0000)]
media: Add Y012 video format
Y012 is a luma-only formats with 12-bits per pixel,
expanded to 16bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
Signed-off-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Ming Qian [Wed, 22 Mar 2023 05:13:04 +0000 (05:13 +0000)]
media: Add P012 and P012M video format
P012 is a YUV format with 12-bits per component with interleaved UV,
like NV12, expanded to 16 bits.
Data in the 12 high bits, zeros in the 4 low bits,
arranged in little endian order.
And P012M has two non contiguous planes.
Signed-off-by: Ming Qian <ming.qian@nxp.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Tomi Valkeinen [Thu, 23 Mar 2023 13:58:35 +0000 (13:58 +0000)]
media: v4l2-subdev: Add new ioctl for client capabilities
Add new ioctls to set and get subdev client capabilities. Client in this
context means the userspace application which opens the subdev device
node. The client capabilities are stored in the file handle of the
opened subdev device node, and the client must set the capabilities for
each opened subdev.
For now we only add a single flag, V4L2_SUBDEV_CLIENT_CAP_STREAMS, which
indicates that the client is streams-aware.
The reason for needing such a flag is as follows:
Many structs passed via ioctls, e.g. struct v4l2_subdev_format, contain
reserved fields (usually a single array field). These reserved fields
can be used to extend the ioctl. The userspace is required to zero the
reserved fields.
We recently added a new 'stream' field to many of these structs, and the
space for the field was taken from these reserved arrays. The assumption
was that these new 'stream' fields are always initialized to zero if the
userspace does not use them. This was a mistake, as, as mentioned above,
the userspace is required to zero the _reserved_ fields. In other words,
there is no requirement to zero this new stream field, and if the
userspace doesn't use the field (which is the case for all userspace
applications at the moment), the field may contain random data.
This shows that the way the reserved fields are defined in v4l2 is, in
my opinion, somewhat broken, but there is nothing to do about that.
To fix this issue we need a way for the userspace to tell the kernel
that the userspace has indeed set the 'stream' field, and it's fine for
the kernel to access it. This is achieved with the new ioctl, which the
userspace should usually use right after opening the subdev device node.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Hans Verkuil [Thu, 2 Mar 2023 12:45:11 +0000 (12:45 +0000)]
media: pci: saa7146: advertise only those TV standard that are supported
V4L2_STD_ALL advertises more standards than these boards
actually support. This causes a V4L2 compliance issue. Limit
the supported standards to those that are actually implemented.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Hans Verkuil [Thu, 2 Mar 2023 11:39:41 +0000 (11:39 +0000)]
media: mxb: update the tvnorms when changing input
The tuner input uses different tvnorms compared to the
S-Video/Composite inputs. So update the tvnorms field
in struct video_device when switching inputs.
This fixes a V4L2 compliance issue.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
When this driver is loaded for the first time, input 0 is
not initialized. In order to capture from that input you would
have to switch to input 1, then back to 0.
Properly initialize the input when the driver is loaded.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Hans Verkuil [Thu, 23 Mar 2023 15:11:20 +0000 (15:11 +0000)]
media: common: saa7146: disable clipping
The patch removing overlay support also removed the old
saa7146_disable_clipping() function, but that is needed in order
to capture video. Without this the Hexium cards won't show any
video.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 7777694f8066 ("media: saa7146: drop overlay support") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Document FCPVD found in RZ/G2L alike SoCs. FCPVD block is similar to
FCP for VSP found on R-Car SoC's . It has 3 clocks compared to 1
clock on fcpv. Introduce new compatibles renesas,r9a07g044-fcpvd
for RZ/G2{L,LC} and renesas,r9a07g054-fcpvd for RZ/V2L to handle this
difference.
The 3 clocks are shared between du, vspd and fcpvd. No driver changes
are required as generic compatible string "renesas,fcpv" will be used
as a fallback.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Irui Wang [Mon, 3 Apr 2023 09:43:42 +0000 (10:43 +0100)]
media: mediatek: vcodec: Coverity issues in encoder driver
CERT-C Characters and Strings:
check core id is in valid range:
dev->reg_base[dev->venc_pdata->core_id] evaluates to an address
that could be at negative offset of an array.
CERT-C Expression:
check buf is not NULL before used:
Dereferencing buf, which is known to be NULL.
Signed-off-by: Irui Wang <irui.wang@mediatek.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Wei Chen [Wed, 29 Mar 2023 08:05:13 +0000 (09:05 +0100)]
media: mediatek: vcodec: Fix potential array out-of-bounds in decoder queue_setup
variable *nplanes is provided by user via system call argument. The
possible value of q_data->fmt->num_planes is 1-3, while the value
of *nplanes can be 1-8. The array access by index i can cause array
out-of-bounds.
Fix this bug by checking *nplanes against the array size.
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Hans Verkuil [Fri, 24 Mar 2023 14:52:57 +0000 (14:52 +0000)]
media: cec: core: not all messages were passed on when monitoring
The valid_la boolean is used to check if the destination logical
address is either 15 (broadcast) or our logical address. If it is
for another logical address, then only adapters that have the
CEC_CAP_MONITOR_ALL capability can pass it on.
However, it is also used to do more detailed validity checks,
such as whether the message was broadcast when it should have been
directed, or vice versa, in which case the message must be ignored
according to the spec. But that should not apply to monitoring.
Add a new bool that just checks the LA and nothing else.
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
media: verisilicon: Fix crash when probing encoder
ctx->vpu_dst_fmt is no more initialized before calling hantro_try_fmt()
so assigne it to vpu_fmt led to crash the kernel.
Like for decoder case use 'fmt' as format for encoder and clean up
the code.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: db6f68b51e5c ("media: verisilicon: Do not set context src/dst formats in reset functions") Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Laurent Pinchart [Wed, 15 Feb 2023 15:18:39 +0000 (17:18 +0200)]
media: Use designated initializers for all subdev pad ops
Structures passed to subdev pad operations are all zero-initialized when
declaring variables. In most cases, this is done with designated
initializers to initialize some of the fields to specific values, but in
a minority of cases the structures are zero-initialized by assigning
them to '{ 0 }' or '{ }'.
Improve coding style consistency by using designated initializers where
possible, always initializing the 'which' field.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Laurent Pinchart [Wed, 15 Feb 2023 15:18:39 +0000 (17:18 +0200)]
media: Prefer designated initializers over memset for subdev pad ops
Structures passed to subdev pad operations are all zero-initialized, but
not always with the same kind of code constructs. While most drivers
used designated initializers, which zero all the fields that are not
specified, when declaring variables, some use memset(). Those two
methods lead to the same end result, and, depending on compiler
optimizations, may even be completely equivalent, but they're not
consistent.
Improve coding style consistency by using designated initializers
instead of calling memset(). Where applicable, also move the variables
to inner scopes of for loops to ensure correct initialization in all
iterations.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Lad Prabhakar <prabhakar.csengg@gmail.com> # For am437x Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Laurent Pinchart [Wed, 15 Feb 2023 15:18:39 +0000 (17:18 +0200)]
media: Zero-initialize all structures passed to subdev pad operations
Several drivers call subdev pad operations, passing structures that are
not fully zeroed. While the drivers initialize the fields they care
about explicitly, this results in reserved fields having uninitialized
values. Future kernel API changes that make use of those fields thus
risk breaking proper driver operation in ways that could be hard to
detect.
To avoid this, make the code more robust by zero-initializing all the
structures passed to subdev pad operation. Maintain a consistent coding
style by preferring designated initializers (which zero-initialize all
the fields that are not specified) over memset() where possible, and
make variable declarations local to inner scopes where applicable. One
notable exception to this rule is in the ipu3 driver, where a memset()
is needed as the structure is not a local variable but a function
parameter provided by the caller.
Not all fields of those structures can be initialized when declaring the
variables, as the values for those fields are computed later in the
code. Initialize the 'which' field in all cases, and other fields when
the variable declaration is so close to the v4l2_subdev_call() call that
it keeps all the context easily visible when reading the code, to avoid
hindering readability.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Shuah Khan <skhan@linuxfoundation.org> # For vimc Reviewed-by: Lad Prabhakar <prabhakar.csengg@gmail.com> # For am437x Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> # For drivers/staging/media/imx/ Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Laurent Pinchart [Wed, 15 Feb 2023 15:24:57 +0000 (17:24 +0200)]
media: Fix indentation issues introduced by subdev-wide state struct
Commit 0d346d2a6f54 ("media: v4l2-subdev: add subdev-wide state struct")
applied a large media tree-wide change produced by coccinelle. It was so
large that a set of identical indentation issues went unnoticed during
review. Fix them.
While at it, and because it's easy to review both changes together, add
a trailing comma for the last (and only) struct member initialization of
the related structures, to avoid future changes should new fields need
to be initialized.
Fixes: 0d346d2a6f54 ("media: v4l2-subdev: add subdev-wide state struct") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
media: venus: dec: Fix capture formats enumeration order
Commit 9593126dae3e ("media: venus: Add a handling of QC08C compressed
format") and commit cef92b14e653 ("media: venus: Add a handling of QC10C
compressed format") added support for the QC08C and QC10C compressed
formats respectively.
But these also caused a regression, because the new formats where added
at the beginning of the vdec_formats[] array and the vdec_inst_init()
function sets the default format output and capture using fixed indexes
of that array:
Since now V4L2_PIX_FMT_NV12 is not the first entry in the array anymore,
the default capture format is not set to that as it was done before.
Both commits changed the first index to keep inst->fmt_out default format
set to V4L2_PIX_FMT_H264, but did not update the latter to keep .fmt_out
default format set to V4L2_PIX_FMT_NV12.
Rather than updating the index to the current V4L2_PIX_FMT_NV12 position,
let's reorder the entries so that this format is the first entry again.
This would also make VIDIOC_ENUM_FMT report the V4L2_PIX_FMT_NV12 format
with an index 0 as it did before the QC08C and QC10C formats were added.
Fixes: 9593126dae3e ("media: venus: Add a handling of QC08C compressed format") Fixes: cef92b14e653 ("media: venus: Add a handling of QC10C compressed format") Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Michał Krawczyk [Mon, 30 Jan 2023 13:54:18 +0000 (13:54 +0000)]
media: venus: dec: Fix handling of the start cmd
The decoder driver should clear the last_buffer_dequeued flag of the
capture queue upon receiving V4L2_DEC_CMD_START.
The last_buffer_dequeued flag is set upon receiving EOS (which always
happens upon receiving V4L2_DEC_CMD_STOP).
Without this patch, after issuing the V4L2_DEC_CMD_STOP and
V4L2_DEC_CMD_START, the vb2_dqbuf() function will always fail, even if
the buffers are completed by the hardware.
Fixes: beac82904a87 ("media: venus: make decoder compliant with stateful codec API") Signed-off-by: Michał Krawczyk <mk@semihalf.com> Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Florian Fainelli [Fri, 24 Mar 2023 20:38:33 +0000 (13:38 -0700)]
media: rc: gpio-ir-recv: Fix support for wake-up
The driver was intended from the start to be a wake-up source for the
system, however due to the absence of a suitable call to
device_set_wakeup_capable(), the device_may_wakeup() call used to decide
whether to enable the GPIO interrupt as a wake-up source would never
happen. Lookup the DT standard "wakeup-source" property and call
device_init_wakeup() to ensure the device is flagged as being wakeup
capable.
Reported-by: Matthew Lear <matthew.lear@broadcom.com> Fixes: fd0f6851eb46 ("[media] rc: Add support for GPIO based IR Receiver driver") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
The GPIO IR receiver can be used as a wake-up source for the system,
document that.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Sakari Ailus [Fri, 13 May 2022 13:12:54 +0000 (16:12 +0300)]
media: ccs: Differentiate SMIA and MIPI vendors in static data
MIPI CCS uses a 16-bit MIPI manufacturer identifier for firmware filenames
compared to older 8-bit identifier used by SMIA. The requested firmware
files used the MIPI manufacturer ID even for SMIA compliant devices,
effectively making the manufacturer ID 0.
While CCS static data is a feature of CCS 1.1, it has no hardware
dependencies. Making this feature available for SMIA devices helps adding
support for them and avoids requesting ill-generated CCS static data file
names. The files are named as:
ccs/smiapp-module-vv-mmmm-rrrr.fw,
ccs/smiapp-sensor-vv-mmmm-rr.fw and
ccs/smia-sensor-vv-mmmm-rr.fw
where vv is the manufacturer ID, mmmm is the model ID and rr or rrrr is
the revision number.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
projects / thirdparty / kernel / linux.git / log
