Depending on which order userspace makes various v4l2 calls, the sensor
might still be powered down when set_fmt is called.
What should really happen here is delay the writing of the mode-related
registers till streaming is started, but for now use the same quick fix
as the atomisp_ov2680 / atomisp_gc0310 code and call power_up() from
set_fmt() in combination with keeping track of the power-state to avoid
doing the power-up sequence twice.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
On ov2722_set_fmt() calls with format->which == V4L2_SUBDEV_FORMAT_TRY,
ov2722_set_fmt() does not talk to the sensor, so there is no need to
lock the dev->input_lock mutex in this case.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The comment claims the PWDN pin is active when pulled down in other words,
it is /power-down so it needs to be driven high to get the sensor
powered-up (not powered down) and flag is 1 when powering-up the sensor
so the ! is wrong, drop it.
This also matches with the schematics which I have which shows GPIO1 also
enables a 3.3v line to the sensor-module which controls the privacy-LED
and indeed before this patch the privacy LED was inverted from what it
should be (and the sensor did not work).
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Call atomisp_gmin_remove_subdev() on probe failure to properly free
the GPIOs and other resources acquired by the gmin_camera_platform_data()
call earlier.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The DSDT of all Windows BYT / CHT devices which I have seen has proper
ACPI powermagement for the clk and regulators used by the sensors.
So there is no need for the whole custom atomisp_gmin custom code to
disable the ACPI pm and directly poke at the PMIC for this.
Replace all the atomisp_gmin usage with using the new
atomisp_register_sensor_no_gmin() / atomisp_unregister_subdev()
helpers which allow registering a sensor with the atomisp code
without using any of the atomisp_gmin power-management code.
Note eventually these calls should be replaced by the standard
v4l2_async_register_subdev_sensor() mechanism.
But this first requires a bunch of work to the atomisp main code
to make it set the necessary fwnodes up, similar to how
drivers/media/pci/intel/ipu3/cio2-bridge.c does this.
This has been tested on:
-Trekstor Surftab duo W1 10.1, CHT, AXP288 PMIC, 2x ov2680 sensor
-Asus T101HA, CHT, TI PMIC, 1x ov2680 sensor
-MPMAN Converter 9, BYT, AXP288 PMIC, ov2680 back, gc0310 front sensor
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Use devm_kzalloc() to allocate the sensor data struct. It is always free-ed
as the last step of probe-error-exit or remove, so it can be devm-managed.
This will make unwinding things easier when support is added to the ov2680
code to use standard GPIO APIs instead of the custom atomisp_gmin code.
This also allows dropping the out_free label and use direct return
on errors.
This may seem like a functional change since the out_free label also
did a v4l2_device_unregister_subdev() but at the 2 changed returns
the device is not registered yet, so that always is a no-op and can
be dropped.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Add a dev local variable to probe(), to allow shortening
&client->dev in various places, including further patches
in this series.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Using dev as name for variables pointing to struct ov2680_device is a bit
unfortunate choice.
All the recently added / rewritten code is already using sensor for this,
replace the remaining usages of "struct ov2680_device *dev" with
"struct ov2680_device *sensor".
Note the power_up()/power_down() related functions are not changed as
these will be removed in one of the next patches.
No functional changes.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Add runtime-pm support. This is a preparation patch for letting
ACPI deal with the regulators and clocks instead of the DIY code
in atomisp_gmin_platform.c.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Move the setting of the mode to stream on, this also allows
delaying power-on till streaming is started.
And drop the deprecated s_power callback since this now no long
is necessary.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Remove unused includes and sort the remaining ones alphabetically.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Use the same indentation level for all #define values.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The ov2680 only supports a single format, there is no need to
use a define for this.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Remove a bunch of unused data-types and defines from ov2680.h.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
3 fixes for the framesize list:
1. Drop modes < 640x480, these are made by significant cropping,
leading to such a small remainig field-of-view that they are
not really usable
2. 1616x1082 is presumably intended to be 1600x1080 + 16 pixels
padding in both dimensions, but the height is wrong.
Change this to 1616x1096.
3. The 800x600 mode is missing the 16 pixels padding and
720x592 is missing 16 pixels padding in its width and
the 720x576 base mode is a mode with non square pixels,
while the sensor has square pixels.
Replace both with 768x576 + 16 pixels padding -> 784x592
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Drop struct ov2680_resolution and the ov2680_res_preview[] array,
this is now only used in ov2680_enum_frame_size() and only
the width + height are used there.
Replace this with a new struct v4l2_frmsize_discrete ov2680_frame_sizes[]
array.
No functional changes.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Since we now calculate timings baded on the desired width and height,
any width and height are valid as long as they don't exceed the sensor's
dimensions.
Drop the v4l2_find_nearest_size() call and instead clamp the requested
width and height.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Fix and simplify ov2680_enum_frame_interval(), the index is not
an index into ov2680_res_preview[], so using N_PREVIEW is wrong.
Instead it is an index indexing the different framerates for
the resolution specified in fie->width, fie->height.
Since the ov2680 code only supports a single fixed 30 fps,
index must always be 0 and we don't need to check the other
fie input values.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The res member of struct ov2680_device isn't read anywhere anymore,
drop it.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The fps, lines-per-frame and skip-frames values are the same for all
resolutions, use defines for these.
The ov2680_res_preview[] incorrectly sets fps to 60 for some low-res
modes, this is incorrect with the current fixed (resolution independent)
lines-per-frame value.
Note this not drop the now no longer used fps, lines-per-frame and
skip-frames struct ov2680_resolution members. The entire struct is going
away in the next patches so that would just cause unnecessary changes.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Instead of using a long fixed register settings list for each resolution,
calculate the register settings based on the requested width + height.
This will allow future enhancements like adding hblank and vblank controls
and adding selection support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
By default the ov2680 automatically sets the window to match the outputsize
and automatically adjusts it to keep the bayer pattern stable when enabling
hflip/vflip.
This does not work for the 1616x1216 mode because there is no room to
adjust the window there. To make flipping work in the 1616 wide modes the
register lists for those modes set bit 0 of 0x5708 (manual_win_en) to 1 and
ov2680_set_bayer_order() updates the bayer-order on the pad to match.
But ov2680_set_bayer_order() is always called, so when enabling flipping
on modes with a width of less then 1616 now results in the wrong bayer
order being reported on the pad since the sensor is auto-adjusting
the window in this case.
Specify the correct (== output-size) window-size in all resolutions
register-list and always set the manual_win_en bit, so that the bayer order
is changed on hflip/vflip enable on all resolutions.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Add a test pattern control. This is a 1:1 copy of the test pattern
control in the main drivers/media/i2c/ov2680.c driver.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Add exposure and gain controls. This allows controlling
the exposure and gain through standard v4l2 IOCTLs.
Note the register defines for the exposure and gain registers
are renamed to match the datasheet.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
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@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Rework the flip ctrls to be more like those of mainline (non staging)
drivers.
This is modelled after the main ov2680 and ov5693 drivers. This also
introduces __ov2680_get_pad_format() to make the ov2680 code more compliant
with the mainline v4l2-subdev APIs.
Note the OV2680_FLIP_REG and OV2680_MIRROR_REG defines are renamed to
OV2680_REG_FORMAT1 and OV2680_REG_FORMAT2 to match the datasheet.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Use the new ov_16bit_addr_reg_helpers.h instead of duplicating
the ovxxxx sensor I2C register access helpers found in many different
sensor drivers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The following drivers under drivers/media/i2c: ov08x40.c, ov13858.c,
ov13b10.c, ov2680.c, ov2685.c, ov2740.c, ov4689.c, ov5670.c,
ov5675.c, ov5695.c, ov8856.c, ov9282.c and ov9734.c,
as well as various "atomisp" sensor drivers in drivers/staging, *all*
use register access helpers with the following function prototypes:
int ovxxxx_read_reg(struct ovxxxx_dev *sensor, u16 reg,
unsigned int len, u32 *val);
int ovxxxx_write_reg(struct ovxxxx_dev *sensor, u16 reg,
unsigned int len, u32 val);
To read/write registers on Omnivision OVxxxx image sensors wich expect
a 16 bit register address in big-endian format and which have 1-3 byte
wide registers, in big-endian format (for the higher width registers).
Add a new ov_16bit_addr_reg_helpers.h header file with static inline
versions of these register access helpers, so that this code duplication
can be removed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Don't use MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN to initialize the function field
of various media-entity links.
This fixes the following warnings showing up in dmesg:
atomisp-isp2 0000:00:03.0: Entity type for entity ATOM ISP CSI2-port0 was not initialized!
atomisp-isp2 0000:00:03.0: Entity type for entity ATOM ISP CSI2-port1 was not initialized!
atomisp-isp2 0000:00:03.0: Entity type for entity ATOM ISP CSI2-port2 was not initialized!
atomisp-isp2 0000:00:03.0: Entity type for entity tpg_subdev was not initialized!
atomisp-isp2 0000:00:03.0: Entity type for entity ATOMISP_SUBDEV_0 was not initialized!
atomisp-isp2 0000:00:03.0: Entity type for entity ATOMISP_SUBDEV_1 was not initialized!
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Looking at csi2_link_setup(), this function can never work,
it does a switch-case like this:
switch (local->index | is_media_entity_v4l2_subdev(remote->entity))
with cases like this:
case ATOMISP_SUBDEV_PAD_SOURCE | MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN
where ATOMISP_SUBDEV_PAD_SOURCE matches an index (0-1) and
MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN is 0x00020000, but
is_media_entity_v4l2_subdev(remote->entity) does not return
MEDIA_ENT_F_* values, it return a bool, so 0 or 1 which means
that non of the cases can ever match the input value.
Looking at the rest of the function all it ever does (if it
would actually hit one of the cases) is set the atomisp_mipi_csi2_device
struct's output member.
And checking the rest of the atomisp code that member is never
read. Also userspace does not actually setup media-controller
links when using the atomisp /dev/video$ nodes since all the links
are fixed. So csi2_link_setup() never runs.
Remove the unnecessary and broken csi2_link_setup() function
and also remove the unused atomisp_mipi_csi2_device struct's
output member.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Looking at isp_subdev_link_setup(), this function can never work,
it does a switch-case like this:
switch (local->index | is_media_entity_v4l2_subdev(remote->entity))
with cases like this:
case ATOMISP_SUBDEV_PAD_SINK | MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN
where ATOMISP_SUBDEV_PAD_SINK matches an index (0-4) and
MEDIA_ENT_F_V4L2_SUBDEV_UNKNOWN is 0x00020000, but
is_media_entity_v4l2_subdev(remote->entity) does not return
MEDIA_ENT_F_* values, it return a bool, so 0 or 1 which means
that non of the cases can ever match the input value.
Looking at the rest of the function all it ever does (if it
would actually hit one of the cases) is set the atomisp_sub_device
struct's input member.
And checking the rest of the atomisp code that member is never
read. Also userspace does not actually setup media-controller
links when using the atomisp /dev/video$ nodes since all the links
are fixed. So isp_subdev_link_setup() never runs.
Remove the unnecessary and broken isp_subdev_link_setup() function
and also remove the unused atomisp_sub_device struct's input member.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The device core will call ACPI to turn the device (i2c_client) for a sensor
on / put it in D0 before calling its probe() method.
This takes a reference on all of the ACPI power-resources belonging to
the device. Since the atomisp_gmin_platform code disables ACPI
power-resource management and does its own pm, this reference never gets
released.
This is a problem for ACPI power-resources which are shared with other
devices since those now never get turned off again (nor back on again).
Explicitly put the device in D3 before disabling the ACPI power-resource
management.
Note that atomisp_register_i2c_module() runs near the end of the sensor
driver's probe() function, after the driver is done with probing the hw.
So the power-resouces (the same resources as directly controlled by
the atomisp platform code) getting turned off (a second time, as they are
already off) is not a problem.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
atomisp_set_fmt() first does:
v4l2_fill_mbus_format(&vformat.format, ...);
vformat.format.height += padding_h;
vformat.format.width += padding_w;
ret = v4l2_subdev_call(isp->inputs[asd->input_curr].camera, pad,
set_fmt, NULL, &vformat);
if (ret)
return ret;
f->fmt.pix.width = vformat.format.width - padding_w;
f->fmt.pix.height = vformat.format.height - padding_h;
this happens with the original padding w/h = 16 values and then later
on it calls:
ret = atomisp_set_fmt_to_snr(vdev, &s_fmt,
f->fmt.pix.pixelformat, padding_w,
padding_h, dvs_env_w, dvs_env_h);
Which repeats the above structure. If at that point padding w/h are
changed to 12 then it will now request a different output-size of
the sensor driver.
The sensor drivers so far have actually been ignoring this since they use
v4l2_find_nearest_size() on a fixed resolution list and the nearest
resolution will be the one from the earlier calls where padding w/h
was 16.
But there really is no reason for sensor drivers to use a fixed
resolution list. They make lower resolutions using cropping so they
can make any resolution as long as width/height are even numbers.
Dropping the fixed-resolution list limit from sensors on BYT results
in trying to start streaming failing because the resolution set to
the sensor now no longer matches with the resolution used during
the initial part of the configuration done by atomisp_set_fmt().
Drop the BYT specific overriding of the padding_w/h to 12, so that
the padding in the first and second s_fmt calls made to the sensor
matches, to fix stream start failing when the fixed resolution list
is dropped.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
ffmt is a local variable pointing to a substruct of another local
variable which really just makes the code harder to read / follow,
so drop it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The DSDT of all Windows BYT / CHT devices which I have seen has proper
ACPI powermagement for the clk and regulators used by the sensors.
So there is no need for the whole custom atomisp_gmin custom code to
disable the ACPI pm and directly poke at the PMIC for this.
Add new atomisp_register_sensor_no_gmin() + atomisp_unregister_subdev()
helpers which allow registering a sensor with the atomisp code without
using any of the atomisp_gmin power-management code.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
atomisp_gmin_find_subdev() can be used to lookup a subdev
given its i2c-adapter + i2c-client-address.
But the only caller of it reads this from the intel_v4l2_subdev_table
struct and that same struct already contains a pointer to the v4l2_subdev.
So this function is not necessary, drop it and modify its only caller
to directly take the subdev from the intel_v4l2_subdev_table struct.
Also drop struct intel_v4l2_subdev_i2c_board_info since that now no
longer is used.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The s_power callback for v4l2-subdevs has been deprecated, allow sensor
drivers without a s_power callback to work by ignoring the -ENOIOCTLCMD
return value.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The atomisp driver creates 8 /dev/video# device nodes. 4 nodes (preview /
video / viewfinder / capture) for each of 2 possible streams aka
atomisp-sub-device-s (asd-s).
Both streams start with asd->input_curr set to 0 (to the first sensor),
opening + releasing a file-handle on one of the nodes of an asd,
while streaming from the other asd causes the sensor to get turned off,
leading to the stream failing.
The atomisp-code already tracks which asd "owns" a specific sensor,
use this to only turn the sensor off if it is owned by the asd.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The memory for all of struct atomisp_video_pipe is kzalloc()-ed in
atomisp_subdev_init() so there is no need to memset parts of
struct atomisp_video_pipe to 0.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
atomisp_init_pipe() does 3 things:
1. Init a bunch of list-heads / locks
2. Init the vb_queue for the videodev (aka pipe)
3. zero the per-frame parameters related variables of the pipe
1. and 2. really should not be done at file-open time, but once at probe.
Currently the code is getting away with doing this on every videodev-open
because only 1 open is allowed at a time.
1. is already done at probe time by atomisp_init_subdev_pipe(), move 2. to
atomisp_init_subdev_pipe() so that it is also done once at probe.
As for 3. The per-frame parameters can only be set from a qbuf ioctl,
which can only happen after a reqbufs ioctl and atomisp_buf_cleanup
already zeros the per-frame parameters when the buffers are released,
so 3. is not necessary at all.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Make atomisp behave like any other drivers and have it load the firmware
at probe time (as it was already doing by default).
The deferred firmware loading support needlessly complicates the
v4l2_file_operations.open callback (atomisp_open()), getting in
the way of allowing multiple opens like a normal v4l2 device would.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Remove the no longer used bin_factor_x, bin_factor_y and bin_mode members
from the resolution info inside various atomisp camera sensor drivers.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The bin-factor-x and bin-factor-y ctrls are only used internally to
get a single value to pass to atomisp_css_input_set_binning_factor(),
which is supposed to tune the lens-shading correction for the binning
factor. But all sensor drivers return either 0 or 1 for this,
with 0 meaning unset and 1 meaning no-binning. Even though some modes
do actually do binning ...
Also note that the removed atomisp_get_sensor_bin_factor() would fall
back to 0 if either the x and y factor differ or if the ctrls are not
implemented (not all sensor drivers implement them).
Simply always pass 0 to atomisp_css_input_set_binning_factor().
This is part of a patch-series which tries to remove atomisp specific /
custom code from the sensor drivers, with as end goal to make the atomisp
drivers regular camera sensor drivers.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
This ioctl returns a number of fixed sensor parameters +
a number of mode-specific parameters.
With libcamera these fixed parameters are instead stored in a table
with sensor-name to parameters mappings (camera_sensor_properties.cpp);
and the variable parameters can be derived from the set fmt.
So this custom ioctl is not necessary; and it currently has no users.
Remove the ioctl and all the sensor drivers xxxx_get_intg_factor()
helpers which return this info.
This is part of a patch-series which tries to remove atomisp specific /
custom code from the sensor drivers, with as end goal to make the atomisp
drivers regular camera sensor drivers.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
This ioctl simply returns a couple of fixed sensor parameters.
With libcamera these fixed parameters are instead stored in a table
with sensor-name to parameters mappings (camera_sensor_properties.cpp),
so this custom ioctl is not necessary; and it currently has no users.
Remove the ioctl and also remove the custom v4l2-ctrls underpinning
the ioctl.
This is part of a patch-series which tries to remove atomisp specific /
custom code from the sensor drivers, with as end goal to make the atomisp
drivers regular camera sensor drivers.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
On BYT on poweron/runtime-resume the code is doing:
1. Do nothing
2. msleep(10)
3. Start actual poweron sequence
Since the runtime resume can happen at any moment, waiting 10ms
after it does not really make any sense.
According to both the comment and to:
https://github.com/intel/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/cam-0341-atomisp-WA-sleep-10ms-when-power-up-ISP-on-byt.patch
Which is the patch which originally added this this was added
as a workaround for a single test failing on a single model
tablet/laptop. So lets just drop this.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
punit_ddr_dvfs_enable() is only used on CHT devices and there dmesg
gets filled with: "DDR DVFS, door bell is not cleared within 3ms"
messages, so clearly the doorbell checking is not working.
This check was added by:
https://github.com/intel/ProductionKernelQuilts/blob/master/uefi/cht-m1stable/patches/cam-0340-atomisp-add-door-bell-for-ddr-dvfs-on-cht.patch
Which commit message says: "PUNIT interface added to check Req_ACK
of freq status". This suggests that the doorbell mechanism may only
be available with certain PUNIT fw versions and it seems that
many CHT devices do not have this fw version; that or the doorbell
mechanism is not working for other reasons.
Revert cam-0340-atomisp-add-door-bell-for-ddr-dvfs-on-cht.patch,
replacing the doorbell check with a msleep(20) this fixes dmesg
getting filled with error messages.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
These are clearly debug messages, printing these all the time is not
useful.
Silence these by simply removing them altogether.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
The atomisp does not use standard PCI power-management through the
PCI config space. Instead this driver directly tells the P-Unit to
disable the ISP over the IOSF. The standard PCI subsystem pm_ops will
try to access the config space before (resume) / after (suspend) this
driver has turned the ISP on / off, resulting in the following errors:
Unable to change power state from D0 to D3hot, device inaccessible
Unable to change power state from D3cold to D0, device inaccessible
Getting logged into dmesg a whole bunch of time during boot as well as
every time the camera is used.
To avoid these errors use a custom pm_domain instead of standard driver
pm-callbacks so that all the PCI subsys suspend / resume handling is
skipped and call pci_save_state() / pci_restore_state() ourselves.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Remove the atomisp_sw_contex struct, it has only 1 member: running_freq,
instead store running_freq directly.
While at it also change running_freq from an int to an unsigned int,
all values stored in it are unsigned and it is compared to the also
unsigned new_freq variable.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
