- 08 Apr, 2022 9 commits
-
-
Maxime Ripard authored
When debugging, finding out what muxing decisions were made and what the actual core clock rate is is always useful, so let's add some more messages. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20220328153659.2382206-7-maxime@cerno.tech
-
Maxime Ripard authored
The documentation explicitly states we must prevent the output 2 and 3 from feeding from the same HVS channel. Let's add a warning to make some noise if we ever find ourselves in such a case. Signed-off-by:
-
Maxime Ripard authored
We use the channel from our vc4_crtc_state structure in multiple places, let's store it in a local variable to make it cleaner. Signed-off-by:
-
Maxime Ripard authored
If we use a format that has padding instead of the alpha component (such as XRGB8888), it appears that the Transposer will fill the padding to 0, disregarding what was stored in the input buffer padding. This leads to issues with IGT, since it will set the padding to 0xff, but will then compare the CRC of the two frames which will thus fail. Another nice side effect is that it is now possible to just use the buffer as ARGB. Fixes: 008095e0 ("drm/vc4: Add support for the transposer block") Signed-off-by:
-
Maxime Ripard authored
The TXP_VSTART_AT_EOF will generate a second VSTART signal to the HVS. However, the HVS waits for VSTART to enable the FIFO and will thus start filling the FIFO before the start of the frame. This leads to corruption at the beginning of the first frame, and content from the previous frame at the beginning of the next frames. Since one VSTART is enough, let's get rid of it. Fixes: 008095e0 ("drm/vc4: Add support for the transposer block") Signed-off-by:
-
Maxime Ripard authored
By default, the HVS driver will force the HVS output 3 to be muxed to the HVS channel 2. However, the Transposer can only be assigned to the HVS channel 2, so whenever we try to use the writeback connector, we'll mux its associated output (Output 2) to the channel 2. This leads to both the output 2 and 3 feeding from the same channel, which is explicitly discouraged in the documentation. In order to avoid this, let's reset all the output muxes to their reset value. Fixes: 87ebcd42 ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by:
-
Matthew Auld authored
All of CI is just failing with the following, which prevents loading of the module: i915 0000:03:00.0: [drm] *ERROR* Scratch setup failed Best guess is that this comes from the pin_map() for the scratch page, which does an i915_gem_object_wait_moving_fence() somewhere. It looks like this now calls into dma_resv_wait_timeout() which can return the remaining timeout, leading to the caller thinking this is an error. v2(Lucas): handle ret == 0 Fixes: 1d7f5e6c ("drm/i915: drop bo->moving dependency") Signed-off-by:Matthew Auld <matthew.auld@intel.com> Cc: Christian König <christian.koenig@amd.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Christian König <christian.koenig@amd.com> #v1 Link: https://patchwork.freedesktop.org/patch/msgid/20220408084205.1353427-1-matthew.auld@intel.comSigned-off-by:
Christian König <christian.koenig@amd.com>
-
Arunpravin Paneer Selvam authored
- Switch to drm buddy allocator - Add resource cursor support for drm buddy v2(Matthew Auld): - replace spinlock with mutex as we call kmem_cache_zalloc (..., GFP_KERNEL) in drm_buddy_alloc() function - lock drm_buddy_block_trim() function as it calls mark_free/mark_split are all globally visible v3(Matthew Auld): - remove trim method error handling as we address the failure case at drm_buddy_block_trim() function v4: - fix warnings reported by kernel test robot <lkp@intel.com> v5: - fix merge conflict issue v6: - fix warnings reported by kernel test robot <lkp@intel.com> v7: - remove DRM_BUDDY_RANGE_ALLOCATION flag usage v8: - keep DRM_BUDDY_RANGE_ALLOCATION flag usage - resolve conflicts created by drm/amdgpu: remove VRAM accounting v2 v9(Christian): - merged the below patch - drm/amdgpu: move vram inline functions into a header - rename label name as fallback - move struct amdgpu_vram_mgr to amdgpu_vram_mgr.h - remove unnecessary flags from struct amdgpu_vram_reservation - rewrite block NULL check condition - change else style as per coding standard - rewrite the node max size - add a helper function to fetch the first entry from the list v10(Christian): - rename amdgpu_get_node() function name as amdgpu_vram_mgr_first_block v11: - if size is not aligned with min_page_size, enable is_contiguous flag, therefore, the size round up to the power of two and trimmed to the original size. v12: - rename the function names having prefix as amdgpu_vram_mgr_*() - modify the round_up() logic conforming to contiguous flag enablement or if size is not aligned to min_block_size - modify the trim logic - rename node as block wherever applicable Signed-off-by:Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Acked-by:
-
Matthew Auld authored
I guess this was missed in the conversion or something. Fixes: 7bc80a54 ("dma-buf: add enum dma_resv_usage v4") Signed-off-by:
-
- 07 Apr, 2022 31 commits
-
-
Daniel Vetter authored
Accessing the one in fbmem.c without taking the right locks is a bad idea. Instead maintain our own private copy, which is fully protected by console_lock() (like everything else in fbcon.c). That copy is serialized through fbcon_fb_registered/unregistered() calls. Also this means we do not need to hold a full fb_info reference, which is nice because doing so would mean a refcount loop between the console and the fb_info. But it's also not nice since it means console_lock() must be held absolutely everywhere. Well strictly speaking we could still try to do some refcounting games again by calling get_fb_info before we drop the console_lock. But things will get tricky. Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Claudio Suarez <cssk@net-c.es> Cc: Du Cheng <ducheng2@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220405210335.3434130-18-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
There's a bunch of confusions going on here: - The deferred fbcon setup notifier should only be cleaned up from fb_console_exit(), to be symmetric with fb_console_init() - We also need to make sure we don't race with the work, which means temporarily dropping the console lock (or we can deadlock) - That also means no point in clearing deferred_takeover, we are unloading everything anyway. - Finally rename fbcon_exit to fbcon_release_all and move it, since that's what's it doing when being called from consw->con_deinit through fbcon_deinit. To answer a question from Sam just quoting my own reply: > We loose the call to fbcon_release_all() here [in fb_console_exit()]. > We have part of the old fbcon_exit() above, but miss the release parts. Ah yes that's the entire point of this change. The release_all in the fbcon exit path was only needed when fbcon was a separate module indepedent from core fb.ko. Which means it was possible to unload fbcon while having fbdev drivers registered. But since we've merged them that has become impossible, so by the time the fb.ko module can be unloaded, there's guaranteed to be no fbdev drivers left. And hence removing them is pointless. v2: Explain the why better (Sam) Acked-by:
-
Daniel Vetter authored
con2fb_release_oldinfo() has a bunch more kfree() calls than fbcon_exit(), but since kfree() on NULL is harmless doing that in both places should be ok. This is also a bit more symmetric now again with fbcon_open also allocating the fbcon_ops structure. Acked-by:
-
Daniel Vetter authored
Ideally console_lock becomes an implementation detail of fbcon.c and doesn't show up anywhere in fbmem.c. We're still pretty far from that, but at least the register/unregister code is there now. With this the do_fb_ioctl() handler is the only code in fbmem.c still calling console_lock(). Acked-by:
-
Daniel Vetter authored
This shouldn't be a problem in practice since until we've actually taken over the console there's nothing we've registered with the console/vt subsystem, so the exit/unbind path that check this can't do the wrong thing. But it's confusing, so fix it by moving it a tad later. Acked-by:
-
Daniel Vetter authored
Now we get to the real motiviation, because fbmem.c insists that that's the right lock for these. Ofc fbcon.c has a lot more places where it probably should call lock_fb_info(). But looking at fbmem.c at least most of these seem to be protected by console_lock() too, which is probably what papers over any issues. Note that this means we're shuffling around a bit the locking sections for some of the console takeover and unbind paths, but not all: - console binding/unbinding from the console layer never with lock_fb_info - unbind (as opposed to unlink) never bother with lock_fb_info Also the real serialization against set_par and set_pan are still doing by wrapping the entire ioctl code in console_lock(). So this shuffling shouldn't be worse than what we had from a "can you trigger races?" pov, but it's at least clearer. Acked-by:
-
Daniel Vetter authored
No idea why con2fb_acquire_newinfo() initializes much less than fbcon_startup(), but so be it. From a quick look most of the un-initialized stuff should be fairly harmless, but who knows. Note that the error handling for the con2fb_acquire_newinfo() failure case was very strange: Callers updated con2fb_map to the new value before calling this function, but upon error con2fb_acquire_newinfo reset it to the old value. Since I removed the call to fbcon_release anyway that strange error path was sticking out like a sore thumb, hence I removed it. Which also allows us to remove the oldidx parameter from that function. v2: Explain what's going on with oldidx and error paths (Sam) v3: Drop unused variable (0day) v4: Rebased over bisect fix in previous patch, unchagend end result. Acked-by: Sam Ravnborg <sam@ravnborg.org> (v2) Acked-by:
-
Daniel Vetter authored
It doesn't ever fail anymore. Acked-by:
-
Daniel Vetter authored
There's two minor behaviour changes in here: - in error paths we now consistently call fb_ops->fb_release - fb_release really can't fail (fbmem.c ignores it too) and there's no reasonable cleanup we can do anyway. Note that everything in fbcon.c is protected by the big console_lock() lock (especially all the global variables), so the minor changes in ordering of setup/cleanup do not matter. v2: Explain a bit better why this is all correct (Sam) Acked-by:
-
Daniel Vetter authored
It was only used by fbcon, and that now switched to its own, private work. Acked-by:
-
Daniel Vetter authored
It's only one flag and slightly tidier code. Acked-by:
-
Daniel Vetter authored
Allows us to delete a bunch of hand-rolled stuff using a timer plus a separate work). Also to simplify the code we initialize the cursor_work completely when we allocate the fbcon_ops structure, instead of trying to cope with console re-initialization. The motiviation here is that fbcon code stops using the fb_info.queue, which helps with locking issues around cleanup and all that in a later patch. Also note that this allows us to ditch the hand-rolled work cleanup in fbcon_exit - we already call fbcon_del_cursor_timer, which takes care of everything. Plus this was racy anyway. v2: - Only INIT_DELAYED_WORK when kzalloc succeeded (Tetsuo) - Explain that we replace both the timer and a work with the combined delayed_work (Javier) Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
-
Daniel Vetter authored
fb_set_var requires we hold the fb_info lock. Or at least this now matches what the ioctl does ... Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here, but I will not fix them up. Also in practice this isn't a big deal, because really variable fbdev state is actually protected by console_lock (because fbcon just doesn't bother with lock_fb_info() at all), and lock_fb_info protecting anything is really just a neat lie. But that's a much bigger fish to fry. Acked-by:
-
Daniel Vetter authored
Before commit 6104c370 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Aug 1 17:32:07 2017 +0200 fbcon: Make fbcon a built-time depency for fbdev it was possible to load fbcon and fbdev drivers in any order, which means that fbcon init had to handle the case where fbdev drivers where already registered. This is no longer possible, hence delete that code. Note that the exit case is a bit more complex and will be done in a separate patch. Since I had to audit the entire fbcon load code I also spotted a wrong function name in a comment in fbcon_startup(), which this patch also fixes. v2: Explain why we also fix the comment (Sam) Acked-by:
-
Daniel Vetter authored
Half of it is protected by console_lock, but the other half is a lot more awkward: Registration/deregistration of fbdev are serialized, but we don't really clear out anything in con2fb_map and so there's potential for use-after free mixups. First step is to encapsulate the lookup. Acked-by:
-
Daniel Vetter authored
Avoids two forward declarations, and more importantly, matches what I've done in my fbcon scrolling restore patches - so I need this to avoid a bunch of conflicts in rebasing since we ended up merging Helge's series instead. Acked-by:
-
Daniel Vetter authored
I didn't bother with any code movement to fix the others, these just got a bit in the way. v2: Rebase on top of Helge's reverts. Acked-by:
-
Javier Martinez Canillas authored
The commit 73511edf ("dma-buf: specify usage while adding fences to dma_resv obj v7") ported all the DRM drivers to use the newer fence API that specifies the usage with the enum dma_resv_usage rather than doing an explicit shared / exclusive distinction. But the commit didn't do it properly in two callers of the vc4 driver, leading to build errors. Fixes: 73511edf ("dma-buf: specify usage while adding fences to dma_resv obj v7") Signed-off-by:
-
Chen-Yu Tsai authored
The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes. Add support for this display driver. The default values for some of the hardware settings are taken from the datasheet. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
-
Chen-Yu Tsai authored
On the SINO WEALTH SH1106, which is mostly compatible with the SSD1306, only the basic page addressing mode is supported. This addressing mode is not as easy to use compared to the currently supported horizontal addressing mode, as the page address has to be set prior to writing out each page, and each page must be written out separately as a result. Also, there is no way to force the column address to wrap around early, thus the column address must also be reset for each page to be accurate. Add support for this addressing mode, with a flag to choose it. This flag is designed to be set from the device info data structure, but can be extended to be explicitly forced on through a device tree property if such a need arises. Signed-off-by:
-
Chen-Yu Tsai authored
The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes. Add a compatible string for it. Signed-off-by:
-
Chen-Yu Tsai authored
Add a vendor prefix entry for SINO WEALTH Eletronics Ltd. (http://www.sinowealth.com). Signed-off-by:
-
Christian König authored
This isn't included here any more since the removal of ww_mutex.h from seqlock.h which causes a build break. Signed-off-by:
Shashank Sharma <shashank.sharma@amd.com> Fixes: e84815cb ("seqlock: drop seqcount_ww_mutex_t") Link: https://patchwork.freedesktop.org/patch/msgid/20220407114619.961750-1-christian.koenig@amd.com
-
Christian König authored
Daniel pointed out that this series removes the last user of seqcount_ww_mutex_t, so let's drop this. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220407085946.744568-16-christian.koenig@amd.com
-
Christian König authored
This should be possible now since we don't have the distinction between exclusive and shared fences any more. The only possible pitfall is that a dma_fence would be reused during the RCU grace period, but even that could be handled with a single extra check. Signed-off-by:
-
Christian König authored
This is now handled by the DMA-buf framework in the dma_resv obj. Also remove the workaround inside VMWGFX to update the moving fence. Signed-off-by:
-
Christian König authored
That should now be handled by the common dma_resv framework. Signed-off-by:
-
Christian König authored
We have previously done that in the individual drivers but it is more defensive to move that into the common code. Dynamic attachments should wait for map operations to complete by themselves. Signed-off-by:
-
Christian König authored
Add an usage for submissions independent of implicit sync but still interesting for memory management. v2: cleanup the kerneldoc a bit v3: separate amdgpu changes from this Signed-off-by:
-
Christian König authored
We only need to wait for kernel submissions here. Signed-off-by:
-
Christian König authored
Always wait for kernel fences before kmap and not only for UVD kmaps. Signed-off-by:
-
