- 30 Oct, 2020 4 commits
-
-
Steven Price authored
The mutex within the panfrost_queue_state should have the lifetime of the queue, however it was erroneously initialised/destroyed during panfrost_job_{open,close} which is called every time a client opens/closes the drm node. Move the initialisation/destruction to panfrost_job_{init,fini} where it belongs. Fixes: 1a11a88c ("drm/panfrost: Fix job timeout handling") Signed-off-by:Steven Price <steven.price@arm.com> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
-
Robin Murphy authored
According to a downstream commit I found in the Khadas vendor kernel, the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows how to handle this properly) we should describe it as such. Otherwise the mismatch leads to all manner of fun with mismatched attributes and inadvertently snooping stale data from caches, which would account for at least some of the brokenness observed on this platform. Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Tested-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
-
Robin Murphy authored
When the GPU's ACE-Lite interface is fully wired up and capable of snooping CPU caches, it may be described as "dma-coherent" in devicetree, which will already inform the DMA layer not to perform unnecessary cache maintenance. However, we still need to ensure that the GPU uses the appropriate cacheable outer-shareable attributes in order to generate the requisite snoop signals, and that CPU mappings don't create a mismatch by using a non-cacheable type either. Signed-off-by:
-
Robin Murphy authored
Midgard GPUs have ACE-Lite master interfaces which allows systems to integrate them in an I/O-coherent manner. It seems that from the GPU's viewpoint, the rest of the system is its outer shareable domain, and so even when snoop signals are wired up, they are only emitted for outer shareable accesses. As such, setting the TTBR_SHARE_OUTER bit does indeed get coherent pagetable walks working nicely for the coherent T620 in the Arm Juno SoC. Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
-
- 29 Oct, 2020 11 commits
-
-
Chris Wilson authored
We have a few displays in CI that always report their EDID as a bunch of zeroes. This is consistent behaviour, so one assumes intentional indication of an "absent" EDID. Flagging these consistent warnings detracts from CI. One option would be to ignore the zero EDIDs as intentional behaviour, but Ville would like to keep the information available for debugging. The simple alternative then is to reduce the loglevel for all the EDID dumping from WARN to DEBUG so the information is present but not annoy CI. Note that the bad EDID dumping is already only shown if drm.debug=KMS, it's just the loglevel chosen was set to be caught by CI if it ever occurred as it was expected to be an internal error not external. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2203Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201029213042.11672-1-chris@chris-wilson.co.uk
-
Christian König authored
Not used any more. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
Madhav Chauhan <madhav.chauhan@amd.com> Tested-by:
Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/397087/?series=83051&rev=1
-
Christian König authored
Not needed as far as I can see. Signed-off-by:
-
Christian König authored
Not needed as far as I can see. Signed-off-by:
-
Christian König authored
It should be able to handle all cases now. Signed-off-by:
-
Christian König authored
It should be able to handle all cases now. Signed-off-by:
-
Christian König authored
It should be able to handle all cases here. v2: fix debugfs as well Signed-off-by:
-
Christian König authored
It should be able to handle all cases here. v2: fix debugfs as well Signed-off-by:
-
Christian König authored
Provide the necessary parameters by all drivers and use the new pool alloc when no driver specific function is provided. v2: fix the GEM VRAM helpers Signed-off-by:
-
Christian König authored
This replaces the spaghetti code in the two existing page pools. First of all depending on the allocation size it is between 3 (1GiB) and 5 (1MiB) times faster than the old implementation. It makes better use of buddy pages to allow for larger physical contiguous allocations which should result in better TLB utilization at least for amdgpu. Instead of a completely braindead approach of filling the pool with one CPU while another one is trying to shrink it we only give back freed pages. This also results in much less locking contention and a trylock free MM shrinker callback, so we can guarantee that pages are given back to the system when needed. Downside of this is that it takes longer for many small allocations until the pool is filled up. We could address this, but I couldn't find an use case where this actually matters. We also don't bother freeing large chunks of pages any more since the CPU overhead in that path isn't really that important. The sysfs files are replaced with a single module parameter, allowing users to override how many pages should be globally pooled in TTM. This unfortunately breaks the UAPI slightly, but as far as we know nobody ever depended on this. Zeroing memory coming from the pool was handled inconsistently. The alloc_pages() based pool was zeroing it, the dma_alloc_attr() based one wasn't. For now the new implementation isn't zeroing pages from the pool either and only sets the __GFP_ZERO flag when necessary. The implementation has only 768 lines of code compared to the over 2600 of the old one, and also allows for saving quite a bunch of code in the drivers since we don't need specialized handling there any more based on kernel config. Additional to all of that there was a neat bug with IOMMU, coherent DMA mappings and huge pages which is now fixed in the new code as well. v2: make ttm_pool_apply_caching static as reported by the kernel bot, add some more checks v3: fix some more checkpatch.pl warnings Signed-off-by: -
Peter Ujfalusi authored
There is no need to use the of_dma_request_slave_channel() directly as dma_request_chan() is going to try to get the channel via OF as well. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Hyun Kwon <hyun.kwon@xilinx.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201023094602.5630-1-peter.ujfalusi@ti.com
-
- 28 Oct, 2020 2 commits
-
-
Peilin Ye authored
`width` and `height` are defined as unsigned in our UAPI font descriptor `struct console_font`. Make them unsigned in our kernel font descriptor `struct font_desc`, too. Also, change the corresponding printk() format identifiers from `%d` to `%u`, in sti_select_fbfont(). Signed-off-by:
Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201028105647.1210161-1-yepeilin.cs@gmail.com
-
Peilin Ye authored
Remove 6 unused extern variables to reduce confusion. It is worth mentioning that lib/fonts/font_8x8.c and lib/fonts/font_8x16.c also declare `fontdata_8x8` and `fontdata_8x16` respectively, and this file has nothing to do with them. Signed-off-by:
-
- 27 Oct, 2020 3 commits
-
-
Arnd Bergmann authored
The -Wmissing-field-initializer warning when building with W=2 turns into an error because tilcdc is built with -Werror: drm/tilcdc/tilcdc_drv.c:431:33: error: missing field 'data' initializer [-Werror,-Wmissing-field-initializers] { "regs", tilcdc_regs_show, 0 }, drm/tilcdc/tilcdc_drv.c:432:33: error: missing field 'data' initializer [-Werror,-Wmissing-field-initializers] { "mm", tilcdc_mm_show, 0 }, Add the missing field initializers to address the warning. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Jyri Sarha <jsarha@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201026194110.3817470-1-arnd@kernel.org
-
Daniel Vetter authored
It's the horror and shouldn't be used. Realized we're not clear on this in a discussion with Rob about what msm is doing to better support async commits. v2: Refine existing todo item to include this (Thomas) Cc: Sean Paul <sean@poorly.run> Cc: Rob Clark <robdclark@gmail.com> Acked-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201023123925.2374863-3-daniel.vetter@ffwll.ch
-
Arnd Bergmann authored
The open-coded list_for_each_entry() causes a harmless warning: drivers/video/fbdev/matrox/matroxfb_base.c: In function 'matroxfb_register_driver': include/linux/kernel.h:856:3: warning: array subscript -98 is outside array bounds of 'struct list_head[1]' [-Warray-bounds] Use the normal list_for_each_entry instead. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201026194010.3817166-1-arnd@kernel.org
-
- 26 Oct, 2020 5 commits
-
-
Simon Ser authored
DRM_FORMAT_MOD_NONE is in the list of vendors, which is pretty confusing. We already have DRM_FORMAT_MOD_VENDOR_NONE. Move it down in the list of format modifiers. DRM_FORMAT_MOD_NONE is an alias for DRM_FORMAT_MOD_LINEAR, however the name is confusing: NONE doesn't mean that the modifier is implicit, instead it means that the layout is linear. Deprecate it. Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by:
-
Christian König authored
It makes no difference to kmalloc if the structure is 48 or 64 bytes in size. Signed-off-by:
-
Christian König authored
We can still allocate 16TiB with that. Signed-off-by:
-
Christian König authored
This is not related to allocating the backing store in any way. Signed-off-by:
-
Christian König authored
Neither page allocation backend nor the driver should mess with that. Signed-off-by:
-
- 23 Oct, 2020 2 commits
-
-
Qinglang Miao authored
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Acked-by:
Liviu Dudau <liviu.dudau@arm.com> Tested-by:
Carsten Haitzler <carsten.haitzler@foss.arm.com> Signed-off-by:
-
Saeed Mirzamohammadi authored
This patch fixes the issue due to: [ 89.572883] divide_error: 0000 [#1] SMP KASAN PTI [ 89.572897] CPU: 3 PID: 16083 Comm: repro Not tainted 5.9.0-rc7.20200930.rc1.allarch-19-g3e32d0d.syzk #5 [ 89.572902] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.5.1 01/01/2011 [ 89.572934] RIP: 0010:cirrusfb_check_var+0x84/0x1260 The error happens when the pixels value is calculated before performing the sanity checks on bits_per_pixel. A bits_per_pixel set to zero causes divide by zero error. This patch moves the calculation after the sanity check. Signed-off-by:
Saeed Mirzamohammadi <saeed.mirzamohammadi@oracle.com> Tested-by:
-
- 22 Oct, 2020 5 commits
-
-
Dave Airlie authored
remove the overlapping memcp support as it's never used. Reviewed-by:
-
Maxime Ripard authored
If the DSI driver is the last to probe, component_add will try to run all the bind callbacks straight away and return the error code. However, since we depend on a power domain, we're pretty much guaranteed to be in that case on the BCM2711, and are just lucky on the previous SoCs since the v3d also depends on that power domain and is further in the probe order. In that case, the DSI host will not stick around in the system: the DSI bind callback will be executed, will not find any DSI device attached and will return EPROBE_DEFER, and we will then remove the DSI host and ask to be probed later on. But since that host doesn't stick around, DSI devices like the RaspberryPi touchscreen whose probe is not linked to the DSI host (unlike the usual DSI devices that will be probed through the call to mipi_dsi_host_register) cannot attach to the DSI host, and we thus end up in a situation where the DSI host cannot probe because the panel hasn't probed yet, and the panel cannot probe because the DSI host hasn't yet. In order to break this cycle, let's wait until there's a DSI device that attaches to the DSI host to register the component and allow to progress further. Acked-by:
Eric Anholt <eric@anholt.net> Suggested-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200707101912.571531-1-maxime@cerno.tech
-
Simon Ser authored
User-space should avoid parsing EDIDs for metadata already exposed via other KMS interfaces and properties. For instance, user-space should not try to extract a list of modes from the EDID: the kernel might mutate the mode list (because of link capabilities or quirks for instance). Other metadata not exposed by KMS can be parsed by user-space. This includes for instance monitor identification (make/model/serial) and supported color-spaces. v2: add short explanation why user-space shouldn't do this (Brian) Signed-off-by:
Brian Starkey <brian.starkey@arm.com> Acked-by:
-
Dave Airlie authored
The move notify callback is only used in one place, this should be removed in the future, but for now just rename it to the use case which is to notify the driver that the GPU memory is to be deleted. Drivers can be cleaned up after this separately. Reviewed-by:
-
Dave Airlie authored
Removed unused parameter. Reviewed-by:
-
- 21 Oct, 2020 8 commits
-
-
Daniel Vetter authored
It's the only ioctl handler purely for legacy drivers that didn't have this yet. Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Dave Airlie authored
This moves the call to tt binding into the driver move, and drops the driver callback. Reviewed-by:
-
Dave Airlie authored
The drivers now do this in the move callback. move_notify is still needed in the destroy path. Reviewed-by:
-
Dave Airlie authored
This show the remaining bind callback, which my next series of patches will aim to remove. Reviewed-by:
-
Dave Airlie authored
The drivers now control this, so drop unbinding. Reviewed-by:
-
Dave Airlie authored
This moves the to system move into the drivers, and moves all the unbinds in the move path under driver control Note: radeon/nouveau already wait so don't duplicate it. Reviewed-by:
-
Dave Airlie authored
resource free already sets the domain to system, and old_mem isn't really needed. Reviewed-by:
-
Dave Airlie authored
This just gives the driver control over some of the bind paths. Reviewed-by:
-
