Move away from the deprecated API and return the shiny new ERRPTR where
useful.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Move away from the deprecated API.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Move away from the deprecated API and make use of the fact that
unregistering devices is NULL- and ERR_PTR-safe.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Fix spelling (s/Aramda/Armada/) in a log message and in a comment. While
at it, add a trailing '\n' in messages.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Jan Luebbe <jlu@pengutronix.de>
Link: https://lkml.kernel.org/r/20200413041556.3514-1-christophe.jaillet@wanadoo.fr
Refactor how S_FMT and TRY_FMT are handled, and also make sure
internal initial format and format reset are done properly.
The latter is achieved by making sure the same hantro_{set,try}_fmt
helpers are called on all paths that set the format (which is
part of the driver state).
This commit removes the following v4l2-compliance warnings:
test VIDIOC_G_FMT: OK
fail: v4l2-test-formats.cpp(711): Video Capture Multiplanar: TRY_FMT(G_FMT) != G_FMT
test VIDIOC_TRY_FMT: FAIL
fail: v4l2-test-formats.cpp(1116): Video Capture Multiplanar: S_FMT(G_FMT) != G_FMT
test VIDIOC_S_FMT: FAIL
Reported-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Move the extra bytes calculation that are needed for H264
motion vector to a helper. This is just a cosmetic cleanup.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Since now .buf_prepare takes care of setting the
buffer payload size, we can get rid of this,
at least for decoders.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Let the core sort out the nuances of returning buffers
to userspace, by using the v4l2_m2m_buf_done_and_job_finish
helper.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Buffers' zeroth plane payload size is calculated at format
negotiation time, and so it can be set in .buf_prepare.
Keep in mind that, to make this change easier, hantro_buf_prepare
is refactored, using the cedrus driver as reference. This results
in cleaner code as byproduct.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
When the request API is used, typically an OUTPUT (src) buffer
will be part of a request. A userspace process will be typically
blocked, waiting on the request file descriptor.
Returning the OUTPUT (src) buffer will wake-up such processes,
who will immediately attempt to dequeue the CAPTURE buffer,
only to find it's still unavailable.
Therefore, change v4l2_m2m_buf_done_and_job_finish returning
the CAPTURE (dst) buffer first, to avoid signalling the request
file descriptor prematurely, i.e. before the CAPTURE buffer is done.
When the request API is not used, this change should have
no impact.
Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This device is used on Lenovo V130-15IKB variants and uses
the same registers as U1.
Signed-off-by: Artem Borisov <dedsa2002@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The Logitech G11 keyboard is a cheap variant of the G15 without the LCD
screen. It uses the same layout for its extra and macro keys (G1 - G18,
M1-M3, MR) and - from the input subsystem's perspective - behaves just
like the G15, so we can treat it as such.
Tested it with my own keyboard.
Signed-off-by: Fabian Schindlatz <fabian.schindlatz@fau.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
samsung-golden has the same sharp,gp2ap002s00f proximity sensor
that is also used in samsung-skomer.
A driver was added for it in
commit 97d642e230 ("iio: light: Add a driver for Sharp GP2AP002x00F").
Now that it was merged we can add an entry for it in the device tree
for samsung-golden.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200405173252.67614-1-stephan@gerhold.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Changing from "depends on" to "select" may cause some
side-effects. This patch is not ready to be merged yet,
as it requires some adjustments.
So, let's revert it.
This reverts commit a3b91d8bd1.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
The new device tree for samsung-golden depends on some additional
drivers that are not selected in the u8500 defconfig yet:
- Bluetooth: hci_bcm
- WiFi: brcmfmac
- Touchscreen: atmel_mxt_ts
- Vibrator: gpio-vibra
- Sensors: inv_mpu6050 (IMU)
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20191219202052.19039-10-stephan@gerhold.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There are some uAPI stuff that are driver-specific. Add them
to the main media uAPI body.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Those documents don't really describe the driver API.
Instead, they contain development-specific information.
Yet, as the main index file describes the content of it as:
"how specific kernel subsystems work
from the point of view of a kernel developer"
It seems to be the better fit.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Most of the driver-specific documentation is meant to help
users of the media subsystem.
Move them to the admin-guide.
It should be noticed, however, that several of those files
are outdated and will require further work in order to make
them useful again.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
During RX, accessing the reo dest ring descriptor directly is consuming
a lot of CPU cycles. Accessing the descriptor after copying it locally
has improved CPU usage by around ~10-15% while measuring throughput
in RX DBTC test cases(all radios are involved in the throughput
measurement).
HW tested: IPQ8074
Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1586421797-885-1-git-send-email-mpubbise@codeaurora.org
Unlike CE interrupts, DP interrupts are not enabled/disabled at
source; they are enabled/disabled only at GIC level, therefore
it is required to set IRQ_DISABLE_UNLAZY flag to avoid spurious
interrupts.
Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1586421013-23025-1-git-send-email-mpubbise@codeaurora.org
This file gives a hint about how fourcc should be named.
It is on a very weird place, as such kind of thing belongs to the
uAPI guide.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
All those documents describe the media driver API. So, move
them to the right place within the Kernel documentation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add the mechanisms to distinguish notifications from delayed responses
and command responses. Also add support to properly fetch notification
messages upon reception. Notifications processing does not continue any
further after the fetch phase.
Link: https://lore.kernel.org/r/20200327143438.5382-5-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
[Reworked/renamed scmi_handle_xfer_delayed_resp()]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Since 2017, there is an space reserved for userspace API,
created by changeset 1d596dee38 ("docs: Create a user-space API guide").
As the media subsystem was one of the first subsystems to use
Sphinx, until this patch, we were keeping things on a separate
place.
Let's just use the new location, as having all uAPI altogether
will likely make things easier for developers.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Add common transport-layer methods to:
- fetch a notification instead of a response
- clear a pending notification
Add also all the needed support in mailbox/shmem transports.
Link: https://lore.kernel.org/r/20200327143438.5382-4-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add commands' enumerations and messages definitions for all existing
notify-enable commands across all protocols.
Link: https://lore.kernel.org/r/20200327143438.5382-3-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
With all the plumbing in place, let's just add the separate dedicated
receive buffers to handle notifications that can arrive asynchronously
from the platform firmware to OS.
Also add one check to see if the platform supports any receive channels
before allocating the receive buffers: since those buffers are optionally
supported though, the whole xfer initialization is also postponed to be
able to check for their existence in advance.
Link: https://lore.kernel.org/r/20200327143438.5382-2-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
[Changed parameters in __scmi_xfer_info_init()]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
If this header is include twice, it will generate loads of compile
time error with the following below error pattern. It was reported by
0day kbuild robot on a branch pushed with double inclusion by accident.
This is based on the similar change in linux/scmi_protocol.h
error: conflicting types for ‘...’
note: previous declaration of ‘...’ was here
error: redefinition of ‘...’
Add a header include guard just in case.
Link: https://lore.kernel.org/r/20200403171018.1230-2-sudeep.holla@arm.com
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
If this header is include twice, it will generate loads of compile
time error with the following below error pattern. It was reported by
0day kbuild robot on a branch pushed with double inclusion by accident.
error: conflicting types for ‘...’
note: previous declaration of ‘...’ was here
error: redefinition of ‘...’
Add a header include guard just in case.
Link: https://lore.kernel.org/r/20200403171018.1230-1-sudeep.holla@arm.com
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The scmi protocol core driver checks for the channel availability
before evaluating the shmem property. If the individual protocols
don't have separate channel assigned to them, the channel alloted
for the BASE protocol is reused automatically.
Therefore there is no need to check for the shmem property in the
parent node if it is absent in the child protocol node.
Link: https://lore.kernel.org/r/20200327163654.13389-5-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Instead of declaring the channel availabilty unconditionally, let us
check for the presence of "shmem" property and return the channel
availablity accordingly.
Link: https://lore.kernel.org/r/20200327163654.13389-4-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The scmi protocol core driver check for non NULL mark_txdone before
invoking the same. There is no need to provide a empty stub. SMC/HVC
calls are synchronous and the call return indicates the completion.
Link: https://lore.kernel.org/r/20200327163654.13389-3-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
In order to support multiple SMC/HVC transport channels with associated
shared memory, it is better to maintain the mutex per channel instead of
existing global one.
Move the smc_mutex into the scmi_smc structure and also rename it to
shmem_lock which is more appropriate for it's use.
Link: https://lore.kernel.org/r/20200327163654.13389-2-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Use the value of "arm,smc-id" property from the device tree as the first
argument for SMCCC call leaving all the other arguments as zero for now.
There is no Rx, only Tx because of smc/hvc not support Rx.
Link: https://lore.kernel.org/r/1583673879-20714-3-git-send-email-peng.fan@nxp.com
Signed-off-by: Peng Fan <peng.fan@nxp.com>
[sudeep.holla: reworded commit log/subject and fixed !HAVE_ARM_SMCCC build]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
SCMI could use SMC/HVC as tranports. Since there is no standardized
SMC/HVC function identifier for the same, we need to use vendor
specific id. Add the same into the devicetree binding document.
Also add arm,scmi-smc compatible string for smc/hvc transport
Link: https://lore.kernel.org/r/1583673879-20714-2-git-send-email-peng.fan@nxp.com
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
[sudeep.holla: reworded commit log and subject]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
substitute vfio_pin_pages() and vfio_unpin_pages() with
vfio_group_pin_pages() and vfio_group_unpin_pages(), so that
it will not go through looking up, checking, referencing,
dereferencing of VFIO group in each call.
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200313031151.8042-1-yan.y.zhao@intel.com
This file contains both driver develompent documentation and
userspace API.
Split on two, as they're usually read by different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
As a device model, it is better to read/write guest memory using vfio
interface, so that vfio is able to maintain dirty info of device IOVAs.
Cc: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Yan Zhao <yan.y.zhao@intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200313031109.7989-1-yan.y.zhao@intel.com
This file contains both driver develompent documentation and
userspace API.
Split on two, as they're usually read by different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This file contains both driver develompent documentation and
userspace API.
Split on two, as they're usually read by different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This file contains both driver develompent documentation and
userspace API.
Split on two, as they're usually read by different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This file contains both driver develompent documentation and
userspace API.
Split on two, as they're usually read by different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
There are two places inside this file that points to the
cx2341x documentation, with was split into two. Looking
at changeset dcc0ef8820
("V4L/DVB (10442): cx18: Fixes for enforcing when Encoder Raw VBI params can be set")
with added those comments, it was originally pointing to:
Documentation/video4linux/cx2341x/fw-encoder-api.txt
Well, the firmware details went to
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
This file contains both driver develompent documentation
(basically, firmware documentation) and IVTV-specific
documentation about VBI and raw formats, focused on uAPI
development.
Split on two, as they're usually read by different audiences.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
