summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-03-05media: meson: vdec: add VP9 decoder supportMaxime Jourdan
This adds VP9 decoding for the Amlogic GXL, G12A & SM1 SoCs, using the commong "HEVC" HW decoder. For G12A & SM1, it uses the IOMMU support from the firmware. For 10bit decoding, the firmware can only decode in the proprietary Amlogic Framebuffer Compression format, but can output in 8bit NV12 buffer while writing the decoded frame. Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: meson: vdec: add VP9 input supportMaxime Jourdan
Amlogic VP9 decoder requires an additional 16-byte payload before every frame header. The source buffer is updated in-place, then given to the Parser FIFO DMA. The FIFO DMA copies the blocks into the 16MiB parser ring buffer, then parses and copies the slice into the decoder "workspace". Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: meson: vdec: add common HEVC decoder supportMaxime Jourdan
Add support for the HEVC & VP9 common decoder support, handling Amlogic GXBB, GXL, G12A and SM1 platforms. This handles the "HEVC" hw decoder used for HEVC and VP9, and will be using in the new H264 multi-instance decoder for G12A & SM1 platforms. Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: meson: vdec: add helpers for lossless framebuffer compression buffersMaxime Jourdan
Add helpers to support the lossless framebuffer compression format that will be used in HEVC & VP9 decoders when decoding 10bit content for downsampling to 8bit NV12 and later proper compressed buffer support. Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: meson: vdec: align stride on 32 bytesNeil Armstrong
The HEVC/VP9 aligns the plane stride on 32, so align the planes stride for all codecs to 32 to satisfy HEVC/VP9 decoding using the "HEVC" HW. This fixes VP9 decoding of streams with following (not limited) widths: - 264 -288 - 350 - 352 - 472 - 480 - 528 - 600 - 720 - 800 - 848 - 1440 Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Tested-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: meson: vdec: add H.264 decoding supportMaxime Jourdan
Add support for the H264 compressed format (V4L2_PIX_FMT_H264). Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: meson: vdec: bring up to complianceMaxime Jourdan
Add all the necessary bits to pass v4l2-compliance in stateful decoding mode. Mostly includes tracking the state of the decoder, allowing the OUTPUT queue to stream while the CAPTURE queue is inactive, handling resolution change events, draining with V4L2_DEC_CMD_STOP, copying more metadata from the src buffers to the dst buffers, etc. Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: vicodec: use v4l2-mem2mem draining, stopped and next-buf-is-last ↵Neil Armstrong
states handling Use the previously introduced v4l2-mem2mem core APIs to handle the drainig, stopped and next-buf-is-last states. With these changes, the v4l2-compliance still passes with the following commands : >>>><><><><><><><><><><><><><><><><>< 15.53 fps 15.53 fps ><><><><><><><><><><><><>< 13.99 fps 13.99 fps ><><><><><><><><><><><>< 13.52 fps 13.52 fps ><><><><><><><><><><><><>< 13.41 fps 13.41 fps ><><><><><><><><><><><><>< 13.21 fps 13.21 fps ><><><><><><><><><><><>< 13.09 fps 13.09 fps ><><><><><><>< STOP ENCODER <<< EOS EVENT v4l2-compliance SHA: 7ead0e1856b89f2e19369af452bb03fd0cd16793, 64 bits [...] Total for vicodec device /dev/video0: 50, Succeeded: 50, Failed: 0, Warnings: 0 The full output is available at [1] v4l2-compliance SHA: 7ead0e1856b89f2e19369af452bb03fd0cd16793, 64 bits [...] Total for vicodec device /dev/video1: 50, Succeeded: 50, Failed: 0, Warnings: 0 The full output is available at [2] No functional changes should be noticed. [1] https://termbin.com/25nn [2] https://termbin.com/dza4 Suggested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Suggested-by: Maxime Jourdan <mjourdan@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: v4l2-mem2mem: handle draining, stopped and next-buf-is-last statesNeil Armstrong
Since the draining and stop phase of the HW decoder mem2mem bahaviour is now clearly defined, we can move handling of the following states to the common v4l2-mem2mem core code: - draining - stopped - next-buf-is-last By introducing the following v4l2-mem2mem APIs: - v4l2_m2m_encoder_cmd/v4l2_m2m_ioctl_encoder_cmd to handle start/stop command - v4l2_m2m_decoder_cmd/v4l2_m2m_ioctl_decoder_cmd to handle start/stop command - v4l2_m2m_update_start_streaming_state to update state on start of streaming of the de/encoder queue - v4l2_m2m_update_stop_streaming_state to update state on stop of streaming of the de/encoder queue - v4l2_m2m_last_buffer_done to make the current dest buffer as the last one And inline helpers: - v4l2_m2m_mark_stopped to mark the de/encoding process as stopped - v4l2_m2m_clear_state to clear the de/encoding state - v4l2_m2m_dst_buf_is_last to detect the current dequeued dst_buf is the last - v4l2_m2m_has_stopped to detect the de/encoding stopped state - v4l2_m2m_is_last_draining_src_buf to detect the current source buffer should be the last processing before stopping the de/encoding process The special next-buf-is-last when min_buffers != 1 case is also handled in v4l2_m2m_qbuf() by reusing the other introduced APIs. This state management has been stolen from the vicodec implementation, and is no-op for drivers not calling the v4l2_m2m_encoder_cmd or v4l2_m2m_decoder_cmd and v4l2_m2m_update_start/stop_streaming_state. The vicodec will be the first one to be converted as an example. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: v4l2-ctrls: v4l2_ctrl_request_complete() should always set ref->reqHans Verkuil
When the request is completed, all controls are copied to the request object. However, when VIDIOC_G_EXT_CTRLS attempts to read control values from the request it will read the current value instead for any control reference that has a NULL ref->req pointer. But that's wrong: after completing the request *all* controls should have a non-NULL ref->req pointer since they are after all copied to the request. So set ref->req if it wasn't set already. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: staging: media: usbvision: Add missing MEDIA_USB_SUPPORT dependencyYueHaibing
VIDEO_USBVISION driver depends on MEDIA_USB_SUPPORT Fixes: 8fb12ce2ec9d ("media: usbvision: deprecate driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: staging: tegra-vde: Use devm_platform_ioremap_resource_byname()Dmitry Osipenko
There is a new devm_platform_ioremap_resource_byname() helper in the kernel now, which helps to make code cleaner a tad by replacing few "boilerplate" lines of code with a single line. Let's utilize that new helper in the VDE driver. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: ti-vpe: cal: fix disable_irqs to only the intended targetBenoit Parrot
disable_irqs() was mistakenly disabling all interrupts when called. This cause all port stream to stop even if only stopping one of them. Cc: stable <stable@vger.kernel.org> Signed-off-by: Benoit Parrot <bparrot@ti.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: imx: Propagate quantization and encoding in CSISteve Longerbeam
Unlike the PRPENC and PRPVF subdevices, the CSI's cannot convert quantization from sink to source, or do any kind of Y'CbCr <-> RGB encoding. So the CSI's cannot allow quantization and ycbcr_enc to be selectable by the user and must be propagated from sink to source. Fixes: 4791bd7d6adc4 ("media: imx: Try colorimetry at both sink and source pads") Reported-by: Tim Harvey <tharvey@gateworks.com> Signed-off-by: Steve Longerbeam <slongerbeam@gmail.com> Tested-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Rui Miguel Silva <rmfrfs@gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: spi: gs1662: Use new structure for SPI transfer delaysSergiu Cuciurean
In a recent change to the SPI subsystem [1], a new `delay` struct was added to replace the `delay_usecs`. This change replaces the current `delay_usecs` with `delay` for this driver. The `spi_transfer_delay_exec()` function [in the SPI framework] makes sure that both `delay_usecs` & `delay` are used (in this order to preserve backwards compatibility). [1] commit bebcfd272df6 ("spi: introduce `delay` field for `spi_transfer` + spi_transfer_delay_exec()") Signed-off-by: Sergiu Cuciurean <sergiu.cuciurean@analog.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: v4l2-core: fix entity initialization in device_register_subdevEugen Hristev
The entity variable was being initialized in the wrong place, before the parameters have been checked. To solve this, completely removed the entity variable and replaced it with the initialization value : &sd->entity. This will avoid dereferencing 'sd' pointer before it's being checked if it's NULL. Fixes: 61f5db549dde ("[media] v4l: Make v4l2_subdev inherit from media_entity") Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: v4l2-core: fix a use-after-free bug of sd->devnodeDafna Hirschfeld
sd->devnode is released after calling v4l2_subdev_release. Therefore it should be set to NULL so that the subdev won't hold a pointer to a released object. This fixes a reference after free bug in function v4l2_device_unregister_subdev Fixes: 0e43734d4c46e ("media: v4l2-subdev: add release() internal op") Cc: stable@vger.kernel.org Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> 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-03-05media: vimc: use-after-free fix - release vimc in the v4l_device releaseDafna Hirschfeld
A use-after-free bug occures when unbinding the device while it streams. The 'struct vimc_ent_device' allocated for the 'Sensor A' is freed when calling the sensor's 'rm' callback but the freed pointer is later accessed in the function 'vimc_streamer_pipeline_terminate'. To fix this bug, move the release callback of the vimc entities and vimc_device to the release callback of v4l2_device. The .rm callback of vimc_ent_config is replaced by two callbacks: .unregister - this is called upon removing the device and it unregisters the entity. This is an optional callback since subdevices don't need to implement it because they are already unregistered in v4l2_device_unregister. .release - this is called from the release callback of v4l2_device and it frees the entity. This ensures that the entities will be released when the last fh of any of the devices is closed. The commands that cause the crash and the KASAN report: media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 v4l2-ctl --stream-mmap --stream-count=1000 -d /dev/video2 & sleep 1 echo -n vimc.0 >/sys/bus/platform/drivers/vimc/unbind [ 188.417934] BUG: KASAN: use-after-free in vimc_streamer_pipeline_terminate+0x75/0x140 [vimc] [ 188.420182] Read of size 8 at addr ffff8881e9c26008 by task bash/185 [ 188.421800] [ 188.422223] CPU: 0 PID: 185 Comm: bash Not tainted 5.5.0-rc1+ #1 [ 188.423681] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 188.425938] Call Trace: [ 188.426610] dump_stack+0x75/0xa0 [ 188.427519] ? vimc_streamer_pipeline_terminate+0x75/0x140 [vimc] [ 188.429057] print_address_description.constprop.6+0x16/0x220 [ 188.430462] ? vimc_streamer_pipeline_terminate+0x75/0x140 [vimc] [ 188.431979] ? vimc_streamer_pipeline_terminate+0x75/0x140 [vimc] [ 188.433455] __kasan_report.cold.9+0x1a/0x40 [ 188.434518] ? vimc_streamer_pipeline_terminate+0x75/0x140 [vimc] [ 188.436010] kasan_report+0xe/0x20 [ 188.436859] vimc_streamer_pipeline_terminate+0x75/0x140 [vimc] [ 188.438339] vimc_streamer_s_stream+0x8b/0x3c0 [vimc] [ 188.439576] vimc_cap_stop_streaming+0x22/0x40 [vimc] [ 188.440863] __vb2_queue_cancel+0x65/0x560 [videobuf2_common] [ 188.442391] vb2_core_queue_release+0x19/0x50 [videobuf2_common] [ 188.443974] vimc_cap_rm+0x10/0x20 [vimc] [ 188.444986] vimc_rm_subdevs+0x9e/0xe0 [vimc] [ 188.446179] vimc_remove+0x19/0x70 [vimc] [ 188.447301] platform_drv_remove+0x2f/0x50 [ 188.448468] device_release_driver_internal+0x133/0x260 [ 188.449814] unbind_store+0x121/0x150 [ 188.450726] kernfs_fop_write+0x142/0x230 [ 188.451724] ? sysfs_kf_bin_read+0x100/0x100 [ 188.452826] vfs_write+0xdc/0x230 [ 188.453760] ksys_write+0xaf/0x140 [ 188.454702] ? __ia32_sys_read+0x40/0x40 [ 188.455773] ? __do_page_fault+0x473/0x620 [ 188.456780] do_syscall_64+0x5e/0x1a0 [ 188.457711] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 188.459079] RIP: 0033:0x7f80f1f13504 [ 188.459969] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48 8d 05 f9 61 0d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53 [ 188.464445] RSP: 002b:00007ffd7e843b58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 188.466276] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f80f1f13504 [ 188.467999] RDX: 0000000000000006 RSI: 000055ef2eb21b10 RDI: 0000000000000001 [ 188.469708] RBP: 000055ef2eb21b10 R08: 00007f80f1fe68c0 R09: 00007f80f1e26740 [ 188.471407] R10: 000055ef2eade010 R11: 0000000000000246 R12: 00007f80f1fe5760 [ 188.473381] R13: 0000000000000006 R14: 00007f80f1fe0760 R15: 0000000000000006 [ 188.475107] [ 188.475500] Allocated by task 473: [ 188.476351] save_stack+0x19/0x80 [ 188.477201] __kasan_kmalloc.constprop.6+0xc1/0xd0 [ 188.478507] vimc_sen_add+0x36/0x309 [vimc] [ 188.479649] vimc_probe+0x1e2/0x530 [vimc] [ 188.480776] platform_drv_probe+0x46/0xa0 [ 188.481829] really_probe+0x16c/0x520 [ 188.482732] driver_probe_device+0x114/0x170 [ 188.483783] device_driver_attach+0x85/0x90 [ 188.484800] __driver_attach+0xa8/0x190 [ 188.485734] bus_for_each_dev+0xe4/0x140 [ 188.486702] bus_add_driver+0x223/0x2d0 [ 188.487715] driver_register+0xca/0x140 [ 188.488767] 0xffffffffc037003d [ 188.489635] do_one_initcall+0x86/0x28f [ 188.490702] do_init_module+0xf8/0x340 [ 188.491773] load_module+0x3766/0x3a10 [ 188.492811] __do_sys_finit_module+0x11a/0x1b0 [ 188.494059] do_syscall_64+0x5e/0x1a0 [ 188.495079] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 188.496481] [ 188.496893] Freed by task 185: [ 188.497670] save_stack+0x19/0x80 [ 188.498493] __kasan_slab_free+0x125/0x170 [ 188.499486] kfree+0x8c/0x230 [ 188.500254] v4l2_subdev_release+0x64/0x70 [videodev] [ 188.501498] v4l2_device_release_subdev_node+0x1c/0x30 [videodev] [ 188.502976] device_release+0x3c/0xd0 [ 188.503867] kobject_put+0xf4/0x240 [ 188.507802] vimc_rm_subdevs+0x9e/0xe0 [vimc] [ 188.508846] vimc_remove+0x19/0x70 [vimc] [ 188.509792] platform_drv_remove+0x2f/0x50 [ 188.510752] device_release_driver_internal+0x133/0x260 [ 188.512006] unbind_store+0x121/0x150 [ 188.512899] kernfs_fop_write+0x142/0x230 [ 188.513874] vfs_write+0xdc/0x230 [ 188.514698] ksys_write+0xaf/0x140 [ 188.515523] do_syscall_64+0x5e/0x1a0 [ 188.516543] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 188.517710] [ 188.518034] The buggy address belongs to the object at ffff8881e9c26000 [ 188.518034] which belongs to the cache kmalloc-4k of size 4096 [ 188.520528] The buggy address is located 8 bytes inside of [ 188.520528] 4096-byte region [ffff8881e9c26000, ffff8881e9c27000) [ 188.523015] The buggy address belongs to the page: [ 188.524357] page:ffffea0007a70800 refcount:1 mapcount:0 mapping:ffff8881f6402140 index:0x0 compound_mapcount: 0 [ 188.527058] raw: 0200000000010200 dead000000000100 dead000000000122 ffff8881f6402140 [ 188.528983] raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000 [ 188.530883] page dumped because: kasan: bad access detected [ 188.532336] [ 188.532720] Memory state around the buggy address: [ 188.533871] ffff8881e9c25f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 188.535631] ffff8881e9c25f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 188.537370] >ffff8881e9c26000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 188.538996] ^ [ 188.539812] ffff8881e9c26080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 188.541549] ffff8881e9c26100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: vimc: allocate vimc_device dynamicallyDafna Hirschfeld
In future patch, the release of the device will move to the release callback of v4l2_device. Therefore the device will be released only when the last fh will be closed. Dynamic allocation will then be needed since when the device is unbounded and then bounded again, it might be that the probe callback will run before the release of the last device is finished. In that case both operations will run on the same memory concurrently and cause memory corruption. This patch also removes the pdev field of vimc_device since it is not needed anymore. Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05media: vimc: replace vimc->pdev.dev with vimc->mdev.devDafna Hirschfeld
replace 'vimc->pdev.dev' with 'vimc->mdev.dev' in debug prints and in assignment to vimc_ent_device.dev. This helps to unify the debug statements. This will also eliminate the need to use the pdev field in vimc_device in future patch. Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
2020-03-05serial: 8250_exar: add support for ACCES cardsJay Dolan
Add ACCES VIDs and PIDs that use the Exar chips Signed-off-by: Jay Dolan <jay.dolan@accesio.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200305140504.22237-1-jay.dolan@accesio.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-05tty:serial:mvebu-uart:fix a wrong returntangbin
in this place, the function should return a negative value and the PTR_ERR already returns a negative,so return -PTR_ERR() is wrong. Signed-off-by: tangbin <tangbin@cmss.chinamobile.com> Cc: stable <stable@vger.kernel.org> Acked-by: Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20200305013823.20976-1-tangbin@cmss.chinamobile.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-05net: hns3: fix a not link up issue when fibre port supports autonegJian Shen
When fibre port supports auto-negotiation, the IMP(Intelligent Management Process) processes the speed of auto-negotiation and the user's speed separately. For below case, the port will get a not link up problem. step 1: disables auto-negotiation and sets speed to A, then the driver's MAC speed will be updated to A. step 2: enables auto-negotiation and MAC gets negotiated speed B, then the driver's MAC speed will be updated to B through querying in periodical task. step 3: MAC gets new negotiated speed A. step 4: disables auto-negotiation and sets speed to B before periodical task query new MAC speed A, the driver will ignore the speed configuration. This patch fixes it by skipping speed and duplex checking when fibre port supports auto-negotiation. Fixes: 22f48e24a23d ("net: hns3: add autoneg and change speed support for fibre port") Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05slip: make slhc_compress() more robust against malicious packetsEric Dumazet
Before accessing various fields in IPV4 network header and TCP header, make sure the packet : - Has IP version 4 (ip->version == 4) - Has not a silly network length (ip->ihl >= 5) - Is big enough to hold network and transport headers - Has not a silly TCP header size (th->doff >= sizeof(struct tcphdr) / 4) syzbot reported : BUG: KMSAN: uninit-value in slhc_compress+0x5b9/0x2e60 drivers/net/slip/slhc.c:270 CPU: 0 PID: 11728 Comm: syz-executor231 Not tainted 5.6.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 slhc_compress+0x5b9/0x2e60 drivers/net/slip/slhc.c:270 ppp_send_frame drivers/net/ppp/ppp_generic.c:1637 [inline] __ppp_xmit_process+0x1902/0x2970 drivers/net/ppp/ppp_generic.c:1495 ppp_xmit_process+0x147/0x2f0 drivers/net/ppp/ppp_generic.c:1516 ppp_write+0x6bb/0x790 drivers/net/ppp/ppp_generic.c:512 do_loop_readv_writev fs/read_write.c:717 [inline] do_iter_write+0x812/0xdc0 fs/read_write.c:1000 compat_writev+0x2df/0x5a0 fs/read_write.c:1351 do_compat_pwritev64 fs/read_write.c:1400 [inline] __do_compat_sys_pwritev fs/read_write.c:1420 [inline] __se_compat_sys_pwritev fs/read_write.c:1414 [inline] __ia32_compat_sys_pwritev+0x349/0x3f0 fs/read_write.c:1414 do_syscall_32_irqs_on arch/x86/entry/common.c:339 [inline] do_fast_syscall_32+0x3c7/0x6e0 arch/x86/entry/common.c:410 entry_SYSENTER_compat+0x68/0x77 arch/x86/entry/entry_64_compat.S:139 RIP: 0023:0xf7f7cd99 Code: 90 e8 0b 00 00 00 f3 90 0f ae e8 eb f9 8d 74 26 00 89 3c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 002b:00000000ffdb84ac EFLAGS: 00000217 ORIG_RAX: 000000000000014e RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000200001c0 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 0000000040047459 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:144 [inline] kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:127 kmsan_slab_alloc+0x8a/0xe0 mm/kmsan/kmsan_hooks.c:82 slab_alloc_node mm/slub.c:2793 [inline] __kmalloc_node_track_caller+0xb40/0x1200 mm/slub.c:4401 __kmalloc_reserve net/core/skbuff.c:142 [inline] __alloc_skb+0x2fd/0xac0 net/core/skbuff.c:210 alloc_skb include/linux/skbuff.h:1051 [inline] ppp_write+0x115/0x790 drivers/net/ppp/ppp_generic.c:500 do_loop_readv_writev fs/read_write.c:717 [inline] do_iter_write+0x812/0xdc0 fs/read_write.c:1000 compat_writev+0x2df/0x5a0 fs/read_write.c:1351 do_compat_pwritev64 fs/read_write.c:1400 [inline] __do_compat_sys_pwritev fs/read_write.c:1420 [inline] __se_compat_sys_pwritev fs/read_write.c:1414 [inline] __ia32_compat_sys_pwritev+0x349/0x3f0 fs/read_write.c:1414 do_syscall_32_irqs_on arch/x86/entry/common.c:339 [inline] do_fast_syscall_32+0x3c7/0x6e0 arch/x86/entry/common.c:410 entry_SYSENTER_compat+0x68/0x77 arch/x86/entry/entry_64_compat.S:139 Fixes: b5451d783ade ("slip: Move the SLIP drivers") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-05Merge tag 'hyperv-fixes-signed' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux Pull Hyper-V update from Wei Liu: - Update MAINTAINERS file for Hyper-V - One cleanup patch for Hyper-V HID driver * tag 'hyperv-fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux: HID: hyperv: NULL check before some freeing functions is not needed. Hyper-V: add myself as a maintainer Hyper-V: Drop Sasha Levin from the Hyper-V maintainers
2020-03-05Merge tag 'dmaengine-fix-5.6-rc5' of ↵Linus Torvalds
git://git.infradead.org/users/vkoul/slave-dma Pull dmaengine fixes from Vinod Koul: "A bunch of driver fixes: - Doc updates to clean warnings for dmaengine - Fixes for newly added Intel idxd driver - More fixes for newly added TI k3-udma driver - Fixes for IMX and Tegra drivers" * tag 'dmaengine-fix-5.6-rc5' of git://git.infradead.org/users/vkoul/slave-dma: dmaengine: imx-sdma: Fix the event id check to include RX event for UART6 dmaengine: tegra-apb: Prevent race conditions of tasklet vs free list dmaengine: tegra-apb: Fix use-after-free dmaengine: imx-sdma: fix context cache dmaengine: idxd: wq size configuration needs to check global max size dmaengine: idxd: sysfs input of wq incorrect wq type should return error dmaengine: coh901318: Fix a double lock bug in dma_tc_handle() dmaengine: idxd: correct reserved token calculation dmaengine: ti: k3-udma: Fix terminated transfer handling dmaengine: ti: k3-udma: Use the channel direction in pause/resume functions dmaengine: ti: k3-udma: Use the TR counter helper for slave_sg and cyclic dmaengine: ti: k3-udma: Move the TR counter calculation to helper function dmaengine: ti: k3-udma: Workaround for RX teardown with stale data in peer dmaengine: ti: k3-udma: Use ktime/usleep_range based TX completion check dmaengine: idxd: Fix error handling in idxd_wq_cdev_dev_setup() dmaengine: doc: fix warnings/issues of client.rst dmaengine: idxd: fix runaway module ref count on device driver bind
2020-03-05drm/bridge: dw-hdmi: fix AVI frame colorimetryJernej Skrabec
CTA-861-F explicitly states that for RGB colorspace colorimetry should be set to "none". Fix that. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Fixes: def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20200304232512.51616-2-jernej.skrabec@siol.net
2020-03-05xen/blkfront: fix ring info addressingJuergen Gross
Commit 0265d6e8ddb890 ("xen/blkfront: limit allocated memory size to actual use case") made struct blkfront_ring_info size dynamic. This is fine when running with only one queue, but with multiple queues the addressing of the single queues has to be adapted as the structs are allocated in an array. Fixes: 0265d6e8ddb890 ("xen/blkfront: limit allocated memory size to actual use case") Reported-by: Sander Eikelenboom <linux@eikelenboom.it> Tested-by: Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Link: https://lore.kernel.org/r/20200305155129.28326-1-jgross@suse.com Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-03-05xen/xenbus: fix lockingJuergen Gross
Commit 060eabe8fbe726 ("xenbus/backend: Protect xenbus callback with lock") introduced a bug by holding a lock while calling a function which might schedule. Fix that by using a semaphore instead. Fixes: 060eabe8fbe726 ("xenbus/backend: Protect xenbus callback with lock") Signed-off-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20200305100323.16736-1-jgross@suse.com Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-03-05xenbus: req->err should be updated before req->stateDongli Zhang
This patch adds the barrier to guarantee that req->err is always updated before req->state. Otherwise, read_reply() would not return ERR_PTR(req->err) but req->body, when process_writes()->xb_write() is failed. Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Link: https://lore.kernel.org/r/20200303221423.21962-2-dongli.zhang@oracle.com Reviewed-by: Julien Grall <jgrall@amazon.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-03-05xenbus: req->body should be updated before req->stateDongli Zhang
The req->body should be updated before req->state is updated and the order should be guaranteed by a barrier. Otherwise, read_reply() might return req->body = NULL. Below is sample callstack when the issue is reproduced on purpose by reordering the updates of req->body and req->state and adding delay in code between updates of req->state and req->body. [ 22.356105] general protection fault: 0000 [#1] SMP PTI [ 22.361185] CPU: 2 PID: 52 Comm: xenwatch Not tainted 5.5.0xen+ #6 [ 22.366727] Hardware name: Xen HVM domU, BIOS ... [ 22.372245] RIP: 0010:_parse_integer_fixup_radix+0x6/0x60 ... ... [ 22.392163] RSP: 0018:ffffb2d64023fdf0 EFLAGS: 00010246 [ 22.395933] RAX: 0000000000000000 RBX: 75746e7562755f6d RCX: 0000000000000000 [ 22.400871] RDX: 0000000000000000 RSI: ffffb2d64023fdfc RDI: 75746e7562755f6d [ 22.405874] RBP: 0000000000000000 R08: 00000000000001e8 R09: 0000000000cdcdcd [ 22.410945] R10: ffffb2d6402ffe00 R11: ffff9d95395eaeb0 R12: ffff9d9535935000 [ 22.417613] R13: ffff9d9526d4a000 R14: ffff9d9526f4f340 R15: ffff9d9537654000 [ 22.423726] FS: 0000000000000000(0000) GS:ffff9d953bc80000(0000) knlGS:0000000000000000 [ 22.429898] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 22.434342] CR2: 000000c4206a9000 CR3: 00000001ea3fc002 CR4: 00000000001606e0 [ 22.439645] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 22.444941] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 22.450342] Call Trace: [ 22.452509] simple_strtoull+0x27/0x70 [ 22.455572] xenbus_transaction_start+0x31/0x50 [ 22.459104] netback_changed+0x76c/0xcc1 [xen_netfront] [ 22.463279] ? find_watch+0x40/0x40 [ 22.466156] xenwatch_thread+0xb4/0x150 [ 22.469309] ? wait_woken+0x80/0x80 [ 22.472198] kthread+0x10e/0x130 [ 22.474925] ? kthread_park+0x80/0x80 [ 22.477946] ret_from_fork+0x35/0x40 [ 22.480968] Modules linked in: xen_kbdfront xen_fbfront(+) xen_netfront xen_blkfront [ 22.486783] ---[ end trace a9222030a747c3f7 ]--- [ 22.490424] RIP: 0010:_parse_integer_fixup_radix+0x6/0x60 The virt_rmb() is added in the 'true' path of test_reply(). The "while" is changed to "do while" so that test_reply() is used as a read memory barrier. Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com> Link: https://lore.kernel.org/r/20200303221423.21962-1-dongli.zhang@oracle.com Reviewed-by: Julien Grall <jgrall@amazon.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-03-05xen: Replace zero-length array with flexible-array memberGustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: https://lore.kernel.org/r/20200226212612.GA4663@embeddedor Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-03-05driver core: fw_devlink_flags can be statickbuild test robot
Fixes: 8375e74f2bca ("driver core: Add fw_devlink kernel commandline option") Signed-off-by: kbuild test robot <lkp@intel.com> Acked-by: Saravana Kannan <saravanak@google.com> Link: https://lore.kernel.org/r/20200305020916.GA14234@3143ef58ba07 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-03-05drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume ↵Hersen Wu
from s3 (v2) This interface is for dGPU Navi1x. Linux dc-pplib interface depends on window driver dc implementation. For Navi1x, clock settings of dcn watermarks are fixed. the settings should be passed to smu during boot up and resume from s3. boot up: dc calculate dcn watermark clock settings within dc_create, dcn20_resource_construct, then call pplib functions below to pass the settings to smu: smu_set_watermarks_for_clock_ranges smu_set_watermarks_table navi10_set_watermarks_table smu_write_watermarks_table For Renoir, clock settings of dcn watermark are also fixed values. dc has implemented different flow for window driver: dc_hardware_init / dc_set_power_state dcn10_init_hw notify_wm_ranges set_wm_ranges For Linux smu_set_watermarks_for_clock_ranges renoir_set_watermarks_table smu_write_watermarks_table dc_hardware_init -> amdgpu_dm_init dc_set_power_state --> dm_resume therefore, linux dc-pplib interface of navi10/12/14 is different from that of Renoir. v2: add missing unlock in error case Signed-off-by: Hersen Wu <hersenxs.wu@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amd/powerplay: map mclk to fclk for COMBINATIONAL_BYPASS casePrike Liang
When hit COMBINATIONAL_BYPASS the mclk will be bypass and can export fclk frequency to user usage. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-03-05drm/amd/powerplay: fix pre-check condition for setting clock rangePrike Liang
This fix will handle some MP1 FW issue like as mclk dpm table in renoir has a reverse dpm clock layout and a zero frequency dpm level as following case. cat pp_dpm_mclk 0: 1200Mhz 1: 1200Mhz 2: 800Mhz 3: 0Mhz Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-03-05drm/amd/display: fix dcc swath size calculations on dcn1Josip Pavic
[Why] Swath sizes are being calculated incorrectly. The horizontal swath size should be the product of block height, viewport width, and bytes per element, but the calculation uses viewport height instead of width. The vertical swath size is similarly incorrectly calculated. The effect of this is that we report the wrong DCC caps. [How] Use viewport width in the horizontal swath size calculation and viewport height in the vertical swath size calculation. Signed-off-by: Josip Pavic <Josip.Pavic@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amd/display: Clear link settings on MST disable connectorBhawanpreet Lakha
[Why] If we have a single MST display and we disconnect it, we dont disable that link. This causes the old link settings to still exist Now on a replug for MST we think its a link loss and will try to reallocate mst payload which will fail, throwing warning below. [ 129.374192] [drm] Failed to updateMST allocation table forpipe idx:0 [ 129.374206] ------------[ cut here ]------------ [ 129.374284] WARNING: CPU: 14 PID: 1710 at drivers/gpu/drm/amd/amdgpu/../dal-dev/dc/core/dc_link.c:3153 dc_link_allocate_mst_payload+0x1f7/0x220 [amdgpu] [ 129.374285] Modules linked in: amdgpu(OE) amd_iommu_v2 gpu_sched ttm drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect sysimgblt binfmt_misc nls_iso8859_1 edac_mce_amd snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio kvm snd_hda_codec_hdmi snd_hda_intel snd_intel_nhlt snd_hda_codec irqbypass snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi crct10dif_pclmul snd_seq crc32_pclmul ghash_clmulni_intel snd_seq_device snd_timer snd aesni_intel eeepc_wmi crypto_simd asus_wmi joydev cryptd sparse_keymap input_leds soundcore video glue_helper wmi_bmof mxm_wmi k10temp ccp mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic usbhid hid igb i2c_algo_bit ahci dca i2c_piix4 libahci gpio_amdpt wmi gpio_generic [ 129.374318] CPU: 14 PID: 1710 Comm: kworker/14:2 Tainted: G W OE 5.4.0-rc7bhawan+ #480 [ 129.374318] Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 0515 03/30/2017 [ 129.374397] Workqueue: events dm_irq_work_func [amdgpu] [ 129.374468] RIP: 0010:dc_link_allocate_mst_payload+0x1f7/0x220 [amdgpu] [ 129.374470] Code: 52 20 e8 1c 63 ad f4 48 8b 5d d0 65 48 33 1c 25 28 00 00 00 b8 01 00 00 00 75 16 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <0f> 0b e9 fa fe ff ff e8 ed 5b d6 f3 41 0f b6 b6 c4 02 00 00 48 c7 [ 129.374471] RSP: 0018:ffff9f9141e7fcc0 EFLAGS: 00010246 [ 129.374472] RAX: 0000000000000000 RBX: ffff91ef0762f800 RCX: 0000000000000000 [ 129.374473] RDX: 0000000000000005 RSI: ffffffffc0c4a988 RDI: 0000000000000004 [ 129.374474] RBP: ffff9f9141e7fd10 R08: 0000000000000005 R09: 0000000000000000 [ 129.374475] R10: 0000000000000002 R11: 0000000000000001 R12: ffff91eebd510c00 [ 129.374475] R13: ffff91eebd510e58 R14: ffff91ef052c01b8 R15: 0000000000000006 [ 129.374476] FS: 0000000000000000(0000) GS:ffff91ef0ef80000(0000) knlGS:0000000000000000 [ 129.374477] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 129.374478] CR2: 000055623ea01d50 CR3: 0000000408a8c000 CR4: 00000000003406e0 [ 129.374479] Call Trace: [ 129.374550] dc_link_reallocate_mst_payload+0x12e/0x150 [amdgpu] [ 129.374617] dc_link_handle_hpd_rx_irq+0x6d4/0x6e0 [amdgpu] [ 129.374693] handle_hpd_rx_irq+0x77/0x310 [amdgpu] [ 129.374768] dm_irq_work_func+0x53/0x70 [amdgpu] [ 129.374774] process_one_work+0x1fd/0x3f0 [ 129.374776] worker_thread+0x255/0x410 [ 129.374778] kthread+0x121/0x140 [ 129.374780] ? process_one_work+0x3f0/0x3f0 [ 129.374781] ? kthread_park+0x90/0x90 [ 129.374785] ret_from_fork+0x22/0x40 [How] when we disable MST we should clear the cur link settings (lane_count=0 is good enough). This will cause us to not reallocate payloads earlier than expected and not throw the warning Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Reviewed-by: Hersen Wu <hersenxs.wu@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2020-03-05drm/amdgpu: disable 3D pipe 1 on Navi1xTianci.Yin
[why] CP firmware decide to skip setting the state for 3D pipe 1 for Navi1x as there is no use case. [how] Disable 3D pipe 1 on Navi1x. Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Reviewed-by: Monk Liu <monk.liu@amd.com> Signed-off-by: Tianci.Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2020-03-05Merge series "TCFQ to XSPI migration for NXP DSPI driver" from Vladimir ↵Mark Brown
Oltean <olteanv@gmail.com> Vladimir Oltean <vladimir.oltean@nxp.com>: From: Vladimir Oltean <vladimir.oltean@nxp.com> This series aims to remove the most inefficient transfer method from the NXP DSPI driver. TCFQ (Transfer Complete Flag) mode works by transferring one word, waiting for its TX confirmation interrupt (or polling on the equivalent status bit), sending the next word, etc, until the buffer is complete. The issue with this mode is that it's fundamentally incompatible with any sort of batching such as writing to a FIFO. But actually, due to previous patchset ("Compatible string consolidation for NXP DSPI driver"): https://patchwork.kernel.org/cover/11414593/ all existing users of TCFQ mode today already support a more advanced feature set, in the form of XSPI (extended SPI). XSPI brings 2 extra features: - Word sizes up to 32 bits. This is sub-utilized today, and acceleration of smaller-than-32 bpw values is provided. - "Command cycling", basically the ability to write multiple words in a row and receiving an interrupt only after the completion of the last one. This is what enables us to make use of the full FIFO depth of this controller. Series was tested on the NXP LS1021A-TSN and LS1043A-RDB boards, both functionally as well as from a performance standpoint. The command used to benchmark the increased throughput was: spidev_test --device /dev/spidev1.0 --bpw 8 --size 256 --cpha --iter 10000000 --speed 20000000 where spidev1.0 is a dummy spidev node, using a chip select that no peripheral responds to. On LS1021A, which has a 4-entry-deep FIFO and a less powerful CPU, the performance increase brought by this patchset is from 2700 kbps to 5800 kbps. On LS1043A, which has a 16-entry-deep FIFO and a more powerful CPU, the performance increases from 4100 kbps to 13700 kbps. On average, SPI software timestamping is not adversely affected by the extra batching, due to the extra patches. There is one extra patch which clarifies why the TCFQ users were not converted to the "other" mode in this driver that makes use of the FIFO, which would be EOQ mode. My request to the many people on CC (known users and/or contributors) is to give this series a test to ensure there are no regressions, and for the Coldfire maintainers to clarify whether the EOQ limitation is acceptable for them in the long run. Vladimir Oltean (12): spi: spi-fsl-dspi: Simplify bytes_per_word gymnastics spi: spi-fsl-dspi: Remove unused chip->void_write_data spi: spi-fsl-dspi: Don't mask off undefined bits spi: spi-fsl-dspi: Add comments around dspi_pop_tx and dspi_push_rx functions spi: spi-fsl-dspi: Rename fifo_{read,write} and {tx,cmd}_fifo_write spi: spi-fsl-dspi: Implement .max_message_size method for EOQ mode spi: Do spi_take_timestamp_pre for as many times as necessary spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO mode spi: spi-fsl-dspi: Accelerate transfers using larger word size if possible spi: spi-fsl-dspi: Optimize dspi_setup_accel for lowest interrupt count spi: spi-fsl-dspi: Use EOQ for last word in buffer even for XSPI mode spi: spi-fsl-dspi: Take software timestamp in dspi_fifo_write drivers/spi/spi-fsl-dspi.c | 421 ++++++++++++++++++++++++------------- drivers/spi/spi.c | 19 +- include/linux/spi/spi.h | 3 +- 3 files changed, 288 insertions(+), 155 deletions(-) -- 2.17.1
2020-03-05spi: spi-fsl-dspi: Make bus-num property optionalSascha Hauer
The SPI bus number is completely optional to Linux, so make the corresponding device tree property optional as well. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/r/20200305115546.31814-1-s.hauer@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05spi: spi-nxp-fspi: Enable the Octal Mode in MCR0Han Xu
Apply patch from NXP upstream repo to Enable the octal combination mode in MCR0 Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20200126140913.2139260-3-aford173@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05spi: fspi: dynamically alloc AHB memoryHan Xu
Apply patch from NXP upstream repo to dynamically allocate AHB memory as needed. Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20200126140913.2139260-2-aford173@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05spi: fspi: enable fspi on imx8qxp and imx8mmHan Xu
Pull in this patch from NXP's upstream repo to enable fspi on imx8qxp and imx8mm Signed-off-by: Adam Ford <aford173@gmail.com> Signed-off-by: Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20200126140913.2139260-1-aford173@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05HID: hyperv: NULL check before some freeing functions is not needed.Lucas Tanure
Fix below warnings reported by coccicheck: drivers/hid/hid-hyperv.c:197:2-7: WARNING: NULL check before some freeing functions is not needed. drivers/hid/hid-hyperv.c:211:2-7: WARNING: NULL check before some freeing functions is not needed. Signed-off-by: Lucas Tanure <tanure@linux.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Reviewed-by: Wei Liu <wei.liu@kernel.org> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Wei Liu <wei.liu@kernel.org>
2020-03-05spi: spi-fsl-dspi: Take software timestamp in dspi_fifo_writeVladimir Oltean
Although the SPI system timestamps are supposed to reflect the moment that the peripheral has received a word rather than the moment when the CPU has enqueued that word to the FIFO, in practice it is easier to just record the latter time than the former (with a smaller error). With the recent migration of TCFQ users from poll back to interrupt mode (this time for XSPI FIFO), it's wiser to keep the interrupt latency outside of the measurement of the PTP system timestamp itself. If there proves to be any constant offset that requires static compensation, that can always be added later. So far that does not appear to be the case at least on the LS1021A-TSN board, where testing shows that the phc2sys offset is able to remain within +/- 200 ns even after 68 hours of testing. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-13-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05spi: spi-fsl-dspi: Use EOQ for last word in buffer even for XSPI modeVladimir Oltean
The EOQ mode has a hardware limitation in that it stops the transmission (including the deassertion of the chip select signal) once the host CPU requests end-of-queue for a particular word in the TX FIFO. And XSPI mode has a limitation in that we need a separate CMD FIFO entry for the last byte in the buffer, where the chip select signal needs to be deasserted. It's not a functional limitation, but it's rather clunky and the fact that we need to halt the pipeline and write a single entry to the TX FIFO whenever a buffer ends brings the throughput down when transmitting small buffers. So the idea here is to use EOQ's limitation in our favor when using XSPI mode. Stop special-casing that final word in the buffer, and just kill the chip select signal by issuing an EOQ for that last word. Now it can be mixed in with all the other words in the current TX FIFO train. A small trick here is that we still keep using the XSPI-specific signaling via the CMDTCFQ interrupt in RSER, and not enabling the EOQ interrupt, in order to avoid hardware weirdness (potential races with separate interrupts being raised for CMDTCFQ and EOQ for what is in fact the end of the same transmission). That is just theoretical, but it's good to be cautious, and the EOQ interrupt isn't needed. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-12-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05spi: spi-fsl-dspi: Optimize dspi_setup_accel for lowest interrupt countVladimir Oltean
Currently, a SPI transfer that is not multiple of the highest supported word width (e.g. 4 bytes) will be transmitted as follows (assume a 30-byte buffer transmitted through a 32-bit wide FIFO that is 32 bytes deep): - First 28 bytes are sent as 7 words of 32 bits each - Last 2 bytes are sent as 1 word of 16 bits size But if the dspi_setup_accel function had decided to use a lower oper_bits_per_word value (16 instead of 32), there would have been enough space in the TX FIFO to fit the entire buffer in one go (15 words of 16 bits each). What we're actually trying to avoid is mixing word sizes within the same run with the TX FIFO, since there is an erratum surrounding this, and invalid data might get transmitted. So this patch adds special cases for when the remaining length of the buffer can be sent in one go as 8-bit or 16-bit words, otherwise it falls back to the standard logic of sending as many bytes as possible at the highest oper_bits_per_word value possible. The benefit is that there will be one less CMDFQ/EOQ interrupt to service when the entire buffer is transmitted during a single go, and that will improve the overall latency of the transfer. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-11-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05spi: spi-fsl-dspi: Accelerate transfers using larger word size if possibleVladimir Oltean
This patch adds logic in the driver to transmit SPI buffers that use bits_per_word=8 with a higher bits_per_word count (multiple of 8). Currently the following (most common) modes are implemented: - 8 bits_per_word on 32-bit capable controllers - 8 bits_per_word on 16-bit capable controllers - 16 bits_per_word on 32-bit capable controllers Transfers which are not accelerated are transferred with a hardware bits_per_word value equal to the one of the SPI transfer. The difference from just extending bits_per_word=32 at the spi_device driver level is that endianness is different - the SPI core wants to treat bits_per_word=32 buffers as arrays of u32 (i.e. words in host CPU endianness). So to preserve endianness when clumping 8x4 bits into 32-bit words, one must perform conversion between CPU and standard (big) endianness. All appearances (both on the wire as well as in the buffers presented to the peripheral driver) are preserved, just that accesses to the PUSHR and POPR registers are now more efficient, since the same number of reads/writes can now carry more data (2x more data on TX, 4x more data on RX). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-10-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-03-05spi: spi-fsl-dspi: Convert TCFQ users to XSPI FIFO modeVladimir Oltean
The Transfer Complete Flag (TCF) interrupt gets raised after each write to the TX FIFO (PUSHR) which means that it is not possible to devise a transfer procedure that makes full utilization of the FIFO depth (4 entries on most controllers, 16 entries on some). On the other hand, XSPI mode has a feature called "command cycling", which allows a single TX command to be run for a pre-specified number of TX words. When the command cycle ends, the Command Transfer Complete Flag bit asserts and raises an interrupt. The advantage in this mode is that the TX FIFO can be better utilized (more words can be batched at once). Other changes brought by this patch: - The dspi->rx_end variable has been removed, since now the dspi_fifo_write function sets up dspi->words_in_flight, so dspi_fifo_read knows how much to read without overrunning the RX buffer. - Stop using poll mode unconditionally for TCFQ mode, since XSPI mode is a little less efficient than that, and so, poll mode doesn't bring as many improvements for XSPI. - Stop relying on the hardware transfer counter (SPI_TCR_GET_TCNT) and instead increment the message->actual_length based on the newly introduced dspi->words_in_flight variable. - The CTARE register is now written in the hotpath instead of just at transfer init time, since it contains the DTCP field (transfer preload - the counter indicating how many txdata words will follow), which is a dynamic value. Due to the fact that the Chip Select toggling setting is part of the command written to the TX FIFO, the ending word of each buffer needs to be sent via its own TX command, so that we have a chance to emit a 1-word command with deasserted PCS. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20200304220044.11193-9-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-16 08:27:32 +0000