Commit Graph

932793 Commits

Author SHA1 Message Date
Chuck Lever
eefc536dbd SUNRPC: rpc_call_null_helper() already sets RPC_TASK_NULLCREDS
Clean up.

Commit a52458b48a ("NFS/NFSD/SUNRPC: replace generic creds with
'struct cred'.") made rpc_call_null_helper() set RPC_TASK_NULLCREDS
unconditionally. Therefore there's no need for
rpc_call_null_helper()'s call sites to set RPC_TASK_NULLCREDS.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2020-06-11 13:33:48 -04:00
Chuck Lever
42aad0d7f9 SUNRPC: trace RPC client lifetime events
The "create" tracepoint records parts of the rpc_create arguments,
and the shutdown tracepoint records when the rpc_clnt is about to
signal pending tasks and destroy auths.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2020-06-11 13:33:48 -04:00
Chuck Lever
911813d7a1 SUNRPC: Trace transport lifetime events
Refactor: Hoist create/destroy/disconnect tracepoints out of
xprtrdma and into the generic RPC client. Some benefits include:

- Enable tracing of xprt lifetime events for the socket transport
  types

- Expose the different types of disconnect to help run down
  issues with lingering connections

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2020-06-11 13:33:48 -04:00
Chuck Lever
c509f15a58 SUNRPC: Split the xdr_buf event class
To help tie the recorded xdr_buf to a particular RPC transaction,
the client side version of this class should display task ID
information and the server side one should show the request's XID.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2020-06-11 13:33:48 -04:00
Chuck Lever
0125ecbb52 SUNRPC: Add tracepoint to rpc_call_rpcerror()
Add a tracepoint in another common exit point for failing RPCs.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2020-06-11 13:33:48 -04:00
Chuck Lever
82909dc546 SUNRPC: Update the RPC_SHOW_SOCKET() macro
Clean up: remove unnecessary commas, and fix a white-space nit.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2020-06-11 13:33:48 -04:00
Chuck Lever
7a34c8e0c3 SUNRPC: Update the rpc_show_task_flags() macro
Recent additions to the RPC_TASK flags neglected to update
the tracepoint ENUM definitions.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2020-06-11 13:33:47 -04:00
Chuck Lever
74fb8fecee SUNRPC: Trace GSS context lifetimes
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2020-06-11 13:33:47 -04:00
Chuck Lever
53bc19f17f SUNRPC: receive buffer size estimation values almost never change
Avoid unnecessary cache sloshing by placing the buffer size
estimation update logic behind an atomic bit flag.

The size of GSS information included in each wrapped Reply does
not change during the lifetime of a GSS context. Therefore, the
au_rslack and au_ralign fields need to be updated only once after
establishing a fresh GSS credential.

Thus a slack size update must occur after a cred is created,
duplicated, renewed, or expires. I'm not sure I have this exactly
right. A trace point is introduced to track updates to these
variables to enable troubleshooting the problem if I missed a spot.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
2020-06-11 13:33:47 -04:00
Linus Torvalds
c742b63473 Highlights:
- Keep nfsd clients from unnecessarily breaking their own delegations:
   Note this requires a small kthreadd addition, discussed at:
   https://lore.kernel.org/r/1588348912-24781-1-git-send-email-bfields@redhat.com
   The result is Tejun Heo's suggestion, and he was OK with this going
   through my tree.
 - Patch nfsd/clients/ to display filenames, and to fix byte-order when
   displaying stateid's.
 - fix a module loading/unloading bug, from Neil Brown.
 - A big series from Chuck Lever with RPC/RDMA and tracing improvements,
   and lay some groundwork for RPC-over-TLS.
 
 Note Stephen Rothwell spotted two conflicts in linux-next.  Both should
 be straightforward:
 	include/trace/events/sunrpc.h
 		https://lore.kernel.org/r/20200529105917.50dfc40f@canb.auug.org.au
 	net/sunrpc/svcsock.c
 		https://lore.kernel.org/r/20200529131955.26c421db@canb.auug.org.au
 -----BEGIN PGP SIGNATURE-----
 
 iQJJBAABCAAzFiEEYtFWavXG9hZotryuJ5vNeUKO4b4FAl7iRYwVHGJmaWVsZHNA
 ZmllbGRzZXMub3JnAAoJECebzXlCjuG+yx8QALIfyz/ziPgjGBnNJGCW8BjWHz7+
 rGI+1SP2EUpgJ0fGJc9MpGyYTa5T3pTgsENnIRtegyZDISg2OQ5GfifpkTz4U7vg
 QbWRihs/W9EhltVYhKvtLASAuSAJ8ETbDfLXVb2ncY7iO6JNvb22xwsgKZILmzm1
 uG4qSszmBZzpMUUy51kKJYJZ3ysP+v14qOnyOXEoeEMuJYNK9FkQ9bSPZ6wTJNOn
 hvZBMbU7LzRyVIvp358mFHY+vwq5qBNkJfVrZBkURGn4OxWPbWDXzqOi0Zs1oBjA
 L+QODIbTLGkopu/rD0r1b872PDtket7p5zsD8MreeI1vJOlt3xwqdCGlicIeNATI
 b0RG7sqh+pNv0mvwLxSNTf3rO0EKW6tUySqCnQZUAXFGRH0nYM2TWze4HUr2zfWT
 EgRMwxHY/AZUStZBuCIHPJ6inWnKuxSUELMf2a9JHO1BJc/yClRgmwJGdthVwb9u
 GP6F3/maFu+9YOO6iROMsqtxDA+q5vch5IBzevNOOBDEQDKqENmogR/knl9DmAhF
 sr+FOa3O0u6S4tgXw/TU97JS/h1L2Hu6QVEwU2iVzWtlUUOFVMZQODJTB6Lts4Ka
 gKzYXWvCHN+LyETsN6q7uHFg9mtO7xO5vrrIgo72SuVCscDw/8iHkoOOFLief+GE
 O0fR0IYjW8U1Rkn2
 =YEf0
 -----END PGP SIGNATURE-----

Merge tag 'nfsd-5.8' of git://linux-nfs.org/~bfields/linux

Pull nfsd updates from Bruce Fields:
 "Highlights:

   - Keep nfsd clients from unnecessarily breaking their own
     delegations.

     Note this requires a small kthreadd addition. The result is Tejun
     Heo's suggestion (see link), and he was OK with this going through
     my tree.

   - Patch nfsd/clients/ to display filenames, and to fix byte-order
     when displaying stateid's.

   - fix a module loading/unloading bug, from Neil Brown.

   - A big series from Chuck Lever with RPC/RDMA and tracing
     improvements, and lay some groundwork for RPC-over-TLS"

Link: https://lore.kernel.org/r/1588348912-24781-1-git-send-email-bfields@redhat.com

* tag 'nfsd-5.8' of git://linux-nfs.org/~bfields/linux: (49 commits)
  sunrpc: use kmemdup_nul() in gssp_stringify()
  nfsd: safer handling of corrupted c_type
  nfsd4: make drc_slab global, not per-net
  SUNRPC: Remove unreachable error condition in rpcb_getport_async()
  nfsd: Fix svc_xprt refcnt leak when setup callback client failed
  sunrpc: clean up properly in gss_mech_unregister()
  sunrpc: svcauth_gss_register_pseudoflavor must reject duplicate registrations.
  sunrpc: check that domain table is empty at module unload.
  NFSD: Fix improperly-formatted Doxygen comments
  NFSD: Squash an annoying compiler warning
  SUNRPC: Clean up request deferral tracepoints
  NFSD: Add tracepoints for monitoring NFSD callbacks
  NFSD: Add tracepoints to the NFSD state management code
  NFSD: Add tracepoints to NFSD's duplicate reply cache
  SUNRPC: svc_show_status() macro should have enum definitions
  SUNRPC: Restructure svc_udp_recvfrom()
  SUNRPC: Refactor svc_recvfrom()
  SUNRPC: Clean up svc_release_skb() functions
  SUNRPC: Refactor recvfrom path dealing with incomplete TCP receives
  SUNRPC: Replace dprintk() call sites in TCP receive path
  ...
2020-06-11 10:33:13 -07:00
Jonas Karlman
2630e1bb09 media: rkvdec: Fix H264 scaling list order
The Rockchip Video Decoder driver is expecting that the values in a
scaling list are in zig-zag order and applies the inverse scanning process
to get the values in matrix order.

Commit 0b0393d59e ("media: uapi: h264: clarify expected
scaling_list_4x4/8x8 order") clarified that the values in the scaling list
should already be in matrix order.

Fix this by removing the reordering and change to use two memcpy.

Fixes: cd33c83044 ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Ezequiel Garcia <ezequiel@collabora.com>
[hverkuil-cisco@xs4all.nl: rkvdec_scaling_matrix -> rkvdec_h264_scaling_list]
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:21:38 +02:00
Jonas Karlman
88441917dc media: v4l2-ctrls: Unset correct HEVC loop filter flag
Wrong loop filter flag is unset when tiles enabled flag is not set,
this cause HEVC decoding issues with Rockchip Video Decoder.

Fix this by unsetting the loop filter across tiles enabled flag instead of
the pps loop filter across slices enabled flag when tiles are disabled.

Fixes: 256fa39208 ("media: v4l: Add definitions for HEVC stateless decoding")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:21:14 +02:00
Tomi Valkeinen
0d96687213 media: videobuf2-dma-contig: fix bad kfree in vb2_dma_contig_clear_max_seg_size
Commit 9495b7e92f ("driver core: platform:
Initialize dma_parms for platform devices") in v5.7-rc5 causes
vb2_dma_contig_clear_max_seg_size() to kfree memory that was not
allocated by vb2_dma_contig_set_max_seg_size().

The assumption in vb2_dma_contig_set_max_seg_size() seems to be that
dev->dma_parms is always NULL when the driver is probed, and the case
where dev->dma_parms has bee initialized by someone else than the driver
(by calling vb2_dma_contig_set_max_seg_size) will cause a failure.

All the current users of these functions are platform devices, which now
always have dma_parms set by the driver core. To fix the issue for v5.7,
make vb2_dma_contig_set_max_seg_size() return an error if dma_parms is
NULL to be on the safe side, and remove the kfree code from
vb2_dma_contig_clear_max_seg_size().

For v5.8 we should remove the two functions and move the
dma_set_max_seg_size() calls into the drivers.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Fixes: 9495b7e92f ("driver core: platform: Initialize dma_parms for platform devices")
Cc: stable@vger.kernel.org
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:20:55 +02:00
Michael Rodin
5be5f41dd7 media: v4l2-subdev.rst: correct information about v4l2 events
Remove description of non-existing v4l2_subdev.nevents and replace the
undefined flag V4L2_SUBDEV_USES_EVENTS by the correct flag
V4L2_SUBDEV_FL_HAS_EVENTS, which is already documented in v4l2_subdev.flags

Fixes: commit 02adb1cc76 ("[media] v4l: subdev: Events support")
Signed-off-by: Michael Rodin <mrodin@de.adit-jv.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:20:26 +02:00
Marek Szyprowski
cc8c0363dd media: s5p-mfc: Properly handle dma_parms for the allocated devices
Commit 9495b7e92f ("driver core: platform: Initialize dma_parms for
platform devices") in v5.7-rc5 added allocation of dma_parms structure to
all platform devices. Then vb2_dma_contig_set_max_seg_size() have been
changed not to allocate dma_parms structure and rely on the one allocated
by the device core. Lets allocate the needed structure also for the
devices created for the 2 MFC device memory ports.

Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Fixes: 9495b7e92f ("driver core: platform: Initialize dma_parms for platform devices")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:20:09 +02:00
Geert Uytterhoeven
15168b2046 media: medium: cec: Make MEDIA_CEC_SUPPORT default to n if !MEDIA_SUPPORT
Recently, MEDIA_CEC_SUPPORT became indepedent of MEDIA_SUPPORT.
However, if MEDIA_SUPPORT is not enabled, MEDIA_SUPPORT_FILTER is not
defined, and MEDIA_CEC_SUPPORT is thus enabled by default, which is not
desirable.

Fix this by adding a dependency on MEDIA_CEC_SUPPORT to the default
configuration.

Fixes: 46d2a3b964 ("media: place CEC menu before MEDIA_SUPPORT")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:19:50 +02:00
Jernej Skrabec
d5aecd289b media: cedrus: Implement runtime PM
This allows the VE clocks and PLL_VE to be disabled most of the time.
A runtime PM reference is held while streaming.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-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>
2020-06-11 19:19:27 +02:00
Samuel Holland
a8876c22ea media: cedrus: Program output format during each run
Previously, the output format was programmed as part of the ioctl()
handler. However, this has two problems:

  1) If there are multiple active streams with different output
     formats, the hardware will use whichever format was set last
     for both streams. Similarly, an ioctl() done in an inactive
     context will wrongly affect other active contexts.
  2) The registers are written while the device is not actively
     streaming. To enable runtime PM tied to the streaming state,
     all hardware access needs to be moved inside cedrus_device_run().

The call to cedrus_dst_format_set() is now placed just before the
codec-specific callback that programs the hardware.

Cc: <stable@vger.kernel.org>
Fixes: 50e761516f ("media: platform: Add Cedrus VPU decoder driver")
Suggested-by: Jernej Skrabec <jernej.skrabec@siol.net>
Suggested-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Tested-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-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>
2020-06-11 19:18:37 +02:00
Mauro Carvalho Chehab
f4f90edf90 media: atomisp: improve ACPI/DMI detection logs
As there are several ways where the driver could possible
retrieve sensor data, make the prints clearer about what
was detected and from where.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:17:40 +02:00
Mauro Carvalho Chehab
c25ad350f1 media: Revert "media: atomisp: add Asus Transform T101HA ACPI vars"
Now that the EFI _DSM table is parsed by the driver, we don't
need a DMI match anymore for Asus Transform T101HA.

This reverts commit 0a76fd8e8d.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:16:50 +02:00
Mauro Carvalho Chehab
fc9bfbc67f media: Revert "media: atomisp: Add some ACPI detection info"
This reverts commit 0d64e94205.

As gmin_subdev_add() now takes the ACPI handle directly,
we can deprecate the code that were doing this inside each
I2C driver.

PS.: This also reverts commit c03496b3bd ("media: atomisp: add a notice about possible leak resources")

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:16:34 +02:00
Mauro Carvalho Chehab
387041cda4 media: atomisp: improve sensor detection code to use _DSM table
Instead of keep hardcoding device-specific tables, read them
directly from the ACPI BIOS, if available.

This method is know to work with Asus T101HA device. the
same table is also visible on EzPad devices. So, it seems
that at least some BIOSes use this method to pass data about
ISP2401-connected sensors.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:16:16 +02:00
Mauro Carvalho Chehab
69a03e36c7 media: atomisp: get rid of an iomem abstraction layer
The hive_isp_css_custom_host_hrt.h code, together
with atomisp_helper.h, provides an abstraction layer for
some functions inside atomisp_compat_css20.c and atomisp_cmd.c.

There's no good reason for that. In a matter of fact, after
removing the abstraction, the code looked a lot cleaner
and easier to understand.

So, get rid of them.

While here, get rid also of the udelay(1) abstraction code.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:15:51 +02:00
Mauro Carvalho Chehab
662fb4fceb media: atomisp: get rid of a string_support.h abstraction layer
Some parts of the driver have their own implementation of
memcpy() & friends. Replace all of them by strscpy().

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:13:32 +02:00
Mauro Carvalho Chehab
48b532b9d2 media: atomisp: use strscpy() instead of less secure variants
Replace usages of strcpy(), strlcpy() and strncpy() in favor
of strscpy().

Suggested-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:13:10 +02:00
Mauro Carvalho Chehab
baf768cf29 media: atomisp: set DFS to MAX if sensor doesn't report fps
If the sensor doesn't implement support for g_frame_interval,
it won't return the expected fps rate.

Instead of keeping DFS on its minimal value (which will likely
not work), set it to the max.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:12:14 +02:00
Mauro Carvalho Chehab
92b2bc49fc media: atomisp: use different dfs failed messages
There are several parts of the driver that could produce
a "dfs failed!" message. Change the texts, in order to help
identifying from where they're coming.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:12:00 +02:00
Mauro Carvalho Chehab
469a7306f1 media: atomisp: change the detection of ISP2401 at runtime
Instead of having a static var to detect it, let's use the
already-existing arch-specific bytes, as this is how other
parts of the code also checks when it needs to do something
different, depending on an specific chipset version.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:11:39 +02:00
Mauro Carvalho Chehab
77bdacaa9f media: atomisp: use macros from intel-family.h
Instead of hardcoding the intel family values there, use
the already defined ones from asm/intel-family.h.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:11:15 +02:00
Mauro Carvalho Chehab
17c3827b4c media: atomisp: don't set hpll_freq twice with different values
The logic which sets the hpll_freq for BYT sets hpll_freq
to 1600MHz, but ignores it, and sets it again after reading
from-device-specific EFI vars (this time, using a default
of 2000MHz).

Remove the first set, as this will be overriden anyway.

While here, do minor adjustments on comments and on a
printk message.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:10:56 +02:00
Mauro Carvalho Chehab
c371af6869 media: atomisp: get rid of a detection hack for a BYT Andorid-based tablet
There's a hack at the driver that selects a different table
for a BYT tablet, which sets the maximum frequency to 320 MHz,
instead of 400 MHz.

After looking at the Intel Aero Yocto's version from:

	https://download.01.org/aero/deb/pool/main/l/linux-4.4.76-aero-1.3/

It was noticed that this depends on an Android-specific modprobe parameter,
which uses a macro (INTEL_MID_BOARD) from this file:

	arch/x86/include/asm/spid.h

>From the comments there, it looks like this macro parses a
variable passed at boot time:

	cmdline : androidboot.spid=vend:cust:manu:plat:prod:hard

The devices in question are identified there as:

	INTEL_BYT_TABLET_BLK_PRO = 0x0000
	INTEL_BYT_TABLET_BLK_ENG = 0x8000

Well, this is something that we don't have upstream. So,
without further details about that, we can't really parse it.

If we ever end supporting those devices with the upstream driver,
this patch can be reverted and the device can be detected
via DMI (or maybe via PCI ID?).

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:10:35 +02:00
Mauro Carvalho Chehab
9468811091 media: atomisp: use just one mamoiada_params.h
As both isp2400 and isp2401 files are identical, remove one
of them and remove the test for ISP variant.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:10:13 +02:00
Mauro Carvalho Chehab
55b0d4d931 media: atomisp: remove some unused defines from *mamoiada_params.h
There are some parameters that are different between
isp2400 and isp2401. None of those are actually used.

So, get rid of them.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:09:52 +02:00
Mauro Carvalho Chehab
0a4b8c457b media: atomisp: simplify IRQ ifdef logic
There are lots of mess with IRQ ifdef settings. As the
*_global.h will already detect the type of IRQ system at
compile time, we can get rid of them, replacing by just
one ifdef for ISP2401.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:09:36 +02:00
Mauro Carvalho Chehab
d0b674ac62 media: atomisp: get rid of ifdef nonsense
There are some ifdefs there that end doing the same thing.
Get rid of them.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:09:08 +02:00
Mauro Carvalho Chehab
35a933d470 media: atomisp: get rid of a duplicated file
The contents of hive_isp_css_2401_irq_types_hrt.h and
hive_isp_css_common/irq_global.h are identical, except for
one unused enum:

On isp2401, this IRQ line has this name:

	hrt_isp_css_irq_is2401 = HIVE_GP_DEV_IRQ_ISP_PMEM_ERROR_BIT_ID,

While the same bit is named as:
	hrt_isp_css_irq_isp_pmem_error = HIVE_GP_DEV_IRQ_ISP_PMEM_ERROR_BIT_ID,

At the isp2400 version.

Remove one of them, in order to reduce the code differences
between those two versions.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:07:47 +02:00
Mauro Carvalho Chehab
9024001789 media: atomisp: do some cleanup at irq_local.h
- Get rid of typedefs;
- Get rid of a duplicated enum type with different names for
  ISP2400 and ISP2401;
- adjust indentation on the touched code.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:07:27 +02:00
Mauro Carvalho Chehab
f2fb029b37 media: atomisp: improve IRQ handling debug messages
When an IRQ is not handled, it is nice to know what's the
reason.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:04:44 +02:00
Mauro Carvalho Chehab
495eef11f7 media: atomisp: comment an unused code
There's a different table for some BYT variants that depend
on something inside a FIXME ifdef.

Place this also inside it, just to shut up a clang-11 warning.

Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:04:26 +02:00
Mauro Carvalho Chehab
586f93fa2a media: atomisp: get rid of a left-over wrapper function
The abstraction layer for kvfree() was removed, but there
is still a left-over code there.

Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:03:57 +02:00
Mauro Carvalho Chehab
54b15d8de0 media: atomisp: get rid of an unused IRQ duplicated event
There are two names for the same IRQ, but just one is used.
Remove the unused one.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:03:39 +02:00
Mauro Carvalho Chehab
c081868537 media: atomisp: get rid of sh_css_pipe.c
There's nothing there, just comments.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:03:21 +02:00
Arnd Bergmann
89f3b3196e media: staging: media: atomisp: fix stack overflow in init_pipe_defaults()
When building with clang, multiple copies of the structures to be
initialized are passed around on the stack and copied locally, using an
insane amount of stack space:

drivers/staging/media/atomisp/pci/sh_css.c:2371:1: error: stack frame size of 26864 bytes in function 'create_pipe' [-Werror,-Wframe-larger-than=]

Use constantly-allocated variables plus an explicit memcpy()
to avoid that.

Co-authored-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

Fixes: 6dc9a2568f ("media: atomisp: convert default struct values to use compound-literals with designated initializers")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:03:03 +02:00
Mauro Carvalho Chehab
5b552b198c media: atomisp: re-enable warnings again
For most warnings, the current code is OK. There are still
some issues with implicit-fallthough warnings.

Solve those and re-enable all warnings for this driver.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:02:30 +02:00
Mauro Carvalho Chehab
fb1f6ae692 media: atomisp: remove format duplication at mbus->fourcc table
This table used to be used also to translate between ia_css
abstraction and V4L2 fourcc codes.

This was removed on a past patch, but the table now contains
two fields with identical values.

Get rid of one of them.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:01:08 +02:00
Arnd Bergmann
4e86bde201 media: staging: media: atomisp: add PMIC_OPREGION dependency
Without that driver, there is a link failure in

ERROR: modpost: "intel_soc_pmic_exec_mipi_pmic_seq_element"
[drivers/staging/media/atomisp/pci/atomisp_gmin_platform.ko] undefined!

Add an explicit Kconfig dependency.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 19:00:43 +02:00
Arnd Bergmann
065e5e5595 media: staging: media: atomisp: disable all custom formats
clang points out the usage of an incorrect enum type in the
list of supported image formats:

drivers/staging/media/atomisp/pci/atomisp_subdev.c:49:65: error: implicit conversion from enumeration type 'enum ia_css_frame_format' to different enumeration type 'enum atomisp_input_format' [-Werror,-Wenum-conversion]
        { V4L2_MBUS_FMT_CUSTOM_NV21, 12, 12, CSS_FRAME_FORMAT_NV21, 0, CSS_FRAME_FORMAT_NV21 },
drivers/staging/media/atomisp/pci/atomisp_subdev.c:49:39: error: implicit conversion from enumeration type 'enum ia_css_frame_format' to different enumeration type 'enum atomisp_input_format' [-Werror,-Wenum-conversion]
        { V4L2_MBUS_FMT_CUSTOM_NV21, 12, 12, CSS_FRAME_FORMAT_NV21, 0, CSS_FRAME_FORMAT_NV21 },
        { V4L2_MBUS_FMT_CUSTOM_NV12, 12, 12, CSS_FRAME_FORMAT_NV12, 0, CSS_FRAME_FORMAT_NV12 },
        { MEDIA_BUS_FMT_JPEG_1X8, 8, 8, CSS_FRAME_FORMAT_BINARY_8, 0, ATOMISP_INPUT_FORMAT_BINARY_8 },

Checking the git history, I found a commit that disabled one such case
because it did not work. It seems likely that the incorrect enum was
part of the original problem and that the others do not work either,
or have never been tested.

Disable all the ones that cause a warning.

Fixes: cb02ae3d71 ("media: staging: atomisp: Disable custom format for now")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 18:51:56 +02:00
Arnd Bergmann
6fc07dd22f media: staging: media: atomisp: fix enum type mixups
Some function calls pass an incorrect enum type:

drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:858:16: error: implicit conversion from enumeration type 'input_system_ID_t' to different enumeration type 'gp_device_ID_t' [-Werror,-Wenum-conversion]
        gp_device_rst(INPUT_SYSTEM0_ID);
        ~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~
drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:860:19: error: implicit conversion from enumeration type 'input_system_ID_t' to different enumeration type 'gp_device_ID_t' [-Werror,-Wenum-conversion]
        input_switch_rst(INPUT_SYSTEM0_ID);
        ~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~
drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:876:27: error: implicit conversion from enumeration type 'input_system_cfg_flag_t' to different enumeration type 'input_system_connection_t' [-Werror,-Wenum-conversion]
                config.multicast[i]              = INPUT_SYSTEM_CFG_FLAG_RESET;
                                                 ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:1326:32: error: implicit conversion from enumeration type 'input_system_ID_t' to different enumeration type 'gp_device_ID_t' [-Werror,-Wenum-conversion]
        input_selector_cfg_for_sensor(INPUT_SYSTEM0_ID);
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~
drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:1329:19: error: implicit conversion from enumeration type 'input_system_ID_t' to different enumeration type 'gp_device_ID_t' [-Werror,-Wenum-conversion]
        input_switch_cfg(INPUT_SYSTEM0_ID, &config.input_switch_cfg);
        ~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~

INPUT_SYSTEM0_ID is zero, so use the corresponding zero-value
of the expected types instead.

Fixes: a49d25364d ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 18:51:39 +02:00
Arnd Bergmann
93517ea037 media: staging: media: atomisp: declare 'struct device' before using it
In some configurations, including this header leads to a warning:

drivers/staging/media/atomisp//pci/sh_css_firmware.h:41:38: error: declaration of 'struct device' will not be visible outside of this function [-Werror,-Wvisibility]

Make sure the struct tag is known before declaring a function
that uses it as an argument.

Fixes: 9d4fa1a16b ("media: atomisp: cleanup directory hierarchy")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 18:51:16 +02:00
Mauro Carvalho Chehab
f5fbb83feb media: atomisp: add SPDX headers
This driver is licensed under GPL 2.0, as stated inside their
headers.

Add the proper tag there. We should probably latter cleanup
the reduntant licensing text, but this could be done later,
after we get rid of other abstraction layers.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-06-11 18:50:18 +02:00