summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-04-14ext4: move s_reserved_gdt_blocks and addressable checking into ↵Jason Yan
ext4_check_geometry() These two checkings are more suitable to be put into ext4_check_geometry() rather than spreading outside. Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20230323140517.1070239-7-yanaijie@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: rename two functions with 'check'Jason Yan
The naming styles are different for some functions with 'check' in their names. Some of them are like: ext4_check_quota_consistency ext4_check_test_dummy_encryption ext4_check_opt_consistency ext4_check_descriptors ext4_check_feature_compatibility While the others looks like below: ext4_geometry_check ext4_journal_data_mode_check This is not a big deal and boils down to personal preference. But I'd like to make them consistent. Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20230323140517.1070239-6-yanaijie@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: factor out ext4_flex_groups_free()Jason Yan
Factor out ext4_flex_groups_free() and it can be used both in __ext4_fill_super() and ext4_put_super(). Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20230323140517.1070239-5-yanaijie@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: use ext4_group_desc_free() in ext4_put_super() to save some duplicated ↵Jason Yan
code The only difference here is that ->s_group_desc and ->s_flex_groups share the same rcu read lock here but it is not necessary. In other places they do not share the lock at all. Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20230323140517.1070239-4-yanaijie@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: factor out ext4_percpu_param_init() and ext4_percpu_param_destroy()Jason Yan
Factor out ext4_percpu_param_init() and ext4_percpu_param_destroy(). And also use ext4_percpu_param_destroy() in ext4_put_super() to avoid duplicated code. No functional change. Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20230323140517.1070239-3-yanaijie@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: factor out ext4_hash_info_init()Jason Yan
Factor out ext4_hash_info_init() to simplify __ext4_fill_super(). No functional change. Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20230323140517.1070239-2-yanaijie@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14Merge branch 'page_pool-allow-caching-from-safely-localized-napi'Jakub Kicinski
Jakub Kicinski says: ==================== page_pool: allow caching from safely localized NAPI I went back to the explicit "are we in NAPI method", mostly because I don't like having both around :( (even tho I maintain that in_softirq() && !in_hardirq() is as safe, as softirqs do not nest). Still returning the skbs to a CPU, tho, not to the NAPI instance. I reckon we could create a small refcounted struct per NAPI instance which would allow sockets and other users so hold a persisent and safe reference. But that's a bigger change, and I get 90+% recycling thru the cache with just these patches (for RR and streaming tests with 100% CPU use it's almost 100%). Some numbers for streaming test with 100% CPU use (from previous version, but really they perform the same): HW-GRO page=page before after before after recycle: cached: 0 138669686 0 150197505 cache_full: 0 223391 0 74582 ring: 138551933 9997191 149299454 0 ring_full: 0 488 3154 127590 released_refcnt: 0 0 0 0 alloc: fast: 136491361 148615710 146969587 150322859 slow: 1772 1799 144 105 slow_high_order: 0 0 0 0 empty: 1772 1799 144 105 refill: 2165245 156302 2332880 2128 waive: 0 0 0 0 v1: https://lore.kernel.org/all/20230411201800.596103-1-kuba@kernel.org/ rfcv2: https://lore.kernel.org/all/20230405232100.103392-1-kuba@kernel.org/ ==================== Link: https://lore.kernel.org/r/20230413042605.895677-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-14bnxt: hook NAPIs to page poolsJakub Kicinski
bnxt has 1:1 mapping of page pools and NAPIs, so it's safe to hoook them up together. Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Tested-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-14page_pool: allow caching from safely localized NAPIJakub Kicinski
Recent patches to mlx5 mentioned a regression when moving from driver local page pool to only using the generic page pool code. Page pool has two recycling paths (1) direct one, which runs in safe NAPI context (basically consumer context, so producing can be lockless); and (2) via a ptr_ring, which takes a spin lock because the freeing can happen from any CPU; producer and consumer may run concurrently. Since the page pool code was added, Eric introduced a revised version of deferred skb freeing. TCP skbs are now usually returned to the CPU which allocated them, and freed in softirq context. This places the freeing (producing of pages back to the pool) enticingly close to the allocation (consumer). If we can prove that we're freeing in the same softirq context in which the consumer NAPI will run - lockless use of the cache is perfectly fine, no need for the lock. Let drivers link the page pool to a NAPI instance. If the NAPI instance is scheduled on the same CPU on which we're freeing - place the pages in the direct cache. With that and patched bnxt (XDP enabled to engage the page pool, sigh, bnxt really needs page pool work :() I see a 2.6% perf boost with a TCP stream test (app on a different physical core than softirq). The CPU use of relevant functions decreases as expected: page_pool_refill_alloc_cache 1.17% -> 0% _raw_spin_lock 2.41% -> 0.98% Only consider lockless path to be safe when NAPI is scheduled - in practice this should cover majority if not all of steady state workloads. It's usually the NAPI kicking in that causes the skb flush. The main case we'll miss out on is when application runs on the same CPU as NAPI. In that case we don't use the deferred skb free path. Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com> Tested-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-14net: skb: plumb napi state thru skb freeing pathsJakub Kicinski
We maintain a NAPI-local cache of skbs which is fed by napi_consume_skb(). Going forward we will also try to cache head and data pages. Plumb the "are we in a normal NAPI context" information thru deeper into the freeing path, up to skb_release_data() and skb_free_head()/skb_pp_recycle(). The "not normal NAPI context" comes from netpoll which passes budget of 0 to try to reap the Tx completions but not perform any Rx. Use "bool napi_safe" rather than bare "int budget", the further we get from NAPI the more confusing the budget argument may seem (particularly whether 0 or MAX is the correct value to pass in when not in NAPI). Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Tested-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-14Revert "ext4: Fix warnings when freezing filesystem with journaled data"Jan Kara
After making ext4_writepages() properly clean all pages there is no need for special treatment of filesystem freezing. Revert commit e6c28a26b799c7640b77daff3e4a67808c74381c. Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-13-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: Update comment in mpage_prepare_extent_to_map()Jan Kara
Since filemap_write_and_wait() is now enough to get journalled data to final location update the comment in mpage_prepare_extent_to_map(). Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-12-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: Simplify handling of journalled data in ext4_bmap()Jan Kara
Now that ext4_writepages() gets journalled data into its final location we just use filemap_write_and_wait() instead of special handling of journalled data in ext4_bmap(). We can also drop EXT4_STATE_JDATA flag as it is not used anymore. Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-11-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: Drop special handling of journalled data from ext4_quota_on()Jan Kara
Now that ext4_writepages() makes sure all journalled data is committed and checkpointed, sync_filesystem() call done by dquot_quota_on() is enough for quota IO to see uptodate data. So drop special handling of journalled data from ext4_quota_on(). Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-10-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: Drop special handling of journalled data from ext4_evict_inode()Jan Kara
Now that ext4_writepages() makes sure journalled data is on stable storage, write_inode_now() call in iput_final() is enough to make pagecache pages with journalled data really clean (data committed and checkpointed). So we can drop special handling of journalled data in ext4_evict_inode(). Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-9-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: Fix special handling of journalled data from extent zeroingJan Kara
The handling of journalled data in ext4_zero_range() is incomplete. We do not need to commit running transaction but we rather need to checkpoint pages with journalled data. If we don't, journal tail can be advanced beyond transaction containing the journalled data and if we then crash before committing the transaction doing the zeroing we will have inconsistent (too old) data in the file. Make sure file pages with journalled data are properly checkpointed before removing them from the page cache. Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-8-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: Drop special handling of journalled data from extent shifting operationsJan Kara
Now that filemap_write_and_wait() makes sure pages with journalled data are safely on disk, ext4_collapse_range() and ext4_insert_range() do not need special handling of journalled data. Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-7-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: Drop special handling of journalled data from ext4_sync_file()Jan Kara
Now that ext4_writepages() make sure all pages with journalled data are stable on disk, we don't need special handling of journalled data in ext4_sync_file(). Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-6-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: Commit transaction before writing back pages in data=journal modeJan Kara
When journalling data we currently just walk over pages, journal those that are marked for delayed dirtying (only pinned pages dirtied behing our back these days) and checkpoint other dirty pages. Because some pages may be part of running transaction the result is that after filemap_write_and_wait() we are not guaranteed pages are stable on disk. Thus places that want to flush current pagecache content need to jump through hoops to make sure journalled data is not lost. This is manageable in cases completely controlled by ext4 (such as extent shifting operations or inode eviction) but it gets ugly for stuff like fsverity. Furthermore it is rather error prone as people often do not realize journalled data needs special handling. So change ext4_writepages() to commit transaction with inode's data before going through the writeback loop in WB_SYNC_ALL mode. As a result filemap_write_and_wait() is now really getting pages to stable storage and makes pagecache pages safe to reclaim. Consequently we can remove the special handling of journalled data from several places in follow up patches. Note that this will make fsync(2) for journalled data more expensive as we will end up not only committing the transaction we need but also checkpointing the data (which we may have previously skipped if the data was part of the running transaction). If we really cared, we would need to introduce special VFS function for writing out & invalidating page cache for a range, use ->launder_page callback to perform checkpointing, and use it from all the places that need this functionality. But at this point I'm not convinced the complexity is worth it. Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-5-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: Clear dirty bit from pages without data to writeJan Kara
With journalled data it can happen that checkpointing code will write out page contents without clearing the page dirty bit. The logic in ext4_page_nomap_can_writeout() then results in us never calling mpage_submit_page() and thus clearing the dirty bit. Drop the optimization with ext4_page_nomap_can_writeout() and just always call to mpage_submit_page(). ext4_bio_write_page() knows when to redirty the page and the additional clearing & setting of page dirty bit for ordered mode writeout is not that expensive to jump through the hoops for it. Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-4-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: Keep pages with journalled data dirtyJan Kara
Currently we clear page dirty bit when we checkpoint some buffers from a page with journalled data or when we perform delayed dirtying of a page in ext4_writepages(). In a quest to simplify handling of journalled data we want to keep page dirty as long as it has either buffers to checkpoint or journalled dirty data. So make sure to keep page dirty in ext4_writepages() if it still has journalled data attached to it. Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-3-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14ext4: Mark pages with journalled data dirtyJan Kara
Currently pages with journalled data written by write(2) or modified by block zeroing during truncate(2) are not marked as dirty. They are dirtied only once the transaction commits. This however makes writeback code think inode has no pages to write and so ext4_writepages() is not called to make pages with journalled data persistent. Mark pages with journalled data dirty (similarly as it happens for writes through mmap) so that writeback code knows about them and ext4_writepages() can do what it needs to to the inode. Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-2-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14jdb2: Don't refuse invalidation of already invalidated buffersJan Kara
When invalidating buffers under the partial tail page, jbd2_journal_invalidate_folio() returns -EBUSY if the buffer is part of the committing transaction as we cannot safely modify buffer state. However if the buffer is already invalidated (due to previous invalidation attempts from ext4_wait_for_tail_page_commit()), there's nothing to do and there's no point in returning -EBUSY. This fixes occasional warnings from ext4_journalled_invalidate_folio() triggered by generic/051 fstest when blocksize < pagesize. Fixes: 53e872681fed ("ext4: fix deadlock in journal_unmap_buffer()") Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-1-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2023-04-14net/mlx5: DR, Enable patterns and arguments for supporting devicesYevgeny Kliteynik
Check if patterns and arguments for modify header action are supported and enable them accordingly. Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Add support for the pattern/arg parameters in debug dumpYevgeny Kliteynik
Support the pattern/args-based MODIFY_HDR and TNL_L3_TO_L2 actions in dbg dump Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Modify header action of size 1 optimizationYevgeny Kliteynik
Set modify header action of size 1 directly on the STE for supporting devices, thus reducing number of hops and cache misses. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Support decap L3 action using pattern / arg mechanismYevgeny Kliteynik
Use the new accelerated action for decap L3 on RX side: use the mechanism of pattern and argument same as in modify-header action. Signed-off-by: Erez Shitrit <erezsh@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Apply new accelerated modify action and decapl3Yevgeny Kliteynik
If there is support for pattern/args, use the new accelerated modify header action for modify header and decap L3 actions. Otherwise fall back to the old modify-header implementation. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Add modify header argument pointer to actions attributesYevgeny Kliteynik
While building the actions, add the pointer of the arguments for accelerated modify list action into the action's attributes. This will be used later on while building the specific STE for this action. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Add modify header arg pool mechanismYevgeny Kliteynik
Added new mechanism for handling arguments for modify-header action. The new action "accelerated modify-header" asks for the arguments from separated area from the pattern, this area accessed via general objects. Handling of these object is done via the pool-manager struct. When the new header patterns are supported, while loading the domain, a few pools for argument creations will be created. The requests for allocating/deallocating arg objects are done via the pool manager API. Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Fix QP continuous allocationYevgeny Kliteynik
When allocating a QP we allocate an RQ and an SQ, the RQ is stored first in memory and followed by the SQ. This allocation is not physically continiuos - it may span across different physical pages. SW Steering code always writes in pairs: 1BB write + 1BB read, or 2 continuous BBs of GTA WQE. This lead to an issue where RQ allocation was 4x16 which is equal to 1 WQE BB, causing 1 BB offset in the page and splitting the GTA WQE between different physical pages. The solution was to create the RQ with a even number of BBs and to have the RQ aligned to a page. Signed-off-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Read ICM memory into dedicated bufferYevgeny Kliteynik
Instead of using the write buffer for reading we will use a dedicated buffer only for reading ICM memory. Due to the new support for args, we can have a case with pending_wc being odd number, and with reading into the same write buffer, it is possible to overwrite next write on the same slot. For example: pending_wc is 17 so the buffer for write is: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | and we have requests as follows: r wr wr wr wr wr wr wr wr Now, the first read will be written into the last write because we use the same buffer for read and write, before it was written to the HW and we will have a wrong data in the ICM area. Signed-off-by: Erez Shitrit <erezsh@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Add support for writing modify header argumentYevgeny Kliteynik
The accelerated modify header arguments are written in the HW area with special WQE and specific data format. New function was added to support writing of new argument type. Note that GTA WQE is larger than READ and WRITE, so the queue management logic was updated to support this. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Add create/destroy for modify-header-argument general objectYevgeny Kliteynik
Add functions for creation/destruction of the new type of general object. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Check for modify_header_argument device capabilitiesYevgeny Kliteynik
Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Split chunk allocation to HW-dependent waysYevgeny Kliteynik
This way we are able to allocate chunk for modify_headers from 2 types: STEv0 that is allocated from the action area, and STEv1 that is allocating the chunks from the special area for patterns. Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Add cache for modify header patternYevgeny Kliteynik
Starting with ConnectX-6 Dx, we use new design of modify_header FW object. The current modify_header object allows for having only limited number of FW objects, so the new design of pattern and argument allows pattern reuse, saving memory, and having a large number of modify_header objects. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14net/mlx5: DR, Move ACTION_CACHE_LINE_SIZE macro to headerYevgeny Kliteynik
Move ACTION_CACHE_LINE_SIZE macro to header to be used by the pattern functions as well. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Reviewed-by: Alex Vesker <valex@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2023-04-14Merge tag 'v6.3-next-soc' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into soc/drivers mtk-svs: smaller coding style changes mtk-mutex: - add support for mt8365 display and mt8195 VPP mutex - add support for more then 32 mods - use module_platform_driver instead of open coding mtk-mmsys: - add support for mt8195 RSZ switching - add remove function - use module_platform_driver instead of open coding - split out mt8173 routing table from the legacy table - bump up resets in mt8173 to 64 - add support for mt6795 (Helio X10) - clean-up IS_REACHABLE code for cmdq * tag 'v6.3-next-soc' of https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux: (25 commits) soc: mediatek: Kconfig: Add MTK_CMDQ dependency to MTK_MMSYS soc: mediatek: mutex: Use dev_err_probe() soc: mediatek: mtk-mmsys: Add support for MT6795 Helio X10 soc: mediatek: mtk-mmsys: Change MT8173 num_resets to 64 soc: mediatek: mtk-mmsys: Split out MT8173 mmsys DDP routing table soc: mediatek: Cleanup ifdefs for IS_REACHABLE(CONFIG_MTK_CMDQ) soc: mediatek: cmdq: Add inline functions for !CONFIG_MTK_CMDQ soc: mediatek: mtk-mutex: Use module_platform_driver() macro soc: mediatek: mtk-mutex: Replace max handles number with definition soc: mediatek: mtk-mutex: Compress of_device_id array entries soc: mediatek: mtk-mmsys: Add MODULE_DEVICE_TABLE() to allow auto-load soc: mediatek: mtk-mmsys: Compress of_device_id array entries soc: mediatek: mtk-mmsys: Use module_platform_driver() macro soc: mediatek: mtk-mmsys: Add .remove() callback dt-bindings: soc: mediatek: add display mutex for MT8365 SoC dt-bindings: soc: mediatek: specify which compatible requires clocks property soc: mediatek: mtk-svs: add thermal voltage compensation if needed soc: mediatek: mtk-svs: fix passing zero to 'PTR_ERR' soc: mediatek: mtk-svs: delete node name check soc: mediatek: mutex: support MT8195 VPPSYS ... Link: https://lore.kernel.org/r/bc9f7a74-ce12-b323-021c-ff2c0473e979@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-04-14Merge tag 'v6.3-next-dts64' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into soc/dt mt6795 - enable frequency hopping controller (FHCTL) - add i2c, power domains and some clocks for video enconde/decode - Sony Xperia M5 enable touchscreen, proximity sensor, accelerometer and NFC mt8173 - align keys with DT binding mt8183 - enable GPU DVFS mt8186 - enable GPU mt8192 - enable GPU mt8195 - add mutex for Video Processor Pipeline Subsystem (VPP) - add support for Mali-G57 Valhall Natt GPU baked by panfrost - add support for display on vdosys1 - add thermal support - add display PWM mt8365 - add support for the eval kit including i2c, pmic-wrapper, mmc and ethernet * tag 'v6.3-next-dts64' of https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux: (50 commits) arm64: dts: mediatek: mt6795-xperia-m5: Add Bosch BMM050 Magnetometer arm64: dts: mediatek: mt6795-xperia-m5: Add Bosch BMA255 Accelerometer arm64: dts: mediatek: mt6795: Add tertiary PWM node arm64: dts: mediatek: mt8173: correct GPIO keys wakeup arm64: dts: mediatek: mt6795-xperia-m5: Add NXP PN547 NFC on I2C3 arm64: dts: mediatek: mt6795-xperia-m5: Add Sensortek STK3310 Proximity arm64: dts: mediatek: mt6795-xperia-m5: Add Synaptics RMI4 Touchscreen arm64: dts: mediatek: mt6795-xperia-m5: Enable I2C 0-3 busses arm64: dts: mediatek: mt6795: Add VDECSYS and VENCSYS clocks arm64: dts: mediatek: mt6795: Add SoC power domains arm64: dts: mediatek: mt6795: Add nodes for I2C controllers arm64: dts: mediatek: mt6795: xperia-m5: Enable Frequency Hopping arm64: dts: mediatek: mt6795: Add apmixedsys syscon node arm64: dts: mediatek: mt6795: Add Frequency Hopping Controller node arm64: dts: mediatek: cherry: Add configuration for display backlight arm64: dts: mediatek: mt8195: Add display pwm nodes arm64: dts: mediatek: mt8195: Add temperature mitigation threshold arm64: dts: mediatek: mt8195: Add thermal zones and thermal nodes arm64: dts: mediatek: add ethernet support for mt8365 SoC arm64: dts: mediatek: add mmc support for mt8365 SoC ... Link: https://lore.kernel.org/r/6920736b-ddb3-29df-d0b2-46db40cef49f@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-04-14Merge tag 'v6.3-next-dts32' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into soc/dt mt7623: Disable not exising home key mt2701: change node name to match DT bindings * tag 'v6.3-next-dts32' of https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux: arm: dts: mt7623: disable home key on Bananapi BPI-R2 arm: dts: mediatek: Fix existing NAND controller node name Link: https://lore.kernel.org/r/c3b17357-e08d-da7e-def0-a7f9e0b95cb7@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-04-14drm/amdgpu: add some basic elements for multiple XCD caseLe Ma
Add some basic definitions and structure member. Inscrease MAX_WB slots to 1024 to support the increasing number of rings for multiple partitions. v2: unify naming style Signed-off-by: Le Ma <le.ma@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-04-14drm/amdgpu: move vmhub out of amdgpu_ring_funcs (v4)Le Ma
It looks better to place this field in ring structure. Also drop the repeated ring funcs definitions if there's no difference except for vmhub field. v2: rename the field to vm_hub like others (Le) v3: apply the changes to new ip blocks (Hawking) v4: fix vcn sw ring (Alex) Signed-off-by: Le Ma <le.ma@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-04-14Revert "drm/amdgpu: enable ras for mp0 v13_0_10 on SRIOV"Jane Jian
This reverts commit fe120b9f5ce873516a2604e4ff0c19084be94e8c. This patch impacts sriov multi-vf stability Signed-off-by: Jane Jian <Jane.Jian@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-04-14drm/amdgpu: add common ip block for GC 9.4.3Hawking Zhang
Add common IP handling for GC 9.4.3 Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <Le.Ma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-04-14drm/amd/display: Add logging when DP link training Clock recovery is SuccessfulSrinivasan Shanmugam
Log when Clock recovery is successful, as part of DP link training process. Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-04-14drm/amdgpu: add common early init support for GC 9.4.3Hawking Zhang
init asic funcs and cp/pg flags for GC 9.4.3 Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <Le.Ma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-04-14drm/amdgpu: switch to v9_4_3 gfx_funcs callbacks for GC 9.4.3Hawking Zhang
add gfx_funcs callbacks implemenation based on gc_v9_4_3 ip headers Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-04-14drm/amd/display: Add logging when setting DP sink power state failsSrinivasan Shanmugam
Log if we fail to setup sink power states. Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-04-14drm/amdkfd: Add gfx_target_version for GC 9.4.3Graham Sider
Required for Thunk GFX version sysfs query. Signed-off-by: Graham Sider <Graham.Sider@amd.com> Reviewed-by: Amber Lin <Amber.Lin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>