- 19 May, 2020 34 commits
-
-
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:
Suzuki K Poulose <suzuki.poulose@arm.com> [Revised to use the generic sysfs links functions & link structures. Provides a connections sysfs group in each device to hold the links.] Co-developed-by:
Mike Leach <mike.leach@linaro.org> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200518180242.7916-5-mathieu.poirier@linaro.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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:
-
Omer Shpigelman authored
Define a structure representing the h/w sync object (SOB). a SOB can contain up to 2^15 values. Each signal CS will increment the SOB by 1, so after some time we will reach the maximum number the SOB can represent. When that happens, the driver needs to move to a different SOB for the signal operation. A SOB can be in 1 of 4 states: 1. Working state with value < 2^15 2. We reached a value of 2^15, but the signal operations weren't completed yet OR there are pending waits on this signal. For the next submission, the driver will move to another SOB. 3. ALL the signal operations on the SOB have finished AND there are no more pending waits on the SOB AND we reached a value of 2^15 (This basically means the refcnt of the SOB is 0 - see explanation below). When that happens, the driver can clear the SOB by simply doing WREG32 0 to it and set the refcnt back to 1. 4. The SOB is cleared and can be used next time by the driver when it needs to reuse an SOB. Per SOB, the driver will maintain a single refcnt, that will be initialized to 1. When a signal or wait operation on this SOB is submitted to the PQ, the refcnt will be incremented. When a signal or wait operation on this SOB completes, the refcnt will be decremented. After the submission of the signal operation that increments the SOB to a value of 2^15, the refcnt is also decremented. Signed-off-by:
-
Omer Shpigelman authored
This feature requires handling h/w resources which are a bit different from one ASIC to the other. Therefore, we need to define a set of interfaces the ASIC code provides to the common code to signal, wait, reset sync object and to reset and init a queue. As this feature is not supported in Goya, provide an empty implementation of those functions. Signed-off-by:
-
Omer Shpigelman authored
This is a pre-requisite to upstreaming GAUDI support. Signal/wait operations are done by the user to perform sync between two Primary Queues (PQs). The sync is done using the sync manager and it is usually resolved inside the device, but sometimes it can be resolved in the host, i.e. the user should be able to wait in the host until a signal has been completed. The mechanism to define signal and wait operations is done by the driver because it needs atomicity and serialization, which is already done in the driver when submitting work to the different queues. To implement this feature, the driver "takes" a couple of h/w resources, and this is reflected by the defines added to the uapi file. The signal/wait operations are done via the existing CS IOCTL, and they use the same data structure. There is a difference in the meaning of some of the parameters, and for that we added unions to make the code more readable. Signed-off-by:
-
Oded Gabbay authored
PCI drivers should use this define to declare their PCI ID table. Reviewed-by:
Tomer Tayar <ttayar@habana.ai> Signed-off-by:
-
Dotan Barak authored
Make all the CB handles printed in the same way and not some as decimal and some as hex numbers. Signed-off-by:
Dotan Barak <dbarak@habana.ai> Reviewed-by:
-
Oded Gabbay authored
Update the mapping to the latest one used by the Firmware. No impact on the driver in this update. Reviewed-by:
-
Adam Aharon authored
Set the STMTCSR.COMPEN bit to enable leading-zero trace data compression functionality for the extended stimulus ports. Signed-off-by:
Adam Aharon <aaharon@habana.ai> Reviewed-by:
-
Ofir Bitton authored
Load CPU device boot loader during driver boot time in order to avoid flash write for every boot loader update. To preserve backward-compatibility, skip the device boot load if the device doesn't request it. Signed-off-by:
-
Oded Gabbay authored
The user must leave space for 2xMSG_PROT in the external CB, so adjust the define of max size accordingly. The driver, however, can still create a CB with the maximum size of 2MB. Therefore, we need to add a check specifically for the user requested size. Reviewed-by:
-
Christine Gharzuzi authored
Support hwmon_temp_reset_histroy, hwmon_in_reset_history and hwmon_curr_reset attribute which resets the historical highest value. Signed-off-by:
Christine Gharzuzi <cgharzuzi@habana.ai> Reviewed-by:
-
Tomer Tayar authored
Align the protection bits configuration of all TPC cores to be as of TPC core 0. Fixes: a513f9a7 ("habanalabs: make tpc registers secured") Signed-off-by:
-
Tomer Tayar authored
Allow user access to TPC LFSR register, as it might be accessed by TPC kernels. Signed-off-by:
-
Tomer Tayar authored
Add a new opcode to the INFO IOCTL that retrieves the device time alongside the host time, to allow a user application that want to measure device time together with host time (such as a profiler) to synchronize these times. Signed-off-by:
-
kbuild test robot authored
set function to be static as it is not called from outside its file. Signed-off-by:
kbuild test robot <lkp@intel.com> Reviewed-by:
-
- 17 May, 2020 6 commits
-
-
Oded Gabbay authored
When we have DMA QMAN with multiple streams, we need to know whether the command buffer contains at least one DMA packet in order to configure the barriers correctly when adding the 2xMSG_PROT at the end of the JOB. If there is no DMA packet, then there is no need to put engine barrier. This is relevant only for GAUDI as GOYA doesn't have streams so the engine can't be busy by another stream. Reviewed-by:
-
Oded Gabbay authored
Retrieve from the firmware the DMA mask value we need to set according to the device's PCI controller configuration. This is needed when working on POWER9 machines, as the device's PCI controller is configured in a different way in those machines. Reviewed-by:
-
Oded Gabbay authored
Add comments for the various errors and states of the firmware during boot. Add a mapping of a new register that will tell the driver whether the firmware executed the request from the driver or if it has encountered an error. Add a new enum for the possible values of this register. Reviewed-by:
-
Oded Gabbay authored
When doing training, the DL framework (e.g. tensorflow) performs hundreds of thousands of memory allocations and mappings. In case the driver needs to perform hard-reset during training, the driver kills the application and unmaps all those memory allocations. Unfortunately, because of that large amount of mappings, the driver isn't able to do that in the current timeout (5 seconds). Therefore, increase the timeout significantly to 30 seconds to avoid situation where the driver resets the device with active mappings, which sometime can cause a kernel bug. BTW, it doesn't mean we will spend all the 30 seconds because the reset thread checks every one second if the unmap operation is done. Reviewed-by:
-
Oded Gabbay authored
When the system administrator asks the driver to soft or hard reset the device through sysfs, the driver should display a warning in the kernel log to explain why it suddenly resets the device. Reviewed-by:
-
Oded Gabbay authored
Move the code of device CPU initialization from being ASIC-Dependent to common code. In addition, add support for the new error reporting feature of the firmware boot code. Reviewed-by:
-
