Add support for the SM8650 platform by re-using the SM8550
definitions and using the vpu33 ops.
Move the Sm8650 reset tables that differs in a per-SoC platform
header, that will contain mode SoC specific data when
more codecs are introduced.
The SM8650/vpu33 requires more reset lines, but the H.264
decoder capabilities are identical.
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # x1e Dell
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
The IRIS acceleration found in the SM8650 platforms uses the vpu33
hardware version, and requires a slighly different reset and power off
sequences in order to properly get out of runtime suspend.
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # x1e Dell
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Introduce an optional controller_rst_tbl use to store reset lines
used to reset part of the controller.
This is necessary for the vpu3 support, when the xo reset line
must be asserted separately from the other reset line
on power off operation.
Factor the iris_init_resets() logic to allow requesting
multiple reset tables.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # x1e Dell
Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
There are two ways to switch GDSC mode. One is to write the POWER_CONTROL
register and the other is to use dev_pm_genpd_set_hwmode(). However, they
rely on different clock driver flags. dev_pm_genpd_set_hwmode() depends on
the HW_CTRL_TRIGGER flag and POWER_CONTROL register depends on the HW_CTRL
flag.
By default, the dev_pm_genpd_set_hwmode() is used to switch the GDSC mode.
If it fails and dev_pm_genpd_set_hwmode() returns -EOPNOTSUPP, it means
that the clock driver uses the HW_CTRL flag. At this time, the GDSC mode
is switched to write the POWER_CONTROL register.
Clock driver is using HW_CTRL_TRIGGER flag with V6. So hwmode_dev is
always true on using V6 platform. Conversely, if hwmode_dev is false, this
platform must be not using V6. Therefore, replace IS_V6 in poweroff_coreid
with hwmode_dev. Also, with HW_CTRL_TRIGGER flag, the vcodec gdsc gets
enabled in SW mode by default. Therefore, before disabling the GDSC, GDSC
should be switched to SW mode so that GDSC gets enabled in SW mode in the
next enable.
Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
[bod: added media prefix]
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
For the seek case, the input port will be called stream_off and then
stream_on in the driver. Firmware will flush all buffers during stream_off
input port. Therefore, driver needs to queue DPB buffers to firmware
during stream_on input port to ensure that decoder can decode normally
when it receives enough input and output buffers. Otherwise, decoder
will not be able to decode due to lack of DPB buffer even if there are
enough input and output buffers.
Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
[bod: added media prefix]
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Video device registering has been moved earlier in the probe function,
but the new order has not been propagated to error handling. This means
we can end with unreleased resources on error (e.g dangling video device
on missing firmware probe aborting).
Fixes: 08b1cf474b ("media: venus: core, venc, vdec: Fix probe dependency error")
Cc: stable@vger.kernel.org
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
For various SoC skews at 4nm CSIPHY 2.1.2 is used. Add in the init sequence
with base control reg offset of 0x1000.
This initial version will support X1E80100. Take the silicon verification
PHY init parameters as a first/best guess pass.
SKEW_CAL is included as received from the qcom silicon init sequence.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Currently we have an s32 value called delay which has been inherited from
the CamX code for PHY init. This unused value relates to a post-write delay
latching time.
In the silicon test-bench which provides the basis for the CamX code the
write settle times are specified in nanoseconds.
In the upstream kernel we currently take no notice of the delay value and
use all zero in any case.
Nanosecond granularity timing from the perspective of the kernel is total
overkill, however for some PHY init sequences introduction of a settle
delay has a use.
Add support to the 3ph init sequence for microsecond level delay. A
readback of written data would probably accomplish the same thing but,
since the PHY init sequences in the wild provide a delay value - we can
just add support here for that delay and consume the values given.
Generally these delays are probably not necessary but, they do speak to a
theoretical delay that silicon test-benches utilise and therefore are
worthwhile to replicate if the given PHY init sequence has the data.
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Add silicon enabling support for VFE680 as found on sm8450, x1e and
derivatives thereof.
References work from Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
[bod: fix minor checkpatch linelenght splat @ lines 21, 22]
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Use the CSIPHY id property to find clock names instead of relying on
generating the clock names based on the control-loop index.
x1e80100 has CSIPHY0, CSIPHY1, CSIPHY2 and CSIPHY4 so simple index naming
won't work whereas and 'id' property allows any ordering and any stepping
between the CSIPHY names.
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
In various places in CAMSS we assume a linear set of declared devices
{csiphy0, csiphy1, csiphy2} which currently works for upstream SoCs but for
upcoming SoCs some of the SoC resources will result in a set such as
{csiphy0, csiphy2} which will break the naive for() loops we have.
Introduce an identity property which resource declarations can populate
hence facilitating non-linear resource naming.
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
A recent commit refactored the printing of the VFE hardware version, but
(without it being mentioned) also changed the log level from debug to
info.
This results in several hundred lines of repeated log spam during boot
and use, for example, on the Lenovo ThinkPad X13s:
qcom-camss ac5a000.camss: VFE:1 HW Version = 1.2.2
qcom-camss ac5a000.camss: VFE:0 HW Version = 1.2.2
qcom-camss ac5a000.camss: VFE:2 HW Version = 1.2.2
qcom-camss ac5a000.camss: VFE:2 HW Version = 1.2.2
qcom-camss ac5a000.camss: VFE:3 HW Version = 1.2.2
qcom-camss ac5a000.camss: VFE:5 HW Version = 1.3.0
qcom-camss ac5a000.camss: VFE:6 HW Version = 1.3.0
qcom-camss ac5a000.camss: VFE:4 HW Version = 1.3.0
qcom-camss ac5a000.camss: VFE:5 HW Version = 1.3.0
qcom-camss ac5a000.camss: VFE:6 HW Version = 1.3.0
qcom-camss ac5a000.camss: VFE:7 HW Version = 1.3.0
qcom-camss ac5a000.camss: VFE:7 HW Version = 1.3.0
qcom-camss ac5a000.camss: VFE:7 HW Version = 1.3.0
...
Suppress the version logging by demoting to debug level again.
Fixes: 10693fed12 ("media: qcom: camss: vfe: Move common code into vfe core")
Cc: stable@vger.kernel.org
Cc: Depeng Shao <quic_depengs@quicinc.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
A recent commit refactored the printing of the CSID hardware version, but
(without it being mentioned) also changed the log level from debug to
info.
This results in repeated log spam during use, for example, on the Lenovo
ThinkPad X13s:
qcom-camss ac5a000.camss: CSID:0 HW Version = 1.0.0
qcom-camss ac5a000.camss: CSID:0 HW Version = 1.0.0
qcom-camss ac5a000.camss: CSID:0 HW Version = 1.0.0
qcom-camss ac5a000.camss: CSID:0 HW Version = 1.0.0
qcom-camss ac5a000.camss: CSID:0 HW Version = 1.0.0
Suppress the version logging by demoting to debug level again.
Fixes: f759b8fd30 ("media: qcom: camss: csid: Move common code into csid core")
Cc: stable@vger.kernel.org
Cc: Depeng Shao <quic_depengs@quicinc.com>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Depending on IOMMU_DMA is suspicious, since the low-level DMA ops
internals and MSI helpers is provides are not of interest to general
drivers. In practice it mostly seems to be serving as a dependency on
ARM64 here, so do that properly. The venus driver looks like it won't
actually be useful at runtime without the IOMMU API, so add that too.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
sfr->buf_size is in shared memory and can be modified by malicious user.
OOB write is possible when the size is made higher than actual sfr data
buffer. Cap the size to allocated size for such cases.
Cc: stable@vger.kernel.org
Fixes: d96d3f30c0 ("[media] media: venus: hfi: add Venus HFI files")
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
qsize represents size of shared queued between driver and video
firmware. Firmware can modify this value to an invalid large value. In
such situation, empty_space will be bigger than the space actually
available. Since new_wr_idx is not checked, so the following code will
result in an OOB write.
...
qsize = qhdr->q_size
if (wr_idx >= rd_idx)
empty_space = qsize - (wr_idx - rd_idx)
....
if (new_wr_idx < qsize) {
memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while
reading and writing packets into the queue.
Cc: stable@vger.kernel.org
Fixes: d96d3f30c0 ("[media] media: venus: hfi: add Venus HFI files")
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
words_count denotes the number of words in total payload, while data
points to payload of various property within it. When words_count
reaches last word, data can access memory beyond the total payload. This
can lead to OOB access. With this patch, the utility api for handling
individual properties now returns the size of data consumed. Accordingly
remaining bytes are calculated before parsing the payload, thereby
eliminates the OOB access possibilities.
Cc: stable@vger.kernel.org
Fixes: 1a73374a04 ("media: venus: hfi_parser: add common capability parser")
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
There is a possibility that init_codecs is invoked multiple times during
manipulated payload from video firmware. In such case, if codecs_count
can get incremented to value more than MAX_CODEC_NUM, there can be OOB
access. Reset the count so that it always starts from beginning.
Cc: stable@vger.kernel.org
Fixes: 1a73374a04 ("media: venus: hfi_parser: add common capability parser")
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Build-testing on x86 showed two modules with conflicting "iris.ko"
names after the addition of the qualcomm driver:
error: the following would cause module name conflict:
arch/x86/platform/iris/iris.ko
drivers/media/platform/qcom/iris/iris.ko
Since this a new module, nothing should rely on the name yet, so
rename this one to a more specific "qcom-iris.ko".
Fixes: 38506cb7e8 ("media: iris: add platform driver for iris video device")
Cc: Shérab <Sebastien.Hinderer@ens-lyon.org> # for x86 iris
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
handle the V4L2_DEC_CMD_STOP by initiating a drain sequence on the
firmware. Process and decode all OUTPUT buffers, that are queued by the
client, before the VIDIOC_DECODER_CMD() was issued and mark the last
buffer with the V4L2_BUF_FLAG_LAST flag. The decoder is stopped, after
processing the last buffer.
Resume the decoder when one of these operations are issued by the client:
- V4L2_DEC_CMD_START
- pair of VIDIOC_STREAMOFF() and VIDIOC_STREAMON() on the CAPTURE queue
- pair of VIDIOC_STREAMOFF() and VIDIOC_STREAMON() on the OUTPUT queue
Add the handling to resume decoding when client issues
V4L2_DEC_CMD_START to resume decoding after a source change is detected.
Tested-by: Stefan Schmidt <stefan.schmidt@linaro.org> # x1e80100 (Dell XPS 13 9345)
Reviewed-by: Stefan Schmidt <stefan.schmidt@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-HDK
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Handle the response sent by the firmware, when a source change is
detected. Read the subscribed parameter to get the changed values. Raise
the source change event to the client and update the instance sub-state.
Mark the last buffer from before the source change with the
V4L2_BUF_FLAG_LAST flag and return to the client.
Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
Tested-by: Stefan Schmidt <stefan.schmidt@linaro.org> # x1e80100 (Dell XPS 13 9345)
Reviewed-by: Stefan Schmidt <stefan.schmidt@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-HDK
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Implement the vb2 ops for the buf queue. These are the different buffer
attributes:
BUF_ATTR_DEFERRED - buffer queued by the client but not submitted to
firmware.
BUF_ATTR_PENDING_RELEASE - buffers requested to be released from
the firmware.
BUF_ATTR_QUEUED - buffers submitted to the firmware.
BUF_ATTR_DEQUEUED - buffers received from the firmware.
BUF_ATTR_BUFFER_DONE - buffers sent back to vb2.
Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
Tested-by: Stefan Schmidt <stefan.schmidt@linaro.org> # x1e80100 (Dell XPS 13 9345)
Reviewed-by: Stefan Schmidt <stefan.schmidt@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-HDK
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
During the stream on operation, send HFI_CMD_START on the capture and
output planes to start processing on the respective planes.
During the stream off operation, send HFI_CMD_STOP to the firmware,
which is a synchronous command. After the response is received by the
firmware, the session is closed on the firmware.
Introduce different states for the instance and state transitions.
IRIS_INST_INIT - video instance is opened.
IRIS_INST_INPUT_STREAMING - stream on is completed on output plane.
IRIS_INST_OUTPUT_STREAMING - stream on is completed on capture plane.
IRIS_INST_STREAMING - stream on is completed on both output and capture
planes.
IRIS_INST_DEINIT - video instance is closed.
IRIS_INST_ERROR - error state.
|
v
-------------
+---------| INIT |--------- +
| ------------- |
| ^ ^ |
| / \ |
| / \ |
| v v |
| ----------- ----------- |
| | INPUT OUTPUT | |
|---| STREAMING STREAMING |---|
| ----------- ----------- |
| ^ ^ |
| \ / |
| \ / |
| v v |
| ------------- |
|--------| STREAMING |-----------|
| ------------- |
| | |
| | |
| v |
| ----------- |
+-------->| DEINIT |<----------+
| ----------- |
| | |
| | |
| v |
| ---------- |
+-------->| ERROR |<-----------+
----------.
Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
Tested-by: Stefan Schmidt <stefan.schmidt@linaro.org> # x1e80100 (Dell XPS 13 9345)
Reviewed-by: Stefan Schmidt <stefan.schmidt@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-HDK
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Initialize the control handler by reading the platform specific firmware
capabilities. Capabilities are features, which are supported by a
specific platform (SOC). Each capability is defined with a min, max,
range and default value and a corresponding HFI. Implement s_ctrl and
g_volatile_ctrl ctrl ops.
Co-developed-by: Vedang Nagar <quic_vnagar@quicinc.com>
Signed-off-by: Vedang Nagar <quic_vnagar@quicinc.com>
Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
Tested-by: Stefan Schmidt <stefan.schmidt@linaro.org> # x1e80100 (Dell XPS 13 9345)
Reviewed-by: Stefan Schmidt <stefan.schmidt@linaro.org>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-HDK
Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
