- 19 May, 2020 40 commits
-
-
John Hubbard authored
This code was using get_user_pages*(), in a "Case 2" scenario (DMA/RDMA), using the categorization from [1]. That means that it's time to convert the get_user_pages*() + put_page() calls to pin_user_pages*() + unpin_user_pages() calls. There is some helpful background in [2]: basically, this is a small part of fixing a long-standing disconnect between pinning pages, and file systems' use of those pages. Note that this effectively changes the code's behavior as well: it now ultimately calls set_page_dirty_lock(), instead of SetPageDirty(). This is probably more accurate. As Christoph Hellwig put it, "set_page_dirty() is only safe if we are dealing with a file backed page where we have reference on the inode it hangs off." [3] [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ [3] https://lore.kernel.org/r/20190723153640.GB720@lst.deSigned-off-by:John Hubbard <jhubbard@nvidia.com> Link: https://lore.kernel.org/r/20200518041307.1987328-1-jhubbard@nvidia.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mike Leach authored
Adds a notify callback for CPU PM events to the CTI driver - for CPU bound CTI devices. Signed-off-by:
Mike Leach <mike.leach@linaro.org> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200518180242.7916-24-mathieu.poirier@linaro.orgSigned-off-by:
-
Mike Leach authored
Adds registration of CPU start and stop functions to CPU hotplug mechanisms - for any CPU bound CTI. Sets CTI powered flag according to state. Will enable CTI on CPU start if there are existing enable requests. Signed-off-by:
-
Suzuki K Poulose authored
etm probe could be deferred due to the dependency in the trace path chain and may be retried. We need to clear the per-cpu etmdrvdata entry for the etm in case of a failure to avoid use-after-free cases as reported below: KASAN use-after-free bug in etm4_cpu_pm_notify(): [ 8.574566] coresight etm0: CPU0: ETM v4.2 initialized [ 8.581920] BUG: KASAN: use-after-free in etm4_cpu_pm_notify+0x580/0x2024 [ 8.581925] Read of size 8 at addr ffffff813304f8c8 by task swapper/3/0 [ 8.581927] [ 8.581934] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G S W 5.4.28 #314 [ 8.587775] coresight etm1: CPU1: ETM v4.2 initialized [ 8.594195] Call trace: [ 8.594205] dump_backtrace+0x0/0x188 [ 8.594209] show_stack+0x20/0x2c [ 8.594216] dump_stack+0xdc/0x144 [ 8.594227] print_address_description+0x3c/0x494 [ 8.594232] __kasan_report+0x144/0x168 [ 8.601598] coresight etm2: CPU2: ETM v4.2 initialized [ 8.602563] kasan_report+0x10/0x18 [ 8.602568] check_memory_region+0x1a4/0x1b4 [ 8.602572] __kasan_check_read+0x18/0x24 [ 8.602577] etm4_cpu_pm_notify+0x580/0x2024 [ 8.665945] notifier_call_chain+0x5c/0x90 [ 8.670166] __atomic_notifier_call_chain+0x90/0xf8 [ 8.675182] cpu_pm_notify+0x40/0x6c [ 8.678858] cpu_pm_enter+0x38/0x80 [ 8.682451] psci_enter_idle_state+0x34/0x70 [ 8.686844] cpuidle_enter_state+0xb8/0x20c [ 8.691143] cpuidle_enter+0x38/0x4c [ 8.694820] call_cpuidle+0x3c/0x68 [ 8.698408] do_idle+0x1a0/0x280 [ 8.701729] cpu_startup_entry+0x24/0x28 [ 8.705768] secondary_start_kernel+0x15c/0x170 [ 8.710423] [ 8.711972] Allocated by task 242: [ 8.715473] __kasan_kmalloc+0xf0/0x1ac [ 8.719426] kasan_slab_alloc+0x14/0x1c [ 8.723375] __kmalloc_track_caller+0x23c/0x388 [ 8.728040] devm_kmalloc+0x38/0x94 [ 8.731632] etm4_probe+0x48/0x3c8 [ 8.735140] amba_probe+0xbc/0x158 [ 8.738645] really_probe+0x144/0x408 [ 8.742412] driver_probe_device+0x70/0x140 [ 8.746716] __device_attach_driver+0x9c/0x110 [ 8.751287] bus_for_each_drv+0x90/0xd8 [ 8.755236] __device_attach+0xb4/0x164 [ 8.759188] device_initial_probe+0x20/0x2c [ 8.763490] bus_probe_device+0x34/0x94 [ 8.767436] device_add+0x34c/0x3e0 [ 8.771029] amba_device_try_add+0x68/0x440 [ 8.775332] amba_deferred_retry_func+0x48/0xc8 [ 8.779997] process_one_work+0x344/0x648 [ 8.784127] worker_thread+0x2ac/0x47c [ 8.787987] kthread+0x128/0x138 [ 8.791313] ret_from_fork+0x10/0x18 [ 8.794993] [ 8.796532] Freed by task 242: [ 8.799684] __kasan_slab_free+0x15c/0x22c [ 8.803897] kasan_slab_free+0x10/0x1c [ 8.807761] kfree+0x25c/0x4bc [ 8.810913] release_nodes+0x240/0x2b0 [ 8.814767] devres_release_all+0x3c/0x54 [ 8.818887] really_probe+0x178/0x408 [ 8.822661] driver_probe_device+0x70/0x140 [ 8.826963] __device_attach_driver+0x9c/0x110 [ 8.831539] bus_for_each_drv+0x90/0xd8 [ 8.835487] __device_attach+0xb4/0x164 [ 8.839431] device_initial_probe+0x20/0x2c [ 8.843732] bus_probe_device+0x34/0x94 [ 8.847678] device_add+0x34c/0x3e0 [ 8.851274] amba_device_try_add+0x68/0x440 [ 8.855576] amba_deferred_retry_func+0x48/0xc8 [ 8.860240] process_one_work+0x344/0x648 [ 8.864366] worker_thread+0x2ac/0x47c [ 8.868228] kthread+0x128/0x138 [ 8.871557] ret_from_fork+0x10/0x18 [ 8.875231] [ 8.876782] The buggy address belongs to the object at ffffff813304f800 [ 8.876782] which belongs to the cache kmalloc-1k of size 1024 [ 8.889632] The buggy address is located 200 bytes inside of [ 8.889632] 1024-byte region [ffffff813304f800, ffffff813304fc00) [ 8.901761] The buggy address belongs to the page: [ 8.906695] page:ffffffff04ac1200 refcount:1 mapcount:0 mapping:ffffff8146c03800 index:0x0 compound_mapcount: 0 [ 8.917047] flags: 0x4000000000010200(slab|head) [ 8.921799] raw: 4000000000010200 dead000000000100 dead000000000122 ffffff8146c03800 [ 8.929753] raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 [ 8.937703] page dumped because: kasan: bad access detected [ 8.943433] [ 8.944974] Memory state around the buggy address: [ 8.949903] ffffff813304f780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 8.957320] ffffff813304f800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 8.964742] >ffffff813304f880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 8.972157] ^ [ 8.977886] ffffff813304f900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 8.985298] ffffff813304f980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 8.992713] ================================================================== Fixes: f188b5e7 ("coresight: etm4x: Save/restore state across CPU low power states") Reported-by:
Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Tested-by:
Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by:
-
Stephen Boyd authored
We don't need to cast void pointers, such as the amba_id data. Assign to a local variable to make the code prettier and also return NULL instead of 0 to make sparse happy. Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Mike Leach <mike.leach@linaro.org> Reviewed-by:
Joe Perches <joe@perches.com> Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
-
Stephen Boyd authored
We should include headers that C files use in the C files that use them and avoid relying on implicit includes as much as possible. This helps avoid compiler errors in the future about missing declarations when header files change includes in the future. Cc: Douglas Anderson <dianders@chromium.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Mike Leach <mike.leach@linaro.org> Signed-off-by:
-
Stephen Boyd authored
Sparse gets annoyed when this initializer is 0 but the first struct member is a pointer. Just use { } to initialize instead so that sparse is quiet. Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Mike Leach <mike.leach@linaro.org> Signed-off-by: -
Stephen Boyd authored
These variables are assigned again before they're used. Leave them unassigned at first so that the compiler can detect problems in the future with use before initialization. Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Mike Leach <mike.leach@linaro.org> Signed-off-by:
-
Stephen Boyd authored
These functions aren't used outside the file they're in. Mark them static to indicate as such and silence tools like sparse. Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Mike Leach <mike.leach@linaro.org> Signed-off-by:
-
Anurag Koul authored
Add PID for Arm Neoverse N1 ETM to the list of supported/known ETMs. Signed-off-by:
Anurag Koul <anurag.koul@arm.com> Signed-off-by:
-
Mike Leach authored
Differing default states set on driver init / perf init and as a result of a sysfs reset. The ETMv4 can be programmed to trace the entire instruction address range without the need to use address comparator filter resources. (Described in the ETMv4.x technical reference manual) sysfs reset was using this method, perf and default driver init were setup with an address range comparator for the entire address range. The perf / driver init has been altered to use the method without needing any comparator address hardware. Minor adjustment to the vinst_ctrl register initialisation to ensure correct zero initialisation. Signed-off-by:
-
Sai Prakash Ranjan authored
On some QCOM platforms like SC7180, SDM845 and SM8150, reading TMC mode register without proper coresight power management can lead to async exceptions like the one in the call trace below in tmc_read_prepare_etb(). This can happen if the user tries to read the TMC etf data via device node without setting up source and the sink first. Fix this by having a check for coresight sysfs mode before reading TMC mode management register. Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 7 PID: 2605 Comm: hexdump Tainted: G S 5.4.30 #122 Call trace: dump_backtrace+0x0/0x188 show_stack+0x20/0x2c dump_stack+0xdc/0x144 panic+0x168/0x36c panic+0x0/0x36c arm64_serror_panic+0x78/0x84 do_serror+0x130/0x138 el1_error+0x84/0xf8 tmc_read_prepare_etb+0x88/0xb8 tmc_open+0x40/0xd8 misc_open+0x120/0x158 chrdev_open+0xb8/0x1a4 do_dentry_open+0x268/0x3a0 vfs_open+0x34/0x40 path_openat+0x39c/0xdf4 do_filp_open+0x90/0x10c do_sys_open+0x150/0x3e8 __arm64_compat_sys_openat+0x28/0x34 el0_svc_common+0xa8/0x160 el0_svc_compat_handler+0x2c/0x38 el0_svc_compat+0x8/0x10 Fixes: 4525412a ("coresight: tmc: making prepare/unprepare functions generic") Reported-by:
-
Suzuki K Poulose authored
On some systems the firmware may not describe all the ports connected to a component (e.g, for security reasons). This could be especially problematic for "funnels" where we could end up in modifying memory beyond the allocated space for refcounts. e.g, for a funnel with input ports listed 0, 3, 5, nr_inport = 3. However the we could access refcnts[5] while checking for references, like : [ 526.110401] ================================================================== [ 526.117988] BUG: KASAN: slab-out-of-bounds in funnel_enable+0x54/0x1b0 [ 526.124706] Read of size 4 at addr ffffff8135f9549c by task bash/1114 [ 526.131324] [ 526.132886] CPU: 3 PID: 1114 Comm: bash Tainted: G S 5.4.25 #232 [ 526.140397] Hardware name: Qualcomm Technologies, Inc. SC7180 IDP (DT) [ 526.147113] Call trace: [ 526.149653] dump_backtrace+0x0/0x188 [ 526.153431] show_stack+0x20/0x2c [ 526.156852] dump_stack+0xdc/0x144 [ 526.160370] print_address_description+0x3c/0x494 [ 526.165211] __kasan_report+0x144/0x168 [ 526.169170] kasan_report+0x10/0x18 [ 526.172769] check_memory_region+0x1a4/0x1b4 [ 526.177164] __kasan_check_read+0x18/0x24 [ 526.181292] funnel_enable+0x54/0x1b0 [ 526.185072] coresight_enable_path+0x104/0x198 [ 526.189649] coresight_enable+0x118/0x26c ... [ 526.237782] Allocated by task 280: [ 526.241298] __kasan_kmalloc+0xf0/0x1ac [ 526.245249] kasan_kmalloc+0xc/0x14 [ 526.248849] __kmalloc+0x28c/0x3b4 [ 526.252361] coresight_register+0x88/0x250 [ 526.256587] funnel_probe+0x15c/0x228 [ 526.260365] dynamic_funnel_probe+0x20/0x2c [ 526.264679] amba_probe+0xbc/0x158 [ 526.268193] really_probe+0x144/0x408 [ 526.271970] driver_probe_device+0x70/0x140 ... [ 526.316810] [ 526.318364] Freed by task 0: [ 526.321344] (stack is not available) [ 526.325024] [ 526.326580] The buggy address belongs to the object at ffffff8135f95480 [ 526.326580] which belongs to the cache kmalloc-128 of size 128 [ 526.339439] The buggy address is located 28 bytes inside of [ 526.339439] 128-byte region [ffffff8135f95480, ffffff8135f95500) [ 526.351399] The buggy address belongs to the page: [ 526.356342] page:ffffffff04b7e500 refcount:1 mapcount:0 mapping:ffffff814b00c380 index:0x0 compound_mapcount: 0 [ 526.366711] flags: 0x4000000000010200(slab|head) [ 526.371475] raw: 4000000000010200 ffffffff05034008 ffffffff0501eb08 ffffff814b00c380 [ 526.379435] raw: 0000000000000000 0000000000190019 00000001ffffffff 0000000000000000 [ 526.387393] page dumped because: kasan: bad access detected [ 526.393128] [ 526.394681] Memory state around the buggy address: [ 526.399619] ffffff8135f95380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.407046] ffffff8135f95400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.414473] >ffffff8135f95480: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.421900] ^ [ 526.426029] ffffff8135f95500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.433456] ffffff8135f95580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.440883] ================================================================== To keep the code simple, we now track the maximum number of possible input/output connections to/from this component @ nr_inport and nr_outport in platform_data, respectively. Thus the output connections could be sparse and code is adjusted to skip the unspecified connections. Cc: Mathieu Poirier <mathieu.poirier@linaro.org> Cc: Mike Leach <mike.leach@linaro.org> Reported-by:
-
Jason Yan authored
Fix the following sparse warning: drivers/hwtracing/coresight/coresight-etb10.c:720:30: warning: symbol 'coresight_etb_groups' was not declared. Should it be static? Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
-
Jason Yan authored
Fix the following sparse warning: drivers/hwtracing/coresight/coresight-cti.c:22:1: warning: symbol 'ect_net' was not declared. Should it be static? drivers/hwtracing/coresight/coresight-cti.c:625:32: warning: symbol 'cti_ops_ect' was not declared. Should it be static? drivers/hwtracing/coresight/coresight-cti.c:630:28: warning: symbol 'cti_ops' was not declared. Should it be static? Reported-by:
-
Sai Prakash Ranjan authored
Replace the AMBA ETM PIDs with UCI IDs to avoid future conflicts when adding the CTI support for QCOM Kryo385 CPU cores. Fixes: 17b4add0 ("coresight: etm4x: Add ETM PIDs for SDM845 and MSM8996") Signed-off-by:
-
Sai Prakash Ranjan authored
Add ETM UCI IDs for Qualcomm SC7180 SoC. It has 2 big CPU cores based on Cortex-A76 and 6 LITTLE CPU cores based on Cortex-A55. Signed-off-by:
-
Mauro Carvalho Chehab authored
Sphinx wants a line after "..", as otherwise it complains with: Documentation/trace/coresight/coresight-ect.rst:2: WARNING: Explicit markup ends without a blank line; unexpected unindent. Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Mike Leach authored
Update the CoreSight documents to describe the new connections directory and the links between CoreSight devices in this directory. Signed-off-by:
-
Mike Leach authored
Adds in sysfs links for connections where the connected device is another coresight device. This allows examination of the coresight topology. Non-coresight connections remain just as a reference name. Signed-off-by:
-
Suzuki K Poulose authored
Coresight device connections are a bit complicated and is not exposed currently to the user. One has to look at the platform descriptions (DT bindings or ACPI bindings) to make an understanding. Given the new naming scheme, it will be helpful to have this information to choose the appropriate devices for tracing. This patch exposes the device connections via links in the sysfs directories. e.g, for a connection devA[OutputPort_X] -> devB[InputPort_Y] is represented as two symlinks: /sys/bus/coresight/.../devA/out:X -> /sys/bus/coresight/.../devB /sys/bus/coresight/.../devB/in:Y -> /sys/bus/coresight/.../devA Signed-off-by:
-
Mike Leach authored
To allow the connections between coresight components to be represented in sysfs, generic methods for creating sysfs links between two coresight devices are added. Signed-off-by:
-
Suzuki K Poulose authored
Handle failures in fixing up connections for a newly registered device. This will be useful to handle cases where we fail to expose the links via sysfs for the connections. Signed-off-by:
-
Suzuki K Poulose authored
As we prepare to expose the links between the devices in sysfs, pass the coresight_device instance to the coresight_release_platform_data in order to free up the connections when the device is removed. No functional changes as such in this patch. Signed-off-by:
-
Greg Kroah-Hartman authored
Merge tag 'misc-habanalabs-next-2020-05-19' of git://people.freedesktop.org/~gabbayo/linux into char-misc-next Oded writes: This tag contains the following changes for kernel 5.8: - GAUDI ASIC support. The tag contains code and header files needed to initialize the GAUDI ASIC and run workloads on it. There are changes to the common code that are needed for GAUDI and there is the addition of new ASIC-dependent code of GAUDI. - Add new feature of signal/wait command submissions. This is relevant to GAUDI only and allows the user to sync between streams (queues) inside the device. - Allow user to retrieve the device time alongside the host time, to allow a user application to synchronize device time together with host time during profiling. - Change ASIC's CPU initialization by loading its boot loader code from the Host memory (instead of it being programmed on the on-board FLASH). - Expose more attributes through HWMON. - Move the ASIC event handling code to be "common code". This will be shared between GAUDI and future ASICs. Goya will still use its own code. - Fix bug in command submission parsing in Goya. - Small fixes to security configuration (open up some registers for user access). - Improvements to ASIC reset code. * tag 'misc-habanalabs-next-2020-05-19' of git://people.freedesktop.org/~gabbayo/linux: (38 commits) habanalabs: update patched_cb_size for Wreg32 habanalabs: move event handling to common firmware file habanalabs: enable gaudi code in driver habanalabs: add gaudi profiler module habanalabs: add gaudi security module habanalabs: add hwmgr module for gaudi habanalabs: add gaudi asic-dependent code uapi: habanalabs: add gaudi defines habanalabs: add gaudi asic registers header files habanalabs: get card type, location from F/W habanalabs: support clock gating enable/disable habanalabs: set PM profile to auto only for goya habanalabs: add dedicated define for hard reset habanalabs: check if CoreSight is supported habanalabs: add signal/wait to CS IOCTL operations habanalabs: handle the h/w sync object habanalabs: define ASIC-dependent interface for signal/wait uapi: habanalabs: add signal/wait operations habanalabs: add missing MODULE_DEVICE_TABLE habanalabs: print all CB handles as hex numbers ...
-
Rachel Stahl authored
The patch_cb_size is not updated for Wreg32 in its validate function, so updated in goya_validate_cb. Signed-off-by:
Rachel Stahl <rstahl@habana.ai> Reviewed-by:
Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by:
-
Ofir Bitton authored
Instead of writing similar event handling code for each ASIC, move the code to the common firmware file. This code will be used for GAUDI and all future ASICs. In addition, add two new fields to the auto-generated events file: valid and description. This will save the need to manually write the events description in the source code and simplify the code. Signed-off-by:
Ofir Bitton <obitton@habana.ai> Reviewed-by:
-
Oded Gabbay authored
Enable the GAUDI ASIC code in the pci probe callback of the driver so the driver will handle GAUDI ASICs. Signed-off-by: -
Omer Shpigelman authored
Add the GAUDI code to initialize the ASIC's profiler. The profile receives its initialization values from the user, same as in Goya, but the code to initialize is in the driver because the configuration space of the device is not directly exposed to the user. Signed-off-by:
Omer Shpigelman <oshpigelman@habana.ai> Reviewed-by:
-
Omer Shpigelman authored
Add the code to initialize the security module of GAUDI. Similar to Goya, we have two dedicated mechanisms for security: Range Registers and Protection bits. Those mechanisms protect sensitive memory and configuration areas inside the device. In addition, in Gaudi we moved to a 3-level security scheme, where the F/W runs with the highest security level (Privileged), the driver runs with a less secured level (Secured) and the user is neither privileged nor secured. The security module in the driver configures the Secured parts so the user won't be able to access them. The Privileged parts are configured by the F/W. Signed-off-by:
-
Oded Gabbay authored
The hwmgr module is responsible for messages sent to GAUDI F/W that are not common to all habanalabs ASICs. In GAUDI, we provide the user a simplified mode of controlling the ASIC clock frequency. Instead of three different clocks, we present a single clock property that the user can configure via sysfs. Signed-off-by: -
Oded Gabbay authored
Add the ASIC-dependent code for GAUDI. Supply (almost) all of the function callbacks that the driver's common code need to initialize, finalize and submit workloads to the GAUDI ASIC. It also contains the code to initialize the F/W of the GAUDI ASIC and to receive events from the F/W. Signed-off-by: -
Oded Gabbay authored
Add the new defines for GAUDI uapi interface. It includes the queue IDs, the engine IDs, SRAM reserved space and Sync Manager reserved resources. There is no new IOCTL or additional operations in existing IOCTLs. Signed-off-by: -
Oded Gabbay authored
Add the relevant GAUDI ASIC registers header files. These files are generated automatically from a tool maintained by the VLSI engineers. There are more files which are not upstreamed because only very few defines from those files are used in the driver. For those files, we copied the relevant defines into gaudi_regs.h and gaudi_masks.h, to reduce the size of this patch. Signed-off-by: -
Omer Shpigelman authored
For Gaudi the driver gets two new additional properties from the F/W: 1. The card's type - PCI or PMC 2. The card's location in the Gaudi's box (relevant only for PMC). The card's location is also passed to the user in the HW IP info structure as it needs this property for establishing communication between Gaudis. Signed-off-by:
-
Oded Gabbay authored
In Gaudi there is a feature of clock gating certain engines. Therefore, add this property to the device structure. In addition, due to a limitation of this feature, the driver needs to dynamically enable or disable this feature during run-time. Therefore, add ASIC interface functions to enable/disable this function from the common code. Moreover, this feature must be turned off when the user wishes to debug the ASIC by reading/writing registers and/or memory through the driver's debugfs. Therefore, add an option to enable/disable clock gating via the debugfs interface. Signed-off-by: -
Oded Gabbay authored
For Gaudi, the driver doesn't change the PM profile automatically due to device-controlled PM capabilities. Therefore, set the PM profile to auto only for Goya so the driver's code to automatically change the profile won't run on Gaudi. Signed-off-by: -
Omer Shpigelman authored
Gaudi requires longer waiting during reset due to closing of network ports. Add this explanation to the relevant comment in the code and add a dedicated define for this reset timeout period, instead of multiplying another define. Signed-off-by:
-
Omer Shpigelman authored
Coresight is not supported on simulator, therefore add a boolean for checking that (currently used by un-upstreamed code). Signed-off-by:
-
Omer Shpigelman authored
Add the following two operations to the CS IOCTL: Signal: The signal operation is basically a command submission, that is created by the driver upon user request. It will be implemented using a dedicated PQE that will increment a specific SOB. There will be a new flag: HL_CS_FLAGS_SIGNAL. When the user set this flag in the CS IOCTL structure, the driver will execute a dedicated code path that will prepare this special PQE and submit it. The user only needs to provide a queue index on which to put the signal. Wait: The wait operation is also a command submission that is created by the driver upon user request. It will be implemented using a dedicated PQE that will contain packets of "ARM a monitor" + FENCE packet. There will be a new flag: HL_CS_FLAGS_WAIT. When the user set this flag in the CS structure, the driver will execute a dedicated code path that will prepare this special PQE and submit it. The user needs to provide the following parameters: 1. queue ID 2. an array of signal_seq numbers and the number of signals to wait on (the length of signal_seq_arr). The IOCTL will return the CS sequence number of the wait it put on the queue ID. Currently, the code supports signal_seq_nr==1. But this API definition will allow us to put a single PQE that waits on multiple signals. To correctly configure the monitor and fence, the driver will need to retrieve the specified signal CS object that contains the relevant SOB and its expected value. In case the signal CS has already been completed, there is no point of adding a wait operation. In this case, the driver will return to the user *without* putting anything on the PQ. The return code should reflect to the user that the signal was completed, as we won't return a CS sequence number for this wait. Signed-off-by:
-
