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>
The atomisp probe error logic is incomplete. Add the missing
bits to return the PCI device to its original state.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As getting the exact version used by the driver is not easy,
let's relax the version detection and hope for the best,
producing just a warning.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
- Remove useless check if !dev at the probe function: if
such function is called, the device is defined.
- Cleanup the PCI ID table using macros.
- Use the same macros at the version-dependent part of the
atomisp_v4l2.c file;
- Add print messages to help understand what model the
driver detect;
- If device is not valid, better explain why.
Signed-off-by: Mauro Carvalho Chehehab <mchehab+huawei@kernel.org>
We need to preserve the "iio_evgen->irq_sim_domain" error code before
we free "iio_evgen" otherwise it leads to a use after free.
Fixes: 337cbeb2c1 ("genirq/irq_sim: Simplify the API")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Convert the Renesas Clock Pulse Generator (CPG) Module Stop (MSTP)
Clocks Device Tree binding documentation to json-schema.
Drop R-Car Gen2 compatible values, which were obsoleted by the unified
"Renesas Clock Pulse Generator / Module Standby and Software Reset" DT
bindings.
Replace the obsolete example for R-Car H2 by an example that is still
valid.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20200508100321.6720-1-geert+renesas@glider.be
Expose MIPI DisCo Slave properties in sysfs.
For Slave properties and Data Port 0, the attributes are managed with
simple devm_ support.
A Slave Device may have more than one Data Port (DPN), and each Data
Port can be sink or source. The attributes are created dynamically
using pre-canned macros, but still use devm_ with a name attribute
group to avoid creating kobjects - as requested by GregKH. In the
_show function, we use container_of() to retrieve port number and
direction required to extract the information.
Audio modes are not supported for now. Depending on the discussions
the SoundWire Device Class, we may add it later as is or follow the
new specification.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20200518203551.2053-4-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Quoth the man page:
```
If the tracee was restarted by PTRACE_SYSCALL or PTRACE_SYSEMU, the
tracee enters syscall-enter-stop just prior to entering any system
call (which will not be executed if the restart was using
PTRACE_SYSEMU, regardless of any change made to registers at this
point or how the tracee is restarted after this stop).
```
The parenthetical comment is currently true on x86 and powerpc,
but not currently true on arm64. arm64 re-checks the _TIF_SYSCALL_EMU
flag after the syscall entry ptrace stop. However, at this point,
it reflects which method was used to re-start the syscall
at the entry stop, rather than the method that was used to reach it.
Fix that by recording the original flag before performing the ptrace
stop, bringing the behavior in line with documentation and x86/powerpc.
Fixes: f086f67485 ("arm64: ptrace: add support for syscall emulation")
Cc: <stable@vger.kernel.org> # 5.3.x-
Signed-off-by: Keno Fischer <keno@juliacomputing.com>
Acked-by: Will Deacon <will@kernel.org>
Tested-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Bin Lu <Bin.Lu@arm.com>
[catalin.marinas@arm.com: moved 'flags' bit masking]
[catalin.marinas@arm.com: changed 'flags' type to unsigned long]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The mmsys driver supports only MT8173 device for now, but like other system
controllers is an important piece for other Mediatek devices. Actually
it depends on the mt8173 clock specific driver but that dependency is
not real as it can build without the clock driver. Instead of depends on
a specific model, make the driver depends on the generic ARCH_MEDIATEK and
enable by default so other Mediatek devices can start using it without
flood the Kconfig.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Tested-by: Hsin-Yi Wang <hsinyi@chromium.org>
Link: https://lore.kernel.org/r/20200401201736.2980433-1-enric.balletbo@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
changeset d5426f4c2e ("media: staging: atomisp: use clock framework for camera clocks")
removed a platform-specific code to set the clock rate, in favor of
using the Kernel clock framework.
However, instead of passing the frequency for clk_set_rate(),
it is passing either 0 or 1.
Looking at the original patchset, it seems that there are two
possible configurations for the ISP:
0 - it will use a 25 MHz XTAL to provide the clock;
1 - it will use a PLL with is set to 19.2 MHz
(only for the CHT version?)
Eventually, different XTALs and/or PLL frequencies might
be possible some day, so, re-implent the logic for it to be
more generic.
Fixes: d5426f4c2e ("media: staging: atomisp: use clock framework for camera clocks")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The printed message when a firmware version is wrong says nothing
usefull:
atomisp-isp2 0000:00:03.0: Fw version check failed.
atomisp-isp2: probe of 0000:00:03.0 failed with error -22
Print the expected and the received firmware version instead.
In order to do that, the firmware functions will need at least
a struct device pointer, so pass it.
While writing this patch, it was noticed that some of the
abstraction layers of this driver have functions that are never
called, but use this interface. Get rid of them.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As the atomisp driver should already be handling the ISP
PCI ID, there's no sense on keeping the dummy driver enabled
in tis case.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
With the changes, this function is now undefined if built
for ISP2400. So, move its implementation to the file which
calls it.
Reported-by: Francescodario Cuzzocrea <francescodario.cuzzocrea@mail.polimi.it>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Some recent changes at V4L2 core changed the way querycap is handled.
Due to that, this warning is generated:
WARNING: CPU: 1 PID: 503 at drivers/media/v4l2-core/v4l2-dev.c:885 __video_register_device+0x93e/0x1120 [videodev]
as introduced by this commit:
commit 3c1350501c
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date: Tue Jul 23 04:21:25 2019 -0400
media: v4l2-dev/ioctl: require non-zero device_caps, verify sane querycap results
Now that all V4L2 drivers set device_caps in struct video_device, we can add
a check for this to ensure all future drivers fill this in.
The fix is simple: we just need to initialize dev_caps before
registering the V4L2 dev.
While here, solve other problems at VIDIOC_QUERYCAP ioctl.
Reported-by: Patrik Gfeller <patrik.gfeller@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are currently two identical copies of some files, one
at css_2401_csi2p_system/ and another one at css_2401_system/.
Get rid of one of them, moving the remaining files to the
directory with the shortest name.
While here, do more renames, in order to get smaller path
names.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The Asus Transformer T101HA comes with a newer hardware
version. Add support to load firmware for it.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are lots of places inside this driver checking for
ISP2400/ISP2401 verison. Get rid of most of those, while
keep building for both.
Most of stuff in this patch is trivial to solve.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Now that everything needed to build for ISP2401 is solved,
we can setup atomisp to build either for ISP2400 or ISP2401.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
With the current way, it will produce lots of errors because
the public header contains wrong definitions and the private
one has functions defined at the wrong order.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Probably due to some version conflicts while the atomisp code
were generated, some things don't build for ISP2401. So, use
the ISP2400 variant when available, or get rid of the
code that doesn't build.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This driver has very long directories without a good
reason (IMHO). Let's drop two directories from such hierarchy,
in order to simplify things a little bit and make the dir
output a bit more readable.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
