| 03be3489 | 24-Aug-2023 |
farah kassabri <fkassabri@habana.ai> |
accel/habanalabs: fix bug in timestamp interrupt handling
[ Upstream commit 0165994c215f321e2d055368f89b424756e340eb ]
There is a potential race between user thread seeking to re-use
a timestamp re
accel/habanalabs: fix bug in timestamp interrupt handling
[ Upstream commit 0165994c215f321e2d055368f89b424756e340eb ]
There is a potential race between user thread seeking to re-use
a timestamp record with new interrupt id, while this record is still
in the middle of interrupt handling and it is about to be freed.
Imagine the driver set the record in_use to 0 and only then fill the
free_node information. This might lead to unpleasant scenario where
the new registration thread detects the record as free to use, and
change the cq buff address. That will cause the free_node to get
the wrong buffer address to put refcount to.
Signed-off-by: farah kassabri <fkassabri@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
| db5ba2c1 | 09-Aug-2023 |
Tomer Tayar <ttayar@habana.ai> |
accel/habanalabs: export dma-buf only if size/offset multiples of PAGE_SIZE
[ Upstream commit 0b75cb5b240fddf181c284d415ee77ef61b418d6 ]
It is currently allowed for a user to export dma-buf with si
accel/habanalabs: export dma-buf only if size/offset multiples of PAGE_SIZE
[ Upstream commit 0b75cb5b240fddf181c284d415ee77ef61b418d6 ]
It is currently allowed for a user to export dma-buf with size and
offset that are not multiples of PAGE_SIZE.
The exported memory is mapped for the importer device, and there it will
be rounded to PAGE_SIZE, leading to actually exporting more than the
user intended to.
To make the user be aware of it, accept only size and offset which are
multiple of PAGE_SIZE.
Signed-off-by: Tomer Tayar <ttayar@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
| 5175a72c | 26-Jan-2024 |
Krystian Pradzynski <krystian.pradzynski@intel.com> |
accel/ivpu/40xx: Stop passing SKU boot parameters to FW
[ Upstream commit 553099da45397914a995dce6307d6c26523c2567 ]
This parameter was never used by the 40xx FW.
Signed-off-by: Krystian Pradzynsk
accel/ivpu/40xx: Stop passing SKU boot parameters to FW
[ Upstream commit 553099da45397914a995dce6307d6c26523c2567 ]
This parameter was never used by the 40xx FW.
Signed-off-by: Krystian Pradzynski <krystian.pradzynski@intel.com>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240126122804.2169129-7-jacek.lawrynowicz@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
| 98951886 | 26-Jan-2024 |
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> |
accel/ivpu: Disable d3hot_delay on all NPU generations
[ Upstream commit a7f31091ddf457352e3dd7ac183fdbd26b4dcd04 ]
NPU does not require this delay regardless of the generation.
All generations are
accel/ivpu: Disable d3hot_delay on all NPU generations
[ Upstream commit a7f31091ddf457352e3dd7ac183fdbd26b4dcd04 ]
NPU does not require this delay regardless of the generation.
All generations are integrated into the SOC.
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240126122804.2169129-4-jacek.lawrynowicz@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
| f8d0c6d1 | 08-Dec-2023 |
Jeffrey Hugo <quic_jhugo@quicinc.com> |
accel/qaic: Implement quirk for SOC_HW_VERSION
[ Upstream commit 4c8874c2a6512b9fe7285cab1a6910d9211a6cfb ]
The SOC_HW_VERSION register in the BHI space is not correctly initialized
by the device a
accel/qaic: Implement quirk for SOC_HW_VERSION
[ Upstream commit 4c8874c2a6512b9fe7285cab1a6910d9211a6cfb ]
The SOC_HW_VERSION register in the BHI space is not correctly initialized
by the device and in many cases contains uninitialized data. The register
could contain 0xFFFFFFFF which is a special value to indicate a link
error in PCIe, therefore if observed, we could incorrectly think the
device is down.
Intercept reads for this register, and provide the correct value - every
production instance would read 0x60110200 if the device was operating as
intended.
Fixes: a36bf7af868b ("accel/qaic: Add MHI controller")
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com>
Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231208163101.1295769-3-quic_jhugo@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
| 83a42d79 | 04-Dec-2023 |
Andrzej Kacprowski <Andrzej.Kacprowski@intel.com> |
accel/ivpu/37xx: Fix interrupt_clear_with_0 WA initialization
[ Upstream commit 35c49cfc8b702eda7a0d3f05497b16f81b69e289 ]
Using PCI Device ID/Revision to initialize the interrupt_clear_with_0
work
accel/ivpu/37xx: Fix interrupt_clear_with_0 WA initialization
[ Upstream commit 35c49cfc8b702eda7a0d3f05497b16f81b69e289 ]
Using PCI Device ID/Revision to initialize the interrupt_clear_with_0
workaround is problematic - there are many pre-production
steppings with different behavior, even with the same PCI ID/Revision
Instead of checking for PCI Device ID/Revision, check the VPU
buttress interrupt status register behavior - if this register
is not zero after writing 1s it means there register is RW
instead of RW1C and we need to enable the interrupt_clear_with_0
workaround.
Fixes: 7f34e01f77f8 ("accel/ivpu: Clear specific interrupt status bits on C0")
Signed-off-by: Andrzej Kacprowski <Andrzej.Kacprowski@intel.com>
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Link: https://lore.kernel.org/all/20231204122331.40560-1-jacek.lawrynowicz@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
| 790c480d | 15-Nov-2023 |
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> |
accel/ivpu/37xx: Fix hangs related to MMIO reset
[ Upstream commit 3f7c0634926daf48cd2f6db6c1197a1047074088 ]
There is no need to call MMIO reset using VPU_37XX_BUTTRESS_VPU_IP_RESET
register. IP w
accel/ivpu/37xx: Fix hangs related to MMIO reset
[ Upstream commit 3f7c0634926daf48cd2f6db6c1197a1047074088 ]
There is no need to call MMIO reset using VPU_37XX_BUTTRESS_VPU_IP_RESET
register. IP will be reset by FLR or by entering d0i3. Also IP reset
during power_up is not needed as the VPU is already in reset.
Removing MMIO reset improves stability as it a partial device reset
that is not safe in some corner cases.
This change also brings back ivpu_boot_pwr_domain_disable() that
helps to properly power down VPU when it is hung by a buggy workload.
Signed-off-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com>
Fixes: 828d63042aec ("accel/ivpu: Don't enter d0i3 during FLR")
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231115111004.1304092-1-jacek.lawrynowicz@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|