if v4l2_subdev_call(..., VENC_GET_FLD,...) fails, it
currently returns a random value. Instead, return 1.
That's probably better than returning 0, as this is very
likely what happens in practice with the current code, as
as the probably of an unititialized 32 bits integer to
have an specific value (0, in this case), is 1/(2^32).
An alternative would be to return an error code, and
let the caller to hint, based on the past received
frame, but that sounds weird.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Driver build produce lots of warnings due to wrong kernel-doc markups:
drivers/media/platform/davinci/vpbe.c:60: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_current_encoder_info'
drivers/media/platform/davinci/vpbe.c:78: warning: Function parameter or member 'cfg' not described in 'vpbe_find_encoder_sd_index'
drivers/media/platform/davinci/vpbe.c:78: warning: Function parameter or member 'index' not described in 'vpbe_find_encoder_sd_index'
drivers/media/platform/davinci/vpbe.c:105: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_g_cropcap'
drivers/media/platform/davinci/vpbe.c:105: warning: Function parameter or member 'cropcap' not described in 'vpbe_g_cropcap'
drivers/media/platform/davinci/vpbe.c:127: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_enum_outputs'
drivers/media/platform/davinci/vpbe.c:127: warning: Function parameter or member 'output' not described in 'vpbe_enum_outputs'
drivers/media/platform/davinci/vpbe.c:221: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_set_output'
drivers/media/platform/davinci/vpbe.c:221: warning: Function parameter or member 'index' not described in 'vpbe_set_output'
drivers/media/platform/davinci/vpbe.c:316: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_get_output'
drivers/media/platform/davinci/vpbe.c:328: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_s_dv_timings'
drivers/media/platform/davinci/vpbe.c:328: warning: Function parameter or member 'dv_timings' not described in 'vpbe_s_dv_timings'
drivers/media/platform/davinci/vpbe.c:380: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_g_dv_timings'
drivers/media/platform/davinci/vpbe.c:380: warning: Function parameter or member 'dv_timings' not described in 'vpbe_g_dv_timings'
drivers/media/platform/davinci/vpbe.c:405: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_enum_dv_timings'
drivers/media/platform/davinci/vpbe.c:405: warning: Function parameter or member 'timings' not described in 'vpbe_enum_dv_timings'
drivers/media/platform/davinci/vpbe.c:436: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_s_std'
drivers/media/platform/davinci/vpbe.c:436: warning: Function parameter or member 'std_id' not described in 'vpbe_s_std'
drivers/media/platform/davinci/vpbe.c:475: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_g_std'
drivers/media/platform/davinci/vpbe.c:475: warning: Function parameter or member 'std_id' not described in 'vpbe_g_std'
drivers/media/platform/davinci/vpbe.c:500: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_set_mode'
drivers/media/platform/davinci/vpbe.c:500: warning: Function parameter or member 'mode_info' not described in 'vpbe_set_mode'
drivers/media/platform/davinci/vpbe.c:585: warning: Function parameter or member 'dev' not described in 'vpbe_initialize'
drivers/media/platform/davinci/vpbe.c:585: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_initialize'
drivers/media/platform/davinci/vpbe.c:779: warning: Function parameter or member 'dev' not described in 'vpbe_deinitialize'
drivers/media/platform/davinci/vpbe.c:779: warning: Function parameter or member 'vpbe_dev' not described in 'vpbe_deinitialize'
drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter or member 'sd' not described in '_osd_dm6446_vid0_pingpong'
drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter or member 'field_inversion' not described in '_osd_dm6446_vid0_pingpong'
drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter or member 'fb_base_phys' not described in '_osd_dm6446_vid0_pingpong'
drivers/media/platform/davinci/vpbe_osd.c:144: warning: Function parameter or member 'lconfig' not described in '_osd_dm6446_vid0_pingpong'
drivers/media/platform/davinci/vpbe_osd.c:799: warning: Function parameter or member 'sd' not described in 'try_layer_config'
drivers/media/platform/davinci/vpbe_osd.c:799: warning: Function parameter or member 'layer' not described in 'try_layer_config'
drivers/media/platform/davinci/vpbe_osd.c:799: warning: Function parameter or member 'lconfig' not described in 'try_layer_config'
drivers/media/platform/davinci/vpbe_display.c:578: warning: Function parameter or member 'disp_dev' not described in 'vpbe_try_format'
drivers/media/platform/davinci/vpbe_display.c:578: warning: Function parameter or member 'pixfmt' not described in 'vpbe_try_format'
drivers/media/platform/davinci/vpbe_display.c:578: warning: Function parameter or member 'check' not described in 'vpbe_try_format'
drivers/media/platform/davinci/vpbe_display.c:943: warning: Function parameter or member 'file' not described in 'vpbe_display_s_std'
drivers/media/platform/davinci/vpbe_display.c:943: warning: Function parameter or member 'priv' not described in 'vpbe_display_s_std'
drivers/media/platform/davinci/vpbe_display.c:943: warning: Function parameter or member 'std_id' not described in 'vpbe_display_s_std'
drivers/media/platform/davinci/vpbe_display.c:975: warning: Function parameter or member 'file' not described in 'vpbe_display_g_std'
drivers/media/platform/davinci/vpbe_display.c:975: warning: Function parameter or member 'priv' not described in 'vpbe_display_g_std'
drivers/media/platform/davinci/vpbe_display.c:975: warning: Function parameter or member 'std_id' not described in 'vpbe_display_g_std'
drivers/media/platform/davinci/vpbe_display.c:998: warning: Function parameter or member 'file' not described in 'vpbe_display_enum_output'
drivers/media/platform/davinci/vpbe_display.c:998: warning: Function parameter or member 'priv' not described in 'vpbe_display_enum_output'
drivers/media/platform/davinci/vpbe_display.c:998: warning: Function parameter or member 'output' not described in 'vpbe_display_enum_output'
drivers/media/platform/davinci/vpbe_display.c:1025: warning: Function parameter or member 'file' not described in 'vpbe_display_s_output'
drivers/media/platform/davinci/vpbe_display.c:1025: warning: Function parameter or member 'priv' not described in 'vpbe_display_s_output'
drivers/media/platform/davinci/vpbe_display.c:1025: warning: Function parameter or member 'i' not described in 'vpbe_display_s_output'
drivers/media/platform/davinci/vpbe_display.c:1054: warning: Function parameter or member 'file' not described in 'vpbe_display_g_output'
drivers/media/platform/davinci/vpbe_display.c:1054: warning: Function parameter or member 'priv' not described in 'vpbe_display_g_output'
drivers/media/platform/davinci/vpbe_display.c:1054: warning: Function parameter or member 'i' not described in 'vpbe_display_g_output'
drivers/media/platform/davinci/vpbe_display.c:1074: warning: Function parameter or member 'file' not described in 'vpbe_display_enum_dv_timings'
drivers/media/platform/davinci/vpbe_display.c:1074: warning: Function parameter or member 'priv' not described in 'vpbe_display_enum_dv_timings'
drivers/media/platform/davinci/vpbe_display.c:1074: warning: Function parameter or member 'timings' not described in 'vpbe_display_enum_dv_timings'
drivers/media/platform/davinci/vpbe_display.c:1104: warning: Function parameter or member 'file' not described in 'vpbe_display_s_dv_timings'
drivers/media/platform/davinci/vpbe_display.c:1104: warning: Function parameter or member 'priv' not described in 'vpbe_display_s_dv_timings'
drivers/media/platform/davinci/vpbe_display.c:1104: warning: Function parameter or member 'timings' not described in 'vpbe_display_s_dv_timings'
drivers/media/platform/davinci/vpbe_display.c:1137: warning: Function parameter or member 'file' not described in 'vpbe_display_g_dv_timings'
drivers/media/platform/davinci/vpbe_display.c:1137: warning: Function parameter or member 'priv' not described in 'vpbe_display_g_dv_timings'
drivers/media/platform/davinci/vpbe_display.c:1137: warning: Function parameter or member 'dv_timings' not described in 'vpbe_display_g_dv_timings'
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Fix those two warnings
drivers/media/platform/davinci/vpbe_venc.c: In function ‘venc_set_ntsc’:
drivers/media/platform/davinci/vpbe_venc.c:230:6: warning: variable ‘val’ set but not used [-Wunused-but-set-variable]
u32 val;
^~~
drivers/media/platform/davinci/vpbe_venc.c: In function ‘venc_sub_dev_init’:
drivers/media/platform/davinci/vpbe_venc.c:611:6: warning: variable ‘err’ set but not used [-Wunused-but-set-variable]
int err;
^~~
AR drivers/media/platform/davinci/built-in.a
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Except for some includes (with doesn't seem to be used), this
driver builds fine with COMPILE_TEST.
So, add checks there to avoid building it if ARCH_DAVINCI
is not selected.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The only reason why this driver doesn't build with COMPILE_TEST
is because it includes mach/mux.h. It turns that none of the
macros defined there are used.
So, get rid of it, in order to allow it to build with
COMPILE_TEST.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Those functions are used only internally:
CC drivers/media/platform/marvell-ccic/mmp-driver.o
drivers/media/platform/marvell-ccic/mmp-driver.c:186:6: warning: no previous prototype for ‘mcam_ctlr_reset’ [-Wmissing-prototypes]
void mcam_ctlr_reset(struct mcam_camera *mcam)
^~~~~~~~~~~~~~~
drivers/media/platform/marvell-ccic/mmp-driver.c:217:6: warning: no previous prototype for ‘mmpcam_calc_dphy’ [-Wmissing-prototypes]
void mmpcam_calc_dphy(struct mcam_camera *mcam)
^~~~~~~~~~~~~~~~
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This driver was disabled back in 2015 from builds because
of some troubles with the platform_data definition. Now
that this got fixed, re-enable it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
There's nothing that prevents building this driver with
COMPILE_TEST. So, enable it.
While here, make the Kconfig dependency cleaner by removing
the unneeded if block.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
At least on i386, building with allyesconfig doesn't enable
PREEMPT, causing cec_gpio to not build.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
There aren't many things that would be needed to allow it
to build with compile test.
Add the needed bits.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
There are several functions that are used only inside the
driver. Stop exposing that to global symbolspace.
Get rid of the following gcc warnings:
drivers/media/platform/fsl-viu.c:240:17: warning: no previous prototype for ‘format_by_fourcc’ [-Wmissing-prototypes]
struct viu_fmt *format_by_fourcc(int fourcc)
^~~~~~~~~~~~~~~~
drivers/media/platform/fsl-viu.c:253:6: warning: no previous prototype for ‘viu_start_dma’ [-Wmissing-prototypes]
void viu_start_dma(struct viu_dev *dev)
^~~~~~~~~~~~~
drivers/media/platform/fsl-viu.c:262:6: warning: no previous prototype for ‘viu_stop_dma’ [-Wmissing-prototypes]
void viu_stop_dma(struct viu_dev *dev)
^~~~~~~~~~~~
drivers/media/platform/fsl-viu.c:807:5: warning: no previous prototype for ‘vidioc_g_fbuf’ [-Wmissing-prototypes]
int vidioc_g_fbuf(struct file *file, void *priv, struct v4l2_framebuffer *arg)
^~~~~~~~~~~~~
drivers/media/platform/fsl-viu.c:818:5: warning: no previous prototype for ‘vidioc_s_fbuf’ [-Wmissing-prototypes]
int vidioc_s_fbuf(struct file *file, void *priv, const struct v4l2_framebuffer *arg)
^~~~~~~~~~~~~
drivers/media/platform/fsl-viu.c: In function ‘viu_open’:
drivers/media/platform/fsl-viu.c:1170:6: warning: variable ‘status_cfg’ set but not used [-Wunused-but-set-variable]
u32 status_cfg;
^~~~~~~~~~
drivers/media/platform/fsl-viu.c: At top level:
drivers/media/platform/fsl-viu.c:1304:6: warning: no previous prototype for ‘viu_reset’ [-Wmissing-prototypes]
void viu_reset(struct viu_reg *reg)
^~~~~~~~~
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The isp_xclk_init_data const data isn't used anywere.
drivers/media/platform/omap3isp/isp.c:294:35: warning: ‘isp_xclk_init_data’ defined but not used [-Wunused-const-variable=]
static const struct clk_init_data isp_xclk_init_data = {
^~~~~~~~~~~~~~~~~~
Fixes: 9b28ee3c91 ("[media] omap3isp: Use the common clock framework")
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This adds support for generating coredumps for remoteprocs using
devcoredump, adds the Qualcomm sysmon driver for intra-remoteproc crash
handling and a number of fixes in Qualcomm and IMX drivers.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAlrL5dgbHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FufUP/ifQ+QbDzYzBI4CHfbef
hls8bplN9GlW4acJuhVRe8ikGz6vHZdyH88KJJX+IHekDXFqk10rWEgcyfV0h5mU
qOrhiW7hjfm2Mhs0MvNg9rKxbFrD5wAeJBJn8ukTB4z4jc9iFPazVu37V3ul/wVR
yMM4zI6kA54UwsLunqLEapb1thgLO4P99tvA+vdR8ekz/j0AVHB7HiHVLY1JX5Gu
D679icQSWOSsSQaRR7G0E97ZKZF6XaM6+aJV3eZol1HQw8k3I/Vbudi2wIKj0Ia8
jLO5JyCpgeSAAjPCZLrB5XyUXl/vU7PSPKTPyOnv2lK1wQgKsmHX80HfeAt1ISNn
4nY/Oy651/rjBN3FR9HQvQoqCDF08GG5YRDmUZCg0kS/OStrbJT4eCm+hklvanmK
O98LEWm5+FLqk+9Wau1DXGa0raXon2REIJxQSDnBUODZSqTQBS1iQmdtdYtrZxRp
17LtCABCSBMbAI8VE6eb/5jj/z07aI0pBwKEYEWOOG2xsF6q1GGZAXRxnmMUOWAv
bwSgiNqNbbYUdYMjVYDxDtWIp3/Dy8VQ3N3Fz61SieS0GjJxDy/SyNByzVL4eEjk
yYj+N74Dxgms1V/xknQmJn4ktwqaVxapnj52WF1WaEtIcm5WvPFZUVNSFvWMlbcD
rAiTKkpFC0CkINlM+dk3Ti/a
=cxV7
-----END PGP SIGNATURE-----
Merge tag 'rproc-v4.17' of git://github.com/andersson/remoteproc
Pull remoteproc updates from Bjorn Andersson:
- add support for generating coredumps for remoteprocs using
devcoredump
- add the Qualcomm sysmon driver for intra-remoteproc crash handling
- a number of fixes in Qualcomm and IMX drivers
* tag 'rproc-v4.17' of git://github.com/andersson/remoteproc:
remoteproc: fix null pointer dereference on glink only platforms
soc: qcom: qmi: add CONFIG_NET dependency
remoteproc: imx_rproc: Slightly simplify code in 'imx_rproc_probe()'
remoteproc: imx_rproc: Re-use existing error handling path in 'imx_rproc_probe()'
remoteproc: imx_rproc: Fix an error handling path in 'imx_rproc_probe()'
samples: Introduce Qualcomm QMI sample client
remoteproc: qcom: Introduce sysmon
remoteproc: Pass type of shutdown to subdev remove
remoteproc: qcom: Register segments for core dump
soc: qcom: mdt-loader: Return relocation base
remoteproc: Rename "load_rsc_table" to "parse_fw"
remoteproc: Add remote processor coredump support
remoteproc: Remove null character write of shared mem
When a BRx is provided by a pipeline, the WPF must determine the master
layer. Currently the condition to check this identifies pipe->bru ||
pipe->num_inputs > 1.
The code then moves on to dereference pipe->bru, thus the check fails
static analysers on the possibility that pipe->num_inputs could be
greater than 1 without pipe->bru being set.
The reality is that the pipeline must have a BRx to support more than
one input, thus this could never cause a fault - however it also
identifies that the num_inputs > 1 check is redundant.
Remove the redundant check - and always configure the master layer
appropriately when we have a BRx configured in our pipeline.
Fixes: 6134148f60 ("v4l: vsp1: Add support for the BRS entity")
Cc: stable@vger.kernel.org
Suggested-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
An older version of the driver patches were merged accidentally which
resulted in missing the array_size parameter that tells the length of the
array that contains the different supported sizes.
Bring it back to v4l2_find_nearest size and make the corresponding change
for the drivers using it as well.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The error return value should be fixed as it may return EPROBE_DEFER.
Cc: Bin Liu <bin.liu@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Acked-by: Rick Chang <rick.chang@mediatek.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
find_format_by_index() stops enumerating formats as soon as the index
matches, and returns NULL if venus_helper_check_codec() finds out that
the format is not supported. This prevents formats to be properly
enumerated if a non-supported format is present, as the enumeration will
end with it.
Fix this by moving the call to venus_helper_check_codec() into the loop,
and keep enumerating when it fails.
Fixes: 29f0133ec6 media: venus: use helper function to check supported codecs
Signed-off-by: Alexandre Courbot <acourbot@chromium.org>
Acked-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJaw1yeAAoJEAhfPr2O5OEVDDgQAIYpin6obedJOm7zIm741Q0S
fS2FL2pygyvHlVtU20ERHgvM6aD5tujekpDM4+GNgnq0aAabxvqBvdohmHQjyVSw
FgszgY6kQSnI8S4Oy9RB8H/MFRq7Wz9Qf+KmJh0SfuUoMzBe2A40yLjYQ+sAMJr9
mm0ijxxRpFYikVtIBgKDbjnx6wdkOs12M7YlJuI8N/tMBHMt+p2EfvqcX6GF725i
sgLGcMsTJr1sUSyY8vnM2pAlKfZL2tZqigx5f9sB4UM7uHSw/oL/a/8I+t6Mju1X
J1BD3L7UtTpwqO9sAR5BsJQ+0pAkXNOF+eLGs2p9rx4sO0DOLKoUptMI+YryvE86
/SOlTskSSAeX/rBFyZJw1zv0/9mdGrHoyCy0q/lfDkD/mQkrUJDDZ7GPLqZ9rLUe
2cXn1xMWB/soeR70oTyew0D2SZkp6y4DQr0Rwje7V8/SOWMmJvhaVIWhVIP9ZrS6
AvCS7WUYTTVIX+td2glnLkJ5SaXXJyRYv8Utp/TUrYvCFOX7wsk7F0pRY4PE4PeZ
BL7Bl8H9l3HGWWhdqPvw+ETdJgcbq/IwVUcpuuEPjkhDZEqHz//vzwoPt1nT4v6M
gfqfaW5LaYuj0MYYqyxZMDwP3FWk4SsQ0NZzmaFs+yfE17bcWUMuf3ZVJtjmLxzk
RUo0E/7RZsrw7LkCy0KF
=bzhS
-----END PGP SIGNATURE-----
Merge tag 'media/v4.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media updates from Mauro Carvalho Chehab:
- new CEC pin injection code for testing purposes
- DVB frontend cxd2099 promoted from staging
- new platform driver for Sony cxd2880 DVB devices
- new sensor drivers: mt9t112, ov2685, ov5695, ov772x, tda1997x,
tw9910.c
- removal of unused cx18 and ivtv alsa mixers
- the reneseas-ceu driver doesn't depend on soc_camera anymore and
moved from staging
- removed the mantis_vp3028 driver, unused since 2009
- s5p-mfc: add support for version 10 of the MSP
- added a decoder for imon protocol
- atomisp: lots of cleanups
- imx074 and mt9t031: don't depend on soc_camera anymore, being
promoted from staging
- added helper functions to better support DVB I2C binding
- lots of driver improvements and cleanups
* tag 'media/v4.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (438 commits)
media: v4l2-ioctl: rename a temp var that stores _IOC_SIZE(cmd)
media: fimc-capture: get rid of two warnings
media: dvb-usb-v2: fix a missing dependency of I2C_MUX
media: uvc: to the right check at uvc_ioctl_enum_framesizes()
media: cec-core: fix a bug at cec_error_inj_write()
media: tda9840: cleanup a warning
media: tm6000: avoid casting just to print pointer address
media: em28xx-input: improve error handling code
media: zr364xx: avoid casting just to print pointer address
media: vivid-radio-rx: add a cast to avoid a warning
media: saa7134-alsa: don't use casts to print a buffer address
media: solo6x10: get rid of an address space warning
media: zoran: don't cast pointers to print them
media: ir-kbd-i2c: change the if logic to avoid a warning
media: ir-kbd-i2c: improve error handling code
media: saa7134-input: improve error handling
media: s2255drv: fix a casting warning
media: ivtvfb: Cleanup some warnings
media: videobuf-dma-sg: Fix a weird cast
soc_camera: fix a weird cast on printk
...
This removes the entire architecture code for blackfin, cris, frv, m32r,
metag, mn10300, score, and tile, including the associated device drivers.
I have been working with the (former) maintainers for each one to ensure
that my interpretation was right and the code is definitely unused in
mainline kernels. Many had fond memories of working on the respective
ports to start with and getting them included in upstream, but also saw
no point in keeping the port alive without any users.
In the end, it seems that while the eight architectures are extremely
different, they all suffered the same fate: There was one company
in charge of an SoC line, a CPU microarchitecture and a software
ecosystem, which was more costly than licensing newer off-the-shelf
CPU cores from a third party (typically ARM, MIPS, or RISC-V). It seems
that all the SoC product lines are still around, but have not used the
custom CPU architectures for several years at this point. In contrast,
CPU instruction sets that remain popular and have actively maintained
kernel ports tend to all be used across multiple licensees.
The removal came out of a discussion that is now documented at
https://lwn.net/Articles/748074/. Unlike the original plans, I'm not
marking any ports as deprecated but remove them all at once after I made
sure that they are all unused. Some architectures (notably tile, mn10300,
and blackfin) are still being shipped in products with old kernels,
but those products will never be updated to newer kernel releases.
After this series, we still have a few architectures without mainline
gcc support:
- unicore32 and hexagon both have very outdated gcc releases, but the
maintainers promised to work on providing something newer. At least
in case of hexagon, this will only be llvm, not gcc.
- openrisc, risc-v and nds32 are still in the process of finishing their
support or getting it added to mainline gcc in the first place.
They all have patched gcc-7.3 ports that work to some degree, but
complete upstream support won't happen before gcc-8.1. Csky posted
their first kernel patch set last week, their situation will be similar.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJawdL2AAoJEGCrR//JCVInuH0P/RJAZh1nTD+TR34ZhJq2TBoo
PgygwDU7Z2+tQVU+EZ453Gywz9/NMRFk1RWAZqrLix4ZtyIMvC6A1qfT2yH1Y7Fb
Qh6tccQeLe4ezq5u4S/46R/fQXu3Txr92yVwzJJUuPyU0arF9rv5MmI8e6p7L1en
yb74kSEaCe+/eMlsEj1Cc1dgthDNXGKIURHkRsILoweysCpesjiTg4qDcL+yTibV
FP2wjVbniKESMKS6qL71tiT5sexvLsLwMNcGiHPj94qCIQuI7DLhLdBVsL5Su6gI
sbtgv0dsq4auRYAbQdMaH1hFvu6WptsuttIbOMnz2Yegi2z28H8uVXkbk2WVLbqG
ZESUwutGh8MzOL2RJ4jyyQq5sfo++CRGlfKjr6ImZRv03dv0pe/W85062cK5cKNs
cgDDJjGRorOXW7dyU6jG2gRqODOQBObIv3w5efdq5OgzOWlbI4EC+Y5u1Z0JF/76
pSwtGXA6YhwC+9LLAlnVTHG+yOwuLmAICgoKcTbzTVDKA2YQZG/cYuQfI5S1wD8e
X6urPx3Md2GCwLXQ9mzKBzKZUpu/Tuhx0NvwF4qVxy6x1PELjn68zuP7abDHr46r
57/09ooVN+iXXnEGMtQVS/OPvYHSa2NgTSZz6Y86lCRbZmUOOlK31RDNlMvYNA+s
3iIVHovno/JuJnTOE8LY
=fQ8z
-----END PGP SIGNATURE-----
Merge tag 'arch-removal' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic
Pul removal of obsolete architecture ports from Arnd Bergmann:
"This removes the entire architecture code for blackfin, cris, frv,
m32r, metag, mn10300, score, and tile, including the associated device
drivers.
I have been working with the (former) maintainers for each one to
ensure that my interpretation was right and the code is definitely
unused in mainline kernels. Many had fond memories of working on the
respective ports to start with and getting them included in upstream,
but also saw no point in keeping the port alive without any users.
In the end, it seems that while the eight architectures are extremely
different, they all suffered the same fate: There was one company in
charge of an SoC line, a CPU microarchitecture and a software
ecosystem, which was more costly than licensing newer off-the-shelf
CPU cores from a third party (typically ARM, MIPS, or RISC-V). It
seems that all the SoC product lines are still around, but have not
used the custom CPU architectures for several years at this point. In
contrast, CPU instruction sets that remain popular and have actively
maintained kernel ports tend to all be used across multiple licensees.
[ See the new nds32 port merged in the previous commit for the next
generation of "one company in charge of an SoC line, a CPU
microarchitecture and a software ecosystem" - Linus ]
The removal came out of a discussion that is now documented at
https://lwn.net/Articles/748074/. Unlike the original plans, I'm not
marking any ports as deprecated but remove them all at once after I
made sure that they are all unused. Some architectures (notably tile,
mn10300, and blackfin) are still being shipped in products with old
kernels, but those products will never be updated to newer kernel
releases.
After this series, we still have a few architectures without mainline
gcc support:
- unicore32 and hexagon both have very outdated gcc releases, but the
maintainers promised to work on providing something newer. At least
in case of hexagon, this will only be llvm, not gcc.
- openrisc, risc-v and nds32 are still in the process of finishing
their support or getting it added to mainline gcc in the first
place. They all have patched gcc-7.3 ports that work to some
degree, but complete upstream support won't happen before gcc-8.1.
Csky posted their first kernel patch set last week, their situation
will be similar
[ Palmer Dabbelt points out that RISC-V support is in mainline gcc
since gcc-7, although gcc-7.3.0 is the recommended minimum - Linus ]"
This really says it all:
2498 files changed, 95 insertions(+), 467668 deletions(-)
* tag 'arch-removal' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: (74 commits)
MAINTAINERS: UNICORE32: Change email account
staging: iio: remove iio-trig-bfin-timer driver
tty: hvc: remove tile driver
tty: remove bfin_jtag_comm and hvc_bfin_jtag drivers
serial: remove tile uart driver
serial: remove m32r_sio driver
serial: remove blackfin drivers
serial: remove cris/etrax uart drivers
usb: Remove Blackfin references in USB support
usb: isp1362: remove blackfin arch glue
usb: musb: remove blackfin port
usb: host: remove tilegx platform glue
pwm: remove pwm-bfin driver
i2c: remove bfin-twi driver
spi: remove blackfin related host drivers
watchdog: remove bfin_wdt driver
can: remove bfin_can driver
mmc: remove bfin_sdh driver
input: misc: remove blackfin rotary driver
input: keyboard: remove bf54x driver
...
Pull wait_var_event updates from Ingo Molnar:
"This introduces the new wait_var_event() API, which is a more flexible
waiting primitive than wait_on_atomic_t().
All wait_on_atomic_t() users are migrated over to the new API and
wait_on_atomic_t() is removed. The migration fixes one bug and should
result in no functional changes for the other usecases"
* 'sched-wait-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/wait: Improve __var_waitqueue() code generation
sched/wait: Remove the wait_on_atomic_t() API
sched/wait, arch/mips: Fix and convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, fs/ocfs2: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, fs/nfs: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, fs/fscache: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, fs/btrfs: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, fs/afs: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, drivers/media: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, drivers/drm: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait: Introduce wait_var_event()
The m32r architecture is getting removed, so this one is no longer needed.
Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The blackfin architecture is getting removed, so the video
capture driver is also obsolete.
Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Acked-by: Aaron Wu <aaron.wu@analog.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Smatch produces two warnings when building this file:
./arch/x86/include/asm/bitops.h:433:22: warning: asm output is not an lvalue
./arch/x86/include/asm/bitops.h:433:22: warning: asm output is not an lvalue
On some asm instructions.
I suspect that those asm instructions might not be producing the
right code, so, better to use two intermediate vars, get rid of
the warnings and of the risk of producing a wrong code.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
As warned:
drivers/media/platform/rockchip/rga/rga.c:210:16: warning: symbol 'formats' was not declared. Should it be static?
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
It turns out that the struct cec_fh event buffer size of 64 events
(64 for CEC_EVENT_PIN_CEC_LOW and 64 for _HIGH) is too small. It's
about 160 ms worth of events and if the Raspberry Pi is busy, then it
might take too long for the application to be scheduled so that it can
drain the pending events. Increase these buffers to 800 events which
is at least 2 seconds worth of events.
There is also a FIFO in between the interrupt and the cec-pin thread.
The thread passes the events on to the CEC core. It is important that
should this FIFO fill up the cec core will be informed that events
have been lost so this can be communicated to the user by setting
CEC_EVENT_FL_DROPPED_EVENTS.
It is very hard to debug CEC problems if events were lost without
informing the user of that fact.
If events were dropped due to the FIFO filling up, then the debugfs
status file will let you know how many events were dropped.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The values of enc_y_addr and enc_c_addr are initialized by
s5p_mfc_hw_call(), but, in thesis, this macro might be doing
nothing, if the get_enc_frame_buffer() is not declared.
That causes those GCC warnings:
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1242 enc_post_frame_start() error: uninitialized symbol 'enc_y_addr'.
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1243 enc_post_frame_start() error: uninitialized symbol 'enc_c_addr'.
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1256 enc_post_frame_start() error: uninitialized symbol 'enc_y_addr'.
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c:1257 enc_post_frame_start() error: uninitialized symbol 'enc_c_addr'.
Change the logic by initializing those constants to zero,
with should hopefully do the right thing.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Valid range for those controls is specified in documentation as [0, 51],
so initialize the controls to such range rather than [INT_MIN, INT_MAX].
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
When value of V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP or V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP
controls is changed we should update range of a set of HEVC quantization
parameter v4l2 controls as specified in the HEVC controls documentation.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Provide proper (real) struct device to request_firmware() call. This fixes
following error messages:
(NULL device *): Direct firmware load for s5p-mfc-v6-v2.fw failed with error -2
(NULL device *): Direct firmware load for s5p-mfc-v6.fw failed with error -2
into a bit more meaningful ones:
s5p-mfc 11000000.codec: Direct firmware load for s5p-mfc-v6-v2.fw failed with error -2
s5p-mfc 11000000.codec: Direct firmware load for s5p-mfc-v6.fw failed with error -2
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Add support for codec definition and corresponding buffer
requirements for VP9 decoder.
Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Add support for codec definition and corresponding buffer
requirements for HEVC decoder.
Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
After MFC v8.0, mfc f/w lets the driver know how much scratch buffer
size is required for decoder. If mfc f/w has the functionality,
E_MIN_SCRATCH_BUFFER_SIZE, driver can know how much scratch buffer size
is required for encoder too.
Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Adding the support for MFC v10.10, with new register file and
necessary hw control, decoder, encoder and structural changes.
Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
This patch renames macro IS_MFCV8 to IS_MFCV8_PLUS so that the MFCv8
code can be resued for MFCv10.10 support. Since the MFCv8 specific code
holds good for MFC v10.10 also.
Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Instead of switching capture mode depending on how many buffers are
available use a scratch buffer and always run in continuous mode. By
using a scratch buffer the responsiveness of the capture loop is
increased as it can keep running even if there are no buffers available
from userspace.
As soon as a userspace queues a buffer it is inserted into the capture
loop and returned as soon as it is filled. This is a improvement on the
previous logic where the whole capture loop was stopped and switched to
single capture mode if userspace did not feed the VIN driver buffers at
the same time it consumed them. To make matters worse it was difficult
for the driver to reenter continuous mode if it entered single mode even
if userspace started to queue buffers faster. This resulted in
suboptimal performance where if userspace where delayed for a short
period the ongoing capture would be slowed down and run in single mode
until the capturing process where restarted.
An additional effect of this change is that the capture logic can be
made much simple as we know that continuous mode will always be used.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Before starting a capture, allocate a scratch buffer which can be used
by the driver to give to the hardware if no buffers are available from
userspace. The buffer is not used in this patch but prepares for future
refactoring where the scratch buffer can be used to avoid the need to
fallback on single capture mode if userspace can't queue buffers as fast
as the VIN driver consumes them.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
We now get a warning after the 'dmadev' variable is no longer used:
drivers/media/platform/omap/omap_vout_vrfb.c: In function 'omap_vout_prepare_vrfb':
drivers/media/platform/omap/omap_vout_vrfb.c:239:21: error: unused variable 'dmadev' [-Werror=unused-variable]
Fixes: 8f0aa38292 ("media: v4l: omap_vout: vrfb: Use the wrapper for prep_interleaved_dma()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Do not stop/restart dma on overrun or errors.
Dma will be restarted on current frame transfer
completion. Frame transfer completion is ensured
even if overrun or error occurs by DCMI continuous
capture mode which restarts data transfer at next
frame sync.
Do no warn on overrun while in irq thread, this slows down
system and lead to more overrun errors. Use a counter
instead and log errors at stop streaming.
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
