Repalce kthread_create/wake_up_process() with kthread_run()
to simplify the code.
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
aspeed_video_get_resolution() will try to do res-detect again if the
timing got in last try is invalid. But it will always time out because
VE_SEQ_CTRL_TRIG_MODE_DET is only cleared after 1st mode-detect.
To fix the problem, just clear VE_SEQ_CTRL_TRIG_MODE_DET before setting
it in aspeed_video_enable_mode_detect().
Fixes: d2b4387f3b ("media: platform: Add Aspeed Video Engine driver")
Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
Acked-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The open() fops support two types of devices: "acc" and normal
ones. the acc works on a different way, using a different pipe
struct. Not sure yet if it would make sense to setup a run_mode
there. Also, As default_run_mode exists only on normal modes,
we can simplify the logic to check if the device is in normal
mode.
That solves this warning:
../drivers/staging/media/atomisp/pci/atomisp_fops.c:904 atomisp_open() warn: variable dereferenced before check 'asd' (see line 807)
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The asd->isp was referenced before checking if asd is not
NULL.
This fixes this warning:
../drivers/staging/media/atomisp/pci/atomisp_cmd.c:5548 atomisp_set_fmt_to_snr() warn: variable dereferenced before check 'asd' (see line 5540)
While here, avoid getting the pipe pointer twice.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The "power" pointer is not initialized on the else path and that would
lead to an Oops.
Link: https://lore.kernel.org/linux-media/20211012082150.GA31086@kili
Fixes: c30f4cb2d4 ("media: atomisp: Refactor PMIC detection to a separate function")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The vts value should be set before being checked, as otherwise a
warning will arise:
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c: In function 'ov2680_set_fmt':
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:873:33: warning: 'vts' may be used uninitialized
[-Wmaybe-uninitialized]
873 | if (dev->exposure > vts - OV2680_INTEGRATION_TIME_MARGIN)
Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Fixes: 62b984359b6f ("media: atomisp-ov2680: Fix ov2680_set_fmt() messing up high exposure settings")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As the settings are only applied when the device is powered on,
it should return 0 when the device is not powered.
Not doing that causes a warning:
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c: In function 'ov2680_ioctl':
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:390:16: warning: 'ret' may be used uninitialized in this
function [-Wmaybe-uninitialized]
390 | return ov2680_set_exposure(sd, coarse_itg, analog_gain, digital_gain);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/media/atomisp/i2c/atomisp-ov2680.c:359:13: note: 'ret' was declared here
359 | int ret;
| ^~~
Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Fixes: 6b5b60687ada ("media: atomisp-ov2680: Save/restore exposure and gain over sensor power-down")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
For exposure settings > (lines_per_frame - vts_margin) the VTS register
needs to be programmed to (exposure + vts_margin) rather then being
set to lines_per_frame.
The res->regs register array was clobbering this higher setting causing
high exposure settings to not work. Fix this by letting ov2680_set_fmt()
calculate the vts value, instead of hardcoding it.
This is the last in a series of fixes which fixes exposure and gain
settings not working, with this everything works, so drop the comment
that it does not work.
Link: https://lore.kernel.org/linux-media/20211107171549.267583-12-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Now that we restore the default or last user set exposure setting on
power_up() there is no need for the registers written by ov2680_set_fmt()
to write to the exposure register.
Not doing so fixes the exposure always being reset to the value from
the res->regs array after a set_fmt().
Link: https://lore.kernel.org/linux-media/20211107171549.267583-11-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The shift << 16 of the value in the code path for 16 bit values is
bogus, put_unaligned_be16() takes the lower 16 bits which will not
always be 0.
This was causing __ov2680_set_exposure() to always set the
OV2680_AGC and OV2680_TIMING_VTS registers to 0.
Link: https://lore.kernel.org/linux-media/20211107171549.267583-10-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Switch to ov2680_read_reg() to read all 24 bits in one go;
and the exposure value sits in bits 4-19 of the 24 bit exposure
register, so we need to shift the read value by 4 to report the
correct value.
Link: https://lore.kernel.org/linux-media/20211107171549.267583-9-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Some ov2680 registers like exposure are 24 bit,
ov2680_read_reg() already mostly supports this, we just
need to change the return type from u16 to u32.
Link: https://lore.kernel.org/linux-media/20211107171549.267583-8-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Save/restore exposure and gain over sensor power-down and don't write them
to the sensor when ov2680_set_exposure() is called while the sensor is off.
Link: https://lore.kernel.org/linux-media/20211107171549.267583-7-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Move ov2680_init_registers() call to power_up(), so that we also
init the registers on code-paths which do not call ov2680_s_power()
like running camorama.
Link: https://lore.kernel.org/linux-media/20211107171549.267583-6-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The ov2680_res and N_RES global variables are just hardcoded as aliases
for ov2680_res_preview and N_RES_PREVIEW, remove them.
Link: https://lore.kernel.org/linux-media/20211107171549.267583-5-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
ov2680_s_power() is the only caller of ov2680_init(), push the input_lock
taking from ov2680_init() up into ov2680_s_power(), this way the new
power_on bool is also protected by it.
Link: https://lore.kernel.org/linux-media/20211107171549.267583-4-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add a power_on bool to track if the power is on, and make
power_up() a no-op if the power is already on.
This also removes a power_down() call from ov2680_s_config() since
that is a no-op now, this is ok because s_config() is only called
once on probe and the sensor is off at boot.
Besides avoiding to the work in power_up() multiple times this patch
is also a preparation for switching to the clk and regulator frameworks
which keep an enable count, so there we must call enable() and
disable() only once per power-cycle.
Link: https://lore.kernel.org/linux-media/20211107171549.267583-3-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Remove a couple of variables which where either completely unused,
or only ever got a value assigned to them but were never read.
Link: https://lore.kernel.org/linux-media/20211107171549.267583-2-hdegoede@redhat.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The atomisp currenyl registers 5 pairs of devices each one
for one different run_mode, plus one for "ACC". The only
one that behaves like a normal V4L2 device is the preview
one. The others are doing weird things, and perhaps are
using some proprietary extensions to the API.
Change the device order to start with the preview one,
e. g:
/dev/video0: ATOMISP ISP PREVIEW output
/dev/video1: ATOMISP ISP CAPTURE output
/dev/video2: ATOMISP ISP VIEWFINDER output
/dev/video3: ATOMISP ISP VIDEO output
/dev/video4: ATOMISP ACC
This way, a normal V4L2 application will get the right
device, as the first one will be the one they should use.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The atomisp driver originally used the s_parm command to
initialize the run_mode type to the driver. So, before start
setting up the streaming, s_parm should be called.
So, even having 5 "normal" video devices, one meant to be used
for each type, the run_mode was actually selected when
s_parm is called.
Without setting the run mode, applications that don't call
VIDIOC_SET_PARM with a custom atomisp parameters won't work, as
the pipeline won't be set:
atomisp-isp2 0000:00:03.0: can't create streams
atomisp-isp2 0000:00:03.0: __get_frame_info 1600x1200 (padded to 0) returned -22
However, commit 8a7c5594c0 ("media: v4l2-ioctl: clear fields in s_parm")
broke support for it, with a good reason, as drivers shoudn't be
extending the API for their own purposes.
So, as an step to allow generic apps to use this driver, put
the device's run_mode in preview after open.
After this patch, using v4l2grab starts to work on preview
mode (/dev/video2):
$ v4l2grab -f YUYV -x 1600 -y 1200 -d /dev/video2 -n 1 -u
$ feh out000.pnm
So, let's just setup the default run_mode that each video devnode
should assume, setting it at open() time.
Reported-by: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
All ISP2401 devices use the new input system. So, get rid
of the remaining definitions, replacing them by runtime
checks for BYT/CHT when applicable.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Now that the pipeline config functions can return errors, change
ia_css_dma_configure_from_info() and callers in order for them
to return errors at pipelines instead of using assert().
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Those functions can internally break, but, as they don't return
errors, internally there are some assert() calls, which is bad,
as it hangs the driver.
So, add return codes there, in preparation for removing such
assert() calls.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The auto-generated code inside ia_css_isp_configs() is more
complex than it should be. Also, it doesn't return any errors.
However, the functions called by it can mis-configure the pipelines,
but, as there's no way to return errors, it internally calls the
assert() macro.
So, add a return parameter to each routine there, in order to
prepare the code to be more robust.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The contents of ia_css_isp_params.c is almost identical for
2400 and 2401. The only difference is that, on 2400, there
are some duplicated assignments. So, drop it, unifying this
file.
While here, simplify the Makefile's logic by dropping an
unused define.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Instead of reinventing the wheel, use v4l2_find_nearest_size()
in order to get the closest resolution.
This should address a bug where the wrong resolution was
selected.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Instead of reinventing the wheel, use v4l2_find_nearest_size()
in order to get the closest resolution.
This should address a bug where the wrong resolution was
selected.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Instead of reinventing the wheel, use v4l2_find_nearest_size()
in order to get the closest resolution.
This should address a bug where the wrong resolution was
selected.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Instead of reinventing the wheel, use v4l2_find_nearest_size()
in order to get the closest resolution.
This should address a bug where the wrong resolution was
selected.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Instead of reinventing the wheel, use v4l2_find_nearest_size()
in order to get the closest resolution.
This should address a bug where the wrong resolution was
selected.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The g_fmt logic is currently broken, as it is not returning
the same imagesize as previoulsy calculated by s_fmt.
Fix it by just re-using whatever it was defined at s_fmt,
if this was called before.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The internal try_fmt logic is not meant to provide everything
that the V4L2 API should provide. Also, it doesn't decrement
the pads that are used only internally by the driver, but aren't
part of the device's output.
Fix it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
move atomisp_g_fmt_cap() for it to be after try_fmt, as we'll
re-use try_fmt there.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently, the enum lists the sensor's native format as a
supported format. However, trying to setup a pipeline using
it doesn't work.
So, exclude such formats from the enum.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are several issues on S_FMT implementation:
- it doesn't properly handle pad_h/pad_w;
- it reports a wrong visible size to userspace;
- it allows setting the format to a raw mode, which
currently causes the pipeline to break.
Address such issues, for it to start working with generic
apps.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The sensor width/height report is alread being printed after
its calculus. The only reason for an extra debug printk is
when dis is used. So, change its message to reflect and move
it to be inside the if checks.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Now that this driver starting to show signals of real progress,
let's update its TODO list.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The switch() logic there misses a break and a default case.
That makes it more prone to problems as the code change.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add basic support for Maxim MAX96712 quad GMSL2 deserializers. The
driver is capable of powering on the device and configuring the MIPI
CSI-2 bus in a DPHY 4-lane configuration as well as operating the
internal VTG (Video Timing Generator) and VPG (Video Pattern Generator).
Using these features the driver is able to act as a 1080p @ 30 fps V4L2
video source. Producing either a checkerboard or gradient pattern on the
CSI-2 bus, selectable thru a V4L2 control.
While the driver is useful as-is and have been used to prove the correct
operation of the MAX96712 itself and "downstream" devices using the
MAX96712 as a video source there are a lot of features missing. Most
notably the ability to operate the GMSL bus.
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>
This is already disabled on some parts of the code, and trying
to use it with current firmware causes an error:
[ 53.799946] atomisp-isp2 0000:00:03.0: can't create streams
[ 53.799962] atomisp-isp2 0000:00:03.0: __get_frame_info 1600x900 (padded to 0) returned -22
So, completely disable reporting it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The atomisp sensors and logic adds an extra pad lines/columns,
called "dvs envelope". It also uses an extra 12 lines/columns
at the sensor for BYT.
As those are not visible to userspace, the V4L2 API should
decrement such values when reporting the current resolution.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cai Huoqing
Jammy Huang
Xu Wang
Mauro Carvalho Chehab
Dan Carpenter
Hans de Goede
Niklas Söderlund