aboutsummaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2023-12-22Merge tag 'drm-xe-next-2023-12-21-pr1-1' of ↵Dave Airlie3-0/+1547
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Introduce a new DRM driver for Intel GPUs Xe, is a new driver for Intel GPUs that supports both integrated and discrete platforms. The experimental support starts with Tiger Lake. i915 will continue be the main production driver for the platforms up to Meteor Lake and Alchemist. Then the goal is to make this Intel Xe driver the primary driver for Lunar Lake and newer platforms. It uses most, if not all, of the key drm concepts, in special: TTM, drm-scheduler, drm-exec, drm-gpuvm/gpuva and others. Signed-off-by: Dave Airlie <[email protected]> [airlied: add an extra X86 check, fix a typo, fix drm_exec_init interface change]. From: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-12-21entry: Move syscall_enter_from_user_mode() to header fileSven Schnelle1-2/+25
To allow inlining of syscall_enter_from_user_mode(), move it to entry-common.h. Signed-off-by: Sven Schnelle <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-12-21entry: Move enter_from_user_mode() to header fileSven Schnelle1-1/+14
To allow inlining of enter_from_user_mode(), move it to entry-common.h. Signed-off-by: Sven Schnelle <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-12-21entry: Move exit to usermode functions to header fileSven Schnelle1-1/+52
To allow inlining, move exit_to_user_mode() to entry-common.h. Signed-off-by: Sven Schnelle <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-12-21Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netPaolo Abeni12-136/+80
Cross-merge networking fixes after downstream PR. Adjacent changes: drivers/net/ethernet/broadcom/bnxt/bnxt_xdp.c 23c93c3b6275 ("bnxt_en: do not map packet buffers twice") 6d1add95536b ("bnxt_en: Modify TX ring indexing logic.") tools/testing/selftests/net/Makefile 2258b666482d ("selftests: add vlan hw filter tests") a0bc96c0cd6e ("selftests: net: verify fq per-band packet limit") Signed-off-by: Paolo Abeni <[email protected]>
2023-12-21net/ipv6: Remove gc_link warn on in fib6_info_releaseDavid Ahern1-3/+1
A revert of 3dec89b14d37 ("net/ipv6: Remove expired routes with a separated list of routes") was sent for net-next. Revert the remainder of 5a08d0065a915 which added a warn on if a fib entry is still on the gc_link list to avoid compile failures when net is merged to net-next Signed-off-by: David Ahern <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2023-12-21wifi: mac80211: add a driver callback to check active_linksMiri Korenblit1-0/+5
During ieee80211_set_active_links() we do (among the others): 1. Call drv_change_vif_links() with both old_active and new_active 2. Unassign the chanctx for the removed link(s) (if any) 3. Assign chanctx to the added link(s) (if any) 4. Call drv_change_vif_links() with the new_active links bitmap The problem here is that during step #1 the driver doesn't know whether we will activate multiple links simultaneously or are just doing a link switch, so it can't check there if multiple links are supported/enabled. (Some of the drivers might enable/disable this option dynamically) And during step #3, in which the driver already knows that, returning an error code (for example when multiple links are not supported or disabled), will cause a warning, and we will still complete the transition to the new_active links. (It is hard to undo things in that stage, since we released channels etc.) Therefore add a driver callback to check if the desired new_active links will be supported by the driver or not. This callback will be called in the beginning of ieee80211_set_active_links() so we won't do anything before we are sure it is supported. Signed-off-by: Miri Korenblit <[email protected]> Reviewed-by: Gregory Greenman <[email protected]> Reviewed-by: Johannes Berg <[email protected]> Link: https://msgid.link/20231220133549.64c4d70b33b8.I79708619be76b8ecd4ef3975205b8f903e24a2cd@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-12-21wifi: mac80211: allow 64-bit radiotap timestampsJohannes Berg1-1/+6
When reporting the radiotap timestamp, the mactime field is usually unused, we take the data from the device_timestamp. However, there can be cases where the radiotap timestamp is better reported as a 64-bit value, so since the mactime is free, add a flag to support using the mactime as a 64-bit radiotap timestamp. Signed-off-by: Johannes Berg <[email protected]> Reviewed-by: Gregory Greenman <[email protected]> Reviewed-by: Benjamin Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20231220133549.00c8b9234f0c.Ie3ce5eae33cce88fa01178e7aea94661ded1ac24@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-12-21wifi: mac80211: rework RX timestamp flagsJohannes Berg1-4/+9
We only have a single flag free, and before using that for another mactime flag, instead refactor the mactime flags to use a 2-bit field. Signed-off-by: Johannes Berg <[email protected]> Reviewed-by: Gregory Greenman <[email protected]> Reviewed-by: Benjamin Berg <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20231220133549.d0e664832d14.I20c8900106f9bf81316bed778b1e3ce145785274@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-12-21wifi: cfg80211: handle UHB AP and STA power typeMukesh Sisodiya3-0/+20
UHB AP send supported power type(LPI, SP, VLP) in beacon and probe response IE and STA should connect to these AP only if their regulatory support the AP power type. Beacon/Probe response are reported to userspace with reason "STA regulatory not supporting to connect to AP based on transmitted power type" and it should not connect to AP. Signed-off-by: Mukesh Sisodiya <[email protected]> Reviewed-by: Gregory Greenman <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20231220133549.cbfbef9170a9.I432f78438de18aa9f5c9006be12e41dc34cc47c5@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-12-21wifi: cfg80211: Schedule regulatory check on BSS STA channel changeAndrei Otcheretianski1-0/+10
Due to different relaxation policies it may be needed to re-check channels after a BSS station interface is disconnected or performed a channel switch. Signed-off-by: Andrei Otcheretianski <[email protected]> Reviewed-by: Gregory Greenman <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20231220133549.1f2f8475bcf1.I1879d259d8d756159c8060f61f4bce172e6d323e@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-12-21wifi: cfg80211: reg: Support P2P operation on DFS channelsAndrei Otcheretianski2-0/+18
FCC-594280 D01 Section B.3 allows peer-to-peer and ad hoc devices to operate on DFS channels while they operate under the control of a concurrent DFS master. For example, it is possible to have a P2P GO on a DFS channel as long as BSS connection is active on the same channel. Allow such operation by adding additional regulatory flags to indicate DFS concurrent channels and capable devices. Add the required relaxations in DFS regulatory checks. Signed-off-by: Andrei Otcheretianski <[email protected]> Reviewed-by: Gregory Greenman <[email protected]> Signed-off-by: Miri Korenblit <[email protected]> Link: https://msgid.link/20231220133549.bdfb8a9c7c54.I973563562969a27fea8ec5685b96a3a47afe142f@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-12-21wifi: mac80211: address some kerneldoc warningsJonathan Corbet1-12/+3
include/net/mac80111.h contains a number of either excess or incorrect kerneldoc entries for structure members, leading to these warnings: ./include/net/mac80211.h:491: warning: Excess struct member 'rssi' description in 'ieee80211_event' ./include/net/mac80211.h:491: warning: Excess struct member 'mlme' description in 'ieee80211_event' ./include/net/mac80211.h:491: warning: Excess struct member 'ba' description in 'ieee80211_event' ./include/net/mac80211.h:777: warning: Excess struct member 'ack_enabled' description in 'ieee80211_bss_conf' ./include/net/mac80211.h:1222: warning: Excess struct member 'ampdu_ack_len' description in 'ieee80211_tx_info' ./include/net/mac80211.h:1222: warning: Excess struct member 'ampdu_len' description in 'ieee80211_tx_info' ./include/net/mac80211.h:1222: warning: Excess struct member 'ack_signal' description in 'ieee80211_tx_info' ./include/net/mac80211.h:2920: warning: Excess struct member 'radiotap_he' description in 'ieee80211_hw' Fix or remove the entries as needed. This change removes 208 warnings from a "make htmldocs" build. Signed-off-by: Jonathan Corbet <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-12-21wifi: cfg80211: address several kerneldoc warningsJonathan Corbet1-7/+4
include/net/cfg80211.h includes a number of kerneldoc entries for struct members that do not exist, leading to these warnings: ./include/net/cfg80211.h:3192: warning: Excess struct member 'band_pref' description in 'cfg80211_bss_selection' ./include/net/cfg80211.h:3192: warning: Excess struct member 'adjust' description in 'cfg80211_bss_selection' ./include/net/cfg80211.h:6181: warning: Excess struct member 'bssid' description in 'wireless_dev' ./include/net/cfg80211.h:6181: warning: Excess struct member 'beacon_interval' description in 'wireless_dev' ./include/net/cfg80211.h:7299: warning: Excess struct member 'bss' description in 'cfg80211_rx_assoc_resp_data' Remove and/or repair each entry to address the warnings and ensure a proper docs build for the affected structures. Signed-off-by: Jonathan Corbet <[email protected]> Reviewed-by: Randy Dunlap <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-12-21kernel/module: improve documentation for try_module_get()Marco Pagani1-1/+1
The sentence "this call will fail if the module is already being removed" is potentially confusing and may contradict the rest of the documentation. If one tries to get a module that has already been removed using a stale pointer, the kernel will crash. Signed-off-by: Marco Pagani <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]>
2023-12-21Merge tag 'afs-fixes-20231221' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs Pull AFS fixes from David Howells: "Improve the interaction of arbitrary lookups in the AFS dynamic root that hit DNS lookup failures [1] where kafs behaves differently from openafs and causes some applications to fail that aren't expecting that. Further, negative DNS results aren't getting removed and are causing failures to persist. - Always delete unused (particularly negative) dentries as soon as possible so that they don't prevent future lookups from retrying. - Fix the handling of new-style negative DNS lookups in ->lookup() to make them return ENOENT so that userspace doesn't get confused when stat succeeds but the following open on the looked up file then fails. - Fix key handling so that DNS lookup results are reclaimed almost as soon as they expire rather than sitting round either forever or for an additional 5 mins beyond a set expiry time returning EKEYEXPIRED. They persist for 1s as /bin/ls will do a second stat call if the first fails" Link: https://bugzilla.kernel.org/show_bug.cgi?id=216637 [1] Reviewed-by: Jeffrey Altman <[email protected]> * tag 'afs-fixes-20231221' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: keys, dns: Allow key types (eg. DNS) to be reclaimed immediately on expiry afs: Fix dynamic root lookup DNS check afs: Fix the dynamic root's d_delete to always delete unused dentries
2023-12-21Merge tag 'net-6.7-rc7' of ↵Linus Torvalds5-54/+31
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from WiFi and bpf. Current release - regressions: - bpf: syzkaller found null ptr deref in unix_bpf proto add - eth: i40e: fix ST code value for clause 45 Previous releases - regressions: - core: return error from sk_stream_wait_connect() if sk_wait_event() fails - ipv6: revert remove expired routes with a separated list of routes - wifi rfkill: - set GPIO direction - fix crash with WED rx support enabled - bluetooth: - fix deadlock in vhci_send_frame - fix use-after-free in bt_sock_recvmsg - eth: mlx5e: fix a race in command alloc flow - eth: ice: fix PF with enabled XDP going no-carrier after reset - eth: bnxt_en: do not map packet buffers twice Previous releases - always broken: - core: - check vlan filter feature in vlan_vids_add_by_dev() and vlan_vids_del_by_dev() - check dev->gso_max_size in gso_features_check() - mptcp: fix inconsistent state on fastopen race - phy: skip LED triggers on PHYs on SFP modules - eth: mlx5e: - fix double free of encap_header - fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list()" * tag 'net-6.7-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (69 commits) net: check dev->gso_max_size in gso_features_check() kselftest: rtnetlink.sh: use grep_fail when expecting the cmd fail net/ipv6: Revert remove expired routes with a separated list of routes net: avoid build bug in skb extension length calculation net: ethernet: mtk_wed: fix possible NULL pointer dereference in mtk_wed_wo_queue_tx_clean() net: stmmac: fix incorrect flag check in timestamp interrupt selftests: add vlan hw filter tests net: check vlan filter feature in vlan_vids_add_by_dev() and vlan_vids_del_by_dev() net: hns3: add new maintainer for the HNS3 ethernet driver net: mana: select PAGE_POOL net: ks8851: Fix TX stall caused by TX buffer overrun ice: Fix PF with enabled XDP going no-carrier after reset ice: alter feature support check for SRIOV and LAG ice: stop trashing VF VSI aggregator node ID information mailmap: add entries for Geliang Tang mptcp: fill in missing MODULE_DESCRIPTION() mptcp: fix inconsistent state on fastopen race selftests: mptcp: join: fix subflow_send_ack lookup net: phy: skip LED triggers on PHYs on SFP modules bpf: Add missing BPF_LINK_TYPE invocations ...
2023-12-21drm/xe/uapi: Remove reset uevent for nowRodrigo Vivi1-11/+0
This kernel uevent is getting removed for now. It will come back later with a better future proof name. v2: Rebase (Francois Dugast) Cc: Himal Prasad Ghimiray <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: Francois Dugast <[email protected]> Cc: Aravind Iddamsetty <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Himal Prasad Ghimiray <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]>
2023-12-21drm/xe/uapi: Move DRM_XE_ACC_GRANULARITY_* where they are usedFrancois Dugast1-14/+8
Bring those defines close to the context where they can be used. Also apply indentation as it is done for other subsets of defines. Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Move CPU_CACHING defines before docFrancois Dugast1-2/+2
Move those defines to align on the rule used elsewhere in the file which was introduced by commit 4f082f2c3a37 ("drm/xe: Move defines before relevant fields"). Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21io_uring/kbuf: add method for returning provided buffer ring headJens Axboe1-0/+10
The tail of the provided ring buffer is shared between the kernel and the application, but the head is private to the kernel as the application doesn't need to see it. However, this also prevents the application from knowing how many buffers the kernel has consumed. Usually this is fine, as the information is inherently racy in that the kernel could be consuming buffers continually, but for cleanup purposes it may be relevant to know how many buffers are still left in the ring. Add IORING_REGISTER_PBUF_STATUS which will return status for a given provided buffer ring. Right now it just returns the head, but space is reserved for more information later in, if needed. Link: https://github.com/axboe/liburing/discussions/1020 Signed-off-by: Jens Axboe <[email protected]>
2023-12-21drm/xe/uapi: Add examples of user space codeFrancois Dugast1-0/+84
Complete the documentation of some structs by adding functional examples of user space code. Those examples are intentionally kept very simple. Put together, they provide a foundation for a minimal application that executes a job using the Xe driver. v2: Remove use of DRM_XE_VM_BIND_FLAG_ASYNC (Francois Dugast) Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Add block diagram of a deviceFrancois Dugast1-0/+39
In order to make proper use the uAPI, a prerequisite is to understand some key concepts about the discrete GPU devices which are supported by the Xe driver. For example, some structs defined in the uAPI are an abstraction of a hardware component with a specific role. This diagram helps to build a mental representation of a device how it is seen by the Xe driver. As written in the documentation, it does not intend to be a literal representation of an existing device. A lot more information could be added but the intention for the overview is to keep it simple, and go into detail as needed in other sections. v2: Add GT1 inside Tile0 (José Roberto de Souza) Reviewed-by: José Roberto de Souza <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Document the memory_region bitmaskRodrigo Vivi1-5/+18
The uAPI should stay generic in regarding to the bitmask. It is the userspace responsibility to check for the type/class of the memory, without any assumption. Also add comments inside the code to explain how it is actually constructed so we don't accidentally change the assignment of the instance and the masks. No functional change in this patch. It only explains and document the memory_region masks. A further follow-up work with the organization of all memory regions around struct xe_mem_regions is desired, but not part of this patch. Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]>
2023-12-21drm/xe/uapi: More uAPI documentation additions and cosmetic updatesRodrigo Vivi1-7/+40
No functional change in this patch. Let's ensure all of our structs are documented and with a certain standard. Also, let's have an overview and list of IOCTLs as the very beginning of the generated HTML doc. v2: Nits (Lucas De Marchi) Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]>
2023-12-21drm/xe/uapi: Order sectionsRodrigo Vivi1-122/+130
This patch doesn't modify any text or uapi entries themselves. It only move things up and down aiming a better organization of the uAPI. While fixing the documentation I noticed that query_engine_cs_cycles was in the middle of the memory_region info. Then I noticed more mismatches on the order when compared to the order of the IOCTL and QUERY entries declaration. So this patch aims to bring some order to the uAPI so it gets easier to read and the documentation generated in the end is able to tell a consistent story. Overall order: 1. IOCTL definition 2. Extension definition and helper structs 3. IOCTL's Query structs in the order of the Query's entries. 4. The rest of IOCTL structs in the order of IOCTL declaration. 5. uEvents Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]>
2023-12-21drm/xe/uapi: Make constant comments visible in kernel docFrancois Dugast1-116/+155
As there is no direct way to make comments of constants directly visible in the kernel doc, move them to the description of the structure where they can be used. By doing so they appear in the "Description" section of the struct documentation. v2: Remove DRM_XE_UFENCE_WAIT_MASK_* (Francois Dugast) Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Document DRM_XE_DEVICE_QUERY_HWCONFIGFrancois Dugast1-0/+5
Add a documentation on the content and format of when using query type DRM_XE_DEVICE_QUERY_HWCONFIG. The list of keys can be found in IGT under lib/intel_hwconfig_types.h. Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Document drm_xe_query_config keysFrancois Dugast1-0/+20
Provide a description of the keys used the struct drm_xe_query_config info array. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/637 Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Document use of size in drm_xe_device_queryFrancois Dugast1-3/+9
Document the behavior of the driver for IOCTL DRM_IOCTL_XE_DEVICE_QUERY depending on the size value provided in struct drm_xe_device_query. Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Add missing documentation for struct membersFrancois Dugast1-2/+4
This removes the documentation build warnings below: include/uapi/drm/xe_drm.h:828: warning: Function parameter or \ member 'pad2' not described in 'drm_xe_vm_bind_op' include/uapi/drm/xe_drm.h:875: warning: Function parameter or \ member 'pad2' not described in 'drm_xe_vm_bind' include/uapi/drm/xe_drm.h:1006: warning: Function parameter or \ member 'handle' not described in 'drm_xe_sync' include/uapi/drm/xe_drm.h:1006: warning: Function parameter or \ member 'timeline_value' not described in 'drm_xe_sync' Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Add a comment to each structFrancois Dugast1-3/+40
Add a comment to each struct to complete documentation, ensure all struct appear in the kernel doc, and bind structs to IOCTLs. Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Remove sync bindsMatthew Brost1-7/+4
Remove concept of async vs sync VM bind queues, rather make all binds async. The following bits have dropped from the uAPI: DRM_XE_ENGINE_CLASS_VM_BIND_ASYNC DRM_XE_ENGINE_CLASS_VM_BIND_SYNC DRM_XE_VM_CREATE_FLAG_ASYNC_DEFAULT DRM_XE_VM_BIND_FLAG_ASYNC To implement sync binds the UMD is expected to use the out-fence interface. v2: Send correct version v3: Drop drm_xe_syncs Cc: Rodrigo Vivi <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Francois Dugast <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Ensure every uapi struct has drm_xe prefixRodrigo Vivi1-9/+9
To ensure consistency and avoid possible later conflicts, let's add drm_xe prefix to xe_user_extension struct. Cc: Francois Dugast <[email protected]> Suggested-by: Lucas De Marchi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]>
2023-12-21drm/xe/pmu: Remove PMU from Xe till uapi is finalizedAshutosh Dixit1-40/+0
PMU uapi is likely to change in the future. Till the uapi is finalized, remove PMU from Xe. PMU can be re-added after uapi is finalized. v2: Include xe_drm.h in xe/tests/xe_dma_buf.c (Francois) Signed-off-by: Ashutosh Dixit <[email protected]> Acked-by: Aravind Iddamsetty <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Reviewed-by: Umesh Nerlige Ramappa <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Remove DRM_XE_UFENCE_WAIT_MASK_*Francois Dugast1-5/+7
Those are just possible values for the comparison mask but they are not specific magic values. Let's keep them as examples in the documentation but remove them from the uAPI. Suggested-by: Matthew Brost <[email protected]> Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Remove DRM_IOCTL_XE_EXEC_QUEUE_SET_PROPERTYFrancois Dugast1-1/+0
The exec_queue_set_property feature was removed in a previous commit 0f1d88f27864 ("drm/xe/uapi: Kill exec_queue_set_property") and is no longer usable, struct drm_xe_exec_queue_set_property does not exist anymore, so let's remove this. Reviewed-by: Lucas De Marchi <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: add exec_queue_id member to drm_xe_wait_user_fence structureBommu Krishnaiah1-12/+5
remove the num_engines/instances members from drm_xe_wait_user_fence structure and add a exec_queue_id member Right now this is only checking if the engine list is sane and nothing else. In the end every operation with this IOCTL is a soft check. So, let's formalize that and only use this IOCTL to wait on the fence. exec_queue_id member will help to user space to get proper error code from kernel while in exec_queue reset Signed-off-by: Bommu Krishnaiah <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Acked-by: Matthew Brost <[email protected]> Reviewed-by: Francois Dugast <[email protected]> Acked-by: José Roberto de Souza <[email protected]> Acked-by: Mateusz Naklicki <[email protected]> Signed-off-by: Francois Dugast <[email protected]>
2023-12-21drm/xe/uapi: Kill exec_queue_set_propertyRodrigo Vivi1-35/+13
All the properties should be immutable and set upon exec_queue creation using the existent extension. So, let's kill this useless and dangerous uapi. Cc: Francois Dugast <[email protected]> Cc: José Roberto de Souza <[email protected]> Cc: Matthew Brost <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Francois Dugast <[email protected]>
2023-12-21drm/xe: Remove unused extension definitionRodrigo Vivi1-1/+0
The vm_create ioctl function doesn't accept any extension. Remove this left over. A backward compatible change. Cc: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]>
2023-12-21drm/xe/uapi: Use LR abbrev for long-running vmsThomas Hellström1-1/+22
Currently we're using "compute mode" for long running VMs using preempt-fences for memory management, and "fault mode" for long running VMs using page faults. Change this to use the terminology "long-running" abbreviated as LR for long-running VMs. These VMs can then either be in preempt-fence mode or fault mode. The user can force fault mode at creation time, but otherwise the driver can choose to use fault- or preempt-fence mode for long-running vms depending on the device capabilities. Initially unless fault-mode is specified, the driver uses preempt-fence mode. v2: - Fix commit message wording and the documentation around CREATE_FLAG_LR_MODE and CREATE_FLAG_FAULT_MODE Cc: Matthew Brost <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Francois Dugast <[email protected]> Signed-off-by: Thomas Hellström <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Move xe_exec after xe_exec_queueRodrigo Vivi1-6/+6
Although the exec ioctl is a very important one, it makes no sense to explain xe_exec before explaining the exec_queue. So, let's move this down to help bring a better flow on the documentation and code readability. It is important to highlight that this patch is changing all the ioctl numbers in a non-backward compatible way. However, we are doing this final uapi clean-up before we submit our first pull-request to be part of the upstream Kernel. Once we get there, no other change like this will ever happen and all the backward compatibility will be respected. Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]>
2023-12-21drm/xe/uapi: Fix various struct padding for 64b alignmentRodrigo Vivi1-9/+12
Let's respect Documentation/process/botching-up-ioctls.rst and add the proper padding for a 64b alignment with all as well as all the required checks and settings for the pads and the reserved entries. v2: Fix remaining holes and double check with pahole (Jose) Ensure with pahole that both 32b and 64b have exact same layout (Thomas) Do not set query's pad and reserved bits to zero since it is redundant and already done by kzalloc (Matt) v3: Fix alignment after rebase (José Roberto de Souza) v4: Fix pad check (Francois Dugast) Cc: Thomas Hellström <[email protected]> Cc: Francois Dugast <[email protected]> Cc: José Roberto de Souza <[email protected]> Cc: Matt Roper <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]>
2023-12-21drm/xe/uapi: Add Tile ID information to the GT info queryRodrigo Vivi1-0/+2
As an information only. So Userspace can use this information and be able to correlate different GTs. Make API symmetric between Engine and GT info. There's no need right now to include a tile_query entry since there's no other information that we need from tile that is not already exposed through different queries. However, this could be added later if we have different Tile information that could matter to userspace. But let's keep the API ready for a direct reference to Tile ID based on the GT entry. Signed-off-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]>
2023-12-21drm/xe/uapi: Crystal Reference Clock updatesRodrigo Vivi1-7/+4
First of all, let's remove the duplication. But also, let's rename it to remove the word 'frequency' out of it. In general, the first thing people think of frequency is the frequency in which the GTs are operating to execute the GPU instructions. While this frequency here is a crystal reference clock frequency which is the base of everything else, and in this case of this uAPI it is used to calculate a better and precise timestamp. v2: (Suggested by Jose) Remove the engine_cs and keep the GT info one since it might be useful for other SRIOV cases where the engine_cs will be zeroed. So, grabbing from the GT_LIST should be cleaner. v3: Keep comment on put_user() call (José Roberto de Souza) Cc: Matt Roper <[email protected]> Umesh Nerlige Ramappa <[email protected]> Cc: Jose Souza <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]>
2023-12-21drm/xe/uapi: Kill tile_maskRodrigo Vivi1-7/+1
It is currently unused, so by the rules it cannot go upstream. Also there was the desire to convert that to align with the engine_class_instance selection, but the consensus on that one is to remain with the global gt_id. So we are keeping the gt_id there, not converting to a generic sched_group and also killing this tile_mask and only using the default behavior of 0 that is to create a mapping / page_table entry on every tile, similar to what i915. Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]>
2023-12-21drm/xe/uapi: Split xe_sync types from flagsRodrigo Vivi1-8/+8
Let's continue on the uapi clean-up with more splits with stuff into their own exclusive fields instead of reusing stuff. Signed-off-by: Rodrigo Vivi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]>
2023-12-21drm/xe/uapi: Align on a common way to return arrays (engines)Francois Dugast1-31/+47
The uAPI provides queries which return arrays of elements. As of now the format used in the struct is different depending on which element is queried. Fix this for engines by applying the pattern below: struct drm_xe_query_Xs { __u32 num_Xs; struct drm_xe_X Xs[]; ... } Instead of directly returning an array of struct drm_xe_query_engine_info, a new struct drm_xe_query_engines is introduced. It contains itself an array of struct drm_xe_engine which holds the information about each engine. v2: Use plural for struct drm_xe_query_engines as multiple engines are returned (José Roberto de Souza) Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Align on a common way to return arrays (gt)Francois Dugast1-3/+3
The uAPI provides queries which return arrays of elements. As of now the format used in the struct is different depending on which element is queried. However, aligning on the new common pattern: struct drm_xe_query_Xs { __u32 num_Xs; struct drm_xe_X Xs[]; ... } ... would mean bringing back the name "gts" which is avoided per commit fca54ba12470 ("drm/xe/uapi: Rename gts to gt_list") so make an exception for gt and leave gt_list. Also, this change removes "query" in the name of struct drm_xe_query_gt as it is not returned from the query IOCTL. There is no functional change. v2: Leave gt_list (Matt Roper) Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: Matt Roper <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
2023-12-21drm/xe/uapi: Align on a common way to return arrays (memory regions)Francois Dugast1-6/+6
The uAPI provides queries which return arrays of elements. As of now the format used in the struct is different depending on which element is queried. Fix this for memory regions by applying the pattern below: struct drm_xe_query_Xs { __u32 num_Xs; struct drm_xe_X Xs[]; ... } This removes "query" in the name of struct drm_xe_query_mem_region as it is not returned from the query IOCTL. There is no functional change. v2: Only rename drm_xe_query_mem_region to drm_xe_mem_region (José Roberto de Souza) v3: Rename usage to mem_regions in xe_query.c (José Roberto de Souza) Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.