There are several error conditions that don't print anything,
making harder to identify bugs at the code there.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There's no reason to copy isp_sink_fmt, as the driver
uses it for read-only purposes.
Linux stack is a precious resource. Let's avoid wasting it.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Currently, when an EOF IRQ is received, it generates two messages:
[ 59.191893] atomisp-isp2 0000:00:03.0: irq:0x200000
[ 59.191913] atomisp-isp2 0000:00:03.0: atomisp_isr EOF exp_id 142, asd 0
Flooding the dmesg with lots of messages per second. The same
pattern happens for all other IRQs.
Change the logic for printing just one message per IRQ and
rate-limit those, as, for debugging purposes, it is usually
interesting to know that IRQs are being received, but not
displaying every single one.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This is not used anywhere. So, let's trash it.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The code under load_primary_binaries() is complex and
were hard to understand, because it used to have lots
of ifdefs and broken identation.
The patch which cleaned it and removed the version-specific
ifdefs added a regression.
Solve it.
Fixes: 3c0538fbad ("media: atomisp: get rid of most checks for ISP2401 version")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The media bus formats to be used on serial busses are documented but there
was no reference from CSI-2 documentation. Add that now.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The IMX219 camera driver is not a clock provider, but merely a clock
consumer, and thus does not need to include <linux/clk-provider.h> and
<linux/clkdev.h>.
Signed-off-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>
OminiVision ov2740 is a 2 megapixels RAW RGB image sensor which can
deliver 1920x1080@60fps frames. This driver add the support of
vertical blanking, exposure, test pattern, digital and analog gain
control for sensor.
Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Shawn Tu <shawnx.tu@intel.com>
Signed-off-by: Qiu, Tianshu <tian.shu.qiu@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Query the sensor for its module revision, and compare it
to known revisions.
Currently 2A and 1B revision indentification is supported.
[Sakari Ailus: Wrap a line over 80, alignment, use %u for printing u32]
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add match table, enable ov8856_probe() to support
both ACPI and DT modes.
ACPI and DT modes are primarily distinguished from
by checking for ACPI mode and by having resource like
be NULL.
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This patch adds documentation of device tree in YAML schema for the
OV8856 CMOS image sensor.
Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Terratec Cinergy S2 PCIe Dual is a PCIe device with two tuners that
actually contains two USB devices. The devices are visible in the
lsusb printout.
Bus 004 Device 002: ID 153b:1182 TerraTec Electronic GmbH Cinergy S2 PCIe Dual Port 2
Bus 003 Device 002: ID 153b:1181 TerraTec Electronic GmbH Cinergy S2 PCIe Dual Port 1
The devices use the Montage M88DS3000/M88TS2022 demod/tuner.
Signed-off-by: Dirk Nehring <dnehring@gmx.net>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
reg property is not used in Rockchip MIPI DPHY RX0 bindings, thus remove
it.
Suggested-by: Johan Jonker <jbx6244@gmail.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Based on Yocto Aero's repository, the file name for the isp2401
is the same for the B0 release.
So, unify it at the driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When checking sh_css.c against the Yocto Aero's version, it can
be noticed that some isp2401 dependencies may have been taken
wrongly.
Change the code to work like the Yocto Aero, as this driver
was tested in the past with an ISP2401 device.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Depending on the ISP-specific HAS_NO_INPUT_FORMATTER macro,
some IRQs will be ignored by the driver. Yet, those keep
happening, as reported by this debug print:
[ 61.620746] atomisp-isp2 0000:00:03.0: atomisp_css_irq_enable: css irq info 0x00000004: disable.
Causing this warning:
[ 61.620749] atomisp-isp2 0000:00:03.0: atomisp_css_irq_enable:Invalid irq info.
Well, if this is a normal situation, just ignore it without
warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Calling acpi_bus_get_device() may end allocating resources that
aren't freed. So, add a notice about that, as, if those drivers
get out of staging, we may need some changes.
Fixes: 0d64e94205 ("media: atomisp: Add some ACPI detection info")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The memory management code for atomisp is complex: it has 2
extra pools (plus some ION-specific code).
The code for those extra pools are complex, and there are even
some parts of code over there that were forked from some
mm/ code, probably from Kernel 3.10.
Let's just use a single one, in order to make the driver
simpler.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Instead of trying to send multiple bytes at the same time,
just go one by one, like the upstream driver does.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There is an ov2680 driver mainstream. Use the read/write
routines from it, as the ones inside this driver are
generating some errors:
ov2680 i2c-OVTI2680:00: ov2680_i2c_write: i2c write reg=0x3086, value 0x00, error -121
Maybe the code that changes from/to BE are not right.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Change some code at ov2680 for it to better report what's
happening there at sensor's level.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The sensor should finish its init before atomisp driver, as
otherwise the atomisp driver won't be able to talk with it.
So, we need to turn atomisp_gmin_platform into a module
again, for it to not depend on atomisp driver to finish
probing, and add some delay at atomisp to let the sensor
driver to finish probing.
Yeah, this is hacky. The real solution here would be to use
the async framework, but for now, our goal is to make the
driver to work. So, let's postpone such change to be done
later.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The current code causes ISP2401 to power down and never return
back to live, causing the driver to crash.
Fix it by commenting out the bad code. It should be noticed that
the Yocto Aero code has something similar to it.
Maybe the issue is related to an ISP bug (or maybe PM is
controlled on a different way for this hardware).
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The value returned by BIOS is 1. Fix it at the driver,
as it won't read this from EFI.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Simplify the hmm_bo a little bit by removing this
macro. This will avoid printing twice errors when
allocations happen.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Those files seem to be firmware-dependent, probably being used
by some debug interface.
Well, their contents are not really used by atomisp, so let's
just send them to the trash can, as it shouldn't have any
usage upstream.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When changing the IFs to select isp2401 at runtime, one of
the conditions ended by being written wrong.
Code double-checked on both Yocto Aero's driver version and
against the previous code.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Use the version from intel_atomisp2_pm.c for power up/down,
removing some code duplication and using just one kAPI call
for modifying the ISPSSPM0 register.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Changing to pci_enable_device() didn't produce the expected
result. It could also eventually led to problems when driver
is removed, due to object lifetime issues. So, let's just
return to the previous behavior.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This patch required lots of research and work. The existing
atomisp driver at staging assumed that all Intel PMIC would
be using regulators, but upstream didn't follow it. Instead,
the intel_pmic.c driver added a hack, instead of using i2c_transfer,
it writes I2C values directly via regmapped registers.
Oh, well... At least, it provided a common API for doing that.
The PMIC settings used here came from the driver at the
yocto Aero distribution:
https://download.01.org/aero/deb/pool/main/l/linux-4.4.76-aero-1.3/
The logic itself was re-written, in order to use the I2C address
detected by the probing part.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The atomisp_gmin_platform.c is not a platform driver anymore,
but it is, instead, part of the atomisp driver.
Move it to be together with the driver. As a bonus, as the
atomisp i2c drivers depends on its contents, probing them
should load automatically the atomisp core. This should
likely avoid some possible race conditions.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Sub-device's power management can be provided via different ways.
Instead of hardcoding it, add a code that would be detecting it.
This uses a code similar to what's found at the atomisp driver
inside the Intel Aero repository:
https://github.com/intel-aero/meta-intel-aero.git
(driver was removed on some commit, but it can be found on
git history).
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Right now, the driver supports just one VCM and just one
flash device. Warn if more than one such devices were
probed.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This driver is really on bad shape. One of the problems
is that, as soon as the I2C transfers start to happen, it
timeouts detecting a camera:
ov2680 i2c-OVTI2680:00: ov2680_probe: ACPI detected it on bus ID=CAM1, HID=OVTI2680
atomisp-isp2 0000:00:03.0: no camera attached or fail to detect
ov2680 i2c-OVTI2680:00: gmin: initializing atomisp module subdev data using PMIC regulator
...
The right fix here would be to use defer probe, but driver is
still on too bad shape.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
While the current code is hardcoded to just one specific
type of PMIC, it can support several types. Those should
be board-dependent. Instead of just printing a number,
change the message to display what type of PMIC control
is used at runtime.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are several device-specific data that are obtained
either via DMI or EFI, with changes the driver's behavior.
Display what has been detected, as such info may help
identifying troubles at the driver.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When someone would report problems with a new device, we
need to know the DMI product ID and the ACPI name for the
detected sensor. So, print them at dmesg.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This driver still has lots of issues. Let's enable debug
there inconditionally, as we need more information in order
to address the pending issues.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This setting is used only for one of te Merryfield PCI IDs.
As this is an ISP2400, we can just get rid of a version
test, writing the right value directly inside the struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
